Bug#945828: background info
i spent the last 4 days searching because of this bug.
originally i started to write a bug report against libgdk-pixbuf2.0-0
but further investigations revealed the ugly root cause.
it was very hard to "google" this. maybe adding some pointers and
related keywords here will help upcoming victims...
as enrico reported, update-mime-database will not check readdir() for
error-return. instead it will silently create an emtpy mime cache.
this will cause e.g. all gdk pixbuf users to get an error message like
Couldn’t recognize the image file format for file XY
and that while
/usr/lib/ARCH/gdk-pixbuf-2.0/2.10.0/loaders.cache
is completely fine.
gdk pixbuf relies on glib's xdg_mime stuff which reads
/usr/share/mime/mime.cache
it might sound like an unimportant bug, to fix that error checking, but
it seems the only good way to notify people that there is something
wrong going on.
and i think it definitely is a bug within update-mime-database to
silently and happily create an empty mime cache while there always is at
least freedesktop.org.xml to be expected in /usr/share/mime/packages/
because it is installed with that package.
so i would suggest to at least output some warning message in case
/usr/share/mime/packages/ is discovered completely empty.
background:
running 32bit processes via qemu-user-static on a 64bit linux kernel
with a chroot will cause readdir() to error-out with
EOVERFLOW - Value too large for defined data type
for processes that are compiled without "-D_FILE_OFFSET_BITS=64" and for
directories on an ext4 filesystem.
this problem surfaced because of a change in glibc:
https://sourceware.org/bugzilla/show_bug.cgi?id=23960
qemu bug:
https://bugs.launchpad.net/qemu/+bug/1805913
linux kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=205957
lkml:
https://lkml.org/lkml/2018/12/27/155
i stumbled upon this when preparing an armhf buster rootfs via
multistrap (or debootstrap) and qemu-user-static on my x86_64 buster
host that uses an ext4 filesystem.
if update-mime-database would error-out because of that readdir() error
i would have seen that something is wrong and had something to search for.
with the current situation i had no indication at all and had to start
debugging gdk pixbuf, leading to glib, leading to an empty mime.cache
and further debugging of update-mime-database leading to the EOVERFLOW
error.
please add this error-out to save others from having to go through this!
a workaround that made readdir() work in that scenario was to compile it
with large-file support (-D_FILE_OFFSET_BITS=64) which can be achieved
by adding the macro
AC_SYS_LARGEFILE
to configure.ac.
attached a patch that does both.
--
Florian Schmidt
diff -Nurw shared-mime-info-1.10/configure.ac shared-mime-info-1.10-readdir-error-check/configure.ac
--- shared-mime-info-1.10/configure.ac 2018-06-28 10:02:17.0 +
+++ shared-mime-info-1.10-readdir-error-check/configure.ac 2020-03-03 20:49:32.0 +
@@ -13,6 +13,7 @@
dnl Checks for typedefs, structures, and compiler characteristics.
AC_C_CONST
+AC_SYS_LARGEFILE
IT_PROG_INTLTOOL([0.35.0])
diff -Nurw shared-mime-info-1.10/update-mime-database.c shared-mime-info-1.10-readdir-error-check/update-mime-database.c
--- shared-mime-info-1.10/update-mime-database.c 2018-04-24 13:09:19.0 +
+++ shared-mime-info-1.10-readdir-error-check/update-mime-database.c 2020-03-03 20:50:32.0 +
@@ -804,9 +804,12 @@
}
files = g_ptr_array_new();
- while ((ent = readdir(dir)))
+ while (TRUE)
{
int l;
+ errno = 0;
+ if(!(ent = readdir(dir)))
+ break;
l = strlen(ent->d_name);
if (l < 4 || strcmp(ent->d_name + l - 4, ".xml") != 0)
continue;
@@ -817,6 +820,11 @@
}
g_ptr_array_add(files, g_strdup(ent->d_name));
}
+ if (errno != 0)
+ {
+ g_printerr("readdir for %s returned errno %d: %s\n", path, errno, strerror(errno));
+ exit(EXIT_FAILURE);
+ }
closedir(dir);
g_ptr_array_sort(files, strcmp2);
Bug#927953: systemd: user and group files ignored in tmpfiles.d files
Hi mika, great, thanks for the info! Didn't think of checking the mailing list in addition to open bugs... Well, I guess such a quickly resolved bug report is great for statistics at least. Cheers, flosch On 4/25/19 1:37 PM, Michael Prokop wrote: * Florian Schmidt [Thu Apr 25, 2019 at 01:29:45PM +0200]: Package: systemd Version: 215-17+deb8u12 Severity: important it seems the recent security update led to systemd ignoring the user and group columns in tmpfiles.d files. This immediately leads to postgresql in the current oldstable version (postgresql-9.4 9.4.21-0+deb8u1, postgresql-common 165+deb8u3) breaking on reboot. [...] JFYI, this is already known and work in progress, see https://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/2019-April/038787.html regards -mika-
Bug#927953: systemd: user and group files ignored in tmpfiles.d files
Package: systemd Version: 215-17+deb8u12 Severity: important Dear Maintainer, it seems the recent security update led to systemd ignoring the user and group columns in tmpfiles.d files. This immediately leads to postgresql in the current oldstable version (postgresql-9.4 9.4.21-0+deb8u1, postgresql-common 165+deb8u3) breaking on reboot. This is /usr/lib/tmpfiles.d/postgrestql.conf from postgresql-common 165+deb8u3: # Directory for PostgreSQL sockets, lockfiles and stats tempfiles d /var/run/postgresql 2775 postgres postgres - - User and group postgres exist on the system. However, after reboot, /var/run/postgresql has root:root as owner: # stat /var/run/postgresql File: ‘/var/run/postgresql’ Size: 60 Blocks: 0 IO Block: 4096 directory Device: eh/14d Inode: 9690Links: 3 Access: (0775/drwxrwxr-x) Uid: (0/root) Gid: (0/root) Access: 2019-04-25 13:19:45.279148802 +0200 Modify: 2019-04-25 13:19:48.963148802 +0200 Change: 2019-04-25 13:19:48.963148802 +0200 Birth: - This means postgres can't write its lock file in that directory, and fails to start: # systemctl status postgresql@9.4-main.service -l ● postgresql@9.4-main.service - PostgreSQL Cluster 9.4-main Loaded: loaded (/lib/systemd/system/postgresql@.service; disabled) Active: failed (Result: exit-code) since Thu 2019-04-25 13:19:49 CEST; 15s ago Process: 352 ExecStart=postgresql@%i %i start (code=exited, status=1/FAILURE) Apr 25 13:19:49 [server] postgresql@9.4-main[352]: The PostgreSQL server failed to start. Please check the log output: Apr 25 13:19:49 [server] postgresql@9.4-main[352]: 2019-04-25 11:19:49 UTC [390-1] FATAL: could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock": Permission denied Apr 25 13:19:49 [server] systemd[1]: postgresql@9.4-main.service: control process exited, code=exited status=1 Apr 25 13:19:49 [server] systemd[1]: Failed to start PostgreSQL Cluster 9.4-main. Apr 25 13:19:49 [server] systemd[1]: Unit postgresql@9.4-main.service entered failed state. I wonder whether that has something to do with the following item in the change log: * CVE-2017-18078: tmpfiles: refuse to chown()/chmod() files which are hardlinked, unless protected_hardlinks sysctl is on. Though protected_hardlinks is on: # cat /proc/sys/fs/protected_hardlinks 1 And a directory can't be hardlinked anyway, so the relationship to that change log entry might be a red herring. -- Package-specific info: -- System Information: Debian Release: 8.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-8-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash 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+deb8u10 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+deb8u5 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b3 ii libpam0g1.1.8-3.1+deb8u2+b1 ii libselinux1 2.3-2 ii libsystemd0 215-17+deb8u12 ii mount 2.25.2-6 ii sysv-rc 2.88dsf-59 ii udev215-17+deb8u12 ii util-linux 2.25.2-6 Versions of packages systemd recommends: ii dbus1.8.22-0+deb8u1 pn libpam-systemd Versions of packages systemd suggests: pn systemd-ui -- Configuration Files: /etc/systemd/timesyncd.conf changed [not included] -- no debconf information
Bug#913138: linux: I/O on md RAID 6 hangs completely
i have the same problem here with one of my boxes. it happens with disk IO going via raid1 to one of my SATA ssd's (sda & sdb). disabling blk_mq solves this issue for me. i am using 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 but i had the same problems with 4.18. my raid setup: $ pvdisplay --- Physical volume --- PV Name /dev/sdb VG Name flo_data PV Size 465.76 GiB / not usable 4.02 MiB Allocatable yes PE Size 4.00 MiB Total PE 119234 Free PE 9153 Allocated PE 110081 PV UUID 7vbn06-H2vv-6O08-ndZa-Z1LF-xKN1-QcTBGh --- Physical volume --- PV Name /dev/sda VG Name flo_data PV Size 465.76 GiB / not usable 4.02 MiB Allocatable yes PE Size 4.00 MiB Total PE 119234 Free PE 9153 Allocated PE 110081 PV UUID xYIXB0-7SF6-KexY-Aw4S-31uL-7mAF-7sHTqj $ lvdisplay --- Logical volume --- LV Path/dev/flo_data/home LV Namehome VG Nameflo_data LV UUIDMf5mBg-Gj1c-Gclf-e3WG-mK2g-icRN-NO0SZg LV Write Accessread/write LV Creation host, time uter, 2018-05-24 19:57:17 +0200 LV Status available # open 2 LV Size430.00 GiB Current LE 110080 Mirrored volumes 2 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:4 i get "blocked for more than 120 seconds" kernel messages and all stacks seem to have in common: ... proc a: [ 5076.429209] schedule+0x28/0x80 [ 5076.429218] md_super_wait+0x6e/0xa0 [md_mod] [ 5076.429220] ? finish_wait+0x80/0x80 [ 5076.429229] md_bitmap_wait_writes+0x93/0xa0 [md_mod] [ 5076.429233] ? __wake_up_common_lock+0x89/0xc0 [ 5076.429242] md_bitmap_unplug+0xc7/0x110 [md_mod] [ 5076.429246] flush_bio_list+0x1c/0xd0 [raid1] [ 5076.429249] raid1_unplug+0xb9/0xd0 [raid1] [ 5076.429254] blk_flush_plug_list+0xcf/0x240 [ 5076.429257] blk_finish_plug+0x21/0x2e [ 5076.429286] ext4_writepages+0x68f/0xf00 [ext4] ... proc b: [ 5076.429429] schedule+0x28/0x80 [ 5076.429438] md_super_wait+0x6e/0xa0 [md_mod] [ 5076.429440] ? finish_wait+0x80/0x80 [ 5076.429449] md_bitmap_wait_writes+0x93/0xa0 [md_mod] [ 5076.429452] ? __wake_up_common_lock+0x89/0xc0 [ 5076.429461] md_bitmap_unplug+0xc7/0x110 [md_mod] [ 5076.429465] flush_bio_list+0x1c/0xd0 [raid1] [ 5076.429469] raid1_unplug+0xb9/0xd0 [raid1] [ 5076.429472] blk_flush_plug_list+0xcf/0x240 [ 5076.429475] blk_finish_plug+0x21/0x2e [ 5076.429497] ext4_writepages+0x68f/0xf00 [ext4] ... proc c: [ 5076.429633] schedule+0x28/0x80 [ 5076.429641] md_super_wait+0x6e/0xa0 [md_mod] [ 5076.429644] ? finish_wait+0x80/0x80 [ 5076.429652] md_bitmap_wait_writes+0x93/0xa0 [md_mod] [ 5076.429656] ? __wake_up_common_lock+0x89/0xc0 [ 5076.429665] md_bitmap_unplug+0xc7/0x110 [md_mod] [ 5076.429669] flush_bio_list+0x1c/0xd0 [raid1] [ 5076.429672] raid1_unplug+0xb9/0xd0 [raid1] [ 5076.429675] blk_flush_plug_list+0xcf/0x240 [ 5076.429678] blk_finish_plug+0x21/0x2e [ 5076.429701] ext4_writepages+0x68f/0xf00 [ext4] my journalctl -a output: Jan 09 19:27:48 uter kernel: Linux version 4.19.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.19.12-1 (2018-12-22) Jan 09 19:27:48 uter kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-1-amd64 root=/dev/sdc1 ro quiet Jan 09 19:27:48 uter kernel: x86/fpu: x87 FPU will use FXSAVE Jan 09 19:27:48 uter kernel: BIOS-provided physical RAM map: Jan 09 19:27:48 uter kernel: BIOS-e820: [mem 0x-0x0009e7ff] usable Jan 09 19:27:48 uter kernel: BIOS-e820: [mem 0x0009f800-0x0009] reserved Jan 09 19:27:48 uter kernel: BIOS-e820: [mem 0x000f-0x000f] reserved Jan 09 19:27:48 uter kernel: BIOS-e820: [mem 0x0010-0xcfed] usable Jan 09 19:27:48 uter kernel: BIOS-e820: [mem 0xcfee-0xcfee2fff] ACPI NVS Jan 09 19:27:48 uter kernel: BIOS-e820: [mem 0xcfee3000-0xcfee] ACPI data Jan 09 19:27:48 uter kernel: BIOS-e820: [mem 0xcfef-0xcfef] reserved Jan 09 19:27:48 uter kernel: BIOS-e820: [mem 0xf000-0xf3ff] reserved Jan 09 19:27:48 uter kernel: BIOS-e820: [mem 0xfec0-0x] reserved Jan 09 19:27:48 uter kernel: BIOS-e820: [mem 0x0001-0x00022fff] usable Jan 09 19:27:48 uter kernel: NX (Execute Disable) protection: active Jan 09 19:27:48 uter kernel: SMBIOS 2.4 present. Jan 09 19:27:48 uter kernel: DMI: Gigabyte Technology Co., Ltd. X38-DS4/X38-DS4, BIOS F1 11/23/2007 Jan 09 19:27:48 uter kernel: tsc: Fast TSC calibration using PIT Jan 09 19:27:48 uter
Bug#872057: (no subject)
This is due to a change in the behavior of tar's --no-recursion option.
In either 1.28 or 1.29, it was changed to only apply to all options
*following* it. Since the flexbackup command line has --files-from
before --no-recursion, the --no-recursion is effectively ignored. (See
also bug #829738)
Changing the order restores the correct behavior (see attached patch).
--- /usr/bin/flexbackup 2018-03-07 21:51:57.950379925 +0100
+++ /usr/bin/flexbackup 2018-03-07 21:52:17.418333887 +0100
@@ -1405,11 +1405,11 @@
$cmd .= "| ";
$cmd .= "$::path{tar} --create ";
+$cmd .= "--no-recursion ";
$cmd .= "--null ";
$cmd .= "--files-from=- ";
$cmd .= "--ignore-failed-read ";
$cmd .= "--same-permissions ";
-$cmd .= "--no-recursion ";
$cmd .= "--totals ";
if ($cfg::label ne 'false') {
if (length($title) > $::tar_max_label) {
Bug#884776: libc6: pthread_cond_broadcast() blocks indefinitely on process-shared cond-var
On Wed, Dec 27, 2017 at 09:22:50AM +0100, Aurelien Jarno wrote: > Debian should make sure this change doesn't break any software we ship > in the archive. today i've checked all 19217 reverse-depend-packages of libc6 in "testing" whether they use ROBUST-marked pthread-mutexes together with a pthread-condvar in their source. (the fact that they decided to use a ROBUST mutex could indicate that they expect lock-holders to die without cleanup and they might not be aware that the condvar is not ROBUST). of the ~14 hits only two of them could probably break due to the new condvar: package firebird3.0 (version 3.0.2.32703.ds4-12) this sql server makes use of the pshared mutex & condvar combination in their src/common/isc_sync.cpp which provides shm-based services for their LockManager, EventManager and MappingIpc classes. i don't know whether or not it is to be expected in their use-case that lock-holders might disappear or get killed (oom killer is always there looking for memory hungry server processes) (they provide different server models, among others also a multi-process model...) the only other thing i found is boost1.63-1.63.0+dfsg and boost1.62-1.62.0+dfsg. i tried to build the package and the only code-section that seems to be active (on amd64) and uses pshared condvars is: libs/log/src/posix/ipc_sync_wrappers.hpp: class boost::log::ipc::aux::interprocess_condition_variable now the next job would be to check whether any debian packages uses those classes expecting a robust condvar... maybe on another day...
Bug#884776: libc6: pthread_cond_broadcast() blocks indefinitely on process-shared cond-var
On Wed, Dec 20, 2017 at 10:25:33PM +0100, Aurelien Jarno wrote: > ... > I have also tested that the problem is still present in upstream git > HEAD. > > It looks to me the best is to take this issue upstream. Do you want me > to forward your bug report and your example in the upstream bugzilla [1] > or do you prefer to do it yourself? despite me doing an honest search for an already reported bug like this before, i did not find this one, but it seems to address the same problem: https://sourceware.org/bugzilla/show_bug.cgi?id=21422 it is marked as INVALID with the explanation that there are no "robust" variants of the pthread-condition variables. torvalds suggestion mentions catching signals, but as i exlpained this is not really an option for us (and does also not work if the waiter is killed by SIGKILL e.g. by the OOM killer...). the other suggestion is to use other non-blocking synchronization methods such as C11 atomics. and further down it was also suggested to directly use linux' futex operations. thats what i actually did in the last week: signal my "subscribers" via a FUTEX_WAKE and by using non-blocking atomic memory ops. it works and will probably yield much better real-time behaviour (not yet tested). still i had to implement it for our system and my guess is that it might break other in-production systems (because they erroneously rely on what is considered to be not-required behaviour). so maybe debian should at least make an explicit warning when installing glibc >= 2.25? -- Florian Schmidt DLR German Aerospace Center - Institute of Robotics and Mechatronics P.O.Box 1116, D-82230 Wessling
Bug#884776: other permutations...
i also tried to do the pthread_cond_broadcast() while the "publisher" holds the mutex -- same problem. also using pthread_cond_signal() shows the exact same behaviour. -- Florian Schmidt DLR German Aerospace Center - Institute of Robotics and Mechatronics P.O.Box 1116, D-82230 Wessling
Bug#884776: libc6: pthread_cond_broadcast() blocks indefinitely on process-shared cond-var
Package: libc6
Version: 2.25-3
Severity: important
Tags: upstream
TL;DR: pthread_cond_broadcast() on a process shared condition variable
will block indefinitely when another process that
pthread_cond_wait()'ed on this condition gets killed and restarted.
starting with libc6:armd64 version 2.25-3 from debian testing/buster, our
in-house robotics communication middleware (links_and_nodes) does no
longer behave as expected:
this middleware uses process shared mutex'es and condition variables
in shared memory (pthread_mutex_t, pthread_cond_t, shm_open) for
synchronization between processes.
attached is a simple self-contained test-case where a
"publisher"-process repeatedly increments a counter in shm (while
holding a pshared mutex) and then broadcasts the condition.
another process (lets call it "subscriber") is blocking waiting on
that same condition variable (with the same mutex).
this works as expected. until the subscriber is killed/terminated by
any signal while it is waiting.
when the subscriber is then started a 2nd time, the publisher gets
blocked in its call to pthread_cond_broadcast()!
with glibc <= 2.24 this caused no problems. i saw that there is a new
condvar impl in glibc 2.25 -- so this is probably something for
upstream.
with the attached test case i can reproduce this problem with debians
libc6 version 2.25-3 (buster), 2.25-5 (sid) and 2.26-0experimental2
(experimental).
on stable with 2.24-11+deb9u1 this problem does not occour!
attached is a Makefile, main.cpp and howto-reproduce.txt which should
be all thats needed to reproduce it (tested with gcc version 7.2.1
20171205 (Debian 7.2.0-17) and others...):
$ make
$ ./condvar-test publisher
in another terminal:
$ ./condvar-test subscriber
all works fine. now kill the subscriber via a signal, eg SIGINT with
Ctrl-C. publisher is still happy. now restart the subscriber:
$ ./condvar-test subscriber
this will cause the publisher to get blocked in
pthread_cond_broadcast()!
known workarounds: when the subscriber gets killed/terminated anywhere
outside of the critical section / not while blocked in _wait(), the
problem does not occour!
e.g. capturing the signal, and then doing a clean shutdown after
pthread_cond_wait() returned with EAGAIN.
this will be a major problem for us, because this synchronization is
provided by means of a shared library. and we can hardly control how
processes terminate. (and telling the average user how to do signal
handling is also not very convincing -- also letting the library catch
any/all signals to be able to return cleanly from _wait() is not a
good option...)
or is this usage of pthread_mutex,_cond considered to be bad/wrong? how?
still its an unexpected change in behaviour and i currently don't see
a clean way to solve this.
(i could also successfully reproduce this issue on different machines
with glibc >= 2.25, also with older 3.x and newer 4.9 kernels)
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.8.0-rt1+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages libc6 depends on:
ii libgcc1 1:7.2.0-17
libc6 recommends no packages.
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.65
pn glibc-doc
pn libc-l10n
pn locales
-- debconf information excluded
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define SHM_NAME "test_shm"
#define check_error_ret_null(func, ...) do {
\
int ret = func(__VA_ARGS__);
\
if(ret != 0) {
\
fprintf(stderr, "error calling " #func "(): %d %s!\n",
ret, strerror(ret)); \
return NULL;
\
}
\
} while(0)
unsigned int t = 10;
typedef struct {
pthread_mutex_t mutex;
pthread_cond_t cond;
unsigned int triggered;
} shm_t;
shm_t* mmap_fd(int fd) {
shm_t* ret = (shm_t*)mmap(NULL, sizeof(shm_t), PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_POPULATE | MAP_LOCKED, fd, 0);
close(fd);
if((void*)ret == MAP_FAILED) {
fprintf(stderr, "could not mmap: %d %s!\n", errno,
strerror(errno));
return NULL;
}
return ret;
}
shm_t* create_shm() {
int fd = shm_open(SHM_NAME, O_RDWR | O_CREAT, 0777);
if(fd == -1) {
fprintf(stderr, "could
Bug#478863: dfsbuild v1.0.2.0(amd64) does not pass '-a arch' to cdebootstrap
Package: dfsbuild Version: 1.0.2.0 Architecture: amd64 when i call dfsbuild with this command line: dfsbuild -V -a i386 -c usb1.cfg -w ./usb1 i get this output: [dfs/DEBUG] Command line parsed, results: [(V,),(a,i386),(c,usb1.cfg),(a,i386),(w,./usb1)] ... [dfs/DEBUG] Working dir is ./usb1 [dfs/DEBUG] Working dir created [dfs/DEBUG] Initial cwd is /home/flo/dfs [System.Cmd.Utils.pipeFrom/DEBUG] dpkg [--print-architecture] [dfs/INFO] Welcome to dfsbuild. Image architecture: i386 [dfs/DEBUG] dfsbuild is running as root. [dfs/INFO] Using working directory /home/flo/dfs/usb1 [dfs/INFO] Using library directory /usr/lib/dfsbuild [dfs/INFO] Running. [dfs/DEBUG] Processing at state Fresh [dfs/DEBUG] Processing at state Initialized [dfs/INFO] Mirroring process starting. [dfs/INFO] Running cdebootstrap for unstable [HSH.Command/DEBUG] S Before fork for (cdebootstrap,[--debug,-v,-d,unstable,/home/flo/dfs/usb1/target,http://localhost:3142/debian;]) dfsbuild correctly says 'Image architecture: i386' but calls cdebootstrap without the needed -a option! dfsbuild dependencies: ii cdebootstrap 0.5.1 Bootstrap a Debian system ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM File System) ii debconf 1.5.20Debian configuration management system ii grub 0.97-32 GRand Unified Bootloader (Legacy version) ii libc6 2.7-9 GNU C Library: Shared libraries ii libgmp3c2 2:4.2.2+dfsg-2Multiprecision arithmetic library ii mkisofs 9:1.1.7.1-1 Dummy transition package for genisoimage ii reprepro 3.4.1-1 Debian package repository producer ii ucf 3.005 Update Configuration File: preserve user changes to config -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457138: Default encoding always latin1 ?
hi Marek, you can set emma's default encoding in its own configuration file. in your $HOME/.emma/emmarc you can set db_encoding=utf-8 to switch your default encoding. emma is not designed to only access your local mysql server so your local mysqlD config ist not of interest. -- Florian Schmidt DLR German Aerospace Center - Institute of Robotics and Mechatronics P.O.Box 1116, D-82230 Wessling -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324529: Freeverb nonfunctional
Package: cmt Version: 1.15-2 It seems i experience the same as this person here (way too short response): http://music.columbia.edu/pipermail/linux-audio-user/2004-July/013472.html The thread seems to contain a fix, too: http://music.columbia.edu/pipermail/linux-audio-user/2004-July/013489.html Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321149: jackd not using /dev/shm as tmpdir
Package: jackd Version: 0.100.0-2 Hi, ~$ jackd --version jackd version 0.100.0 tmpdir /tmp protocol 15 ^^^ Fix: It should really be /tmp/shm. reconfigure and rebuild with the appropriate switch --with-default-tmpdir=/dev/shm i think. Having the fifos on a regular filesystem can be a source of xruns. a shmfs or tmpfs is much better suited. Regards, Florian Schmidt -- Palimm Palimm! http://affenbande.org/~tapas/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
