Pierre Langlois writes:

> Pierre Langlois writes:
>
>> Hi!
>>
>> Marinus Savoritias writes:
>>
>>> I update Guix yesterday and org-mode doesn't load anymore.
>>>
>>> The debug trace is this:
>>>
>>> Debugger entered--Lisp error: (error "Invalid version syntax: ‘’ (must start
>>> with a number)")
>>>   signal(error ("Invalid version syntax: ‘’ (must start with a number)"))
>>>   error("Invalid version syntax: `%s' (must start with a number)" "")
>>>   version-to-list("")
>>>   version<("" "9.0")
>>>   #f(compiled-function () #<bytecode 0x5c3b49>)()
>>>   funcall(#f(compiled-function () #<bytecode 0x5c3b49>))
>>>   (lambda nil (funcall '#f(compiled-function () #<bytecode 0x5c3b49>)))()
>>> eval-after-load-helper("/home/marinus/.guix-profile/share/emacs/site-lisp/org.elc")
>>>   run-hook-with-args(eval-after-load-helper
>>> "/home/marinus/.guix-profile/share/emacs/site-lisp/org.elc")
>>> do-after-load-evaluation("/home/marinus/.guix-profile/share/emacs/site-lisp/org.elc")
>>>   require(org)
>>> byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305!\210\300\306!\210\307\310\311\312\313\314%\210\315\316\317\320\313\310\321\322&\7\210\315\323\324\325\313\310\321..."
>>> [require elfeed org dash s cl-lib xml custom-declare-group elfeed-org 
>>> nil "Configure the Elfeed RSS reader with an Orgmode fi..." :group comm
>>> custom-declare-variable rmh-elfeed-org-tree-id "elfeed" "The tag or ID 
>>> property on the trees containing the..." :type string rmh-elfeed-org-ignore-tag
>>> "ignore" "The tag on the feed trees that will be ignored."
>>> rmh-elfeed-org-auto-ignore-invalid-feeds "Tag feeds to ignore them when a feed
>>> could not loa..." bool rmh-elfeed-org-files (list "~/.emacs.d/elfeed.org") "The
>>> files where we look to find trees with the `rm..." (repeat (file :tag "org-mode
>>> file"))] 8)
>>>   require(elfeed-org)
>>>   eval-buffer(#<buffer  *load*> nil "/home/marinus/.emacs" nil t)  ; Reading at
>>> buffer position 39
>>>   load-with-code-conversion("/home/marinus/.emacs" "/home/marinus/.emacs" t t)
>>>   load("~/.emacs" noerror nomessage)
>>>   startup--load-user-init-file(#f(compiled-function () #<bytecode 0x5c3f71>)
>>> #f(compiled-function () #<bytecode 0x5c3f85>) t)
>>>   command-line()
>>>   normal-top-level()
>>>
>>> Everytime I try to open a org file I get the same error. I noticed that after I
>>> removed the elfeed-org requirement to see if that was the problem.
>>>
>>> Emacs commit is this:   /gnu/store/lhw3zwhzra0w5l8a4jw8fvm58i75xyl8-emacs-27.1
>>>
>>> Guix System config is this:
>>>
>>> Generation 15   Dec 26 2020 15:25:17    (current)
>>>   guix 4969b51
>>>     repository URL: https://git.savannah.gnu.org/git/guix.git
>>>     branch: master
>>>     commit: 4969b51d175497bfcc354c91803e9d70542b7113
>>>
>>> My .emacs file has nothing besides this:
>>>
>>> ;;Elfeed config
>>>
>>> (require 'elfeed-org)
>>> (setq rmh-elfeed-org-files (list "~/.emacs.d/elfeed.org"))
>>
>> I also hit this issue yesterday :-/. To fix it, I found you could make
>> sure to have (require 'org) *before* loading other packages that
>> depended on org. Would that work for you? I'm using use-package, so the
>> particular fix for me was to add ":after org" on every package
>> declaration that needed to use org.
>>
>> There's still an issue upstream I think, probably due to a mis-match
>> between the org that's shipped in emacs and the newer one in guix?
>
> Actually, it started failing again just after I sent this message... It
> seems reordering require didn't actually fix anything, sorry!
>
> Looking into it a little bit more, it seems there was an issue with the
> version reporting, if you try and evaluate (org-version), it returns an
> empty string, then causing the original backtrace.
>
> There seems to be an issue when building the package, I see the result
> of (org-version) should be defined at build-time: https://code.orgmode.org/bzg/org-mode/src/master/mk/default.mk#L118
>
> But we don't do it properly:
>
> --8<---------------cut here---------------start------------->8---
> $ cat $(guix build emacs-org)/share/emacs/site-lisp/org-version.el
> ;;; org-version.el --- autogenerated file, do not edit
> ;;
> ;;; Code:
> ;;;###autoload
> (defun org-release ()
>   "The release version of Org.
> Inserted by installing Org mode or when a release is made."
>    (let ((org-release ""))
>      org-release))
> ;;;###autoload
> (defun org-git-version ()
>   "The Git version of Org mode.
> Inserted by installing Org or when a release is made."
>    (let ((org-git-version ""))
>      org-git-version))
>
>
> (provide 'org-version)
> --8<---------------cut here---------------end--------------->8---
>
> I'll see if I can spot anything going wrong during the build process.

So, as it turns out tarball on elpa contains this bug, I've just
reported it upstream: https://lists.gnu.org/archive/html/emacs-orgmode/2020-12/msg00729.html

In the meantime, we can either revert the update or just fix it
downstream temporarily. The following patch works for me for example:

--8<---------------cut here---------------start------------->8---
diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index eaa0fc8d2a..e65666a6ac 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -10296,6 +10296,11 @@ passive voice.")
     (arguments
      `(#:phases
        (modify-phases %standard-phases
+         (add-after 'unpack 'fix-org-version
+           (lambda _
+             (substitute* "org-version.el"
+               (("org-release \"\"") (string-append "org-release \"" ,version "\"")))
+             #t))
          (add-after 'install 'install-documentation
            (lambda* (#:key outputs #:allow-other-keys)
              (let* ((share (string-append (assoc-ref outputs "out") "/share"))
--8<---------------cut here---------------end--------------->8---

I'm more tempted to add this little fix rather than revert the update,
given we'd also have to revert org-contrib.

WDYT?

Thanks,
Pierre