Bug#972805: xserver-xorg-core: XWarpPointer() corrupts pointer position when mouse accelerated
Package: xserver-xorg-core
Version: 2:1.20.4-1+deb10u1
Severity: normal
File: /usr/bin/X
Dear Maintainer,
I have been pulling my hair out about this problem. Programs that make
heavy use of XWarpPointer() (like 'Kicad') were totally broken on my
system. Turns out that speeding up the mouse using 'xset m' or ' xinput
set-prop xx 147' causes pointer position to become corrupt on the first
mouse-movement, after XWarpPointer() was called.
Below I attached an example program that invokes XWarpPointer() when a
key is pressed inside the window. Bug consistently reproducable via:
* compile test
gcc -lX11 -Wall testwrap.c -o testwrap
* configure your mouse to high speed.
- find out the ID of your mouse via 'xinput list'. I.e. for me it
lists:
Kensington Computer [..] Trackball id=19 [slave pointer (2)]
- Use that ID to configure a higher speed
input set-prop 19 147 3, 0, 0, 0, 3, 0, 0, 0, 1
- ('xset mouse 3 0' also sometimes triggers the bug, however it only
seems to act on the first connected mouse and none of the
hot-plugged mice.)
* invoke ./testwrap, place mouse cursor inside black window
* Make sure the mouse is steady and press any key. Observe the mouse
pointer jumping to the top-left of the window. That's what it should
do.
* now move the mouse just a little.
- I expect: mouse moves just a little
- What happens: mouse jumps to the bottom-right-most corner of the
screen
* without accelerating the mouse, this does not happen. Exactly same
mis-behaviour happening in Kicad on most GUI operations. Makes Kicad
mostly unusable.
The only workaround (other than giving up on accelerating the mouse) for
me currently is to use LD_PRELOAD to fully disable XWarpPointer() for
e.g. Kicad.
cheers,
David
/* derived from examples found here:
* http://xopendisplay.hilltopia.ca/index.html */
#include
#include
int main(int argc, char ** argv){
int screen_num, width, height;
unsigned long background, border;
Window win;
XEvent ev;
Display *dpy;
/* First connect to the display server */
dpy = XOpenDisplay(NULL);
if (!dpy) {fprintf(stderr, "unable to connect to display\n");return 7;}
screen_num = DefaultScreen(dpy);
background = BlackPixel(dpy, screen_num);
border = WhitePixel(dpy, screen_num);
width = 320;
height = 200;
win = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), /* display, parent */
0,0, /* x, y: the window manager will place the window elsewhere */
width, height, /* width, height */
2, border, /* border width & colour, unless you have a window manager */
background); /* background colour */
/* tell the display server what kind of events we would like to see */
XSelectInput(dpy, win, ButtonPressMask|StructureNotifyMask|KeyPressMask|KeyReleaseMask|KeymapStateMask);
/* okay, put the window on the screen, please */
XMapWindow(dpy, win);
/* as each event that we asked about occurs, we respond. In this
* case we note if the window's shape changed, and exit if a button
* is pressed inside the window */
while(1){
XNextEvent(dpy, );
switch(ev.type){
case KeymapNotify:
XRefreshKeyboardMapping();
break;
case KeyPress: break; /* ignore these */
case KeyRelease:
XWarpPointer(dpy, None, win, 0, 0, 0, 0, 5, 5);
break;
case ButtonPress:
XCloseDisplay(dpy);
return 0;
}
}
}
Bug#909741: Acknowledgement (mesa-opencl-icd: Memory leak in clEnqueueNDRangeKernel())
Also reported the issue to upstream: https://bugs.freedesktop.org/show_bug.cgi?id=108087
Bug#909741: mesa-opencl-icd: Memory leak in clEnqueueNDRangeKernel()
Note that this bug seems to be present in all versions of mesa 18.1.x [1] but is fixed in mesa 18.2 [2]. [1] https://gitlab.freedesktop.org/mesa/mesa/blob/18.1/src/gallium/state_trackers/clover/core/kernel.hpp [2] https://gitlab.freedesktop.org/mesa/mesa/blob/18.2/src/gallium/state_trackers/clover/core/kernel.hpp
Bug#909741: mesa-opencl-icd: Memory leak in clEnqueueNDRangeKernel()
Package: mesa-opencl-icd Version: 18.1.6-1~bpo9+1 Severity: normal Dear Maintainer, the mesa 18.1.6 version that is provided via debian-backports has a memory leak in the functions that implement clEnqueueNDRangeKernel(). The root cause is that destructor clover::kernel::scalar_argument::~scalar_argument() is never called, as life-time is managed via a unique_ptr<> to the parent class 'argument' which does not have a virtual destructor. This leads to memory allocated by member vector<> kernel::scalar_argument::_v to leak. For me adding a virtual destructor fixes this specific leak: --- src.orig/mesa-18.1.6/src/gallium/state_trackers/clover/core/kernel.hpp 2018-08-13 18:42:38.0 +0200 +++ mesa-18.1.6/src/gallium/state_trackers/clover/core/kernel.hpp 2018-09-27 10:17:16.689585453 +0200 @@ -75,6 +75,7 @@ argument(const argument ) = delete; argument & operator=(const argument ) = delete; + virtual ~argument() = default; /// \a true if the argument has been set. bool set() const; Maybe somebody more familiar with the sources could look through GCC warnings or sanitizer output for whether more problems of that sort are present throughout the Mesa sources? This bug currently causes leela zero [1] to consume many gigabytes of memory over time, making it impractical to run, see the corresponding leela zero bug [2] ([2] also has more details like valgrind backtraces of the leak in question). cheers, David [1] http://zero.sjeng.org/ [2] https://github.com/gcp/leela-zero/issues/1823 -- Package-specific info: glxinfo: DISPLAY is not set. X server symlink status: lrwxrwxrwx 1 root root 13 Mar 22 2016 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Oct 14 2017 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Carrizo [1002:9874] (rev e3) /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 4.17.0-0.bpo.3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.17.17-1~bpo9+1 (2018-08-27) Xorg X server log files on system: -- -rw-r--r-- 1 root root 32159 Mar 22 2016 /var/log/Xorg.1.log -rw-r--r-- 1 root root 36921 Sep 5 21:54 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 641.716] X.Org X Server 1.19.2 Release Date: 2017-03-02 [ 641.716] X Protocol Version 11, Revision 0 [ 641.716] Build Operating System: Linux 4.9.0-4-amd64 x86_64 Debian [ 641.716] Current Operating System: Linux mosquito2 4.17.0-0.bpo.3-amd64 #1 SMP Debian 4.17.17-1~bpo9+1 (2018-08-27) x86_64 [ 641.716] Kernel command line: BOOT_IMAGE=/vmlinuz-4.17.0-0.bpo.3-amd64 root=/dev/mapper/yami-root ro quiet [ 641.716] Build Date: 16 October 2017 08:19:45AM [ 641.716] xorg-server 2:1.19.2-1+deb9u2 (https://www.debian.org/support) [ 641.716] Current version of pixman: 0.34.0 [ 641.716]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 641.716] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 641.716] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Sep 1 06:24:09 2018 [ 641.807] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 641.973] (==) No Layout section. Using the first Screen section. [ 641.973] (==) No screen section available. Using defaults. [ 641.973] (**) |-->Screen "Default Screen Section" (0) [ 641.973] (**) | |-->Monitor "" [ 641.977] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 641.977] (==) Automatically adding devices [ 641.977] (==) Automatically enabling devices [ 641.977] (==) Automatically adding GPU devices [ 641.977] (==) Max clients allowed: 256, resource mask: 0x1f [ 642.044] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 642.044]Entry deleted from font path. [ 642.231] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 642.231] (==) ModulePath set to "/usr/lib/xorg/modules" [ 642.231] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable
Bug#824903: letsencrypt.sh: Letsencrypt.sh broken due to "pretty" json used in Let's Encrypt API
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Package: letsencrypt.sh
Version: 0.1.0-2~bpo8+1
Severity: normal
File: /usr/bin/letsencrypt.sh
Hi,
I'm testing this using the backports package, but I guess the problem
applies to sid as well (same version).
Recently letsencrypt.org changed to return pretty json with lots of
newlines (as tested via
https://acme-staging.api.letsencrypt.org/directory). This breaks
various sed-based json parsing code in the distributed version of
letsencrypt.sh .
The symptom is that 'letsencrypt.sh --cron' silently exits after
printing
+ Requesting challenge for
Aborting before completing the challenge.
Looking at trace output from
bash -x -c 'source /usr/bin/letsencrypt.sh --cron'
It obviously fails to extract the challenge from json output due to
sed -n 's/.*\("challenges":[^\[]*\[[^]]*]\).*/\1/p'
expecting the hole match to be on a single line. Somebody reported the
issue upstream on May 18th:
https://github.com/lukas2511/letsencrypt.sh/pull/202
The "official" fix is here:
https://github.com/lukas2511/letsencrypt.sh/commit/561f0626b855ec4ee94856884e2f1eff9ade2d88
cheers,
David
- -- System Information:
Debian Release: 8.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages letsencrypt.sh depends on:
ii curl 7.38.0-4+deb8u3
ii openssl 1.0.1k-3+deb8u5
letsencrypt.sh recommends no packages.
letsencrypt.sh suggests no packages.
- -- no debconf information
- --
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg
Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iF4EAREIAAYFAlc/5WIACgkQk15vCORXIF+G/gD/YYZYGZDLM6Jb64JCtWojJCqP
dLaNFWQkMUqrfuizXJkBAKmJjaUMs8PHREkge9T1oIjVzukCQA7dz9Y2OndEAxIx
=nAa2
-END PGP SIGNATURE-
Bug#805066: backup2l: Parallel invocation sometimes overwrites current in-progress backup
Package: backup2l Version: 1.5-6 Severity: normal File: /usr/bin/backup2l Dear Maintainer, recently a new level-1 backup was created which took more than one day to complete. With backup2l being run from /etc/cron.daily this lead to a second concurrent 'backup2l -b' invocation. For some reason the lock-file check was not effective and the second invocation (partially) overwrote the backup-files that had been building for 24 hours. Looking at the source code I see at least one problem: umount_dev is run unconditionally at the end of script. umount_dev also removes the lock-file. So while backup2l is running, I can accidentally remove the lock-file by merely inovking backup2l with an invalid command line option: $ backup2l -b (switch to other console) $ backup2l -b ERROR: Backup volume is locked. (so far so good) $ backup2l --summary Usage: backup2l [-c ] [-t ] (lock-file now gone) $ backup2l -b [..] Running pre-backup procedure... I'm not sure whether this is the scenario that hit me when backup2l started to overwrite its own backup, but it's the only way I am currently able to reproduce the problem. cheers, David -- System Information: Debian Release: 7.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: mipsel (mips64) Kernel: Linux 2.6.39.4-dk1-fix2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash backup2l depends on no packages. Versions of packages backup2l recommends: ii bzip2 1.0.6-4 backup2l suggests no packages. -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F
Bug#690531: Help needed: Porting IRAF to MIPS
Thomas == Thomas Bogendoerfer tsbog...@alpha.franken.de writes: On Thu, May 08, 2014 at 02:07:45AM +0200, David Kuehling wrote: Index: zsvjmp/zsvjmp-mipsel.s why only mipsel ? The code should look the same for big endian MIPS... Because that's the name his test-case Makefile expected :) : ARCH:=$(shell dpkg-architecture -qDEB_BUILD_ARCH) zsvjmp.s: zsvjmp-$(ARCH).s ln -sf $ $@ (I did all coding against Ole's test-case tarball and not against actual IRAF sources). Rename sources at your will and/or use links/#include/.include/makefile rules/autoconf code or whatever else to make mipsel and mips both use the same code David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F pgp0rsgvK7HN4.pgp Description: PGP signature
Bug#690531: Help needed: Porting IRAF to MIPS
On 05.05.2014 12:16, Ole Streicher wrote: since a while, I am working to bring the IRAF package [1] into Debian [2]. I'd like to make the package working on as many Debian platforms as possible. The major problem here is that IRAF needs a small piece of assembler code that provides a (sort of) setjmp() to their Fortran variant. Attached you'll find a patch against your zsvjmp.tar.gz test-case that adds mipsel support. This seems to work on my debian squeeze mipsel system, i.e. running 'make test' outputs: ./zzdebug Status = 0, step = 0 Calling zdojmp Status = 1, step = 1 All OK ./jmptest Status = 0 step = 0 Calling zdojmp Status = 1 step = 1 All OK STOP 0 cheers, David PS: forget my last comment WRT loading $t9 when jumping to PIC code: the mipsel linker (or assembler?) automatically adds such stub code for calls into PIC routines when .abicalls was enabled in the assembler source. -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F Index: zsvjmp/zsvjmp-mipsel.s === --- /dev/null 1970-01-01 00:00:00.0 + +++ zsvjmp/zsvjmp-mipsel.s 2014-05-08 00:18:31.433683675 +0200 @@ -0,0 +1,19 @@ + .file zsvjmp.s + +# Copyright (c) 2014 David Kuehling dvdkhlng AT posteo TOD de +# Distributable under the same license as IRAF +# This file contains the Linux mipsel version of ZSVJMP for Debian. + + .set mips1 + .abicalls + .text + .global zsvjmp_ + .type zsvjmp_, %function + +zsvjmp_: + sw $a1, 0($a0) # buf[0]=status + sw $zero, 0($a1) # *status=0 + addiu $a0, $a0, 4 # buf[1] -- 1st arg for sigsetjmp + move$a1, $zero # 2nd arg is zero; this opcode fills delay slot + j __sigsetjmp # jump to sigsetjmp + ## note: no delay slot, filled by GAS reordering instructions above pgp2nf_W6sHxY.pgp Description: PGP signature
Bug#690531: Help needed: Porting IRAF to MIPS
David == David Kuehling dvdkh...@posteo.de writes: Attached you'll find a patch against your zsvjmp.tar.gz test-case that adds mipsel support. This seems to work on my debian squeeze mipsel system, i.e. running 'make test' outputs: correction: I actually tested this on a debian /wheezy/ system. david pgpPCZrPSqDkB.pgp Description: PGP signature
Bug#690531: Help needed: Porting IRAF to MIPS
The code needs some more changes to be compiled and work as part of a shared library. Note: you need to compile assembly sources via '$(CC) $(CFLAGS) -c' so that options like -fPIC make it to the assembler. Patch below works with both static and shared libraries. Makefile patched so that shared library test can be built as well (set LIBEXT to either .a or .so and comment out CFLAGS+=-fPIC accordingly). Index: zsvjmp/zsvjmp-mipsel.s === --- /dev/null 1970-01-01 00:00:00.0 + +++ zsvjmp/zsvjmp-mipsel.s 2014-05-08 02:06:41.733234949 +0200 @@ -0,0 +1,28 @@ + .file zsvjmp.s + +# Copyright (c) 2014 David Kuehling dvdkhlng AT posteo TOD de +# Distributable under the same license as IRAF +# This file contains the Linux mipsel version of ZSVJMP for Debian. + + .set mips1 + .abicalls + .text + .global zsvjmp_ + .ent zsvjmp_ + .type zsvjmp_, %function + +zsvjmp_: + .set noreorder + .cpload $t9 + .set reorder + sw $a1, 0($a0) # buf[0]=status + sw $zero, 0($a1) # *status=0 + addiu $a0, $a0, 4 # buf[1] -- 1st arg for sigsetjmp + move$a1, $zero # 2nd arg is zero + + # this call sequence is required when used inside shared library + la $t9, __sigsetjmp + j $t9 + ## note: no delay slot, filled by GAS + + .end zsvjmp_ Index: zsvjmp/Makefile === --- zsvjmp.orig/Makefile 2014-05-05 10:50:35.0 +0200 +++ zsvjmp/Makefile 2014-05-08 02:02:08.515737053 +0200 @@ -2,16 +2,25 @@ FC=gfortran FFLAGS+=-ff2c +LIBEXT=.so +CFLAGS += -fPIC # uncomment when LIBEXT=.a + +%.o : %.s + $(CC) $(CFLAGS) -o $@ -c $ + libzsvjmp.a: zdojmp.o zsvjmp.o $(AR) cr $@ $^ +libzsvjmp.so: zdojmp.o zsvjmp.o + gcc -shared -fPIC -o $@ $^ + zsvjmp.s: zsvjmp-$(ARCH).s ln -sf $ $@ -jmptest: jmptest.o libzsvjmp.a +jmptest: jmptest.o libzsvjmp$(LIBEXT) $(FC) -o $@ $ -L. -lzsvjmp -zzdebug: zzdebug.o libzsvjmp.a +zzdebug: zzdebug.o libzsvjmp$(LIBEXT) $(CC) -o $@ $ -L. -lzsvjmp test: jmptest zzdebug @@ -19,5 +28,5 @@ ./jmptest clean: - rm -f *.o zsvjmp.s jmptest zzdebug *.a + rm -f *.o zsvjmp.s jmptest zzdebug *.a *.so pgpLSxE7vAwLI.pgp Description: PGP signature
Bug#738625: Same (or worse) problem here
Using Debian Wheeze amd64, same version of wget (1.13.4-3+deb7u1). Just had new SSL keys generated for my hobby site stech.muecke.pw (heartbleed disaster recovery). According to gnutls-cli my certificate is completely valid: $ gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt [..] - The hostname in the certificate matches 'stech.muecke.pw'. - Peer's certificate is trusted [..] Corresponding wget command still fails: $ wget -4 --ca-certificate /etc/ssl/certs/ca-certificates.crt \ https://stech.muecke.pw -O /dev/null [..] Connecting to stech.muecke.pw (stech.muecke.pw)|xx.xx.xx.xx|:443... connected. GnuTLS: A TLS warning alert has been received. Unable to establish SSL connection. --no-check-certificate does not help. Curl works, as does iceweasel. Wget with --no-check-certificate, using IP address instead of hostname also works (with IP v4 and v6 addresses). Using a locally defined DNS alias mosquito.pool with --no-check-certificate also works, but the public DNS alias mosquito.selfhost.eu produces the above error. cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F pgp5i0FmmIGZJ.pgp Description: PGP signature
Bug#744168: iceweasel: OCSP check takes more than 30 minutes per request, crashes
Package: iceweasel
Version: 24.4.0esr-1~deb7u2
Severity: normal
File: /usr/bin/iceweasel
Dear Maintainer,
trying to load a single encrypted websites, such as
https://bugs.debian.org now takes more than 30 minutes during which
(according to tcpdump, ifttop) firefox keeps talking to
ocsp.commodoca.com, downloading over 70 Mbyte in the process. No, my
internet connection is not the bottleneck here ( 10mbit).
Seems to depend on certifcate authority, I was only able to reproduce
this particlar problem for websites that use Comodo's CA.
This may be result of the heartbleed bug causing lots of certificates to
be revoked? Unfortunately it makes HTTPS (or OCSP) completely unusable.
Once the site is loaded, further operation is nominal, but the delay
occurs again when Iceweasel is restarted (note: I have disabled harddisk
cache for privacy reasons, don't know whether configuring a sufficiently
large cache would help).
Update: It gets worse: during my last test Iceweasel crashed after 78
Megabyte had been downloaded from ocsp.comodoca.com, ca 45 minutes after
initiating the loading of https://bugs.debian.org
cheers,
David
-- Package-specific info:
-- Extensions information
Name: 4or6
Location: ${PROFILE_EXTENSIONS}/4...@hunen.net.xpi
Status: enabled
Name: Adblock Plus
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Package: xul-ext-adblock-plus
Status: enabled
Name: CipherFox
Location: ${PROFILE_EXTENSIONS}/cipher...@mkfly.xpi
Status: user-disabled
Name: Default theme
Location:
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled
Name: Facebook Disconnect
Location: ${PROFILE_EXTENSIONS}/faceb...@disconnect.me.xpi
Status: enabled
Name: Flashblock
Location: ${PROFILE_EXTENSIONS}/{3d7eb24f-2740-49df-8937-200b1cc08f8a}
Status: enabled
Name: Flash Video Downloader - Full HD Download
Location: ${PROFILE_EXTENSIONS}/artur.dubo...@gmail.com
Status: user-disabled
Name: Flash Video Resources Downloader
Location: ${PROFILE_EXTENSIONS}/m...@subfighter.com
Status: app-disabled
Name: Google Disconnect
Location: ${PROFILE_EXTENSIONS}/goo...@disconnect.me.xpi
Status: enabled
Name: Greasemonkey
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}
Package: xul-ext-greasemonkey
Status: user-disabled
Name: HTTPS-Everywhere
Location: ${PROFILE_EXTENSIONS}/https-everywh...@eff.org
Status: user-disabled
Name: lori (Life-of-request info)
Location: ${PROFILE_EXTENSIONS}/{6dfc4f52-26f0-4e5f-89c7-31d6de480db9}
Status: user-disabled
Name: NoScript
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{73a6fe31-595d-460b-a920-fcc0f8843232}
Package: xul-ext-noscript
Status: enabled
Name: NoSquint
Location: ${PROFILE_EXTENSIONS}/nosqu...@urandom.ca.xpi
Status: enabled
Name: Twitter Disconnect
Location: ${PROFILE_EXTENSIONS}/twit...@disconnect.me.xpi
Status: enabled
Name: User Agent Switcher
Location: ${PROFILE_EXTENSIONS}/{e968fc70-8f95-4ab9-9e79-304de2a71ee1}
Status: user-disabled
-- Plugins information
Name: DivX Web Player
Location: /usr/lib/mozilla/plugins/libtotem-mully-plugin.so
Package: totem-mozilla
Status: enabled
Name: Gnome Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled
Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: enabled
Name: Java(TM) Plug-in 1.6.0_26
Location: /usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64/libnpjp2.so
Package: sun-java6-bin
Status: disabled
Name: MozPlugger 1.14.1 handles QuickTime and Windows Media Player Plugin
(1.14.1)
Location: /usr/lib/mozilla/plugins/mozplugger.so
Package: mozplugger
Status: enabled
Name: QuickTime Plug-in 7.6.6
Location: /usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so
Package: totem-mozilla
Status: enabled
Name: Shockwave Flash
Location: /usr/lib/flashplugin-nonfree/libflashplayer.so
Status: enabled
Name: VLC Multimedia Plugin (compatible Totem 3.0.1)
Location: /usr/lib/mozilla/plugins/libtotem-cone-plugin.so
Package: totem-mozilla
Status: enabled
Name: Windows Media Player Plug-in 10 (compatible; Totem)
Location: /usr/lib/mozilla/plugins/libtotem-gmp-plugin.so
Package: totem-mozilla
Status: enabled
-- Addons package information
ii gnome-shell3.4.2-7+deb7 amd64graphical shell for the GNOME des
ii iceweasel 24.4.0esr-1~ amd64Web browser based on Firefox
ii mozplugger 1.14.1-1 amd64Plugin allowing external viewers
ii rhythmbox-plug 2.97-2.1 amd64plugins for rhythmbox music playe
ii sun-java6-bin 6.26-0squeez amd64Sun Java(TM) Runtime Environment
ii totem-mozilla 3.0.1-8 amd64Totem Mozilla plugin
ii xul-ext-adbloc 2.1-1+deb7u1 all Advertisement blocking extension
ii
Bug#736304: apache2-mpm-worker: error.log: child NNN exit Segmentation fault
Package: apache2-mpm-worker Version: 2.2.22-13 Severity: normal File: /usr/sbin/apache2 Dear maintainer, I recently noticed that long-running HTTP connections to my webserver are closed at random points in time, and whenever such an event occurs, a corresponding child N exit Segmentation fault message appears in /var/log/apache2/errors.log. Here's an excerpt of errors.log: [Mon Jan 20 11:24:54 2014] [notice] child pid 24196 exit signal Segmentation fault (11) At the exact same time, a connection to the server opened via proxytunnel -v -B -p $host:443 -d MAGIC_IP: was closed. I was monitoring the connection via tcpdump: 11:24:45.094427 IP CLIENT.39172 SERVER.443: Flags [.], ack 5889, win 212, options [nop,nop,TS val 3379557 ecr 168685518], length 0 11:24:54.271639 IP SERVER.443 CLIENT.39172: Flags [F.], seq 5889, ack 5680, win 444, options [nop,nop,TS val 168687824 ecr 3379557], length 0 11:24:54.322112 IP CLIENT.39172 SERVER.443: Flags [F.], seq 5680, ack 5890, win 212, options [nop,nop,TS val 3381864 ecr 168687824], length 0 11:24:54.325877 IP SERVER.443 CLIENT.39172: Flags [.], ack 5681, win 444, options [nop,nop,TS val 168687837 ecr 3381864], length 0 The connection was processed via mod_proxy_connect. However, even when no connections via mod_proxy are active, I see lots of these Segmenation fault messages, so I currently assume that the problem is not in mod_proxy but somewhere deeper in apache's internals. For reference, this is the mod_proxy configuration that I'm using: --8-- ProxyRequests on AllowCONNECT ProxyVia on Proxy * Order deny,allow Deny from all /proxy SetEnvIf User-Agent ^magic_string_blablabla SSHTUNNEL_AUTHORIZED Proxy MAGIC_IP Order deny,allow Deny from all Allow from env=SSHTUNNEL_AUTHORIZED /Proxy --8-- Looking at my errors.log, I see 10 Segmentation fault messages for Jan/20, while in the same time frame access.log lists 700 and ssl_access.log lists 30 requests. Maybe the problem is related to this bug [1]? cheers, David [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=50335 -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: mipsel (mips64) Kernel: Linux 2.6.39.4-dk1-fix1 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 apache2-mpm-worker depends on: ii apache2.2-bin 2.2.22-13 ii apache2.2-common 2.2.22-13 apache2-mpm-worker recommends no packages. apache2-mpm-worker suggests no packages. -- no debconf information -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F pgpXVhlqbPDFF.pgp Description: PGP signature
Bug#728697: wget: segfault with SSL and --read-timeout
Package: wget Version: 1.13.4-3 Severity: normal File: /usr/bin/wget Dear Maintainer, After upgrading from squeeze to wheezy, the following invokation of wget segfaults: wget --read-timeout=0.0 -O - https://www.google.de This is the corresponding terminal output: --2013-11-04 09:10:04-- https://www.google.de/ Resolving www.google.de (www.google.de)... 173.194.69.94, 2a00:1450:4008:c01::5e Connecting to www.google.de (www.google.de)|173.194.69.94|:443... connected. HTTP request sent, awaiting response... Segmentation fault GDB is incapable of supplying a corresponding backtrace: [..] Program received signal SIGSEGV, Segmentation fault. 0x00424e98 in ?? () (gdb) bt #0 0x00424e98 in ?? () warning: GDB can't find the start of the function at 0x424e98. This is the disassambly around the error location: (gdb) disas $pc-16,$pc+16 Dump of assembler code from 0x424e88 to 0x424ea8: 0x00424e88: sw ra,36(sp) 0x00424e8c: jal 0x403330 clock_gettime@plt 0x00424e90: addiu a1,sp,24 0x00424e94: lw v0,28(sp) = 0x00424e98: lw v1,4(s0) 0x00424e9c: lw a0,0(s0) 0x00424ea0: subuv1,v0,v1 0x00424ea4: mtc1v1,$f0 End of assembler dump. Register dump: (gdb) info regist zero at v0 v1 a0 a1 a2 a3 R0 cfff 1740e769 00488098 0001 7fff2620 t0 t1 t2 t3 t4 t5 t6 t7 R8 0004 0002 00424e94 8008 80277ea0 0047 s0 s1 s2 s3 s4 s5 s6 s7 R16 00488098 0008 ffcc 0080 t8 t9 k0 k1 gp sp s8 ra R24 2acf8620 00487e88 2ad14040 7fff2608 00424e94 status lo hi badvaddrcause pc 44f3 0953fd71 0001 0004 10008008 00424e98 fcsr fir restart 0084 0501 Looks like a 0-pointer dereference. Accordingo to /proc/pid/maps, the location of the faulting instruction is part of wget's code segment (i.e. it's not a shared library that causes the crash): 0040-00458000 r-xp fe:02 131578 /usr/bin/wget -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: mipsel (mips64) Kernel: Linux 2.6.38-bpo.2-loongson-2f 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 wget depends on: ii dpkg 1.16.12 ii install-info 4.13a.dfsg.1-10 ii libc6 2.13-38 ii libgcrypt111.5.0-5+deb7u1 ii libgnutls262.12.20-7 ii libgpg-error0 1.10-3.1 ii libidn11 1.25-2 ii zlib1g 1:1.2.7.dfsg-13 wget recommends no packages. wget suggests no packages. -- no debconf information -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F pgp32AGqxoHY9.pgp Description: PGP signature
Bug#728755: libapache2-mod-gnutls: mod_gnutls stops working after upgrade to wheezy
Package: libapache2-mod-gnutls Version: 0.5.10-1.1 Severity: normal File: /usr/lib/apache2/modules/mod_gnutls.so Dear Maintainer, after upgrading from squeeze to wheezy, mod_gnutls based sites stopped working. My formerly SSL-enabled site at 'server:443' is now serving unencrypted plain HTTP protocol, i.e. Now this works (but it should not): wget http://mosquito.selfhost.eu:443/ While this does not (but should): wget https://mosquito.selfhost.eu:443/ The corresponding configuration on my server is located at /etc/apache2/sites-enabled/20-default-ssl A slightly cleaned-up version of that config file is attached below. The accesses to server:443 are logged in /var/log/apache2/ssl_access.log (and not access.log), indicating that the correct configuration is in fact loaded and used by apache. I tried many variations and simplifications of the configuration but without success. It looks as if the configuration directive GnuTLSEnable on is just completely ignored. cheers, David -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: mipsel (mips64) Kernel: Linux 2.6.39.4-dk1-fix1 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 libapache2-mod-gnutls depends on: ii libapr-memcache0 0.7.0-1 ii libc6 2.13-38 ii libgnutls26 2.12.20-7 libapache2-mod-gnutls recommends no packages. libapache2-mod-gnutls suggests no packages. -- no debconf information -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F 20-default-ssl Description: Binary data pgpWMXJ0yZ0Nx.pgp Description: PGP signature
Bug#728697: wget: segfault with SSL and --read-timeout
Noël == Noël Köthe n...@debian.org writes: I tried to reproduce your problem with wget 1.12 (squeeze/oldstable), 1.13 (stable/wheezy) and 1.14 (testing/sid) on amd64 and it is reproducible with 1.13 (amd64) but not with 1.12 and 1.14. [..] Do you have the possiblity to test 1.14 (testing and unstable) on mipsel to verify it is fixed in 1.14? Hi Noël, I don't currently have a testing or unstable installation. Would need to setup a chroot first. Maybe it's easier just asking the people at debian-m...@lists.debian.org. Will drop a mail there in the next days unless the bug is closed by then :) But given your results on amd64, I'm quite sure the bug is architecture-neutral. cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F pgp6bjqe4Y8Tn.pgp Description: PGP signature
Bug#693273: upgrade-reports: upgrade squeeze - wheezy
Julien == Julien Cristau jcris...@debian.org writes: On Thu, Nov 15, 2012 at 01:00:59 +0100, David Kuehling wrote: I did the upgrade to wheezy this weekend which went suprisingly well. Only two slight problems I stumbled upon: - My NFSv4-mounted directories lost ownership information (everything set to nobody/nogroup), which I had to fix by manually setting Domain=localdomain in /etc/idmapd.conf (looks like the newer idmapd now uses the real domainname of my machine by default). Also NEED_IDMAPD wasn't set yes in /etc/default/nfs-common after the upgrade, but not sure how it was set before. I only know that I /did/ have idmapd running before the upgrade. Weird. The way I'm reading wheezy's /etc/init.d/nfs-common, AUTO_NEED_IDMAPD seems to be set to yes pretty much unconditionally now, so as far as I can tell it *should* be running automatically. Yes, you're right, looking at etc/init.d/nfs-common I now see that there is absolutely no need to set NEED_IDMAPD in etc/common/nfs-common, and most certainly my problems were merely caused by the wrong domain setting in idmapd.conf. - gnutls-cli lost support for option --protocols which my Emacs/Gnus had been configured to using, so Mail retrieval failed until I found out how to remove that command line switch. Also the new version now denies access to any mailservers with self-signed certificates, but I won't complain about the added security. Consider filing a bug against that package if the incompatible change is not documented prominently enough by gnutls-cli. Well, --protocols was already declared as obsolete in the manpage that came with squeeze (which I never bothered to read before the upgrade), so I'd say that makes it as prominently documented. cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgp2v1Bq4UZOG.pgp Description: PGP signature
Bug#693273: upgrade-reports: upgrade squeeze - wheezy
Package: upgrade-reports Severity: minor Tags: wheezy Hi, I did the upgrade to wheezy this weekend which went suprisingly well. Only two slight problems I stumbled upon: - My NFSv4-mounted directories lost ownership information (everything set to nobody/nogroup), which I had to fix by manually setting Domain=localdomain in /etc/idmapd.conf (looks like the newer idmapd now uses the real domainname of my machine by default). Also NEED_IDMAPD wasn't set yes in /etc/default/nfs-common after the upgrade, but not sure how it was set before. I only know that I /did/ have idmapd running before the upgrade. - gnutls-cli lost support for option --protocols which my Emacs/Gnus had been configured to using, so Mail retrieval failed until I found out how to remove that command line switch. Also the new version now denies access to any mailservers with self-signed certificates, but I won't complain about the added security. cheers, David -- System Information: Debian Release: wheezy/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpuLsWsFueyr.pgp Description: PGP signature
Bug#693274: pulseaudio: audio playback too fast and only silence
Package: pulseaudio Version: 2.0-6 Severity: normal Hi, after upgrading to wheezy, audio playback worked normally for a few days, but now failed beginning on nov 14. I updated packages regularly and I'd suspect a newer version of pulseaudio triggered the error, as I didn't touch any of the audio-related stuff. The symptoms: Applications won't complain when playing back audio. They just run the playback too quickly (approx 5.75 times as fast as real-time) and no audible audio is actually output on the speakers (complete silence, no noise etc.). This happens consistently when playing via alsa, directly via pulseaudio or via libSDL. I can still play back audio when using the OSS API. Illustrating the issue with command 'play' from package 'sox': $ time play 01_So_What_-_Ast0r.flac -t alsa 01_So_What_-_Ast0r.flac: File Size: 67.5M Bit Rate: 956k Encoding: FLAC Info: http://kindofbloop.com/ Channels: 2 @ 16-bit Track: 1 Samplerate: 44100Hz Album: Kind of Bloop Replaygain: off Artist: Ast0r Duration: 00:09:24.84 Title: So What In:100% 00:09:24.84 [00:00:00.00] Out:24.9M [ | ]Clip:0 Done. real 1m38.126s user 0m8.261s sys 0m2.684s I.e. it Plays back a 9 minutes 24 audio file in 1 minutes 38. Exact same behaviour when playing back with option -t pulseaudio. Playback works when playing with -t oss or -t ossdsp. Same problem when using mplayer for movie playback. Movies play back much too quickly (mplayer uses the audio playback for timing the frames), when playing via -ao pulse, -ao alsa or -ao sdl. Only -ao oss works. I have merely these pulseaudio-related messages in my syslog: ---8--- Nov 15 00:02:05 snail rtkit-daemon[4468]: Successfully made thread 4620 of process 4620 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11. Nov 15 00:02:06 snail rtkit-daemon[4468]: Successfully made thread 4621 of process 4620 (/usr/bin/pulseaudio) owned by '1000' RT at priority 5. Nov 15 00:02:06 snail rtkit-daemon[4468]: Successfully made thread 4622 of process 4620 (/usr/bin/pulseaudio) owned by '1000' RT at priority 5. Nov 15 00:02:06 snail rtkit-daemon[4468]: Successfully made thread 4623 of process 4620 (/usr/bin/pulseaudio) owned by '1000' RT at priority 5. Nov 15 00:02:12 snail rtkit-daemon[4468]: Successfully made thread 4696 of process 4696 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11. Nov 15 00:02:14 snail pulseaudio[4696]: [pulseaudio] pid.c: Daemon already running. ---8--- cheers, David -- System Information: Debian Release: wheezy/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pulseaudio depends on: ii adduser 3.113+nmu3 ii consolekit0.4.5-3.1 ii libasound21.0.25-4 ii libasound2-plugins1.0.25-2 ii libc6 2.13-35 ii libcap2 1:2.22-1.2 ii libdbus-1-3 1.6.8-1 ii libfftw3-33.3.2-3.1 ii libgcc1 1:4.7.1-7 ii libice6 2:1.0.8-2 ii libltdl7 2.4.2-1.1 ii liborc-0.4-0 1:0.4.16-2 ii libpulse0 2.0-6 ii libsamplerate00.1.8-5 ii libsm62:1.2.1-2 ii libsndfile1 1.0.25-5 ii libspeexdsp1 1.2~rc1-6 ii libstdc++64.7.1-7 ii libsystemd-daemon044-5 ii libsystemd-login0 44-5 ii libtdb1 1.2.10-2 ii libudev0 175-7 ii libwebrtc-audio-processing-0 0.1-2 ii libx11-6 2:1.5.0-1 ii libx11-xcb1 2:1.5.0-1 ii libxcb1 1.8.1-2 ii libxtst6 2:1.2.1-1 ii lsb-base 4.1+Debian7 ii udev 175-7 Versions of packages pulseaudio recommends: ii gstreamer0.10-pulseaudio 0.10.31-3 ii pulseaudio-module-x11 2.0-6 ii rtkit 0.10-2 Versions of packages pulseaudio suggests: pn paman none pn paprefs none pn pavucontrol none pn pavumeter none ii pulseaudio-utils 2.0-6 -- no debconf information -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpI6lacbaJ3d.pgp Description: PGP signature
Bug#689136: gforth.el fails to compile with emacs-snapshot
Hi, When having emacs-snapshot installed, the gforth package fails to configure, due to an elisp compilation error: [..] | gforth.el:742:18:Error: Don't know how to compile nil The attached patch removes invocations of `byte-compile' from gforth.el, which rectifies this issue. I'm not sure whether it might have any negative (perfomance, perhaps?) impact. Yes, the patch that you sent will certainly have a noticeable negative impact on the performance of the syntax-highlighting code, which is why I'd vote against it. Googeling for the error in question, it seems that newer Emacs versions error on (byte-compile nil), while older versions silently accept it [1]. For my theory why Emacs may encounters a nil here, see below. Also noteworthy in this context is the following German comment in gforth.el: ; Byte-compile-Code rausschmeißen, Compilieren im Makefile über Emacs ; batch-Modus A rough translation would be get rid of byte-compile code, compile via makefile using Emacs batch mode. This seems to indicate that the original author(s) probably intended a change in the spirit of the attached patch. I might be the author of that comment. That would be more on the long-time todo list, involving a few more changes, also to gforth's Makefile, and also quite a bit more testing. I just notice that Gforth's Debian maintainers already enabled byte-code compilation of the complete gforth.el at install-time, for all installed versions of Emacs. This is different from installing the original gforth from soure. So maybe the (eval-when-compile ...) statement itself evaluates to nil and that is the problem? Does wrapping (eval-when-compile ..) into (or ... 1) change the outcome? It looks like all the byte-compile statements should then really be removed for *Debian's version* of gforth.el, but IMO we shouldn't apply the patch upstream. Our implementation of byte-compiling at load-time has the benefit of working for all installed versions of Emacs and XEmacs, even for Emacs versions installed /after/ gforth was installed. cheers, David [1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2012-07/msg00055.html -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpDsBAaMwFXS.pgp Description: PGP signature
Bug#657400: texlive-latex-extra: dinbrief.sty broken
Package: texlive-latex-extra Version: 2009-10 Severity: normal File: /usr/share/texmf-texlive/tex/latex/dinbrief Hi, I cannot make 'dinbrief' work with debian squeeze. Even the example file supplied by texlive-latex-extra-doc won't work: gunzip -c /usr/share/doc/texlive-latex-extra-doc/latex/dinbrief/example.tex.gz test.tex latex test.tex results in: This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) entering extended mode (./test.tex LaTeX2e 2009/09/24 Babel v3.8l and hyphenation patterns for english, usenglishmax, dumylang, noh yphenation, ngerman, german, german-x-2009-06-19, ngerman-x-2009-06-19, loaded. LaTeX Warning: File `signatur.ps' already exists on the system. Not generating it from this source. (/usr/share/texmf-texlive/tex/latex/dinbrief/dinbrief.cls Document Class/Style 'dinbrief' - Version 1.73 University of Karlsruhe - 2000/03/02 12:49:21 *** dinbrief: Running in LaTeX 2e mode! *** dinbrief: NFSS 2! Document Class: dinbrief 2000/03/02 LaTeX2e class (/usr/share/texmf-texlive/tex/latex/dinbrief/dinbrief.cfg)) (/usr/share/texmf-texlive/tex/generic/german/german.sty v2.5e 1998-07-08) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty (/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty) (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty) (/etc/texmf/tex/latex/config/graphics.cfg) (/usr/share/texmf-texlive/tex/latex/graphics/dvips.def))) ! I can't find file `brfkopf'. l.124 \input brfkopf (Press Enter to retry, or Control-D to exit) I have a lot of stuff that uses dinbrief.sty. Is there any known workaround (other than recode everything to use g-brief2.sty)? cheers, David -- Package-specific info: If you report an error when running one of the TeX-related binaries (latex, pdftex, metafont,...), or if the bug is related to bad or wrong output, please include a MINIMAL example input file that produces the error in your report. Please run your example with (pdf)latex -recorder ... (or any other program that supports -recorder) and send us the generated file with the extension .fls, it lists all the files loaded during the run and can easily explain problems induced by outdated files in your home directory. Don't forget to also include minimal examples of other files that are needed, e.g. bibtex databases. Often it also helps to include the logfile. Please, never send included pictures! If your example file isn't short or produces more than one page of output (except when multiple pages are needed to show the problem), you can probably minimize it further. Instructions on how to do that can be found at http://www.latex-einfuehrung.de/mini-en.html (english) or http://www.latex-einfuehrung.de/mini.html (german) ## minimal input file ## other files ## List of ls-R files -rw-r--r-- 1 root root 1077 Jan 26 00:04 /var/lib/texmf/ls-R -rw-rw-r-- 1 root staff 80 Jan 26 00:04 /usr/local/share/texmf/ls-R lrwxrwxrwx 1 root root 29 Jan 25 23:53 /usr/share/texmf/ls-R - /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 27 Jan 25 23:53 /usr/share/texmf-texlive/ls-R - /var/lib/texmf/ls-R-TEXLIVE lrwxrwxrwx 1 root root 27 Jan 25 23:53 /usr/share/texmf-texlive/ls-R - /var/lib/texmf/ls-R-TEXLIVE ## Config files lrwxrwxrwx 1 root root 20 Jan 25 23:53 /usr/share/texmf/web2c/texmf.cnf - /etc/texmf/texmf.cnf -rw-r--r-- 1 root root 4172 Jan 26 00:04 /var/lib/texmf/web2c/fmtutil.cnf -rw-r--r-- 1 root root 7971 Jan 26 00:04 /var/lib/texmf/web2c/updmap.cfg -rw-r--r-- 1 root root 3709 Jan 26 00:04 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 4 -rw-r--r-- 1 root root 283 Feb 18 2011 mktex.cnf ## md5sums of texmf.d 3875bf0f4a53a29b7f247399dc9833e2 /etc/texmf/texmf.d/05TeXMF.cnf 6e82a3d4c00ae7e4f86aa8dcf9438cf3 /etc/texmf/texmf.d/15Plain.cnf c60a084820a0b73e3bfbf2e90bda437c /etc/texmf/texmf.d/45TeXinputs.cnf ea33127256c6a9f37145ae5b16fdb80c /etc/texmf/texmf.d/55Fonts.cnf afccf1d3f87057411166a77c58e00bd1 /etc/texmf/texmf.d/65BibTeX.cnf 9da7c1c7b1eaf06f941af91f48a23068 /etc/texmf/texmf.d/75DviPS.cnf 7ae52efac46feb97010986e57877d12e /etc/texmf/texmf.d/80DVIPDFMx.cnf 37329819f1109e8a457e64b8b58fecdb /etc/texmf/texmf.d/85Misc.cnf a8952d594677235951d447665ec46e9c /etc/texmf/texmf.d/90TeXDoc.cnf 402d5adb3864c09ed3cd80c0f2131361 /etc/texmf/texmf.d/95NonPath.cnf -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of
Bug#647457: logcheck-database: fix qpopper related filter rules
Package: logcheck-database
Version: 1.3.13
Severity: normal
Tags: patch
On Debian Squeeze the rules installed with logcheck for the qpopper POP3
service seem to be incomplete and outdated. First line connect from
needs to accept an IP-address after the host name. Also I needed to add
two more rules: one to ignore the message Servicing request when
clients connect, and one to ignore the bogus error message Unable to
open bulletin directory '/var/spool/popbull' when mail is read by
clients.
The version of qpopper installed here is 4.0.9.dfsg-1.2.
Patch attached.
cheers,
David
-- System Information:
Debian Release: 6.0.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: mipsel (mips64)
Kernel: Linux 2.6.39.4-dk1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
Index: logcheck.ignore/qpopper
===
--- logcheck.ignore.orig/qpopper 2011-11-02 21:58:04.409495461 +0100
+++ logcheck.ignore/qpopper 2011-11-02 21:58:54.757714318 +0100
@@ -1,6 +1,8 @@
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ in.qpopper\[[0-9]+\]: connect from [._[:alnum:]-]+$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ in.qpopper\[[0-9]+\]: connect from [._[:alnum:]-]+ \([.[:digit:]]{7,15}\)$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ in.qpopper\[[0-9]+\]: \(v[.[:digit:]]+\) POP login by user \[@._[:alnum:]-]+\ at \([._[:alnum:]-]+\) [.[:digit:]]+ \[pop_log.c:244\]$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ in.qpopper\[[0-9]+\]: \[drac\]: login by [@._[:alnum:]-]+ from host [._[:alnum:]-]+ \([.[:digit:]]+\) \[drac.c:[0-9]+\]$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ in.qpopper\[[0-9]+\]: [@._[:alnum:]-]+ at [._[:alnum:]-]+ \([.[:digit:]]+\): -ERR Message [[:digit:]]+ does not exist. \[pop_send.c:289\]$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ in.qpopper\[[0-9]+\]: ([@._[:alnum:]-]+|\(null\)) at [._[:alnum:]-]+ \([.[:digit:]]+\): -ERR Unknown command: \[[:alnum:]]+\. \[pop_get_command.c:152\]$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ in.qpopper\[[0-9]+\]: \(v[.[:digit:]]+\) Unable to get canonical name of client [.[:digit:]]+: Name or service not known \(-2\) \[pop_init.c:1196\]$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ in.qpopper\[[0-9]+\]: \(v[.[:digit:]]+\) Servicing request from [^]+ at [.[:digit:]]{7,15} \[pop_init.c:[0-9]+\]$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ in.qpopper\[[0-9]+\]: Unable to open bulletin directory '/var/spool/popbull': No such file or directory \(2\) \[pop_bull.c:[0-9]+\]$
pgpzN2K5xXtjS.pgp
Description: PGP signature
Bug#608574: same problem here
Same problem here (running Debian Squeeze), I regularly see lots of
messages like:
Nov 1 15:49:22 mosquito dnsmasq-dhcp[17144]: DHCPNAK(vlan3) 192.168.1.171
00:1f:1f:02:74:81 wrong server-ID
Correct fix for logcheck seems to be this line:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dnsmasq-dhcp\[[0-9]+\]:
DHCPNAK\([.[:alnum:]]+\) [.[:digit:]]{7,15} [:[:xdigit:]]{17} wrong server-ID$
cheers,
David
--
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
pgpu6ZEKfFK3F.pgp
Description: PGP signature
Bug#647242: emacs23: Starttls times out with gnutls-cli
Package: emacs23 Version: 23.2+1-7 Severity: normal File: /usr/bin/emacs23 I spent quite some time trying to make Emacs on Debian Squeeze connect to a Pop3 mailbox with starttls with no avail. My Emacs mail configuration is verified to work flawlessly with the Emacs 23.3.1 included in Ubuntu 11.10/amd64, however, with the same home directory mounted into my Squeeze/mipsel machine, mail retrival fails to work. It just gets stuck after Opening STARTTLS connection to `mosquito:110'...done, then times out after 120 seconds, asking Mail source (pop :server mosquito :stream starttls) error (stringp). Continue?. Meanwhile the POP3 server logs: in.qpopper[12658]: (v4.0.9) TLSv1/SSLv3 handshake with client at mosquito.pool (192.168.0.99); new session-id; cipher: AES128-SHA (AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1), 128 bits [pop_tls_openssl.c:547] in.qpopper[12658]: (v4.0.9) Timeout (120 secs) during nw read from at mosquito.pool (192.168.0.99) [popper.c:608] in.qpopper[12658]: (null) at mosquito.pool (192.168.0.99): -ERR POP timeout from mosquito.pool [popper.c:825] I tried to narrow down the problem, but are currently stuck: - The failure occurs with two distinct pop3 servers, one being the debian system itself with 'qpopper' configured for starttls support. - gnutls-cli which is started as process by Emacs starttls.el works flawlessly. Manually starting it as gnutls-cli -s mosquito -p 110 (or gnutls-cli -s mosquito -p 110 --protocols ssl3) I can log into my mailbox without any problems (i.e. I enter 'STLS' RET, then do a 'killall -ALRM gnutls-cli' or press Ctrl-D) - attaching 'strace' to the running Emacs process, I can see that in fact gnutls-cli's TLS negotiation output was correctly read by Emacs: read(16, - Certificate type: X.509\n - Got a certificate list of 1 certificates.\n - Certificate[0] info:\n - subject `CN=mosquito', issuer `CN=mosquito', RSA key 1024 bits, signed using RSA-SHA, activated `2009-01-07 12:57:36 UTC', expires `2019-01-05 12:57:36 UTC', SHA-1 fingerprint `37e8974209ccfe3ea73b371457c827fab68a1f5f'\n- The hostname in the certificate matches 'mosquito'.\n- Peer's certificate issuer is unknown\n- Peer's certificate is NOT trusted\n- Version: SSL3.0\n- Key Exchange: RSA\n- Cipher: AES-128-CBC\n- MAC: SHA1\n- Compression: NULL\n, 4096) = 539 But that is the last time Emacs reads anything from descriptor 16, so I suspect, it gets stuck somewhere in the process input management in 'process.c'. That's a huge mess of code and I didn't wrap my head around it yet. This is running on a Loongson-2f, kernel 2.6.39.4. Pagesize is 16k, but AFAIR pagesize doesn't have any effect on pipe buffering in recent kernels. What else can I do to narrow this down? Is this a known problem? Does it happen on non-mipsel architectures? cheers, David -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: mipsel (mips64) Kernel: Linux 2.6.39.4-dk1 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 emacs23 depends on: ii emacs23-bin-common23.2+1-7 The GNU Emacs editor's shared, arc ii libasound21.0.23-2.1 shared library for ALSA applicatio ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libdbus-1-3 1.2.24-4+squeeze1 simple interprocess messaging syst ii libfontconfig12.8.0-2.1 generic font configuration library ii libfreetype6 2.4.2-2.1+squeeze2 FreeType 2 font engine, shared lib ii libgconf2-4 2.28.1-6 GNOME configuration database syste ii libgif4 4.1.6-9library for GIF images (library) ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgpm2 1.20.4-3.3 General Purpose Mouse - shared lib ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libice6 2:1.0.6-2 X11 Inter-Client Exchange library ii libjpeg62 6b1-1 The Independent JPEG Group's JPEG ii libm17n-0 1.6.1-1a multilingual text processing lib ii libncurses5 5.7+20100313-5 shared libraries for terminal hand ii libotf0 0.9.11-1 A Library for handling OpenType Fo ii libpango1.0-0 1.28.3-1+squeeze2 Layout and rendering of internatio ii libpng12-01.2.44-1+squeeze1 PNG library - runtime ii librsvg2-22.26.3-1 SAX-based renderer library for SVG ii libsm62:1.1.1-1 X11 Session Management library ii libtiff4 3.9.4-5+squeeze3 Tag Image File Format (TIFF) libra ii
Bug#646233: emacs23-lucid: Emacs23-lucid installation fails on mipsel
Package: emacs23-lucid Version: 23.2+1-7 Severity: normal On installation, emacs23-lucid aborts, pointing to the error message in /tmp/elc_hEmQLu.log that reads: emacs23 -q -no-site-file --no-site-file -batch -l path.el -f batch-byte-compile apt-sources.el apt-utils.el debian-bug.el debian-el.el debian-el-loaddefs.el deb-view.el preseed.el emacs23: malloc.c:3097: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd old_size == 0) || ((unsigned long) (old_size) = (unsigned long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) ~((2 * (sizeof(size_t))) - 1))) ((old_top)-size 0x1) ((unsigned long)old_end pagemask) == 0)' failed. Fatal error (6) The normal emacs23 package with gtk interface installs and works. (but I'd still want to use the lighter -lucid version if it worked) This bug seems to be the same problem reported in debian bug #598234 for emacs23-nox (which is tagged 'squeeze-ignore'). cheers, David -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: mipsel (mips64) Kernel: Linux 2.6.39.3-dk6 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 emacs23-lucid depends on: ii emacs23-bin-common23.2+1-7 The GNU Emacs editor's shared, arc ii libasound21.0.23-2.1 shared library for ALSA applicatio ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libdbus-1-3 1.2.24-4+squeeze1 simple interprocess messaging syst ii libfontconfig12.8.0-2.1 generic font configuration library ii libfreetype6 2.4.2-2.1+squeeze1 FreeType 2 font engine, shared lib ii libgif4 4.1.6-9library for GIF images (library) ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgpm2 1.20.4-3.3 General Purpose Mouse - shared lib ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libice6 2:1.0.6-2 X11 Inter-Client Exchange library ii libjpeg62 6b1-1 The Independent JPEG Group's JPEG ii libm17n-0 1.6.1-1a multilingual text processing lib ii libncurses5 5.7+20100313-5 shared libraries for terminal hand ii libotf0 0.9.11-1 A Library for handling OpenType Fo ii libpng12-01.2.44-1+squeeze1 PNG library - runtime ii librsvg2-22.26.3-1 SAX-based renderer library for SVG ii libsm62:1.1.1-1 X11 Session Management library ii libtiff4 3.9.4-5+squeeze3 Tag Image File Format (TIFF) libra ii libx11-6 2:1.3.3-4 X11 client-side library ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar ii libxft2 2.1.14-2 FreeType-based font drawing librar ii libxmu6 2:1.0.5-2 X11 miscellaneous utility library ii libxpm4 1:3.5.8-1 X11 pixmap library ii libxrender1 1:0.9.6-1 X Rendering Extension client libra ii libxt61:1.0.7-1 X11 toolkit intrinsics library pn xaw3dgnone (no description available) ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime emacs23-lucid recommends no packages. Versions of packages emacs23-lucid suggests: pn emacs23-common-non-dfsg none (no description available) -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpQg6USwOaM5.pgp Description: PGP signature
Bug#646106: shorewall6: Shorewall6 not working with unique local IPv6 addresses
Package: shorewall6
Version: 4.4.11.6-1
Severity: normal
I have configured my a router running debian squeeze to use unique local
ip6 addresses (ULA) [1] with prefix 'fd' on all interfaces. These allow
my network to do ipv6 routing between my subnets without any external
ip6 connectivity.
However, shorewall6 currently seems to assert that all routable ip6
address start on '2'. I.e. the .start script generated by shorewall6
checks all interfaces agains interface_is_usable(), which is implemented
as:
interface_is_usable() # $1 = interface
{
[ $1 = lo ] return 0
interface_is_up $1 [ $(find_first_interface_address_if_any $1) != :: ]
run_isusable_exit $1
}
and find_first_interface_address_if_any does:
find_first_interface_address_if_any() # $1 = interface
{
#
# get the line of output containing the first IP address
#
addr=$(${IP:-ip} -f inet6 addr show $1 2 /dev/null | grep 'inet6 2.*
global' | head -n1)
[..]
Here it ignores all addresses that don't start on 2. This results in
shorewall6 startup to fail with 'ERROR: Required interface eth0 not
available'.
[1] http://en.wikipedia.org/wiki/Unique_local_address
cheers,
David
-- System Information:
Debian Release: 6.0.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: mipsel (mips64)
Kernel: Linux 2.6.39.3-dk6
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 shorewall6 depends on:
ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy
ii iproute 20100519-3 networking and traffic control too
ii iptables 1.4.8-3administration tools for packet fi
ii libio-socket-inet6-perl 2.65-1.1 Object interface for AF_INET6 doma
ii shorewall 4.4.11.6-3 Shoreline Firewall, netfilter conf
shorewall6 recommends no packages.
Versions of packages shorewall6 suggests:
ii linux-image-2. 2.6.38-5~bpo60+1 Linux 2.6.38 for Loongson 2F
ii linux-image-2. 2.6.39.3-dk-10.00.Custom Linux kernel binary image for vers
ii linux-image-2. 2.6.39.3-dk2-10.00.Custom Linux kernel binary image for vers
ii linux-image-2. 2.6.39.3-dk3-10.00.Custom Linux kernel binary image for vers
ii linux-image-2. 2.6.39.3-dk4-10.00.Custom Linux kernel binary image for vers
ii linux-image-2. 2.6.39.3-dk5-10.00.Custom Linux kernel binary image for vers
ii linux-image-2. 2.6.39.3-dk6-10.00.Custom Linux kernel binary image for vers
ii make 3.81-8An utility for Directing compilati
ii shorewall-doc 4.4.11-1 documentation for Shoreline Firewa
-- Configuration Files:
/etc/default/shorewall6 changed:
startup=1
OPTIONS=
/etc/shorewall6/shorewall6.conf [Errno 13] Permission denied:
u'/etc/shorewall6/shorewall6.conf'
-- debconf information:
shorewall6/major_release:
shorewall6/dont_restart:
shorewall6/invalid_config:
--
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
pgpz12MhD6kvZ.pgp
Description: PGP signature
Bug#635021: iotop: AssertionError on loongson (mipsel) system
Package: iotop Version: 0.4-2 Severity: normal File: /usr/bin/iotop Trying to run iotop on a a Fuloong 6004 installed with Debian Squeeze mipsel results in the following output: Traceback (most recent call last): File /usr/bin/iotop, line 16, in module main() File /usr/lib/pymodules/python2.6/iotop/ui.py, line 547, in main main_loop() File /usr/lib/pymodules/python2.6/iotop/ui.py, line 537, in lambda main_loop = lambda: run_iotop(options) File /usr/lib/pymodules/python2.6/iotop/ui.py, line 452, in run_iotop return curses.wrapper(run_iotop_window, options) File /usr/lib/python2.6/curses/wrapper.py, line 43, in wrapper return func(stdscr, *args, **kwds) File /usr/lib/pymodules/python2.6/iotop/ui.py, line 444, in run_iotop_window process_list = ProcessList(taskstats_connection, options) File /usr/lib/pymodules/python2.6/iotop/data.py, line 348, in __init__ self.update_process_counts() File /usr/lib/pymodules/python2.6/iotop/data.py, line 404, in update_process_counts stats = self.taskstats_connection.get_single_task_stats(thread) File /usr/lib/pymodules/python2.6/iotop/data.py, line 148, in get_single_task_stats assert reply_length = 288 AssertionError cheers, David -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: mipsel (mips64) Kernel: Linux 2.6.39.3-dk 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 iotop depends on: ii python [python-ctypes] 2.6.6-3+squeeze6 interactive high-level object-orie ii python-support 1.0.10 automated rebuilding support for P iotop recommends no packages. iotop suggests no packages. -- no debconf information -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpDnnWCDMTI1.pgp Description: PGP signature
Bug#635021: iotop: AssertionError on loongson (mipsel) system
Paul == Paul Wise p...@debian.org writes: On Thu, 2011-07-21 at 21:59 +0200, David Kuehling wrote: Trying to run iotop on a a Fuloong 6004 installed with Debian Squeeze mipsel results in the following output: Please try with the Debian Longsoon kernel and then try the version of iotop available in backports/wheezy/sid. That said I think this particular problem is due to your use of a newer kernel with an older iotop. Hi Paul, this is the fastest reply+bugfix I got to a debian bug-report :) Going with the 'iotop' from squeeze-backports fixes the issue. Sorry for the noise, should have tried first. Note that there is no loongson kernel in Squeeze, had to go for backports whose 2.6.38 loongson kernel also made Squeeze's iotop fail. cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpuvJ9zLMcNA.pgp Description: PGP signature
Bug#632863: eglibc: add support for arch powerpcspe
Sebastian == Sebastian Andrzej Siewior bige...@linutronix.de writes: severity 632863 wishlist thanks David Kuehling wrote: Severity: minor I've been this is always wishlist because we are not in main archive. Please use User: debian-powerpc...@breakpoint.cc Usertags: powerpcspe So all ppcspe related bugs are together somehow. Just sent a mail to cont...@bugs.debian.org that should fix it. The attached patch makes eglibc 2.13 work on architecture powerpcspe (an unofficial port hosted on www.debian-ports.org, [1]). Thanks for that. If you have sometime then you could add two files. One of them says which tests-cases are known to fail so if we get another failure it aborts. The second file contains the symbol list for libc. Both were available for ppc the last time I was looking into it. Attached below is an updated version of the patch. - patches in debian/patches/powerpcspe are renamed to branch-* since they were just committed to eglibc svn (branch 2.13, 2.14 and trunk). - added file testsuite-checking/expected-results-powerpc-linux-gnuspe-libc, tested to pass here - added debian/libc6.symbols.powerpcspe, which is currently just copied from debian/libc6.symbols.powerpc running 'dpkg-gensymbols -Pdebian/tmp-libc -plibc6 -v2.13' (output attached below), I get a huge load of deltas involving 'symver' lines like #MISSING: 2.13# (symver|optional)GCC_3.0 2.3.6 (symver|optional)GLIBC_2.1.2 2.1.2 which looks non-critical, but I'm not sure why these aren't suppressed by symbols.wildcards. Filtering that noise, it shows something that looks like permutations in symbol or library order, or just an artefact of the noise lines that makes diff think that stuff lines moved around, although joust noise lines were added in between. No symbols are missing, though, and no symbols have been added. I wonder whether it's the same on normal 'powerpc' builds. cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 diff -Nru --exclude 'locale*' --exclude control.in eglibc-2.13/debian/changelog eglibc-2.13/debian/changelog --- eglibc-2.13/debian/changelog 2011-07-08 14:20:58.0 +0200 +++ eglibc-2.13/debian/changelog 2011-07-08 14:21:12.0 +0200 @@ -1,3 +1,12 @@ +eglibc (2.13-10+powerpcspe1) unstable; urgency=low + + * forward-port powerpcspe-specific changes form 2.11.1-2+powerpcspe1 + * dropped 0002-replace-eieio-with-mbar-on-__SPE__.patch since that +should nowadays be handled by GNU 'as' + * added local-no-fma.patch to fix new compile problem on powerpcspe + + -- David Kuehling dvdkh...@gmx.de Wed, 06 Jul 2011 16:36:54 +0200 + eglibc (2.13-10) unstable; urgency=low * control.in/main: tag libc-bin Essential: yes. diff -Nru --exclude 'locale*' --exclude control.in eglibc-2.13/debian/libc6.symbols.powerpcspe eglibc-2.13/debian/libc6.symbols.powerpcspe --- eglibc-2.13/debian/libc6.symbols.powerpcspe 1970-01-01 01:00:00.0 +0100 +++ eglibc-2.13/debian/libc6.symbols.powerpcspe 2011-07-08 14:21:12.0 +0200 @@ -0,0 +1,12 @@ +#include libc6.symbols.common +ld.so.1 #PACKAGE# #MINVER# +#include symbols.wildcards +### TLS support enabled in Debian upload 2.3.5 + __tls_get_addr@GLIBC_2.3 2.3.5 +libc.so.6 #PACKAGE# #MINVER# +#include symbols.wildcards +### +### Override headers already defined in libc6.symbols.common +### +libpthread.so.0 #PACKAGE# (= 2.3.5), #PACKAGE# #MINVER# +#include symbols.wildcards diff -Nru --exclude 'locale*' --exclude control.in eglibc-2.13/debian/patches/powerpcspe/branch-no-fma.patch eglibc-2.13/debian/patches/powerpcspe/branch-no-fma.patch --- eglibc-2.13/debian/patches/powerpcspe/branch-no-fma.patch 1970-01-01 01:00:00.0 +0100 +++ eglibc-2.13/debian/patches/powerpcspe/branch-no-fma.patch 2011-07-08 14:21:12.0 +0200 @@ -0,0 +1,16 @@ +Override s_fma[f] assembly routines with C-code when compiling for powerpcspe. + +Signed-off-by: David Kuehling dvdkhlng AT gmx DOT de + +Index: eglibc-2.13/ports/sysdeps/powerpc/powerpc32/e500/fpu/s_fma.c +=== +--- /dev/null 1970-01-01 00:00:00.0 + eglibc-2.13/ports/sysdeps/powerpc/powerpc32/e500/fpu/s_fma.c 2011-07-06 16:47:39.0 +0200 +@@ -0,0 +1 @@ ++#include math/s_fma.c +Index: eglibc-2.13/ports/sysdeps/powerpc/powerpc32/e500/fpu/s_fmaf.c +=== +--- /dev/null 1970-01-01 00:00:00.0 + eglibc-2.13/ports/sysdeps/powerpc/powerpc32/e500/fpu/s_fmaf.c 2011-07-06 16:47:39.0 +0200 +@@ -0,0 +1 @@ ++#include math/s_fmaf.c diff -Nru --exclude 'locale*' --exclude control.in eglibc-2.13/debian/patches/powerpcspe/branch-Powerpc-trampline-consider-__NO_FPRS__.patch eglibc-2.13/debian/patches/powerpcspe/branch-Powerpc-trampline-consider-__NO_FPRS__.patch --- eglibc-2.13/debian/patches/powerpcspe/branch
Bug#632863: eglibc: add support for arch powerpcspe
Source: eglibc Version: 2.13-10 Severity: minor Tags: sid, patch The attached patch makes eglibc 2.13 work on architecture powerpcspe (an unofficial port hosted on www.debian-ports.org, [1]). It adds two patches in debian/patches/powerpcspe that fix some floating-point related issues (powerpcspe uses a different FPU than powerpc). There should not be any effects on non-powerpcspe builds. cheers, David [1] http://wiki.debian.org/PowerPCSPEPort -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 diff -u eglibc-2.13/debian/changelog eglibc-2.13/debian/changelog --- eglibc-2.13/debian/changelog +++ eglibc-2.13/debian/changelog @@ -1,3 +1,12 @@ +eglibc (2.13-10+powerpcspe1) unstable; urgency=low + + * forward-port powerpcspe-specific changes form 2.11.1-2+powerpcspe1 + * dropped 0002-replace-eieio-with-mbar-on-__SPE__.patch since that +should nowadays be handled by GNU 'as' + * added local-no-fma.patch to fix new compile problem on powerpcspe + + -- David Kuehling dvdkh...@gmx.de Wed, 06 Jul 2011 16:36:54 +0200 + eglibc (2.13-10) unstable; urgency=low * control.in/main: tag libc-bin Essential: yes. diff -u eglibc-2.13/debian/patches/series eglibc-2.13/debian/patches/series --- eglibc-2.13/debian/patches/series +++ eglibc-2.13/debian/patches/series @@ -171,6 +171,9 @@ powerpc/local-libgcc_eh-ld.so.diff +powerpcspe/submitted-Powerpc-trampline-consider-__NO_FPRS__.patch +powerpcspe/submitted-no-fma.patch + s390/submitted-nexttowardf.diff s390/cvs-iconv-z9-109.diff only in patch2: unchanged: --- eglibc-2.13.orig/debian/patches/powerpcspe/submitted-Powerpc-trampline-consider-__NO_FPRS__.patch +++ eglibc-2.13/debian/patches/powerpcspe/submitted-Powerpc-trampline-consider-__NO_FPRS__.patch @@ -0,0 +1,48 @@ +From 5f2110f9ce203c42aadc3968ddc487a8c9cc6c83 Mon Sep 17 00:00:00 2001 +From: Sebastian Andrzej Siewior bige...@linutronix.de +Date: Sat, 15 May 2010 21:51:49 +0200 +Subject: [PATCH] Powerpc/trampline: consider __NO_FPRS__ + +don't save/restore FPRs on FPR less systems + +Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de +--- + sysdeps/powerpc/powerpc32/dl-trampoline.S |4 + 1 files changed, 4 insertions(+), 0 deletions(-) + +Index: eglibc-2.13/sysdeps/powerpc/powerpc32/dl-trampoline.S +=== +--- eglibc-2.13.orig/sysdeps/powerpc/powerpc32/dl-trampoline.S 2006-08-17 03:18:26.0 +0200 eglibc-2.13/sysdeps/powerpc/powerpc32/dl-trampoline.S 2011-07-06 16:46:14.0 +0200 +@@ -137,6 +137,7 @@ + stw r9,40(r1) + stw r10,44(r1) + stw r0,8(r1) ++#ifndef __NO_FPRS__ + # Save the floating point registers + stfd fp1,48(r1) + stfd fp2,56(r1) +@@ -146,6 +147,7 @@ + stfd fp6,88(r1) + stfd fp7,96(r1) + stfd fp8,104(r1) ++#endif + # XXX TODO: store vmx registers + # Load the extra parameters. + addi r6,r1,16 +@@ -169,6 +171,7 @@ + lwz r4,20(r1) + lwz r3,16(r1) + lwz r0,12(r1) ++#ifndef __NO_FPRS__ + # Load the floating point registers. + lfd fp1,48(r1) + lfd fp2,56(r1) +@@ -178,6 +181,7 @@ + lfd fp6,88(r1) + lfd fp7,96(r1) + lfd fp8,104(r1) ++#endif + # ...unwind the stack frame, and jump to the PLT entry we updated. + addi r1,r1,320 + bctr only in patch2: unchanged: --- eglibc-2.13.orig/debian/patches/powerpcspe/submitted-no-fma.patch +++ eglibc-2.13/debian/patches/powerpcspe/submitted-no-fma.patch @@ -0,0 +1,16 @@ +Override s_fma[f] assembly routines with C-code when compiling for powerpcspe. + +Signed-off-by: David Kuehling dvdkhlng AT gmx DOT de + +Index: eglibc-2.13/ports/sysdeps/powerpc/powerpc32/e500/fpu/s_fma.c +=== +--- /dev/null 1970-01-01 00:00:00.0 + eglibc-2.13/ports/sysdeps/powerpc/powerpc32/e500/fpu/s_fma.c 2011-07-06 16:47:39.0 +0200 +@@ -0,0 +1 @@ ++#include math/s_fma.c +Index: eglibc-2.13/ports/sysdeps/powerpc/powerpc32/e500/fpu/s_fmaf.c +=== +--- /dev/null 1970-01-01 00:00:00.0 + eglibc-2.13/ports/sysdeps/powerpc/powerpc32/e500/fpu/s_fmaf.c 2011-07-06 16:47:39.0 +0200 +@@ -0,0 +1 @@ ++#include math/s_fmaf.c pgpHOuBDOg8V9.pgp Description: PGP signature
Bug#627179: multistrap: Using retainsources=dir does not retain some sources
Neil == Neil Williams codeh...@debian.org writes: A version mismatch will occur exacty when a mirror update ocurred in between the download of sources.bz2 and packages.bz2. You want to tell me that this is not possible, however your description of the process makes it look like it is possible, though unlikely. How? apt opens the sockets and then starts the download. If the file changes, the download will abort. Both sockets are open before the download starts. Therefore, if the files download successfully, the files must be in the same state as when the sockets were originally opened. Are you trying to say that files change in the microsecond between the creation of one socket and the creation of the next socket on a multi-core server?? [..] Which, apart from the time which elapses between the opening of one socket and the opening of the next is already implemented. Maybe if *I* ran a multi-core server and sit on the same LAN as debian's mirror, opening of two sockets would be nearly synchronous and happen in a microsecond. However, I'm pretty far away from the server, the 3-way handshake to open a socket can vary a lot in its timing depending on latencies and packet error rate. With a realistic socket setup jitter of 100ms and one mirror update per day, you'll fetch the wrong index file once in about 10^6 downloads. Relying on uncontrollable network parameters for avoiding races sounds like a bad idea to me. Betting on non-deterministic software to function, because malfunctioning looks unlikely, is not the best idea as well. cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpq7Xyocaa79.pgp Description: PGP signature
Bug#627179: multistrap: Using retainsources=dir does not retain some sources
Neil == Neil Williams codeh...@debian.org writes: Could you have a look at the current SVN revision and let me know how that matches your tests? I just tested with r8024 and it now seems to correctly retrieve all source packages (i.e. the files in the retainsources directory now pass the debparanoia license check). cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgp6r5DQeCULN.pgp Description: PGP signature
Bug#627179: multistrap: Using retainsources=dir does not retain some sources
Neil == Neil Williams codeh...@debian.org writes: Thought I'd just point out where my paranoia about proper source version matching comes from: * we're using architecture powerpcspe from debian-ports. debian-ports doesn't carry sources, and is out of sync with normal debian mirrors, which makes it pretty difficult to satisfy the GPL. * we're using our own, custom mirroring tool [1] to overcome the limitations of debian-ports. this tool is named 'debparanoia' for a reason, as it double checks that matching source packages are present for all .debs. * Since debparanoia is used for mirroring as well as for license-checking our images, I dont't really care if multistrap does the source package version check. I just thought it would be good anyways to eliminate the slightest chance of 'apt-get source' not satisfying the GPL by getting wrong package versions, without the user noticing. Below I'll try again to prove my point, sorry if this is getting off topic and wasting your time :) On Wed, 15 Jun 2011 23:22:25 +0200 David Kuehling dvdkh...@gmx.de wrote: Are you assuming a non-changing archive? No, I'm assuming a decent mirroring tool. There is also a need to understand exactly what apt is doing with apt-get source. I don't think you've got that clear. I'm sorry if I gave the impression of not understanding apt nor archives :) Maybe last mail just written to hastily. I think I understand that stuff pretty well. As soon as the archive changes non-atomically (with locking applied by the client) I think we're doomed. Broken mirror resulting from an inadequate mirroring tool. Not something which either apt or multistrap can fix or avoid. I'm willing to believe that debian mirror updates are atomic. [..] * Concurrently I run 'multistrap' which runs 'apt-get update', fetching dists/sid/main/binary-amd64/Packages.bz2 and sid/main/source/Sources.bz2 . * Now I get Packages.bz2 from before the mirror update, and Sources.bz2 from after the mirror update. No you don't. You get Packages.bz2 and Sources.bz2 in sync at the same time in the same apt-get update call. Indeed in most cases, as apt is using parallel connections, Packages and Sources are downloaded at the same time over multiple sockets. What happens afterwards is that apt-get source uses that cached data to get the sources. Well this is the part that only works if you cross your fingers. Nothing guarantees that 'apt-get update' schedules the packages.bz2 and sources.bz2 for synchronous download. In fact typing in 'apt-get update' on my pc, it first downloads 4 Sources files, then 4 Packages files for me. This race can be detected by checking Packages.bz2 and Sources.bz2 with the checksums present in the Release. Not sure whether that's implemented. For me 'multistrap' happily uses repositories without checksums in the Release file. If a new version has arrived in the meantime then the old source (the same version as the version of the binary downloaded earlier) will still be obtained because apt only has cached data for the downloaded source version, the Sources file already downloaded before the new version arrived. In most cases, the old version will remain for at least 10 days because it's the version currently in testing. [..] I do not contest that debian archives carry source packages for all binary packages in the pool. I only contest that the .deb packages referenced by apt's cache do not neccessarily match the source packages referenced the cache. This condition would result in license violation for people who rely on 'apt-get source' to satisfy the GPL. A version mismatch will occur exacty when a mirror update ocurred in between the download of sources.bz2 and packages.bz2. You want to tell me that this is not possible, however your description of the process makes it look like it is possible, though unlikely. The only way to prevent such a race would be to either (a) prevent mirror updates (i.e. 'lock' the archive) during 'apt-get update' sessions, or (b) to guarantee that Sources.bz2 and Packages.bz2 download starts at exactly the same point in time. I think neither (a) nor (b) can be implemented. You can only implement (c): ensure consistency with checksums in the release file, and retry download ad infinitum, until checksums match. Sources.bz2 is going to have some packages updated to newer versions, and won't correspond 100% to binaries from Packages.bz2, thus violating the GPL Not true - unless you're talking about waiting for packages to arrive from the buildd's, but that is a very small space of time normally and if that bothers you, just don't use unstable for the kind of tasks where you need synchronised sources. Unstable does NOT make that promise and there is nothing apt or multistrap can do about it. Note that I wasn't talking about packages in the pool, but only about the indices that were snapshotted by 'apt-get update'. Of course I
Bug#627179: multistrap: Using retainsources=dir does not retain some sources
Neil == Neil Williams codeh...@debian.org writes: On Wed, 18 May 2011 15:09:44 +0200 David Kuehling dvdkh...@gmx.de wrote: the attached patch (mostly) fixes bug #627179 [1]. Patch is against multistrap SVN head [2]. The patch looks interesting but incomplete and possibly misleading. I understand that it's incomplete, but I do not think it is more 'misleading' than the code that it attempts to fix :) The patch misses one occurence of the bug, when multistrap looks at var/lib/dpkg/status looking for Source: headers only (ignoring Version: and Package:). Fixing that feels like beyond my perl skills, and I'm not sure that this whole part is required anyways (it's redandant with checking the downloaded .debs). For now I put a big Todo: comment on top. Think about this more carefully. The situation is that multistrap is stateless and something can have happened which means that the run when the packages are actually downloaded failed at a later stage (e.g. in the hooks or setupscript) and then got fixed. So a later run of multistrap still needs to go through the status file (because the .debs have been unpacked and deleted) to check if some source packages still need to be downloaded. apt-get install will check the status file and report that it the packages are already at the newest version, without downloading anything, so the list has to come from somewhere else. i.e. the list of downloaded debs is untrustworthy and must be regarded as incomplete. Ok, if this is the case, then why do we have to collect source packages (dsclist) at 3 places in multistrap.conf . Won't it be sufficient to just do it once, when parsing the status file? That said, for me the patch fixes the problem with missing sources for the multistrap.conf I test with. More testing required. I hope to get some time to look at this soon but it needs a lot more thought. I'm willing to invest the time to fix it, everything is better than maintaining my own version of debian stuff. The patch also fixes another bug, not yet reported: multistrap could have fetched source packages versions that differ from the binary package versions. That is more about differences in aptsources and debootstrap lines than anything to do with specifying the version. I don't think your patch actually works here. apt-get source will get the latest, just as apt-get install will get the latest. What changes is whether the call is made when aptsources are active or when bootstrap sources are active. It needs to be bootstrap sources. I'd need to have a real example of where apt-get install will download a different version to what apt-get source will download for the same sources - that would be a bug in apt, not multistrap. (Multistrap creates deb-src lines for each source specified, so the versions are expected to be the same from deb to deb-src or else there are problems with the archive.) That's exactly the problem: inconsistent versions in the archive or archive updates while multistrap runs. With the current implementation those won't be detected. IMO this is a severe error that can cause commercial distributors of images real pain due to the resulting GPL violation. So what work needs to be done for the patch to be accepted? - Drop the explicit versioning of source packages? - Fix the parsing of var/lib/dpkg/status in tidy_apt to use package-name in case that Source: is not present - what else did I miss? cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpgNDvu4Ikyc.pgp Description: PGP signature
Bug#627179: multistrap: Using retainsources=dir does not retain some sources
Neil == Neil Williams codeh...@debian.org writes: Error handling is the main reason. Unpacking might fail, the archives might be the only source of data. Could you have a look at the current SVN revision and let me know how that matches your tests? I'm going to have a look at it and test this stuff on friday. That's exactly the problem: inconsistent versions in the archive or archive updates while multistrap runs. That sounds like a broken archive. I haven't implemented the versioned source call - I remain unconvinced that a valid archive would cause the download of a source package of a different version to the binary package. Are you assuming a non-changing archive? As soon as the archive changes non-atomically (with locking applied by the client) I think we're doomed. As we're building images from debian sid, changes will be pretty common. I'm not sure how many times 'multistrap' performs 'apt-get update'. Even if it only does it once, the source and binary package indices are distinct files, and they are retrieved by distinct transaction from the ftp/http server, so I see no way that you can guarantee consistency during mirror pushes. The only atomicity you have is for updating a single index file via 'mv'. The following scenario: * mirror gets updated, probably first new files put into the pool, then the new indices follow, then even later, it's going to delete the files no longer referenced by the indices. * Concurrently I run 'multistrap' which runs 'apt-get update', fetching dists/sid/main/binary-amd64/Packages.bz2 and sid/main/source/Sources.bz2 . * Now I get Packages.bz2 from before the mirror update, and Sources.bz2 from after the mirror update. Sources.bz2 is going to have some packages updated to newer versions, and won't correspond 100% to binaries from Packages.bz2, thus violating the GPL Of course I guess the error rate will not be too high, at least not over a normal high-rate internet connection. cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpjbDIxwAMg7.pgp Description: PGP signature
Bug#627179: [PATCH] fix #627179 (multistrap misses some source packages)
Hi,
the attached patch (mostly) fixes bug #627179 [1]. Patch is against
multistrap SVN head [2].
The patch misses one occurence of the bug, when multistrap looks at
var/lib/dpkg/status looking for Source: headers only (ignoring Version:
and Package:). Fixing that feels like beyond my perl skills, and I'm
not sure that this whole part is required anyways (it's redandant with
checking the downloaded .debs). For now I put a big Todo: comment on
top.
That said, for me the patch fixes the problem with missing sources for
the multistrap.conf I test with.
The patch also fixes another bug, not yet reported: multistrap could
have fetched source packages versions that differ from the binary
package versions.
cheers,
David
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627179
[2] http://www.emdebian.org/svn/current/host/trunk/multistrap/trunk
--
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
Index: multistrap
===
--- multistrap (revision 8004)
+++ multistrap (working copy)
@@ -465,6 +465,28 @@
}
}
+sub get_corresponding_dsc {
+my $debfile = shift;
+my $ver=`LC_ALL=C dpkg -f $debfile Version`;
+my $pkg=`LC_ALL=C dpkg -f $debfile Package`;
+my $src=`LC_ALL=C dpkg -f $debfile Source`;
+
+chomp ($ver);
+chomp ($pkg);
+chomp ($src);
+
+if ($src =~ / \((.*)\)/) {
+ # source nanme contains an explicit version number in parens. use it.
+ $ver = $1;
+ $src =~ s/ \(.*\)//;
+} elsif ($src eq ) {
+ # no 'Source:' line. use package name instead.
+ $src = $pkg
+}
+
+return ${src}=${ver};
+}
+
sub force_unpack {
my (@limits) = @_;
my %unpack=();
@@ -521,13 +543,9 @@
printf (_g(Using directory %s for unpacking operations\n), $dir);
foreach $deb (sort @archives) {
printf (_g(I: Extracting %s...\n), $deb);
- my $ver=`LC_ALL=C dpkg -f ./${cachedir}archives/$deb Version`;
my $pkg=`LC_ALL=C dpkg -f ./${cachedir}archives/$deb Package`;
- my $src=`LC_ALL=C dpkg -f ./${cachedir}archives/$deb Source`;
my $multi=`LC_ALL=C dpkg -f ./${cachedir}archives/$deb Multi-Arch`;
- chomp ($ver);
chomp ($pkg);
- chomp ($src);
chomp ($multi);
if (($multi eq foreign) or ($multi eq allowed)) {
$multi = '';
@@ -548,7 +566,7 @@
warn ($msg\n);
$multi = '';
}
- $src =~ s/ \(.*\)//;
+ my $src = get_corresponding_dsc ./${cachedir}archives/${deb};
push @dsclist, $src;
mkdir (./tmp);
my $tmpdir = `mktemp -p ./tmp -d -t multistrap.XX`;
@@ -760,7 +778,7 @@
next if (-d $file);
next unless ($file =~ /\.deb$/);
if (defined $sourcedir) {
-my $srcname = `LC_ALL dpkg -f ${dir}${cachedir}archives/$file Source`;
+my $srcname = get_corresponding_dsc ${dir}${cachedir}archives/$file;
chomp ($srcname);
push @dsclist, $srcname;
system (mv ${dir}${cachedir}archives/$file $sourcedir/$file);
@@ -775,6 +793,12 @@
open (STATUS, ${dir}${dpkgdir}status);
my @lines=STATUS;
close (STATUS);
+ # Todo: this is (still) broken: need to look at Package:,
+ # Version: and Source: to determine the correct .dsc name.
+ # look at get_corresponding_dsc() for details. Note
+ # however, that this code is somewhat redundant, since
+ # .dsc names are already determined from downloaded .deb
+ # files.
foreach my $line (@lines) {
if ($line =~ /^Source: (.*)$/) {
my $c = $1;
pgp5Abi3WOkd2.pgp
Description: PGP signature
Bug#612913: [PATCH] fix unionfs-fuse support
At the end of march I send patches fixing #612913 to the debian-live mailinglist. Looks like my email was forgotten. This took me some time to figure out, maybe you could finally merge that stuff (or tell me how to improve it)? Here is the mail in question: http://lists.debian.org/debian-live/2011/03/msg00269.html The Git-branch with my fixes is at: https://github.com/dvdkhlng/live-boot/ also have look the email thread for more info. cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpotoxbnK17L.pgp Description: PGP signature
Bug#627179: multistrap: Using retainsources=dir does not retain some sources
Package: multistrap
Severity: normal
looks like multistrap 2.1.13 (from svn) is incapable of downloading
source for some packages. For example source-code for bash is missing
when used with Ubuntu Lucid repositories.
The problem seems to be caused by multistrap querying the 'Source' field
of the corresponding binary packages to see what source-packages to
get. Some packages do not have any 'Source' field, in which case the
binary Package name ought to be used.
i.e. multistrap line 527:
my $src=`LC_ALL=C dpkg -f ./${cachedir}archives/$deb Source`;
should fall back to using $deb if $src is not set.
cheers,
David
--
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
pgpHW1JY9HH8l.pgp
Description: PGP signature
Bug#624189: snapshot.debian.org: Accessing files by hash broken for a few files
Package: snapshot.debian.org Severity: normal Hi, I'm using the snapshot mirror to collect matching source packages for packages on the unofficial debian-ports repositories (at least for those packages where sources in normal debian repos do not match). Stumbled into a problem with a file that I cannot download, with snapshot.debian.org just closing the connection without headers nor data: export http_proxy= wget -S http://snapshot.debian.org/file/18875e19f017fa3ed747eea29033904e7ad11d02 Resolving snapshot.debian.org... 193.62.202.30, 206.12.19.150 Connecting to snapshot.debian.org|193.62.202.30|:80... connected. HTTP request sent, awaiting response... No data received. Retrying. ... cheers, David -- GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpPjctOz4Fjc.pgp Description: PGP signature
Bug#619959: multistrap: Incomplete support for 'flat' repositories
Package: multistrap
Version: 2.1.12
Severity: normal
Multistrap recently got support for 'flat' repositories. However, at
one location in the code, this support is missing (or broken).
/usr/sbin/multistrap, line 406 reads:
$component = (defined $components{$aptsrc}) ? $components{$aptsrc}
: (exists $flatfile{$aptsrc}) ? : main;
Compare this to the correct (?) line 236:
$component = (exists $flatfile{$aptsrc}) ?
: (defined $components{$aptsrc}) ? $components{$aptsrc} :
main;
As a result, a multistrap configuration snippet like this:
[Mtronix]
packages=live-boot live-boot-initramfs-tools
source=http://server/debian-local/ unstable/
Uses the apt source correctly during the bootstrap phase, but then
generates an invalid sources.list entry and puts that in the chroot.
Something like:
deb http://server/debian-local/ unstable/ main
See also the mailing-list thread about the problem:
http://lists.debian.org/debian-embedded/2011/03/msg00124.html
cheers,
David
--
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
pgpbYDzSreYOk.pgp
Description: PGP signature
Bug#611249: gcc-4.4: Fix PR44606 concerning powerpcspe architecture
Sebastian == Sebastian Andrzej Siewior bige...@linutronix.de writes: * David Kuehling | 2011-01-27 11:57:58 [+0100]: Hi, the attached .debdiff fixes PR44606 [1], a register-allocation bug that (seldomly) miscompiles floating point code in the unofficial powerpcspe port [2]. This is a backport of commit 168347 from GCC svn [3]. Thanks for that. We have a few other patches which are part of trunk but not part of stable branches. So we need to consider those as well or we brake things what were working. Attached is a .debdiff against 4.4.4-4+powerpcspe4.5 as found in debian-ports/pool-powerpcspe/main/g/gcc-4.4/ . The patch modifies debian/rules.patch to only apply the patch on powerpcspe, so there should be no side-effects on other architectures. Not sure if this is wise. Not sure either. Changed it to now apply pr44606.diff independent of architecture (see the debdiff). Just wondering: is it generally a bad idea to file bugs against powerpcspe specific versions of packages with the debian BTS? Changed the gcc version of the bug report to 4.4.4-4+powerpcspe4.5 . cheers, David -- GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pr44606+powerpcspe.diff Description: Binary data pgpKDAIV1aKYG.pgp Description: PGP signature
Bug#611249: gcc-4.4: Fix PR44606 concerning powerpcspe architecture
Package: src:gcc-4.4 Version: 4.4.5-9 Severity: normal Tags: patch Hi, the attached .debdiff fixes PR44606 [1], a register-allocation bug that (seldomly) miscompiles floating point code in the unofficial powerpcspe port [2]. This is a backport of commit 168347 from GCC svn [3]. The patch modifies debian/rules.patch to only apply the patch on powerpcspe, so there should be no side-effects on other architectures. I verified the patch to compile and be effective on a powerpcspe sid installation running on a P2020RDB development board. I guess the same patch should go into gcc-4.3 as well, going to post a corresponding bug report in the next days. cheers, David [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606 [2] http://wiki.debian.org/PowerPCSPEPort [3] http://gcc.gnu.org/viewcvs?view=revisionrevision=168347 -- GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pr44606.debdiff Description: Binary data pgpm2CSBKvTm6.pgp Description: PGP signature
Bug#611249: gcc-4.4: Fix PR44606 concerning powerpcspe architecture
Sebastian == Sebastian Andrzej Siewior bige...@linutronix.de writes: * David Kuehling | 2011-01-27 11:57:58 [+0100]: Hi, the attached .debdiff fixes PR44606 [1], a register-allocation bug that (seldomly) miscompiles floating point code in the unofficial powerpcspe port [2]. This is a backport of commit 168347 from GCC svn [3]. Thanks for that. We have a few other patches which are part of trunk but not part of stable branches. So we need to consider those as well or we brake things what were working. Thanks for pointing that out. I got the GCC source to patch against from standard debian repository, since debian-ports does not carry sources. Now I realized, that there is a .diff.gz in pool-powerpcspe/main/g/gcc-4.4/. Is there some easy and straight-forward way to grab corresponding source packages in a powerpcspe system? Going to try to build a fixed gcc via the ppcspe specific source. Any plans to move your patches into the normal gcc package? The patch modifies debian/rules.patch to only apply the patch on powerpcspe, so there should be no side-effects on other architectures. Not sure if this is wise. There is an _all package which containts the patched source. This source is used afaik for gcj. So this would work for +powerpcspe package but won't work in the official debian package. Hmm, the complexity of debian's gcc building starts giving me headaches. I saw that there were many arch-specific patches already in rules.patch, so thought that was standard practice. Are you sure this is a problem? Are you sure patches are applied before building the _all package? According to READEM.maintainers: When we build from the gcc-4.3 source package, we produce, among many others, a gcc-4.3-source binary package that contains the pristine upstream tarball and some Debian-specific patches. Any user can then install this package on their Debian system, and will have the full souces in /usr/src/gcc-4.3/gcc-timestamp.tar.bz2, along with the Makefile snippets that unpack and patch them. [..] The second step is to unpack the GCC source tarball. This tarball is either in the build directory (when building gcc-4.3), or in /usr/src/gcc-4.3/gcc-timestamp.tar.bz2 (when building the other source packages). The fourth step is to select which patches to apply (this is done in debian/rules.defs), and then to apply the selected patches (see debian/rules.patch). So that sounds like most of the patches being applied on top of the gcc-4.4-source package when building gcc, gcj etc. I verified the patch to compile and be effective on a powerpcspe sid installation running on a P2020RDB development board. cool. I guess the same patch should go into gcc-4.3 as well, going to post a corresponding bug report in the next days. No, I'm dropping gcc-4.3. There is little need in keeping it as all software compiles with 4.4+ Ok. I heared from colleagues, that gcc-4.3 were more stable then 4.4, but maybe that's just broken code on our sides and I'll try to make sure that we drop 4.3, too. cheers, David -- GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpNMoePN6TrS.pgp Description: PGP signature
Bug#605474: upgrade-reports: Lenny-Squeeze upgrade side-effects on backup2l
Package: upgrade-reports Severity: normal After upgrading to Squeeze, backup2l created a level-2 backup that contains /all/ files to backup, instead of just the few files that actually changed. So something in the new version of backup2l (or bash, or find or ls?) messes with the algorithm that backup2l employs to check for whether files have changed (date/time/size?). After the one oversized backup, following differential backups have a usually small size, so the problem is only visible when backup2l creates a differential backup against a backup that was created with lenny. So actually I'm seeing the problem twice: once for the level-2 backup that diffed against the previous level-2 backup created with lenny. Then a week later when Squeeze creates a new level-1 backup against the earlier level-1 backup also created by lenny. Quite a lot of wasted disk space + bandwidth. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpltRtoMjJil.pgp Description: PGP signature
Bug#604814: upgrade-reports: Upgrade lenny to squeeze mostly successful
Julien == Julien Cristau jcris...@debian.org writes: On Wed, Nov 24, 2010 at 14:53:59 +0100, David Kuehling wrote: Upgraded my system a few days ago. No severe problems during upgrade. Just afterwards the pop3 server 'qpopper' is not working any more. Attempts to retrieve Email via pop3 from my debian system fail and leave the following error message in the logs: [..] This is 548383. I've just upgraded its severity, thanks for the report. The fix attached to 548383 worked for me; i.e. I just replaced /etc/pam.d/qpopper with the two lines @include common-auth @include common-account Thanks for the hint, cheers, David pgpay8VBHUs0T.pgp Description: PGP signature
Bug#604814: [pkg-cryptsetup-devel] Bug#604814: upgrade-reports: Upgrade lenny to squeeze mostly successful
Hi, first let me thank you all for the quick and helpful responses. Jonas Meurer jo...@freesources.org writes: Weird. Maybe the cryptsetup or initramfs-tools maintainer will have an idea. for some reason, $script seems to contain a space. David, please apply attached patch to /usr/share/initramfs-tools/scripts/local-top/cryptroot and see, whether that fixes the bug for you. you can try this by invoking 'update-initramfs -u' after applying the patch. $ patch --dry-run cryptroot-script.diff patching file cryptroot Hunk #1 FAILED at 8. Hunk #2 FAILED at 90. Hunk #3 FAILED at 198. Hunk #4 FAILED at 226. Hunk #5 FAILED at 258. 5 out of 5 hunks FAILED -- saving rejects to file cryptroot.rej Ok, Squeeze seems to be a qickly moving target: $ apt-get update apt-get upgrade $ patch cryptroot-script.diff patching file cryptroot $update-initramfs -u update-initramfs: Generating /boot/initrd.img-2.6.32-5-686 cryptsetup: WARNING: target sda2_crypt has a random key, skipped Seems to fix the problem. Didn't yet try to reboot my system, though. cheers, David -- GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgptqGOw56D7f.pgp Description: PGP signature
Bug#388626: g++-4.1: ICE on source with template
Package: g++-4.1
Version: 4.1.1-5
Severity: normal
Debian (testing) g++-4.1 fails to compile a simple C++ source that makes
use of templates and quits with an internal compiler error:
$ g++-4.1 -Wall -c gcc-4-bug.ii
gcc-4-bug.cc: In function ‘int label(int) [with bool neighb8 = true]’:
gcc-4-bug.cc:21: internal compiler error: in make_decl_rtl, at varasm.c:883
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
Preprocessed source stored into /tmp/ccANp0rz.out file, please attach this to
your bugreport.
The stripped down and preprocessed source that's used to demonstrate the
error ('gcc-4-bug.ii') is attached to this mail.
As a workaround, the source can be compiled using g++-3.4, but that
might cause trouble when other C++ libraries are linked into the
resulting executable (ABI incompatability).
Note that compilation with g++-4.0 fails as well.
regards,
David
--
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
gcc-4-bug.ii
Description: Binary data
