Bug#1031802: Move fuse_new_31 to FUSE_3.13?
Hi Andrea, thanks for raising my attention and thanks for the detailed analysis. Would it help to move that symbol to FUSE_3.13 in the version script (for example in libfuse-3.17?)? Thanks, Bernd
Bug#1063679: O: unionfs-fuse -- Fuse implementation of unionfs
Package: wnpp Severity: normal Dear Debian maintainers, unfortunately I don't have time anymore to maintain unionfs-fuse. There hadn't been any updates from me for the last years and I'm afraid it does not get any better. To my excuse I actually tried to upload a new version some time ago (1 or 2 years ago now), posted it to to debian mentors - no progress and I then didn't have time again either - the updated package was auto-removed from mentors.debian.net/packages/. Thanks, Bernd
Bug#778156: unionfs-fuse: ftbfs with GCC-5
Hi Brett,
I'm currently preparing a new version upload. If you should be DD and
would have some time, would you mind to upload the current version in
mentors? I'm probably going to do another to add a man page for the old
binary name 'unionfs-fuse', just pointing to 'unionfs'. And another man
page for unionfsctl.
I think we fixed the hashtable issue already in 2011, I just didn't have
time for uploads for a long time...
http://mentors.debian.net/package/unionfs-fuse
Thanks,
Bernd
On 07/15/2015 01:53 AM, Brett Johnson wrote:
tags 778156 +patch
thanks
This package has multiple (identical) definitions of two inline functions,
which was allowed in gnu89, but is no longer allowed. This kludge of a
patch removes the offending redefinitions when compiling with gcc5. Another
workaround would be to pass -std=gnu89 to the compiler, but this makes
the breakage more obvious. This really should be fixed upstream.
--- unionfs-fuse-0.24.orig/src/hashtable_itr.c
+++ unionfs-fuse-0.24/src/hashtable_itr.c
@@ -37,7 +37,7 @@ hashtable_iterator(struct hashtable *h)
/*/
/* key - return the key of the (key,value) pair at the current position
*/
/* value- return the value of the (key,value) pair at the current
position */
-
+#if !(__GNUC__==5)
void *
hashtable_iterator_key(struct hashtable_itr *i)
{ return i-e-k; }
@@ -45,6 +45,7 @@ hashtable_iterator_key(struct hashtable_
void *
hashtable_iterator_value(struct hashtable_itr *i)
{ return i-e-v; }
+#endif
/*/
/* advance - advance the iterator to the next element
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778156: unionfs-fuse: ftbfs with GCC-5
On 07/15/2015 05:28 PM, Martin Michlmayr wrote: * Bernd Schubert bernd.schub...@fastmail.fm [2015-07-15 11:06]: I'm currently preparing a new version upload. If you should be DD and would have some time, would you mind to upload the current version in mentors? I've uploaded the package. Thanks a lot Martin! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757076: unionfs-fuse: library too old, some operations may not not work, writing does not work
On 08/05/2014 08:21 AM, Frank Heckenbach wrote: Package: unionfs-fuse Version: 0.24-2.2 Justification: renders package unusable Severity: grave # mkdir 1 2 3 # unionfs-fuse 1:2 3 fuse: warning: library too old, some operations may not not work According to the dependencies it requires libfuse2 = 2.8.1. I have 2.9.0-2 installed, so how can it be too old? But indeed some operations don't work. In particular writing doesn't seem to work at all (with or without -o cow), which renders the whole thing quite useless: # touch 3/foo touch: cannot touch `3/foo': Permission denied -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (900, 'stable'), (500, 'stable-updates'), (500, 'proposed-updates') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages unionfs-fuse depends on: ii fuse 2.9.0-2+deb7u1 ii libc6 2.13-38+deb7u3 ii libfuse2 2.9.0-2+deb7u1 I have no idea so far. I'm using it myself for diskless nfs environments with the same versions and without any issues. The only difference I see is that you have i686 while I have amd64 only. The error comes from fuse_fs_new(), but I don't have time right now to check what calls that. Unless you would investigate yourself, I will try to find time for that on Friday or Saturday. Any chance you could try to re-compile to libfuse package? And if that shouldn't help to recompile unionfs-fuse? Please note that we are just on the process to relocate from Germany to France and I might not answer for several days. Thanks, Bernd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742033: Support for extended attributes causes errors on ls
On 03/18/2014 03:10 PM, Goswin von Brederlow wrote:
Package: unionfs-fuse
Version: 0.24-2.1
Severity: normal
Tags: patch upstream
Hi,
I've compiled unionfs-fuse with extended attribute support and now I'm
getting errors on ls:
ls -lh union/
ls: union/stats: No such file or directory
total 4.0K
-rw-rw-r-- 1 brederlo users4 Mar 18 14:43 foo
-r--r--r-- 1 root root 2.0K Jan 1 1970 stats
The reason is that the lgetxattr() callback doesn't handle the stats
file. This is simple to fix with the patch below.
MfG
Goswin
--
Index: unionfs-fuse-0.24/src/unionfs.c
===
--- unionfs-fuse-0.24.orig/src/unionfs.c2014-03-18 15:08:54.526796991
+0100
+++ unionfs-fuse-0.24/src/unionfs.c 2014-03-18 15:09:01.703071796 +0100
@@ -639,6 +639,10 @@
static int unionfs_getxattr(const char *path, const char *name, char *value,
size_t size) {
DBG_IN();
+ if (uopt.stats_enabled strcmp(path, STATS_FILENAME) == 0) {
+ return -ENODATA;
+ }
+
int i = find_rorw_branch(path);
if (i == -1) return -errno;
I think this is fixed upstream already, but upstream and this patch
don't make it the way I want to have it.
I hope I find some time over the weekend to test the ioctl patches I
started to work on some time ago. And with ioctl support and the new
unionfs-fuse-ctl there is no need anymore for the ugly stats hack at all.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614771: COW broken WRT directory permission handling
Hello Eduard, On 02/24/2011 09:11 AM, Eduard Bloch wrote: #include hallo.h * Bernd Schubert [Wed, Feb 23 2011, 02:14:15PM]: a) unionfs-fuse -ocow repdir=RW:/var/cache=RO testdir -ononempty chmod -R a+w testdir b) unionfs-fuse -ocow repdir=RW:/var/log=RO testdir -ononempty echo foo testdir/cups/access_log (or similar existing file in a read-only directory) sorry, can't follow you: root@fslab3 ~unionfs-fuse -ocow,nonempty repdir=RW:/var/log=RO testdir root@fslab3 ~echo foo testdir/cups/access_log If you are working as another user and the copy-from-directory/file/path is owned by root or Of course I was not working as root. And I don't think it's a pure wishlist because working with basic permissions belongs to essential functionality, IMHO. well, you write to a file owned by another user and to a file you do not have permissions to write to... Really, we have ripped out all permission code in unionfs-fuse and let fuse do the job to check permissions. In 0.25 added code to allow the user to disable fuse-default-permission handling if not running with super-user rights. However, I am simply not *absolutely* sure (yet) that will not cause a security issue and therefore it has to be specified manually. Also please compare it with in-kernel-filesystems - you cannot start those without super-user rights. If you start unionfs-fuse as root, you will not have that problem Then, one way or another it is too late for Squueze. Unionfs-fuse did not go into Squeeze, as kfreebsd is missing fuse-utils and as I simply did not have the time to try to upload a new package that removes that dependency on fuse-utils and sets it to recommended only. If there is a chance to get it into 6.01, it will be the current version with that minor change. If not and anyway, 0.25, for which I will just still need a few hours to add a simple IOCTL interface, will be released during the next weeks. So I simply will not make myself extra work for another package upload (already working again far too long this day and all the other days during the week). Besides that I'm a package maintainer only and so it always takes ages (about 6 months last year) to get someone to upload a new version for me. Cheers, Bernd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614771: COW broken WRT directory permission handling
Hello Eduard, On Wed, 23 Feb 2011 12:10 +0100, Eduard Bloch bl...@debian.org wrote: Package: unionfs-fuse Version: 0.24-2 Severity: normal Tags: upstream Hi, it's totally impossible to use the COW feature as soon as some directory with incovenient permissions comes inbetween. It simply returns permission-denied when you try to chmod/write the file therein. Test vectors: a) unionfs-fuse -ocow repdir=RW:/var/cache=RO testdir -ononempty chmod -R a+w testdir b) unionfs-fuse -ocow repdir=RW:/var/log=RO testdir -ononempty echo foo testdir/cups/access_log (or similar existing file in a read-only directory) sorry, can't follow you: root@fslab3 ~unionfs-fuse -ocow,nonempty repdir=RW:/var/log=RO testdir root@fslab3 ~echo foo testdir/cups/access_log If you are working as another user and the copy-from-directory/file/path is owned by root or another user, then you will need to wait for 0.25, which has a new flag -o relaxed_permissions for non UID=0 or GID=0 users. And it is a wish-list bug then. Cheers, Bernd -- Bernd Schubert aa...@fastmail.fm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575661: manpage-has-errors for multibyte issue on col must be skipped
Hello, could you please tell me what is the outcome of this bug report? Lintian reports for my unionfs-fuse: W: unionfs-fuse: manpage-has-errors-from-man usr/share/man/man8/unionfs-fuse.8.gz Invalid or incomplete multibyte or wide character [...] N:To test this for yourself you can use the following command: N: LANG=C MANWIDTH=80 man --warnings -E UTF-8 -l manpage-file /dev/null But be...@sid32@bathl:~/src/unionfs-fuse/debian_commit$ LANG=C MANWIDTH=80 man --warnings= -E UTF-8 -l unionfs-fuse-0.24/man/unionfs-fuse.8 /dev/null be...@sid32@bathl:~/src/unionfs-fuse/debian_commit$ So I don't see what should be wrong with that man page. Thanks, Bernd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541614: unionfs-fuse: using relative paths completely broken, again
I really sorry Raphael. All my fault. I introduced this bug and I'm also responsible for the huge delay to upload a new package. Unfortunately, I had been more than busy over the past months. While I fixed it seem, I always wanted to investigate other issues on the mailing list before uploading a new package. But now it turned out those issues on the mailing list either had been this bug here, or incorrect arguments/usage. I just uploaded a new package to mentors. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535233: updated package
Hi all, I updated the packages on my home page and also made it mostly lintian clean now. I'm going to upload it to Debian-Mentors now. Cheers, Bernd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535233: ITP: collectl -- Initial package request
Hello Christopher, On Wednesday 01 July 2009, Simmons, Christopher wrote: Package: collectl Version: 3.3.4 Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org *** Please type your report below this line *** I wish to work on creating a debian package for collectl-3.3.4 I already have a package, just didn't have the time yet to upload it. http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/collectl/ This also includes some patches from Goswin. Cheers, Bernd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517662: network-manager-kde: New version fails to connect to wlan
Package: network-manager-kde Version: 1:0.7~~svn931033-1 Severity: grave Justification: renders package unusable The new version in Sid refuses to connect to my wlan network, but gnome-network-manager works fine. The version in Lenny also did worked fine. I get these error messages on the command line: be...@bathl ~knetworkmanager knetworkmanager: WARNING: [Q_UINT32 Device::getDeviceType() const] knetworkmanager: ERROR: req name failed for org.freedesktop.NetworkManagerSettings.Connection knetworkmanager: ERROR: req name failed for org.freedesktop.NetworkManagerSettings.Connection.Secrets knetworkmanager: WARNING: [virtual void ConnectionSettings::WirelessSecurity::fromMap(const ConnectionSettings::SettingsMap)] Unknown setting: psk be...@bathl ~knetworkmanager: WARNING: [AccessPoint* WirelessDevice::getActiveAccessPoint()] No object for active access point found! knetworkmanager: WARNING: [AccessPoint* WirelessDevice::getActiveAccessPoint()] No object for active access point found! knetworkmanager: WARNING: [AccessPoint* WirelessDevice::getActiveAccessPoint()] No object for active access point found! knetworkmanager: WARNING: [AccessPoint* WirelessDevice::getActiveAccessPoint()] No object for active access point found! knetworkmanager: WARNING: [AccessPoint* WirelessDevice::getActiveAccessPoint()] No object for active access point found! knetworkmanager: WARNING: [AccessPoint* WirelessDevice::getActiveAccessPoint()] No object for active access point found! knetworkmanager: WARNING: [Q_UINT32 Device::getDeviceType() const] knetworkmanager: WARNING: [Q_UINT32 Device::getDeviceType() const] knetworkmanager: WARNING: [Q_UINT32 Device::getDeviceType() const] knetworkmanager: WARNING: [Q_UINT32 Device::getDeviceType() const] knetworkmanager: WARNING: [AccessPoint* WirelessDevice::getActiveAccessPoint()] No object for active access point found! knetworkmanager: WARNING: [AccessPoint* WirelessDevice::getActiveAccessPoint()] No object for active access point found! -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.28.4-bs4 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/bash Versions of packages network-manager-kde depends on: ii kdelibs4c2a 4:3.5.10.dfsg.1-1+b1 core libraries and binaries for al ii libc6 2.9-3GNU C Library: Shared libraries ii libdbus-1-3 1.2.12-1 simple interprocess messaging syst ii libdbus-1-qt3-0 0.9-2backport of Qt4 D-Bus bindings (sh ii libgcc1 1:4.3.3-4GCC support library ii libhal1 0.5.11-8 Hardware Abstraction Layer - share ii libice6 2:1.0.5-1X11 Inter-Client Exchange library ii libnl1 1.1-5library for dealing with netlink s ii libpng12-0 1.2.35-1 PNG library - runtime ii libqt3-mt 3:3.3.8b-5+b1Qt GUI Library (Threaded runtime v ii libsm6 2:1.1.0-2X11 Session Management library ii libstdc++6 4.3.3-4 The GNU Standard C++ Library v3 ii libx11-62:1.1.5-2X11 client-side library ii libxext62:1.0.4-1X11 miscellaneous extension librar ii network-manager 0.7.0.97-1 network management framework daemo ii zlib1g 1:1.2.3.3.dfsg-12compression library - runtime Versions of packages network-manager-kde recommends: ii kwalletmanager4:4.2.0-1 secure password wallet manager for ii network-manager-openvpn 0.7.0.97-1 network management framework (Open ii network-manager-vpnc 0.7.0.97-1 network management framework (VPNC network-manager-kde 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#516096: ITP: libibumad -- OpenFabrics Alliance InfiniBand umad (user MAD) library
Guus Sliepen wrote: On Thu, Feb 19, 2009 at 10:31:43AM +, Guy Coates wrote: * Package name: libibumad Version : 1.2.3 Upstream Author : Voltaire, Inc. * URL : http://www.openfabrics.org I do not see a libibumad tarball there, I did find OFED-1.4.tgz which contained a SRPM for it... if this is the only way upstream distributes these libraries, please suggest to them that it is better if they publish normal tarballs. Hmm, that is the difficult part. There are individual packages and there is OFED. OFED is a collection of many packages, mostly not the recent version, but a more tested stable version. E.g. IB management packages can be found here: http://www.openfabrics.org/downloads/management/ I already wondered all the time, which would be better for Debian, the packages from OFED or the individual packages. IHMO, extracting all the srpms is a pain... Description : OpenFabrics Alliance InfiniBand umad (user MAD) library libibumad provides the user MAD library functions which sit on top of the user MAD modules in the kernel. These are used by the IB diagnostic and management tools, including OpenSM. I have absolutely no clue what this does, except that it has something to do with InfiniBand. What is MAD? What is OpenSM? What functionality does this library provide? Also drop OpenFabrics Alliance from the short description. If you want to mention it, do it in the long description. The problem is, there is nowhere a real description of what all these IB libraries are actually doing. MAD = management datagram. As far as I understand it, you need this library to send IB management packages from user space. OpenSM = open subnet manager. Each IB network needs at least one running subnet manager, which controls the routing between ports. From the man page of opensm: opensm provides an implementation of an InfiniBand Subnet Manager and Administration. Such a software entity is required to run for in order to initialize the InfiniBand hardware (at least one per each InfiniBand subnet). Guy, it is a bit a pity, since you did all the work again, we already had done at q-leap :( IMHO all these IB packages are too many for one maintainer, what do you think to make an alioth for these? Cheers, Bernd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511995: Do you still need sponsoring for unionfs-fuse 0.21-3 ?
Hello Vincent On Monday 02 February 2009, Vincent Fourmond wrote: Hello, Bernd Schubert wrote: On Sunday 01 February 2009, Vincent Fourmond wrote: Hello, I've noticed this RC bug: 511995. Are you still in need for a sponsor for unionfs-fuse 0.21-3 ? If yes, would you like me to sponsor you ? (that would probably happen only tomorrow). I didn't find a sponsor yet, so would be really great if you could upload it. It is on its way. thanks a lot for your help and efforts! Two things: * make sure you send an unblock request to debian-rele...@lists.debian.org, else the package won't make it to testing (I'm quite confident you are aware of that, but I mention it just in case ;-)...); Thanks, I know. Shame on me, it is already the third time for this package. Always my own programming bugs :( * I think it would be better if you added the (closes: ...) stanza along with the line that describes what was fixed, rather than at the end of the changelog. Ah, I should have studied more changelogs, didn't know this is proper syntax. Will do so next time. Thanks again, Bernd signature.asc Description: This is a digitally signed message part.
Bug#511995: Do you still need sponsoring for unionfs-fuse 0.21-3 ?
Hello Vincent, On Sunday 01 February 2009, Vincent Fourmond wrote: Hello, I've noticed this RC bug: 511995. Are you still in need for a sponsor for unionfs-fuse 0.21-3 ? If yes, would you like me to sponsor you ? (that would probably happen only tomorrow). I didn't find a sponsor yet, so would be really great if you could upload it. Thanks in advance, Bernd signature.asc Description: This is a digitally signed message part.
Bug#513681: unionfs-fuse: all freshly created files are made in top branch
Hello Mark On Saturday 31 January 2009, Mark Poks wrote: Package: unionfs-fuse Version: 0.21-2 Severity: wishlist i have very fast SSD disk, but it's very small. i would like to have part of /home directory here (a config files) and another part on typical SATA drive (usual files), so i may make unionfs /mnt/home_sata=RW:/mnt/home_ssd=RW to /home. i can place all config files on faster drive but when new application is installed i have to move manually it's config file. it would be nice to make some automation, for example a file-filter in unionfs, which decides if file is written to top branch, or to lower branch, or another lower branch, etc.. as for now i have script which moves all files/dirs begining with '.' on ssd disk when system is shoutdown. thanks for your suggestion.I have to admit we even don't have the basic infrastructure for that, though. I will keep it in my mind, but support for / and control sockets have a higher priority for me (and I even hardly find time to work on that :( ). Patches are welcome, of course. Cheers, Bernd signature.asc Description: This is a digitally signed message part.
Bug#511995: unionfs-fuse: too short memory allocation when determining absolute path
Sorry for the delay, I was busy all the time. I upgraded the bug to serious and uploaded a new package to mentors. Once it is in unstable I will write a mail to the release team. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511995: unionfs-fuse: too short memory allocation when determining absolute path
Hello Raphael, On Friday 16 January 2009, Raphael Geissert wrote: Package: unionfs-fuse Version: 0.21-2 Severity: important Tags: patch Hi again, It took me a little while to track it down, but here it is: When using relative paths unionfs-fuse wasn't allocation enough memory thus the resulting absolute path was not always correct. Diff of strace (- current code, + patched code): -open(/home/ttt/ff/imagess/\31, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) +open(/home/ttt/ff/images/, O_RDONLY|O_LARGEFILE) = 4 And as you can guess all the remaining lstat and other system calls fail because the path doesn't exist. thanks a lot for spotting this! Stupid me! I introduced this in changeset 255 and didn't notice the missing byte, even though I even added the comments what for +2 is for and then added another trailing slash :( http://podgorny.cz/~bernd/hg/hgwebdir.cgi/radek-trunk-bernd-merge/rev/5e0ced59f299 I will upload a new package in the evening. Thanks again, Bernd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511446: Wrong calculation of free space with RO directories
Hello Jörg,
On Saturday 10 January 2009, Jörg Sommer wrote:
Package: unionfs-fuse
Version: 0.21-2
Severity: normal
Hi,
# mkdir /tmp/{a-c}
# for i in /tmp/{a,b}; do mount -t tmpfs none $i; done
# unionfs-fuse /tmp/a=RW:/tmp/b=RO /tmp/c
# df G /tmp/.
none 315M 0 315M 0% /tmp/a
none 315M 0 315M 0% /tmp/b
unionfs-fuse 629M 0 629M 0% /tmp/c
The free space value of the union is wrong, because unionfs can only
write to one of the joined directories.
this is already fixed for some time in my branch
(http://podgorny.cz/~bernd/hg/hgwebdir.cgi/radek-trunk-bernd-merge).
Cheers,
Bernd
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511157: unionfs-fuse: --help writes to stderr
On Wednesday 07 January 2009 22:17:07 Raphael Geissert wrote: Package: unionfs-fuse Version: 0.21-2 Severity: minor --help should not write to stderr, it should better write to stdout; just like the majority of commands out there. Cheers, Thanks, commited upstream. Cheers, Bernd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511158: unionfs-fuse should be installed in /usr/bin
Hello Raphael, On Wednesday 07 January 2009 22:20:50 Raphael Geissert wrote: Package: unionfs-fuse Version: 0.21-2 Hi again, I fail to understand why unionfs-fuse is installed in /usr/sbin, as any non-root user in the fuse group can make use of it; avoiding yet another super user process. sorry my fault, we do use unionfs-fuse for NFS clients for /etc and /var, and I entirely forgot it also might be used for other purposes ;) So thanks a lot for noticing that, I have pushed the installation to bin/ instead of sbin/ upstream. Cheers, Bernd -- Bernd Schubert Q-Leap Networks GmbH -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511047: unionfs-fuse: RO not being respected
On Wednesday 07 January 2009 22:07:49 Raphael Geissert wrote: Hello Bernd, 2009/1/7 Bernd Schubert b...@q-leap.de: [...] Hmm, I'm afraid though, this is more a missing feature. Everything I did for RO/RW branches I did to properly support copy-on-write. And actually I thing Then please state so in the man page ;) Thanks, committed upstream :) What do you think, would it be possible to add these changes to Lenny? http://podgorny.cz/~bernd/hg/hgwebdir.cgi/radek-trunk-bernd-merge/rev/c18067e6a849 http://podgorny.cz/~bernd/hg/hgwebdir.cgi/radek-trunk-bernd-merge/rev/c61013290b29 http://podgorny.cz/~bernd/hg/hgwebdir.cgi/radek-trunk-bernd-merge/rev/2c4ec61d88d9 I'm only a package maintainer, would you sponsor an upload from mentors? I would then also write another mail to the release team. Thanks, Bernd -- Bernd Schubert Q-Leap Networks GmbH -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511047: unionfs-fuse: RO not being respected
Hello Raphael,
On Wednesday 07 January 2009 02:07:08 Raphael Geissert wrote:
Package: unionfs-fuse
Version: 0.21-2
Hi,
Trying out unionfs-fuse to determine whether it is better than funionfs or
not I noticed that even when a directory is marked as RO, it is not
I'm very glad you are testing unionfs-fuse and reporting bugs :)
respected. Example:
$ mkdir -p {{local,remote}/,}test
$ /usr/sbin/unionfs-fuse remote/test=RO:local/test=RW test
$ cat /dev/null test/foo
$ ls local/test
$ ls remote/test
foo
If I change the order of the arguments so that local comes before remote it
is respected (in the sense that the file is written under local, and not
under remote; but I suspect that given the required circumstances the bug
would show up in that case as well).
Hmm, I'm afraid though, this is more a missing feature. Everything I did for
RO/RW branches I did to properly support copy-on-write. And actually I thing
unionfs-fuse is not much of use without cow. However, Radek, the inital
developer wanted to have cow as an option and so cow is disabled by default.
So please give the options -ocow,allow_other,use_ino,nonempty to get the
correct behaviour.
Ah and if possible also -o noinitgroups. The next release will use kernel
permissions and so -o noinitgroups won't be required any more (my branch is
here: http://podgorny.cz/~bernd/hg/hgwebdir.cgi/radek-trunk-bernd-merge).
As soon as I have some time, I will see what I can do for RW/RO without cow.
Cheers,
Bernd
--
Bernd Schubert
Q-Leap Networks GmbH
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509516: unionfs-fuse: Fails to link new files
Hello Jörg, thanks for spotting and reporting this bug. I have commited a first patch to my branch, which should fix the issue with one rw-branch, but it needs more work when there are several rw-branches. http://podgorny.cz/~bernd/hg/hgwebdir.cgi/radek-trunk-bernd-merge/rev/94df00cfbff6 I will do a new upload once Lenny got released. Thanks again, Bernd On Monday 22 December 2008, Jörg Sommer wrote: Package: unionfs-fuse Version: 0.21-2 Severity: normal Hi, % mkdir -p /tmp/a/dir1/dir1a % mkdir /tmp/b % mkdir /tmp/c % unionfs-fuse -o cow -o default_permissions -o use_ino -o nonempty \ /tmp/b=RW:/tmp/a=RO /tmp/c % ls /tmp/c dir1 % echo bla /tmp/c/file % ls /tmp/c/dir1/dir1a/ % link /tmp/c/file /tmp/c/dir1/dir1a/file link: cannot create link `/tmp/c/dir1/dir1a/file' to `/tmp/c/file': No such file or directory % ls /tmp/c/dir1/dir1a/ % mkdir -p /tmp/b/dir1/dir1a % link /tmp/c/file /tmp/c/dir1/dir1a/file % ls /tmp/c/dir1/dir1a file % Bye, Jörg. -- System Information: Debian Release: unstable/experimental APT prefers unstable APT policy: (900, 'unstable'), (700, 'experimental') Architecture: powerpc (ppc) Kernel: Linux 2.6.28-rc9 Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages unionfs-fuse depends on: ii fuse-utils2.7.4-1.1 Filesystem in USErspace (utilities ii libc6 2.7-16 GNU C Library: Shared libraries ii libfuse2 2.7.4-1.1 Filesystem in USErspace library unionfs-fuse recommends no packages. unionfs-fuse 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#495380: detailed bug description
Hmm, I see my previous description was a bit terse, so here in detail: read-only branch: some_path/sub_path read-write branch: empty or some_path, but NOT sub_path == union: some_path/sub_path Creating a new file in the union directory some_path/subpath will now fail without the bugfix, since it will fail to create rw_branch/some_path/sub_path. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487629: further bugfix information
Neil asked me to send futher information about the bug fix, so here it is. 1) Way to reproduce: No idea what needs to be done to trigger this bug, I only know that after I installed keytouch log-out and system shutdown from KDE didn't work anymore. 2) Killing keytouchd is one possibility to workaround this bug. 3) Once I figured out keytouchd was the reason for my shutdown problem, I searched a bit and came across the ubuntu bugreport. The upstream author there describes the cause of the problem: https://bugs.launchpad.net/debian/+source/keytouch/+bug/186713/comments/53 4) So I went ahead and added this patch (as backport from new upstream 2.4.1) to the debian package and uploaded the new package, with *only* this additional patch to mentors.debian.net #! /bin/sh /usr/share/dpatch/dpatch-run ## 25_XCloseDisplay.dpatch by [EMAIL PROTECTED] ## ## DP: Backport from 2.4.0, allow proper X-session shutdown @DPATCH@ diff -urNad keytouch-2.3.2~/keytouchd/main.c keytouch-2.3.2/keytouchd/main.c --- keytouch-2.3.2~/keytouchd/main.c2008-08-20 22:15:57.0 +0200 +++ keytouch-2.3.2/keytouchd/main.c 2008-08-20 22:16:53.587173950 +0200 @@ -168,7 +168,7 @@ XmlFree (user_preferences.browser); XmlFree (user_preferences.email_program); XmlFree (user_preferences.chat_program); - XCloseDisplay (display); + /* XCloseDisplay (display); This may prevent keytouchd from terminating */ exit (EXIT_SUCCESS); } 5) Before I uploaded the new package to mentors, I also checked several times, that this patch indeed fixes the problem. 6) Interdiff output [EMAIL PROTECTED] keytouchinterdiff -z keytouch_2.3.2-2.diff.gz keytouch_2.3.2-2.1.diff.gz diff -u keytouch-2.3.2/debian/patches/00list keytouch-2.3.2/debian/patches/00list --- keytouch-2.3.2/debian/patches/00list +++ keytouch-2.3.2/debian/patches/00list @@ -3,0 +4 @@ +25_XCloseDisplay.dpatch diff -u keytouch-2.3.2/debian/changelog keytouch-2.3.2/debian/changelog --- keytouch-2.3.2/debian/changelog +++ keytouch-2.3.2/debian/changelog @@ -1,3 +1,11 @@ +keytouch (2.3.2-2.1) unstable; urgency=low + + * Non-maintainer upload. + * fix xsession shutdown problem + * (closes: #487629) + + -- Bernd Schubert [EMAIL PROTECTED] Wed, 20 Aug 2008 22:24:27 +0200 + keytouch (2.3.2-2) unstable; urgency=low * Vcs-* fields no longer need XS- prefix. only in patch2: unchanged: --- keytouch-2.3.2.orig/debian/patches/25_XCloseDisplay.dpatch +++ keytouch-2.3.2/debian/patches/25_XCloseDisplay.dpatch @@ -0,0 +1,18 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## 25_XCloseDisplay.dpatch by [EMAIL PROTECTED] +## +## DP: Backport from 2.4.0, allow proper X-session shutdown + [EMAIL PROTECTED]@ +diff -urNad keytouch-2.3.2~/keytouchd/main.c keytouch-2.3.2/keytouchd/main.c +--- keytouch-2.3.2~/keytouchd/main.c 2008-08-20 22:15:57.0 +0200 keytouch-2.3.2/keytouchd/main.c2008-08-20 22:16:53.587173950 +0200 +@@ -168,7 +168,7 @@ + XmlFree (user_preferences.browser); + XmlFree (user_preferences.email_program); + XmlFree (user_preferences.chat_program); +- XCloseDisplay (display); ++ /* XCloseDisplay (display); This may prevent keytouchd from terminating */ + + exit (EXIT_SUCCESS); + } -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487629: Unable to reproduce
Hello Neil, I already uploaded a fixed version to mentors.debian.net, which only fixes this bug and therefore should be o.k. as freeze exception. Unfortunately, I'm only a package maintainer without any upload rights. Would be great if you could do that for me. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/k/keytouch - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/k/keytouch/keytouch_2.3.2-2.1.dsc Thanks, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495380: unionfs-fuse: cow fails to create directories
Package: unionfs-fuse Version: 0.21-1 Severity: grave Tags: patch Justification: renders package unusable -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495380: unionfs-fuse: cow fails to create directories
Oops, somehow deleted the bug descripton when I submitted the bug. Last week a user reported on the mailing list that creating new files will fail the the writable branch doesn't have the directory path. So clearly a copy-on-write bug. I already submitted patch to the upstream repository: http://hg.podgorny.cz/unionfs-fuse/rev/2be23aea75a0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492176: initscripts: umountfs must not umount fuse file-systems with -f
Package: initscripts Version: 2.86.ds1-60 Severity: important In /etc/init.d/umountfs all filesystems except tmpfs are umounted with the force -f flag. While I already think it is a bad idea to use the special force flag for everything, it causes real trouble with fuse-filesystems. For fuse-filesystems the force flag will close the /dev/fuse connection and thus the filesystem will abort. If there are still open filedescriptors on the mount point, all further access to these mount points will return Transport endpoint is not connected (errno 108). I also think this should be fixed in fuse, however, the author of fuse thinks the present behaviour is correct and so there is presently no way to fix it at kernel level. Please see this thread: http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/6579/focus=6592 So there are two options: 1) Entirely remove the force flag. Probably too late for Lenny. 2) Make exeptions for fuse filesystems. I also believe Miklos is right, simply umounting everything is wrong. Umounting /bin, /sbin/, /lib, etc. shouldn't be done at all. IMHO this also should be fixed in Lenny+1. Thanks, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481490: ITP: unionfs-fuse -- user-space directory concatenation
On Friday 16 May 2008, Daniel Baumann wrote: how does it compare to funionfs? Compare the sources yourself ;) Funionfs has all code in a very few files, only a very few comments and then some of these in French... On the other hand, unionfs-fuse is well structured, has many comments, uses lots of static functions, etc (well I wrote large chunks of the cow code, so I naturally think the code looks good ;) ). However, I tested funfionfs myself some time ago and it wasn't running sufficiently stable (this was shortly before I started to work on unionfs-fuse). Again on the other hand, unionfs-fuse is sufficiently stable to run on diskless workstations (used by my former university group for /etc and /var) and diskless HPC compute nodes (we are presently using it on most of our clusters for all system directories). Both of these setups do require large uptimes and an rock stable unionfs implementation. Btw, I'm not going to package the released version and also for now not Radeks main branch, since both branches have some severe bugs. Radek is presently also too busy to merge my branch (http://podgorny.cz/~bernd/hg/hgwebdir.cgi/radek-trunk-bernd-merge). Cheers, Bernd PS: I know, funionfs has one advantage to unionfs-fuse, it has a control utility. However, for our needs a stable unionfs implementation is by far more important than this tool. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468939: udev: scsi-devfs.sh overwrites sg devices for unknown device names
Package: udev Version: 0.114-2 Severity: normal Tags: patch Hello, sg*|*) NAME=generic ;; So for sg* _and_ all targets so far without a rule NAME=generic is used. On the specific system we have a tape-library attached and the ch.ko driver uses ch* as device names. When the device was detected first the sg-driver created its /dev entries and then the ch-driver took over and called udev for the very same host-id, bus, id and lun. Since scsi-devfs.sh now didn't have a rule for ch* it gracefully overwrote the sg scsi/host$HOST/bus$BUS/target$TARGET/lun$LUN/generic entries with ch major and minors. Of course, the /dev/sg* still existed, but just pointed to wrong device. The tape software trying to access the sg devices with sg ioctls got rather confused (you have no idea how much trouble this caused...). Here are two patches, entirely untested though, since we solved it on the specific system differently. 01_dev_ch.patch: Rule for media changer devices Index: udev/scsi-devfs.sh === --- udev.orig/scsi-devfs.sh 2008-03-02 14:14:18.0 +0100 +++ udev/scsi-devfs.sh 2008-03-02 14:19:03.0 +0100 @@ -74,6 +74,9 @@ NAME=$(echo $1 | sed -e 's/st0m/mt/') [ $NAME = mt0 ] LINK=tape ;; +ch*) + NAME=ch + ;; sg*|*) NAME=generic ;; 02_no_default_generic.patch: Abort if a device name is unknown. Better no devfs-style rule than a harmful rule. Index: udev/scsi-devfs.sh === --- udev.orig/scsi-devfs.sh 2008-03-02 14:19:53.0 +0100 +++ udev/scsi-devfs.sh 2008-03-02 14:21:58.0 +0100 @@ -77,9 +77,13 @@ ch*) NAME=ch ;; -sg*|*) +sg*) NAME=generic ;; +*) + echo Unknown device-type $1 + exit 1 + ;; esac echo scsi/host$HOST/bus$BUS/target$TARGET/lun$LUN/$NAME $LINK Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435381: e2fsprogs: Patch to use ssscanf() instead of atoi() in the option parser.
Package: e2fsprogs
Version: 1.39+1.40-WIP-2006.11.14+dfsg-2
Severity: normal
In unix.c: PRS() the function atoi() is used to convert strings to integers,
however, atoi() does not check for errors and therefore shouldn't be used
for human input.
Yesterday I wanted to create the lustre mds and ost databases,
but also wanted to see a progress bar, so I called e2fsck -C -n, but forgot
-C requires an argument. So atoi happiliy accepted -n as argument of -C,
unfortunately the filesystem was mounted :( Well, it did ask me if I really
want to continue, but since I specified -n I confirmed that, of course.
Only after it already did a journal recovery I realized the -n option
wasn't properly parsed.
Please consider to apply the attached patch.
Bernd
diff -r 7b057872ec06 e2fsck/unix.c
--- a/e2fsck/unix.c Fri Jul 27 16:08:50 2007 +0200
+++ b/e2fsck/unix.c Tue Jul 31 12:20:22 2007 +0200
@@ -585,6 +585,10 @@ static errcode_t PRS(int argc, char *arg
#endif
char *extended_opts = 0;
char *cp;
+ int res; /* result of sscanf */
+#ifdef CONFIG_JBD_DEBUG
+ char *jbd_debug;
+#endif
retval = e2fsck_allocate_context(ctx);
if (retval)
@@ -614,7 +618,10 @@ static errcode_t PRS(int argc, char *arg
switch (c) {
case 'C':
ctx-progress = e2fsck_update_progress;
- ctx-progress_fd = atoi(optarg);
+ res = sscanf(optarg, %d, ctx-progress_fd);
+ if (res != 1)
+goto sscanf_err;
+
if (!ctx-progress_fd)
break;
/* Validate the file descriptor to avoid disasters */
@@ -674,20 +681,26 @@ static errcode_t PRS(int argc, char *arg
/* What we do by default, anyway! */
break;
case 'b':
- ctx-use_superblock = atoi(optarg);
+ res = sscanf(optarg, %d, ctx-use_superblock);
+ if (res != 1)
+goto sscanf_err;
ctx-flags |= E2F_FLAG_SB_SPECIFIED;
break;
case 'B':
ctx-blocksize = atoi(optarg);
break;
case 'I':
- ctx-inode_buffer_blocks = atoi(optarg);
+ res = sscanf(optarg, %d, ctx-inode_buffer_blocks);
+ if (res != 1)
+goto sscanf_err;
break;
case 'j':
ctx-journal_name = string_copy(ctx, optarg, 0);
break;
case 'P':
- ctx-process_inode_size = atoi(optarg);
+ res = sscanf(optarg, %d, ctx-process_inode_size);
+ if (res != 1)
+goto sscanf_err;
break;
case 'L':
replace_bad_blocks++;
@@ -830,10 +843,22 @@ static errcode_t PRS(int argc, char *arg
putenv(newpath);
}
#ifdef CONFIG_JBD_DEBUG
- if (getenv(E2FSCK_JBD_DEBUG))
- journal_enable_debug = atoi(getenv(E2FSCK_JBD_DEBUG));
+ jbd_debug = getenv(E2FSCK_JBD_DEBUG);
+ if (jbd_debug)
+ res = sscanf(jbd_debug, %d, journal_enable_debug);
+ if (res != 1) {
+ fprintf(stderr,
+ _(\nInvalid argument \%s\, not an integer\n\n),
+ jbd_debug);
+ exit (1);
+ }
#endif
return 0;
+
+sscanf_err:
+ fprintf(stderr, _(\nInvalid argument \%s\, not an integer\n\n),
+ optarg);
+ exit (1);
}
static const char *my_ver_string = E2FSPROGS_VERSION;
Bug#416512: removed disk md-device
On Friday 11 May 2007 10:51:40 Michael Tokarev wrote: Neil Brown wrote: [] But joggling a usb stick (similar to your use case) would probably be OK since it would be hot-removed and then hot-added. This still needs user-space interaction. If the USB layer detects a removal and a re-insert, sdb may well come back a something different (sdp?) - though I'm not completely familiar with how USB storage works. This is in fact an.. interesting issue. Suppose I pulled the USB cable of sdb -- the WRONG one -- by a mistake. I noticed this immediately (since the led on the disk stopped lighting), and plugged the cable back again. There was no write requests to the array during this time, there was no ANY requests to it at all, it was completely idle. But. The unplug immediately triggers USB device removal. But md subsystem still holds a reference to (now orphan) sdb. So upon plugging it back, since sdb is busy, scsi subsystem (which handles USB disks) grabs first available sdX device, let's say it'll be sdp. So we've orphan sdb which is in use by the array, and fresh new sdp, which is unused but contains the orphaned array component. And there's no way to hot-re-add sdp to the array (there's nothing to do to the array itself!) but.. to powercycle the machine! Because on hot-remove, event count will be updated on the still-plugged-in device (sda let it be), and upon hot-add, md will start resyncing. Oh well... (the only help from md subsystem here is in case if it is using bitmaps, but that's different issue.) Yep, thats exactly what I'm talking about and its not only limited to usb, but happens with sata as well. Bernd -- Bernd Schubert Q-Leap Networks GmbH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416512: removed disk md-device
On Thursday 10 May 2007 09:12:54 Neil Brown wrote: On Wednesday May 9, [EMAIL PROTECTED] wrote: Neil Brown [EMAIL PROTECTED] [2007.04.02.0953 +0200]: Hmmm... this is somewhat awkward. You could argue that udev should be taught to remove the device from the array before removing the device from /dev. But I'm not convinced that you always want to 'fail' the device. It is possible in this case that the array is quiescent and you might like to shut it down without registering a device failure... Hmm, the the kernel advised hotplug to remove the device from /dev, but you don't want to remove it from md? Do you have an example for that case? Until there is known to be an inconsistency among the devices in an array, you don't want to record that there is. Suppose I have two USB drives with a mounted but quiescent filesystem on a raid1 across them. I pull them both out, one after the other, to take them to my friends place. I plug them both in and find that the array is degraded, because as soon as I unplugged on, the other was told that it was now the only one. Not good. Best to wait for an IO request that actually returns an errors. Ok, keeping the raid working in this case would be a good idea, so we would need it configurable if it should degrade or not. However, have you tested if pulling and hotplugging the drive works? Actually thats what our customer did. As long as md keeps the old device information, the re-plugged-in device will get another device name (and of course also another major number) and so the md-device will still keeps the old device information and it will never automagically add the new device. Probably thats even a good idea, how should the md-layer know if it is really the very same device and even if it would know that, how should it know that no data have been modified on it, while it was plugged out? Maybe an mdadm command that will do that for a given device, or for all components of a given array if the 'dev' link is 'broken', or even for all devices for all array. mdadm --fail-unplugged --scan or mdadm --fail-unplugged /dev/md3 Ok, so one could run this as cron script. Neil, may I ask if you already started to work on this? Since we have the problem on a customer system, we should fix it ASAP, but at least within the next 2 or 3 weeks. If you didn't start work on it yet, I will do... No, I haven't, but it is getting near the top of my list. If you want a script that does this automatically for every array, something like: I have never looked into the mdadm sources before, but I will try during the weekend (without any promises). for a in /sys/block/md*/md/dev-* do if [ -f $a/block/dev ] then : still there else echo faulty $a/state echo remove $a/state fi done should do what you want. (I haven't tested it though). Thanks a lot, we will test that here. Do you propose the same logic for mdadm? Thanks, Bernd -- Bernd Schubert Q-Leap Networks GmbH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416512: removed disk md-device
On Wednesday 09 May 2007 15:14:50 martin f krafft wrote: also sprach Bernd Schubert [EMAIL PROTECTED] [2007.05.09.1417 +0200]: Problem-1) When the disk fails, udev will remove it from /dev. Unfortunately this will make it impossible to remove the disk or its partitions from /dev/mdX device, since mdadm tries to read the device fail and will abort if this file is not there. Please also see http://bugs.debian.org/416512. It would be nice if you could keep [EMAIL PROTECTED] on CC. mdadm upstream knows of the problem. See the bug log. Ah, so Goswin already wrote a bug report :) Actually Goswin first did run into this problem here while doing some internal tests, but today we have it on a customer system. Neil Brown [EMAIL PROTECTED] [2007.04.02.0953 +0200]: Hmmm... this is somewhat awkward. You could argue that udev should be taught to remove the device from the array before removing the device from /dev. But I'm not convinced that you always want to 'fail' the device. It is possible in this case that the array is quiescent and you might like to shut it down without registering a device failure... Hmm, the the kernel advised hotplug to remove the device from /dev, but you don't want to remove it from md? Do you have an example for that case? It is still possible to fail and remove the device by writing faulty and then remove to /sys/block/mdX/md/dev-YYY/state Maybe an mdadm command that will do that for a given device, or for all components of a given array if the 'dev' link is 'broken', or even for all devices for all array. mdadm --fail-unplugged --scan or mdadm --fail-unplugged /dev/md3 Ok, so one could run this as cron script. Neil, may I ask if you already started to work on this? Since we have the problem on a customer system, we should fix it ASAP, but at least within the next 2 or 3 weeks. If you didn't start work on it yet, I will do... Thanks, Bernd -- Bernd Schubert Q-Leap Networks GmbH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402163: openoffice.org-calc: [calc] quotient-function doesn't work
I'm on amd64 using 2.0.4.dfsg.1-1 in my i386-chroot I got the older 2.0.3-something Version where OUOTIENT is working fine. Thus I'm not sure whether this is amd64 or 2.0.4 related. Works fine on i386 and has the bug on AMD64 (both just tested with 2.0.4.dfsg.1-1). -- Bernd Schubert PCI / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg
Bug#335897: NFS file access bug still observed on multiple machines with working NFS servers
On Monday 04 December 2006 01:40, you wrote:
Bernd Schubert wrote:
do you know at which openoffice.org version the problem first occurded?
In the institut we are running 2.0.3-6~bpo.1 and there's everything on
nfs (even the root filesystem) without any problems.
2.0.4. The first report of this came in after the upgrade to 2.0.4
Ok, I will try to reproduce it in our Sid chroot. If openoffice.org won't work
on nfs we will have a real problem.
More interesting is the fact that it DOESN'T find the libnss3.so library.
Hmm, I see openoffice.org-core has a dependency to libnss3-0d but none to
libnss3. I just straced it myself and its really calling libnss3.so and
not libnss3.so.0d (but libnss3 is installed on my system).
Can you install the libnss3 package and see what happens?
And how does that have anything to do with this report?
The NSS stuff is for XML security and it works.
Well, it somewhere stalls and it probably doesn' t stall in D-state. I also
only know the libnss-{ldap,mysql, etc) libraries used for account support
(passwd, group, etc) and thought it might be related to libnss3. The package
description of libnss3 also is a bit short and I didn't find any other
information about it.
I simply thought that openoffice might have problems to resolve the uid and
gid to a username. Sorry that I was entirely wrong here.
Anyway, it won't hurt to install the libnss3 library. The given trace is not
enlightening and installing this library is just a shot in the dark.
Regards,
Bernd
--
Bernd Schubert
PCI / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg
Bug#335897: NFS file access bug still observed on multiple machines with working NFS servers
Hi Stephen, Stephen Benning wrote: I, too, have been given fits by this bug. However, I have restarted my portmapper multiple times, and the problem was *not* fixed. I have this problem whether or not my NFS is firewalled (in fact, the problem first showed up on my non-firewalled machines at home). This is not due to bug 391911, as I have statd running: do you know at which openoffice.org version the problem first occurded? In the institut we are running 2.0.3-6~bpo.1 and there's everything on nfs (even the root filesystem) without any problems. respond only to a command line kill [pid] or killall soffice. Not being That means its not in D state, since processes in D state wouldn't be killable. There are some curious calls being made to the mozilla suite when I start the program up. stat64(/usr/lib/mozilla/libnss3.so, 0xafa23f68) = -1 ENOENT (No such file or directory) You mean those stat64() calls? This only means that /usr/lib/mozilla/ is in your library path and that it is looking there for libnss3.so. Nothing wrong with that. More interesting is the fact that it DOESN'T find the libnss3.so library. Hmm, I see openoffice.org-core has a dependency to libnss3-0d but none to libnss3. I just straced it myself and its really calling libnss3.so and not libnss3.so.0d (but libnss3 is installed on my system). Can you install the libnss3 package and see what happens? Did you give the option -f to strace to see process forks? Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385798: openoffice.org: font hinting still does not work with the current version ob libfreetype
I'm also working on a fix for ubuntu (not ready yet) and therefore moved the directory, new sources.list line: # my Openoffice build deb http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/openoffice/sid ./ -- Bernd Schubert PCI / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg
Bug#400531: moinmoin-common: new upstream release 1.5.6
Package: moinmoin-common Version: 1.5.3-1.1 Severity: wishlist Hi Jonas, I just wanted to ask why there's in Sid/Etch still moinmoin-1.5.3 and not 1.5.6? As far as I can see it from the upstream changelog most updates are just bugfixes. I also did a quick test with 1.5.6 backported to sarge and so far I didn't find any problem. Thanks, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385798: openoffice.org: font hinting still does not work with the current version ob libfreetype
For those who are interested, I have uploaded openoffice.org packages including my patch. Just add this line to your sources.list deb http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/openoffice/ ./ -- Bernd Schubert PCI / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg
Bug#385798: openoffice.org: font hinting still does not work with the current version ob libfreetype
1) cd whatever/vcl 2) . ../Linuxwhatever.sh 3) build 4) copy the lib into your install 5) *try* 6) repeat from 2) Ah, finally I understood what you mean. Got it recompiled within 1min and first test was immediately successfull - the screenshots now look identical. http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/freetype-snapshots/3-old_full_sub.png http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/freetype-snapshots/3-new_full_sub_oo_normal_fix.png I suggest anyone who is interesting tries those new libs: http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/freetype/OpenOffice_fix_libs/ NOTE: They are for openoffice.org-2.0.4~rc1 NOT for rc2! About the patch, since it sets normal hinting it might be possible one could disable this flag at all. However, to verify this, I would need to read the code more carefully, I only don't have the time to do that. Cheers, Bernd -- Bernd Schubert PCI / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg --- openoffice.org-2.0.4~rc1.old/ooo-build/build/ood680-m3/vcl/source/glyphs/gcach_ftyp.cxx 2006-09-24 00:23:00.0 +0200 +++ openoffice.org-2.0.4~rc1.new/ooo-build/build/ood680-m3/vcl/source/glyphs/gcach_ftyp.cxx 2006-09-28 02:16:19.0 +0200 @@ -849,10 +859,10 @@ #endif mnLoadFlags |= FT_LOAD_NO_HINTING; -#ifdef FT_LOAD_TARGET_LIGHT +#ifdef FT_LOAD_TARGET_NORMAL // enable light hinting if available if( !(mnLoadFlags FT_LOAD_NO_HINTING) (nFTVERSION = 2103)) -mnLoadFlags |= FT_LOAD_TARGET_LIGHT; + mnLoadFlags |= FT_LOAD_TARGET_NORMAL; #endif if( ((mnCos != 0) (mnSin != 0)) || (mnPrioEmbedded = 0) ) @@ -2158,10 +2168,10 @@ FT_Int nLoadFlags = FT_LOAD_DEFAULT; -#ifdef FT_LOAD_TARGET_LIGHT +#ifdef FT_LOAD_TARGET_NORMAL // enable light hinting if available if( nFTVERSION = 2103 ) -nLoadFlags |= FT_LOAD_TARGET_LIGHT; +nLoadFlags |= FT_LOAD_TARGET_NORMAL; #endif FT_Error rc = FT_Load_Glyph( maFaceFT, nGlyphIndex, nLoadFlags );
Bug#385798: openoffice.org: font hinting still does not work with the current version ob libfreetype
Now, there are two ways to resolve this bug: 1.) Quick'n dirty. Simply replace FT_LOAD_TARGET_LIGHT in vcl/source/glyphs/gcach_ftyp.cxx by FT_LOAD_TARGET_NORMAL or FT_LOAD_TARGET_LCD or FT_LOAD_TARGET_LCD_V (if recompiling wouldn't take 8h on Opteron 242, it would be easy to test which gives best results). Hmm. Can't you do it as you know what you expect to have? :) You don't need to do a full rebuild for every change ;-) - you only have to build once (assume the default or with one of the changes), and then just can do: 1) cd whatever/vcl 2) . ../Linuxwhatever.sh 3) build 4) copy the lib into your install 5) *try* 6) repeat from 2) The problem is that the system I'm building on is in the institute and I'm presently writing my thesis at home and I'm refusing to use my home system for such a long compile time (my temperature controlled fans will begin to make too much noise) ;) Additionally the build system is ro-mounted nfs-diskless, the build itself is in a nfs sid-chroot - installation is only possible to local tmp-disk storage. Lets see how well openoffice behaves with this installation. I will be in the institute tomorrow, but I don't know yet, if I will have time to care about this. 2.) Take the latest patch from http://qa.openoffice.org/issues/show_bug.cgi?id=64508 and adjust it, so that it applies to openoffice-2.0.4. From the point of the user wishes and user config probably the best, but its clearly not a simple replace patch and might be buggy. Which one do you prefer? Given the timeframe and the maybe-riskyness of i64508 I'd prefer 1.) Ok, before I wanted to spend further (in principle not available) spare time on any of those two possibilities, I first wanted to know which solution you prefer :) Cheers, Bernd -- Bernd Schubert PCI / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg
Bug#385798: openoffice.org: font hinting still does not work with the current version ob libfreetype
Hello Rene, I think I found the reason why the bytecode interpreter is not used, see here: http://www.openoffice.org/servlets/ReadMsg?list=devmsgNo=17880 Now, there are two ways to resolve this bug: 1.) Quick'n dirty. Simply replace FT_LOAD_TARGET_LIGHT in vcl/source/glyphs/gcach_ftyp.cxx by FT_LOAD_TARGET_NORMAL or FT_LOAD_TARGET_LCD or FT_LOAD_TARGET_LCD_V (if recompiling wouldn't take 8h on Opteron 242, it would be easy to test which gives best results). 2.) Take the latest patch from http://qa.openoffice.org/issues/show_bug.cgi?id=64508 and adjust it, so that it applies to openoffice-2.0.4. From the point of the user wishes and user config probably the best, but its clearly not a simple replace patch and might be buggy. Which one do you prefer? Cheers, Bernd
Bug#385798: openoffice.org: font hinting still does not work with the current version ob libfreetype
Hello,
Rene Engelhard wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Rene Engelhard wrote:
Ah, it's in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378619
where you didn't refer to..
You are referring to
http://www.openoffice.org/nonav/issues/showattachment.cgi/36573/vcl-freetype-2.2.x.diff,
don't you?
- --- snip ---
#
OpenOffice
All current versions of OpenOffice.org include internal headers; this
will be fixed either in 2.0.3 or 2.0.4. (The fix is applied to the CVS,
but still waiting for approval for the 2.0.3 branch).
Until then, you can use this patch.
- --- snip ---
reading this, can you try 2.0.4rc1 (2.0.4rc2 coming soon) in sid and try
whether it works there?
I just checked it myself, the patch is included into 2.0.4rc1, slightly
different, as in 2.0.4rc1 fist the unsigned's are defined and from it the
signed's, but that shouldn't matter (if I'm not entirely mistaken at this
late hour).
typedef const unsigned char* CPU8;
inline sal_uInt16 NEXT_U16( CPU8 p ) { p+=2; return (p[-2]8)|p[-1]; }
inline sal_Int16 NEXT_S16( CPU8 p ) { return (sal_Int16)NEXT_U16(p); }
inline sal_uInt32 NEXT_U32( CPU8 p ) { p+=4; return (p[-4]24)|(p[-3]16)|
(p[-2]8)|p[-1]; }
//inline sal_Int32 NEXT_S32( U8* p ) { return (sal_Int32)NEXT_U32(p); }
NEXT_S32() is really not used in gcach_ftyp.cxx.
The problem is that the bytecode interpretation doesn't work, I just asked
several questions on the freetype-list:
http://lists.nongnu.org/archive/html/freetype/2006-09/msg00050.html
Sasha, is this the same problem you have?
Cheers,
Bernd
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388795: latex-xft-fonts: Missing character in cmex10.ttf
Package: latex-xft-fonts Version: 0.1-5 Severity: normal Tags: patch Hi, in cmex10.ttf there is a missing opening bracket '[' of character number #138. I created this missing character by using fontforge and copying and flipping the closing bracket ']' of character #139. I'm attaching the new cmex10.ttf Cheers, Bernd -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-rc5-bs1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages latex-xft-fonts depends on: ii defoma0.11.10Debian Font Manager -- automatic f Versions of packages latex-xft-fonts recommends: ii fontconfig2.4.1-2generic font configuration library ii x-ttcidfont-conf 25 Configure TrueType and CID fonts f -- no debconf information cmex10.ttf Description: Binary data
Bug#388795: latex-xft-fonts: Missing character in cmex10.ttfO
Oops, I mean #183 (missing '[') and #184 (template ']' used to create the missing character). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372719: regression in FreeType security fix for DSA-1095
Version: 2.1.7-5 On Sat, Aug 19, 2006 at 04:23:50PM +0200, Martin Schulze wrote: Maybe it's better to fix it via proposed-updates and let the SRM team decide. This has happened now, and is r3. It's regrettable that we couldn't get it out in a DSA update, but it's at least done for users who will upgrade from stable. Sorry for my dumb question, but where do I find the latest package? I don't see any recent libfreetype6 security updates and also sarge-proposed-updates doesn't have anything about libfreetype6? On vorlons site (http://people.debian.org/~vorlon/) there's also only the -3 package from june. Another question, did you discuss this issue with upstream? I mean, if there's some dispute on how it should be solved, shouldn't upstream be at least asked? This also applies to #367593, I searched the freetype list archives, but didn't find anything recent about debian bugs. Thanks, Bernd -- Bernd Schubert PCI / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg
Bug#383893: kxkb: multi-user problem with files in /tmp
The attached patch was accepted upstream. Please apply it, if etch will be shipped with the current kde version. Thanks, Bernd diff -ru kdebase-3.5.4/kxkb/extension.cpp kdebase-3.5.4.new/kxkb/extension.cpp --- kdebase-3.5.4/kxkb/extension.cpp 2006-03-17 11:17:41.0 +0100 +++ kdebase-3.5.4.new/kxkb/extension.cpp 2006-08-26 14:46:07.0 +0200 @@ -40,8 +40,9 @@ d = qt_xdisplay(); m_dpy = d; - QStringList dirs = KGlobal::dirs()-findDirs ( tmp, ); - m_tempDir = dirs.count() == 0 ? /tmp/ : dirs[0]; + // QStringList dirs = KGlobal::dirs()-findDirs ( tmp, ); + // m_tempDir = dirs.count() == 0 ? /tmp/ : dirs[0]; + m_tempDir = locateLocal(tmp, ); } bool XKBExtension::init()
Bug#339693: svgalib_helper kernel module wanted
Hi, svgalib-1.9.25 is in experimental, but there's still no kernel module package. The module builds and insmods without any problems on 2.6.17. Any chance for an official package? Another question, svgalib-1.9 is a prerelease since ages and I don't see it will ever declared stable. How about taking the package from experimental, renaming it to svgalib2 and adding it to sid? I'm just hoping to convince Christian Marillat to build mplayer with svgalib support then... In svga output mode mplayer just need so much less cputime. Thanks, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383893: kxkb: multi-user problem with files in /tmp
Package: kdebase-bin
Version: 4:3.5.4-2
Severity: normal
Tags: patch
Hi,
kxkb creates {layoutname}.xkm files in /tmp. Now think of a
multi-usersystem as with xdmcp. Since those *.xkm files won't be
deleted, only one user can create them. For all other users there's a
problem.
I already have reported this upstream:
http://bugs.kde.org/show_bug.cgi?id=132421
This bug is also in Sarge forcing me to creaty my own kdebase debs for
our group. It would be nice if this could be fixed with etch, I'm
attaching a patch.
Thanks,
Bernd
-- no debconf information
diff -ru kdebase-3.5.4/kxkb/extension.cpp kdebase-3.5.4.new/kxkb/extension.cpp
--- kdebase-3.5.4/kxkb/extension.cpp 2006-03-17 11:17:41.0 +0100
+++ kdebase-3.5.4.new/kxkb/extension.cpp 2006-08-20 02:40:18.0 +0200
@@ -1,5 +1,6 @@
#include string.h
#include errno.h
+#include stdlib.h
#include qstring.h
#include qmap.h
@@ -22,6 +23,10 @@
QMapQString, FILE* XKBExtension::fileCache; //TODO: move to class?
+static QString user(void)
+{
+ return getenv(USER);
+}
static QString getLayoutKey(const QString layout, const QString variant)
{
@@ -30,7 +35,7 @@
QString XKBExtension::getPrecompiledLayoutFilename(const QString layoutKey)
{
- QString compiledLayoutFileName = m_tempDir + layoutKey + .xkm;
+ QString compiledLayoutFileName = m_tempDir + username + . + layoutKey + .xkm;
return compiledLayoutFileName;
}
@@ -42,6 +47,8 @@
QStringList dirs = KGlobal::dirs()-findDirs ( tmp, );
m_tempDir = dirs.count() == 0 ? /tmp/ : dirs[0];
+
+ username = user();
}
bool XKBExtension::init()
diff -ru kdebase-3.5.4/kxkb/extension.h kdebase-3.5.4.new/kxkb/extension.h
--- kdebase-3.5.4/kxkb/extension.h 2006-03-17 11:17:41.0 +0100
+++ kdebase-3.5.4.new/kxkb/extension.h 2006-08-20 02:46:22.0 +0200
@@ -22,6 +22,7 @@
private:
Display *m_dpy;
QString m_tempDir;
+ QString username;
static QMapQString, FILE* fileCache;
bool setLayoutInternal(const QString model,
Bug#381761: tidev-modules-source: postinst/postrm depmod -- update templates to use dh_installmodules instead
Hello Matej, On Sunday 13 August 2006 06:21, Matej Vela wrote: [EMAIL PROTECTED] writes: this bug report is part of a mass-bugfiling. Your package tidev-modules-source is calling depmod in its postinst and/or postrm scripts. [...] As far as I can tell, no, it isn't. Where's the catch? sorry, tidev-modules-source got probably by accident into the list. Anyway looking at I see that it is calling 'update-modules', though the man page of update-modules says that it is obsolete. Maybe a good chance to fix this? Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381761: tidev-modules-source: postinst/postrm depmod -- update templates to use dh_installmodules instead
On Sunday 13 August 2006 21:58, Matej Vela wrote: retitle 381761 tidev-modules-source: update-modules deprecated thanks Bernd Schubert [EMAIL PROTECTED] writes: sorry, tidev-modules-source got probably by accident into the list. Anyway looking at I see that it is calling 'update-modules', though the man page of update-modules says that it is obsolete. Maybe a good chance to fix this? If you can provide a patch, sure (the package is orphaned). Pity, I just (2 weeks ago) throw away my self-made serial cable to connect my Ti85 - didn't use it for 5 years and it was, erm lets say, not the best thing I ever soldered :) I also didn't know and never checked that connecting Ti calculators is supported on Linux. Attached are two patches. One is to remove the postinst script (there's even no update-devfsd script in unstable) and adjusts the deb_helper dependency and the other patch fixes module_param() for newer kernel versions. Now that I know there I could connect my Ti85 in Linux I might consider to resolder a new cable. However, I'm pretty sure I don't have time to that at least until February 2007. Do you think tidev can stay in unstable until that time? I would report back in February or March and ask to maintain it. Cheers, Bernd -- Bernd Schubert PCI / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg diff -ruN tidev-modules.old/debian/control.modules.in tidev-modules.new/debian/control.modules.in --- tidev-modules.old/debian/control.modules.in 2006-04-12 16:49:59.0 +0200 +++ tidev-modules.new/debian/control.modules.in 2006-08-13 22:45:53.0 +0200 @@ -2,7 +2,7 @@ Section: misc Priority: optional Maintainer: Julien BLACHE [EMAIL PROTECTED] -Build-Depends: debhelper (= 4.0.0) +Build-Depends: debhelper (= 5.0.37) Standards-Version: 3.6.1 Package: tidev-modules-_KVERS_ diff -ruN tidev-modules.old/debian/tidev-modules-_KVERS_.postinst.modules.in tidev-modules.new/debian/tidev-modules-_KVERS_.postinst.modules.in --- tidev-modules.old/debian/tidev-modules-_KVERS_.postinst.modules.in 2006-04-12 16:49:59.0 +0200 +++ tidev-modules.new/debian/tidev-modules-_KVERS_.postinst.modules.in 1970-01-01 01:00:00.0 +0100 @@ -1,12 +0,0 @@ -#!/bin/sh - -#DEBHELPER# - -if [ $1 = configure ]; then - - if [ `uname -r` = _KVERS_ ] ; then - update-modules || true - update-devfsd || true - fi - -fi diff -ru tidev-modules.new/tiser/module/tiser.c tidev-modules.new2/tiser/module/tiser.c --- tidev-modules.new/tiser/module/tiser.c 2004-06-19 10:36:07.0 +0200 +++ tidev-modules.new2/tiser/module/tiser.c 2006-08-13 22:26:41.0 +0200 @@ -508,7 +508,7 @@ EXPORT_NO_SYMBOLS; #endif -MODULE_PARM(timeout, i); +module_param(timeout, int, 0); MODULE_PARM_DESC(timeout, Timeout, default=1.5 seconds); -MODULE_PARM(delay, i); +module_param(delay, int, 0); MODULE_PARM_DESC(delay, Inter-bit delay, default=10 microseconds);
Bug#380159: Bug#381776: em8300-source: postinst/postrm depmod -- update templates to use dh_installmodules instead
Hi Nicolas, On Monday 07 August 2006 00:38, Nicolas Boullis wrote: Hi, On Sun, Aug 06, 2006 at 11:55:30PM +0200, [EMAIL PROTECTED] wrote: Package: em8300-source Hi, 7 this bug report is part of a mass-bugfiling. Your package em8300-source is calling depmod in its postinst and/or postrm scripts. With a recent debhelper (5.0.37) and by calling dh_installmodules in the rules script this is not neccessary any more. This report is related to Bug#380159. The full discussion is here http://lists-archives.org/debian-devel/24684-kernel-modules-postinst- script.html As far as I am concerned, whenever possible, I'd rather not depend (or build-depend) on things that are not available in stable, since it makes back-poting more complex. Is there a good reason to use dh_installmodules rather than copy the code snippet from http://lists-archives.org/debian-devel/24684-kernel-modules-postinst-script .html ? Personally I have no real opinion about that. Using debhelper makes it easy to fix bugs like this the future. On the other hand it really wasn't that easy to get debhelper-5.0.37 to sarge. Its not available on backports.org and to port it myself, I had to backport several other packages as well. Again on the other hand, Etch seems to get released on time which is not so far in the future. Well, I'm not a debian-developer, so my opinion shouldn't count anyway ;) I have CC'ed to Bug#380159, maybe they have a real opinion there. Thanks, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380159: kernel modules postinst script -- update templates to use dh_installmodules instead
As of debhelper 5.0.37, dh_installmodules uses the System.map for the target kernel as per template, iirc. No maintainer provided script templates are required for this purpose if dh_installmodules is used. Thanks, I just backported debhelper 5.0.37 into our sarge-build environment and tested with drbd0.7-module-source. Seems to work fine. Any reason for not adding -e to the depmod arguments? Its not required, but might give helpful messages. -e --errsyms When combined with the -F option, this reports any symbols which a module needs which are not sup- plied by other modules or the kernel. Normally, any symbols not provided by modules are assumed to be provided by the kernel (which should be true in a perfect world). I'm not experienced with mass bug reporting, what needs to be done to assigne this bug to the corresponding module-source packages? All packages manually one by one or is there an automatic way? Thanks, Bernd -- Bernd Schubert PCI / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg
Bug#364308: krb5-admin-server: kadmind stalls on system boot due to readin from /dev/random
Hi Russ,
I don't have time just at the moment to check whether this change is easy
to make or to work on a patch. If you have a moment to do that, it would
be greatly appreciated. Otherwise, I'll try to take a look at this as
soon as I have some more free time.
the attached patch is rather simple as it will only move the fork() lines. I
don't think it might have any negative impacts and its also tested on my home
system for 14 days.
Moving the random number reading would be much more difficult, as one would
have to check all those initializations after krb5_c_random_os_entropy() in
ovsec_kadmind.c.
Cheers,
Bernd
--
Bernd Schubert
PCI / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg
diff -ru krb5-1.4.3.orig/src/kadmin/server/ovsec_kadmd.c krb5-1.4.3-7/src/kadmin/server/ovsec_kadmd.c
--- krb5-1.4.3.orig/src/kadmin/server/ovsec_kadmd.c 2004-09-21 20:20:16.0 +0200
+++ krb5-1.4.3-7/src/kadmin/server/ovsec_kadmd.c 2006-05-27 04:10:49.0 +0200
@@ -269,6 +269,18 @@
if (argc != 0)
usage();
+ if (!nofork (ret = daemon(0, 0))) {
+ ret = errno;
+ krb5_klog_syslog(LOG_ERR, Cannot detach from tty: %s, error_message(ret));
+ fprintf(stderr, %s: Cannot detach from tty: %s\n,
+ whoami, error_message(ret));
+ svcauth_gssapi_unset_names();
+ kadm5_destroy(global_server_handle);
+ krb5_klog_close(context);
+ exit(1);
+ }
+
+
if ((ret = krb5_init_context(context))) {
fprintf(stderr, %s: %s while initializing context, aborting\n,
whoami, error_message(ret));
@@ -591,16 +603,6 @@
exit(1);
}
- if (!nofork (ret = daemon(0, 0))) {
- ret = errno;
- krb5_klog_syslog(LOG_ERR, Cannot detach from tty: %s, error_message(ret));
- fprintf(stderr, %s: Cannot detach from tty: %s\n,
- whoami, error_message(ret));
- svcauth_gssapi_unset_names();
- kadm5_destroy(global_server_handle);
- krb5_klog_close(context);
- exit(1);
- }
setup_signal_handlers();
krb5_klog_syslog(LOG_INFO, starting);
Bug#369176: tvtime: postinst script doesn't set suid bit properly
Package: tvtime Version: 1.0.1-2.2 Severity: minor The suid bits become overwritten by chown root:root /usr/bin/tvtime, therefore the suid bit is first set and then removed again. --- tvtime.postinst.old 2006-05-28 01:56:42.528132901 +0200 +++ tvtime.postinst 2006-05-28 01:54:31.853586239 +0200 @@ -28,14 +28,14 @@ if [ -x /usr/bin/tvtime ] [ $RET = false ] ; then if [ ! -x /usr/sbin/dpkg-statoverride ] ||\ ! /usr/sbin/dpkg-statoverride --list /usr/bin/tvtime /dev/null; then - chmod u=rwx,go=rx /usr/bin/tvtime chown root:root /usr/bin/tvtime + chmod u=rwx,go=rx /usr/bin/tvtime fi else if [ ! -x /usr/sbin/dpkg-statoverride ] || \ ! /usr/sbin/dpkg-statoverride --list /usr/bin/tvtime /dev/null; then - chmod u=rwxs,go=rx /usr/bin/tvtime chown root:root /usr/bin/tvtime + chmod u=rwxs,go=rx /usr/bin/tvtime fi fi } -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364308: krb5-admin-server: kadmind stalls on system boot due to readin from /dev/random
Package: krb5-admin-server Version: 1.4.3-6 Severity: important While testing kerberos on my home system I noticed that krb5-admin-server hangs on almost each system startup. After pressing randomly some keys the boot process goes on. While this is already annoying on my desktop system, it is not acceptable for a remotely administrated system. I think this should be fixable using the following patch and I'm just recompiling to test it. --- prng.c.old 2006-04-22 17:34:54.0 +0200 +++ prng.c 2006-04-22 17:35:21.0 +0200 @@ -164,7 +164,7 @@ int fd; unsigned char buf[YARROW_SLOW_THRESH/8]; int left; - fd = open (device, O_RDONLY); + fd = open (device, O_RDONLY | O_NONBLOCK); if (fd == -1) return 0; if (fstat (fd, sb) == -1) Another solution would be to increase the runlevel number hoping for more entropy later on. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.1-test Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Versions of packages krb5-admin-server depends on: ii debconf [debc 1.4.70 Debian configuration management sy ii krb5-kdc 1.4.3-6MIT Kerberos key server (KDC) ii libc6 2.3.5-13 GNU C Library: Shared libraries an ii libcomerr21.38+1.39-WIP-2005.12.31-1 common error description library ii libkadm55 1.4.3-6MIT Kerberos administration runtim ii libkrb53 1.4.3-6MIT Kerberos runtime libraries ii libss21.38+1.39-WIP-2005.12.31-1 command-line interface parsing lib krb5-admin-server recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364308: krb5-admin-server: kadmind stalls on system boot due to readin from /dev/random
On Saturday 22 April 2006 18:58, Russ Allbery wrote: Bernd Schubert [EMAIL PROTECTED] writes: Package: krb5-admin-server Version: 1.4.3-6 Severity: important While testing kerberos on my home system I noticed that krb5-admin-server hangs on almost each system startup. After pressing randomly some keys the boot process goes on. While this is already annoying on my desktop system, it is not acceptable for a remotely administrated system. FWIW, I'm not seeing this on my systems, so I'm wondering what's different between my setup and yours. I'm surprised myself that I seem to be almost the only one to have this problem. However, one can some reports, e.g.: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125743 I think this should be fixable using the following patch and I'm just recompiling to test it. --- prng.c.old 2006-04-22 17:34:54.0 +0200 +++ prng.c 2006-04-22 17:35:21.0 +0200 @@ -164,7 +164,7 @@ int fd; unsigned char buf[YARROW_SLOW_THRESH/8]; int left; - fd = open (device, O_RDONLY); + fd = open (device, O_RDONLY | O_NONBLOCK); if (fd == -1) return 0; if (fstat (fd, sb) == -1) It would surprise me if this helped at all, since if your understanding of what's happening is correct, the hang is from trying to read entropy, not just opening the device. Well, I would call read() 'subsequent operation', see man 2 open O_NONBLOCK or O_NDELAY When possible, the file is opened in non-blocking mode. Neither the open() nor any subsequent opera-tions on the file descriptor which is returned will cause the calling process to wait. For the han-dling of FIFOs (named pipes), see also fifo(4). This mode need not have any effect on files other than FIFOs. My unix programmers book from W. Richard Stevens also clearly states the non-blocking open mode is (also) for read and write operatations. Furthermore, after installing the recompiled packages and rebooting my system several time, I can confirm that the patch works. Cheers, Bernd -- Bernd Schubert PCI / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg
Bug#328485: 'apt-get update' leaves zero byte files in /var/lib/apt/lists/partial/
On Thursday 06 October 2005 11:52, you wrote: On Thu, Sep 15, 2005 at 05:50:59PM +0200, Bernd Schubert wrote: Package: apt Version: 0.6.41 Severity: important We are running Sid within a chroot environment and from time to time I update the packages there. Since about apt-0.6.40 the 'apt-get update command' causes problems. It just leaves zero byte files in /var/lib/apt/lists/partial/, e.g.: Perhaps your sources.list in the chroot has duplicate entries. Hmm, I'm a bit in a hurry (will be on travel until Saturday), but I don't see any duplicated lines there: # Debian Unstable deb ftp://ftp.uni-heidelberg.de/pub/mirror.debian/ unstable main non-free contrib deb ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.debian.org/debian/ unstable main non-free contrib # Debian Testing deb ftp://ftp.uni-heidelberg.de/pub/mirror.debian/ testing main non-free contrib deb ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.debian.org/debian/ testing main non-free contrib # Debian stable deb ftp://ftp.uni-heidelberg.de/pub/mirror.debian/ stable main non-free contrib deb ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.debian.org/debian/ stable main non-free contrib deb-src ftp://ftp.uni-heidelberg.de/pub/mirror.debian/ unstable main non-free contrib deb-src ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.debian.org/debian/ unstable main non-free contrib # Debian Experimental deb ftp://ftp.uni-heidelberg.de/pub/mirror.debian/ experimental main non-free contrib deb ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.debian.org/debian/ experimental main non-free contrib # video-stuff deb ftp://ftp.nerim.net/debian-marillat/ sarge main deb-src ftp://ftp.nerim.net/debian-marillat/ sid main # Blackdown java #deb ftp://ftp.informatik.hu-berlin.de/pub/Java/Linux/debian/ sarge non-free # Bibus deb http://switch.dl.sourceforge.net/sourceforge/bibus-biblio ./ deb-src http://switch.dl.sourceforge.net/sourceforge/bibus-biblio ./ -- Bernd Schubert Physikalisch Chemisches Institut / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg e-mail: [EMAIL PROTECTED]
Bug#328485: 'apt-get update' leaves zero byte files in /var/lib/apt/lists/partial/
Package: apt Version: 0.6.41 Severity: important We are running Sid within a chroot environment and from time to time I update the packages there. Since about apt-0.6.40 the 'apt-get update command' causes problems. It just leaves zero byte files in /var/lib/apt/lists/partial/, e.g.: -rw-r--r-- 1 root root 0 2005-08-28 10:43 ftp.nerim.net_debian-marillat_dists_sarge_main_binary-i386_Packages -rw-r--r-- 1 root root 0 2005-09-14 21:47 ftp-stud.fht-esslingen.de_pub_Mirrors_ftp.debian.org_debian_dists_experimental_main_binary-i386_Packages -rw-r--r-- 1 root root 0 2005-09-14 21:47 ftp-stud.fht-esslingen.de_pub_Mirrors_ftp.debian.org_debian_dists_experimental_non-free_binary-i386_Packages -rw-r--r-- 1 root root 0 2005-09-14 21:47 ftp-stud.fht-esslingen.de_pub_Mirrors_ftp.debian.org_debian_dists_stable_contrib_binary-i386_Packages During the next 'apt-get update' I'm getting many messages like below, and the package list won't be updated. Hit ftp://ftp-stud.fht-esslingen.de unstable/contrib Sources 99% [Packages bzip2 0] [Query] [Logging in] bzip2: Compressed file ends unexpectedly; perhaps it is corrupted? *Possible* reason follows. bzip2: Inappropriate ioctl for device Input file = (stdin), output file = (stdout) It is possible that the compressed file(s) have become corrupted. You can use the -tvv option to test integrity of such files. You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. This bug can be very confusing as I first thought we are experiencing filesystem or even memory errors - until I found out about the files in /var/lib/apt/lists/partitial. Thanks, Bernd PS: Sorry that I reported not earlier, but my first bug report seems to have been lost due to a mail-agent misconfiguration in the chroot. -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture i386; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Cache-Limit 33554432; Dir /; Dir::State var/lib/apt/; Dir::State::lists lists/; Dir::State::cdroms cdroms.list; Dir::State::userstatus status.user; Dir::State::status /var/lib/dpkg/status; Dir::Cache var/cache/apt/; Dir::Cache::archives archives/; Dir::Cache::srcpkgcache srcpkgcache.bin; Dir::Cache::pkgcache pkgcache.bin; Dir::Etc etc/apt/; Dir::Etc::sourcelist sources.list; Dir::Etc::vendorlist vendors.list; Dir::Etc::vendorparts vendors.list.d; Dir::Etc::main apt.conf; Dir::Etc::parts apt.conf.d; Dir::Etc::preferences preferences; Dir::Bin ; Dir::Bin::methods /usr/lib/apt/methods; Dir::Bin::dpkg /usr/bin/dpkg; DPkg ; DPkg::Pre-Install-Pkgs ; DPkg::Pre-Install-Pkgs:: /usr/sbin/dpkg-preconfigure --apt || true; -- /etc/apt/preferences -- Package: * Pin: release a=stable Pin-Priority: 20 Package: * Pin: release a=testing Pin-Priority: 50 Package: * Pin: release a=unstable Pin-Priority: 500 -- /etc/apt/sources.list -- # Debian Unstable deb ftp://ftp.uni-heidelberg.de/pub/mirror.debian/ unstable main non-free contrib deb ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.debian.org/debian/ unstable main non-free contrib # Debian Testing deb ftp://ftp.uni-heidelberg.de/pub/mirror.debian/ testing main non-free contrib deb ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.debian.org/debian/ testing main non-free contrib # Debian stable deb ftp://ftp.uni-heidelberg.de/pub/mirror.debian/ stable main non-free contrib deb ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.debian.org/debian/ stable main non-free contrib deb-src ftp://ftp.uni-heidelberg.de/pub/mirror.debian/ unstable main non-free contrib deb-src ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.debian.org/debian/ unstable main non-free contrib # Debian Experimental deb ftp://ftp.uni-heidelberg.de/pub/mirror.debian/ experimental main non-free contrib deb ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.debian.org/debian/ experimental main non-free contrib # video-stuff deb ftp://ftp.nerim.net/debian-marillat/ sarge main deb-src ftp://ftp.nerim.net/debian-marillat/ sid main # Blackdown java #deb ftp://ftp.informatik.hu-berlin.de/pub/Java/Linux/debian/ sarge non-free # Bibus deb http://switch.dl.sourceforge.net/sourceforge/bibus-biblio ./ deb-src http://switch.dl.sourceforge.net/sourceforge/bibus-biblio ./ -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (50, 'testing'), (20, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-ck10-tc9 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages apt depends on: ii libc6 2.3.5-3GNU C Library: Shared libraries an ii libgcc1 1:4.0.1-4 GCC support library ii libstdc++64.0.1-4The GNU Standard C++ Library v3 apt recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of
Bug#320776: missing slash in make_extra_nodes() of /etc/init.d/udev
Package: udev
Version: 0.060-1
Severity: normal
Tags: patch
Hello Marco,
the function make_extra_nodes() in /etc/init.d/udev is only executed
properly when the current working directory is '/'. This is just due to
a missing slash on checking for /etc/udev/links.conf (in the script this
is etc/udev/links.conf). Somehow *some*, but not all of our clients
therefor don't execute this function. It seems all version of udev,
including sarge, are affected.
Cheers,
Bernd
-- Kernel configuration:
isapnp_init not present.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (800, 'unstable'), (800, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-ck7-BS2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Versions of packages udev depends on:
ii hotplug 0.0.20040329-22 Linux Hotplug Scripts
ii initscripts 2.86.ds1-2 Standard scripts needed for bootin
ii libc62.3.2.ds1-22GNU C Library: Shared libraries an
ii libselinux1 1.22-1 SELinux shared libraries
ii makedev 2.3.1-78creates device files in /dev
ii sed 4.1.4-2 The GNU sed stream editor
udev recommends no packages.
-- debconf information excluded
--- udev.old2005-08-01 13:40:41.0 +0200
+++ udev2005-08-01 13:40:53.0 +0200
@@ -57,7 +57,7 @@
# I hate this hack. -- Md
make_extra_nodes() {
- [ -e etc/udev/links.conf ] || return 0
+ [ -e /etc/udev/links.conf ] || return 0
grep '^[^#]' /etc/udev/links.conf | \
while read type name arg1; do
[ $type -a $name -a ! -e /dev/$name -a ! -L /dev/$name ] ||continue
Bug#311043: sntop wrongly expects global config file in /usr/etc and not /etc
Package: sntop
Version: 1.4.3-1
Severity: important
Tags: patch
I just found out there is something like sntop (so far only knew iftop)
and immediately believe that the package has a bug ;)
Just installing sntop without further configuration results in this
message
[EMAIL PROTECTED] ~sntop
sntop: error, cannot open systen or user conf file
Here's the corresponding strace output.
open(/home/bernd/.sntoprc, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(/usr/etc/sntoprc, O_RDONLY) = -1 ENOENT (No such file or
directory)
However, sntoprc is installed in /etc. So I checked the debian-source
and the rules script gives this option --sysconfdir=\$${prefix}/etc. I
really think \$${prefix} should be removed.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (800, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.11-ck7-BS2
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15
(charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Versions of packages sntop depends on:
ii fping 2.4b2-to-ipv6-10 sends ICMP ECHO_REQUEST packets to
ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an
ii libncurses5 5.4-4Shared libraries for terminal hand
-- no debconf information
diff -ru sntop-1.4.3.orig/debian/rules sntop-1.4.3/debian/rules
--- sntop-1.4.3.orig/debian/rules 2005-05-28 01:47:10.0 +0200
+++ sntop-1.4.3/debian/rules2005-05-28 02:00:02.0 +0200
@@ -13,7 +13,7 @@
dh_testdir
# Commands to configure the package.
./configure --prefix=/usr --mandir=\$${prefix}/share/man \
- --infodir=\$${prefix}/share/info --sysconfdir=\$${prefix}/etc
+ --infodir=\$${prefix}/share/info --sysconfdir=/etc
touch configure-stamp
build: configure-stamp build-stamp
