Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)
On Wed, Jun 17, 2020 at 04:42:56PM +0200, Andreas Gruenbacher wrote: > Hi Bruce, > > On Wed, Jun 17, 2020 at 2:58 AM J. Bruce Fields wrote: > > I think I'll send the following upstream. > > looking good, but how about using a little helper for this? I like it. And the new comment's helpful too. > > Also I'm not sure if ecryptfs gets this right, so taking the ecryptfs > list into the CC. Yes, questions I had while doing this: - cachefiles, ecrypfs, devtmpfs, and unix_mknod skip the check, is that OK for all of them? (Overlayfs too, I think?--that code's harder to follow. - why don't vfs_{create,mknod,mkdir} do the IS_POSIXACL check themselves? Even if it's unnecessary for some callers, surely it wouldn't be wrong? I also wondered why both vfs_{create,mknod,mkdir} and the callers were calling security hooks, but now I see that the callers are calling security_path_* hooks and the vfs_ functions are calling security_inode_* hooks, so I guess they're not redundant. Though now I wonder why some of the callers (nfsd, overlayfs) are skipping the security_path_* hooks. --b. > > Thanks, > Andreas > > -- > > Add a posix_acl_apply_umask helper for filesystems like nfsd to apply > the umask before calling into vfs_create, vfs_mkdir, and vfs_mknod when > necessary. > > Signed-off-by: Andreas Gruenbacher > --- > fs/namei.c| 9 +++-- > fs/nfsd/vfs.c | 6 ++ > fs/overlayfs/dir.c| 4 ++-- > fs/posix_acl.c| 15 +++ > include/linux/posix_acl.h | 6 ++ > 5 files changed, 28 insertions(+), 12 deletions(-) > > diff --git a/fs/namei.c b/fs/namei.c > index 72d4219c93ac..a68887d3a446 100644 > --- a/fs/namei.c > +++ b/fs/namei.c > @@ -3054,8 +3054,7 @@ static struct dentry *lookup_open(struct nameidata *nd, > struct file *file, > if (open_flag & O_CREAT) { > if (open_flag & O_EXCL) > open_flag &= ~O_TRUNC; > - if (!IS_POSIXACL(dir->d_inode)) > - mode &= ~current_umask(); > + posix_acl_apply_umask(dir->d_inode, ); > if (likely(got_write)) > create_error = may_o_create(>path, dentry, mode); > else > @@ -3580,8 +3579,7 @@ long do_mknodat(int dfd, const char __user *filename, > umode_t mode, > if (IS_ERR(dentry)) > return PTR_ERR(dentry); > > - if (!IS_POSIXACL(path.dentry->d_inode)) > - mode &= ~current_umask(); > + posix_acl_apply_umask(path.dentry->d_inode, ); > error = security_path_mknod(, dentry, mode, dev); > if (error) > goto out; > @@ -3657,8 +3655,7 @@ long do_mkdirat(int dfd, const char __user *pathname, > umode_t mode) > if (IS_ERR(dentry)) > return PTR_ERR(dentry); > > - if (!IS_POSIXACL(path.dentry->d_inode)) > - mode &= ~current_umask(); > + posix_acl_apply_umask(path.dentry->d_inode, ); > error = security_path_mkdir(, dentry, mode); > if (!error) > error = vfs_mkdir(path.dentry->d_inode, dentry, mode); > diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c > index d22a056da477..0c625b004b0c 100644 > --- a/fs/nfsd/vfs.c > +++ b/fs/nfsd/vfs.c > @@ -1226,8 +1226,7 @@ nfsd_create_locked(struct svc_rqst *rqstp, struct > svc_fh *fhp, > iap->ia_mode = 0; > iap->ia_mode = (iap->ia_mode & S_IALLUGO) | type; > > - if (!IS_POSIXACL(dirp)) > - iap->ia_mode &= ~current_umask(); > + posix_acl_apply_umask(dirp, >ia_mode); > > err = 0; > host_err = 0; > @@ -1461,8 +1460,7 @@ do_nfsd_create(struct svc_rqst *rqstp, struct svc_fh > *fhp, > goto out; > } > > - if (!IS_POSIXACL(dirp)) > - iap->ia_mode &= ~current_umask(); > + posix_acl_apply_umask(dirp, >ia_mode); > > host_err = vfs_create(dirp, dchild, iap->ia_mode, true); > if (host_err < 0) { > diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c > index 1bba4813f9cb..4d98db2a0208 100644 > --- a/fs/overlayfs/dir.c > +++ b/fs/overlayfs/dir.c > @@ -325,8 +325,8 @@ static int ovl_create_upper(struct dentry *dentry, struct > inode *inode, > struct dentry *newdentry; > int err; > > - if (!attr->hardlink && !IS_POSIXACL(udir)) > - attr->mode &= ~current_umask(); > + if (!attr->hardlink) > +posix_acl_apply_umask(udir, >mode); > > inode_lock_nested(udir, I_MUTEX_PARENT); >
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl
On Wed, Jun 17, 2020 at 06:58:29AM +0200, Salvatore Bonaccorso wrote: > On Tue, Jun 16, 2020 at 08:58:49PM -0400, J. Bruce Fields wrote: > Thank you, could test this on my test setup and seem to work properly. Great, thanks. > Should it also be CC'ed to sta...@vger.kernel.org so it is picked up > by the current supported stable series? Will do.--b.
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)
On Tue, Jun 16, 2020 at 06:16:58PM +0200, Salvatore Bonaccorso wrote: > This might be unneeded to test but as additional datapoint which > confirms the suspect: I tried check the commit around 47057abde515 > ("nfsd: add support for the umask attribute") in 4.10-rc1 > > A kernel built with 47057abde515~1, and mounting from an enough recent > client which has at least dff25ddb4808 ("nfs: add support for the > umask attribute") does not show the observed behaviour, the server > built with 47057abde515 does. Thanks for the confirmation! I think I'll send the following upstream. --b. commit 595ccdca9321 Author: J. Bruce Fields Date: Tue Jun 16 16:43:18 2020 -0400 nfsd: apply umask on fs without ACL support The server is failing to apply the umask when creating new objects on filesystems without ACL support. To reproduce this, you need to use NFSv4.2 and a client and server recent enough to support umask, and you need to export a filesystem that lacks ACL support (for example, ext4 with the "noacl" mount option). Filesystems with ACL support are expected to take care of the umask themselves (usually by calling posix_acl_create). For filesystems without ACL support, this is up to the caller of vfs_create(), vfs_mknod(), or vfs_mkdir(). Reported-by: Elliott Mitchell Reported-by: Salvatore Bonaccorso Fixes: 47057abde515 ("nfsd: add support for the umask attribute") Signed-off-by: J. Bruce Fields diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c index 0aa02eb18bd3..8fa3e0ff3671 100644 --- a/fs/nfsd/vfs.c +++ b/fs/nfsd/vfs.c @@ -1225,6 +1225,9 @@ nfsd_create_locked(struct svc_rqst *rqstp, struct svc_fh *fhp, iap->ia_mode = 0; iap->ia_mode = (iap->ia_mode & S_IALLUGO) | type; + if (!IS_POSIXACL(dirp)) + iap->ia_mode &= ~current_umask(); + err = 0; host_err = 0; switch (type) { @@ -1457,6 +1460,9 @@ do_nfsd_create(struct svc_rqst *rqstp, struct svc_fh *fhp, goto out; } + if (!IS_POSIXACL(dirp)) + iap->ia_mode &= ~current_umask(); + host_err = vfs_create(dirp, dchild, iap->ia_mode, true); if (host_err < 0) { fh_drop_write(fhp);
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)
On Mon, Jun 15, 2020 at 10:38:20PM -0400, J. Bruce Fields wrote: > Thanks for the detailed reproducer. > > It's weird, as the server is basically just setting the transmitted > umask and then calling into the vfs to handle the rest, so it's not much > different from any other user. But the same reproducer run just on the > ext4 filesystem does give the right permissions > > Oh, but looking at the system call, fs_namei.c:do_mkdirat(), it does: > > if (!IS_POSIXACL(path.dentry->d_inode)) > mode &= ~current_umask(); > error = security_path_mkdir(, dentry, mode); > if (!error) > error = vfs_mkdir(path.dentry->d_inode, dentry, mode); > > whereas nfsd just calls into vfs_mkdir(). > > And that IS_POSIXACL() check is exactly a check whether the filesystem > supports ACLs. So I guess it's the responsibility of the caller of > vfs_mkdir() to handle that case. But, that's unsatisfying: why isn't vfs_mkdir() taking care of this itself? And what about that security_path_mkdir() call? And are the other cases of that switch in fs/nfsd/vfs.c:nfsd_create_locked() correct? I think there may be some more cleanup here called for, I'll poke around tomorrow. --b.
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)
Thanks for the detailed reproducer. It's weird, as the server is basically just setting the transmitted umask and then calling into the vfs to handle the rest, so it's not much different from any other user. But the same reproducer run just on the ext4 filesystem does give the right permissions Oh, but looking at the system call, fs_namei.c:do_mkdirat(), it does: if (!IS_POSIXACL(path.dentry->d_inode)) mode &= ~current_umask(); error = security_path_mkdir(, dentry, mode); if (!error) error = vfs_mkdir(path.dentry->d_inode, dentry, mode); whereas nfsd just calls into vfs_mkdir(). And that IS_POSIXACL() check is exactly a check whether the filesystem supports ACLs. So I guess it's the responsibility of the caller of vfs_mkdir() to handle that case. So the obvious fix is something like (untested!) diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c index 0aa02eb18bd3..dabdcca58969 100644 --- a/fs/nfsd/vfs.c +++ b/fs/nfsd/vfs.c @@ -1234,6 +1234,8 @@ nfsd_create_locked(struct svc_rqst *rqstp, struct svc_fh *fhp, nfsd_check_ignore_resizing(iap); break; case S_IFDIR: + if (!IS_POSIXACL(dirp)) + iap->ia_mode &= ~current_umask(); host_err = vfs_mkdir(dirp, dchild, iap->ia_mode); if (!host_err && unlikely(d_unhashed(dchild))) { struct dentry *d; --b.
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported ZFS (with acltype=off) (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)
On Sat, Jun 13, 2020 at 11:45:27AM -0700, Elliott Mitchell wrote: > I disagree with this assessment. All of the reporters have been using > ZFS, but this could indicate an absence of testers using other > filesystems. We need someone with a NFS server which has a 4.15+ kernel > and uses a different filesystem which supports ACLs. Honestly I don't think I currently have a regression test for this so it's possible I could have missed something upstream. I haven't seen any reports, though ZFS's ACL implementation is very different from any in-tree filesystem's, and given limited time, a filesystem with no prospect of going upstream isn't going to get much attention, so, yes, I'd need to see a reproducer on xfs or ext4 or something. --b.
Bug#714974: [PATCH] jfs: avoid misuse of cookie value of 2
On Wed, Aug 14, 2013 at 10:54:31PM -0500, Dave Kleikamp wrote: For the sake of those not watching https://bugzilla.kernel.org/show_bug.cgi?id=60737 It looks like the problem is that jfs was using a cookie value of 2 for a real directory entry, where NFSv4 expect 2 to represent ... This patch has so far only been lightly tested. NFSv4 reserves cookie values 0, 1 and 2 for a rewind, and the . and .. entries. jfs was using 0 and 1 for . and .., but 2 for a regular entry. This patch makes jfs conform by using 1 and 2 for . and .. and fixes any regular entry using the value 2. Oh, I'd forgotten that. From rfc 5661: For some file system environments, the directory entries . and .. have special meaning, and in other environments, they do not. If the server supports these special entries within a directory, they SHOULD NOT be returned to the client as part of the READDIR response. To enable some client environments, the cookie values of zero, 1, and 2 are to be considered reserved. Note that the UNIX client will use these values when combining the server's response and local representations to enable a fully formed UNIX directory presentation to the application. OK! --b. Signed-off-by: Dave Kleikamp dave.kleik...@oracle.com diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c index 8743ba9..93466e8 100644 --- a/fs/jfs/jfs_dtree.c +++ b/fs/jfs/jfs_dtree.c @@ -349,11 +349,8 @@ static u32 add_index(tid_t tid, struct inode *ip, s64 bn, int slot) ASSERT(DO_INDEX(ip)); - if (jfs_ip-next_index 2) { - jfs_warn(add_index: next_index = %d. Resetting!, -jfs_ip-next_index); - jfs_ip-next_index = 2; - } + if (jfs_ip-next_index 3) { + jfs_ip-next_index = 3; index = jfs_ip-next_index++; @@ -2864,7 +2861,7 @@ void dtInitRoot(tid_t tid, struct inode *ip, u32 idotdot) } else ip-i_size = 1; - jfs_ip-next_index = 2; + jfs_ip-next_index = 3; } else ip-i_size = IDATASIZE; @@ -2951,7 +2948,7 @@ static void add_missing_indices(struct inode *inode, s64 bn) for (i = 0; i p-header.nextindex; i++) { d = (struct ldtentry *) p-slot[stbl[i]]; index = le32_to_cpu(d-index); - if ((index 2) || (index = JFS_IP(inode)-next_index)) { + if ((index 3) || (index = JFS_IP(inode)-next_index)) { d-index = cpu_to_le32(add_index(tid, inode, bn, i)); if (dtlck-index = dtlck-maxcnt) dtlck = (struct dt_lock *) txLinelock(dtlck); @@ -3031,7 +3028,7 @@ int jfs_readdir(struct file *file, struct dir_context *ctx) struct jfs_dirent *jfs_dirent; int jfs_dirents; int overflow, fix_page, page_fixed = 0; - static int unique_pos = 2; /* If we can't fix broken index */ + static int unique_pos = 3; /* If we can't fix broken index */ if (ctx-pos == DIREND) return 0; @@ -3039,15 +3036,16 @@ int jfs_readdir(struct file *file, struct dir_context *ctx) if (DO_INDEX(ip)) { /* * persistent index is stored in directory entries. - * Special cases:0 = . - * 1 = .. + * Special cases:0 = rewind + * 1 = . + * 2 = .. * -1 = End of directory */ do_index = 1; dir_index = (u32) ctx-pos; - if (dir_index 1) { + if (dir_index 2) { struct dir_table_slot dirtab_slot; if (dtEmpty(ip) || @@ -3090,18 +3088,18 @@ int jfs_readdir(struct file *file, struct dir_context *ctx) return 0; } } else { - if (dir_index == 0) { + if (dir_index 2) { /* * self . */ - ctx-pos = 0; + ctx-pos = 1; if (!dir_emit(ctx, ., 1, ip-i_ino, DT_DIR)) return 0; } /* * parent .. */ - ctx-pos = 1; + ctx-pos = 2; if (!dir_emit(ctx, .., 2, PARENT(ip), DT_DIR)) return 0; @@ -3122,22 +3120,24 @@ int jfs_readdir(struct file *file, struct dir_context *ctx) /* * Legacy filesystem - OS/2 Linux JFS 0.3.6
Bug#714974: [Jfs-discussion] NFS 'readdir loop' error on JFS
On Mon, Aug 12, 2013 at 01:29:15AM -0700, Christian Kujau wrote: Sorry for the noise, here's another oddity, same setup (client server running 3.11-rc5): $ find /mnt/nfs/usr/share/ -name getopt.awk -ls 250724 -rw-r--r-- 1 root root 2237 Mar 16 04:46 /mnt/nfs/usr/share/awk/getopt.awk 250724 -rw-r--r-- 1 root root 2237 Mar 16 04:46 /mnt/nfs/usr/share/awk/getopt.awk 250724 -rw-r--r-- 1 root root 2237 Mar 16 04:46 /mnt/nfs/usr/share/awk/getopt.awk 250724 -rw-r--r-- 1 root root 2237 Mar 16 04:46 /mnt/nfs/usr/share/awk/getopt.awk 250724 -rw-r--r-- 1 root root 2237 Mar 16 04:46 /mnt/nfs/usr/share/awk/getopt.awk 250724 -rw-r--r-- 1 root root 2237 Mar 16 04:46 /mnt/nfs/usr/share/awk/getopt.awk 250724 -rw-r--r-- 1 root root 2237 Mar 16 04:46 /mnt/nfs/usr/share/awk/getopt.awk 250724 -rw-r--r-- 1 root root 2237 Mar 16 04:46 /mnt/nfs/usr/share/awk/getopt.awk 250724 -rw-r--r-- 1 root root 2237 Mar 16 04:46 /mnt/nfs/usr/share/awk/getopt.awk 250724 -rw-r--r-- 1 root root 2237 Mar 16 04:46 /mnt/nfs/usr/share/awk/getopt.awk It's the same file, but gets reported 10 times! Hence the error when trying to tar(1) the directory: $ tar -cf - /mnt/nfs/usr/share/awk/ /dev/null tar: Removing leading `/' from member names tar: /mnt/nfs/usr/share/awk/: Cannot savedir: Too many levels of symbolic links tar: Exiting with failure status due to previous errors On the server: $ find /mnt/disk/usr/share/ -name getopt.awk -ls 250724 -rw-r--r-- 1 root root 2237 Mar 16 04:46 /mnt/disk/usr/share/awk/getopt.awk So, is JFS NFS really br0ken and nobody noticed? It does sound like a jfs bug, and I don't know if anyone tests nfs exports of jfs regularly. It might be interesting to get a network trace (something like tcpdump -s0 -wtmp.pcap; then wireshark tmp.pcap and look at the cookie fields in the readdir calls and replies. The server shouldn't return the same one twice on one read through the directory. And when the client uses a cookie it should get the next entries, not already-returned entries.) You could also just run strace -egetdents64 -v ls on the server on the exported filesystem, in a problem directory, and see if the offsets are unique. --b. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702448: nfs-common: UID's do not get properly mapped
I've created users test1 and test2 in /etc/passwd, but with swapped UID's There's a common (and understable) mistake here: many people think that NFSv4 never requires uid's and gid's to agree between hosts. This is not true. NFSv4, when used with traditional auth_sys authentication, requires names and ID's to agree between client and server. The behavior you describe is as expected. The issue is that while the NFSv4 protocol itself uses names, it's the RPC protocol (which NFSv4 runs on top of) which carries the information about who is performing a given RPC. How exactly it identifies the user depends on the security flavor. In the auth_sys case, it uses numeric ID's. For example, in this case, when you create a file, the owner of the new file will the one who performed the create. The server determines this from the uid sent in the rpc header. However, when you ls -l the file, the information about who owns the file is returned as a name in the body of the NFSv4 reply. The clearest way to see what's going on is to rerun your test cases while watching the traffic in wireshark, and look at both the rpc headers and the bodies of the requests. If you wish to get away from numeric id's on the wire, you need to switch to using NFSv4 with kerberos instead of auth_sys. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#494154: nfs-common: sm-notify manpage not installed
Package: nfs-common Version: 1:1.1.3-1 Severity: normal Tags: patch The sm-notify command has a manpage; we should install it. Patch (untested) attached. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24.2 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8) Shell: /bin/sh linked to /bin/bash Versions of packages nfs-common depends on: ii adduser 3.108 add and remove users and groups ii initscripts 2.86.ds1-60Scripts for initializing and shutt ii libc6 2.7-13 GNU C Library: Shared libraries ii libcomerr21.41.0-3 common error description library ii libevent1 1.3e-3 An asynchronous event notification ii libgssglue1 0.1-2 mechanism-switch gssapi library ii libkrb53 1.6.dfsg.4~beta1-3 MIT Kerberos runtime libraries ii libnfsidmap2 0.21-2 An nfs idmapping library ii librpcsecgss3 0.18-1 allows secure rpc communication us ii libwrap0 7.6.q-16 Wietse Venema's TCP wrappers libra ii lsb-base 3.2-16 Linux Standard Base 3.2 init scrip ii netbase 4.33 Basic TCP/IP networking system ii portmap 6.0-6 RPC port mapper ii ucf 3.007 Update Configuration File: preserv nfs-common recommends no packages. nfs-common suggests no packages. -- no debconf information diff --git a/debian/nfs-common.manpages b/debian/nfs-common.manpages index 2fd641d..5f264ab 100644 --- a/debian/nfs-common.manpages +++ b/debian/nfs-common.manpages @@ -3,6 +3,7 @@ debian/tmp/usr/share/man/man5/nfs.5 debian/tmp/usr/share/man/man8/gssd.8 debian/tmp/usr/share/man/man8/idmapd.8 debian/tmp/usr/share/man/man8/statd.8 +debian/tmp/usr/share/man/man8/sm-notify.8 debian/tmp/usr/share/man/man8/nfsstat* debian/tmp/usr/share/man/man8/showmount* debian/tmp/usr/share/man/man8/idmapd*
Bug#492970: (was: nfs-utils-1.1.3 released)
On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote: J. Bruce Fields [EMAIL PROTECTED] writes: On Fri, Aug 01, 2008 at 11:15:33PM +1000, Aníbal Monsalve Salazar wrote: On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote: I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having issues accessing my kernel.org account so for the moment the tar ball is only available on SourceForge: http://sourceforge.net/projects/nfs [...] 1.1.3 clients don't work with a 1.0.10 server anymore. Very weird--it might make sense if upgrading nfs-utils broke the mount itself, but here it seems the mount is succeeding and subsequent file access (which I'd expect to only involve the in-kernel client code) is failing. Maybe there's some difference in the mount options? What does /proc/self/mounts say? I assume these are all v2 or v3 mounts? I discovered today that I was no longer able to write to the v3 mount on my 1.1.2 server. I checked /proc/mounts and noticed sec=null on the mount. Either adding sec=sys to the client's mount options or downgrading to nfs-common 1.1.2 on the client fixes the problem. That would do it! So it sounds like there's a bug that causes mount.nfs to get the default mount options wrong? --b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: (was: nfs-utils-1.1.3 released)
On Fri, Aug 01, 2008 at 11:15:33PM +1000, Aníbal Monsalve Salazar wrote: On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote: I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having issues accessing my kernel.org account so for the moment the tar ball is only available on SourceForge: http://sourceforge.net/projects/nfs [...] 1.1.3 clients don't work with a 1.0.10 server anymore. Very weird--it might make sense if upgrading nfs-utils broke the mount itself, but here it seems the mount is succeeding and subsequent file access (which I'd expect to only involve the in-kernel client code) is failing. Maybe there's some difference in the mount options? What does /proc/self/mounts say? I assume these are all v2 or v3 mounts? --b. Please read the Debian bug report at http://bugs.debian.org/492970 On Fri, Aug 01, 2008 at 02:54:02PM +0200, Christian Surchi wrote: On Wed, Jul 30, 2008 at 12:56:12PM +0200, Rasmus Bøg Hansen wrote: Package: nfs-common Version: 1:1.1.3-1 Severity: important Upgrading nfs-common 1:1.1.3-1 broke my NFS client. The NFS server is running etch and nothing was changed. After upgrading the client to 1:1.1.3-1 access to my files (/home is NFS-mounted) is disallowed where it should be allowed (and certainly was in 1:1.1.2-6). I confirm this one on my sid client too. No changes in nfs server (etch). Downgrading nfs-common solved the problem for me too. Christian ___ NFSv4 mailing list [EMAIL PROTECTED] http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454540: fast-user-switch-applet: switches to incorrect virtual terminal after login/logout of other user
On Sat, Dec 08, 2007 at 10:47:20PM +0100, Julien Valroff wrote: Hi, Thanks for reporting this issue. Le mercredi 05 décembre 2007 à 19:58 -0500, J. Bruce Fields a écrit : Package: fast-user-switch-applet Version: 2.20.0-2 Severity: normal If user 1 and 2 are both logged in, and user 2 logs out and then logs back in again, then choosing user 2 from user 1's fast-user-switch applet no longer sends me to the virtual terminal with user 2's login session; instead I end up with a blank screen and have to hunt around with alt-ctl-Fn to find it. It seems I have a different behaviour: I can't switch back to user 2 from user 1 session. Right, we agree: choosing user 2 from user 1's fast-user-switch applet no longer sends me to the virtual terminal with user 2's login. But maybe I said it in a confusing way. Just to be sure I have well understood: 1/ User 1 is logged in 2/ Switch to user 2 though f-u-s-a 3/ User 2 closes the current session 4/ and logs in again 5/ Switch back to user 1 6/ From user 1 session, you can't reach user 2 desktop, you only see a blank screen Am I right? Yes. Thanks for confirming. --b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454540: fast-user-switch-applet: switches to incorrect virtual terminal after login/logout of other user
On Sun, Dec 09, 2007 at 08:52:23PM +0100, Julien Valroff wrote: package fast-user-switch-applet tags 454540 + confirmed upstream forwarded 454540 http://bugzilla.gnome.org/show_bug.cgi?id=502720 thanks Le dimanche 09 décembre 2007 à 14:25 -0500, J. Bruce Fields a écrit : [...] Just to be sure I have well understood: 1/ User 1 is logged in 2/ Switch to user 2 though f-u-s-a 3/ User 2 closes the current session 4/ and logs in again 5/ Switch back to user 1 6/ From user 1 session, you can't reach user 2 desktop, you only see a blank screen Am I right? Yes. Thanks for confirming. We get a different behaviour as for 6/ - in my case, the VT isn't even changed, but I am pretty sure it is the same issue. OK, thanks, I understand. Yes, it's definitely switching virtual terminals. In fact, I believe the VT it's switching to is the one that user 2 used to be on before logging out and then logging back in again. I have thus forwarded the bug upstream. Thanks! --b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454540: fast-user-switch-applet: switches to incorrect virtual terminal after login/logout of other user
Package: fast-user-switch-applet Version: 2.20.0-2 Severity: normal If user 1 and 2 are both logged in, and user 2 logs out and then logs back in again, then choosing user 2 from user 1's fast-user-switch applet no longer sends me to the virtual terminal with user 2's login session; instead I end up with a blank screen and have to hunt around with alt-ctl-Fn to find it. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.23.1 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8) Shell: /bin/sh linked to /bin/bash Versions of packages fast-user-switch-applet depends on: ii gconf2 2.20.1-1 GNOME configuration database syste ii gdm 2.20.2-1 GNOME Display Manager ii gnome-panel 2.20.2-2 launcher and docking facility for ii gnome-system-tools 2.20.0-1 Cross-platform configuration utili ii libart-2.0-22.3.19-3 Library of functions for 2D graphi ii libatk1.0-0 1.20.0-1 The ATK accessibility toolkit ii libbonobo2-02.20.1-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.20.0-1 The Bonobo UI library ii libc6 2.7-3GNU C Library: Shared libraries ii libcairo2 1.4.10-1.1 The Cairo 2D vector graphics libra ii libfontconfig1 2.5.0-2 generic font configuration library ii libfreetype62.3.5-1+b1 FreeType 2 font engine, shared lib ii libgconf2-4 2.20.1-1 GNOME configuration database syste ii libglade2-0 1:2.6.2-1library to load .glade files at ru ii libglib2.0-02.14.4-2 The GLib library of C routines ii libgnome2-0 2.20.1.1-1 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.20.1.1-1 A powerful object-oriented display ii libgnomeui-02.20.1.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.20.1-1 GNOME Virtual File System (runtime ii libgtk2.0-0 2.12.2-1 The GTK+ graphical user interface ii libice6 2:1.0.4-1X11 Inter-Client Exchange library ii liborbit2 1:2.14.7-0.1 libraries for ORBit2 - a CORBA ORB ii libpanel-applet2-0 2.20.2-2 library for GNOME Panel applets ii libpango1.0-0 1.18.3-1 Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-3 PNG library - runtime ii libpopt01.10-3 lib for parsing cmdline parameters ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libx11-62:1.0.3-7X11 client-side library ii libxau6 1:1.0.3-2X11 authorisation library ii libxcomposite1 1:0.4.0-1X11 Composite extension library ii libxcursor1 1:1.1.9-1X cursor management library ii libxdamage1 1:1.1.1-3X11 damaged region extension libra ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes' extensio ii libxi6 2:1.1.3-1X11 Input extension library ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxml2 2.6.30.dfsg-3GNOME XML library ii libxmu6 1:1.0.3-1X11 miscellaneous utility library ii libxrandr2 2:1.2.2-1X11 RandR extension library ii libxrender1 1:0.9.4-1X Rendering Extension client libra ii zlib1g 1:1.2.3.3.dfsg-7 compression library - runtime fast-user-switch-applet recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436284: strace: -e write=fd doesn't dump data after error return
Package: strace Version: 4.5.15-1 Severity: normal Tags: patch -e write=fd doesn't dump data after error return When you provide the commandline option -e write=fd, strace still doesn't dump the full write data in the case where the write system call returns an error. Of course, the write that fails is sometimes exactly the one I wanted to see So, reorganize the cases in dumpio() so that all the write-like cases (where the io is input to the system call) are before all the read-like cases, and only exit early in the second case. (You could even wonder whether it makes sense to skip dumping in the read case. I tend to suspect the likelihood of there being interesting data in the read buffer is small in that case, and that it's likely to confuse the reader into thinking that the dumped data was actually returned from the read.) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.19 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8) Shell: /bin/sh linked to /bin/bash Versions of packages strace depends on: ii libc6 2.6-5 GNU C Library: Shared libraries strace recommends no packages. -- no debconf information diff --git a/syscall.c b/syscall.c index 06b10e8..781ead0 100644 --- a/syscall.c +++ b/syscall.c @@ -505,31 +505,10 @@ static void dumpio(tcp) struct tcb *tcp; { - if (syserror(tcp)) - return; if (tcp-u_arg[0] 0 || tcp-u_arg[0] = MAX_QUALS) return; + switch (known_scno(tcp)) { - case SYS_read: -#ifdef SYS_pread64 - case SYS_pread64: -#endif -#if defined SYS_pread SYS_pread64 != SYS_pread - case SYS_pread: -#endif -#ifdef SYS_recv - case SYS_recv: -#elif defined SYS_sub_recv - case SYS_sub_recv: -#endif -#ifdef SYS_recvfrom - case SYS_recvfrom: -#elif defined SYS_sub_recvfrom - case SYS_sub_recvfrom: -#endif - if (qual_flags[tcp-u_arg[0]] QUAL_READ) - dumpstr(tcp, tcp-u_arg[1], tcp-u_rval); - break; case SYS_write: #ifdef SYS_pwrite64 case SYS_pwrite64: @@ -550,12 +529,6 @@ struct tcb *tcp; if (qual_flags[tcp-u_arg[0]] QUAL_WRITE) dumpstr(tcp, tcp-u_arg[1], tcp-u_arg[2]); break; -#ifdef SYS_readv -case SYS_readv: -if (qual_flags[tcp-u_arg[0]] QUAL_READ) -dumpiov(tcp, tcp-u_arg[2], tcp-u_arg[1]); -break; -#endif #ifdef SYS_writev case SYS_writev: @@ -564,6 +537,39 @@ struct tcb *tcp; break; #endif } + + /* Don't bother dumping output if the sycall returned an error */ + if (syserror(tcp)) + return; + + switch (known_scno(tcp)) { + case SYS_read: +#ifdef SYS_pread64 + case SYS_pread64: +#endif +#if defined SYS_pread SYS_pread64 != SYS_pread + case SYS_pread: +#endif +#ifdef SYS_recv + case SYS_recv: +#elif defined SYS_sub_recv + case SYS_sub_recv: +#endif +#ifdef SYS_recvfrom + case SYS_recvfrom: +#elif defined SYS_sub_recvfrom + case SYS_sub_recvfrom: +#endif + if (qual_flags[tcp-u_arg[0]] QUAL_READ) + dumpstr(tcp, tcp-u_arg[1], tcp-u_rval); + break; +#ifdef SYS_readv +case SYS_readv: +if (qual_flags[tcp-u_arg[0]] QUAL_READ) +dumpiov(tcp, tcp-u_arg[2], tcp-u_arg[1]); +break; +#endif + } } #ifndef FREEBSD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350341: xserver-xorg: screen corrupted (using Radeon 9100 IGP)
On Thu, Jun 21, 2007 at 12:43:40AM +0200, Brice Goglin wrote: About a year ago, you reported a bug to the Debian BTS regarding the screen being corrupted on a Radeon 9100 IGP board. Did you reproduce this problem recently? With Xorg/Etch? With latest xserver-xorg-core and drivers? If not, I will close this bug in the next weeks. I don't believe I've actually seen the bug again since that day, so I assume it's either fixed or just incredibly unlikely. (And I've been tracking Sid on that machine that whole time.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428341: git-core: needs build-depend on openssl-dev
On Wed, Jun 13, 2007 at 07:29:11AM +, Gerrit Pape wrote: On Sun, Jun 10, 2007 at 07:50:20PM -0400, J. Bruce Fields wrote: After apt-get uild-dep git-core, a build of the latest git fails with In file included from convert-objects.c:1: cache.h:6:21: error: openssl/sha.h: No such file or directory What's the command you use to build git? I was just building by hand with make prefix=/usr/local all doc. It's fine with 'debian/rules build', it sets NO_OPENSSL=1 for the build process so that a different sha1 implementation is used. 'make NO_OPENSSL=1' should also work. Oh, OK, thanks, I should have tried the debian build first, sorry for the noise. (apt-get build-dep is a great time-saver when building stuff from source, even when I'm not using the debian build stuff; so other things being equal, it'd be great if we could err on the side of adding more build dependencies in cases like this. But if that's not OK for some reason, I'd understand.) Thanks!--b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428341: git-core: needs build-depend on openssl-dev
Package: git-core Severity: normal After apt-get uild-dep git-core, a build of the latest git fails with In file included from convert-objects.c:1: cache.h:6:21: error: openssl/sha.h: No such file or directory It appears that libssl-dev also needs to be installed. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.19 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8) Shell: /bin/sh linked to /bin/bash Versions of packages git-core depends on: ii libc6 2.5-10 GNU C Library: Shared libraries ii libcurl3-gnutls 7.15.5-1 Multi-protocol file transfer libra ii libdigest-sha1-perl 2.11-2 NIST SHA-1 message digest algorith ii liberror-perl 0.15-8 Perl module for error/exception ha ii libexpat1 1.95.8-3.4 XML parsing C library - runtime li ii perl-modules 5.8.8-7Core Perl modules ii rcs 5.7-18 The GNU Revision Control System ii zlib1g1:1.2.3-15 compression library - runtime Versions of packages git-core recommends: ii curl 7.16.2-4 Get a file from an HTTP, HTTPS or pn git-doc none (no description available) ii less 394-4 Pager program similar to more ii openssh-client [ssh-client] 1:4.3p2-10 Secure shell client, an rlogin/rsh ii patch 2.5.9-4Apply a diff file to an original ii python2.4.4-6An interactive high-level object-o ii rsync 2.6.9-3fast remote file copy program (lik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408345: wireshark: fix parsing of nfsv4 stateid
Package: wireshark Version: 0.99.4-4 Severity: normal Tags: patch Fix an obvious error in the nfs4 stateid parsing. The stateid is used in a number of common operations (such as open and setattr), so this caused a lot of misparsing. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20-rc5-g7a00406b Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8) Versions of packages wireshark depends on: ii libadns1 1.4-0.1 Asynchronous-capable DNS client li ii libatk1. 1.12.4-1The ATK accessibility toolkit ii libc62.3.6.ds1-10GNU C Library: Shared libraries ii libcairo 1.2.4-4 The Cairo 2D vector graphics libra ii libcap1 1:1.10-14 support for getting/setting POSIX. ii libcomer 1.39+1.40-WIP-2006.11.14+dfsg-1 common error description library ii libfontc 2.4.2-1 generic font configuration library ii libgcryp 1.2.3-2 LGPL Crypto library - runtime libr ii libglib2 2.12.6-2The GLib library of C routines ii libgnutl 1.4.4-3 the GNU TLS library - runtime libr ii libgpg-e 1.4-2 library for common error values an ii libgtk2. 2.8.20-4The GTK+ graphical user interface ii libkrb53 1.4.4-6 MIT Kerberos runtime libraries ii libpango 1.14.8-5Layout and rendering of internatio ii libpcap0 0.9.5-1 System interface for user-level pa ii libpcre3 6.7-1 Perl 5 Compatible Regular Expressi ii libporta 18.1-4 Portable audio I/O - shared librar ii libx11-6 2:1.0.3-4 X11 client-side library ii libxcurs 1.1.7-4 X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxfixe 1:4.0.1-5 X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-4 X11 Input extension library ii libxiner 1:1.0.1-4.1 X11 Xinerama extension library ii libxrand 2:1.1.0.2-5 X11 RandR extension library ii libxrend 1:0.9.1-3 X Rendering Extension client libra ii wireshar 0.99.4-4network traffic analyser (common f ii zlib1g 1:1.2.3-13 compression library - runtime Versions of packages wireshark recommends: ii gksu 2.0.0-1graphical frontend to su -- no debconf information commit 8f870c16fd014d13a7b43b553eaf3c3a1c17cd36 Author: J. Bruce Fields [EMAIL PROTECTED] Date: Wed Jan 24 23:49:33 2007 -0500 nfs: fix nfs4 stateid parsing Fix an obvious error in the nfs4 stateid parsing. The stateid is used in a number of common operations (such as open and setattr), so this caused a lot of misparsing. Signed-off-by: J. Bruce Fields [EMAIL PROTECTED] diff --git a/epan/dissectors/packet-nfs.c b/epan/dissectors/packet-nfs.c index eff0d23..ae4c0ab 100644 --- a/epan/dissectors/packet-nfs.c +++ b/epan/dissectors/packet-nfs.c @@ -6922,7 +6922,6 @@ dissect_nfs_stateid4(tvbuff_t *tvb, int offset, } offset = dissect_rpc_uint32(tvb, newftree, hf_nfs_seqid4, offset); - offset+=4; proto_tree_add_item(newftree, hf_nfs_stateid4_other, tvb, offset, 12, FALSE); offset+=12;
Bug#374994: cscope crashes while being driven by vim
This looks like the same bug as #132466; if I start up vim and do a ps, I see: 5019 pts/2S+ 0:00 view fs/nfsd/nfs4acl.c 5022 pts/2S+ 0:00 cscope -dl -f cscope.out strace'ing while I change vim's window size shows: Process 5022 attached - interrupt to quit read(0, 0xb7f4a000, 4096) = ? ERESTARTSYS (To be restarted) --- SIGWINCH (Window changed) @ 0 (0) --- --- SIGSEGV (Segmentation fault) @ 0 (0) --- Process 5022 detached and subsequent attempts to use cscope from within vim get error reading cscope connection 0 until I restart cscope (with :cscope reset), at which point it will last until the next time I resize the window. --b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365232: xserver-xorg-video-ati: freeze after resume on Thinkpad X31
Package: xserver-xorg-video-ati Version: 1:6.5.8.0-1 Severity: important I get a hard lockup shortly after an APM suspend-to-ram/resume cycle. (Very shortly after--at most some cursor movement is possible for a moment.) For now my workaound is to use Alt-Ctrl-F1 to switch to a text-only virtual terminal, suspend, resume, then switch back to X. That always works. This started failing after the big 6.9-7 transition; previously it's worked without fail for a few years. According to lspci, this is an ATI Technologies Inc Radeon Mobility M6 LY. Appended /etc/X11/xorg.conf /var/log/Xorg.0.log in case those are helpful /etc/X11/xorg.conf: -- # XF86Config-4 (XFree86 X server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type man XF86Config-4 at the shell prompt.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xfree86 # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom # md5sum /etc/X11/XF86Config-4 /var/lib/xfree86/XF86Config-4.md5sum # dpkg-reconfigure xserver-xfree86 Section Files FontPathunix/:7100# local font server # if the local font server has problems, we can fall back on these FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/CID FontPath/usr/lib/X11/fonts/Speedo FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module Loadglx Loaddri EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/psaux Option Protocol PS/2 EndSection Section InputDevice Identifier Generic Mouse Driver mouse Option SendCoreEventstrue Option Device/dev/input/mice Option Protocol ImPS/2 EndSection Section Device Identifier Radeon Mobility Driver ati # Option UseFBDev true EndSection Section Monitor Identifier builtin LCD HorizSync 28-50 VertRefresh 43-75 Option DPMS EndSection Section Screen Identifier Default Screen Device Radeon Mobility Monitor builtin LCD DefaultDepth24 SubSection Display Depth 1 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 4 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 8 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 15 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 16 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes 1024x768 800x600 640x480 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Generic Keyboard InputDevice Configured Mouse InputDevice Generic Mouse EndSection Section DRI Mode0666 EndSection --- /var/log/Xorg.0.log: --- X Window System Version 7.0.0 Release Date: 21 December 2005 X Protocol Version 11, Revision 0, Release 7.0 Build Operating System:Linux 2.6.12-1-686 i686 Current Operating System: Linux puzzle 2.6.17-rc2-CITI_NFS4_ALL-1-g497b5848 #193 PREEMPT Thu Apr 20 21:38:27 EDT 2006 i686 Build Date: 16 March 2006 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader
Bug#353216: libxklavier10: bizarrely misplaced Caps Lock is Compose option
Package: libxklavier10 Version: 2.1-1 Severity: normal The Caps Lock is Compose key option is currently under the Adding EuroSign to certain keys section of the Layout Options tab in the Gnome Keyboard Preferences dialog. The Compose key position section (or maybe CapsLock key behaviour section) would seem more reasonable. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-rc3-CITI_NFS4_ALL-1-g8698c9b9 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages libxklavier10 depends on: ii libc6 2.3.6-1 GNU C Library: Shared libraries an ii libx11-6 6.9.0.dfsg.1-4X Window System protocol client li ii libxkbfile16.9.0.dfsg.1-4X Keyboard Extension file parsing ii libxml22.6.23.dfsg.1-0.1 GNOME XML library ii zlib1g 1:1.2.3-9 compression library - runtime libxklavier10 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345836: netbase: add nfs entry to /etc/services
Package: netbase Version: 4.23 Severity: normal Tags: patch NFS has traditionally used port 2049. Though clients usually look up the port with portmap anyway, rfc3530 sets 2049 as the well known port. Therefore NFSv4 clients, at least, no longer depend on portmap. The NFS entries are also in http://www.iana.org/assignments/port-numbers, and development versions of rpc.gssd (www.citi.umich.edu/projects/nfsv4/linux/) expect to find it in /etc/exports. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-rc3-g1376481d Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages netbase depends on: ii debconf [debconf-2.0] 1.4.66 Debian configuration management sy ii ifupdown 0.6.7 high level tools to configure netw ii lsb-base 3.0-13 Linux Standard Base 3.0 init scrip ii netkit-inetd 0.10-10.2 The Internet Superserver ii netkit-ping [ping]0.10-10.2 The ping utility from netkit ii tcpd 7.6.dbs-8 Wietse Venema's TCP wrapper utilit netbase recommends no packages. -- debconf information excluded Add nfs port --- etc-services |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/etc-services b/etc-services index 215d8c8..e36a18d 100644 --- a/etc-services +++ b/etc-services @@ -277,6 +277,8 @@ radius-acct 1813/udpradacct unix-status1957/tcp# remstats unix-status server log-server 1958/tcp# remstats log server remoteping 1959/tcp# remstats remoteping server +nfs2049/tcp# Network File System +nfs2049/udp# Network File System rtcm-sc104 2101/tcp# RTCM SC-104 IANA 1/29/99 rtcm-sc104 2101/udp cvspserver 2401/tcp# CVS client/server operations
Bug#317545: ifp-line: documentation should reference plugdev group, not pmp-common
Package: ifp-line Version: 0.2.4.6-1 Severity: normal Tags: patch The pmp-common package seems to use the plugdev group now, not the pmp-driver group; update the last sentence of README.Debian to reflect this fact. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages ifp-line depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libusb-0.1-42:0.1.10a-16 userspace USB programming library Versions of packages ifp-line recommends: ii pmp-common2 hotplug scripts for portable music -- no debconf information --- debian/README.Debian~ 2005-07-09 11:01:08.0 -0400 +++ debian/README.Debian2005-07-09 11:01:39.0 -0400 @@ -45,6 +45,6 @@ 3. How can I let a non-root user use the `ifp' tool? Make sure you have 'pmp-common' installed (`apt-get install pmp-common') -and add the user to the pmp-driver group (`adduser user pmp-driver'). +and add the user to the plugdev group (`adduser user plugdev'). -- Joe Wreschnig [EMAIL PROTECTED], Sun, 22 Aug 2004 16:42:44 -0500
Bug#307222: gimp-help-en: inserted Czech (?) text in ch. 2 sec. 6.3
Package: gimp-help-en Version: 2+0.7-3 Severity: normal In chapter 2, section 6.3 (Improving Colors), under the heading Auto Levels, there is a paragraph inserted in some language other than english (Czech, maybe??). -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11.7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages gimp-help-en depends on: ii epiphany-browser [w 1.4.8-3 Intuitive GNOME web browser ii galeon [www-browser 1.3.20-1 GNOME web browser for advanced use ii gimp-help-common2+0.7-3 Data files for the GIMP documentat ii gimp-helpbrowser2.2.6-1 Built-in Help Browser plugin for T ii konqueror [www-brow 4:3.3.2-1KDE's advanced File Manager, Web B ii links [www-browser] 0.99+1.00pre12-1 Character mode WWW browser ii lynx [www-browser] 2.8.5-2 Text-mode WWW Browser ii mozilla-browser [ww 2:1.7.7-2The Mozilla Internet application s ii mozilla-firefox [ww 1.0.3-2 lightweight web browser based on M ii w3-el-e21 [www-brow 4.0pre.2001.10.27-16 Web browser for GNU Emacs 21 ii w3m [www-browser] 0.5.1-3 WWW browsable pager with excellent -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#257709: gnome-terminal: failing to paste accented characters
On Mon, Apr 18, 2005 at 11:50:40AM +0200, Sjoerd Simons wrote: At least e-mail (and probably newsgroups too) indicate which encoding there using in the headers. So a mail reader should convert from the mails locale to the terminals locale if possible (Which mutt does fine with for example this mail when in an utf-8 terminal).. That's not a problem of the terminal. With utf-8 set in gdm, gnome-terminal, and my .bashrc (my ssh login sessions seem to revert back to POSIX/C otherwise), that conversion works, in mutt, tin, and vi. Thanks! Apologies for my ignorance on this subject --b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#257709: gnome-terminal: failing to paste accented characters
On Mon, Apr 18, 2005 at 12:15:27AM +0100, Stewart Jeacocke wrote: retitle 257709 Silently fails to paste chars if locale doesn't support them. thanks If I try to cut and paste a piece of text from mozilla which contains, e.g., eacute;, the paste silently fails. Pasting the same text into, e.g., gedit, succeeds. The problem is that you are not using a UTF-8 (Unicode) system locale. Run # pkg-reconfigure locales and select a Unicode locale (eg en_GB.UTF-8) as the default system locale. Log out of GNOME and log back in. Launch gnome-terminal and check that the menu item Terminal - Set Character Encoding - Current Locale shows the UTF-8 locale. If so you should be able to paste any Unicode character that you like into gnome terminal. Of course it would be nice if gnome-terminal warned you when you tried to paste a string containing an unsupported character into the terminal rather that just silently failing the paste. This probably deserves to be forwarded upstream. Yeah, OK, thanks, that seems to explain the symptoms. As a practical problem, it seems that most of the email and newgroups I see are using iso-8859-1, so that's the only thing that seems to work as a default encoding for my terminal. --b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#257709: gnome-terminal: failing to paste accented characters
On Mon, Apr 18, 2005 at 12:39:57AM +0100, Stewart Jeacocke wrote: On Sun, 2005-04-17 at 19:26 -0400, J. Bruce Fields wrote: The problem is that you are not using a UTF-8 (Unicode) system locale. Run # pkg-reconfigure locales and select a Unicode locale (eg en_GB.UTF-8) as the default system locale. Log out of GNOME and log back in. Yeah, OK, thanks, that seems to explain the symptoms. As a practical problem, it seems that most of the email and newgroups I see are using iso-8859-1, so that's the only thing that seems to work as a default encoding for my terminal. I'm pretty sure that iso-8859-1 encoding is a subset of the Unicode encoding. So even when the locale is set to a Unicode encoding iso-8859-1 (extended ASCI) documents should still work fine (they seem to here). If they really don't then would you attach an example file that contains characters that fail to render with a Unicode locale? None of these: e with an acute accent: é e with a grace accent: è c with a cedille: ç show up if I choose UTF-8 in gnome-terminal. iso-8859-1 may be a subset of unicode in the sense that all the characters it encodes are also in unicode, but I don't believe that the iso-8859-1 encoding is a subset of UTF-8. I'm far from an expert on this, though --b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304599: libnfsidmap: New upstream release
On Thu, Apr 14, 2005 at 09:53:27AM +0200, Ghe Rivero wrote: Package: libnfsidmap Severity: normal New upstream version available at: http://www.citi.umich.edu/projects/nfsv4/linux/libnfsidmap/nfsidmap-0.10.tar.gz Is there any particular reason you need the new version? I do of course plan to upload a new version eventually, but I've been assuming it's a relatively low priority--b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303559: O: nfs-utils -- NFS support files common to client and server
On Thu, Apr 07, 2005 at 09:18:40AM -0400, Chip Salzenberg wrote: Package: wnpp Severity: important I have orphaned the source package nfs-utils (binary packages nfs-common, nfs-kernel-server, and nhfsstone). I'll help if I can, but have more experience with the nfs side than the debian side, so would probably need help from someone with more debian experience. --Bruce Fields -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300631: findutils: nfs4 should be included in list of excluded filesystems
Package: findutils Version: 4.1.20-6 Severity: normal The NFSv4 filesystem (nfs4) is also a network filesystem and should be included in the PRUNENFS list in /etc/updatedb.conf. (NFSv4 has experimental support in 2.6 kernels and currently has some (incomplete) userland support in Debian.) Note that it is implemented as a completely separate filesystem, not (like NFSv2 and NFSv3) as an nfs filesystem with mount options to distinguish the protocol version, so it does need a separate nfs4 entry in this list. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11-CITI_NFS4_ALL-5 Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US.ISO-8859-1) Versions of packages findutils depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]