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

[Karl Berry]

I presume that
should be a safe place to have an unencrypted ssh private key?

I wouldn't (and haven't) thought twice about having private keys on
fencepost, for precisely the reason of ssh to savannah. I just don't use
that key for anything else.

As you say, there is no feasible alternative (that I know of). --thanks, karl.

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

[Karl Berry]

I don't have my old checkout any more, but wouldn't we use, e.g.,
  svn+ssh://k...@svn.savannah.gnu.org/gnueval
to access?
(As shown on https://savannah.gnu.org/svn/?group=gnueval)

Sorry if that's what you're already saying ...

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

[Karl Berry]

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

FWIW, I have a vague recollection from my time as gnueval (~15-20 years
ago) that, as a super special case, we explicitly made the repository
private because it contained possibly-nonfree and/or private information
that should not be publicly readable. -k

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

[Karl Berry]

The message comes from sv_membersh itself; 

Sure.

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.

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.

Anyway, regardless of that, the (A)GPL certainly does not require
unconditionally forcing unwanted info on users. Just like it's possible
for users to request that gdb, for instance, not display the various GPL
notices on startup.

I, like many others I'm sure, update tons of repositories nightly in my
cron job. Real messages are easily lost amidst all the new noise.  So,
please make it possible for me to stop seeing this, or revert the
default behavior.

For instance, if you keep showing it by default, then please give me an
option in the Savane interface to turn it off. Or something. It is quite
painful for a cron job that has run fine for decades to suddenly be
reporting this verbose information on every update. With no warning and,
most importantly, no way back to the previous quiet behavior.

karl

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

[Karl Berry]

As of two days ago, every cvs update, with or without -q, inflicts this
"helpful" message on me:

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

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

Can this please be changed back to silence? It is absurdly verbose to
see this report about an internal script on every update. A user doing
an update is not running sv_membersh.

It happens with both web repos and source repos. CVS only. --thanks, karl.

[Savannah-hackers-public] sv_membersh syntax error

[Karl Berry]

I'm not sure what to make of it, but when doing cvs update on the
automake www repo, my cron job last night reported: 

syntax error at /opt/savane/bin/sv_membersh line 96, near "$msg ~"
  (Might be a runaway multi-line << string starting on line 92)
Execution of /opt/savane/bin/sv_membersh aborted due to compilation errors.
cvs [update aborted]: end of file from server (consult above messages if any)

It doesn't happen now, so maybe the script was being edited at that
point? But I thought I'd report it anyway. --best, karl.

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

[Karl Berry]

> In sum, this private playground is something webmasters want and need,
> and search engines should have no business indexing it. Is it possible?

robots.txt will not stop ill-behaved robots from indexing.  Although
Google and Duck Duck Go, to the best of my knowledge, do respect it, it
is no panacea. So I don't think robots.txt solves the problem.

Also, as Alfred said, it feels quite weird to me to try to restrict
public pages to "robots". If a page is readable by a random human member
of the public, philosophically it seems to me it should also be readable
by robots (resources permitting, which is not the issue here).

Thus, using a separate and private repo like www-fr as Therese suggested
sounds to me like the best solution, both technically and
philosophically. I'm sure it is possible somehow to restrict viewing the
www-fr web pages to www members. Should be much easier than with a
subdirectory (/staging) of a public repo, seems to me.

My $.02, FWIW ... -k

Re: [Savannah-hackers-public] cgit syntax highlight request

[Karl Berry]

Should we leave color as it is now without?

I vote for "no color".

In the alternative, I'm in full agreement with using highlight, not
Pygments, for the reasons stated (which I've also
experienced). --thanks, karl.

Re: [Savannah-hackers-public] Moving some Git repositories to Savannah

[Karl Berry]

but could you please assist me in unsubscribing from these

Sure, I unsubscribed you. Happy hacking.


Note for any others who might be in the same boat, and the archives: you
can (un)subscribe yourself from any GNU list via the list's mailman
page, in this case:
https://lists.gnu.org/mailman/listinfo/savannah-hackers-public

It is likely that the automated mail generated as a result of that page
will be considered to be spam on your (receiving) end. But it does get sent.
--best, karl.

Re: [Savannah-hackers-public] small suggestion, list descriptions

[Karl Berry]

[savannah-help-public] ... also among the maintainers.

In my mind that would normally be savannah-hackers-public (where this
discussion is taking place :).

This is one of the places where having two lists is unnecessary IMHO.
I don't see anything to be gained by removing one at this late date.
Given the amount of confusion caused by the savannah-hackers ==
savannah-help-public conflation, I would not advocate for additional
list merging.

wonder about the word "occasional".

I put in that word because it seems better for people to submit
requests.  At least that's what the description says (written by
Sylvain, I think).  But I agree with you.  I removed the word. --thanks, karl.

Re: [Savannah-hackers-public] small suggestion, list descriptions

[Karl Berry]

Hi Ian,

On that page, add a description of what savannah-users is for and what
savannah-help-public is for.

Good question. In my mind, savannah-users is more for discussion "among"
users and savannah-help-public is more for sending queries "to" the
savannah maintainers. But in practice, as far as I can see, this amounts
to a distinction without a difference.  (Not helped by the
savannah-help-public and savannah-hackers being the same thing.)

We also seem to use savannah-users for occasional status reports and
less-permanent announcements (like that upgrade snag), instead of
savannah-announce.

I changed the descriptions (overwriting Bob's valiant effort :) to:

savannah-hackers   For occasional queries and reports to the Savannah
maintainers. Now referred to as savannah-help-public ...

savannah-users   Discussions among Savannah users, informal
announcements and status reports.

though I'm not sure it's really an improvement :(. -k

Re: [Savannah-hackers-public] Reply To button in lists.gnu.org email archives

[Karl Berry]

This would require a change in Mailman 

The "reply via email" button at the bottom of gnu.org message pages
(e.g., https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02469.html)
is not part of mailman.

I suspect it is part of mharc, the archive program that (I believe)
generates those archives, but perhaps it is a feature that GNU sysadmins
themselves programmed, years ago. -k

Re: [Savannah-hackers-public] Allowing git repos to automatically push to gnu.org/software/$PROJECT

[Karl Berry]

Ok, seems like we should setup a development instance of Savane, at
least the relevant parts. Does that sound right?

FWIW, I found it impossible in practice to set up a usable development
instance of Savannah (or Savane). Thus, when I wanted to do experiments
like this, I merely copied the php file in the live directory (on
frontend) to a different name (e.g., editgroupkarl.php) and then worked
on that.

Otherwise I could have spent my whole life trying to get the development
savannah working, and never made any progress on the actual
problem. Adding in the FSF connection (precisely one of the places where
"Savane" and "Savannah" differ, BTW, as I understood it) and it sounds
even more problematic to get a development instance working.

On the other hand, if you want to try, Assaf (Gordon) put a lot of
effort into setting up a development instance, and (afaik) it did work
for him. He documented his process here:
https://savannah.gnu.org/maintenance/FrontEndDevelopmentSite

Happy hacking,
Karl

Re: [Savannah-hackers-public] Allowing git repos to automatically push to gnu.org/software/$PROJECT

[Karl Berry]

Hi Daniel - sorry, but someone else from Savannah will need to work with
you to move this forward.  I just can't undertake the project.

Project maintainers on savannah cannot create their own git repos.  They
have send email/submit a support request.  (This is a constant thorn in
everyone's side.)

I guess your proposal is intended to avoid any work being necessary on
the Savannah side. I can understand that goal.

All that said, let me just say that the interface that seems cleanest to
me would be to change new.py to take an additional option to specify the
web repository VC type, say "-R cvs" or "-R git".

Then, on the savannah side, git would have to be supported as a backend
for web repos as well as cvs (database work, UI work). On the fsf side,
it would be a matter of running git commands instead of cvs commands,
but following exactly the same pattern.

But, as I say, I'm not going to be the one to move this forward, so I'm
not going to complain about whatever happens.

Also, I saw that there is a script to generate documentation for
each project. I think it runs on the Savannah side of things but
want to confirm.

"Generate documentation"? Sorry, I don't know what you're referring to.
If you mean the output for Texinfo manuals in different formats, like
the links on https://www.gnu.org/software/emacs/manual/, they are
(usually) generated by the gendocs.sh script, which is maintained in the
gnulib project. Project maintainers run it themselves; Savannah per se
is not involved.

Or, maybe you noticed that Savannah inherited a concept of "User Docs"
("Cookbook" and "In Depth Guide") from its parent software, but
essentially no projects use them, as far as I know. They are always just
boilerplate. (I wish it were possible to turn off the links in the menu.)

All the best,
Karl

Re: [Savannah-hackers-public] Allowing git repos to automatically push to gnu.org/software/$PROJECT

[Karl Berry]

Hi Daniel,

I'm also wondering if anyone knows of or has access to the CVS
hook/script that is on Savannah?

A gnu example is vcs1:/srv/cvs/web/emacs/CVSROOT/loginfo, which contains:

#
ALL echo 'Triggering webpages update...'; cat > /dev/null; curl 
http://www.gnu.org/new-savannah-project/new.py -s -F type=gnu -F 
project=`basename %r`
#

A nongnu example (type=non-gnu instead of gnu, otherwise the same):
$ cat /srv/cvs/web/zutils/CVSROOT
#
ALL echo 'Triggering webpages update...'; cat > /dev/null; curl 
http://www.gnu.org/new-savannah-project/new.py -s -F type=non-gnu -F 
project=`basename %r`
#

We wrote a few words about this in the sv wiki:
https://savannah.gnu.org/maintenance/HomepageUpload

We (sv people) have never seen the new.py script or had access to what
happens on the fsf side, but I guess you do.

I plan to modify the scripts to work with both Git and CVS 

Nice. Certainly a long-requested feature. Besides the changes on the fsf
side, it also requires some changes to Savannah to support git as an
option for web repositories. If you were planning to work on that too,
that's great. I don't know that any of the current sv volunteers have
any available time for it (I don't, sadly enough).

Hope this helps,
Karl

Re: [Savannah-hackers-public] Some email messages don't make it to my Inbox

[Karl Berry]

Date: Sat, 04 Apr 2020 10:56:47 +0300
From: Eli Zaretskii 
...
Here are a few examples of such missed messages.  In each case I
verified by downloading the emacs-devel archives that the message made
it to the list, but I see no such message in my Inbox.
...
This message didn't get to me:
Message-ID:


Since the msgs are making it to the list, I can only surmise it is a
problem in lists.gnu.org -> fencepost delivery -- system spam filtering
on fencepost, a routing error,  Unless you have some kind of
personal spam filtering set up for yourself on fencepost? I did not see
a .procmailrc in ~eliz, but what do I know. I'm sure you would have
checked that, anyway.

I don't think I have permission to view the logs on lists.gnu.org, nor
do I have any understanding of internal mail routing among the GNU
machines, so can't pursue. Sorry. I hope the sysadmins can do so
soon. --best, karl.

P.S. Also, I did not see an open ticket in the sysadmin RT queue
corresponding to your original message. Maybe I just missed it, or maybe
it got moved, or closed somehow. I don't know, but just thought I'd mention.

Re: [Savannah-hackers-public] Volunteer

[Karl Berry]

Hi Noel, Svetlana, all -

http://savannah.gnu.org/maintenance/SavaneTasks

Help with php etc. would be great, of course, but the coding tasks
listed there require setting up a local Savannah for any reasonable
testing and debugging. Quite a painful prerequisite afaik.

Here is another page with tasks, including many that only require using
the savannah admin web interface, a much easier way to gain some
overall experience:
http://savannah.gnu.org/maintenance/HowToBecomeASavannahHacker

Best,
Karl

Re: [Savannah-hackers-public] Access to rdiff-backup

[Karl Berry]

 (not the mailing list though, AFAIK).

If the lists are connected to the sv project, they should show up under
Mailing lists -> Configure in the web interface, and there is a check
box there for "Reset List Admin Password: ___ Requested". The new
password should get mailed to the project admins, as I understand it.

If they don't show up there, or that process doesn't work (I wouldn't be
surprised), feel free to write mail...@gnu.org and we will try to help.

Also, FYI, the rdiff-backup-* lists, like 90%+ of all lists on
lists.gnu.org, have been maintained as part of "listhelper"
(http://listhelper.nongnu.org). I just checked, and (as expected) they
don't have any pending messages and their configurations look ok.

Best,
Karl

Re: [Savannah-hackers-public] How do I delete a list in savannah?

[Karl Berry]

It looks like I can't do it in the savannah gui because I'm a "project
member", not a "site administrator" in the savannah project. 

Weird :). I made you an admin ... -k

Re: [Savannah-hackers-public] How do I delete a list in savannah?

[Karl Berry]

Hi Ian,

Subject: [Savannah-hackers-public] How do I delete a list in savannah?
As a savannah admin.

"Become Superuser" (on savannah, left-hand menu)

Go to the "Mailing lists" menu, then the "Configure" submenu,
resulting in, e.g.:
https://savannah.nongnu.org/mail/admin/?group=frozenb-ptp

Select the "To be deleted" radio button for the -admin list.
Click the "Submit" form button at the bottom.

It's also possible to do it through the database, naturally, but for a
half-dozen lists, I imagine clicking through the GUI is easier. (I have
no recipe for the sql side.)

Just to say it out loud: if the lists are empty, they should be deleted
on the server too.  I imagine you're well familiar with that, but for
the record, see "List deletion" on
http://savannah.gnu.org/maintenance/ListServer/ for info.

Happy deleting,
Karl

Date: Thu, 31 Oct 2019 14:24:35 -0400
From: Ian Kelling 
To: Savannah Hackers 
Subject: [Savannah-hackers-public] How do I delete a list in savannah?

[...]
https://savannah.nongnu.org/mail/?group=frozenb-ptp
https://savannah.nongnu.org/mail/?group=dfey
https://savannah.nongnu.org/mail/?group=gcpp
https://savannah.nongnu.org/mail/?group=librpgnu
https://savannah.gnu.org/mail/?group=www-he

Re: [Savannah-hackers-public] [savannah-help-public] [sr #109956] Error 403 in latest project release uploads

[Karl Berry]

You uploaded those files without permission for "other" to read them; I've
just fixed that.

How about doing a chmod -R a+rX of the upload tree every so often?

Or if it's possible to do it as some sort of hook on an upload, so much
the better.

Is there a valid reason why someone might need to upload unreadable
files? I can't think of any.

These days, when 077 or 007 umasks are often some sort of default, we
can expect the problem to recur. -k

[Savannah-hackers-public] mirrorbits multiplexer

[Karl Berry]

For the record, I just learned of this multiplexer, used to distribute
VLC and others:

  https://github.com/etix/mirrorbits
  
Just a thought, in case we ever want to replace the one we have now,
e.g., to support IPv6 ... -k

[Savannah-hackers-public] [task #15294] horizontal submenus not easy reachable with mouse (firefox)

[Karl Berry]

Follow-up Comment #3, task #15294 (project administration):

i certainly have no objection to making "stone age menu" the default. as far
as i'm concerned it's your decision, Ineiev :).

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[Savannah-hackers-public] [task #15294] horizontal submenus not easy reachable with mouse (firefox)

[Karl Berry]

Follow-up Comment #1, task #15294 (project administration):

Thanks for the CSS fix. I trust Ineiev will consider/apply.

FWIW, personally, my recommendation is to use the "stone age menu" feature,
selectable from the "My Account Conf" page, for more reliable UI operation.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

Re: [Savannah-hackers-public] [Savannah-cvs] [377] (Valid copyright notices): Add (C) to the line.

[Karl Berry]

To follow up (even more emphatically) Bob's reply:

-`Copyright _year1_, _year2_, _year3_  _copyright-holder_`
+`Copyright (C) _year1_, _year2_, _year3_  _copyright-holder_`

The ASCII (C) is neither forbidden nor required; it is irrelevant,
legally. What counts is the English word "Copyright" (or the
c-in-a-circle character, but that should not be used since it can cause
unnecessary encoding hassles). It is possible that courts might
recognize ASCII "(C)" as an alternative representation of c-in-a-circle,
but to the best of my knowledge this has never been tested, so best to
avoid it, since there is no loss in doing so.

I looked this up at the Library of Congress web site years
ago. Copyright notices without a "(C)" are widespread, and totally
fine. And shorter.

I don't think we should imply that "(C)" is meaningful. IMHO. -k

P.S. The maintainers file is written as it is because every single
(semantic) change of words must be approved by rms. Therefore when I
proposed or passed on changes I did my utmost to minimize the changes he
had to look at. That often meant ending up with wording that is
different than it would have been had it been written from scratch.

-- 

Re: [Savannah-hackers-public] Remove resume feature to prevent abuse?

[Karl Berry]

I propose that we decommission the resume feature from the Savannah
web UI.

I agree, FWIW.

Re: [Savannah-hackers-public] long GPG keys

[Karl Berry]

Longer than 64K!  That seems very long to me.  

Maybe they included a big image. (Knowingly or not.)

Maybe it would be better to consistently report an error and reject the
upload, for the reasons Bob gave ... -k

Re: [Savannah-hackers-public] Fwd: Mirmon can't reach the team-cymru mirror by rsync

[Karl Berry]

~ $ time ssh t...@fencepost.gnu.org true
real2m8.751s

traceroute may be more diagnostic than the raw time, to see if the
problem is in the routing in between. Or ssh -vvv if it's the ssh
negotiation that's taking the two minutes.

I also wonder if ssh on fencepost is trying to do reverse dns on your
host and that is inducing the delay. It's a common reason for such delays.

I also wonder about forcing a connection over IPv4 to see if that makes
a difference, e.g., maybe it's trying to negotiate over v6 that is
taking forever. Another common culprit. --good luck, karl.

Re: [Savannah-hackers-public] documentation changes for converting from git to svn

[Karl Berry]

The :: syntax didn't work 

For the record, it's either host::/path or rsync://host/path (or modules
instead of paths, not relevant here), but the syntaxes can't be mixed,
as the previous .md was doing. -k

Re: [Savannah-hackers-public] [gnu.org #1231910] Ggradebook

[Karl Berry]

Norbert de Jonge (the original author of GNU gradebook) is unable to
update the project's Savannah repo because he is not a member of the
project -- his request for inclusion hasn't been processed yet. In
fact, the former project admin is "inactive". 
Could you possibly add him manually?

Well, since Norbert is the original author of the package, ok, I went in
and added him.

But ordinarily this would not be acceptable.  Ggradebook has a listed
maintainer, namely Peter Cherepanov (cc'd; hope you don't mind me doing
this, Peter). We have no way to know he is "inactive", if in fact he is.
There is nothing in general that delegates tasks like membership
approval from the maintainer(s) to Savannah admins; that would not be right.

The place to which to escalate problems is maintain...@gnu.org. Those
are the people who have volunteered to sort out problems like
this. (Like, try to contact Peter, see if he replies, remove him from
the maintainers file if appropriate, decide about doing a manual
approval, ask about becoming a (co-)maintainer, etc.)

> approval process does not take into account that GNU projects can be
> orphaned/unmaintained. 

Ggradebook is not orphaned/unmaintained, as far as the official file
goes, so fixes for that (which would not be bad) wouldn't help here.

> cron-job checks which inclusion requests have been active for more than
> two weeks or so. 

Agreed, it would be nice. There are a plethora of nice ideas, and
evidently zero volunteers with time and interest in implementing such
things. Sad, but that's the reality I observe. (Unfortunately I am of
those not-enough-time-and-interest-to-do-real-work people too.) Maybe
more dedicated volunteers will come forward one day. --best, karl.

Re: [Savannah-hackers-public] [task #14586] svn import for gnustep-nonfsf

[Karl Berry]

Does it mean it cannot be used (I actually checked and the website 
doesn't show= ) and we need to put it in CVS?

To be explicit: yes, that is what it means. Sorry, but that is the
reality. -k

Re: [Savannah-hackers-public] VCS for web pages [was: [task #14586] svn import for gnustep-nonfsf]

[Karl Berry]

With current issues related to vcs load, I think CVS may have
substantial advantages over Git (not sure for Subversion).

For the record, Subversion has the same advantages as (and many fewer
disadvantages than) CVS. It is no problem to check out a single
subdirectory; you just do it. As in CVS.

That is not to say we should not, in principle, support git for web
pages. Many people want it. -k

Re: [Savannah-hackers-public] gnustep-nonfsf download Area

[Karl Berry]

the gnustep-nonfsf looks unlucky in its birth!
When I use the "Downloads" link I get:

I confirm that https://savannah.nongnu.org/files/?group=gnustep-nonfsf
yields a 404 message(*), and that
download0:/srv/download/gnustep-nonfsf/ contains some files.

I no longer know how all these things are intended to fit together. I
hope one of the others can fix can fix ... --sorry, karl.

(*) And the message contains a relative url, which should be absolute to
be useful.

[Savannah-hackers-public] [task #14586] svn import for gnustep-nonfsf

[Karl Berry]

Update of task #14586 (project administration):

 Open/Closed:Open => Closed 

___

Follow-up Comment #5:

svn history now imported (on vcs). went fine after the reboot, yay.

cvs shouldn't/can't be disabled because it remains the only way to deal with
web pages (for http://gnustep-nonfsf.nongnu.org) on savannah, unfortunately.



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Savannah-hackers-public] [task #14586] svn import for gnustep-nonfsf

[Karl Berry]

Follow-up Comment #2, task #14586 (project administration):

Sadly, the import fails on the (woefully underpowered) server. It got to about
rev10, and then:
"Out of memory - terminating application."

I am helpless to proceed in the face of insufficient hardware, afaik :(. Maybe
Assaf or Bob will have an idea for how to work around ...

Sorry ...






___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Savannah-hackers-public] [task #14586] svn import for gnustep-nonfsf

[Karl Berry]

Follow-up Comment #1, task #14586 (project administration):

in process, will let you know.

assaf/bob/anyone: it seems the automatic creation of svn repos when enabled in
the web interface is not working. at least, gnustep-nonfsf had svn enabled,
but no /srv/svn/gnustep-nonfsf on vcs ... i created it by hand
[[AdminSvnImport]] ...


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [Savannah-hackers-public] http://planet.gnu.org/

[Karl Berry]

ch> http://planet.gnu.org/ still nonfunctional

bp> planet.gnu.org is a volunteer run service not run by the Savannah
Hackers, nor by the FSF admins.  I don't know who the admins for 

Jose Marchesi and Nacho Gonzalez set up planet.gnu.org. Cc'ing them ... -k

Re: [Savannah-hackers-public] How to take over an abandoned project

[Karl Berry]

Thomas - per Rein's mail, I made you an admin of tlf.
(I left Rein there but marked him off-duty.)

Savannah people: Rein's original mail got filtered somehow, my resending
of it also got filtered somehow, I can't look into it right now, so am
appending it here. -k



rein.msg.gz
Description: Binary data

Re: [Savannah-hackers-public] How to take over an abandoned project

[Karl Berry]

My mails to the list showed up nearly only a day later.

The first time any address posts to any list, it has to be approved by a
human, and there are only a couple of us doing that job. At least I
surmise that is what is happening.

Well one of the users of sv-users managed to find the phone number
of Rein Couperous and gave him a call about it. In result Rein wrote
yesterday to sv-users that he would agree to the transfer.

Excellent!

So maybe we should wait some more time or I can forward the message to
you.

There is nothing pending in the sv-users (or any other) list right now,
so I guess it was accidentally deleted somewhere. I'm hunting for it,
but meanwhile, yes, please send it. With the Message-ID and other
headers if possible.

Thanks,
Karl

Re: [Savannah-hackers-public] How to take over an abandoned project

[Karl Berry]

[switching to sv-hk-pub from sv-users]

Thomas - I'm not sure if someone else has already replied, but if not ...

statement at the top of the mailing list archive that the content is
updated twice an hour. 

It appears to me that the cron job to update mailing list archives runs
four times an hour now.

> > I am wondering what are the steps  to take over an abandoned nongnu
> > project.

I'm not sure we have an official policy about it.

It seems to me that if you can get the previous owner (one "Rein
Couperus", I gather), or someone, to tell us that it's ok (or point us
to somewhere where they say they are abandoning it, then we can transfer it.

Failing that, you could certainly submit the code as a new project (say,
tlf2), though I realize that is suboptimal in several ways, and we can
evaluate/approve as with anything else.

Otherwise, I just feel leery of forcibly transferring a project with no
input from the previous admin. Perhaps others would like to weigh in.

Hope we can make something work,
Karl

[Savannah-hackers-public] [savannah-reports-private-boun...@gnu.org: Forward of moderated message]

[Karl Berry]

Bob/Assaf - these monit reports were sent to "root@localhost" and
therefore were held for moderation in mailman. I didn't want to add that
address to any mailman field because it's invalid; mailman will let you
add it but then (annoyingly/wrongly/uselessly) complain on a subsequent
edit to that field. You've probably seen that.

Bottom line: can you somehow tweak something so that the To: line is
root@fqdn, or sv-reports-priv...@gnu.org, or something?  -k

Date: Thu, 23 Feb 2017 21:14:31 -0500
From: savannah-reports-private-boun...@gnu.org
To: k...@gnu.org
Subject: Forward of moderated message

Envelope-to: savannah-reports-priv...@gnu.org
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56232)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from )
id 1ch0ZW-0001dg-AQ
for savannah-reports-priv...@gnu.org; Thu, 23 Feb 2017 16:05:07 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from )
id 1ch0ZV-0003PX-Gz
for savannah-reports-priv...@gnu.org; Thu, 23 Feb 2017 16:05:06 -0500
Received: from vcs0.savannah.gnu.org ([208.118.235.201]:39429)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from )
id 1ch0ZV-0003PT-E1
for savannah-reports-priv...@gnu.org; Thu, 23 Feb 2017 16:05:05 -0500
Received: by vcs0.savannah.gnu.org (Postfix)
id 361A624A7A; Thu, 23 Feb 2017 16:05:05 -0500 (EST)
Delivered-To: root@localhost
Received: from vcs0.savannah.gnu.org (localhost [127.0.0.1])
by vcs0.savannah.gnu.org (Postfix) with SMTP id 1C21724912
for ; Thu, 23 Feb 2017 16:05:05 -0500 (EST)
From: mo...@savannah.gnu.org
To: root@localhost
Subject: monit alert --  Monit instance changed vcs0.savannah.gnu.org
Date: Thu, 23 Feb 2017 21:05:04 GMT
X-Mailer: monit 5.6
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <1487883905.329...@vcs0.savannah.gnu.org>
Content-Transfer-Encoding: quoted-printable
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 208.118.235.201

Monit instance changed Service vcs0.savannah.gnu.org

Date:Thu, 23 Feb 2017 16:05:04
Action:  stop
Host:vcs0.savannah.gnu.org
Description: Monit stopped

Your faithful employee,
Monit

Re: [Savannah-hackers-public] New guix-patches mailing list not showing up on Mailman

[Karl Berry]

I created a new œôòøguix-patchesœôòù mailing lists ~48h ago on Savannah.  

I just created it by hand. Assaf is looking into the PHP<->Savannah
linkage/breakage. --best, karl.

Re: [Savannah-hackers-public] Web Crawler Bots

[Karl Berry]

Mostly I was looking for comments or feedback on whether DROPing
packets from crawlers is a good or bad thing to do.

Either DROP or REJECT, take your choice. f2b usually does reject,
I believe. I see pros and cons either way ...

problem has been lack of appropriate robots.txt files.  

My tug.org robots.txt does seem to stop a surprising majority of
undesired crawling. Of course you could grab it helpful.

User-agent: *
Disallow: /

Ack :).

Happy filtering,
Karl

Re: [Savannah-hackers-public] Web Crawler Bots

[Karl Berry]

Bob - as you probably know, there are some existing fail2ban filters for
this -- {apache,nginx}-botsearch.conf are the most apropos I see at
first glance. fail2ban is the only scalable/maintainable way I can
imagine to deal with it.

A nonscalable/nonmaintainable way ... for tug.org, years ago I created a
robots.txt based on spammer user-agent strings I found at
projecthoneypot.org
(https://www.projecthoneypot.org/harvester_useragents.php nowadays, it
seems). It's still somewhat beneficial, though naturally it was surely
out of date the instant I put it up, let alone now. I also threw in
iptable rules by hand when the server was getting bogged down. I hope
one day I'll set up fail2ban (including recidive) for it ... -k

[Savannah-hackers-public] resending 800+ lost tracker emails

[Karl Berry]

I'm about to resend 800+ emails from Savannah trackers to various
lists. The earliest is from mid-October (this year). It's likely that
some tracker mail before that was also lost, but no practical way to
retrieve it now as far as I know. FSF sysadmin promptly fixed the
problem going forward (thanks Ruben).

I write this here in case there are questions from people receiving the
old mail. I didn't feel like writing to each individual list. 

These messages will go only to the lists involved, not to any other
individual recipients on the mail (who got it the first time around).

For possible future reference, I wrote some details about the story in
lists:~/archive/filtspam/README

Hope it flies,
Karl

audio-video
avr-libc-dev
avrdude-dev
bug-gnu-pspp
bug-grub
bug-kawa
bug-wget
denemo-devel
gnuastro-devel
health-dev
lwip-devel
lwip-members
octave-bug-tracker
octave-patch-tracker
octave-task-tracker
savannah-hackers-public
savannah-register-public
screen-devel
www-pt-br-general

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

[Karl Berry]

Not I.  The planet.gnu.org web site isn't related to anything
Savannah.  Your best source of information will be the FSF admins.

For the record, the maintainers of planet.gnu.org == chapters.gnu.org
are (so far as I know) Nacho Gonzalez, Jose Marchesi, and Ineiev. -k

Re: [Savannah-hackers-public] [Savannah-cvs] [266] MigrationChecklist: more tasks

[Karl Berry]

+* Check for special permissions for gnu webmasters?

I don't know for a fact if it is still the case, but it is true that at
least at one time anyone in the www group could commit to any type=gnu
web repository (CVS).  This was useful.  -k

Re: [Savannah-hackers-public] mismatching licenses in list on Savannah

[Karl Berry]

Assaf -

re  https://savannah.gnu.org/support/?109134
and https://savannah.gnu.org/support/?109136

Yes, surely the newly "unknown" licenses are about my changing
hashes.txt as stated.  However, if I put back the old hashes.txt, they
stay unknown.  So that's highly unfortunate.

Does this ring any bells?

My bells are silent, sorry.  

I have noticed that there are generally at least two copies of savane
sources and data files on the hosts, one under /etc/savane and one under
/usr/src/savane.  It's never been clear to me why this is the case, or
which one is used in which circumstances; it's a fundanmentally bad
thing as far as I can see.  Anyway, I tried copying the "new" hashes.txt
from the /usr/src instance to /etc (on frontend), but it didn't help :(.

If not, I'll be able to investigate further a bit later today.

That would be highly, highly, appreciated.
Sorry for the "surprise" work.  -k

[Savannah-hackers-public] commit mail coming from @vcs.

[Karl Berry]

Bob - it seems commit mail has started coming from @vcs.savannah.gnu.org
in some cases.  Maybe it is user specific.  For example, see message
below; mail from "dvc" (David Craven), and I also noted "nckx", is @vcs,
but not others.

The first time I see this is in guix-commits is June 20, with another user:
>From kkebreauvcs.savannah.gnu.org Mon Jun 20 09:06:13 2016

I think I've seen it with other commit lists as well, but didn't check
around.

Maybe there is nothing to be done, but it somehow doesn't seem right, so
thought I'd mention it.

lists:/var/lib/mailman/archives/private/guix-commits.mbox$ grep '^From ' 
guix-commits.mbox | tail
..
>From efraimflashner.co.il Mon Aug 22 05:39:56 2016
>From dvcvcs.savannah.gnu.org Mon Aug 22 07:08:55 2016
>From mhwnetris.org Mon Aug 22 08:18:06 2016
>From mhwnetris.org Mon Aug 22 08:18:05 2016
>From dvcvcs.savannah.gnu.org Mon Aug 22 07:09:09 2016
>From dvcvcs.savannah.gnu.org Mon Aug 22 07:08:56 2016

(The "" is really a literal "@" sign.)

Thanks either way,
karl



msg.gz
Description: Binary data

Re: [Savannah-hackers-public] SavannahHosts r212

[Karl Berry]

/etc/default/iptables-rules file I find this:

Crazy, yes.

  # Forward cvspserver connections to vcs-noshell

Ah, I missed that critical comment.

I think we should definitely not continue it and then deal with
any pserver connections as needed.

Agreed.

[Savannah-hackers-public] SavannahHosts r212

[Karl Berry]

Bob writes:

+* Are people using download for a pserver?  There are notes to that
+  effect in the download /etc/default/iptables-rules file.

locate /CVS/ on download tells me there is a CVS repository for
audio-video (nothing else).  Whether it is still used, have to ask
"them" (whoever "they" are nowadays :).  -k

Re: [Savannah-hackers-public] Broken links in Savannah news items

[Karl Berry]

  [www.gnu.org main site]
  ...
  $line = preg_replace('/(^|\s|\[)(www\.)/i', '$1http://$2', $line);

Right.  Thanks, installed.  Hopefully third time's the charm ... -k

Re: [Savannah-hackers-public] Broken links in Savannah news items

[Karl Berry]

Hi Ludo,

I see this is being worked out:
  
https://lists.gnu.org/archive/html/savannah-hackers-public/2016-07/msg5.html

Yesterday's change was the culprit, yes.

Sorry for the noise

On the contrary, it's good you reported it since it was a bug in the fix :).

apparently œôòühttps://œôòý was automatically prepended ...


Actually, "http://; was being incorrectly prepended to "www.".
The https's are yours :).


Sergey: it seems to me we can only safely prepend "http://; if the "www."
is at ^ or preceded by whitespace.  As in:

  # Prepare usual links: prefix "www." with "http://;
  # if it is preceded by whitespace or at the beginning of line.
  # (don't want to prefix in cases like "//www.." or "ngwww...")
  $line = preg_replace('/(\s|^)(www\.)/i', '$1http://$2', $line);

(I changed over to that line and now Ludo's forum page looks right.)

It's not clear to me what other case is trying to be handled by the
original alternative of [^/], though surely it was something, and maybe
we'll hear about it shortly ... -k

[Savannah-hackers-public] too many http://'s

[Karl Berry]

Sergey, does this happen on puszcza?  I guess the incorrect replacement
in the "rich markup" is happening in frontend/php/include/markup.php.  I
don't immediately see what's wrong in the regular expression there :(.
TIA ... -k

Date: Sun,  3 Jul 2016 11:38:31 + (UTC)
From: ederag 
To: ederag , savannah-help-pub...@gnu.org
Subject: [savannah-help-public] [sr #109087] links beginning with
 "http://ngwww.*; are transformed to "http://nghttp://www.*;

URL:
  

 Summary: links beginning with "http://ngwww.*; are
transformed to "http://nghttp://www.*;
 Project: Savannah Administration
Submitted by: ederag
Submitted on: Sun 03 Jul 2016 11:38:29 AM GMT
Category: Savannah trackers - bugs, tasks, etc.
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: 
Operating System: GNU/Linux
 Open/Closed: Open
 Discussion Lock: Any

___

Details:


links beginning with "http://ngwww.*; are transformed to
"http://nghttp://www.*;

For instance in 
https://savannah.gnu.org/bugs/index.php?48387#comment2
The correct link being given verbatim
https://savannah.gnu.org/bugs/index.php?48387#comment3

This is the same with the [link title] syntax
https://savannah.gnu.org/bugs/index.php?48387#comment5

[...]

[Savannah-hackers-public] [task #14070] Fix typo

[Karl Berry]

Update of task #14070 (project administration):

 Open/Closed:Open => Closed 
 Summary:Fix type => Fix typo   

___

Follow-up Comment #2:

thanks for the report. this tracker is the right place.

i thought that whole sentence was just unnecessary, so deleted it. made other
english wording fixes throughout those paragraphs. imperfect english is
pervasive throughout savannah ... (fixed your trivial subject typo, i hope)
... --thanks, karl.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [Savannah-hackers-public] Updating GNU contact information in Savannah's wiki

[Karl Berry]

Hi Assaf,

Can you advise on the text below ?

Although it's always easier just to hack our wiki, I think it is better
in principle not to duplicate information, but rather to point to one
reference and make that be as good as it can be.

Your descriptions are accurate, but they are also already stated in
other places, primarily the maintainers guide -- not as well organized
as they could be, surely.

Thus, I propose adding what's missing to
http://www.gnu.org/prep/maintain/maintain.html#Getting-Help -> sending a
patch to maintain.texi to bug-standa...@gnu.org.
To that end, FYI, it's intentional that the "Getting Help" section is
arranged by "job -> mailing list", rather than "mailing list ->
description", per rms's general principles.

Savannah administrators can help with technical matters ...

This paragraph ("Savannah doesn't do GNU admin tasks") is another item
for NotSavannahAdmins, certainly.

Thanks,
Karl

Re: [Savannah-hackers-public] Task #14039: Terminocheck

[Karl Berry]

Hi Hugh,

Thanks for your comment at
  https://savannah.gnu.org/task/?14039
It looks just right.

So ... I've made you (account hlam) an administrator of the
"administration" project, which will let you update the ticket statuses
and create new projects, etc.  Welcome!

Of course, double-checking and all that before taking actions is prudent :).
Feel free to poke around the site now and see what you can see, ask any
questions here (or savannah-hackers-private as you prefer).  See
[[SavannahHackersCommunication]], etc.

Thanks,
Karl

Re: [Savannah-hackers-public] Task #14028: Farming Applications

[Karl Berry]

Hi Hugh,

paste.debian.net/739188

Great.  It is usually best to reply directly ("post a comment") in the
ticket, but no problem this time that you already did so separately.

I noticed you (presumably you) have several accounts on savannah.  Which
one(s) are active?  For when we enable you as an admin ... 

Thanks for all,
Karl

Re: [Savannah-hackers-public] Task #14028: Farming Applications

[Karl Berry]

This application relates to a proposal to create free software for 
agriculture, rather than any specific program per se.  I don't know if 
there is a Savannah policy on that.  

The (not 100% hard-and-fast) policy is not to do it.  People should have
code, not just an idea, before it makes sense to register a software
project.

I think this is an excellent idea which could do a lot of good.

Agreed.

someone reach out to the applicant with support and encouragement.  I 
would be happy to do that; 

Please do.

I have actually been thinking about trying to 
develop software for agriculture myself.

Great!

Thanks,
Karl

Re: [Savannah-hackers-public] Task #14039: Terminocheck

[Karl Berry]

Hi Hugh,

I have joined the list because I would like to 
help support Savannah.

Thanks!

* project naming: one concern I had is that I would see the project name 
("Terminocheck") and think the program had something to do with terminals 

I agree.  Please bring it up with them.  I'm not sure what alternative
to suggest.  fsvocabcheck?  fslingo?  rmsvocab?  Got to be something.

* Licensing: unable to check notices in detail 

Are you aware of Assaf's scripts for automatically testing a submitted
tarball?  I can't remember now where we linked to them in the help
pages, but they should be there somewhere.

because my system was 
unable to open the .gz archive, complaining about the format.  

Despite the name, it's a tar.bz2 file.  (file told me.)
  bunzip2 

Re: [Savannah-hackers-public] CVS web repos of Cssc and Stalkerfs: modifications don't show up on the web

[Karl Berry]

Question for the Savannah Hackers: Is there a reason these don't have
the hook?  Should I add it to them?

Probably not www.  I don't understand how it is on your list, but www
updates are happening (I presume), so seems better not to mess with it.

I know of no reason not to add the hook (gnu resp. nongnu as
appropriate) to the others, which I expect are moribund so it will make
no practical difference.  But may as well have the hook for
consistency.  -k

Re: [Savannah-hackers-public] Permission issue in the audio-video directory

[Karl Berry]

Very frustrating for a cleaning lady.  :)

I understand, being the janitorial type too :).

oitofeliz, luca, dskfw and atticusrex (Zak) are members of svusers

Indeed, Luca explicitly asked us to make him a shell account
specifically so he could do audio-video stuff.  Pity none of us realized
that changing group permissions was all that was really needed.

I still think it wouldn't harm to set the group of all directories
to audio-video.

It seems that has been done.  Let us know if that part still looks broken?

>   http://audio-video.gnu.org/
> Or?
>   http://www.gnu.org/software/audio-video/

We can conceivably try to "trigger" an update, but it seems like it
would be nice to understand what the intended setup is.  E.g., does the
former use the cvs files from the latter?

You or one of us could take a look at fencepost:/srv/data/www-config and
../www-mirror, which should be copies of the real web server setup and
the files on it (respectively), which might garner some info.
Unfortunately I cannot look right now.

Happy cleaning,
Karl

Re: [Savannah-hackers-public] Did the permissions on CVS lock files change?

[Karl Berry]

I think there is a rationale 

Sure.  The rationale isn't in question.  The "implementation" on
Savannah of giving members of the www project access to other projects'
"webpage repositories" is the question.  Whatever the implementation
was, it evidently broke with the hardware switch.  I don't know the
answer and I'm afraid I cannot research it any time soon, and I don't
think Bob can either for a couple of days at least.  Assaf, Michael?  -k

Re: [Savannah-hackers-public] Did the permissions on CVS lock files change?

[Karl Berry]

Hi Therese,

commits I attempted on May 8 and 9 (to the gnudos, gnutrition, leg
and smalltalk repositories) failed with that sort of error:
...
`/webcvs/leg/leg/,index.html,': Permission denied

As I recall, there is some ACL or other magic allowing members of group
www (like you) to commit to other repositories?  Unfortunately I'm not
able to find the information now.  It is certainly plausible that
such stuff was lost in the migration (not intentionally/knowingly).

.. bob? ... 

Without something like that, I see no reason why th_g should have been
able to commit to any project repository previously.  The web
directories are only writable to the group, as intended, and you are
only in a few groups:

vcs$ groups th_g
th_g : svusers www trans-coord www-fr

/var/lock/cvs/web/[package].

I see a lock directory owned by you there from earlier today:
vcs$ ls -l /var/lock/cvs/web/leg
..
drwxrwxrwx2 th_g svusers40 May 10 08:01 leg

But I'm not sure if deleting it is a good idea, and probably wouldn't
help anyway, so I didn't touch it.

Sorry ...

co-coordinator ... and cleaning lady

:)

Re: [Savannah-hackers-public] UPDATE: New hardware for *.savannah.gnu.org and lists.gnu.org

[Karl Berry]

vpn.savannah.gnu.org has not been migrated yet (but it is running on
the old machine). Is it needed?

It is not needed.  Thanks.  -k

Re: [Savannah-hackers-public] /etc/aliases on internal?

[Karl Berry]

Anyone know any details about the /etc/aliases file on internal?

Not me.

Why does internal need to know about all of these aliases?

Cron jobs, database stuff, erroneous setup?  Don't know ... -k

Re: [Savannah-hackers-public] mgt disk space?

[Karl Berry]

The disk space on mgt is getting tight.

We should ask them to make a bigger partition, it seems to me.  It seems
bizarre to have to worry about disk space now when we didn't before.

Karl, I found /root/colonialone from 2011 at 1.8G.  There is a README
addressed to you there.  Could you look at that directory and see if
it is still needed?  

Can you move it to some other partition/host where there is space?  (One
big .tar.gz or whatever would be fine.)  Nothing in there is needed
live, unless I'm much mistaken (always possible), but it was the root
system at one time.  It can probably be deleted without losing much if
anything, but I can't investigate that any time soon, and disk space is
so much cheaper than human time, anyway ...  -k

Re: [Savannah-hackers-public] Should we put up a maintenance page?

[Karl Berry]

Warnings about current realities are good.  Please do, as far as I'm
concerned.  Thanks.  -k

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

[Karl Berry]

   http://savannah.gnu.org/maintenance/NotSavannahAdmins/

I made some tweaks.  Thanks.  -k

Re: [Savannah-hackers-public] Email on fencepost hosed?

[Karl Berry]

the way to reach them is with a mail to sysad...@gnu.org

Or sysad...@fsf.org, if one suspects @gnu.org mail is broken.  -k

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

[Karl Berry]

In addition to what Bob said ...

What about providing rsync/ssh access like for nongnu.org?  

For the umpteenth time: www.gnu.org (and ftp.gnu.org and alpha.gnu.org
and ...) is controlled by FSF sysadmin.  Not us Savannah volunteers.  We
have no more access to it than you do.  There are plenty of possible
solutions, but we cannot implement them.  You want changes, talk to
them.

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.  And if any
changes happen, they surely will not happen quickly.  So fix your tool
-- just running the output through fmt comes to mind, HTML being what it
is.  Or something like that.

Or: stop hosting your web pages through savannah -- having your own site
at guix.gnu.org comes to mind.  Talk to the FSF about it.  There is
nothing we can do to set that up.  Good luck.

Karl

Re: [Savannah-hackers-public] Quote from Savannah regarding GNU Ethical Repository Criteria for Announcement

[Karl Berry]

Hi Andrew,

Could you just confirm that it is OK for release

Seems fine to me.

and representative of your goals?

Just for the record, I wouldn't say "we" have goals in this regard.  The
rules for Savannah are ultimately defined by the FSF, not Savannah
developers.  It is, one might say, a "wholly owned" GNU projectj.  None of
the three most active maintainers involved with Savannah now until
relatively recently (a couple years); obviously we, like any
Savannah contributor, agreed to support and work within the existing goals.

Regarding the criteria:
  http://www.gnu.org/software/repo-criteria.en.html

1) It's unclear to me what "visitor" means to me -- whether it means only
an anonymous visitor, or either anonymous or authenticated.

2) Criteria A+1, "Does not log anything about visitors." is draconian,
and, so far as I can see, directly conflicts with A+2, "Follows the
criteria in the [EFF's best practices]".  The EFF recommends keeping
logs for a short time, but not no logs at all.  Thus there will be the
standard web server access_log / error_log stuff even for anonymous
visitors.  (I doubt it is feasible to 100% turn off *all* logging at
every level, even aside from whether it is desirable.)

Furthermore, if "visitors" includes those who have logged in, it is an
unavoidable aspect of hosting to log many actions, and this is not bad.
Simple example: make a commit -> write repository history.
Another example: update password -> writes database -> database records
transaction.

These too could be construed as logging  "about visitors".
Presumably not what A+1 intends, but as written, I wouldn't have a clue
how one could comply with A+1 and still provide standard hosting services.

(If desired, feel free to pass this on to your list, of course.)

Happy hacking,
Karl

[Savannah-hackers-public] a+ repo criteria

[Karl Berry]

Andrew Ferguson's message

talks about Savannah being "A", but not "A+".

So I looked at the criteria:
http://www.gnu.org/software/repo-criteria.en.html

I have to say I think the A+ items are pretty reasonable.  Aside from
the W3C stuff, we should be able to implement the others.  In our
copious spare time and especially given the scads of active new (and
old) volunteers :).

Anyway ...

k

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

[Karl Berry]

GNU Project offered an official Gitlab or Gogs instance, 

I suggest asking gnu-advisory about the idea.  If they and/or rms give
the green light, maybe people on gnu-prog-discuss would be willing to
volunteer to do the work involved.  If you weren't volunteering to do so
yourself (wasn't sure).  Happy hacking.  --karl.

Re: [Savannah-hackers-public] Mirmon does not show US mirrors

[Karl Berry]

This is to let you know that mirrors located in the United States of
America do not show up in
http://download.savannah.gnu.org/mirmon/allgnu/.

Oops!  Glad you noticed.  I think I've fixed it.  The same bug also
omitted US mirrors from http://download.savannah.gnu.org/mirmon/gnu.
Think that's fixed too.  --Thanks, Karl.

Re: [Savannah-hackers-public] Contributor submission

[Karl Berry]

Hi Kuba,

Thanks for writing.

projects waiting for approval or abandoned, whose are really good.

These are two entirely different things.

Projects waiting approval need to be reviewed to see if they meet the
conditions for hosting on Savannah.  I.e., helping with this means
helping with Savannah administratively.  This web page discusses details:
http://savannah.gnu.org/maintenance/HowToBecomeASavannahHacker

Projects which are abandoned are not related to Savannah administration.
Rather, if you want to pick up development of an abandoned project, the
thing to do is write the prior authors/developers and get their
permission to take over.

Thanks again,
Karl

Re: [Savannah-hackers-public] How to decide about the acceptability of a project name

[Karl Berry]

However, I want to make sure I'm applying it the way it is intended

We inserted that precisely for the cases like the one at hand:
too-generic and/or too-short identifiers.  Although we shouldn't be
overly finicky about it, it's also a disservice to everyone (including
the project author) to accept undescriptive names.

Should I decide if a name is acceptable or not just judging by
common sense and my sole viewpoint?

Yes, that's fine, though of course also feel free to ask when you're
dubious but don't feel completely sure, as you are here.

To contextualize, the task #13802[0] is the submission of a project
named simply "chat".  It's not reasonably descriptive, 
[0] https://savannah.gnu.org/task/?13802

I agree with you, especially when the code is not working and thus has
zero users.  "foopl" would seem like the obvious identifier here.
(Didn't check if it's available, though.)

best,
k

Re: [Savannah-hackers-public] broken mirrors

[Karl Berry]

Hi Ineiev,

How do we maintain Savannah mirror list?

See http://savannah.gnu.org/maintenance/DownloadArea, last section
("Mirrors") and reverse the steps for removal.  Thanks for asking :).  -k

Re: [Savannah-hackers-public] Criterion regarding minimum acceptable usefulness/capability of submitted packages

[Karl Berry]

I was somewhat sure I'd sent a message asking about this, 

I don't recall seeing it, but don't know for sure.

https://savannah.gnu.org/task/?13796

I wouldn't rule it out on the basis of size, but the LPPL is not
GPL-compatible, so if he's releasing his material under the LPPL, that's
a stopper.

If he's releasing his material under the GPL, that's ok, but

1) it would not be bad to ask him why he wants to host on savannah, and
2) it would not be bad to suggest that he could just upload it as a
package to ctan (ctan.org/upload).  If he wants his template to get into
the TeX distributions, it has to go there anyway.

k

Re: [Savannah-hackers-public] Investigating validation email issues

[Karl Berry]

Are we talking about the same main page[0]?

No.  On savannah.gnu.org, sv administrators have a section in the
left-hand menu for "Site Administration".  The first item in that
section is "Main page".  That's the main page I was talking about.

The other items in the menu are "Pending projects" and "Site news
approval".  All these items are visible but crossed out if you are in
the administration group but not "logged in as superuser" in the web
interface.  -k

Re: [Savannah-hackers-public] Investigating validation email issues

[Karl Berry]

When logged as superuser what's the path from the main page to get
there?

Main page -> Browse users list -> [search one way or another]

It's mentioned, sort of, in the UserAuthentication and
ManuallyChangeE-mail and DeletingUserAccount wiki pages.

Best,
karl

Re: [Savannah-hackers-public] Investigating validation email issues

[Karl Berry]

  https://savannah.gnu.org/support/?108914

It 99.9% likely got filtered.  gmail definitely considers our mail to be
spam, and it has always ended up in their normal spam folder before.
Why the user cannot find it, I cannot say.  It's beyond our control, in
any case.

How can I track down such issues? 

I don't know of any practical way to discern when it left our systems.
I mean, there are mail logs on fe and lists, but I don't know what
string could be searched for.  

How would I proceed to handle this one?

The only idea that I have is to activate the account manually, at
https://savannah.gnu.org/siteadmin/userlist.php?user_name_search=GT9
It's pretty obvious it's a real person.  They've passed far more
stringent Turing tests than our captcha(s) :).   --karl

Re: [Savannah-hackers-public] Submission of Wine programs

[Karl Berry]

What's the policy about accepting programs that run on Wine?  I'm
asking this because of the submission:
https://savannah.gnu.org/task/index.php?13750

I don't recall the question being explicitly asked before.

It seems to me that even if a program runs under Wine, in practice a
package that works only in a Windows environment of whatever kind will
necessarily induce people to use Windows -- thinking that people will go
install wine just to run such a package seems delusionary to me.
Therefore I conclude the submission should not be accepted.
We have certainly rejected Windows-only submissions in the past.

That's my opinion.  If you want to get an official ruling,
gnu-advis...@gnu.org is the place to ask.  --karl

Re: [Savannah-hackers-public] Making Savannah reach grade A in GNU Code Hosting Standards

[Karl Berry]

What's the user-visible page this change propagates to?

https://savannah.gnu.org/register/requirements.php

I forgot to update it.  (It does not happen automatically on commit.)
Done now.  -k

Re: [Savannah-hackers-public] [PATCH 1/2] detect_license: detect the non-free JSON license.

[Karl Berry]

+my $possible_json = ($text =~ /The Software shall be used for 
Good, not Evil/ && $possible_x11);
+$possible_x11 = 0 if $possible_json;

People distribute json files with that too-cute notice?

k

Re: [Savannah-hackers-public] [Savannah-register-public] [task #13715] Submission of Angel's Destiny

[Karl Berry]

   

http://www.gnu.org/licenses/license-list.html#OpenContentL declares the
Open Content License 1.0 as nonfree.  I hope they've fixed whatever the
problems are.

The license must a a free license, as defined by FSF/GNU.

Not just free, but GPL-compatible.  I'd say the license has to be in the
list at
http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
(or be explicitly ok'd by FSF licensing).  Wouldn't you?  In fact, that
seems like something we could/should put into requirements.php.

Right now, we just say "Software licenses must be GPL-compatible.", but
I don't think it is within Savannah's purview to decide if a license is
GPL-compatible or not.  If an author thinks their license is compatible,
but it's not listed, they should have to convince licens...@fsf.org, not
us.  (Usually it's obvious that the desired license is incompatible.)

k

Re: [Savannah-hackers-public] Savannah evaluation for FSF's code hosting service criteria for use with GNU packages

[Karl Berry]

1. Does Savannah report visitors to other organizations?

So far as I know or have ever seen, no.

2. Does Savannah allows anonymous visitors to look and download, 

Yes.

and does not log anything about those visitors?

There are normal web access/download logs which sometimes include
IP addresses.

3. Does Savannah follow the criteria in The Electronic Frontier
   Foundation's best practices for online service providers[0]?

Partially.  Complying with the rest remains in progress.  There have been
previous discussions (initiated by rms) about this.  -k

Re: [Savannah-hackers-public] Unable to moderate Emacs mailing lists

[Karl Berry]

A captcha requirement would reduce it a lot, 

The problem is not so much that they are succeeding in their
subscriptions, but that there is such a flood that merely executing the
python to load the page slows the system to a crawl.  Thus the sysadmins
are working on cutting them off at the apache level, or similar.  The
requests come from thousands of ip addresses so it's not feasible to
block that way.

Anyway, sysad...@fsf.org is the place to send suggestions ...

best,
karl

Re: [Savannah-hackers-public] wiki page 'Why Choose Savannah' - mention recent events?

[Karl Berry]

+Savannah aims for long-term stability and availability - operating since
+late 2000 and hosting source-code which dates back to 1985. Source code
+repositories, mailing lists, websites, FTP/HTTP downloads are all kept
+indefinitely with a stable URL (compared with GoogleCode closing after
+9 years, Gitorious sold and closing down after 7 years, and SourceForge
+problematic takeover of some projects).

I don't think we gain anything by mentioning the other sites.
Tweaked version:

Savannah aims for long-term stability and availability.  It has been
operating since late 2000 and hosts source code which dates back to
1985. Source code repositories, mailing lists, web sites, files for
download, tracker items, etc., are all kept indefinitely with stable
urls.

Thanks,
K

Re: [Savannah-hackers-public] wiki page 'Why Choose Savannah' - mention recent events?

[Karl Berry]

I was wondering if it's worth mentioning long-term stability and 
availability ?

Sounds good to me.

Re: [Savannah-hackers-public] [gnu.org #1014158] New mirror: ftp.acc.umu.se (Sweden)

[Karl Berry]

 http://ftp.acc.umu.se/mirror/gnu.org/savannah/
 rsync://ftp.acc.umu.se/mirror/gnu.org/savannah/

Thanks, added to the sv mirror list.

In the future, please include the country where the mirror is located
and admin contact name and email.

best,
karl

Re: [Savannah-hackers-public] [gnu.org #1017575] New Mirror

[Karl Berry]

http://mirror.unicorncloud.org/savannah-nongnu/
https://mirror.unicorncloud.org/savannah-nongnu/

Thanks, added to the sv mirror list.

In the future, please include the country where the mirror is located
and admin contact name and email.

best,
karl

[Savannah-hackers-public] submit changes and return to this item

[Karl Berry]

For the record ... here is the patch that I just referred to in
https://savannah.gnu.org/task/?13522#comment13.  I happened to get the
same nogroup message on puszcza as the OP did here, and Sergey fixed
it in short order.  (Thanks Sergey.)  I just committed the patch to
administration/savane.git; it applied fine (only uselessly annoying
whitespace differences).

karl


From: Sergey Poznyakoff g...@gnu.org.ua
Date: Sat, 4 Apr 2015 09:13:20 +0300
Subject: [PATCH] Fix 'submit and return to this item'.

Clicking on submit changes and return to this item button would
return to the item, but the item_id in the URL would be lost. This
caused all relative links on the page to become invalid.

Reported by Karl on 2015-04-02 201504021742.t32hgwl7007...@freefriends.org.

* frontend/php/include/trackers_run/index.php: Use redirect instead of
file inclusion when 'submit and return to this item' is requested.
---
 frontend/php/include/trackers_run/index.php | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/frontend/php/include/trackers_run/index.php 
b/frontend/php/include/trackers_run/index.php
index dfa7aad..abc3c36 100644
--- a/frontend/php/include/trackers_run/index.php
+++ b/frontend/php/include/trackers_run/index.php
@@ -505,9 +505,7 @@ switch ($func)
 $reassign_change_project,
 $reassign_change_artifact);
}
-

-
  # show browse item page, unless the user want to get back
  # to the
  # same report, to make something else
@@ -517,13 +515,21 @@ switch ($func)
}
  else
{
-$_POST = $_FILES = array();
-$form_id = $depends_search = $reassign_change_project_search = $add_cc
-  = $input_file = $changed = $vfl = $details = $comment = null;
-$nocache = 1;
-include '../include/trackers_run/mod.php';
+if (preg_match(/:\/\/($sys_default_domain)|($sys_https_host)/,
+   $_SERVER[HTTP_REFERER]))
+   {
+header('Location: ' . $_SERVER[HTTP_REFERER]);
+  }
+ else
+   {
+$_POST = $_FILES = array();
+$form_id = $depends_search =
+ $reassign_change_project_search = $add_cc =
+ $input_file = $changed = $vfl = $details = $comment = null;
+$nocache = 1;
+include '../include/trackers_run/mod.php';
+   }
}
-
  break;
}

--
1.8.3.1

Re: [Savannah-hackers-public] improving spf (anti-spam) measures from outgoing emails from savannah

[Karl Berry]

Do you think adding a DNS TXT
record could improve the SPF filtering?

It might help, is unlikely to hurt, but SPF is no panacea.

One of the things in Sergey's patch is to change the From: address to be
that of the user posting the item/comment, instead of invalid.noreply.
I rather suspect that would help at least as much.

k

Re: [Savannah-hackers-public] cgit/gitweb - owner updates

[Karl Berry]

BTW, I just thought of one more point: if the purpose of the owner field
is to provide a way for people to contact the maintainers, only bug-PKG
(not bugs-PKG, by the way) would do, I think.  Maintainers are not
obligated to be on any help or discussion list by the GNU standards.
Although it's true that in practice they almost(?) always are.

Anyway, looking at your file, findutils should be bug-findutils rather
than findutils-patches.  I didn't see any other immediate discrepancies.

thanks,
karl

Re: [Savannah-hackers-public] cgit/gitweb - owner updates

[Karl Berry]

Hi Assaf,

Though there are few existing cases of names being used for owners:

If a person decides to put their own name in, that's up to them.
My point was, we shouldn't do it automatically.

emacs.git Jim+Meyering

Certainly wrong, as Jim would be the first to say.
Which makes me think this information doesn't actually matter.
So why are we spending time on it at all?

There are several packages (gnu included) which have other lists for
more general discussions, and not for bugs.

Yep, I am well aware of this.  I spend my life dealing with gnu and
nongnu (and tug) mailing lists.  Not much of a life :).

Would you think these are more suitable for initial contact, 

For initial contact, yes, a help list would be better.  It all depends
on what this owner information is for.

But a couple of your proposed lists didn't seem good to me.  I'll have
to look at your list.  I'll do that and get back to you as soon as I
can.  (Won't be today.)

Meanwhile, the principal reason I proposed bug-PKG is because: what
happens when a new package is approved, a git repository is created
.. and the information is blank.  You can't put a help list in because
it's a new package.  What are you going to do?  Only bug-PKG should work
(eventually).  There's no way of knowing when, if ever, another list
will be created.  

Personally, it seems much more useful to me (though much less fun,
granted) to provide a UI so owners can update the info themselves than
worrying about what value to automatically inflict on existing
repositories.

thanks,
karl

Re: [Savannah-hackers-public] cgit/gitweb - owner updates

[Karl Berry]

Which one do you think is better?

A generic email address, definitely.  Or else do nothing.

It would be wrong to, e.g., call me the owner of administration,
or rms the owner of Emacs or Jeff Bailey the owner of tar,
so don't do that in any event.  At least with generic email addresses,
we're not specifying wrong information.

Furthermore, I think I would suggest uniformly using
bug-pkgn...@gnu.org.  Per GNU standards, that address is always supposed
to exist and be monitored for bug reports.  (Although I know some
packages do not do so, but that's a different problem.)  There is no
other per-package address like that.

Also, that way the info could be automatically created.  We don't want
to create yet more places that maintainers are supposed to insert
redundant information.

Above is for gnu packages.  For nongnu, I can't think of anything to be
done.  (Aside from the well-known todo of creating a UI so package
admins can update the info themselves.)

karl

Re: [Savannah-hackers-public] [Savannah-cvs] lwip_socket() return null

[Karl Berry]

Hi,

To: savannah-...@gnu.org
Subject: [Savannah-cvs] lwip_socket() return null

This needs to go to an lwip list, not the general savannah lists ...

Best,
Karl

Re: [Savannah-hackers-public] disk-usage monitoring on vcs.sv.gnu.org

[Karl Berry]

So something like the following, once a week:

Right.  Maybe --exclude=/proc, as Bob mentioned.

  du --one-file-system --human --bytes --separate-dirs / \

Better to leave out --human, since it's a lot easier for a script to
subtract two actual numbers than something like 2.1M from 1.1G.
Also I wouldn't bother with --bytes; when it comes to disk space, kb is
easier to think in, and the exact number of bytes isn't really crucial.
Anything important will be a lot of megabytes anyway.

Thanks,
Karl

Re: [Savannah-hackers-public] disk-usage monitoring on vcs.sv.gnu.org

[Karl Berry]

As long as you're doing a du of everything -- when looking for disk hogs
(wasn't that what we were talking about initially?), you need to know
the exact directory.  I find GNU du's --separate-dirs option the most
useful approach.

The summary could be useful to see how usage changes over time, I guess,
though.

On another diskfull front: frontend's disk has been 100% full for a
while, for the same reason as before.  I'm wasting my time dealing with
it again.  Can nagios be configured to send a report, say, hourly when
any partition is, say, 98% (= requires action)?  If not, a trivial
shell script that just runs df would do the job.

K