Hello,

Sorry Simon for the noise, this is just a quick feedback about my
debugging; next messages will be only to debbugs, you know how to track
it :-D 

Meanwhile I've learned how to test things in a dedicated environment,
thanks to some interesting tips [1] (I ignored before) adapted to Guix;
this confirms (ça va sanse dire) how powerful Guix is!

Giovanni Biscuolo <g@xelera.eu> writes:

[...]

>> Yes, AFAIU it's really a loading order triggered error... and I'm not
>> able to debug this :-(
>
> I've finally found the conflicting configuration!

No, I've actually found a workaround - commenting out "(require
'org-tempo)" in my init.el - that works with my emacs configuration (and
package set) BUT there is absolutely no conflict between org-tempo and
elfeed-org.

I confirm that if I eval "(require 'org-tempo)" I get the previously
reported error and backtrace, I confirm that if I do not remove
(comment) "(require 'org-tempo)" in my "production" init.el elfeed does
not work as reported in the first message of this bug report.

Last but not least, I confirm I had no issues with the same manifest
(I've replaced ghc-pandoc with pandoc but that's tangent) and the same
init.el using Guix Emacs 26.3

So I ceated a directory dedicated to my tests in
~/.emacs-testing.d/test-elfeed, where I put "manifest.scm" and a
"test-elfeed.el" (both attached below, inline).

Well: if I do this

--8<---------------cut here---------------start------------->8---

[~/.emacs-testing.d/test-elfeed]-
giovanni@roquette: guix environment --pure --ad-hoc -m manifest.scm -- emacs -q -l test-elfeed.el

--8<---------------cut here---------------end--------------->8---

I get an emacs session with a running elfeed, and "(require 'org-tempo)"
is there.

This is manifest.scm: