Re: bug#19148: ls --inode --sort=inode

[Eric Blake]

On 11/21/2014 07:52 PM, Glenn Morris wrote:
> Eric Blake wrote:
> 
>> Uggh. It seems like mail from me is NOT reaching the GNU mailing lists.
>>  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19148 shows that I clearly
>> replied to this bug, but
>> https://lists.gnu.org/archive/html/bug-coreutils/2014-11/index.html
>> shows only your reply, which came long after mine.  Could it be because
>> I am GPG-signing my emails, and mailman is eating mails with gpg
>> signatures?  If so, that is a recently relative event, because I haven't
>> changed anything on my end.  I'm wondering if the recent changes to turn
>> on https for debbugs and mailman is causing not just mine, but anyone
>> else sending signed mail, to get their messages eaten.
> 
> But mail doesn't go via http, so what could using https for the mailman
> web moderation interface possibly have to do with anything? Also, it's
> only the incoming mails on debbugs that go through mailman, and we can
> see that your mails are arriving fine.

You are right that my mail is getting past debbugs (because it got
archived in debbugs), so it appears that it is mailman doing the silent
dropping, and debbugs itself seems just fine.  Where I'm wondering is if
the recent configuration switch in mailman that turned https
administration on also tweaked something to make mailman drop
MIME-encoded signatures.  If nothing else, I picked help-debbugs to warn
other debbugs users that there may be bugs showing up in the bug
database but not reaching lists.

Nov 14 was the last time I see a mail from me with MIME-encoding
reaching the mailman archives, so the change is sometime in the last
week:
https://lists.gnu.org/archive/html/bug-coreutils/2014-11/msg00027.html;
I'll attach the original of that mail.

On a hunch, I just sent an inline gpg mail to bug-bash, another list
where I've noticed the problems.  My MIME-encoded signature sent on the
19th never made it to the list, but the inline version sent today made
it just fine (both outgoing mails attached, and here's the archive of
the inline version:
https://lists.gnu.org/archive/html/bug-bash/2014-11/msg00137.html). And
it's been a long time since I've been sending MIME-encoded gpg
signatures, with no problems until this week.

> 
> AFAICS debbugs.gnu.org is sending out your mails just fine,
> so I think you'll have to take this up with lists.gnu.org.

Who's the best person to contact on that front?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

--- Begin Message --- Subject: bash --debugger does nothing if debug script not installed Date: Wed, 19 Nov 2014 10:11:54 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

I wanted to play with debugging a bash script:

$ echo 'echo hello' > foo
$ bash --debugger foo
hello
$ sudo yum install bashdb -y
...
$ bash --debugger foo
bash debugger, bashdb, release 4.2-0.8

Copyright 2002, 2003, 2004, 2006, 2007, 2008, 2009, 2010, 2011 Rocky
Bernstein
This is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.

(/home/eblake/foo:1):
1:      echo hello
bashdb<0> run
Restarting with: ''
hello
$

I can understand why the --debugger option forwards to the bashdb script
when that is installed (that's obviously a choice that my distro
packager has made, to configure bash so that the --debugger option tries
to use /usr/bin/bashdb as its DEBUGGER_START_FILE; see
shell.c:start_debugger()).  But it was surprising to me that until I
installed bashdb, the --debugger option was silently ignored.  I was
expecting something like:

$ bash --debugger foo
bash: debug script /usr/bin/bashdb: file not found

to give me a heads up that I need to install bashdb.  Would it make
sense to make the explicit use of --debugger be fatal if a debugger
start file is configured but not present?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> bash --debugger does nothing if debug script not installed
>
>
>
>
> Date: 
>
> Fri, 21 Nov 2014 19:31:07 -0700
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
>
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> I wanted to play with debugging a bash script:
>
> $ echo 'echo hello' > foo
> $ bash --debugger foo
> hello
> $ sudo yum install bashdb -y
> ...
> $ bash --debugger foo
> bash debugger, bashdb, release 4.2-0.8
>
> Copyright 2002, 2003, 2004, 2006, 2007, 2008, 2009, 2010, 2011 Rocky
> Bernstein
> This is free software, covered by the GNU General Public License, and
> you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
>
> (/home/eblake/foo:1):
> 1:      echo hello
> bashdb<0> run
> Restarting with: ''
> hello
> $
>
> I can understand why the --debugger option forwards to the bashdb script
> when that is installed (that's obviously a choice that my distro
> packager has made, to configure bash so that the --debugger option tries
> to use /usr/bin/bashdb as its DEBUGGER_START_FILE; see
> shell.c:start_debugger()).  But it was surprising to me that until I
> installed bashdb, the --debugger option was silently ignored.  I was
> expecting something like:
>
> $ bash --debugger foo
> bash: debug script /usr/bin/bashdb: file not found
>
> to give me a heads up that I need to install bashdb.  Would it make
> sense to make the explicit use of --debugger be fatal if a debugger
> start file is configured but not present?
>
> - -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
>
> iQEcBAEBCAAGBQJUb/VrAAoJEKeha0olJ0NqyqQIAKFcVsgNs74wWGu2Q291BVti
> r/+JtPJVA5B4rBSPaog3+lJNor8IVWeTsR8MluPORGSStqPcbw8e+MKl9tUtFfZ0
> NrDKOgJJN0t1zJdM/pPkZlxjW7GWmm4Lknp6LOLon51npBNcq42lNEE+giO/j8zY
> aqjCdmHbAcFaJONC9uwn+YY8yAbor5XBwC4jHv4XXlYQjB/jlGopbkJ6LO4xXmI3
> 9Z7Irhtz4QGvaNLTzKD3JoFFc3biklGDNO3L7ACmd79ebSERBDP/XPeDUy6eDrp0
> /WjBVjpaGB+uRj2APSXo2Q6U6dH/kb7p9pFwKo3NFONBcvskaFKYagOXUSD76bw=
> =25Ju
> -----END PGP SIGNATURE-----
>
> --- End Message ---

--- Begin Message --- Subject: Re: bug#19051: rm symboliclink/ # "Is a directory" Date: Fri, 14 Nov 2014 07:47:44 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

On 11/14/2014 06:15 AM, Eric Blake wrote:

>> Confused me too when I encountered it first, but tt's required by POSIX:
>> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11
> 
> No, actually, POSIX requires that it (attempt to) remove the DIRECTORY,
> not the symlink.  Linux is intentionally in violation of POSIX on this
> front.
> 
> Try this on Solaris:
> 
> $ mkdir a
> $ ln -s a b
> $ rm b/
> $ ls -d ?
> b

Uggh, serves me right for typing without testing.  I'm mixing up
rename(), unlink(), and rmdir() semantics.  Basically,
unlink("anything/") is required by POSIX to fail because the trailing /
means that the only thing to be removed is a directory, but directories
can only be removed by rmdir(), not unlink().

Still, my point remains when you use 'rm -r b/': on Linux, it fails
(cannot remove 'b/': Not a directory), on Solaris it succeeds at
removing 'a' and leaving 'b' dangling.

The fact that Linux intentionally violates POSIX on some of the corner
cases related to symlinks to directories makes it harder to definitively
state what coreutils should do.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature

--- End Message ---

signature.asc
Description: OpenPGP digital signature