mainSavannah Administration - Support: sr #111226, Please change jcal repository and...

 
 

sr #111226: Please change jcal repository and website owner

Submitter:  None
Submitted:  Sun 13 Apr 2025 01:31:36 PM UTC
   
 
Category:  Source code repositories - developer access Priority:  7 - High
Severity:  3 - Normal Status:  In Progress
Privacy:  Public Assigned to:  ineiev
Originator Email:  -email is unavailable- Operating System:  None
Open/Closed:  Open
* Mandatory Fields

Post a Comment

Add a New Comment Rich Markup
   

Discussion

Jump to the original submission

Tue 04 Nov 2025 03:19:00 PM UTC, comment #36: 

On Sun, Nov 02, 2025 at 06:49:43AM -0500, Hossein wrote:

> > Just to be on the same page: when speaking about
> 'files in the project', we discuss what the tarball contains---and in our
> case, it's a working copy of the 'main' branch of your Git repository.  Do I
> mean the same as you?  If yes, then a closer look is needed into how you make
> that list.  I find more.
>
> Yes we're on the same page. I'm afraid I don't find any other files, or my
> grep command is mistaken `grep -RL GNU` shows exactly that list.


I see; this is where we diverge: you grepped for the word whereas
I looked for copyright and license notices.

> > This is too terse to see if the person who wrote this understands the
> > requirements.
>
> The files in the "./sources/man" folder are exactly one line therefore
> trivial. The guideline accepts this exception for very short files.
> NEWS, AUTHORS and TODO are metadata


I would classify them as 'documentation' or at least 'supporting
files' in terms of
www.gnu.org/prep/ ... ight-Notices.html

As far as I understand it, metadata are access permissions,
timestamps, sizes and so on.

> (the first and last one could be generated by git for example)


How can the current texts of those files be generated by git?

> that are generally facts and not subject to copyright.


The facts are not subject to copyright.  The selections of facts and their
expressions may be.

> > I don't think you've addressed one of my previous comments... their texts are
> > not consistent
>
> It appears that I didn't send my reply to this one on my second attempt, when
> my initial text was not sent for some reason.


Sorry.

> Both texts show LGPLv3+, I didn't catch how they are in conflict with each
> other or could be misinterpreted/the reason for recommendation for a change.


First, the sets of copyright years differ; second, the wording
of the license notice is important.  The current recommendation
was carefully designed by lawyers who used the experience of free
software community to avoid possible misunderstanding and other
issues.  We may use terms like 'LGPLv3+' when we speak to each other
informally because the context makes the meaning quite certain,
however, one can't assume any user who gets the tarball will
understand it as well as we do in this conversation.

And generally, it isn't a good idea to do the same thing twice.

Ineiev <ineiev>
Site Administrator
Sun 02 Nov 2025 11:49:39 AM UTC, comment #35: 


>  Savannah has certain hosting requirements.  We have no resources to continually check that every hosted package follows them, so we have to rely on package maintainers to comply with them.  This means that we should make sure that the prospective admins understand our hosting requirements and know how to follow them.


I'll keep that in mind.

>  Just to be on the same page: when speaking about

'files in the project', we discuss what the tarball contains---and in our case, it's a working copy of the 'main' branch of your Git repository.  Do I mean the same as you?  If yes, then a closer look is needed into how you make that list.  I find more.

Yes we're on the same page. I'm afraid I don't find any other files, or my grep command is mistaken `grep -RL GNU` shows exactly that list. Let me know which files I have missed.

> This is too terse to see if the person who wrote this understands the requirements.


The files in the "./sources/man" folder are exactly one line therefore trivial. The guideline accepts this exception for very short files.
NEWS, AUTHORS and TODO are metadata (the first and last one could be generated by git for example) that are generally facts and not subject to copyright.


>  I'd also like to suggest to stick to common terminology:

there are valid copyright notices and valid license notices.  Those are distinct well-defined things, and the term to cover both categories is 'legal notices'.  If we use other wording, we
may miscommunicate.

Good point. I didn't know about this.

>  I don't think you've addressed one of my previous comments... their texts are not consistent


It appears that I didn't send my reply to this one on my second attempt, when my initial text was not sent for some reason.

Both texts show LGPLv3+, I didn't catch how they are in conflict with each other or could be misinterpreted/the reason for recommendation for a change.

Hossein <hossein>
Thu 30 Oct 2025 05:55:41 AM UTC, comment #34: 

On Mon, Oct 27, 2025 at 03:44:14PM -0400, Hossein wrote:

>
> I made another commit that removes pyjalali docs that I didn't know how to
> license and the reason for your question.


Savannah has certain hosting requirements.  We have no resources
to continually check that every hosted package follows them, so we
have to rely on package maintainers to comply with them.  This means
that we should make sure that the prospective admins understand
our hosting requirements and know how to follow them.

Is anyting still unclear to you?

> Currently the only files in the project that don't have the word "Copyright"
> or "GNU" are these:
>
> ./README.md

...

> ./.gitignore


Just to be on the same page: when speaking about
'files in the project', we discuss what the tarball contains---and
in our case, it's a working copy of the 'main' branch of your Git
repository.  Do I mean the same as you?  If yes, then a closer
look is needed into how you make that list.  I find more.

> I see no reason to add a copyright header to any of them.


This is too terse to see if the person who wrote this understands
the requirements.  What would do is if you, for example, listed all
the reasons you've considered, and why they don't apply to each
file.

I'd also like to suggest to stick to common terminology:
there are valid copyright notices and valid license notices.  Those
are distinct well-defined things, and the term to cover both
categories is 'legal notices'.  If we use other wording, we
may miscommunicate.

> Let me know if there is any other thing that needs to be done.


I don't think you've addressed one of my previous comments,

> By the way, files like sources/man/jstrptime.3 include copyright
> and license notices twice, in comments at the top and at the
> bottom, and their texts are not consistent.  I would recommend
> only leaving the user-visible one and updating it to the form
> recommended in GNU guidelines (another minor note is, GNU
> currently uses a HTTPS URL rather than HTTP in the license
> notices).


Ineiev <ineiev>
Site Administrator
Mon 27 Oct 2025 07:44:09 PM UTC, comment #33: 

I made another commit that removes pyjalali docs that I didn't know how to license and the reason for your question.

Currently the only files in the project that don't have the word "Copyright" or "GNU" are these:

./README.md
./sources/man/jalali_create_date_from_days.3
./sources/man/jalali_create_days_from_date.3
./sources/man/jalali_create_secs_from_time.3
./sources/man/jalali_create_time_from_secs.3
./sources/man/jalali_get_date.3
./sources/man/jalali_get_diff.3
./sources/man/jalali_get_jyear_info.3
./sources/man/jalali_is_jleap.3
./sources/man/jalali_update.3
./sources/man/jasctime.3
./sources/man/jasctime_r.3
./sources/man/jctime_r.3
./sources/man/jgmtime.3
./sources/man/jgmtime_r.3
./sources/man/jlocaltime.3
./sources/man/jlocaltime_r.3
./sources/man/jmktime.3
./sources/NEWS
./sources/AUTHORS
./sources/TODO
./.gitignore

I see no reason to add a copyright header to any of them.

Let me know if there is any other thing that needs to be done.

Hossein <hossein>
Mon 27 Oct 2025 05:48:50 PM UTC, comment #32: 

You see, the task at hand is to make sure that all non-trivial files have valid copyright and license notices.  Can you do that?

Ineiev <ineiev>
Site Administrator
Mon 27 Oct 2025 01:17:48 PM UTC, comment #31: 


> sources/configure.ac

Nice catch.


In the two latest commits (https://codeberg. ... mmits/branch/main) I:
1. Updated the HTML files made from man pages to reflect the new changes.
2. Added a copyright header to the build tools as well.
3. Verified that the code still compiles just fine.

Hossein <hossein>
Thu 23 Oct 2025 05:24:01 AM UTC, comment #30: 

On Tue, Oct 21, 2025 at 02:20:04PM -0400, Hossein wrote:

> https://codeberg. ... 6f97fe60ab14ec54a
>
> Thanks to your reply, in the commit above I:
> 1. Changed HTTP to HTTPS wherever I could (only place not affected is the docs
> made by man2html. I had problems with Perl which I will solve in the future)
> 2. During the process I realized there are links to Ashkan's email, and I
> replaced them with Savannah's bug tracker.


Thanks!

> > Can you explain why?
>
> Sure, I believe that the Makefile.am in test kits are trivial, for example if
> we remove the trivial lines of 8 to 15 from
> sources/test_kit/jalali/Makefile.am , and then the empty lines, we're left
> with 5 lines of code that are trivial to begin with.


This reasoning doesn't seem perfect to me.  Any usual line of code
is noncopyrightable, but they sum up to programs like Emacs.
Do I miss some point?

However, I agree that sources/test_kit/jalali/Makefile.am is not
very long and shouldn't relly be problematic (I'm not so sure
for sources/Makefile.am and even less for sources/setup.py).
On the other hand, it wouldn't hurt to add the notices to be
on the safe site while you are working on this issue in your
package.

> However important files such as autogen.sh already have a copyright header so
> we're fine there.


Sure thing.  What about files like sources/configure.ac?

Ineiev <ineiev>
Site Administrator
Tue 21 Oct 2025 06:20:00 PM UTC, comment #29: 

Wow, I could've sworn that I had sent a reply in here 3 days ago. Turns out my reply wasn't sent.
----------
https://codeberg. ... 6f97fe60ab14ec54a

Thanks to your reply, in the commit above I:
1. Changed HTTP to HTTPS wherever I could (only place not affected is the docs made by man2html. I had problems with Perl which I will solve in the future)
2. During the process I realized there are links to Ashkan's email, and I replaced them with Savannah's bug tracker.


>  Can you explain why?


Sure, I believe that the Makefile.am in test kits are trivial, for example if we remove the trivial lines of 8 to 15 from sources/test_kit/jalali/Makefile.am , and then the empty lines, we're left with 5 lines of code that are trivial to begin with.

However important files such as autogen.sh already have a copyright header so we're fine there.

Hossein <hossein>
Fri 17 Oct 2025 05:20:17 AM UTC, comment #28: 

comment #27:

> Just added the copyright notices for the project's testkit.


Thank you!

By the way, files like sources/man/jstrptime.3 include copyright and license notices twice, in comments at the top and at the bottom, and their texts are not consistent.  I would recommend only leaving the user-visible one and updating it to the form recommended in GNU guidelines (another minor note is, GNU currently uses a HTTPS URL rather than HTTP in the license notices).
 

> What remains is setup.py and some Makefiles, but I don't find it necessary to add copyright notices to those as well.


Can you explain why?

Ineiev <ineiev>
Site Administrator
Wed 15 Oct 2025 04:36:33 PM UTC, comment #27: 

Thanks for pointing that out. Just added the copyright notices for the project's testkit.

https://codeberg. ... 896cc178b285d025a

I also verified that all man pages have the appropriate notices.

What remains is setup.py and some Makefiles, but I don't find it necessary to add copyright notices to those as well.

Hossein <hossein>
Thu 09 Oct 2025 04:52:15 PM UTC, comment #26: 

On Tue, Oct 07, 2025 at 06:47:13AM -0400, Hossein wrote:

>
> As everything exists already in the code, I have removed the Sphinx generated
> docs (docs/pyjalali) for the time being, until I can deal with the python
> section of the project and do a revamp.
>
> https://codeberg. ... c388f3963f251e5d0


Thank you!

> Let me know if there's any other thing that I need to take care of.


The next issue is, all copyrightable files should have valid copyright and license notices.  Have you checked that?

Ineiev <ineiev>
Site Administrator
Tue 07 Oct 2025 10:47:08 AM UTC, comment #25: 

As everything exists already in the code, I have removed the Sphinx generated docs (docs/pyjalali) for the time being, until I can deal with the python section of the project and do a revamp.

https://codeberg. ... c388f3963f251e5d0

Let me know if there's any other thing that I need to take care of.

Hossein <hossein>
Mon 06 Oct 2025 06:02:14 AM UTC, comment #24: 

On Fri, Oct 03, 2025 at 03:26:48AM -0400, Hossein wrote:

> > Have you checked all files, like those in docs/pyjalali/_static/?

...

> However, doesn't this fall under the category of generated content by Sphinx?


Basically, for copyright purposes, there are only two categories, trivial files and non-trivial files.  Non-trivial files should have copyright and license notices.  The legal status of anything the tarball contains should be clear.

> I also didn't know exactly where to put licenses. Can you guide me?
> For example both underscore.js and jquery.js use MIT license. And MIT license
> comes with "Copyright (c) [year] [fullname]" in its heading.
> So should I create two files in _static, one named underscore_LICENSE.txt and
> the other jquery_LICENSE.txt?


I'm not sure what 'MIT' license means, it's ambiguous.  Historically, MIT released software under many various licenses.

If it's a short permissive license, then it should be included entirely; in such cases, the license coincides with the license notice.

> Oh, how's that? I was under the impression that all the contributors had to
> give copyright wavers to the FSF (as in Emacs).


No.  Some GNU packages are FSF-copyrighted, and other are not.

> If this is not the case, I'd like to nominate jcal to become a GNU project.


Let us return to this question when the original task is done.

Ineiev <ineiev>
Site Administrator
Fri 03 Oct 2025 07:26:42 AM UTC, comment #23: 


> Thanks!  Can you attach a patch set, for the reference?  Codeberg sometimes rejects me.


Sure thing. I have attached the patch for my latest commit.

>  Have you checked all files, like those in docs/pyjalali/_static/?


To be honest I hadn't, the pyjalali part is too old and I doubt it will run on Python 3. I haven't spent enough time on reviving it yet. So I'm inclined to remove the auto-generated docs for the time being.

However, doesn't this fall under the category of generated content by Sphinx? I also didn't know exactly where to put licenses. Can you guide me?
For example both underscore.js and jquery.js use MIT license. And MIT license comes with "Copyright (c) [year] [fullname]" in its heading.
So should I create two files in _static, one named underscore_LICENSE.txt and the other jquery_LICENSE.txt?

>  (By the way: it isn't necessary to be the sole copyright holder in order to offer a package to the GNU Project; for example, the maintainer of linux-libre is not.)


Oh, how's that? I was under the impression that all the contributors had to give copyright wavers to the FSF (as in Emacs). If this is not the case, I'd like to nominate jcal to become a GNU project. It'd be preserved much better that way.

(file #57697)

Hossein <hossein>
Thu 02 Oct 2025 02:46:37 PM UTC, comment #22: 

comment #21:

> Alright! Thanks again for the URLs. Let me know if my latest commit rectifies the problems. I have:
> 1. Removed the git2changelog which used GPLv2-or-later.
> 2. Made my own copyright claim in a new line.


Thanks!  Can you attach a patch set, for the reference?  Codeberg sometimes rejects me.

> I checked and the copyright notice is otherwise verbatim from the notice in GPL HowTo. I was also unable to find any other file that uses any other license, let me know if there are any.


Have you checked all files, like those in docs/pyjalali/_static/?

> Actually I'd love jcal to become a GNU package, however I am not the sole copyright holder and therefore I won't be able to do that.


(By the way: it isn't necessary to be the sole copyright holder in order to offer a package to the GNU Project; for example, the maintainer of linux-libre is not.)

Ineiev <ineiev>
Site Administrator
Thu 02 Oct 2025 10:05:13 AM UTC, comment #21: 

Alright! Thanks again for the URLs. Let me know if my latest commit rectifies the problems. I have:
1. Removed the git2changelog which used GPLv2-or-later.
2. Made my own copyright claim in a new line.

I checked and the copyright notice is otherwise verbatim from the notice in GPL HowTo. I was also unable to find any other file that uses any other license, let me know if there are any.

I also read a fair part of GPL FAQ and it was a nice rabbit-hole.

> Hi Hossein: unless you plan to make it a GNU package, you can save yourself tons of energy (and etc.) by staying on codeberg, which is certainly at least passing the ethical repo standard (recent news learned from another source). savannah doesn't offer much benefits over codeberg and the downside is too apparent. This is the advice from a junior savannah hacker.


Hi Luke! Thanks for the advice. Actually I'd love jcal to become a GNU package, however I am not the sole copyright holder and therefore I won't be able to do that.
I am also aware of the shortcomings of Savannah. But as strict as the rules maybe, I like that I'm learning throughout the process. It's like having a mentor on licensing, which is nice and I'd love it if Codeberg offered it too.

Hossein <hossein>
Thu 02 Oct 2025 08:42:15 AM UTC, comment #20: 

no, I did not say "learning takes energy", I wanted to say "dealing with 'whatever this is' is wasting one's energy"

Luke Yasuda <jing>
Site Administrator
Thu 02 Oct 2025 06:20:02 AM UTC, comment #19: 

Yes, it's true that learning takes energy; whether it's worth the efforts is for Hossein to decide.

Ineiev <ineiev>
Site Administrator
Thu 02 Oct 2025 01:53:21 AM UTC, comment #18: 

Hi Hossein: unless you plan to make it a GNU package, you can save yourself tons of energy (and etc.) by staying on codeberg, which is certainly at least passing the ethical repo standard (recent news learned from another source). savannah doesn't offer much benefits over codeberg and the downside is too apparent. This is the advice from a junior savannah hacker.

Luke Yasuda <jing>
Site Administrator
Wed 01 Oct 2025 05:38:45 PM UTC, comment #17: 

Thank you!

comment #16:

>1. For some reason COPYING was in .gitignore and I hadn't noticed that the project lacks this file. Now the project comes with LGPLv3 and GPLv3 licenses.


I see.  It's important to have a copy of all used licenses in the tarball in order to make the users aware of their rights prominently and unambiguously.  Can you check if other used licenses are missing in your tarball?

> 3. I had used sed to add my name to the project for 2025, and the man files that I hadn't changed were affected too. I reverted this change.


While at the copyright notices: valid notices should have a certain form; please see savannah.nongnu.o ... nce/ValidNotices/ www.gnu.org/prep/ ... ight-Notices.html

Ineiev <ineiev>
Site Administrator
Tue 30 Sep 2025 09:44:08 AM UTC, comment #16: 

Thanks a lot for giving the URL. I had for some reason missed it. Although I knew most of it, it helped to see a thorough guide.

Here are the changes I made:
1. For some reason COPYING was in .gitignore and I hadn't noticed that the project lacks this file. Now the project comes with LGPLv3 and GPLv3 licenses.
2. The pyjalali library lacked a proper notice in its files, this has now been fixed.
3. I had used sed to add my name to the project for 2025, and the man files that I hadn't changed were affected too. I reverted this change.
4. I added the news about Ashkan's death in AUTHORS file, added my own contact point.

You can see the changes here:
https://codeberg. ... 36ea338d4214fc2a8

Hossein <hossein>
Mon 29 Sep 2025 08:21:24 PM UTC, comment #15: 


> I have read the hosting requirements, as well as the requirements of GPL and
> LGPL which this project uses, rather carefully and I believe that my fork
> (which contains contributions from my friend  as well) fulfills all the
> requirements. (except for one line of comment that uses the term AI, which
> goes against the recommendation of
> https://www.gnu.o ... rds-to-avoid.html, but that function and its
> comments will be rewritten in future versions anyway.)


Thank you!  It's nice that you are taking into accounts the words to use with care, but strictly speaking, that is not a Savannah hosting requirement.

> However, I am a newbie in this area and willing to learn; so if there are any
> inconsistencies let me know and I'll fix them.


Very well.  Let us begin with the licenses.  Your package uses LGPLv3.  Please read it again, and the GPL HowTo.  Don't you see if your tarball is missing anything?

Ineiev <ineiev>
Site Administrator
Sun 28 Sep 2025 08:20:12 PM UTC, comment #14: 

Your assumption is correct.

I have read the hosting requirements, as well as the requirements of GPL and LGPL which this project uses, rather carefully and I believe that my fork (which contains contributions from my friend  as well) fulfills all the requirements. (except for one line of comment that uses the term AI, which goes against the recommendation of https://www.gnu.o ... rds-to-avoid.html, but that function and its comments will be rewritten in future versions anyway.)

However, I am a newbie in this area and willing to learn; so if there are any inconsistencies let me know and I'll fix them.

Thanks!

Hossein <hossein>
Sun 28 Sep 2025 07:40:28 PM UTC, comment #13: 


> You can download a tarball from: https://codeberg. ... ein/jcal/releases


Thank you!  I'll assume the version 0.6.0.

Have you checked it against Savannah hosting requirements?  Are there any incompliances?

Ineiev <ineiev>
Site Administrator
Sat 27 Sep 2025 04:51:29 PM UTC, comment #12: 

I'd like to thank you both for your assistance.

I spent today to make a bug-free version of jcal. Here's the changes I have made. It is directly forked from Ashkan's repo in Savannah: https://codeberg. ... mmits/branch/main

You can download a tarball from: https://codeberg. ... ein/jcal/releases

Although when I get access to Savannah I'd make this a read-only mirror of the repo in Savannah, and I'd also release the codes in source directory as the tarball.

Hossein <hossein>
Sat 27 Sep 2025 11:03:03 AM UTC, comment #11: 

In any case we'll want to make sure that the new maintainer is able to follow Savannah hosting requirements, and the usual way is to evaluate a tarball prepared by the prospective maintainer.

Ineiev <ineiev>
Site Administrator
Fri 26 Sep 2025 11:24:01 PM UTC, comment #10: 

OK.  Thank you.  I have reopened (and, for the moment) taken charge of the ticket.  I can discuss with Richard in Boston if needs be but, as ineiev has said: we will need to discuss a little internally.   I can commit to reporting back within two weeks, probably very much sooner.  Thanks for your work on this package.

Corwin Brust <carlc>
Site Administrator
Fri 26 Sep 2025 10:52:20 PM UTC, comment #9: 

Hello again,

Given that the forked project is not landing on different distros on a timely fashion, and that there are a few unattended bugs on the fork as well. I'd like to continue the development of jcal on my own (independent of the current fork on Github) while respecting the spirit of freedom and rules on Savannah.

I'd be much obliged if I were given access to the repo and could act as its maintainer.

Many thanks.

Hossein <hossein>
Tue 13 May 2025 03:30:55 PM UTC, comment #8: 


> Alright, much to my dismay, the current lead maintainer decided to go with Github instead. The new project has landed in Debian's repositories btw.


I see; closing the sr.

> If you're 100% sure you don't want us to take the repo and use it as a mirror,


I don't think that would make sense.  GitHub has an incomparably greater bandwidth and computing power than Savannah.

> we'd be much obliged if you could at least link the new repository in the project's homepage as an alternative


GitHub is hostile to free software.  The GNU Project generally avoids linking to it.

Ineiev <ineiev>
Site Administrator
Mon 12 May 2025 06:55:50 AM UTC, comment #7: 

Alright, much to my dismay, the current lead maintainer decided to go with Github instead. The new project has landed in Debian's repositories btw.

If you're 100% sure you don't want us to take the repo and use it as a mirror, we'd be much obliged if you could at least link the new repository in the project's homepage as an alternative: https://github.co ... m/persiancal/jcal

Thanks again for hosting this project for all these years.

comment #6:

> Hello again,
>
> I just wanted to say that we're discussing the primary use of Savannah internally and that's why it's taking us long to respond. We'll let you know and thanks.

Hossein <hossein>
Sun 04 May 2025 07:33:41 AM UTC, comment #6: 

Hello again,

I just wanted to say that we're discussing the primary use of Savannah internally and that's why it's taking us long to respond. We'll let you know and thanks.


comment #5:

> > I consider myself to be a free software enthusiast and I don't see why any of
> > the requirements you have should be disregarded. If that is your concern, you
> > can count on the new team to keep jcal a free software as it always have
> > been.
>
> Very well.  Can you check the current state of jcal against Savannah
> hosting requirements?  (By the way, please note that they are
> stronger than just being free software.)
>
> > So still I'd like to volunteer and take charge of jcal repo on nongnu, keeping
> > in mind your requirements. The only change that I don't like yet may be
> > necessary is that we may make this a mirror of Github (or Codeberg), as they
> > offer better issue tracking and a nicer UI for contributors. I don't believe
> > any change will happen to the free spirit of the program otherwise.
>
> This would conflict with our policies.  We expect to be used primarily and
> not as a back-up.  We exist to help people develop software and technical
> documentation.  Other hosting services offer storage space.
>

Hossein <hossein>
Fri 25 Apr 2025 07:30:38 PM UTC, comment #5: 


> I consider myself to be a free software enthusiast and I don't see why any of
> the requirements you have should be disregarded. If that is your concern, you
> can count on the new team to keep jcal a free software as it always have
> been.


Very well.  Can you check the current state of jcal against Savannah
hosting requirements?  (By the way, please note that they are
stronger than just being free software.)

> So still I'd like to volunteer and take charge of jcal repo on nongnu, keeping
> in mind your requirements. The only change that I don't like yet may be
> necessary is that we may make this a mirror of Github (or Codeberg), as they
> offer better issue tracking and a nicer UI for contributors. I don't believe
> any change will happen to the free spirit of the program otherwise.


This would conflict with our policies.  We expect to be used primarily and
not as a back-up.  We exist to help people develop software and technical
documentation.  Other hosting services offer storage space.

Ineiev <ineiev>
Site Administrator
Fri 25 Apr 2025 05:48:09 AM UTC, comment #4: 


> To tell the truth, our concerns dwell in a somewhat different plain.  Savannah has a few hosting requirements to be followed by the admins of the hosted packages, and they are surprisingly hard to follow for the newcomers.


I see.

I consider myself to be a free software enthusiast and I don't see why any of the requirements you have should be disregarded. If that is your concern, you can count on the new team to keep jcal a free software as it always have been.


> On the other hand, it seems possible to me that after all these years of discontinued maintenance the Savannah jcal group isn't actually the 'upstream' for the distros any more, that is,


Well at least the homepage of the project has not been changed, even on NixOS repos for example. But even then it'll be quite a task for us to convince all the distros to migrate. It was only after the bug affected the usability of the program that volunteers are trying to push the new code onto the distros.

So still I'd like to volunteer and take charge of jcal repo on nongnu, keeping in mind your requirements. The only change that I don't like yet may be necessary is that we may make this a mirror of Github (or Codeberg), as they offer better issue tracking and a nicer UI for contributors. I don't believe any change will happen to the free spirit of the program otherwise.

Hossein <hossein>
Mon 21 Apr 2025 04:45:41 PM UTC, comment #3: 

On Sun, Apr 20, 2025 at 02:55:13AM -0400, Hossein wrote:

>
> Given the xz attack I totally understand your concern. I signed up using my
> academic email, tied to my real identity. I can also provide further
> guarantees if needed.


To tell the truth, our concerns dwell in a somewhat different plain.  Savannah has a few hosting requirements to be followed by the admins of the hosted packages, and they are surprisingly hard to follow for the newcomers.  Still our users expect that these packages live up to these standards, so we need to make sure that the admins who take over orphan groups are able to comply with them.

> Note that due to a bug (https://github.co ... ncal/jcal/pull/15) in the old
> code, it is one day behind the real date. If we could make distroes benefit
> from the new code, it'd be great.


On the other hand, it seems possible to me that after all these years of discontinued maintenance the Savannah jcal group isn't actually the 'upstream' for the distros any more, that is,

  • updates in it will not be automatically accepted by the distros, and
  • the distros may accept bug fixes from other sources.


Ineiev <ineiev>
Site Administrator
Sun 20 Apr 2025 06:55:07 AM UTC, comment #2: 

comment #1:

> Thank you for your work on this package.  Your request isn't trivial; please let people behind Savannah discuss it internally to make the right decision.


Given the xz attack I totally understand your concern. I signed up using my academic email, tied to my real identity. I can also provide further guarantees if needed.

Note that due to a bug (https://github.co ... ncal/jcal/pull/15) in the old code, it is one day behind the real date. If we could make distroes benefit from the new code, it'd be great.

Thanks for considering this.

Hossein <hossein>
Wed 16 Apr 2025 03:26:49 PM UTC, comment #1: 

Thank you for your work on this package.  Your request isn't trivial; please let people behind Savannah discuss it internally to make the right decision.

Ineiev <ineiev>
Site Administrator
Sun 13 Apr 2025 01:31:36 PM UTC, original submission:  

Hi!

I am an Iranian student. Currently nongnu.org hosts an important piece of software for Iranian people called 'jcal'. Here's the link: https://www.n ... gnu.org/jcal/

However due to an unfortunate accident the owner of this repo, a prominent figure in Iranian free software, has died:
Source 1: https://jadi.net/ ... 0/ashkan-ghasemi/
Source 2: https://meid ... n.com/ashkan
Source 3: https://mehdix. ... rip-ashkan.html

You can use Google Translate or an AI of your choosing to translate the sources above (which are actually quite old now), or just search فوت اشکان قاسمی (Death of Ashkan Ghasemi) by yourself.

I would be very grateful if you let me (based in Iran), or the person behind https://githu ... om/persiancal (based in Berlin) take ownership of the repo. Currently NixOS is using the new version of the tool, however for effective and more expedient adoption it'd be awesome if you could handle the ownership change.

Many thanks,
Hossein.

Anonymous

 

Attached Files

Attached Files

(Note: upload size limit is set to 16MiB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Dependencies

This item does not depend on any other items.

No items depend on this one.

 

Mail Notification Carbon-Copy List

Carbon-Copy List
  • -email is unavailable- added by jing (Posted a comment)
  • -email is unavailable- added by carlc (Posted a comment)
  • -email is unavailable- added by hossein (Posted a comment)
  • -email is unavailable- added by ineiev (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    Votes

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    History

    Follow 22 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-10-03 hossein Attached File- Added 0001-Correct-copyright-notice-on-each-file.patch, #57697
    2025-10-02 ineiev StatusNeed Info In Progress
        Assigned tocarlc ineiev
    2025-10-02 jing Originator Email -email is unavailable-
    2025-10-02 jing Assigned toineiev carlc
    2025-10-02 jing CategoryLost account Source code repositories - developer access
    2025-10-02 ineiev Assigned tocarlc ineiev
        Originator Email-email is unavailable-
    2025-10-02 jing Assigned toineiev carlc
        Originator Email -email is unavailable-
        Operating SystemGNU/Linux None
    2025-09-27 ineiev CategoryWebpages repositories Lost account
        Assigned tocarlc ineiev
        Originator Email-email is unavailable-
    2025-09-26 carlc Priority5 - Normal 7 - High
        StatusWont Do Need Info
        Assigned toineiev carlc
        Open/ClosedClosed Open
    2025-05-13 ineiev StatusIn Progress Wont Do
        Open/ClosedOpen Closed
    2025-04-16 ineiev StatusNone In Progress
        Assigned toNone ineiev

    Back to the top

    Powered by Savane 3.16.
    Corresponding source code