Re: [gentoo-dev] Fwd: New eclass suggestion: docs.eclass
On 4/27/20 7:10 PM, Andrew Ammerlaan wrote: > Hi all, > Hey, could you please plaintext your whole patch in this thread, so it can be viewed and commented by replying? See how lanodan did. Or check: https://archives.gentoo.org/gentoo-dev/message/f2a7abcc8506ae3e56a0ebb0ea0cadc8 -- juippis signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-libs/quasselc
Upstream stopped development. This lib was only required for net-irc/quassel-irssi Bug: https://bugs.gentoo.org/719856 -- Best regards, Jonas Stein signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-irc/quassel-irssi
profiles: net-irc/quassel-irssi last rites Our package is no longer usable and would require an update by upstream which is no longer active. Last riting the unusable package now. Bug: https://bugs.gentoo.org/719728 -- Best regards, Jonas Stein signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Fwd: New eclass suggestion: docs.eclass
[2020-04-27 18:10:43+0200] Andrew Ammerlaan:
> # Copyright 1999-2020 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: docs.eclass
> # @MAINTAINER:
> # Andrew Ammerlaan
> # @AUTHOR:
> # Author: Andrew Ammerlaan
> # Based on the work of: Michał Górny
> # @SUPPORTED_EAPIS: 5 6 7
> # @BLURB: A simple eclass to build documentation.
> # @DESCRIPTION:
> # A simple eclass providing functions to build documentation.
> #
> # Please note that docs sets RDEPEND and DEPEND unconditionally
> # for you.
> #
> # This eclass also appends "doc" to IUSE, and sets HTML_DOCS
> # to the location of the compiled documentation
> #
> # The aim of this eclass is to make it easy to add additional
> # doc builders. To do this, add a -setup and
> # -build function for your doc builder.
> # For python based doc builders you can use the
> # python_append_deps function to append [${PYTHON_USEDEP}]
> # automatically to additional dependencies
> #
> # For more information, please see the Python Guide:
> # https://dev.gentoo.org/~mgorny/python-guide/
Should change this part to not be about python docs, right?
>
> case "${EAPI:-0}" in
> 0|1|2|3|4)
> die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
> ;;
> 5|6|7)
> ;;
> *)
> die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
> ;;
> esac
>
> # @ECLASS-VARIABLE: DOCBUILDER
> # @REQUIRED
> # @PRE_INHERIT
> # @DESCRIPTION:
> # Sets the doc builder to use, currently supports
> # sphinx and mkdocs
>
> # @ECLASS-VARIABLE: DOCDIR
> # @DESCRIPTION:
> # Sets the location of the doc builder config file.
Suggestion:
Path containing the doc builder config file(s).
Re: [gentoo-dev] [PSA] If you ssh interactively to git.gentoo.org (somehow) let me know.
On Mon, Apr 27, 2020 at 7:04 AM Kent Fredric wrote: > On Mon, 27 Apr 2020 09:43:44 -0400 > Mike Gilbert wrote: > > > He was replying to me. Your master connection will continue to work > > just fine, as I said in my previous message. > > I must have lost something in grammar, because no matter how many times I > read: > > > If you are authenticating that master connection as the "git" user, I > > suspect it will not affect you. If you are using it to push to > > gentoo.git, that is almost certainly the case. > > I interpret that as: > > - Anonymous fetch is fine > - Authorised Push will fail > "If you are authenticating the master connection as the 'git' user then this change will not affect you. "If you are using controlmaster to push to git.gentoo.org, then you are definitely authenticating as user=git because there is no other way to commit to ::gentoo." > > But I guess my mistake is in that we don't push with "user@git ...", we > push with "git@ ... ", and the SSH key is the gate keeper of "push will > work", not the UID. > > Right? > A working ssh key for user=git is a necessary (but not sufficient) component of a successful git push. > > So assuming you're using git@ for fetch *and* push, *then* it will > continue to work. > > Right? > Correct. > > Forgive me for any potential idiocy, language and remembering the > details of everything all the time is hard. > I don't actually expect people to know these details.
[gentoo-dev] Fwd: New eclass suggestion: docs.eclass
Hi all,
I've been working with some mkdocs-* related ebuilds, and I kept having
to do the same lines over and over again to get things to build the
documentation. Therefore, I felt that it might be useful to automate
this a bit with an eclass. However, because mkdocs is a relatively
small, I tried to write a somewhat more generic eclass that supports
multiple doc builders. So far I have added support for mkdocs, sphinx
and doxygen.
The functions are based on the `distutils_enable_sphinx` function from
the distutils-r1 eclass (but unlike the distutils function, sphinx
building also works for non-python packages in the docs eclass). The
generic parts have been stripped out and put into the generic part of
the eclass. Each doc builder has it's own _setup function to set up the
dependencies, and _compile function which calls the documentation
builder and deals with things specific to that doc builder. The rest
should be pretty self explanatory (I hope).
In my opinion it is very easy to use, e.g.:
```
DOCBUILDER="mkdocs" (or "sphinx" or "doxygen" )
DOCDEPEND="dev-python/mkdocs-material" (additional doc deps, apart from
the doc builder itself)
inherit docs
```
There are some more variables which can be set for more advanced use
cases (e.g. DOCDIR if the docs are not in ${S}), see the in-file
documentation. And see
https://gitweb.gentoo.org/repo/proj/guru.git/tree/dev-python/mkdocs-material/mkdocs-material-5.1.1.ebuild?h=dev
for an example.
I'd be very interested to hear what you all think of this eclass, and if
it would make a nice addition to ::gentoo? I'd also be interested to
hear about any other documentation builders that might be added to the
eclass (I tried to write it such that it is easy to add support for more
doc builders). (Juippis already suggested to add doxygen yesterday in
https://github.com/gentoo/gentoo/pull/15302 )
There are some mkdocs related ebuilds in the guru overlay
https://github.com/gentoo/guru that this eclass can be tested on (e.g.
mkdocs-material). Though a circular dependency prevents from setting
USE="doc" on the entire overlay (mkdocs-material depends on things,
whose documentation depends on mkdocs-material again), it is easily
resolved by first emerging those packages with USE="-doc".
I already tested this in every use case I could think of, mkdocs/sphinx
python ebuild, mkdocs non-python ebuild, doxygen ebuild, sphinx with and
without autodoc, mkdocs with and without mkautodoc, docs in a subdir.
And so far it seems to be working just fine. It's also been in the guru
overlay for quite some time already.
Please let me know if you find any issues, or potential improvements.
Best Regards,
Andrew
See Also: https://github.com/gentoo/gentoo/pull/15302
# Copyright 1999-2020 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: docs.eclass
# @MAINTAINER:
# Andrew Ammerlaan
# @AUTHOR:
# Author: Andrew Ammerlaan
# Based on the work of: Michał Górny
# @SUPPORTED_EAPIS: 5 6 7
# @BLURB: A simple eclass to build documentation.
# @DESCRIPTION:
# A simple eclass providing functions to build documentation.
#
# Please note that docs sets RDEPEND and DEPEND unconditionally
# for you.
#
# This eclass also appends "doc" to IUSE, and sets HTML_DOCS
# to the location of the compiled documentation
#
# The aim of this eclass is to make it easy to add additional
# doc builders. To do this, add a -setup and
# -build function for your doc builder.
# For python based doc builders you can use the
# python_append_deps function to append [${PYTHON_USEDEP}]
# automatically to additional dependencies
#
# For more information, please see the Python Guide:
# https://dev.gentoo.org/~mgorny/python-guide/
case "${EAPI:-0}" in
0|1|2|3|4)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
5|6|7)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
;;
esac
# @ECLASS-VARIABLE: DOCBUILDER
# @REQUIRED
# @PRE_INHERIT
# @DESCRIPTION:
# Sets the doc builder to use, currently supports
# sphinx and mkdocs
# @ECLASS-VARIABLE: DOCDIR
# @DESCRIPTION:
# Sets the location of the doc builder config file.
#
# For sphinx this is the location of "conf.py"
# For mkdocs this is the location of "mkdocs.yml"
#
# Note that mkdocs.yml often does not reside
# in the same directory as the actual doc files
#
# Defaults to ${S}
# @ECLASS-VARIABLE: DOCDEPEND
# @DEFAULT_UNSET
# @PRE_INHERIT
# @DESCRIPTION:
# Sets additional dependencies to build docs.
# For sphinx and mkdocs these dependencies should
# be specified without [${PYTHON_USEDEP}], this
# is added by the eclass. E.g. to depend on mkdocs-material:
#
# DOCDEPEND="dev-python/mkdocs-material"
#
# This eclass appends to this variable, so you can
# call it later in your ebuild again if necessary.
# @ECLASS-VARIABLE: AUTODOC
# @PRE_INHERIT
# @DESCRIPTION:
# Sets
Re: [gentoo-dev] [PSA] If you ssh interactively to git.gentoo.org (somehow) let me know.
On Mon, Apr 27, 2020 at 10:03 AM Kent Fredric wrote: > > On Mon, 27 Apr 2020 09:43:44 -0400 > Mike Gilbert wrote: > > > He was replying to me. Your master connection will continue to work > > just fine, as I said in my previous message. > > I must have lost something in grammar, because no matter how many times I > read: > > > If you are authenticating that master connection as the "git" user, I > > suspect it will not affect you. If you are using it to push to > > gentoo.git, that is almost certainly the case. > > I interpret that as: > > - Anonymous fetch is fine > - Authorised Push will fail There's no such thing as an "anonymous fetch" from git.gentoo.org. You must be authenticated to do anything. > But I guess my mistake is in that we don't push with "user@git ...", we > push with "git@ ... ", and the SSH key is the gate keeper of "push will > work", not the UID. > > Right? Correct. > So assuming you're using git@ for fetch *and* push, *then* it will > continue to work. > > Right? Correct.
Re: [gentoo-dev] [PSA] If you ssh interactively to git.gentoo.org (somehow) let me know.
On Mon, 27 Apr 2020 09:43:44 -0400 Mike Gilbert wrote: > He was replying to me. Your master connection will continue to work > just fine, as I said in my previous message. I must have lost something in grammar, because no matter how many times I read: > If you are authenticating that master connection as the "git" user, I > suspect it will not affect you. If you are using it to push to > gentoo.git, that is almost certainly the case. I interpret that as: - Anonymous fetch is fine - Authorised Push will fail But I guess my mistake is in that we don't push with "user@git ...", we push with "git@ ... ", and the SSH key is the gate keeper of "push will work", not the UID. Right? So assuming you're using git@ for fetch *and* push, *then* it will continue to work. Right? Forgive me for any potential idiocy, language and remembering the details of everything all the time is hard. pgpIucuM6gDEB.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PSA] If you ssh interactively to git.gentoo.org (somehow) let me know.
On Mon, Apr 27, 2020 at 9:13 AM Kent Fredric wrote: > > On Sun, 26 Apr 2020 18:00:19 -0700 > Alec Warner wrote: > > > This is correct. > > Surely then, this is a reduction in fuctionality. > > That's a handy tool to put up your sleeve when you're trying to avoid > getting thrashed by slow network connects when some contributor is > pushing every 30 seconds :) He was replying to me. Your master connection will continue to work just fine, as I said in my previous message.
Re: [gentoo-dev] [PSA] If you ssh interactively to git.gentoo.org (somehow) let me know.
On Sun, 26 Apr 2020 18:00:19 -0700 Alec Warner wrote: > This is correct. Surely then, this is a reduction in fuctionality. That's a handy tool to put up your sleeve when you're trying to avoid getting thrashed by slow network connects when some contributor is pushing every 30 seconds :) pgp6Hvdpu0Q9i.pgp Description: OpenPGP digital signature
[gentoo-dev] Last-rites: twisted-r1.eclass
It has no more consumers in ::gentoo tree. Removal in ~30 days. Bug: https://bugs.gentoo.org/719794 -- juippis signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH] Change BINPKG_COMPRESS default from bzip2 to xz
On Sun, 2020-04-26 at 18:23 -0400, Michael Orlitzky wrote: > On 4/26/20 3:25 PM, Ulrich Mueller wrote: > > > > > > > On Sun, 26 Apr 2020, Michael Orlitzky wrote: > > > Fuel for the fire: > > > * https://www.nongnu.org/lzip/lzip_benchmark.html > > > * https://www.nongnu.org/lzip/xz_inadequate.html > > > > Yep. That's why lzip is the dominant compression format now, and nobody > > is using xz any more. > > > > If you believed that argument, you would be using Windows =P > > Dude has GRAPHS, it must be true. > It is true but nobody cares. People managed to shove a lot of unused code into the kernel and nobody cares. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-python/asynctest
# Michał Górny (2020-04-27) # Unmaintained. Unresolved breakage with py3.8 for almost a year. # Python upstream included some async testing support in py3.8 too. # No revdeps. # Removal in 30 days. Bug #719746. dev-python/asynctest -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs: app-text/gocr
On Mon, 2020-04-27 at 01:32 +0200, Jonas Stein wrote: > Dear all > > the following packages are up for grabs after retirement > of the proxied maintainer: python@ will take the following: > dev-python/parver > dev-python/pyotp > dev-python/h11 > dev-python/pyzbar > dev-python/wsproto > dev-python/brotlipy I will last rite this one since it is broken with py3.8 and seems dead: > dev-python/asynctest -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
