Bug#910696: Dangling link still present as of openjdk version 11.0.1+13-2~bpo9+1.
Hello, all, installing Package: openjdk-11-jdk Version: 11.0.1+13-2~bpo9+1 and Package: openjdk-11-source Version: 11.0.1+13-2~bpo9+1 still shows the problem: The former produces a dangling symbolic link to where the latter has nothing. Regards, and thank you for providing fine software, Andreas signature.asc Description: OpenPGP digital signature
Bug#910857: Race condition when rapidly starting many KVMs: binding socket to 127.0.0.1:5900 failed
Package: libvirt-daemon
Version: 3.0.0-4+deb9u3
Followup-For: Bug #910857
Hello,
I ran into a race condition today which may be the same as discussed
in this bug.
What I did: I started several KVM VMs in parallel. This rather
reliably triggers an error. The error message I see (split into
shorter lines for readability):
ERROR internal error: process exited while connecting to monitor:
((null):24104): Spice-Warning **:
reds.c:2524:reds_init_socket:
reds_init_socket: binding socket to 127.0.0.1:5900 failed
Workaround: Start the machines one at a time.
How to reproduce the error:
# for i in 1 2 3; do virt-install --name node$i
--network=bridge:docker0,mac=52:54:00:a1:9c:0$i --boot=hd,network --memory=2048
--vcpus=1 --disk pool=default,size=10 --os-type=linux --os-variant=generic
--noautoconsole --events on_poweroff=preserve & done
Replacing the "&" with a ";" cures the problem.
Background information: I'm experimenting with a DHCP server that is
running in a docker container. I expect my newly-born KVM nodes to
interact with that DHCP server.
The error message as quoted seems to come from a qemu-system-x86_64
process. This I conclude from looking what listens on port 5900 after
a successful startup. With three KVMs running, I have three
qemu-system-x86_64 processes, listening on ports 5900, 5901, 5902.
Checking the command line of those instances, I find that the port
number is not their choice. They are given command line arguments
like, e.g.,
-spice
port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on
(among many others).
After a bit of poking around, I noticed that on my system, the present
pid of the libvirtd process is 1227. I started to trace that process
via
strace -ff -e trace=process -e abbrev=none -o /home/user/junk/strace.log -p 1227
and start one more KVM instance. In one of the files written, I find
(abbreviated):
execve("/usr/bin/qemu-system-x86_64",
["qemu-system-x86_64",
(many lines omitted)
"-spice",
"port=5900,addr=127.0.0.1,disable"...,
So I speculate as follows: The problem may be caused by libvirtd
deciding to assign the same port to different KVMs, if the latter are
started in rapid succession. All affected qemu-processes try to fetch
that port from the host OS, and all but one fail.
Regards,
and thank you for providing fine software
Andreas
-- System Information:
Debian Release: 9.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libvirt-daemon depends on:
ii libapparmor1 2.11.0-3+deb9u2
ii libaudit1 1:2.6.7-2
ii libavahi-client3 0.6.32-2
ii libavahi-common3 0.6.32-2
ii libblkid1 2.29.2-1+deb9u1
ii libc6 2.24-11+deb9u3
ii libcap-ng0 0.7.7-3+b1
ii libdbus-1-3 1.10.26-0+deb9u1
ii libdevmapper1.02.1 2:1.02.137-2
ii libfuse2 2.9.7-1+deb9u1
ii libgnutls30 3.5.8-5+deb9u3
ii libnetcf1 1:0.2.8-1+b2
ii libnl-3-200 3.2.27-2
ii libnl-route-3-200 3.2.27-2
ii libnuma1 2.0.11-2.1
ii libparted2 3.2-17
ii libpcap0.8 1.8.1-3
ii libpciaccess0 0.13.4-1+b2
ii librados2 10.2.11-1
ii librbd1 10.2.11-1
ii libsasl2-2 2.1.27~101-g0780600+dfsg-3
ii libselinux1 2.6-3+b3
ii libssh2-1 1.7.0-1
ii libudev1 232-25+deb9u4
ii libvirt0 3.0.0-4+deb9u3
ii libxen-4.8 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10
ii libxenstore3.0 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10
ii libxml2 2.9.4+dfsg1-2.2+deb9u2
ii libyajl2 2.1.0-2+b3
Versions of packages libvirt-daemon recommends:
ii libxml2-utils 2.9.4+dfsg1-2.2+deb9u2
ii netcat-openbsd 1.130-3
ii qemu-kvm 1:2.8+dfsg-6+deb9u5
Versions of packages libvirt-daemon suggests:
ii libvirt-daemon-system 3.0.0-4+deb9u3
pn numad
-- no debconf information
signature.asc
Description: OpenPGP digital signature
Bug#912203: qsstv: Reproducable crash of qsstv (stretch version) reading wav file
Package: qsstv Version: 9.2.4+repack-1 Severity: normal Dear qsstv-maintainer, the ISS presently sends SSTV pictures. I recorded what my receiver could collect. I have a nice fragment of one picture (I was late getting ready), then noise when the ISS did not transmit, and then a nice fragment of another picture that's slowly decaying into noise. All as one .wav file. For reference, that file is currently available at https://www.delta25.de/qsstv-crash/2018-10-29_0717UTC.wav . $ sha256sum 2018-10-29_0717UTC.wav 985ff4d8e95250a2deed1a8878ebee4e4166d2eb84f663e77190da4dd97e8c7d 2018-10-29_0717UTC.wav Trying to read this file into qsstv reliably crashes qsstv. Here is how I can replicate the problem: Start qsstv. In the "wave file" file chooser that opens automatically, navigate to the file and open it. Then, qsstv properly decodes and displays the first picture fragment. Then it sifts through a lot of noise present in the file, I speculate it continues to the point when it should start to decode the second picture fragment. However, instead of that, the window disappears, qsstv apparently crashes. The shell that I used to start qsstv displays this: $ qsstv Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged. Speicherzugriffsfehler The German "Speicherzugriffsfehler" translates to "memory access error". Regards, and thank you for providing fine software Andreas -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qsstv depends on: ii libasound2 1.1.3-5 ii libc6 2.24-11+deb9u3 ii libfftw3-double3 3.3.5-3 ii libfftw3-single3 3.3.5-3 ii libgcc1 1:6.3.0-18+deb9u1 ii libgl1-mesa-glx [libgl1] 13.0.6-1+b2 ii libhamlib2 3.0.1-1+b1 ii libopenjp2-7 2.1.2-1.1+deb9u2 ii libpulse0 10.0-1+deb9u1 ii libqt5core5a 5.7.1+dfsg-3+b1 ii libqt5gui5 5.7.1+dfsg-3+b1 ii libqt5network5 5.7.1+dfsg-3+b1 ii libqt5widgets5 5.7.1+dfsg-3+b1 ii libqt5xml5 5.7.1+dfsg-3+b1 ii libstdc++6 6.3.0-18+deb9u1 ii libv4l-0 1.12.3-1 ii libv4lconvert0 1.12.3-1 qsstv recommends no packages. qsstv suggests no packages. -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#909521: libpython3.5-minimal: "Exception ignored in: .remove"
Package: libpython3.5-minimal Version: 3.5.3-1 Severity: normal Tags: patch I'm running ansible from a virtualenv based on Python 3.5 as installed via the python-3 package in Debian Stretch. I frequently (though not on all runs) see the error Exception ignored in: .remove at 0x7f749113bbf8> Traceback (most recent call last): File "/home/andreas/.../lib/python3.5/weakref.py", line 117, in remove TypeError: 'NoneType' object is not callable I understand that a known bug is the culprit, which can be found at https://bugs.python.org/issue29519 This bug has been fixed upstream with Python versions 3.5.4 and 3.6.1. The Debian Stretch Python 3.5 packages are based on 3.5.3. The fix is a two-line patch to weakref.py available at https://hg.python.org/cpython/rev/2cb530243943 . Workaround: I applied this patch to the copy of this file available in my virtualenv, (after replacing the symlink with an actual copy). That cured my problem. Regards, and thank you for providing fine software, Andreas -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-0.bpo.3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libpython3.5-minimal depends on: ii libc6 2.24-11+deb9u3 ii libssl1.1 1.1.0f-3+deb9u2 Versions of packages libpython3.5-minimal recommends: ii libpython3.5-stdlib 3.5.3-1 libpython3.5-minimal suggests no packages. -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#862072: Should python3-virtualenv depend on virtualenv?
Hello, I was just bitten by this, too, and was about to file a bug on python3-virtualenv that it should depend on virtualenv. Or, if there is a reason to not outright depend on it (I'd be curious to learn about it), python3-virtualenv should recommend virtualenv. Regards, and thank you for providing fine software Andreas dpkg -s python3-virtualenv Package: python3-virtualenv Status: install ok installed Priority: optional Section: python Installed-Size: 137 Maintainer: Debian Python Modules Team Architecture: all Source: python-virtualenv Version: 15.1.0+ds-1 Depends: python-pip-whl (>= 8.1.1-2), python3, python3-pkg-resources, python3:any (>= 3.3.2-2~) Description: Python virtual environment creator The virtualenv utility creates virtual Python instances, each invokable with its own Python executable. Each instance can have different sets of modules, installable via easy_install. Virtual Python instances can also be created without root access. . This is the Python 3 version of the library. Homepage: https://pypi.python.org/pypi/virtualenv signature.asc Description: OpenPGP digital signature
Bug#825862: qrq: segfault using pulseaudio at qrs
Package: qrq
Version: 0.3.1-1
Severity: normal
Tags: patch
Dear Maintainer,
I'm running qrq using pulseaudio (as is the default on my system).
I've configured the speed to slower than normal, and then goofed quite a bit.
This led to slower and slower speeds and finally to quite reproducible
segfaults.
Investigating, I found that pulseaudio.c reserves a fixed buffer
which is good for 10 seconds. If a long callsign at slow speed exceeds that
limit, a segfault results.
Fortunately, it is easy to replace the fixed buffer with a dynamically
allocated one that is enlarged dynamically as needed.
Find a patch to this respect included.
Regards, and thank you for providing fine software,
Andreas, DJ3EI.
-- System Information:
Debian Release: 8.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages qrq depends on:
ii libc62.19-18+deb8u4
ii libncurses5 5.9+20140913-1+b1
ii libpulse05.0-13
ii libtinfo55.9+20140913-1+b1
qrq recommends no packages.
Versions of packages qrq suggests:
pn gnuplot
-- no debconf information
Common subdirectories: qrq-0.3.1/.pc and qrq-mine/.pc
Common subdirectories: qrq-0.3.1/OSXExtras and qrq-mine/OSXExtras
Common subdirectories: qrq-0.3.1/debian and qrq-mine/debian
diff -u qrq-0.3.1/pulseaudio.c qrq-mine/pulseaudio.c
--- qrq-0.3.1/pulseaudio.c 2013-01-06 15:14:09.0 +0100
+++ qrq-mine/pulseaudio.c 2016-05-30 22:19:03.214507268 +0200
@@ -29,7 +29,8 @@
extern long samplerate;
extern void *dsp_fd;
-short int buf[441000]; /* 10 secs buffer */
+short int *buf = 0;
+int bufsize = 0;
int bufpos = 0;
void *open_dsp () {
@@ -64,8 +65,13 @@
/* actually just puts samples into the buffer that is played at the end
(close_audio) */
void write_audio (void *bla, int *in, int size) {
+ int sample_count = size/sizeof(int);
int i = 0;
- for (i=0; i < size/sizeof(int); i++) {
+ if(bufsize <= bufpos + sample_count) {
+ buf = realloc(buf, (bufpos + sample_count) * sizeof(short int));
+ bufsize = bufpos + sample_count;
+ }
+ for (i=0; i < sample_count; i++) {
buf[bufpos] = (short int) in[i];
bufpos++;
}
signature.asc
Description: OpenPGP digital signature
Bug#811268: kicad: Please provide 4.0.1 or newer KiCad, preferably in Jessie-Backports.
Package: kicad Severity: wishlist Dear Maintainer, I managed to home-brew (fumble) Jessie backports kicad-common_4.0.1-0~bpo8+1_all.deb and kicad_4.0.1-0~bpo8+1_amd64.deb, and they installed and seem to work at first glance (I'm new at kicad). But I would very much appreciate an official version in Jessie-Backports. If that helps, here are some key points of what I found myself doing (full details as a script below): I replaced the libglew1.13 dependency with libglew1.10. I used https://launchpad.net/kicad/4.0/4.0.1/+download/kicad-4.0.1.tar.xz as my source of upstream sources and had to change debian/patches/20-noAvhttp.patch and debian/patches/desktop-files.patch, as the upstream sources used ^M line endings for all files in those patches. I failed to build the 4.0.1 documentation packages. There was a possibly related note in README.source that I didn't understand: > The script get-kicad is run once, then debian patches are applied, and > a build is done in the directory /doc to generate > PDF, HTML, EPUB files. Sourceless PDF files are erased, and the > source package is compressed again. Is that something I should have done manually, or is this a mere description of things that happen during the build? I compared the content of the official kicad_4.0.0~rc1a.orig.tar.xz and my home-grown kicad_4.0.1.orig.tar.xz, found quite a few differences of course, but nothing that stroke me as glaring. Regards, and thank you for providing fine software, Andreas My full workaround script for home-brewing those two is attached. As far as downloads is concerned, the script caches the results. Build is done anew from scratch each time. The script contains a few ^M line endings which need to be preserved for it to properly function: $ sha256sum -b run-build.sh afe257af7624da4b7c884453219f80ae6ffa0c8200d2e9d0fb3957aaa9524c46 *run-build.sh The following system information pertains to my home-brew-result installed: -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kicad depends on: ii kicad-common4.0.1-0~bpo8+1 ii libboost-context1.55.0 1.55.0+dfsg-3 ii libboost-date-time1.55.01.55.0+dfsg-3 ii libboost-filesystem1.55.0 1.55.0+dfsg-3 ii libboost-iostreams1.55.01.55.0+dfsg-3 ii libboost-locale1.55.0 1.55.0+dfsg-3 ii libboost-program-options1.55.0 1.55.0+dfsg-3 ii libboost-regex1.55.01.55.0+dfsg-3 ii libboost-system1.55.0 1.55.0+dfsg-3 ii libboost-thread1.55.0 1.55.0+dfsg-3 ii libc6 2.19-18+deb8u1 ii libgcc1 1:4.9.2-10 ii libgl1-mesa-glx [libgl1]10.3.2-1+deb8u1 ii libglew1.10 1.10.0-3 ii libglu1-mesa [libglu1] 9.0.0-2 ii libgomp14.9.2-10 ii libice6 2:1.0.9-1+b1 ii libsm6 2:1.2.2-1+b1 ii libstdc++6 4.9.2-10 ii libwxbase3.0-0 3.0.2-1+b1 ii libwxgtk3.0-0 3.0.2-1+b1 ii libx11-62:1.6.2-3 ii libxext62:1.3.3-1 kicad recommends no packages. Versions of packages kicad suggests: ii extra-xdg-menus 1.0-4 ii kicad-doc-en 4.0.0~rc1a-3 -- no debconf information run-build.sh Description: application/shellscript signature.asc Description: OpenPGP digital signature
Bug#805617: systemd: journalctl --system as user: "No journal files were found"
Hello, Michael, you asked: > Can you also send us the output of > ls -la /var/log/journal I'm not sure this is still needed, but I'll leave that for you to decide. The following is after my initial workaround, no additional change beyond that. In passing: It strikes me as somewhat inconsequential that the software produces fine-tuned ACL, but I as the admin I have to remember to set the g+s bit on the directory for that ACL to do any good. That's not a big issue, though. Regards, Andreas > Script started on Sa 21 Nov 2015 13:20:11 CET > root@falcon:~ > # ls -laR /var/log/journal/ > /var/log/journal/: > insgesamt 20 > drwxr-xr-x 3 root root 4096 Nov 9 16:49 . > drwxr-xr-x 17 root root 12288 Nov 20 11:37 .. > drwxr-xr-x 2 root root 4096 Nov 11 13:08 a40db01e5f2643f68bc99238f1b07903 > > /var/log/journal/a40db01e5f2643f68bc99238f1b07903: > insgesamt 311328 > drwxr-xr-x 2 root root 4096 Nov 11 13:08 . > drwxr-xr-x 3 root root 4096 Nov 9 16:49 .. > -rw-r- 1 root systemd-journal 134217728 Nov 11 13:08 system@e41bf2c7805949d5aded2b24d60f8cef-0001-000522a3bb30b625.journal > -rw-r- 1 root systemd-journal 92274688 Nov 21 13:20 system.journal > -rw-r-+ 1 root systemd-journal 8388608 Nov 11 13:08 user-1000@5903d660b88f444d884298a8dc4324c1-0001d6d8-0005241dac321f96.journal > -rw-r-+ 1 root systemd-journal 25165824 Nov 21 13:15 user-1000.journal > -rw-r-+ 1 root systemd-journal 8388608 Nov 11 13:08 user-1001@09ef76898b3844bda80636b8d1ab57b0-0001d6d4-0005241daa1d6d25.journal > -rw-r-+ 1 root systemd-journal 33554432 Nov 21 13:15 user-1001.journal > -rw-r-+ 1 root systemd-journal 8388608 Nov 11 13:08 user-65534@4bc5536f47f44143b0418cdf0391a240-0001dc3e-0005241dec12aa4e.journal > -rw-r-+ 1 root systemd-journal 8388608 Nov 18 10:04 user-65534.journal > root@falcon:~ > # getfacl -R /var/log/journal/ > getfacl: Entferne führende '/' von absoluten Pfadnamen > # file: var/log/journal/ > # owner: root > # group: root > user::rwx > group::r-x > other::r-x > > # file: var/log/journal//a40db01e5f2643f68bc99238f1b07903 > # owner: root > # group: root > user::rwx > group::r-x > other::r-x > > # file: var/log/journal//a40db01e5f2643f68bc99238f1b07903/user-65534@4bc5536f47f44143b0418cdf0391a240-0001dc3e-0005241dec12aa4e.journal > # owner: root > # group: systemd-journal > user::rw- > user:nobody:r-- > group::r-- > mask::r-- > other::--- > > # file: var/log/journal//a40db01e5f2643f68bc99238f1b07903/system.journal > # owner: root > # group: systemd-journal > user::rw- > group::r-- > other::--- > > # file: var/log/journal//a40db01e5f2643f68bc99238f1b07903/user-1001@09ef76898b3844bda80636b8d1ab57b0-0001d6d4-0005241daa1d6d25.journal > # owner: root > # group: systemd-journal > user::rw- > user:andreas:r-- > group::r-- > mask::r-- > other::--- > > # file: var/log/journal//a40db01e5f2643f68bc99238f1b07903/system@e41bf2c7805949d5aded2b24d60f8cef-0001-000522a3bb30b625.journal > # owner: root > # group: systemd-journal > user::rw- > group::r-- > other::--- > > # file: var/log/journal//a40db01e5f2643f68bc99238f1b07903/user-65534.journal > # owner: root > # group: systemd-journal > user::rw- > user:nobody:r-- > group::r-- > mask::r-- > other::--- > > # file: var/log/journal//a40db01e5f2643f68bc99238f1b07903/user-1001.journal > # owner: root > # group: systemd-journal > user::rw- > user:andreas:r-- > group::r-- > mask::r-- > other::--- > > # file: var/log/journal//a40db01e5f2643f68bc99238f1b07903/user-1000.journal > # owner: root > # group: systemd-journal > user::rw- > user:andreask:r-- > group::r-- > mask::r-- > other::--- > > # file: var/log/journal//a40db01e5f2643f68bc99238f1b07903/user-1000@5903d660b88f444d884298a8dc4324c1-0001d6d8-0005241dac321f96.journal > # owner: root > # group: systemd-journal > user::rw- > user:andreask:r-- > group::r-- > mask::r-- > other::--- > > root@falcon:~ > # exit > > Script done on Sa 21 Nov 2015 13:20:42 CET signature.asc Description: OpenPGP digital signature
Bug#805617: systemd: journalctl --system as user: "No journal files were found"
Hello, Michael, my source of information on the creation of /var/log/journal had been the systemd-journald man page: > By default, the journal stores log data in /run/log/journal/. Since > /run/ is volatile, log data is lost at reboot. To make the data > persistent, it is sufficient to create /var/log/journal/ where > systemd-journald will then store the data. Reading that, I had done a simple `mkdir /var/log/journal` as root and left it at that. > Fwiw, I will clarify the documentation in /usr/share/doc/README.Debian, Fine! Could you please also augment the systemd-journald manual page? Regards, and thank you for providing fine software Andreas signature.asc Description: OpenPGP digital signature
Bug#805617: systemd: journalctl --system as user: "No journal files were found"
Package: systemd Version: 215-17+deb8u2 Severity: normal Dear maintainers, summary: Permission problem with files created below /var/log/journal, systemd-journal group cannot read. Details: On this Jessie system, as a user that's a member of the systemd-journal group, I run some `journalctl --system ...` command and get the error message `No journal files were found.`. This is not the behaviour I expect, as, according to the journalctl manual page, > ... users who are members of the "systemd-journal" > group get access to the system journal ... Doing the same command as root produces the expected output. This seems to be a permission problem regarding the files in /var/log/journal (which exists on my machine). Temporary workaround: As root, I navigate to /var/log/journal and execute chgrp systemd-journal */* Afterwards, the user can run `journalctl --system ...` and get the expected output. This workaround will not help in the long run, as new directories or files are created below /var/log/journal. Regards, and thank you for providing fine software, Andreas -- Package-specific info: -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-59 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.25.2-6 ii libc6 2.19-18+deb8u1 ii libcap2 1:2.24-8 ii libcap2-bin 1:2.24-8 ii libcryptsetup4 2:1.6.6-5 ii libgcrypt20 1.6.3-2 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b3 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 215-17+deb8u2 ii mount 2.25.2-6 ii sysv-rc 2.88dsf-59 ii udev215-17+deb8u2 ii util-linux 2.25.2-6 Versions of packages systemd recommends: ii dbus1.8.20-0+deb8u1 ii libpam-systemd 215-17+deb8u2 Versions of packages systemd suggests: ii systemd-ui 3-2 -- Configuration Files: /etc/systemd/journald.conf changed: [Journal] ForwardToSyslog=no -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#692736: Bug still present in openssl 1.0.2d-1.
Thanks, Christoph, I stumbled over the same bug also. I was on the edge of compiling openssl from source to get this feature that's already present, only not documented in the man page. The bug is still present in Jessie and also in Debian's Package: openssl Version: 1.0.2d-1 FWIW: The version over at https://www.openssl.org/docs/manmaster/apps/s_client.html doesn't have this bug. Regards, and thanks. Andreas signature.asc Description: OpenPGP digital signature
Bug#788185: squashfs-tools: Occasional corruption of large files.
Hello, Steve, you > understood ... that he [me] reports or at least suspects that the discrepancy > problem does not occur in the context of a single-processor machine or a > single-processor VM. I did indeed speculate at one time the problem might be multi-processor related. But attempts to verify this failed. So forget about that one. Regards, Andreas signature.asc Description: OpenPGP digital signature
Bug#788185: squashfs: Last few kB stored as nulls.
Hello, in the meantime, I tried to reproduce the bug with an artificial setup, but couldn't. With one of my regular backups, again one big file wasn't stored in the squashfs correctly. This time, I investigated further, by running both files through od -c and comparing via diff -u. Not very efficient, needs quite a few GB of RAM, but works: --- /tmp/should 2015-06-13 09:14:28.713323748 +0200 +++ /tmp/is 2015-06-13 09:14:33.625302914 +0200 @@ -156571783,1800 +156571783,4 @@ 2453360 6 . 3 2 - 4 3 1 . 2 9 . 2 . e l 2453400 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * -2453553 336 o 177 303 334 257 215 # 227 367 9 314 377 344 C \b [many lines starting with "-" and showing data from the "should" file omitted] -2453562 l = c r o n r e s = s u c c e -24535620020 s s ' \n \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 -24535620040 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 -* 2453600 So what I'm seeing here is: * The squashfs copy and the original file agree for most of its content. * The lengths of the two agree. * The last few kByte of the squashfs copy does not show the content it should, but nulls instead. As mentioned before, I'm using mksquashfs inroot out.squashfs -always-use-fragments -processors 2 My guess is that my combination of "-always-use-fragments" and "-processors 2" and many files and a few really big files triggers a race condition in the mksquashfs code. Regards, and thank you for providing fine software, Andreas signature.asc Description: OpenPGP digital signature
Bug#788185: squashfs-tools: Occasional corruption of large files.
Package: squashfs-tools Version: 1:4.2+20130409-2 Severity: normal Hello, I'm using squashfs for full backups of my laptop, from a (quiet) LVM snapshot. I run sha256sum checksums on each file, then run mksquashfs /freeze /backup/$timestamp.backup.squashfs \ -always-use-fragments -processors 2 then mount the resulting squashfs file system and compare the checksums. Over the years, I've seen checksum errors occasionally. I have recently started to use virtual machines, so I now have more very large files in my backup. Since then, the number of problems seemed to have increased substantially The current backup saw two of these. Interestingly, in both cases, the problem is very close to the end of the file. For the record: In either case, the file length, according to ls -l, is the same for the original and the copy in the squashfs. One file is 2776104960 bytes long, a plain "cmp" run finds the first inconsistency at byte 2776018945, a mere 86015 bytes from the end. The other file is 7831814144 bytes long, a plain "cmp" finds the first inconsistency at byte 7831683073, a mere 131071 bytes from the end. Regards, and thank you for providing fine software Andreas -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages squashfs-tools depends on: ii libc6 2.19-18 ii liblzma5 5.1.1alpha+20120614-2+b3 ii liblzo2-2 2.08-1.2 ii zlib1g 1:1.2.8.dfsg-2+b1 squashfs-tools recommends no packages. squashfs-tools suggests no packages. -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#740117: Can reproduce 740117 starting with --write=4068.
Hello, I can reproduce the bug on my Debian Jessie AMD64 system with kernel $ uname -a Linux falcon 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux and haveged Version: 1.9.1-1 FWIW: Up to --write=4067, all seems to be well, starting with --write=4068 and higher values, I see spinning with one CPU busy. Regards, and thank you for providing fine software, Andreas signature.asc Description: OpenPGP digital signature
Bug#786683: Missing key downloadable from keyring.debian.org not via gpg2 --keyserver, but via rsync.
Workaround: I found the missing key in the file obtainable via rsync -az keyring.debian.org::keyrings/keyrings/debian-role-keys.gpg . After importing the keys from that file, I could finally verify: $ LANG=C gpg2 --verify SHA512SUMS.sign gpg: assuming signed data in 'SHA512SUMS' gpg: Signature made Sun Apr 26 01:43:56 2015 CEST using RSA key ID 6294BE9B gpg: Good signature from "Debian CD signing key " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B Regards, and thank you for providing fine software and infrastructure, Andreas signature.asc Description: OpenPGP digital signature
Bug#786683: debian-8.0.0-amd64-netinst.iso cannot be verified: SHA512SUM.sign broken or GPG-key not available.
Package: cdimage.debian.org Hello, I have a Debian Jessie up and running on one computer. I want to install Jessie on another computer. I downloaded debian-8.0.0-amd64-netinst.iso from some Debian mirror and want to verify this, via the existing Jessie. This I cannot do. Details: I downloaded http://cdimage.debian.org/debian-cd/8.0.0/amd64/iso-cd/SHA512SUMS and the pertinent line verified ok with grep debian-8.0.0-amd64-netinst.iso SHA512SUMS | sha512sum -c So far, so good. I downloaded http://cdimage.debian.org/debian-cd/8.0.0/amd64/iso-cd/SHA512SUMS.sign and tried to verify SHA512SUM with that, but (of course) $ LANG=C gpg2 --verify SHA512SUMS.sign gpg: assuming signed data in 'SHA512SUMS' gpg: Signature made Sun Apr 26 01:43:56 2015 CEST using RSA key ID 6294BE9B gpg: Can't check signature: No public key The information over at http://keyring.debian.org/ suggests that I can retrieve the key there, but $ LANG=C gpg2 --keyserver keyring.debian.org --recv-keys 6294BE9B gpg: requesting key 6294BE9B from hkp server keyring.debian.org gpgkeys: key 6294BE9B can't be retrieved gpg: no valid OpenPGP data found. gpg: Total number processed: 0 Finally, the discussion over at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609451 seems to suggest that SHA512SUMS.sign should have been changed some time after "Mon, 27 Apr 2015 23:18:02 +0100", but the file is older: $ curl -sI http://cdimage.debian.org/debian-cd/8.0.0/amd64/iso-cd/SHA512SUMS.sign | grep -i 'last-modified' Last-Modified: Sat, 25 Apr 2015 23:43:56 GMT So I'm at a loss. Where do I get the signature to verify? Where do I get the key that signed that signature? Regards, and thank you for providing fine software, Andreas signature.asc Description: OpenPGP digital signature
Bug#341935: closed by Baruch Even (Issue fixed in v0.2 branch)
Seems to indeed work now. (Briefly tested with Version: 0.1h-11+b1 .) Thank you! Andreas signature.asc Description: OpenPGP digital signature
Bug#706350: xdg-utils: xdg-open wants to start browser /usr/lib/firefox/firefox instead, of iceweasel on xfce4 system.
Package: xdg-utils Version: 1.1.0~rc1+git20111210-6 Severity: normal Dear xdg-utils - maintainer, when asked to open file:-URLs, xdg-open does not find the iceweasel browser that is installed and named thís user's prefered browser on this xfce4 system. What do I do? LANG=C xdg-open "file://`find /usr/share/doc -name \*.html | head -1`" Expected outcome: The browser opens at some local html file. Outcome seen: A popup comes up, saying Failed to open URI "file:///html". Failed to execute child process "/usr/lib/firefox/firefox" (No such file or directory). Regards, and thank you for providing fine software Andreas Krüger -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash xdg-utils depends on no packages. Versions of packages xdg-utils recommends: ii libfile-mimeinfo-perl 0.16-1 ii libnet-dbus-perl 1.0.0-1+b1 ii libx11-protocol-perl 0.56-4 ii x11-utils 7.7~1 ii x11-xserver-utils 7.7~3 Versions of packages xdg-utils suggests: pn gvfs-bin -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#706312: arduino: "Help" fails to open browser /usr/lib/firefox/firefox
Hello, Scott, thank you for the fast and helpful reaction! I agree I was suffering a xdg-open misconfiguration issue. Here's what I did to verify: $ grep xdg-open $HOME/.arduino/preferences.txt launcher=xdg-open Next, I then tried $ xdg-open file:///usr/share/arduino/reference/index.html Unsurprisingly, this worked. I then removed my bloody hack, and the same did no longer work, instead it came up with the same popup I had seen originally when I posted the bug. Regards, and thank you for providing fine software and user support, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#706312: arduino: "Help" fails to open browser /usr/lib/firefox/firefox
retitle 706312 arduino: Make preferences.txt more transparent, please. severity 706312 wishlist thank you Hello, Scott, now what? Anything left for arduino to do? Adding documentation of the preferences.txt file, and adding a pointer to that documentation to the preferences.txt file as generated when it doesn't exist, would have helped avoid the bug report. Additional, I suggest renaming that particular property from "launcher" to "browser.launcher". I take the liberty of changing the bug a bit to that end. Regards, and thank you for providing fine software, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#706313: sorry about the dupe!
Sorry about the dupe! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#706312: arduino: "Help" fails to open browser /usr/lib/firefox/firefox
Package: arduino Version: 1:1.0.4+dfsg-1 Severity: normal Dear arduino maintainer, "help/reference" in the arduino GUI is expected to open a browser with the pertinent file. Instead of doing so, it displays a popup with the messages Failed to open URI "file:///usr/share/arduino/reference/index.html". Failed to execute child process "/usr/lib/firefox/firefox" (No such file or directory). How did I get there? * Install recent arduino software * Move previous $HOME/.arduino out of the way * start arduino GUI software. For the purpose of this bug report, to get the messages in English, I did "LANG=C arduino" . * In the GUI, trigger "Help/Reference". As a (bloody) workaround, I did sudo ln -s /usr/lib/iceweasel /usr/lib/firefox sudo ln -s /usr/lib/iceweasel/iceweasel /usr/lib/iceweasel/firefox This solves the problem for me, in a fashion. Regards, and thank you for providing fine sofware, Andreas -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages arduino depends on: ii arduino-core 1:1.0.4+dfsg-1 ii default-jre [java6-runtime]1:1.6-47 ii libjna-java3.2.7-4 ii librxtx-java 2.2pre2-11 ii openjdk-6-jre [java6-runtime] 6b27-1.12.4-1 ii openjdk-7-jre [java6-runtime] 7u3-2.1.7-1 Versions of packages arduino recommends: ii extra-xdg-menus 1.0-4 ii policykit-1 0.105-3 arduino suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697216: installation-reports: installer-generated stance in /etc/network/interfaces interfers with networkmanager nm-applet
Package: installation-reports Severity: normal Dear Maintainers, I installed Debian a while ago and am mostly pleased with the result, but want to complain about one particular bug I found. Here goes: I used WLAN during the installation. The installation process itself worked well. But installation left one stance like the following in /etc/network/interfaces : # The primary network interface allow-hotplug wlan0 iface wlan0 inet dhcp wpa-ssid ... wpa-psk ... This caused continous trouble with nm-applet after each reboot. Here the gory details: What I saw: After each reboot, a file /var/run/wpa_supplicant.wlan0.pid was generated. This contained a pid. The corresponding process, according to ps, the last time I saw this: /sbin/wpa_supplicant -s -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0 -D nl80211,wext -C /var/run/wpa_supplicant The existence of this process appearently hinders network manager from doing its job, as far as wlan0 is concerned. I cannot disconnect or connect WLAN via the nm-applet GUI under X-Windows. For the record, here is what I use for that: Package: network-manager-gnome Status: install ok installed Architecture: amd64 Source: network-manager-applet Version: 0.9.4.1-2 I tend to reboot only every so many weeks. The last few reboots, I would kill the wpa_supplicant process (which causes the pid-file to go away), switch WLAN off and back on via the hardware radio kill switch or via nm-applet, and this would bring the control of wlan0 to nm-applet, where I want it. Control was again lost after the next reboot. Removing the stance from /etc/network/interfaces apparently caused the problem to go away for good. Regards, and thank you for providing fine software, Andreas Below is some additional standard information for completeness (not sure whether this is useful). -- Package-specific info: Boot method: USB-stick. Image version: Debian GNU/Linux wheezy-DI-b3 _Wheezy_ - Official Snapshot amd64 NETINST Binary-1 20121012-13:45 Date: November 2, 2012 Machine: Thinkpad T420s Partitions: I let some older LVM volumnes I had survive the install, and used spare space on that old volumn group for the new install, so this was slightly tricky. But in the end, I got what I wanted. $ LANG=C df -Tl FilesystemType 1K-blocks Used Available Use% Mounted on rootfsrootfs27867324 8769988 17681760 34% / udev devtmpfs 102400 10240 0% /dev tmpfs tmpfs 808176 708807468 1% /run /dev/mapper/falcon-root ext4 27867324 8769988 17681760 34% / tmpfs tmpfs 51200 5120 0% /run/lock tmpfs tmpfs 1616340 92 1616248 1% /run/shm /dev/sda1 ext424097243723184808 20% /boot /dev/mapper/falcon-home ext4 30963708 19617076 9878712 67% /home /dev/mapper/falcon-backup ext4 45413424 40498528 2629004 94% /backup /dev/loop0squashfs 20090624 20090624 0 100% /oldfreeze Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [E] Detect CD: [ ] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [ ] Install boot loader:[O] Overall install:[O] Comments/Problems: See above for the network problem, which is the point of this bug report. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="7.0 (wheezy) - installer build 20120930+b1" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux falcon 3.2.0-3-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012 x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09) lspci -knn: Subsystem: Lenovo Device [17aa:21d2] lspci -knn: Kernel driver in use: agpgart-intel lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) lspci -knn: Subsystem: Lenovo Device [17aa:21d3] lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Se
Bug#594741: Gnome panel not clickable
Hello, I have the same problem as does Paolo (in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594741 ). When I ran vnc4server from the command line and connect through the Java viewer applet, again the gnome panel is not clickable. So same story, regardless whether I use remote session (sesman) or Xvnc directly. This is also running under vnc4server, version 4.1.1+X4.3.0-31. One peculiarity: Whenever I kill the VNC X server (either the sesman-created or the directly created one), and check what is still running under my user, I find three left over processes: gnome-panel --sm-client-id default1 /usr/lib/libgconf2-4/gconfd-2 14 /usr/lib/bonobo-activation/bonobo-activation-server --ac-activate --ior-output-f... Why would gnome-panel continue to run, when the X server it was associated with no longer exists? There are also a lot of error messages in $HOME/.xsession-errors , repeated over and over again while the session was running: ** (nm-applet:17390): WARNING **: nma_dbus_init(): could not acquire its service. dbus_bus_acquire_service() says: 'Connection ":1.35" is not allowed to own the service "org.freedesktop.NetworkManagerInfo" due to security policies in the configuration file' To get rid of those, I edited /etc/dbus-1/system.d/nm-applet.conf --- nm-applet.conf~ 2009-12-16 16:16:51.0 +0100 +++ nm-applet.conf 2011-01-21 16:56:01.0 +0100 @@ -34,10 +34,11 @@ send_member="updateNetworkInfo"/> - + + - - + + 512 That resulted in fewer .xsession-errors, but did not solve the underlying problem. When sifting through the issues in .xsession-errors, for example, xkeyboard extensions not being available, more dbus, and one that particularly stuck out: The program 'gnome-settings-daemon' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 2410 error_code 3 request_code 20 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Finally, I pulled the emergency break and switched from Gnome to Xfce. As that user, I do not care what is configured for local sessions, so: echo exec xfce4-session > $HOME/.xsession This is a viable workaround for me. Regards, and thank you for providing fine software, Andreas -- Dr. Andreas Krüger, Senior Developer Tel. (+49) (211) 280 69-1132 andreas.krue...@hp.com DV-RATIO NORDWEST GmbH, Habsburgerstraße 12, 40547 Düsseldorf, Germany für Hewlett-Packard GmbH H Herrenberger Str. 140 71034 Böblingen www.hp.com/de Geschäftsführer: Volker Smid (Vorsitzender), Michael Eberhardt, Thorsten Herrmann, Martin Kinne, Heiko Meyer, Ernst Reichart, Rainer Sterk Vorsitzender des Aufsichtsrates: Jörg Menno Harms Sitz der Gesellschaft: Böblingen S Amtsgericht Stuttgart HRB 244081 WEEE-Reg.-Nr. DE 30409072
Bug#542633: linux-image-2.6.26-2-openvz-686 version 2.6.26-22 also fixes this kernel bug!
Hello, Maximilian and all, package linux-image-2.6.26-2-openvz-686 version 2.6.26-22 fixes bug 571457 ! Thanks! So, in my opinion as the original reporter, bug 571457 can be considered obsolete. As I'm not 100% sure about proper procedure, I leave the actual closing to you Debian maintainers. For the record: The present Lenny version 2.6.26-21lenny4 of that package still has the bug. Gory details: > please test the 2.6.26-22 upload to stable proposed uploads, > see instructions on how to install > http://www.de.debian.org/releases/proposed-updates I tried that yesterday, but it didn't work for me. Poking into the Debian mirrors, I found that the 64bit version was present, but the 32bit I need not yet. So I guess I was monitoring the Debian build while it happened. A few hours later, the front-door approach with aptitude still did not work, but I found linux-image-2.6.26-2-openvz-686_2.6.26-22_i386.deb below http://ftp.de.debian.org/debian/pool/main/l/linux-2.6/ . So I installed that with raw dpkg -i . Result: Bug no longer present. The results with this Debian kernel are quite comparable to what I have seen with the openvz upstream kernel, as reported in my earlier mail. Regards, > thanks for feedback on it. you're welcome, and thank you all for providing fine software, Andreas -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 577 996-26 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram DV-RATIO - "Kompetenz und Zuverlässigkeit seit 1980" signature.asc Description: OpenPGP digital signature
Bug#573701: base-files: /usr/src permissions causes make-kpkg failure "control directory has bad permissions 2755"
Package: base-files Version: 5.1 Severity: normal To help investigate bug 571457, I wanted to compile an openvz upstream kernel obtained by cd /usr/src git clone git://git.openvz.org/pub/linux-2.6.26-openvz openvz-git-kernel For the actual kernel compile, I configured and then tried the Debian way: cd /usr/src/openvz-git-kernel make-kpkg --initrd kernel_image Expected result: A linux-image .deb package gets built. Result seen: The build fails, with an error message dpkg-deb: control directory has bad permissions 2755 (must be >=0755 and <=0775) My analysis: base-files sets up /usr/src with the g+s permission bit, that bit infects my entire source directory tree, make-kpkg doesn't like that. My take on this: Various Debian packages should fit together, but base-files and make-kpkg don't, in this respect. My own suggestion towards how to achieve cooperation: Drop the g+s bit from /usr/src. My workaround does exactly that: chroot -R g-s . Final "pea-counting" remarks on the precise package version: The build actually failed on a Lenny system with base-files version 5lenny5. I verified that it is the base-files package that sets up the g+s permission, via rm -rf /usr/src aptitude reinstall base-files ls -l /usr But I did this verification on a different system (in fact, an openvz guest of the Lenny system host) which has "testing" installed. I didn't bother to retry the entire kernel compilation on that "testing" system. (I would be willing to do that if people think it's worth the effort.) Regards, and thank you for providing fine software, Andreas -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-openvz-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages base-files depends on: ii base-passwd 3.5.22 Debian base system master password ii mawk [awk]1.3.3-15 a pattern scanning and text proces base-files recommends no packages. base-files suggests no packages. -- no debconf information -- andreas.krue...@famsik.de PGP-Schlüssel 0xA207E340 (http://blackhole.pca.dfn.de/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 signature.asc Description: OpenPGP digital signature
Bug#571457: This kernel bug is Debian-specific, not present in openvz upstream Kernel.
This bug is Debian specific: The endless looping inside the kernel system call is not present in a current openvz upstream kernel. I'm refering to Debian bug 571457 which, according to Maximilian, is probably the same as bug 542633 . The details: I had filed an upstream bug report http://bugzilla.openvz.org/show_bug.cgi?id=1443 . In that bug's discussion, Pavel Emelyanov asked me to verify whether the bug was present in their git kernel. So I grabbed their kernel source git clone git://git.openvz.org/pub/linux-2.6.26-openvz openvz-git-kernel For configuration, I used Debian's linux-image-2.6.26-2-openvz-686, Version 2.6.26-21lenny4 as my baseline, via cp /boot/config-2.6.26-2-openvz-686 .config I compiled the sources via make-kpkg --initrd kernel_image (which didn't at first work. The directory permissions of /usr/src had infected my git directory with g+s, and, after a long time of churning, make-kpkg decided it didn't like that.) The good news: After booting into that kernel, my example runs fine as expected! No more endless looping and CPU cycle eating. Instead, a mere 20 milliseconds user time consumed by the server. The Perl client is through in 1.5 seconds real runtime. For comparison, directly on the host machine (a somewhat dated box), the server's user stays the same, the client's real is about 0.1 seconds faster. After two runs on a freshly started openvz client, I get 511 tcpsndbuf fail counts grep tcpsnd /proc/user_beancounters tcpsndbuf 0 70400 7 15511 which was to be expected. Regards, Andreas -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 577 996-26 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram DV-RATIO - "Kompetenz und Zuverlässigkeit seit 1980" signature.asc Description: OpenPGP digital signature
Bug#571457: OpenVZ TCP/IP socket write hangs - is this Debian bug 542633 ?
Hello, Maximilian, I would like to ask you whether you think the following bug is the same as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542633 "openvz: [UBC]: Endless loop in __sk_stream_wait_memory." I had a reproducible "stops working" with a Subversion server running on an OpenVZ guest. After some investigation, this turned out to be nothing Subversion-specific. I was able to reproduce with a minimal client / server pair. What I know about "my" bug: * A write system call to a TCP/IP connection socket hangs, it does not return to the application, * the process doing the write consumes what CPU cycles it can get, as reported by "top", * killing the other side of the TCP/IP connection does not result in the "connection reset by peer" condition as it should, * instead, the write simply continues to consume all CPU cycles it can get, for all I know, indefinitely until I kill the process, * the bug seems to appear if the sender writes fast, faster than the network or the client can consume, * putting big chunks of data into a single write call does not seem to be strictly necessary to reproduce the problem, but it does make the problem appear more easily, * the problem can be made to appear a write or two later by raising the tcpsndbuf UBC. For more details, I have filed http://bugzilla.openvz.org/show_bug.cgi?id=1443 on this issue. This also has my client / server pair with which I have been able to reproduce this bug. I have also filed the Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571457 on the same issue, originally against Subversion, now I have reassigned it to the OpenVZ image I have been using. Would you kindly tell me whether this bug is the same as Debian bug 542633 ? Do you think this is Debian specific, or does it also concern OpenVZ upstream? Regards, Andreas -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 577 996-26 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram DV-RATIO - "Kompetenz und Zuverlässigkeit seit 1980" signature.asc Description: OpenPGP digital signature
Bug#571457: I meant svnserve, not svnadmin.
Hello, I wrote "svnadmin" a few times in my previous mail, but I meant "svnserve" each time. I apologize for any confusion that may have been caused by this! Andreas -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 577 996-26 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram DV-RATIO - "Kompetenz und Zuverlässigkeit seit 1980" signature.asc Description: OpenPGP digital signature
Bug#571457: svnserve hangs, burning CPU cycles, under low TCP sendbuffer.
Package: subversion Version: 1.6.9dfsg-1 X-Debbugs-CC: d...@subversion.apache.org Hello, Subversionists, I have a subversion repository with a single revision, consisting of a single roughly 10 MB file with random data. I use svnserve to serve that repository. I use a client to access the svnserve over the network, via "svn co". (The client happens to be Ubuntu's 1.6.5dfsg-1ubuntu1, in case that matters.) The server is an openvz guest. When, on the corresponding host, I set vzctl set NNN --tcpsndbuf 415k:715k or lower (my guess is the first number is the one that matters), the checkout starts, there is some initial network traffic, but then svnadmin starts to eat up all CPU cycles it can get and no further progress is made, until I kill the svnadmin process manually on the server. Just killing the client does not seem to stop the waste of CPU cycles on the server. When I increase the tcpsndbuf above that value, there is no problem. However, when I check in a much larger file into the repository (I do that directly, using file:/// - access), and try to check out again (using svnserve), the problem reappears. This is quite reproducibly, with svnadmin as a standalone daemon as well as svnadmin running under inetd. For the latter case, I made no precise experiments about the --tcpsndbuf numbers. This is the summary. I have written three mails yesterday and today to the d...@subversion.apache.org mailing list, but have not received any answers there yet. There is lots of nitty-gritty background information in those mails, which, hopefully, you'll be able to find here: http://mail-archives.apache.org/mod_mbox/subversion-dev/201002.mbox/browser Regards, and thank you for providing fine software, Andreas P.S.: I ask the Debian bug tracking system to forward a copy of this mail to the SVN dev mailing list. This contains two pieces of information not available in my previous mails to that list: * The bug is reproducible with the latest subversion software version I can easily install, short of compiling myself. * The client I'm using is, and always has been, 1.6.5dfsg-1ubuntu1. I think I misquoted it to be 1.5 in one of my earlier mails. I apologize if this caused any confusion! -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 577 996-26 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram DV-RATIO - "Kompetenz und Zuverlässigkeit seit 1980" signature.asc Description: OpenPGP digital signature
Bug#564622: php.ini-paranoid: "Error parsing /etc/php5/apache2/php.ini on line 95" results in "not paranoid".
Package: php5-common Version: 5.2.6.dfsg.1-1+lenny4 Severity: normal Tags: patch Hello, I copied the file provided as /usr/share/doc/php5-common/examples/php.ini-paranoid to /etc/php5/apache2/php.ini and used that. The error.log said PHP: Error parsing /etc/php5/apache2/php.ini on line 95 on apache startup. Unfortunately, the apache PHP interpreter did operate on .php files in spite of the parsing error. Even worse, the security features the file is supposed to provide were NOT active! So this is somewhat of a security issue. (Of course, one can hope an admin who is cautious enough to read the standard php.ini and is cautious to replace it with the paranoid one is also cautious enough to have a look at error.log, and act on the warning.) The obvious repair is to add a ";" in front of line 95. I include a patch that does that. Regards, and thank you for providing fine software, Andreas --- /usr/share/doc/php5-common/examples/php.ini-paranoid 2009-11-22 03:48:28.0 +0100 +++ /tmp/php.ini-paranoid 2010-01-10 19:13:35.0 +0100 @@ -92,7 +92,7 @@ ; be found by running: ; ; $ diff -u /usr/share/doc/php5-common/examples/php.ini-dist \ - /usr/share/doc/php5-common/examples/php.ini-paranoid |less +;/usr/share/doc/php5-common/examples/php.ini-paranoid |less ; ; ; This is a (not complete) list of some of the changes introduced in this file: signature.asc Description: OpenPGP digital signature
Bug#540299: xmail: Fails to install on machine with very little infrastructure.
llapsed, e.g., through a server
crash at just the "right" moment?)
I tried deleted /var/lib/xmail/spool. Sure enough, this ran into an endless loop
waiting for xmail to start running:
=
+ ln -sf /etc/xmail/dnsroots /var/lib/xmail
+ chmod 711 /var/lib/xmail
+ chmod 711 /var/spool/xmail
+ chmod 711 /var/spool/xmail/spool
+ chmod 770 /var/spool/xmail/spool/local
+ chown root:mail /var/spool/xmail/spool/local
+ chmod 770 /var/spool/xmail/spool/temp
+ chown root:mail /var/spool/xmail/spool/temp
+ chmod 700 /var/cache/xmail
+ SSL_CERT=/var/lib/xmail/server.cert
+ SSL_KEY=/var/lib/xmail/server.key
+ '[' '!' -f /var/lib/xmail/server.cert ']'
+ chmod +t /var/spool/xmail/spool/temp
+ chmod +t /var/spool/xmail/spool/local
+ dpkg-statoverride --force --update --add root mail 2555
/var/lib/xmail/sendmail/xsendmail
An override for "/var/lib/xmail/sendmail/xsendmail" already exists, but --force
specified so will be ignored.
+ '[' -x /etc/init.d/xmail ']'
+ update-rc.d xmail defaults
++ which invoke-rc.d
+ '[' -x /usr/sbin/invoke-rc.d ']'
+ invoke-rc.d xmail start
Starting XMail server: XMail.
+ '[' configure = configure ']'
+ '[' '!' -f /var/run/XMail.pid ']'
+ '[' -z '' ']'
+ '[' '!' -d /var/lib/xmail/spool/22/22/ ']'
+ sleep 1
+ '[' '!' -d /var/lib/xmail/spool/22/22/ ']'
+ sleep 1
+ '[' '!' -d /var/lib/xmail/spool/22/22/ ']'
+ sleep 1
+ '[' '!' -d /var/lib/xmail/spool/22/22/ ']'
and many more of these.
=
At this point, I forced xmail to be started via /etc/init.d. This got me out of
the endless loop, but now
...
+ printf '%s\n' 'GET xmail/redirect'
+ IFS='
'
+ read -r _db_internal_line
+ RET=
+ case ${_db_internal_line%%[ ]*} in
+ return 0
+ redirect=
+ '[' /etc/mailname = /etc/mailname ']'
+ '[' -f /etc/mailname ']'
++ cat /etc/mailname
+ domainname=approx.famsik.de
+ cat
+ '[' -f /etc/xmail/default_domain ']'
+ old_domain=xmailserver.test
+ echo 'I: Adding new domain.'
I: Adding new domain.
++ CtrlClnt -s localhost -u debian -p debian domainlist approx.famsik.de
ErrCode = -152
ErrString = End of socket stream data
+ EXISTS_D=
dpkg: error processing xmail (--configure):
subprocess post-installation script returned error exit status 4
Errors were encountered while processing:
xmail
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Best regards, and thank you for providing fine software,
Andreas Krüger
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkp7cWAACgkQnWrlKaIH40CzUgCgntU9gyef0fz27vnj14494N+D
cz8An0qiYZ/Zyx/h99PNoH1Si71UdUVZ
=jKgv
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533304: rubygems1.8: "gem install" calls "make" on a broken Makefile
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello, Diago
>> It is not the problem of Debian's rubygems.
I have not investigated this throughly, but I agree / my guess is this is
probably not a specific Debian problem, but upstream.
>> Since Debian is not darwin, the Makefile provided by the gem won't work.
It seems to be more complicated than that. I've done some three experiments:
To set these experiments up, I verify I can do both "gem uninstall sqlite3-ruby"
and "gem install sqlite3-ruby" with no problem. I also utilized a crude little
script to keep track of the Makefile (attached below).
First experiment: Trigger a successful "install".
Result: As far as observed via my script, the Makefile gets written twice. First
with the wrong "darwin" information. Some time later, it gets rewritten
extensively. Among other things, the "darwin" information is replaced with
"i486-linux" information.
For the second experiment, I deviously moved /usr/lib/ruby/1.8/i486-linux/ruby.h
out of the way.
Result: Of course, this causes "gem install sqlite3-ruby" to fail.
With the error message: "mkmf.rb can't find header files for ruby at
/usr/lib/ruby/ruby.h".
Wrong. This should really point to /usr/lib/ruby/1.9/i486-linux/ruby.h.
For the record: The Makefile still has the "darwin" version, it has not yet been
updated to "i486-linux".
In preparation for the third experiment, I repair
/usr/lib/ruby/1.8/i486-linux/ruby.h and check the gem now installs (it does),
and, of course, again uninstall it.
For the third experiment, "aptitude purge libsqlite3-dev" removes header files
required by "gem install sqlite3-ruby". Those out of the way, I again fire up
"gem install sqlite3-ruby".
Chaos results. The correct Makefile never gets written, what's on the disk is
still the "darwin" one. But the really bad part of this story: "make" is called
on this wrong-system "darwin" Makefile!
A rather confusing error message results:
> /usr/bin/ruby1.8 extconf.rb install sqlite3-ruby
> checking for fdatasync() in -lrt... yes
> checking for sqlite3.h... no
>
> make
> make: *** No rule to make target `ruby.h', needed by `sqlite3_api_wrap.o'.
> Stop.
In my opinion:
* "make" should never get called on a Makefile which gem could not properly
adjust to the system.
* This is buggy error handling on the part of "gem". (Probably upstream, but
that is only a guess.)
* Less importantly: If gem knows it needs to do a second write, then first write
should preferably not go to the final file name "Makefile", but to
"Makefile.prelim" or some such name.
Regards, and thank you for providing fine software,
Andreas
Here is my crude "observe the Makefile" hack:
#!/usr/bin/perl -w
use strict;
my $file = "/var/lib/gems/1.8/gems/sqlite3-ruby-1.2.4/ext/sqlite3_api/Makefile";
my $i = 0;
system "touch /tmp/Makefile.$i";
while(1) {
if (-f $file) {
if(((system "cmp $file /tmp/Makefile.$i") >> 8) != 0) {
# They are not the same.
$i++;
system "cp $file /tmp/Makefile.$i";
print "Captured /tmp/Makefile.$i\n";
} else {
# wait 100 ms.
select(undef, undef, undef, 0.1);
}
} else {
# wait 100 ms.
select(undef, undef, undef, 0.1);
}
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAko48QgACgkQnWrlKaIH40AQ5QCgqygbYPorvPsHIMSfeAzRvaMu
swMAoIUVpHeJ1cpxyhOHSMlK8dWVQfvx
=k2Km
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533304: libsqlite3-ruby1.8: Ruby gem sqlite3-ruby should be available.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: libsqlite3-ruby1.8 Version: 1.2.2-1 Severity: wishlist X-Debbugs-CC: Daigo Moriwaki Hello, I wanted to install the "typo" Ruby gem. As I found no Debian package to that end, I tried gem install typo For all I can tell, this recursively calls, in effect (among other things), gem install sqlite3-ruby Why would it do that? I do have libsqlite3-ruby1.8 already installed on the system! So, with this bug report, I wish to request: The fact that sqlite3-ruby functionality is already available through libsqlite3-ruby1.8 should be made available to gem, if libsqlite3-ruby1.8 happens to be installed. (See bug 533304 for a fairly chaotic story that came out of this.) More generally: Gem should not try to redo work already done by Debian developers, if that work is already present on the installation system through installed Debian packages. Indeed, this is probably a somewhat general issue, effecting not only libsqlite3-ruby1.8, but also other gems repackaged by Debian. I'm not sure what the correct package to report this would be. So I report it with the package that caused the trouble in my particular case. Feel free to move. Please note that I don't ask for the much tougher reverse direction here. Namely, that gem knows to install Debian packages instead of doing the usual gem thing. While that would be nice to have, too, it'll be a lot more difficult. This is the easy part: Just having gem know about what's there through Debian-ly installed packages. This should be relatively straightforward to implement (I think), and offer some valuable benefit. Regards, and thank you for providing fine software, Andreas Krüger - -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libsqlite3-ruby1.8 depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libruby1.81.8.7.72-3 Libraries necessary to run Ruby 1. ii libsqlite3-0 3.5.9-6SQLite 3 shared library libsqlite3-ruby1.8 recommends no packages. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko3x6IACgkQnWrlKaIH40BaBwCfe8SDXCQq696iJ+v+ft4l3zGI R3MAnA3GBugABxSXPyAeSDm4FuoI8psn =pnr3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533304: Workaround: Compiling yourself.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I compiled first ruby (1.9.1p129, with prefix set to /usr/local/lib/ruby1.9) and then rubygems from scratch. This seems to work around the problem. Regards, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko3rmsACgkQnWrlKaIH40DnEwCgoYcztqLsxJbGOMIo59jc9bkY RdkAn0iP5hf/8tJRynJHOe/5ozlIHrwN =BQaq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533304: rubygems1.8: "gem install" points make to non-existing /opt/local/lib/ruby/1.8/i686-darwin9.2.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: rubygems1.8 Version: 1.2.0-3 Severity: important Hello, I'm trying to do use "gem install" to compile native stuff. It does not work. I found that include files are not expected by the compilation process at the place where they actually reside. The compilation process's expectancies are governed by a Makefile, which, on my system, has In detail: "gem install sqlite3-ruby" fails, leaving the following log file content in /var/lib/gems/1.8/gems/sqlite3-ruby-1.2.4/ext/sqlite3_api/gem_make.out : > /usr/bin/ruby1.8 extconf.rb install sqlite3-ruby > checking for fdatasync() in -lrt... yes > checking for sqlite3.h... no > > make > make: *** No rule to make target `ruby.h', needed by `sqlite3_api_wrap.o'. > Stop. This include file ruby.h is available as /usr/lib/ruby/1.8/i486-linux/ruby.h. Looking at the Makefile generated by the gem installation process, I think it is looked for in /opt/local/lib/ruby/1.8/i686-darwin9.2.2 instead. I verified this by providing /opt/local/lib/ruby/1.8/i686-darwin9.2.2/ruby.h. When doing this, make apparently finds "ruby.h". It now stumbles over "defines.h" not being present. I think the following lines of /var/lib/gems/1.8/gems/sqlite3-ruby-1.2.4/ext/sqlite3_api/Makefile are part of the problem: > topdir = /opt/local/lib/ruby/1.8/i686-darwin9.2.2 > INCFLAGS = -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin9.2.2 -I. > arch = i686-darwin9.2.2 > sitearch = i686-darwin9.2.2 > vendorarch = i686-darwin9.2.2 As an attempted workaround, at my trusted bash prompt, I installed rubygems from scratch. This did not help. I continued to encounter the same problem. Even though it did not help, here is what I tried: aptitude purge rubygems1.8 # which also removed a whole lot of other things. # Mainly left was aptitude install ruby rdoc wget http://rubyforge.org/frs/download.php/57643/rubygems-1.3.4.tgz -O - | tar xzf - cd rubygems-1.3.4 export GEM_HOME=/usr/local/lib/ruby1.8/gems ruby setup.rb --prefix=/usr/local/lib/ruby1.8 export RUBYLIB=/usr/local/lib/ruby1.8/lib Regards, and thank you for providing fine software, Andreas Krüger - -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages rubygems1.8 depends on: ii rdoc1.8 1.8.7.72-3 Generate documentation from Ruby s ii ruby1.8 1.8.7.72-3 Interpreter of object-oriented scr rubygems1.8 recommends no packages. Versions of packages rubygems1.8 suggests: ii build-essential 11.4 Informational list of build-essent ii ruby1.8-dev 1.8.7.72-3 Header files for compiling extensi pn rubygems-doc (no description available) - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko3hqYACgkQnWrlKaIH40CeOgCgrsZXqg5HcIuCBw56/SlufiQu ft0AnR+S1p8ZZCkvZy94wQ52yc9IMve6 =BhfO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#503043: Downgrade to 0.3.17-1 (Etch) does not cure this bug.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I had been running the Etch version of the Bittornado tracker for
quite some time, without this bug manifesting itself. Since updating
to Lenny, the tracker has become unusable for me as it would keep
crashing after a while (a few hours, apparently). My current command
line does include the --allowed_dir option:
/usr/bin/bttrack.bittornado --port 10815 --log_nat_checks 1 \
--nat_check 3 --allowed_dir /var/local/lib/bttrack/serve \
--dfile /home/bttrack/persist/bittornado.dfile
As a workaround, I've been using the tracker from the "bittorrent"
software package instead. It does not show the problems I had
experienced with Bittornado.
Today, I decided to try the old Etch version 0.3.17 of Bittornado on
my Lenny system. So I grabbed bittornado_0.3.17-1_all.deb and
installed that, using a brute-force "dpkg -i".
After that downgrade, I keep getting messages like
92.228.159.139 gzip - [17/May/2009:11:50:07] "GET / HTTP/1.1" 200
610 "-"
"Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.9) Gecko/2009050519
Iceweasel/3.0.6 (Debian-3.0.6-1)"
Traceback (most recent call last):
File "/var/lib/python-support/python2.5/BitTornado/RawServer.py",
line 133, in
listen_forever
func()
File "/var/lib/python-support/python2.5/BitTornado/BT1/track.py",
line 947, in
save_state
h.write(bencode(self.state))
File "/var/lib/python-support/python2.5/BitTornado/bencode.py",
line 290, in
bencode
assert 0
AssertionError
*** error *** could not encode type (value: {...})
(I don't know whether I used to also get these on my old Etch system.)
After about an hour or so of these, the tracker crashed.
So back to plain original bittorrent...
Regards, and thank you for providing good software
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoQD54ACgkQnWrlKaIH40CcUgCfcQOdEptcul7es5hkWbceI3Is
8bIAnir/ZDUURKGh4MkuSZ4qGlNbZls0
=7dOU
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#527448: oregano: Black and white PNG export produces colored file.
Hello, Maximiliano, > ... oregano uses cairo now thanks for that inside information you give! > So, removing the option from the export window might be the best option. Technically, yes, that'd fix this bug. But only in a formal manner. Individual circuit elements come out red, connecting wires partially red, partially blue, connection points black, writing in green. (I enclose an example.) These colors are useful for me while working in Oregano. But they are no longer useful in the exported end result circuit diagram. From an end result perspective, these colors do not make sense; not for my purpose, anyway. Again: > So, removing the option from the export window might be the best option. Ok - but I'd be asking for a black and white option, as a "wishlist" feature request. (If you develop folks think two steps are a good way to handle this, we can do it that way.) Finally, for the record: As my workaround, I presently use something like pngtopnm < XYZ-color.png | ppmtopgm | pgmnorm -wvalue 255 -bvalue 180 | pnmtopng > XYZ.png > I might be able to hack something for the png export, but for the other > formats > I'm not really sure how to convert them. You may be able to hack something equivalent to my pipe for the png export. In my opinion (and I'm somewhat of a developer myself), it'd smell like a kludgy hack. There should be a cleaner way. But then, I don't know anything about cairo. Regards, > I'll talk with the main oregano developer and see what we can do. and again thank you, Andreas > Hola Andreas Krüger! > > El 07/05/2009 a las 17:30 escribiste: >> Expected result: A black and white .png - file is generated. > >> Result seen: A .png file is generated all right, but it has colors. > > I believe the "black and white" radio button is a left over of a pre-cairo > export, oregano uses cairo now, and it seems there is no easy way to convert a > cairo surface to black and white or grayscale. I might be able to hack > something for the png export, but for the other formats I'm not really sure > how to convert them. > > So, removing the option from the export window might be the best option. > > I'll talk with the main oregano developer and see what we can do. > <> signature.asc Description: OpenPGP digital signature
Bug#527448: oregano: Black and white PNG export produces colored file.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: oregano Version: 0.69.0-2 Severity: normal Hello, I'm using oregano simply to draw simple circuit diagrams and export those as .png files to be included in a web page. Here is what I do to reproduce the problem: I draw a simple circuit diagram, click on File / Export, adjust width and height, change "Format" to "Portable Network Graphics (PNG)", select "Background" as "White", select "Output" to "Black and White", select some file name, and hit "OK". Expected result: A black and white .png - file is generated. Result seen: A .png file is generated all right, but it has colors. Obvious workaround: Change to a black and white file using external tools. Regards, and thank you for providing fine software, Andreas - -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages oregano depends on: ii libart-2.0-22.3.20-2 Library of functions for 2D graphi ii libbonobo2-02.22.0-1 Bonobo CORBA interfaces library ii libc6 2.7-18 GNU C Library: Shared libraries ii libcairo2 1.6.4-7 The Cairo 2D vector graphics libra ii libgconf2-4 2.22.0-1 GNOME configuration database syste ii libglade2-0 1:2.6.2-1library to load .glade files at ru ii libglib2.0-02.16.6-1+lenny1 The GLib library of C routines ii libgnome2-0 2.20.1.1-1 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.20.1.1-1 A powerful object-oriented display ii libgnomeui-02.20.1.1-2 The GNOME 2 libraries (User Interf ii libgtk2.0-0 2.12.12-1~lenny1 The GTK+ graphical user interface ii libgtksourceview1.0-0 1.8.5-1 shared libraries for the GTK+ synt ii libpango1.0-0 1.20.5-3 Layout and rendering of internatio ii libxml2 2.6.32.dfsg-5GNOME XML library Versions of packages oregano recommends: ii gnucap1:0.35-1.1 GNU Circuit Analysis package oregano suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoC/ogACgkQnWrlKaIH40BvagCfdMNnQxJq7p8Jrr1mJqV+wjoL xEUAmwUbESjYefmbDvAPf/57lwcvQlbo =qUZT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518988: Little manual Pidgin backport installation howto.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Christoph, thank you very much for that pidgin backport! For the other "unpatients": We don't seem to have a line for /etc/apt/sources.list, but simply downloading and installing manually has been working for me. This ought work on a Lenny system (sequence is important): dpkg -i pidgin-data_2.5.5-1.1~bpo50+1_all.deb dpkg -i libpurple0_2.5.5-1.1~bpo50+1_i386.deb dpkg -i pidgin_2.5.5-1.1~bpo50+1_i386.deb Myself, I did it not in the right sequence, so I had to throw in an additional aptitude install to fix it up in the end. Regards, and thank you all for providing fine software Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm5fhMACgkQnWrlKaIH40BlpgCgi87HLLes1jggCut93f3ZRmix CzMAn3tb2LINytVTkZS7C4JnorVXfwkh =44QZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518133: closed by Aurelien Jarno (Re: Bug#518133: libc6-xen: nosegneg not selected when running in OpenVZ under Xen)
Hello, Aurelian, thank you for that piece of information. > You should either ask the company providing you kernel to fix the pseudo > hwcap nosegneg value, or edit /etc/ld.so.conf.d/libc6-xen.conf and > replace 'hwcap 1 nosegneg' by 'hwcap 0 nosegneg'. I have tried that "hwcap 0 nosegneg" bit. That one does NOT help. That established, do you still think there a good chance that the other part of your counsel does help, that is, upgrading to a more recent kernel? For the record, as an ugly workaround, what does get rid of the messages is: Move the plain versions to the side and replace them with symbolic links into the i686/nosegneg directory. Something along those lines (while 156 is stopped): cd /var/lib/vz/private/156/lib mkdir wrong-version-moved-to-the-side for f in `cd i686/nosegneg; echo *` do test -f $f && mv $f wrong-version-moved-to-the-side && ln -s i686/nosegneg/$f . done Regards Andreas -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 559 1617 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram 25 Jahre DV-RATIO "ein Vierteljahrhundert Zuverlässigkeit" signature.asc Description: OpenPGP digital signature
Bug#518133: libc6-xen: nosegneg not selected when running in OpenVZ under Xen
Package: libc6-xen Version: 2.7-18 Severity: normal Hello, this bug report is about improving libc6's "I'm under Xen" - detection. The situation "OpenVZ guest below Xen domU as OpenVZ host" should be detected, and libc6-xen should be used in this situation. This has been working fine under Etch, but fails to work in a mixed Etch host / Lenny guest environment. Here are the details: I rent a Xen domU guest from some hosting company. That Xen guest is running a kernel supplied by myself, from some package ovzkernel-xen_2.6.18-54.1_i386.deb, 32 bit. I did not get that kernel from any official Debian source. I think I originally obtained it from http://download.openvz.org/debian/ , but I'm not absoultely sure. If so, the kernel is no longer available there. Privately, I still have that .deb archive I originally used to install the kernel. That Xen guest runs Debian Etch, with libc6-xen version 2.3.6.ds1-13etch9+b1, and shows no problems. I use that Etch installation as an OpenVZ host. So virtualization on top of virtualization, Xen guest = OpenVZ host. (Roughly, the Xen virtualization is for economics, the OpenVZ virtualization is for security. It's been working out very nicely for me thus far.) Most of my OpenVZ guest instances also run under Debian Etch at this point in time, again with no problems. I want to update this entire setup to Lenny. For my first stab at that, I upgraded just one OpenVZ guest to Lenny. This is guest 156. I have, of course, been installing the new libc6-xen version 2.7-18 in 156. As far as visible from within, the OpenVZ guest seems to be running fine. But one level below, at the OpenVZ host machine, I keep seeing log messages ... kernel: 4gb seg fixup, process ... (pid ...), cs:ip ... I interpret this as Xen is complaining that the libc6-xen is not being used, but the plain vanilla libc6 is. Checking the process ids, I found that the processes that use the wrong libc6 always belong to the Lenny VZ guest 156. Shutting down 156 makes the problem disappear. (But, obviously, the services 156 is intended to provide also disappear). I doublechecked with "ls -u", and indeed, 156 is using the wrong version of libc. The correct ones have not been read for several weeks: vzhost:/var/lib/vz/private/156/lib# ls -ltu i686/nosegneg/libc*so libc*so -rwxr-xr-x 1 root root 1294572 2009-03-04 10:43 libc-2.7.so -rw-r--r-- 1 root root 38296 2009-03-04 10:39 libcrypt-2.7.so -rwxr-xr-x 1 root root 1425828 2009-02-20 14:11 i686/nosegneg/libc-2.7.so -rw-r--r-- 1 root root 185816 2009-02-20 14:11 i686/nosegneg/libcidn-2.7.so -rw-r--r-- 1 root root 38296 2009-02-20 14:11 i686/nosegneg/libcrypt-2.7.so -rw-r--r-- 1 root root 185816 2009-02-20 14:11 libcidn-2.7.so This problem does not occur with the Etch libc6-xen version. For comparison, my Etch VZ guest 153 has that version, and it is being used. On that machine, it is the plain vanilla libc version that has not been read for several weeks: vzhost:/var/lib/vz/private/153/lib# ls -ltu libc*so tls/i686/cmov/libc*so -rw-r--r-- 1 root root 1253680 2009-03-04 11:18 tls/i686/cmov/libc-2.3.6.so -rw-r--r-- 1 root root 21868 2009-03-04 10:58 tls/i686/cmov/libcrypt-2.3.6.so -rwxr-xr-x 1 root root 1147548 2009-02-11 22:51 libc-2.3.6.so -rw-r--r-- 1 root root 181684 2009-02-11 22:51 libcidn-2.3.6.so -rw-r--r-- 1 root root 21868 2009-02-11 22:51 libcrypt-2.3.6.so -rw-r--r-- 1 root root 185780 2009-02-11 22:51 tls/i686/cmov/libcidn-2.3.6.so Regards, and thank you for providing fine software, Andreas The following information is about 156: -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-53.1.19.el5.028stab053.14xen (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages libc6-xen depends on: ii libc6 2.7-18 GNU C Library: Shared libraries libc6-xen recommends no packages. libc6-xen suggests no packages. -- no debconf information -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 559 1617 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram 25 Jahre DV-RATIO "ein Vierteljahrhundert Zuverlässigkeit" signature.asc Description: OpenPGP digital signature
Bug#275164: Sympa no longer available here - need to orphanate bugs.
Hello, Paul and all, it's been more than four years since I've filed my last Debian bug report on sympa. Shortly afterwards, my company has discontinued the use of that software. I frankly don't want to spend the time of messing with it again, just to support my ol' bug reports from back then. Plenty of other issues are dearer to my heart (and my boss's) to occupy my time then those. So, in effect, I orphan bugs 149285, 275001, 275012, 275147, and 275164. May they find some kind soul that actually uses sympa and can check the validity. Paul, a big thank you for finally attending to those old ones! Sorry I'm of no better help to the cause here. Best regards, Andreas -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 559 1617 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram 25 Jahre DV-RATIO "ein Vierteljahrhundert Zuverlässigkeit" signature.asc Description: OpenPGP digital signature
Bug#510571: Spurious "#" generated in mason_example output [patch].
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Package: libhtml-mason-perl-examples
Version: 1:1.39-1
Severity: Minor
The output generated by various mason examples, e.g.,
http://localhost/mason_example/index.html ,
contains a spurious "#". That is displayed by the browser next to the
"powered by Mason" logo, and can be found in the generated HTML code
in the as follows:
>
>
> #
>
>
>
>
>
This output is the result of a line
#<% $ENV{UNIQUE_ID} %>
in
/usr/share/doc/libhtml-mason-perl-examples/examples/mason_example/autohandler
resp. its active copy /var/www/mason_example/autohandler .
I guess someone tried to comment out that line, but did not quite succeed.
Compare http://www.masonhq.com/docs/manual/Devel.html#comment_markers .
As that line does not seem to serve any particular purpose, I suggest
removing it. The trivial patch is included.
Regards, and thank you for providing fine software,
Andreas
- --
andreas.krue...@famsik.de
PGP-Schlüssel 0xA207E340 (http://blackhole.pca.dfn.de/)
Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340
- --- /var/www/mason_example/autohandler.original 2008-07-25
04:48:35.0 +0200
+++ /var/www/mason_example/autohandler 2009-01-03 11:29:08.0 +0100
@@ -28,7 +28,6 @@
% if ($ENV{REMOTE_USER}) {
You are logged in as "<% $r->connection->user |h%>"
% }
- -#<% $ENV{UNIQUE_ID} %>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.0 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJX0NanWrlKaIH40ARAlr3AJ4kSa1JVB1ybwL4hYaVGSeg4meBVQCfRWJQ
vZAHNFPQsDtjnaRvdC8ybII=
=p0ys
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#451714: Patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I ran into the same problem this afternoon. For one quick fix, spelling out /mason_example/index.html seems to work. For a more substantial cure, I found that specifying the extensions of the files that should be served using mod_perl helps. I attach a patch, to be applied to /etc/apache2/conf.d/libhtml-mason-perl-examples.conf , that has been working for me. Finally, I found https://issues.apache.org/bugzilla/show_bug.cgi?id=25435 which gives background information to our problem. Regards, and thank you for providing fine software, Andreas - -- andreas.krue...@famsik.de PGP-Schlüssel 0xA207E340 (http://blackhole.pca.dfn.de/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 - --- libhtml-mason-perl-examples.conf.ori 2009-01-02 17:28:59.0 +0100 +++ libhtml-mason-perl-examples.conf2009-01-02 21:51:02.0 +0100 @@ -3,10 +3,12 @@ PerlModule CGI::Cookie - -SetHandler perl-script - -PerlResponsehandler HTML::Mason::ApacheHandler - -PerlSetVar MasonArgsMethod CGI - -# CGI was previously required for Mason to work in Apache2 + + SetHandler perl-script + PerlResponsehandler HTML::Mason::ApacheHandler + PerlSetVar MasonArgsMethod CGI + # CGI was previously required for Mason to work in Apache2 + -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJXn6RnWrlKaIH40ARAl00AJwK8SVvLi/YJg4Vg/hqSqEFOvRDXwCdEUcC cM8aANv6FUEHKb8kQ0Ghr+Y= =VWBU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#492471: java-gcj-compat: Cyclic symlink /usr/share/man/man1/gcj-dbtool.1.gz .
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: java-gcj-compat Version: 1.0.65-10 Severity: normal Hello, kindly look at this mess (a few line breaks inserted to make it more readable): $ file /usr/share/man/man1/gcj-dbtool.1.gz /usr/share/man/man1/gcj-dbtool.1.gz: broken symbolic link to `/etc/alternatives/gcj-dbtool.1.gz' $ ls -l /usr/share/man/man1/gcj-dbtool.1.gz lrwxrwxrwx 1 root root 33 2005-10-23 15:25 /usr/share/man/man1/gcj-dbtool.1.gz -> /etc/alternatives/gcj-dbtool.1.gz $ ls -l /etc/alternatives/gcj-dbtool.1.gz lrwxrwxrwx 1 root root 46 2005-10-23 15:25 /etc/alternatives/gcj-dbtool.1.gz -> /usr/lib/jvm/java-gcj/man/man1/gcj-dbtool.1.gz $ ls -l /usr/lib/jvm/java-gcj/man/man1/gcj-dbtool.1.gz lrwxrwxrwx 1 root root 49 2007-01-13 21:16 /usr/lib/jvm/java-gcj/man/man1/gcj-dbtool.1.gz -> ../../../../../share/man/man1/gcj-dbtool-4.1.1.gz $ (cd /usr/lib/jvm/java-gcj/man/man1/../../../../../share/man/man1; pwd) /usr/share/man/man1 The good news: cd /usr/share/man/man1; file * | grep broken gives only this and no other such problem. Regards, and thank you for providing fine software, Andreas - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-openvz-18-53.5d1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages java-gcj-compat depends on: ii fastjar 1:4.1.1-21 Jar creation utility ii gij-4.1 4.1.1-20 The GNU Java bytecode interpreter ii java-common 0.25 Base of all Java packages ii libgcj-common 1:4.1.1-21 Java runtime library (common files ii libgcj7-jar 4.1.1-20 Java runtime library for use with java-gcj-compat recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIixmjnWrlKaIH40ARApp1AJwMZEdJ1G5CFS3NPgLpPv/ayvc13ACdEH6q ktV7B3+hb9jBDfgp4U4VKF8= =yew8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485572: lvm2: Outdated README? (suggests root on LVM is not supported by Debian initrds).
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: lvm2 Version: 2.02.06-4etch1 Severity: minor Please review the content of /usr/share/doc/lvm2/README.Debian. In particular: > This doc directory contains a script called lvm2create_initrd. This > is to help people who want to run LVM2 as their root filesystem. It > is not compatible with the Debian initrds so you should only use > this script if you really know what you are doing. The wording may well be precise if read carefully. But it does create the impression that "root on LVM2" is not supported by standard Debian initrds. That, at least, is no longer true (at least not on the architecture I'm using). I am not aware of any Howto "port existing Debian 'root on /dev/hd* or /dev/sd*' to LVM". If such exists, it should probably be mentioned in the README. Regards, and thank you for providing fine software, Andreas Krüger - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://blackhole.pca.dfn.de/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages lvm2 depends on: ii debconf [debconf-2.0] 1.5.11etch1 Debian configuration management sy ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libdevmapper1.02 2:1.02.08-1 The Linux Kernel Device Mapper use ii libncurses55.5-5 Shared libraries for terminal hand ii libreadline5 5.2-2 GNU readline and history libraries ii libselinux11.32-3SELinux shared libraries ii libsepol1 1.14-2Security Enhanced Linux policy lib ii lvm-common 1.5.20The Logical Volume Manager for Lin lvm2 recommends no packages. - -- debconf information: lvm2/snapshots: -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITjc1nWrlKaIH40ARAmBaAKCZjL5G4qbjUSKyvHBrkaKb6Oq5bwCfbr0C 4vW4+OUAg/6dI70b/GcJXxg= =JDgP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#458905: gnuplot-info.1.gz and gnuplot-info.2.gz missing from /usr/share/info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Cyril, I ran into that same bug this evening and was about to report it, when I saw that had already been done. I did not try to rebuild the package locally, and this bug is no really big deal as there is good html documentation. But here is what I guess might have happened: As part of the package build, files gnuplot.info.gz, gnuplot.info-1.gz and gnuplot.info-2.gz have been generated (by makeinfo from the source gnuplot.texi). Of these, only gnuplot.info.gz made it into the .deb, the other two are missing. As gnuplot.info.gz contains only references, the meat of the documentation is missing indeed, as far as info is concerned. Regards, and thank you for providing fine software, Andreas Krüger - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://blackhole.pca.dfn.de/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFISD05nWrlKaIH40ARApn6AJ4oR5nggr9VsPGD/5unN/WCIOjwvwCfcLfI C+IkwIXWsWRjjNaAn9+fbk4= =BlNE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#481572: btlaunchmanycurses.bittornado please fully redraw screen on ^L
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: bittornado Version: 0.3.17-1 Severity: minor I'm using btlaunchmanycurses.bittornado on a console-type terminal to seed files. It gives me a nice screen that keeps me up to date on what's going on with transfers. I like that. The internet connection services delivered by my DSL provider is flaky: The connection breaks down regularly once every 24 hours. These breakdowns cause syslogd to write error messages to that same console window. After briefly scanning those messages, I typically want to have that bittornado information back. So I type the customary CTRL-L. Expected behavior: This should cause btlaunchmanycurses to redraw its entire screen, so the syslogd messages are gone. Behavior seen: The screen is only partly redrawn, resulting in a garbled overall layout. Regards, and thank you for providing fine software, Andreas - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-vserver-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages bittornado depends on: ii python2.4.4-2An interactive high-level object-o ii python-support0.5.6 automated rebuilding support for p Versions of packages bittornado recommends: ii mime-support 3.39-1 MIME files 'mime.types' & 'mailcap - -- no debconf information - -- [EMAIL PROTECTED] PGP-Key 0xA207E340 (http://blackhole.pca.dfn.de) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFILnnVnWrlKaIH40ARAkWxAJ0Yol/252JQqLhEomTOA5BK7HSk5QCfWd/l 3qq/FUECUy9TeOv1nL9hlus= =FyJt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#451775: xvnc4viewer: "Local loop-back connections are disabled." - server or client?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: xvnc4viewer Version: 4.1.1+X4.3.0-21 Severity: minor I had some ssh port-forwarding tunnel rigged up for the VNC port 5900 and tried to fire up "xnc4viewer localhost", to use that tunnel and connect to the remote VNC server. That failed as follows: > $ xvnc4viewer localhost > > VNC Viewer Free Edition 4.1.1 for X - built Feb 26 2007 20:38:07 > Copyright (C) 2002-2005 RealVNC Ltd. > See http://www.realvnc.com for information on VNC. > > Sun Nov 18 13:27:34 2007 > CConn: connected to host localhost port 5900 > > Sun Nov 18 13:27:35 2007 > CConnection: Server supports RFB protocol version 3.4 > CConnection: Using RFB protocol version 3.3 > main:Local loop-back connections are disabled. I wasted some time probing into the wrong direction, until I realized that the error message "Local loop-back connections are disabled." is non-local, but comes from the remote server. (So no amount of tweaking of the client could possibly help.) In my opinion, this error message could be improved easily. The fairly meaningless "main:" might be replaced with "server says:", or whatever else is appropriate. Best regards, and many thanks for providing fine software, Andreas - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages xvnc4viewer depends on: ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries ii libgcc11:4.1.1-21GCC support library ii libice61:1.0.1-2 X11 Inter-Client Exchange library ii libsm6 1:1.0.1-3 X11 Session Management library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii zlib1g 1:1.2.3-13compression library - runtime xvnc4viewer recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQDY1nWrlKaIH40ARAtCCAJsHlFgqjKm1jYTisSfdOVQZilVX/QCggNiG IhSnsvjptv3hPKjJQlB5BBA= =qvVL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447161: util-vserver: man vserver does not mention --help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: util-vserver Version: 0.30.212-1 Severity: normal The manual page of the vserver command does not mention the --help option. In general, vserver - command --help seems to produce quite a bit of valuable information (actually more than is available on the man page itself). At least this is true for the special case of the build command. This should be mentioned in the manual page. I found that hint over at http://linux-vserver.org/Installation_on_Debian Regards, and thank you for providing fine software, Andreas Krüger - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-vserver-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages util-vserver depends on: ii debconf1.5.11Debian configuration management sy ii iproute20061002-3Professional tools to control the ii libbeecrypt6 4.1.2-6 open source C library of cryptogra ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries ii make 3.81-2The GNU version of the "make" util ii net-tools 1.60-17 The NET-3 networking toolkit Versions of packages util-vserver recommends: ii binutils2.17-3 The GNU assembler, linker and bina ii debootstrap 0.3.3.2etch1 Bootstrap a basic Debian system - -- debconf information: util-vserver/postrm_remove_vserver_configs: false util-vserver/prerm_stop_running_vservers: true -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHF3AznWrlKaIH40ARAna4AKC1IC+EhrnTr9+X2+dOZhUQ/mBPSgCfTeQn cwqPmXxc6w4x2r3d5X569Cw= =zo65 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447162: util-vserver Any user should be able to access --help.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: util-vserver Version: 0.30.212-1 Severity: minor vserver - build --help and similar "help only" commands should not require root privileges to run. Presently, trying to run those as user results in: $ /usr/sbin/vserver - build --help vnamespace: clone(): Operation not permitted Regards, and thank you for providing fine software, Andreas Krüger - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-vserver-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages util-vserver depends on: ii debconf1.5.11Debian configuration management sy ii iproute20061002-3Professional tools to control the ii libbeecrypt6 4.1.2-6 open source C library of cryptogra ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries ii make 3.81-2The GNU version of the "make" util ii net-tools 1.60-17 The NET-3 networking toolkit Versions of packages util-vserver recommends: ii binutils2.17-3 The GNU assembler, linker and bina ii debootstrap 0.3.3.2etch1 Bootstrap a basic Debian system - -- debconf information: util-vserver/postrm_remove_vserver_configs: false util-vserver/prerm_stop_running_vservers: true -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHF3ExnWrlKaIH40ARAuxjAJ98OWZtluX5qUwTpLFwTwIsviPgxQCgtk/f KXa2aBtNrKTiZeYaYEC73vY= =UksT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443520: Subject: clisp: Error on startup "invalid byte #xC3 in CHARSET:ASCII conversion"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Pierre, > Not so sure it's a bug in clisp, though. I have a bunch of files with > names encoded in ISO-8859-15 and I copied one in my $HOME with an > accentuated character, then invoked clisp while having fr_FR.UTF-8 as my > locale (where the byte encoding of the previously mentioned character is > not a legal one). I have done a bit more experimentation. Apparently, no just any illegal name triggers the problem. However, the following line, executed in your $HOME, produces a file name that reliably triggers the problem (Lisp running under an UTF-8 regime). perl -e '$w = ">weird-name-" . (pack "C", 196) . "M"; open F, $w' I don't think fr_FR or de_DE makes that much of a difference (just guessing). Could you please tell me whether you reproduce? Regards, Andreas - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+SV5nWrlKaIH40ARAg8jAJ97EWsqBkm/BTRklWoPYqMscvJUEwCgpipk 8vsxnfID9xgnOB06WCxtDaI= =iGSY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443520: [cl-debian] Bug#443520: Subject: clisp: Error on startup "invalid byte #xC3 in CHARSET:ASCII conversion"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Pierre, oops - this message got sorted differently in my Email tool, as there was no Debian bug in the CC or To. > For every locale where you encounter the bug, can you check what > /usr/sbin/validlocale says? Sure: for l in [EMAIL PROTECTED] de_DE.UTF-8 de_DE.ISO-8859-1 C; do echo $l; /usr/sbin/validlocale $l; echo; done Results in: [EMAIL PROTECTED] locale '[EMAIL PROTECTED]' valid and available de_DE.UTF-8 locale 'de_DE.UTF-8' valid and available de_DE.ISO-8859-1 locale 'de_DE.ISO-8859-1' valid and available C locale 'C' valid and available So all locales are valid. All of them but de_DE.ISO-8859-1 gave the problem while I still had the file with the bad name. Cheers, Andreas - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+BqznWrlKaIH40ARAgZ3AJ9nwmrHngDPKnfEZvcssYHLBzdg5QCfbn7d QWjFJphXNoJ856qZuNkNapY= =tyY6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443520: Subject: clisp: Error on startup "invalid byte #xC3 in CHARSET:ASCII conversion"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Peter, > I think I know what causes your problem: it is caused by having a > file in your home directory with a name that cannot be encoded with > the locale you're trying to use. Bingo! That was the ticket! I had an ancient file with an ISO-8859-1 name in my $HOME. That name contained characters illegal in ASCII and also was not legal in UTF-8. Renaming that file solved the problem. For the record, that file name had nothing to do whatsoever with LISP / clisp. > It is unclear how to fix this, as it is normal that an error should > be displayed an easy fix it to use a locale that uses UTF8 More precisely, "to use a locale that can display all file names in the $HOME directory". Which, in my case, was "ISO-8859-1". > clisp stumbles across this file while searching for its > .clisprc.lisp file in the home directory, Weird. Why does clisp think it needs to read my entire $HOME? As far as LISP is concerned, I'm a beginner. In other programming languages, I would have coded a "stat" to see whether ".clisprc.lisp" is there, and then an "open" if it is. Or else, I might have tried to open, and handle whatever "file not there" error I might get. Is it not straightforward to do this in LISP? Anyway. Thank you, Peter! Cheers, regards, warm greetings (on this sunny morning here in Germany) Andreas - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG92fJnWrlKaIH40ARAqm6AKCLDhWXZEqYR1n6jslIFDGyg7BX7ACfRQkP IMV1fLQVhdMtp2zJ9IMdmy0= =cjRI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443520: [cl-debian] Bug#443520: Subject: clisp: Error on startup "invalid byte #xC3 in CHARSET:ASCII conversion"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Pierre, de_DE.UTF-8, which is configured on my machine, does not work for me. Even "C" doesn't! However, I have found out, and verified, that old de_DE.ISO-8859-1 does not show the problem. So that is a workaround for me, for the time being. Details (using bash): for l in [EMAIL PROTECTED] de_DE.UTF-8 de_DE.ISO-8859-1 C; do echo "$l"; export LANG="$l"; clisp -c /dev/null 2>&1 | grep CHARSET; echo; done Result was: [EMAIL PROTECTED] *** - Ungültige Byte-Folge #xC4 #x55 in CHARSET:UTF-8 Konversion de_DE.UTF-8 *** - Ungültige Byte-Folge #xC4 #x55 in CHARSET:UTF-8 Konversion de_DE.ISO-8859-1 C *** - invalid byte #xC3 in CHARSET:ASCII conversion I guess some start up file has been coded in ISO-8859-1, but also gets read for both UTF-8 and C/ASCII? Regards, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG9jQHnWrlKaIH40ARAmJ7AKCrsrDvjW2+OK5tvtaPaW21Etd//gCdHbII uZfKFQTTXydTnHRbuIXIVZw= =GJZ9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443520: Subject: clisp: Error on startup "invalid byte #xC3 in CHARSET:ASCII conversion"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: clisp Version: 1:2.41-1 Severity: normal I cannot run clisp without getting this error, see below. (I'm a Lisp beginner.) Best regards, and thank you for providing fine software, Andreas Krüger - --- $ LANG=C clisp i i i i i i i ooooo o o I I I I I I I 8 8 8 8 8 o 88 I \ `+' / I 8 8 8 888 \ `-+-' / 8 8 8 o 8 `-__|__-'8 8 8 8 8 |8 o 8 8 o 8 8 --+-- o8oo ooo8ooo o 8 Copyright (c) Bruno Haible, Michael Stoll 1992, 1993 Copyright (c) Bruno Haible, Marcus Daniels 1994-1997 Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998 Copyright (c) Bruno Haible, Sam Steingold 1999-2000 Copyright (c) Sam Steingold, Bruno Haible 2001-2006 *** - invalid byte #xC3 in CHARSET:ASCII conversion The following restarts are available: ABORT :R1 ABORT ABORT :R2 ABORT ABORT :R3 ABORT ABORT :R4 ABORT ABORT :R5 ABORT Break 1 [6]> - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-openvz-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages clisp depends on: ii common-lisp-controller 6.9 This is a Common Lisp source and c ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries ii libice61:1.0.1-2 X11 Inter-Client Exchange library ii libncurses55.5-5 Shared libraries for terminal hand ii libreadline5 5.2-2 GNU readline and history libraries ii libsm6 1:1.0.1-3 X11 Session Management library ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxpm41:3.5.5-2 X11 pixmap library clisp recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG9GgMnWrlKaIH40ARAr+GAJ9qScEDZ7BXkfPcl7W5L3NQgAaWqQCeIEce WsET80tzecFYFZJ3DkWpw6o= =S6HS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#391172: gnomermind: Help does not open help file.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Chess, > I am working on becoming the maintainer of this package and if that > occurs, I might mark this bug as closed since it seems that it's not > really a gnomermind bug, but a libgnome32 bug, though my lack of C > skills could mean my investigation and conclusions are incorrect. :-) Should a bug marked "closed" while the problem still persists? I think you might have a case to move the bug over to libgnome32. Regards, and three cheers to you for volunteering to become a package maintainer! Andreas - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG9AKRnWrlKaIH40ARAuBjAKCEbpIhG0tuQbeamGpwAOIAkzi+ywCgpqLB bgg0enPmezSLiNB7CkVZGEE= =Z1nN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435171: enigmail: README.Debian instructions no longer cure update problem.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Alexander, > yes ... i think recipient key dialog is broken ... same for key > management. I always thought it was just key management, but its > likely that its recipient dialog too. Indeed, it was worse than I had thought: The recipient key worked for one mail, but then it broke again (with no intervening installation). Regards, and I appreciate your efforts, Andreas - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGrXv2nWrlKaIH40ARAjGjAJ44FGiLVMYYR5PObbU9FbgEjX8HBgCeI7ra l8oHi45nKqlJSP1mZX2eul8= =RTJv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435171: enigmail: README.Debian instructions no longer cure update problem.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: enigmail Version: 2:0.94.2-1 Severity: normal The instructions from /usr/share/doc/enigmail/README.Debian no longer work. I'm guessing why: There no longer is a file "chrome.rdf", and it is unclear which file needs to be removed instead. In passing, these lines are clearly out of date and do not reflect the present names: > apt-get install mozilla-thunderbird-enigmail > 1. stop thunderbird > 3. start thunderbird This is a Etch machine, aka "stable". I have followed recent updates from the stable parts of the distribution. One of those caused Enigmail to quit working. Particularily, when I want to send an encrypted email, upon pressing "send" nothing happens for some time (but I see a lot of CPU load). Then the warning comes up: "A script on this page is busy, do you want to continue or stop the script." (Translated from the German original text I see.) Continuing produces the same warning, after some time. When I stop the script, enigmail has not found the recepient's key (though that is in my GPG keyring), but displays an empty choice box. The enigmail console says it has been running enigmail> /usr/bin/gpg --charset utf8 --batch --no-tty --status-fd 2 - --with-fingerprint --fixed-list-mode --with-colons --list-keys When I rerun this command in a terminal, it seems to run all right and returns quite a few lines. So it seems the output is not parsed correctly. I follow the advice from Bug 427591: * Stop icedove, * remove file extensions.ini, * purge enigmail, * run icedove one more time (yes, enigmail is gone), * stop icedove, * install enigmail * start icedove. Enigmail was there, and my previous settings were remembered (in spite of the "purge"). But the problem was still there, also: Choosing the recepient's key did not come back. I became more desperate: Manually edited .rdf files containing "enigmail" occurances. And I found both /usr/bin/gpg and also /usr/bin/gpg2, so I tried /usr/bin/gpg2. Some of these changes finally worked - which, I don't know. Please, provide up to date information in that README.Debian file. Sad as it is, we still depend on it! Regards, and thank you for providing fine software, Andreas - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-vserver-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages enigmail depends on: ii gnupg 1.4.6-2 GNU privacy guard - a free PGP rep ii icedove1.5.0.12.dfsg1-0etch1 free/unbranded thunderbird mail cl ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libgcc11:4.1.1-21GCC support library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 enigmail recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGrPDynWrlKaIH40ARAlzHAJ9ZWNkghSXF6SMJTvGmctQ6C1Ss/ACgr7y0 YDySeDsP3MKrvjH51jnd94c= =ABZW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348641: TCP keepalive within redir
Hello, Daniel, to continue the discussion started at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348641 (and I've also added Nigel and Sammy to the CC): > It sounds like you're suggesting that redir use TCP keepalive > settings. Yes. > Have you considered using socat for your purposes? At this point, I no longer need to solve that particular problem that I used redir for. Should I ever have a problem like this again, and most such problems I tend to solve these days do involve TCP keepalive, I will strongly consider socat. Thank you for the suggestion! But you're loosing a customer here... ;-) > You may also be interested in libkeepalive: In my opinion, libkeepalive somewhat of a temporary hack. Good to have around in an emergency. But it definitely has a smell to it. But again, thank you for pointing that out. > Given these other options, if you still feel that this functionality > belongs in redir, please followup here and we'll sort it out. I take you on that offer: Yes. I still do feel that way. Firstly, let me make a case that TCP-keepalive is useful. For me, TCP connection redirection solves all kinds of little network problems. In the consumer end of these day's internet, dynamic IP is there to stay. UMTS and similar wireless communication is on it's way in. In general, there is a lot of connectivity that's offered on the market. Much of that is intended, by the providers, for "client" use. But that same network connectivity can be used be the creative for "server" service, too. To do so, one needs a little imagination, redir functionality, and some bridge-head-box out fixed-IP netland. Plus TCP-keepalive. Dynamic IP demands it. Wireless demands it. The ubiquitous NAT demands it. In all of these cases, "client" connections are somewhat flaky. That by itself is often not a big problem. It can be fixed if I hasten to rebuild the connection quickly, each time, after it came done. But in order to be able to do so, I need to find out about connection death. Which is exactly what I need TCP keepalive (or something like it) for. Personally, I use the ssh port forwarding functionality all the time. Almost literally "all the time", one particular such forwarding runs straight from my /etc/inittab ;-) . And I find something like "-o ServerAliveInterval=20 -o ServerAliveCountMax=7" essential in most such operations. Secondly, why would I expect this functionality particularily in redir? Well, of that I'm not entirely sure. It depends. How does redir position itself, in particular in comparison with socat? That one I'm not in a position to answer. That's up to Sammy, or Nigel, or you, or whoever presently "owns" redir. That said, I can make a suggestion. My suggestion would be: Redir focus is on the plain TCP/IP case. And redir does that case well. Whereas socat, in comparision, tries to cover all things socket (and even some things file descriptor), tries to be more universal, tries to be a jack-of-all-trades. But may not do any single one thing quite as well. This suggestion fits what I find. Redir already supports FTP proxy, which socat doesn't. Redir already supports bandwidth throttling, which socat doesn't. In my opinion, TCP keepalive is an issue that also belongs to redir and should be implemented by it. I would expect redir to do TCP keepalive, and would be surprised that socat does it, too. - Not the other way round, as is presently te case. This particular features generates quite a few command line options, yes. But it would not bloat the code much, could be implemented in a few hours (do you want me do do it?). And has less overall impact than either bandwidth throttling or FTP proxy did. Another difference between the two, by the way: Redir is much easier on the paranoid user. The source code of redir is about 1/8 of that of socat (in lines of code), and it is much easier to review. In my opinion, TCP keepalive simply fits extremely well into redir's present profile. Regards, Andreas -- Dr. Andreas Krüger, Berater, DV-RATIO Nordwest GmbH [EMAIL PROTECTED] GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 Sitz der Gesellschaft: Leostrasse 31, 40545 Düsseldorf, Germany Tel.: +49 211 577 996-0, Fax: +49 211 559 1617 Registergericht Düsseldorf HRB 34330 Ust-IdNr.: DE811321837, Steuer-Nr. 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram 25 JAHRE DV-RATIO "ein Vierteljahrhundert Zuverlässigkeit" signature.asc Description: OpenPGP digital signature
Bug#425029: yacas: Plot2D broken tmpfile handling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Package: yacas
Version: 1.0.57-3
Severity: important
The Plot2D function of yacas communicates with gnuplot through
temporary files. The name of the files is hard-wired into yacas, as
follows:
A new directory /tmp/plot.tmp is created, if it does not yet
exist. And files gnuplot.in and data1 under that directory are used
for the temporary files.
This opens up a "tmp file vulnerability" and is simply not appropriate
for a mutliuser system like Linux.
For one, it is not mutliuser - safe. Try this:
As one user, start yacas, and type, at the prompt,
Plot2D(Sin(x), 0:10)
("Sin", not "sin")
Assuming you also have gnuplot installed, a nice sin graph will pop
up.
A second user trying the same, while the first is still looking at the
nice graph, will not suceed. The /tmp/plot.tmp directory is owned by
the first user, and the files can not be written by the second.
There is even a race condition problem if only one user has several
instances of yacas up and running in parallel (as I sometimes do).
And, this stuff is outright dangerous: If someone maliciously sets up
/tmp/plot.tmp/data1 as a symbolic link pointing to any old file
somewhere in the file system, yacas will happily overwrite that file
with the plot data.
So if I know you're using yacas' Print2D, I can set things up in the
/tmp directory so that yacas will trash any of your files (e.g., your
mailbox, or your GPG key, or your ssh key (or even /etc/passwd, if you
are root).
It is because of this danger I've decided to file this with severity
"important".
In my opinion, to create a new directory is a good idea. But yacas
should make sure nothing of that name already exists beforehand. And
there should be no time wasted: The check and the file creation must
happen atomically. In other words, it must not even theoretically be
possible to set things up maliciously between the existence check and
the creation. If the directory already does exists, a fresh directory
name (preferably unpredictable) should be used.
Compare the Debian policy:
http://www.debian.org/doc/debian-policy/ch-files.html
which has a little remark on temp files in 10.4.
Regards, and thank you for providing fine software
Andreas
- -- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-vserver-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)
Versions of packages yacas depends on:
ii debianutils2.17 Miscellaneous utilities
specific t
ii dillo [www-browser]0.8.5-4.1 Small and fast web browser
ii freeglut3 2.4.0-5 OpenGL Utility Toolkit
ii iceweasel [www-browser 2.0.0.3-1 lightweight web browser
based on M
ii konqueror [www-browser 4:3.5.5a.dfsg.1-6 KDE's advanced file
manager, web b
ii libc6 2.3.6.ds1-13 GNU C Library: Shared
libraries
ii libgcc11:4.1.1-21GCC support library
ii libgl1-mesa-glx [libgl 6.5.1-0.6 A free implementation of
the OpenG
ii libglu1-mesa [libglu1] 6.5.1-0.6 The OpenGL utility
library (GLU)
ii libgsl01.8-2 GNU Scientific Library
(GSL) -- li
ii libice61:1.0.1-2 X11 Inter-Client Exchange
library
ii libsm6 1:1.0.1-3 X11 Session Management
library
ii libstdc++6 4.1.1-21 The GNU Standard C++
Library v3
ii libx11-6 2:1.0.3-7 X11 client-side library
ii libxext6 1:1.0.1-2 X11 miscellaneous
extension librar
ii libxi6 1:1.0.1-4 X11 Input extension library
ii libxmu61:1.0.2-2 X11 miscellaneous utility
library
ii libxt6 1:1.0.2-2 X11 toolkit intrinsics
library
ii lynx [www-browser] 2.8.5-2sarge2.2 Text-mode WWW Browser
ii w3m [www-browser] 0.5.1-5.1 WWW browsable pager with
excellent
ii yacas-doc 1.0.57-3 Documentation for Yacas
yacas recommends no packages.
- -- no debconf information
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGTca+nWrlKaIH40ARAoPwAJwJZFZrFHxqS6cTiRkCj9R0xQggnQCeJHig
XItxDC5/jQ0aeUcc4gD+wxU=
=K8Ch
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#254485: yacas depends on yacas-doc for online help: Suggest "wontfix" for 254485.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When I starting yacas on my system, it makes the following promises
(edited for brevity):
> Type ?license or ?licence to see the GPL;
> type ?warranty for warranty info.
> Type ?? for help.
> Or type ?function for help on a function.
After optionally doing something like
SetHelpBrowser("iceweasel");
do try any of those, e.g.,
??
You will understand why yacas should indeed depend on yacas-doc:
Yacas-doc provides the files required for the runtime help of Yacas to
work properly.
So, in my opinion, this Debian-Bug 254485
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=254485
is invalid and should be closed without further action (wontfix).
Best regards, and thank you (the maintainer) for providing fine software,
Andreas
- --
[EMAIL PROTECTED]
PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/)
Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGTKdHnWrlKaIH40ARAoxaAJ4sAVM98sd6vmMSYiOvaTfEDOXNsACgoP+A
7YyYAQ7wZewC5bNSyIh/Ij8=
=HB9G
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#424889: yacas-doc: Problem is gone when books.html is found - renaming bug report.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 retitle 424889 yacas-doc: Please copy books.html to index.html thanks Only after filing the bug report did I find the "books.html" file. That should really be the first thing in the documentation one looks at. Originally, I had assumed that "books.html" would be something close to what you get when you type "man perlbook" (having installed perl-doc). Which was not the type of information I was looking for. So, for this reason, this was one of the last files I looked at. When one doesn't find that, but browses through the html files manually, it is somewhat confusing to have all the info twice. After one has found this wonderful index, the duplication problem disappears (discontinues being a problem) and it all falls into place. Could you please provide a copy of books.html under the name "index.html"? Or rename it to that name? Or provide an "index.html" that simply refers to "books.html" as the appropiate entry point? Either of those would help people like myself find their way around the documentation considerably faster. Regards, and thank you for providing fine software Andreas - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTJhUnWrlKaIH40ARAm4gAKCJDymY7MtNRGCAud1L0pPbbt2gdgCgt4zw 1vF/pv6ZI+RpANUaJtMKuuQ= =wnJZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#424889: yacas-doc: Much of the documentation contained twice.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: yacas-doc Version: 1.0.57-3 Severity: minor As far as I can tell, /usr/share/doc/yacas-doc/html/essays.html contains the same material, in one big file, as do /usr/share/doc/yacas-doc/html/essayschapter*.html, in individual files, one per chapter. Similar things are true for other yacas documentation materials as well. In my opinion, it is not useful, but wasteful, to have the documentation twice on the hard disk, the only difference being "few big files" vs. "many small files". Regards, and thank you for providing fine software, Andreas - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-vserver-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTH+/nWrlKaIH40ARAsHWAJ44c9IDwUpCLg8FUck5uZpum6RJEQCgq83O 9rorOFUQY+v6f1igpCRNnqU= =l7i2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#424878: yacas: New upstream version available.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: yacas Version: 1.0.57-3 Severity: wishlist As of this writing, an upstream version 1.0.63 is available of yacas at http://yacas.sourceforge.net/ . I would appreciate if that version were available for installation through Debian. I would particularily appreciate if that version could be made available for the current Debian stable version Etch. E.g., it would be fine if the package continues to not need anything that's not in Etch, as seems to be the case with the current 1.0.57-3. Alternatively, support through http://www.backports.org/debian would be fine also. Please pardon if a bug report in the official Debian system is not the right place for that second item. If so, just stay with the first. Regards, and thank you for providing fine software, Andreas - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-vserver-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages yacas depends on: ii debianutils2.17 Miscellaneous utilities specific t ii dillo [www-browser]0.8.5-4.1 Small and fast web browser ii freeglut3 2.4.0-5 OpenGL Utility Toolkit ii iceweasel [www-browser 2.0.0.3-1 lightweight web browser based on M ii konqueror [www-browser 4:3.5.5a.dfsg.1-6 KDE's advanced file manager, web b ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libgcc11:4.1.1-21GCC support library ii libgl1-mesa-glx [libgl 6.5.1-0.6 A free implementation of the OpenG ii libglu1-mesa [libglu1] 6.5.1-0.6 The OpenGL utility library (GLU) ii libgsl01.8-2 GNU Scientific Library (GSL) -- li ii libice61:1.0.1-2 X11 Inter-Client Exchange library ii libsm6 1:1.0.1-3 X11 Session Management library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxi6 1:1.0.1-4 X11 Input extension library ii libxmu61:1.0.2-2 X11 miscellaneous utility library ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library ii lynx [www-browser] 2.8.5-2sarge2.2 Text-mode WWW Browser ii w3m [www-browser] 0.5.1-5.1 WWW browsable pager with excellent ii yacas-doc 1.0.57-3 Documentation for Yacas yacas recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTGWWnWrlKaIH40ARAvV8AJkB8Qk8QVjRAr6BgRu/BICfvnvzFQCfXYGZ GJQtij0KitgAYNkAmws2jXY= =n3Fo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421791: kernel-patch-openvz: Please integrate with module-assistant.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 retitle 421791 kernel-patch-openvz: Please provide image+header packages in Debian thanks Hi, Ola, Summary: What I'd really like to have: The functionality that is available with the non-Debian packages from http://download.openvz.org/kernel/debian/etch/ should be available within Debian. This was not clear in my initial bug report, and actually, not even clear to me myself then. So I'm trying to fix that report, including a retitle operation. Details: First, let me thank you for your two emails regarding my bug. And accept my apologies: I'm afraid I have been less clear than I could have been. To briefly explain the Debian software "module-assistant": That software uses the header files of the running kernel, and some Debian kernel module source file package, to compile additional kernel modules, as the user requests. These are then wrapped into a Debian package (.deb file), which in turn can be used to install those kernel modules. My original bug report was written under the assumption that openvz could be loaded into the kernel as a kernel module. Most of the confusion came from that. I now no longer think that is possible. But it would be nice to use module-assistant to integrate Debian-provided kernel modules with Debian-provided openvz - Kernels. That is presently not possible, to my knowledge. But the only thing that is missing is, that Debian proper provides the kernels + headers packages as they are already available through http://download.openvz.org/kernel/debian/etch/ . In my particular case, I could not find those customary "image + header" packages in my aptitude. So my initial assumption was, "if it's not there, it's not needed, so openvz must be a kernel module". Not very clear thinking on my part, I admit. Only after some unsuccessful messing around, and then hunting through the documentation files, I learned that the usual "image + header" indeed are needed (to do what I wanted to do), but they are not provided within Debian, but externally. It's all not a big deal. This is only a wishlist bug, and remains that. Regards, and again thank you for the valuable work you are doing for the rest of us, Andreas - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGPHFPnWrlKaIH40ARAr5SAJ9oJYxa/Wb2tvWff3K6CGGCT0YZYACfRX30 WnwhL4p75O7YeJKmnkMW4bY= =GqbH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421791: Workaround: Kernel and header from download.openvz.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As a workaround, I installed both linux-image-2.6.18-openvz-k7_028.18.1-2.6.18-12-1_i386.deb and linux-headers-2.6.18-openvz-k7_028.18.1-2.6.18-12-1_i386.deb form http://download.openvz.org/kernel/debian/etch/ After I got that kernel up and running, module-assistant worked fine and was able to compile and install that additional module I was after. Regards, and thank you for providing fine software Andreas - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGN2HmnWrlKaIH40ARAvnWAKCiIDRQSvzJEw/y2txRYYM2S+n63QCeMM5y 2AJRBqlgnBPJdsgUakMsB34= =mSMV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421791: kernel-patch-openvz: Please integrate with module-assistant.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: kernel-patch-openvz Version: 028.18.1 Severity: wishlist It would be very nice indeed if kernel-patch-openvz could be installed using the services of module-assistant, on a plain Etch system. Regards, and thank you for providing fine software, Andreas - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-k7 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages kernel-patch-openvz depends on: ii bash 3.1dfsg-8 The GNU Bourne Again SHell ii grep-dctrl2.9.3 Grep Debian package information - ii patch 2.5.9-4Apply a diff file to an original kernel-patch-openvz recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGN1NtnWrlKaIH40ARAitCAJ9Y6D5PaVf8xx0rXLoo8JygPMKMRQCfcuND UQGvgQTDiXwvFHZn4GBV6vs= =OOD2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#417621: Workaround (netpbm: pnmtops produces dark images for maxval < 255)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There is a fairly obvious workaround: Use pnmdepth 255 | pnmtops ... Regards, and thank you for providing fine software, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGE5AynWrlKaIH40ARAoitAJsFZLqDlAiaER8MjjLvR+LRWZkPRgCfaIaa Psiot/yOs9DrobN/MB/X2r8= =qYST -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#417621: netpbm: pnmtops produces dark images for maxval < 255
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Package: netpbm
Version: 2:10.0-11
Severity: normal
I had problems with pnmtops producing very dark images.
I found out that this problem happens if the maxval in a ppm file
is lower than 255.
E.g., this is a little perl script that produces a completely
white page:
#!/usr/bin/perl -w
print "P6 1217 1737 60\n";
# Decimal 60 is ASCII "<"
for (1 .. 1217) {
for (1 .. 1737) {
print "<<<";
}
}
Save those few lines to a script mkwhite.
Then run the following commands:
chmod a+x mkwhite
./mkwhite.pl | tee white.ppm | pnmtops -dpi 150 -equalpixel > white.ps
The file white.ppm is indeed pure white (I checked with eog).
In contrast, the file white.ps is quite dark - demonstrating
the bug in pnmtops.
Regards, and thank you for providing fine software,
Andreas
- -- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-vserver-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)
Versions of packages netpbm depends on:
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libjpeg62 6b-13 The Independent JPEG Group's JPEG
ii libnetpbm10 2:10.0-11 Shared libraries for netpbm
ii libpng12-01.2.15~beta5-1 PNG library - runtime
ii libtiff4 3.8.2-7Tag Image File Format (TIFF) libra
ii zlib1g1:1.2.3-13 compression library - runtime
Versions of packages netpbm recommends:
ii gs 8.54.dfsg.1-5 Transitional package
ii gs-esp [gs] 8.15.3.dfsg.1-1 The Ghostscript PostScript interpr
- -- no debconf information
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGErP4nWrlKaIH40ARAnD1AKCxJ6tFVkNcPCgLwYnel6we0SFl6wCgqtM3
f+liVGKmTLqeFgOdARh1QOY=
=Fuy3
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409601: vzctl: Man page "vz(5)" announced in man page "vzctl" is missing.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: vzctl Version: 3.0.11-13 Severity: minor Hello, the manual page of vzctl announces: SEE ALSO vz(5), vps.conf(5), vzquota(8), (by the way - there is a "," too many at the end of that list). But neither "man vz" nor "man 5 vz" finds any such manual page. Regards, and thank you for providing fine software, Andreas - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFxa8qnWrlKaIH40ARArHjAJ9Os8SSbJ8LuIyc/poPR4eCTRkhowCeKe9t WJD9bwEnftjf76AF3anGwpw= =vMls -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409599: vzctl create: --root ignored, uses /var/lib/vz/private/NNN instead.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: vzctl Version: 3.0.11-13 Severity: normal Hello, I try to get a virtual server going using openvz. I have an empty file system /flish. That's where I want the virtual server's root to live. So I did kauz:~# vzctl --verbose create 101 --ostemplate gentoo-20060317-i686-stage3 \ -- root /flish/'$VEID' --ipadd 192.168.42.101 --hostname flish Unable to open /usr/lib/vzctl/modules/: No such file or directory Creating VPS private area: /var/lib/vz/private/101 Running: /usr/sbin/vzquota stat 101 -f Running: /usr/sbin/vzquota drop 101 Running: /usr/sbin/vzquota init 101 -b 1048576 -B 1153434 -i 20 -I 22 -p /var/lib/vz/private/101.tmp -e 0 -n 0 -s 0 Running: /usr/sbin/vzquota on 101 -r 0 -b 1048576 -B 1153434 -i 20 -I 22 - -e 0 -n 0 -s 0 Running: /usr/lib/vzctl/scripts/vps-create Running: /usr/sbin/vzquota off 101 Running: vzquota setlimit 101 -p /var/lib/vz/private/101 -b 1048576 -B 1153434 - -i 20 -I 22 -e 0 -n 0 Mounting root: /flish/101 /var/lib/vz/private/101 Performing postcreate actions Running: /etc/vz/dists/scripts/postcreate.sh Running: /usr/sbin/vzquota stat 101 -f VPS private area was created After that, I find the virtual server's entire file system below /var/lib/vz/private/101 . The directory /flish/101 is created, but remains empty. When I vzstart, it does access the root file system below /var/lib/vz/private/101 . Regards, and thank you for providing fine sofware, Andreas - -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-openvz-k7 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages vzctl depends on: ii iproute 20061002-3 Professional tools to control the ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii vzquota 3.0.8-2 server virtualization solution - q Versions of packages vzctl recommends: ii rsync 2.6.9-2fast remote file copy program (lik - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFxa4HnWrlKaIH40ARApHuAJ9NGairQ5z26lzhNT6UvvA+BxhM4ACgpzJy K9cYATp/HCaKIXV/3Qs3Tns= =gRZa -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397505: Some NVidia hardware currently supported by 8776 specifically needs 96xx, not 97xx.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We would very much like to see a 96xx NVidia driver appear in Debian (experimental or unstable or (later) etch-backports or whereever). The 97xx currently in experimental does not work for our hardware. The 8776 does, and previous drivers have done so. The details: By and large, this is an Etch system, with very little unstable stuff thrown in. The Etch Nvidia driver works well for us, with the exception that it does not support compiz (for all we know). We wanted to have a look at that eye candy. This afternoon, we grabbed nvidia-glx_1.0.9746-2_i386.deb from experimental and installed that. The installation process from nvidia-kernel-2.6.18-3-k7, 1.0.8776+5 to nvidia-kernel-source_1.0.9746-2_i386.deb went smoothly as documented. However, when trying to start X windows with our new driver, we ran into this problem: (II) NVIDIA dlloader X Driver 1.0-9746 Fri Dec 15 09:56:41 PST 2006 (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs (II) Primary Device is: PCI 01:00:0 (WW) NVIDIA(0): The NVIDIA GeForce4 MX 4000 GPU installed in this system is (WW) NVIDIA(0): supported through the NVIDIA 1.0-96xx Legacy drivers. (WW) NVIDIA(0): Please visit http://www.nvidia.com/object/unix.html for (WW) NVIDIA(0): more information. The 1.0-9746 NVIDIA driver will ignore (WW) NVIDIA(0): this GPU. Continuing probe... (EE) No devices detected. Fatal server error: no screens found Here is the card we have: # lspci | grep -i nvidia 01:00.0 VGA compatible controller: nVidia Corporation NV18 \ [GeForce4 MX 4000 AGP 8x] (rev c1) Regards, and thank you for providing fine software, Andreas - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFs6+InWrlKaIH40ARAjk/AKCB/7Lha2zVgPYdw3jYgDjlbuDA5gCgqNfp IYKvzIMytIzlGUk7XyEk1wo= =QaNY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#198386: xserver-xfree86: [vesa] driver slows down system clock on S3 Inc. 86c775/86c785 [Trio 64V2/DX or /GX]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Did you reproduce this problem recently? That hardware has not been in active service for some years now. So, to answer your question: No. > If not, I will close this bug in the next weeks. Please do. Thank you for the considerate treatment of this problem Andreas - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFsG56nWrlKaIH40ARAlUfAJ0RnZ1HJhNu7f5at8hy0vSsLV9zsgCeNTEl nmCz4/tjpldFMyc4GN8CQ3I= =ReTD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#391175: mozilla-thunderbird: line-wrapping limit changeable on the fly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: mozilla-thunderbird Version: 1.0.2-2.sarge1.0.8b.2 Severity: wishlist Thunderbird mail composition has the very usefull feature of wrapping lines after, e.g., 75 characters. I suggest it should be possible to change the number of characters on the fly, after already having started to compose the message. For me, 75 characters is usually just what I want. A noteable exception being when I write Debian bug tracking messages, such as this. This message was composed mainly by a copy-and-paste operation of some text, that has been generated under control of the reportbug programm. If you scroll further down, you can see it has some lines describing this system and setup. Those lines have been wrapped in the paste process, but should not have been. As a workaround, I can save the message, change the wrapping for all messages, and reopen the message, and repeat the paste. Regards, and thank you for providing fine software Andreas Krüger - -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages mozilla-thunderbird depends on: ii bash 2.05b-26 The GNU Bourne Again SHell ii libatk1.0-01.10.1-2 The ATK accessibility toolkit ii libc6 2.3.2.ds1-22sarge4GNU C Library: Shared libraries an ii libfontconfig1 2.3.1-2 generic font configuration library ii libfreetype6 2.1.7-6 FreeType 2 font engine, shared lib ii libgcc11:4.0.0-12GCC support library ii libglib2.0-0 2.6.4-1 The GLib library of C routines ii libgtk2.0-02.6.4-3.1 The GTK+ graphical user interface ii libjpeg62 6b-10 The Independent JPEG Group's JPEG ii libpango1.0-0 1.8.1-1 Layout and rendering of internatio ii libpng12-0 1.2.8rel-1PNG library - runtime ii libstdc++5 1:3.3.5-13The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-14sarge1 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-14sarge1 X Window System miscellaneous exte ii libxft22.1.7-1 FreeType-based font drawing librar ii libxp6 4.3.0.dfsg.1-14sarge1 X Window System printing extension ii libxrender10.8.3-7 X Rendering Extension client libra ii libxt6 4.3.0.dfsg.1-14sarge1 X Toolkit Intrinsics ii xlibs 4.3.0.dfsg.1-14sarge1 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime - -- debconf information: * mozilla-thunderbird/browser: Debian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFJMWDnWrlKaIH40ARAt57AJ9MnK7rE9A27EV+L3Udt+8DrTZ5OACgtT+v 5j5ULzhkV1ZpbvbhwbZR9vs= =ctIF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#391172: gnomermind: Help does not open help file.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: gnomermind Version: 1.0.1-7 Severity: normal I open up gnomermind, click on "Hilfe" (German for "Help") and then on GnomerMind/Help. Expected behaviour: Help pops up. Actual behaviour: A window pops up, telling me »ghelp:///usr/share/gnome/help/gnomermind/C/index.html« ist kein gültiger Ort. retranslated from German to English: ghelp:///usr/share/gnome/help/gnomermind/C/index.html is not a valid place. Oddly enough, typing, into a terminal window, gnome-help ghelp:///usr/share/gnome/help/gnomermind/C/index.html does open the help file all right. Regards, and thank you for providing fine software Andreas Krüger - -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages gnomermind depends on: ii gdk-imlib1 1.9.14-16.2 imaging library for use with gtk ( ii libart21.4.2-19 The GNOME canvas widget - runtime ii libaudiofile0 0.2.6-6 Open-source version of SGI's audio ii libc6 2.3.2.ds1-22sarge4GNU C Library: Shared libraries an ii libdb3 3.2.9-22 Berkeley v3 Database Libraries [ru ii libesd-alsa0 [libe 0.2.35-2 Enlightened Sound Daemon (ALSA) - ii libgdk-pixbuf2 0.22.0-8.1The GdkPixBuf image library, gtk+ ii libglib1.2 1.2.10-9 The GLib library of C routines ii libgnome32 1.4.2-19 The GNOME libraries ii libgnomesupport0 1.4.2-19 The GNOME libraries (Support libra ii libgnomeui32 1.4.2-19 The GNOME libraries (User Interfac ii libgtk1.2 1.2.10-17 The GIMP Toolkit set of widgets fo ii libpopt0 1.7-5 lib for parsing cmdline parameters ii xlibs 4.3.0.dfsg.1-14sarge1 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFJL+2nWrlKaIH40ARAg9FAKCZB2x7ZE7AxjolMcP9OqIyBEwovwCgl1QC SWZkGCvfRcg3j0ab2Cx0xcU= =+KZJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382765: cloop-utils: extract_compressed_fs should become first class citizen of its man page [patch]
Package: cloop-utils Version: 2.04-1+eb.1-6 Severity: minor *** Please type your report below this line *** In my opinion, extract_compressed_fs is documented poorly in its manual page. I add a minmal patch that may serve as a start to remedy this situation. Regards, and thank you for providing fine software Andreas --- debian-original/create_compressed_fs.1.sgml 2006-08-06 19:05:25.0 +0200 +++ debian/create_compressed_fs.1.sgml 2006-08-13 10:28:17.0 +0200 @@ -29,6 +29,9 @@ create_compressed_fs compresses a filesystem image to a compressed image suitable for mounting with the cloop driver. +extract_compressed_fs uncompresses a filesystem image +created by create_compressed_fs. + @@ -45,6 +48,7 @@ EXAMPLES create_compressed_fs image.ext2 image.ext2.cloop +extract_compressed_fs image.ext2.cloop | cmp image.ext2 - mkcmd="mkisofs -J -r data" signature.asc Description: OpenPGP digital signature
Bug#382762: cloop-utils: "out of memory" as create_compressed_fs - produced big file contains "0 blocks of size 65536."
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: cloop-utils Version: 2.04-1+eb.1-5 Severity: normal *** Please type your report below this line *** I have this cloop - file. When I try to mount it, the kernel complains something about "out of memory". To see whether the kernel module has a problem or my file, I have tried to uncompress that cloop file manually. Here is what I did and what came out of it: $ extract_compressed_fs KNOPPIX 0 blocks of size 65536. Preamble: #!/bin/sh #V2.0 Format modprobe cloop file=$0 && mount -r -t iso9660 /dev/cloop $1 exit $? and that is all the output I get. Just a few lines of plain text, not the many megabyte of binary data expected. To compare, I tried the same uncompress on a cloop file from KNOPPIX_V5.0.1CD-2006-06-01-DE as available via Knopper.net - this time inserting protection from binary data and "head"ing the output: X$ extract_compressed_fs KNOPPIX | od -c | head -10 31120 blocks of size 65536. Preamble: #!/bin/sh #V2.0 Format modprobe cloop file=$0 && mount -r -t iso9660 /dev/cloop $1 exit $? Block 0 length 12773 => 65536 Block 1 length 29872 => 65536 000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 010 001 C D 0 0 1 001 \0 L I N U X 0100020 0100040 K N O P P I X _ 0100060 F S 0100100 \0 \0 \0 \0 \0 \0 \0 \0 0100120 370 1 017 \0 \0 017 1 370 \0 \0 \0 \0 \0 \0 \0 \0 0100140 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0100160 \0 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 001 001 \0 \0 001 So I conclude my problem isn't in the cloop kernel module, but in the cloop file itself. Finally, how did I construct that defect compressed file? I used mkisofs to construct an ISO-9960 image. This image is a 1.7 G file: $ ls -l knoppix-raw.iso - -rw-r--r-- 1 root root 1713979392 2006-08-12 14:31 knoppix-raw.iso - From that, I used the command: create_compressed_fs -v -L -1 -B 65536 -f tmpfile \ knoppix-raw.iso master/KNOPPIX/KNOPPIX That gave me a file of the expected size: $ ls -l master/KNOPPIX/KNOPPIX - -rw-r--r-- 1 root root 677200178 2006-08-12 15:53 master/KNOPPIX/KNOPPIX In passing, I noticed thet /fotos/tmpfile was created, but not really used. Both during the run (a two hour affair) and afterwards, its' length remained 0 byte. I remember that create_compressed_fs used a little more than 100 MB RAM. Regards, and thank you for providing fine software Andreas - -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-k7 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages cloop-utils depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-5 GCC support library ii libstdc++64.1.1-5The GNU Standard C++ Library v3 ii zlib1g1:1.2.3-13 compression library - runtime cloop-utils recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE3t6TnWrlKaIH40ARAk/PAKCLS4fMeEYPm4PsbQWzUUBQ1OeIRQCfXGu1 YJi1SNcVNft5NjBNuOBEHS4= =g6VN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382611: cloop-utils: "One of: -s, -m, -f or -r required. Exiting..." in spite of "-m".
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: cloop-utils Version: 2.04-1+eb.1-5 Severity: normal *** Please type your report below this line *** I have issued the following command: create_compressed_fs -m -v -L -1 -B 65536 - - As a result, I get ERROR: Unknown input data size and no tempdata storage strategy has been choosen. One of: -s, -m, -f or -r required. Exiting... Clearly, I *have* issued "-m". So that message is less helpful than it could be. The manual page does not really tell me what is wrong about my option usage, either. (I understand that -m is no longer recommended, but the docs do not tell me that it has been outright disallowed.) Regards, and thank you for providing fine software Andreas - -- System Information: Debian Release: testing/unstable Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages cloop-utils depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-5 GCC support library ii libstdc++64.1.1-5The GNU Standard C++ Library v3 ii zlib1g1:1.2.3-13 compression library - runtime cloop-utils recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE3Y+CnWrlKaIH40ARAovMAJ94BehOjNNq8fPibfptP9BrxVcBfwCghBrn SxSNCl7FKpacNzSltl3hHDI= =SUkq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378344: closed by maximilian attems <[EMAIL PROTECTED]> (Re: Bug#378344: initramfs-tools: Should be able to force root device for update-initramfs)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 reopen 378344 thank you Hello, Maximilian, thanks for addressing my bug report. Your council does not help me all that much, though. I do not feel my concerns have been addressed. I try to repair this situation by answering some of your arguments, and also by explaining my concern more clearly. > the initramfs will just boot without any root bootarg, > beware that an root bootarg overides this hardcoding. > (initrd-tools compat + repair capability) So far, so good, yes. The problem I was experiencing: The initramfs will not be able to mount the desired LVM root unless LVM software is contained in that initramfs. And that software will not be contained in that initramfs, if the initramfs building-process had not understood that root is on LVM. And finally, there is no easy, well-documented way to force the initramfs building tools to use a particular root file system (and the software it deems neccessary to boot from it), or even a particular name for the current root file system (if that helps the building tools to discern where the file system lives). In particular, switching from non-LVM root to LVM root by simply providing arguments to the boot process through grub does *not* work. (Not that much compat+repair capability, really.) > once the bootloader points to the lvm2 root dev aka /dev/mapper/vgX-root > the box will happily boot from that, provided you have lvm2 installed > there. no need to regenerate the initrd. My experience is different. No happy boot. For me, it was not possible for /dev/mapper/vgX-root to even exist during the boot process, unless the initramfs itself already contains LVM software. At a minimum, vgchange needs to be present to activate vgX. But there is no easy way to force it to be there. That is the problem I'm trying to describe. Or if there is such an easy way, I have not found the documentation in the manual pages. > if there was previously _no_ lvm2 installed you need to update it > update-initramfs -u Again, my experience is different. When I newly install LVM2, my root at that point clearly is not under LVM2-control yet. In my experience, that fact is reason enough for "update-initramfs -u" to *not* copy LVM software to the initramfs. LVM software will not be picked up just because it is available, but only if the build scripts are convinced that the root file system actually lives on LVM. It becomes a chicken and egg problem. I cannot switch to a LVM2 root because I cannot boot into such a root, as long as the initramfs does not contain LVM2. And on the other hand, the initramfs will never pick up LVM2, unless I have already managed to boot into the LVM2 root. > this will go away soonest as lvm2 will get the hooks and regenerate > latest initramfs on install with relevant lvm2 boot scripts. Good news! But, for one, I would prefer my bug reports to be left open, util the bugs are actually fixed. And, secondly, I'm a bit sceptic. The regeneration process itself will still need to be changed from how it currently operates. Here is my concerned spelled out, I hope, more clearly: I consider the problem solved, if there is a documented way to move a system from an old setup, e.g., "root on /dev/hda5", to a new setup "root on some LVM". For a specific example, I may have bought and installed this shiny big new /dev/hdb, I may want to move my entire system to an LVM vg that lives on /dev/hdb, and then remove my old /dev/hda and give it to my daughter to play with. How do I do this? More general, I may want to play with any odd file system container that the initramfs-scripts support, and set up a dual boot for that purpose. This is not really a "root on LVM" issue, but a more general "move from root on A to root on B" issue. What is the general recipe? How do I do that? My suggested "I want this particular root" - option would solve all those problems, for LVM and any other file system containers the initramfs-generating scripts happen to support. "If you can mount it now, you can boot from it next time." Regards, and thank you for providing fine software and services, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEy7EVnWrlKaIH40ARAvYCAJ91ALJ/BS7BcuFa33vN+amDEHcf9gCghi46 +ITVPYPGdDCtdb8nGmETyJ8= =gtSx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#380384: cloop-utils: Error 21133 compressing block 10 with 7ZIP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: cloop-utils Version: 2.04-1+eb.1-1 Severity: normal *** Please type your report below this line *** Running create_compress_fs, I keep getting error messages such as "Error 21133 compressing block 10 with 7ZIP". The actual number (here: 21133) tends to vary a bit, though it is typically in the 2s. I have tried various things to evade this error, with no result. What I currently do is: mkisofs -R -U -V "Krueger-KNOPPIX" -publisher "[EMAIL PROTECTED]" \ -hide-rr-moved -cache-inodes -no-bak -pad source/KNOPPIX | buffer -m 1024k | create_compressed_fs -v -L -2 -m -t 1 -B 65536 - - > master/KNOPPIX/KNOPPIX This command will typically run for a very long time. The mkisofs - output tells me it is through with about 40% of the image or so. Then the error. Further background: I try to produce a slightly modified KNOPPIX_V5.0.1CD-2006-06-01-DE. The cloop-utils that fail me are those from my main Debian installation, not from that Knoppix version. That Debian installation is mostly "etch" with a bit of "unstable". E.g., one of the several things I have tried was, to upgrade to the very latest "unstable" cloop-utils and zlib1g. That did not help, either. Regards, and thank you for providing fine software Andreas - -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-k7 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages cloop-utils depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-5 GCC support library ii libstdc++64.1.1-5The GNU Standard C++ Library v3 ii zlib1g1:1.2.3-13 compression library - runtime cloop-utils recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEy6LOnWrlKaIH40ARAuEhAJ0ZB7iw6DdOcaur+Z2kNcm2fX9bhQCZARwQ UjIuNxv3ERs/iHM37qDasSc= =vvrE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378344: initramfs-tools: Should be able to force root device for update-initramfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: initramfs-tools Version: 0.68b Severity: wishlist Grub and lilo allow one to set kernel options to force a particular boot device, and for good reasons. Unfortunately, update-initramfs does not sport such a possibility. E.g., let us assume I bought a new hard disk drive and want to port an existing /dev/hd?? - System to LVM. It is easy enough to copy the whole thing to a new filesystem, that lives on LVM on the new drive. But: How do I come up with that initrd, that boots from LVM on the new disk? It can be done. One needs to dig down into the internals of mkinitramfs (disregarding the warning in the manual page that this is not needed for a local box). I suggest that this particular thing should be easier. It should be possible to force a particular boot device via two ways: A "root=" line in /etc/initramfs-tools/initramfs.conf, and a "-r" option to update-initramfs (that ought to override the "root=" line). In passing, either of these would have also helped me working around bug 378332 more elegantly, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378332 . Regards, and thank you for providing fine software, Andreas - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEuPFPnWrlKaIH40ARAjkUAJ9MqvP9fatBdaMZrVevnmyUcGswiQCcD/h+ nUPVCIlLy8+LRLH3vNeBVyY= =v2cX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378332: initramfs-tools: Symlink /dev/volgroup/root not recognized as lvm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Package: initramfs-tools
Version: 0.68b
Severity: normal
*** Please type your report below this line ***
My current setup: Root on LVM2, Kernel 2.6.12. I remember I had to
arm-twist the initrd-generation to get it going, way back.
The root fs is on LVM2:
[EMAIL PROTECTED]:/tmp$ LANG=C df /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/e2vg/root15482320 10793140 3902748 74% /
The twist in this setup: This root block device is a symbolic link:
[EMAIL PROTECTED]:/tmp$ ssh [EMAIL PROTECTED] LANG=C ls -l /dev/e2vg/root
lrwxrwxrwx 1 root root 21 Jul 15 11:35 /dev/e2vg/root -> /dev/mapper/e2vg-root
Today, I was trying to upgrade to kernel 2.6.16. The update itself went
smoothly enought, but I could not boot into the new kernel with the ram
disk that had been produced automatically. Appearently, the ram disk
generation scripts did not find out that /dev/e2vg/root lives on LVM2.
Here is the long story:
Looking at the ramdisk contents with
gunzip < /boot/initrd.img-2.6.16-2-k7 | cpio -ivt
I saw that not a whole lot of LVM things were included.
I tried this and that. In the end, I hacked update-initramfs itself,
adding "-r /dev/mapper/e2vg-root" to the mkinitramfs - call:
kauz:/usr/sbin# diff -u update-initramfs-ori update-initramfs
- --- update-initramfs-ori2006-07-15 11:54:55.0 +0200
+++ update-initramfs2006-07-15 11:58:37.0 +0200
@@ -67,7 +67,7 @@
if [ "${verbose}" = 1 ]; then
OPTS="-v $OPTS"
fi
- - if mkinitramfs $OPTS "${initramfs}" "${version}"; then
+ if mkinitramfs -r /dev/mapper/e2vg-root $OPTS "${initramfs}"
"${version}"; then
set_sha1
else
mkinitramfs_return="$?"
That produced a rd that did contain more of the LVM stuff.
I then changed the new kernel line in /boot/grub/menu.lst
from root=/dev/e2vg/root to root=/dev/mapper/e2vg-root
kernel /vmlinuz-2.6.16-2-k7 root=/dev/mapper/e2vg-root apm=off
Now, it all worked.
Regards, and thank you for providing fine software,
Andreas Krüger
- -- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-k7
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
(charmap=ISO-8859-15)
Versions of packages initramfs-tools depends on:
ii busybox 1:1.01-4 Tiny utilities for small and embed
ii cpio 2.6-12 GNU cpio -- a program to manage ar
ii klibc-utils 1.3.35-1 small statically-linked utilities
ii module-init-tools 3.2.2-3tools for managing Linux kernel mo
ii udev 0.091-2/dev/ and hotplug management daemo
initramfs-tools recommends no packages.
- -- no debconf information
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEuNa6nWrlKaIH40ARAqRbAJ48XXevdYuyshrsVjJpql6x/D7+bQCdHV+w
xHM8KQrb3Uc1pbZRO2tNOks=
=3nc1
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348641: redir: Options to keep idle connection open with no-data packets.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: redir Version: 2.1-2.1 Severity: wishlist I am frequently using ssh with "-L" or "-R" for port forwarding. The general setup here includes NAT routers. I have seen problems with connection stability. Apparently, when no data was transmitted for some time, the NAT router would forget about the connection, essentially killing it. I now regularly use ssh options such as - -o ServerAliveInterval=20 -o ServerAliveCountMax=7 Those helped me out. They cause ssh to regularly transmit "no data" packets when the connection would otherwise be idle. In this way, the NAT state of the connection is kept alive. I have now set up a connection for my users using redir. There are reports about connection instabilities. The situation is not easy to debug, but we may be running into the same kind of problem that I have seen with ssh. I suggest that redir is augmented with options similar to the ssh ones. I understand that it is more difficult for redir to implement this feature than it was for ssh, as there is a ssh protocol, while redir is forced to speak plain TCP/IP. But I remember that it is possible, at the TCP/IP level, to send packets that contain no data, but ask the receiver to acknowledge the pacpacket. If that recollection is correct, implementing the feature should be possible. I would like the proposed options to differentiate: It should be possible to keep the client connection open, the server connection, or both. So two options. Each option gives the number of seconds of idleness after which a no-data packet is sent. As is true in the ssh case, after some number of packets have not been ack'ed, both parts of the redired connection should shut down. Those numbers should be configurable, again separately for client and server. So two more options, four in all. Regards, and thank you for providing fine software Andreas Krüger - -- Dr. Andreas Krüger, [EMAIL PROTECTED] GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO Nordwest GmbH, Tel.: +49 211 577 996-0, Fax: +49 211 559 1617 Leostraße 31, 40545 Düsseldorf, Germany - -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages redir depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libwrap07.6.dbs-8Wietse Venema's TCP wrappers libra - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDzfgT6hmq3P1EXrcRAmtTAJ9+NNYd3762YHk43K6A4KdoY9mcPwCfV8PJ A6bPRgpY/860hQ7XVRT1Itk= =ITyV -END PGP SIGNATURE-
Bug#343922: apt-cache: manual cleanup of cache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is almost a month after the configuration change to cleanup_freq = 1d max_age = 40d In the meantime, I had updated all machines that live from this cache. And I have seen quite a bit of trouble, as the /var file system is full to the brim. In the days of trouble, "apt-get cleanup" was my friend. This morning, I finally ran find /var/cache/apt-proxy -type f -name \*.deb -atime +40 -print0 | xargs -0 -r rm That did free up some 4 GB of data. In other words, the configuration change has still not taken effect, not even a month after the inital change. And I had the computer switched on for some time almost every day since then. Finally, /var will start to function again. However, I do not know whether this has now utterly confused my apt-cache setup. Will it just work, or will my bold "solution" earn me apt-proxy problems? A first test has been hopeful. As far as I can see, apt-cache still works. Regards, and thank you for providing fine software Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDxMYCnWrlKaIH40ARAu/gAKCiHKUTDd5FNX4OJn4GTAb3JrPCSACgkB1Y tF7uQcxtjxcPMOyf3J0Kcsk= =FAWr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343922: apt-proxy: cleanup_freq and max_age configuration options not honored by restart.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: apt-proxy Version: 1.9.29 Severity: normal This is one of three computers in my family's little LAN. All are switched on for only a few hours a day, as neccessity demands. I am running apt-proxy on this particular machine. This saves quite a bit of (both Debian and my) bandwidth, and (my) time. Good stuff. I only need to have it switched on and running when I do apt-things on any of the other machines, that depend on the cache. Today, I was running out of disk space on /var. With "df" and "du | sort -n", I quickly found out that /var/cache/apt-proxy is much larger than I would like it to be. A solution for bug #198859 would help... As a workaround, I set, in /etc/apt/apt-proxy-v2.conf: cleanup_freq = 1d max_age = 40d Both numbers had been considerably higher previously. I issued /etc/init.d/apt-proxy stop and /etc/init.d/apt-proxy start, to make the two changes valid immediately. I don't think I had a cache cleanup yesterday. So I expected quite some disk activity, and presumed the disk space consumed by the apt-proxy cache would come down considerably. But neither of the two happened. At this point, I'm still running with a close to overflowing /var file system. Regards, and thank you for providing fine software Andreas Krüger - -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages apt-proxy depends on: ii bzip2 1.0.2-7 high-quality block-sorting file co ii debconf1.4.30.13 Debian configuration management sy ii logrotate 3.7-5 Log rotation utility ii python 2.3.5-2 An interactive high-level object-o ii python-apt 0.5.10Python interface to libapt-pkg ii python-bsddb3 3.3.0-6 Python interface to libdb3 ii python-twisted 1.3.0-8 Event-based framework for internet ii python2.3 2.3.5-3sarge1 An interactive high-level object-o - -- debconf information: * apt-proxy/upgrading-v2: * apt-proxy/upgrading-v2-result: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDpbhpnWrlKaIH40ARAqVaAKCPB/z+4HJpxxN6Qp6nA1049QED+gCfcM91 8zq4tjoYY817ltzKa7j5pfg= =qL4/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341935: gpart: "ioctl(HDIO_GETGEO) failed:" Could be more helpful.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: gpart Version: 0.1h-4 Severity: minor I tried to use gpart for a quick check whether it could recover the broken partition table from a (relatively unimportant) USB stick image. I was greeted with the error message > *** Fatal error: ioctl(HDIO_GETGEO) failed: Invalid argument. I admit this is sufficient for the initiated. However, it will lead the uninitiated towards using the device itself, instead of the image. At least that is what I did, being in the hurry I was. That got rid of the message all right - allthough I feel using the device instead of the copy is somehow the "wrong way". Also, the "device itself" is rather slow in my paticular case. In my view, an addition to the error message would be helpful. I suggest something like the following: > *** Fatal error: ioctl(HDIO_GETGEO) failed: Invalid argument. > Disc geometry information could not be read. > (Maybe you want to try either the -C or the -g option.) Regards, and thank you for providing fine software Andreas - -- [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 - -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages gpart depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDksFZnWrlKaIH40ARApT4AKCJkQEwMw8QfPj+k5AGOZfMgZfuRwCgg7pt 5tagQzqxWW8RaNDBSTcm1jM= =2mI2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312923: How I un-wedged aptitude.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I would have filed 312923 if it hadn't already existed. Here, for what it's worth, my story and how I was able to fix my problem. The story: I (root) got myself into quite some problem today with aptitude. One upgrade somewhere in the general vicinity of KDE 3.4 lead to many package removals because of missing dependencies in the general vicinity of KDE 3.3. Closed it all down and went for lunch. Came back, fired up aptitude again and was now looking for a way out. In the meantime, I had decided to be happy with KDE 3.3 for the time being. How do I cancel all the changes I had previously entered? Ctrl+u did not work. "f" got me only so far - but still aptitude thought I wanted to remove many packages from my system. The fix: In the end, I closed down aptitude and found a file /var/lib/aptitude/pkgstates. The next thing I would have tried was, purge and reinstall aptitude with apt-get, so what could I loose? I deleted that file. - And, yes, that did solve my problem. Regards, and thank you for providing fine software Andreas [EMAIL PROTECTED] PGP-Schlüssel 0xA207E340 (http://www.pca.dfn.de/dfnpca/pgpkserv/) Fingerprint B46B C7BA FFEE AD41 35DD 49C3 9D6A E529 A207 E340 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDZQsgnWrlKaIH40ARAvuWAKCqcn0YsdjxITYxi6+xJd91gmQvcwCbBTq7 XxNqo+gn+DORmfaDEKypmVI= =Jffr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324547: gphoto2 -P has a memory leak. [sarge]
Package: gphoto2 Version: 2.1.5-1 Severity: normal The story: A fairly old computer, with Pentium III CPU and a mere 128 MB of RAM. Debian Sarge for software. Before the recent summer vacation, I bought a new 512 MB CF card for my Cannon Power Shot A75. My two children take pictures, too, so this was a smart move. Coming back, that card is full to the brim. I fire up "gphoto2 -P" in a terminal window. This will take a while. So I start composing an email message in parallel. After some time, the email programm becomes very slow and unresponsive. There is also an increasing amount of hard disk activity. Finally, the "gphoto2" - process aborts, complaining about some USB communication problem with the camera. I think little about it. As I'm in no particular hurry, I delete all pictures that have already been downloaded, and fire "gphoto2" up again. Same story, at about the same picture (though not quite the identical one, I seem to recall). Now I start to pay attention. Who is causing all that hard disk activity? On the third attempt, a "top" quickly reveals: The "gphoto2" - process by and by eats up all available real and swap memory. When monitoring its memory vs. the progress it makes, it looks like it stores all pictures in RAM and never releases them. It seems, when the computer has become slow enough, for all the lack of memory, gphoto2 finally crashes. In this computer's setup, I roughly follow the old rule "swap space = twice real RAM". So together, real + swap are considerably less than the 512 MB of the CF card. Which is appearently what gphoto2 eats. Fortunately, I still have a few G of hard disk space in reserve. So, as a quick workaround, I temporarily opened up some more swap. As root: dd if=/dev/zero of=emergencyswap bs=1024k count=500 mkswap emergencyswap swapon emergencyswap That helped. I went to eat supper instead of watching the progress and memory consumption of gphoto2, but this time it goes through successfully. In my opinion, ghoto2 should release from memory the pictures after writing them to disk. Regards, and thank you for providing fine software, Andreas -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages gphoto2 depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libcdk4 4.9.9-4 C-based curses widget library ii libexif10 0.6.9-6 library to parse EXIF files ii libgphoto2-22.1.5-6 gphoto2 digital camera library ii libgphoto2-port02.1.5-6 gphoto2 digital camera port librar ii libjpeg62 6b-10The Independent JPEG Group's JPEG ii libncurses5 5.4-4Shared libraries for terminal hand ii libpopt01.7-5lib for parsing cmdline parameters ii libreadline44.3-11 GNU readline and history libraries -- no debconf information signature.asc Description: OpenPGP digital signature
