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)

2020-06-17 Thread J. Bruce Fields
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

2020-06-17 Thread J. Bruce Fields
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)

2020-06-16 Thread J. Bruce Fields
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)

2020-06-15 Thread J. Bruce Fields
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)

2020-06-15 Thread J. Bruce Fields
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)

2020-06-15 Thread J. Bruce Fields
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

2013-08-15 Thread J. Bruce Fields
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

2013-08-12 Thread J. Bruce Fields
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

2013-03-07 Thread J. Bruce Fields
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

2008-08-07 Thread J. Bruce Fields
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)

2008-08-03 Thread J. Bruce Fields
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)

2008-08-02 Thread J. Bruce Fields
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

2007-12-09 Thread J. Bruce Fields
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

2007-12-09 Thread J. Bruce Fields
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

2007-12-05 Thread J. Bruce Fields
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

2007-08-06 Thread J. Bruce Fields
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)

2007-06-20 Thread J. Bruce Fields
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

2007-06-13 Thread J. Bruce Fields
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

2007-06-10 Thread J. Bruce Fields
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

2007-01-24 Thread J. Bruce Fields
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

2006-08-18 Thread J. Bruce Fields
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

2006-04-28 Thread J. Bruce Fields
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

2006-02-16 Thread J. Bruce Fields
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

2006-01-03 Thread J. Bruce Fields
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

2005-07-09 Thread J. Bruce Fields
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

2005-05-01 Thread J. Bruce Fields
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

2005-04-18 Thread J. Bruce Fields
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

2005-04-17 Thread J. Bruce Fields
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

2005-04-17 Thread J. Bruce Fields
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

2005-04-14 Thread J. Bruce Fields
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

2005-04-07 Thread J. Bruce Fields
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

2005-03-20 Thread J. Bruce Fields
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]