repositories: Add overlays for emacs package repositories.

[houseofsuns]

Specifically these are:

• gnu-elpa
• melpa
• melpa-stable
• nongnu-elpa

They are automatically refreshed from their source repositories via gs-elpa.

[Flowdalic]

I am skeptical about this.

It appears that you used gs-elpa, which hasn't seen a commit since 2015, to automatically generate ebuilds of packages in the four mentioned emacs package repositories. So this adds a massive amount of ebuilds, which is not itself a bad thing. However, a quick check showed that the ebuilds appear have some QA issues like

app-emacs/aggressive-indent
  RedundantLongDescription: metadata.xml longdescription closely matches DESCRIPTION
  MissingLicense: version 1.10.0: no license defined

I fear that if those Gentoo package repositories are added, then they would permanently show QA errors.

But in the end it probably comes down to how usable are auto-generated packages with a tool from 2015 turn out to be. If you believe that there is a benefit for doing so, or if I am missing something, then please let me know.

But before this can be considered for merging, the QA reports for those repositories should be addressed.

[Flowdalic]

I just saw that you maintain your own fork of gs-elpa and g-sorcery. So maybe the situation is not as dire as I thought it is. I'd love to hear what @ulm thinks, as he should be knowledgeable about gs-elpa/g-sorcery and elisp packaging in general.

[ulm]

But in the end it probably comes down to how usable are auto-generated packages with a tool from 2015 turn out to be.

Sure, g-sorcery and gs-elpa haven't see much activity after jauhien's retirement. But the tools are alive, and we try to address any issues when they arise:
https://gitweb.gentoo.org/proj/g-sorcery.git/
https://gitweb.gentoo.org/proj/gs-elpa.git/

I fear we cannot do much about the QA warnings, as there is no easy way to extract e.g. the license information (ELPA should be all GPL licensed, though).

[Flowdalic]

@ulm would you assume that merging this PR is beneficial for Gentoo users?

[Flowdalic]

FWIW, I tried to emerge a random package from one of the repos

$ eselect repository add gnu-elpa git https://github.com/houseofsuns/gnu-elpa.git 
$ eselect repository add melpa-stable git https://github.com/houseofsuns/melpa-stable.git
$ ACCEPT_KEYWORDS="~amd64" emerge orgbox
…
>>> Emerging (2 of 2) app-emacs/orgbox-0.5.0::melpa-stable
 * orgbox-0.5.0.el BLAKE2B SHA512 size ;-) ...                                                                                      [ ok ]
 * Emacs version: 28.2
>>> Unpacking source...
>>> Unpacking orgbox-0.5.0.el to /data-scratch/var-tmp/portage/app-emacs/orgbox-0.5.0/work
unpack orgbox-0.5.0.el: file format not recognized. Ignoring.
mv: cannot stat './orgbox-0.5.0.el': No such file or directory
 * ERROR: app-emacs/orgbox-0.5.0::melpa-stable failed (unpack phase):
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line 136:  Called src_unpack
 *   environment, line 945:  Called gs-elpa_src_unpack
 *   environment, line 847:  Called die
 * The specific snippet of code:
 *           mv ./${SOURCEFILE} ./${P}/${REALNAME}.${SUFFIX} || die;

I see a similar failure with app-emacs/znc. Granted, the sample size is only two, but I wonder if this is ready to be made easily discoverable by our users.

Edit: I also just found that the repos appear to duplicate app-emacs/org-mode as app-emacs/org.

[ulm]

@ulm would you assume that merging this PR is beneficial for Gentoo users?

@houseofsuns: Could you elaborate what would be the advantage, as compared to the user building these repos himself with app-portage/gs-elpa?

[houseofsuns]

I see a similar failure with app-emacs/znc. Granted, the sample size is only two, but I wonder if this is ready to be made easily discoverable by our users.

Argh, that's indeed a bug I introduced in my fork. I'll need to fix that and come back here.

Edit: I also just found that the repos appear to duplicate app-emacs/org-mode as app-emacs/org.

I'm not a heavy org-user so I didn't notice. As it's listed as "org" in ELPA this will need a specific fix.

@houseofsuns: Could you elaborate what would be the advantage, as compared to the user building these repos himself with app-portage/gs-elpa?

It offers mainly two advantages:
(i) distfile digests: some assurance that the downloaded files are not randomly replaced
(ii) easier setup: no fiddling with layman and gs-elpa

I'll be busy over the weekend, but I'll hopefully get around to this next week.

[houseofsuns]

I'm back and it should be ready for prime time now.

I fixed the bug with unpack.

I checked the qa-warnings with pkgcheck and fixed as many as possible. Sadly license information is not available so that could not be rectified. I added homepage information and it now complains about missing remote ids, which I felt was not worth the effort. Last was the redundant longdescription. It could simply be dropped, but I'm hesitant whether tools like eix will in that case miss something and it's not a severe issue.

I also substituted org-mode for org as well as a handful of other mismatched packages.