Re: [Savannah-hackers-public] Problem with Mailman

2024-02-21 Thread Alfred M. Szmidt
Bandali reported that lists.gnu.org ran out of disk space, and
escalated that to sysadmin@.

There was a spike in spam on Monday as well .. so might be
afterquakes...



Re: [Savannah-hackers-public] SubversionException: 13 - Can't open file '/srv/svn/gnueval/db/fs-type': Permission denied

2024-01-05 Thread Alfred M. Szmidt
   Thank you for this report.  I don't know why but the permissions on
   that one file were incorrect.

   drwxrws--- 6 root gnueval 253 Nov  9 11:34 /srv/svn/gnueval/db

Yeah, I cannot explain it .. the gnueval repository is not heavily
used.  I have one job that runs a `svn update' to send out a
periodical email.  But that is it.

Thanks for the fix.





[Savannah-hackers-public] SubversionException: 13 - Can't open file '/srv/svn/gnueval/db/fs-type': Permission denied

2024-01-04 Thread Alfred M. Szmidt
E.g., https://svn.savannah.gnu.org/viewvc/?root=gnueval ->

An Exception Has Occurred

Python Traceback

Traceback (most recent call last):
  File "/usr/lib/viewvc/lib/viewvc.py", line 4322, in main
request.run_viewvc()
  File "/usr/lib/viewvc/lib/viewvc.py", line 268, in run_viewvc
self.repos.open()
  File "/usr/lib/viewvc/lib/vclib/svn/svn_repos.py", line 403, in open
self.repos = repos.svn_repos_open(self.rootpath)
  File "/usr/lib/python2.7/dist-packages/libsvn/repos.py", line 216, in 
svn_repos_open
return _repos.svn_repos_open(*args)
SubversionException: 13 - Can't open file '/srv/svn/gnueval/db/fs-type': 
Permission denied


or

make: Entering directory '/srv/data/home/a/ams/gnueval'
svn update
Updating '.':
svn: E170013: Unable to connect to a repository at URL 
'svn://svn.savannah.gnu.org/gnueval'
svn: E13: Can't open file '/srv/svn/gnueval/db/fs-type': Permission denied
Makefile:24: recipe for target 'pending-report-mail' failed
make: *** [pending-report-mail] Error 1
make: Leaving directory '/srv/data/home/a/ams/gnueval'





[Savannah-hackers-public] please get rid of this nuisance message from sv_membersh

2023-10-16 Thread Alfred M. Szmidt
Can we please turn this nuisance off?  It is nothing related to the
AGPL in any shape or form.

You even get this utter garbage when doing an rsync?!

...
sv_membersh is part of Savane.
In order to download the corresponding source code of Savane, run

  rsync -avz --cvs-exclude a...@cvs.savannah.nongnu.org:/opt/src/savane .

...


This is a total misreading of the AGPL and just a waste of peoples
energy.



Re: [Savannah-hackers-public] verbose cvs -q update

2023-09-11 Thread Alfred M. Szmidt
   > I believe users who authenticate do interact with sv_membersh
   > in a way analogous to the frontend PHP code invoked through Apache.
   > 
   > I don't agree that the AGPL requires this message to be shown on every
   > cvs update. It's one possible interpretation, but not the only one.

   No, but it does require a prominent offer to be shown every user
   connecting through a network.  Have you any better ideas for how
   to implement it?

That is not what the GNU AGPL requires or say.  Karl already raised
this: You are not interacting with the sv_membersh.  I as a user am
not talking to the script in any shape or form, just like I am not
interacting to your editor of choise when you wrote your email.

   > When I run cvs on my machine *I* am not interacting with sv_membersh.
   > I'm just running CVS, which obviously knows nothing about sv_membersh.
   > It's the savannah implementation doing the interaction.

   Sorry.

   When I run a web browser on my machine *I* am not interacting with
   Savane PHP code.  I'm just running my web browser, which obviously
   knows nothing about Savane PHP code.  It's the savannah
   implementation doing the interaction.

The GNU AGPL is not concerned where you are running the program, in
the case of Savane PHP you are _DEFINITLY_ interacting with it.  It is
no more different than a Dungeon crawler written in PH.


Karl is right, this is just annoying and not required.



Re: [Savannah-hackers-public] stale directory in CVS-managed WWW pages for groff project

2023-09-01 Thread Alfred M. Szmidt
   Thank you for your help!

Happy hacking!



Re: [Savannah-hackers-public] stale directory in CVS-managed WWW pages for groff project

2023-09-01 Thread Alfred M. Szmidt
   It looks like I need some coaching with CVS.  It's been a long, long
   time since I used it daily.

No worries, same here .. trying to recall.

   > $ cvsu   
   > X manual/html_node

   $ cvsu
   cvsu: command not found

   I assume you had a typo, but for what, I'm not sure.

Not a typo, it is part of the cvsutils package.

   $ cvs update -PAd

Right, cvs update will try to add the files back.  Did you do remove?
You also need to do commit after.  So basically,

cvs remove foo.html;
cvs commit -m "foo.html: Delete." foo.html

If my memory serves me right.  I would suggest, just to be on the safe
side, to do it in a fresh checkout.

_IF_ you want, you can add me to the groff project, and I can wipe
those files.



Re: [Savannah-hackers-public] stale directory in CVS-managed WWW pages for groff project

2023-08-26 Thread Alfred M. Szmidt
   >https://web.cvs.savannah.gnu.org/viewvc/groff/groff/manual/

   If you open that URL you will find a directory:

   https://web.cvs.savannah.gnu.org/viewvc/groff/groff/manual/html_node/

Yes, that directory exists.

   alongside this one:

   https://web.cvs.savannah.gnu.org/viewvc/groff/groff/manual/groff.html.node/

So does this one.

   I asked my CVS checkout what the status of the former is.

   $ cvs status | grep html_node || echo NO RESULT
   cvs status: Examining .
   NO RESULT

Which, given a fresh checkout, does not return NO RESULT; since the
directory html_node exists in CVS.

So the question remains, how did you checkout, and what did you do in
your directory.  I would _guess_ that you've removed it locally, but
never done the cvs step of removing it.

E.g., in a fresh checkout, I do

$ rm -rf manual/html_node 
$ cvs status|grep html_node||echo NO RESULT
cvs2 status: Examining .
cvs2 status: Examining manual
cvs2 status: Examining manual/groff.html.node
NO RESULT
$ cvsu   
X manual/html_node

And I will bet that if you do "cvs update -PAd" .. you will once again
have that directory.

To remove it, you need to do "cvs remove manual/html_node" -- or
similar.



Re: [Savannah-hackers-public] stale directory in CVS-managed WWW pages for groff project

2023-08-26 Thread Alfred M. Szmidt
   There is a stale directory in the GNU groff project's website.

   https://www.gnu.org/software/groff/manual/html_node/

   This corresponds to the groff 1.22.4 release, which is nearly 5 years
   old.

   The directory also shows up in ViewVC.

   https://web.cvs.savannah.gnu.org/viewvc/groff/groff/manual/

   However it is _not_ present in my CVS checkout.

How did you checkout your directory?  What did you do in your
checkout?

I did a fresh checkout, and manual/ is there, as it should be from the
looks of it.  So it is not stale, might be out-dated, but that is
becuase nobody removed it.

   My memories of CVS are that it didn't handle symlinks well.

   Does this require administrative intervention?

I'm not sure what intervention is needed, manual/ is part of the
source tree, nobody (you?) never removed it.



Re: [Savannah-hackers-public] gnu coding standards

2023-06-20 Thread Alfred M. Szmidt
   >> Savannah Hackers, would you please add Alfred?
   > 
   >Alfred was added to gnustandards on 2023-06-18.
   > 
   > Not as admin.  Brandon is no longer active.

   Done; I've also added you to the 'www' group where the generated output
   is posted, in prep/.

   Please be more specific if anything else is needed.

Sorry, though it was.  Thanks for the help!



Re: [Savannah-hackers-public] gnu coding standards

2023-06-20 Thread Alfred M. Szmidt
   > Savannah Hackers, would you please add Alfred?

   Alfred was added to gnustandards on 2023-06-18.

Not as admin.  Brandon is no longer active.



Re: [Savannah-hackers-public] gnu coding standards

2023-06-19 Thread Alfred M. Szmidt
   >  > And some rule on what can "automatically" go into the GCS without 
your
   >  > explicit review and approval.
   >
   >Normally all changes in the GNU standards have to be approved by me,
   >though it would be ok to fix a trivial typo.
   >
   > Fair enough.  I'm still waitig for Savannah admins to add me to the
   > gnustandards project.

   Got a pointer to the issue tracker entry for this?

No, only this email.



Re: [Savannah-hackers-public] gnu coding standards

2023-06-18 Thread Alfred M. Szmidt


   [[[ To any NSA and FBI agents reading my email: please consider]]]
   [[[ whether defending the US Constitution against all enemies, ]]]
   [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

 > And some rule on what can "automatically" go into the GCS without your
 > explicit review and approval.

   Normally all changes in the GNU standards have to be approved by me,
   though it would be ok to fix a trivial typo.

Fair enough.  I'm still waitig for Savannah admins to add me to the
gnustandards project.



Re: [Savannah-hackers-public] gnu coding standards

2023-06-11 Thread Alfred M. Szmidt
 > *waves hand as volunteer* I could do it, it isn't that much work.

   Thank you for volunteering -- please take up the responsibility.
   Do you need anyone else's help to do that?

Only admin access to https://savannah.gnu.org/projects/gnustandards --
CCing savannah hackers.

And some rule on what can "automatically" go into the GCS without your
explicit review and approval.



Re: [Savannah-hackers-public] Please disallow www-commits in robots.txt

2023-05-12 Thread Alfred M. Szmidt
   That sounds reasonable to me. I would assume that if webmasters don't
   have access to change robots.txt, it would just be the fsf tech team.

They do.  It is in www.

I'm still sorta opposing this .. we have always been transparant.
That search engines "have no business" is as saying that other GNU
hackers have no business looking at www-commits, www-discuss, or
whatever.  It is anti-social.  We aren't publishing sensetive information...



Re: [Savannah-hackers-public] Please disallow www-commits in robots.txt

2023-05-12 Thread Alfred M. Szmidt
Might be worth noting that www.gnu.org is mostly usable locally from
the CVS checkout as well, if one needs to look things over.

So a patch to www-discuss@ or whatever for a unpublished article would
be sufficient in postponing any publishing.  It would just be a matter
of applying the patch, and looking at the web pages locally to see
what is or isn't.



Re: [Savannah-hackers-public] Please disallow www-commits in robots.txt

2023-05-10 Thread Alfred M. Szmidt


   Le 10/05/2023 à 20:50, Alfred M. Szmidt a écrit :
   > > You've not explained the actual problem.  What are you trying to
   > > solve?
   > 
   > "it" is the www-commits list, which registers all changes to the www
   > directory, including to pages that are not published yet. I suspect 
most
   > of the other *-commits lists deal with source code repositories, which
   > are public anyway.
   > 
   > If you wish to disallow access to pages, do not publish them --
   > www-commits is a public list, the www repository is a public
   > repository -- any commit is by definition published.  It is no
   > different than getting bug reports for commits in a software
   > repository that still hasn't had a release.
   > 
   > If you let crawlers access changes to disallowed directories, you are
   > defeating the purpose of robots.txt. What was supposed to be 
unpublished
   > is actually published.
   > 
   > The purpose of robots.txt is to avoid overloading a web site, it is
   > not to disallow access to pages.
   > 
   > This still does not explain what the problem is -- "don't let crawlers
   > crawl" doesn't explain it.  What are you trying to solve?  That
   > unpublished articles are not published before they are finished?

   Yes, basically. The purpose of the staging area is to work on articles
   that are not ready yet.

What about putting such articles / pages on fp? Or sharing them on
some internal list?




Re: [Savannah-hackers-public] Please disallow www-commits in robots.txt

2023-05-10 Thread Alfred M. Szmidt
   > You've not explained the actual problem.  What are you trying to
   > solve?

   "it" is the www-commits list, which registers all changes to the www
   directory, including to pages that are not published yet. I suspect most
   of the other *-commits lists deal with source code repositories, which
   are public anyway.

If you wish to disallow access to pages, do not publish them --
www-commits is a public list, the www repository is a public
repository -- any commit is by definition published.  It is no
different than getting bug reports for commits in a software
repository that still hasn't had a release.

   If you let crawlers access changes to disallowed directories, you are
   defeating the purpose of robots.txt. What was supposed to be unpublished
   is actually published.

The purpose of robots.txt is to avoid overloading a web site, it is
not to disallow access to pages.

This still does not explain what the problem is -- "don't let crawlers
crawl" doesn't explain it.  What are you trying to solve?  That
unpublished articles are not published before they are finished? 



Re: [Savannah-hackers-public] Please disallow www-commits in robots.txt

2023-05-10 Thread Alfred M. Szmidt
   Because it registers every single commit to www, 

What is "it"?  How is this different from _any_ -commits list we have?

   including to working directories that webmasters have disallowed,
   for instance */po/, /server/staging/, */workshop/, /prep/gnumaint/,
   etc.

Ok, and?  

   Please see https://www.gnu.org/robots.txt.

And?

You've not explained the actual problem.  What are you trying to
solve?



Re: [Savannah-hackers-public] Please disallow www-commits in robots.txt

2023-05-10 Thread Alfred M. Szmidt
   I was searching for an article with DuckDuckGo, and guess what
   appeared on top of the results...
   https://lists.gnu.org/archive/html/www-commits/2023-05/msg00082.html
   and
   https://lists.gnu.org/archive/html/www-commits/2023-05/msg00062.html
   !!

What is the problem?

   I understand it wouldn't be practical to make this list private,
   but it could at least be off-limits for crawlers.

How is www-commits different from anything else?  



Re: [Savannah-hackers-public] Delays in mail delivery by gnu.org mailing lists

2022-09-29 Thread Alfred M. Szmidt


   Lately, mail delivery by gnu.org mailing lists intermittently suffers
   from very long delays.  For example, currently emacs-devel and
   help-gnu-emacs mail is delivered with delays between 45 minutes and
   1.5 hours (based on admittedly small and potentially
   non-representative sample).

   This happens a lot during the last days.

   What causes this?  Can this be improved?  TIA.

I've not seen any specific delays, but that doesn't mean that there
aren't any.  So this is more of an ACK that someone read this specific
email...

Usually, though Savannah hackers are fast, mail related issues is
handled by the FSF so ... sysad...@gnu.org, CC forward there.


   P.S. https://hostux.social/@fsfstatus is as usual not helpful.






Re: [Savannah-hackers-public] Sending email via fencepost fails

2022-08-25 Thread Alfred M. Szmidt
Sometimes, some of us subscribed here, can also ping the FSF admins in
other ways -- sysadmin@ is not a list that is easily subscribed to
AFAIK.



Re: [Savannah-hackers-public] Sending email via fencepost fails

2022-08-22 Thread Alfred M. Szmidt
   But the gripe about the FSF Status page is real: lately I find it less
   and less useful in such cases.  Which is too bad.

Just to give a small shout, I agree.



Re: [Savannah-hackers-public] Email address no more hidden

2020-07-28 Thread Alfred M. Szmidt
This is I think better directed to the FSF sysadmins.  CCing.

   > Date: Tue, 28 Jul 2020 09:54:28 +0200 (CEST)
   > From: Angelo Graziosi 
   > 
   > I noticed that reading the post online 
(https://lists.gnu.org/archive/html/emacs-devel/2020-07/index.html, for 
example), the email address in citation is not substituted with "addres@hidden" 
any more, so would be desirable to avoid email address in citation when 
replaying to an email.
   > 
   > The "address@hidden" starts to disappear between May 26-27

   The above message was posted today to the emacs-devel mailing list.  I
   verified that Angelo is factually correct, and that the corresponding
   setting of the emacs-devel list still says to make the addresses not
   recognizable.

   So why is this happening?

   TIA






Re: [Savannah-hackers-public] Emacs git repository clone limits

2020-05-27 Thread Alfred M. Szmidt
Why not simply use a reference repository?

  git clone --mirror git://git.gnu.org/emacs.git ~/emacs-reference

And when cloning:

  git clone --reference ~/emacs-reference git://git.gnu.org/emacs.git 

the ~/emacs-reference place can be accessible where ever you are using
it.  This will work incrementally, and not use up scares resources..



Re: [Savannah-hackers-public] Shutting down the old frontend?

2017-03-24 Thread Alfred M. Szmidt
   > Is there any reason we can't shutdown the old frontend now?  I can't
   > think of anything that is still using it.  I think the time has come
   > that we can now shutdown halt the old frontend.

   I moved the content of frontend:/root
   into frontend0:/root/old-frontend-root -
   it had some files and scripts from various admins, some might be useful 
(didn't go through it, yet).

Tip, always name things with a date.  In 1, 10, 20 years you will
wonder when that directory was created. ;-)



Re: [Savannah-hackers-public] [gnu.org #1162706] Website DOWN

2016-11-07 Thread Alfred M. Szmidt
I have forwarded this to the Chapters/Planet admin(s).




Re: [Savannah-hackers-public] New Wiki page explaining when/how to contact FSF sysadmins

2016-04-28 Thread Alfred M. Szmidt
   Comments, suggestions and improvements welcomed.

I like it.  Maybe put it into the GNU maintainers guide as well?



Re: [Savannah-hackers-public] Web CVS server unavailable

2016-04-21 Thread Alfred M. Szmidt
Maybe incorperate it with the Free Software Directory somehow, there
could be an icon showing that a package is available in Guix; and
which version. 



Re: [Savannah-hackers-public] Web CVS server unavailable

2016-04-21 Thread Alfred M. Szmidt
   It’s clear that CVS is a hindrance for such purposes so if there’s
   another possibility,

   Ludo, why must we go through this yet again?  Surely you know perfectly
   well by now that there is no other possibility at present.  

Not to mention that it isn't a problem with CVS; git would have
similar issues down the line; and the file as such is heavy for the
network pipe on both ends -- it is a 7MiB download.



Re: [Savannah-hackers-public] Savannah and the present

2016-02-05 Thread Alfred M. Szmidt
   Perhaps Savannah is not suited for the purpose of replacing Github,
   but at the very least the FSF should sponsor sites like:

   https://notabug.org/

   which are based on free software and host exclusively free software
   (unlike Github, which accepts proprietary programs).

It seems that http://notabug.org also accepts non-free programs, for
example:

  https://notabug.org/nelis/hg-shopp-theme

This has no license information what so ever.  If this is in error or
not, I don't know.  

   > This also keeps Javascript requirements to minimum - which is
   > another added bonus for some.

   Github does not require JavaScript and can be completely operated
   by a free command line program that uses their API called "hub".

>From what I recall this is not entierly correct, to be able to use
github you need an account -- that requires non-free javascript.

   If it's perceived as something old and clunky, we can't expect
   people to support it, and consequently, many people will not make
   their programs part of the GNU project, which often means releasing
   them under permissive licenses to satisfy the "open source"
   supporters who think the GPL is "viral" and "restrictive" and they
   "wouldn't touch any GPL code".

People who call the GPL "viral", and "restrictive" are already people
who would be unwilling to use Savannah, since they are already hostile
to the idea of computer user freedom -- it doesn't matter to them what
Savannah looks like.

The goal of Savannah, and the GNU project isn't to make more GNU
projects -- it is to provide a free software hosting platform and a
free operating system.





Re: [Savannah-hackers-public] Savannah and the present

2016-02-05 Thread Alfred M. Szmidt
   > It seems that http://notabug.org also accepts non-free programs, for
   > example:
   > 
   >   https://notabug.org/nelis/hg-shopp-theme
   > 
   > This has no license information what so ever.  If this is in error or
   > not, I don't know. 

   This should have not happened, according to what I know. I'm putting the
   NAB admin in CC, hoping he will give you a satisfying answer.

Thank you.

   > People who call the GPL "viral", and "restrictive" are already people
   > who would be unwilling to use Savannah, since they are already hostile
   > to the idea of computer user freedom -- it doesn't matter to them what
   > Savannah looks like.

   But it gives them some arguments in favor of their labelling of the GNU
   Project as elitist and dated ("just look at Savannah").

People who are hostile toward our goals will always find an excuse to
call us names and attack us, there is little we can do about it.  If
we have a "pretty" web page, they will attack us for that.

   > The goal of Savannah, and the GNU project isn't to make more GNU
   > projects -- it is to provide a free software hosting platform and
   > a free operating system.

   But outside of GNU, the GPL isn't very common.

It is the most common free software license being used, it can't be
much more common than that.

   I think the goal of the GNU Project should be to take as many
   project under its umbrella as possible, [...]

There are many good reasons to reject a free software project to be
part of the GNU project -- there is another project that does the same
job being the most common reason.

But for before a project can become a GNU project, the hackers who
work on it have to have at least aligned their views with the views of
the Free Software movement and the GNU project -- Savannah looking
pretty or not has little to do with ethics and morals.



Re: [Savannah-hackers-public] Licensing advice for package submitters

2015-09-24 Thread Alfred M. Szmidt
   There is no license that limits commercial use and still compatible
   with GPLv2 (and GNU savannah).

Or any free software license for that matter.  All free software
licenses explicitly allow commercial use.



[Savannah-hackers-public] unpacker error when pushing

2014-08-05 Thread Alfred M. Szmidt
I'm getting the following error when trying to push, anyone know what
is wrong?

$ git push --verbose
Pushing to git://git.sv.gnu.org/womb/hacks.git
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 426 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 1 (delta 0)
error: unpack failed: unpack-objects abnormal exit
To git://git.sv.gnu.org/womb/hacks.git
 ! [remote rejected] master - master (n/a (unpacker error))
error: failed to push some refs to 'git://git.sv.gnu.org/womb/hacks.git'



Re: [Savannah-hackers-public] Non-fast-forward pushes on git

2014-07-24 Thread Alfred M. Szmidt
Instead of getting emotional, have you tried doing `git commit
--amend'?  That command is exactly created for situations like this!



Re: [Savannah-hackers-public] Non-fast-forward pushes on git

2014-07-23 Thread Alfred M. Szmidt
   My new project has been recently approved (gnu-social-mode), but due to
   a new member's mistake there is a commit on the repository which is
   malformed.  

The proper way is to use `git commit -amend'; not rewrite history.

But what do you mean malformed? These are the few last commits to
gnu-social-mode, none of them seem malformed:

  commit 7c7d3f6f9eb29edfece1841911e80f4f594e3d17
  Author: Albino Biasutti Neto b...@riseup.net
  Date:   Mon Jul 21 19:53:22 2014 -0300
  
  fix link identica-mode L25
  
  commit 12ba11968045b5fb3da8fcbf93b5c242e9aa3c61
  Author: Sergio Durigan Junior sergi...@sergiodj.net
  Date:   Sat Jul 19 20:08:51 2014 -0300
  
  Rename files, comments, functions, etc.
  
  This commit is a major renaming for the project.  It basically does
  s/identica/gnu-social/ in every file.  It also renames the files
  themselves, and makes a few adjustments needed for the OAuth support on
  gnu-social-mode.el.
  
  commit 5b7d171392db4f2a2a0713f3ecba9bdf602f64ba
  Author: Sergio Durigan Junior sergi...@sergiodj.net
  Date:   Fri Jul 18 21:17:34 2014 -0300
  
  Relicense code to GPLv3+ for gnu-social-mode
  
  This is the first commit of the new gnu-social-mode project.  It simply
  relicenses all the code to GPLv3+ on all files.  Very tiny cleanups were
  also made on the top comments of those files as well.
  
  Welcome, gnu-social-mode!
  
  commit cf9183ee11ac922e85c7c908f04e2d00b03111b3
  Author: Gabriel Saldana gabr...@gabrielsaldana.org
  Date:   Mon Feb 4 16:53:42 2013 -0600
  
  bump version to 1.3.1 after patches




Re: [Savannah-hackers-public] Non-fast-forward pushes on git

2014-07-23 Thread Alfred M. Szmidt
Or you, if you're the only one working on that repository, you
could try to fix it using `git revert` (see the manual for that).

   Yeah, I know about git-revert.  But the wrong commit is so
   small/simple that it doesn't take much to revert it.  

Just use `git commit --amend' for that.

There are already four people, and eleven emails already involved (if
that is simple/small then one might wonder what complex/big is) -- and
for a change that is immensly minor change.  There have been _three_
commits (of which two you are the author of) in over one year of which
none are malformed:

fix link identica-mode L25H
Rename files, comments, functions, etc.
Relicense code to GPLv3+ for gnu-social-mode



Re: [Savannah-hackers-public] Savannah dead in the water...

2012-02-28 Thread Alfred M. Szmidt
   I assume this is known, but the savannah web site isn't answering and
   neither is the git repo (git.sv.gnu.org).

Savannah (including all other GNU and FSF machines) are being moved to
a new colo.  

| The GNU/FSF servers are moving between February 22nd and March 1st,
| 2012.  There will be service interruptions during that period.
| There will be a multi-hour outage for most services on February
| 28th, 2012, starting at 10am EST (UTC/GMT -5).  The GNU/FSF servers
| are moving to a new colocation facility.  This will involve
| renumbering all our IP addresses.

| The work starts February 22nd and will be completed by March 1st.
| There will be occasional service interruptions during this period.
| There will be a multi-hour outage for most services on February
| 28th, starting at 10am EST (UTC/GMT -5).

| We will be posting updates via https://identi.ca/group/fsfstatus

| Feel free to contact sysad...@gnu.org if you see something that
| seems wrong, but please keep in mind that some downtime is
| inevitable.

| If the FSF hosts a virtual machine for your organization, please
| contact sysad...@gnu.org to plan the migration of your virtual
| machine.



Re: [Savannah-hackers-public] Projects for Android in GNU Savannah

2011-12-20 Thread Alfred M. Szmidt
   The question is not whether Android requires aditional software to be
   useful but whether it can be used with only free software, for otherwise
   Android-specific projects can't run on a fully free enviroment which is
   a requirement in GNU Savannah.

A simple approach might be to do what is done for other non-free
operating systems, like OS X.  Do we host code for projects that only
run on those?  If no, then we should do the same for Android projects.

   By the way I, there is the GNU HURD.

And Linux, specially in its form of Linux-Libre.



Re: [Savannah-hackers-public] #savannah on irc.gnu.org

2011-03-15 Thread Alfred M. Szmidt
   I won't object the migration of #savannah to some other IRC network
   if someone trustable first check than it doesn't have issues like
   this one (Or precisely this one).  But I'm definitively not that
   someone.

I see no reason why you can't do it, could you do it so we can resolve
this issue?  Do you know someone who can try and setup TOR with
Freenode, and work with the Freenode people to resolve any issues if
you don't have the time?



Re: [Savannah-hackers-public] #savannah on irc.gnu.org

2011-03-13 Thread Alfred M. Szmidt
I haven't recived any updates on this, have you tried using Freenode
with TOR?  Could you update me on the status?



Re: [Savannah-hackers-public] #savannah on irc.gnu.org

2011-03-03 Thread Alfred M. Szmidt
We shouldn't confuse the discussion, it is about having #savannah on
irc.gnu.org, not about Freenode, OTFC or where to host it.

If TOR users have issues with Freenode it is better to solve the
problems with them, than changing networks every week.  Could you
bring the issues you experienced with supp...@freenode.net first?

Saying that Freenode is hostile towards TOR users is harsh, and
untrue.  Freenode does support TOR, it may be a bit of a fiddle since
it has been abused; but this is no different than it being fiddly to
access the GNU machines since people abused them and now we have to
use SSH.

Personally, I'd like to see GNU hosting as IRC server.



[Savannah-hackers-public] #savannah on irc.gnu.org

2011-03-02 Thread Alfred M. Szmidt
Hi,

I find it immensly annoying that irc.gnu.org isn't hosting #savannah,
while I understand Sylvain's concerns regarding TOR, it does more harm
than good to have some IRC channels (specially ones as important as
#savannah, which has been invaluable when shit hits the fan) on random
servers.

If freenode for whatever reason cannot support our needs, then maybe
we should switch.  But I think that #savannah should exist, and be
active when you connect to irc.gnu.org.

Cheers, Alfred





[Savannah-hackers-public] [mats.anders...@gisladisker.se: Re: Me failing at SSH keys]

2010-11-18 Thread Alfred M. Szmidt
Could someone look into this?  We don't know what is wrong.

--- Start of forwarded message ---
Date: Thu, 18 Nov 2010 17:39:50 +0100
To: Sergey Poznyakoff g...@gnu.org.ua
Cc: Alfred M. Szmidt a...@gnu.org,
Jeff Bailey jbai...@raspberryginger.com,
Alain Magloire ala...@gnu.org
From: Mats Erik Andersson mats.anders...@gisladisker.se
Subject: Re: Me failing at SSH keys

Dear Sergey,

torsdag den 18 november 2010 klockan 17:44 skrev Sergey Poznyakoff detta:
 Hi Mats,
 
  I would just like to keep you informed on my failure to
  get the uploading of SSH keys at Savannah to work properly.
 
 Could you give more detail please? What it is you attempted to
 do and how exactly did it fail?

I have uploaded two RSA keys to Savannah using the web interface.
They seem to be accepted every time, also after proof reading the
key material and replacing all ambiguous letters: 0, O, 1, l, and I.

I have also checked, using ssh-keygen -y -f key-path, that I do
in fact remember both pass phrases!


In order to access Savannah I have attempted at

   ssh -i key-path git.gnu.org   (Alfred suggested this.)

   git clone ssh://git.sv.gnu.org/srv/git/inetutils.git

Yes, my SSH client ties the correct key to git.sv.gnu.org.
Both attempts end in a disappointing

   Permission denied (publickey)

The latter attempt asks for my pass phrase three time,
whereas the first command communicates a denial right off!

Whithout the ability to clone the repository, there is
no way I could push my ACK-ed changes back, so I must
somehow resolve this calamitym, if I should become
productive in the service of GNU Inetutils at all.


Best regards,
Mats
--- End of forwarded message ---



Re: [Savannah-hackers-public] inetutils: accidental push of branch

2009-12-08 Thread Alfred M. Szmidt
It's a mostly-default one.
You can enable branch deletion by doing this on the server:

  git --git-dir /vservers/vcs-noshell/srv/git/inetutils.git \
config hooks.allowdeletebranch true

   I have enabled it. Sorry for not being able to react earlier.

   Alfred, please retry deleting.

Thanks!  Not sure if we want to allow branch deletion, I have no real
opinion on the topic.




Re: [Savannah-hackers-public] [si...@josefsson.org: [SCM] GNU Inetutils branch, master, updated. inetutils-1_6-127-gb68da88]

2009-12-08 Thread Alfred M. Szmidt
   We're using contrib/hooks/post-receive-email from the Git release.
   I would suggest sending patches to the Git project.

Can you send me a copy of this file?




[Savannah-hackers-public] [si...@josefsson.org: [SCM] GNU Inetutils branch, master, updated. inetutils-1_6-127-gb68da88]

2009-12-07 Thread Alfred M. Szmidt
It seems that `git diff' still gets immensly confused when producing
diff output, man/Makefile.am was not copied from Makefile.am.  The
summary at the end if also confusing, the diff states that Makefile.am
was copied to man/Makefile.am, while the summary says
rexec/Makefile.am was copied to man/Makefile.am.

--- Start of forwarded message ---
To: commit-inetut...@gnu.org
From: Simon Josefsson si...@josefsson.org
Date: Mon, 07 Dec 2009 10:45:59 +
Subject: [SCM] GNU Inetutils  branch, master,
updated. inetutils-1_6-127-gb68da88

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Inetutils .

The branch, master has been updated
   via  b68da88c4318500bb32a64da58221895be0feb94 (commit)
  from  01469ec1de61765657f4a94660a60b0bdab5b922 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- - Log -
http://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=b68da88c4318500bb32a64da58221895be0feb94


commit b68da88c4318500bb32a64da58221895be0feb94
Author: Simon Josefsson si...@josefsson.org
Date:   Mon Dec 7 11:45:55 2009 +0100

Add (some) man pages.

diff --git a/ChangeLog b/ChangeLog
index 94c9ec4..a6154e5 100644
- --- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2009-12-07  Simon Josefsson  si...@josefsson.org
+
+   * configure.ac: Check for help2man.
+   * configure.ac (AC_CONFIG_FILES): Add man/Makefile.
+   * Makefile.am (SUBDIRS): Add man directory.
+   * man/Makefile.am: Add file.
+   * man/telnet.x, man/telnetd.x, man/rshd.x: New files.
+
 2009-12-06  Giuseppe Scrivano  gscriv...@gnu.org
 
* NEWS: Mention the new program rexec.
diff --git a/Makefile.am b/Makefile.am
index 5c9f40c..72437dd 100644
- --- a/Makefile.am
+++ b/Makefile.am
@@ -26,7 +26,7 @@ EXTRA_DIST = README-alpha paths ChangeLog.0
 SUBDIRS = lib headers libinetutils libtelnet \
hostname inetd telnetd libls ftpd rshd rlogind uucpd rexecd syslogd \
tftpd talkd telnet ftp rsh rcp rlogin tftp logger whois talk \
- - libicmp ping doc ifconfig traceroute rexec tests
+   libicmp ping doc ifconfig traceroute rexec tests man
 
 DISTCLEANFILES = pathdefs.make paths.defs
 
diff --git a/configure.ac b/configure.ac
index bfe17bc..d2df5a3 100644
- --- a/configure.ac
+++ b/configure.ac
@@ -132,6 +132,7 @@ AC_PROG_INSTALL
 AC_PROG_MAKE_SET
 AC_PROG_RANLIB
 AC_PROG_YACC
+AM_MISSING_PROG(HELP2MAN, help2man, $missing_dir)
 
 gl_INIT
 
@@ -844,5 +845,6 @@ confpaths.h:confpaths.h.in
 headers/Makefile
 doc/Makefile
 tests/Makefile
+man/Makefile
 ])
 AC_OUTPUT
diff --git a/Makefile.am b/man/Makefile.am
similarity index 50%
copy from Makefile.am
copy to man/Makefile.am
index 5c9f40c..61235ed 100644
- --- a/Makefile.am
+++ b/man/Makefile.am
@@ -1,6 +1,5 @@
 #
- -# Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
- -# 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009 Free Software Foundation, Inc.
 #
 # This file is part of GNU Inetutils.
 #
@@ -17,18 +16,24 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see `http://www.gnu.org/licenses/'.
 
- -AUTOMAKE_OPTIONS = 1.9
+dist_man1_MANS = telnet.1 telnetd.1 rshd.1
 
- -ACLOCAL_AMFLAGS = -I m4 -I am
+man_aux = $(dist_man1_MANS:.1=.x)
+EXTRA_DIST = $(man_aux)
 
- -EXTRA_DIST = README-alpha paths ChangeLog.0
+MAINTAINERCLEANFILES = $(dist_man1_MANS)
 
- -SUBDIRS = lib headers libinetutils libtelnet \
- - hostname inetd telnetd libls ftpd rshd rlogind uucpd rexecd syslogd \
- - tftpd talkd telnet ftp rsh rcp rlogin tftp logger whois talk \
- - libicmp ping doc ifconfig traceroute rexec tests
+telnet.1: telnet.x $(top_srcdir)/telnet/main.c $(top_srcdir)/configure.ac
+   $(HELP2MAN) \
+   --include=telnet.x \
+   --output=$@ $(top_builddir)/telnet/telnet$(EXEEXT)
 
- -DISTCLEANFILES = pathdefs.make paths.defs
+telnetd.1: telnetd.x $(top_srcdir)/telnetd/telnetd.c $(top_srcdir)/configure.ac
+   $(HELP2MAN) \
+   --include=telnetd.x \
+   --output=$@ $(top_builddir)/telnetd/telnetd$(EXEEXT)
 
- -snapshot:
- - $(MAKE) dist distdir=$(PACKAGE)-`date +%Y%m%d`
+rshd.1: rshd.x $(top_srcdir)/rshd/rshd.c $(top_srcdir)/configure.ac
+   $(HELP2MAN) \
+   --include=rshd.x \
+   --output=$@ $(top_builddir)/rshd/rshd$(EXEEXT)
diff --git a/man/rshd.x b/man/rshd.x
new file mode 100644
index 000..c3dfb66
- --- /dev/null
+++ b/man/rshd.x
@@ -0,0 +1,4 @@
+[NAME]
+rshd \- Remote shell server
+[SEE ALSO]
+rsh(1)
diff --git a/man/telnet.x b/man/telnet.x
new file mode 100644
index 000..1abcd29
- --- /dev/null
+++ b/man/telnet.x
@@ -0,0 +1,4 @@
+[NAME]
+telnet \- User interface