Hi there,
Kyle Meyer writes:
> Stefan Monnier writes:
>
>> Indeed that's the origin of the problem.
>
> Thanks for confirming.
>
>> I don't know exactly how `org-version.el` is created and how the release
>> version is extracted, so I'm not sure how to fix it.
>>
>> The approach I'd advocate
> Based on tested in a `git clone --no-tags ...` repo, should be fixed by
> 61336f80d.
Looks like it works: the `version.el` in
https://elpa.gnu.org/devel/org-9.5snapshot0.20210205.62105.tar
now says:
(defun org-release ()
"The release version of Org.
Inserted by installing Org
Stefan Monnier writes:
> Indeed that's the origin of the problem.
Thanks for confirming.
> I don't know exactly how `org-version.el` is created and how the release
> version is extracted, so I'm not sure how to fix it.
>
> The approach I'd advocate would be to use `package-get-version` (or
>
>> Since the latest update to 9.4.4, some of us in Guix have been
>> experiencing issues with loading packages that depend on Org [0]. It
>> seems the root of the problem is that (org-release) returns an empty
>> string, you can see this manifesting in this email actually :-).
[...]
> In between
Pierre Langlois writes:
> Hello there!
>
> Since the latest update to 9.4.4, some of us in Guix have been
> experiencing issues with loading packages that depend on Org [0]. It
> seems the root of the problem is that (org-release) returns an empty
> string, you can see this manifesting in this
Hello there!
Since the latest update to 9.4.4, some of us in Guix have been
experiencing issues with loading packages that depend on Org [0]. It
seems the root of the problem is that (org-release) returns an empty
string, you can see this manifesting in this email actually :-).
Looking a little
