buffer-extension.el[1] provides enhanced functions for buffer manipulations. Pull request[2] on github adds app-emacs/buffer-extension ebuild and its dependencies. [1] https://www.emacswiki.org/emacs/buffer-extension.el [2] https://github.com/gentoo/gentoo/pull/1339
Hello @gnu-emacs Could someone peer-review Victor's PR and sign off on it? Thanks!
Some comments throughout: - Ebuilds should be newest EAPI, i.e. EAPI=6. - Is the license really GPL-3 only? If it is GPL version 3 or later, it should be labelled LICENSE="GPL-3+". - Empty IUSE="" assignments are not needed. - The DEPENDs look suspicious, I'd guess they should be in RDEPEND as well. Also, please put DEPEND and RDEPEND in a separate block, betweeen the LICENSE/SLOT/KEYWORDS and the SITEFILE blocks. - In site-init files, we usually include the first line of the function's docstring as the third argument. Also, is none of these functions interactive? Otherwise, a fourth argument of t should be added as well.
Please see updated PR. > - Ebuilds should be newest EAPI, i.e. EAPI=6. Fixed. > - Is the license really GPL-3 only? If it is GPL version 3 or later, it > should be labelled LICENSE="GPL-3+". Partially fixed. 1. buffer-extension and basic-toolkit are really GPL-3+. 2. cycle-buffer mentions no license, but emacswiki has a GPL-2 footer, which is the "default" license I guess. windows.el and revive.el mention no specific license; instead, they contain this note: ;;; This program is distributed as a free software. The author is ;;; not responsible for any possible defects caused by this ;;; software. See also copyright notice[1] for debian `windows-el' package[2], which contains author's response to debian maintainers. What license should we use for them? > - Empty IUSE="" assignments are not needed. > - The DEPENDs look suspicious, I'd guess they should be in RDEPEND as well. > Also, please put DEPEND and RDEPEND in a separate block, betweeen the > LICENSE/SLOT/KEYWORDS and the SITEFILE blocks. Fixed. > - In site-init files, we usually include the first line of the function's > docstring as the third argument. Also, is none of these functions > interactive? Otherwise, a fourth argument of t should be added as well. Could you give an example please? Do we need autoloads for all provided functions in site-init files? [1] http://sources.debian.net/copyright/license/windows-el/2.48-3/ [2] https://packages.debian.org/en/sid/windows-el
(In reply to Victor from comment #3) > 2. cycle-buffer mentions no license, but emacswiki has a GPL-2 footer, which > is the "default" license I guess. The wiki footer isn't the license of the file. Especially, it isn't a statement of the file's author, since cycle-buffer.el may have been uploaded to the wiki by somebody else. The license needs to be clarified with the author before we can include the package. > windows.el and revive.el mention no specific license; instead, they contain > this note: > > ;;; This program is distributed as a free software. The author is > ;;; not responsible for any possible defects caused by this > ;;; software. > > See also copyright notice[1] for debian `windows-el' package[2], which > contains author's response to debian maintainers. This is less than ideal, but I think we can copy lines 15 to 42 from the Debian notice [1] and add them as a license file. It should go to the @MISC-FREE group (CCing licenses team). > > - In site-init files, we usually include the first line of the function's > > docstring as the third argument. Also, is none of these functions > > interactive? Otherwise, a fourth argument of t should be added as well. > > Could you give an example please? See app-emacs/chess/files/50chess-gentoo.el which contains several examples. > Do we need autoloads for all provided functions in site-init files? The rule of thumb is that a function should be autoloaded if it would be executed by the user in order to start the package. For example, app-emacs/ebuild-mode has an autoload for 'ebuild-mode but not for any of the mode's internal commands (since those will be executed only when the package has been loaded). A similar rule applies for functions called non-interactively by another package. > [1] http://sources.debian.net/copyright/license/windows-el/2.48-3/ > [2] https://packages.debian.org/en/sid/windows-el
> > 2. cycle-buffer mentions no license, but emacswiki has a GPL-2 footer, which > > is the "default" license I guess. > > The wiki footer isn't the license of the file. Especially, it isn't a > statement of the file's author, since cycle-buffer.el may have been uploaded > to the wiki by somebody else. > > The license needs to be clarified with the author before we can include the > package. OK. I'll try to send him an email. > > windows.el and revive.el mention no specific license; instead, they contain > > this note: > > > > ;;; This program is distributed as a free software. The author is > > ;;; not responsible for any possible defects caused by this > > ;;; software. > > > > See also copyright notice[1] for debian `windows-el' package[2], which > > contains author's response to debian maintainers. > > This is less than ideal, but I think we can copy lines 15 to 42 from the > Debian notice [1] and add them as a license file. It should go to the > @MISC-FREE group (CCing licenses team). Done, see updated PR. > > > - In site-init files, we usually include the first line of the function's > > > docstring as the third argument. Also, is none of these functions > > > interactive? Otherwise, a fourth argument of t should be added as well. > > > > Could you give an example please? > > See app-emacs/chess/files/50chess-gentoo.el which contains several examples. > > > Do we need autoloads for all provided functions in site-init files? > > The rule of thumb is that a function should be autoloaded if it would be > executed by the user in order to start the package. For example, > app-emacs/ebuild-mode has an autoload for 'ebuild-mode but not for any of > the mode's internal commands (since those will be executed only when the > package has been loaded). > > A similar rule applies for functions called non-interactively by another > package. All packages now have autoload comments and use `elisp-make-autoload-file'. Is it OK? I've also updated `basic-toolkit' to version 0.3 (with autoload comments) and removed revive-2.22 ebuild.
The author of cycle-buffer.el kindly published the module on github[1] under public domain. EmacsWiki page[2] is also updated now[2]. (See updated pull request) Are there any other outstanding issues? [1] https://github.com/VladimirAlexiev/emacs/blob/master/cycle-buffer.el [2] https://www.emacswiki.org/emacs/cycle-buffer.el
Looks good. Thanks for the contribution!
One minor point: You are the "proxied maintainer", whereas a "proxy maintainer" is someone who is committing for you. I've updated all metadata.xml accordingly.
> You are the "proxied maintainer", whereas a "proxy maintainer" is someone who > is committing for you. I've updated all metadata.xml accordingly. Ah, really. Thanks! Is it OK that SRC_URIs in ebuilds still point to my server[1]? I'm not 100% sure that it will always work 24/7 :) [1] https://enise.org/users/victor/share/distfiles/
(In reply to Victor from comment #9) > Is it OK that SRC_URIs in ebuilds still point to my server[1]? I'm not 100% > sure that it will always work 24/7 :) > > [1] https://enise.org/users/victor/share/distfiles/ That should be OK, as the files will be on the Gentoo mirror system too. Alternatively, I could copy them to my dev space. Just tell me what you prefer.
(In reply to Ulrich Müller from comment #10) > (In reply to Victor from comment #9) > > Is it OK that SRC_URIs in ebuilds still point to my server[1]? I'm not 100% > > sure that it will always work 24/7 :) > > > > [1] https://enise.org/users/victor/share/distfiles/ > > That should be OK, as the files will be on the Gentoo mirror system too. > Alternatively, I could copy them to my dev space. Just tell me what you > prefer. Great, then it's more convenient to keep in when they are.
*keep them
*where
Thanks ulm. The bug ought to be assigned to the maintainer.
