Bug#695937: Segfault with gnome-control-center, presumably cogl's fault
Package: libcogl9
Version: 1.10.2-6
Severity: normal
Tags: upstream
On my mostly wheezy-ish system, gnome-control-center segfaults with the
following back trace. I'm not quite sure what's wrong, but reading the code
in cogl-pipeline-fragend-arbfp.c, it looks strange to pass on a pointer
to gl_program, when that itself is NULL. Especially in combination with the
params=0x2d argument for __indirect_glProgramParameters4fvNV().
Note that I don't have an ordinary gnome-session running, nor is the
gnome-settings-daemon up - if that matters.
Note that 1.10.2-6exp1 fails in the very same way. I didn't test 1.12, as I
don't expect that to hit wheezy, anymore.
Program received signal SIGSEGV, Segmentation fault.
__memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:91
91 ../sysdeps/x86_64/multiarch/memcpy-ssse3.S: No such file or directory.
(gdb) bt
#0 __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:91
#1 0x7fffe1c47b0b in __indirect_glProgramParameters4fvNV (target=8559836,
index=45, num=-1538988976, params=0x2d) at indirect.c:9317
#2 0x7fffe4d4d855 in _cogl_pipeline_fragend_arbfp_end (pipeline=0x6bf5a0,
pipelines_difference=optimized out) at ./cogl-pipeline-fragend-arbfp.c:868
#3 0x7fffe4d4b9e2 in _cogl_pipeline_flush_gl_state (pipeline=0x6bf5a0,
skip_gl_color=skip_gl_color@entry=0,
n_tex_coord_attribs=n_tex_coord_attribs@entry=0) at
./cogl-pipeline-opengl.c:1290
#4 0x7fffe4d27848 in cogl_context_new (display=optimized out,
error=error@entry=0x7fffe2d8) at ./cogl-context.c:427
#5 0x7fffe5427333 in clutter_backend_real_create_context
(error=0x7fffe478, backend=0x6c05b0) at ./clutter-backend.c:341
#6 clutter_backend_real_create_context (backend=0x6c05b0,
error=0x7fffe478) at ./clutter-backend.c:256
#7 0x7fffe543e2b3 in _clutter_feature_init
(error=error@entry=0x7fffe478) at ./clutter-feature.c:107
#8 0x7fffe5449cda in clutter_init_real (error=error@entry=0x7fffe478)
at ./clutter-main.c:1571
#9 0x7fffe5449f0b in post_parse_hook (error=0x7fffe478,
context=optimized out, group=optimized out, data=optimized out) at
./clutter-main.c:1782
#10 post_parse_hook (context=optimized out, group=optimized out,
data=optimized out, error=0x7fffe478) at ./clutter-main.c:1750
#11 0x761045d7 in g_option_context_parse () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x7fffe544a1d2 in clutter_parse_args (error=0x7fffe470, argv=0x0,
argc=0x0) at ./clutter-main.c:2018
#13 clutter_init (argc=0x0, argv=0x0) at ./clutter-main.c:2080
#14 0x7fffe590be34 in cheese_gtk_init () from
/usr/lib/x86_64-linux-gnu/libcheese-gtk.so.21
#15 0x7fffe6052bc3 in g_io_module_load () from
/usr/lib/control-center-1/panels/libuser-accounts.so
#16 0x766566a6 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#17 0x763dba41 in g_type_module_use () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x76656a84 in g_io_modules_load_all_in_directory_with_scope () from
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#19 0x0040a9ca in ?? ()
#20 0x763d8a97 in g_type_create_instance () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#21 0x763bd818 in ?? () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#22 0x763bf2d1 in g_object_newv () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#23 0x763bf91c in g_object_new () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#24 0x00408d42 in main ()
(gdb) frame 1
#1 0x7fffe1c47b0b in __indirect_glProgramParameters4fvNV (target=8559836,
index=45, num=-1538988976, params=0x2d) at indirect.c:9317
9317indirect.c: No such file or directory.
(gdb) print gc-pc+16
$1 = (GLubyte *) 0x829cdc \a
(gdb) print params
$2 = (const GLfloat *) 0x2d
(gdb) frame 2
#2 0x7fffe4d4d855 in _cogl_pipeline_fragend_arbfp_end (pipeline=0x6bf5a0,
pipelines_difference=optimized out) at ./cogl-pipeline-fragend-arbfp.c:868
868 GE (ctx, glGenPrograms (1, shader_state-gl_program));
(gdb) print shader_state
$3 = (CoglPipelineShaderState *) 0x7c2580
(gdb) print *shader_state
$4 = {ref_count = 3, user_program = 0x0, source = 0x79cec0, gl_program = 0,
unit_state = 0x0, next_constant_id = 0, user_program_age = 0,
last_used_for_pipeline = 0x0}
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.7.0-argodan (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libcogl9 depends on:
ii libc6 2.13-37
ii libgdk-pixbuf2.0-0 2.26.1-1
ii libgl1-mesa-glx 8.0.5-3
ii libglib2.0-02.33.12+really2.32.4-3
ii libx11-62:1.5.0-1
ii libxcomposite1 1:0.4.3-2
ii libxdamage1 1:1.1.3-2
ii libxext62:1.3.1-2
ii libxfixes3 1:5.0-4
ii
Bug#695156: Qt QML XmlHttpRequest insecure redirection
On Tue, Dec 04, 2012 at 07:04:51PM +0100, Thijs Kinkhorst wrote: Package: qt4-x11 Severity: serious Tags: security patch Hi, A security advisory has been posted by Qt regarding XmlHttpRequest insecure redirection: http://lists.qt-project.org/pipermail/announce/2012-November/14.html A patch is available in their advisory. This is CVE-2012-5624. AFAICS stable is not affected. QT maintainers, please double-check. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695916: libreoffice-common: libreoffice installs its own /ust/bin/soffice instead of using debian alternatives system
Hi, On Fri, Dec 14, 2012 at 04:14:38PM +0100, Rene Engelhard wrote: To make that more clear. UNO bootstrap uses /usr/bin/soffice. That's why it's there, I would more like to have it NOT in /usr/bin _at all_ as the name already is misleading and is a remain from the prorietary *S*tar*Office*. But no, we need to keep it and we need to make sure it is the right one for what we ship - what we do. (This is also why libreoffice-common conflicts openoffice.org-common) And to make it even more clear: http://cgit.freedesktop.org/libreoffice/core/log/?h=libreoffice-4-0qt=grepq=API+CHANGE (as you see, this *will be* in LO 4.0 beginning of next year already) What are you doing with stuff using that accessing /usr/bin/soffice and assuming it's AOO which includes those obsolete API which would happen if soffice was an alternative? [1] Regards, Rene [1] There shouldn't be much using that (if at all), but it's the theory which counts.. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695916: libreoffice-common: libreoffice installs its own /ust/bin/soffice instead of using debian alternatives system
Hi Rene, Le 14/12/2012 16:02, Rene Engelhard a écrit : severity 695916 wishlist tag 695916 wontfix retitle 695916 libreoffice-common: pleasse use alternatives system for /usr/bin/soffice thanks On Fri, Dec 14, 2012 at 11:15:21AM +0100, Luc Maisonobe wrote: Package: libreoffice-common Version: 1:3.5.4+dfsg-4 Severity: normal No. It's wishlist. See below. OK. Since the fork between LibreOffice and OpenOffice.org (now Apache OpenOffice), both suites install /usr/bin/soffice directly. Yes. This completely prevents users to install both on the same computer, despite Correct. LibreOffice (and Apache OpenOffice too) should use the alternative mechanism to set up the /usr/bin/soffice link. BTW, This is a) a wish OK with that. b) not a bug in Debian in any case but a upstream one (it relies on a /usr/bin/soffice anyways) b1) the Debian policy is to file bug against Debian first, not to upstream. It is the responsibility to the packaging team to forward it upstream if needed, not to the original reporter b2) in many other packages, Debian packagers choose to adapt what is provided upstream, so it is a packaging decision. I'm not claiming it is a right or wrong decision (I do not have the necessary background for that). I just want to make clear that you do have this choice and decided to preserve this link in your packaging. b3) I did not ask to remove this link, I asked for this link to be set up according to the alternatives mechanism which is Debian standard c) irrelevant in Debian as that doesn't have Apache OpenOffice packages (not even RFPed/ITPed) But even then: - how do you ensure external API stuff (especially those using new APIs/features introduced) uses the correct soffice? - or stuff adapted for the fixed (-- vs -, though the latter still work.) command line options in LO? Stuff using that will break when soffice points to a AOO soffice? I am not assuming any of these. There are legitimate use that many users would find helpful. Just being able to launch one of the program using mime type from a file explorer (say gnome nautilus) for example does not use any custom flag. So for such uses (which correspond proably to 99% of the uses), letting the user make his own choices would be nice. But even then, for use that require a specific version would of course not rely on the anonymous link but rather on the specific target of the link (or use loffice link). Relyng on an historical link for such thing would of course be an error. This is exactly what the alternatives system is used for. For really simple things like launching a program perhaps with one file argument, the common link that can be provided by several programs is good, so people do not need to care about that. For more complex thing were people really need to know which program they use, and since they are power user they *do* need to have several alternatives installed, the link is not useful. But here, the current behaviour completely prevent installation! I am not claming the two suites can be completely replaced by one other, and in fact it is even exactly my point: I need to have the two installed *because* they are not the same. I don't mess with the link and would be more than happy than this link disappear. But now, a link that is not useful prevents installation. I don't think mangling a such-important thing like soffice is a good idea. I don't think fighting against users to prevent them doing their own choices as responsible people is a good choice either. Couls you please reconsider this wish. Regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695882: menu: su-to-root runs root applications using user's HOME, when SU_TO_ROOT_X=sux
On Fri, Dec 14, 2012 at 07:04:49AM -0800, snailbox88-...@yahoo.com wrote:
As you can see, su-to-root is a rather stupid wrapper and does not make
any policy decision by itself. Whether HOME should be kept or changed is a
policy decision, and the su-to-root documentation does not take side on this
issue.
The manpage for su-to-root didn't mention about this, so the problem must be
with sux, but only when it is called from su-to-root? I remember there's
still that other problem with sux in Debian concerning having 'no job control
in this shell.'
Are you using systemd ?
For me it fails with
'env: -c: No such file or directory'
I get that same message when I set SU_TO_ROOT_SU=sux in /etc/su-to-rootrc. I
guess I didn't explicitly differentiate between SU_TO_ROOT_X and
SU_TO_ROOT_SU in my forum posts.
I get this error when calling
DISPLAY=:0 SU_TO_ROOT_X=sux su-to-root -X -c xterm
and su-to-root -X will set SU_TO_ROOT_SU to sux by itself.
With regard to SU_TO_ROOT_SU, as per the manpage the default is
SU_TO_ROOT_SU=su. To help you replicate the behavior I was observing, please
see if /etc/su-to-rootrc in your system contains the following:
SU_TO_ROOT_X=sux
SU_TO_ROOT_SU=su
OK, I see what you report: by setting SU_TO_ROOT_SU=su,
you force su-to-root to use su instead of sux, so you
are actually using su, so you are bypassing the bug with su-to-root.
Probably this is not the expected behaviour, though it is pointless to
set SU_TO_ROOT_SU to su since it is the default value anyway.
Now to your report, it seems the su behaviour is correct, see the bug reports
#246886 and #150314. Basically, if su reset $HOME, then X programs will fail to
find the .Xauthority file.
So what su-to-root script do you use ?
I'm not really using any script. I observed the undesired behavior when I ran
GSmartControl by selecting it from the menu. Upon inspecting the .desktop for
GSmartControl, it has
su-to-root is a script!
Please remove SU_TO_ROOT_SU=su from your su-to-rootrc file and try the script
in attachment
which fix the bug with sux.
Cheers,
Bill.
#!/bin/bash
if test -r /etc/su-to-rootrc; then
. /etc/su-to-rootrc
fi
if test -r ~/.su-to-rootrc; then
. ~/.su-to-rootrc
fi
PRIV=root
COMMAND=
NEEDS=text
gettext=$(which gettext 2/dev/null)
transl() {
txt=$1;
shift;
if [ -n $gettext ]; then
txt=$(gettext su-to-root $txt);
fi
printf $txt $@
}
eshell() {
getent passwd $1 | cut -f7 -d:
}
usage () {
transl 'usage: %s [-X] [-p user] -c command
-c command: command to execute as a string (mandatory)
-p user: user to switch to (default: root)
-X: command is a X11 program\n' $0 2
exit 1
}
for i in $@; do
case $prev in
-p)
PRIV=$i;;
-c)
COMMAND=$i;;
-X)
NEEDS=X11;;
esac
prev=$i
done
if [ -z $COMMAND ] ; then
usage;
fi
euid=$(id -u)
privid=$(id -u $PRIV)
if test $euid = $privid; then
sh -c $COMMAND
else
case $NEEDS in
text)
if test $euid != 0; then
transl 'About to execute %s.\n' $COMMAND
transl 'This command needs %s privileges to be executed.\n' $PRIV
fi
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin
SHELL=`eshell $PRIV`
case $SU_TO_ROOT_SU in
sux) suname=sux; pwuser=$PRIV; cmd='sux -p $PRIV $COMMAND';;
sudo) suname=sudo;pwuser=$USER; cmd='sudo -u $PRIV sh -c $COMMAND';;
*)suname=su; pwuser=$PRIV; cmd='su -p $PRIV -c $COMMAND';;
esac
transl 'Using %s...\n' $suname
transl 'Enter %s password at prompt.\n' $pwuser
yesexpr=$(locale yesexpr)
while ! eval $cmd; do
transl 'Incorrect password or command failed. Try again? (y/N)'
read ans
if echo $ans | perl -e =~ /$yesexpr/ and exit(1);; then
exit 1
fi
done;;
X11)
if test -z $SU_TO_ROOT_X; then
if which gksu /dev/null 21 ; then
SU_TO_ROOT_X=gksu
if test X$KDE_FULL_SESSION = Xtrue ; then
if which kdesu /dev/null 21 ; then
SU_TO_ROOT_X=kdesu
elif test -x /usr/lib/kde4/libexec/kdesu ; then
SU_TO_ROOT_X=kde4su
fi;
fi;
elif which kdesu /dev/null 21 ; then
SU_TO_ROOT_X=kdesu
elif test -x /usr/lib/kde4/libexec/kdesu ; then
SU_TO_ROOT_X=kde4su
elif which ktsuss /dev/null 21 ; then
SU_TO_ROOT_X=ktsuss
elif which sux /dev/null 21 ; then
SU_TO_ROOT_X=sux
else
SU_TO_ROOT_X=su-to-root
fi
fi
case $SU_TO_ROOT_X in
gksu) gksu -u $PRIV $COMMAND;;
gksudo) gksudo -u $PRIV $COMMAND;;
kdesu) kdesu -u $PRIV $COMMAND;;
kdesudo) kdesudo -u $PRIV $COMMAND;;
kde4su) /usr/lib/kde4/libexec/kdesu -u $PRIV $COMMAND;;
ktsuss) ktsuss -u $PRIV $COMMAND;;
sux) env SU_TO_ROOT_SU=sux \
x-terminal-emulator -e su-to-root -p $PRIV -c $COMMAND;;
# As a last resort, open a new x-terminal-emulator and prompt for the
Bug#695938: locales: date format %x returns wrong format in Dutch
Package: locales Version: 2.11.3-4 Severity: minor LC_TIME=nl_NL date +%x Expected result: 14-12-2012 Actual result: -- 14-12-12 I'm from the Netherlands and can assure you nobody writes or uses dates like dd-mm-yy, while the documentation of strftime (man strftime) states %x The preferred date representation for the current locale without the time. -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-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 locales depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii libc6 [glibc-2.11-1] 2.11.3-4 Embedded GNU C Library: Shared lib locales recommends no packages. locales suggests no packages. -- debconf information: locales/default_environment_locale: None locales/locales_to_be_generated: de_DE ISO-8859-1, de_DE.UTF-8 UTF-8, de_DE@euro ISO-8859-15, en_GB ISO-8859-1, en_GB.ISO-8859-15 ISO-8859-15, en_GB.UTF-8 UTF-8, en_US ISO-8859-1, en_US.ISO-8859-15 ISO-8859-15, en_US.UTF-8 UTF-8, fr_FR ISO-8859-1, fr_FR.UTF-8 UTF-8, fr_FR@euro ISO-8859-15, nl_BE ISO-8859-1, nl_BE.UTF-8 UTF-8, nl_BE@euro ISO-8859-15, nl_NL ISO-8859-1, nl_NL.UTF-8 UTF-8, nl_NL@euro ISO-8859-15 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695939: im-config: Japanese dialog get wrong encoding treatment
Package: im-config Version: 0.19 Severity: normal This is the result of zenity Bug#695933: zenity: zenity --text-info Chokes on some UTF-8 string Not much I can do ... -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.6-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages im-config depends on: ii dialog1.1-20120215-3 ii gettext-base 0.18.1.1-10 ii zenity3.4.0-2 Versions of packages im-config recommends: ii dialog 1.1-20120215-3 ii x11-common 1:7.7+1 im-config suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695916: libreoffice-common: libreoffice installs its own /ust/bin/soffice instead of using debian alternatives system
Hi, On Fri, Dec 14, 2012 at 04:34:01PM +0100, Luc Maisonobe wrote: b1) the Debian policy is to file bug against Debian first, not to upstream. It is the responsibility to the packaging team to forward it upstream if needed, not to the original reporter And guess what? I think that this is nonsense for bugs clearly in the upstream domain. And I won't forward bugs I don't consider nonsense either way. b3) I did not ask to remove this link, I asked for this link to be set up according to the alternatives mechanism which is Debian standard for stuff with *EXACTLY THE SAME INTERFACE*. Which is not true between AOO and LO (anymore). I am not assuming any of these. There are legitimate use that many users would find helpful. Just being able to launch one of the program using mime type from a file explorer (say gnome nautilus) for example does not use any custom flag. So for such uses (which correspond proably to 99% of the uses), letting the user make his own choices would be nice. Correct. But that shouldn't use soffice (and no menu entry does.) and LOs mimetype entries have the -- form, so they *ARE* going to break when the alternatives points to something else. Would you like soffice being a alternaive but becauseof the incompatibility stuff using it conflicting against openoffice? Wouldn't help you instead of making the problem even more complex to solve. But even then, for use that require a specific version would of course not rely on the anonymous link but rather on the specific target of the link (or use loffice link). Relyng on an historical link for such thing would of course be an error. The problem is that the programmer using the API doesn't do it him-/herself. AOO/LOs libraries do it in bootstrap somehow. The programm,er has no influcene here: rene@frodo:~/LibreOffice/libreoffice-4-0/core$ grep -r soffice sal* cppu* sal/qa/osl/profile/osl_old_testprofile.cxx: rtl_uString_newFromAscii(ustrProfileName,//./tmp/soffice.ini); sal/qa/osl/profile/osl_old_testprofile.cxx: rtl_uString_newFromAscii(ustrProfileName2,//./tmp/not_existing_path/soffice.ini); sal/osl/unx/salinit.cxx:// On Mac OS X, soffice can restart itself via exec (see restartOnMac in sal/osl/unx/salinit.cxx:// of processes here, not just soffice, but hopefully none of our processes sal/osl/unx/profile.c:#define SVERSION_PROFILEsofficerc sal/osl/unx/signal.c:static sal_Bool is_soffice_Impl (void) sal/osl/unx/signal.c:idx = rtl_str_indexOfStr (rtl_string_getStr (strProgName), soffice); sal/osl/unx/signal.c:if (is_soffice_Impl()) sal/osl/unx/signal.c: crash soffice re-execs itself from within the signal handler, so the sal/osl/unx/signal.c: second soffice would have the guilty signal blocked and would freeze upon sal/osl/w32/profile.cxx:#define SVERSION_PROFILEsoffice.ini sal/osl/w32/profile.cxx:/* if we have not product identfication, do a special handling for soffice.ini */ cppuhelper/Module_cppuhelper.mk:StaticLibrary_findsofficepath \ cppuhelper/source/bootstrap.cxx:#include cppuhelper/findsofficepath.h cppuhelper/source/bootstrap.cxx:OUSTR(no soffice installation found!)); cppuhelper/source/bootstrap.cxx:OUSTR(bad characters in soffice installation path!)); cppuhelper/source/bootstrap.cxx:OUSTR(cannot convert soffice installation path to URL!)); cppuhelper/source/bootstrap.cxx:OUString(path + soffice).pData, ar_args, ARLEN( ar_args ), cppuhelper/source/findsofficepath.c: * pAn installation is found, if the executable 'soffice' or a symbolic link cppuhelper/source/findsofficepath.c:/* construct soffice file path */ cppuhelper/source/findsofficepath.c:/* check existence of soffice file */ cppuhelper/Package_inc.mk:$(eval $(call gb_Package_add_file,cppuhelper_inc,inc/cppuhelper/findsofficepath.h,cppuhelper/findsofficepath.h)) cppuhelper/Library_cppuhelper.mk: findsofficepath \ cppuhelper/inc/cppuhelper/findsofficepath.h:/* Internal function to find an soffice installation. cppuhelper/StaticLibrary_findsofficepath.mk:$(eval $(call gb_StaticLibrary_StaticLibrary,findsofficepath)) cppuhelper/StaticLibrary_findsofficepath.mk:$(eval $(call gb_StaticLibrary_use_packages,findsofficepath,\ cppuhelper/StaticLibrary_findsofficepath.mk:$(eval $(call gb_StaticLibrary_add_cobjects,findsofficepath,\ cppuhelper/StaticLibrary_findsofficepath.mk: cppuhelper/source/findsofficepath \ Note the static soffice in bootstrap.cxx. This is exactly what the alternatives system is used for. For really simple things like launching a program perhaps with one file argument, the common link that can be provided by several programs is good, so people do not need to care about that. For more complex thing were No, it isn't. Guess why gcc isn't an alternaive? For a similar reason. (Reproducible builds, standard library incompatibilities, etc.) I don't think fighting
Bug#695940: im-config: GUI panel started too early.
Package: im-config Version: 0.19 Severity: critical Justification: breaks unrelated software For uim, panel GUI is started too early. It was fixed in 0.18 for most IMs but there were some regression for uim. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.6-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages im-config depends on: ii dialog1.1-20120215-3 ii gettext-base 0.18.1.1-10 ii zenity3.4.0-2 Versions of packages im-config recommends: ii dialog 1.1-20120215-3 ii x11-common 1:7.7+1 im-config suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695801: debian/compat -- allow to specify compatibility range with debhelper taking the largest specified
Yaroslav Halchenko wrote: But often dh-based packaging itself is simple/generic enough to work fine even with previous releases of debhelper still in production in Debian stable or its derivatives If a new compat level does not change a package, the package can be left on the old compat level. The only problem with this is that it requires people to actually think about whether a new compat level will affect a package, rather than increasing to the new level because it's there and waiting to see if something breaks. But expecting packagers to select a range of compat levels that will work is even more of a burden. So I don't see it helping. -- see shy jo signature.asc Description: Digital signature
Bug#695941: does not honour PREF parameters
Package: python-vobject Version: 0.8.1c-4 Severity: normal Tags: upstream vobject.adr seems to be the first entry of vobject.adr_list, unconditionally, even if the second entry has a higher-ranked (= lower) preference parameter, e.g. ADR;PREF=2:foo ADR;PREF=1:bar In this case, vobject.adr should really correspond to the bar entry. Along similar lines, it would be good if there were a filter function for adr_list and other type entries that can be duplicated and have PREF parameters. Thanks for your consideration, -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.5-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-vobject depends on: ii python 2.7.3-3 ii python-dateutil 1.5+dfsg-0.1 ii python-support 1.0.15 python-vobject recommends no packages. python-vobject suggests no packages. -- no debconf information -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#695772: bugs.cgi: allow filtering based on unblock/approve hints
Hi,
On Wed, Dec 12, 2012 at 05:01:28PM +0100, Niels Thykier wrote:
Please allow the possibility to filter bugs based on unblock or approve
hints
by the release team. The attached patch frovides these filters.
Good idea. :)
I'd probably merge them into one entry as approve is (for most
practical purposes) unblock for tpu uploads[1].
New patch attached.
And thanks to Adam for the history wrt unblock vs approve.
Cheers,
Ivo
diff --git a/web/bugs.cgi b/web/bugs.cgi
index 211f78d..ba0fa76 100755
--- a/web/bugs.cgi
+++ b/web/bugs.cgi
@@ -47,6 +47,7 @@ FILTERS = [
['rtwheezy-will-remove', 'RT tag for wheezy: will-remove', id in (select id from bugs_usertags where email='release.debian@packages.debian.org' and tag='wheezy-will-remove')],
['rtwheezy-can-defer', 'RT tag for wheezy: can-defer', id in (select id from bugs_usertags where email='release.debian@packages.debian.org' and tag='wheezy-can-defer')],
['rtwheezy-is-blocker', 'RT tag for wheezy: is-blocker', id in (select id from bugs_usertags where email='release.debian@packages.debian.org' and tag='wheezy-is-blocker')],
+ ['unblock-hint', 'RT unblock hint', source in (select source from hints where type in ('approve','unblock'))],
]
TYPES = [
Bug#695942: Error with boolean query
Package: python-whoosh Version: 2.3.2-2 i386, kernel3.2.0-4-686-pae I've found a problem with queries with the boolean NOT. Try this example: #!/usr/bin/python from whoosh.index import create_in,open_dir from whoosh.fields import * from whoosh.qparser import QueryParser import os class Co: def __init__(self): home_content = './CONTENT' self.schema = Schema(content=TEXT(stored=False),ud=ID(stored=True)) if not os.path.exists(home_content): os.mkdir(home_content) self.ic = create_in(home_content,self.schema) else: self.ic=open_dir(home_content) self.writer = self.ic.writer() self.writer.add_document(content = upippo,ud = u1) self.writer.add_document(content = upluto,ud = u2) self.writer.commit() def search(self,pattern,tipo): with self.ic.searcher() as searcher: qp=QueryParser(tipo,self.ic.schema) query=qp.parse(pattern) results = searcher.search(query,limit=None) for result in results: print result c=Co() c.search(u'NOT pippo',u'content') Try to run this script more times: it gives wrong results and after 8 times gives the follow error: Traceback (most recent call last): File ./content_NOT.py, line 34, in module c.search(u'NOT pippo',u'content') File ./content_NOT.py, line 30, in search print result File /usr/lib/python2.7/dist-packages/whoosh/searching.py, line 1784, in __repr__ return %s %r % (self.__class__.__name__, self.fields()) File /usr/lib/python2.7/dist-packages/whoosh/searching.py, line 1670, in fields self._fields = self.searcher.stored_fields(self.docnum) File /usr/lib/python2.7/dist-packages/whoosh/reading.py, line 722, in stored_fields return self.readers[segmentnum].stored_fields(segmentdoc) File /usr/lib/python2.7/dist-packages/whoosh/filedb/filereading.py, line 156, in stored_fields in iteritems(self.storedfields[docnum]) File /usr/lib/python2.7/dist-packages/whoosh/filedb/filetables.py, line 792, in __getitem__ % (num, self.length)) IndexError: Tried to get document 4, file has 4 Walter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695943: libjs-jquery-fancybox: fancybox css using relative path and it should be absolute
Package: libjs-jquery-fancybox Version: 6-1 Severity: normal Dear Maintainer, The problem is in fancybox css and how it uses Alpha for IE, a good fix for debian is to change it to use absolute paths, so instead of fancy_shadow.png use /javascript/jquery-fancybox/fancy_shadow.png. In fink I'm using this regex to patch it, perl -pi -e s,DXImageTransform\.Microsoft\.AlphaImageLoader.src=',DXImageTransform.Microsoft.AlphaImageLoader\(src='/javascript/jquery-fancybox/,g fancybox/jquery.fancybox.css -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libjs-jquery-fancybox depends on: ii libjs-jquery 1.7.2+dfsg-1 ii libjs-jquery-easing 6-1 ii libjs-jquery-mousewheel 6-1 Versions of packages libjs-jquery-fancybox recommends: ii javascript-common 7 libjs-jquery-fancybox suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695881: patch update
attached a little update to the first patch fixing a couple of forgotten
things.
it applies ontop the last one.
the openblas test is actually a bit sketchy as it does not work properly
in virtual machines (depending on their configuration) which are used to
run the tests automatically.
diff --git a/debian/tests/control b/debian/tests/control
index 5ef860b..ca64018 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -4,11 +4,15 @@ Depends: python-numpy, python-all, python-nose, python-tz
Tests: python3
Depends: python3-numpy, python3-all, python3-nose, python3-tz
+#use update-alternatives
Tests: openblas
+Restrictions: needs-root
Depends: python-numpy, python-all, python-nose, python-tz, libopenblas-base
+#use update-alternatives
Tests: atlas
+Restrictions: needs-root
Depends: python-numpy, python-all, python-nose, python-tz, libatlas3-base
Tests: f2py
-Depends: gfortran, python-numpy, python-numpy-dbg, python-all, python-all-dbg,
python-all-dev, python3-numpy, python3-numpy-dbg, python3-all, python3-all-dbg,
python3-all-dev
+Depends: gcc, gfortran, python-numpy, python-numpy-dbg, python-all,
python-all-dbg, python-all-dev, python3-numpy, python3-numpy-dbg, python3-all,
python3-all-dbg, python3-all-dev
diff --git a/debian/tests/f2py b/debian/tests/f2py
index afbd8b7..7d7c320 100755
--- a/debian/tests/f2py
+++ b/debian/tests/f2py
@@ -17,7 +17,7 @@ for py in 3 $PYS; do
[ $py = ] py=
echo === f2py$py ===
f2py$py -c -m hello hello.f 21
-python -c 'import hello; assert hello.foo(4) == 5'
+python$py -c 'import hello; assert hello.foo(4) == 5'
f2py$py-dbg -c -m hello hello.f 21
-python -c 'import hello; assert hello.foo(4) == 5'
+python$py-dbg -c 'import hello; assert hello.foo(4) == 5'
done
diff --git a/debian/tests/openblas b/debian/tests/openblas
index 211eee6..c4b9eb2 100755
--- a/debian/tests/openblas
+++ b/debian/tests/openblas
@@ -1,6 +1,7 @@
#!/bin/sh
set -efu
-readlink -f /usr/lib/libblas.so.3 21 || true
+blaslib=$(update-alternatives --list libblas.so.3 | grep $(basename $0))
+update-alternatives --set libblas.so.3 $blaslib
# one python is enough
PYS=${PYS:-$(pyversions -d 2/dev/null)}
Bug#695944: centerim-utf8: crash when signing in to MSN
Package: centerim-utf8
Version: 4.22.10-1
Severity: important
Tags: patch
When I sign in to MSN centerim often segfaults.
After looking into the issue it seems to be due to a missing field in a
response from the MSN server.
args[5] here from notificationserver.cpp line ~200 will be undefined since
the vector only has 5 entries:
this-myNotificationServer()-externalCallbacks.gotNewReverseListEntry(this, \
args[4], decodeURL(args[5]));
This is because the MSN server is sometimes sending:
ADD 0 RL 0 user.n...@example.com
Instead of this:
ADD 0 RL 0 user.n...@example.com User%20Name
So my quick fix to this (without any knowledge on the MSN protocol) was to
copy user.n...@example.com to args[5] and that way avoiding the segfault.
I'm attaching an patch that shows how I solved my issue.
-- System Information:
Debian Release: 6.0.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages centerim-utf8 depends on:
ii centerim-common 4.22.10-1 A text-mode multi-protocol instant
ii libc62.11.3-4Embedded GNU C Library: Shared lib
ii libcurl3-gnutls 7.21.0-2.1+squeeze2 Multi-protocol file transfer libra
ii libgcc1 1:4.4.5-8 GCC support library
ii libgnutls26 2.8.6-1+squeeze2the GNU TLS library - runtime libr
ii libgpg-error01.6-1 library for common error values an
ii libgpgme11 1.2.0-1.2 GPGME - GnuPG Made Easy
ii libncursesw5 5.7+20100313-5 shared libraries for terminal hand
ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3
Versions of packages centerim-utf8 recommends:
ii lynx-cur [www-browser] 2.8.8dev.5-1 Text-mode WWW Browser with NLS sup
pn sox none (no description available)
ii w3m [www-browser] 0.5.2-9 WWW browsable pager with excellent
centerim-utf8 suggests no packages.
-- no debconf information
--- tmp/centerim-4.22.10/libmsn/msn/notificationserver.cpp 2010-10-26
19:19:06.0 +0200
+++ centerim-4.22.10/libmsn/msn/notificationserver.cpp 2012-12-13
23:13:09.0 +0100
@@ -191,9 +191,14 @@
void NotificationServerConnection::handle_ADD(std::vectorstd::string
args)
{
+ //std::cerr DEBUG handle_ADD size: args.size() std::endl;
this-assertConnectionStateIsAtLeast(NS_CONNECTED);
if (args[2] == RL)
{
+ if (args.size() == 5)
+ {
+ args.push_back(args[4]);
+ }
this-myNotificationServer()-externalCallbacks.gotNewReverseListEntry(this,
args[4], decodeURL(args[5]));
}
else
Bug#695945: quik-installer returns error during debian-installer
Package: quik-installer Version: 0.0.30 Severity: normal Tags: d-i I'm installing wheezy on an emulated PowerPC machine (qemu-system-ppc 1.2.1, g3beige hardware) from debian-wheezy-DI-b4-powerpc-netinst.iso. Everything in d-i goes fine until the Install quik on a hard disk step, which fails with an error. But if I choose Continue without a bootloader and bypass the scary warning about an unbootable system, the machine boots just fine. So apparently the error is spurious. Possibly relevant excerpt from /var/log/installer/syslog: Dec 14 02:16:27 main-menu[190]: INFO: Menu item 'quik-installer' selected Dec 14 02:16:35 in-target: Reading package lists... Dec 14 02:16:35 in-target: Dec 14 02:16:35 in-target: Building dependency tree... Dec 14 02:16:38 in-target: Dec 14 02:16:38 in-target: Reading state information... Dec 14 02:16:38 in-target: Dec 14 02:16:39 in-target: powerpc-utils is already the newest version. Dec 14 02:16:39 in-target: yaboot is already the newest version. Dec 14 02:16:39 in-target: The following NEW packages will be installed: Dec 14 02:16:39 in-target: quik Dec 14 02:16:41 kernel: [ 3250.076211] ISO 9660 Extensions: Microsoft Joliet Level 3 Dec 14 02:16:41 kernel: [ 3250.078788] ISO 9660 Extensions: RRIP_1991A Dec 14 02:16:46 in-target: 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Dec 14 02:16:46 in-target: Need to get 0 B/68.8 kB of archives. Dec 14 02:16:46 in-target: After this operation, 225 kB of additional disk space will be used. Dec 14 02:16:47 in-target: Selecting previously unselected package quik. Dec 14 02:16:47 in-target: (Reading database ... Dec 14 02:16:47 in-target: 14525 files and directories currently installed.) Dec 14 02:16:47 in-target: Unpacking quik (from .../quik/quik_2.1-9.1_powerpc.deb) ... Dec 14 02:16:47 in-target: Since your boot sector or MBR might still need some files from /boot Dec 14 02:16:47 in-target: this script will preserve them as /boot/filename.preserved Dec 14 02:16:47 in-target: IMPORTANT: In the dpkg prompt answer 'N' to overwriting quik.conf Dec 14 02:16:47 in-target: Processing triggers for man-db ... Dec 14 02:16:56 in-target: Setting up quik (2.1-9.1) ... Dec 14 02:17:01 kernel: [ 3270.083883] ISO 9660 Extensions: Microsoft Joliet Level 3 Dec 14 02:17:01 kernel: [ 3270.086282] ISO 9660 Extensions: RRIP_1991A Dec 14 02:17:01 kernel: [ 3270.562094] ISO 9660 Extensions: Microsoft Joliet Level 3 Dec 14 02:17:01 kernel: [ 3270.563316] ISO 9660 Extensions: RRIP_1991A Dec 14 02:17:02 quik-installer: info: root partition: /dev/sda3 Dec 14 02:17:02 quik-installer: info: boot partition: /dev/sda2 Dec 14 02:17:02 quik-installer: info: architecture: powerpc/powermac_oldworld Dec 14 02:17:14 quik-installer: Second-stage loader is on /dev/sda2 Dec 14 02:17:14 quik-installer: Conffile is /boot/etc/quik.conf Dec 14 02:17:14 quik-installer: Config file is on partition 2 Dec 14 02:17:14 quik-installer: Writing first-stage QUIK boot block to /dev/sda2 Dec 14 02:17:14 quik-installer: Making /dev/sda2 bootable (map entry 2) Dec 14 02:17:14 quik-installer: Writing block table to boot block on /dev/sda2 Dec 14 02:17:16 main-menu[190]: (process:1505): ofpath: Driver pata_macio is not supported Dec 14 02:17:16 main-menu[190]: WARNING **: Configuring 'quik-installer' failed with error code 1 Dec 14 02:17:16 main-menu[190]: WARNING **: Menu item 'quik-installer' failed. Dec 14 02:17:44 main-menu[190]: INFO: Modifying debconf priority limit from 'high' to 'medium' Dec 14 02:17:44 debconf: Setting debconf/priority to medium Dec 14 02:17:50 grub-installer: GRUB requires OF bootable partition mounted at /boot/grub on PowerPC systems Dec 14 02:17:52 main-menu[190]: INFO: Menu item 'nobootloader' selected Dec 14 02:17:57 main-menu[190]: INFO: Restoring default debconf priority 'high' Dec 14 02:17:57 debconf: Setting debconf/priority to high Dec 14 02:18:04 grub-installer: GRUB requires OF bootable partition mounted at /boot/grub on PowerPC systems Dec 14 02:18:04 grub-installer: GRUB requires OF bootable partition mounted at /boot/grub on PowerPC systems Dec 14 02:18:04 main-menu[190]: INFO: Menu item 'finish-install' selected -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Kernel: Linux 3.2.0-4-powerpc Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695946: ITP: libbot-basicbot-pluggable-perl -- extended simple IRC bot for pluggable modules
Package: wnpp Severity: wishlist Owner: Jotam Jr. Trejo jota...@debian.org.sv * Package name: libbot-basicbot-pluggable-perl Version : 0.98 Upstream Author : Mario Domgoergen m...@cpan.org * URL : http://search.cpan.org/dist/Bot-BasicBot-Pluggable/ * License : GPL-1+, Artistic Programming Lang: Perl Description : extended simple IRC bot for pluggable modules Test::Bot::BasicBot::Pluggable was written to provide a minimalistic testing bot in order to write cleaner unit tests for Bot::BasicBot::Pluggable modules. signature.asc Description: Digital signature
Bug#695947: cheese: Cheese leaves webcam LED lit (failed de-initialization?)
Package: cheese Version: 3.4.2-2 Severity: normal This thinkpad X220 has the following USB integrated webcam: Bus 001 Device 004: ID 04f2:b217 Chicony Electronics Co., Ltd Lenovo Integrated Camera (0.3MP) If i launch cheese, it turns on the camera and the camera's LED gets lit. when i choose Cheese → Quit from the menu, cheese closes, but the camera's LED stays lit. When i launch cheese again, the camera's LED turns off during the startup of the application, and then turns back on when the video appears within the frame (it's off for about 2 seconds total). So i suspect that cheese is failing to de-initialize the camera properly. fwiw, i also see the following spew from cheese's stderr (i don't know if any of this is relevant, or if it's all just noise): -- (cheese:13809): Gtk-WARNING **: Attempting to add a widget with type GtkImage to a GtkToggleButton, but as a GtkBin subclass a GtkToggleButton can only contain one widget at a time; it already contains a widget of type GtkLabel (cheese:13809): Gtk-WARNING **: Attempting to add a widget with type GtkImage to a GtkToggleButton, but as a GtkBin subclass a GtkToggleButton can only contain one widget at a time; it already contains a widget of type GtkLabel (cheese:13809): Gtk-WARNING **: Attempting to add a widget with type GtkImage to a GtkToggleButton, but as a GtkBin subclass a GtkToggleButton can only contain one widget at a time; it already contains a widget of type GtkLabel (cheese:13809): Gtk-WARNING **: Attempting to add a widget with type GtkImage to a GtkButton, but as a GtkBin subclass a GtkButton can only contain one widget at a time; it already contains a widget of type GtkLabel (cheese:13809): Gtk-WARNING **: Attempting to add a widget with type GtkGrid to a GtkToggleButton, but as a GtkBin subclass a GtkToggleButton can only contain one widget at a time; it already contains a widget of type GtkLabel (cheese:13809): Gtk-WARNING **: Attempting to add a widget with type GtkImage to a GtkButton, but as a GtkBin subclass a GtkButton can only contain one widget at a time; it already contains a widget of type GtkLabel ** (cheese:13809): WARNING **: could not generate thumbnail for /home/dkg/.gnome2/cheese/media/2011-08-11-151048.ogv (video/ogg) ** (cheese:13809): WARNING **: could not generate thumbnail for /home/dkg/.gnome2/cheese/media/2011-08-11-151002.ogv (video/ogg) -- all of the above is generated before the video appears in the application window. --dkg -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-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 cheese depends on: ii cheese-common 3.4.2-2 ii gnome-video-effects 0.4.0-1 ii libc6 2.13-37 ii libcanberra-gtk3-00.28-6 ii libcheese-gtk21 3.4.2-2 ii libcheese33.4.2-2 ii libclutter-1.0-0 1.10.8-2 ii libclutter-gtk-1.0-0 1.2.0-2 ii libgdk-pixbuf2.0-02.26.1-1 ii libgee2 0.6.4-2 ii libglib2.0-0 2.33.12+really2.32.4-3 ii libgnome-desktop-3-2 3.4.2-1 ii libgstreamer0.10-00.10.36-1 ii libgtk-3-03.4.2-4 Versions of packages cheese recommends: ii gnome-icon-theme3.4.0-2 pn gvfsnone ii hicolor-icon-theme 0.12-1 pn nautilus-sendto none pn yelpnone cheese suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695948: /usr/bin/gsettings: gsettings segfaults on startup
Package: libglib2.0-bin Version: 2.33.12+really2.32.4-3 Severity: normal File: /usr/bin/gsettings Dear Maintainer, I got following message on my box: gsettings[5020]: segfault at 10 ip 7fc5f8589193 sp 7fffcb450478 error 6 in libgio-2.0.so.0.3200.4[7fc5f84e+14c000] PLS tell me, if you need further information. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libglib2.0-bin depends on: ii dpkg 1.16.9 ii libc62.13-37 ii libelf1 0.152-1+wheezy1 ii libglib2.0-0 2.33.12+really2.32.4-3 ii libglib2.0-data 2.33.12+really2.32.4-3 libglib2.0-bin recommends no packages. libglib2.0-bin suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695543: bugs.cgi: also show removal requests
Control: retitle -1 bugs.cgi: show unblock and removal requests based on
usertags
Hi,
On Mon, Dec 10, 2012 at 12:28:02AM +0100, Ivo De Decker wrote:
In bugs.cgi the unblock requests are shown based on bugs against
release.debian.org that match '^unblock (package)'. A number of unblock
requests have a (slightly) different title. They all (should) have an unblock
usertag, so the unblock requests can be found based on that usertag. That way,
more unblock can be found and displayed.
The attached patch (on top of the previous one) also show removal requests
(from testing and unstable).
Cheers,
Ivo
diff --git a/web/bugs.cgi b/web/bugs.cgi
index ba0fa76..4c2a2ea 100755
--- a/web/bugs.cgi
+++ b/web/bugs.cgi
@@ -358,10 +358,11 @@ if cols['chints']
hints[r['source']] ||= []
hints[r['source']] r
end
- sthh = dbh.prepare(select distinct bugs_usertags.id as id, bugs_usertags.tag as tag, bugs.title as title from bugs_usertags, bugs where bugs.id = bugs_usertags.id and bugs_usertags.email='release.debian@packages.debian.org' and bugs_usertags.tag='unblock' and bugs.status = 'pending')
+ sthh = dbh.prepare(select distinct bugs_usertags.id as id, bugs_usertags.tag as tag, bugs.title as title from bugs_usertags, bugs where bugs.id = bugs_usertags.id and bugs_usertags.email in ('release.debian@packages.debian.org','ftp.debian@packages.debian.org') and bugs_usertags.tag in ('unblock','rm','remove') and bugs.status = 'pending')
sthh.execute
rowsh = sthh.fetch_all
unblockreq = {}
+ unblockreqtype = {}
ids = []
rowsh.each do |r|
src = (/[^-a-zA-Z0-9.]([-a-zA-Z0-9.]+)\//.match(r['title']) || [] ) [1] || ;
@@ -370,6 +371,7 @@ if cols['chints']
end
unblockreq[src] ||= []
unblockreq[src] r['id']
+unblockreqtype[r['id']] = r['tag']
ids r['id']
end
ids = ids.join(',')
@@ -446,7 +448,7 @@ puts 'thlastnbsp;modified/th/tr'
puts '/thead'
puts 'tbody'
-def genhints(source, hints, unblockreq, tags)
+def genhints(source, hints, unblockreq, tags, type)
s = ''
if not hints.nil?
hints.each do |h|
@@ -457,7 +459,12 @@ def genhints(source, hints, unblockreq, tags)
end
if not unblockreq.nil?
unblockreq.each do |u|
- s += req:a href=\http://bugs.debian.org/#{u}\;##{u}/a#{gentags(tags[u])}
+ if (type[u] != unblock)
+ s += #{type[u]};
+ else
+ s += req
+ end
+ s += :a href=\http://bugs.debian.org/#{u}\;##{u}/a#{gentags(tags[u])}
end
end
s
@@ -530,7 +537,7 @@ rows.each do |r|
puts td#{CGI::escapeHTML(r['title'])}/td
puts td#{r['popcon']}/td if cols['cpopcon']
puts td#{r['severity']}/td if cols['cseverity']
- puts td#{genhints(r['source'], hints[r['source']], unblockreq[r['source']], unblockreqtags)}/td if cols['chints']
+ puts td#{genhints(r['source'], hints[r['source']], unblockreq[r['source']], unblockreqtags, unblockreqtype)}/td if cols['chints']
puts td#{claimedbugs[r['id']]}/td if cols['cclaimed']
puts td#{deferredbugs[r['id']]}/td if cols['cdeferred']
puts td#{rttags[r['id']]}/td if cols['crttags']
Bug#695906: ifupdown: removal of /etc/network/interfaces is not preserved
Tollef Fog Heen wrote: rm /etc/network/interfaces apt-get --reinstall install ifupdown observe that /etc/network/interfaces exists. If I remove the file, that change should be preserved on upgrades. But /etc/network/interfaces is not an ifupdown conffile. Bob signature.asc Description: Digital signature
Bug#693659: vmix floating-point mode does not use proper API on Linux
Control: severity -1 grave Hi, On Wed, Dec 05, 2012 at 06:50:17PM -0500, Michael Gilbert wrote: control: severity -1 wishlist control: tag -1 upstream control: reopen -1 Reopening since the issue was worked around rather than fixed. This should really be addressed upstream, so it should be forwarded there by someone with more interest than myself. The workaround was reverted (and the fix never entered testing), so I guess the original bug (which Ben marked as grave) is still present. So I'm increasing the severity back to grave. If I misunderstood the situation, feel free to downgrade again. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695949: reprepro: Please allow multiple distributions for include* subcommands
Package: reprepro Severity: wishlist Version: 4.2.0-2 Hi Bernhard, I quite often have to do the following: reprepro include squeeze some.changes reprepro include wheezy some.changes reprepro include lucid some.changes reprepro include oneiric some.changes reprepro include precise some.changes reprepro include quantal some.changes It would be nice if could do that like this instead: reprepro include squeeze,wheezy,lucid,oneiric,precise,quantal some.changes The same counts for the includedsc and includedeb subcommands. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (990, 'unstable'), (900, 'testing'), (600, 'stable'), (200, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.6-trunk-686-pae (SMP w/1 CPU core) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679365: Q: target version (1.4, 1.5 or 1.6) for java-bytecode-format backward compatibility
On 2012-12-14 15:41, Hideki Yamane wrote: Hi, Hi, Moving this to debian-java@l.d.o. About incompatible-java-bytecode-format with OpenJDK 7 as default-jdk issue, I wonder which version should be specified to keep backward compatibility. https://bugs.launchpad.net/ubuntu/+bugs?field.tag=java7-bytecode I've found this is reported in LP#1049779. And I've investigated how should be fixed, and specifying target version is good way. But I cannot decide which version would be used. [...] So, 1.4, 1.5 or 1.6? Honestly, in practise either of version = 1.6 will do. I think most of us pick 1.5 out of habbit. This is somewhat complicated by the fact that on kfreebsd we still don't have openjdk, so we're using GCJ/GIJ, which is really a 1.5 implementation. If it's true, 1.5. If not, 1.6 IMO. You would think that, but no. GCJ/GIJ is instructed to accept any known major Java version and then croak if it sees a byte code it doesn't grok[1]. However, GCJ/GIJ does not (to my knowledge) have the full Java 1.6 (nor 1.7) library behind it, so the code will still crash due to missing methods or classes. However, the bytecode format is not going to save you from that. If we were to check that, we would have to use a JavaX library when compiling in 1.X mode. I am told that OpenJDK 7 has been ported to kFreeBSD and it is simply stalled a buildd issue. If so, I'd rather see GCJ/GIJ being removed as a Java implementation[2]. Anyway, this part is all for Jessie, so ... ~Niels [1] http://gcc.gnu.org/ml/java-patches/2012-q2/msg00013.html [2] E.g. default-jre would never use GCJ/GIJ and GCJ/GIJ should stop providing javaX-runtime etc. Though, GCJ/GIJ will still remain as it is used for bootstrapping OpenJDK. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695906: ifupdown: removal of /etc/network/interfaces is not preserved
]] Bob Proulx Tollef Fog Heen wrote: rm /etc/network/interfaces apt-get --reinstall install ifupdown observe that /etc/network/interfaces exists. If I remove the file, that change should be preserved on upgrades. But /etc/network/interfaces is not an ifupdown conffile. It's a configuration file, and removing a configuration file is, or at least has historically been, a completely valid local change. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695823: mirror submission for 91.220.215.24
Hi, On Thu, Dec 13, 2012 at 03:20:08PM +1100, bo...@homelane.me wrote: Please allocate a dns entry, to avoid IP hardcoding in lists. Ok. http://open-source.homelane.me Bandwidth ? For all ISP in Sakhalin this resource is local. (2Gbps) Thanks for these reply. Please don't silently skip the other questions/remarks, like tracefile, as we really need it. You will them below for reference. Could you please go trough the remaining items ? Thanks in advance. On Thu, Dec 13, 2012 at 01:02:24AM +0100, Simon Paillard wrote: There are a few remarks to be taken into account before proper addition to the official list of mirrors. On Wed, Dec 12, 2012 at 11:33:27PM +, HomeLane wrote: [..] Archive-http: /repo/debian/ Please check the local trace file generation as required per http://www.debian.org/mirror/ftpmirror#how Using the recommended tool 'ftpsync' is the best way to fulfil requirements. Then you may consider providing the mirror at /debian/ directly, the standard path used by most mirrors. Archive-upstream: mirror.yandex.ru Seems it is mirror.mephi.ru now (that you should reference as ftp.ru.debian.org) Updates: twice Please 4 per day if possible, see http://www.debian.org/mirror/ftpmirror#when -- Simon Paillard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695916: libreoffice-common: libreoffice installs its own /ust/bin/soffice instead of using debian alternatives system
Hi, On Fri, Dec 14, 2012 at 04:46:39PM +0100, Rene Engelhard wrote: On Fri, Dec 14, 2012 at 04:34:01PM +0100, Luc Maisonobe wrote: b1) the Debian policy is to file bug against Debian first, not to upstream. It is the responsibility to the packaging team to forward it upstream if needed, not to the original reporter And guess what? I think that this is nonsense for bugs clearly in the upstream domain. And I won't forward bugs I don't consider nonsense either way. s/don't/do/. And in this case I wouldn't even expect upstream packages to use the alternatives system. They only ship their stuff, alternatives would be the distributions' job... Regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672880: CVE-2012-2132: does not indicate whether or not an SSL certificate is valid
Package: midori Version: 0.4.3-1 Followup-For: Bug #672880 Hello, how come this bug is not marked grave as per 'introduces a security hole allowing access to the accounts of users who use the package' ? It is nice to have choice of software in Debian but when the software has security hole then it should be a) fixed b) removed from the archive Especially sice we are nearing a realease and there is not fix in sight b) is applicable. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695928: [eagle] unable to run: error loading libssl.so.0.9.8
On Fri, Dec 14, 2012 at 8:31 AM, Arthur Magill arthur.mag...@epfl.ch wrote: Package: eagle Version: 5.10.0-2 Severity: grave --- Please enter the report below this line. --- Until this week, I have been happily running Eagle. Clearly something changed with a recent upgrade. When I try to start Eagle, I see the following: $ eagle /home/magill/.eagle/bin/eagle: error while loading shared libraries: libssl.so.0.9.8: wrong ELF class: ELFCLASS64 It seems that the problem came about because your system is using Wheezy multiarched ia32-libs but Squeeze non-multiarched eagle. Eagle is a 32 bit binary, and should only be using the 32 bit libraries (even on amd64 systems). The squeeze version of Eagle is looking for the 32 bit libssl: /usr/lib32/i486/libssl.so.0.9.8 and is included in package ia32-libs in squeeze. However, you have a version of ia32-libs installed from Wheezy. Wheezy introduced multiarch, which allowed 32 and 64 bit libraries to be co-installed. Eagle, a 32 bit binary, depends on 32 bit libraries. Since you've already upgraded to ia32-libs from Wheezy, you either have to downgrade it to the squeeze version to get the library back or install a multiarched version of eagle: $ dpkg --add-architecture i386 $ apt-get update $ apt-get install eagle:i386 -t unstable More information is here: http://wiki.debian.org/Multiarch fixing this is going to come down to getting the right versions of different packages working together (either all from squeeze or all from wheezy, mixing won't work). Cheers, Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695931: [pkg-mad-maintainers] Bug#695931: madplay fails to play - device or resource busy
On Fri, Dec 14, 2012 at 03:10:54PM +0100, Halim Sahin wrote: Package: madplay Version: 0.15.2b-8 Severity: important Madplay doesn't play anything. madplay file.mp3 MPEG Audio Decoder 0.15.2 (beta) - Copyright (C) 2000-2004 Robert Leslie et al. audio: Device or resource busy Maybe the audio device has been opened by something else? Note that madplay directly talks alsa by default. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695950: ITP: libconfig-find-perl -- find configuration files in the native OS fashion
Package: wnpp Severity: wishlist Owner: Jotam Jr. Trejo jota...@debian.org.sv * Package name: libconfig-find-perl Version : 0.26 Upstream Author : Salvador Fandino sfand...@yahoo.com * URL : http://search.cpan.org/dist/Config-Find/ * License : Artistic Programming Lang: Perl, GPL-1+ Description : find configuration files in the native OS fashion Every OS has different rules for configuration files placement, this module allows to easily find and create your app configuration files following those rules. Config::Find references configuration files by the application name or by the application name and the configuration file name when the app uses several application files, i.e emacs, profile, apache/httpd, apache/ssl. signature.asc Description: Digital signature
Bug#643818: radvd: sendmsg gets EINVAL
Hi dkg, For a friend of mine it was a dadfailed address on the interface which prevented the it from working. (And google revealed this bugreport before we found that.) Can you still reproduce this? (more than a year old bugreport) Regards, cstamas -- CSILLAG Tamas (cstamas) - http://cstamas.hu/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695788: mirror submission for debian.serverspace.co.uk
Control: tag -1 +moreinfo Hi, On Wed, Dec 12, 2012 at 05:21:29PM +, Chris Lewis wrote: Package: mirrors Severity: wishlist Submission-Type: new Site: debian.serverspace.co.uk Type: leaf The local trace file is not consistent, please don't try to fool check scripts that may think your mirror actually run ftpsync version 20120521 while it's not the case (this version improvide the local trace file). If you don't run ftpsync, don't make your script pretend to be ftpsync, but make sure it follows requirement indicated on the web page below. If you run an old ftpsync version, please don't manually change the version inside code. At last, please run the last recommended tool: ftpsync :) http://www.debian.org/mirror/ftpmirror#how Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc Archive-http: /debian/ IPv6: no Archive-upstream: ftp.uk.debian.org Updates: four Maintainer: Chris Lewis deb-r...@serverspace.co.uk Country: GB United Kingdom Location: London, UK Sponsor: ServerSpace http://www.serverspace.co.uk How much bandwidth would be available ? -- Simon Paillard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695849: RFP: glmark2 -- OpenGL (ES) 2.0 benchmark suite
On 2012-12-14 13:51:43, Dmitry Smirnov wrote: On Fri, 14 Dec 2012 00:12:25 Sebastian Ramacher wrote: So this should be an ITP instead, shouldn't it? You clearly intend to package it. Not just intended to package by I already packaged it so it could be RFS. :) I know it looks like a mistake but it's not: although packaging is practically finished at the moment I can't continue working on it due to limited time. Therefore I dumped results of my effort in hope that someone might pick it up where I left it. Eventually I may return and help maintain it (let's see how it goes) but at the moment I'm not going to request sponsorship etc. so the package if free for take over. It is RFP because I no longer (actively) work on it. Thanks for clarifying. It wasn't clear to me in the beginning. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#677638: laptop-mode-tools: Breaks wired network when running on battery
On Sat, Jun 16, 2012 at 03:59:16AM +0200, Guillem Jover wrote: Hi! [ Ccing Lucas because I saw a related post which *might* be related, but it's not clear. I've not trimmed the mail for your convenience. http://www.mail-archive.com/e1000-devel@lists.sourceforge.net/msg04477.html] On Sat, 2012-06-16 at 02:32:28 +0530, Ritesh Raj Sarraf wrote: severity 677638 normal tags 677638 +moreinfo thanks Setting severity of normal because: * You have an option to disable. That's right, but only as long as you know what needs disabling, it took me a while to spot what the culprit was, because the battery/ac stuff is a bit hairy, there's at least acpid, laptop-mode-tools, pm-utils, and the kernel messing with this stuff. Suddenly getting the network to stop working is pretty mysterious given all those layers, and as such (as said before) even if the real problem is with the driver or the kernel PM settings or whatever, if laptop-mode-tools triggers this (when it could avoid it), then that's a “problem” with it. * This problem is not commonly reported. It could be that other poeple might not have been able to spot what triggered it, it's really not obvious. Checking google for similar errors I've got on my dmesg, I find quite some people reporting similar stuff on random forums and mailing lists. * Not reproducible on my machine (with the same driver) Well, if it can affect other users then I'd say it justifies the severity. :) I can confirm the problem on my Thinkpad X200 with 00:19.0 Ethernet controller: Intel Corporation 82567LF Gigabit Network Connection (rev 03) Subsystem: Lenovo Device 20ee Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at f260 (32-bit, non-prefetchable) [size=128K] Memory at f2624000 (32-bit, non-prefetchable) [size=4K] I/O ports at 1820 [size=32] Capabilities: access denied Kernel driver in use: e1000e It's been a persistent problem for some time. I initially suspected a kernel regression since it started when I updated from Squeeze to testing (about the time when 2.6.39 was current). Switching back to the 2.6.32 from Squeeze fixed it, but I hadn't had the chance to track this down properly until today, when I found this bug. Setting BATT_THROTTLE_ETHERNET=0 in /etc/laptop-mode/conf.d/ethernet.conf fixed wired ethernet for me. I agree with Guillem that this should be fixed for Wheezy by setting BATT_THROTTLE_ETHERNET=0 by default. While a workaround is available it is very difficult to find (who suspects laptop power saving settings when network-manager or the kernel are culprits much more likely?). Also e1000e is quite a common chipset. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695830: [Openstack-devel] Bug#695830: nova: CVE-2012-5625
On Thu, Dec 13, 2012 at 04:34:38PM +0800, Thomas Goirand wrote: On 12/13/2012 03:37 PM, Moritz Muehlenhoff wrote: Package: nova Severity: grave Tags: security Justification: user security hole Please see http://seclists.org/oss-sec/2012/q4/435 Cheers, Moritz Hi Moritz, Thanks for opening this bug entry! I do appreciate (a lot) your commitment to the security in Debian and tracking all issues. However, this CVE is present only in Openstack Folsom, as described in the Affects: field of this link. Debian Wheezy/SID has Openstack Essex. Therefor, Debian isn't affected by this problem, and I'm closing this bug. Also, I am receiving security alerts for Openstack directly from the release manager (eg: ttx), and most of the time, one week in advance, if the bug/security-fix can be embargoed. You can assume I am aware of it (though reminding me is a good idea). Note that I'm about to upload Folsom in Experimental (it's ready on Alioth, I'm only waiting for FTP masters to approve openstack-pkg-tools which all packages now build-depends on). Thanks! I don't use OpenStack and I have no idea what these codenames mean. If you're notified of an OpenStack issue in the future, which doesn't affect the Debian version, please ping me on IRC or send a mail to t...@security.debian.org so that we can update the Debian Security Tracker. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643818: radvd: sendmsg gets EINVAL
On 12/14/2012 12:21 PM, Csillag Tamas wrote: For a friend of mine it was a dadfailed address on the interface which prevented the it from working. (And google revealed this bugreport before we found that.) hm, i'm afraid i don't know enough to say whether the issue was DADfailed or not. Can you still reproduce this? (more than a year old bugreport) Hm, i had to rebuild the machine that was seeing this due to a disk failure since i reported it last. The rebuild happened around 2012-05-17. Looking at the logs in the new machine, it appears only once in the logs, and has not shown up since the initial installation and successful configuration: 2012-05-17_08:27 radvd: IPv6 forwarding setting is: 0, should be 1 2012-05-17_08:27 radvd: IPv6 forwarding seems to be disabled, but continuing anyway. 2012-05-17_08:27 radvd: IPv6 forwarding setting is: 0, should be 1 2012-05-17_08:27 radvd: sendmsg: Invalid argument 2012-05-17_08:32 radvd: version 1.6 started 2012-05-17_08:40 radvd: version 1.6 started And now that the configuration is correct, it doesn't happen any more. I hope that helps with the diagnosis! sorry to not have a better understanding of the underlying issues. --dkg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688772: gnome Depends network-manager-gnome
Tollef Fog Heen tfh...@err.no writes: Is this a requirement for other network-providing packages as well? If so, openvpn for instance is RC-buggy because upgrading it will restart any configured VPNs. We don't require other packages to continue to work uninterrupted during upgrades, I think we actually do require that in some cases. OpenSSH, the X server, and GDM come immediately to mind. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678251: crash after lid close/ suspend
Hi, The above mention bug is solved for me. I am using debian-cut and I used debian snapshots of 31st October and 30th November. My current gnome-shell version is 3.4.2-3 and gnome package is 1:3.4+7. -- Faisal-ur-Rehman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679543: That worked
Thanks, Tomas! OK to close. I will look into Gsettings some more, it seems odd to me that this problem occurs only in VNC session. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695855: please provide a --verify command that outputs the signed data
On Thu, 13 Dec 2012 16:35, ans...@debian.org said:
it would be very nice if gpg had a --verify command that would also output the
signed data. (Maybe gpg --output - --verify?) Otherwise you know the data is
signed, but still have to extract it somehow.
Verification of a signature is quite complicated. The math is easy but
how to properly setup a scheme for automated signature checking is hard.
You need to figure out what has been signed, who signed, whether the key
is valid, and what to do if the key meanwhile expired. Return just a
simple status code would need to hardwire a certain policy which needs
to be strictly followed. I doubt that this is easier than to use
detached signatures, which instantly solve many of the problems.
similar seems to be `gpg --status-{fd,file}=... --decrypt $file' and parsing
the status output, but that is significantly more work (esp. when processing
files in shell).
That is actually pretty easy with a few lines of awk. Remember, it is a
Unix tool; the Unix philosophy is that of a toolbox and not of highly
specialized tools.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695951: ITP: liburi-title-perl -- get the titles of things on the web in a sensible way
Package: wnpp Severity: wishlist Owner: Jotam Jr. Trejo jota...@debian.org.sv * Package name: liburi-title-perl Version : 1.86 Upstream Author : Tom Insam t...@jerakeen.org * URL : http://search.cpan.org/dist/URI-Title/ * License : GPL-1+, Artistic Programming Lang: Perl Description : get the titles of things on the web in a sensible way URI::Title is a tool that allow us to get titles of things on the web in a sensible way. . It aims to provide a single interface to get the titles of html pages and different type of files like mp3, pdf, word document, etc. signature.asc Description: Digital signature
Bug#695952: IPython should use Linux color scheme by default
Package: ipython Version: 0.13.1-2 For some reason, Debian version of IPython uses LightBG color scheme by default. Upstream version uses Linux color scheme by default, and I think Debian version should use it as well. Most terminal emulators in Debian use dark background by default, and Linux color scheme looks much better on dark background. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695923: meld: crashes when copying symlinks
tags 695923 confirmed fixed-upstream thanks Hi Julian, Thank you for the report. Since there is a workaround (cp) I don't plan back-porting the mentioned fix, but wait for upstream to include it in an official release. Cheers, Balint 2012/12/14 Julian Taylor jtaylor.deb...@googlemail.com: Package: meld Version: 1.6.1-1 Severity: normal Tags: patch meld can't copy directories containing symlinks: e.g. ls -oR tmp tmp2 tmp: total 0 tmp2/: total 0 drwxrwxr-x 2 jtaylor 80 Dec 14 12:56 test tmp2/test: total 0 -rw-rw-r-- 1 jtaylor 0 Dec 14 12:56 a lrwxrwxrwx 1 jtaylor 1 Dec 14 12:56 b - a copying tmp2/test to tmp results in this error: Traceback (most recent call last): File /usr/lib/meld/meld/dirdiff.py, line 836, in on_button_copy_left_clicked self.copy_selected(-1) File /usr/lib/meld/meld/dirdiff.py, line 679, in copy_selected misc.copytree(src, dst) File /usr/lib/meld/meld/misc.py, line 288, in copytree os.symlink(os.readlink(srcname, dstname)) patch available in upstream commit 02588ecaa0c96b1b1b05ff2df13b7abd7f8b0966 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695844: syntactical break between 'grub2' and 'grub' ?
Hello, Wheezytester wheezytes...@online.de wrote: There had allready two systems been installed: 'openSuse 10.8' and 'Debian 4 (Etch)', both on logical drives. After installing 'Debian 7 b4' on /dev/sda1, 'grub2' detected both of them. But only 'openSuse' was bootable by selecting from the boot-menu. 'Debian 4' wasn´t bootable from the grub2-menu anymore, even after many trials of editing the menu-entry. There may be a syntactical break between 'grub2' and 'grub'. My sugestion would be, to ship the installation with both: 'grub2' and 'grub legacy', as you did with 'Debian 5 (Lenny)'. Please, give me a re, if this is known problem installing 'grub2'. Could you provide the installation logs? Without them it will be impossible to debug the problem. Holger -- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Created with Sylpheed 3.0.2 under D e b i a n G N U / L I N U X 6.0 ( S q u e e z e ) Registered LinuxUser #311290 - http://linuxcounter.net/ = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695953: ITP: liburi-find-simple-perl -- simple interface to URI::Find
Package: wnpp Severity: wishlist Owner: Jotam Jr. Trejo jota...@debian.org.sv * Package name: liburi-find-simple-perl Version : 1.03 Upstream Author : Tom Insam t...@jerakeen.org * URL : http://search.cpan.org/dist/URI-Find-Simple/ * License : Artistic, GPL-1+ Programming Lang: Perl Description : simple interface to URI::Find URI::Find is all very well, but sometimes you just want a list of the links in a given piece of text, or you want to change all the urls in some text somehow, and don't want to mess with callback interfaces. . This module uses URI::Find, but hides the callback interface, providing two functions - one to list all the uris, and one to change all the uris. signature.asc Description: Digital signature
Bug#695954: unblock: flashplugin-nonfree/1:3.2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock flashplugin-nonfree 1:3.2. It fixes two security bugs. Debdiff attached. diff -ruN ../orig/flashplugin-nonfree-2.8.2/debian/changelog ./debian/changelog --- ../orig/flashplugin-nonfree-2.8.2/debian/changelog 2010-09-17 21:04:37.0 +0200 +++ ./debian/changelog 2012-12-14 19:05:13.0 +0100 @@ -1,3 +1,11 @@ +flashplugin-nonfree (1:2.8.2+squeeze1) stable; urgency=low + + * update-flashplugin-nonfree: Added use of gpg --verify to notice files +without signature. Thanks to Ansgar Burchardt for reporting the security +issue (via private e-mail on 13 Dec 2012). + + -- Bart Martens ba...@debian.org Fri, 14 Dec 2012 19:03:40 +0100 + flashplugin-nonfree (1:2.8.2) unstable; urgency=low * Removed 64 bit player temporarily not supported. Closes: #586273. diff -ruN ../orig/flashplugin-nonfree-2.8.2/update-flashplugin-nonfree ./update-flashplugin-nonfree --- ../orig/flashplugin-nonfree-2.8.2/update-flashplugin-nonfree 2010-09-17 20:42:15.0 +0200 +++ ./update-flashplugin-nonfree 2012-12-14 19:06:17.0 +0100 @@ -164,6 +164,8 @@ gpg -q --homedir . --import /usr/lib/flashplugin-nonfree/pubkey.asc /dev/null 21 \ || die_hard_with_a_cleanup gpg failed to import /usr/lib/flashplugin-nonfree/pubkey.asc [ $verbose != yes ] || echo verifying PGP $downloadfile ... + gpg -q --homedir . --verify $downloadfile 2 /dev/null \ + || die_hard_with_a_cleanup gpg rejected signature of $downloadurl gpg -q --homedir . $downloadfile checksums.txt 2 /dev/null \ || die_hard_with_a_cleanup gpg rejected signature of $downloadurl
Bug#652006: blueman: 'Stream setup failed' on bluetooth headphone connection
Adding Socket in Enable on the General part of /etc/bluetooth/audio.conf seems to have fixed the problem. So if encounter the same problem, add Enable=Socket after [General], then restart bluetooth and it should be ok. (Seen at https://wiki.archlinux.org/index.php/Bluetooth#My_device_is_paired_but_no_sound_is_played_from_it). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695788: mirror submission for debian.serverspace.co.uk
Hi Simon, Could you tell me exactly which bit of the config is wrong. I am using the latest version of ftpsync from the page you specified. I have modified the config so that a full trace file is created instead of the terse setting I was using before, and have run the script again so the full trace should be there. Hopefully this will allow you to point me to where I went wrong in my setup. Also we would have 100mbps available bandwidth for this mirror. Thanks Chris Lewis Systems Installation Engineer 93-95 Borough High Street London, SE1 1NL T: 0207 129 7005 F: 08701 992 688 E: cle...@serverspace.co.uk W: www.serverspace.co.uk -Original Message- From: Simon Paillard [mailto:spaill...@debian.org] Sent: 14 December 2012 17:33 To: deb-repo; 695...@bugs.debian.org Subject: Re: Bug#695788: mirror submission for debian.serverspace.co.uk Control: tag -1 +moreinfo Hi, On Wed, Dec 12, 2012 at 05:21:29PM +, Chris Lewis wrote: Package: mirrors Severity: wishlist Submission-Type: new Site: debian.serverspace.co.uk Type: leaf The local trace file is not consistent, please don't try to fool check scripts that may think your mirror actually run ftpsync version 20120521 while it's not the case (this version improvide the local trace file). If you don't run ftpsync, don't make your script pretend to be ftpsync, but make sure it follows requirement indicated on the web page below. If you run an old ftpsync version, please don't manually change the version inside code. At last, please run the last recommended tool: ftpsync :) http://www.debian.org/mirror/ftpmirror#how Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc Archive-http: /debian/ IPv6: no Archive-upstream: ftp.uk.debian.org Updates: four Maintainer: Chris Lewis deb-r...@serverspace.co.uk Country: GB United Kingdom Location: London, UK Sponsor: ServerSpace http://www.serverspace.co.uk How much bandwidth would be available ? -- Simon Paillard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695955: fail upon failures in loops + do not ignore tests failures
Package: python-numpy Version: 1:1.6.2-1 Severity: wishlist Tags: patch Actually here are two patches (ready to be committed to SVN happen the maintainer approves) - one assures that all for loops are secured with set -e, so if any command fails, the loop fails (do not remember who pointed me to this drawback in my packages originally, thanks again ;) ) - tests failures are not ignored imho it is much better to submit packages with only known to fail tests disabled/excluded or even better resolved -- that provides some guarantee that there is no unknown issues left yes -- currently it would lead to FTBFS since all (or nearly all -- that is the point, impossible to figure out besides going through all of them 1 by 1) architectures show some kind of test failure or a crash: https://buildd.debian.org/status/package.php?p=python-numpysuite=experimental -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python-numpy depends on: ii libatlas3-base [liblapack.so.3gf] 3.8.4-7 ii libatlas3gf-base 3.8.4-7 ii libblas3 [libblas3gf] 1.2.20110419-5 ii libblas3gf 1.2.20110419-5 ii libc6 2.13-33 ii libgcc11:4.7.2-4 ii libgfortran3 4.7.2-4 ii liblapack3 [liblapack3gf] 3.4.1-4 ii liblapack3gf 3.4.1-4 ii libquadmath0 4.7.2-4 ii python 2.7.3-3 ii python-support 1.0.15 python-numpy recommends no packages. Versions of packages python-numpy suggests: ii gcc 4:4.7.2-1 ii gfortran 4:4.7.1-1 ii python-dev2.7.3-3 ii python-nose 1.1.2-3 pn python-numpy-dbg none ii python-numpy-doc 1:1.6.2-1 -- no debconf information From 46bbfedb75f53f8f89ea749c60a4fc7c1ed75e3d Mon Sep 17 00:00:00 2001 From: Yaroslav Halchenko deb...@onerussian.com Date: Fri, 14 Dec 2012 13:10:34 -0500 Subject: [PATCH 1/2] debian/rules: safe-guard all for loops with 'set -e; ' to prevent uncaught failures --- debian/changelog | 7 +++ debian/rules | 32 2 files changed, 23 insertions(+), 16 deletions(-) diff --git a/debian/changelog b/debian/changelog index b701e8a..2f5ca09 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +python-numpy (1:1.7.0~b2-2) UNRELEASED; urgency=low + + * debian/rules +- safe-guard all for loops with 'set -e; ' to prevent uncaught failures + + -- Yaroslav Halchenko deb...@onerussian.com Fri, 14 Dec 2012 13:08:56 -0500 + python-numpy (1:1.7.0~b2-1) experimental; urgency=low * New upstream beta release diff --git a/debian/rules b/debian/rules index ca48806..fc3d41c 100755 --- a/debian/rules +++ b/debian/rules @@ -16,7 +16,7 @@ export ATLAS=None override_dh_auto_build: dh_auto_build - for v in $(PY3VERS); do \ + set -e; for v in $(PY3VERS); do \ python$$v setup.py build; \ python$$v-dbg setup.py build; \ done @@ -34,11 +34,11 @@ override_dh_installman: mv debian/python3-numpy/usr/share/man/man1/f2py.1 \ debian/python3-numpy/usr/share/man/man1/f2py3.1 # link manpage for versioned and dbg incarnations of f2py - for v in $(PY2VERS); do \ + set -e; for v in $(PY2VERS); do \ dh_link /usr/share/man/man1/f2py.1.gz /usr/share/man/man1/f2py$$v.1.gz; \ dh_link -ppython-numpy-dbg /usr/share/man/man1/f2py.1.gz /usr/share/man/man1/f2py$$v-dbg.1.gz; \ done - for v in $(PY3VERS); do \ + set -e; for v in $(PY3VERS); do \ dh_link -ppython3-numpy /usr/share/man/man1/f2py3.1.gz /usr/share/man/man1/f2py$$v.1.gz; \ dh_link -ppython3-numpy-dbg /usr/share/man/man1/f2py3.1.gz /usr/share/man/man1/f2py$$v-dbg.1.gz; \ done @@ -47,7 +47,7 @@ override_dh_installman: override_dh_install: # add shebang information to f2py script - for v in $(PY2VERS) $(PY3VERS); do \ + set -e; for v in $(PY2VERS) $(PY3VERS); do \ sed -i 1s,#!.*python[^ ]*\(.*\),#!/usr/bin/python$$v, debian/tmp/usr/bin/f2py$$v; \ cp -a debian/tmp/usr/bin/f2py$$v debian/tmp/usr/bin/f2py$$v-dbg ; \ sed -i 1s,#!.*python[^ ]*\(.*\),#!/usr/bin/python$$v-dbg, debian/tmp/usr/bin/f2py$$v-dbg; \ @@ -74,23 +74,23 @@ override_dh_install: find $(CURDIR)/debian/python-numpy/ -name *_d.so -delete # create symlinks for .h files - for i in $(PY2VERS); do \ + set -e; for i in $(PY2VERS); do \ [ -d $(CURDIR)/debian/python-numpy/usr/include/python$$i ] || \ mkdir -p $(CURDIR)/debian/python-numpy/usr/include/python$$i; \ dh_link usr/lib/pymodules/python$$i/numpy/core/include/numpy usr/include/python$$i/numpy; \ done - for i in $(PY2VERS); do \ + set -e; for
Bug#695954: unblock: flashplugin-nonfree/1:3.2
I attached the wrong diff. I'm now attaching the right one. Regards, Bart Martens diff -Nru flashplugin-nonfree-3.1/debian/changelog flashplugin-nonfree-3.2/debian/changelog --- flashplugin-nonfree-3.1/debian/changelog 2012-09-15 14:50:34.0 +0200 +++ flashplugin-nonfree-3.2/debian/changelog 2012-12-13 22:07:41.0 +0100 @@ -1,3 +1,16 @@ +flashplugin-nonfree (1:3.2) unstable; urgency=low + + * update-flashplugin-nonfree: Added use of gpg --verify to notice files +without signature. Thanks to Ansgar Burchardt for reporting the security +issue (via private e-mail on 13 Dec 2012). + * get-upstream-version.pl: Added validation of link to flash. +Thanks to Henrik Ahlgren for reporting the security issue (on +debian-security on 12 Dec 2012). + * debian/postinst: Added removal of cached get-upstream-version.pl so that a +fresh copy is downloaded. + + -- Bart Martens ba...@debian.org Thu, 13 Dec 2012 17:45:13 + + flashplugin-nonfree (1:3.1) unstable; urgency=low * get-upstream-version.pl: Added error handling with failed to read $url. diff -Nru flashplugin-nonfree-3.1/debian/postinst flashplugin-nonfree-3.2/debian/postinst --- flashplugin-nonfree-3.1/debian/postinst 2010-06-17 18:54:42.0 +0200 +++ flashplugin-nonfree-3.2/debian/postinst 2012-12-13 19:07:59.0 +0100 @@ -4,6 +4,7 @@ case $1 in configure) + rm -f /var/cache/flashplugin-nonfree/get-upstream-version.pl update-flashplugin-nonfree --install --fast || true ;; diff -Nru flashplugin-nonfree-3.1/get-upstream-version.pl flashplugin-nonfree-3.2/get-upstream-version.pl --- flashplugin-nonfree-3.1/get-upstream-version.pl 2012-09-15 14:39:21.0 +0200 +++ flashplugin-nonfree-3.2/get-upstream-version.pl 2012-12-13 18:46:50.0 +0100 @@ -50,6 +50,7 @@ my $link_to_flash = $1; $link_to_flash =~ s,^/,,; +die link to flash contains invalid characters: $link_to_flash if( $link_to_flash !~ m%^[a-zA-Z0-9/=?]+$% ); $url = http://www.adobe.com/$link_to_flash;; $page = read_page( $ARGV[0], $url ); diff -Nru flashplugin-nonfree-3.1/update-flashplugin-nonfree flashplugin-nonfree-3.2/update-flashplugin-nonfree --- flashplugin-nonfree-3.1/update-flashplugin-nonfree 2012-09-15 14:28:52.0 +0200 +++ flashplugin-nonfree-3.2/update-flashplugin-nonfree 2012-12-13 18:25:48.0 +0100 @@ -194,6 +194,8 @@ wget $wgetoptions $downloadurl \ || die_hard_with_a_cleanup wget failed to download $downloadurl + gpg -q --homedir . --verify get-upstream-version.pl.gz.pgp 2 /dev/null \ + || die_hard_with_a_cleanup gpg rejected signature of get-upstream-version.pl.gz.pgp gpg -q --homedir . get-upstream-version.pl.gz.pgp get-upstream-version.pl.gz 2 /dev/null \ || die_hard_with_a_cleanup gpg rejected signature of get-upstream-version.pl.gz.pgp @@ -239,6 +241,8 @@ wget $wgetoptions $downloadurl \ || die_hard_with_a_cleanup wget failed to download $downloadurl [ $verbose != yes ] || echo verifying PGP $downloadfile ... + gpg -q --homedir . --verify $downloadfile 2 /dev/null \ +|| die_hard_with_a_cleanup gpg rejected signature of $downloadurl gpg -q --homedir . $downloadfile checksums.txt 2 /dev/null \ || die_hard_with_a_cleanup gpg rejected signature of $downloadurl
Bug#695903: razorqt-session: sessions choosing a specific window manager do not work from gdm3
tags 695903 + upstream confirmed found 695903 0.4.1-2 stop Hi Paul, 2012/12/14 Paul Wise p...@debian.org: Package: razorqt-session Version: 0.4.1-1~exp1 Severity: normal These sessions that set a specific window manager do not work even though I have all three window managers installed. razorqt-session: /usr/share/xsessions/razor-kwin.desktop razorqt-session: /usr/share/xsessions/razor-metacity.desktop razorqt-session: /usr/share/xsessions/razor-openbox.desktop When I try them I get a dialog that contains these texts: Xsession: unable to launch razor-session -w kwin X session --- razor-session -w kwin not found; falling back to default session. Xsession: unable to launch razor-session -w metacity X session --- razor-session -w metacity not found; falling back to default session. Xsession: unable to launch razor-session -w openbox X session --- razor-session -w openbox not found; falling back to default session. This seems to be an error from upstream .desktop files: https://groups.google.com/group/razor-qt/browse_thread/thread/9555a74cf7188ad2 It's fixed in newer versions by commenting out the TryExec, which (even if it works -- it doesn't for me when modifying my .desktop files by hand) is not very optimal, since then one has entries for window managers not really available in the system: https://github.com/Razor-qt/razor-qt/commit/bc8148c5e7741de9400f7436f188e178a51b5b96 I guess that this is a duplicate of #653327 , due to the following line having several arguments: Exec=razor-session -w openbox Comments? Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684434: RFS: yamcha/0.33-1 [ITP] -- General purpose chunker annotator
* Giulio Paci giuliop...@gmail.com, 2012-12-13, 00:56: debian/patches/1002_manpages_fix.patch touches a file which starts with the following comment: .\ DO NOT MODIFY THIS FILE! It was generated by help2man 1.23. Fixed: now this patch does not alter man/yamcha.1 anymore. If it doesn't touch manpages anymore, perhaps it needs a better name? Instead help2man is invoked at build time. I added: 1) helpman as build dependency; 2) a patch to fix update-man target in the man/Makefile.am; 3) code to invoke this target in debian/rules. Great. doc/yamcha.html looks like it was automatically generated from the manpage, although it's not up-to-date... -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695956: pu: package flashplugin-nonfree/1:2.8.2+squeeze1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: squeeze Please consider updating flashplugin-nonfree in squeeze for fixing a security bug. Diff attached. A prepared package is here : http://people.debian.org/~bartm/flashplugin-nonfree/stable/ diff -ruN ../orig/flashplugin-nonfree-2.8.2/debian/changelog ./debian/changelog --- ../orig/flashplugin-nonfree-2.8.2/debian/changelog 2010-09-17 21:04:37.0 +0200 +++ ./debian/changelog 2012-12-14 19:05:13.0 +0100 @@ -1,3 +1,11 @@ +flashplugin-nonfree (1:2.8.2+squeeze1) stable; urgency=low + + * update-flashplugin-nonfree: Added use of gpg --verify to notice files +without signature. Thanks to Ansgar Burchardt for reporting the security +issue (via private e-mail on 13 Dec 2012). + + -- Bart Martens ba...@debian.org Fri, 14 Dec 2012 19:03:40 +0100 + flashplugin-nonfree (1:2.8.2) unstable; urgency=low * Removed 64 bit player temporarily not supported. Closes: #586273. diff -ruN ../orig/flashplugin-nonfree-2.8.2/update-flashplugin-nonfree ./update-flashplugin-nonfree --- ../orig/flashplugin-nonfree-2.8.2/update-flashplugin-nonfree 2010-09-17 20:42:15.0 +0200 +++ ./update-flashplugin-nonfree 2012-12-14 19:06:17.0 +0100 @@ -164,6 +164,8 @@ gpg -q --homedir . --import /usr/lib/flashplugin-nonfree/pubkey.asc /dev/null 21 \ || die_hard_with_a_cleanup gpg failed to import /usr/lib/flashplugin-nonfree/pubkey.asc [ $verbose != yes ] || echo verifying PGP $downloadfile ... + gpg -q --homedir . --verify $downloadfile 2 /dev/null \ + || die_hard_with_a_cleanup gpg rejected signature of $downloadurl gpg -q --homedir . $downloadfile checksums.txt 2 /dev/null \ || die_hard_with_a_cleanup gpg rejected signature of $downloadurl
Bug#695855: please provide a --verify command that outputs the signed data
Werner Koch w...@gnupg.org writes: On Thu, 13 Dec 2012 16:35, ans...@debian.org said: it would be very nice if gpg had a --verify command that would also output the signed data. (Maybe gpg --output - --verify?) Otherwise you know the data is signed, but still have to extract it somehow. Verification of a signature is quite complicated. The math is easy but how to properly setup a scheme for automated signature checking is hard. You need to figure out what has been signed, who signed, whether the key is valid, and what to do if the key meanwhile expired. Return just a simple status code would need to hardwire a certain policy which needs to be strictly followed. I doubt that this is easier than to use detached signatures, which instantly solve many of the problems. I agree that detached signatures are easier, but that should only change the what has been signed part. Having gpg output the signed data would answer that. For the rest, I'm mostly thinking of places where gpgv is used and one has a keyring where all keys are trusted. I don't think more complicated policies should be implemented using just the return code. Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692874: liferea: diff for NMU version 1.8.6-1+nmu1
David, Any progress on this? I am willing to look into a new version from you, but I haven't seen one. Paul signature.asc Description: OpenPGP digital signature
Bug#688772: gnome Depends network-manager-gnome
On Fri, Dec 14, 2012 at 09:50:37AM +0100, Tollef Fog Heen wrote: ]] Steve Langasek - Installing the gnome or the NM package must not cause the network to break on upgrade, even temporarily, under any circumstances. Is this a requirement for other network-providing packages as well? If so, openvpn for instance is RC-buggy because upgrading it will restart any configured VPNs. We don't require other packages to continue to work uninterrupted during upgrades, and while I can agree NM is in a bit of special situation by virtue of controlling the network, I am not sure being as strict as you are here is reasonable. Sorry, my wording was a bit sloppy there. What I meant to say was, an upgrade that pulls in either gnome or network-manager as a new package must not cause the network to break, even temporarily. So on new installation of the NM package, my expectation is that it will not tamper with the current network state, because doing so may break the admin's remote connection to the machine. I think it's important that an upgrade of the NM package *also* not cause the network to drop, but that's a slightly different point than the one I was meaning to make. - Installing the gnome or the NM package must not cause any network configuration the user has specified to be lost. This is reasonable, and makes ifupdown RC-buggy, since rm-ing /etc/network/interfaces and reinstalling the package will change the network configuration (the file is recreated). I've just filed a bug about this. I think you're missing several steps in your proof that this is RC buggy. ;) The policy requirement isn't that *filesystem* changes be preserved, it's that *configuration* changes be preserved. In what way does deleting /etc/network/interfaces constitute a valid configuration that must be preserved? When ifupdown recreates the file, it populates it only with a config for lo. I don't think it's reasonable to claim that it's valid and intentional to configure a system in such a way that it will fail to bring up the loopback interface on boot. In fact, booting the system without lo breaks so many assumptions that Ubuntu, for example, *unconditionally* brings up lo on boot, whether or not it's configured in /etc/network/interfaces. I consider restoring a stock /e/n/i on package upgrade to be in the same category. If the reason you raise this concern is because of my comment that NM should always report the system online unless it controls all the network interfaces, I was implicitly excluding lo from the reckoning. First, it's not relevant to whether the machine is online, and second, there's only one valid state for this interface (up) so there's no configuration to fight over the management of. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#566825: Bug#695903: razorqt-session: sessions choosing a specific window manager do not work from gdm3
2012/12/14 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com: This seems to be an error from upstream .desktop files: https://groups.google.com/group/razor-qt/browse_thread/thread/9555a74cf7188ad2 It's fixed in newer versions by commenting out the TryExec, which (even if it works -- it doesn't for me when modifying my .desktop files by hand) is not very optimal, since then one has entries for window managers not really available in the system: https://github.com/Razor-qt/razor-qt/commit/bc8148c5e7741de9400f7436f188e178a51b5b96 I had thought that the above might be the problem, but I think now that what I said above is wrong. I think that the actual issue is the following one: I guess that this is a duplicate of #653327 , due to the following line having several arguments: Exec=razor-session -w openbox #694832 and #566825 also seem duplicates of #653327 . Sending a copy of this message to all of these bug reports, some of them quite old; to see if submitters, triagers and maintainers concur and we can get it fixed. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695931: Acknowledgement (madplay fails to play - device or resource busy)
Hello, The attached patch fixes the reported issue. Note: it works but only for native alsa output. It fails when trying to use pulseaudio's alsa plugin. The problem was opening plughw:0,0 alsa device. If other apps are using the device at the same time, madplay can't use that device. The patch changes it to use default device which works here. Regards Halim -- Halim Sahin E-Mail: halim.sahin (at) t-online.de --- audio_alsa.c.orig 2012-12-14 21:04:47.081986940 +0100 +++ audio_alsa.c2012-12-14 21:05:18.805980761 +0100 @@ -46,7 +46,7 @@ int buffer_time= 50; int period_time= 10; -char *defaultdev = plughw:0,0; +char *defaultdev = default; snd_pcm_hw_params_t *alsa_hwparams; snd_pcm_sw_params_t *alsa_swparams;
Bug#695919: dpkg-source --require-valid-signature can be tricked
On Fri, 2012-12-14 at 15:47:57 +0100, Ansgar Burchardt wrote:
On 12/14/2012 02:51 PM, Guillem Jover wrote:
This happens as Dpkg::Control::Hash skips until an empty line:
145 } elsif (m/^-BEGIN PGP SIGNED MESSAGE/) {
146 $expect_pgp_sig = 1;
147 if ($$self-{'allow_pgp'}) {
148 # Skip PGP headers
149 while ($fh) {
150 last if m/^$/;
151 }
However one can add trailing whitespace without breaking the signature
causing
the code to skip until the second section.
Nice catch! I'm preparing a tiny fix, and I'm going over RFC4880 to see
if there's any other issues to take care of. Will most probably ask the
RT if they'd be fine including such fix for wheezy.
There are quite a lot of them. Other fun things to abuse include the
wrong markers in line 145 or dash-escaping text.
I had gone over the RFC, and as you note, the other problem I've spotted
is wrongly matched Armor Header Line (missing dashes and possible
whitespace before EOL). I don't see how dash-escaped text can be an
issue, as gpg would not consider it an Armor Header Line.
Sadly I'm not sure of a painless way to safely extract the data that gpg
(gpgv) actually checked the signature for: gpgv has no option for this
and with gpg you only get the output when using something other than
--verify, but then you have to check the output on --status-fd for the
existance of a valid signature :/
I've fixed those locally now, and will do some more testing later
today. The RFC is pretty clear on how to parse this so I don't think
it's that painful.
I did file a wishlist request against gnupg to provide an option that
outputs the data as well as checking the signature (#695855).
Even if such new feature would get implemented, adding a versioned
dependency on it would be a bit harsh.
As I found this problem in quite a lot of packages, I'll probably write
a mail to d-devel later. Maybe somebody else has a better idea how to
address this problem.
I think parsers just need to be fixed as specified in RFC4880.
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657440: xkb-data: cannot switch between two kb layout in gnome
Control: reassign -1 xkb-data 2.5.1-2.1 Control: severity -1 important Control: tags -1 + upstream fixed-upstream patch Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=43541 Le jeudi 26 janvier 2012 à 12:20 +0100, Rémi Letot a écrit : Package: xkb-data Version: 2.5-1 Severity: normal I upgraded my sid system, and xkb-data was upgraded to 2.5-1. Normaly, my X configuration is azerty Belgian at the time of gdm, and switches to French bépo (façon dvorak) once in gnome. After upgrading xkb-data, the layout stays Belgian even after login. Gnome's keyboard applet says fr, and the bépo layout it selected in the menu if I expand it, but the real used layout is Belgian. More than that, I can't select the other option in the keyboard applet. Now if I open keyboard parameters and change the order of the layouts (that is make Belgian first in the list), I can use the menu to switch layouts again. If I change the orders again, I can still switch but the layouts are inverted: selecting be gets me bépo, and fr gets me be... Reverting to xkb-data 2.3-2 from testing fixes everything. As a user of the fr(bepo) layout, I confirm this. This is actually an xkb-data bug that has been fixed upstream and for which I attach the relevant patch. I consider this issue to be of severity important, because it severely affects several categories of users, like the Bépo community and users of fr(oss) and Norwegian keymaps. I think the fix should go into Wheezy. Kibi, what's your opinion? I can NMU if this helps. Cheers, -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Bug#657440: xkb-data: cannot switch between two kb layout in gnome
Le vendredi 14 décembre 2012 à 21:28 +0100, Sébastien Villemot a écrit :
This is actually an xkb-data bug that has been fixed upstream and for which I
attach the
relevant patch.
Attaching the missing patch, sorry.
--
.''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://www.dynare.org/sebastien
`- GPG Key: 4096R/381A7594
diff -u xkeyboard-config-2.5.1/debian/changelog xkeyboard-config-2.5.1/debian/changelog
--- xkeyboard-config-2.5.1/debian/changelog
+++ xkeyboard-config-2.5.1/debian/changelog
@@ -1,3 +1,14 @@
+xkeyboard-config (2.5.1-2.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Add ossmath-is-five-levels.patch: some keymaps like fr/oss and fr/bepo
+fail to load because they include ossmath (via keypad(oss)) which
+misconfigures the keypad as 4-level when it should be 5-level. This
+patch from upstream fixes this by adding the 5th level to the ossmath
+definition. (Closes: #657440)
+
+ -- Sébastien Villemot sebast...@debian.org Thu, 13 Dec 2012 21:29:57 +0100
+
xkeyboard-config (2.5.1-2.1) unstable; urgency=low
* Non-maintainer upload.
diff -u xkeyboard-config-2.5.1/debian/patches/series xkeyboard-config-2.5.1/debian/patches/series
--- xkeyboard-config-2.5.1/debian/patches/series
+++ xkeyboard-config-2.5.1/debian/patches/series
@@ -3,0 +4 @@
+ossmath-is-five-levels.diff
only in patch2:
unchanged:
--- xkeyboard-config-2.5.1.orig/debian/patches/ossmath-is-five-levels.diff
+++ xkeyboard-config-2.5.1/debian/patches/ossmath-is-five-levels.diff
@@ -0,0 +1,36 @@
+Description: ossmath is CTRL+ALT, not FOUR_LEVEL
+ Having KPMU defined as FOUR_LEVEL, with 4 symbols only, triggers an xkb error
+ when the keypad stuff picks up the CTRL+ALT (from x11) and waits for 5 symbols
+ instead.
+Origin: http://cgit.freedesktop.org/xkeyboard-config/commit/?id=49ed96928f6036bf07c8daa5aa886485fc3635e4
+Bug: https://bugs.freedesktop.org/show_bug.cgi?id=43541
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657440
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/985065
+Reviewed-by: Sébastien Villemot sebast...@debian.org
+Last-Update: 2012-12-13
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/symbols/keypad
b/symbols/keypad
+@@ -267,13 +267,12 @@ xkb_symbols legacymath {
+ partial keypad_keys
+ xkb_symbols ossmath {
+
+-key.type[Group1]=FOUR_LEVEL_X ;
+-
+-key KPDV { [ KP_Divide, 0x1002215, 0x1F7, XF86_Ungrab ] }; // / ∕ ÷ XF86_Ungrab
+-key KPMU { [ KP_Multiply, 0x10022C5, 0x1D7, XF86_ClearGrab ] }; // * ⋅ × XF86_ClearGrab
+-key KPSU { [ KP_Subtract, 0x1002212, 0x1002212, XF86_Prev_VMode ] }; // - − − XF86_Prev_VMode
++key.type[Group1]=CTRL+ALT ;
+
+-key KPAD { [ KP_Add, 0x12B, 0x12B, XF86_Next_VMode ] }; // + + + XF86_Next_VMode
++key KPDV { [ KP_Divide, 0x1002215, 0x1F7, VoidSymbol, XF86_Ungrab ] }; // / ∕ ÷ XF86_Ungrab
++key KPMU { [ KP_Multiply, 0x10022C5, 0x1D7, VoidSymbol, XF86_ClearGrab ] }; // * ⋅ × XF86_ClearGrab
++key KPSU { [ KP_Subtract, 0x1002212, 0x1002212, VoidSymbol, XF86_Prev_VMode ] }; // - − − XF86_Prev_VMode
++key KPAD { [ KP_Add, 0x12B, 0x12B, VoidSymbol, XF86_Next_VMode ] }; // + + + XF86_Next_VMode
+
+ };
+
+--
+1.7.10.2
+
signature.asc
Description: This is a digitally signed message part
Bug#369693: Log rotation modification suggestion
To fix the issue of squid log rotation being out of sync with sarg reporting, it might be better to change the squid log rotation to monthly. This article http://jamesmcdonald.id.au/it-tips/ubuntu-9-04-sarg-squid-no-reports documents the changes. Perhaps this could be part of the install package for sarg or at least ask the op if they would like the changes made. -- = bep -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689653: Voronoi license question
THANK you! On Thu, Dec 13, 2012 at 08:20:55PM +, Fortune, Steven (Steven) wrote: Hi Florian: The Voronoi package will include the license, attached. --Steve Fortune -Original Message- From: Florian Schlichting [mailto:fschl...@zedat.fu-berlin.de] Sent: Friday, October 05, 2012 5:11 PM To: Fortune, Steven (Steven) Cc: 689...@bugs.debian.org Subject: Voronoi license question Hi, I'm writing to you as the original author of Voronoi. We from the Debian Perl Team would like to package a Perl module, Math::Geometry::Voronoi (http://search.cpan.org/~samtregar/Math-Geometry-Voronoi-1.3/lib/Math/Geometry/Voronoi.pm), for Debian. The module is basically a wrapper around Derek Bradley's improved version of your C implementation. It seems your Voronoi code does not come with any kind of license statement, a fact that's also noted at the above mentioned URL. Copyright/license information is needed in order for Debian (and others) to be able to legally distribute the software. Could you please give us details on the following points (replying to this email including the bug addess I've cc'd is fine): * years of copyright of your Voronoi code * copyright holders' names and email addesses (if you're not the copyright holder yourself) * the license under which Voronoi can be redistributed and modified I apologize in advance for this request, as I understand that the last thing most authors want to deal with is legal administrivia like this. I'm not a lawyer, but it's my understanding that both copyright and licensing information is vital for the continued success of open source software. Copyright is what allows you to assert a license, and a license is what gives others the rights to use and re-distribute your software. A great article discussing some of this is What is Copyleft? by Richard Stallman: http://www.gnu.org/copyleft/ Thank you, and sorry for the noise. Florian Copyright (c) 1987 Alcatel-Lucent, as successor to ATT Bell Laboratories, Inc. 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688772: gnome Depends network-manager-gnome
]] Steve Langasek On Fri, Dec 14, 2012 at 09:50:37AM +0100, Tollef Fog Heen wrote: ]] Steve Langasek - Installing the gnome or the NM package must not cause the network to break on upgrade, even temporarily, under any circumstances. Is this a requirement for other network-providing packages as well? If so, openvpn for instance is RC-buggy because upgrading it will restart any configured VPNs. We don't require other packages to continue to work uninterrupted during upgrades, and while I can agree NM is in a bit of special situation by virtue of controlling the network, I am not sure being as strict as you are here is reasonable. Sorry, my wording was a bit sloppy there. What I meant to say was, an upgrade that pulls in either gnome or network-manager as a new package must not cause the network to break, even temporarily. So on new installation of the NM package, my expectation is that it will not tamper with the current network state, because doing so may break the admin's remote connection to the machine. Ok, fair enough. I think it's important that an upgrade of the NM package *also* not cause the network to drop, but that's a slightly different point than the one I was meaning to make. My question then still stands: Do you consider NM in any way special here or does the same requirement apply to other network-providing apps? - Installing the gnome or the NM package must not cause any network configuration the user has specified to be lost. This is reasonable, and makes ifupdown RC-buggy, since rm-ing /etc/network/interfaces and reinstalling the package will change the network configuration (the file is recreated). I've just filed a bug about this. I think you're missing several steps in your proof that this is RC buggy. ;) I had enough steps in there that one of the release managers agreed with me. The policy requirement isn't that *filesystem* changes be preserved, it's that *configuration* changes be preserved. In what way does deleting /etc/network/interfaces constitute a valid configuration that must be preserved? The policy requirement is not that the configuration changes are valid. It's not ok to replace a config file just because it has a syntax error in it, is it? Also, see below. When ifupdown recreates the file, it populates it only with a config for lo. I don't think it's reasonable to claim that it's valid and intentional to configure a system in such a way that it will fail to bring up the loopback interface on boot. In fact, booting the system without lo breaks so many assumptions that Ubuntu, for example, *unconditionally* brings up lo on boot, whether or not it's configured in /etc/network/interfaces. I consider restoring a stock /e/n/i on package upgrade to be in the same category. Putting «iface lo» into /etc/network/interfaces is not only a way to ensure there is a loopback interface on boot. It's also a way for ifupdown to claim to handle that interface (this is a natural consequence of the CTTE ruling; that ifupdown is special and has precedence and other tools should stay away from interfaces where there is a ifupdown configuration for the interface), so if ifupdown does add that configuration, there is no way for me to have ifupdown installed so I can read the man page at the same time as letting other tools manage lo. I might also dislike the name «lo» for loopback and rename the lo interface to something else, and let «lo» be the name of yet another interface. It's a bit crazy, but not much cares about network interface names apart from the network configuration tools, so this would actually break a most unusual, but otherwise valid configuration of the network stack. ifupdown would break that configuration. If the reason you raise this concern is because of my comment that NM should always report the system online unless it controls all the network interfaces, I was implicitly excluding lo from the reckoning. First, it's not relevant to whether the machine is online, and second, there's only one valid state for this interface (up) so there's no configuration to fight over the management of. Your mail triggered me to go look, but it wasn't otherwise directly related, no. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695957: googleearth-package: please change googleearth-package to multiarch
Package: googleearth-package Severity: normal Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: x86_64 Kernel: Linux 3.5-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Dear developers, please change googleearth-package to multiarch. As its script is building a debian package, it makes a packaage, which depends ia32-libs and ia32-libs-gtk. So, if then googleearth-X.X-X.X.deb is installed, I cannot deinstall ia32-libs. As you know, ia32-libs are no more needed in multiarch (wheezy and higher, of course). Thank you for readinbg it. I guess, you are already working on it. It is ok for me, to change the status to minor. Best regards Hans -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695958: python2.7: Expose multiarch triplet in sys module
Package: python2.7 Version: 2.7.3~rc2-2.1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, We have several cases where the multiarch triplet is needed for the proper building or functioning of other Python modules or applications. A recent example is virtualenv. In the debian-python mailing list, several solutions for the virtualenv problem have been discussed, but all of them are unsatisfying. What we really need is an officially approved, common way of getting the triplet, that doesn't require shelling out or globbing the file system. When Python is built, it already knows (or can easily find out) what the triplet should be, so it's best if we expose this in the sys module. Attached is a patch similar to one discussed on debian-python. It exposes the triplet as `sys._architecture`. A similar patch will be made available for Python 3.3, except that there, it will be avialable under `sys.implementation._architecture` as per PEP 421. Bilingual Python code can use: import sys getattr(sys, 'implementation', sys)._architecture Cheers. - -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python2.7 depends on: ii libbz2-1.0 1.0.6-4 ii libc6 2.13-37 ii libdb5.1 5.1.29-5 ii libexpat1 2.1.0-1 ii libgcc11:4.7.2-4 ii libncursesw5 5.9-10 ii libreadline6 6.2-8 ii libsqlite3-0 3.7.13-1 ii libtinfo5 5.9-10 ii mime-support 3.52-1 ii python2.7-minimal 2.7.3~rc2-2.1 python2.7 recommends no packages. Versions of packages python2.7 suggests: ii binutils 2.22-7.1 pn python2.7-doc none - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIbBAEBCAAGBQJQy5pQAAoJEBJutWOnSwa/e1QP91RxE/xWAUKQvSM08BEZsmW6 J7NEgCOz5GNIM2nG2VxTL2L2s3dxNNODhMi9r35RrmgSeTkkiUmMiqpL5hKPiVMs 5bjIA/GHYfdZp3wt52qBA2KckvW9D0257QoMs+d5j0lHs/syijTPLGvg9qAJx70L 4SsjZSCnJ4aKpYvu8je8RKc2lzmsLBuY6NuIoIRbee0KhZoXwXwb0y0JNpUj7r2T QlCiM9dh8OS2vMtiRmL27/jT1HWLnoT3tkBzkP/eaYP+wyhwbIsQ8q9Ltk5PtzMV gX/N7sy8QnetNopILxAhmK+h0O9OoH5Is4WrF8USsAJeb8TWLmxOjTTlDmHGyIde xOqj7hlhzc+uNzR/jB09j7Uszj7J0i0hunJadGCmCTk/OunY5Y+IKHBA78+JSNVI hF8j81p6iTg1BNzrcrKAwzbkXFWD/bUgK85xBP1wdtm6srIKVyBfSw5eqiuAVfgw SwLyhiqZPz+UeFXaSKgOGAYLW+do5qZdaQ64CbXTAjm5P/hZR7+xwfA0cnla9RT5 ZclZnHojln9uw/9i1mTMZ+278hnIbTzfzxRkmaNUmKN7VV0gDry9ltlUJtHsGb3C Kn/jYSVsnSqCV06qm2x4Gei5sPqlVN/TpuvEssf5ZnK40mSVMKvTDnit9Gvmh/yU viPWNZdWPBrqaSJ2gAc= =2fr2 -END PGP SIGNATURE- === modified file 'debian/changelog' --- debian/changelog 2012-12-10 19:10:32 + +++ debian/changelog 2012-12-14 20:24:32 + @@ -1,3 +1,10 @@ +python2.7 (2.7.3-13) experimental; urgency=low + + * debian/patches/sys-implementation.diff: Expose multiarch triplet value +as sys._architecture. + + -- Barry Warsaw ba...@python.org Fri, 14 Dec 2012 15:23:02 -0500 + python2.7 (2.7.3-12) experimental; urgency=low * Fix typo in pkgconfig file. Closes: #695671, LP: #1088988. === modified file 'debian/patches/series.in' --- debian/patches/series.in 2012-12-10 16:06:41 + +++ debian/patches/series.in 2012-12-14 20:24:32 + @@ -66,3 +66,4 @@ lib2to3-no-pickled-grammar.diff add-python-config-sh.diff ssl.match_hostname.diff +sys-implementation.diff === added file 'debian/patches/sys-implementation.diff' --- debian/patches/sys-implementation.diff 1970-01-01 00:00:00 + +++ debian/patches/sys-implementation.diff 2012-12-14 20:24:32 + @@ -0,0 +1,60 @@ +--- a/configure.ac b/configure.ac +@@ -24,6 +24,24 @@ + prefix=`echo $prefix | sed -e 's/\/$//g'` + fi + ++dnl Debian multiarch support in sys.implementation._architecture ++dnl Try `dpkg-architecture -qDEB_BUILD_MULTIARCH` first, then ++dnl `gcc --print-multiarch`. ++AC_SUBST(MULTIARCH_BUILD) ++AC_CHECK_PROG(HAS_DPKG_ARCHITECTURE, dpkg-architecture, found, not-found) ++if test $HAS_DPKG_ARCHITECTURE = found ++then ++MULTIARCH_BUILD=dpkg-architecture -qDEB_BUILD_MULTIARCH ++else ++AC_CHECK_PROG(HAS_GCC_FOR_ARCH, gcc, found, not-found) ++if test $HAS_GCC_FOR_ARCH = found ++then ++MULTIARCH_BUILD=gcc --print-multiarch ++else ++MULTIARCH_BUILD= ++fi ++fi ++ + dnl This is for stuff that absolutely must end up in pyconfig.h. + dnl Please use pyport.h instead, if possible. + AH_TOP([ +--- a/Makefile.pre.in b/Makefile.pre.in +@@ -40,6 +40,7 @@ + HGVERSION= @HGVERSION@ + HGTAG= @HGTAG@ + HGBRANCH= @HGBRANCH@ ++MULTIARCH_BUILD= @MULTIARCH_BUILD@ + + GNULD= @GNULD@ + +@@ -1304,6 +1305,11 @@ + + Python/thread.o: @THREADHEADERS@ + ++Python/sysmodule.o: $(srcdir)/Python/sysmodule.c Makefile ++ $(CC) -c $(PY_CORE_CFLAGS) \ ++ -DMULTIARCH_BUILD=\`LC_ALL=C
Bug#680100: Re[4]: [Gc] Alpha issue running test_stack (Debian Bug #680100)
On Fri, Dec 14, 2012 at 03:29:23PM +0100, gregor herrmann wrote: I've prepared a debdiff where I tried to backport the 00d7cb8 commit to the version in testing (attached). Could you please take a look at it and if possible upload it after checking back with the release team? Thanks for doing this. As discussed, this looks correct to me and I'd really appreciate if you could do the NMU on-top of the existing package in t-p-u Thanks, -i -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680100: Re[4]: [Gc] Alpha issue running test_stack (Debian Bug #680100)
On Fri, 14 Dec 2012 13:33:22 -0800, Ian Wienand wrote: On Fri, Dec 14, 2012 at 03:29:23PM +0100, gregor herrmann wrote: I've prepared a debdiff where I tried to backport the 00d7cb8 commit to the version in testing (attached). Could you please take a look at it and if possible upload it after checking back with the release team? Thanks for doing this. As discussed, this looks correct to me and I'd really appreciate if you could do the NMU on-top of the existing package in t-p-u Thank you, will file a t-p-u bug in a minute. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Johnny Cash: I Hung My Head signature.asc Description: Digital signature
Bug#553311: Fwd: New LeoCAD version
On Fri, 14 Dec 2012 03:35:17 +0100, Carlo Stemberger wrote: Hi, here is the announcement. Thanks for the ping. The actual source is building fine; I've been struggling understanding how to build the pieces library over the last few months. Yet I don't know how to build it. :/ David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#695959: python3.3: Expose multiarch triplet in sys module
Package: python3.3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, We have several cases where the multiarch triplet is needed for the proper building or functioning of other Python modules or applications. A recent example is virtualenv. In the debian-python mailing list, several solutions for the virtualenv problem have been discussed, but all of them are unsatisfying. What we really need is an officially approved, common way of getting the triplet, that doesn't require shelling out or globbing the file system. When Python is built, it already knows (or can easily find out) what the triplet should be, so it's best if we expose this in the sys module. Attached is a patch similar to one discussed on debian-python. It exposes the triplet as sys.implementation_architecture. A similar patch has been made available for Python 2.7, except that there, it will be avialable under sys._architecture. Bilingual Python code can use: import sys getattr(sys, 'implementation', sys)._architecture Cheers. - -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQy56RAAoJEBJutWOnSwa/W3wP/ili/1kfbJu7sZvy2LjrgYPJ TXepiU7cp1Ezj5ZQFNMZf7vT9vguamuQfXSXuEaMbzuB22oKaGfdBmVjO9uWppxY 3SJ6Qm8WKM2xcRGmGHVKgwBD7lH1AnUIVSWwz0UMqw7Q6gc2SIYI8ESEYfCvLMRV WVscW9iUMxrzBqHT099PWe7DdCWPhckEnNL76L+uNXkco3HgwasYo+mO/oHCoAVB h67VbWdc2FBo3sbtcf8UQVmAfXeWL5ek1qw7QL2MCAxFR+0rdqj3zRa80+ZhP3Tu zsJqzTietpaS8mnM5fSzsW6yWGutsuBk958cxb4jlKN88U6rvQvM0I+duYzVmSIU gP4iG/F4I5yEN1J41Jpm6xYBOjmmGyHRoDcsnRl3r0bjNnY1JmgymOjnQvTqTYso 0dUR+Oddvd/2PoMr1xWHHstCI5QszbTutXVWMf/cSZPkcbyWuJOTR8p0UU1WzOsO TDmp2OoT/h6/VYuK/MQbEAZMm11A704M4P4rcC2ct045ao/2zRGVJ5cbbvrTbU69 Dy6HbkqeNMBmXsU9jHdyD20jhC9c/WSF3hEKXnMsddNWu6AyM1/4dOrT6UJ1ufxT Gw26A15YtS+ySAcSmwYwb6YcaLjSMyOFpH9x4qpWbTVWZLGqxRccHsqMcfPHOrrr ZQpXIbw85BsTZ29UCbfP =vxcp -END PGP SIGNATURE- === modified file 'debian/changelog' --- debian/changelog 2012-12-04 04:36:42 + +++ debian/changelog 2012-12-14 20:52:07 + @@ -1,3 +1,10 @@ +python3.3 (3.3.0-7) experimental; urgency=low + + * debian/patches/sys-implementation.diff: Expose multiarch triplet value +as sys._architecture. + + -- Barry Warsaw ba...@python.org Fri, 14 Dec 2012 15:50:45 -0500 + python3.3 (3.3.0-6) experimental; urgency=low * Don't use xattrs on kfreebsd and the Hurd. === modified file 'debian/patches/series.in' --- debian/patches/series.in 2012-12-04 04:36:42 + +++ debian/patches/series.in 2012-12-14 20:52:07 + @@ -54,3 +54,4 @@ ext-no-libpython-link.diff add-python-config-sh.diff kfreebsd-xattrs.diff +sys-implementation.diff === added file 'debian/patches/sys-implementation.diff' --- debian/patches/sys-implementation.diff 1970-01-01 00:00:00 + +++ debian/patches/sys-implementation.diff 2012-12-14 20:52:07 + @@ -0,0 +1,63 @@ +--- a/configure.ac b/configure.ac +@@ -84,6 +84,24 @@ + prefix=`echo $prefix | sed -e 's/\/$//g'` + fi + ++dnl Debian multiarch support in sys.implementation._architecture ++dnl Try `dpkg-architecture -qDEB_BUILD_MULTIARCH` first, then ++dnl `gcc --print-multiarch`. ++AC_SUBST(MULTIARCH_BUILD) ++AC_CHECK_PROG(HAS_DPKG_ARCHITECTURE, dpkg-architecture, found, not-found) ++if test $HAS_DPKG_ARCHITECTURE = found ++then ++MULTIARCH_BUILD=dpkg-architecture -qDEB_BUILD_MULTIARCH ++else ++AC_CHECK_PROG(HAS_GCC_FOR_ARCH, gcc, found, not-found) ++if test $HAS_GCC_FOR_ARCH = found ++then ++MULTIARCH_BUILD=gcc --print-multiarch ++else ++MULTIARCH_BUILD= ++fi ++fi ++ + dnl This is for stuff that absolutely must end up in pyconfig.h. + dnl Please use pyport.h instead, if possible. + AH_TOP([ +--- a/Makefile.pre.in b/Makefile.pre.in +@@ -43,6 +43,7 @@ + HGVERSION= @HGVERSION@ + HGTAG= @HGTAG@ + HGBRANCH= @HGBRANCH@ ++MULTIARCH_BUILD= @MULTIARCH_BUILD@ + + GNULD= @GNULD@ + +@@ -647,6 +648,7 @@ + Python/sysmodule.o: $(srcdir)/Python/sysmodule.c Makefile + $(CC) -c $(PY_CORE_CFLAGS) \ + -DABIFLAGS='$(ABIFLAGS)' \ ++ -DMULTIARCH_BUILD=\`LC_ALL=C $(MULTIARCH_BUILD)`\ \ + -o $@ $(srcdir)/Python/sysmodule.c + + $(IO_OBJS): $(IO_H) +--- a/Python/sysmodule.c b/Python/sysmodule.c +@@ -1534,6 +1534,15 @@ + if (res 0) + goto error; + ++/* For Debian multiarch support. */ ++value = PyUnicode_FromString(MULTIARCH_BUILD); ++if (value == NULL) ++goto error; ++res = PyDict_SetItemString(impl_info, _architecture, value); ++Py_DECREF(value); ++if (res 0) ++goto error; ++ + /* dict ready */ + + ns = _PyNamespace_New(impl_info);
Bug#693659: vmix floating-point mode does not use proper API on Linux
control: severity -1 wishlist control: retitle -1 oss4: switch back to vmix floating-point mode once it uses proper api On Fri, Dec 14, 2012 at 12:01 PM, Ivo De Decker wrote: If I misunderstood the situation, feel free to downgrade again. Apologies, but you have. Like I said, the issue was worked around, and that itself needs to be pushed to tpu. I'll do that. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695960: /usr/share/pyshared/UpdateManager/Backend/PythonApt.py: [CRASH] Uncaught exception AttributeError in Backend/PythonApt.py:801
Package: update-manager-core
Version: 0.200.5-2.1
Severity: normal
File: /usr/share/pyshared/UpdateManager/Backend/PythonApt.py
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these lines ***
*** /tmp/update-manager-bug34AFoC
The information below has been automatically generated.
Please do not remove this from your bug report.
- Exception Type: type 'exceptions.AttributeError'
- Exception Value: AttributeError('NoneType' object has no attribute
'get_package_list',)
- Exception Origin: BugHandler.Thread(PythonAptCommit, started
140006984845056)
- Exception Traceback:
File /usr/lib/pymodules/python2.7/UpdateManager/BugHandler.py, line 89, in
run
threading.Thread.run(self, *args, **kwargs)
File /usr/lib/python2.7/threading.py, line 504, in run
self.__target(*self.__args, **self.__kwargs)
File /usr/lib/pymodules/python2.7/UpdateManager/Backend/PythonApt.py, line
801, in thread_helper
for pkg_info in self._available_updates.get_package_list():
-- System Information:
Debian Release: wheezy/sid
APT prefers stable
APT policy: (900, 'stable'), (400, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages update-manager-core depends on:
ii lsb-release 4.1+Debian8
ii python 2.7.3~rc2-1
ii python-apt 0.8.8.1
ii python-support 1.0.15
Versions of packages update-manager-core recommends:
ii update-manager-gnome 0.200.5-2.1
update-manager-core suggests no packages.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695961: boot after installation on Acer Aspire One 725 fails
Package: installation-reports Boot method: USB Image version: http://cdimage.debian.org/cdimage/wheezy_di_beta4/amd64/iso-cd/debian-wheezy-DI-b4-amd64-CD-1.iso Date: 14. 12. 2012 Machine: Acer Aspire One 725 Processor: AMD C-70 Memory: 4 GB Partitions: / and /home Output of lspci -knn (or lspci -nn): NA Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [E] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [E] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[E] Comments/Problems: Configure network: - recognition of Ethernet and WLAN card is correct. LAN card would need non-free firmware (not offered since not found on net - not invested much time in that). - WLAN installed, WEP authentication passed, IP assigned, setup of LAN via DHCP failed! (in another try WLAN was configured manually, but it didn't work either). Clock/timezone setup: - fails because of missing network connection, manual setup not offered (?) Overall install: - touchpad works only in first few screens (had to try how many actually) - after installation is finished and system reboots, grub is started, OS selected, boot process starts, after /dev filesystem is populated, screen gets corrupted (no matter whether desktop packages are selected during the installation or not) and system hangs. System is unresponsive to any key.
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Thu, 13 Dec 2012, Frank Schäfer wrote: I have the MCP61 (rev. A2) with id 10de:03f1. Further NVIDIA OHCI HCD IDs can be found at http://openbenchmarking.org/linux/PCI/0c03. But I'm not sure that we should blacklist them all. Maybe this bug has been fixed in newer chipset revisions / generations ? Has anybody ever seen a report of an nVidia OHCI controller that does _not_ have this bug? Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695962: radicale system user can't use PAM auth
Package: radicale Version: 0.7-1 Severity: normal When trying to use PAM auth, radicale user seems to not being allowed to talk to pam. Errors in /var/log/auth.log : Dec 14 21:59:42 myhost unix_chkpwd[4854]: check pass; user unknown Dec 14 21:59:42 myhost unix_chkpwd[4854]: password check failed for user (steve) Dec 14 21:59:42 myhost python: pam_unix(login:auth): authentication failure; logname=root uid=118 euid=118 tty= ruser= rhost= user=steve Dec 14 21:59:42 myhost python: pam_winbind(login:auth): getting password (0x0388) Dec 14 21:59:42 myhost python: pam_winbind(login:auth): pam_get_item returned a password Dec 14 21:59:42 myhost python: pam_winbind(login:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_USER_UNKNOWN (10), NTSTATUS: NT_STATUS_NO_SUCH_USER, Error message was: No such user The workaround is to had radicale system user to the shadow system group. usermod -G shadow radicale -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 2.6.32-5-kirkwood Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages radicale depends on: ii adduser 3.112+nmu2 add and remove users and groups ii python 2.6.6-3+squeeze7 interactive high-level object-orie ii python-radicale 0.3-2simple calendar server - module radicale recommends no packages. Versions of packages radicale suggests: ii apache2-utils 2.2.16-6+squeeze7 utility programs for webservers pn courier-authdaemon none(no description available) ii python-ldap2.3.11-1 LDAP interface module for Python ii python-pam 0.4.2-13 Python interface to the PAM librar -- Configuration Files: /etc/default/radicale changed: ENABLE_RADICALE=yes RADICALE_OPTS=--daemon VERBOSE=yes /etc/radicale/config changed: [server] [encoding] [acl] type = PAM pam_group_membership = users [storage] filesystem_folder = /var/lib/radicale/collections [logging] debug = false -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695963: magics++: FTBFS: configure error
Package: src:magics++ Version: 2.18.7-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Hi! Your package failed to build on the buildds: checking for pbopen in -lemosR64... yes Emoslib found. checking for pj_init in -lproj... no configure: error: Proj4 could not be linked! tail -v -n +0 config.log Full build log at https://buildd.debian.org/status/fetch.php?pkg=magics%2B%2Barch=amd64ver=2.18.7-1stamp=1355221432 Regards Christoph -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686931: closed by jald...@debian.org (Jaldhar H. Vyas) (Bug#686931: fixed in dovecot 1:2.1.7-3)
On Tue, 27 Nov 2012, Svante Signell wrote: On Tue, 2012-11-27 at 10:44 +0200, Timo Sirainen wrote: On 27.11.2012, at 10.40, Svante Signell wrote: Hi, looks like one PATH_MAX issue remains in 2.1.7. Don't know if the latest version 2.1.10 has solved it. The inlined patch below solves the remaining build problem. One unclear point in the patch is if linkbuf should be freed or not (probably it should). It shouldn't. The compiler warning you get should discourage you from doing that. :) Thanks, I saw the compiler warning when looking at the build log: sieve-storage-script.c: In function 'sieve_storage_read_active_link': sieve-storage-script.c:157:2: warning: passing argument 1 of 'free' discards 'const' qualifier from pointer target type [enabled by default] Hello everyone. Just FYI, I had to remove the hurd compatability stuff in -6 in order to get dovecot into wheezy. But it will be back in -7. -- Jaldhar H. Vyas jald...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691186: unblock: icecast2/2.3.2-9+deb7u2
On Wed, Dec 12, 2012 at 07:04:04PM +, Adam D. Barratt wrote: Control: tags -1 + confirmed On Mon, 2012-10-22 at 20:53 +0200, Moritz Muehlenhoff wrote: Ok to upload to t-p-u with the attached debdiff? This fixes CVE-2011-4612 / #652663) Much as I dislike wheel re-inventing, I'm assuming the patch matches how upstream decided to resolve the issue; please go ahead. A more descriptive changelog entry would be good. ;-) Thanks, that's indeed the backported upstream fix. Uploaded. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695964: librost-blast: FTBFS: symbol changes
Package: src:librostlab-blast Version: 1.0.1-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Hi! Your package failed to build on the buildds: dh_makeshlibs -a -O--parallel dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/librostlab-blast0/DEBIAN/symbols doesn't match completely debian/librostlab-blast0.symbols --- debian/librostlab-blast0.symbols (librostlab-blast0_1.0.1-1_i386) +++ dpkg-gensymbols5oTZaW 2012-11-24 21:22:34.0 + @@ -12,7 +12,8 @@ _Z12yyset_linenoiPv@Base 1.0.0 _Z13yy_scan_bytesPKciPv@Base 1.0.0 _Z13yylex_destroyPv@Base 1.0.0 - _Z14yy_scan_bufferPcmPv@Base 1.0.0 + _Z14yy_scan_bufferPcjPv@Base 1.0.1-1 +#MISSING: 1.0.1-1# _Z14yy_scan_bufferPcmPv@Base 1.0.0 _Z14yy_scan_stringPKcPv@Base 1.0.0 _Z15yy_flush_bufferP15yy_buffer_statePv@Base 1.0.0 _Z16yy_create_bufferP8_IO_FILEiPv@Base 1.0.0 @@ -23,11 +24,13 @@ _Z19yypush_buffer_stateP15yy_buffer_statePv@Base 1.0.0 _Z5yylexPN7rostlab5blast6parser13semantic_typeEPNS0_8locationERNS0_13parser_driverEPv@Base 1.0.0 _Z6yyfreePvS_@Base 1.0.0 - _Z7yyallocmPv@Base 1.0.0 + _Z7yyallocjPv@Base 1.0.1-1 +#MISSING: 1.0.1-1# _Z7yyallocmPv@Base 1.0.0 _Z8yyget_inPv@Base 1.0.0 _Z8yyset_inP8_IO_FILEPv@Base 1.0.0 _Z9yyget_outPv@Base 1.0.0 - _Z9yyreallocPvmS_@Base 1.0.0 + _Z9yyreallocPvjS_@Base 1.0.1-1 +#MISSING: 1.0.1-1# _Z9yyreallocPvmS_@Base 1.0.0 _Z9yyrestartP8_IO_FILEPv@Base 1.0.0 _Z9yyset_outP8_IO_FILEPv@Base 1.0.0 _ZN7rostlab13runtime_errorC1ERKSs@Base 1.0.0 @@ -49,9 +52,11 @@ _ZN7rostlab5blast13parser_driver14trace_scanningEv@Base 1.0.0 _ZN7rostlab5blast13parser_driver5parseEbb@Base 1.0.0 _ZN7rostlab5blast3hitC1ERKS1_@Base 1.0.0 - _ZN7rostlab5blast3hitC1ERKSsS3_m@Base 1.0.0 + _ZN7rostlab5blast3hitC1ERKSsS3_j@Base 1.0.1-1 +#MISSING: 1.0.1-1# _ZN7rostlab5blast3hitC1ERKSsS3_m@Base 1.0.0 _ZN7rostlab5blast3hitC2ERKS1_@Base 1.0.0 - _ZN7rostlab5blast3hitC2ERKSsS3_m@Base 1.0.0 + _ZN7rostlab5blast3hitC2ERKSsS3_j@Base 1.0.1-1 +#MISSING: 1.0.1-1# _ZN7rostlab5blast3hitC2ERKSsS3_m@Base 1.0.0 _ZN7rostlab5blast3hitD0Ev@Base 1.0.0 _ZN7rostlab5blast3hitD1Ev@Base 1.0.0 _ZN7rostlab5blast3hitD2Ev@Base 1.0.0 @@ -123,29 +128,42 @@ _ZN7rostlab5blastlsERSoRKNS0_8locationE@Base 1.0.0 _ZN7rostlab5blastlsERSoRKNS0_8positionE@Base 1.0.0 _ZNK7rostlab16error_backtracer9backtraceEv@Base 1.0.0 + _ZNK7rostlab5blast5sliceINS0_8locationENS0_5stackIS2_St5dequeIS2_SaIS2_EixEj@Base 1.0.1-1 _ZNK7rostlab5blast6parser11debug_levelEv@Base 1.0.0 _ZNK7rostlab5blast6parser12debug_streamEv@Base 1.0.0 - _ZNKSt15_Deque_iteratorIN7rostlab5blast6parser13semantic_typeERKS3_PS4_EplEl@Base 1.0.0 - _ZNKSt15_Deque_iteratorIN7rostlab5blast6parser13semantic_typeERS3_PS3_EmiEl@Base 1.0.0 - _ZNKSt15_Deque_iteratorIN7rostlab5blast6parser13semantic_typeERS3_PS3_EplEl@Base 1.0.0 - _ZNKSt15_Deque_iteratorIN7rostlab5blast8locationERKS2_PS3_EplEl@Base 1.0.0 - _ZNKSt15_Deque_iteratorIN7rostlab5blast8locationERS2_PS2_EmiEl@Base 1.0.0 - _ZNKSt15_Deque_iteratorIN7rostlab5blast8locationERS2_PS2_EplEl@Base 1.0.0 - _ZNKSt15_Deque_iteratorIiRKiPS0_EplEl@Base 1.0.0 - _ZNKSt15_Deque_iteratorIiRiPiEmiEl@Base 1.0.0 - _ZNKSt15_Deque_iteratorIiRiPiEplEl@Base 1.0.0 - _ZNKSt6vectorIN7rostlab5blast3hitESaIS2_EE12_M_check_lenEmPKc@Base 1.0.0 - _ZNKSt6vectorIN7rostlab5blast3hspESaIS2_EE12_M_check_lenEmPKc@Base 1.0.0 - _ZNKSt6vectorIN7rostlab5blast5roundESaIS2_EE12_M_check_lenEmPKc@Base 1.0.0 - _ZNKSt6vectorIN7rostlab5blast7onelineESaIS2_EE12_M_check_lenEmPKc@Base 1.0.0 - _ZNKSt6vectorISsSaISsEE12_M_check_lenEmPKc@Base 1.0.0 - _ZNSt11_Deque_baseIN7rostlab5blast6parser13semantic_typeESaIS3_EE17_M_initialize_mapEm@Base 1.0.0 + _ZNKSt15_Deque_iteratorIN7rostlab5blast6parser13semantic_typeERKS3_PS4_EplEi@Base 1.0.1-1 +#MISSING: 1.0.1-1# _ZNKSt15_Deque_iteratorIN7rostlab5blast6parser13semantic_typeERKS3_PS4_EplEl@Base 1.0.0 + _ZNKSt15_Deque_iteratorIN7rostlab5blast6parser13semantic_typeERS3_PS3_EmiEi@Base 1.0.1-1 +#MISSING: 1.0.1-1# _ZNKSt15_Deque_iteratorIN7rostlab5blast6parser13semantic_typeERS3_PS3_EmiEl@Base 1.0.0 + _ZNKSt15_Deque_iteratorIN7rostlab5blast6parser13semantic_typeERS3_PS3_EplEi@Base 1.0.1-1 +#MISSING: 1.0.1-1# _ZNKSt15_Deque_iteratorIN7rostlab5blast6parser13semantic_typeERS3_PS3_EplEl@Base 1.0.0 + _ZNKSt15_Deque_iteratorIN7rostlab5blast8locationERKS2_PS3_EplEi@Base 1.0.1-1 +#MISSING: 1.0.1-1# _ZNKSt15_Deque_iteratorIN7rostlab5blast8locationERKS2_PS3_EplEl@Base 1.0.0 + _ZNKSt15_Deque_iteratorIN7rostlab5blast8locationERS2_PS2_EmiEi@Base 1.0.1-1 +#MISSING: 1.0.1-1# _ZNKSt15_Deque_iteratorIN7rostlab5blast8locationERS2_PS2_EmiEl@Base 1.0.0 + _ZNKSt15_Deque_iteratorIN7rostlab5blast8locationERS2_PS2_EplEi@Base 1.0.1-1 +#MISSING: 1.0.1-1#
Bug#695965: gnome-shell crashes after restarting NetworkManager
Package: gnome-shell Version: 3.4.2-3 Severity: important Dear Maintainer, * What led up to the situation? Issued /etc/init.d/network-manager restart as root while logged into Gnome as a regular user. * What was the outcome of this action? gnome-shell process crashes then restarts. And of course NetworkManager restarts as well. * What outcome did you expect instead? I expect NetworkManager to restart without crashing gnome-shell. Looking at /var/log/messages while issuing '/etc/init.d/network-manager restart' shows: [ 100.511094] gnome-shell[3518]: segfault at 2bf9 ip 7f77c8c95132 sp 7fff17d07b20 error 4 in libgjs.so.0.0.0[7f77c8c75000+3b000] Retrying while attached to gnome-shell over gdb shows a failure at libgobject-2.0.so instead of libgjs.so above: (gdb) c Continuing. [New Thread 0x7f3a2e11b700 (LWP 4962)] [New Thread 0x7f3a2d711700 (LWP 4963)] [New Thread 0x7f3a2cd09700 (LWP 4964)] [New Thread 0x7f3a23ffe700 (LWP 4965)] [New Thread 0x7f3a21dff700 (LWP 4970)] [New Thread 0x7f3a163fc700 (LWP 4976)] [Thread 0x7f3a163fc700 (LWP 4976) exited] Program received signal SIGSEGV, Segmentation fault. 0x7f3a38af9ef0 in g_type_check_instance_cast () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 (gdb) bt #0 0x7f3a38af9ef0 in g_type_check_instance_cast () from /usr/lib/x86_64 -linux-gnu/libgobject-2.0.so.0 #1 0x7f3a41233ce6 in gjs_value_from_g_argument () from /usr/lib/libgjs.so.0 #2 0x7f3a41235159 in ?? () from /usr/lib/libgjs.so.0 #3 0x7f3a412341e5 in gjs_value_from_g_argument () from /usr/lib/libgjs.so.0 #4 0x7f3a4123a818 in ?? () from /usr/lib/libgjs.so.0 #5 0x7f3a4123abc0 in ?? () from /usr/lib/libgjs.so.0 #6 0x7f3a40d8a056 in ?? () from /usr/lib/libmozjs185.so.1.0 #7 0x7f3a40d73c0f in ?? () from /usr/lib/libmozjs185.so.1.0 #8 0x7f3a40d87f3f in ?? () from /usr/lib/libmozjs185.so.1.0 #9 0x7f3a40d89f3a in ?? () from /usr/lib/libmozjs185.so.1.0 #10 0x7f3a40d58bac in ?? () from /usr/lib/libmozjs185.so.1.0 #11 0x7f3a40d7de4e in ?? () from /usr/lib/libmozjs185.so.1.0 #12 0x7f3a40d87f3f in ?? () from /usr/lib/libmozjs185.so.1.0 #13 0x7f3a40d89f3a in ?? () from /usr/lib/libmozjs185.so.1.0 #14 0x7f3a40d58bac in ?? () from /usr/lib/libmozjs185.so.1.0 #15 0x7f3a40d7de4e in ?? () from /usr/lib/libmozjs185.so.1.0 #16 0x7f3a40d87f3f in ?? () from /usr/lib/libmozjs185.so.1.0 #17 0x7f3a40d89f3a in ?? () from /usr/lib/libmozjs185.so.1.0 #18 0x7f3a40d58bac in ?? () from /usr/lib/libmozjs185.so.1.0 #19 0x7f3a40d7de4e in ?? () from /usr/lib/libmozjs185.so.1.0 #20 0x7f3a40d87f3f in ?? () from /usr/lib/libmozjs185.so.1.0 #21 0x7f3a40d89f3a in ?? () from /usr/lib/libmozjs185.so.1.0 #22 0x7f3a40d583b4 in ?? () from /usr/lib/libmozjs185.so.1.0 #23 0x7f3a40d89cfb in ?? () from /usr/lib/libmozjs185.so.1.0 #24 0x7f3a40d8a414 in ?? () from /usr/lib/libmozjs185.so.1.0 #25 0x7f3a40cff8e4 in JS_CallFunctionValue () from /usr/lib/libmozjs185.so.1.0 #26 0x7f3a4122ce4c in gjs_call_function_value () from /usr/lib/libgjs.so.0 #27 0x7f3a41237cad in gjs_closure_invoke () from /usr/lib/libgjs.so.0 #28 0x7f3a412435f9 in ?? () from /usr/lib/libgjs.so.0 #29 0x7f3a38ad86e0 in g_closure_invoke () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #30 0x7f3a38ae9750 in ?? () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #31 0x7f3a38af16bc in g_signal_emit_valist () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #32 0x7f3a38af1852 in g_signal_emit () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #33 0x7f3a38add085 in ?? () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #34 0x7f3a38ade96b in g_object_notify () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #35 0x7f3a3dc466fb in ?? () from /usr/lib/libnm-glib.so.4 #36 0x7f3a38819355 in g_main_context_dispatch () from /lib/x86_64-linux- gnu/libglib-2.0.so.0 #37 0x7f3a38819688 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #38 0x7f3a38819a82 in g_main_loop_run () from /lib/x86_64-linux- gnu/libglib-2.0.so.0 #39 0x7f3a414a9f27 in meta_run () from /usr/lib/libmutter.so.0 #40 0x00401e77 in main () -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-3 ii gconf-service3.2.5-1+build1 ii gir1.2-accountsservice-1.0 0.6.21-7 ii gir1.2-atk-1.0 2.4.0-2 ii gir1.2-caribou-1.0 0.4.4-1 ii gir1.2-clutter-1.0 1.10.8-2 ii gir1.2-cogl-1.0 1.10.2-6 ii gir1.2-coglpango-1.0
Bug#695949: reprepro: Please allow multiple distributions for include* subcommands
package reprepro tags 695949 + upstream confirmed wontfix thanks * Axel Beckert a...@debian.org [121214 18:09]: I quite often have to do the following: reprepro include squeeze some.changes reprepro include wheezy some.changes reprepro include lucid some.changes reprepro include oneiric some.changes reprepro include precise some.changes reprepro include quantal some.changes It would be nice if could do that like this instead: reprepro include squeeze,wheezy,lucid,oneiric,precise,quantal some.changes The same counts for the includedsc and includedeb subcommands. As including a package can be quite different depending what distribution you put it into (consider for example the case that the different distributions can have disjoint components) and as the include command is not really prepared for those differences, this is not very likely to be implemented anytime soon (and not even very likely to be implemented at all). Note that processincoming support somethine like that. You can have an upload queue that has fields like Multiple: yes Allow: everywheresqueeze everywherewheezy everywherelucid (plus the of course the usual Name: and *Dir:s) to have packages to be put into all those distributions at once. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673606: Please package! I have an actual need.
This is more than a nice to have for me -- I'm trying to work with a project that uses Netbeans API 7.1+ (possibly later by now). Do you need help getting this packaged? If there's something I can do, let me know.
Bug#692297: youtube-dl: Useless (unless updated independently) in wheezy
severity 692297 grave tag 692297 wheezy fixed-upstream confirmed thanks Package: youtube-dl Priority: grave Version: 2012.02.27-1 As reported Youtube-dl, when used in testing, is unable to download *any* videos from Youtube. Unless the system administrator uses it's update functionality, which basicly will download a *new* version of the program and install it on the system the package is quite useless. I'm raising the severity of this bug, tagging it accordinly and providing additional information in this bug report. Below is an annotated transcript of a session right after installing the program in a testing system in order to download a video. As you can see: - the program fails with an error ERROR: unable to download video which does not indicate the cause (this is a known bug upstream, see: https://github.com/rg3/youtube-dl/issues/427) - the reason it fails is only found by Googling, it turns out that the Youtube make changes that turned this program incompatible - the only fix is to update from upstream (or from sid) - the update from upstream is actually installing software as root in the system downloaded from the web without any signature changes as far as I see I'm labeling this bug as 'grave' for testing since it makes the package useless unless updated. I don't think we should release this package in its current state. Note: the bug is *not* present on sid. But even if we fixed this with the 'sid' package, the manpage and errors should indicate the user that if downloads fail (might happen in the future) then he might probably need to update the package from backports. It seems that the current bug might reappear if Youtube.com changes something in its download mechanisms again. Here's a transcript of a use of youtube-dl: TRANSCRIPT BEGIN $ youtube-dl http://www.youtube.com/watch?v=fGFNmEOntFA [youtube] Setting language [youtube] fGFNmEOntFA: Downloading video webpage [youtube] fGFNmEOntFA: Downloading video info webpage [youtube] fGFNmEOntFA: Extracting video information ERROR: unable to download video [ The error here is completely useless. It does not indicate the user what might be the problem. Network error? Permissions? Error in the download? If you debug the connection you actually see a 403 error being returned by Youtube ] $ man youtube-dl [ No information is found on the manpage regarding possible errors. There is no BUG section ] [ Googling a bit you find all these sites which point the user towards updating the program: https://github.com/rg3/youtube-dl/issues/427 http://askubuntu.com/questions/194420/youtube-dl-is-not-working ] $ sudo youtube-dl --update Updating to latest version... Updated youtube-dl. Restart youtube-dl to use the new version. [ First update, as root, downloads and installs a new binary version. There does not seem to be any indication of checks done of the remote server, so a user that runs this exposes himself to a MITM attack. He could be tricked into obtaining a binary which is trojanized, a virus or whatever ] $ youtube-dl http://www.youtube.com/watch?v=fGFNmEOntFA Hi! We changed distribution method and now youtube-dl needs to update itself one more time. This will only happen once. Simply press enter to go on. Sorry for the trouble! The new location of the binaries is https://github.com/rg3/youtube-dl/downloads, not the git repository. ERROR: no write permissions on /usr/bin/youtube-dl [ Ok. the first update did not work, we have to update *again* ] $ sudo youtube-dl --update Hi! We changed distribution method and now youtube-dl needs to update itself one more time. This will only happen once. Simply press enter to go on. Sorry for the trouble! The new location of the binaries is https://github.com/rg3/youtube-dl/downloads, not the git repository. Done! Now you can run youtube-dl. [ OK. We need to run as root and download *another* untrusted binary from the network. At least now it looks like the download connection is SSL. I wonder how is the certificate checked ... ] $ youtube-dl http://www.youtube.com/watch?v=fGFNmEOntFA [youtube] Setting language [youtube] fGFNmEOntFA: Downloading video webpage [youtube] fGFNmEOntFA: Downloading video info webpage [youtube] fGFNmEOntFA: Extracting video information [download] Destination: fGFNmEOntFA.mp4 [download] 100.0% of 183.93M at6.05M/s ETA 00:00 [ finally the download works ] $ youtube-dl --version 2012.12.11 $ debsums youtube-dl /usr/bin/youtube-dl FAILED /usr/share/doc/youtube-dl/NEWS.Debian.gz OK /usr/share/doc/youtube-dl/changelog.Debian.gz OK /usr/share/doc/youtube-dl/copyright OK /usr/share/man/man1/youtube-dl.1.gz OK [ We are not, however running the version provided by the package ] TRANSCRIPT END
Bug#686158: browser-plugin-gnash: Segfault in libgnashplugin.so despite `startStopped on`
Control: tags -1 fixed-upstream Control: affects -1 midori Am Mittwoch, den 29.08.2012, 11:28 +0200 schrieb Paul Menzel: […] using Midori and opening several tabs of Flash using pages like Phoronix articles [2], libgnashplugin.so segfaults more or less reliably. I reported this upstream with the back trace [1] but did not get a response yet. A emphasize again that this is very strange, since `startStopped on` is set. one constructor does not initialize all variables used for file descriptor numbers causing a segmentation fault later on in `FD_SET`. Upstream pushed a commit [3] supposedly fixing this issue. It would be great if that could be backported and the fixed version also uploaded for Wheezy. I rebuild the package with the patch applied and it worked. By the way, the attached patch to the upstream bug report [4] has a more elaborate commit message. Thanks, Paul [1] http://savannah.gnu.org/bugs/?37077 [2] http://www.phoronix.com/ [3] http://git.savannah.gnu.org/cgit/gnash.git/commit/?id=bcd78c4c862f40ca1bdbb90bc88a1bc7970296fc [4] https://savannah.gnu.org/bugs/download.php?file_id=27086 signature.asc Description: This is a digitally signed message part
Bug#695966: kde-workspace-bin: KDE powerdevil sometimes incorrectly attempts to hibernate when resuming from suspend
Package: kde-workspace-bin Version: 4:4.8.4-4 Severity: normal I am using a relatively fresh (one month old) install of Debian Wheezy on a Dell Inspiron 17R Special Edition laptop. KDE powerdevil usually works correctly: it dims my screen when I'm idle and notifies me when my battery is low. But when the laptop resumes from suspend, Powerdevil will occasionally (as in once every ten resumes or so) believe that my battery is critical; it will then warn me that hibernation will occur if I do not connect a power adapter within thirty seconds. If I do not connect an adapter, it lives up to its promise and my laptop will hibernate. The difficulty is that my battery is not critical. I configured Powerdevil to run a script when it believes that the battery is critical; that script contains the following lines: ( echo $(date): KDE thinks the battery is now critical. acpitool echo ) $HOME/kde-battery-log.txt The log file contains the following entry for today: Fri Dec 14 08:53:56 EST 2012: KDE thinks that the battery is now critical. Battery #1 : Unknown, 98.00% AC adapter : online Thermal info : not available My vague guess is that my new laptop has some strange ACPI behavior; for instance, it might report the battery at 0% for the first few milliseconds after a resume or something like that. I would advocate both of the following changes to Powerdevil: * When the notification is issued that the laptop will be hibernated in 30 seconds, provide a button or similar mechanism to allow me to cancel or delay hibernation manually. * When Powerdevil executes an automatic time-delayed hibernate, have the hibernation process check the battery again. Cancel the hibernation if *either* the AC adapter has been plugged in *or* the battery level is well above critical. At this time, I do not have a workaround for this behavior; I just have to get the AC adapter out of my bag really quickly and find a wall outlet (or simply let it hibernate and wake it back up again). -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kde-workspace-bin depends on: ii iso-codes 3.40-1 ii kde-runtime 4:4.8.4-2 ii kde-style-oxygen 4:4.8.4-4 ii kde-workspace-data4:4.8.4-4 ii kde-workspace-kgreet-plugins 4:4.8.4-4 ii libc6 2.13-37 ii libcln6 1.3.2-1.2 ii libfontconfig12.9.0-7 ii libfreetype6 2.4.9-1 ii libgcc1 1:4.7.2-4 ii libgl1-mesa-glx [libgl1] 8.0.5-3 ii libice6 2:1.0.8-2 ii libjpeg8 8d-1 ii libkactivities6 4:4.8.4-1 ii libkcmutils4 4:4.8.4-4 ii libkdeclarative5 4:4.8.4-4 ii libkdecore5 4:4.8.4-4 ii libkdesu5 4:4.8.4-4 ii libkdeui5 4:4.8.4-4 ii libkephal4abi14:4.8.4-4 ii libkfile4 4:4.8.4-4 ii libkidletime4 4:4.8.4-4 ii libkio5 4:4.8.4-4 ii libknewstuff3-4 4:4.8.4-4 ii libknotifyconfig4 4:4.8.4-4 ii libkparts44:4.8.4-4 ii libkpty4 4:4.8.4-4 ii libkrosscore4 4:4.8.4-4 ii libkscreensaver5 4:4.8.4-4 ii libkworkspace4abi14:4.8.4-4 ii libnepomuk4 4:4.8.4-4 ii libnepomukquery4a 4:4.8.4-4 ii libpam0g 1.1.3-7.1 ii libphonon44:4.6.0.0-2 ii libplasma34:4.8.4-4 ii libplasmagenericshell44:4.8.4-4 ii libpng12-01.2.49-1 ii libprocesscore4abi1 4:4.8.4-4 ii libprocessui4a4:4.8.4-4 ii libqalculate5 0.9.7-8 ii libqt4-dbus 4:4.8.2+dfsg-2 ii libqt4-declarative4:4.8.2+dfsg-2 ii libqt4-sql4:4.8.2+dfsg-2 ii libqt4-xml4:4.8.2+dfsg-2 ii libqtcore44:4.8.2+dfsg-2 ii libqtgui4 4:4.8.2+dfsg-2 ii libsm62:1.2.1-2 ii libsolid4 4:4.8.4-4 ii libsolidcontrol4abi2 4:4.8.4-4 ii libsolidcontrolifaces4abi24:4.8.4-4 ii libsoprano4 2.7.6+dfsg.1-1 ii libstdc++64.7.2-4 ii libstreamanalyzer00.7.7-3 ii libusb-0.1-4 2:0.1.12-20+nmu1 ii libx11-6 2:1.5.0-1 ii libxau6 1:1.0.7-1 ii libxcursor1 1:1.1.13-1 ii libxext6 2:1.3.1-2 ii
Bug#695967: [new check] GFDL invariant
Package: lintian
Version: 2.5.10.2
Severity: wishlist
tag: patch
Please found some patch in order to check GFDL liense
diff --git a/checks/cruft b/checks/cruft
index 1121e16..e3a4498 100644
--- a/checks/cruft
+++ b/checks/cruft
@@ -412,11 +412,31 @@ sub find_cruft {
# test license problem is source file (only text file)
if (-T $basename) {
open my $F, '', $basename or fail can't open $name: $!;
+
+# GFDL state variable
+my $foundGFDL = 0;
while (my $line = $F) {
# json evil license
if ($line =~ m/Software\s+shall\s+be\s+used\s+for\s+Good\s*,?\s*not\s+Evil/i) {
tag 'license-problem-json-evil', $name;
}
+ # GFDL state machine
+ if($line =~ m/GNU\s+Free\s+Documentation\s+License/) {
+ $foundGFDL = 1;
+ }
+ if($foundGFDL) {
+ # match in two part in order to not match italic html license example
+ if($line =~ m/with\s+the\s+Invariant\s+Sections\s+being/i) {
+ if($line !~ m/list\s+their\s+titles/i) {
+ tag 'license-problem-gfdl-invariants', $name;
+ }
+ }
+ if($line =~ m/the\s+Front-Cover\s+Texts\s+being/i) {
+ if($line !~ m/the\s+Front-Cover\s+Texts\s+being\s+(?:var)?\s+list/) {
+ tag 'license-problem-gfdl-invariants', $name;
+ }
+ }
+ }
}
close $F or fail can not close opened file $name: $!
}
diff --git a/checks/cruft.desc b/checks/cruft.desc
index 084354d..2ba0866 100644
--- a/checks/cruft.desc
+++ b/checks/cruft.desc
@@ -486,3 +486,9 @@ Info: The given source file is copyrighted under the non free
license of json and the infamous clause:
The Software shall be used for Good, not Evil.
Ref: http://wiki.debian.org/qa.debian.org/jsonevil
+
+Tag: license-problem-gfdl-invariants
+Severity: serious
+Certainty: possible
+Info: The given source file contain is licensed under
+ GFDL with invariant section or frontcover.
Bug#695968: linux-image-3.2.0-4-amd64: ath.ko starts printing thousands of error messages several minutes after boot
Package: src:linux Version: 3.2.35-1 Severity: important Dear Maintainer, * What led up to the situation? Just using the computer normally. For unrelated reasons, the actual network traffic was being routed through eth0 and not wlan0 (even though wlan0 had a valid IP address). Ran my machine all last night and it idled all day today on linux-3.7 without issue, so it appears that at least the 3.7 kernel is enough to avoid this problem. Got home, booted back to linux-image-3.2.0-4-amd64 from unstable, and within a few minutes, NetworkManager started asking me for my wireless password again. Looked at /var/log/messages, and saw thousands of messages. Here's a sampling of the messages from where they started: Dec 11 07:28:55 debian kernel: [ 26.663294] eth0: no IPv6 routers present Dec 11 07:40:20 debian kernel: [ 710.908470] ath: Failed to wakeup in 500us Dec 11 07:40:20 debian kernel: [ 711.116205] ath: Failed to wakeup in 500us Dec 11 07:40:21 debian kernel: [ 711.323932] ath: Failed to wakeup in 500us Dec 11 07:40:21 debian kernel: [ 711.334481] ath: Failed to wakeup in 500us Dec 11 07:40:21 debian kernel: [ 711.399197] ath: Failed to stop TX DMA, queues=0x10f! Dec 11 07:40:21 debian kernel: [ 711.410630] ath: DMA failed to stop in 10 ms AR_CR=0x AR_DIAG_SW=0x DMADBG_7=0x Dec 11 07:40:21 debian kernel: [ 711.410645] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up Dec 11 07:40:21 debian kernel: [ 711.524848] ath: Chip reset failed Dec 11 07:40:21 debian kernel: [ 711.524851] ath: Unable to reset channel, reset status -22 Dec 11 07:40:21 debian kernel: [ 712.030988] ath: Failed to wakeup in 500us Dec 11 07:40:22 debian kernel: [ 712.592641] ath: Failed to stop TX DMA, queues=0x10f! Dec 11 07:40:22 debian kernel: [ 712.604405] ath: DMA failed to stop in 10 ms AR_CR=0x AR_DIAG_SW=0x DMADBG_7=0x Dec 11 07:40:22 debian kernel: [ 712.604409] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up Dec 11 07:40:22 debian kernel: [ 712.718443] ath: Chip reset failed Dec 11 07:40:22 debian kernel: [ 712.718445] ath: Unable to reset channel, reset status -22 Dec 11 07:40:22 debian kernel: [ 712.718457] ath: Unable to set channel Dec 11 07:40:22 debian kernel: [ 712.784418] ath: Failed to stop TX DMA, queues=0x10f! Dec 11 07:40:22 debian kernel: [ 712.795789] ath: DMA failed to stop in 10 ms AR_CR=0x AR_DIAG_SW=0x DMADBG_7=0x Dec 11 07:40:22 debian kernel: [ 712.795793] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up Dec 11 07:40:22 debian kernel: [ 712.910239] ath: Chip reset failed Dec 11 07:40:22 debian kernel: [ 712.910242] ath: Unable to reset channel (2412 MHz), reset status -22 Dec 11 07:40:22 debian kernel: [ 713.034731] ath: Failed to wakeup in 500us After these messages appear, the wlan0 interface is no longer functional (ie. it has lost it's IP address and isn't associated with my access point and 'route' no longer has a path for the wlan0 interface). -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.35-1 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 root=UUID=490e12ae-c9a7-4690-af26-303affdb9a89 ro quiet ** Not tainted ** Kernel log: [ 1823.579486] ath: Failed to wakeup in 500us [ 1828.581029] ath: Failed to wakeup in 500us [ 1833.566841] ath: Failed to wakeup in 500us [ 1838.568081] ath: Failed to wakeup in 500us [ 1843.553632] ath: Failed to wakeup in 500us [ 1848.555477] ath: Failed to wakeup in 500us [ 1853.540704] ath: Failed to wakeup in 500us [ 1857.729388] ath: Failed to wakeup in 500us [ 1857.739864] ath: Failed to wakeup in 500us [ 1857.854378] ath: Chip reset failed [ 1857.854381] ath: Unable to reset channel (2462 MHz), reset status -22 [ 1857.945059] ath: Failed to stop TX DMA, queues=0x10f! [ 1857.956451] ath: DMA failed to stop in 10 ms AR_CR=0x AR_DIAG_SW=0x DMADBG_7=0x [ 1857.956467] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 1858.071039] ath: Chip reset failed [ 1858.071042] ath: Unable to reset channel, reset status -22 [ 1858.071050] ath: Unable to set channel [ 1858.135313] ath: Failed to stop TX DMA, queues=0x10f! [ 1858.146724] ath: DMA failed to stop in 10 ms AR_CR=0x AR_DIAG_SW=0x DMADBG_7=0x [ 1858.146727] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 1858.260711] ath: Chip reset failed [ 1858.260713] ath: Unable to reset channel, reset status -22 [ 1858.260716] ath: Unable to set channel [ 1858.325006] ath: Failed to stop TX DMA, queues=0x10f! [ 1858.336364] ath: DMA failed to stop in 10 ms AR_CR=0x AR_DIAG_SW=0x DMADBG_7=0x [ 1858.336366] ath: Could not stop RX, we could be confusing the DMA engine when we
Bug#695550: libjack-dev: does not automatically transition to libjack-jackd2-dev
On Tue, Dec 11, 2012 at 11:17 AM, The Wanderer wande...@fastmail.fm wrote: On 12/11/2012 08:56 AM, Fabian Greffrath wrote: Am 11.12.2012 14:44, schrieb The Wanderer: And since I didn't say it explicitly before: although I do think the bug report is legitimate, I'm willing enough at this point to fix my own package-install situation manually and proceed from there, if no one has any further suggestions for how to proceed. You could try aptitude why libjack-jackd2-0 to find out what caused the installation of that package and thus the removal of libjack0. Unfortunately, that just reports p libjack-jackd2-dev Provides libjack-dev p libjack-jackd2-dev Depends libjack-jackd2-0 (= 1.9.8~dfsg.4+20120529git007c dc37-4.1) which doesn't tell me anything I didn't already know. I played around with why and why-not for a few other packages as well, but didn't succeed in tracking anything down. (I wasn't aware of these commands, and I think they may be useful for future reference.) It seems possible that this might change if I actually go through with the remove libjack0 and libjack-dev dist-upgrade, so that the jackd2 packages are actually installed (and the jackd1 packages are not) - but so far I haven't done that, and I'm not sure I'd like to. I tried to reproduce this on a clean chroot: 1. Create squeeze chroot 2. Install libjack-dev, jackd and jack1 3. install ia32-libs 4. Add wheezy to sources.list 5. Upgrade apt and dpkg (needed for multiarch) 6. Add i386 foreign architecture in dpkg and apt-get update again 7. apt-get dist-upgrade This caused a lot of installs (including a :i386 flurry), but libjack-dev was not removed, and libjack-jack2-0 was not installed. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688772: gnome Depends network-manager-gnome
On Fri, Dec 14, 2012 at 10:23:58PM +0100, Tollef Fog Heen wrote: I think it's important that an upgrade of the NM package *also* not cause the network to drop, but that's a slightly different point than the one I was meaning to make. My question then still stands: Do you consider NM in any way special here or does the same requirement apply to other network-providing apps? I think NM is quantitatively different from other network-providing packages, but not qualitatively so, because NM purports to manage the primary network connection. If you're remotely connected to a machine over openvpn, and you upgrade the openvpn package, and you are then surprised that the connection drops in the middle while the openvpn server restarts, well... that's a bug, but I'm not sure why you as the admin weren't prepared to deal with that. OTOH, if you upgrade the quagga package and it flushes your entire network's BGP table (to take a historical example), that's a serious issue. So NM is special in that it's important. Other packages that provide similar management of the primary network connection are similarly important. The policy requirement isn't that *filesystem* changes be preserved, it's that *configuration* changes be preserved. In what way does deleting /etc/network/interfaces constitute a valid configuration that must be preserved? The policy requirement is not that the configuration changes are valid. The policy requirement specifically says that: Configuration file handling must conform to the following behavior: * local changes must be preserved during a package upgrade You're right that validity is not mentioned. But I consider this a very broad gray area open to interpretation, and I think all of the following are legitimate, non-buggy (and especially not RC-buggy) actions for a package to take: - update a configuration file on upgrade to drop deprecated, user-specified configuration options that are no longer supported (and which may cause the package to stop working) - convert the configuration file on upgrade from one format to another, preserving any user changes to the configuration settings but not the text of the config file - modify a config file to recover from known software-induced damage, even though it is impossible to determine with certainty that a particular file was damaged by software vs. by explicit admin action - recreate a template config file on upgrade if missing, where the contents of that config file correspond to the default behavior of the software when not configured at all - fail to complete package configuration while the config file is invalid, requiring the admin to fix it manually. I think recreating a stock non-conffile config file when it's been removed is just one more point along this continuum. You might consider it a bug to recreate the file, but I see no basis for considering it a policy violation. And by the way, if you're going to treat it as a serious bug, you'd better get filing other bugs for consistency. Just off the top of my head, base-passwd has had the same handling of /etc/passwd for *years* without anyone objecting. To me, this is very clearly a matter of moving the goal posts. It's not ok to replace a config file just because it has a syntax error in it, is it? Also, see below. Replace, no. Repair, maybe. When ifupdown recreates the file, it populates it only with a config for lo. I don't think it's reasonable to claim that it's valid and intentional to configure a system in such a way that it will fail to bring up the loopback interface on boot. In fact, booting the system without lo breaks so many assumptions that Ubuntu, for example, *unconditionally* brings up lo on boot, whether or not it's configured in /etc/network/interfaces. I consider restoring a stock /e/n/i on package upgrade to be in the same category. Putting «iface lo» into /etc/network/interfaces is not only a way to ensure there is a loopback interface on boot. It's also a way for ifupdown to claim to handle that interface (this is a natural consequence of the CTTE ruling; that ifupdown is special and has precedence and other tools should stay away from interfaces where there is a ifupdown configuration for the interface), so if ifupdown does add that configuration, there is no way for me to have ifupdown installed so I can read the man page at the same time as letting other tools manage lo. I don't see where the previous TC ruling says that ifupdown is special. Rather, it says that upgrading gnome-core shouldn't cause network-manager to clobber the user's network preferences on upgrade, /whichever/ tool they were using to manage those. That should be trivially easy in the case of lo. If the /e/n/i entry for lo is missing, or matches this: iface lo inet loopback ... it's fair game. If it's something else, then /against all reason/, the user has
Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.
On Mon, Dec 10, 2012 at 11:34:47PM +, Roger Leigh wrote: tags 694379 + serious thanks On Mon, Dec 10, 2012 at 09:47:39PM +, Roger Leigh wrote: On Sun, Dec 09, 2012 at 05:24:50PM +0100, Jozsef Marton wrote: Thank you, Roger, for your comments. You're right that the test Oracle XE applies is badly broken. See details inline your comment below. This has not been reported to Oracle as Debian Linux is not a supported platform for running their Database product. (I will make a try reporting this.) Though I understand that dev/shm is an implementation detail, it was user for ages and would using bind mount would simplify Debian users' life when they intend to use Oracle Database. I'm attaching a patch[1] I have tested that makes this behaviour configurable in /etc/default/tmpfs leaving symlink as the default value. I hope that this can be intergated in Wheezy. Thanks very much for the patch. I'll look at merging this, or something very similar to it--there are some other details which also need taking care of. Preliminary patch is at http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=9be900ce3dc679f3f49b86b439b90f6937a159aa This fits in with the existing script logic, and will simply mount the tmpfs on /dev/shm rather than /run/shm if RAMSHM_ON_DEV_SHM=yes. Note that this is currently not tested, so it's not ready for use yet. And (note to me), needs to default RAMSHM=yes if RAMSHM_ON_DEV_SHM=yes since there's no underlaying /run to fall back on. We don't use a bind mount because with this approach it's firstly not needed, and also because bind mounts don't play well in chroot environments. (Another note to me: check chroot upgrade logic in case /run/shm is hardcoded in the maintainer scripts.) With some further additions and testing, the current patch for this is here: http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff_plain;h=f208974e295f187238d2ef6831ebc35d72b3c7de If you'd like to try this out, I'd be grateful for any feedback. If you would prefer prebuilt packages for testing, just let me know, and I'll make them available for download. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695969: linux-image-3.2.0-4-amd64: ath.ko prints thousands of error messages and wireless connection goes down
Package: src:linux Version: 3.2.35-1 Severity: important Dear Maintainer, * What led up to the situation? Just using the computer while both wlan0 and eth0 were active and eth0 was the prefered route. This also ocurred yesterday, so I built upstream linux-3.7 and ran it overnight and all day today without issue. Got home, downgraded to linux-image-3.2.0-4-amd64 from unstable, and within minutes the wireless network starts acting up (noticed because NetworkManager asked me for my wireless password again). Looked in /var/log/messages, and there are thousands of messages from ath.ko. From right before the issues started and including some of many messages looks like: Dec 11 07:28:55 debian kernel: [ 26.663294] eth0: no IPv6 routers present Dec 11 07:40:20 debian kernel: [ 710.908470] ath: Failed to wakeup in 500us Dec 11 07:40:20 debian kernel: [ 711.116205] ath: Failed to wakeup in 500us Dec 11 07:40:21 debian kernel: [ 711.323932] ath: Failed to wakeup in 500us Dec 11 07:40:21 debian kernel: [ 711.334481] ath: Failed to wakeup in 500us Dec 11 07:40:21 debian kernel: [ 711.399197] ath: Failed to stop TX DMA, queues=0x10f! Dec 11 07:40:21 debian kernel: [ 711.410630] ath: DMA failed to stop in 10 ms AR_CR=0x AR_DIAG_SW=0x DMADBG_7=0x Dec 11 07:40:21 debian kernel: [ 711.410645] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up Dec 11 07:40:21 debian kernel: [ 711.524848] ath: Chip reset failed Dec 11 07:40:21 debian kernel: [ 711.524851] ath: Unable to reset channel, reset status -22 Dec 11 07:40:21 debian kernel: [ 712.030988] ath: Failed to wakeup in 500us Dec 11 07:40:22 debian kernel: [ 712.592641] ath: Failed to stop TX DMA, queues=0x10f! Dec 11 07:40:22 debian kernel: [ 712.604405] ath: DMA failed to stop in 10 ms AR_CR=0x AR_DIAG_SW=0x DMADBG_7=0x Dec 11 07:40:22 debian kernel: [ 712.604409] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up Dec 11 07:40:22 debian kernel: [ 712.718443] ath: Chip reset failed Dec 11 07:40:22 debian kernel: [ 712.718445] ath: Unable to reset channel, reset status -22 Dec 11 07:40:22 debian kernel: [ 712.718457] ath: Unable to set channel Dec 11 07:40:22 debian kernel: [ 712.784418] ath: Failed to stop TX DMA, queues=0x10f! Dec 11 07:40:22 debian kernel: [ 712.795789] ath: DMA failed to stop in 10 ms AR_CR=0x AR_DIAG_SW=0x DMADBG_7=0x Dec 11 07:40:22 debian kernel: [ 712.795793] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up Dec 11 07:40:22 debian kernel: [ 712.910239] ath: Chip reset failed Dec 11 07:40:22 debian kernel: [ 712.910242] ath: Unable to reset channel (2412 MHz), reset status -22 Dec 11 07:40:22 debian kernel: [ 713.034731] ath: Failed to wakeup in 500us Dec 11 07:40:22 debian kernel: [ 713.034833] cfg80211: Calling CRDA to update world regulatory domain Dec 11 07:40:22 debian kernel: [ 713.038617] cfg80211: World regulatory domain updated: Dec 11 07:40:22 debian kernel: [ 713.038621] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Dec 11 07:40:22 debian kernel: [ 713.038626] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) Dec 11 07:40:22 debian kernel: [ 713.038630] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) Dec 11 07:40:22 debian kernel: [ 713.038633] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) Dec 11 07:40:22 debian kernel: [ 713.038636] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) Dec 11 07:40:22 debian kernel: [ 713.038639] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) Dec 11 07:40:22 debian kernel: [ 713.135138] ath: Failed to wakeup in 500us Dec 11 07:40:22 debian kernel: [ 713.145635] ath: Failed to wakeup in 500us Dec 11 07:40:22 debian kernel: [ 713.259637] ath: Chip reset failed Dec 11 07:40:22 debian kernel: [ 713.259640] ath: Unable to reset channel (2412 MHz), reset status -22 Dec 11 07:40:23 debian kernel: [ 713.723480] ath: Failed to stop TX DMA, queues=0x10f! Dec 11 07:40:23 debian kernel: [ 713.788035] ath: Failed to stop TX DMA, queues=0x10f! Dec 11 07:40:23 debian kernel: [ 713.799426] ath: DMA failed to stop in 10 ms AR_CR=0x AR_DIAG_SW=0x DMADBG_7=0x Dec 11 07:40:23 debian kernel: [ 713.799439] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up Dec 11 07:40:23 debian kernel: [ 713.914081] ath: Chip reset failed Dec 11 07:40:23 debian kernel: [ 713.914083] ath: Unable to reset channel, reset status -22 Dec 11 07:40:23 debian kernel: [ 714.058610] ath: Failed to stop TX DMA, queues=0x10f! Dec 11 07:40:23 debian kernel: [ 714.069984] ath: DMA failed to stop in 10 ms AR_CR=0x AR_DIAG_SW=0x DMADBG_7=0x Dec 11 07:40:23 debian kernel: [ 714.069987] ath: Could not stop RX,
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
On Thu, Dec 13, 2012 at 09:15:12AM +0100, Adrin wrote: This is the find output: # find /etc -name '*vpnagentd_init*' /etc/rc5.d/K25vpnagentd_init /etc/rc5.d/S85vpnagentd_init /etc/init.d/vpnagentd_init /etc/rc4.d/K25vpnagentd_init /etc/rc4.d/S85vpnagentd_init /etc/rc2.d/K25vpnagentd_init /etc/rc2.d/S85vpnagentd_init /etc/rc3.d/K25vpnagentd_init /etc/rc3.d/S85vpnagentd_init OK, I've solved the problem. If you adjust your symlinks like this: (sid)root@hufflepuff:/# find /etc -name '*vpnagentd_init' | sort | xargs ls -l -rwxr-xr-x 1 root root 1153 Dec 4 08:46 /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 24 Dec 14 22:52 /etc/rc0.d/K01vpnagentd_init - ../init.d/vpnagentd_init lrwxrwxrwx 1 root root 24 Dec 14 22:52 /etc/rc1.d/K01vpnagentd_init - ../init.d/vpnagentd_init lrwxrwxrwx 1 root root 26 Dec 4 08:46 /etc/rc2.d/S21vpnagentd_init - /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 26 Dec 4 08:46 /etc/rc3.d/S21vpnagentd_init - /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 26 Dec 4 08:46 /etc/rc4.d/S21vpnagentd_init - /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 26 Dec 4 08:46 /etc/rc5.d/S21vpnagentd_init - /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 24 Dec 14 22:52 /etc/rc6.d/K01vpnagentd_init - ../init.d/vpnagentd_init And then run insserv: (sid)root@hufflepuff:/# insserv insserv: warning: script 'K01vpnagentd_init' missing LSB tags and overrides insserv: warning: script 'vpnagentd_init' missing LSB tags and overrides It will then adjust the links and all will be well. Not entirely sure why this shows two warnings though. I think the cryptic errors you were getting were a result of S85 being higher than the biggest runlevel S21 in used by insserv. This then makes it get placed after $all and hence the dependency loop. That's my theory anyway--I haven't looked at the code yet. The stop number is adjusted to be first, and has also been removed from runlevels 2-5 and added to runlevels 0, 1 and 6. However, it does look like there's room for improvement here. If we haven't got an LSB header, why does the number get used at all? Isn't its presence in this runlevel sufficient? If so, we could just ignore the number and have insserv assign it one appropriately. Likewise for stop links. I hope this makes some degree of sense. I'm still not entirely sure about how the internals work here. I didn't notice issues like this testing upgrades, possibly due to there always being a script at S99. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695970: bc: Should have a terminal launcher in menus
Package: bc Version: 1.06.95-2 Severity: wishlist Dear Maintainer, bc should have a launcher for a terminal with bc inside in menus (and Gnome Shell). -- System Information: Debian Release: wheezy/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages bc depends on: ii dpkg 1.16.9 ii install-info 4.13a.dfsg.1-10 ii libc6 2.13-37 ii libncurses5 5.9-10 ii libreadline6 6.2-8 bc recommends no packages. bc suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695969: linux-image-3.2.0-4-amd64: ath.ko prints thousands of error messages and wireless connection goes down
Sorry, close this bug. Bug 695968 was already opened for the issue described here. reportbug crashed during bug submission of 695968, so I figured it didn't go through and redid the bug report and this one is therefore a dupe. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688772: gnome Depends network-manager-gnome
On Fri, Dec 14, 2012 at 01:35:49PM +0100, Philipp Kern wrote: On Fri, Dec 14, 2012 at 12:18:31AM -0800, Steve Langasek wrote: (Furthermore, I think the whole idea of needing custom desktop infrastructure to tell apps whether they're online or not is silly; you're online if you have a default route. [...] I know that you put it in braces because it's not your main point. Still I don't think this is true. Other proprietary (and some open) OSes now have elaborate measurement facilities to check if they're online. They detect captive portals and tell you to login, they detect if just IPv6 is broken, but IPv4 works, the other way around, they might even detect if DNS64 and NAT64 are in use. (Coming from an IPv6 background.) I don't want applications to be stuck connecting to stuff if they're not really online. Obviously TCP will retry the handshake for some time but it will still require manual action of reconnecting pidgin if the network access is finally granted. On the other hand one could argue that the network resources pidgin would need could already be available when there's no default route. So centralizing the knowledge what it takes for a network connection to be considered up (for which n-m gives you basic means like requiring IPv4 and/oror requiring IPv6 to be up on a given interface) makes a lot of sense. And it could still be improved. Fair point. The main idea I was trying to express wasn't that having such a higher-level network connectivity service was somehow redundant or useless, but the importance of failing *open* when the service is absent or operating with incomplete information. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#695550: libjack-dev: does not automatically transition to libjack-jackd2-dev
On 12/14/2012 05:59 PM, Felipe Sateler wrote: On Tue, Dec 11, 2012 at 11:17 AM, The Wanderer wande...@fastmail.fm wrote: On 12/11/2012 08:56 AM, Fabian Greffrath wrote: You could try aptitude why libjack-jackd2-0 to find out what caused the installation of that package and thus the removal of libjack0. Unfortunately, that just reports p libjack-jackd2-dev Provides libjack-dev p libjack-jackd2-dev Depends libjack-jackd2-0 (= 1.9.8~dfsg.4+20120529git007c dc37-4.1) which doesn't tell me anything I didn't already know. I played around with why and why-not for a few other packages as well, but didn't succeed in tracking anything down. (I wasn't aware of these commands, and I think they may be useful for future reference.) It seems possible that this might change if I actually go through with the remove libjack0 and libjack-dev dist-upgrade, so that the jackd2 packages are actually installed (and the jackd1 packages are not) - but so far I haven't done that, and I'm not sure I'd like to. I tried to reproduce this on a clean chroot: 1. Create squeeze chroot 2. Install libjack-dev, jackd and jack1 3. install ia32-libs 4. Add wheezy to sources.list 5. Upgrade apt and dpkg (needed for multiarch) 6. Add i386 foreign architecture in dpkg and apt-get update again 7. apt-get dist-upgrade This caused a lot of installs (including a :i386 flurry), but libjack-dev was not removed, and libjack-jack2-0 was not installed. Well, I have encountered the same problem on a second system (a laptop, configured similarly although not identically to the original report's desktop machine), so at least it's not a pure one-off situation. I don't have any further ideas about how to track down the cause, however, and although I do have a squeeze-based VM explicitly for testing things related to Debian I'm not likely to have time to experiment much with this anytime soon. For the time being, I've gone ahead and dodged around the problem (on one of the two affected systems) by dist-upgrading with jackd1 and libjack-dev held. Whether there will be problems with future dist-upgrades I don't know. FWIW, I've checked the dependencies of every package in that dist-upgrade via 'apt-cache show', and the only references to jack are in the package description (not the actual dependencies) of vlc-nox. The only packages not modified in that dist-upgrade which would be modified in one without those two holds are the four which would be removed and the four which would be installed: jackd1, jackd1-firewire, libjack-dev, and libjack0 on the one hand, and jackd2, jackd2-firewire, libjack-jackd2-0, and libjack-jackd2-0:i386 on the other. If you want to close this as unreproducible or similar, I wouldn't actively object. It might be worth keeping it open as a low priority just in case something does get discovered, or for discoverability in case someone else has the same problem, but I'm not in a position to make that judgment. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683508: couldn't run gnome-keyring-daemon
Package: lightdm Version: 1.2.2-4 I almost reported this as a new bug until I saw this existing report. It seems similar enough to group it together. I am seeing these messages to the system log: Dec 14 11:13:56 hysteria lightdm: gkr-pam: couldn't run gnome-keyring-daemon: No such file or directory Dec 14 11:13:56 hysteria lightdm: gkr-pam: gnome-keyring-daemon didn't start properly properly I do not have gnome-keyring-daemon installed. Why is it trying to start it? I am not running a gnome system. Bob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635131: systemd: Creates user-writable directory under /run, /run/user
severity 635131 important thanks On 22.07.2011 23:27, Roger Leigh wrote: /run/user is created by systemd. This contains within it directories owned by logged in users e.g. /run/user/rleigh in my case, and the environment variable XDG_RUNTIME_DIR is set to this location. There are a few problems with this: 1) Any user can now trivially DoS the system by filling up /run. I think that is a valid problem and a possible solution would be to use a separate tmpfs for /run/user as long as we don't have quota support for tmpfs. mountall (upstart) goes this route and uses none /run/user tmpfs nodev,noexec,nosuid,size=104857600,mode=0755 0 0 in /lib/init/fstab. The only tricky part here is the size. We can either: a/ hard code it and ship a run-user.mount unit in /lib/systemd/system b/ generate it dynamically upon installation and store the mount unit in /etc/systemd/system If a/, the question is which size we chose, if b/ which percentage of the available RAM we use. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
