[sr #106712] accepting follow-ups by email

[Ineiev]

Update of sr #106712 (group administration):

  Depends on: => support #107431


___

Reply to this item at:

  

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

[sr #106712] accepting follow-ups by email

[Ineiev]

Update of sr #106712 (group administration):

  Depends on: => support #110907


___

Reply to this item at:

  

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

[sr #110907] reply-to emails which are comments on bugs

[Ineiev]

Update of sr #110907 (group administration):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up Comment #6:

This request duplicates the recently re-opened sr #106712.


___

Reply to this item at:

  

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

[sr #111062] Can log into savannah.nongnu.org but not savannah.gnu.org

[Ineiev]

Update of sr #111062 (group administration):

  Status: In Progress => Ready For Test 

___

Follow-up Comment #8:

Thank you, now I can reproduce this.

[comment #6 comment #6:]
> session_hash=(something else) (domain=.savannah.gnu.org)
...
> session_uid=(the same value) (domain=.savannah.gnu.org)

It turns out that these stale cookies override the new ones; I've added some
code to remove them.

Let us see if other people are affected by other bugs.


___

Reply to this item at:

  

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

[sr #111062] Can log into savannah.nongnu.org but not savannah.gnu.org

[Ineiev]

Follow-up Comment #5, sr #111062 (group administration):

Thank you, this is helpful.

Can you list your cookies for savannah.gnu.org and savannah.nongnu.org
(without their values)?


___

Reply to this item at:

  

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

[sr #111062] Can log into savannah.nongnu.org but not savannah.gnu.org

[Ineiev]

Follow-up Comment #2, sr #111062 (group administration):

I can't reproduce this.  I did push a cookie-related commit, but I don't think
it fixed the bug.  If the problem persists for you, could you list your
cookies for savannah.gnu.org and savannah.nongnu.org (without their values)?


___

Reply to this item at:

  

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

[sr #111062] Can log into savannah.nongnu.org but not savannah.gnu.org

[Ineiev]

Update of sr #111062 (group administration):

  Status:None => In Progress
 Assigned to:None => ineiev 


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111062>

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

[sr #111061] Submitting a new item no longer navigates to the new ticket on success

[Ineiev]

Update of sr #111061 (group administration):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[sr #111061] Submitting a new item no longer navigates to the new ticket on success

[Ineiev]

Update of sr #111061 (group administration):

  Status:None => Need Info  
 Assigned to:None => ineiev 

___

Follow-up Comment #1:

I can't reproduce this; groff bug tracker works for me.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111061>

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

[sr #111059] stop discarding infromation in "Duplicate posts"

[Ineiev]

Update of sr #111059 (group administration):

  Status:None => In Progress
 Assigned to:None => ineiev 

___

Follow-up Comment #2:

[reordered]

[comment #0 original submission:]
... 
> what I want to see is a dump of the field changes that were submitted, and
above all the text of the comment that couldn't be posted, because that often
takes a lot of time and thought to compose.

Thank you, done.

...
> I believe I understand the necessity of not performing a ticket update
against stale data.

This feature isn't really intended for dealing with 'stale' data, it's about
posting the same message multiple times, and more important, it is used to
block cross-site scripting.

> ...So possibly "Duplicate post" is being thrown for spurious or excessively
aggressive reasons, like the age of some cookie, or because some server got
rebooted.

It may, but at this point, I have no sufficient data to tell.  The feature
doesn't depend on cookies in the strict sense or on rebooting the server. 
This is how it works.

When a user visits a page containing a form, a form_id token is saved in
Savane database and inserted on the page; when the form is submitted, the
request is only honored when the token is present both in the request and in
the database (e.g. a malicious page from a third party website can't embed
it), and at the same time the token is removed from the database.  Then, a
cron job removes the tokens more than a day old; that period could be
increased, but we should clear them at some point.

I'm not sure how this mechanism can be improved or replaced.

[comment #1 comment #1:]
> ...it does nothing to prevent collisions...

No, it doesn't.  The server could add the previous state to the form and then
check against it, but that would be more than a dozen or two lines of Savane
code.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111059>

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

[sr #111057] textprogramme

[Ineiev]

Update of sr #111057 (group administration):

  Status:None => Invalid
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[sr #111056] Question (Request) about my account

[Ineiev]

Update of sr #111056 (group administration):

Category:None => Savannah website   
  Status:None => Done   
 Assigned to:None => ineiev 
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Savannah accounts (profiles) are only removed when

* they prove [//savannah.nongnu.org/maintenance/IdleAccounts/ idle]
* their users remove them
* they are abused (typically, to post spam in the trackers)

As an anti-spam measure, the resume text
[//savannah.nongnu.org/people/resume.php?user_id=7475 like in ] is only
available for people who are members of any group and for those who already
have a non-empty resume.  In particular, I've just added an initial resume for
you account, you can edit it and make it publicly visible in your *Account
Conf -> Edit Resume and Skills*.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111056>

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

[sr #111052] cannot create account

[Ineiev]

Update of sr #111052 (group administration):

  Status: In Progress => Need Info  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[sr #111023] My account is in some weird half-existent state

[Ineiev]

Update of sr #111023 (group administration):

Operating System:   GNU/Linux => None   
 Open/Closed:  Closed => Open   

___

Follow-up Comment #3:

I can see that someone tried to reset the password of the account in question;
please confirm in case it was you and you succeeded.


___

Reply to this item at:

  

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

[sr #111052] cannot create account

[Ineiev]

Update of sr #111052 (group administration):

  Status:None => In Progress


___

Reply to this item at:

  

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

[sr #111052] cannot create account

[Ineiev]

Update of sr #111052 (group administration):

 Assigned to:None => ineiev 

___

Follow-up Comment #1:

Our records suggest that an account with your email was only created in
2024-02, then it was activated, but later it was automatically removed because
of [//savannah.nongnu.org/maintenance/IdleAccounts/ inactivity].

Please try again, and make sure that no error messages (like weak password or
wrong captcha) show up.  I've just tested the registration form and received a
confirmation email (I have no Gmail account, though, so I used a different
service).


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111052>

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

[sr #111023] My account is in some weird half-existent state

[Ineiev]

Update of sr #111023 (group administration):

  Status: In Progress => Need Info  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

No response; closing.


___

Reply to this item at:

  

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

[sr #111023] My account is in some weird half-existent state

[Ineiev]

Update of sr #111023 (group administration):

Originator Email: => nova...@novalis.org


___

Reply to this item at:

  

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

[sr #111036] llvm internal options are ignored by libtool.

[Ineiev]

Update of sr #111036 (group administration):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[sr #111049] Bug links in comments stopped working

[Ineiev]

Update of sr #111049 (group administration):

 Assigned to:None => ineiev 
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thank you, fixed.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111049>

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

Re: Fwd: [gnu.org #2042083] savannah.gnu.org query, how to recover username

[Ineiev]

On Tue, Apr 09, 2024 at 12:42:15PM +0900, Jing Luo wrote:
...
> From: "Ed Avis via RT" 
...
> I would have filed a support request on the Savannah site, but to file a
> request you have to be logged in...

For the record: Savannah administration support tracker does accept
anonymous support requests; the requestor can fill the 'Originator
Email' field to have follow-up notifications.

[sr #111034] llvm internal options are ignored.

[Ineiev]

Update of sr #111034 (group administration):

  Status:None => Invalid
 Assigned to:None => ineiev 
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

You've reached the support tracker of Savannah, the software forge; however,
your request is about some software, and unfortunately, it isn't clear what
software package you are reporting about.  So I can only suggest that you find
the right communications channel.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111034>

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

[sr #110973] AGPL notices not correct

[Ineiev]

Follow-up Comment #5, sr #110973 (group administration):

Is Bob rewriting frontend?


___

Reply to this item at:

  

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

[sr #111028] In email bodies, space disappeared in bug identifier

[Ineiev]

Update of sr #111028 (group administration):

  Status:None => Done   
 Assigned to:None => ineiev 
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thank you, fixed.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111028>

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

Re: How to build savane now?

[Ineiev]

On Tue, Feb 27, 2024 at 05:09:42PM -0700, Bob Proulx wrote:
> >
> > INSTALL is expected to cover this; is there anything
> > that doesn't work for you, specifically?
> 
> I don't think anyone was previously aware of the recent changes to
> INSTALL as RunningSavaneLocally has been widely discussed.

I don't recall widely discussing RunningSavaneLocally.

> > > * Run a local development server with php -S
> >
> > Use $prefix/sbin/sv_php_server.pl.
> 
> I will give it a test drive.

Thank you!

> > > * Be able to make and test changes
> >
> > Again, this seems too abstract to me.
> 
> It's a self-obvious statement.  We need to be able to make changes,
> test changes, and deploy changes.  Those actions are concrete.

Actions may be concrete, but the real obstacles are not obvious.


signature.asc
Description: PGP signature

Re: Extremely large change wave?

[Ineiev]

On Tue, Feb 27, 2024 at 05:48:47PM -0700, Bob Proulx wrote:
> > I believe the most important change from Savannah admins' viewpoint
> > wasn't in fact in the code.
...
> That's a good example of a fundamental change which had no
> communication nor coordination.  Though it is a change that I would
> generally support.  But the result is that it leaves everyone else
> lost at sea without any footing.
>
> > I did it on Jan, 31, when migrating to frontend2, and I mentioned
> > I was going to do that even earlier, when the fundraiser was
> > running.
> 
> This detail must have been missed in the communications.

That's true, I'm a lousy communicator. I beg for indulgence.

> > > Just on the surface I see the following confusing things.
> > >
> > > * All of the .gitignore files have been deleted.  This causes a large
> > >   amount of noise files to appear in the git status.  What's the plan
> > >   for this?
> >
> > When I use a separate build tree, git status only shows these files
> > [reordered]:
> >
> >   configure Makefile.in frontend/Makefile.in lib/Makefile.in
> >   po/Makefile.in autotools/m4/Makefile.in
> >   aclocal.m4 autom4te.cache/ autotools/install-sh autotools/missing
> >   po/stamp-po po/savane.pot
> >   po/ca.po~ po/de.po~ po/es.po~ po/fr.po~ po/he.po~ po/it.po~
> >   po/ja.po~ po/pt_BR.po~ po/ru.po~ po/sv.po~
> >
> > I don't think the amount is really large and noisy.
> 
> Really?

Yes, those are all the items git status shows,
and no, I don't think it's too many.

> I was seeing at least three pages of differences!

22 lines fit in one standard page; ten of them are backup PO files,
perhaps it wouldn't be hard to avoid generating them.

> Requiring
> the use of a pager to skip over files that should not be committed is
> not a good thing.

What about recommending VPATH builds?
https://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html

Missing files that should be committed is a bad thing, too.

> And now documentation can be
> updated to make it possible for other people who are not you to clone
> the repository and do work with it.

PHP built-in web server isn't intended to be a full-featured server;
instead, INSTALL refers to a script that runs Apache from a non-root
account.

> > The files in /opt/savannah/savane are leftover from the times when
> > frontend2 served as frontend.
> 
> That's quite the pitfall to leave behind.

It may be, but it isn't extremely unusual for Savannah.

> > mgt1:ChangeLog does include some records; general setup is now
> > outlined in .
> 
> I see that is a new file created on Feb 24.  I wrote my message on the
> 25th so of course being new I would not have known abou it.  It's only
> the 27th today.  That's really a very new file!

mgt1:ChangeLog is no way new, and it contains sufficient info;
its daily diffs are forwarded to a mailing list. SavaneSetup.mdwn
is new, but it only finalizes the unification that started
in 2023-05, according to mgt1:ChangeLog records. then, the wiki
repository has a log feature, and a mailing list for the commits is
functioning. worst comes to worst, your humble servant is responsive
as a rule of thumb.

> Writing that as if it
> has been there for a long time is again disingenuous at best.

I'm sorry, I wasn't clear. I wrote 'now', and I implied that it was
a recent development.

...
> The files you work with in your local sandbox may have
> been there for years and no one else will have been able to see them,
> to view them, to comment upon them, or even to know if they are
> happening at all.  Those private dates do not matter.  The only dates
> that matter are the dates when they become visible to us.
...

I'm glad you recognize that. I have no habit of working on Savane
privately, I rarely push later than the same day I write the commit.
and in particular, preliminary but functional versions of the commit
I mentioned, 9fd58ef254ab, and the subsequent 91cf0c8012, were
in the official Savane repository on 2023-09-19 or earlier
(I've just checked the oldest occasional backup I have).
IIRC Jing Luo commented upon them in December, and I don't recall
reports for any issues with finding the development sources.

And I hope your note applies to other people to a degree.


signature.asc
Description: PGP signature

Re: [sr #111026] AGPL spamming my `git pull` outputs

[Ineiev]

On Tue, Feb 27, 2024 at 09:27:58AM -0500, Stefan Monnier wrote:
> > How does the script tell which connection is interactive?
> 
> Usually that's done by testing if the output is a tty.

user@host:~$ ssh ine...@cfarm110.cfarm.net cat tty.pl
#! /usr/bin/perl
print "tty(?)\n" if -t 1;
print "scripted(?)\n" unless -t 1;
user@host:~$ ssh ine...@cfarm110.cfarm.net
Last login: Tue Feb 27 
ineiev@gcc1-power7:~$ ./tty.pl
tty(?)
ineiev@gcc1-power7:~$ logout
Connection to cfarm110.cfarm.net closed.
user@host:~$ ssh ine...@cfarm110.cfarm.net ./tty.pl
scripted(?)
user@host:~$


signature.asc
Description: PGP signature

Re: [sr #111026] AGPL spamming my `git pull` outputs

[Ineiev]

On Tue, Feb 27, 2024 at 08:05:42AM -0500, Stefan Monnier wrote:
> 
> I see no reason why it needs to display the notice on every connection,
> including those whose output is processed by a program
...
> I already suggested we can display it only on interactive connections.

How does the script tell which connection is interactive?

> >> ...the majority of people who use Git with Savannah -- who haven't logged 
> >> in
> > to the Savannah web app to toggle the "Quiet SSH member shell" setting.
> > Any user has to log in Savannah web UI in order to register SSH keys; 
> > without
> > that, people can't access non-anonymous VCS.
> 
> So why not display the notice right there when they register an SSH key?

Thank you, I'm discussing this option with rms.


signature.asc
Description: PGP signature

[sr #111026] AGPL spamming my `git pull` outputs

[Ineiev]

Follow-up Comment #8, sr#111026 (group administration):

[comment #7 comment #7:]
> The AGPL itself does not require this kind of notice, as far as I can tell,

The AGPL requires that the program in question prominently offer every its
user the corresponding source code; I believe the current implementation
complies with that, and rms has confirmed it does.

It doesn't seem helpful to me to say, 'we needn't do it this way'---not
without explaining, 'we can do it such or such way instead'.

> ...the majority of people who use Git with Savannah -- who haven't logged in
to the Savannah web app to toggle the "Quiet SSH member shell" setting.

Any user has to log in Savannah web UI in order to register SSH keys; without
that, people can't access non-anonymous VCS.


___

Reply to this item at:

  

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

[sr #111026] AGPL spamming my `git pull` outputs

[Ineiev]

Update of sr#111026 (group administration):

  Status:Works For Me => In Progress
 Assigned to:None => ineiev 
 Open/Closed:  Closed => Open   

___

Follow-up Comment #5:

[comment #4 comment #4:]
> I'm not asking to change the AGPL, just to fix an obvious bug in the way
those notices are implemented.

Do you suggest a rewording, a different behavior, anything else?


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111026>

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

[sr #111022] My Savannah account keeps getting removed due to inactivity

[Ineiev]

Update of sr#111022 (group administration):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[sr #111026] AGPL spamming my `git pull` outputs

[Ineiev]

Update of sr#111026 (group administration):

Category:None => Source code repositories
- developer access
  Status:None => Works For Me   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thank you for your feedback.

It may be problematic, but changing the AGPL would be a greater trouble.

In case your scripts are hard to repair, you can set the 'Quiet SSH member
shell' option in the Savannah accounts you use.


___

Reply to this item at:

  

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

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

[Ineiev]

On Sun, Feb 25, 2024 at 12:23:54AM -0700, Bob Proulx wrote:
> > I'm not sure why. the permissions will prevent anonymous access.
> > that's what Savannah has always done with CVS directories of private
> > groups.
> 
> This is in a PUBLIC DIRECTORY.  Everything has always assumed that all
> of those files are publically accessible files.

Private groups with CVS repositories have been existing since 2001.
I don't think the layout of CVS repositories had any changes
in the last two decades. in 2006 (when Savane Git history starts),
Cvs.pm already sets the permissions of new repositories according to
the is_public field.

> Trying to block a
> list of private files from the default access of private files goes
> against almost all security practices.  Private files should be
> located in a private directory to avoid the possibility entirely.

/ is world-readable, isn't it? and typical $HOME as well.

> Here are some examples.
> 
> At one time people used to write PHP projects such that all of the
> files were in a root directory.  But usually one of those files must
> contain the database access credentials.  Call that config.php for
> discussion since that was usually the name of it.
> 
> phpproject/index.php
> phpproject/admin/config.php
> phpproject/admin/index.php
> 
> Malicious agents found that often, very often, web sites were not
> configured to block access to that file.  It was often possible to
> gain access to that private file because it was located in a public
> directory.  Due to that universially PHP projects never put the config
> file in the public directory and now relocate that to a directory
> outside of the public area.  It avoids any possibility of malicious
> access to it.  Now the root is public and served but the include
> directory is not made public avoiding those types of accidents.

Still blocking access to that file does mitigate those attacks. 
(Moving it out of public directory sometimes doesn't e.g. when users
are allowed to create symbolic links.)

> It used to be that people wrote firewall scripts allowing everything
> but blocking what they wanted to block.
> 
> ACCEPT ALL
> DROP 1433
> DROP 1434
...
> But the problem is that there are an increasing number of malicious
> attacks and this strategy was not sustainable.  Everyone has
> universially moved to the opposite strategy of blocking everything by
> default and then only allowing the things they want to allow.

I'm not sure the analogy applies very well. we have very few private
groups, their number isn't likely to grow considerably, and it's
clear if the given repository should be public or not.

Then, we do use file permissions (complicated with ACLs) to limit
the write access; why can't we use them to limit the read access?


signature.asc
Description: PGP signature

Re: Extremely large change wave?

[Ineiev]

On Sun, Feb 25, 2024 at 12:13:35AM -0700, Bob Proulx wrote:
> 
> I am trying to understand the large change wave that has been
> committed in the last few days.

Last quite a few months, in a sense. the date of 9fd58ef254ab is
2023-08-16.

> I made a commit on Feb 8 a894e1 and for example between then and now I
> see many commits resulting in this large diff.
> 
> $ git diff a894e1..HEAD | diffstat | tail -n1
>  386 files changed, 56532 insertions(+), 16683 deletions(-)

Most of insertions are in two new data files,
backend/external/cities15000{.txt,}, though.

> That is a very large number of changes in a very short period of time!
> This has only been in the last few days.

I believe the most important change from Savannah admins' viewpoint
wasn't in fact in the code. it was in how the frontend code is
installed. previously, what was used were basically a Git clone
(which wasn't actually supported); then I migrated to a regular
installation.

I did it on Jan, 31, when migrating to frontend2, and I mentioned
I was going to do that even earlier, when the fundraiser was
running.

> Just on the surface I see the following confusing things.
> 
> * All of the .gitignore files have been deleted.  This causes a large
>   amount of noise files to appear in the git status.  What's the plan
>   for this?

When I use a separate build tree, git status only shows these files
[reordered]:

  configure Makefile.in frontend/Makefile.in lib/Makefile.in
  po/Makefile.in autotools/m4/Makefile.in
  aclocal.m4 autom4te.cache/ autotools/install-sh autotools/missing
  po/stamp-po po/savane.pot
  po/ca.po~ po/de.po~ po/es.po~ po/fr.po~ po/he.po~ po/it.po~
  po/ja.po~ po/pt_BR.po~ po/ru.po~ po/sv.po~

I don't think the amount is really large and noisy.

> * The local development router has been removed.  This was being used
>   to run a local sandbox.
> 
> * The script that was used to launch the local development router has
>   been removed.

To be precise, they weren't removed, they were replaced with scripts
that take into account configure-time settings; moreover, an option
to specify the path to the PHP executable was added (to say nothing
of the standard --help and --version), a450ed9468.

> On the frontend servers the files being served had been in version
> control at /opt/savannah/savane.  Those files are still there but the
> version control has not been updated in a very long time.  Yet I think
> as recently as last month when the fundraising banner was removed that
> it had been updated.

The files in /opt/savannah/savane are leftover from the times when
frontend2 served as frontend.

> I see that apparently on Jan 31 this has been changed to serve files
> from /opt/savane/share/savane/frontend/php as what appears to be an
> installed files area.  But I can't find any indication of where those
> files are being installed from or from what version.

mgt1:ChangeLog does include some records; general setup is now
outlined in .

> When I look through the version control commit message history I see a
> lot of very confusing things that indicate to me that the timeline was
> committed and then reset and then re-committed differently.

I often modify and reorder commits before they enter the master branch,
typically because

* a commit may need fixing, or it may be incomplete; committing
  every fix at HEAD would make the history more complicated than
  necessary; or

* some commits seem ready for master, i.e. it doesn't look like
  they'll need fixing; then I move them closer to master (or just
  push them into master).

Git preserves the original dates, as far as I can tell.


signature.asc
Description: PGP signature

Re: How to build savane now?

[Ineiev]

Hello, Bob;

On Sun, Feb 25, 2024 at 12:13:28AM -0700, Bob Proulx wrote:
> These are the things that we need to be able to do.
>
> * Build a local copy of savane

INSTALL is expected to cover this; is there anything
that doesn't work for you, specifically?

> * Run a local development server with php -S

Use $prefix/sbin/sv_php_server.pl.

> * Be able to make and test changes

Again, this seems too abstract to me.

> * Be able to release changes

Generally,
  https://savannah.gnu.org/maintenance/SavaneReleases/
  https://savannah.gnu.org/maintenance/SavaneSetup/


signature.asc
Description: PGP signature

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

[Ineiev]

On Sat, Feb 24, 2024 at 02:07:15PM -0700, Bob Proulx wrote:
> 
> I see that nothing more has happened on this issue since then.  My bad
> that I have been busy with other things and not driving on this issue.
> 
> What's the plan to address the security vulnerability by having this
> private directory in the public directory area?  That's something that
> needs to be fixed.  Otherwise it will always be a source of errors
> making private data public.  And trying to keep it private will be an
> endless wack-a-mole of trying to block it.

I'm not sure why. the permissions will prevent anonymous access.
that's what Savannah has always done with CVS directories of private
groups.


signature.asc
Description: PGP signature

Re: not getting new account confirmation email

[Ineiev]

On Fri, Feb 23, 2024 at 11:43:40AM -0500, Rob Musial wrote:
> 
> I registered an account yesterday, robmusial, the email is
> robmus...@gnu.org. I am not getting a confirmation email for it. I have
> checked that the email address works. Any help would be appreciated!

Your account is active.  Have you received a confirmation email?


signature.asc
Description: PGP signature

[sr #111024] cannot create account

[Ineiev]

Update of sr#111024 (group administration):

  Status:None => In Progress
 Assigned to:None => ineiev 

___

Follow-up Comment #1:

I've activated your account manually; please try logging in.

Our logs say that messages to your email were queued.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111024>

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

[sr #111023] My account is in some weird half-existent state

[Ineiev]

Update of sr#111023 (group administration):

Category:Savannah website => Lost account   
  Status:None => In Progress
 Assigned to:None => ineiev 

___

Follow-up Comment #1:

That form accepts user names rather than emails.  Your user name is novalis. 
Can you try again?


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111023>

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

[sr #111022] My Savannah account keeps getting removed due to inactivity

[Ineiev]

Update of sr#111022 (group administration):

  Status:None => Need Info  
 Assigned to:None => ineiev 

___

Follow-up Comment #1:

You've already done, by posting on this tracker.

...or do you mean that you posted in other trackers, and despite that your
account was removed?  Our logs have no records about deleting accounts named
.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111022>

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

[sr #111012] No git repositories found

[Ineiev]

Follow-up Comment #8, sr#111012 (group administration):

[comment #7 comment #7:]
> Yes, I can confirm yesterday's problem has been fixed (it was already fixed
yesterday, but I only got around to replying now); 

Anyway, thank you for reporting.  Next time the bug you'll notice won't be
being worked on.

> And sorry for coming to this issue, I came here through [1] and I must have
mistaken the green color for "Open" despite the open/closed field clearly
stating "Closed".

Never mind; the formalities are less important than the subject itself.


___

Reply to this item at:

  

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

[sr #111021] CSP header and inline style in testconfig.php

[Ineiev]

Update of sr#111021 (group administration):

  Status:None => Done   
 Assigned to:None => ineiev 
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thank you, done.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111021>

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

[sr #111012] No git repositories found

[Ineiev]

Follow-up Comment #6, sr#111012 (group administration):

[comment #4 comment #4:]
> Is this issue still ongoing?

No.

> I just noticed http://git.savannah.gnu.org/cgit/gnupod.git/ is reachable but
is completely unrelated to gnupod.
...
[comment #5 comment #5:]
> (I just found that gnupod is at
http://git.savannah.gnu.org/cgit/gnulib/maint-tools.git/ 

I believe I've just committed and fixed it.  Please try again.


___

Reply to this item at:

  

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

Re: [Savannah-hackers-public] mirror-redirect me to cloudflare cdn

[Ineiev]

On Fri, Feb 16, 2024 at 11:05:51PM +0900, Jing Luo wrote:
> Well, now I'm being redirected to:
> 
> Suggested mirror: https://quantum-mirror.hu/mirrors/pub/gnusavannah [hu]
> 
> even though there is only one mirror in Asia :)

Thank you, fixed (the parser didn't realize that
https://mirror/nongnu and https://mirror/nongnu/ was the same).


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] mirror-redirect me to cloudflare cdn

[Ineiev]

On Fri, Feb 16, 2024 at 07:25:54PM +0900, Jing Luo via Discussions among 
Savannah Hackers, open subscription wrote:
> 
> After Ineiev changed something in mirror-redirect, I've been redirected [1]
> to a cloudfuck cdn

I've removed that mirror from Savannah list.

> while the nearest mirror is literally within the same /64
> subnet with my PC. Before this month, I was redirected to mirrors located in
> the US.

The heuristics did change, but now we can override it when it drives
in wrong directions from any particular country.


signature.asc
Description: PGP signature

[sr #110973] AGPL notices not correct

[Ineiev]

Update of sr#110973 (group administration):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[sr #111001] unsafe permission in www-zh-cn CVS source repo

[Ineiev]

Update of sr#111001 (group administration):

  Status:   Need Info => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #7:

I've cleared the execution bit in all files in www-zh-cn CVS source
repository; the rest is up to the team.


___

Reply to this item at:

  

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

Re: [Savannah-hackers-public] Don't multiplex mirror URLs that use nonfree JavaScript ?

[Ineiev]

On Tue, Feb 13, 2024 at 06:42:45PM +0100, Thérèse Godefroy wrote:
> > Correct; moreover, the new script has been installed in its place.
> 
> Thanks a whole lot! :)
> Does it mean we can move the files in staging to www/prep/?

Yes, as far as the scripts are concerned.


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] Don't multiplex mirror URLs that use nonfree JavaScript ?

[Ineiev]

On Wed, Feb 14, 2024 at 01:04:25AM +0900, Jing Luo wrote:
> > 
> > Now that mirrors using nonfree JavaScript are marked, don't you think
> > it's time to fix the FTP-to-mirmon script so it generates a list that
> > doesn't contain them, for the multiplexor? Thanks!
> 
> I'm not following up well enough, but it looks like some scripts are making
> their way into savane repo [1].

Correct; moreover, the new script has been installed in its place.


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] Don't multiplex mirror URLs that use nonfree JavaScript ?

[Ineiev]

On Wed, Feb 07, 2024 at 03:55:05PM +0100, Thérèse Godefroy wrote:
> > This version lacks the last passage ("Add your mirror"); currently,
> > the script uses it to make sure its input is the right file. I'm not
> > sure if we should leave it in FTP or update the script.
> 
> The current script relies on "Add your mirror" to close the last list
> with \n. It can't even add a  at the end of "Add your
> mirror"! This  is in ftp-eol.

Good point.

Re: [Savannah-hackers-public] Don't multiplex mirror URLs that use nonfree JavaScript ?

[Ineiev]

On Tue, Feb 06, 2024 at 11:05:44AM +0100, Thérèse Godefroy wrote:
> I applied your patch to the staged version:
> https://www.gnu.org/server/staging/prep/

Thank you!

This version lacks the last passage ("Add your mirror"); currently,
the script uses it to make sure its input is the right file. I'm not
sure if we should leave it in FTP or update the script.


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] Don't multiplex mirror URLs that use nonfree JavaScript ?

[Ineiev]

On Mon, Feb 05, 2024 at 07:15:27PM +0100, Thérèse Godefroy wrote:
> 
> If a mirror is marked, it won't be used for redirections; _why_ it is
> marked is unimportant. We want to keep /prep/FTP as simple as possible,
> so I think one marker per mirror is enough for the time being. If we
> need more in a few years, we can easily change a few lines in
> ftp_convert.pl.

I don't think it makes /prep/FTP less simple, however, it does make
the file more maintainable.

Index: wrappers-and-scripts/ftp_convert.pl
===
RCS file: /web/www/www/server/staging/prep/wrappers-and-scripts/ftp_convert.pl,v
retrieving revision 1.3
diff -U 2 -r1.3 ftp_convert.pl
--- wrappers-and-scripts/ftp_convert.pl 5 Feb 2024 18:12:55 -   1.3
+++ wrappers-and-scripts/ftp_convert.pl 6 Feb 2024 08:35:54 -
@@ -7,5 +7,5 @@
 # this page. See the Makefile.
 #
-# Original Script Written by jo...@gnu.org
+# Public domain.  Original script written by jo...@gnu.org.
 #
 # 01/02/1999 - Murali - Added support for http sites on the ftp list
@@ -13,5 +13,5 @@
 # 26/07/2010 - bjg - add rel="nofollow" to mirror links
 # 01/02/2024 - th_g - Simplify (disable support for ); don't convert
-#   http(s) URLs marked with '_' or '__'; add support for additional lists;
+#   http(s) URLs marked with '[m0, m1...]'; add support for additional lists.
 
 use strict;
@@ -41,4 +41,27 @@
 die "Incorrect format, start with How to get." unless /^How to get/;
 
+sub get_place_markers
+{
+  my $markers = '';
+  my @ret;
+  $markers = $1 if $_[0] =~ m/.*\[(.*)\]$/;
+  $markers =~ s/\s*//g;
+  foreach my $mark (split /,/, $markers) {
+push @ret,
+  "[" . uc ($mark)
+. "]";
+  }
+  return '' if $#ret < 0;
+  return join (' ', @ret) . ' ';
+}
+
+sub print_site
+{
+  my ($site, $place) = @_;
+  $site = get_place_markers ($place) . $site if $site =~ /^https?:/;
+  $site = display_link ($site) if $site =~ /^(https?|ftp):/;
+  print $site;
+}
+
 while (<>) {
   # Take care of headers
@@ -52,11 +75,11 @@
   }
 
-  # Country and URLs are separated by ' - ' or ' -- '
+  # Country and URLs are separated by ' - ' or ' -- '.
   # Lines with ' -- ' should be skipped by Mirmon.
-  if (/^(.+)\s+\--?\s+(\S+.*)$/) {
+  if (/^(.*\S) --? (\S+.*)$/) {
 # State (US) or country (everything else)
 $marked_place = $1;
 @ftp_sites = split /,/,$2;
-($place = $marked_place) =~ s/[ *\[\]]*$//;
+($place = $marked_place) =~ s/ \[.*\]$//;
 if ((!$last_place) or ($place ne $last_place)) {
   if ($last_place) {
@@ -80,15 +103,5 @@
   }
   # Mark problematic sites.
-  if (($ftpsite =~ /^https?:/) and ($marked_place =~ /\*$/)) {
-$ftpsite =~ s,^,[JS] ,;
-if  ($marked_place =~ / \*\*$/) {
-  $ftpsite =~ s,^,[CN] ,;
-}
-  }
-  if ($ftpsite =~ /^(https?|ftp):/) {
-print _link($ftpsite);
-  } else {
-print $ftpsite;
-  }
+  print_site ($ftpsite, $marked_place);
   print "\n";
 }
Index: wrappers-and-scripts/ftp-header.html
===
RCS file: 
/web/www/www/server/staging/prep/wrappers-and-scripts/ftp-header.html,v
retrieving revision 1.2
diff -U 2 -r1.2 ftp-header.html
--- wrappers-and-scripts/ftp-header.html5 Feb 2024 18:12:55 -   
1.2
+++ wrappers-and-scripts/ftp-header.html6 Feb 2024 08:35:54 -
@@ -15,6 +15,6 @@
 .summary { margin-top: 1.7em; }
 #content h3 { margin-top: 1.5em; border-bottom: 2px solid #bbb; }
-.warn1 { color: #ce5c00; }
-.warn2 { color: red; }
+.warn-js { color: #ce5c00; }
+.warn-cn { color: red; }
 -->
 
Index: FTP
===
RCS file: /web/www/www/server/staging/prep/FTP,v
retrieving revision 1.2
diff -U 2 -r1.2 FTP
--- FTP 5 Feb 2024 18:12:54 -   1.2
+++ FTP 6 Feb 2024 08:35:54 -
@@ -8,6 +8,6 @@
 Canada - https://mirror.its.dal.ca/gnu, http://mirror.its.dal.ca/gnu, 
rsync://mirror.its.dal.ca/gnu
 Canada - https://mirror2.evolution-host.com/gnu, 
http://mirror2.evolution-host.com/gnu, rsync://mirror2.evolution-host.com/gnu
-Canada ** - https://ca.mirrors.cicku.me/gnu/, http://ca.mirrors.cicku.me/gnu/ 
(also, mirror alpha: https://ca.mirrors.cicku.me/gnu-alpha/, 
http://ca.mirrors.cicku.me/gnu-alpha/)
-US-Arizona * - https://mirrors.sarata.com/gnu/, 
rsync://mirrors.sarata.com/gnu/ (also, mirror alpha: 
https://mirrors.sarata.com/gnu-alpha/, rsync://mirrors.sarata.com/gnu-alpha/)
+Canada [cn, js] - https://ca.mirrors.cicku.me/gnu/, 
http://ca.mirrors.cicku.me/gnu/ (also, mirror alpha: 
https://ca.mirrors.cicku.me/gnu-alpha/, http://ca.mirrors.cicku.me/gnu-alpha/)
+US-Arizona [js] - https://mirrors.sarata.com/gnu/, 
rsync://mirrors.sarata.com/gnu/ (also, mirror alpha: 
https://mirrors.sarata.com/gnu-alpha/, rsync://mirrors.sarata.com/gnu-alpha/)
 US-California - https://mirror.fcix.net/gnu/, http://mirror.fcix.net/gnu/
 US-California - 

[sr #111017] /svn/?group=apl causes 404 (not found)

[Ineiev]

Update of sr#111017 (group administration):

 Assigned to:None => ineiev 
Operating System:   GNU/Linux => None   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thank you, fixed.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111017>

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

Re: [Savannah-hackers-public] Don't multiplex mirror URLs that use nonfree JavaScript ?

[Ineiev]

On Mon, Feb 05, 2024 at 10:52:01AM +0100, Thérèse Godefroy wrote:
> > * marking mirrors rather than URLs,
> 
> Some JS mirrors have ftp/rsync URLs that are safe.

Yes; but coincidentally, these URLs aren't used in redirections,
so in effect, the script is to either accept or reject all URLs
with applicable protocols in the mirror.

> > * using uniform markers so that (0) any number of them could be
> >attached to a mirror, and (1) /prep/FTP-to-mirmon list converter
> >could distinguish the lines where markers are present,
> 
> OK, but I think that's overkill. We have yet to see a centralized
> surveillance mirror that doesn't use JS.

The scripts won't need changing when we see such a mirror, or when
we find other reasons to avoid mirrors in redirections.

> > * adding footnotes explaining what each marker is for.
> 
> So you want footnotes? Not sure they are necessary, but it can be done.
> I will rewrite the paragraph about JS and add anchors.

People will visit /prep/ftp.html; we should explain why one mirror
differs from the others, shouldn't we?


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] Don't multiplex mirror URLs that use nonfree JavaScript ?

[Ineiev]

On Sun, Feb 04, 2024 at 07:31:47PM +0100, Thérèse Godefroy wrote:
> > I wonder if we could implement a more flexible approach
> > to mark mirrors, something along these lines,
> > 
> > NR - https://wicked-js.biz/gnu [*]
> > SM - http://walled.mil/mirrors [**]
> > TD - https://gnu-mirror.td [*] [**]
> > 
> > [*] The mirror uses unethical JavaScript.
> > [**] The mirror is part of a centralized surveillance network.
> > 
> 
> So basically you want 2 markers instead of one, after the URL rather than
> before?

Basically, I mean

* marking mirrors rather than URLs,
* using uniform markers so that (0) any number of them could be
  attached to a mirror, and (1) /prep/FTP-to-mirmon list converter
  could distinguish the lines where markers are present,
* adding footnotes explaining what each marker is for.


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] Don't multiplex mirror URLs that use nonfree JavaScript ?

[Ineiev]

Hello, Thérèse;

On Fri, Feb 02, 2024 at 04:44:58PM +0100, Thérèse Godefroy wrote:
...
> I made a test list [1] with underscores as markers:
>   '_' for URLs that use nonfree JavaScript
>   '__' for mirrors that use Cloudflare services.
...
> It probably wouldn't take much to adapt the Mirmon scripts so they
> select all URLs for the "allgnu" list, and unmarked URLs for the "gnu"
> list [4].

Probably no, it wouldn't.

> WDYT?

I wonder if we could implement a more flexible approach
to mark mirrors, something along these lines,

NR - https://wicked-js.biz/gnu [*]
SM - http://walled.mil/mirrors [**]
TD - https://gnu-mirror.td [*] [**]

[*] The mirror uses unethical JavaScript.
[**] The mirror is part of a centralized surveillance network.

> I have another question: how do these scripts select against alpha
> mirrors? Do they look for "alpha" in the URL? Are the parentheses
> necessary?

The script that extracts mirror list from /prep/FTP skips anything
written in parentheses, so alpha mirrors are ignored.


signature.asc
Description: PGP signature

[sr #111012] No git repositories found

[Ineiev]

Update of sr#111012 (group administration):

  Status: In Progress => Done   
Operating System:   Microsoft Windows => None   


___

Reply to this item at:

  

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

[sr #111013] Reassigned to another tracker [was: MQTT is not working with multiple topics]

[Ineiev]

Update of sr#111013 (group administration):

Category: Savannah trackers - bugs, tasks, etc. => None   
   


___

Reply to this item at:

  

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

Re: [Savannah-hackers-public] git down

[Ineiev]

On Tue, Jan 30, 2024 at 01:26:41PM +0800, Po Lu via Discussions among Savannah 
Hackers, open subscription wrote:
> I've started experiencing this error:
> 
> + git pull
> fatal: read error: Connection reset by peer

Savannah services git, svn, hg, bzr, download and audio-video.gnu.org are 
unavailable,
https://hostux.social/@fsfstatus.rss

Re: [Savannah-hackers-public] Strange behavior of "post a comment" on Savannah?

[Ineiev]

On Sat, Jan 27, 2024 at 05:49:58PM -0500, Paul Smith wrote:
> I wasn't talking so much about the canned responses although I agree
> that since I don't have any it's a bit annoying to use the screen real-
> estate to show an empty box, rather than allowing my reply to take up
> the entire screen.  Better would be to omit this section if there are
> no canned responses.

Thank you, done.

> But I was more referring to the messed up formatting at the bottom
> where the comment box overlaps with the horizontal lines and the title
> of the "Discussion" section appears to the right of the comment box
> instead of below it.

Fixed, sorry for the trouble.


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] New nongnu mirror mirrors.cicku.me/nongnu

[Ineiev]

On Mon, Jan 22, 2024 at 05:16:37PM +, Ineiev wrote:
> First, the contact is missing; second...

...and third, of course it should go to sv-hackers-private@.


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] New nongnu mirror mirrors.cicku.me/nongnu

[Ineiev]

On Tue, Jan 23, 2024 at 12:13:13AM +0900, Jing Luo via Discussions among 
Savannah Hackers, open subscription wrote:
> New nongnu mirror,..

First, the contact is missing; second and more important, I don't
see how Savannah is going to direct the users to it, in principle:
our server technically chooses the "nearest" mirror, whatever
that means. will it direct all our users to the new mirror?


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] Scope of backward compatibility

[Ineiev]

On Fri, Jan 19, 2024 at 11:57:09PM +0900, Jing Luo wrote:
> Please forget what I said. I apologize for my tone, which may have been a
> result of misinterpreting your tone.

Then I apologize for mine.

> Now it seems to make sense to support old versions of those, but if it was
> me, I would need more persuasion to do so.

Ok, let us see what you'll say when you are 22 years older.


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] Scope of backward compatibility

[Ineiev]

On Fri, Jan 19, 2024 at 07:27:51PM +0900, Jing Luo wrote:
> Let me clarify. My point was that it's not worth your effort to support old
> PHP versions that are already not supported by PHP's developers.

And I made a point that it is, and I've seen no counter-arguments.

> Do FSF admins "want" to upgrade the VMs or do they want to stay on old
> distros?

They do upgrade them (BTW at least part of that work is done
by Savannah volunteers rather than FSF staff).

> > These days, to continue to support old PHP versions is incomparably
> > easier than to support the new releases, so we'll gain little if we
> > stop supporting them.
> 
> By all means, drop support for PHP 8.2 :)

I'm sorry, I don't understand.

> > The most important "downstream" are private local instances
> > of testers. for example, occasionally I run Savane on a machine
> > that simply can't boot Trisquel 9.
> 
> That's unfortunate. Are you unable to acquire a no non-free firmware machine
> that works with newer versions of Trisquel?

The reasons don't matter. what matters is, quite a few more
man-hours were contributed to Savane because it could run
on top of older releases of its dependencies.

> My mistake. This [1] is probably something else.

That file does nothing substantial. the feature needs more.

After a closer look, I admit that Sergey's version may support
it to some degree, but I see no relevant controls in my Puszcza
package.


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] Multiple git repos for one group

[Ineiev]

On Fri, Jan 19, 2024 at 12:57:50PM +0900, Jing Luo via Discussions among 
Savannah Hackers, open subscription wrote:
> The frontend php code and site-specific code don't tell me much except it
> can display multiple git repos on "Use Git", and the backend sv_groups seems
> to be able to take $dir_git. So, did groups like "dragora" request the
> Savannah hackers to manually create multiple git repos? Did Savannah hackers
> manually created multiple git repos?

Creating repositories is a one-way process because our general
policy is to keep any code indefinitely. we could automatically
check if the repository is empty and allow the users to remove it,
but in most cases they'll have at least a few testing commits,
anyway. if the users can easily create repositories themselves,
Savannah sysadmins may face a high-volume flow of requests
to remove unneeded repositories.


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] Scope of backward compatibility

[Ineiev]

On Fri, Jan 19, 2024 at 01:26:38PM +0900, Jing Luo via Discussions among 
Savannah Hackers, open subscription wrote:
> Anyway...it's not "we may stop supporting MySQL", because MySQL is already
> unsupported as the status quo is. MariaDB is so great. I love it.

You may mean MySQL support by its developers; I was speaking about
MySQL support in Savane. we consider fixing incompatibilities
with MySQL, therefore we support it.

> Speaking of compatibility, it's not clear what Savane's policy is: I also
> mentioned it in the email I sent to savannah-hackers-private.

The supported versions of dependencies are listed in README; when
unspecified, it usually means that we've never encountered versions
that wouldn't work for us.

> PHP 5.4 was first released in 2012, and even PHP 7.4 was decleared
> EOL in 2022.

Probably you mean support by PHP developers, and that isn't
a very good criterion. Trisquel 10 is still supported, it comes
with PHP 7.4, and Savannah frontend is running Trisquel 10
currently (I shan't mention the distro releases that other
machines like fencepost or internal run).

> Is there a reason that Savane has to maintain its backward
> compatibility with ancient software?

These days, to continue to support old PHP versions is incomparably
easier than to support the new releases, so we'll gain little if we
stop supporting them.

> If Savane's maintainers don't mind maintaining ancient software, that's fine
> too; if we want to clearly define a scope, this would be an example:
> "everything included in Trisquel 9 or Debian 10". Another thing to consider
> is Savane's downstream, and currently the only publicly known downstream (?)
> is Puszcza's fork, which uses the 3.1 cleaned up version.

The most important "downstream" are private local instances
of testers. for example, occasionally I run Savane on a machine
that simply can't boot Trisquel 9.

> Btw, Puszcza introduced git homepage support a few years ago.

You must be confusing it with some other feature.


signature.asc
Description: PGP signature

[sr #111009] tasks: failed to save "should be finished on..."

[Ineiev]

Update of sr#111009 (group administration):

  Status:None => Done   
 Assigned to:None => ineiev 
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thank you, fixed.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111009>

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

Re: [Savannah-hackers-public] Final-stage work/changes on adding the Git homepage source code web browsing option.

[Ineiev]

While at home pages: as part of the current process, will FSF
sysadmins find time to remove pages of non-existing Savannah
groups?


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] Final-stage work/changes on adding the Git homepage source code web browsing option.

[Ineiev]

On Wed, Jan 17, 2024 at 07:26:35PM +, Ineiev wrote:
> > Do you suggest alternatives?
> 
> Yes.  I'll send the details a few hours later.

Attached.

In short, homepage VCS selection is stored in group preferences,
url_cvs_viewcvs_homepage is decommissioned, the value
is derived from type_data_array["{$vcs}_viewvcs"].
diff --git a/frontend/php/include/group.php b/frontend/php/include/group.php
index 4afea29b..a546edea 100644
--- a/frontend/php/include/group.php
+++ b/frontend/php/include/group.php
@@ -450,20 +450,38 @@ class Group extends savane_error
 return $this->CanUse ($artifact);
   }
 
+  function getHomepageVCS ()
+  {
+$pref = group_get_preference ($this->group_id, 'homepage_vcs');
+if ($pref !== false)
+  return $pref;
+return 'cvs'; # Historical default.
+  }
+
+  function setHomepageVCS ($vcs)
+  {
+group_set_preference ($this->group_id, 'homepage_vcs', $vcs);
+  }
+
+  function getHomeBrowseURL ()
+  {
+$url = $this->getTypeUrl ($this->getHomepageVCS () . "_viewcvs");
+return preg_replace (',^(http(s?):)?//,', '$0web.', $url);
+  }
+
+  # Determine if the group uses a specific artifact to manage its home page:
+  # - the group must use home page;
+  # - the group must be select the VCS for its home page;
+  # - the home page URL must be empty or default.
   function UsesForHomepage ($artifact)
   {
-# Useful to determine whether the project is a specific artifact
-# to manage its homepage:
-#   - must use homepage
-#   - must be set as homepage SCM for the group type
-#   - the projet url must be empty or equal to the group setting
+if (!$this->Uses ("homepage"))
+  return false;
+if ($this->getHomepageVCS () != $artifact)
+  return false;
 return
-  $this->Uses ("homepage")
-  && $this->type_data_array['homepage_scm'] == $artifact
-  && (
-   $this->data_array['url_homepage'] == $this->getTypeUrl ('homepage')
-   || $this->data_array['url_homepage'] == ""
- );
+  $this->data_array['url_homepage'] == $this->getTypeUrl ('homepage')
+  || $this->data_array['url_homepage'] == "";
   }
 
   # Related to mail notification.
@@ -742,7 +760,7 @@ function group_get_artifact_url ($artifact, $hostname = 1)
 {
   global $project, $sys_home;
   $type_urls = [
-"homepage", "download", "cvs_viewcvs", "cvs_viewcvs_homepage",
+"homepage", "download", "cvs_viewcvs",
 "arch_viewcvs", "svn_viewcvs", "git_viewcvs", "hg_viewcvs", "bzr_viewcvs"
   ];
   if (in_array ($artifact, $type_urls))
diff --git a/frontend/php/include/pagemenu.php b/frontend/php/include/pagemenu.php
index 9af82f33..b06c0d9d 100644
--- a/frontend/php/include/pagemenu.php
+++ b/frontend/php/include/pagemenu.php
@@ -344,15 +344,9 @@ function pagemenu_vcs_browse_entry ($group, $vcs, $name)
 
 function pagemenu_vcs_web_browse_url ($group, $vcs)
 {
-  if (!pagemenu_url_is_set ($group, "cvs_viewcvs_homepage"))
-return '';
-  if ($vcs == 'cvs')
-$have_entry = $group->Uses ('homepage');
-  else
-$have_entry = $group->UsesForHomepage ($vcs);
-  if (!$have_entry)
-return '';
-  return $group->getUrl ("cvs_viewcvs_homepage");
+  if ($group->UsesForHomepage ($vcs))
+return $group->getHomeBrowseURL ();
+  return '';
 }
 
 function pagemenu_vcs_web_browse_entry ($group, $vcs, $name)
diff --git a/frontend/php/include/vcs.php b/frontend/php/include/vcs.php
index e8947ba9..701e1cc3 100644
--- a/frontend/php/include/vcs.php
+++ b/frontend/php/include/vcs.php
@@ -131,24 +131,40 @@ function vcs_sort_repos ($vcs, $group_id, $repos)
   return $ret;
 }
 
+# Guess base VCS directory from the configuration.
+function vcs_get_dir ($vcs)
+{
+  global $sys_vcs_dir;
+  if (empty ($sys_vcs_dir) || !is_array ($sys_vcs_dir))
+return null;
+  if (empty ($sys_vcs_dir[$vcs]['dir']) || !is_dir ($sys_vcs_dir[$vcs]['dir']))
+return null;
+  return $sys_vcs_dir[$vcs]['dir'];
+}
+
+# Guess base VCS clone path from the configuration.
+function vcs_get_clone_path ($vcs, $fallback = null)
+{
+  global $sys_vcs_dir;
+  if ($fallback === null)
+$fallback = vcs_get_dir ($vcs);
+  if (empty ($sys_vcs_dir[$vcs]['clone-path']))
+return $fallback;
+  return $sys_vcs_dir[$vcs]['clone-path'];
+}
+
 # Get array of repository descriptions.
 function vcs_get_repos ($vcs, $group_id)
 {
-  global $sys_vcs_dir;
   $func = "{$vcs}_list_repos";
   if (!function_exists ($func))
 return [];
+  $vcs_dir = vcs_get_dir ($vcs);
+  if ($vcs_dir === null)
+return [];
   $group = project_get_object ($group_id);
   $group_name = $group->getUnixName ();
-  if (empty ($sys_vcs_dir) || !is_array ($sys_vcs_dir))
-return [];
-  if (empty ($sy

Re: [Savannah-hackers-public] Final-stage work/changes on adding the Git homepage source code web browsing option.

[Ineiev]

On Tue, Jan 16, 2024 at 09:55:37PM -0500, Ian Kelling wrote:
> > Still it will be single repository at the same time, and in fact,
> > non-default values are (and will be) effectively never used.
> 
> What do you mean by "single repository at the same time"?

I mean that Savannah isn't supposed to simultaneously display
multiple home pages, each originating from the respective VCS.
The home page at any specific moment will reflect a single choice.

Of course, Savannah is expected to support working with all
repositories that have ever been created, even when disabled,
like it does now, and has always done.

> > There is no need for this new field, and for any other new fields,
> > on the other hand, the harm would be more than palpable.
> 
> Well, I can think of ways to reuse existing fields in new ways, or
> compute information without using a field, but this seems to follow the
> existing pattern in the code base: clearly fields were added when git
> support was added for non-web repositories.

That wasn't a very good decision. generally, the existing
patterns in the code base are often far from perfect.

> What is the harm you see?

The new code wouldn't work with old databases; all existing
instances and dumps would need manual error-prone updating.
the SQL queries would fetch excessive data that isn't needed
in most cases. the column list grows boundless.

> Do you suggest alternatives?

Yes.  I'll send the details a few hours later.


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] Final-stage work/changes on adding the Git homepage source code web browsing option.

[Ineiev]

On Tue, Jan 16, 2024 at 02:41:39PM -0500, Ian Kelling wrote:
> 
> Ayushman's been chatting with me, Michael, Bob, Corwin and Bandali
> in #fsfsys, and also at the FSF weekly volunteer meetings in mumble, 11
> am wednesdays US eastern time (utc -5 right now). Feel free to join us,

Thank you; still the official Savannah communication channel
is this mailing list. I'd prefer using it. 


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] Final-stage work/changes on adding the Git homepage source code web browsing option.

[Ineiev]

On Tue, Jan 16, 2024 at 02:46:49PM -0500, Ian Kelling wrote:
> Ineiev  writes:
>
> > The group will use no more than one VCS for its homepage; a new
> > field 'url_git_viewcvs_homepage' will only add unneeded complexity.
>
> Ayushman didn't explain some of the ideas behind this. I believe we
> actually want projects to be able to have CVS and Git homepage
> repositories simultaneously on the savannah side, and then be able to
> choose and switch back and forth between which one is the source of the
> actually published homepage.

Still it will be single repository at the same time, and in fact,
non-default values are (and will be) effectively never used.

There is no need for this new field, and for any other new fields,
on the other hand, the harm would be more than palpable.

It's much easier to workaround such things at the design stage
than fixing them after they are built in the package.


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] Final-stage work/changes on adding the Git homepage source code web browsing option.

[Ineiev]

Hello, Ayushman; could you not top-post?

On Mon, Jan 15, 2024 at 08:23:56PM +0530, Ayushman Tripathi wrote:
> I used this quote `groups` because in the latest MySQL version, groups is a
> reserved keyword. So, when I was trying to set up a development environment,
> I got so many errors related to this.

This is a separate issue, and it isn't clear how to deal with it;
ultimately, we may stop supporting MySQL. IIRC Bob said its free
version wasn't properly supported, and its manual is proprietary.

Meanwhile, you can use MariaDB.

> I'll try to make these changes very shortly.

Thank you!

> And yes, I'm working with the Savannah volunteers to implement its backend,

I wonder who those volunteers are.

> which is to update the sv_groups.in 
> 
> and Git.pm.in, 
> and

I agree that these steps are needed, but setting up the repositories
on VCS servers won't make www.{non,}gnu.org serve those pages,
and it won't make Git work flawlessly; those are things that are
the most important to do---they can't be done by volunteers,
unlike all the rest.

> I set an independent database field, `homepage_vcs`, which stores the value
> of the vcs used, which can be git, cvs, etc. With this approach, if in the
> future we want to add other VCS support, it will be much easier and more
> clear.

This is exactly what I highly recommend against.  Adding a dependence
on a new column is a very intrusive step, and we definitely don't
want to break compatibility with any new feature like this.


signature.asc
Description: PGP signature

[sr #111008] libtool-commit not receiving commit mail

[Ineiev]

Update of sr#111008 (group administration):

  Status:  Ready For Test => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

New commits are in the archives of libtool-commit.


___

Reply to this item at:

  

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

[sr #110999] Remove no longer used additional libidn/libidn2.git repository

[Ineiev]

Update of sr#110999 (group administration):

 Open/Closed:  Closed => Open   

___

Follow-up Comment #4:

It doesn't seem to me that it may confuse the users if you provide a right
description.


___

Reply to this item at:

  

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

Re: [Savannah-hackers-public] Final-stage work/changes on adding the Git homepage source code web browsing option.

[Ineiev]

Hello, Ayushman;

On Fri, Jan 12, 2024 at 01:55:15AM +0530, Ayushman Tripathi wrote:
> Hello! I'm reaching the final stage of the process of implementing the
> option for the Git webpage repository.
> This patch basically covers the PHP changes.

What about the other end, linking the checkout of the repository
to website and updating it on the web server?

> -function form_radio ($name, $value, $attr)
> +function form_radio ($name, $value, $attr = [])

The default value is never used in your patch, and in fact,
form_radio makes little sense without at least a label, which has
no reasonable default.

> -  db_execute ("SELECT * FROM groups WHERE group_id = ?", [$id]);
> +  db_execute ("SELECT * FROM `groups` WHERE group_id = ?", [$id]);

Current Savane code doesn't use this kind of quoting; irrespectively
of whether they may improve the program, it seems to me it's
pointless to introduce this kind of inconsistency in an unrelated
modification.

> +  function isArtifactUrlSet ($artifact)
> +  {
> +# Returns true if the artifact url is set for this group.
> +return $this->data_array["url_$artifact"] != "";
> +  }

This function is never used, and I don't think it would be really
helpful.

> +  function getHomepageVcs ()
> +  {
> +return $this->data_array['homepage_vcs'];
> +  }

The code implies a new field in the groups table, and in many
cases of access to data of the group it will not be used.
That alone is a good reason against it, and the compatibility
issues are even more important.

It's OK to keep this value in $this->data_array, but the code to
extract and update it should be different.

> @@ -743,7 +754,7 @@ function group_get_artifact_url ($artifact, $hostname = 1)
>global $project, $sys_home;
>$type_urls = [
>  "homepage", "download", "cvs_viewcvs", "cvs_viewcvs_homepage",
> -"arch_viewcvs", "svn_viewcvs", "git_viewcvs", "hg_viewcvs", "bzr_viewcvs"
> +"arch_viewcvs", "svn_viewcvs", "git_viewcvs", "git_viewcvs_homepage", 
> "hg_viewcvs", "bzr_viewcvs"

Savane follows GNU recommendations for style.  Please keep
the length of source lines to 79 characters or less,
https://www.gnu.org/prep/standards/html_node/Formatting.html

Also, these VCS URLs are in fact the same for all group types; we'd
better decommission these useless fields that make group types
unmanageable rather than add yet one more.

> -  if (!pagemenu_url_is_set ($group, "cvs_viewcvs_homepage"))
> +  if (!pagemenu_url_is_set ($group, "cvs_viewcvs_homepage") && 
> !pagemenu_url_is_set ($group, "git_viewcvs_homepage"))

The group will use no more than one VCS for its homepage; a new
field 'url_git_viewcvs_homepage' will only add unneeded complexity.


signature.asc
Description: PGP signature

[sr #111008] libtool-commit not receiving commit mail

[Ineiev]

Update of sr#111008 (group administration):

  Status:None => Ready For Test 
 Assigned to:None => ineiev 

___

Follow-up Comment #1:

Done; Mail-Followup-To is set to libt...@gnu.org.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111008>

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

[sr #110977] can't upload to download area by scp or sftp

[Ineiev]

Follow-up Comment #5, sr#110977 (group administration):


> please update the maintainer documentation to state that scp's `-O` option
is required starting with OpenSSH 9.0.

Done, thank you.


___

Reply to this item at:

  

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

[sr #110299] minor typo submits unfinished bug report

[Ineiev]

Update of sr#110299 (group administration):

  Status:None => Works For Me   
 Assigned to:None => ineiev 
 Open/Closed:Open => Closed 

___

Follow-up Comment #10:

Improved in
[//git.savannah.nongnu.org/cgit/administration/savane.git/commit/?id=fae313a67816f2fc8e517113c42a35e48431afe9
fae313a].


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?110299>

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

[sr #110999] Remove no longer used additional libidn/libidn2.git repository

[Ineiev]

Update of sr#110999 (group administration):

  Status: In Progress => Works For Me   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[sr #111005] [i18n] "browse tracker" does not return a table of items

[Ineiev]

Update of sr#111005 (group administration):

  Status:   Need Info => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #5:

Now the code does include a hint that special groups shouldn't be deleted.

Thank you!


___

Reply to this item at:

  

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

[Savannah-hackers-public] [task #12911] Cleaning up Contributors Wanted

[Ineiev]

Update of task#12911 (group administration):

  Status: In Progress => Done   
 Assigned to: caveryb => None   
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

Closing stale job.


___

Reply to this item at:

  

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

[Savannah-hackers-public] [task #15140] Automatically updating GPG keys when expired

[Ineiev]

Follow-up Comment #9, task#15140 (group administration):

[comment #8 comment #8:]
> It seems to be dormant - is it dead, or just resting? 

It's waiting for its turn.

> I'm not sure how it can be addressed without access to the servers in
question

The first step is to find out what we should do in the first place.

If you wish, I can share a list of users with GPG keys (about 3000 accounts),
then you would be able to download the keys and see what they look like.


___

Reply to this item at:

  

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

[sr #111005] [i18n] "browse tracker" does not return a table of items

[Ineiev]

Follow-up Comment #3, sr#111005 (group administration):

Then I don't understand why sv_cleaner deletes that group (it didn't for me so
far).


___

Reply to this item at:

  

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

[sr #111005] [i18n] "browse tracker" does not return a table of items

[Ineiev]

Update of sr#111005 (group administration):

  Status:None => Need Info  
 Assigned to:None => ineiev 

___

Follow-up Comment #1:

I can't reproduce this from 17fec9f21a8; more info is needed.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111005>

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

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

[Ineiev]

On Sat, Jan 06, 2024 at 04:35:07PM -0700, Bob Proulx wrote:
> 
> I have set permissions aback to the above.  But now there is the
> question of how this previously worked.

I have a hypothesis.  I may have changed the permissions when
I modified sv_groups to create repositories of private groups
with less permissive access in November. gnueval was the only
private group using Subversion, so no other repositories were
affected.


signature.asc
Description: PGP signature

Re: [Savannah-hackers-public] Initial changes for adding the Git homepage source code web browsing option.

[Ineiev]

Hello;

On Wed, Jan 03, 2024 at 05:26:13PM -0700, Bob Proulx wrote:
> > +if ($project->CanUse("homepage") && $project->CanUse("git")) {
>
> That's an insufficient combination.  Many current projects already use
> git for their source code and many of them won't want to change their
> web page version control at this time.  But having this control logic
> would force them to make a web page version control change.

Indeed, the introduced controls aren't very well thought out.

> There are only three magic numbers.  Zero, One, and Many.  If we are
> moving past One then we should set up for the Many case.  I think we
> should set up an enumeration of possible version control systems to
> include the current CVS and the new incoming GIT.  Let's not include
> any more unless more are needed but it allows expansion to more in
> the future.  It would allow an SVN project to be set up for SVN for
> web pages as well.  And the same for HG.  And so on.  But let's focus
> on just the two CVS and GIT for the moment in order to keep things
> manageable initially.
>
> This will require altering the schema of the database to include the
> new data fields.  And of course new code to interact with those
> fields.  I think you will need to ask for help in doing those parts of
> the task.  That's going to be expected.

I don't think any change in database tables is needed or desirable;
the feature may be implemented without that.

Ayushman made a good point when mentioned that this task includes
frontend and backend parts. as I understand it, the backend parts
include

* the programs and their configurations that update the pages
  from the repositories to www.{,non}gnu.org, and
* the VCS servers and their setup.

Savannah volunteers traditionally have little access to that setup
and almost zero knowledge of it, therefore it has to be done by FSF
people, and I believe an important aspect here is making the VCS
servers work flawlessly: even before the task is complete, the users
will benefit from the stable operation; so it would be nice
to address the issues raised in
https://savannah.nongnu.org/support/?110712

On the other hand, Savannah volunteers have decades of expertise
in the frontend part, and spending FSF people's scarce labor on that
work would be next to counter-productive.

> Let me applaud you for getting the standalone setup up and running!
> That's really good!  That's better than a lot of people have been able
> to do recently.  Good job!

+1

> Since you have recently done this I think the best thing to do next is
> to get the documentation updated which covers this part of the task.

As far as I can tell, it isn't outdated, though.

By the way, relatively recent changes in the development branch
considerably simplify the process, to the degree that I'd like
to migrate the installation on frontend2 to the new workflow
before we switch to it (I hope to do that after the fundraiser
ends).


signature.asc
Description: PGP signature

[sr #111001] unsafe permission in www-zh-cn CVS source repo

[Ineiev]

Follow-up Comment #5, sr#111001 (group administration):

TTBOMK, the executable attribute in the repository is set during the first
commit and then persists.

In my working copy, I can chmod -x file, and the file will be non-executable
until I rm file; cvs up file---and then the executable bit is fetched from the
repository again.

Likewise, that bit is set when checking out a fresh working copy.

Removing and re-adding file doesn't help, like mv file{,~}; cvs rm file; cvs
ci -m'removing' file; mv file{~,}; chmod -x file; cvs add file; cvs ci
-m're-adding' file

So it looks like in Savannah environment only Savannah admins can reset those
bits, like chmod -x file,v; but it makes little sense to do that if other such
files be added subsequently.


___

Reply to this item at:

  

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

[sr #110972] m...@lix.polytechnique.fr and m...@cnrs.fr not working

[Ineiev]

Update of sr#110972 (group administration):

  Status:   Need Info => Done   
 Assigned to:None => ineiev 
 Open/Closed:Open => Closed 

___

Follow-up Comment #6:

Fixed, see sr #110998.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?110972>

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

[sr #110998] no email got sent regarding Savannah #65092 (°)

[Ineiev]

Update of sr#110998 (group administration):

Category:None => Savannah trackers - bugs,
tasks, etc.
  Status: In Progress => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #4:

Instead of modifying frontend1 mailing system configuration, I made Savane
encode non-ASCII subjects.


___

Reply to this item at:

  

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

[sr #110998] no email got sent regarding Savannah #65092 (°)

[Ineiev]

Update of sr#110998 (group administration):

 Summary: no email got sent regarding Savannah #65092 => no
email got sent regarding Savannah #65092 (°)

___

Follow-up Comment #3:

test with non-ASCII subject...


___

Reply to this item at:

  

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

[sr #110995] Private Git Repo

[Ineiev]

Update of sr#110995 (group administration):

  Status: In Progress => Ready For Test 
 Assigned to: rwp => ineiev 

___

Follow-up Comment #14:

In fact, the fix was pushed in Savane in 2023-11, it just wasn't installed on
vcs0. I've updated the scripts and re-enabled Git in the group; then the
repository was created with the right permissions.  Both the anonymous clones
and clones of non-members fail.

Jason, does member clone work for you?


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?110995>

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

[sr #110995] Private Git Repo

[Ineiev]

Update of sr#110995 (group administration):

  Status:Done => In Progress
 Open/Closed:  Closed => Open   

___

Follow-up Comment #13:

The feature does apply to the repositories; if it Git repository isn't
private, it just means that the Savane script had a bug (which isn't
surprising because the latest private groups predate Git), and it should be
fixed.


___

Reply to this item at:

  

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

Re: [savannah-help-public] Can't recover password

[Ineiev]

On Fri, Jan 05, 2024 at 12:02:31PM +0300, LRN wrote:
> 
> Well, i do have a problem. Can't log in again :)
> 
> Did you suspend my account (again)?

The Savannah account  was deleted before 2017-07,
most probably, by the user who controlled the account.


signature.asc
Description: PGP signature

[sr #110999] Remove no longer used additional libidn/libidn2.git repository

[Ineiev]

Update of sr#110999 (group administration):

  Status:None => In Progress
 Assigned to:None => ineiev 

___

Follow-up Comment #1:

We generally keep repositories even if they are unused.  You can update its
label to say it's obsolete at https://savannah.gnu.org/git/admin/?group=libidn
and add a README file that will be displayed by Cgit.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?110999>

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

[sr #111000] fatal error when updating Savannah ticket

[Ineiev]

Update of sr#111000 (group administration):

  Status:Works For Me => Done   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[sr #111001] unsafe permission in www-zh-cn CVS source repo

[Ineiev]

Update of sr#111001 (group administration):

  Status:None => Need Info  
 Assigned to:None => ineiev 
Operating System:   GNU/Linux => None   

___

Follow-up Comment #2:

We could clear that bit in the attributes, but
1. technically, such changes should come from the admins of the respective
groups, and
2. that wouldn't fix the issue if people proceed with adding files with such
attributes.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111001>

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

[sr #111000] fatal error when updating Savannah ticket

[Ineiev]

Update of sr#111000 (group administration):

  Status:None => Works For Me   
 Assigned to:None => ineiev 

___

Follow-up Comment #4:

Sorry for the trouble, fixed.


___

Reply to this item at:

  <https://savannah.nongnu.org/support/?111000>

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

[sr #110988] (wishlist) more php warnings

[Ineiev]

Update of sr#110988 (group administration):

  Status: In Progress => Done   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[sr #110997] Mislabeled button: "Revert comment order"

[Ineiev]

Update of sr#110997 (group administration):

  Status:   Need Info => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

Thank you, fixed.


___

Reply to this item at:

  

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