unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#62893: 30.0.50; ELPA recipes with broken :url property values
@ 2023-04-17  2:53 No Wayman
  2023-04-18  6:13 ` Philip Kaludercic
  0 siblings, 1 reply; 4+ messages in thread
From: No Wayman @ 2023-04-17  2:53 UTC (permalink / raw)
  To: 62893


In elpa-packages, is there a reason why we keep the :url property 
for packages for which
the upstream no longer exists? e.g. any package :url pointing to 
"http://www.dr-quibit.org/git/predictive.git"?

I ask because I'm writing GNU/NonGNU ELPA support for Elpaca.
I'd like to avoid hard-coding an exception for that URL when 
generating package recipes.
Would a patch changing those :url values to nil be accepted?
If so, should the old URL be preserved in a comment above each 
package?





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#62893: 30.0.50; ELPA recipes with broken :url property values
  2023-04-17  2:53 bug#62893: 30.0.50; ELPA recipes with broken :url property values No Wayman
@ 2023-04-18  6:13 ` Philip Kaludercic
  2023-09-05 16:34   ` Stefan Kangas
  0 siblings, 1 reply; 4+ messages in thread
From: Philip Kaludercic @ 2023-04-18  6:13 UTC (permalink / raw)
  To: No Wayman; +Cc: 62893

No Wayman <iarchivedmywholelife@gmail.com> writes:

> In elpa-packages, is there a reason why we keep the :url property for
> packages for which
> the upstream no longer exists? e.g. any package :url pointing to
> "http://www.dr-quibit.org/git/predictive.git"?
>
> I ask because I'm writing GNU/NonGNU ELPA support for Elpaca.
> I'd like to avoid hard-coding an exception for that URL when
> generating package recipes.
> Would a patch changing those :url values to nil be accepted?
> If so, should the old URL be preserved in a comment above each
> package?

Elpa-admin.el fails with a message from "git fetch", which makes sense
if a repository is temporarily not available.  What I think would make
sense here would be to first check what repositories are failing and
then consider if setting the :url to nil would make sense or if it has
just moved somewhere else.

E.g. in this case it seems that there has been an issue with the hosting
provider, and Toby has been (very) slowly porting his packages over to
Gitlab: https://dr-qubit.org/undo-tree.html#orgffcc37e.





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#62893: 30.0.50; ELPA recipes with broken :url property values
  2023-04-18  6:13 ` Philip Kaludercic
@ 2023-09-05 16:34   ` Stefan Kangas
  2023-09-05 19:42     ` Stefan Kangas
  0 siblings, 1 reply; 4+ messages in thread
From: Stefan Kangas @ 2023-09-05 16:34 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: Toby Cubitt, No Wayman, 62893

Philip Kaludercic <philipk@posteo.net> writes:

> No Wayman <iarchivedmywholelife@gmail.com> writes:
>
>> In elpa-packages, is there a reason why we keep the :url property for
>> packages for which
>> the upstream no longer exists? e.g. any package :url pointing to
>> "http://www.dr-quibit.org/git/predictive.git"?
>>
>> I ask because I'm writing GNU/NonGNU ELPA support for Elpaca.
>> I'd like to avoid hard-coding an exception for that URL when
>> generating package recipes.
>> Would a patch changing those :url values to nil be accepted?
>> If so, should the old URL be preserved in a comment above each
>> package?
>
> Elpa-admin.el fails with a message from "git fetch", which makes sense
> if a repository is temporarily not available.  What I think would make
> sense here would be to first check what repositories are failing and
> then consider if setting the :url to nil would make sense or if it has
> just moved somewhere else.
>
> E.g. in this case it seems that there has been an issue with the hosting
> provider, and Toby has been (very) slowly porting his packages over to
> Gitlab: https://dr-qubit.org/undo-tree.html#orgffcc37e.

I think the only one left to fix is predictive:

    https://dr-qubit.org/predictive.html

Toby, could you please look into this package too when you have the
chance?





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#62893: 30.0.50; ELPA recipes with broken :url property values
  2023-09-05 16:34   ` Stefan Kangas
@ 2023-09-05 19:42     ` Stefan Kangas
  0 siblings, 0 replies; 4+ messages in thread
From: Stefan Kangas @ 2023-09-05 19:42 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: Toby Cubitt, No Wayman, 62893

Stefan Kangas <stefankangas@gmail.com> writes:

> I think the only one left to fix is predictive:
>
>     https://dr-qubit.org/predictive.html
>
> Toby, could you please look into this package too when you have the
> chance?

The email address I tried bounced, so I'm trying this one.

Toby, please see above.





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-09-05 19:42 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-17  2:53 bug#62893: 30.0.50; ELPA recipes with broken :url property values No Wayman
2023-04-18  6:13 ` Philip Kaludercic
2023-09-05 16:34   ` Stefan Kangas
2023-09-05 19:42     ` Stefan Kangas

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).