Re: RFC: changing the "+" in ls -l output to be "." or "+"

Vikram Noel Ambrose <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> wrote: ... if (SELinux, with no other MAC or ACL) use '.' else if (any other combination of alternate access methods) use '+' ... >>> Here's sample output, running on an SELinux

Re: "mkdir -p" in Makefile fails with installwatch of checkinstall in Mandriva 2009.0

vatbier <[EMAIL PROTECTED]> wrote: > Description of problem: > Mandriva 2009.0. > I use checkinstall to make an .rpm of x11vnc-0.9.4 > (http://www.karlrunge.com/x11vnc/ ): > ./configure > make > checkinstall > Checkinstall fails because the command "mkdir -p" in a Makefile fails with > installwa

Re: RFC: changing the "+" in ls -l output to be "." or "+"

Jim Meyering wrote: A desire for compatibility makes "+" look good. "." is appealing for SELinux-only because it's inconspicuous. Speaking as a fairly new SELinux user/admin, having a "." next to every file in my ls output is just as useful or non-useful as having a "+" next to them, so does

Re: RFC: changing the "+" in ls -l output to be "." or "+"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Mike Edenfield on 10/24/2008 7:19 AM: > Based on the kind of real-world problems I've had, the most useful thing > ls could tell me about a file on my SELinux system would be that it > *should* have a label and *doesn't*, something like: >

[PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them

Hello, as reported in https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/187315 by Aaron Toponce , chmod could display confusing messages when used for SGID/SUID/sticky bits without permissions to change them. e.g. with non-root sudoers user following scenario mkdir tmp;sudo chown .root tmp;

group-list warning

During the window of buggy autoconf, I saw this evidence of a latent bug for platforms that lack getgroups: group-list.c: In function `print_group_list': group-list.c:89: warning: control reaches end of non-void function OK to commit? From: Eric Blake <[EMAIL PROTECTED]> Date: Fri, 24 Oct 2008

Re: group-list warning

Eric Blake <[EMAIL PROTECTED]> wrote: > During the window of buggy autoconf, I saw this evidence of a latent bug for > platforms that lack getgroups: > > group-list.c: In function `print_group_list': > group-list.c:89: warning: control reaches end of non-void function > > OK to commit? > > From: Er

remove --bignum from 'factor'

Here's a patch to remove the --bignum and --no-bignum options from 'factor'. The case for removing --bignum isn't as strong as that for 'expr', but still, it seems to me that these options are not needed and complicate the documentation unnecessarily. Remove --bignum and --no-bignum from 'factor

Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them

Ondřej Vašík <[EMAIL PROTECTED]> writes: > - bool changed = (chmod_succeeded > - && mode_changed (file, old_mode, new_mode)); > + bool mode_change = mode_changed (file, old_mode, new_mode); > + bool changed = (chmod_succeeded && mode change); > + > + if (chmod

Re: remove --bignum from 'factor'

Paul Eggert wrote: > Here's a patch to remove the --bignum and --no-bignum options from > 'factor'. The case for removing --bignum isn't as strong as that for > 'expr', but still, it seems to me that these options are not needed and > complicate the documentation unnecessarily. > > > Remove --bi

seq regression on x86 in coreutils 7.0

Here's the bug: $ seq 9223372036854775807 9223372036854775808 9223372036854775807 9223372036854775808 9223372036854775809 This is Debian stable x86, compiled with GCC 4.3.2. This worked correctly in older 'seq' versions. The problem is that the 2008-04-14 seq patch introduced an abs_rel_diff fun