http://www.gnu.org/software/inetutils/manual/ apparently hasn't been
updated for the latest release (1.8).
Also, I suggest removing the @shortcontents or @summarycontents from
inetutils.texi. There are relatively few subnodes in the manual, so
having the short contents basically doubles the lengt
All the other ftp programs I've seen support -p to mean switch into
passive mode by default. This is very useful, since so many places
(such as fencepost :() are configured to only work with passive mode.
Printing a command line prompt when not on a tty seems very obscure by
comparison. How abou
Please do, I couldn't figure out how to create foo-inetutils@ via the
web interface, it only wanted to create inetutils-foo@ ...
Indeed, it is not possible to create foo-pkgname for any foo, sorry I
forgot about that. (Only the standard {bug,help,info}-inetutils.)
Before I create the lis
I'll take care of it as soon as I can remeber whom to poke about
mailing lists.
You don't have to poke anyone. Lists can be created through savannah.
https://savannah.gnu.org/mail/?group=inetutils
If you like I will create build-inetutils there and remove the alias on
fencepost.
To: build-inetut...@gnu.org
After just a few hours ... Can we make this a separate list?
I for one am interested in following what's happening, but not in
receiving build reports.
Is there anyone who builds inetutils without GNU make?
I don't know, but if we want GNU inetutils to have a chance of being
adopted, best not to put up additional barriers if they can be avoided.
People do use BSD make, Solaris make, etc., to compile GNU utilities in
general.
Is it possible to make the CVS repository read-only?
How about disabling the CVS "feature" in the savannah project?
(The actual ,v files would still exist.)
We would like your help, but as with all free software projects,
most of the initiative must be done by the contributor.
Please find something that interests you in the project, make some
work on it and send a patch when you feel you have something. The TODO
file contains a li
All contributions to inetutils are licensed under the GPL
It's common practice in GNU to keep the license of the original code, in
the spirit of allowing the original upstream authors to benefit from our
improvements. For example, rms specifically said that our changes to
firefox to make icec
I often need to use `ping -c 1 gnu.org'
Not to be obvious, but my suggestion is, use an alias. That's what
aliases are for.
have to resolve the conflict somehow, breaking things in the process
no matter what we do.
FWIW, I very strongly disagree that shortening the above command by
Think of `sort -2' etc, which had also been there
since inception, but that was deprected.
Well, that deprecation (and coreutils' slavish adherence to it) was,
IMHO, an incredibly stupid idea, not an improvement in any way.
It broke many scripts which ran perfectly fine since day one of Un
After the patch I installed to inetutils [1],
Which is good, thanks.
So in gnulib, I propose we deprecated 'fdl' and ask maintainers to
depend directly on 'fdl-1.3' or whatever version they need. Thoughts?
Makes sense to me.
doc/fdl.texi is removed below
If I'm understanding correctly, removing fdl.texi seems wrong to me.
I'm supposing it's created dynamically from a copy in gnulib or
somewhere now? But the license can't be updated merely by changing that
file. The @copying block has to be updated also. In fact
Paper work is already finished.
That's strange. Your name does not appear in the
/gd/gnuorg/copyright.list file where all papers are supposed to be
recorded. Did you get the confirmation back from the copyright clerk?
karl
LGPL2.1 is compatible with GPL version 3 and later.
So if a library is released under LGPL 2.1, it can be used
in inetutils.
But isn't there a difference between something licensed under
LGPLv2.1-only and LGPLv2.1-or-later? We don't want dependencies on
packages licensed under anythin
Hm. Was thinking that we could remove the r* utilities, is anyone
actually using those?
Aside from the case of old machines that Debarshi mentioned, they can
still be useful in a small internal network environment where all hosts
(and the wire) can be trusted.
In general, they have bee
Does someone know where one can find the most recent version of
finger{,d}? Or is it the stuff in ftp.gnu.org:/gnu/old-gnu/finger
that is the latest?
It is the latest as far as I know.
karl
___
bug-inetutils mailing list
bug-inetutils@gnu
I did a checkout && bootstrap && make of inetutils, and now cvs update
reports:
? ._bootmp
? ._bootmp2
? config.h
? confpaths.h
? stamp-h1
? build-aux/.cvsignore
? build-aux/ylwrap
? lib/.cvsignore
? lib/Makefile
? lib/Makefile.in
? lib/charset.alias
? lib/configmake.h
? m4/.cvsignore
Wdyt about
rms gave his blessing to decommissioning finger as a separate package
and incorporating it in inetutils. So please go ahead with that.
(Chris Cooper has remained uncontactable.)
The finger areas on ftp.gnu.org and www.gnu.org will be updated to
reflect this soonly.
FWIW, I note there is another
Any update on this?
I've already written to some alternative addresses for Chris Cooper,
with no luck -- either no answer or it's the wrong Chris Cooper.
As it happens, rms and I are in the process of dealing with
uncontactable GNU maintainers. I'll write him now about Chris and get
back to
Could you ask him at the same time if we can use finger in inetutils?
Yes, I will suggest that.
Is it copyrighted by the FSF?
I believe so. I'll check for sure.
___
bug-inetutils mailing list
bug-inetutils@gnu.org
http://lists.gnu.org/mail
But I agree, if we do not get a reply by Feb. 14th, then we should
talk with RMS.
Aside from not working on finger, Chris has also failed to respond to
any of rms/my previous emails about things (contact info, GPLv3, etc.).
I'll ask rms about taking him out of the maintainers file in a fe
Could you convince the fencepost sysadmins to install fingerd again,
You mean so that remote finger works? My experience is that they are
unwilling to run any Internet-accessible service that is not absolutely
crucial, by their definition of crucial.
If you just mean locally, running "finger
Wdyt about including finger in inetutils?
Perhaps some of the code from the 15-year-old distribution on
ftp.gnu.org could be reused. Perhaps not :). It doesn't really seem
like it needs to be a separate package.
Thanks,
Karl
___
bug-inetutils mailin
could you test it once just to see that it works?
Worked fine, except there's a typo in the comment :). Fixed below.
Also, here again is the change to cmds.c to send the NOOP.
Thanks,
Karl
Index: cmds.c
===
RCS file: /sources/i
I really do not like to ignore signals
I hear you, but SIGPIPE is documented in this case, and we definitely
don't want to just crash with it, and we're doing the right thing
(disconnecting) if we see it.
Seems like the only alternative is the inferior-to-the-user choice of
invariably discon
Typo in inetutils.texi:
-* inetd: (inetutils)inetd invocation. Interner super-server.
+* inetd: (inetutils)inetd invocation. Internet super-server.
(At least not everything I report requires exhausting analysis and
debugging. :)
karl
_
Try doing this (somewhere) instead: signal (SIGPIPE, SIG_IGN);
Yep. I put that just before the NOOP, and now it works! I would guess
the handler should be saved and restored, but I'll leave that to you.
My diff from cvs below.
Thanks for persevering with me on this ...
karl
--- cmds.c
Can you put a break point at the fflush, and then examine the
content in gdb
Sadly, both the cout FILE structure and struct stat from fstat are
identical in each of the two cases (connection still open & connection
died). So I see no way to know in advance that it's going to failure.
Been trying to reproduce this, but I cannot, admitably I'm using CVS
I checked out inetutils from CVS.
The sigpipe still happens for me on my machine after letting the
connection silently time out -- not 100% of the time, but >90%. I'll
append the backtrace, not that it's especially illuminat
I assume that the change works, so I'll apply it soon. Thanks.
Sorry to be unclear. It doesn't work. My change was just restoring the
warning in the case that the connection was truly open. It doesn't
solve the SIGPIPE problem. (Again, this was in the case where we wait
without doing anyt
By the way, we previously discussed making "open" without any args
attempt to reopen the host from the command line (or previous open). Is
this still pending? (If it is, that's fine, of course, just didn't want
it to have been lost.) In inetutils 1.5, I still get the mysterious
error:
$ ftp alp
+ if (connected &&
+ command ("NOOP") != COMPLETE)
When the connection has closed, I now get a SIGPIPE in the NOOP,
specifically at the fflush(cout); at line 369 of ftp.c (in inetutils 1.5,
sorry, I don't have a CVS checkout just now.)
If it's not too hard to fix that, I do think i
Could you ask the fellow that we are most interested in the features
that we don't have in GNU ping to be added to GNU ping, but that
having two ping's in GNU that do the same thing, doesn't make much
sense?
That is exactly what I told him.
Sorry I didn't realize about GNU ping al
-{
- printf ("Already connected to %s, use close first.\n", hostname);
- code = -1;
- return;
-}
+disconnect (0, 0);
It solves the stated issue, but introduces another: now if I do
ftp> open alpha.gnu.org
... gets connected, then, without any del
Like I said, I definitely don't suggest that we accept his python
program as the new ping (it was hardly a drop-in replacement anyway) --
I did decline. I only forwarded the info since I wasn't sure if our
ping already had the functionality.
___
bug-in
A fellow has offered a new program to GNU, an enhanced ping implemented
in Python. I can't see that it makes any sense to think about adding
this to GNU per se, but I thought you might be interested in the
additional features he claims it has, and consider them for GNU ping:
http://www.nongnu.org
ftp> ls
421 Timeout.
Try the open *without* that ls first -- just do an open when the
connection is closed, and I hope you'll see it. It's been in ftp since
the Arpanet or so :).
What version of GNU ftp are you using?
ftp (GNU inetutils) 1.5. (I compiled it from the source on prep.
One minor niglet in ftp that has always caught me is that you can't
reopen a closed connection without an explicit close first. For
instance:
$ ftp ftp.gnu.org
...
# wait a few minutes, so the connection gets closed.
ftp> open ftp.gnu.org
Already connected to ftp.gnu.org, use close first.
Well,
Hello inetutilitarians,
The inetutils manual still uses the old @ifinfo stuff for the Info dir
entries. Here's a patch to make it play nicely with the categories used
in other projects, etc.
Also, it should be changed to use @copying for the permission notice
(which should come before the dir en
So do I, hence why I'm going to break compatibility when we have had a
previously connected host and only prompt interactivley if there
wasn't. Do you think that would be fine?
Yep. Thanks.
___
bug-inetutils mailing list
bug-inetutils@gnu
ftp> open
(to) _!_
I know. Personally, I'd find it much more useful to re-open the
"previous" site and just give a diagnostic if there isn't one.
Thanks for your consideration.
___
bug-inetutils mailing list
bug-inetutils@gnu.org
http://lists
to figure out what interfaces are avaiable on the host.
Ok, true enough.
___
bug-inetutils mailing list
bug-inetutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-inetutils
With ftp 1.5, the simple command:
ftp> open
gets the error:
sorry, arguments too long
Too long? Too short I could understand :).
However, I suggest an enhancement: have open without an argument re-open
the previous host, if there is one. E.g.,
ftp ftp.gnu.org
... connects ...
ftp> close
221 G
Some picky stuff in inetutils 1.5.
First, I suggest that ifconfig be installed in $(sbindir) instead of
$(bindir). It seems like nearly the canonical example of an sbin
program.
Second, stuff about --version:
1) the first line of the ping --version output is:
ping - GNU inetutils 1.5
For co
45 matches
Mail list logo
