Bug#668776: [lshell] log directory permissions insecure/wrong
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, Am 14.04.2012 12:36, schrieb Raf Czlonka: When logrotate runs it generates an error message: error: skipping /var/log/lshell/*.log because parent directory has insecure permissions (It's world writable or writable by group which is not root) Set su directive in config file to tell logrotate which user/group should be used for rotation. is there a chance to get that fixed in wheezy? On the first view it looks really like a minor issue. But it can be really annoying to get mails every day from daily cronjob about this. Many thanks, Jan. - -- Never write mail to w...@spamfalle.info, you have been warned! - -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y - --END GEEK CODE BLOCK-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQmMTM9u6Dud+QFyQRArS2AJ9HSl+pMzaq2mpF6g6j+yl74HHOmQCfdo/5 PpoCDe0CYZUxEEPMkhHHR/w= =fgbv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668776: [lshell] log directory permissions insecure/wrong
On Tue, Nov 6, 2012 at 9:05 AM, Jan Wagner w...@debian.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, Am 14.04.2012 12:36, schrieb Raf Czlonka: When logrotate runs it generates an error message: error: skipping /var/log/lshell/*.log because parent directory has insecure permissions (It's world writable or writable by group which is not root) Set su directive in config file to tell logrotate which user/group should be used for rotation. is there a chance to get that fixed in wheezy? I will fix this ASAP. On the first view it looks really like a minor issue. But it can be really annoying to get mails every day from daily cronjob about this. Do you think it is important enough to request a freeze exception? Many thanks, Jan. Cheers, Ignace M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668776: [lshell] log directory permissions insecure/wrong
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ignace, thanks for your fast reply. Am 06.11.2012 09:11, schrieb Ignace Mouzannar: On Tue, Nov 6, 2012 at 9:05 AM, Jan Wagner w...@debian.org wrote: is there a chance to get that fixed in wheezy? I will fix this ASAP. On the first view it looks really like a minor issue. But it can be really annoying to get mails every day from daily cronjob about this. Do you think it is important enough to request a freeze exception? as it seems to be non invasive change, I think it's worth to give it a try. Just ask for a freeze exception with a included debdiff. Many thanks for caring, Jan. - -- Never write mail to w...@spamfalle.info, you have been warned! - -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y - --END GEEK CODE BLOCK-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQmMl69u6Dud+QFyQRAkQMAJ9jnPD0LE8thco9LLExqwI44WEyRQCfTKiu iJjzoR56apTndPgviIOZMPE= =hab2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692367: [Pkg-gmagick-im-team] Bug#692367: patches
On Mon, Nov 5, 2012 at 10:28 PM, Vincent Danen vda...@redhat.com wrote: Would it be possible to get the patches noted to fix these flaws? Other distros would be interested in it as well (as would upstream, I imagine). Has this been reported upstream yet? They have been fixed upstream. it is only a backport. The backport are joined here -- Vincent Danen / Red Hat Security Response Team ___ Pkg-gmagick-im-team mailing list pkg-gmagick-im-t...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team 0005-Memory-leak-after-setjmp-used-variable-need-to-be-vo.patch Description: Binary data 0006-Fix-a-memory-leak-in-webp-handling.patch Description: Binary data 0007-Magick-fix-a-memory-leak.patch Description: Binary data
Bug#692432: exaile: from mp3 to ogg : still difficult
As I came back to previous version, I can tell : * On screen display does not close ; This was due to version change. Re-initiating the config file fixed that. * Asking for properties of a file blocks the gui a long time (proportionnal to playlist length ?) but the music continues playing ; It's the same in previous version. With a big playlist, a long time is needed to obtain properties (but I think it was not this way before). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674156: alignment issue
reassign 674156 glib-2.0
thanks,
On Fri, Oct 19, 2012 at 10:32:46PM +0900, Koichi Akabe wrote:
(gst-plugin-scanner:961): GLib-GObject-WARNING **: specified instance
size for type `GstRtpAC3Depay' is smaller than the parent type's
`GstBaseRTPDepayload' instance size
Digging through this it turned out that GStaticMutex changed size since
squeeze... When running the following test program:
#include stdio.h
#include glib.h
#define SIZE(x) printf (#x : %G_GSIZE_FORMAT\n, sizeof (x))
int
main (int argc, char **argv)
{
SIZE (GMutex *);
SIZE (double);
SIZE (pthread_mutex_t);
SIZE (GStaticMutex);
SIZE (GStaticRecMutex);
SIZE (struct { GMutex *a; union { char pad[24] ; char d; }; });
return 0;
}
On squeeze (armel):
GMutex *: 4
double: 8
pthread_mutex_t: 24
GStaticMutex: 32
GStaticRecMutex: 48
struct { GMutex *a; union { char pad[24] ; double d; }; }: 32
On wheezy (armel):
GMutex *: 4
double: 8
pthread_mutex_t: 24
GStaticMutex: 28
GStaticRecMutex: 40
struct { GMutex *a; union { char pad[24] ; double d; }; }: 32
Digging futher and futher on squeese GStaticMutex was defined as:
struct _GStaticMutex
{
struct _GMutex *runtime_mutex;
union {
char pad[24];
double dummy_double;
void *dummy_pointer;
long dummy_long;
} static_mutex;
};
While on wheezy:
typedef struct
{
GMutex *mutex;
#ifndef G_OS_WIN32
/* only for ABI compatibility reasons */
pthread_mutex_t unused;
#endif
} GStaticMutex;
Even though both pthread_mutex_t and the earlier union are 24 bytes themselves,
because of the double in the union it gets aligned to a multiple of 8 on ARM,
causing 4 bytes of extra padding to be added. Which in turns makes the old
GStaticMutex struct 4 bytes bigger then the current one...
This obviously breaks ABI on these platforms, not only of glib but also of
libraries which have a GStaticMutex embedded in their public structs in some
way.
I'm not sure what to do at this point... One option would be to patch
glib-2.0 so it's at least ABI compatible again with squeeze again, but it's
unlikely other distributions would follow (so we would be incompatible with
others). On the other hand this might not matter so much for arm.
Whatever we do, we do need to ensure that all affected software gets compiled
against whatever final solution we pick.
--
The light of a hundred stars does not equal the light of the moon.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668197: (no subject)
Ah, that patch doesn't work on Gnome because all the browser settings in
liferea other than manual get ignored in Gnome. Setting the browser default to
manual doesn't seem to work either.
Purging all the browser options other than manual (x-www-browser) works for
Gnome and works for a vanilla KDE install as well. It's not pretty, but it
fixes all 4 problems listed above.
New patch attached.
--- a/src/browser.c
+++ b/src/browser.c
@@ -28,50 +28,6 @@
#include ui/liferea_shell.h
static struct browser browsers[] = {
- {
- default, N_(Default Browser), NULL, /* triggering gtk_show_uri() */
- NULL, NULL,
- NULL, NULL,
- NULL, NULL
- },
- {
- /* tested with SeaMonkey 1.0.6 */
- mozilla, Mozilla, mozilla %s,
- NULL, mozilla -remote openURL(%s),
- NULL, mozilla -remote 'openURL(%s,new-window)',
- NULL, mozilla -remote 'openURL(%s,new-tab)'
- },
- {
- /* tested with Firefox 1.5 and 2.0 */
- firefox, Firefox,firefox \%s\,
- NULL, firefox -a firefox -remote \openURL(%s)\,
- NULL, firefox -a firefox -remote 'openURL(%s,new-window)',
- NULL, firefox -a firefox -remote 'openURL(%s,new-tab)'
- },
- {
- opera, Opera,opera \%s\,
- opera \%s\, opera -remote \openURL(%s)\,
- opera -newwindow \%s\, NULL,
- opera -newpage \%s\, NULL
- },
- {
- epiphany, Epiphany,epiphany \%s\,
- NULL, NULL,
- epiphany \%s\, NULL,
- epiphany -n \%s\, NULL
- },
- {
- konqueror, Konqueror, kfmclient openURL \%s\,
- NULL, NULL,
- NULL, NULL,
- NULL, NULL
- },
- {
- x-www-browser, x-www-browser, x-www-browser \%s\,
- NULL, NULL,
- NULL, NULL,
- NULL, NULL
- },
{ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL }
};
Bug#662611: with the new kernel Pulseaudio volume changes weirdly connect multiple ALSA channels together
Sjoerd Simons wrote: On Mon, 2012-11-05 at 00:44 -0800, Jonathan Nieder wrote: Am I correct in guessing that Nico gave some clarification privately? Didn't notice it was only a private mail, Nico let me know he has switched to a different distribution, which means we can't really debug this any futher :/ Thanks, that makes sense. Nico, if your new distro is Debian- or RPM-based, feel free to let me know privately and I can send some instructions for isolating the change that fixed this so it can be applied to the 3.2.y kernel from kernel.org. Regards, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686070: libpam-ssh/1.92-15
On 11/6/12 5:13 AM, Jerome BENOIT wrote: a potential sponsor for reintroducing libpam-ssh asked me to contact you as previous maintainer for comments on the reintroduction version, which is meant to be a minimal version. A commented debdiff output is attached in such a way you can get quickly a picture of this minimal version. Looks fine to me, thanks for taking care of libpam-ssh! Cheers, /JP -- Jens Peter Secher jpsec...@gmail.com A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692429: libpython3.3-dev: fatal error: pyconfig.h: No such file or directory
reassign 692429 blender severity 692429 important thanks Am 06.11.2012 07:10, schrieb IRIE Shinsuke: Package: libpython3.3-dev Version: 3.3.0-2 Severity: grave I attempted to build Blender trunk using python3.3-dev but got the following error: [ 58%] Building C object source/blender/python/intern/CMakeFiles/bf_python.dir/gpu.c.o In file included from /home/irie/Subversion/Blender/blender/source/blender/python/intern/gpu.c:40:0: /usr/include/python3.3m/Python.h:8:22: fatal error: pyconfig.h: No such file or directory compilation terminated. '#include pyconfig.h' in Python.h assumed that pyconfig.h is in /usr/include/python3.3m, but it's actually placed in /usr/include/x86_64-linux-gnu/python3.3m. Probably most of all programs using libpython3.3 cannot be built for this bug. no, only these which use home-grown configure tests. Please use python3.3-config --includes or pkgconfig. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692155: Please
Russ Allbery wrote: Actually, it could ship in the regular shared library path. It would just change its SONAME a lot, which would be fine, since no other applications would link against it and therefore no one would really care. And indeed it would probably have to be in the public search path because libcups itself would doubtless need to depend on it. Would setting DT_RUNPATH on libcups work to avoid that? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692433: getaddrinfo: Syscall param socketcall.connect(serv_addr.sin6_addr) points to uninitialised byte(s)
Package: libc6
Version: 2.13-36
Severity: normal
Dear Maintainer,
when calling getaddrinfo(), valgrind detects:
==7051== Syscall param socketcall.connect(serv_addr.sin6_addr) points to
uninitialised byte(s)
==7051==at 0x362E6DB780: __connect_nocancel (syscall-template.S:82)
==7051==by 0x362E6B9307: getaddrinfo (getaddrinfo.c:2279)
==7051==by 0x4006A3: main (x.c:17)
==7051== Address 0x7fe10 is on thread 1's stack
==7051== Uninitialised value was created by a stack allocation
==7051==at 0x362E6B8FD0: getaddrinfo (getaddrinfo.c:2092)
Here is the short C source to reproduce the problem (gcc -g x.c -o x):
#include stdio.h
#include string.h
#include sys/types.h
#include sys/socket.h
#include netdb.h
void main(void)
{
struct addrinfo *addrinfo = NULL;
struct addrinfo hints;
memset(hints,0,sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
hints.ai_flags = AI_NUMERICSERV;
if (getaddrinfo(www.example.com, 80, hints, addrinfo) == 0)
freeaddrinfo(addrinfo);
}
This problem is pretty new, maybe introduced by fixing bug #690021.
Regards, Tim
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6:amd64 depends on:
ii libc-bin 2.13-36
ii libgcc1 1:4.7.2-4
libc6:amd64 recommends no packages.
Versions of packages libc6:amd64 suggests:
ii debconf [debconf-2.0] 1.5.46
ii glibc-doc 2.13-36
ii locales2.13-36
ii locales-all [locales] 2.13-36
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692434: yui: CVE-2012-5475 - YUI 2.x security issue regarding embedded SWF files
Package: yui Severity: grave Tags: security Justification: user security hole Hi, please see : http://www.yuiblog.com/blog/2012/10/30/security-announcement-swf-vulnerability- in-yui-2/ Are vulnerable versions in Debian? Cheers, luciano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692225: [3.2-3.6.4 regression] screen starts to flicker after suspend-to-disk
Sebastian Ramacher wrote: I've just tried 3.7 RC 3. The assertion failure is gone and it doesn't flicker anymore. Yay, thank you for testing so quickly. 3.6.y is not an advertised longterm release and if I understand correctly 3.4.y is not affected, so I don't think I'll bother backporting the fix. At the moment what would help most in easily bringing the fix in experimental is rebasing the realtime patchset against 3.7 release candidates. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692435: gegl: CVE-2012-4433 - Integer overflow, leading to heap-based buffer overflow by parsing PPM image headers
Package: gegl Severity: grave Tags: security Justification: user security hole Hi, please see : http://seclists.org/oss-sec/2012/q4/215 Can you confirm if any of the Debian packages are affected? Cheers, luciano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692361: [experimental] ACPI display backlight brightness is set to zero at every boot-up
Stefan Nagy wrote: I tested this with vanilla kernel 3.6.4 and can confirm that this is an upstream bug. I suppose this bug report is a duplicate of #681743 but since I'm seeing this on another notebook (HP Folio 13-2000) than the original reporter Jonathan Nieder asked me to open a new report. Thanks! They certainly seem related, though I am not sure yet that the symptoms are identical. Please tell me if you need more information. Please attach full dmesg output from booting a good and bad kernel, and acpidump output. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691237: libassuan0: fixed ASSUAN_LINELENGTH for 4096bit encryption keys (Patch included)
Control: reassign -1 gnupg2 Control: retitle -1 fixed length for assuan messages is too short for 4096 decryption keys For gnupg2 maintainers: this is about an issue with gnupg2 not beeing able to decrypt stuff encrypted for 4096b keys on OpenPGP smartcards. This is caused by messages sent over assuan protocol being too large for 4096 keys. Patch attached in this bug report implements a split (think fragmentation of IP packets) in order to send the data in multiple packets. On lun., 2012-11-05 at 22:08 +0100, Heiko Schlittermann wrote: Hi, thank you for responding :) Yves-Alexis Perez cor...@debian.org (Mo 05 Nov 2012 18:45:00 CET): On mar., 2012-10-23 at 13:12 +0200, Heiko Schlittermann wrote: Package: libassuan0 Version: 2.0.3-1 Severity: important Tags: upstream patch I used a 4096bit key for encryption (using the GnuPG crypto-stick). Encryption worked, but decryption didn't work (gpg2 didn't find the secret key.) gpg2 uses libassuan to talk to some daemons/agents. gpg (1.x) worked, but only if there was no gnupg-agent running. Patch: http://lists.gnupg.org/pipermail/gnupg-users/2012-June/044868.html I applied this patch and re-built libassuan0-* and gnupg2. This seems to fix the issue. The patch is wrong, according to http://lists.gnupg.org/pipermail/gnupg-devel/2009-October/025412.html According to this above message, my crypt-stick should not expose this bug (SN:113A). But it does. Well, the above message says that SN above 0x15a don't have the firmware bug but doesn't tell anything about the assuan messages size. A better patch was once sent to the same mailing list the following month: http://lists.gnupg.org/pipermail/gnupg-devel/2009-November/025421.html by Klaus Flittner (on CC:). This was never applied because of the lack of copyright assignment. Imho this is a simple bugfix which is not even copyrightable, but IANAL. I've ported the patch to the current gnupg 2.0.19 in Wheezy and sid (it's attached). Ok, I'll test it here. But it will not happen sooner than thursday. And indeed, the patch is to be applied against gnupg2, not libassuan, so I'm reassigning to correct package. I intend to (re)submit it to upstream but it won't work on 2.1 / git HEAD right now and I lack the time to properly port it right now. I think it'd still be nice to push it to gnupg in Debian so we can use 4096 encryption with smartcard, although it might be worth having upstream comment on the technical part before. Yep. I'm not able to decide, if the suggested protocol change breakes other applications. As the line length extension broke gpa for me. I think, here recompilation would have been sufficient, but I didn't test it. As it adds a --more argument to one command, but still support the previous usages I guess it shouldn't break other applications. And application needing to send more data than currently possible over one message can be ported to use the --more argument. So I guess it's fairly safe, but having a comment from upstream would be nice indeed. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#685099: VTKConfig-Tcl.cmake appears not only in libvtk5-dev but also in tcl-vtk
Package: libvtk5-dev Version: 5.9.0-1 Followup-For: Bug #685099 Dear Maintainer, Unpacking replacement tcl-vtk ... dpkg: error processing /var/cache/apt/archives/tcl-vtk_5.9.0-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/vtk-5.9/VTKConfig-Tcl.cmake', which is also in package libvtk5-dev 5.9.0-1 configured to not write apport reports Preparing to replace python-vtk 5.8.0-13+b1 (using .../python-vtk_5.9.0-1_amd64.deb) ... Unpacking replacement python-vtk ... dpkg: error processing /var/cache/apt/archives/python-vtk_5.9.0-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/vtk-5.9/VTKConfig-Python.cmake', which is also in package libvtk5-dev 5.9.0-1 so this bug also affect python-vtk even for 5.9.0-1 in experimental. Best regards, Alban -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.6.0-rc3test0-00207-g318e151-dirty (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libvtk5-dev depends on: ii libavcodec-dev 6:0.8.4-1 ii libavformat-dev6:0.8.4-1 ii libavutil-dev 6:0.8.4-1 ii libc6-dev 2.13-36 ii libexpat1-dev [libexpat-dev] 2.1.0-1 ii libfreetype6-dev 2.4.9-1 ii libgl1-mesa-dev [libgl-dev]8.0.5-1 ii libgl2ps-dev 1.3.7-1~exp1 ii libglu1-mesa-dev [libglu-dev] 8.0.5-1 ii libjpeg8-dev [libjpeg-dev] 8d-1 ii libmysqlclient-dev 5.5.28+dfsg-1 ii libnetcdf-dev 1:4.1.3-6+b1 ii libpng12-dev [libpng-dev] 1.2.49-3 ii libpq-dev 9.2.1-1 ii libqt4-dev 4:4.8.2+dfsg-2 ii libswscale-dev 6:0.8.4-1 ii libtiff4-dev [libtiff-dev] 3.9.6-9 ii libvtk5.9 5.9.0-1 ii libx11-dev 2:1.5.0-1 ii libxft-dev 2.3.1-1 ii libxml2-dev2.9.0+dfsg1-3 ii libxss-dev 1:1.2.2-1 ii libxt-dev 1:1.1.3-1 ii mpi-default-dev1.0.1 ii tcl8.5-dev 8.5.12-1 ii tk8.5-dev 8.5.12-1 ii x11proto-core-dev 7.0.23-1 ii zlib1g-dev 1:1.2.7.dfsg-13 libvtk5-dev recommends no packages. Versions of packages libvtk5-dev suggests: ii vtk-doc 5.9.0-1 ii vtk-examples 5.9.0-1 -- 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#692436: linux-image-3.2.0-4-amd64: asus-laptop module loads slow (fine in 3.2.0-3-amd64)
Package: src:linux Version: 3.2.32-1 Severity: normal Dear Maintainer, After an update to linux-image-3.2.0-4-amd64 from linux-image-3.2.0-3-amd64, I noticed boots were taking longer. I saw Waiting for /dev to be fully populated, so I disabled quiet boot... I saw loading the module asus_laptop (asus-laptop.ko) was taking well over 11 seconds. I tried booting my prior kernel 3.2.0-3-amd64 (3.2.23-1), and it was rapid, with no pause at all: Nov 5 22:33:12 lt kernel: [1.907061] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 Nov 5 22:33:12 lt kernel: [1.907156] ACPI: Power Button [PWRF] Nov 5 22:33:12 lt kernel: [1.912961] ACPI: AC Adapter [AC0] (on-line) Nov 5 22:33:12 lt kernel: [1.913853] usbcore: registered new interface driver usbfs Nov 5 22:33:12 lt kernel: [1.913959] usbcore: registered new interface driver hub Nov 5 22:33:12 lt kernel: [1.919356] [drm] Initialized drm 1.1.0 20060810 Nov 5 22:33:12 lt kernel: [1.921039] asus_laptop: Asus Laptop Support version 0.42 Nov 5 22:33:12 lt kernel: [1.921330] asus_laptop: UL30A model detected Nov 5 22:33:12 lt kernel: [1.922105] asus_laptop: Backlight controlled by ACPI video driver Nov 5 22:33:12 lt kernel: [1.922265] input: Asus Laptop extra buttons as /devices/platform/asus_laptop/input/input4 Nov 5 22:33:12 lt kernel: [1.932089] usbcore: registered new device driver usb I blacklisted asus-laptop in modprobe, rebuilt the initrd, and the boots appeared to be around normal speed. Running modprobe asus-laptop showed it was slow. unloading and showing load time: rmmod asus-laptop ; time modprobe asus-laptop real0m12.159s user0m0.016s sys 0m0.020s strace modprobe asus-laptop output is an attachment, it is slow after printing the ^init_module line. Modinfo for both modules reports the same information, except for the vermagic line: filename: /lib/modules/3.2.0-4-amd64/kernel/drivers/platform/x86/asus-laptop.ko license:GPL description:Asus Laptop Support author: Julien Lerouge, Karol Kozimor, Corentin Chary alias: acpi*:ATK0101:* alias: acpi*:ATK0100:* depends:input-polldev,sparse-keymap,rfkill intree: Y vermagic: 3.2.0-4-amd64 SMP mod_unload modversions parm: wapf:WAPF value (uint) parm: wlan_status:Set the wireless status on boot (0 = disabled, 1 = enabled, -1 = don't do anything). default is -1 (int) parm: bluetooth_status:Set the wireless status on boot (0 = disabled, 1 = enabled, -1 = don't do anything). default is -1 (int) parm: wimax_status:Set the wireless status on boot (0 = disabled, 1 = enabled, -1 = don't do anything). default is -1 (int) parm: wwan_status:Set the wireless status on boot (0 = disabled, 1 = enabled, -1 = don't do anything). default is -1 (int) parm: als_status:Set the ALS status on boot (0 = disabled, 1 = enabled). default is 0 (int) Any thoughts on narrowing the cause of the slow load in the newer kernel? Tks -- 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-12) ) #1 SMP Debian 3.2.32-1 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 root=UUID=3142c636-2d80-45fc-896d-1adc8b29f5b7 ro ** Not tainted ** Kernel log: [2.032141] iTCO_vendor_support: vendor-support=0 [2.035227] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.07 [2.035440] iTCO_wdt: Found a ICH9M-E TCO device (Version=2, TCOBASE=0x0860) [2.040892] mtrr: type mismatch for d000,1000 old: write-back new: write-combining [2.043605] [drm] MTRR allocation failed. Graphics performance may suffer. [2.045239] i915 :00:02.0: irq 44 for MSI/MSI-X [2.045250] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [2.045319] [drm] Driver supports precise vblank timestamp query. [2.045451] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [2.047595] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [2.100953] atl1c :03:00.0: version 1.0.1.0-NAPI [2.130675] ath9k :02:00.0: setting latency timer to 64 [2.181605] ath: EEPROM regdomain: 0x60 [2.181609] ath: EEPROM indicates we should expect a direct regpair map [2.181615] ath: Country alpha2 being used: 00 [2.181618] ath: Regpair used: 0x60 [2.310336] ieee80211 phy0: Selected rate control algorithm 'ath9k_rate_control' [2.311271] Registered led device: ath9k-phy0 [2.311284] ieee80211 phy0: Atheros AR9285 Rev:2 mem=0xc900110a, irq=17 [2.349670] cfg80211: World regulatory domain updated: [2.349744] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [2.349829] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [2.349944] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi,
Bug#669029: openswan: Implements SAref in debian kernel
Dear kernel team, I do not really consider this a valid request currently as upstream is not actively persuing (at least now) integration of the SARef changes in the main kernel (at least to my knowledge). Either this bug should be closed or reassigned as a minor wishlist bug to openswan which will be reassigned to the kernel again when upstream openswan and upstream kernel get to a decision (just my opinion as openswan debian uploader and openswan upstream commiter). Kind regards Harald Jenny -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692437: installation report
Package: installation-reports Boot method: How did you boot the installer? CD? floppy? network? USB Image version: Full URL to image you downloaded is best http://cdimage.debian.org/cdimage/wheezy_di_beta3/amd64/iso-cd/debian-wheezy-DI-b3-amd64-netinst.iso Date: Date and time of the install Nov 04, 2012 Machine: Description of machine (eg, IBM Thinkpad R32) Assembled Machine with ASUS mother board Processor: AMP Sempron 1GHz Memory: 1GB Partitions: df -Tl will do; the raw partition table is preferred500GB HDD with 160GB partitioned for root / Filesystem Type 1K-blocks Used Available Use% Mounted on rootfs rootfs 163199520 5997792 148911388 4% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs89536 628 88908 1% /run /dev/disk/by-uuid/f496b538-7099-45bc-8cf7-956acdf19ee9 ext4 163199520 5997792 148911388 4% / tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 222420 88222332 1% /run/shm /dev/sda5 fuseblk 46829440 10345948 36483492 23% /media/KRISHNA /dev/sda7 fuseblk 50050472 14111480 35938992 29% /media/KRISHNA_ /dev/sda9 fuseblk 75152036 41163364 33988672 55% /media/KRISHNA__ /dev/sda8 fuseblk 150328204 32220356 118107848 22% /media/KRISHNA___ Output of lspci -knn (or lspci -nn): root@gml:~# lspci -knn 00:00.0 RAM memory [0500]: NVIDIA Corporation MCP61 Memory Controller [10de:03ea] (rev a1) Subsystem: ASUSTeK Computer Inc. Device [1043:8234] 00:01.0 ISA bridge [0601]: NVIDIA Corporation MCP61 LPC Bridge [10de:03e0] (rev a2) Subsystem: ASUSTeK Computer Inc. Device [1043:8234] 00:01.1 SMBus [0c05]: NVIDIA Corporation MCP61 SMBus [10de:03eb] (rev a2) Subsystem: ASUSTeK Computer Inc. Device [1043:8234] Kernel driver in use: nForce2_smbus 00:01.2 RAM memory [0500]: NVIDIA Corporation MCP61 Memory Controller [10de:03f5] (rev a2) Subsystem: ASUSTeK Computer Inc. Device [1043:8234] 00:02.0 USB controller [0c03]: NVIDIA Corporation MCP61 USB 1.1 Controller [10de:03f1] (rev a3) Subsystem: ASUSTeK Computer Inc. Device [1043:8234] Kernel driver in use: ohci_hcd 00:02.1 USB controller [0c03]: NVIDIA Corporation MCP61 USB 2.0 Controller [10de:03f2] (rev a3) Subsystem: ASUSTeK Computer Inc. Device [1043:8234] Kernel driver in use: ehci_hcd 00:04.0 PCI bridge [0604]: NVIDIA Corporation MCP61 PCI bridge [10de:03f3] (rev a1) 00:05.0 Audio device [0403]: NVIDIA Corporation MCP61 High Definition Audio [10de:03f0] (rev a2) Subsystem: ASUSTeK Computer Inc. Device [1043:8290] Kernel driver in use: snd_hda_intel 00:06.0 IDE interface [0101]: NVIDIA Corporation MCP61 IDE [10de:03ec] (rev a2) Subsystem: ASUSTeK Computer Inc. Device [1043:8234] Kernel driver in use: pata_amd 00:07.0 Bridge [0680]: NVIDIA Corporation MCP61 Ethernet [10de:03ef] (rev a2) Subsystem: ASUSTeK Computer Inc. Device [1043:8234] Kernel driver in use: forcedeth 00:08.0 IDE interface [0101]: NVIDIA Corporation MCP61 SATA Controller [10de:03f6] (rev a2) Subsystem: ASUSTeK Computer Inc. Device [1043:8234] Kernel driver in use: sata_nv 00:09.0 PCI bridge [0604]: NVIDIA Corporation MCP61 PCI Express bridge [10de:03e8] (rev a2) Kernel driver in use: pcieport 00:0b.0 PCI bridge [0604]: NVIDIA Corporation MCP61 PCI Express bridge [10de:03e9] (rev a2) Kernel driver in use: pcieport 00:0c.0 PCI bridge [0604]: NVIDIA Corporation MCP61 PCI Express bridge [10de:03e9] (rev a2) Kernel driver in use: pcieport 00:0d.0 VGA compatible controller [0300]: NVIDIA Corporation C61 [GeForce 6150SE nForce 430] [10de:03d0] (rev a2) Subsystem: ASUSTeK Computer Inc. Device [1043:8234] Kernel driver in use: nouveau 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] Kernel driver in use: k8temp Base System Installation
Bug#692327: libotr: Please provide libotr2
On Mon, Nov 05, 2012 at 03:04:21PM +0100, Thibaut VARENE wrote: I thought that Wheezy having been frozen for quite some time, it was okay to upload new packages to unstable again. I'm sure we would've communicated that on d-d-a if this would've been the case. (Also please don't put a before the lines you wrote yourself.) Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#662946: equivs: does not strip subdirectories from files to be installed
I agree with RjY, this is undesired behaviour to not allow full path of source files int the Files: section. What if there are two files with same name in different directories, copying them to the same dir as control file is not possible. Also, it cant parse white space in file names. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692327: libotr: Please provide libotr2
On Tue, Nov 6, 2012 at 10:48 AM, Philipp Kern pk...@debian.org wrote: On Mon, Nov 05, 2012 at 03:04:21PM +0100, Thibaut VARENE wrote: I thought that Wheezy having been frozen for quite some time, it was okay to upload new packages to unstable again. I'm sure we would've communicated that on d-d-a if this would've been the case. Okay then. Wheezy has been frozen for 4 months already. Out of curiosity, how long will we have to wait before new software can be pushed again to Debian? (Also please don't put a before the lines you wrote yourself.) I blame Gmail's silly new interface :-P Best -- Thibaut VARENE http://hacks.slashdirt.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692303: (no subject)
Hello, I'm a co-maintainer for this package and wanted to let you know that the author of searchmonkey has no plans to release searchmonkey 2.0 for Linux at this time. The current version in Debian and Ubuntu is the latest stable available upstream. -- - Benjamin Kerensa http://benjaminkerensa.com I am what I am because of who we all are - Ubuntu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692303: (no subject)
Tags: |wontfix| -- - Benjamin Kerensa http://benjaminkerensa.com I am what I am because of who we all are - Ubuntu
Bug#691237: libassuan0: fixed ASSUAN_LINELENGTH for 4096bit encryption keys (Patch included)
On Tue, 6 Nov 2012 10:24, cor...@debian.org said: For gnupg2 maintainers: this is about an issue with gnupg2 not beeing able to decrypt stuff encrypted for 4096b keys on OpenPGP smartcards. If you look at the back of the cards you will notice a limit of 3072 ;-). To stop people complaining about it I eventually lifted this limit in 2.1.0beta3 (2011-12-20): * Allow generation of card keys up to 4096 bit. I never confirmed that encryption will work. In fact, the major problem we have with keys 2048 ist that some readers (or on Windows their drivers) seem not to work correctly related to the BWT extension request; or due to libusb problems. As it adds a --more argument to one command, but still support the previous usages I guess it shouldn't break other applications. And This changes the API of scdaemon and should thus not be applied without checking back with me. I am working on a similar solution for master but I have currently problems to generate any card key (maybe libusb problem on Sid). I am looking into the latter right now. Stay tuned. Salam-Shalom, 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#638792: libjs-scriptaculous 1.9.0 breaks libjs-protaculous
On Tue, 17 Apr 2012, Frank Habermann wrote: But i think for package libjs-protoaculous the best would be if the files would be created at build time not at install time. So you did not have problems at installation time. MOST DEFINITELY NOT! The reason for this is that, with the current setup, you can install fixed versions of either libraries without needing to rebuild protaculous. Since a locally patched prototype (due to #647596) is currently needed, this should not be changed to build the file during package build time. Thanks, //mirabilos • currently wearing the “FusionForge developer” hat -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692438: RFP: rigsofrods -- An open source vehicle simulator based on soft-body physics
Package: wnpp Severity: wishlist * Package Name: Rigs of Rods * Home page: http://www.rigsofrods.com * License: GPLv3 * Description: An open source vehicle simulator based on soft-body physics
Bug#657986: F10 key not working - not a dup
I exchanged Emails on bug #656685 with Michael Biebl who fixed that. He does not think this is a dup: [...] terminator doesn't use GTK3, so this is a different issue then #656685 afaics. [...] Or apply the same fix for GTK2 that was applied to GTK3, ie. cherry-pick [1] for 2.24.11. Also that bug got fixed and terminator still does not behave correctly. cheers, Florian [1] http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24id=1533e67ae40d938a6ee805eab5581922f4b97459 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594902: vinagre: Please provide vncviewer alternative
On Sun, Sep 05, 2010 at 10:38:08PM +0100, Reuben Thomas wrote: I could email some of them if you like? Did you get anywhere? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692439: tomcat6: CVE-2012-2733 CVE-2012-3439
Package: tomcat6 Severity: grave Tags: security Justification: user security hole Please see http://tomcat.apache.org/security-6.html Since Wheezy is frozen, please apply isolated security fixes and do not update to a new upstream release. BTW, is it really necessary to have both tomcat6 and tomcat7 in Wheezy? Shouldn't tomcat6 be dropped in favour of tomcat7? 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#692440: tomcat7: CVE-2012-2733 CVE-2012-3439
Package: tomcat7 Severity: grave Tags: security Justification: user security hole Please see http://tomcat.apache.org/security-7.html Since Wheezy is frozen, please apply isolated security fixes instead of updating to a new upstream release. 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#692415: [patch] Possible solution
Hi!
I've dug this a bit, and by analogue with footnotes, added unsescaping
of special chars to references - and that worked well. The change is
simple and looks logical, but I don't know, if it will break anything.
--- /usr/share/perl5/Text/MultiMarkdown.pm 2011-04-26 12:27:23.0
+0300
+++ Text/MultiMarkdown.pm 2012-11-06 12:35:28.0 +0200
@@ -1218,6 +1218,7 @@
$reference =~ s/^[ ]{0,$self-{tab_width}}//gm;
$reference = $self-_RunBlockGamut($reference, {wrap_in_p_tags = 0});
+$reference = $self-_UnescapeSpecialChars($reference);
$self-{_references}{$id} = $reference;
}
--
Михайло Даниленко
---
jabber: isb...@unixzone.org.ua
icq:590697790
signature.asc
Description: Digital signature
Bug#692441: libx86-1: 100% CPU usage when running 'vbetool dpms off'
Package: libx86-1 Version: 1.1+ds1-10 Severity: normal Tags: upstream Dear Maintainer, Sometimes when I run 'vbetool dmps off' on my notebook it led to 100% CPU usage by 'vbetool' process I investigate this suttuation by 'gdb', and seems that libx86 can't quit from loop at 'X86EMU_exec()' For some reason it not call 'HALT_SYS' macros. Attached backtrace (gdb -p) (gdb) bt #0 __strcpy_ssse3 () at ../sysdeps/x86_64/multiarch/strcpy.S:97 #1 0x7fee8d8d375c in x86emu_decode_printf (x=0x7fee8d8f5993 \n) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:34 #2 0x7fee8d8e8a94 in x86emuOp_add_byte_RM_R (op1=optimized out) at x86emu/ops.c:137 #3 0x7fee8d8d1779 in X86EMU_exec () at x86emu/decode.c:124 #4 0x7fee8d8d1550 in real_call (registers=0x7fff50b846b0) at thunk.c:217 #5 0x00400e8d in ?? () #6 0x00401299 in ?? () #7 0x7fee8d351ead in __libc_start_main (main=optimized out, argc=optimized out, ubp_av=optimized out, init=optimized out, fini=optimized out, rtld_fini=optimized out, stack_end=0x7fff50b847c8) at libc-start.c:228 #8 0x00400d29 in ?? () #9 0x7fff50b847c8 in ?? () #10 0x001c in ?? () #11 0x0003 in ?? () #12 0x7fff50b84f71 in ?? () #13 0x7fff50b84f79 in ?? () #14 0x7fff50b84f7e in ?? () #15 0x in ?? () I can't find author email, at homepage of this project, so write here. I think that all lastest version of libx86 contain this bug. And also I can't find the solution, how can I fix it. Could you help me to fix this bug? -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.6.5macbook-pro-custom-v0.1 (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 libx86-1 depends on: ii libc6 2.13-35 ii multiarch-support 2.13-35 libx86-1 recommends no packages. libx86-1 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#692442: CVE-2012-5783: Insecure certificate validation
Package: commons-httpclient Severity: important Tags: security Please see Section 7.5 of this paper: http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf This has been assigned CVE-2012-5783. I'm not sure if we can backport more correct certificate validation to 3.x, but independent of that it might make sense to introduce the 4.x codebase to the archive? 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#692443: lynx-cur: CVE-2012-5821
Package: lynx-cur Version: 2.8.7dev9-2.1 Severity: important Tags: security Hi, please see Section 7.4 of this paper: http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf This has been assigned CVE-2012-5821. 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#661471: NMU v2 (was: Re: Bug#661471: bug 661471 gnome-accessibility-themes)
On Wed, Oct 31, 2012 at 5:34 PM, Theppitak Karoonboonyanan t...@debian.org wrote: On Wed, Aug 29, 2012 at 10:35 PM, Theppitak Karoonboonyanan t...@debian.org wrote: On Mon, Aug 13, 2012 at 3:01 PM, Theppitak Karoonboonyanan t...@debian.org wrote: So, I agree with splitting the gnome-accessibility-themes binary. Any progress? If not, I'm proposing another NMU, which: - Splits a11y themes into gnome-accessibility-themes binary - Splits the shared translation files into gnome-themes-standard-common - Makes both theme packages depend on -common - Declares gnome-accessibility-themes and gnome-themes-standard-common as Replaces: the old gnome-themes-standard - Drops Replaces: from gnome-themes-standard Debdiff is attached. However, some warnings are found during the upgrade test: ---8--- Preparing to replace gnome-themes-standard 3.4.2-1 (using gnome-themes-standard_3.4.2-1.1_amd64.deb) ... Unpacking replacement gnome-themes-standard ... dpkg: warning: unable to delete old directory '/usr/share/icons/HighContrast': Directory not empty dpkg: warning: unable to delete old directory '/usr/share/icons/LowContrast': Directory not empty dpkg: warning: unable to delete old directory '/usr/share/icons/HighContrastInverse': Directory not empty ---8--- The remaining files in these directories are icon-theme.cache. Any suggestion on how to clear them properly? It seems this does not happen with clean installs. So, it may not be an issue. Could I do the NMU, then? Uploaded to DELAYED/2. Without response for a long time, I assume it's qualified NMU, despite the intrusive change. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692444: tweepy: CVE-2012-5821
Package: tweepy Severity: important Tags: security Justification: user security hole Please see Section 9 of this paper: http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf 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#656296: Patch for password syncing between LDAP/Kerberos/Samba in Debian Edu
Hi Petter, thanks for your feedback. On Mo 05 Nov 2012 13:16:31 CET Petter Reinholdtsen wrote: [Mike Gabriel] Linux solution: dpkg-divert original password tool and replace by a wrapper that points the user to using http://www/gosa Alternative idea, which work for more use cases, is to use pam_python to implement a password module that reject the password change and ask people to use gosa. This could make sure also GUI tools to change passwords show the message. We already use pam_python for other tasks, so it is no new dependency. So, I will address this then in this way... o no $DISPLAY set - output a line of text to stdout o $DISPLAY set - use kdialog/zenity/pynotify to show a message My vote will be for pynotify as most desktop shells support notifications in squeeze. Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpN8CLBVUZ3l.pgp Description: Digitale PGP-Unterschrift
Bug#692445: _home_packages_gcc_4.7_gcc-4.7-4.7.2_build_* in manpage filenames
Package: libstdc++6-4.7-doc Version: 4.7.2-4 Severity: normal Hi, This package contains many manpages with improper names. All of them are file lists of some source directories, and don't seem to be useful. $ dpkg -L libstdc++6-4.7-doc|grep home /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_backward_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_src_libstdc__-v3_doc_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_bin_search_tree__.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_left_child_next_sibling_heap__.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_bits_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_hash_fn_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_binomial_heap__.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_rb_tree_map__.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_binomial_heap_base__.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_profile_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_tr1_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_eq_fn_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_src_libstdc__-v3_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_list_update_map__.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_pairing_heap__.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_ov_tree_map__.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_trie_policy_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_x86_64-linux-gnu_bits_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_branch_policy_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_splay_tree__.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_parallel_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_decimal_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_debug_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_src_libstdc__-v3_doc_doxygen_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_thin_heap__.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_x86_64-linux-gnu_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_rc_binomial_heap__.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_src_libstdc__-v3_libsupc___.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_binary_heap__.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_tree_policy_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_unordered_iterator_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_cc_hash_table_map__.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.7_gcc-4.7-4.7.2_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_resize_policy_.3cxx.gz
Bug#523834:
Some news about inclusion of Naev in official Debian repositories?
Bug#627141:
Some news about inclusion of ManaPlus in official Debian repositories?
Bug#656296: Patch for password syncing between LDAP/Kerberos/Samba in Debian Edu
[Mike Gabriel] So, I will address this then in this way... o no $DISPLAY set - output a line of text to stdout o $DISPLAY set - use kdialog/zenity/pynotify to show a message That should not be neccessary. There is a callback mechanism in PAM to provide feedback to the user, and I suspect it can be used by passwd and any GUI tool to show the message to the user. See for example how I do it in libpam-mklocaluser, look for conversation in debian/pam-python.py. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692446: _home_packages_gcc_4.6_gcc-4.6-4.6.3_build_ in mapage filenames
Package: libstdc++6-4.6-doc Version: 4.6.3-12 Severity: normal Hi, This package contains many manpages with improper names. All of them are file lists of some source directories, and don't seem to be useful. $ dpkg -L libstdc++6-4.6-doc|grep home /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_build_x86_64-linux-gnu_libstdc__-v3_include_debug_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_src_libstdc__-v3_doc_doxygen_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_detail_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_build_x86_64-linux-gnu_libstdc__-v3_include_ext_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_src_libstdc__-v3_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_src_libstdc__-v3_doc_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_build_x86_64-linux-gnu_libstdc__-v3_include_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_build_x86_64-linux-gnu_libstdc__-v3_include_x86_64-linux-gnu_bits_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_build_x86_64-linux-gnu_libstdc__-v3_include_x86_64-linux-gnu_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_build_x86_64-linux-gnu_libstdc__-v3_include_profile_impl_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_build_x86_64-linux-gnu_libstdc__-v3_include_profile_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_src_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_build_x86_64-linux-gnu_libstdc__-v3_include_backward_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_build_x86_64-linux-gnu_libstdc__-v3_include_bits_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_build_x86_64-linux-gnu_libstdc__-v3_include_decimal_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_build_x86_64-linux-gnu_libstdc__-v3_include_ext_pb_ds_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_build_x86_64-linux-gnu_libstdc__-v3_include_tr1_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_build_x86_64-linux-gnu_libstdc__-v3_include_parallel_.3cxx.gz /usr/share/man/man3/_home_packages_gcc_4.6_gcc-4.6-4.6.3_src_libstdc__-v3_libsupc___.3cxx.gz Regards, GUO Yixuan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691237: libassuan0: fixed ASSUAN_LINELENGTH for 4096bit encryption keys (Patch included)
On mar., 2012-11-06 at 11:21 +0100, Werner Koch wrote: On Tue, 6 Nov 2012 10:24, cor...@debian.org said: For gnupg2 maintainers: this is about an issue with gnupg2 not beeing able to decrypt stuff encrypted for 4096b keys on OpenPGP smartcards. If you look at the back of the cards you will notice a limit of 3072 ;-). Indeed :) To stop people complaining about it I eventually lifted this limit in 2.1.0beta3 (2011-12-20): * Allow generation of card keys up to 4096 bit. And this was also backported in 2.0.18. I never confirmed that encryption will work. In fact, the major problem we have with keys 2048 ist that some readers (or on Windows their drivers) seem not to work correctly related to the BWT extension request; or due to libusb problems. Yeah, and I noticed that we need readers with extended apdu support too. Having a clear view of what the issues are and if they are fixable would help indeed. I have to admit I was really happily surprised when I see how easy it was to make stuff work with the openpgp smartcard (especially considering the pkcs11 world), when using 2048 keys. As it adds a --more argument to one command, but still support the previous usages I guess it shouldn't break other applications. And This changes the API of scdaemon and should thus not be applied without checking back with me. Yes, that's why I added you to CC. I guess it's not an invasive solution, but adding it to Debian if a different fix is committed upstream is a bad idea. I am working on a similar solution for master but I have currently problems to generate any card key (maybe libusb problem on Sid). I am looking into the latter right now. Stay tuned. Hmh, I didn't have any problem generating keys on-card nor moving keys to card on Debian sid. The only thing I needed to check is to use /usr/bin/gpg2 and not /usr/bin/gpg, since /u/b/gpg is unfortunately 1.4.12. Regards, -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690159: Embedded code copies in nikola
On 05/11/12 06:35, W. Martin Borgert wrote: Hi, many thanks for packaging nikola. I just came across this program and it seems to be the modern version of WML :~) However, in the files list http://ftp-master.debian.org/new/nikola_4.0.3-1.html I found embedded code copies, which are frown upon in Debian: - jQuery (instead depend on libjs-jquery) - Bootstrap (instead depend on libjs-twitter-bootstrap) - colorbox (not yet in Debian, please package separately, AFAIK piwigo does use colorbox, too) Also, when packaging minified JS or CSS files, one should not use the minified versions from upstream, but minify them in debian/rules. You need to build-depend e.g. on yui-compressor and use it accordingly. Thanks for considering and - again - for packaging nikola! Thanks for the explanation! :). Your report is so great! I followed your recomendations and upload a new version. You can take a look http://ftp-master.debian.org/new/nikola_4.0.3-2.html Thanks, -- TiN signature.asc Description: OpenPGP digital signature
Bug#692447: bash: Default value parameter expansion works incorrectly with $* and single null pos. paramter
Package: bash
Version: 4.2-4
Severity: normal
Hi.
Default value parameter expansion works differently in dash and bash, and i
believe, that dash's behavior is correct one.
$ bash -c 'set -- ; echo A${*:-w}R;'
AR
$ dash -c 'set -- ; echo A${*:-w}R;'
AwR
Because the colon is present, if parameter ($* in the example) is null, it
should be replaced with word (character 'w' in the example). And parameter is
null indeed:
$ bash -c 'set -- ; echo A${*}R;'
AR
$ dash -c 'set -- ; echo A${*}R;'
AR
but bash still does not replace it with word.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (200, 'unstable'), (100, 'stable-updates'),
(100, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages bash depends on:
ii base-files 6.11
ii dash 0.5.7-3
ii debianutils 4.3.2
ii libc62.13-35
ii libtinfo55.9-10
Versions of packages bash recommends:
ii bash-completion 1:2.0-1
Versions of packages bash suggests:
ii bash-doc 4.2-4
-- 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#692448: qemu: system crash on 'libaio1' removal
Package: qemu Version: 0.12.5+dfsg-3squeeze2 Severity: serious Hi, I've just had a system crash a few seconds after I removed 'libaio1 package (declared orphan by deborphan). On KVM systems this is not a problem because its a dependency of qemu-kvm. But on Xen systems (+libvirtd) this package is useless and 'qemu' is enough. I believe 'qemu' should also depend on 'libaio1'. Another alternative is to add the dependency on 'xen-qemu-dm*' packages. Cheers -- 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-xen-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages qemu depends on: ii qemu-system0.12.5+dfsg-3squeeze2 QEMU full system emulation binarie ii qemu-user 0.12.5+dfsg-3squeeze2 QEMU user mode emulation binaries ii qemu-utils 0.12.5+dfsg-3squeeze2 QEMU utilities qemu recommends no packages. Versions of packages qemu suggests: pn qemu-user-static none (no description available) -- 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#692449: unblock: bliss/0.72-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package bliss
There are two simple fixes (one line in -3 and two lines in -4).
The RCish fix is in 0.72-4. In versions 0.72-2 and 0.72-3, if the user
neglects to define the preprocessor symbol BLISS_USE_GMP when
compiling their code, it will build successfuly but segfault at
runtime. This is fixed in -4. The fix in -3 is needed for this to
work transparently.
bliss is a leaf package in Wheezy, but I've already had bug reports
(on the bugtracker of an upstream project) for -3.
Here is the debdiff, less the changelog stanzas.
diff -u bliss-0.72/debian/Makefile.shlib bliss-0.72/debian/Makefile.shlib
--- bliss-0.72/debian/Makefile.shlib
+++ bliss-0.72/debian/Makefile.shlib
@@ -15,7 +15,7 @@
$(CC) -fPIC -c $(CFLAGS) -o $@ $
libbliss.so: $(GMPSHOBJS)
- $(CC) -shared -Wl,-soname,$(SONAME) -o $(SOFULL) $^
+ $(CC) -shared -Wl,-soname,$(SONAME) $(LIB) -o $(SOFULL) $^
ln -sf $(SOFULL) $(SONAME)
ln -sf $(SOFULL) libbliss.so
only in patch2:
unchanged:
--- bliss-0.72.orig/defs.hh
+++ bliss-0.72/defs.hh
@@ -23,6 +23,8 @@
along with Foobar. If not, see http://www.gnu.org/licenses/.
*/
+#undef BLISS_USE_GMP
+#define BLISS_USE_GMP
namespace bliss {
unblock bliss/0.72-4
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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#692443: lynx-cur: CVE-2012-5821
On Tue, Nov 06, 2012 at 11:57:59AM +0100, Moritz Muehlenhoff wrote: Package: lynx-cur Version: 2.8.7dev9-2.1 The package list for lynx-cur doesn't list that version. It shows 2.8.8dev.5-1 as the lowest version. Severity: important Tags: security Hi, please see Section 7.4 of this paper: http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf This has been assigned CVE-2012-5821. The fix can be easily abstracted from the changes in dev.13 -- Thomas E. Dickey dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#692450: rng-tools: please update to version 4
Package: rng-tools Severity: wishlist Hi, would it be possible to update rng-tools to version 4? This version apparently fixes a lot of issues with the previous versions and brings support for RDRAND instruction. Regards, -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692443: lynx-cur: CVE-2012-5821
On Tue, Nov 06, 2012 at 06:46:50AM -0500, Thomas Dickey wrote: The fix can be easily abstracted from the changes in dev.13 (it is the small change made to WWW/Library/Implementation/HTTP.c, of course). -- Thomas E. Dickey dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#692451: buildbot: New upstream version available: 0.8.7
Package: buildbot Version: 0.8.6p1-1 Severity: normal -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages buildbot depends on: ii adduser 3.113+nmu3 ii dpkg 1.16.9 ii libjs-sphinxdoc 1.1.3+dfsg-4 ii python2.7.3~rc2-1 ii python-jinja2 2.6-1 ii python-migrate0.7.2-3 ii python-sqlalchemy 0.7.8-1 ii python-twisted-core 12.0.0-1 ii python-twisted-web12.0.0-1 ii python-twisted-words 12.0.0-1 ii python2.6 2.6.8-0.2 ii python2.7 2.7.3~rc2-2.1 Versions of packages buildbot recommends: ii buildbot-slave 0.8.6p1-1 ii python-twisted-mail 12.0.0-1 Versions of packages buildbot suggests: ii git [git-core] 1:1.7.10.4-1 ii subversion 1.6.17dfsg-4 -- Configuration Files: /etc/default/buildmaster changed [not included] -- 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#692453: unable to select keyboard layout from gnome-control center
package: gnome-control-center severity: important version: 1:3.6.1-1 I get the following error gnome-control-center libibus-1.0.so.5: cannot open shared object file: No such file or directory Failed to load module: /usr/lib/control-center-1/panels/libregion.so ** (gnome-control-center:4196): WARNING **: Could not find the loadable module for panel 'region' It should update the libidbus dependency to libibus-1.0-5 -- പ്രവീണ് അരിമ്പ്രത്തൊടിയില് You have to keep reminding your government that you don't get your rights from them; you give them permission to rule, only so long as they follow the rules: laws and constitution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692452: RFP: teamd -- Daemon for controlling the team network driver
Package: wnpp Severity: wishlist * Package name: libteam Version : 0.1.1 Upstream Author : Jiri Pirko jpi...@redhat.com * URL : https://github.com/jpirko/libteam * License : LGPL Programming Lang: C, Python Description : Daemon for controlling the team network driver The team driver affords teaming (bonding, load-balancing, failover) of multiple network interfaces. It is a lightweight replacement to the bonding driver. The sources contains the library to control the kernel driver, a daemon, Python bindings, and some example programs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692327: libotr: Please provide libotr2
On Tue, 6 Nov 2012 10:59:42 +0100 Thibaut VARENE vare...@debian.org wrote: On Tue, Nov 6, 2012 at 10:48 AM, Philipp Kern pk...@debian.org wrote: On Mon, Nov 05, 2012 at 03:04:21PM +0100, Thibaut VARENE wrote: I thought that Wheezy having been frozen for quite some time, it was okay to upload new packages to unstable again. I'm sure we would've communicated that on d-d-a if this would've been the case. Okay then. Wheezy has been frozen for 4 months already. Out of curiosity, how long will we have to wait before new software can be pushed again to Debian? If it's targeting experimental, that is already possible and has never been a problem. If it's to target unstable then expect an announcement on d-d-a to the effect that unstable is now open again a few days after the Wheezy release. (Release, not freeze). i.e. around the time that Jessie becomes available as the new testing. Note that from past experience, it's not advisable to upload very soon after the d-d-a announcement anyway. So many other packages get uploaded at that point that many dependencies become uninstallable. Talk to maintainers of packages which your package needs and co-ordinate in advance. If you want it in Debian now, push it into experimental. If you want it Jessie (the next testing), then wait for the d-d-a announcement. If you wanted it in Wheezy it's too late. If you just wanted it in unstable then it's clear that this is not desirable and your only option is experimental. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpWWWFomTCRu.pgp Description: PGP signature
Bug#692448: qemu: system crash on 'libaio1' removal
Control: tags -1 unreproducible moreinfo On 06.11.2012 15:40, Teodor wrote: Package: qemu Version: 0.12.5+dfsg-3squeeze2 Severity: serious Hi, I've just had a system crash a few seconds after I removed 'libaio1 package (declared orphan by deborphan). What kind of crash? Crash of what, exactly? What you were running? None of qemu-system or qemu-user binaries are linked with libaio. libaio1 is not used and hence not needed. Note that qemu package - against which you filed the bugreport - is a meta-package, it does not use any library at all. On KVM systems this is not a problem because its a dependency of qemu-kvm. But on Xen systems (+libvirtd) this package is useless and 'qemu' is enough. Which package is useless? I believe 'qemu' should also depend on 'libaio1'. qemu can be made dependent on libaio1 if it were linked with libaio1. For this, it needs to contain at least one binary, which it does not. Note that library dependencies are automatic in debian -- once a binary is linked with a library, the corresponding dependency is reflected in the package control information, so the only thing necessary to do is to actually _use_ the library. Another alternative is to add the dependency on 'xen-qemu-dm*' packages. xen-qemu-dm* packages are not relevant for qemu. Please describe your issue in a bit more details. Currently what you wrote makes no sense, sorry. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692454: crrcsim: FTBFS with --no-copy-dt-needed-entries
Package: crrcsim Version: 0.9.12-4 Severity: normal Tags: upstream patch User: peter.fritzs...@gmx.de Usertags: no-add-needed crrcsim fails to build with --no-copy-dt-needed-entries linker setting. Logs can be found at https://launchpad.net/ubuntu/+source/crrcsim/0.9.12-4 /usr/bin/g++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro CMakeFiles/crrcsim.dir/src/aircraft.cpp.o CMakeFiles/crrcsim.dir/src/config.cpp.o CMakeFiles/crrcsim.dir/src/crrc_fdm.cpp.o CMakeFiles/crrcsim.dir/src/crrc_keyboard.cpp.o CMakeFiles/crrcsim.dir/src/crrc_loadair.cpp.o CMakeFiles/crrcsim.dir/src/crrc_main.cpp.o CMakeFiles/crrcsim.dir/src/crrc_sound.cpp.o CMakeFiles/crrcsim.dir/src/crrc_soundserver.cpp.o CMakeFiles/crrcsim.dir/src/crrc_system.cpp.o CMakeFiles/crrcsim.dir/src/CTime.cpp.o CMakeFiles/crrcsim.dir/src/global.cpp.o CMakeFiles/crrcsim.dir/src/ImageLoaderTGA.cpp.o CMakeFiles/crrcsim.dir/src/mouse_kbd.cpp.o CMakeFiles/crrcsim.dir/src/record.cpp.o CMakeFiles/crrcsim.dir/src/robots.cpp.o CMakeFiles/crrcsim.dir/src/SimStateHandler.cpp.o CMakeFiles/crrcsim.dir/src/zoom.cpp.o -o crrcsim -rdynamic src/GUI/libGUI.a src/mod_cntrl/libmod_cntrl.a src/mod_env/libmod_env.a sr c/mod_fdm/libmod_fdm.a src/mod_inputdev/libmod_inputdev.a src/mod_video/libmod_video.a src/mod_landscape/libmod_landscape.a src/mod_main/libmod_main.a src/mod_math/libmod_math.a src/mod_misc/libmod_misc.a src/mod_mode/libmod_mode.a src/mod_robots/libmod_robots.a src/mod_windfield/libmod_windfield.a src/mod_chardevice/libmod_chardevice.a -Wl,-Bstatic -lSDLmain -Wl,-Bdynamic -lSDL -lpthread -lGL -lGLU -lportaudio -lCGAL -ljpeg -lplibssg -lplibsg -lplibpuaux -lplibpu -lplibul -lplibfnt -lboost_thread-mt -lpthread src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `~Gmpq_rep': /usr/include/CGAL/GMP/Gmpq_type.h:52: undefined reference to `__gmpq_clear' src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `Gmpq_rep': /usr/include/CGAL/GMP/Gmpq_type.h:51: undefined reference to `__gmpq_init' src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `CGAL::Gmpq::operator+=(CGAL::Gmpq const)': /usr/include/CGAL/GMP/Gmpq_type.h:277: undefined reference to `__gmpq_add' src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `~Gmpq_rep': /usr/include/CGAL/GMP/Gmpq_type.h:52: undefined reference to `__gmpq_clear' src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `Gmpq_rep': /usr/include/CGAL/GMP/Gmpq_type.h:51: undefined reference to `__gmpq_init' src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `CGAL::Gmpq::operator-=(CGAL::Gmpq const)': /usr/include/CGAL/GMP/Gmpq_type.h:287: undefined reference to `__gmpq_sub' src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `~Gmpq_rep': /usr/include/CGAL/GMP/Gmpq_type.h:52: undefined reference to `__gmpq_clear' src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `Gmpq_rep': /usr/include/CGAL/GMP/Gmpq_type.h:51: undefined reference to `__gmpq_init' src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `CGAL::Gmpq::operator*=(CGAL::Gmpq const)': /usr/include/CGAL/GMP/Gmpq_type.h:297: undefined reference to `__gmpq_mul' src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `~Gmpq_rep': /usr/include/CGAL/GMP/Gmpq_type.h:52: undefined reference to `__gmpq_clear' /usr/include/CGAL/GMP/Gmpq_type.h:52: undefined reference to `__gmpq_clear' src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `Gmpq_rep': /usr/include/CGAL/GMP/Gmpq_type.h:51: undefined reference to `__gmpq_init' src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `CGAL::Gmpq::Gmpq(double)': /usr/include/CGAL/GMP/Gmpq_type.h:133: undefined reference to `__gmpq_set_d' src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `~Gmpq_rep': /usr/include/CGAL/GMP/Gmpq_type.h:52: undefined reference to `__gmpq_clear' /usr/include/CGAL/GMP/Gmpq_type.h:52: undefined reference to `__gmpq_clear' /usr/include/CGAL/GMP/Gmpq_type.h:52: undefined reference to `__gmpq_clear' /usr/include/CGAL/GMP/Gmpq_type.h:52: undefined reference to `__gmpq_clear' src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `CGAL::Gmpq::operator(CGAL::Gmpq const) const': /usr/include/CGAL/GMP/Gmpq_type.h:195: undefined reference to `__gmpq_cmp' /usr/include/CGAL/GMP/Gmpq_type.h:195: undefined reference to `__gmpq_cmp' src/mod_landscape/libmod_landscape.a(winddata3D.cpp.o): In function `~Gmpq_rep': /usr/include/CGAL/GMP/Gmpq_type.h:52: undefined reference to `__gmpq_clear' /usr/include/CGAL/GMP/Gmpq_type.h:52: undefined reference to `__gmpq_clear' /usr/include/CGAL/GMP/Gmpq_type.h:52: undefined reference to `__gmpq_clear' /usr/include/CGAL/GMP/Gmpq_type.h:52: undefined reference to `__gmpq_clear' /usr/include/CGAL/GMP/Gmpq_type.h:52: undefined reference to `__gmpq_clear'
Bug#656153: jspwiki does depend on tomcat6
Control: notfound -1 2.8.0-5 Control: fixed -1 2.8.0-5 Control: close -1 On Tuesday, 10. July 2012 05:38:06 tony mancill wrote: In looking into this, I was confused to discover that the latest version of jspwiki 2.8.0-5 uploaded to unstable actually does depend on tomcat6, but didn't close #656153 in the changelog. (This is certainly my So let's close this bug properly. The found in -5 seems to be spurious, I cannot reproduce it. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692424: [Pkg-ime-devel] Bug#692424: ibus: Merge fixes from Ubuntu
Hi Jeremy, I have gone over your patch and there is a problem in it: -Recommends: ibus-gtk3, ibus-gtk, ibus-qt4, ibus-clutter, im-config | im-switch +Recommends: ibus-gtk3 | ibus-qt4 | ibus-clutter, ibus-gtk | ibus-qt4 | ibus-clutter, im-config | im-switch Actually the original one is intentional to be like that, you may downgrade ibus-clutter to Suggests, but we need to have all the three other IM Modules in Recommends because: 1. There is no facility assisting users to install needed component when his/her environment changes, e.g. when a Ubuntu user installs some Qt4 application, there isn't a way to notify his/her about installing ibus-qt4. 2. Distribution maker should be able to choose what package they want to ship in ISO, by not enabling Recommends during the generation. 3. Disk space is cheap. 4. im-config requires both Gtk2 and Gtk3 IM Modules to be installed before really setting GTK_IM_MODULE=ibus, otherwise it uses xim for this variable. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692455: jspwiki: modifies conffiles (policy 10.7.3): /etc/jspwiki/jspwiki.properties
Package: jspwiki Version: 2.8.0-5 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package modifies conffiles. This is forbidden by the policy, see http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files 10.7.3: [...] The easy way to achieve this behavior is to make the configuration file a conffile. [...] This implies that the default version will be part of the package distribution, and must not be modified by the maintainer scripts during installation (or at any other time). Note that once a package ships a modified version of that conffile, dpkg will prompt the user for an action how to handle the upgrade of this modified conffile (that was not modified by the user). Further in 10.7.3: [...] must not ask unnecessary questions (particularly during upgrades) [...] If a configuration file is customized by a maintainer script after having asked some debconf questions, it may not be marked as a conffile. Instead a template could be installed in /usr/share and used by the postinst script to fill in the custom values and create (or update) the configuration file (preserving any user modifications!). This file must be removed during postrm purge. ucf(1) may help with these tasks. See also http://wiki.debian.org/DpkgConffileHandling In https://lists.debian.org/debian-devel/2012/09/msg00412.html and followups it has been agreed that these bugs are to be filed with severity serious. debsums reports modification of the following files, from the attached log (scroll to the bottom...): /etc/jspwiki/jspwiki.properties cheers, Andreas jspwiki_2.8.0-5.log.gz Description: GNU Zip compressed data
Bug#622886: Dowloading of Description of updates fails... with HTTP error 404
Package: update-manager-core Version: 0.200.5-1 Severity: minor 1- From Important security updates fails, but from Distribution updates work ok. 2- With debug option (# update-manager -d), when appears an Important security update, I select it and ... [ DEBUG:UpdateManager.Frontend.Gtk.ui] Changelog not in cache, need to download (libproxy). [ DEBUG:UpdateManager.DistSpecific.changelog] Fetching changelog entry for libproxy0. [ DEBUG:UpdateManager.DistSpecific.changelog] Getting changelog URL for package PackageInfo: libproxy0 [ DEBUG:UpdateManager.DistSpecific.Debian.changelog] Downloading changelog for libproxy from http://packages.debian.org/changelogs/pool/updates/main/libp/libproxy/libproxy_0.3.1-2+squeeze1/changelog.txt. [ DEBUG:UpdateManager.DistSpecific.changelog] Fetching http://packages.debian.org/changelogs/pool/updates/main/libp/libproxy/libproxy_0.3.1-2+squeeze1/changelog.txt... [ ERROR:UpdateManager.DistSpecific.changelog] Fetching the changelog entry via HTTP failed: HTTP Error 404: Not Found /usr/lib/pymodules/python2.6/UpdateManager/DistSpecific/changelog.py:108: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 self._handler.changelog_failure(self._pkg_info, exc.message) Here is the error: the url where to retrieve changes don't exist, because after folder “pool” don't exist updates, only contrib, main or non-free: http://packages.debian.org/changelogs/pool/updates/main/libp/libproxy/libproxy_0.3.1-2+squeeze1/changelog.txt ^^^ In folder “main”, there is something similar, but don't have the expected libproxy_0.3.1-2+squeeze1/changelog.txt: http://packages.debian.org/changelogs/pool/main/libp/libproxy/libproxy_0.3.1-2/changelog.txt ... but I don't know how to repair it. (I'm sorry if some words are bad in English: please, correct it by me and delete this line) Thanks. -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages update-manager-core depends on: ii lsb-release 3.2-23.2squeeze1 Linux Standard Base version report ii python 2.6.6-3+squeeze7 interactive high-level object-orie ii python-apt 0.7.100.1+squeeze1 Python interface to libapt-pkg ii python-support 1.0.10 automated rebuilding support for P Versions of packages update-manager-core recommends: ii update-manager-gnome 0.200.5-1 GNOME application that manages sof update-manager-core 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#684329: fixed upstream
Hi! Just FYI, this bug was fixed in 0.9.4. -Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692456: libxml2: Schema validation problem with [0-9]{0,n}|TEXT
Package: libxml2
Version: 2.8.0+dfsg1-6
Severity: important
Dear Maintainer,
Hi!
I have had problems with schema validation pattern [0-9]{0,n}|TEXT.
I run the code below and you can see in output validation isn't work in cases
0, 1 and 2, but in cases 3 and 4 woks fine.
Why? What's wrong? In my mind, the patterns are same case.
Thanks,
Junior Polegato
-- Output --
0. [0-9]{0,4}|TEXT
0.0. = valid: True
0.1. 123 = valid: True
0.2. 12345 = valid: False
0.3. TEXT = valid: False
0.4. TEST = valid: False
1. TEXT|[0-9]{0,4}
1.0. = valid: False
1.1. 123 = valid: True
1.2. 12345 = valid: False
1.3. TEXT = valid: True
1.4. TEST = valid: False
2. [0-9]{0,4}|TEXT|
2.0. = valid: True
2.1. 123 = valid: True
2.2. 12345 = valid: False
2.3. TEXT = valid: False
2.4. TEST = valid: False
3. [0-9]{0,4}|TEXT|1234
3.0. = valid: True
3.1. 123 = valid: True
3.2. 12345 = valid: False
3.3. TEXT = valid: True
3.4. TEST = valid: False
4. TEXT|[0-9]{0,4}|
4.0. = valid: True
4.1. 123 = valid: True
4.2. 12345 = valid: False
4.3. TEXT = valid: True
4.4. TEST = valid: False
-- Code --
#include string.h
#include libxml/parser.h
#include libxml/xmlschemas.h
// gcc -Wall `xml2-config --cflags --libs` -o v v.c ./v
#define DEBUG 0
void Validity(void * ctx, const char *fmt, ...) {
va_list ap;
va_start(ap, fmt);
char *msg;
msg = va_arg(ap, char*);
while ((int)msg != -1) {
printf(fmt, msg);
msg = va_arg(ap, char*);
}
va_end(ap);
}
void NoValidity(void * ctx, const char *fmt, ...){}
void djosStructuredErrorFunc(void * userData, xmlErrorPtr error)
{
printf(\n);
printf(domain : %i\n, error-domain );
printf(code: %i\n, error-code);
printf(message : %s\n, error-message );
printf(level : %i\n, error-level );
printf(file: %s\n, error-file);
printf(line: %i\n, error-line);
printf(str1: %s\n, error-str1);
printf(str2: %s\n, error-str2);
printf(str3: %s\n, error-str3);
printf(int1: %i\n, error-int1);
printf(int2: %i\n, error-int2);
printf(ctxt: %p\n, error-ctxt);
printf(node: %p\n, error-node);
printf(\n);
}
int is_valid(const char *xml, const char *schema_xml)
{
xmlDocPtr schema_doc = xmlReadMemory(schema_xml, strlen(schema_xml), NULL,
NULL, XML_PARSE_NONET);
if (schema_doc == NULL) {
/* the schema cannot be loaded or is not well-formed */
return -1;
}
xmlDocPtr doc = xmlReadMemory(xml, strlen(xml), NULL, NULL, 0);
if (doc == NULL) {
/* the schema cannot be loaded or is not well-formed */
return -1;
}
xmlSchemaParserCtxtPtr parser_ctxt = xmlSchemaNewDocParserCtxt(schema_doc);
if (parser_ctxt == NULL) {
/* unable to create a parser context for the schema */
xmlFreeDoc(schema_doc);
xmlFreeDoc(doc);
return -2;
}
xmlSchemaPtr schema = xmlSchemaParse(parser_ctxt);
if (schema == NULL) {
/* the schema itself is not valid */
xmlSchemaFreeParserCtxt(parser_ctxt);
xmlFreeDoc(schema_doc);
xmlFreeDoc(doc);
return -3;
}
xmlSchemaValidCtxtPtr valid_ctxt = xmlSchemaNewValidCtxt(schema);
if (valid_ctxt == NULL) {
/* unable to create a validation context for the schema */
xmlSchemaFree(schema);
xmlSchemaFreeParserCtxt(parser_ctxt);
xmlFreeDoc(schema_doc);
xmlFreeDoc(doc);
return -4;
}
if (DEBUG == 0)
xmlSchemaSetValidErrors(valid_ctxt, NoValidity, NoValidity, NULL);
else if (DEBUG == 1)
xmlSchemaSetValidErrors(valid_ctxt, Validity, Validity, NULL);
else if (DEBUG == 2){
xmlSchemaSetValidErrors(valid_ctxt, NoValidity, NoValidity, NULL);
xmlSchemaSetValidStructuredErrors(valid_ctxt, djosStructuredErrorFunc,
parser_ctxt);
}
int is_valid = (xmlSchemaValidateDoc(valid_ctxt, doc) == 0);
xmlSchemaFreeValidCtxt(valid_ctxt);
xmlSchemaFree(schema);
xmlSchemaFreeParserCtxt(parser_ctxt);
xmlFreeDoc(schema_doc);
xmlFreeDoc(doc);
/* force the return value to be non-negative on success */
return is_valid ? 1 : 0;
}
int main(int argc, char* argv[]){
int i, j;
const char patterns[5][30] = {[0-9]{0,4}|TEXT, TEXT|[0-9]{0,4},
[0-9]{0,4}|TEXT|, [0-9]{0,4}|TEXT|1234, TEXT|[0-9]{0,4}|};
const char texts[5][10] = {, 123, 12345, TEXT, TEST};
const char bool[2][6] = {False, True};
char xml[100];
char schema_xml[1024];
for (i=0; i 5; i++){
strcpy(schema_xml, ?xml version=\1.0\ encoding=\UTF-8\?
xs:schema
xmlns:xs=\http://www.w3.org/2001/XMLSchema\;
xs:simpleType name=\TTest\
xs:restriction base=\xs:string\
Bug#692457: xfce4: Does not close down properly then xfwm4 does not run on restart
Package: xfce4 Version: 4.8.0.3 Severity: normal Tags: upstream Often when I close down there is a delay of about a minute before the system starts to close down. This happens even if all applications on the desktop have been closed beforehand. The next time I start up after this happens xfwm4 does not run and has to be started manually. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.39-20110627 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xfce4 depends on: ii gtk2-engines-xfce 2.8.1-3 ii orage 4.8.3-2 ii thunar 1.2.3-4+b1 ii xfce4-appfinder4.8.0-3 ii xfce4-mixer4.8.0-3+b1 ii xfce4-panel4.8.6-4 ii xfce4-session 4.8.3-2+b1 ii xfce4-settings 4.8.3-2 ii xfce4-utils4.8.3-2 ii xfconf 4.8.1-1 ii xfdesktop4 4.8.3-2 ii xfwm4 4.8.3-2 Versions of packages xfce4 recommends: pn desktop-base none ii tango-icon-theme 0.8.90-5 ii thunar-volman 0.6.1-1 pn xfce4-notifyd none pn xorg none Versions of packages xfce4 suggests: pn xfce4-goodies none pn xfprint4 none -- 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#594902: vinagre: Please provide vncviewer alternative
On 6 November 2012 10:32, Jon Dowland j...@debian.org wrote: On Sun, Sep 05, 2010 at 10:38:08PM +0100, Reuben Thomas wrote: I could email some of them if you like? Did you get anywhere? Looking at my archive, we had a thread of about a dozen messages in which the last message I have is one from me in October 2010 identifying a common subset of options which should probably be supported. -- http://rrt.sc3d.org
Bug#684553: Patch available
I've made a patch today to address the issue with loading lens information. Haven't tested it thoroughly yet, but looks good at the first glance. For Udi: Please refer to: sourceforge bug http://sourceforge.net/tracker/?func=detailaid=3559274group_id=127649atid=709086 debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684553 -- Best regards, Renat Sabitov lensfun_restore Description: Binary data
Bug#692458: debian installer hangs when entering user name in non-latin languages
package: debian-installer version: 20120930+b1 debian installer should check if user name is in latin and if not should prompt user to select a latin name. To test, chose a non latin language for installation and enter user name in non-latin language. -- പ്രവീണ് അരിമ്പ്രത്തൊടിയില് You have to keep reminding your government that you don't get your rights from them; you give them permission to rule, only so long as they follow the rules: laws and constitution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692459: debian installer should show a keyboard layout indicator in text fields
package: debian-installer version: 20120930+b1 severity: wishlist There should be a visible indication of current keyboard layout selected. Especially when a non-latin language is selected as installation language and first text field is a password field - there is no way to know which keyboard you actually have. Thanks Praveen -- പ്രവീണ് അരിമ്പ്രത്തൊടിയില് You have to keep reminding your government that you don't get your rights from them; you give them permission to rule, only so long as they follow the rules: laws and constitution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661471: NMU v2 (was: Re: Bug#661471: bug 661471 gnome-accessibility-themes)
On 06.11.2012 12:05, Theppitak Karoonboonyanan wrote: On Wed, Oct 31, 2012 at 5:34 PM, Theppitak Karoonboonyanan t...@debian.org wrote: On Wed, Aug 29, 2012 at 10:35 PM, Theppitak Karoonboonyanan t...@debian.org wrote: On Mon, Aug 13, 2012 at 3:01 PM, Theppitak Karoonboonyanan t...@debian.org wrote: So, I agree with splitting the gnome-accessibility-themes binary. Any progress? If not, I'm proposing another NMU, which: - Splits a11y themes into gnome-accessibility-themes binary - Splits the shared translation files into gnome-themes-standard-common - Makes both theme packages depend on -common - Declares gnome-accessibility-themes and gnome-themes-standard-common as Replaces: the old gnome-themes-standard - Drops Replaces: from gnome-themes-standard Debdiff is attached. However, some warnings are found during the upgrade test: ---8--- Preparing to replace gnome-themes-standard 3.4.2-1 (using gnome-themes-standard_3.4.2-1.1_amd64.deb) ... Unpacking replacement gnome-themes-standard ... dpkg: warning: unable to delete old directory '/usr/share/icons/HighContrast': Directory not empty dpkg: warning: unable to delete old directory '/usr/share/icons/LowContrast': Directory not empty dpkg: warning: unable to delete old directory '/usr/share/icons/HighContrastInverse': Directory not empty ---8--- The remaining files in these directories are icon-theme.cache. Any suggestion on how to clear them properly? It seems this does not happen with clean installs. So, it may not be an issue. Could I do the NMU, then? Uploaded to DELAYED/2. Without response for a long time, I assume it's qualified NMU, despite the intrusive change. The gnome-themes-standard-common binary package is superfluous. Afaics the gettext translations are only required to translate the index.theme and background.xml files where the translations are directly embedded, so you don't actually need to install the .mo files. I would thus suggest to simply drop gnome-themes-standard-common. Please also make gnome-theme-standard depend on gnome-accessibility-themes. Also, gnome-accessibility-themes needs a Breaks along with the Replaces. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#692448: qemu: system crash on 'libaio1' removal
2012/11/6 Michael Tokarev m...@tls.msk.ru: On 06.11.2012 15:40, Teodor wrote: I've just had a system crash a few seconds after I removed 'libaio1 package (declared orphan by deborphan). What kind of crash? Crash of what, exactly? What you were running? Debian Linux 6.0 (amd64) on top of Xen 4.0 hypervisor. reboot system boot 2.6.32-5-xen-amd Tue Nov 6 02:59 - 05:01 (02:02) root pts/2vpn-120.DOMAIN Tue Nov 6 02:27 - crash (00:32) None of qemu-system or qemu-user binaries are linked with libaio. libaio1 is not used and hence not needed. Note that qemu package - against which you filed the bugreport - is a meta-package, it does not use any library at all. # aptitude why qemu i xen-qemu-dm-4.0 Depends qemu-system | qemu # aptitude why libaio1 i libvirt-bin Recommends qemu-kvm | qemu (= 0.9.1) p qemu-kvmDependslibaio1 Maybe qemu is not the right package, then which is the right pkg? On KVM systems this is not a problem because its a dependency of qemu-kvm. But on Xen systems (+libvirtd) this package is useless and 'qemu' is enough. Which package is useless? qemu-kvm is useless on a Xen hypervisor. xen-qemu-dm* packages are not relevant for qemu. Please describe your issue in a bit more details. Currently what you wrote makes no sense, sorry. Do you need more info? Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692460: TIFFAppendToStrip: Maximum TIFF file size exceeded
Package: libtiff-tools Version: 4.0.2-4 Severity: important I believe there an issue with tiff2rgba, for some reason it does not seems to be able to deal with BigTIFF as should. Eg: $ tiff2rgba -c none -n bigtiff.tif bigtiff3.tif TIFFAppendToStrip: Maximum TIFF file size exceeded. TIFFAppendToStrip: Maximum TIFF file size exceeded. TIFFAppendToStrip: Maximum TIFF file size exceeded. where: $ tiffinfo bigtiff.tif TIFF Directory at offset 0x2367dba90 (9504144016) Image Width: 78000 Image Length: 30462 Resolution: 10, 10 pixels/cm Bits/Sample: 8 Compression Scheme: None Photometric Interpretation: RGB color Extra Samples: 1assoc-alpha Orientation: row 0 top, col 0 lhs Samples/Pixel: 4 Rows/Strip: 16 Planar Configuration: single image plane However it should always be possible to reduce an RGBA uncompressed TIFF into RGB uncompressed TIFF. What looks suspicious is this: $ tiff2rgba -n bigtiff.tif bigtiff2.tif $ tiffdump bigtiff2.tif bigtiff2.tif: Magic: 0x4949 little-endian Version: 0x2a ClassicTIFF ... while input is: $ tiffdump bigtiff.tif bigtiff.tif: Magic: 0x4949 little-endian Version: 0x2b BigTIFF My guess is that tiff2rgba try hard to write out ClassicTIFF when BigTIFF is required. -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-0.bpo.3-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 libtiff-tools depends on: ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libjpeg62 6b1-1The Independent JPEG Group's JPEG ii libtiff43.9.4-5+squeeze5 Tag Image File Format (TIFF) libra ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime libtiff-tools recommends no packages. Versions of packages libtiff-tools suggests: pn libtiff-openglnone (no description available) -- 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#661471: NMU v2 (was: Re: Bug#661471: bug 661471 gnome-accessibility-themes)
On Tue, Nov 6, 2012 at 7:53 PM, Michael Biebl bi...@debian.org wrote: The gnome-themes-standard-common binary package is superfluous. Afaics the gettext translations are only required to translate the index.theme and background.xml files where the translations are directly embedded, so you don't actually need to install the .mo files. I would thus suggest to simply drop gnome-themes-standard-common. I had also found it out before seeing your message. So, I've cancelled the NMU. Anyway, I also stumbled upon this lintian info: I: gnome-themes-standard: arch-dep-package-has-big-usr-share 3549kB 99% That made me plan to move the non-engine parts into -common instead. What do you think? Please also make gnome-theme-standard depend on gnome-accessibility-themes. OK. I didn't think normal users want those a11y themes, so I hadn't added the dependency. Will do it now as you suggest, anyway. Also, gnome-accessibility-themes needs a Breaks along with the Replaces. OK. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692448: qemu: system crash on 'libaio1' removal
On 06.11.2012 17:02, Teodor MICU wrote: 2012/11/6 Michael Tokarev m...@tls.msk.ru: On 06.11.2012 15:40, Teodor wrote: I've just had a system crash a few seconds after I removed 'libaio1 package (declared orphan by deborphan). What kind of crash? Crash of what, exactly? What you were running? Debian Linux 6.0 (amd64) on top of Xen 4.0 hypervisor. reboot system boot 2.6.32-5-xen-amd Tue Nov 6 02:59 - 05:01 (02:02) root pts/2vpn-120.DOMAIN Tue Nov 6 02:27 - crash (00:32) So, can you start it again when libaio1 is NOT installed? Note that after you remove a library - any library - applications linked against it will continue running just fine. You wont be able to start new applications linked to this library, -- that's for sure, but already running will continue, since the library will still be in memory and on disk (but deleted). None of qemu-system or qemu-user binaries are linked with libaio. libaio1 is not used and hence not needed. Note that qemu package - against which you filed the bugreport - is a meta-package, it does not use any library at all. # aptitude why qemu i xen-qemu-dm-4.0 Depends qemu-system | qemu qemu depends on qemu-system. I don't know what xen-qemu-dm-4.0 uses for its qemu component. I think it too comes with integrated qemu, just another variant of it (like qemu-kvm is yet another variant). # aptitude why libaio1 i libvirt-bin Recommends qemu-kvm | qemu (= 0.9.1) p qemu-kvmDependslibaio1 So libaio1 is used only by qemu-kvm (correctly), not by any other installed packages. Which is exactly what I tried to say initially. Maybe qemu is not the right package, then which is the right pkg? I dunno - in particular, I don't know how xen uses qemu and if it uses its own copy or not. I can _guess_ this dependency is only for some support files, not for qemu-system binaries, but that's just a guess. On KVM systems this is not a problem because its a dependency of qemu-kvm. But on Xen systems (+libvirtd) this package is useless and 'qemu' is enough. Which package is useless? qemu-kvm is useless on a Xen hypervisor. Ah ok. I guess qemu-system is also useless, if not some support files included in there. xen-qemu-dm* packages are not relevant for qemu. Please describe your issue in a bit more details. Currently what you wrote makes no sense, sorry. Do you need more info? I don't see any issue so far. Especially since you're having issue with xen which - most likely - does not use separate qemu package at all. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689790: msva-perl: modifies conffiles during upgrade from squeeze (policy 10.7.3): /etc/X11/Xsession.d/70monkeysphere_use-validation-agent
Control: notfound -1 0.8-2 Control: notfound -1 0.9.1-1 Control: close -1 On 2012-10-07 01:41, Daniel Kahn Gillmor wrote: On 10/06/2012 06:09 PM, Andreas Beckmann wrote: [ ... incredible debugging saga snipped ... ] going to look into dpkg :-) ... and suggesting a one-line fix :-) wow. thanks! I'll keep an eye on this. if you have any suggestions for things you think i should improve, please let me know. much appreciation for tracking this down. no longer reproducible after the fixed dpkg has reached testing Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692327: libotr: Please provide libotr2
On Tue, Nov 6, 2012 at 1:04 PM, Neil Williams codeh...@debian.org wrote: On Tue, 6 Nov 2012 10:59:42 +0100 Thibaut VARENE vare...@debian.org wrote: On Tue, Nov 6, 2012 at 10:48 AM, Philipp Kern pk...@debian.org wrote: On Mon, Nov 05, 2012 at 03:04:21PM +0100, Thibaut VARENE wrote: I thought that Wheezy having been frozen for quite some time, it was okay to upload new packages to unstable again. I'm sure we would've communicated that on d-d-a if this would've been the case. Okay then. Wheezy has been frozen for 4 months already. Out of curiosity, how long will we have to wait before new software can be pushed again to Debian? If it's targeting experimental, that is already possible and has never been a problem. If it's to target unstable then expect an announcement on d-d-a to the effect that unstable is now open again a few days after the Wheezy release. (Release, not freeze). i.e. around the time that Jessie becomes available as the new testing. Note that from past experience, it's not advisable to upload very soon after the d-d-a announcement anyway. So many other packages get uploaded at that point that many dependencies become uninstallable. Talk to maintainers of packages which your package needs and co-ordinate in advance. If you want it in Debian now, push it into experimental. If you want it Jessie (the next testing), then wait for the d-d-a announcement. If you wanted it in Wheezy it's too late. If you just wanted it in unstable then it's clear that this is not desirable and your only option is experimental. Noted. The package was in experimental for several weeks and got zero attention. My general understanding is that nobody looks at experimental anyway. Another part of the issue was upstream's will to have it in Ubuntu as soon as possible. Ubuntu autosync doesn't fetch from experimental. -- Thibaut VARENE http://hacks.slashdirt.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692414: [Pkg-utopia-maintainers] Bug#692414: network-manager: /etc/init.d/network-manager stop leaves wpa_supplicant behind
Heya, On 05.11.2012 23:27, Cyril Brulebois wrote: “/etc/init.d/network-manager stop” indeed drop all networking, but the wpa_supplicant instance it spawned is left behind. Not a practical issue when e.g. switching to wicd, but still not nice. | root 7820 0.0 0.0 31212 3156 ?S23:18 0:00 /sbin/wpa_supplicant -u -s -O /var/run/wpa_supplicant The good news is that one gets reused (there's no second one started) when network-manager is started again. See #692413 for the other way around. The case for wicd (#692413) is not quite comparable. wicd explicitly starts an own wpasupplicant instance with a (temporay) config file and controls that instance. That instance is not usable by e.g. NM so wicd needs to make sure to correctly terminate that service. With NM it is different as it simply uses the wpa_supplicant D-Bus interface and relies on D-Bus activation to start the service on-demand. It controls wpa_supplicant via D-Bus and not a temporary config file. So when NM is stopped, the wpa_supplicant service is still usable by other services. NM also makes use of other D-Bus (activated) services, like polkitd or modem-manager. Stopping those in the sysv init script is not safe as you don't know if those service were actually started by you or if not another application has requested that D-Bus service. Ideally, wicd would just use D-Bus interface of wpa_supplicant to control the service. This way it could simply use the already running wpa_supplicant instance when NM is stopped and wicd started. In contrast to that: NM can use dnsmasq to handle name resolution. For that it explicitly starts an own instance of dnsmasq which it controls via a temporary config file. When NM is stopped it automatically terminates that service. So in summary: I think the current behaviour of NM is not actually buggy wrt D-Bus activated services. Cheers, 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
Bug#692460: -8 is not documented
severity 692460 minor thanks Hum, looks like I spoke too fast. The -undocumented- solution was simply to pass -8 to the command line. r: http://www.remotesensing.org/libtiff/v4.0.0.html For instance, you can use the -8 option on tiffcp to have tiffcp produce BigTIFF files instead of the default ClassicTIFF. Thx -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692414: [Pkg-utopia-maintainers] Bug#692414: network-manager: /etc/init.d/network-manager stop leaves wpa_supplicant behind
Heya, Michael Biebl bi...@debian.org (06/11/2012): So in summary: I think the current behaviour of NM is not actually buggy wrt D-Bus activated services. in which case, feel free to close this bug report; I didn't have any specific knowledge in this area, but I wanted to make sure this behaviour was known/reported (since that's what I did in the wicd case). Mraw, KiBi. signature.asc Description: Digital signature
Bug#692414: [Pkg-utopia-maintainers] Bug#692414: network-manager: /etc/init.d/network-manager stop leaves wpa_supplicant behind
On 06.11.2012 14:10, Michael Biebl wrote: So in summary: I think the current behaviour of NM is not actually buggy wrt D-Bus activated services. A few further remarks: When NM is stopped, it properly deconfigures the wireless interface in wpa_supplicant. So if you later on use wicd or ifupdown, you should be able to start another wpa_supplicant instance. The D-Bus activated one should just do nothing. I tried this: # /etc/init.d/network-manager stop # ps aux | grep wpa_supplicant root 1372 0.0 0.0 31224 3096 ?Ss Nov05 0:00 /sbin/wpa_supplicant -u -s -O /var/run/wpa_supplicant # setup /e/n/i # ifup wlan0 # ps aux | grep wpa_supplicant root 1372 0.0 0.0 31224 3096 ?Ss Nov05 0:00 /sbin/wpa_supplicant -u -s -O /var/run/wpa_supplicant root 21574 0.0 0.0 39632 1456 ?Ss 14:26 0:00 /sbin/wpa_supplicant -s -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0 -W -D nl80211,wext -c /etc/wpa_supplicant/wpa_supplicant.conf Seems to work fine. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#692461: unblock radsecproxy/1.6.2-1
Package: release.debian.org
Severity: normal
Hi,
Please unblock radsecproxy 1.6.2-1. It's a security upload, complementing
1.4-1+squeeze1 and fixing two CVEs. Security team is aware and has reviewed the
upstream fixes for those -- in fact, the second vulnerability was found by
Raphael during the review.
radsecproxy (1.6.2-1) unstable; urgency=high
* Urgency set to high for a security release.
* New upstream release, fixing two security issues:
- When verifying clients, don't consider config blocks with CA settings
('tls') which differ from the one used for verifying the certificate
chain (RADSECPROXY-43, CVE-2012-4523). Reported by Ralf Paffrath.
- Fix the issue with verification of clients when using multiple 'tls'
config blocks for DTLS too (RADSECPROXY-43, CVE-2012-4566). Reported by
Raphael Geissert.
* Drop most of debian/patches/fix_manpages, merged upstream.
Here's the annotated diffstat between 1.6-1 and 1.6.2-1, excluding
configure.ac, config.{guess,sub} and (already-applied, source/format 3.0)
debian/patches:
diff --exclude=.pc --exclude='patches' --exclude='config*' -Nurp \
radsecproxy-1.6/ radsecproxy-1.6.2/ | diffstat
debian/changelog | 14 ++
AUTHORS|1 +
ChangeLog | 19 ++-
README |2 +-
radsecproxy.conf.5.xml | 19 +++
Version updates documentation. Note that the manpage change is needed
as it explains some of the circumstances around the security fix.
aclocal.m4 |4 ++--
AC_AUTOCONF_VERSION 2.65 - 2.68. I realize that this, along the
configure.ac update, maybe unfortunate during the freeze, but it was the
only one that stood out and seems safe enough, so I opted against a
1.6-2 with everything else but this.
tls.c | 28 +++-
Fix for CVE-2012-4523.
dtls.c |4 +++-
Fix for CVE-2012-4566.
tools/naptr-eduroam.sh |4 ++--
Two minor one-liners; that script is only shipped in doc/examples/
anyway.
9 files changed, 71 insertions(+), 24 deletions(-)
Thanks,
Faidon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692448: qemu: system crash on 'libaio1' removal
2012/11/6 Michael Tokarev m...@tls.msk.ru: So, can you start it again when libaio1 is NOT installed? Yes, I was able to start the VMs again after the libaio1 removal. I'm not sure about the full Xen system -- I can't test now. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692327: libotr: Please provide libotr2
On Tue, 6 Nov 2012 14:17:05 +0100 Thibaut VARENE vare...@debian.org wrote: On Tue, Nov 6, 2012 at 1:04 PM, Neil Williams codeh...@debian.org wrote: On Tue, 6 Nov 2012 10:59:42 +0100 Thibaut VARENE vare...@debian.org wrote: If you want it in Debian now, push it into experimental. If you want it Jessie (the next testing), then wait for the d-d-a announcement. If you wanted it in Wheezy it's too late. If you just wanted it in unstable then it's clear that this is not desirable and your only option is experimental. Noted. The package was in experimental for several weeks and got zero attention. Hopefully because people are working on the release so that uploads to unstable can be opened again. The quicker we release Wheezy, the quicker this and other packages get into unstable. It's much better to work on RC bugs than to worry about a migration which can't really start until after the freeze. My general understanding is that nobody looks at experimental anyway. Those who do work other than on RC bugs during a release freeze will use experimental. It's where all the updates happen which are not intended for inclusion into the currently frozen testing. Another part of the issue was upstream's will to have it in Ubuntu as soon as possible. Ubuntu autosync doesn't fetch from experimental. Co-ordinate that with Ubuntu - the version of a package in Ubuntu does not affect how Debian makes a stable release. Whilst the wishes of upstream can be met outside of a freeze, there must always be extra barriers to package updates during a freeze or it wouldn't be a freeze. The will of upstream typically becomes a wishlist bug in Debian and wishes can't be met during a freeze, generally. Having a freeze simply means that some package changes *must* be delayed until after the freeze. Experimental works for some, if it doesn't work for you then you cannot update the package in Debian until the release, so maybe help get the release out. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp8HfxLetFmo.pgp Description: PGP signature
Bug#692414: [Pkg-utopia-maintainers] Bug#692414: network-manager: /etc/init.d/network-manager stop leaves wpa_supplicant behind
Michael Biebl bi...@debian.org (06/11/2012): When NM is stopped, it properly deconfigures the wireless interface in wpa_supplicant. So if you later on use wicd or ifupdown, you should be able to start another wpa_supplicant instance. The D-Bus activated one should just do nothing. Indeed, I covered that part in the wicd bug report I pointed to: migrating from N-M to wicd works fine. Mraw, KiBi. signature.asc Description: Digital signature
Bug#692450: rng-tools: please update to version 4
On Tue, 06 Nov 2012, Yves-Alexis Perez wrote: would it be possible to update rng-tools to version 4? This version apparently fixes a lot of issues with the previous versions and brings support for RDRAND instruction. That requires some work to avoid breaking compatibility with the unofficial fork packaged for Debian, which I currently don't have spare time to do. An alternative would be for someone else to package the new version as rng-tools4, or just submit a patch adding RDRAND support to the unofficial fork. I didn't accept the TPM patches because it would clash with the kernel and the rest of the userspace TPM stack, but RDRAND is different. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692429: libpython3.3-dev: fatal error: pyconfig.h: No such file or directory
Thanks, I have reported this issue in Blender developers ML. -- IRIE Shinsuke 12/11/06, Matthias Klose wrote: reassign 692429 blender severity 692429 important thanks Am 06.11.2012 07:10, schrieb IRIE Shinsuke: Package: libpython3.3-dev Version: 3.3.0-2 Severity: grave I attempted to build Blender trunk using python3.3-dev but got the following error: [ 58%] Building C object source/blender/python/intern/CMakeFiles/bf_python.dir/gpu.c.o In file included from /home/irie/Subversion/Blender/blender/source/blender/python/intern/gpu.c:40:0: /usr/include/python3.3m/Python.h:8:22: fatal error: pyconfig.h: No such file or directory compilation terminated. '#include pyconfig.h' in Python.h assumed that pyconfig.h is in /usr/include/python3.3m, but it's actually placed in /usr/include/x86_64-linux-gnu/python3.3m. Probably most of all programs using libpython3.3 cannot be built for this bug. no, only these which use home-grown configure tests. Please use python3.3-config --includes or pkgconfig. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692424: [Pkg-ime-devel] Bug#692424: ibus: Merge fixes from Ubuntu
On 6 November 2012 08:20, Osamu Aoki os...@debian.org wrote: Actually the original one is intentional to be like that, you may downgrade ibus-clutter to Suggests, but we need to have all the three other IM Modules in Recommends because: Ok. I agree with aron's analisys and I see no bugs here. If you disagree, please reopen this bug with explicit reasoning abut bug and explicit metits your proposed changes bring. Please note Ubuntu is not our upstream. You need to explain why they are better than our solution. There are several fixes. It seems you didn't like one of them so you went ahead and closed the bug. Your .symbols file has the wrong name and doesn't have the most up-to-date symbols. I believe now in experimental is a good time to switch from gconf to gsettings. gsettings has a lot of nice advantages for users, sysadmins, and distros and is being actively developed. You didn't install the bash completion information. I think python-ibus needs to depend on ibus (or you could have things like ibus-anthy explicitly depend on ibus instead). Jeremy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692463: eglibc-source: have gdb be able to list source from eglibc-source directly
Package: eglibc-source Version: 2.13-36 Severity: wishlist Dear Maintainer, gdb true (gdb) run (gdb) break fopen Breakpoint 3 at 0xb6f3d86c: file iofopen.c, line 107. (gdb) list fopen 102 iofopen.c: No such file or directory. # dpkg -L eglibc-sorce [...] /usr/src/glibc/eglibc-2.13.tar.xz i remember that list from gdb use to work, but i might be wrong -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 3.5.4-00581-g5930e52 (PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash eglibc-source depends on no packages. Versions of packages eglibc-source recommends: ii xz-utils 5.1.1alpha+20120614-1 eglibc-source 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#691999: Pre-approval request for t-p-u upload of irqbalance/1.0.3-4
On 05.11.2012 22:28, Aníbal Monsalve Salazar wrote: On Wed, Oct 31, 2012 at 08:51:29PM -0700, Matt Taggart wrote: So the libglib2.0-dev build-dep needs to be versioned. I ran into this attempting to backport to squeeze. [...] I would like to upload irqbalance/1.0.3-4 to fix Bug#691999. Is it okay to upload it to t-p-u? It doesn't look like the bug's been fixed in unstable yet? That would be a pre-requisite to fixing it in testing. (Technically the fix doesn't actually meet the freeze criteria, but I could probably be persuaded to accept it if it were fixed quickly.) Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692448: qemu: system crash on 'libaio1' removal
On 06.11.2012 17:39, Teodor MICU wrote: 2012/11/6 Michael Tokarev m...@tls.msk.ru: So, can you start it again when libaio1 is NOT installed? Yes, I was able to start the VMs again after the libaio1 removal. I'm not sure about the full Xen system -- I can't test now. In this case you really do not need/use libaio1, and there's no bug. Why it crashed is another question, again, I can only guess it was a bad luck - like your xen crashed right at the time when your dpkg were removing libaio1 (eg, it triggered some correct timing or system load or something else). On qemu side, everything is declared exactly as it should be. Qemu package does not use libaio1 and libaio1 is not listed in dependencies -- this is exactly how things were supposed to be and how they are now. Note again: even removing a library which is actually in use will NOT result in the application in question crashing. I think it is time to close this bugreport. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692327: libotr: Please provide libotr2
On Tue, Nov 6, 2012 at 2:43 PM, Neil Williams codeh...@debian.org wrote: Having a freeze simply means that some package changes *must* be delayed until after the freeze. Experimental works for some, if it doesn't work for you then you cannot update the package in Debian until the release, so maybe help get the release out. I believe I was mistaken as to what a freeze is. To me the freeze impacted testing, not unstable, being the whole purpose of a freeze, i.e. ensuring that new packages in unstable don't make it to testing-soon-to-be-stable. I didn't realize this meant that /unstable/ was to be considered as frozen too. Maybe it should effectively be so, so that new packages that aren't RC fixes can't even be uploaded to sid. This would avoid something like this happening again in the future. Anyway, I stand corrected. That being said, I'd like to point out again that all this fuss was made for nothing, since none of the packages listed in the initial email are being blocked from entering wheezy because of this upload, since none of them are unfrozen, and wheezy is unaffected by this change. And I see nothing wrong with breaking packages in unstable, but maybe there too I'm mistaken. -- Thibaut VARENE http://hacks.slashdirt.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691552: unblock: yate/4.1.0-1~dfsg-3
On Saturday 27 October 2012 07:18:17 am Mark Purcell wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package yate This release fixes three RC bugs and includes missing core modules. Thanks, Mark unblock yate/4.1.0-1~dfsg-3 [...] Hi! Does this require any more action? Paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691237: libassuan0: fixed ASSUAN_LINELENGTH for 4096bit encryption keys (Patch included)
Hi, I just pushed fixes to master and stable 2.0. Allow decryption with card keys 3072 bit * scd/command.c (MAXLEN_SETDATA): New. (cmd_setdata): Add option --append. * g10/call-agent.c (agent_scd_pkdecrypt): Use new option for long data * scd/app-openpgp.c (struct app_local_s): Add field manufacturer. (app_select_openpgp): Store manufacturer. (do_decipher): Print a note for broken cards. -- Please note that I was not able to run a full test because I only have broken cards (S/N 346) available. Please let me know if that works for you. Given that the last 2.0 release is more than 6 months old and we fixed a couple of bugs in the meantime, I may do a new release if this thing works for you. 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#661471: NMU v2 (was: Re: Bug#661471: bug 661471 gnome-accessibility-themes)
On Tue, Nov 6, 2012 at 8:09 PM, Theppitak Karoonboonyanan t...@debian.org wrote: On Tue, Nov 6, 2012 at 7:53 PM, Michael Biebl bi...@debian.org wrote: The gnome-themes-standard-common binary package is superfluous. Afaics the gettext translations are only required to translate the index.theme and background.xml files where the translations are directly embedded, so you don't actually need to install the .mo files. I would thus suggest to simply drop gnome-themes-standard-common. I had also found it out before seeing your message. So, I've cancelled the NMU. Anyway, I also stumbled upon this lintian info: I: gnome-themes-standard: arch-dep-package-has-big-usr-share 3549kB 99% That made me plan to move the non-engine parts into -common instead. What do you think? Please also make gnome-theme-standard depend on gnome-accessibility-themes. OK. I didn't think normal users want those a11y themes, so I hadn't added the dependency. Will do it now as you suggest, anyway. Also, gnome-accessibility-themes needs a Breaks along with the Replaces. OK. Re-uploaded to DELAYED/2. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692464: hplip-gui: hp-toolbox fails to start
Package: hplip-gui
Version: 3.12.6-3
Severity: normal
Tags: upstream
Hi.
hp-toolbox fails to start :
$ hp-toolbox
[...]
Traceback (most recent call last):
File /usr/bin/hp-toolbox, line 257, in module
toolbox = DevMgr5(__version__, device_uri, None)
File /usr/share/hplip/ui4/devmgr5.py, line 204, in __init__
if not utils.Is_HPLIP_older_version( installed_version,
self.user_settings.latest_available_version):
File /usr/share/hplip/base/utils.py, line 1828, in Is_HPLIP_older_version
if(int(installed_array[cnt]) int(available_array[cnt])):
ValueError: invalid literal for int() with base 10: 10a Public Release/abr
/')
This is very much similar to : https://bugs.launchpad.net/hplip/+bug/1069450
Thanks in advance.
Best regards,
-- Package-specific info:
HP Linux Imaging and Printing System (ver. 3.12.6)
Dependency/Version Check Utility ver. 15
Copyright (c) 2001-14 Hewlett-Packard Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.
Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before compiling
the HPLIP supplied tarball (.tar.gz or .run) to determine if the proper
dependencies are installed to successfully compile HPLIP.
2. Run-time check mode (-r or --run): Use this mode to determine if a distro
supplied package (.deb, .rpm, etc) or an already built HPLIP supplied tarball
has the proper dependencies installed to successfully run.
3. Both compile- and run-time check mode (-b or --both) (Default): This mode
will check both of the above cases (both compile- and run-time dependencies).
Check types:
a. EXTERNALDEP - External Dependencies
b. GENERALDEP - General Dependencies (required both at compile and run time)
c. COMPILEDEP - Compile time Dependencies
d. [All are run-time checks]
PYEXT SCANCONF QUEUES PERMISSION
Status Types:
OK
MISSING - Missing Dependency or Permission or Plug-in
INCOMPAT - Incompatible dependency-version or Plugin-version
Saving output in log file: /home/olivier/hp-check.log
Initializing. Please wait...
warning: debian-testing version is not supported. Using debian-6.0.5 versions
dependencies to verify and install...
---
| SYSTEM INFO |
---
Kernel: 3.2.0-4-686-pae #1 SMP Debian 3.2.32-1 GNU/Linux
Host: asustour
Proc: 3.2.0-4-686-pae #1 SMP Debian 3.2.32-1 GNU/Linux
Distribution: debian testing
---
| HPLIP CONFIGURATION |
---
HPLIP-Version: HPLIP 3.12.6
HPLIP-Home: /usr/share/hplip
warning: HPLIP-Installation: Auto installation is not supported for debian
distro testing version
Current contents of '/etc/hp/hplip.conf' file:
# hplip.conf. Generated from hplip.conf.in by configure.
[hplip]
version=3.12.6
[dirs]
home=/usr/share/hplip
run=/var/run
ppd=/usr/share/ppd/hplip/HP
ppdbase=/usr/share/ppd/hplip
doc=/usr/share/doc/hplip-doc/HTML
icon=no
cupsbackend=/usr/lib/cups/backend
cupsfilter=/usr/lib/cups/filter
drv=/usr/share/cups/drv
# Following values are determined at configure time and cannot be changed.
[configure]
network-build=yes
libusb01-build=no
pp-build=yes
gui-build=yes
scanner-build=yes
fax-build=yes
dbus-build=yes
cups11-build=no
doc-build=yes
shadow-build=no
hpijs-install=yes
foomatic-drv-install=yes
foomatic-ppd-install=yes
foomatic-rip-hplip-install=no
hpcups-install=yes
cups-drv-install=yes
cups-ppd-install=no
internal-tag=3.12.6
restricted-build=no
ui-toolkit=qt4
qt3=no
qt4=yes
policy-kit=yes
hpijs-only-build=no
lite-build=no
udev-acl-rules=yes
udev_sysfs_rules=no
hpcups-only-build=no
hpijs-only-build=no
Current contents of '/var/lib/hp/hplip.state' file:
Plugins are not installed. Could not access file: No such file or directory
Current contents of '~/.hplip/hplip.conf' file:
[upgrade]
latest_available_version = 3.12.10a Public Release/abr
/');document.write('/li');document.write('li class=rss-itema
class=rss-item
Bug#691237: libassuan0: fixed ASSUAN_LINELENGTH for 4096bit encryption keys (Patch included)
On Tue, 6 Nov 2012 12:24, cor...@debian.org said: Hmh, I didn't have any problem generating keys on-card nor moving keys to card on Debian sid. The only thing I needed to check is to use /usr/bin/gpg2 and not /usr/bin/gpg, since /u/b/gpg is unfortunately Generating keys worked for me using pcscd and thus libusbx instead of gnupg's internal ccid driver which uses libusb. I have not yet looked closer at that problem, though. The other problem here is that I am using 2.1 where the card support is not yet complete. Time to work on this. Salam-Shalom, 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#691925: update-notifier-common: Add an option to only show security packages
On Wed, Oct 31, 2012 at 02:01:47PM +0100, Rodolphe Quiédeville wrote: Package: update-notifier-common Version: 0.99.3debian8 Severity: wishlist Hi, Please found attach a patch to add an option -s like -p but to show onlys packages from security Total NAK. You're duplicating most of the code. What you want is to modify write_package_names to add an additional filtering stage, by checking whether the candidates of the packages are security updates. But you should probably submit this upstream to Ubuntu anyway, after signing a Contributor License Agreement with Canonical. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692423: [Pkg-ime-devel] Bug#692423: ibus-anthy: Missing python dependencies
On 6 November 2012 08:44, Osamu Aoki os...@debian.org wrote: So actually, only python-glade2 may be good idea to add to the list. Ok, that's correct. But please don't close valid bugs just because you don't feel like fixing them today. python-glade2 is definitely not something that is installed on an average Debian system. Since ibus-anthy won't work without python-glade2, I think this bug's importance is easily Serious and therefore RC. The original Ubuntu bug was http://pad.lv/829876 This is the only diff between Ubuntu and Debian for this package. Debian's objective is not match Ubuntu. Please explain this update benefits current Debian. Your bug report is not so friendly kind to us. We are not releasing these for Ubuntu. Without assessing merit and risks, no patch is accepted from Ubuntu. I'm sorry if my bug report seemed rude or unfriendly. It definitely was not intended that way. Having packages in sync makes it easy to verify that Ubuntu didn't fix something in their packages and neglected to forward that fix to Debian (as this bug which was fixed in Ubuntu a year ago). You can use http://packages.qa.debian.org/ibus or http://qa.debian.org/developer.php?login=pkg-ime-de...@lists.alioth.debian.org to easily check the Ubuntu versions. Also, it is much easier on Ubuntu developers to include the latest fixes from Debian if they can do a sync instead of a merge. Just because you don't care about Ubuntu does not mean that you should refuse contributions from Ubuntu. Please do not make us spend more time explaining than you thinking and doing explanation. Actually, it's your job as a Debian maintainer to triage bugs in the packages you maintain. I've reported multiple valid bugs in ibus-related packages today and given the somewhat unfriendly reaction, I'm less motivated to do so in the future. Jeremy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661471: NMU v2 (was: Re: Bug#661471: bug 661471 gnome-accessibility-themes)
On Tue, Nov 6, 2012 at 9:09 PM, Theppitak Karoonboonyanan t...@debian.org wrote: Re-uploaded to DELAYED/2. The debdiff. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ gnome-themes-standard_3.4.2-2.1.debdiff Description: Binary data
