Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

[Szabolcs Nagy]

* Thorsten Glaser  [2024-04-05 05:04:37 +]:
> Markus Wichmann dixit:
> 
> >can check with readelf -r what the relocation types are. If they are not
> >relative, they will not be processed.
> 
> Gotcha! They are all R_390_RELATIVE except for:
> 
> 00045ff0  00110016 R_390_64  00042c58 u_ops + 70
> 00045ff8  00110016 R_390_64  00042c58 u_ops + 0
> 00047020  00110016 R_390_64  00042c58 u_ops + 80
> 00047088  00110016 R_390_64  00042c58 u_ops + 80
> 000470a8  00110016 R_390_64  00042c58 u_ops + b8
> 00047220  00110016 R_390_64  00042c58 u_ops + 80
> 00046900  00260016 R_390_64  00015af8 c_command + 0
> 00046940  00070016 R_390_64  00017238 c_exec + 0
> 00046ab0  00200016 R_390_64  00016a80 c_trap + 0
> 00047090  00250016 R_390_64  000430ac initvsn + 0
> 00047278  00550016 R_390_64  00047438 null_string + 2
> 
> That’s our missing strings.


this is not correct static pie.

glibc handles symbolic relocs, but there should not be
any non-local symbol in a static exe. you may want to
check the symbol table.

so s390 does not support static pie.
(arguably the elf is correct, if you expect a full
dynlinker in a static pie, but even then it's bad
quality linker output)

Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on s390x with static-pie

[Szabolcs Nagy]

* Szabolcs Nagy  [2024-04-04 12:44:28 +0200]:
> * Thorsten Glaser  [2024-04-03 23:57:11 +]:
> > retitle 1068350 musl: miscompiles (runtime problems) on riscv64 and s390x 
> > with static-pie
> > thanks
> 
> are you sure static pie works on these targets?
> 
> last time i checked binutils ld only supports it on a small number of targets.

i take that back, it seems both riscv and s390 fixed
https://sourceware.org/bugzilla/show_bug.cgi?id=22263

the next culprit is gcc (each target can have their own
static pie specs) or the way you invoked gcc (not visible
in the bugreport).

Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on s390x with static-pie

[Szabolcs Nagy]

* Thorsten Glaser  [2024-04-03 23:57:11 +]:
> retitle 1068350 musl: miscompiles (runtime problems) on riscv64 and s390x 
> with static-pie
> thanks

are you sure static pie works on these targets?

last time i checked binutils ld only supports it on a small number of targets.


> 
> Dixi quod…
> 
> >For some reason, mksh built with static-pie behaves bogus:
> 
> Exact same behaviour on the riscv64 buildd.
> 
> bye,
> //mirabilos
> -- 
> /⁀\ The UTF-8 Ribbon
> ╲ ╱ Campaign against
>  ╳  HTML eMail! Also,
> ╱ ╲ header encryption!

Bug#1022027: crypt symbols are missing from musl breaking its ABI

[Szabolcs Nagy]

Package: musl
Version: 1.2.3-1
X-Debbugs-CC: Helmut Grohne 

The crypt symbols are part of the musl libc ABI which enables binaries
to be portable between systems where musl is installed, but debian
removed these symbols (not just the headers).

nm -D /lib/ld-musl-x86_64.so.1 |grep crypt

should print crypt, crypt_r and decrypt symbols, but on debian the
result is empty.

attached a patch that should fix the issue.
diff --minimal -Nru musl-1.2.3/debian/changelog musl-1.2.3/debian/changelog
--- musl-1.2.3/debian/changelog 2022-04-07 22:48:37.0 +0200
+++ musl-1.2.3/debian/changelog 2022-10-17 17:49:14.0 +0200
@@ -1,3 +1,10 @@
+musl (1.2.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Restore crypt functionality in libc.{a,so} for ABI compatibility.
+
+ -- Helmut Grohne   Mon, 17 Oct 2022 17:49:14 +0200
+
 musl (1.2.3-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru musl-1.2.3/debian/clean musl-1.2.3/debian/clean
--- musl-1.2.3/debian/clean 2021-08-21 12:05:49.0 +0200
+++ musl-1.2.3/debian/clean 2022-10-17 17:49:14.0 +0200
@@ -1,7 +1,5 @@
 debian/musl-dev.postinst
 debian/musl-dev.postrm
 debian/scripts/*.path
-include/crypt.h
-src/crypt/
 include/fts.h
 src/fts/
diff --minimal -Nru musl-1.2.3/debian/rules musl-1.2.3/debian/rules
--- musl-1.2.3/debian/rules 2021-08-21 12:05:23.0 +0200
+++ musl-1.2.3/debian/rules 2022-10-17 17:49:14.0 +0200
@@ -73,7 +73,7 @@
dh_auto_configure -- --libdir=/usr/lib/$(MUSL_TRIPLE) 
--includedir=/usr/include/$(MUSL_TRIPLE) --host=$(DEB_HOST_GNU_TYPE) 
--enable-gcc-wrapper=$(GCC_WRAPPER) --enable-debug
 
 execute_after_dh_auto_install:
-   rm debian/tmp/usr/lib/$(MUSL_TRIPLE)/libcrypt.a
+   rm debian/tmp/usr/include/$(MUSL_TRIPLE)/crypt.h 
debian/tmp/usr/lib/$(MUSL_TRIPLE)/libcrypt.a
 
 execute_after_dh_install:
 ifeq ($(GCC_WRAPPER),yes)

Bug#915877: linux-perf-4.18 in Stretch bpo is not linked with libunwind

[Szabolcs Fazekas]

package: linux-perf-4.18
version: 4.18.6-1~bpo9+1

Package is not linked with libunwind, which makes perf report very slow
when dwarf graph is used.

How to reproduce:
$ sudo perf_4.18 record -F 200 -p 38429 --call-graph dwarf sleep 120
$ time sudo perf report -G --no-inline > /dev/null

real5m18.259s
user5m10.644s
sys0m7.527s

I managed to rebuild linux-perf-4.18 manually with libunwind. Using the
exact same set of samples, this is how it performs:
$ time sudo perf_4.18 report -G --no-inline > /dev/null

real0m0.846s
user0m0.654s
sys0m0.190s

I confirmed the followings:
 - linux-perf-4.9 is linked with libunwind and performs properly
 - linux-perf-* packages in sid/experimental are also linked with libunwind
 - linux-perf-* (>4.9) in Stretch backports are not linked with libunwind
and they perform poorly

I suggest to rebuild all linux-perf packages in Stretch backports with
libunwind linked.

-- 
Szabolcs Fazekas
Ahrefs

Bug#818246: libbsd does not build with musl libc

[Szabolcs Nagy]

Package: libbsd
Version: 0.8.2-1

After providing a minimal sys/cdefs.h libbsd builds
with the attached patch with musl libc (O_* open flags
need fcntl.h, funopen is not supported on musl).
diff -u -r libbsd-0.8.2/src/flopen.c ok/src/flopen.c
--- libbsd-0.8.2/src/flopen.c	2011-07-05 16:56:44.0 +
+++ ok/src/flopen.c	2016-03-15 00:08:41.430611577 +
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 int
 flopen(const char *path, int flags, ...)
diff -u -r libbsd-0.8.2/src/funopen.c ok/src/funopen.c
--- libbsd-0.8.2/src/funopen.c	2015-09-22 17:56:09.0 +
+++ ok/src/funopen.c	2016-03-15 00:28:02.500646182 +
@@ -138,5 +138,5 @@
 	return fopencookie(cookiewrap, mode, funcswrap);
 }
 #else
-#error "Function funopen() needs to be ported."
+//#error "Function funopen() needs to be ported."
 #endif
diff -u -r libbsd-0.8.2/src/nlist.c ok/src/nlist.c
--- libbsd-0.8.2/src/nlist.c	2015-09-23 05:59:34.0 +
+++ ok/src/nlist.c	2016-03-15 00:12:38.840618659 +
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if !defined(__NO_A_OUT_SUPPORT)
 #define _NLIST_DO_AOUT

Bug#813751: gpm patch for musl support

[Szabolcs Nagy]

Tags: patch

* Helmut Grohne <hel...@subdivi.de> [2016-02-11 18:21:59 +0100]:
> On Fri, Feb 05, 2016 at 12:43:53AM +0100, Szabolcs Nagy wrote:
> > +This makes gpm compile against musl libc.
> 
> I cannot reproduce this. Even after applying your patch, the build still
> fails:
> 
> prog/display-buttons.c:69:4: error: unknown type name 'fd_set'
> 
> Can you update the patch and add the patch tag again?
> 

fixed.
diff -u gpm-1.20.4/debian/changelog gpm-1.20.4/debian/changelog
--- gpm-1.20.4/debian/changelog
+++ gpm-1.20.4/debian/changelog
@@ -1,3 +1,14 @@
+gpm (1.20.4-6.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use SA_NODEFER instead of its non-standard alias SA_NOMASK.
+  * Add missing sys/select.h and fcntl.h includes.
+  * Use standard sigemptyset unconditionally.
+  * Define SA_INTERRUPT if it's not defined (historical no-op).
+  * With these changes gpm builds against musl libc.
+
+ --  <n...@port70.net>  Fri, 12 Feb 2016 00:47:02 +
+
 gpm (1.20.4-6.1) unstable; urgency=low
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- gpm-1.20.4.orig/src/lib/liblow.c
+++ gpm-1.20.4/src/lib/liblow.c
@@ -173,7 +173,7 @@
   /* Reincarnation. Prepare for another death early. */
   sigemptyset(_mask);
   sa.sa_handler = gpm_suspend_hook;
-  sa.sa_flags = SA_NOMASK;
+  sa.sa_flags = SA_NODEFER;
   sigaction (SIGTSTP, , 0);
 
   /* Pop the gpm stack by closing the useless connection */
@@ -350,7 +350,7 @@
 
  /* if signal was originally ignored, job control is not supported */
  if (gpm_saved_suspend_hook.sa_handler != SIG_IGN) {
-sa.sa_flags = SA_NOMASK;
+sa.sa_flags = SA_NODEFER;
 sa.sa_handler = gpm_suspend_hook;
 sigaction(SIGTSTP, , 0);
  }
only in patch2:
unchanged:
--- gpm-1.20.4.orig/src/prog/display-buttons.c
+++ gpm-1.20.4/src/prog/display-buttons.c
@@ -36,6 +36,7 @@
 #include /* printf() */
 #include  /* time()   */
 #include /* errno*/
+#include/* fd_set, FD_ZERO  */
 #include   /* gpm information  */
 
 /* display resulting data */
only in patch2:
unchanged:
--- gpm-1.20.4.orig/src/prog/display-coords.c
+++ gpm-1.20.4/src/prog/display-coords.c
@@ -37,6 +37,7 @@
 #include /* printf() */
 #include  /* time()   */
 #include /* errno*/
+#include/* fd_set, FD_ZERO  */
 #include   /* gpm information  */
 
 /* display resulting data */
only in patch2:
unchanged:
--- gpm-1.20.4.orig/src/prog/gpm-root.y
+++ gpm-1.20.4/src/prog/gpm-root.y
@@ -1197,11 +1197,10 @@
 LOG_DAEMON : LOG_USER);
/* reap your zombies */
childaction.sa_handler=reap_children;
-#if defined(__GLIBC__)
-   __sigemptyset(_mask);
-#else /* __GLIBC__ */
-   childaction.sa_mask=0;
-#endif /* __GLIBC__ */
+   sigemptyset(_mask);
+#ifndef SA_INTERRUPT
+#define SA_INTERRUPT 0
+#endif
childaction.sa_flags=SA_INTERRUPT; /* need to break the select() call */
sigaction(SIGCHLD,,NULL);
 
only in patch2:
unchanged:
--- gpm-1.20.4.orig/src/prog/open_console.c
+++ gpm-1.20.4/src/prog/open_console.c
@@ -22,6 +22,7 @@
 #include "headers/message.h"/* messaging in gpm */
 #include "headers/daemon.h" /* daemon internals */
 #include 
+#include 
 
 int open_console(const int mode)
 {

Bug#813751: gpm patch for musl support

[Szabolcs Nagy]

Source: gpm
Version: 1.20.4-6.1
Tags: patch

Fix non-portable SA_MASK usage for musl support.
diff -u gpm-1.20.4/debian/changelog gpm-1.20.4/debian/changelog
--- gpm-1.20.4/debian/changelog
+++ gpm-1.20.4/debian/changelog
@@ -1,3 +1,11 @@
+gpm (1.20.4-6.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use SA_NODEFER instead of the non-standard SA_NOMASK alias.
+This makes gpm compile against musl libc.
+
+ --    Thu, 04 Feb 2016 22:57:20 +
+
 gpm (1.20.4-6.1) unstable; urgency=low
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- gpm-1.20.4.orig/src/lib/liblow.c
+++ gpm-1.20.4/src/lib/liblow.c
@@ -173,7 +173,7 @@
   /* Reincarnation. Prepare for another death early. */
   sigemptyset(_mask);
   sa.sa_handler = gpm_suspend_hook;
-  sa.sa_flags = SA_NOMASK;
+  sa.sa_flags = SA_NODEFER;
   sigaction (SIGTSTP, , 0);
 
   /* Pop the gpm stack by closing the useless connection */
@@ -350,7 +350,7 @@
 
  /* if signal was originally ignored, job control is not supported */
  if (gpm_saved_suspend_hook.sa_handler != SIG_IGN) {
-sa.sa_flags = SA_NOMASK;
+sa.sa_flags = SA_NODEFER;
 sa.sa_handler = gpm_suspend_hook;
 sigaction(SIGTSTP, , 0);
  }

Bug#787780: hostname patch for musl support

[Szabolcs Nagy]

Source: hostname
Version: 3.15+nmu1
Tag: patch

This update fixes the man page.

* Michael Meskes <mes...@debian.org> [2015-09-01 12:42:13 +0200]:
> This patch removes usage of yp_get_default_domain, but still leaves it
> referenced in the manpage. So you should change that documentation, too.
> 

done.

> That being said there does not seem to be a need to keep the program names
> ypdomainname and nisdomainname if using your patch, other than backward
> compatibility that is. But then there does not seem to be a huge difference
> between these two and domainname anyway. :)
>  

i did not remove those programs, scripts may rely
on those names and they have slightly different
output.

if they are not needed that should be fixed in a
separate patch i think.
diff -Nru hostname-3.15/Makefile hostname-3.15+nmu1/Makefile
--- hostname-3.15/Makefile  2013-11-03 14:25:42.0 +
+++ hostname-3.15+nmu1/Makefile 2015-06-04 22:12:11.0 +
@@ -1,4 +1,4 @@
-CFLAGS+=-O2 -Wall
+CFLAGS+=-O2 -Wall -D_GNU_SOURCE
 
 # uncomment the following line if you want to install to a different base dir.
 #BASEDIR=/mnt/test
@@ -9,7 +9,7 @@
 OBJS=hostname.o
 
 hostname: $(OBJS)
-   $(CC) $(CFLAGS) -o $@ $(OBJS) $(LDFLAGS) -lnsl
+   $(CC) $(CFLAGS) -o $@ $(OBJS) $(LDFLAGS)
ln -fs hostname dnsdomainname
ln -fs hostname domainname
ln -fs hostname ypdomainname
diff -Nru hostname-3.15/debian/changelog hostname-3.15+nmu1/debian/changelog
--- hostname-3.15/debian/changelog  2013-11-03 14:41:12.0 +
+++ hostname-3.15+nmu1/debian/changelog 2015-06-04 22:44:17.0 +
@@ -1,3 +1,15 @@
+hostname (3.15+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fixes build on musl libc.
+  * Use _GNU_SOURCE feature test macro, instead of glibc internal __USE_GNU.
+  * Use getdomainname instead of yp_get_default_domain because it is more
+widely available and avoids the -lnsl dependency.
+  * localnisdomain is kept, even though it should be the same as localdomain,
+so the behaviour is not changed in case of an error.
+
+ -- Szabolcs Nagy <n...@port70.net>  Thu, 04 Jun 2015 22:13:09 +
+
 hostname (3.15) unstable; urgency=low
 
   * Applied patch to make it possible to install binaries and man pages into
diff -Nru hostname-3.15/hostname.1 hostname-3.15+nmu1/hostname.1
--- hostname-3.15/hostname.12013-11-03 14:24:23.0 +
+++ hostname-3.15+nmu1/hostname.1   2015-09-06 11:05:05.0 +
@@ -70,7 +70,7 @@
 and
 .BR nisdomainname
 use the
-.BR yp_get_default_domain (3).
+.BR getdomainname (2).
 .LP
 .B dnsdomainname
 will print the domain part of the FQDN (Fully Qualified Domain Name). The
diff -Nru hostname-3.15/hostname.c hostname-3.15+nmu1/hostname.c
--- hostname-3.15/hostname.c2013-11-03 14:26:51.0 +
+++ hostname-3.15+nmu1/hostname.c   2015-06-05 22:38:54.0 +
@@ -37,13 +37,11 @@
 #include 
 #include 
 #include 
-#define __USE_GNU 1
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 #define VERSION "3.15"
 
@@ -52,20 +50,19 @@
 char *progname;
 
 /*
- * Return the name of the nis default domain. This is just a wrapper for
- * yp_get_default_domain.  If something goes wrong, program exits.
+ * Return the name of the nis default domain. Same as localdomain below,
+ * but reports failure for unset domain.
  */
 char *
 localnisdomain()
 {
-   char *buf = 0;
+   /* The historical NIS limit is 1024, the limit on Linux is 64.  */
+   static char buf[1025];
int myerror = 0;
 
-   myerror = yp_get_default_domain();
-
-   /* yp_get_default_domain failed, abort. */
-   if (myerror) {
-   printf("%s: %s\n", progname, yperr_string(myerror));
+   myerror = getdomainname(buf, sizeof buf);
+   if (myerror || strcmp(buf, "(none)") == 0) {
+   printf("%s: Local domain name not set\n", progname);
exit (1);
}
 

Bug#787780: hostname patch for musl support

[Szabolcs Nagy]

Source: hostname
Version: 3.15+nmu1
Tag: patch

This update fixes strcmp check of (none).
diff -Nru hostname-3.15/Makefile hostname-3.15+nmu1/Makefile
--- hostname-3.15/Makefile  2013-11-03 14:25:42.0 +
+++ hostname-3.15+nmu1/Makefile 2015-06-04 22:12:11.0 +
@@ -1,4 +1,4 @@
-CFLAGS+=-O2 -Wall
+CFLAGS+=-O2 -Wall -D_GNU_SOURCE
 
 # uncomment the following line if you want to install to a different base dir.
 #BASEDIR=/mnt/test
@@ -9,7 +9,7 @@
 OBJS=hostname.o
 
 hostname: $(OBJS)
-   $(CC) $(CFLAGS) -o $@ $(OBJS) $(LDFLAGS) -lnsl
+   $(CC) $(CFLAGS) -o $@ $(OBJS) $(LDFLAGS)
ln -fs hostname dnsdomainname
ln -fs hostname domainname
ln -fs hostname ypdomainname
diff -Nru hostname-3.15/debian/changelog hostname-3.15+nmu1/debian/changelog
--- hostname-3.15/debian/changelog  2013-11-03 14:41:12.0 +
+++ hostname-3.15+nmu1/debian/changelog 2015-06-04 22:44:17.0 +
@@ -1,3 +1,15 @@
+hostname (3.15+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fixes build on musl libc.
+  * Use _GNU_SOURCE feature test macro, instead of glibc internal __USE_GNU.
+  * Use getdomainname instead of yp_get_default_domain because it is more
+widely available and avoids the -lnsl dependency.
+  * localnisdomain is kept, even though it should be the same as localdomain,
+so the behaviour is not changed in case of an error.
+
+ -- Szabolcs Nagy n...@port70.net  Thu, 04 Jun 2015 22:13:09 +
+
 hostname (3.15) unstable; urgency=low
 
   * Applied patch to make it possible to install binaries and man pages into
diff -Nru hostname-3.15/hostname.c hostname-3.15+nmu1/hostname.c
--- hostname-3.15/hostname.c2013-11-03 14:26:51.0 +
+++ hostname-3.15+nmu1/hostname.c   2015-06-05 22:38:54.0 +
@@ -37,13 +37,11 @@
 #include stdio.h
 #include unistd.h
 #include getopt.h
-#define __USE_GNU 1
 #include string.h
 #include netdb.h
 #include errno.h
 #include ctype.h
 #include err.h
-#include rpcsvc/ypclnt.h
 
 #define VERSION 3.15
 
@@ -52,20 +50,19 @@
 char *progname;
 
 /*
- * Return the name of the nis default domain. This is just a wrapper for
- * yp_get_default_domain.  If something goes wrong, program exits.
+ * Return the name of the nis default domain. Same as localdomain below,
+ * but reports failure for unset domain.
  */
 char *
 localnisdomain()
 {
-   char *buf = 0;
+   /* The historical NIS limit is 1024, the limit on Linux is 64.  */
+   static char buf[1025];
int myerror = 0;
 
-   myerror = yp_get_default_domain(buf);
-
-   /* yp_get_default_domain failed, abort. */
-   if (myerror) {
-   printf(%s: %s\n, progname, yperr_string(myerror));
+   myerror = getdomainname(buf, sizeof buf);
+   if (myerror || strcmp(buf, (none)) == 0) {
+   printf(%s: Local domain name not set\n, progname);
exit (1);
}
 

Bug#787780: hostname patch for musl support

[Szabolcs Nagy]

Source: hostname
Version: 3.15+nmu1
Tag: patch

The hostname tool depends on libnsl and associated headers
which prevents it from compiling on musl (and possibly on
other systems).  The observable behaviour of the tool should
not change with the attached patch on a glibc based system.
diff -Nru hostname-3.15/Makefile hostname-3.15+nmu1/Makefile
--- hostname-3.15/Makefile  2013-11-03 14:25:42.0 +
+++ hostname-3.15+nmu1/Makefile 2015-06-04 22:12:11.0 +
@@ -1,4 +1,4 @@
-CFLAGS+=-O2 -Wall
+CFLAGS+=-O2 -Wall -D_GNU_SOURCE
 
 # uncomment the following line if you want to install to a different base dir.
 #BASEDIR=/mnt/test
@@ -9,7 +9,7 @@
 OBJS=hostname.o
 
 hostname: $(OBJS)
-   $(CC) $(CFLAGS) -o $@ $(OBJS) $(LDFLAGS) -lnsl
+   $(CC) $(CFLAGS) -o $@ $(OBJS) $(LDFLAGS)
ln -fs hostname dnsdomainname
ln -fs hostname domainname
ln -fs hostname ypdomainname
diff -Nru hostname-3.15/debian/changelog hostname-3.15+nmu1/debian/changelog
--- hostname-3.15/debian/changelog  2013-11-03 14:41:12.0 +
+++ hostname-3.15+nmu1/debian/changelog 2015-06-04 22:44:17.0 +
@@ -1,3 +1,15 @@
+hostname (3.15+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fixes build on musl libc.
+  * Use _GNU_SOURCE feature test macro, instead of glibc internal __USE_GNU.
+  * Use getdomainname instead of yp_get_default_domain because it is more
+widely available and avoids the -lnsl dependency.
+  * localnisdomain is kept, even though it should be the same as localdomain,
+so the behaviour is not changed in case of an error.
+
+ -- Szabolcs Nagy n...@port70.net  Thu, 04 Jun 2015 22:13:09 +
+
 hostname (3.15) unstable; urgency=low
 
   * Applied patch to make it possible to install binaries and man pages into
diff -Nru hostname-3.15/hostname.c hostname-3.15+nmu1/hostname.c
--- hostname-3.15/hostname.c2013-11-03 14:26:51.0 +
+++ hostname-3.15+nmu1/hostname.c   2015-06-04 22:37:59.0 +
@@ -37,13 +37,11 @@
 #include stdio.h
 #include unistd.h
 #include getopt.h
-#define __USE_GNU 1
 #include string.h
 #include netdb.h
 #include errno.h
 #include ctype.h
 #include err.h
-#include rpcsvc/ypclnt.h
 
 #define VERSION 3.15
 
@@ -52,20 +50,19 @@
 char *progname;
 
 /*
- * Return the name of the nis default domain. This is just a wrapper for
- * yp_get_default_domain.  If something goes wrong, program exits.
+ * Return the name of the nis default domain. Same as localdomain below,
+ * but reports failure for unset domain.
  */
 char *
 localnisdomain()
 {
-   char *buf = 0;
+   /* The historical NIS limit is 1024, the limit on Linux is 64.  */
+   static char buf[1025];
int myerror = 0;
 
-   myerror = yp_get_default_domain(buf);
-
-   /* yp_get_default_domain failed, abort. */
-   if (myerror) {
-   printf(%s: %s\n, progname, yperr_string(myerror));
+   myerror = getdomainname(buf, sizeof buf);
+   if (myerror || strcmp(buf, (none))) {
+   printf(%s: Local domain name not set\n, progname);
exit (1);
}
 

Bug#786885: Broken gettext check in the build system of bison

[Szabolcs Nagy]

Package: bison
Version: 2:3.0.2.dfsg-2

When building bison on a musl libc based system, creating
the package fails because it incorrectly assumes that the
libc has no gettext support.

The bison configure.ac uses

 AM_GNU_GETTEXT([external], [need-ngettext])

which ends up checking for glibc internal symbols
_nl_msg_cat_cntr and _nl_domain_bindings instead of just
checking for the API in use (gettext and ngettext).

This issue is reported upstream at
http://lists.gnu.org/archive/html/bug-gettext/2015-04/msg2.html

More discussions at the musl-libc mailing list:
http://www.openwall.com/lists/musl/2015/04/16/3

This matters for rebootstrap cross compiled build of bison,
might affect other packages too.

To fix it, remove _nl_* checks from m4/gettext.m4.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782830: attr patch for musl support

[Szabolcs Nagy]

Source: attr
Version: 1:2.4.47-2
Tags: patch
diff -Nru attr-2.4.47/debian/changelog attr-2.4.47/debian/changelog
--- attr-2.4.47/debian/changelog	2014-09-08 07:27:25.0 +
+++ attr-2.4.47/debian/changelog	2015-04-25 18:31:11.0 +
@@ -1,3 +1,12 @@
+attr (1:2.4.47-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream patch to support musl libc
+http://git.savannah.gnu.org/cgit/attr.git/commit/?id=7921157890d07858d092f4003ca4c6bae9fd2c38
+  * xattr.h is not completely removed because some packages depend on it (acl)
+
+ --  Szabolcs Nagy n...@port70.net  Sat, 18 Apr 2015 10:36:23 +
+
 attr (1:2.4.47-2) unstable; urgency=medium
 
   * Standards-Version: 3.9.5.
diff -Nru attr-2.4.47/debian/patches/20-remove-attr-xattr.patch attr-2.4.47/debian/patches/20-remove-attr-xattr.patch
--- attr-2.4.47/debian/patches/20-remove-attr-xattr.patch	1970-01-01 00:00:00.0 +
+++ attr-2.4.47/debian/patches/20-remove-attr-xattr.patch	2015-04-25 18:32:35.0 +
@@ -0,0 +1,320 @@
+Description: Backport upstream patch for musl support
+ Drop attr/xattr.h and use sys/xattr.h from libc instead.
+Author: Szabolcs Nagy n...@port70.net
+Origin: upstream, http://git.savannah.gnu.org/cgit/attr.git/commit/?id=7921157890d07858d092f4003ca4c6bae9fd2c38
+Last-Update: 2015-04-18
+
+Index: attr-2.4.47/getfattr/getfattr.c
+===
+--- attr-2.4.47.orig/getfattr/getfattr.c
 attr-2.4.47/getfattr/getfattr.c
+@@ -29,7 +29,7 @@
+ #include locale.h
+ #include libgen.h
+ 
+-#include attr/xattr.h
++#include sys/xattr.h
+ #include config.h
+ #include walk_tree.h
+ #include misc.h
+Index: attr-2.4.47/include/attributes.h
+===
+--- attr-2.4.47.orig/include/attributes.h
 attr-2.4.47/include/attributes.h
+@@ -21,6 +21,10 @@
+ #ifdef __cplusplus
+ extern C {
+ #endif
++#include errno.h
++#ifndef ENOATTR
++# define ENOATTR ENODATA
++#endif
+ 
+ /*
+  *	An almost-IRIX-compatible extended attributes API
+Index: attr-2.4.47/include/xattr.h
+===
+--- attr-2.4.47.orig/include/xattr.h
 attr-2.4.47/include/xattr.h
+@@ -1,63 +1,5 @@
+-/*
+- * Copyright (c) 2001-2002 Silicon Graphics, Inc.
+- * All Rights Reserved.
+- *
+- * This program is free software; you can redistribute it and/or modify it
+- * under the terms of the GNU Lesser General Public License as published by
+- * the Free Software Foundation; either version 2.1 of the License, or (at
+- * your option) any later version.
+- *
+- * This program is distributed in the hope that it will be useful, but WITHOUT
+- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public
+- * License for more details.
+- *
+- * You should have received a copy of the GNU Lesser General Public
+- * License along with this program.  If not, see
+- * http://www.gnu.org/licenses/.
+- *
+- */
+-#ifndef __XATTR_H__
+-#define __XATTR_H__
+-
+-#include features.h
+-
++#include sys/xattr.h
+ #include errno.h
+ #ifndef ENOATTR
+-# define ENOATTR ENODATA/* No such attribute */
++# define ENOATTR ENODATA
+ #endif
+-
+-#define XATTR_CREATE  0x1   /* set value, fail if attr already exists */
+-#define XATTR_REPLACE 0x2   /* set value, fail if attr does not exist */
+-
+-
+-__BEGIN_DECLS
+-
+-extern int setxattr (const char *__path, const char *__name,
+-		  const void *__value, size_t __size, int __flags) __THROW;
+-extern int lsetxattr (const char *__path, const char *__name,
+-		  const void *__value, size_t __size, int __flags) __THROW;
+-extern int fsetxattr (int __filedes, const char *__name,
+-		  const void *__value, size_t __size, int __flags) __THROW;
+-
+-extern ssize_t getxattr (const char *__path, const char *__name,
+-void *__value, size_t __size) __THROW;
+-extern ssize_t lgetxattr (const char *__path, const char *__name,
+-void *__value, size_t __size) __THROW;
+-extern ssize_t fgetxattr (int __filedes, const char *__name,
+-void *__value, size_t __size) __THROW;
+-
+-extern ssize_t listxattr (const char *__path, char *__list,
+-size_t __size) __THROW;
+-extern ssize_t llistxattr (const char *__path, char *__list,
+-size_t __size) __THROW;
+-extern ssize_t flistxattr (int __filedes, char *__list,
+-size_t __size) __THROW;
+-
+-extern int removexattr (const char *__path, const char *__name) __THROW;
+-extern int lremovexattr (const char *__path, const char *__name) __THROW;
+-extern int fremovexattr (int __filedes,   const char *__name) __THROW;
+-
+-__END_DECLS
+-
+-#endif	/* __XATTR_H__ */
+Index: attr-2.4.47/libattr/Makefile
+===
+--- attr-2.4.47.orig/libattr/Makefile
 attr-2.4.47/libattr/Makefile
+@@ -29,12 +29,6 @@ LT_AGE = 1
+ CFILES = libattr.c

Bug#782830: attr patch for musl support

[Szabolcs Nagy]

Source: attr
Version: 1:2.4.47-2
Tags: patch
diff -Nru attr-2.4.47/debian/changelog attr-2.4.47/debian/changelog
--- attr-2.4.47/debian/changelog	2014-09-08 07:27:25.0 +
+++ attr-2.4.47/debian/changelog	2015-04-21 20:33:20.0 +
@@ -1,3 +1,11 @@
+attr (1:2.4.47-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream patch to support musl libc
+http://git.savannah.gnu.org/cgit/attr.git/commit/?id=7921157890d07858d092f4003ca4c6bae9fd2c38
+
+ --  Szabolcs Nagy n...@port70.net  Sat, 18 Apr 2015 10:36:23 +
+
 attr (1:2.4.47-2) unstable; urgency=medium
 
   * Standards-Version: 3.9.5.
diff -Nru attr-2.4.47/debian/patches/20-remove-attr-xattr.patch attr-2.4.47/debian/patches/20-remove-attr-xattr.patch
--- attr-2.4.47/debian/patches/20-remove-attr-xattr.patch	1970-01-01 00:00:00.0 +
+++ attr-2.4.47/debian/patches/20-remove-attr-xattr.patch	2015-04-21 20:37:10.0 +
@@ -0,0 +1,319 @@
+Description: Backport upstream patch for musl support
+ Drop attr/xattr.h and use sys/xattr.h from libc instead.
+Author: Szabolcs Nagy n...@port70.net
+Origin: upstream, http://git.savannah.gnu.org/cgit/attr.git/commit/?id=7921157890d07858d092f4003ca4c6bae9fd2c38
+Last-Update: 2015-04-18
+
+Index: attr-2.4.47/getfattr/getfattr.c
+===
+--- attr-2.4.47.orig/getfattr/getfattr.c
 attr-2.4.47/getfattr/getfattr.c
+@@ -29,7 +29,7 @@
+ #include locale.h
+ #include libgen.h
+ 
+-#include attr/xattr.h
++#include sys/xattr.h
+ #include config.h
+ #include walk_tree.h
+ #include misc.h
+Index: attr-2.4.47/include/attributes.h
+===
+--- attr-2.4.47.orig/include/attributes.h
 attr-2.4.47/include/attributes.h
+@@ -21,6 +21,10 @@
+ #ifdef __cplusplus
+ extern C {
+ #endif
++#include errno.h
++#ifndef ENOATTR
++# define ENOATTR ENODATA
++#endif
+ 
+ /*
+  *	An almost-IRIX-compatible extended attributes API
+Index: attr-2.4.47/include/xattr.h
+===
+--- attr-2.4.47.orig/include/xattr.h
 attr-2.4.47/include/xattr.h
+@@ -1,63 +1 @@
+-/*
+- * Copyright (c) 2001-2002 Silicon Graphics, Inc.
+- * All Rights Reserved.
+- *
+- * This program is free software; you can redistribute it and/or modify it
+- * under the terms of the GNU Lesser General Public License as published by
+- * the Free Software Foundation; either version 2.1 of the License, or (at
+- * your option) any later version.
+- *
+- * This program is distributed in the hope that it will be useful, but WITHOUT
+- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public
+- * License for more details.
+- *
+- * You should have received a copy of the GNU Lesser General Public
+- * License along with this program.  If not, see
+- * http://www.gnu.org/licenses/.
+- *
+- */
+-#ifndef __XATTR_H__
+-#define __XATTR_H__
+-
+-#include features.h
+-
+-#include errno.h
+-#ifndef ENOATTR
+-# define ENOATTR ENODATA/* No such attribute */
+-#endif
+-
+-#define XATTR_CREATE  0x1   /* set value, fail if attr already exists */
+-#define XATTR_REPLACE 0x2   /* set value, fail if attr does not exist */
+-
+-
+-__BEGIN_DECLS
+-
+-extern int setxattr (const char *__path, const char *__name,
+-		  const void *__value, size_t __size, int __flags) __THROW;
+-extern int lsetxattr (const char *__path, const char *__name,
+-		  const void *__value, size_t __size, int __flags) __THROW;
+-extern int fsetxattr (int __filedes, const char *__name,
+-		  const void *__value, size_t __size, int __flags) __THROW;
+-
+-extern ssize_t getxattr (const char *__path, const char *__name,
+-void *__value, size_t __size) __THROW;
+-extern ssize_t lgetxattr (const char *__path, const char *__name,
+-void *__value, size_t __size) __THROW;
+-extern ssize_t fgetxattr (int __filedes, const char *__name,
+-void *__value, size_t __size) __THROW;
+-
+-extern ssize_t listxattr (const char *__path, char *__list,
+-size_t __size) __THROW;
+-extern ssize_t llistxattr (const char *__path, char *__list,
+-size_t __size) __THROW;
+-extern ssize_t flistxattr (int __filedes, char *__list,
+-size_t __size) __THROW;
+-
+-extern int removexattr (const char *__path, const char *__name) __THROW;
+-extern int lremovexattr (const char *__path, const char *__name) __THROW;
+-extern int fremovexattr (int __filedes,   const char *__name) __THROW;
+-
+-__END_DECLS
+-
+-#endif	/* __XATTR_H__ */
++#include sys/xattr.h
+Index: attr-2.4.47/libattr/Makefile
+===
+--- attr-2.4.47.orig/libattr/Makefile
 attr-2.4.47/libattr/Makefile
+@@ -29,12 +29,6 @@ LT_AGE = 1
+ CFILES = libattr.c attr_copy_fd.c attr_copy_file.c attr_copy_check.c attr_copy_action.c
+ HFILES = libattr.h
+ 
+-ifeq

Bug#782830: attr patch for musl support

[Szabolcs Nagy]

Source: attr
Version: 1:2.4.47-2
Tags: patch
diff -Nru attr-2.4.47/debian/changelog attr-2.4.47/debian/changelog
--- attr-2.4.47/debian/changelog	2014-09-08 07:27:25.0 +
+++ attr-2.4.47/debian/changelog	2015-04-18 11:28:32.0 +
@@ -1,3 +1,11 @@
+attr (1:2.4.47-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream patch to support musl libc
+http://git.savannah.gnu.org/cgit/attr.git/commit/?id=7921157890d07858d092f4003ca4c6bae9fd2c38
+
+ --  Szabolcs Nagy n...@port70.net  Sat, 18 Apr 2015 10:36:23 +
+
 attr (1:2.4.47-2) unstable; urgency=medium
 
   * Standards-Version: 3.9.5.
diff -Nru attr-2.4.47/debian/patches/20-remove-attr-xattr.patch attr-2.4.47/debian/patches/20-remove-attr-xattr.patch
--- attr-2.4.47/debian/patches/20-remove-attr-xattr.patch	1970-01-01 00:00:00.0 +
+++ attr-2.4.47/debian/patches/20-remove-attr-xattr.patch	2015-04-18 11:26:36.0 +
@@ -0,0 +1,306 @@
+Description: Backport upstream patch for musl support
+ Drop attr/xattr.h and use sys/xattr.h from libc instead.
+Author: Szabolcs Nagy n...@port70.net
+Origin: upstream, http://git.savannah.gnu.org/cgit/attr.git/commit/?id=7921157890d07858d092f4003ca4c6bae9fd2c38
+Last-Update: 2015-04-18
+
+--- attr-2.4.47.orig/getfattr/getfattr.c
 attr-2.4.47/getfattr/getfattr.c
+@@ -29,7 +29,7 @@
+ #include locale.h
+ #include libgen.h
+ 
+-#include attr/xattr.h
++#include sys/xattr.h
+ #include config.h
+ #include walk_tree.h
+ #include misc.h
+--- attr-2.4.47.orig/include/Makefile
 attr-2.4.47/include/Makefile
+@@ -20,7 +20,7 @@ TOPDIR = ..
+ include $(TOPDIR)/include/builddefs
+ 
+ INCDIR = attr
+-INST_HFILES = attributes.h xattr.h error_context.h libattr.h
++INST_HFILES = attributes.h error_context.h libattr.h
+ HFILES = $(INST_HFILES) misc.h walk_tree.h
+ LSRCFILES = builddefs.in buildmacros buildrules config.h.in install-sh
+ LDIRT = $(INCDIR)
+--- attr-2.4.47.orig/include/attributes.h
 attr-2.4.47/include/attributes.h
+@@ -21,6 +21,9 @@
+ #ifdef __cplusplus
+ extern C {
+ #endif
++#ifndef ENOATTR
++# define ENOATTR ENODATA
++#endif
+ 
+ /*
+  *	An almost-IRIX-compatible extended attributes API
+--- attr-2.4.47.orig/include/xattr.h
 /dev/null
+@@ -1,63 +0,0 @@
+-/*
+- * Copyright (c) 2001-2002 Silicon Graphics, Inc.
+- * All Rights Reserved.
+- *
+- * This program is free software; you can redistribute it and/or modify it
+- * under the terms of the GNU Lesser General Public License as published by
+- * the Free Software Foundation; either version 2.1 of the License, or (at
+- * your option) any later version.
+- *
+- * This program is distributed in the hope that it will be useful, but WITHOUT
+- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public
+- * License for more details.
+- *
+- * You should have received a copy of the GNU Lesser General Public
+- * License along with this program.  If not, see
+- * http://www.gnu.org/licenses/.
+- *
+- */
+-#ifndef __XATTR_H__
+-#define __XATTR_H__
+-
+-#include features.h
+-
+-#include errno.h
+-#ifndef ENOATTR
+-# define ENOATTR ENODATA/* No such attribute */
+-#endif
+-
+-#define XATTR_CREATE  0x1   /* set value, fail if attr already exists */
+-#define XATTR_REPLACE 0x2   /* set value, fail if attr does not exist */
+-
+-
+-__BEGIN_DECLS
+-
+-extern int setxattr (const char *__path, const char *__name,
+-		  const void *__value, size_t __size, int __flags) __THROW;
+-extern int lsetxattr (const char *__path, const char *__name,
+-		  const void *__value, size_t __size, int __flags) __THROW;
+-extern int fsetxattr (int __filedes, const char *__name,
+-		  const void *__value, size_t __size, int __flags) __THROW;
+-
+-extern ssize_t getxattr (const char *__path, const char *__name,
+-void *__value, size_t __size) __THROW;
+-extern ssize_t lgetxattr (const char *__path, const char *__name,
+-void *__value, size_t __size) __THROW;
+-extern ssize_t fgetxattr (int __filedes, const char *__name,
+-void *__value, size_t __size) __THROW;
+-
+-extern ssize_t listxattr (const char *__path, char *__list,
+-size_t __size) __THROW;
+-extern ssize_t llistxattr (const char *__path, char *__list,
+-size_t __size) __THROW;
+-extern ssize_t flistxattr (int __filedes, char *__list,
+-size_t __size) __THROW;
+-
+-extern int removexattr (const char *__path, const char *__name) __THROW;
+-extern int lremovexattr (const char *__path, const char *__name) __THROW;
+-extern int fremovexattr (int __filedes,   const char *__name) __THROW;
+-
+-__END_DECLS
+-
+-#endif	/* __XATTR_H__ */
+--- attr-2.4.47.orig/libattr/Makefile
 attr-2.4.47/libattr/Makefile
+@@ -29,12 +29,6 @@ LT_AGE = 1
+ CFILES = libattr.c attr_copy_fd.c attr_copy_file.c attr_copy_check.c attr_copy_action.c
+ HFILES = libattr.h
+ 
+-ifeq ($(PKG_PLATFORM),linux)
+-CFILES += syscalls.c
+-else
+-LSRCFILES = syscalls.c

Bug#782830: attr patch for musl support

[Szabolcs Nagy]

Source: attr
Version: 1:2.4.47-2
Tags: patch
diff -Nru attr-2.4.47/debian/changelog attr-2.4.47/debian/changelog
--- attr-2.4.47/debian/changelog	2014-09-08 07:27:25.0 +
+++ attr-2.4.47/debian/changelog	2015-04-18 15:15:41.0 +
@@ -1,3 +1,11 @@
+attr (1:2.4.47-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream patch to support musl libc
+http://git.savannah.gnu.org/cgit/attr.git/commit/?id=7921157890d07858d092f4003ca4c6bae9fd2c38
+
+ --  Szabolcs Nagy n...@port70.net  Sat, 18 Apr 2015 10:36:23 +
+
 attr (1:2.4.47-2) unstable; urgency=medium
 
   * Standards-Version: 3.9.5.
diff -Nru attr-2.4.47/debian/patches/20-remove-attr-xattr.patch attr-2.4.47/debian/patches/20-remove-attr-xattr.patch
--- attr-2.4.47/debian/patches/20-remove-attr-xattr.patch	1970-01-01 00:00:00.0 +
+++ attr-2.4.47/debian/patches/20-remove-attr-xattr.patch	2015-04-18 15:21:35.0 +
@@ -0,0 +1,331 @@
+Description: Backport upstream patch for musl support
+ Drop attr/xattr.h and use sys/xattr.h from libc instead.
+Author: Szabolcs Nagy n...@port70.net
+Origin: upstream, http://git.savannah.gnu.org/cgit/attr.git/commit/?id=7921157890d07858d092f4003ca4c6bae9fd2c38
+Last-Update: 2015-04-18
+
+Index: attr-2.4.47/getfattr/getfattr.c
+===
+--- attr-2.4.47.orig/getfattr/getfattr.c
 attr-2.4.47/getfattr/getfattr.c
+@@ -29,7 +29,7 @@
+ #include locale.h
+ #include libgen.h
+ 
+-#include attr/xattr.h
++#include sys/xattr.h
+ #include config.h
+ #include walk_tree.h
+ #include misc.h
+Index: attr-2.4.47/include/Makefile
+===
+--- attr-2.4.47.orig/include/Makefile
 attr-2.4.47/include/Makefile
+@@ -20,7 +20,7 @@ TOPDIR = ..
+ include $(TOPDIR)/include/builddefs
+ 
+ INCDIR = attr
+-INST_HFILES = attributes.h xattr.h error_context.h libattr.h
++INST_HFILES = attributes.h error_context.h libattr.h
+ HFILES = $(INST_HFILES) misc.h walk_tree.h
+ LSRCFILES = builddefs.in buildmacros buildrules config.h.in install-sh
+ LDIRT = $(INCDIR)
+Index: attr-2.4.47/include/attributes.h
+===
+--- attr-2.4.47.orig/include/attributes.h
 attr-2.4.47/include/attributes.h
+@@ -21,6 +21,10 @@
+ #ifdef __cplusplus
+ extern C {
+ #endif
++#include errno.h
++#ifndef ENOATTR
++# define ENOATTR ENODATA
++#endif
+ 
+ /*
+  *	An almost-IRIX-compatible extended attributes API
+Index: attr-2.4.47/include/xattr.h
+===
+--- attr-2.4.47.orig/include/xattr.h
 /dev/null
+@@ -1,63 +0,0 @@
+-/*
+- * Copyright (c) 2001-2002 Silicon Graphics, Inc.
+- * All Rights Reserved.
+- *
+- * This program is free software; you can redistribute it and/or modify it
+- * under the terms of the GNU Lesser General Public License as published by
+- * the Free Software Foundation; either version 2.1 of the License, or (at
+- * your option) any later version.
+- *
+- * This program is distributed in the hope that it will be useful, but WITHOUT
+- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public
+- * License for more details.
+- *
+- * You should have received a copy of the GNU Lesser General Public
+- * License along with this program.  If not, see
+- * http://www.gnu.org/licenses/.
+- *
+- */
+-#ifndef __XATTR_H__
+-#define __XATTR_H__
+-
+-#include features.h
+-
+-#include errno.h
+-#ifndef ENOATTR
+-# define ENOATTR ENODATA/* No such attribute */
+-#endif
+-
+-#define XATTR_CREATE  0x1   /* set value, fail if attr already exists */
+-#define XATTR_REPLACE 0x2   /* set value, fail if attr does not exist */
+-
+-
+-__BEGIN_DECLS
+-
+-extern int setxattr (const char *__path, const char *__name,
+-		  const void *__value, size_t __size, int __flags) __THROW;
+-extern int lsetxattr (const char *__path, const char *__name,
+-		  const void *__value, size_t __size, int __flags) __THROW;
+-extern int fsetxattr (int __filedes, const char *__name,
+-		  const void *__value, size_t __size, int __flags) __THROW;
+-
+-extern ssize_t getxattr (const char *__path, const char *__name,
+-void *__value, size_t __size) __THROW;
+-extern ssize_t lgetxattr (const char *__path, const char *__name,
+-void *__value, size_t __size) __THROW;
+-extern ssize_t fgetxattr (int __filedes, const char *__name,
+-void *__value, size_t __size) __THROW;
+-
+-extern ssize_t listxattr (const char *__path, char *__list,
+-size_t __size) __THROW;
+-extern ssize_t llistxattr (const char *__path, char *__list,
+-size_t __size) __THROW;
+-extern ssize_t flistxattr (int __filedes, char *__list,
+-size_t __size) __THROW;
+-
+-extern int removexattr (const char *__path, const char *__name) __THROW;
+-extern int lremovexattr (const char *__path, const

Bug#709335: libvirt-bin: Memory leak

[Gyuris Szabolcs]

Hi!

Package: libvirt-bin
Status: install ok installed
Priority: optional
Section: admin
Installed-Size: 11444
Maintainer: Debian Libvirt Maintainers 
pkg-libvirt-maintain...@lists.alioth.debian.org

Architecture: amd64
Source: libvirt
Version: 1.2.4-1~bpo70+1

The package from backports is leaking memory too if I connect to it with 
qemu+ssh:// :(



--

*Gyuris Szabolcs*
/Rendszer-informatikus/

*Prime Rate Kft.*
H-1044 Budapest
Megyeri út 53.
Tel.: +36-1/231 4060/2403
Fax: +36-1/877 2010
Mobil: +36-20/611 4286
www.primerate.hu http://www.primerate.hu/



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#748681: gcc: broken weak symbol optimization in 4.9

[Szabolcs Nagy]

Source: gcc
Version: 4.9
Severity: normal

the gcc-4.9 in debian sid has the bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

this can badly break code that use weak symbol aliases,
in particular it breaks musl libc

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741652: Still an issue with Grub

[Szabolcs, Hodosi]

Hi,

I would like to ask reopening this ticket, since I tried to install 
Debian Jessie (Netinst, amd64 iso image is just downloaded 1 hour ago) 
and after install it dies on the first boot.
It says Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0), then a stacktace comes.

Motherboard is a Supermicro X7SBE server board with Xeon 3110 CPU.
I have a 2 TB SATA disk with bios_grub, partition is aligned, root 
partitition is /dev/sda3.
The UUID value is corrected in /etc/fstab and grub config, verified with 
blkid command.


I am able to boot the system only with Rescue disk.

Needless to say this is a critical issue for an OS if not booting, thus 
ticket short-cutting is not seems to be an option that happened with the 
previous issue reporter.


Could you please handle this situation with trhe severity it deserves 
and fix the issue in a professional way?


Thank you.

Yours Sincerely,

Szabolcs Hodosi


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#419222: bug #419222 (slapd hangs/corruption under vmware)

[Gyuris Szabolcs]

2014-04-16 03:28 keltezéssel, Ryan Tandy írta:

tags 419222 + moreinfo
thanks

Hi Gyuris,

There hasn't been an update to this bug in several years.

Do you still experience this problem with more recent versions of slapd,
such as 2.4.31 in wheezy or 2.4.39 in jessie?

thanks,
Ryan

Hi,

I have no resource yet to test it sorry. You can close it.

Thank you!

--
Üdvözlettel:
  Gyuris Szabolcs
  szims...@oregpreshaz.eu

http://oregpreshaz.eu
https://www.facebook.com/oregpreshazpince
https://twitter.com/oregpreshaz
https://plus.google.com/101294094345126934261




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#569803: pulseaudio: FujitsuSiemens Esprimo Mobile U9200 switch to Analog Headphones mute sound on headphone

[Gyuris Szabolcs]

2014-04-14 15:25 keltezéssel, Felipe Sateler írta:

On Mon, Apr 14, 2014 at 8:59 AM, Timo Juhani Lindfors
timo.lindf...@iki.fi wrote:

Felipe Sateler fsate...@debian.org writes:

Can you still reproduce this issue? If so, please reply so that we may
debug the problem, otherwise I'd like to close this bug

That particular system is unfortunately still running squeeze due to
some legacy software.

OK, so I'll wait to see if Gyuris can still reproduce the problem with
a newer pulseaudio. If not, I'll close this bug. Please re-file if you
upgrade your system and the problem persists.



Hi All!

You can close the bug. Unfortunately I don't have the hardware any more.

Thank You!

--
Üdvözlettel:
  Gyuris Szabolcs
  szims...@oregpreshaz.eu

http://oregpreshaz.eu
https://www.facebook.com/oregpreshazpince
https://twitter.com/oregpreshaz
https://plus.google.com/101294094345126934261




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#705420: Confirming in libsoup2.4-1/2.42.2-6 in debian testing

[Szabolcs Berecz]

I have the same crash is eclipse indigo and crashplan

Bug#701620: update

[szabolcs]

Would there be anything else I could help with to resolve this?

Thanks,

-szabolcs


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#702289: redmine: Manual multi-instace install fails with missing rake task

[Parragh Szabolcs]

Package: redmine
Version: 2.2.3+dfsg1-1~precise+1
Severity: normal

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***


-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-38-generic (SMP w/1 CPU core)
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages redmine depends on:
ii  bundler 1.1.4-5~precise+1
ii  dbconfig-common 1.8.47
ii  debconf [debconf-2.0]   1.5.42ubuntu1
ii  redmine-pgsql   2.2.3+dfsg1-1~precise+1
ii  ruby4.8
ii  ruby-coderay1.0.6-2~precise+1
ii  ruby-fastercsv  1.5.5-1~precise+1
ii  ruby-net-ldap   0.3.1-1~precise+1
ii  ruby-openid 2.1.8debian-5~precise+1
ii  ruby-rack   1.4.1-1~precise+4
ii  ruby-rack-openid1.3.1-1~precise+1
ii  ruby-rails-3.2  3.2.12-1~precise+1
ii  ruby1.8 [ruby-interpreter]  1.8.7.352-2ubuntu1.1

Versions of packages redmine recommends:
ii  libfcgi-ruby1.8 [libfcgi-ruby]0.8.8-1
ii  libfcgi-ruby1.9.1 [libfcgi-ruby]  0.8.8-1
ii  ruby-passenger3.0.13debian-1~precise+1

Versions of packages redmine suggests:
ii  bzr   none
ii  cvs   none
ii  darcs none
ii  git   none
ii  mercurial none
ii  ruby-rmagick  2.13.1-5build1
ii  subversion1.6.17dfsg-3ubuntu3

-- debconf information excluded

root@oberon content.redmine-pojo.hu  rake -f /usr/share/redmine/Rakefile
generate_session_store --trace  17:35:54
WARNING: 'require 'rake/rdoctask'' is deprecated.  Please use 'require
'rdoc/task' (in RDoc 2.4.2+)' instead.
at /usr/lib/ruby/vendor_ruby/rake/rdoctask.rb
rake aborted!
Don't know how to build task 'generate_session_store'
/usr/lib/ruby/vendor_ruby/rake/task_manager.rb:49:in `[]'
/usr/lib/ruby/vendor_ruby/rake/application.rb:115:in `invoke_task'
/usr/lib/ruby/vendor_ruby/rake/application.rb:94:in `top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:94:in `each'
/usr/lib/ruby/vendor_ruby/rake/application.rb:94:in `top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:133:in
`standard_exception_handling'
/usr/lib/ruby/vendor_ruby/rake/application.rb:88:in `top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:66:in `run'
/usr/lib/ruby/vendor_ruby/rake/application.rb:133:in
`standard_exception_handling'
/usr/lib/ruby/vendor_ruby/rake/application.rb:63:in `run'
/usr/bin/rake:27
root@oberon content.redmine-pojo.hu 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#702291: redmine: Huge memory footprint with Apache-Passanger-Redmine install

[Parragh Szabolcs]

Package: redmine
Version: 2.2.3+dfsg1-1~precise+1
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***


-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-38-generic (SMP w/1 CPU core)
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages redmine depends on:
ii  bundler 1.1.4-5~precise+1
ii  dbconfig-common 1.8.47
ii  debconf [debconf-2.0]   1.5.42ubuntu1
ii  redmine-pgsql   2.2.3+dfsg1-1~precise+1
ii  ruby4.8
ii  ruby-coderay1.0.6-2~precise+1
ii  ruby-fastercsv  1.5.5-1~precise+1
ii  ruby-net-ldap   0.3.1-1~precise+1
ii  ruby-openid 2.1.8debian-5~precise+1
ii  ruby-rack   1.4.1-1~precise+4
ii  ruby-rack-openid1.3.1-1~precise+1
ii  ruby-rails-3.2  3.2.12-1~precise+1
ii  ruby1.8 [ruby-interpreter]  1.8.7.352-2ubuntu1.1

Versions of packages redmine recommends:
ii  libfcgi-ruby1.8 [libfcgi-ruby]0.8.8-1
ii  libfcgi-ruby1.9.1 [libfcgi-ruby]  0.8.8-1
ii  ruby-passenger3.0.13debian-1~precise+1

Versions of packages redmine suggests:
ii  bzr   none
ii  cvs   none
ii  darcs none
ii  git   none
ii  mercurial none
ii  ruby-rmagick  2.13.1-5build1
ii  subversion1.6.17dfsg-3ubuntu3

-- debconf information excluded

Basic redmine install, with default data only + 1 empty project. 

This is a separate instance (default doesn't run), installed as a cp-r of
/usr/share/redmine.

TOP output after pushing redmine for 2 mins.

 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND   
 6508 www-data  20   0  295m 120m 2828 S  0.0 12.2   0:03.52 ruby   
11602 www-data  20   0  295m 120m 2808 S  0.0 12.1   0:03.41 ruby   
11591 www-data  20   0  293m 118m 2744 S  0.0 12.0   0:01.93 ruby   
11585 www-data  20   0  290m 118m 5748 S  0.0 11.9   0:04.50 ruby   
11597 www-data  20   0  291m 116m 2756 S  0.0 11.8   0:01.37 ruby 

Apache config:

VirtualHost *:443

  ServerName x.y.hu
  RailsEnv  production
  PassengerAppRoot /data/www/pojo/content.x-y.hu/redmine
  SetEnv X_DEBIAN_SITEID myredmine
  Alias /plugin_assets/ /var/cache/redmine/myredmine/plugin_assets/
  DocumentRoot /data/www/pojo/content.x-y.hu/redmine
  Directory /data/www/pojo/content.x-y.hu/redmine
Order allow,deny
Allow from all
  /Directory

...

Other:

* no debugging configure
* no real change in any configs, only localhost smtp:

root@oberon ~  diff -r /usr/share/redmine
/data/www/pojo/content.x-y.hu/redmine
21:07:21
Only in /data/www/pojo/content.x-y.hu/redmine/config:
additional_environment.rb
Only in /data/www/pojo/content.x-y.hu/redmine/config:
configuration.yml
diff -r /usr/share/redmine/config/environments/production.rb
/data/www/pojo/content.x-y.hu/redmine/config/environments/production.rb
31c31
   config.active_support.deprecation = :log
---
   config.active_support.deprecation = :notify
Only in /data/www/pojo/content.x-y.hu/redmine/db: schema.rb
Only in /data/www/pojo/content.x-y.hu/redmine: files
Only in /data/www/pojo/content.x-y.hu/redmine: log
Only in /data/www/pojo/content.meta-pojo.hu/redmine/public: log
Only in /data/www/pojo/content.meta-pojo.hu/redmine/public: tmp


---

btw: .js files are missing, dead links for these files:

 root@oberon ~  ls -l /usr/share/redmine/public/javascripts/controls.js
lrwxrwxrwx 1 root root 45 febr  13 09:17 
/usr/share/redmine/public/javascripts/controls.js - 
/../../../javascript/scriptaculous/controls.js
-- which doesn't exist!

same for:
/usr/share/redmine/public/javascripts/dragdrop.js
/usr/share/redmine/public/javascripts/effects.js
/usr/share/redmine/public/javascripts/prototype.js
-- shouldn't something have installed these?

Thanks,
Szabolcs


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701620: linux-image-3.2.0-4-amd64: Unable to use PCI cards on Intel DZ77SL50K motherboard (likely any Z77 board)

[szabolcs]

: [  669.071740] eth1:  setting full-duplex.

At this point as far as debian is concerned the device works. In reality it
does not work at all. No packets are being transmitted or received. After a few
minutes of running with the device brought up the output of /proc/interrupts
shows:

CPU0CPU1CPU2CPU3
 18:0   0   0   0
IO-APIC-fasteoi eth1 (the PCI card)
 40:7154721 4809742 PCI-MSI-edge
eth0 (the integrated eth controller of the mobo)

The attached 'lspci' logs also show the 3Com card had IRQ18 assigned to it.
NOTE: so did the motherboard's SMBus Controller (00:1f:3).

Note 1: A side-effect of bringing the iface up is that my USB keyboard slows
down considerably (as if the rate at which it reads keypresses would go down to
~10 presses per second).

Note 2: I am currently running kernel 3.8, because the stock debian 3.2 kernel
freezes the computer after what appears to be a random time (unrelated to what
I actually do on the system, if doing anything at all). However the bug I am
reporting here applies exactly in the same manner to both 3.2 and 3.8 kernels.

Note 3: I tried booting both kernels with the 'pci=nomsi' parameter, but that
didn't change anything.

Note 4: This is likely not a HW issue, since I tested the configuration in
windoze, and all was working as expected.

Thank you for your help,

-szabolcs



-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: 
product_name: 
product_version: 
chassis_vendor: 
chassis_version: 
bios_vendor: Intel Corporation
bios_version: SLZ7710H.86A.0095.2013.0117.1516
board_vendor: Intel Corporation
board_name: DZ77SL-50K
board_version: AAG55115-300

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core 
processor DRAM Controller [8086:0150] (rev 09)
Subsystem: Intel Corporation Device [8086:2030]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort+ SERR- PERR- INTx-
Latency: 0
Capabilities: access denied

00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd 
Gen Core processor Graphics Controller [8086:0152] (rev 09) (prog-if 00 [VGA 
controller])
Subsystem: Intel Corporation Device [8086:2030]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 43
Region 0: Memory at f780 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at e000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=64]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915

00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset 
Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI])
Subsystem: Intel Corporation Device [8086:2030]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 41
Region 0: Memory at f7d2 (64-bit, non-prefetchable) [size=64K]
Capabilities: access denied
Kernel driver in use: xhci_hcd

00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series 
Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
Subsystem: Intel Corporation Device [8086:2030]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 42
Region 0: Memory at f7d3a000 (64-bit, non-prefetchable) [size=16]
Capabilities: access denied
Kernel driver in use: mei

00:19.0 Ethernet controller [0200]: Intel Corporation 82579V Gigabit Network 
Connection [8086:1503] (rev 04)
Subsystem: Intel Corporation Device [8086:2030]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 40
Region 0: Memory at f7d0 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at f7d38000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at f060 [size

Bug#701620: linux-image-3.2.0-4-amd64: Unable to use PCI cards on Intel DZ77SL50K motherboard (likely any Z77 board)

[szabolcs]

Hello Ben,

@VT-d:
My CPU (i3-3220T), does not support VT-d. I also see no such option in
the BIOS. VT-x however is enabled.

@/proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.8.0
root=UUID=aa6e008e-1ec9-4220-8ae9-9d39e8b469d4 ro quiet

The cmdline looks the same with the stock 3.2 kernel too, except of
course for the kernel image file.

Thank you for your attention,

-szabolcs


On Mon, Feb 25, 2013 at 1:52 PM, Ben Hutchings b...@decadent.org.uk wrote:
 Control: tag -1 moreinfo

 On Mon, 2013-02-25 at 12:45 +0100, szabolcs wrote:
 Package: src:linux
 Version: 3.2.35-2
 Severity: important
 Tags: upstream

 Dear Maintainer,

 I am unable to use any of my PCI slots of my new motherboard (a recent HW
 upgrade). Tested with two PCI network cards (1. Atheros chip based WiFi card 
 I
 used with my previous mobo for WiFi AP, and 2. a 3Com NIC) placed repeatedly 
 in
 different PCI slots. The results were always the same:

 1. during boot the kernel loads the appropriate modules (e.g. 3c59x), all
 appears to look just fine in dmesg.

 2. unless I bring the interfaces associated with the network cards up,
 everything works as expected.

 3. the moment I issue the 'ifup ethX' command, the following is printed in
 /var/log/syslog:
 [...]

 Is the IOMMU (also known as VT-d) enabled in the BIOS settings?
 What is the kernel command line (/proc/cmdline)?

 Ben.

 --
 Ben Hutchings
 Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#698787:

[Bobák Szabolcs]

Dear Maintainers,

any help or suggestion would be a huge help. We haven't managed to get it 
compiled from source package even if we modify the suggested source file size.

Best regards,
Szabolcs




Jelen elektronikus levél és csatolmányai bizalmas vagy jogszabály által védett 
információt tartalmazhatnak, amely kizárólag a címzettként feltüntetett 
személynek ill. szervezetnek szól. Amennyiben Ön nem szerepel a címzettek 
között, kérjük, azonnal értesítse a levél küldőjét emailen vagy telefonon és 
törölje a levelet és csatolásait a bejövő üzenetei közül anélkül, hogy a 
levelet bármilyen célra felhasználná, továbbítaná, lemásolná vagy 
hozzáférhetővé tenné a címzetteken kívül más személyek részére. A CompLex Kiadó 
Kft. és az Akadémiai Kiadó Zrt. nem felelős jelen elektronikus levél vagy 
csatolmányai hibás vagy hiányos továbbításából vagy engedély nélküli 
felhasználásából eredő esetleges károkért. Válaszadás esetén a CompLex Kiadó 
Kft. vagy az Akadémiai Kiadó Zrt. jogosult a levél üzleti tartalmát ellenőrizni.

This email and any attachments may contain confidential or privileged 
information and is intended for the addressee only.If you are not the intended 
recipient, please immediately notify us by email or telephone and delete the 
original email and attachments without using, disseminating or reproducing its 
contents to anyone other than the intended recipient. CompLex Publisher Ltd. 
and the Akadémiai Publisher Ltd. shall not be liable for the incorrect or 
incomplete transmission of this email or any attachments, nor for unauthorized 
use by its employees. CompLex Publisher Ltd. or Akadémiai Publisher Ltd. are 
entitled to check the business contents of replied e-mails.

Bug#698787: apache2-mpm-worker multiarch install problem on Debian Wheezy amd64

[Bobák Szabolcs]

Package: apache2-mpm-worker
Version: 2.2.22-12

We run latest Debian Wheezy amd64 (b4 installer, updated system) server with 
multiarch.
We have done correctly the multiarch setup followed the wiki, many i386 package 
install works.
But we would like to install apache2-mpm-worker i386 arch and we cannot get it 
work.

After: apt-get install apache2-mpm-worker:i386 apache2.2-common:i386
we get:

apache2.2-common:i386 : Depends: mime-support:i386 but it is not installable
 Depends: ssl-cert:i386 but it is not installable

But mime-support:all and ssl-cert:all packages are installed.
We think that we are on the right way, but something is wrong with the package.
Do we miss something?

By the way the source package of apache2-mpm-worker is also wrong, please check 
the package because the suggested file size is not the same as the package on 
the server (main mirror and hungarian mirror) and of course hash is incorrect. 
We cannot download or extract it.

Thank you,
Szabolcs Bobak





Jelen elektronikus levél és csatolmányai bizalmas vagy jogszabály által védett 
információt tartalmazhatnak, amely kizárólag a címzettként feltüntetett 
személynek ill. szervezetnek szól. Amennyiben Ön nem szerepel a címzettek 
között, kérjük, azonnal értesítse a levél küldőjét emailen vagy telefonon és 
törölje a levelet és csatolásait a bejövő üzenetei közül anélkül, hogy a 
levelet bármilyen célra felhasználná, továbbítaná, lemásolná vagy 
hozzáférhetővé tenné a címzetteken kívül más személyek részére. A CompLex Kiadó 
Kft. és az Akadémiai Kiadó Zrt. nem felelős jelen elektronikus levél vagy 
csatolmányai hibás vagy hiányos továbbításából vagy engedély nélküli 
felhasználásából eredő esetleges károkért. Válaszadás esetén a CompLex Kiadó 
Kft. vagy az Akadémiai Kiadó Zrt. jogosult a levél üzleti tartalmát ellenőrizni.

This email and any attachments may contain confidential or privileged 
information and is intended for the addressee only.If you are not the intended 
recipient, please immediately notify us by email or telephone and delete the 
original email and attachments without using, disseminating or reproducing its 
contents to anyone other than the intended recipient. CompLex Publisher Ltd. 
and the Akadémiai Publisher Ltd. shall not be liable for the incorrect or 
incomplete transmission of this email or any attachments, nor for unauthorized 
use by its employees. CompLex Publisher Ltd. or Akadémiai Publisher Ltd. are 
entitled to check the business contents of replied e-mails.

Bug#691898: mktemp segfaults on armel (sheevaplug)

[SZÉKELYI Szabolcs]

Subject: mktemp segfaults on armel (sheevaplug)
Package: coreutils
Version: 8.5-1
Severity: important

*** Please type your report below this line ***

This breaks initramfs-tools, hence Severity: important.

-- System Information:
Debian Release: 6.0.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.39-bpo.2-kirkwood
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages coreutils depends on:
ii  libacl1   2.2.49-4   Access control list shared library
ii  libattr1  1:2.4.44-2 Extended attribute shared library
ii  libc6 2.11.3-4   Embedded GNU C Library: Shared lib
ii  libgcc1   1:4.4.5-8  GCC support library
ii  libselinux1   2.0.96-1   SELinux runtime shared libraries

coreutils recommends no packages.

coreutils 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#685713: linux-image-3.2.0-0.bpo.2-kirkwood: fails to boot on SheevaPlug

[Székelyi Szabolcs]

Subject: linux-image-3.2.0-0.bpo.2-kirkwood: fails to boot on SheevaPlug
Package: src:linux
Version: 3.2.20-1~bpo60+1 
Severity: important

*** Please type your report below this line ***

Linux version 3.2.0-0.bpo.2-kirkwood fails to boot on the SheevaPlug.

The kernel and initramfs are loaded from a USB stick.

Here's what I'm doing in u-boot:

==
Marvell usb start
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 4 USB Device(s) found
   scanning bus for storage devices... 2 Storage Device(s) found
Marvell ext2load usb 0:1 0x90 /uImage
Loading file /uImage from usb device 0:1 (usbda1)
1624808 bytes read
Marvell ext2load usb 0:1 0xe0 /uInitrd
Loading file /uInitrd from usb device 0:1 (usbda1)
3097319 bytes read
Marvell bootm 0x90 0xe0
## Booting kernel from Legacy Image at 0090 ...
   Image Name:   Debian kernel
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:1624744 Bytes = 1.5 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 00e0 ...
   Image Name:   Debian ramdisk
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:3097255 Bytes = 3 MiB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

==

And nothing happens.

-- Package-specific info:
** Kernel log: boot messages should be attached


-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.39-bpo.2-kirkwood
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages linux-image-3.2.0-0.bpo.2-kirkwood depends on:
ii  debconf [debconf-2.0]   1.5.36.1 Debian configuration management sy
ii  initramfs-tools [linux-init 0.99~bpo60+1 tools for generating an initramfs
ii  linux-base  3.4~bpo60+1  Linux image base package
ii  module-init-tools   3.12-2   tools for managing Linux kernel mo

Versions of packages linux-image-3.2.0-0.bpo.2-kirkwood recommends:
pn  firmware-linux-free   none (no description available)
pn  uboot-mkimage none (no description available)

Versions of packages linux-image-3.2.0-0.bpo.2-kirkwood suggests:
pn  fdutils   none (no description available)
pn  linux-doc-3.2 none (no description available)

Versions of packages linux-image-3.2.0-0.bpo.2-kirkwood is related to:
pn  firmware-atheros  none (no description available)
pn  firmware-bnx2 none (no description available)
pn  firmware-bnx2xnone (no description available)
pn  firmware-brcm80211none (no description available)
pn  firmware-intelwimax   none (no description available)
pn  firmware-ipw2x00  none (no description available)
pn  firmware-ivtv none (no description available)
pn  firmware-iwlwifi  none (no description available)
pn  firmware-libertas none (no description available)
pn  firmware-linuxnone (no description available)
pn  firmware-linux-nonfreenone (no description available)
pn  firmware-myricom  none (no description available)
pn  firmware-netxen   none (no description available)
pn  firmware-qlogic   none (no description available)
pn  firmware-ralink   none (no description available)
pn  firmware-realtek  none (no description available)
pn  xen-hypervisornone (no description available)

-- debconf information:
  
linux-image-3.2.0-0.bpo.2-kirkwood/postinst/missing-firmware-3.2.0-0.bpo.2-kirkwood:
  linux-image-3.2.0-0.bpo.2-kirkwood/postinst/ignoring-ramdisk:
  
linux-image-3.2.0-0.bpo.2-kirkwood/prerm/removing-running-kernel-3.2.0-0.bpo.2-kirkwood:
 true
  
linux-image-3.2.0-0.bpo.2-kirkwood/postinst/depmod-error-initrd-3.2.0-0.bpo.2-kirkwood:
 false


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#667362: rubberband: diff for NMU version 1.3-1.3

[Székelyi Szabolcs]

Hi Gregor,

On 2012. May 27. 14:24:29 gregor herrmann wrote:
 I've prepared an NMU for rubberband (versioned as 1.3-1.3) and
 uploaded it to DELAYED/2. Please feel free to tell me if I
 should delay it longer.

Thanks for your help.

-- 
cc



signature.asc
Description: This is a digitally signed message part.

Bug#650221: Issue in Wheezy

[Hodosi Szabolcs]

Dear Package Maintainer, Michael,

I can reproduce the issue with fresh install of Debian Wheezy (installed 
on 27th May 2012 with latest packages on testing repo).


I found the file at

root@torch:/usr/src/iscsitarget/trunk# ls -la /usr/sbin/iscsid
-rwxr-xr-x 1 root root 671784 szept 14  2011 /usr/sbin/iscsid

but some of the script in the debian package search for /sbin/iscsid 
which is really not found.


Can you please update the path?

Thanks,

Szabi




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#625430: vrb: diff for NMU version 0.5.1-5.1

[Székelyi Szabolcs]

Hi Gregor,

On 2011. October 24. 16:09:08 gregor herrmann wrote:
 I've prepared an NMU for vrb (versioned as 0.5.1-5.1) and
 uploaded it to DELAYED/2. Please feel free to tell me if I
 should delay it longer.

Please feel free to upload it directly into the archive if you want. Thanks 
for your help!

-- 
cc




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#623875: libuuid-perl is uninstallable again

[Székelyi Szabolcs]

As perl-base 5.12.3-6 has been uploaded to unstable, libuuid-perl is 
uninstallable again because of the dependency on perlapi-5.10.1 while 
unstable's perl-base now provides perlapi-5.12.3.

-- 
cc




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#440835: ITP: sonic-visualiser -- analysing music audio files

[Székelyi Szabolcs]

Hi Alessio,

On Thursday 10 March 2011 00:39:48 Alessio Treglia wrote:
 any news on this?

Actually the package is still available [0] on mentors, along with rubberband 
[1]. They are a bit outdated now, but don't lag too far behind the current 
versions.

I will package the new versions in one or two weeks. Meanwhile you can upload 
the old ones for me if you're interested (IANAD[DM]). ;)

Thanks,
-- 
cc

[0] http://mentors.debian.net/debian/pool/main/s/sonic-visualiser
[1] http://mentors.debian.net/debian/pool/main/r/rubberband




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#615543: base: Firmware files not found by boot process, despite specific files are there and readable for world

[Hodosi Szabolcs]

Package: base
Severity: important

I have two DVB_T USB device, either or both of them can not read the firmware 
file,
nowadays this issue occurs with an (Alcor DTV-1000) Afatech 9015 USB device.

DMESG output:
usb 1-7: New USB device found, idVendor=15a4, idProduct=9016
usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-7: Product: DVB-T 2
usb 1-7: Manufacturer: Afatech
ata6: SATA link down (SStatus 0 SControl 310)
Freeing unused kernel memory: 464k freed
udev[117]: starting version 164
dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in cold state, will try to 
load a firmware
dvb-usb: did not find the firmware file. (dvb-usb-af9015.fw) Please see 
linux/Documentation/dvb/ for more details on firmware-problems. (-2)
dvb_usb_af9015: probe of 1-7:1.0 failed with error -2

lsusb out:

root@torch:~# lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 06da:0003 Phoenixtec Power Co., Ltd 
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 15a4:9016 Afatech Technologies, Inc. AF9015 DVB-T USB2.0 
stick
Bus 001 Device 003: ID 2304:023d Pinnacle Systems, Inc. PCTV 340e
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

And the firmware file is there:

root@torch:/lib/firmware# ls -l /lib/firmware/dvb-usb-af9015.fw 
-rw-r--r-- 1 root root 15913 2010 �pr   16 /lib/firmware/dvb-usb-af9015.fw

Packages installed contains firmwares:

root@torch:/lib/firmware# dpkg --list | grep firmware
ii  firmware-ivtv0.28 Binary 
firmware for iTVC15-family MPEG codecs (ivtv and pvrusb2 drivers)
ii  firmware-linux   0.28 Binary 
firmware for various drivers in the Linux kernel (meta-package)
ii  firmware-linux-free  2.6.32-30Binary 
firmware for various drivers in the Linux kernel
ii  firmware-linux-nonfree   0.28 Binary 
firmware for various drivers in the Linux kernel
ii  firmware-realtek 0.28 Binary 
firmware for Realtek wired and wireless network adapters

Can you please look into why the boot process cannot read the firmware file, 
which exists
and readable?

Scope: Device is unable to use.
Exclusion: Other firmwares are detected and loaded.

User Status:
Reboot didn't help. Poweroff, unplug the computer didn't help.
Unplug the device then replug didn't helped.

The device worked properly under Ubuntu 10.04 LTS Lucid Lynx with (almost) the 
same kernel
(2.6.35.x).

The system itself is a :

root@torch:/lib/firmware# uname -a
Linux torch 2.6.35.10-3 #1 SMP Mon Dec 27 19:56:08 CET 2010 x86_64 GNU/Linux

Thank you very much for all the help, guideance.

-- System Information:
Debian Release: 6.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.35.10-3 (SMP w/4 CPU cores)
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#615546: reportbug: Segmentation fault

[Szabolcs Siebenhofer]

Package: reportbug
Version: 4.12.6
Severity: normal

When burgreport sent, reportbug exited unexpectedly.

error: line 214289: bad flagvector
error: line 214290: bad flagvector
error: line 214291: bad flagvector
error: line 214292: bad flagvector
error: line 214293: bad flagvector
error: line 214294: bad flagvector
error: line 214295: bad flagvector
error: line 214296: bad flagvector
error: line 215652: bad flagvector
error: line 215653: bad flagvector
error: line 215654: bad flagvector
error: line 215655: bad flagvector
error: line 215656: bad flagvector
error: line 215657: bad flagvector
error: line 215658: bad flagvector
error: line 215659: bad flagvector
error: line 222749: bad flagvector
error: line 222750: bad flagvector
error: line 222751: bad flagvector
error: line 222752: bad flagvector
error: line 222753: bad flagvector
error: line 222754: bad flagvector
error: line 222755: bad flagvector
error: line 222756: bad flagvector
error: line 222996: bad flagvector
error: line 222997: bad flagvector
error: line 222998: bad flagvector
error: line 222999: bad flagvector
error: line 223000: bad flagvector
error: line 223001: bad flagvector
error: line 223002: bad flagvector
error: line 223003: bad flagvector
error: line 223004: bad flagvector
error: line 223005: bad flagvector
error: line 223006: bad flagvector
error: line 223007: bad flagvector
error: line 224136: bad flagvector
error: line 224137: bad flagvector
error: line 224138: bad flagvector
error: line 224139: bad flagvector
error: line 224140: bad flagvector
error: line 224141: bad flagvector
error: line 224142: bad flagvector
error: line 224143: bad flagvector
error: line 246317: bad flagvector
Szegmentálási hiba  (this is hungarian means segmentation fault)



-- Package-specific info:
** Environment settings:
EDITOR=nano
INTERFACE=gtk2

** /home/zibi/.reportbugrc:
reportbug_version 4.12.6
mode standard
ui gtk2
realname Szabolcs Siebenhofer
email the...@gmail.com
smtphost mail.t-online.hu
smtpuser zibi

-- System Information:
Debian Release: 6.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=hu_HU.utf8, LC_CTYPE=hu_HU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages reportbug depends on:
ii  apt 0.8.10.3 Advanced front-end for dpkg
ii  python  2.6.6-3+squeeze5 interactive high-level object-orie
ii  python-reportbug4.12.6   Python modules for interacting wit

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  debconf-utilsnone  (no description available)
pn  debsums  none  (no description available)
pn  dlocate  none  (no description available)
pn  emacs22-bin-common | none  (no description available)
ii  exim44.72-6  metapackage to ease Exim MTA (v4) 
ii  exim4-daemon-light [ 4.72-6  lightweight Exim MTA (v4) daemon
ii  file 5.04-5  Determines file type using magic
ii  gnupg1.4.10-4GNU privacy guard - a free PGP rep
ii  python-gtk2  2.17.0-4Python bindings for the GTK+ widge
ii  python-gtkspell  2.25.3-7Python bindings for the GtkSpell l
pn  python-urwid none  (no description available)
ii  python-vte   1:0.24.3-2  Python bindings for the VTE widget
ii  xdg-utils1.0.2+cvs20100307-2 desktop integration utilities from

-- 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#615547: mirrors: release file expired

[Szabolcs Siebenhofer]

Package: mirrors
Severity: important

During apt-get update i got the following error message: E: Release file
expired, ignoring http://ftp.hu.debian.org/debian/dists/squeeze-updates/Release
(invalid since 5d 21h 2min 28s)



-- System Information:
Debian Release: 6.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=hu_HU.utf8, LC_CTYPE=hu_HU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#611937: tasksel: Hungarian spell checking problem

[Szabolcs Siebenhofer]

Package: tasksel
Version: 2.78
Severity: important
Tags: patch l10n


Since OOo and Iceweasel depends on hunspell-hu package, hungarian spell 
checking doesn't work with myspell-hu, so need to change to hunspell-hu.
Without this changes hungarian users can found spell checking unusable. 


-- System Information:
Debian Release: 5.0.8
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages tasksel depends on:
ii  aptitude  0.4.11.11-1~lenny1 terminal-based package manager
ii  debconf [debconf-2.0] 1.5.24 Debian configuration management sy
ii  liblocale-gettext-per 1.05-4 Using libc functions for internati
ii  tasksel-data  2.78   Official tasks used for installati

tasksel recommends no packages.

tasksel suggests no packages.

-- debconf information excluded
Task: hungarian-desktop
Enhances: hungarian, desktop
Section: l10n
Description: Hungarian desktop
 This task localises the desktop in Hungarian.
Key:
 gsfonts-x11
 ttf-dejavu
 ttf-liberation
 ttf-freefont
 xfonts-base
Packages: task-fields
Packages-list:
 ttf-sil-andika
 ttf-tiresias
 iceweasel-l10n-hu
 ttf-junicode
 ttf-georgewilliams
 ttf-isabella
 ttf-opensymbol
 ttf-sil-doulos
 ttf-sil-charis
 ttf-sil-gentium
 ttf-okolaks
 ttf-unicode
 xfonts-100dpi-transcoded
 openoffice.org-l10n-hu
 openoffice.org-help-hu
 openoffice.org-hyphenation-hu
 hunspell-hu
 xfonts-terminus

Bug#610700: initramfs-tools: settings from conf.d/* are not visible for hook scripts

[SZÉKELYI Szabolcs]

Package: initramfs-tools
Version: 0.98.7
Severity: normal

As far as I understand, /etc/initramfs-tools/conf.d is a directory to
configure intramfs-tools without touching the main configuration file
initramfs-tools.conf. But there's some inconsistency here: it looks to
me that only the settings from initramfs.conf are visible to hook
scripts, whereas those from conf.d/* are not.

It would be nice, for example, to check the BOOT setting from hook
scripts and skip growing the initramfs uselessly if the selected boot
method does not require some features. But currently this is not
possible if a value is assigned to BOOT via a file in conf.d.

-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 15M Jan 21 13:15 /boot/initrd.img-2.6.32-5-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 root=/dev/mapper/mranderson-root ro quiet

-- resume
RESUME=/dev/mapper/mranderson-swap_crypt
-- /proc/filesystems
ext4
fuseblk
ext2
ext3
reiserfs
xfs
jfs
msdos
vfat
ntfs
minix
hfs
hfsplus
qnx4
ufs
btrfs

-- lsmod
Module  Size  Used by
nls_utf81208  0 
nls_cp437   5817  0 
btrfs 375670  0 
zlib_deflate   17746  1 btrfs
crc32c  2560  1 
libcrc32c   1074  1 btrfs
ufs56474  0 
qnx46194  0 
hfsplus65270  0 
hfs37455  0 
minix  21197  0 
ntfs  162796  0 
vfat7884  0 
msdos   6202  0 
fat40038  2 vfat,msdos
jfs   140089  0 
xfs   436941  0 
exportfs3170  1 xfs
reiserfs  194156  0 
ext3  106518  0 
jbd37085  1 ext3
ext2   52969  0 
ecryptfs   79791  1 
ip6table_filter 2384  0 
ip6_tables 15075  1 ip6table_filter
iptable_filter  2258  0 
ip_tables  13899  1 iptable_filter
ebtable_nat 1588  0 
ebtables   13933  1 ebtable_nat
x_tables   12845  3 ip6_tables,ip_tables,ebtables
ppdev   5030  0 
lp  7462  0 
sco 7209  2 
bnep9427  2 
acpi_cpufreq5571  1 
rfcomm 29597  8 
cpufreq_userspace   1992  0 
cpufreq_stats   2659  0 
l2cap  24736  16 bnep,rfcomm
cpufreq_conservative 5162  0 
cpufreq_powersave902  0 
kvm_intel  38146  0 
uinput  6376  1 
binfmt_misc 6431  1 
kvm   214088  1 kvm_intel
fuse   50625  1 
sha256_generic  8692  2 
aes_x86_64  7340  200 
aes_generic25714  1 aes_x86_64
cbc 2539  197 
loop   11799  0 
firewire_sbp2  11514  0 
dm_crypt   10664  1 
snd_hda_codec_intelhdmi10695  1 
snd_hda_codec_idt  42481  1 
arc41274  2 
snd_hda_intel  20019  3 
snd_hda_codec  54244  3 
snd_hda_codec_intelhdmi,snd_hda_codec_idt,snd_hda_intel
ecb 1841  3 
snd_hwdep   5380  1 snd_hda_codec
snd_pcm60503  2 snd_hda_intel,snd_hda_codec
iwlagn 73123  0 
snd_seq42881  0 
iwlcore77810  1 iwlagn
snd_timer  15582  2 snd_pcm,snd_seq
uvcvideo   52063  0 
snd_seq_device  4493  1 snd_seq
joydev  8459  0 
videodev   29993  1 uvcvideo
snd46446  15 
snd_hda_codec_intelhdmi,snd_hda_codec_idt,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_seq,snd_timer,snd_seq_device
i2c_i8017830  0 
btusb   9881  0 
hid_microsoft   2695  0 
v4l1_compat11442  2 uvcvideo,videodev
bluetooth  41827  7 sco,bnep,rfcomm,l2cap,btusb
mac80211  137340  2 iwlagn,iwlcore
v4l2_compat_ioctl32 8474  1 videodev
psmouse49777  0 
dell_laptop 1985  0 
soundcore   4598  1 snd
cfg80211  101496  3 iwlagn,iwlcore,mac80211
parport_pc 18855  0 
rfkill 13044  4 bluetooth,dell_laptop,cfg80211
snd_page_alloc  6249  2 snd_hda_intel,snd_pcm
dcdbas  5048  1 dell_laptop
parport27954  3 ppdev,lp,parport_pc
serio_raw   3752  0 
pcspkr  1699  0 
container   2389  0 
battery 4998  0 
ac  2192  0 
processor  29935  5 acpi_cpufreq
wmi 4323  0 
evdev   7352  31 
usbhid 33292  0 
hid63225  2 hid_microsoft,usbhid
ext4  289033  6 

Bug#610738: libvirt-bin: libvirtd should start after cgroups are mounted

[SZÉKELYI Szabolcs]

Package: libvirt-bin
Version: 0.8.3-5
Severity: normal

There's a race condition between cgconfig and libvirt-bin init
scripts. This can cause errors like 'Unable to create cgroup for vm:
No such file or directory' when a VM is migrated to this host from
another one. After a manual restart of libvirtd, everything works
fine.

This should be just a matter of a

# Required-Start: cgconfig

in /etc/init.d/libvirt-bin.

-- System Information:
Debian Release: 6.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libvirt-bin depends on:
ii  adduser   3.112+nmu2 add and remove users and groups
ii  libavahi-client3  0.6.27-3   Avahi client library
ii  libavahi-common3  0.6.27-3   Avahi common library
ii  libblkid1 2.17.2-7   block device id library
ii  libc6 2.11.2-9   Embedded GNU C Library: Shared lib
ii  libcap-ng00.6.5-1An alternate POSIX capabilities li
ii  libdevmapper1.02.12:1.02.48-4The Linux Kernel Device Mapper use
ii  libgcrypt11   1.4.5-2LGPL Crypto library - runtime libr
ii  libgnutls26   2.8.6-1the GNU TLS library - runtime libr
ii  libnl11.1-6  library for dealing with netlink s
ii  libparted0debian1 2.3-5  The GNU Parted disk partitioning s
ii  libpciaccess0 0.12.0-1   Generic PCI access library for X
ii  libreadline6  6.1-3  GNU readline and history libraries
ii  libsasl2-22.1.23.dfsg1-7 Cyrus SASL - authentication abstra
ii  libudev0  164-4  libudev shared library
ii  libuuid1  2.17.2-7   Universally Unique ID library
ii  libvirt0  0.8.3-5library for interfacing with diffe
ii  libxenstore3.04.0.1-2Xenstore communications library fo
ii  libxml2   2.7.8.dfsg-2   GNOME XML library
ii  logrotate 3.7.8-6Log rotation utility

Versions of packages libvirt-bin recommends:
ii  bridge-utils  1.4-5  Utilities for configuring the Linu
ii  dnsmasq-base  2.55-2 A small caching DNS proxy and DHCP
ii  ebtables  2.0.9.2-2  Ethernet bridge frame table admini
ii  gawk  1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr
ii  iptables  1.4.10-1   administration tools for packet fi
ii  libxml2-utils 2.7.8.dfsg-2   XML utilities
ii  netcat-openbsd1.89-4 TCP/IP swiss army knife
ii  qemu-kvm  0.12.5+dfsg-5  Full virtualization on x86 hardwar

Versions of packages libvirt-bin suggests:
ii  policykit-1   0.96-4 framework for managing administrat

-- 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#610530: ocfs2-tools: BUG at fs/ocfs2/dlm/dlmmaster.c:2226! invalid opcode

[Szabolcs JANOSI]

] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.046255] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.046259] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.046277] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.046281] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.046317] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.046322] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.046363] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.046367] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.046374] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.046379] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.046394] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.046399] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.046405] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.046410] (20385,2):dlm_send_remote_unlock_request:359 ERROR: status = -107 
Jan 19 09:54:36 kernel: [5414618.147644] o2net: accepted connection from node XXX (num 1) at x.x.x.x:

Jan 19 09:54:36 kernel: [5414620.867740] (31712,1):dlm_do_master_request:1342 
ERROR: link to 1 went down!
Jan 19 09:54:36 kernel: [5414620.867740] (31712,1):dlm_get_lock_resource:919 ERROR: status = -112 
Jan 19 09:54:36 kernel: [5414620.871982] (31124,9):dlm_do_master_request:1342 ERROR: link to 1 went down!
Jan 19 09:54:36 kernel: [5414620.871982] (31124,9):dlm_get_lock_resource:919 ERROR: status = -112 
--


Technical investigations resulted that it was not caused by network problem.


-- System Information:
Debian Release: 5.0.7
 APT prefers stable
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-26lenny1
CPU: Intel(R) Xeon(R) CPU E5620

Versions of packages ocfs2-tools depends on:
ii  libc62.7-18lenny6 
ii  libcomerr2   1.41.3-1 
ii  libglib2.0-0 2.16.6-3 
ii  libncurses5  5.7+20081213-1
ii  libreadline5 5.2-3.1   
ii  libuuid1 1.41.3-1  



Versions of packages ocfs2-tools suggests:
ii  ocfs2console  1.4.1-1  


/etc/default/o2cb values:
O2CB_HEARTBEAT_THRESHOLD=31
O2CB_IDLE_TIMEOUT_MS=3
O2CB_KEEPALIVE_DELAY_MS=2000
O2CB_RECONNECT_DELAY_MS=2000


Regards,
Szabolcs JANOSI






--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#440835: Processed (with 1 errors): The package is ready

[Székelyi Szabolcs]

What about asking the bug owner first before hijacking an RFP?

I have the packages as well, but no sponsor showed interest in uploading.

-- 
cc

On Wednesday 17 November 2010 18:06:08 Debian Bug Tracking System wrote:
 Processing commands for cont...@bugs.debian.org:
  owner 520230 Alessio Treglia ales...@debian.org
 
 Bug #520230 [wnpp] RFP: sonicvisualiser -- analysing music audio files
 Bug #440835 [wnpp] ITP: sonic-visualiser -- view and analyse the contents
 of audio files Owner changed from SZÉKELYI Szabolcs c...@mail.3d.hu to
 Alessio Treglia ales...@debian.org. Owner changed from SZÉKELYI
 Szabolcs c...@mail.3d.hu to Alessio Treglia ales...@debian.org.
 
  retitle 520230 ITP: sonic-visualiser -- viewing and analysing the
 
 Bug #520230 [wnpp] RFP: sonicvisualiser -- analysing music audio files
 Bug #440835 [wnpp] ITP: sonic-visualiser -- view and analyse the contents
 of audio files Changed Bug title to 'ITP: sonic-visualiser -- viewing and
 analysing the' from 'RFP: sonicvisualiser -- analysing music audio files'
 Changed Bug title to 'ITP: sonic-visualiser -- viewing and analysing the'
 from 'ITP: sonic-visualiser -- view and analyse the contents of audio
 files'
 
  contents of music audio files
 
 Unknown command or malformed arguments to command.
 
  thanks
 
 Stopping processing here.
 
 Please contact me if you need assistance.


signature.asc
Description: This is a digitally signed message part.

Bug#599620: www.debian.org: www.deian.org/intro/cn missing instruction

[Szabolcs Siebenhofer]

Package: www.debian.org
Severity: wishlist

Please insert language settings instruction for Google Chrome in 
intro/cn.wml

-- System Information:
Debian Release: 5.0.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#586202: bind9: configuration file routines:STR_COPY:variable has no value:conf_def.c:629:line 170

[Gyuris Szabolcs]

Package: bind9
Version: 1:9.6.ESV.R1+dfsg-0+lenny2
Severity: normal

after upgrade bind9 stops working with:

Auto configuration failed
3075737296:error:0E065068:configuration file routines:STR_COPY:variable has
no value:conf_def.c:629:line 170

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-openvz-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages bind9 depends on:
ii  adduser   3.110  add and remove users and groups
ii  bind9utils1:9.6.ESV.R1+dfsg-0+lenny2 Utilities for BIND
ii  debconf [debc 1.5.24 Debian configuration management sy
ii  libbind9-50   1:9.6.ESV.R1+dfsg-0+lenny2 BIND9 Shared Library used by BIND
ii  libc6 2.7-18lenny4   GNU C Library: Shared libraries
ii  libcap2   2.11-2 support for getting/setting POSIX.
ii  libdb4.6  4.6.21-11  Berkeley v4.6 Database Libraries [
ii  libdns55  1:9.6.ESV.R1+dfsg-0+lenny2 DNS Shared Library used by BIND
ii  libisc52  1:9.6.ESV.R1+dfsg-0+lenny2 ISC Shared Library used by BIND
ii  libisccc501:9.6.ESV.R1+dfsg-0+lenny2 Command Channel Library used by BI
ii  libisccfg50   1:9.6.ESV.R1+dfsg-0+lenny2 Config File Handling Library used 
ii  libkrb53  1.6.dfsg.4~beta1-5lenny4   MIT Kerberos runtime libraries
ii  libldap-2.4-2 2.4.11-1+lenny1OpenLDAP libraries
ii  liblwres501:9.6.ESV.R1+dfsg-0+lenny2 Lightweight Resolver Library used 
ii  libssl0.9.8   0.9.8g-15+lenny6   SSL shared libraries
ii  libxml2   2.6.32.dfsg-5+lenny1   GNOME XML library
ii  lsb-base  3.2-20 Linux Standard Base 3.2 init scrip
ii  net-tools 1.60-22The NET-3 networking toolkit
ii  netbase   4.34   Basic TCP/IP networking system

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind9-doc none (no description available)
ii  dnsutils  1:9.6.ESV.R1+dfsg-0+lenny2 Clients provided with BIND
pn  resolvconfnone (no description available)
pn  ufw   none (no description available)

-- debconf information:
  bind9/different-configuration-file:
  bind9/run-resolvconf: true
  bind9/start-as-user: bind



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#586202: resolved

[Gyuris Szabolcs]

In /usr/lib/ssl/openssl.cnf I had

  subjectAltName = ${ENV::ALTNAME}

because I need to generate certificates with subjectAltName but before I
started named I didn't set the environment variable.

I commented out the subjectAltName = ${ENV::ALTNAME} lines in openssl
config so bind9 works ok.

-- 
\\///   http://linux.oregpreshaz.eu/ CACert
 O O  / http://www.oregpreshaz.eu/
/=uOO(_)OOu==~ WOT
| E-mail: szimszon az oregpreshaz pont eu
| VoIP  : szimszon a ekiga.net | pgp key id: 049BFAD8   Hitelesito




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#585637: python-imaging-sane: get_devices() doesn't find scanner on net (saned)

[Gyuris Szabolcs]

Package: python-imaging-sane
Version: 1.1.7-1+b1
Severity: normal

Python 2.5.5 (r255:77872, Apr 21 2010, 08:44:16) 
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
 import sane
 sane.init()
(16777237, 1, 0, 21)
 sane.get_devices()
[]

---

but scanimage -L works:


scanimage -L
device `net:domain.tld:gt68xx:libusb:001:119' is a Mustek BearPaw 2400 CU Plus 
flatbed scanner


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.34.gimli (SMP w/2 CPU cores)
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-imaging-sane depends on:
ii  libc62.10.2-9Embedded GNU C Library: Shared lib
ii  libsane  1.0.21-1API library for scanners
ii  python   2.5.4-9 An interactive high-level object-o
ii  python-central   0.6.14+nmu2 register and build utility for Pyt
ii  python-imaging   1.1.7-1+b1  Python Imaging Library

Versions of packages python-imaging-sane recommends:
ii  python-tk 2.6.5-1Tkinter - Writing Tk applications 

Versions of packages python-imaging-sane suggests:
pn  python-imaging-docnone (no description available)
pn  python-imaging-sane-dbg   none (no description available)

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#569803: pulseaudio: FujitsuSiemens Esprimo Mobile U9200 switch to Analog Headphones mute sound on headphone

[Gyuris Szabolcs]

Package: pulseaudio
Version: 0.9.21-1
Severity: normal

If I switch the output device from Analog Speaker or Analog Output to 
Analog Headphones then the Speaker switch is off and the Front is muted 
but it is needed to hear anything in headphone.

So the Speaker switch is off and it's Okay.
The Front is muted it's not.

SoundCard: 
Card: HDA Intel
Chip: Realtek ALC262
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio 
Controller (rev 03)

My laptop is a FujitsuSiemens Esprimo Mobile U9200.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores)
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages pulseaudio depends on:
ii  adduser   3.112  add and remove users and groups
ii  consolekit0.4.1-3framework for defining and trackin
ii  libasound21.0.21a-1  shared library for ALSA applicatio
ii  libasyncns0   0.3-1  Asyncronous name service query lib
ii  libc6 2.10.2-2   GNU C Library: Shared libraries
ii  libcap2   1:2.17-2   support for getting/setting POSIX.
ii  libdbus-1-3   1.2.20-2   simple interprocess messaging syst
ii  libgdbm3  1.8.3-9GNU dbm database routines (runtime
ii  libice6   2:1.0.6-1  X11 Inter-Client Exchange library
ii  libltdl7  2.2.6b-2   A system independent dlopen wrappe
ii  libpulse0 0.9.21-1   PulseAudio client libraries
ii  libsamplerate00.1.7-3Audio sample rate conversion libra
ii  libsm62:1.1.1-1  X11 Session Management library
ii  libsndfile1   1.0.21-2   Library for reading/writing audio 
ii  libspeexdsp1  1.2~rc1-1  The Speex extended runtime library
ii  libudev0  150-2  libudev shared library
ii  libwrap0  7.6.q-18   Wietse Venema's TCP wrappers libra
ii  libx11-6  2:1.3.3-1  X11 client-side library
ii  libxtst6  2:1.1.0-2  X11 Testing -- Resource extension 
ii  lsb-base  3.2-23 Linux Standard Base 3.2 init scrip
ii  udev  150-2  /dev/ and hotplug management daemo

Versions of packages pulseaudio recommends:
ii  gstreamer0.10-pulseaudio 0.10.17-1   GStreamer plugin for PulseAudio
ii  libasound2-plugins   1.0.21-3+b1 ALSA library additional plugins
ii  pulseaudio-esound-compat 0.9.21-1PulseAudio ESD compatibility layer
ii  pulseaudio-module-x110.9.21-1X11 module for PulseAudio sound se

Versions of packages pulseaudio suggests:
ii  paman 0.9.4-1PulseAudio Manager
ii  paprefs   0.9.9-2PulseAudio Preferences
ii  pavucontrol   0.9.9-1PulseAudio Volume Control
ii  pavumeter 0.9.3-1PulseAudio Volume Meter
ii  pulseaudio-utils  0.9.21-1   Command line tools for the PulseAu

-- 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
Archive: 
http://lists.debian.org/20100214122946.29820.6050.report...@gimli.kopaszhegy

Bug#561230: merge Sonic Visualiser ITP/RFP

[SZÉKELYI Szabolcs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

merge 520230 440835
thanks

I already have an ITP on Sonic Visualiser, and packages are ready,
waiting for dependencies (Vamp Plugin SDK, Rubber Band) to find their
ways to the repository.

For the impatient, see
http://mentors.debian.net/debian/pool/main/s/sonic-visualiser/ which may
be a bit outdated, but I'm working on bringing packages in line with
upstream versions.

- --
cc

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAks7oiQACgkQGJRwVVqzMkMSMgCfcTO3PTgNsCdQp7nVxvuhJfEn
yTwAniupzW/xNNuONeiMf5LdPuZHEkGY
=//dH
-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#445418: ntfs-3g: Can't mount anymore as normal user

[Szabolcs Szakacsits]

Mike Hommey wrote:

On Fri, Oct 05, 2007 at 08:26:35PM +0200, Adam CĂŠcile (Le_Vert) wrote:

 The best thing to do would be to have ntfs-3g fall back to exec()ing
 fusermount(1) as plain libfuse does when mount(2) fails.

It would fail with fusermount: option blkdev is privileged error message.
The only solution is http://ntfs-3g.org/support.html#useroption3

CVE-2007-5159 is a misunderstanding and obsolete for over 11 months, since 
the release of NTFS-3G 1.2216: http://ntfs-3g.org/releases.html

NTFS-3G's security was reviewed and reworked one year ago. Using the 
built-in fuse-lite is secure. No known risks are involved. Using external 
FUSE is unknown.

More details are available from the 5th paragraphs at:
http://article.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/418

This is the very short story of the ntfs-3g security problems from over one 
year ago. All and even more were fixed in January and February of 2008. I 
can provide real person names offline if requested.

A Fedora user noticed that if ntfs-3g and everything else is configured the 
documented way for unprivileged mounts to mount NTFS volumes then users can 
indeed mount unprivileged any NTFS volume. This was the intended behavior 
by design for those who needed this feature by explicit configuration (not 
default) but the user believed it is a security problem.

A security advisory was issued by Fedora what other distributions followed
without checking out the technical details.

A Red Hat employee from their security team later confirmed me in private 
that the security analyses was incorrect what he approved.

During the same time Ludwig Nussel from SUSE has found an unrelated, real 
local root exploit (much higher severity). This was never disclosed to the 
public but the incorrect security advisory is used today as a proxy. The 
CVE is still not analysed/confirmed.

The solution would have been not trivial and involved the cooperation of 
several teams. Since the beginning of this year ntfs-3g has no dependency 
on FUSE user space and we was able to fully audit and fix all discovered 
security issues in ntfs-3g.

Please note, the above doesn't mean setuid-root use would be encouraged by 
NTFS-3G. Actually just the opposite. But it's there for those who want to 
run (not only mount) ntfs-3g unprivileged.

The user/user fstab option issue could be fixed if mount(8) called the
mount.ntfs-3g mount helper privileged. Otherwise setuid-root ntfs-3g is
required. 

Regards,
Szaka

--
NTFS-3G:  http://ntfs-3g.org




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#511716: ITP: ttymidi -- serial to ALSA MIDI adapter

[Székelyi Szabolcs]

Package: wnpp
Severity: wishlist
Owner: Székelyi Szabolcs c...@mail.3d.hu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: ttymidi
  Version : 0.20
  Upstream Author : Unknown t...@hotmail.com
* URL : http://www.varal.org/ttymidi/
* License : GPL
  Programming Lang: C
  Description : serial to ALSA MIDI adapter

ttymidi feeds the ALSA MIDI sequencer with MIDI commands read from
standard serial-like devices.

It can be used with devices that don't have a standard 5-pin DIN
connector, but speak (or can be made to speak) the MIDI protocol,
such as the Arduino board. Development files for using the Arduino
this way are also included, so one can build a cheap MIDI interface
with minimum effort.

- -- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkls8u4ACgkQGJRwVVqzMkOtWACdEItN83dR10uhStyyBJlKX5qI
4qgAoIayVQ7hseUZzQzQh9dt9SrvYDQ+
=ksRe
-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#483348: libvrb: FTBFS: mv: cannot stat `debian/tmp/usr/lib/libvrb.a.0.5.1': No such file or directory

[SZÉKELYI Szabolcs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Lucas Nussbaum wrote:
 Package: libvrb
 Version: 0.5.1-4
 Severity: serious
 User: [EMAIL PROTECTED]
 Usertags: qa-ftbfs-20080527 qa-ftbfs
 Justification: FTBFS on i386

 During a rebuild of all packages in sid, your package failed to build on
 i386.

[...]

 This rebuild was done with gcc 4.3 instead of gcc 4.2, because gcc 4.3
 is now the default on most architectures (even if it's not the case on
 i386 yet).  Consequently, many failures are caused by the switch to gcc
 4.3.
 If you determine that this failure is caused by gcc 4.3, feel free to
 downgrade this bug to 'important' if your package is only built on i386,
 and this bug is specific to gcc 4.3 (i.e the package builds fine with
 gcc 4.2).

It looks like the FTBFS is caused by a misbehaving dpkg-source. From the
logs:

[...]
dpkg-source: extracting libvrb in libvrb-0.5.1-4
[...]

According to my best knowledge, the Debian revision number should not be
part of the build directory. On my box, it works properly:

[...]
dpkg-source: extracting libvrb in libvrb-0.5.1
[...]

Is it possible that dpkg used to rebuild the packages was buggy?

Thanks,
- --
cc

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkiHh7MACgkQGJRwVVqzMkMltACeL22wQ/RHlUGi2c1lYtXtkqg7
y8oAni7hFI6uWB11T8y9PsnTvDtqjVae
=7kEi
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#482571: Fix for the FTBFS

[SZÉKELYI Szabolcs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Albin,

Albin Tonnerre wrote:
| tags 482571 patch
| tags 483321 patch
| thanks
|
| Hello,
| I intend to NMU this package as part of the gcc-4.3 release goal.
| Patch fixing the issue attached.

I've contacted upstream author Chris Cannam about this issue, and he
told me that the next release (in a couple of weeks) will fix these
issues (see attached message), so I didn't see the point of applying it
as a Debian-specific patch for such a short time frame, especially
because -- according to my knowledge -- there's no software currently in
Debian that depends on these packages, and they don't have too much use
by themselves.

However, help is always welcome, so feel free to NMU in case you see fit.

I also have to mention that IANADD, so uploading is not just a matter of
a few commands for me.

Regards,
- --
cc

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkhWY7YACgkQGJRwVVqzMkMffwCfSxjH+QNzCKFA4vEj4MFnlN6H
tXUAoKJQM5qSGWIA5RQZZJ0VgX5YeXmL
=oGdg
-END PGP SIGNATURE-
---BeginMessage---
On 26/05/2008, SZÉKELYI Szabolcs [EMAIL PROTECTED] wrote:
  Vamp SDK has just completed its way into the Debian unstable repository.
  However, it looks like it has a problem when built on sparc.

  You can find an extract of the build log at
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482571

That report refers to gcc-4.3.  The current Vamp plugin SDK release
(1.2) should not build with gcc-4.3 in any architecture, because some
#includes are missing.  Previous versions of gcc's supporting
libraries apparently included these headers from other headers, at
variance with the standards, and that has been fixed in 4.3.

This change has been an enormous headache -- it affects a huge amount
of C++ code that mixes the C++ standard library with C library
functions.  Very few programmers (myself obviously included)
consistently check that they have the right #includes every time they
add a call to a C library function; they just rely on the compiler to
tell them if they haven't.  Every project I actively work on has been
affected, and although I have the necessary fixes, in SVN at least,
for all of them, I haven't always had time to roll out a proper
release yet.

Anyway... the build is fixed in the Vamp plugin SDK SVN repository
(since SVN revision 762) and will be fixed in the next release, which
is not very far away (it will be another bugfix-only, API-compatible
release).  I attach below the patch that was necessary to fix this
problem.

Thanks,


Chris


vamp-plugin-sdk-gcc-4.3.diff
Description: Binary data
---End Message---

Bug#457480: Vamp is in sid

[SZÉKELYI Szabolcs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Free,

Free Ekanayaka wrote:
| I've noticed that vamp got accepted in sid, nice! Any plan to upload
| rubberband soon?

Unfortunately I must inform you that Vamp SDK is currently FTBFS because
of gcc4.3 transition, so it's essentially unusable. I didn't plan to fix
this bug in the Debian diff, since according to the author, a fresh
release is on the way; however, Albin Tonnerre signaled his intention to
NMU it, fixing the FTBFS bug, and I welcomed his efforts to do so.

See bugs #482571 and #483321.

These bugs must fixed first, since Vamp is a Build-Depends for Rubber Band.

Regards,
- --
cc

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkhWxogACgkQGJRwVVqzMkN2gwCdFqB9nhk9WzrkqHCxQ7PMS+CW
6aIAoJqbkETkIWPvOrm7IHhVXs3TsnTJ
=f60f
-END PGP SIGNATURE-



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#457480: ITP status

[SZÉKELYI Szabolcs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Free,

Free Ekanayaka wrote:
| I'm interested in getting rubberband into Debian too. What's the status
| of this ITP now? I can give a hand if needed.

Thanks, the packages are ready, I'm just waiting for Vamp Plugin SDK to
go through NEW, since it's a Build-Depends for Rubber Band.

Regards,
- --
cc

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgsAEoACgkQGJRwVVqzMkOWAgCglfGKB6HFt+8n1IElCrFnshU5
il4AoKZudvlWiZlZT/LuE3D5ntpsOmEe
=tFvp
-END PGP SIGNATURE-



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#457480: ITP: rubberband -- An audio time-stretching and pitch-shifting library and utility program

[SZÉKELYI Szabolcs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

owner 457480 !
thanks

Ramakrishnan Muthukrishnan wrote:
  If you are not interested anymore, I would be happy to take it over.
 
 Please take over. Swamped with non-debian work at the moment.

Thank you. I'll do my best to be a good maintainer of it.

- --
cc

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIFl02GJRwVVqzMkMRAm9rAKCS5hRoq98nf0IBmSe/IsekaNrlpQCglrtF
D8Rez7hiZnz2KWP0rF9Dgh4=
=jSL+
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#457480: ITP: rubberband -- An audio time-stretching and pitch-shifting library and utility program

[SZÉKELYI Szabolcs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

what's the status of this bug? I'm asking this because it's blocking my
ITP (#440835), since Sonic Visualiser Build-Depends on this.

If you are not interested anymore, I would be happy to take it over.

Thanks,
- --
cc

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIBPIrGJRwVVqzMkMRAhX5AKCe1OFBFTZ2Z6MOKuKApM0m4PwiqwCcCV8d
mQNptcRTGIbXDdt5RBYHjPQ=
=DdWM
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#463754: ITP: vamp-plugin-sdk -- audio analysis and feature extraction plugins (SDK)

[Sz��kelyi Szabolcs]

Package: wnpp
Severity: wishlist
Owner: Székelyi Szabolcs [EMAIL PROTECTED]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: vamp-plugin-sdk
  Version : 1.1b
  Upstream Author : Chris Cannam [EMAIL PROTECTED]
* URL : http://www.vamp-plugins.org/
* License : BSD
  Programming Lang: C, C++
  Description : audio analysis and feature extraction plugins (SDK)

Vamp is an audio processing plugin system for plugins that extract
descriptive information from audio data - typically referred to as
audio analysis plugins or audio feature extraction plugins.

Just like an audio effects plugin (such as a VST), a Vamp plugin is a
binary module that can be loaded up by a host application and fed
audio data. However, unlike an effects plugin, a Vamp plugin outputs
not processed audio but some sort of symbolic information. Typical
things that a Vamp plugin might calculate include the locations of
moments such as note onset times, visual representations of the audio
such as histograms, or curve data such as power or fundamental
frequency.

- -- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22neo (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHpQsAGJRwVVqzMkMRAgntAKCcEuP/w8Czf48zqbC2yRMm2sxvCACfUoEN
5SNLXrwRsH35e/OzlQfix00=
=sm3q
-END PGP SIGNATURE-

Bug#447927: FTBFS with libmac installed

[Sz��kelyi Szabolcs]

Package: xmms2
Version: 0.2DrJekyll-4
Severity: serious
Justification: no longer builds from source

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

With libmac installed, the configure script automatically builds the
Monkey's Audio plugin, resulting in the following error:

dh_install: debian/tmp/usr/lib/xmms2/libxmms_mac.so exists in debian/tmp/ but 
is not installed to anywhere
dh_install: missing files, aborting
make: *** [install-stamp] Error 1
dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 
2

The mac plugin should be packaged or excluded from the build process
(--without-plugins=mac, maybe).


- -- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22neo (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages xmms2 depends on:
ii  xmms2-client-cli0.2DrJekyll-4+b1 XMMS2 - cli client
ii  xmms2-core  0.2DrJekyll-4+b1 XMMS2 - core package
ii  xmms2-plugin-alsa   0.2DrJekyll-4+b1 XMMS2 - ALSA output
ii  xmms2-plugin-id3v2  0.2DrJekyll-4+b1 XMMS2 - ID3v2 plugin
ii  xmms2-plugin-mad0.2DrJekyll-4+b1 XMMS2 - libmad based mp3 decoder
ii  xmms2-plugin-vorbis 0.2DrJekyll-4+b1 XMMS2 - vorbis decoder

xmms2 recommends no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD4DBQFHH66gGJRwVVqzMkMRAvQNAJYpPSu2gx4yqVwGqGbyk3S7xMvDAJ4lrZPi
w2DAZt8a1OLtSqliO+/yuw==
=DvO+
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#445315: CVE-2007-5159 priviledge escalation

[Szabolcs Szakacsits]

Hi,

I added our comments to the origin of the security report:
https://bugzilla.redhat.com/show_bug.cgi?id=298651#c21

Regards,  Szaka

--
NTFS-3G Lead Developer:  http://ntfs-3g.org



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#445418: ntfs-3g: Can't mount anymore as normal user

[Szabolcs Szakacsits]

Hi,

I added our comments to the origin of the security report:
https://bugzilla.redhat.com/show_bug.cgi?id=298651#c21

Regards,  Szaka

--
NTFS-3G Lead Developer:  http://ntfs-3g.org



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379418: dpkg-buildpackage: signing .dsc and .changes fails with UTF-8 encoded uid

[Székelyi Szabolcs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Frank Lichtenheld wrote:
 On Sun, Jul 23, 2006 at 02:46:26PM +0200, Székelyi Szabolcs wrote:
 Lintian (and Policy?) requires the Debian changelog to be UTF-8
 encoded. But if -- for example, -- the maintainer name is encoded this
 way, then gpg fails to find the secret key because assumes by default
 that the command line parameters are not UTF-8 encoded. Passing
 - --utf8-strings to gpg solves the problem.

 Patch attached.
 
 Can you give me a quick example that demonstrates the difference?
 I can't seem to find one.

Just try building libvrb. Can it be a locale problem?

My $LANG is unset by default, this way I get:

==
 signfile libvrb_0.5.1-4.dsc
gpg: skipped Székelyi Szabolcs [EMAIL PROTECTED]: secret key not
available
gpg: [stdin]: clearsign failed: secret key not available
==

Thanks,
- --
cc

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG/CbsGJRwVVqzMkMRAgKUAKCYZSS6veLmfPVpHBfHYAXC0ibrugCgg9k4
+Fk0WyKVmgcUcUQKS2ZY6oY=
=+MMh
-END PGP SIGNATURE-

Bug#438864: fix

[Gyuris Szabolcs]

/usr/share/python-support/trac/trac/versioncontrol/cache.py

Change the line 114 from

  pass

to
  return

The working code
--
if self.youngest:
next_youngest = self.repos.next_rev(self.youngest)
else:
next_youngest = None
try:
next_youngest = self.repos.oldest_rev
next_youngest = self.repos.normalize_rev(next_youngest)
except TracError:
-pass
+return # can't normalize oldest_rev: repository was
empty


It works for me...

-- 
\\///   http://linux.oregpreshaz.eu/Thawte
 O O  / http://www.oregpreshaz.eu/
/=uOO(_)OOu==~   WOT
| E-mail: szimszon az oregpreshaz pont eu
| VoIP  : szimszon a ekiga.net | pgp key id: 049BFAD8   Notary



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#438402: can't umount a mountpoint with spaces

[Szabolcs Szakacsits]

Hi,

The fusermount error message is misleading because it's incorrect sometimes 
(fusermount reports not the real error). The real problem is described in 
bug #434128 and was fixed in fuse 2.7.0 and ntfs-3g 1.810.

I have tried now to unmount a mountpoint with spaces using the latest fuse 
and ntfs-3g versions and it has worked fine.

But thanks for the bug report: it's better to report an issue more times 
than never.

Szaka

--
NTFS-3G Lead Developer:  http://ntfs-3g.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#434128: ntfs-3g: fusermount -u refuses to unmount

[Szabolcs Szakacsits]

This is a bug in both ntfs-3g and fuse. Fuse 2.7.0 has fixed it and that 
version is a requirement for this functionality for any fuseblk type fuse 
file systems.

It's planned that the next release of ntfs-3g will also fix this issue 
which will work with fuse 2.7.0 and later (it's not possible to fix it 
for earlier fuse releases).

If you already have fuse 2.7.0 then a workaround can be 

ntfs-3g /dev/sda11 ~/mnt/nt/ -o user=username

then fusermount -u will work.

In the long run fusermount will be eliminated and umount(8) can be used 
instead. This requires kernel support on which Miklos Szeredi is already 
working on.

ntfsmount works because it uses the unsafe 'fuse' fstype for block devices 
which can result corruptions, data or volume loss if the device is detached 
or powered down right after unmount since the kernel buffers aren't ensured 
to be flused to the disk. You can make fusermount -u work with ntfs-3g the 
same unsafe, risky way if you downgrade the fuse kernel module to a 2.5.x 
or your kernel to a prior 2.6.20 version.

Szaka

-- 
NTFS-3G Lead Developer: http://ntfs-3g.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#419222: [Pkg-openldap-devel] Bug#419222: it crashed again - news

[Gyuris Szabolcs]

Finally I found some relevant logs:

May  3 19:46:43

conn=63 op=1542 DEL
dn=uid=user_domain1.com,domain=domain1.com,ou=virtualFtp,dc=domain,dc=hu
conn=63 op=1542 RESULT tag=107 err=0 text=
conn=63 op=1543 DEL
dn=domain=domain2.co.hu,domain=domain1.com,ou=virtualFtp,dc=domain,dc=hu
bdb(dc=domain,dc=hu): page 3: illegal page type or format
bdb(dc=domain,dc=hu): PANIC: Invalid argument
= bdb_idl_delete_key: c_close failed: DB_RUNRECOVERY: Fatal error, run
database recovery (-30978)
bdb(dc=domain,dc=hu): PANIC: fatal region error detected; run recovery
conn=63 op=1543 RESULT tag=107 err=80 text=entry index delete failed
conn=63 op=1544 DEL
dn=domain=domain2.co.hu,domain=domain1.com,ou=virtualWeb,dc=domain,dc=hu
bdb(dc=domain,dc=hu): PANIC: fatal region error detected; run recovery
conn=63 op=1544 RESULT tag=107 err=80 text=internal error
conn=63 op=1545 DEL
dn=domain=domain3.org,domain=domain1.com,ou=virtualFtp,dc=domain,dc=hu
bdb(dc=domain,dc=hu): PANIC: fatal region error detected; run recovery
conn=63 op=1545 RESULT tag=107 err=80 text=internal error


I think the conn=63 is the connection from slurpd the master ldap
server's replica daemon.

The objects selected to delete existed in the slave ldap database:

May  2 18:25:57

conn=63 op=1310 ADD
dn=domain=domain2.co.hu,domain=domain1.com,ou=virtualWeb,dc=domain,dc=hu
conn=63 op=1310 RESULT tag=105 err=0 text=
conn=63 op=1311 ADD
dn=domain=domain2.co.hu,domain=domain1.com,ou=virtualFtp,dc=domain,dc=hu
conn=63 op=1311 RESULT tag=105 err=0 text=

What was happening here? there were no shutdowns, no crashes, just
bdb(dc=domain,dc=hu): page 3: illegal page type or format


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#419222: slapd freeze

[Gyuris Szabolcs]

Hi Quanah!

After I gave 256MB ram to the virtual machine the slapd works without
trouble.



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#419222: it crashed again

[Gyuris Szabolcs]

I shouted from the rooftops.

The slapd made some big mistake and the nagios plugin said: Could not
search/find objectclasses in dc=domain,dc=tld

I stopped the slapd, then started and tried to run slapcat:

bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if
errors are encountered.
bdb_db_open: alock_recover failed
bdb_db_close: alock_close failed
backend_startup_one: bi_db_open failed! (-1)
slap_startup failed
Segmentation fault.


I have no db_stat :(

# locate db_stat
/usr/share/mysql/mysql-test/r/have_ndb_status_ok.require

I guess that the failure occurs when the master slapd make some update
to the slave... :(


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#419222: [Pkg-openldap-devel] Bug#419222: it crashed again

[Gyuris Szabolcs]

Quanah Gibson-Mount wrote:
 
 
 --On May 3, 2007 8:57:10 PM +0200 Gyuris Szabolcs
 [EMAIL PROTECTED] wrote:
 
 I shouted from the rooftops.

 The slapd made some big mistake and the nagios plugin said: Could not
 search/find objectclasses in dc=domain,dc=tld

 I stopped the slapd, then started and tried to run slapcat:

 bdb_db_open: unclean shutdown detected; attempting recovery.
 bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if
 errors are encountered.
 
 This says that you are running in read-only mode, so it will not try and
 recover the database.  And it appears to believe you have had an unclean
 shutdown.  How was slapd and/or the system last stopped?
It wasn't stopped at all. I think after the master slapd try to make an
update to the slave then something horrible happens and the database
will be corrupt.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#404486: The same bug with 2.6.18.dfsg.1-12

[Gyuris Szabolcs]

I wonder if somebody could help me...

I had the same serious error recently:

Apr 18 05:44:53 int-backup kernel: EXT3-fs error (device md1):
ext3_free_blocks: Freeing blocks not in datazone - block = 340051947,
count = 1
Apr 18 05:44:53 int-backup kernel: Aborting journal on device md1.
Apr 18 05:44:53 int-backup kernel: __journal_remove_journal_head:
freeing b_committed_data
Apr 18 05:44:53 int-backup kernel: __journal_remove_journal_head:
freeing b_committed_data
Apr 18 05:44:53 int-backup kernel: __journal_remove_journal_head:
freeing b_committed_data
Apr 18 05:44:53 int-backup kernel: __journal_remove_journal_head:
freeing b_committed_data
Apr 18 05:44:53 int-backup kernel: __journal_remove_journal_head:
freeing b_committed_data
Apr 18 05:44:53 int-backup kernel: __journal_remove_journal_head:
freeing b_committed_data

...

Apr 18 05:44:53 int-backup kernel: EXT3-fs error (device md1):
ext3_free_blocks: Freeing blocks not in datazone - block = 371627902,
count = 1
Apr 18 05:44:53 int-backup kernel: EXT3-fs error (device md1):
ext3_free_blocks: Freeing blocks not in datazone - block = 1671519576,
count = 1
Apr 18 05:44:53 int-backup kernel: EXT3-fs error (device md1):
ext3_free_blocks: Freeing blocks not in datazone - block = 1191557896,
count = 1
Apr 18 05:44:53 int-backup kernel: EXT3-fs error (device md1):
ext3_free_blocks: Freeing blocks not in datazone - block = 1800208356,
count = 1
Apr 18 05:44:53 int-backup kernel: EXT3-fs error (device md1):
ext3_free_blocks: Freeing blocks not in datazone - block = 2990452676,
count = 1

...

Apr 18 05:44:54 int-backup kernel: Assertion failure in journal_forget()
at fs/jbd/transaction.c:1228: !jh-b_frozen_data
Apr 18 05:44:54 int-backup kernel: [ cut here ]
Apr 18 05:44:54 int-backup kernel: kernel BUG at fs/jbd/transaction.c:1228!
Apr 18 05:44:54 int-backup kernel: invalid opcode:  [#1]
Apr 18 05:44:54 int-backup kernel: SMP
Apr 18 05:44:54 int-backup kernel: Modules linked in: nfs nfsd exportfs
lockd nfs_acl sunrpc button ac battery ipv6 dm_snapshot dm_mirror dm_mod
loop evdev snd_via82xx gameport snd_ac97_codec snd_ac97_bus snd_pcm
snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd
via82cxxx_audio uart401 floppy sound rtc pcspkr via686a psmouse
serio_raw via_agp agpgart soundcore i2c_isa i2c_viapro parport_pc
i2c_core ac97_codec shpchp pci_hotplug parport ext3 jbd mbcache raid1
md_mod ide_generic ide_cd cdrom sd_mod via82cxxx generic ide_core sata_sil
e100 mii libata scsi_mod uhci_hcd usbcore thermal processor fan
Apr 18 05:44:54 int-backup kernel: CPU:0
Apr 18 05:44:54 int-backup kernel: EIP:0060:[d091dad4]Not
tainted VLI
Apr 18 05:44:54 int-backup kernel: EFLAGS: 00010292   (2.6.18-4-686 #1)
Apr 18 05:44:54 int-backup kernel: EIP is at journal_forget+0xa9/0x1d9 [jbd]
Apr 18 05:44:54 int-backup kernel: eax: 005c   ebx: c15547bc   ecx:
0096   edx: 
Apr 18 05:44:54 int-backup kernel: esi: cbb22f40   edi: cf918600   ebp:
c3850600   esp: cfdc7cf8
Apr 18 05:44:54 int-backup kernel: ds: 007b   es: 007b   ss: 0068
Apr 18 05:44:54 int-backup kernel: Process nfsd (pid: 3040, ti=cfdc6000
task=c13e0aa0 task.ti=cfdc6000)
Apr 18 05:44:54 int-backup kernel: Stack: d09225bd d0922248 d09225a8
04cc d092267b cdd933ec c15547bc c15547bc
Apr 18 05:44:54 int-backup kernel: cf918600 cdd933ec d092011d 00e2c343
c15547bc
cd7480d4 cdd933ec c15547bc
Apr 18 05:44:54 int-backup kernel: d0952644 c15547bc cdd933ec cd7480d4
00e2c343
d095295e c15547bc 00e2c343
Apr 18 05:44:54 int-backup kernel: Call Trace:
Apr 18 05:44:54 int-backup kernel: [d092011d] journal_revoke+0xd1/0xf5
[jbd]
Apr 18 05:44:54 int-backup kernel: [d0952644] ext3_forget+0x7a/0xb3 [ext3]
Apr 18 05:44:54 int-backup kernel: [d095295e]
ext3_free_branches+0xd4/0x1a9 [ext3]
Apr 18 05:44:54 int-backup kernel: [d095294c]
ext3_free_branches+0xc2/0x1a9 [ext3]
Apr 18 05:44:54 int-backup kernel: [d095294c]
ext3_free_branches+0xc2/0x1a9 [ext3]
Apr 18 05:44:54 int-backup kernel: [d0953117]
ext3_truncate+0x6e4/0x79a [ext3]Apr 18 05:44:54 int-backup kernel:
[c015be29] __getblk+0x27/0x266
Apr 18 05:44:54 int-backup kernel: [d091cabb]
do_get_write_access+0x435/0x462
[jbd]
Apr 18 05:44:54 int-backup kernel: [c0147e1e] truncate_inode_pages+0x9/0xf
Apr 18 05:44:54 int-backup kernel: [c014d1e2] vmtruncate+0xc4/0xe2
Apr 18 05:44:54 int-backup kernel: [c016fd9f] inode_setattr+0x59/0x165
Apr 18 05:44:54 int-backup kernel: [d0953fbd] ext3_setattr+0x17e/0x1d8
[ext3]
Apr 18 05:44:54 int-backup kernel: [c016ffd8] notify_change+0x12d/0x2c1
Apr 18 05:44:54 int-backup kernel: [d0bafb28] nfsd_setattr+0x329/0x49d
[nfsd]
Apr 18 05:44:54 int-backup kernel: [d0bb5524]
nfsd3_proc_setattr+0x7c/0x85 [nfsd]
Apr 18 05:44:54 int-backup kernel: [d0bac0cb] nfsd_dispatch+0xbb/0x170
[nfsd]
Apr 18 05:44:54 int-backup kernel: [d0b5d4c9] svc_process+0x3b9/0x614
[sunrpc]Apr 18 05:44:54 int-backup kernel: [d0bac5c5] nfsd+0x1ab/0x30a
[nfsd]
Apr 18 05:44:54 int-backup kernel: [d0bac41a] 

Bug#419222: [Pkg-openldap-devel]

[Gyuris Szabolcs]

Hi Quanah!

I'm again :(

Gyuris Szabolcs wrote:
 If things freeze again, can you please get the output of:

 db_stat -h /var/lib/ldap -c
 I'll keep an eye on it.

Now it goes weirded :(

Today the symptoms was:

 - suddenly I can't found a user with the command id 'No such user'
 - if I exec ldapsearch like in ldap.conf, with the same filter settings
then I got a hit
 - after a while I go with my gq tool to see what my ldap database
look like but the database didn't have an initial dc record - according
to gq :(
 - I'd run ldapsearch next and it found only one record - before that
and after I realized that there is something wrong there was many records.

I can't find the program db_stat but I copied the faulty database
files so I could run the db_stat any time.

That's not all...
After all I rebooted the virtual machine and set the mem limit to 256MB...

After I started the machine I run ldapsearch - I didn't do anything with
slapd - and there was a fragment of entrys (about 17, the full database
now is about ~220 entry). So I dropped the whole db (stoped slapd and rm
all the files DB_CONFIG - excluded). I started slapd and added all the
enrtys from the master slapd (ldapadd).

I can't imagine what that could be :(
Isn't it possible that all this happens because we use the backend hdb?

Best regards...

-- 
\\///   http://linux.oregpreshaz.eu/Thawte
 O O  / http://www.oregpreshaz.eu/
/=uOO(_)OOu==~   WOT
| E-mail: szimszon az oregpreshaz pont eu
| VoIP  : szimszon a ekiga.net | pgp key id: 049BFAD8   Notary



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#419222: checkpoint set

[Gyuris Szabolcs]

Hi Quanah!

I set the checkpoint to 2048 10.

But the shutdown wasn't the problem. The problem is that after variable
time slapd won't answer to any questions. The number of threads are
growing and the system load too.

If I wait more with the restart after slapd froze then I have more
threads open. :(


Now I wait if this checkpoint would have any positive effect. :)

Thank you!


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#419222: [Pkg-openldap-devel] Bug#419222: checkpoint set

[Gyuris Szabolcs]

Quanah Gibson-Mount wrote:
 --On Monday, April 16, 2007 9:57 AM +0200 Gyuris Szabolcs
 [EMAIL PROTECTED] wrote:
 
 Hi Quanah!

 I set the checkpoint to 2048 10.

 But the shutdown wasn't the problem. The problem is that after variable
 time slapd won't answer to any questions. The number of threads are
 growing and the system load too.
 
 Ah, okay.  I misread it as a being a problem with slapd at shutdown time.
Sorry it's my poor English :(

 First, do you have a DB_CONFIG file in /var/lib/ldap that has been
-- DB_CONFIG --
set_cachesize 0 2097152 0
set_lk_max_objects 1500
set_lk_max_locks 1500
set_lk_max_lockers 1500
-- DB_CONFIG --
It's the debian default.

 properly tuned for your database?  If not, if you could send the output
 of `cat /var/lib/ldap/DB_CONFIG` and `du -h id2entry.bdb`
-- DU --
772Kid2entry.bdb
-- DU --

 Second, how many CPU's does your system have?
1 CPU and it's a vmware-server guest OS.

 Third, what is the total amount of RAM on your system?

cat /proc/meminfo:
MemTotal:   127032 kB
MemFree:  3304 kB
Buffers:  1900 kB
Cached:  17492 kB
SwapCached:  80368 kB
Active: 102400 kB
Inactive: 8784 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   127032 kB
LowFree:  3304 kB
SwapTotal:  579592 kB
SwapFree:   302952 kB
Dirty: 100 kB
Writeback:   0 kB
AnonPages:   88344 kB
Mapped:  13676 kB
Slab: 8172 kB
PageTables:   1564 kB
NFS_Unstable:0 kB
Bounce:  0 kB
CommitLimit:643108 kB
Committed_AS:   695280 kB
VmallocTotal:   901112 kB
VmallocUsed:  2556 kB
VmallocChunk:   898056 kB


It's not much. I'm going to set 256MB Ram, after the next reboot.

-- 
\\///   http://linux.oregpreshaz.eu/Thawte
 O O  / http://www.oregpreshaz.eu/
/=uOO(_)OOu==~   WOT
| E-mail: szimszon az oregpreshaz pont eu
| VoIP  : szimszon a ekiga.net | pgp key id: 049BFAD8   Notary



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#419222: [Pkg-openldap-devel]

[Gyuris Szabolcs]

Quanah Gibson-Mount wrote:
 
 
 --On Monday, April 16, 2007 6:54 PM +0200 Gyuris Szabolcs
 [EMAIL PROTECTED] wrote:
 
 Quanah Gibson-Mount wrote:
 --On Monday, April 16, 2007 9:57 AM +0200 Gyuris Szabolcs
 [EMAIL PROTECTED] wrote:
 
 Okay, definitely add threads 8 to the global section of slapd.conf. 
 The default number of threads for slapd is 16, which is substantially
 past the mark for most systems, and has a rather negative impact.
I have set it.


 Third, what is the total amount of RAM on your system?

 cat /proc/meminfo:
 MemTotal:   127032 kB
 
 Well, 128MB should be okay if slapd's BDB cache is only 2MB.
 
 Another setting you should likely set would be the cachesize, in the
 database specific area of slapd.conf.  Given that your total number of
 entries is small, I'd set it to that number (for example, cachesize
 1000 for a 1000 entry DB).
Done.

 If things freeze again, can you please get the output of:
 
 db_stat -h /var/lib/ldap -c
I'll keep an eye on it.

Thank you!


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#419222: slapd.conf

[Gyuris Szabolcs]

Hi Quanah!

Here it is the slapd.conf.

But I think the large number of threads is because after the slapd froze
then all connected client froze too. :(

Thank you!
# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.

###
# Global Directives:

# Features to permit
allow bind_v2

# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema

include /etc/ldap/schema/integrity/common.schema
include /etc/ldap/schema/integrity/ftp.schema
include /etc/ldap/schema/integrity/web.schema
include /etc/ldap/schema/integrity/mail.schema
include /etc/ldap/schema/integrity/nagios.schema
include /etc/ldap/schema/integrity/software_data.schema

# Schema check allows for forcing entries to
# match schemas for their objectClasses's
schemacheck on

# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid

# List of arguments that were passed to the server
argsfile/var/run/slapd/slapd.args

# Read slapd.conf(5) for possible values
loglevel256

# Where the dynamically loaded modules are stored
modulepath  /usr/lib/ldap
moduleload  back_hdb

TLSCACertificateFile /etc/ldap/integrity-ca.pem
TLSCertificateFile  /etc/ldap/ldap.pem
TLSCertificateKeyFile /etc/ldap/ldap.pem
TLSVerifyClient never

###
# Specific Backend Directives for bdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend hdb

###
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backendother

###
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
databasehdb


# The base of your directory in database #1
suffix  dc=domain,dc=tld

# Where the database file are physically stored for database #1
directory   /var/lib/ldap

# Indexing options for database #1
index   objectClass eq
index   apacheServerName pres,eq
index   apacheServerAlias pres,eq
index   uid pres,eq
index   userClass,uidNumber,gidNumber,cn eq
index   memberUid   eq
#index  uniqueMember eq,pres
#index  memberUid,employeeType,mail pres,eq,approx,sub

# Save the time that the entry gets modified, for database #1
lastmod on

# Where to store the replica logs for database #1
replogfile  /var/lib/ldap/replog


rootdn  cn=admin,dc=domain,dc=tld
rootpw  password

#replica
updatedn cn=admin,dc=domain,dc=tld

# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only

access to dn.regex=.*ou=virtualFtp,dc=domain,dc=tld attrs=userPassword
by dn=cn=admin,dc=domain,dc=tld write
by dn=cn=stadmin,dc=domain,dc=tld write
by dn=uid=user1,ou=People,dc=domain,dc=tld write
by dn=uid=user2,ou=People,dc=domain,dc=tld write
by dn=uid=user3,ou=People,dc=domain,dc=tld write
by dn=uid=user4,ou=People,dc=domain,dc=tld write
by anonymous auth
by self write
by * none
access to dn.regex=.*ou=virtualWeb,dc=domain,dc=tld attrs=userPassword
by dn=cn=admin,dc=domain,dc=tld write
by dn=cn=stadmin,dc=domain,dc=tld write
by dn=uid=user1,ou=People,dc=domain,dc=tld write
by dn=uid=user2,ou=People,dc=domain,dc=tld write
by dn=uid=user3,ou=People,dc=domain,dc=tld write
by dn=uid=user4,ou=People,dc=domain,dc=tld write
by anonymous auth
by self write
by * none

access to attrs=operation
by dn=cn=operator,dc=domain,dc=tld write
by dn=cn=admin,dc=domain,dc=tld write
by dn=cn=stadmin,dc=domain,dc=tld write
by dn=uid=user1,ou=People,dc=domain,dc=tld write
by dn=uid=user2,ou=People,dc=domain,dc=tld write
by dn=uid=user3,ou=People,dc=domain,dc=tld write
by dn=uid=user4,ou=People,dc=domain,dc=tld write
by anonymous auth
by self write
by * read

access to attrs=modified
by dn=cn=operator,dc=domain,dc=tld write
by dn=cn=admin,dc=domain,dc=tld write
by dn=cn=stadmin,dc=domain,dc=tld write
by dn=uid=user1,ou=People,dc=domain,dc=tld write
by 

Bug#419222: after a while slapd hangs

[Gyuris Szabolcs]

Package: slapd
Version: 2.3.30-5
Severity: important

I use slapd in production environment with 167 entrys.
The running environment is in a vmware-server 1.0.1.

I use slapd with tls to authenticate users.

After some weeks, days or even hours slapd suddenly stops working. It hangs
and the servers load grows.

I use it with hdb backend.

There is a cut of the relevant log:

Apr 14 12:10:01 v-belso-1 slapd[16844]: conn=3305 fd=84 ACCEPT from 
IP=10.1.3.4:48156 (IP=0.0.0.0:636)
Apr 14 12:10:01 v-belso-1 slapd[16844]: conn=3305 fd=84 TLS established 
tls_ssf=168 ssf=168
Apr 14 12:10:01 v-belso-1 /USR/SBIN/CRON[7760]: (root) CMD 
(/usr/local/sbin/check_prg.sh)
Apr 14 12:10:31 v-belso-1 slapd[16844]: connection_input: conn=3305 deferring 
operation: binding
Apr 14 12:11:05 v-belso-1 slapd[16844]: conn=3306 fd=85 ACCEPT from 
IP=10.1.3.13:53815 (IP=0.0.0.0:636)
Apr 14 12:11:05 v-belso-1 slapd[16844]: conn=3306 fd=85 TLS established 
tls_ssf=128 ssf=128
Apr 14 12:11:51 v-belso-1 slapd[16844]: conn=3307 fd=86 ACCEPT from 
IP=127.0.0.1:3219 (IP=0.0.0.0:389)
Apr 14 12:12:00 v-belso-1 slapd[16844]: conn=3308 fd=87 ACCEPT from 
IP=10.1.3.4:48158 (IP=0.0.0.0:636)
Apr 14 12:12:00 v-belso-1 slapd[16844]: conn=3308 fd=87 TLS established 
tls_ssf=168 ssf=168

/etc/init.d/slapd stop:
Apr 14 12:12:03 v-belso-1 slapd[16844]: daemon: shutdown requested and 
initiated.
Apr 14 12:12:03 v-belso-1 slapd[16844]: conn=6 fd=14 closed (slapd shutdown)
Apr 14 12:12:03 v-belso-1 slapd[16844]: conn=7 fd=20 closed (slapd shutdown)
Apr 14 12:12:03 v-belso-1 slapd[16844]: conn=854 fd=21 closed (slapd shutdown)
Apr 14 12:12:03 v-belso-1 slapd[16844]: conn=2548 fd=25 closed (slapd shutdown)
Apr 14 12:12:03 v-belso-1 slapd[16844]: conn=3130 fd=26 closed (slapd shutdown)
Apr 14 12:12:03 v-belso-1 slapd[16844]: conn=3133 fd=28 closed (slapd shutdown)
Apr 14 12:12:03 v-belso-1 slapd[16844]: conn=374 fd=34 closed (slapd shutdown)
Apr 14 12:12:03 v-belso-1 slapd[16844]: conn=966 fd=36 closed (slapd shutdown)
Apr 14 12:12:03 v-belso-1 slapd[16844]: slapd shutdown: waiting for 89 threads 
to terminate

/etc/init.d/slapd start:
Apr 14 12:12:13 v-belso-1 slapd[8026]: @(#) $OpenLDAP: slapd 2.3.30 (Mar  9 
2007 05:43:02) $[EMAIL 
PROTECTED]:/tmp/buildd/openldap2.3-2.3.30/debian/build/servers/slapd
Apr 14 12:12:13 v-belso-1 slapd[8026]: /etc/ldap/slapd.conf: line 122: rootdn 
is always granted unlimited privileges.
Apr 14 12:12:13 v-belso-1 slapd[8026]: /etc/ldap/slapd.conf: line 133: rootdn 
is always granted unlimited privileges.
Apr 14 12:12:13 v-belso-1 slapd[8026]: /etc/ldap/slapd.conf: line 144: rootdn 
is always granted unlimited privileges.
Apr 14 12:12:13 v-belso-1 slapd[8026]: /etc/ldap/slapd.conf: line 156: rootdn 
is always granted unlimited privileges.
Apr 14 12:12:13 v-belso-1 slapd[8026]: /etc/ldap/slapd.conf: line 168: rootdn 
is always granted unlimited privileges.
Apr 14 12:12:13 v-belso-1 slapd[8026]: /etc/ldap/slapd.conf: line 179: rootdn 
is always granted unlimited privileges.
Apr 14 12:12:13 v-belso-1 slapd[8027]: bdb_db_open: unclean shutdown detected; 
attempting recovery.
Apr 14 12:12:14 v-belso-1 slapd[8027]: slapd starting
Apr 14 12:12:15 v-belso-1 slapd[8027]: conn=0 fd=14 ACCEPT from 
IP=127.0.0.1:3220 (IP=0.0.0.0:389)
Apr 14 12:12:15 v-belso-1 slapd[8027]: conn=0 op=0 BIND dn= method=128
Apr 14 12:12:15 v-belso-1 slapd[8027]: conn=0 op=0 RESULT tag=97 err=0 text=
Apr 14 12:12:15 v-belso-1 slapd[8027]: conn=0 op=1 SRCH base= scope=2 deref=0
filter=(objectClass=*)
Apr 14 12:12:15 v-belso-1 slapd[8027]: conn=0 op=1 SEARCH RESULT tag=101 err=32
nentries=0 text=
Apr 14 12:12:15 v-belso-1 slapd[8027]: conn=0 op=2 UNBIND
Apr 14 12:12:15 v-belso-1 slapd[8027]: conn=0 fd=14 closed
Apr 14 12:12:28 v-belso-1 slapd[8027]: conn=1 fd=14 ACCEPT from 
IP=127.0.0.1:1337 (IP=0.0.0.0:636)
Apr 14 12:12:28 v-belso-1 slapd[8027]: conn=1 fd=14 TLS established tls_ssf=256
ssf=256
Apr 14 12:12:28 v-belso-1 slapd[8027]: conn=1 op=0 BIND dn= method=128

Once it caused a db corruption.

-- 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-3-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages slapd depends on:
ii  adduser   3.102  Add and remove users and groups
ii  coreutils 5.97-5.3   The GNU core utilities
ii  debconf [debconf-2.0] 1.5.11 Debian configuration management sy
ii  libc6 2.3.6.ds1-13   GNU C Library: Shared libraries
ii  libdb4.2  4.2.52+dfsg-2  Berkeley v4.2 Database Libraries [
ii  libiodbc2 3.52.4-5   iODBC Driver Manager
ii  libldap-2.3-0 2.3.30-5   OpenLDAP libraries
ii  libltdl3  1.5.22-4   A system independent dlopen wrappe
ii  libperl5.85.8.8-7Shared Perl library
ii  libsasl2-2

Bug#415670: I had the same problem

[Gyuris Szabolcs]

I had also the same problem.
So I had to downgrade too.

I use tls sasl with ldap...

postconf:
attached

With 2.3.7-3 works perfect.


-- 
\\///   http://linux.oregpreshaz.eu/Thawte
 O O  / http://www.oregpreshaz.eu/
/=uOO(_)OOu==~   WOT
| E-mail: szimszon a gmail-nel pont com
| VoIP  : szimszon a ekiga.net | pgp key id: 049BFAD8   Notary


2bounce_notice_recipient = postmaster
access_map_reject_code = 554
address_verify_default_transport = $default_transport
address_verify_local_transport = $local_transport
address_verify_map = 
address_verify_negative_cache = yes
address_verify_negative_expire_time = 3d
address_verify_negative_refresh_time = 3h
address_verify_poll_count = 3
address_verify_poll_delay = 3s
address_verify_positive_expire_time = 31d
address_verify_positive_refresh_time = 7d
address_verify_relay_transport = $relay_transport
address_verify_relayhost = $relayhost
address_verify_sender = postmaster
address_verify_sender_dependent_relayhost_maps = 
$sender_dependent_relayhost_maps
address_verify_service_name = verify
address_verify_transport_maps = $transport_maps
address_verify_virtual_transport = $virtual_transport
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_mail_to_commands = alias, forward
allow_mail_to_files = alias, forward
allow_min_user = no
allow_percent_hack = yes
allow_untrusted_routing = no
alternate_config_directories = 
always_bcc = 
anvil_rate_time_unit = 60s
anvil_status_update_time = 600s
append_at_myorigin = yes
append_dot_mydomain = no
application_event_drain_time = 100s
authorized_flush_users = static:anyone
authorized_mailq_users = static:anyone
authorized_submit_users = static:anyone
backwards_bounce_logfile_compatibility = yes
berkeley_db_create_buffer_size = 16777216
berkeley_db_read_buffer_size = 131072
best_mx_transport = 
biff = no
body_checks = 
body_checks_size_limit = 51200
bounce_notice_recipient = postmaster
bounce_queue_lifetime = 5d
bounce_service_name = bounce
bounce_size_limit = 5
bounce_template_file = 
broken_sasl_auth_clients = yes
canonical_classes = envelope_sender, envelope_recipient, header_sender, 
header_recipient
canonical_maps = 
cleanup_service_name = cleanup
command_directory = /usr/sbin
command_execution_directory = 
command_expansion_filter = [EMAIL 
PROTECTED]:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
command_time_limit = 1000s
config_directory = /etc/postfix
connection_cache_protocol_timeout = 5s
connection_cache_service_name = scache
connection_cache_status_update_time = 600s
connection_cache_ttl_limit = 2s
content_filter = scan:127.0.0.1:10026
daemon_directory = /usr/lib/postfix
daemon_timeout = 18000s
debug_peer_level = 2
debug_peer_list = 
default_database_type = hash
default_delivery_slot_cost = 5
default_delivery_slot_discount = 50
default_delivery_slot_loan = 3
default_destination_concurrency_limit = 20
default_destination_recipient_limit = 50
default_extra_recipient_limit = 1000
default_minimum_delivery_slots = 3
default_privs = nobody
default_process_limit = 100
default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what] 
blocked using $rbl_domain${rbl_reason?; $rbl_reason}
default_recipient_limit = 1
default_transport = smtp
default_verp_delimiters = +=
defer_code = 450
defer_service_name = defer
defer_transports = 
delay_logging_resolution_limit = 2
delay_notice_recipient = postmaster
delay_warning_time = 0h
deliver_lock_attempts = 20
deliver_lock_delay = 1s
disable_dns_lookups = no
disable_mime_input_processing = no
disable_mime_output_conversion = no
disable_verp_bounces = no
disable_vrfy_command = yes
dont_remove = 0
double_bounce_sender = double-bounce
duplicate_filter_limit = 1000
empty_address_recipient = MAILER-DAEMON
enable_original_recipient = yes
error_notice_recipient = postmaster
error_service_name = error
execution_directory_expansion_filter = [EMAIL 
PROTECTED]:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
expand_owner_alias = no
export_environment = TZ MAIL_CONFIG LANG
fallback_transport = 
fallback_transport_maps = 
fast_flush_domains = $relay_domains
fast_flush_purge_time = 7d
fast_flush_refresh_time = 12h
fault_injection_code = 0
flush_service_name = flush
fork_attempts = 5
fork_delay = 1s
forward_expansion_filter = [EMAIL 
PROTECTED]:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
forward_path = $home/.forward${recipient_delimiter}${extension}, $home/.forward
frozen_delivered_to = yes
hash_queue_depth = 1
hash_queue_names = deferred, defer
header_address_token_limit = 10240
header_checks = regexp:/etc/postfix/header_checks.cf
header_size_limit = 102400
helpful_warnings = yes
home_mailbox = 
hopcount_limit = 50
html_directory = no
ignore_mx_lookup_error = no
import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ XAUTHORITY DISPLAY 
LANG=C
in_flow_delay = 1s
inet_interfaces = all
inet_protocols = ipv4
initial_destination_concurrency = 5
internal_mail_filter_classes = 

Bug#397364: [ntfs-3g-devel] ntfs-3g-0.20070116-BETA

[Szakacsits Szabolcs]

On Wed, 17 Jan 2007 [EMAIL PROTECTED] wrote:

  This effects many other distributions and people often ask what's happening.
  Adam Cecile, Mertens Florent and me offered to help the Debian maintainer,
  and Flo sent an LSB compliant FUSE init file but the maintainer doesn't
  reply repeated emails for some reason for about a month, so the FUSE upgrade
  process stuck unfortunately.
  
  I think the solution could be to have a FUSE Debian co-maintainer.
 
 Some fresh news on this issue. It seams that a new fuse package is
 nearly ready in debian :
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404240
 
 I talked to Bartosz Fenski (fuse package) and his fuse 2.6 package is
 nearly ready. He hopes he will be able to upload during this week.
 
 I will upload update ntfs-3g asap.
 
 Regards, Adam.

Any FUSE development? Debian users are submitting old problems which were
solved months ago ...

Szaka



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#406956: Quick and dirty workaround

[Gyuris Szabolcs]

Edit the /usr/lib/python2.4/site-packages/MySQLdb/cursors.py file at the
 line 146:
-query = query.encode(charset)
+#query = query.encode(charset)

I don't know what could it break, so handle with care.



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#397364: ntfs-3g-0.20070116-BETA

[Szakacsits Szabolcs]

Hi,

On Tue, 16 Jan 2007, [EMAIL PROTECTED] wrote:

 It was a good idea to support older fuse kernel modules, but it still
 requires new fuse user space tools to compile. Is it possible to
 compile/use with fuse 2.5.3 too? Currently there is a check for 2.6.0+
 in the configure script.

Correct. FUSE 2.6 user space is backward comaptible and upgrades went
smoothly for distros. Except for Debian because the optionally provided 
FUSE init script isn't LSB compliant.

This effects many other distributions and people often ask what's happening.
Adam Cecile, Mertens Florent and me offered to help the Debian maintainer,
and Flo sent an LSB compliant FUSE init file but the maintainer doesn't
reply repeated emails for some reason for about a month, so the FUSE upgrade
process stuck unfortunately.

I think the solution could be to have a FUSE Debian co-maintainer.

Regards,
Szaka



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#406956: python-mysqldb: Python crash if the query result has unicode characters

[Szabolcs Gyuris]

Package: python-mysqldb
Version: 1.2.1-p2-4
Severity: important


I got the following error message:

File /usr/lib/python2.4/site-packages/MySQLdb/cursors.py, line 146, in 
execute
query = query.encode(charset)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 81: 
ordinal not in range(128)

I have searched the web for a solution:

http://forums.mysql.com/read.php?50,123051,123051
http://forums.devshed.com/python-programming-11/help-mysqldb-module-chokes-on-unicode-data-396943.html

It seems to me that I have to upgrade the package to the latest 
version :(


-- 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.19.moria
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages python-mysqldb depends on:
ii  libc62.3.6.ds1-8 GNU C Library: Shared libraries
ii  libmysqlclient15off  5.0.30-3mysql database client library
ii  python   2.4.4-2 An interactive high-level object-o
ii  python-central   0.5.12  register and build utility for Pyt
ii  zlib1g   1:1.2.3-13  compression library - runtime

python-mysqldb recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Sun, 3 Dec 2006, David [iso-8859-15] Martínez Moreno wrote:
 El domingo, 3 de diciembre de 2006 11:36, Anton Altaparmakov escribió:
 Thank you very much, guys.  What should we do know, apply the two-line
   patch from Szaka to 1.13.1, wait for 1.14, backport any other change...?
 
  Entirely up to you.  If you want it immediately it is easiest if you apply
  the two-line patch from Szaka now and make your release and then when the
  next ntfsprogs release is done (it will be 2.0 not 1.14 btw) then you can
  release that.
 
  Sound good?
 
   Like a charm. :-)

Sorry I didn't explain myself better. My patch was only for Vista. 

I'm paranoidly careful with changes and would like to know the exact 
side-effects on the bit level on the entire volume for all non-Vista 
Microsoft NTFS drivers (there are quite many!). But I don't have the 
resources for that (hardware, OS, time, etc). So I'll make a surely safe 
patch asap.

Of course anybody is welcome to do it earlier based on what I suggested 
previously. It's not difficult (detect Vista and don't use the 
VOLUME_MOUNTED_ON_NT4 flag).

Btw, there are other reliability problems with the current ntfsprogs, I'll 
write about them later.

   As you probably know, we want to release Debian etch by the end of 
 the year, and this bug was a showstopper.  I will release a patched 
 1.13.1 then (no big changes).

This is an __EXTREMELY__ urgent issue. Each day costs probably at least 
hundreds of trashed Vista. People won't migrate immediately, it will take 
many years. Anytime somebody use their old, trusted ntfs resizing solution 
with vista (gparted, qtparted, diskdrake, partition logic, older Linux 
installers, etc, etc) they will be in trouble.

The same happened when the HDIO_GETGEO ioctl semantic has changed 4 years 
ago in the kernel and Parted (which is used by almost all partitioners) 
started to trash Windows partition tables which is still not fully fixed 
today.

Thankfully Vista includes a resizer and it's easy to understand this 
problem. But we also must make a well articulated solution for unbootable 
Vista and spread these info and warning as quickly as possible. 

Szaka

Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Sun, 3 Dec 2006, Anton Altaparmakov wrote:
 On Sun, 3 Dec 2006, Szakacsits Szabolcs wrote:
  
  Sorry I didn't explain myself better. My patch was only for Vista. 
 
 Disagree.  Your patch is fine for all NTFS volumes.  There is no need to 
 set the mounted on NT4 bit on any volume during what NTFS resize does.  It 
 does not do anything that would be analogous to an NT4 operation.  I have 
 no idea why you ever set the flag.  As far as I am concerned setting that 
 flag at all is an outright bug in NTFS resize.

Ntfsresize works based on the volume version but unconditionally sets 
VOLUME_MOUNTED_ON_NT4 to make chkdsk believe and fix potentially missed 
V3.x modifications. 

I'm not aware of such problem but that doesn't mean there can't be any. 
So you may or may not be right but me being over paranoid about reliability 
I stick to the latter for now. Though an explicit and official guarantee 
from Microsoft could change my standpoint.

Szaka


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

Hi Andree,

On Sun, 3 Dec 2006, Andree Leidenfrost wrote:

 I've tested and all looks well! When booting into Vista after a resize,
 chkdsk is started and after another reboot the system starts as usual.
 You are a star

Thanks for the testing but I object the last sentence because I think this 
was quite a team work ;-)

Cheers,
Szaka


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Sat, 2 Dec 2006, Szakacsits Szabolcs wrote:

 Apparently Vista refuses to boot if an NTFS volume was mounted on 
 NT4 earlier. This is also what ntfsresize lied to trick Windows 
 to be compatible with itself. 
 
 Could you please try the below patch against ntfsprogs 1.13.1 that the 
 theory is correct? Thank you.

I put a statically linked version here to ease the testing.

http://www.ntfs-3g.org/ntfsresize-1.13.1.1.tgz

Thanks,
Szaka

 --- ntfsprogs/ntfsresize.c.orig 2006-04-19 00:03:09.0 +0200
 +++ ntfsprogs/ntfsresize.c  2006-12-02 00:09:44.058395088 +0200
 @@ -2289,8 +2289,6 @@
 u16 flags;
 
 flags = vol-flags | VOLUME_IS_DIRTY;
 -   if (vol-major_ver = 2)
 -   flags |= VOLUME_MOUNTED_ON_NT4;
 
 printf(Schedule chkdsk for NTFS consistency check at Windows 
 boot time ...\n);
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

 El sábado, 2 de diciembre de 2006 20:44, Frans Pop escribió:
  On Saturday 02 December 2006 14:36, Szakacsits Szabolcs wrote:
  
   I put a statically linked version here to ease the testing.
http://www.ntfs-3g.org/ntfsresize-1.13.1.1.tgz
 
  This version makes Vista happy too. After reboot chkdsk is executed and 
  on second reboot Vista boots successfully.

Thanks. So we know now the technical reason why ntfsresize didn't work 
previously. Vista deliberately refuses to mount NTFS if it thinks it was 
mounted by NT4. Though this wasn't very clear from the halt message :-)

  There is a subtle difference: with Anton's fix the progress indicator
  Vista shows during the initial stage of the boot runs much faster than
  with this fix; unsure if that is significant though.

This is pure luck, random or user entertainment. The on-disk NTFS 
filesystems are exactly the same in both cases, just the codes are 
different a bit (I noted an important difference in an earlier email: 
no modification is made to the volume in my version unless it found 
to be consistent and all sanity checks pass).

  P.S. Szakacsits and Anton:
  As you both know I've invested a _huge_ amount of time in tracing this
  issue and providing the information needed. 

I couldn't have figured out the reason without your images. Thanks!

  The first reaction was basically this can't be our bug and now that 
  it turns out it is, 

Well, things worked as expected. We say we are NT4 to chkdsk and Vista 
behaves according to the current Microsoft NT4 product support policy, that 
is, it doesn't boot.

  things run the risk of getting stuck in a kind of turf war between 
  developers.

There isn't any war here :-) Nobody knew what the problem was until you 
confirmed the NT4 related suspicion now. 

Anton was happy with the not understood fix which in fact was a bug in his 
patch which made Vista to boot by pure luck. To be honest, I've been 
working on ntfsresize alone for almost five years, and I very well know how 
many things could go wrong easily if no special attention is taken. I've 
never released a version which wasn't fully understood and very well 
tested. So I'm strongly against any not understood fixes (which actually 
indeed turned out to be a bug during Anton's changes).

The current Vista fixes (either one) could mean that maybe all non-Vista 
(XP, W2K, W2K3) stop booting now or corrupt NTFS. I don't think so but I've 
never tried and investigated it either. 

Probably the safest way is doing what we did previously and use the fix 
only with Vista. Ntfs-3g works fine with Vista, so since we can boot now 
thus I don't think there would be any other unexpected problem.

  I do appreciate all the help you both have provided, but I'd also really
  appreciate if you'd make the effort to settle your differences and
  release a fixed version.

Anton makes the choice for ntfsprogs. I've left the linux-ntfs project a 
few days ago, and continue working only on ntfs-3g till there is interest.

But I'll make a fix for ntfsprogs-1.13.1, as soon as my time allows 
(probably not more than a few days). It might be even part of ntfs-3g in 
the future (online, offline resizing, defrag, etc). But these would be very 
low priorities till the full write support is finished (only a couple of 
decades left, if I counted it correctly).

Regards,
Szaka

Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

Hi,

Apparently Vista refuses to boot if an NTFS volume was mounted on 
NT4 earlier. This is also what ntfsresize lied to trick Windows 
to be compatible with itself. 

Could you please try the below patch against ntfsprogs 1.13.1 that the 
theory is correct? Thank you.

Szaka

--- ntfsprogs/ntfsresize.c.orig 2006-04-19 00:03:09.0 +0200
+++ ntfsprogs/ntfsresize.c  2006-12-02 00:09:44.058395088 +0200
@@ -2289,8 +2289,6 @@
u16 flags;

flags = vol-flags | VOLUME_IS_DIRTY;
-   if (vol-major_ver = 2)
-   flags |= VOLUME_MOUNTED_ON_NT4;

printf(Schedule chkdsk for NTFS consistency check at Windows 
boot time ...\n);


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Thu, 30 Nov 2006, Anton Altaparmakov wrote:

 Szaka wrote: pointless to empty journal if clean...
 
 It is NOT pointless to empty.  

It depends on how journaling works, on which we disagree. It's useless to 
explain the consequences if you're right because I'm obviously aware of it. 
You would have a good argument if you said that sniff and observe Windows 
reading all journal clusters during boot even if it's clean which means 
quite probably that it also analyzes it.

Anyway, ntfsresize always unconditionally emptied the journal. So what did 
you do which made Vista booting? It's either incorrect journal checking on 
Vista or a side-effect of your changes.

Szaka


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Thu, 30 Nov 2006, Anton Altaparmakov wrote:

 I read the code and it does it.  I do not believe in sniffing as you put 
 it.  That is useless as you never know what/why the software is doing 
 something.  The code itself shows exactly what happens.  I prefer to stick 
 with that.

I prefer understanding the code, testing the understanding is correct, and
getting continuous user confirmations that both of the previous are indeed
right.
 
  Anyway, ntfsresize always unconditionally emptied the journal. So what did 
  you do which made Vista booting? It's either incorrect journal checking on 
  Vista or a side-effect of your changes.
 
 I did two things to libntfs:
   - make the journal be emptied at mount time and 
   - set the dirty bit at mount time.
 Then at umount time:
   - clear the dirty bit again unless the volume was dirty when it 
 was mounted.
 
 I then did these things to ntfsresize:
   - remove the journal emptying from ntfsresize as it is done by 
 libntfs now at mount time,
   - remove the setting dirty of volume as that is also done at mount 
 time;

In other words, they were moved to libntfs. No real change here.

   - make ntfsresize unmount the volume if one aborts which will 
 clear the dirty bit again if the volume was not dirty to start with; and 
 finally,
   - disable the unmount in ntfsresize once it is going to start 
 resizing ntfs as you said that unmounting at that point becomes dangerous.

This also has no effect during a successful resize process.

 This fixes ntfsresize on Vista for me.

You didn't answer how the journal looks after running ntfsresize without
your changes. That is, the non-empty journal file detection indeed works on
Vista.

I'd like to emphasize that your change is very dangerous. You did something
which is not understood at all. Perhaps Vista can boot now in your case, but
it's also possible that it will cause serious problems in other scenarios.

Szaka



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Thu, 30 Nov 2006, Anton Altaparmakov wrote:

 I have not the faintest idea what was wrong before. [...] to my surprise
 it now made Vista work.  Why - no idea, and I could not care less.

So, you have no idea of

- what was wrong before
- why ntfsresize works on your Vista now
- internal knowledge of ntfsresize
- what are the impacts of your change

but you would still make a new stable release. For me, these aren't very
solid and convincing technically at all.

My plan was to make an urgent release which would have included only the
denial of the Vista NTFS resizing, based on what I've suggested earlier.
Then there would have been enough time to investigate what's going on when
Vista becomes publicly available.

But this is your project, and of course you can do whatever you want.
Recently you messed up ntfsclone and now ntfsresize. Nothing I could do
about these, unfortunately. The responsibility is yours from now because
obviously I can't support code I disagree with and even you don't understand
why it works.

Szaka



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Thu, 30 Nov 2006, Anton Altaparmakov wrote:
 
 I understand the impact 100% which is why my patch is so big.  It had to 
 touch a lot of utilities to adapt for the changed libntfs behaviour.

The impact to resizing any kind of NTFS. There are many special cases and
ntfsresize works quite differently as you believe. It has its own attribute
resizer, cluster allocator, modifies mft records and not inodes, has strict
ordering of the modifications, etc.

You don't know what you fixed and how fixed. Still you think it doesn't have
any side-effects anywhere because it seems it workes a few times. And you
simply ignore all the cases which did work beforehand.

 How would you tell if it is a Vista partition or not?  

Detect Vista specific files which are always present.

 How do you know that the partition you are resizing is not going to be
 attached to a Vista machine next?  

I think it would work fine. The problem is with Vista volumes, not random
volumes attached to Vista.

 You just can't cope with the idea that someone touches code you have
 written...

I asked very simple technical questions from you:

   - How the journal looks on Vista after resizing without your patch?

   - What did you fix?

The first would have taken about 1-2 minutes from you. I even showed how 
you can do this. You keep it ignoring. Only you have Vista, unfortunately 
I don't. You also don't know what in fact you have fixed.

I'm only interested in the technical explanation but that's not coming.  
Only works for me which I can't consider responsible software engineering,
especially considering that how many people are using the software. Sorry.

Regards,
Szaka



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
 On Tue, 28 Nov 2006, Szakacsits Szabolcs wrote:

  I didn't have time to check the patches yet but wasn't the Vista problem due
  to a bug in libntfs and not because of ntfsresize?

 The problem is that with my first patch which does not turn on unmounting 
 you end up with an ntfsresize that is horrible:

Another ntfsresize design rule was that it doesn't make __ANY__ 
modification to NTFS until it checked and analyzed the volume and it found 
to be consistent and safe for resizing. This is very important. It's even 
explicitely written in the error messages when corrupt volumes are detected 
which happen relatively often:

  NTFS is inconsistent. Run chkdsk /f on Windows then reboot it TWICE!
  The usage of the /f parameter is very IMPORTANT! No modification was
  and will be made to NTFS by this software until it gets repaired.

A lot of softwares, drivers corrupt NTFS and this is a very strong 
argument for self-protection that it was not ntfsresize which corrupted it 
because it was already damaged when user wanted to do the resizing.

 Please take the time to review the patches...

Surely I would but I don't have much free time recently, and unfortunately 
it doesn't help that seemingly you have checked in your entire private 
ntfsprogs CVS in one commmit.

To be honest, I still can't even see what the problem was. You wrote the 
journal wasn't emptied. But ntfsresize explicitely does that. Which 
function became conditional. And perhaps the problem is that that the clean 
journal detection is broken for Vista. For example, because of journal 
format change.

I have checked the ntfsresize journal reset again, without your latest 
patches. After the resize:

  ntfscat -fi 2 /dev/hda1 | hexdump
    ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  *
  02a04000

So, the journal has been reset, entirely. You say that this is not the case 
for Vista? 

Szaka



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
 
 Thank you for persisting with this.  

Yes, thank you Frans and Andree for your help. We definitely found 
something.

 I have now looked at the code and you are right it does not do the same 
 thing.  This is because when Yura ported my $LogFile code from the kernel 
 for some unknown to me (or forgotten by me) reason he did not integrate 
 clearing the journal into the mount process.  He integrated the checking 
 but not the clearing.  This is a HUGE and VERY BAD bug in libntfs and 
 means that all ntfs utilities are _DANGEROUS_ to run and can cause 
 massive and very hard to detect data corruption.  )-:

If the journal is not clean then the mount is refused. This detection was 
added later, previously the journal cleaning was unconditional because we 
didn't know if it's clean or not.

So, I don't see a big problem here. The reliability of ntfsresize and 
ntfs-3g seems to confirm this. Nobody reported corruptions, in fact, people 
are finding bad hardwares (RAM, disk, cable) and softwares during usage and 
testing. Almost like ZFS :-)))

 No wonder Vista does not boot!!!  

I still wonder why it doesn't boot. As I explained in my previous email, 
ntfsresize resets the journal unless the empty journal detection fails.

 It is amazing it took so long to find this problem.  I cannot believe we 
 managed to get away with it for so long...

For me it seems it worked as it should have. If the journal is clean, 
then theoretically it's pointless to empty. If unclean then mount is 
unconditionally refused.

Szaka


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Tue, 28 Nov 2006, Anton Altaparmakov wrote:

 Ok, I just committed some more fixes to ntfsresize.  It never actually
 unmounted the volume, just exited which was very rude of it!

It's intentionally not umounted. Ntfsresize __rewrites__ NTFS and it's
dangerous to umount because that could interfer, corrupt or destroy the
resized, consistent NTFS.

Szaka



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Tue, 28 Nov 2006, Anton Altaparmakov wrote:

  It's intentionally not umounted. Ntfsresize __rewrites__ NTFS and it's
  dangerous to umount because that could interfer, corrupt or destroy the
  resized, consistent NTFS.
 
 Do you not keep the ntfs_volume of the mount consistent with your
 changes?  If yes you should umount and it is not dangerous.  If not why
 not?

There are two NTFS during resizing. The original and the resized. When 
the resizing is over then the latter is consistent and the old one is
irrelevant. ntfsresize doesn't work like the other utilities: mount, modify,
umount. It works like: mount and morph the original into a new one.

Szaka



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
 On Tue, 2006-11-28 at 13:08 +0100, Szakacsits Szabolcs wrote:
  
  There are two NTFS during resizing. The original and the resized. When 
  the resizing is over then the latter is consistent and the old one is
  irrelevant. ntfsresize doesn't work like the other utilities: mount, modify,
  umount. It works like: mount and morph the original into a new one.
[...] 
 I cannot see anywhere you having two different ntfs_volume structures.
 Apologies if I have missed it.  Perhaps you can point out the code to me
 where you have two volumes as I cannot see it...

relocate_inodes(), relocate_inode(), especially the $MFT part. There is a
strict order in what and when is relocated. At some point ntfs_volume is
mostly used only for reading and a new NTFS gets written. 

Anything must be modified before it gets relocated, never afterwards. 
Your change broke this very serious rule.

 However, given things still work, and given that ntfsresize now works
 for Vista for me when it did not do so before I would say unmounting is
 both safe and required for ntfsresize.  (-;

There is a huge difference between the works for me and always works.

Szaka



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
 On Tue, 2006-11-28 at 14:20 +0100, Szakacsits Szabolcs wrote:
  
  relocate_inodes(), relocate_inode(), especially the $MFT part. There is a
  strict order in what and when is relocated. At some point ntfs_volume is
  mostly used only for reading and a new NTFS gets written.
 
 That is not true, at least not in the code that I am reading here!  It
 may have been your intention perhaps but you failed to code it...

Then it wouldn't have worked. 

 relocate_inodes() - relocate_inode() - at the end of the function
 calls write_mft_record() which uses the ntfs_volume and the libntfs
 function ntfs_mft_record_write() to do the writing.

Think about relocating $MFT.
 
 After that we have truncate_badclust_file() and truncate_bitmap_file()
 both of which use write_mft_record() also...

The beginning of the $MFT is never relocated, so the MFT records belonging
to these files can be safely modified in place, otherwise resizing is
restricted to a safe size.

 Remember that what you were doing was not working for Vista and it works
 now...

I didn't have time to check the patches yet but wasn't the Vista problem due
to a bug in libntfs and not because of ntfsresize?

You seem to mix here two different problems: the missing log file reset in
libntfs and the unsafe umount you introduced by another patch to ntfsresize
because you thought that it was missing by accident.
 
 Anyway, given ntfsresize is your code, if you want to insist on not
 allowing unmounting, then can you please tell me the exact point in the
 code at which unmounting becomes dangerous/wrong 

I must think about it. The design rule was being always consistent or
trivially recoverable whenever we exit immediately without any cleanup.

  There is a huge difference between the works for me and always works.
 
 Certainly but given it was broken to start with works for me and
 never works for Vista is more like the real comparison here and the
 works for me is a big improvement...  (-;

The first patch seems to fixed Vista, the next one broke all of them in
certain scenarios.

Szaka



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Sun, 26 Nov 2006, Frans Pop wrote:
 On Sunday 26 November 2006 02:13, you wrote:
  Could you please also test that whether Vista boots if you remove
  /pagefile.sys after ntfsresize? You can use ntfs-3g for this, it's in
  Debian unstable. Usage: http://www.ntfs-3g.org/index.html#usage
  Or use a LiveCD which has both. The above page lists several of them.
 
 Used ntfs-3g for this, but Vista still refuses to boot.

Hmm. What ntfs-3g version did you use? Only the latest, ntfs-3g 0.20061115 
is fully safe regards to umounting before reboot. Do you remember if you 
umounted the partition before reboot and did a 'sync'? An unclean unmount 
could cause the problem you have seen with earlier ntfs-3g versions, though
this is absolutely not typical.

 But progress!
 
 I've managed to boot Vista using the following procedure (which I found by 
 accident when ntfs-3g complained about not being able to mount the NTFS 
 partition):
 - resize Vista partition
 - reboot into Vista (which fails at the point we all know so well by now)
   Vista marks the boot as unsuccessful (next boot it will offer the safe
   boot option, but still not run chkdsk by itself)
 - reboot into linux
 - (try mounting the partition using ntfs-3g which fails)
 - run ntfsfix
 - reboot into Vista, this will at last run chkdsk!
 - Vista reboots automatically after the chkdsk and this time successfully!
 
 So, what does ntfsfix do on a ntfs volume marked dirty by Vista that 
 ntfsresize does not?

Nothing. The volume wasn't mountable because either it wasn't cleanly 
shutdown or because Vista made some changes when you booted.

Could you please try

resize
ntfsfix
vista boot
and 
resize
mount
delete /pagefile.sys
umount 
ntfsfix
vista boot

 # ntfsfix /dev/sda1
 Mounting volume... FAILED
 Attempting to correct errors...
 Processing $FMT amd $MFTMirr...
 Reading $MFT... OK
 Reading $MFTMirr... OK
 Comparing $MFTMirr to $MFT... OK
 Processing of $MFT and $MFTMirr completed successfully.
 Setting required flags on partition... OK
 Going to empty the journal ($Logfile)... OK
 NTFS volume version is 3.1.
 NTFS partition /dev/sda1 was processed successfully.
 
 Attached 3 screenshots that show Vista's chkdsk output.

Thanks, no strange thing here.

Cheers,
Szaka


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379628: [Linux-NTFS-Dev] Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits Szabolcs]

On Sat, 25 Nov 2006, Frans Pop wrote:
 
 I've stopped after the Win2k chkdsk as that turned out to be sufficient to 
 make Vista boot again, so running the Vista repair is unnecessary!
 The md5sum check after running chkdsk showed only /pagefile.sys deleted.

Yes, there isn't really anything special except deleting /pagefile.sys
which is __highly__ unusual.

Quite probably this means that the pagefile.sys format has changed and 
Vista stores information there for faster boots. It boots like Linux 
softsuspend.

Could you please also test that whether Vista boots if you remove 
/pagefile.sys after ntfsresize? You can use ntfs-3g for this, it's in 
Debian unstable. Usage: http://www.ntfs-3g.org/index.html#usage 
Or use a LiveCD which has both. The above page lists several of them.

Thanks,
Szaka


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]