[gentoo-dev] Last rites: x11-wm/stumpwm, x11-wm/stumpwm-contrib
# Arthur Zamarin (2024-05-24) # EAPI=6, fails tests, maintainer-needed, other QA fails. # Removal on 2024-06-23. Bugs #932627, #888473, #882935. x11-wm/stumpwm x11-wm/stumpwm-contrib OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: x11-plugins/pidgin-rhythmbox
# Arthur Zamarin (2024-05-23) # EAPI=6, maintainer-needed, dead HOMEPAGE, fails to compile. # Removal on 2024-06-22. Bugs #932571, #902899, #887625, #853025, #672702. x11-plugins/pidgin-rhythmbox OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-util/bitrise, dev-util/envman, dev-util/stepman
# Arthur Zamarin (2024-05-23) # Bitrise stack is abandoned in Gentoo, maintainer-needed, awaits # version bump, uses deprecated Go eclasses, EAPI=6, fails to compile # with modern C. # Removal on 2024-06-22. Bugs #932570, #844688, #717536, #771066, #844700, #844703. dev-util/bitrise dev-util/envman dev-util/stepman OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-lang/srf
# Arthur Zamarin (2024-05-18) # EAPI=6, no reverse dependencies, dead homepage, has issues # with modern C, maintainer needed. # Removal on 2024-06-17. Bugs #932168, #906348, #895028, #870640. dev-lang/srf OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-emulation/hyperd
# Arthur Zamarin (2024-05-18) # EAPI6. Fails to compile with go versions in tree. Upstream is archived. # Uses deprecated go eclasses. Maintainer needed, no rev deps. # Removal on 2024-06-17. Bugs #932166, #844604, #679832. app-emulation/hyperd OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: x11-plugins/pidgintex
# Arthur Zamarin (2024-05-17) # EAPI=6, no maintainer, fails to compile. # Removal on 2024-06-16. Bugs #932097, #542244, #742965. x11-plugins/pidgintex OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-forensics/air
# Arthur Zamarin (2024-05-17) # EAPI=6, no maintainer, fails to compile. # Removal on 2024-06-16. Bugs #932095, #768072, #47. app-forensics/air OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-emulation/docker-machine-kvm
# Arthur Zamarin (2024-05-13) # EAPI=6, fails to compile, archived upstream, uses deprecated go eclasses. # Removal: 2024-06-12. Bugs #931879, #734186. app-emulation/docker-machine-kvm OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: media-gfx/raw-thumbnailer
# Arthur Zamarin (2024-05-13) # EAPI=6, fails to compile, dead upstream, maintainer-needed. # Removal: 2024-06-12. Bugs #931874, #878771. media-gfx/raw-thumbnailer OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-libs/cifparse-obj
# Arthur Zamarin (2024-05-13) # EAPI=6, fails to compile, library with no reverse dependencies. # Removal: 2024-06-12. Bug #931861. sci-libs/cifparse-obj OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-libs/libghemical
# Arthur Zamarin (2024-05-13) # EAPI=6, fails to compile, no reverse dependencies. # Removal: 2024-06-12. Bugs #931860, #891895. sci-libs/libghemical OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-emulation/docker-machine
# Arthur Zamarin (2024-05-11) # EAPI=6, uses deprecated go eclass, archived upstream. Update to # usage of go-module.eclass isn't simple. # Removal: 2024-06-10. Bugs #931745, #844598. app-emulation/docker-machine OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-go/fuzzy, dev-go/go-bindata-assetfs, dev-go/godebug-pretty, dev-go/goversion, dev-go/sanitized-anchor-name
# Arthur Zamarin (2024-05-11) # EAPI=6, library only without any reverse dependencies, uses # deprecated go eclasses. # Removal: 2024-06-10. Bug #931725. dev-go/fuzzy dev-go/go-bindata-assetfs dev-go/godebug-pretty dev-go/goversion dev-go/sanitized-anchor-name OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-i18n/skkserv
# Arthur Zamarin (2024-04-27) # EAPI=6 package, has issues with implicit function declarations, has # issues with incompatible types and more. The only reverse dependency # is virtual/skkserv, which has other better candidates. # Removal on 2024-05-27, bug #930781 app-i18n/skkserv OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-misc/ttytter
# Arthur Zamarin (2024-04-26) # Broken and reported as such upstream. EAPI=6. # Removal: 2024-05-26. Bug #912842. net-misc/ttytter OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sys-block/megamgr
# Arthur Zamarin (2024-04-20) # EAPI6 package, with no reverse dependencies. Not really maintained # since gentoo's transition to git. Distfile is fetch and mirror # restricted, and based on comment in ebuild, the source isn't stable # and we can lose the only source for distfile. # Removal on 2024-05-20, bug #930346. sys-block/megamgr OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-go/qr, dev-go/twofactor
# Arthur Zamarin (2024-04-19) # EAPI=6, library only without any reverse dependencies, uses # deprecated go eclasses, maintainer-needed. # Removal on 2024-05-19, bug #930249 dev-go/qr dev-go/twofactor OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-emulation/runv
# Arthur Zamarin (2024-04-12) # EAPI6. Fails to compile with go versions in tree. Upstream is # archived. Uses deprecated go eclasses. Maintainer needed, no # rev deps. # Removal: 2024-05-12. Bugs #794913, #679348, #771072, #844607. app-emulation/runv OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH 2/2] tree-sitter-grammar.eclass: support opt in python bindings
New tree-sitter cli generated bindings and code around grammars and
parsers now support bulding a python wheel which supply much better
API and library for consumers in python bindings.
Currently I've added only python as a binding languages, even though
rust, swift, and go are also available. We should add them when we
see a request for them. Python will be needed for pkgcheck.
When we opt in into python bindings, we call the matching distutils
phase functions when `use python` is true.
Signed-off-by: Arthur Zamarin
---
eclass/tree-sitter-grammar.eclass | 85 ++-
1 file changed, 84 insertions(+), 1 deletion(-)
diff --git a/eclass/tree-sitter-grammar.eclass
b/eclass/tree-sitter-grammar.eclass
index 13539daf7e6..b04d5ee1103 100644
--- a/eclass/tree-sitter-grammar.eclass
+++ b/eclass/tree-sitter-grammar.eclass
@@ -36,6 +36,43 @@ RESTRICT+=" !test? ( test )"
# Used to override upstream tag name if tagged differently, e.g. most releases
# are v${PV} but some are tagged as rust-${PV}.
+# @ECLASS_VARIABLE: TS_BINDINGS
+# @PRE_INHERIT
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Array of bindings language to build. Currently only "python" is supported.
+
+for _BINDING in "${TS_BINDINGS[@]}"; do
+ case ${_BINDING} in
+ python)
+ DISTUTILS_EXT=1
+ DISTUTILS_OPTIONAL=1
+ DISTUTILS_USE_PEP517=setuptools
+ PYTHON_COMPAT=( python3_{10..12} )
+ inherit distutils-r1
+
+ IUSE+=" python"
+ REQUIRED_USE+=" python? ( ${PYTHON_REQUIRED_USE} )"
+
+ DEPEND+=" python? (
+ ${PYTHON_DEPS}
+ )"
+ RDEPEND+=" python? (
+ ${PYTHON_DEPS}
+
>=dev-python/tree-sitter-0.21.0[${PYTHON_USEDEP}]
+ )"
+ BDEPEND+=" python? (
+ ${DISTUTILS_DEPS}
+ dev-python/wheel[${PYTHON_USEDEP}]
+ )"
+ ;;
+ *)
+ die "Unknown binding: ${_BINDING}"
+ ;;
+ esac
+done
+unset _BINDING
+
# @FUNCTION: _get_tsg_abi_ver
# @INTERNAL
# @DESCRIPTION:
@@ -49,6 +86,34 @@ _get_tsg_abi_ver() {
die "Unable to extract ABI version for this grammar"
}
+tree-sitter-grammar_src_prepare() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ default
+
+ local binding
+ for binding in "${TS_BINDINGS[@]}"; do
+ case ${binding} in
+ python)
+ use python && distutils-r1_src_prepare
+ ;;
+ esac
+ done
+}
+
+tree-sitter-grammar_src_configure() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ local binding
+ for binding in "${TS_BINDINGS[@]}"; do
+ case ${binding} in
+ python)
+ use python && distutils-r1_src_configure
+ ;;
+ esac
+ done
+}
+
# @FUNCTION: _tree-sitter-grammar_legacy_compile
# @INTERNAL
# @DESCRIPTION:
@@ -102,6 +167,15 @@ tree-sitter-grammar_src_compile() {
else
_tree-sitter-grammar_legacy_compile
fi
+
+ local binding
+ for binding in "${TS_BINDINGS[@]}"; do
+ case ${binding} in
+ python)
+ use python && distutils-r1_src_compile
+ ;;
+ esac
+ done
}
# @FUNCTION: tree-sitter-grammar_src_test
@@ -131,8 +205,17 @@ tree-sitter-grammar_src_install() {
dolib.so "${WORKDIR}/${soname}"
dosym "${soname}" /usr/$(get_libdir)/lib${PN}$(get_libname)
fi
+
+ local binding
+ for binding in "${TS_BINDINGS[@]}"; do
+ case ${binding} in
+ python)
+ use python && distutils-r1_src_install
+ ;;
+ esac
+ done
}
fi
-EXPORT_FUNCTIONS src_compile src_test src_install
+EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install
--
2.44.0
[gentoo-dev] [PATCH 1/2] tree-sitter-grammar.eclass: support for new upstream makefile
The build system for tree-sitters now generates a much better
Makefile we can use to build the parser and grammar into a good C
library.
This also matches the build procedure used by upstream, making our
reports easier for them to debug (we hit this issue in an old bug
report on memory leak with tree-sitter-bash).
Signed-off-by: Arthur Zamarin
---
eclass/tree-sitter-grammar.eclass | 64 +--
1 file changed, 43 insertions(+), 21 deletions(-)
diff --git a/eclass/tree-sitter-grammar.eclass
b/eclass/tree-sitter-grammar.eclass
index b2563220cfc..13539daf7e6 100644
--- a/eclass/tree-sitter-grammar.eclass
+++ b/eclass/tree-sitter-grammar.eclass
@@ -1,10 +1,11 @@
-# Copyright 1999-2023 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: tree-sitter-grammar.eclass
# @MAINTAINER:
# Matthew Smith
# Nick Sarnie
+# Arthur Zamarin
# @AUTHOR:
# Matthew Smith
# @SUPPORTED_EAPIS: 8
@@ -22,7 +23,7 @@ inherit edo multilib toolchain-funcs
SRC_URI="https://github.com/tree-sitter/${PN}/archive/${TS_PV:-v${PV}}.tar.gz
-> ${P}.tar.gz"
-S="${WORKDIR}"/${PN}-${TS_PV:-${PV}}/src
+S="${WORKDIR}"/${PN}-${TS_PV:-${PV}}
BDEPEND+=" test? ( dev-util/tree-sitter-cli )"
IUSE+=" test"
@@ -44,15 +45,16 @@ _get_tsg_abi_ver() {
# This sed script finds ABI definition string in parser source file,
# substitutes all the string until the ABI number, and prints remains
# (the ABI number itself)
- sed -n 's/#define LANGUAGE_VERSION //p' "${S}"/parser.c ||
+ sed -n 's/#define LANGUAGE_VERSION //p' "${S}"/src/parser.c ||
die "Unable to extract ABI version for this grammar"
}
-# @FUNCTION: tree-sitter-grammar_src_compile
+# @FUNCTION: _tree-sitter-grammar_legacy_compile
+# @INTERNAL
# @DESCRIPTION:
-# Compiles the Tree Sitter parser as a shared library.
-tree-sitter-grammar_src_compile() {
- debug-print-function ${FUNCNAME} "${@}"
+# Compiles the Tree Sitter parser as a shared library, the legacy way.
+_tree-sitter-grammar_legacy_compile() {
+ cd "${S}/src" || die
# Grammars always contain parser.c, and sometimes a scanner.c,
# or scanner.cc.
@@ -60,17 +62,17 @@ tree-sitter-grammar_src_compile() {
tc-export CC CXX
# We want to use the bundled parser.h, not anything lurking on the
system, hence -I
# See
https://github.com/tree-sitter/tree-sitter-bash/issues/199#issuecomment-1694416505
- export CFLAGS="${CFLAGS} -fPIC -I. -Itree_sitter"
- export CXXFLAGS="${CXXFLAGS} -fPIC -I. -Itree_sitter"
+ local -x CFLAGS="${CFLAGS} -fPIC -I. -Itree_sitter"
+ local -x CXXFLAGS="${CXXFLAGS} -fPIC -I. -Itree_sitter"
local objects=( parser.o )
- if [[ -f "${S}"/scanner.c || -f "${S}"/scanner.cc ]]; then
+ if [[ -f "${S}"/src/scanner.c || -f "${S}"/src/scanner.cc ]]; then
objects+=( scanner.o )
fi
emake "${objects[@]}"
local link="$(tc-getCC) ${CFLAGS}"
- if [[ -f "${S}/scanner.cc" ]]; then
+ if [[ -f "${S}/src/scanner.cc" ]]; then
link="$(tc-getCXX) ${CXXFLAGS}"
fi
@@ -84,10 +86,24 @@ tree-sitter-grammar_src_compile() {
edo ${link} ${LDFLAGS} \
-shared \
*.o \
- ${soname_args} \
+ "${soname_args}" \
-o "${WORKDIR}"/${soname}
}
+tree-sitter-grammar_src_compile() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ # legacy grammars don't have a pyproject.toml
+ if [[ -f "${S}/pyproject.toml" ]]; then
+ sed -e "/SONAME_MINOR :=/s/:=.*$/:= $(_get_tsg_abi_ver)/" -i
"${S}/Makefile" || die
+ emake \
+ PREFIX="${EPREFIX}/usr" \
+ LIBDIR="${EPREFIX}/usr/$(get_libdir)"
+ else
+ _tree-sitter-grammar_legacy_compile
+ fi
+}
+
# @FUNCTION: tree-sitter-grammar_src_test
# @DESCRIPTION:
# Runs the Tree Sitter parser's test suite.
@@ -95,20 +111,26 @@ tree-sitter-grammar_src_compile() {
tree-sitter-grammar_src_test() {
debug-print-function ${FUNCNAME} "${@}"
- (cd .. && tree-sitter test) || die "Test suite failed"
+ tree-sitter test || die "Test suite failed"
}
-# @FUNCTION: tree-sitter-grammar_src_install
-# @DESCRIPTION:
-# Installs the Tree Sitter parser library.
tree-sitter-grammar_src_install() {
debug-print-function ${FUNCNAME} "${@}"
- local soname=lib${PN}$(get_libn
[gentoo-dev] tree-sitter-grammar.eclass: support new upstream bindings
In latest tree-sitter, we now have much better build system (a good Makefile!), and much nicer to use python bindings per language. So add support for them in the eclass, being mostly backwards compatible with previous eclass (in the PR there are more commits which fix all broken stuff). Pull request: https://github.com/gentoo/gentoo/pull/35750
[gentoo-dev] Last rites: dev-libs/yascreen
# Arthur Zamarin (2024-03-08) # A library without reverse dependencies. # Removal on: 2024-04-07. Bug #926486. dev-libs/yascreen OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
On 27/02/2024 16.45, Michał Górny wrote:
> Hello,
>
> Given the recent spread of the "AI" bubble, I think we really need to
> look into formally addressing the related concerns. In my opinion,
> at this point the only reasonable course of action would be to safely
> ban "AI"-backed contribution entirely. In other words, explicitly
> forbid people from using ChatGPT, Bard, GitHub Copilot, and so on, to
> create ebuilds, code, documentation, messages, bug reports and so on for
> use in Gentoo.
>
> Just to be clear, I'm talking about our "original" content. We can't do
> much about upstream projects using it.
I support this motion.
>
> Rationale:
>
> 1. Copyright concerns. At this point, the copyright situation around
> generated content is still unclear. What's pretty clear is that pretty
> much all LLMs are trained on huge corpora of copyrighted material, and
> all fancy "AI" companies don't give shit about copyright violations.
> In particular, there's a good risk that these tools would yield stuff we
> can't legally use.
I know that GitHub Copilot can be limited to licenses, and even to just
the current repository. Even though, I'm not sure that the copyright can
be attributed to "me" and not the "AI" - so still gray area.
> 2. Quality concerns. LLMs are really great at generating plausibly
> looking bullshit. I suppose they can provide good assistance if you are
> careful enough, but we can't really rely on all our contributors being
> aware of the risks.
Let me tell a story. I was interested if I can teach an LLM the ebuild
format, as a possible helper tool for devs/non-devs. My prompt got so
huge, where I was teaching it all the stuff of ebuilds, where to input
the source code (eclasses), and such. At one point, it even managed to
output a close enough python distutils-r1 ebuild - the same level that
`vim dev-python/${PN}/${PN}-${PV}.ebuild` creates using the gentoo
template. Yes, my long work resulted in no gain.
For each other ebuild type: cmake, meson, go, rust - I always got
garbage ebuild. Yes, it was generating a good DESCRIPTION and HOMEPAGE
(simple stuff to copy from upstream) and even 60% accuracy for LICENSE.
But did you know we have "intel80386" arch for KEYWORDS? We can
RESTRICT="install"? We can use "^cat-pkg/pkg-1" syntax in deps? PATCHES
with http urls inside? And the list goes on. Sometimes it was even funny.
So until a good prompt can be created for gentoo, upon which we *might*
reopen discussion, I'm strongly supporting banning AI generating
ebuilds. Currently good templates per category, and just copying other
ebuilds as starting point, and even just skel.ebuild - all those 3
options bring much better result and less time waste for developers.
> 3. Ethical concerns. As pointed out above, the "AI" corporations don't
> give shit about copyright, and don't give shit about people. The AI
> bubble is causing huge energy waste. It is giving a great excuse for
> layoffs and increasing exploitation of IT workers. It is driving
> enshittification of the Internet, it is empowering all kinds of spam
> and scam.
>
Many companies who use AI as reason for layoff are just creating a
reasoning out of bad will, or ignorance. The company I work at is using
AI tools as a boost for productivity, but at all levels of management
they know that AI can't replace a person - best case boost him 5-10%.
The current real reason for layoffs is tightening of budget movement
cross the industry (just a normal cycle, soon it would get better), so
management prefer to layoff not themselves. So yeah, sad world.
>
> Gentoo has always stood out as something different, something that
> worked for people for whom mainstream distros were lacking. I think
> adding "made by real people" to the list of our advantages would be
> a good thing — but we need to have policies in place, to make sure shit
> doesn't flow in.
>
> Compare with the shitstorm at:
> https://github.com/pkgxdev/pantry/issues/5358
>
Great read, really much WTF. This whole repo is just a cluster of AIs
competing against each other.
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-libs/zlog
# Arthur Zamarin (2024-02-23) # A library without any reverse dependencies in tree. Maintainer-needed # package. Has open security bug without handling. Has open bump for a # long time. # Removal: 2024-03-24. Bugs #925342, #837518. dev-libs/zlog OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] pkgcheck scan: error: failed running git log: fatal: unrecognized argument: --no-find-copies
On 16/02/2024 18.51, Andrey Grozin wrote: > I'm trying to bump master-pdf-editor and get > > grozin@bilbo /home/gentoo/app-text/master-pdf-editor $ pkgcheck scan > pkgcheck scan: error: failed running git log: fatal: unrecognized > argument: --no-find-copies > grozin@bilbo /home/gentoo/app-text/master-pdf-editor $ pkgdev commit -m > 'bump to 5.9.82' > pkgdev commit: error: failed running git log: fatal: unrecognized > argument: --no-find-copies > grozin@bilbo /home/gentoo/app-text/master-pdf-editor $ > > What has happened with pkgcheck scan? > > Andrey > Happened with today's bump to dev-vcs/git [1]. Please downgrade git until I fix pkgcheck (currently v2.43.2 got masked [2] cause of this reason). [1] https://bugs.gentoo.org/924718 [2] https://packages.gentoo.org/packages/dev-vcs/git -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU) OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/empy
# Arthur Zamarin (2023-11-10) # No reverse dependencies, no tests, no upstream activity. All ebuild # maintenance on this package was done randomly by @python project members, # at late stage of python porting, which is hard with no tests. # Removal on 2023-12-10. Bug #917124. dev-python/empy OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] [DRAFT v3] GLEP 84: Standard format for package.mask files
This is the third version of the GLEP after previous recommendations
and suggestions [1] - thank you for all who participated. Similar to
previously, the draft can also be found on glep-0084 branch [2].
[1] https://public-inbox.gentoo.org/gentoo-dev/uzg0mq...@gentoo.org/T/
[2] https://gitweb.gentoo.org/data/glep.git/tree/glep-0084.rst?h=glep-0084
---
GLEP: 84
Title: Standard format for package.mask files
Author: Arthur Zamarin
Type: Standards Track
Status: Draft
Version: 1.0
Created: 2023-11-01
Content-Type: text/x-rst
---
Abstract
This GLEP specifies the format of ``package.mask`` files under profiles
directory.
Motivation
==
At the moment of writing this GLEP, ``package.mask`` files didn't have a full
format specification. While PMS sections 4.4 [#PMS-4.4]_ and 5.2.8
[#PMS-5.2.8]_ specifies the raw format which the package manager must support
for correct behavior, it does not specify how comments must be formatted, how
entries must be grouped, how last-rite masks should be written, etc.
Various tools have been developed to handle that mask message. A non exhaustive
list includes ``lr-add-pmask`` [#lr-add-pmask]_, ``pkgdev mask``
[#pkgdev-mask]_,
and ``soko`` [#soko-mask]_. Those tools have different purposes, filing a new
mask message with all relevant information, and showing a nice rendered mask
message to users. Those tools are very complicated (since they need to handle
various edge cases of existing masks, and try to prepare for future mask
messages).
For a long time, ``profiles/package.mask`` had a special header [#CURR-MASK]_
whose purpose was to define the mask message formatting. While it has served
its purpose for a long time indeed, it still left a lot of wiggle room for the
message.
Therefore, the motivation for this GLEP is to provide unified, clear and
complete specification for package.mask entries across the repository.
Specification
=
Header
--
As an opt-in GLEP for files, files which want to use this GLEP format should
define a special header line which tools should use to know the format of the
file. This line should appear as the first non empty line after the copyright
header. The line should be:
# Uses GLEP 84 format
This header should come instead of the current very long header [#CURR-MASK]_,
as mentioning the GLEP is enough.
Files can decide to add some extra file documentation, in which case, the
entries start after the first separation line comment which begins and ends
with at least 5 "-", matching to the regex:
# -{5,}.*-{5,}
All comments before the first occurrence of this separation line comment are
ignored, and should be considered as file documentation. Another separation
line may appear, after which all comments are also ignored. Those separation
lines are optional, and are not required for the file to conform to this GLEP.
Entries Grouping
Each mask entry consists of 2 parts: `comments block`_ and `packages list`_,
which aren't separated by a blank line between the 2 parts. Between entries, a
mandatory blank line must appear.
New entries added to the file must be inserted at the beginning, after the file
header.
Packages List
-
Must conform to PMS sections 4.4 [#PMS-4.4]_ and 5.2.8 [#PMS-5.2.8]_. This GLEP
further limits the syntax to one item per line, without any leading or trailing
whitespace, no comments inside the packages list. Blank lines between items are
allowed.
Comments Block
--
The lines in the comment block are prefixed with a "#" symbol. The comments
should be separated with single space from the "#", unless this is trailing
whitespace, in which case it should be removed (meaning blank lines in comments
block are just "#\n").
The comments block consists of 2 mandatory parts (`author line`_ and
`explanation`_) and one optional part (`last-rite epilogue`_). A blank line to
separate the parts is optional. Trailing whitespace should be dropped.
The lines of the comments block should use column wrapping of 80 characters
(including the "#" prefix). The author line is excluded from this maximum
width.
For simplifying the explanation, we wouldn't mention the "#" prefix.
Implementations are advised to drop this prefix before further processing the
block.
Author Line
'''
A line of the format: ``${AUTHOR-NAME} <${EMAIL}> (${SINGLE-DATE})``. The author
name and email should correspond to the mask author, and should confirm to the
GLEP 76 rules. The date should be of RFC-3339 full-date format, meaning
``-MM-DD``. The date is recommended to use the date at UTC timezone at the
moment of commit push.
Explanation
'''
In this block the reasons for the mask should be listed, with extra explanation
where needed. If referencing bugs, use the `bugs list`_ format (mask rendering
tools should render mentioned bugs also in this part).
In this part, a paragraph separator is a bl
[gentoo-dev] Using RST for eclassdoc
Hi all For a very long time, we had a WIP branch for pkgcore [1], where I tried to implement parsing of eclassdoc, and convert them to devbook (the format used by devmanual), which the devmanual [2] then would convert to html using the normal converter used there. So, why was this wanted and what happened since? History Our eclassdocs consist of special tags (such as "@INTERNAL" and "@DESCRIPTION") which represent various information. The free-text part is without real rules on formattinf, meaning we can't really say "this is code", "bold this text", "this is a numeric list", "this is bullet list". We have used various hacks and stuff, and it worked mostly. There was a complicated tool which converted those eclassdoc into man page, and then the man page was converted to html. On 2022-05, I was requested to investigate the possibility of using pkgcore for preparing those files, with selection of RST as the formatting syntax. I've managed to do it and it worked, with also a possibility for pkgcore generating the man pages. But as expected, we had various eclasses whose eclassdoc wasn't exactly matching, and also various eclass' format could be improved. I've worked on it at the PR [3], but for the huge take of verifying all eclasses, I tired it out. Yes, this was a mistake on my part. To see the state where we can get and why, look at my devspace [4] to see the result for the very old PR [3]. - Current state - I've merged into pkgcore the devbook code generator. You need pkgcore- for that. You need my changes to the build of devmanual at [2]. We need to declare that from now on eclassdoc uses RST format, so at least future changes would not break us. I'll again say that RST isn't too far from what we used today, so this isn't a big change. Maybe this should be put in a GLEP? We need to fix the eclassdoc of the "broken eclasses". I've attached a file listed all of them. Just run `make` on the devmanual and you can see in the relevant eclass html file a warning box with the issue. Most of the time it is adding `` for marking it as code. [1] https://github.com/pkgcore/pkgcore/pull/346 [2] https://github.com/gentoo/devmanual/pull/317 [3] https://github.com/gentoo/gentoo/pull/27646 [4] https://dev.gentoo.org/~arthurzam/devmanual/eclass-reference/index.html -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, pkgcore stack, Arch Teams)alternatives.eclass apache-2.eclass apache-module.eclass autotools.eclass bazel.eclass check-reqs.eclass cmake.eclass common-lisp-3.eclass cvs.eclass distutils-r1.eclass dotnet-pkg.eclass elisp.eclass flag-o-matic.eclass ghc-package.eclass git-r3.eclass gnome2-utils.eclass golang-vcs-snapshot.eclass go-module.eclass haskell-cabal.eclass java-ant-2.eclass java-osgi.eclass java-pkg-simple.eclass java-utils-2.eclass kernel-build.eclass latex-package.eclass linux-info.eclass linux-mod-r1.eclass lua.eclass lua-single.eclass mate.eclass mercurial.eclass mozlinguas-v2.eclass multilib-build.eclass pax-utils.eclass perl-functions.eclass perl-module.eclass postgres-multi.eclass prefix.eclass python-any-r1.eclass python-r1.eclass python-single-r1.eclass qt6-build.eclass ruby-ng.eclass ruby-single.eclass rust-toolchain.eclass secureboot.eclass stardict.eclass subversion.eclass systemd.eclass toolchain-funcs.eclass verify-sig.eclass versionator.eclass vim-spell.eclass webapp.eclass xdg-utils.eclass OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [DRAFT v2] GLEP 84: Standard format for package.mask files
On 13/10/2023 21.42, Ulrich Mueller wrote:
>
>> BUGS-LIST::= [Bb]ugs? #\d+(,? +#\d+)*
>
> Make this one either "[Bb]ugs? #\d+(,? #\d+)*" (which I'd prefer)
> or "[Bb]ugs? +#\d+(,? +#\d+)*". That is, same number of spaces in both
> locations.
OK, would be hard to define it correctly in the BNF, but will just use
{n} syntax to pass the intent, and explain in English what you said here
(same amount of spaces between "things", with preferred n=1.
>> LAST-RITE::= Removal on {DATE}[.,]? +{BUGS-LIST}.?
>
> Looks good. Adding " *" at the end won't harm, in case someone will
> leave spurious whitespace at the end of the line.
Well, earlier we prohibit trailing whitespace, so it would indeed bring
harm xD
> Ulrich
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [DRAFT v2] GLEP 84: Standard format for package.mask files
On 13/10/2023 21.49, Ulrich Mueller wrote:
>>>>>> On Fri, 13 Oct 2023, Arthur Zamarin wrote:
>
>> PKGS_GROUP ::= {ATOM}(\n{ATOM})*
>
> Sorry, I had missed this when reading it the first time. Please avoid
> the term "atom" because neither PMS nor the Devmanual calls them so.
Oh, sorry, normal jargon from pkgcore work. How to call correctly here
any package specification without use dep?
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [DRAFT v2] GLEP 84: Standard format for package.mask files
On 13/10/2023 19.06, Ulrich Mueller wrote:
>>>>>> On Fri, 13 Oct 2023, Arthur Zamarin wrote:
>
>> Comments Block
>> --
>
>> The comments block consists of 2 mandatory parts (`author line`_ and
>> `explanation`_) and one optional part (`last-rite epilogue`_). A blank line
>> to
>> separate the parts is optional. Trailing whitespace should be dropped.
>
>> The lines in the comment block are prefixed with a "#" symbol. The comments
>> should be separated with single space from the "#", unless this is trailing
>> whitespace, in which case it should be removed (meaning blank lines in
>> comments
>> block are just "#\n").
>
> Maybe flip these two paragraphs? Otherwise it is not entirely clear
> whether the "blank line" mentioned in the first paragraph refers to a
> true blank line, or to a line consisting of a single number sign.
I agree with you.
>> The paragraph should be of format ``Removal on ${DATE}. ${BUGS-LIST}``, where
>> the date is RFC-3339 full-date format, meaning ``-MM-DD``, and the bugs
>> list is of the `bugs list`_ format. The listed bugs should include the
>> last-rite bug opened, and potentially more relevant bugs which weren't listed
>> in the explanation paragraphs.
>
> Does this mean that only the first of the following entries would be
> valid?
>
> # Removal on 2023-11-13. Bugs #678901, #890123
> # Removal on 2023-11-13, bugs #678901, #890123.
> # Removal on 2023-11-13. Bugs #678901 #890123
>
> IMHO that would be too restrictive. Punctuation shouldn't be significant
> there. (This doesn't preclude _recommending_ one of the variants.)
Your current interpretation was correct. My main goal is to define a
"precise" format, so it easy to parse for render of mask (i.e. soko). I
also think we have nothing to gain from allowing "," instead of "."
after removal date, but not that I care. Same for bugs-list, I'm fine
with making the "," optional, but I want us to define a "precise regex"
so we have consistent format for important bits of mask message. Does
this seem good enough for you?
BUGS-LIST::= [Bb]ugs? #\d+(,? +#\d+)*
LAST-RITE::= Removal on {DATE}[.,]? +{BUGS-LIST}.?
> Ulrich
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature.asc
Description: OpenPGP digital signature
[gentoo-dev] [DRAFT v2] GLEP 84: Standard format for package.mask files
This is the second version of the GLEP after previous recommendations
and suggestions [1] - thank you for all who participated. Similar to
previously, the draft can also be found on glep-0084 branch [2].
[1] https://public-inbox.gentoo.org/gentoo-dev/u5y3ky...@gentoo.org/T/
[2] https://gitweb.gentoo.org/data/glep.git/tree/glep-0084.rst?h=glep-0084
---
GLEP: 84
Title: Standard format for package.mask files
Author: Arthur Zamarin
Type: Standards Track
Status: Draft
Version: 1.0
Created: 2023-10-13
Content-Type: text/x-rst
---
Abstract
This GLEP specifies the format of ``package.mask`` files under profiles
directory.
Motivation
==
At the moment of writing this GLEP, ``package.mask`` files didn't have a full
format specification. While PMS sections 4.4 [#PMS-4.4]_ and 5.2.8
[#PMS-5.2.8]_ specifies the raw format which the package manager must support
for correct behavior, it does not specify how comments must be formatted, how
entries must be grouped, how last-rite masks should be written, etc.
Various tools have been developed to handle that mask message. A non exhaustive
list includes ``lr-add-pmask`` [#lr-add-pmask]_, ``pkgdev mask``
[#pkgdev-mask]_,
and ``soko`` [#soko-mask]_. Those tools have different purposes, filing a new
mask message with all relevant information, and showing a nice rendered mask
message to users. Those tools are very complicated (since they need to handle
various edge cases of existing masks, and try to prepare for future mask
messages).
For a long time, ``profiles/package.mask`` had a special header [#CURR-MASK]_
whose purpose was to define the mask message formatting. While it has served
its purpose for a long time indeed, it still left a lot of wiggle room for the
message.
Therefore, the motivation for this GLEP is to provide unified, clear and
complete specification for package.mask entries across the repository.
Specification
=
Header
--
As an opt-in GLEP for files, files which want to use this GLEP format should
define a special header line which tools should use to know the format of the
file. This line should appear as the first non empty line after the copyright
header. The line should be:
# Uses GLEP 84 format
This header should come instead of the current very long header [#CURR-MASK]_,
as mentioning the GLEP is enough.
Files can decide to add some extra file documentation, in which case, the
entries start after the first separation line comment which begins and ends
with at least 5 "-", matching to the regex:
# -{5,}.*-{5,}
All comments before the first occurrence of this separation line comment are
ignored, and should be considered as file documentation. Another separation
line may appear, after which all comments are also ignored. Those separation
lines are optional, and are not required for the file to conform to this GLEP.
Entries Grouping
Each mask entry consists of 2 parts: `comments block`_ and `packages list`_,
which aren't separated by a blank line between the 2 parts. Between entries, a
mandatory blank line must appear.
New entries added to the file must be inserted at the beginning, after the file
header.
Packages List
-
Must conform to PMS sections 4.4 [#PMS-4.4]_ and 5.2.8 [#PMS-5.2.8]_. This GLEP
further limits the syntax to one item per line, without any leading or trailing
whitespace, no comments inside the packages list. Blank lines between items are
allowed.
Comments Block
--
The comments block consists of 2 mandatory parts (`author line`_ and
`explanation`_) and one optional part (`last-rite epilogue`_). A blank line to
separate the parts is optional. Trailing whitespace should be dropped.
The lines in the comment block are prefixed with a "#" symbol. The comments
should be separated with single space from the "#", unless this is trailing
whitespace, in which case it should be removed (meaning blank lines in comments
block are just "#\n").
The lines of the comments block should use column wrapping of 80 characters
(including the "#" prefix). The author line is excluded from this maximum
width.
For simplifying the explanation, we wouldn't mention the "#" prefix.
Implementations are advised to drop this prefix before further processing the
block.
Author Line
'''
A line of the format: ``${AUTHOR-NAME} <${EMAIL}> (${SINGLE-DATE})``. The author
name and email should correspond to the mask author, and should confirm to the
GLEP 76 rules. The date should be of RFC-3339 full-date format, meaning
``-MM-DD``. The date is recommended to use the date at UTC timezone at the
moment of commit push.
Explanation
'''
In this block the reasons for the mask should be listed, with extra explanation
where needed. If referencing bugs, use the `bugs list`_ format (mask rendering
tools should render mentioned bugs also in this part).
In this part, a paragraph separator is a bl
Re: [gentoo-dev] [DRAFT] GLEP 84: Standard format for package.mask files
On 05/10/2023 06.12, Michał Górny wrote: > On Wed, 2023-10-04 at 21:43 +0300, Arthur Zamarin wrote: >> Specification >> = >> >> ... >> >> Must conform to PMS sections 4.4 [#PMS-4.4]_ and 5.2.8 [#PMS-5.2.8]_. This >> GLEP >> further limits the syntax to one item per line, without any leading or >> proceeding whitespaces, no comments inside the packages list, and no blank >> lines between items in the list. > > That kinda sucks. For very long masks, it is useful to be able to split > the entry into subgroups. I suppose it's technically still doable via > splitting the entry but that sounds a bit backwards. > Good point. I'll update the draft to allow single blank lines between package lists, but I'll still add recommendation to consider splitting into multiple separate masks. -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU) OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [DRAFT] GLEP 84: Standard format for package.mask files
On 05/10/2023 21.40, Ulrich Mueller wrote:
>>>>>> On Wed, 04 Oct 2023, Arthur Zamarin wrote:
>
>> Files can decide to add some extra file documentation, in which case, the
>> entries start after the line:
>
>> #--- END OF EXAMPLES ---
>
> This agrees with current package.mask, but seems rather specific.
> Instead of reinventing the wheel, maybe a "scissors line" could be used,
> i.e. a line consisting mainly of "-", ">8" and "8<", similar to the line
> used by git-mailinfo?
>
> I'm also wondering if we shouldn't have a similar marker for the end of
> the mask entries, i.e. everything after it would be ignored. This isn't
> currently needed for package.mask, but other files in profiles have an
> Emacs local variables block or a Vim modeline at the end.
>
> Ulrich
After fast discussion on #gentoo-dev IRC between me and ulm, we agreed
that the "scissors line" from git-mailinfo would be very overkill and
also very complicated to implement.
So we agreed on something simpler and good enough. Comment line
containing at least 5 "-" on beginning and end. As regex:
# -{5,}.*-{5,}
All lines before first occurrence of such line (except the GLEP header
to opt in) are ignored as generic comments not part of mask, and all
lines after second occurrence (if exists) are also ignored.
Those lines are optional, which does mean that implementation should
firstly filter out the ignored part (before first time if found, and
after second time if found), and only that part parse. This means
implementing it as a straight stream is much-much harder, but since the
file are never very big, I think it won't impact performance to perform
multiple text runs.
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [DRAFT] GLEP 84: Standard format for package.mask files
On 05/10/2023 06.12, Michał Górny wrote:
> "Block" in two meanings, confusing.
Thanks for the improvements, I'll apply them soon on the branch, and
send as DRAFT v2 when some more changes collect.
>
>> explanation where needed. If referencing bugs, use the `bugs list`_ format
>> (mask rendering tools should render mentioned bugs also in this part).
>>
>> In this part, a paragraph separator is a blank line, similar to
>> ReStructuredText
>> format. Using multiple blank lines between paragraphs is prohibited.
>>
>> Last-Rite Epilogue
>> ''
>>
>> If the last paragraph starts with "Removal after", then this mask entry is
>> considered as last-rite mask, and the last paragraph must conform to the
>> last-rite epilogue format.
>
> This is inconsistent with the current usage, and confusing. "After"
> makes it unclear whether the list is inclusive (i.e. "remove on that day
> or later") or exclusive ("remove the next day or later"),
> and in the latter case it's quite backwards.
>
Hmm, I don't really care what word we use here, but I do want us to
agree on one word (cause I'll need to update `pkgdev mask`). Some of the
considerations against "on" (currently used) is the fact: does it mean
it isn't fine to remove after it?
Does English has a nice word for ">= time"?
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature.asc
Description: OpenPGP digital signature
[gentoo-dev] [DRAFT] GLEP 84: Standard format for package.mask files
Hi all
As result of the discussion on gentoo-dev ML [1], I've been working on a
GLEP for the standard format for package.mask files. I've tried to
incorporate all the things spoken on that thread.
Currently this GLEP draft can be found on the glep-0084 branch [2].
Please also note that English isn't my first language (and also not
second), so if you think any paragraph isn't quite readable or simple to
understand, feel free to suggest improvements - nothing will be taken as
offense.
As noted in the draft, some of the TODOs is implementing this GLEP in
pkgcheck, pkgdev, and soko. I know that implementing the GLEP isn't a
requirement to accept the GLEP, but this should be simple enough and
should show the GLEP is mature enough.
[1]
https://public-inbox.gentoo.org/gentoo-dev/b2a2515f-8c1e-4422-8cec-cd4fe3a47...@gentoo.org/T/#u
[2] https://gitweb.gentoo.org/data/glep.git/tree/glep-0084.rst?h=glep-0084
---
GLEP: 84
Title: Standard format for package.mask files
Author: Arthur Zamarin
Type: Standards Track
Status: Draft
Version: 1.0
Created: 2023-09-30
Content-Type: text/x-rst
---
Abstract
This GLEP specifies the format of ``package.mask`` files under profiles
directory.
Motivation
==
At the moment of writing this GLEP, ``package.mask`` files didn't have a full
format specification. While PMS sections 4.4 [#PMS-4.4]_ and 5.2.8
[#PMS-5.2.8]_ specifies the raw format which the package manager must support
for correct behavior, it does not specify how comments must be formatted, how
entries must be grouped, how last-rite masks should be written, etc.
Various tools have been developed to handle that mask message. A non exhaustive
list includes ``lr-add-pmask`` [#lr-add-pmask]_, ``pkgdev mask``
[#pkgdev-mask]_,
and ``soko`` [#soko-mask]_. Those tools have different purposes, filing a new
mask message with all relevant information, and showing a nice rendered mask
message to users. Those tools are very complicated (since they need to handle
various edge cases of existing masks, and try to prepare for future mask
messages).
For a long time, ``profiles/package.mask`` had a special header [#CURR-MASK]_
whose purpose was to define the mask message formatting. While it has served
its purpose for a long time indeed, it still left a lot of wiggle room for the
message.
Therefore, the motivation for this GLEP is to provide unified, clear and
complete specification for package.mask entries across the repository.
Specification
=
Header
--
As an opt-in GLEP for files, files which want to use this GLEP format should
define a special header line which tools should use to know the format of the
file. This line should appear as the first non empty line after the copyright
header. The line should be:
# Uses GLEP 84 format
This header should come instead of the current very long header [#CURR-MASK]_,
as mentioning the GLEP is enough.
Files can decide to add some extra file documentation, in which case, the
entries start after the line:
#--- END OF EXAMPLES ---
Entries Grouping
Each mask entry consists of 2 parts: `comments block`_ and `packages list`_,
which aren't separated by a blank line between the 2 parts. Between entries, a
mandatory blank line must appear.
New entries added to the file must be inserted at the beginning, after the file
header.
Packages List
-
Must conform to PMS sections 4.4 [#PMS-4.4]_ and 5.2.8 [#PMS-5.2.8]_. This GLEP
further limits the syntax to one item per line, without any leading or
proceeding whitespaces, no comments inside the packages list, and no blank
lines between items in the list.
Comments Block
--
The comments block consists of 2 mandatory parts (`author line`_ and
`explanation`_) and one optional part (`last-rite epilogue`_). A blank line to
separate the parts is optional. Trailing whitespaces should be dropped.
The comments block is prefixed with a "#" symbol. The comments should be
separated with single space from the "#", unless this is trailing whitespace,
in which case it should be removed (meaning blank lines in comments block are
just "#\n").
The lines of the comments block should use column wrapping of 80 characters
(including the "#" prefix). The author line is excluded from this maximum
width.
For simplifying the explanation, we wouldn't mention the "#" prefix.
Implementations are advised to drop this prefix before further processing the
block.
Author Line
'''
A line of the format: ``${AUTHOR-NAME} <${EMAIL}> (${SINGLE-DATE})``. The author
name and email should correspond to the mask author, and should confirm to the
GLEP 76 rules. The date should be of RFC-3339 full-date format, meaning
``-MM-DD``. The date is recommended to use the date at UTC timezone at the
moment of commit push.
Explanation
'''
In this block the reasons for the block should be listed, with extra
explanation where needed
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
On 22/09/2023 17.50, Alex Boag-Munroe wrote: > On Fri, 22 Sept 2023 at 15:37, Sam James wrote: >> >> >> Alex Boag-Munroe writes: >> >>> Any reason for the parseable parts to not be in an established human >>> readable/editable format? e.g. the config ini style format, or TOML? >> >> The only issue really is that depending on how it's done (do we do >> it for the whole file, or just comments), it may need a new (profile) >> EAPI which will take a while to implement and deploy. >> >> If it's just for comments, then we can do it immediately though. >> >>> >>> To crib from the OP example with something configparser understands: >>> [PREAMBLE] >>> Timestamp: 2023-09-21 15:07:42+00:00 >>> Author: Arthur Zamarin >>> Justification: Very broken, no idea why packaged, need to drop ASAP. >>> The project is done with supporting this package. >>> Bugs: 667687, 667689 >>> Removal Date: 2023-10-21 >>> Packages: dev-lang/python >>> >>> The format is well documented already and simple to check for >>> validity, so any GLEP would just need to cover correct keys/values. >>> >> >> But yeah, I agree it's worth thinking about a proper format rather than >> fragile text mangling going into the future. >> > Perhaps eventually it could/should be used for the whole file but as > an interim/beginning there's no reason you couldn't start with > comments: > > # [PREAMBLE] > # Timestamp: 2023-09-21 15:07:42+00:00 > # Author: Arthur Zamarin > # Justification: Very broken, no idea why packaged, need to drop ASAP. > # The project is done with supporting this package. > # Bugs: 667687, 667689 > # Packages: dev-lang/python > dev-lang/python > > This simply adds a pre parse step of stripping the comments then > feeding directly into configparser or probably more suitable, TOML > since TOML has better syntax for directly delivering things like a > "Packages:" key as a list. > > Redoing a bunch of package.* parsing probably wasn't in scope of the > OP but I've always wondered and this felt an opportune moment to > ask/suggest :) Thanks for the idea. Yes, it was out of scope such suggestions for me originally, but thinking more about it, I take it more positively. Please let me (and others) to consider it for some days, cause this is very interesting proposal. Things to consider is how much effort it is to file in future, which format to use, etc. > -- > Ninpo > -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU) OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Standard parsable format for profiles/package.mask file
On 22/09/2023 00.22, Ulrich Mueller wrote:
>>>>>> On Thu, 21 Sep 2023, Arthur Zamarin wrote:
>
>> = "Formal" format =
>
>> Each entry is composed of 2 parts: "#"-prefixed explanation block and
>> list of "${CATEGORY}/${PN}" packages. Entries are separated when a new
>> explanation block starts (meaning first "#"-prefixed line after packages
>> list). You may add newlines between packages in packages list.
>
> "Must" rather than "may" here? You certainly cannot list several
> packages in the same line.
Agreed, poor choice of words.
>> The first line of the "#"-prefixed explanation block must be of the
>> format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
>> format -MM-DD, in UTC timezone.
>
>> If this is a last-rite message, the last line must list the last-rite
>> last date (removal date) and the last-rite bug number. You can also list
>> other bugs relevant to the last-rite. So I think a format of: "Removal
>> on ${REMOVAL_DATE}. Bug #NN, #NN." Where the bug list is comma
>> and space separated, we have at least one space (" +" regex) between the
>> removal date and bug list, and the date is of -MM-DD format.
>> I prefer this line is separate (and not continuous of prefix message text).
>
>> The explanation block itself can reference bugs, by matching the regex
>> "[Bb]ugs? #\d+(, +#\d+)*" (For example: "bug #713106, #753134"). I think
>> this is quite a simple one, but powerful enough for most.
>
>> Lines with single newline between them (so no blank line between them)
>> are considered as single paragraph continuum. If you want to start new
>> paragraph, leave a blank line (still prefixed with #) - think similar to
>> markdown. A line matching the last-rite line is always it's own paragraph.
>
> Is this rule about paragraphs needed? It is at odds with the rule that
> the removal date and bug must be on their own line (i.e. that line is
> _not_ part of a "paragraph continuum").
Hmm, yeah, rereading my text shows I've over-complicated it. What I
wanted is that last paragraph (yes, if there are many bugs it might wrap
into new line) can be not separated with blank line from "main
explanation block".
> What about the introductory comment block in the file? Should there be a
> defined syntax for a separator between it and the rest of the file? For
> example, everything above the first line matching "^#[ \t]*---" could be
> ignored by automatic tools, and they would insert new entries below that
> separator.
Good point, and I should address it as you recommended. I will mention
the ignore-until-this-line, and that new entries should be added as
first entry after that ignore-until-this-line.
>> Should it be a GLEP, I don't think so? But I'm unsure about it. We do
>> need to document it (for example header of that exact file).
>
> It shouldn't be too difficult to wrap this up as a GLEP. OTOH, we don't
> have a GLEP for eclassdoc either.
Yeah, after all the input, yes, I will work on a formal GLEP. It will
take time, but I hope to prepare a first draft in the coming 2 weeks.
> Ulrich
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Standard parsable format for profiles/package.mask file
On 22/09/2023 12.21, Ulrich Mueller wrote:
>>>>>> On Fri, 22 Sep 2023, Oskari Pirhonen wrote:
>
>>> Each entry is composed of 2 parts: "#"-prefixed explanation block and
>>> list of "${CATEGORY}/${PN}" packages. Entries are separated when a new
>>> explanation block starts (meaning first "#"-prefixed line after packages
>>> list). You may add newlines between packages in packages list.
>
>> What about mandatory blank line(s) between entries? That way it ensures
>> they are visually separated when skimming through the file. Plus, you
>> can easily jump from entry to entry in editors that support
>> paragraph-wise movement.
>
> Yes, please. Mandatory blank lines between entries, and no blank lines
> (or lines containing only whitespace) within entries. Especially, no
> blank lines in the list of packages.
Yeah I agree. Originally I wanted to allow blank lines between packages
in same entry (to enable you to group them), but as further
considerations and your input, this is a bad idea (if you want to divide
the group, create separate entries).
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Standard parsable format for profiles/package.mask file
Hi all
I want to suggest a standard format for profiles/package.mask, for
multiple reasons:
1. Easier to write simple to understand mask or last-rites entries. When
all entries are in similar format, the reader knows where to expect
important information and such. Also easier for writer to convey all
needed information.
2. We can teach tools to parse it and render nicely, or help you fill
the file. For example I've tried to implement a parser for
packages.gentoo.org so it shows as nice as possible the message, see as
example [1]. On the other hand, `pkgdev mask` [2] can help you fill the
message (including bug number, last-rite until date, author & email
line). Both of them mostly works, but when someone "breaks" the
unofficial syntax, the tools fail sadly.
This is why I want to recommend we create a mostly standard syntax, so
we can all expect the same thing and have nice things.
Also please note that for now I want to formalize the format only for
profiles/package.mask file, and not the one inside all the different
profiles. If you think we better apply to all of them, we can think on
it separately please :)
The current format is mostly acceptable, but let's tighten it. I will
implement a pkgcheck check that will validate the format and error out
if invalid.
[1] https://packages.gentoo.org/packages/sys-fs/eudev
[2] https://pkgcore.github.io/pkgdev/man/pkgdev/mask.html
= "Formal" format =
Each entry is composed of 2 parts: "#"-prefixed explanation block and
list of "${CATEGORY}/${PN}" packages. Entries are separated when a new
explanation block starts (meaning first "#"-prefixed line after packages
list). You may add newlines between packages in packages list.
The first line of the "#"-prefixed explanation block must be of the
format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
format -MM-DD, in UTC timezone.
If this is a last-rite message, the last line must list the last-rite
last date (removal date) and the last-rite bug number. You can also list
other bugs relevant to the last-rite. So I think a format of: "Removal
on ${REMOVAL_DATE}. Bug #NN, #NN." Where the bug list is comma
and space separated, we have at least one space (" +" regex) between the
removal date and bug list, and the date is of -MM-DD format.
I prefer this line is separate (and not continuous of prefix message text).
The explanation block itself can reference bugs, by matching the regex
"[Bb]ugs? #\d+(, +#\d+)*" (For example: "bug #713106, #753134"). I think
this is quite a simple one, but powerful enough for most.
Lines with single newline between them (so no blank line between them)
are considered as single paragraph continuum. If you want to start new
paragraph, leave a blank line (still prefixed with #) - think similar to
markdown. A line matching the last-rite line is always it's own paragraph.
= Example =
After all of those rambling, here is an example (it will result in 3
paragraphs, 2 explanation and 1 last-rite finish):
# Arthur Zamarin (2023-09-21)
# Very broken, no idea why packaged, need to drop ASAP. The project
# is done with supporting this package. See for history bug #667889.
#
# As a better plan, you should migrate to dev-lang/perl, which has
# better compatibility with dev-lang/ruby when used with dev-lang/lua
# bindings.
# Removal on 2023-10-21. Bug #667687, #667689.
dev-lang/python
Call for comments
So how does it sound? I know it is easy to try to limit the syntax for
me (since I"ll need to implement parsing of it), but I think this format
above matches most of the currently used once, and the one created by
`pkgdev mask`. But i needed, I'm open to improve it by comments.
Should it be a GLEP, I don't think so? But I'm unsure about it. We do
need to document it (for example header of that exact file).
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC PATCH] metadata: Add gnome package stabilization groups
On 19/07/2023 19.10, Matt Turner wrote:
> Signed-off-by: Matt Turner
> ---
> Feel free to bikeshed the location, structure, file-format, etc.
>
> metadata/stabilization-groups/gnome/evolution | 3 +++
> metadata/stabilization-groups/gnome/glib | 3 +++
> metadata/stabilization-groups/gnome/gnome-shell | 4
> metadata/stabilization-groups/gnome/gobject-introspection | 2 ++
> metadata/stabilization-groups/gnome/sysprof | 3 +++
> metadata/stabilization-groups/gnome/vala | 2 ++
> metadata/stabilization-groups/gnome/vte | 3 +++
> 7 files changed, 20 insertions(+)
> create mode 100644 metadata/stabilization-groups/gnome/evolution
> create mode 100644 metadata/stabilization-groups/gnome/glib
> create mode 100644 metadata/stabilization-groups/gnome/gnome-shell
> create mode 100644 metadata/stabilization-groups/gnome/gobject-introspection
> create mode 100644 metadata/stabilization-groups/gnome/sysprof
> create mode 100644 metadata/stabilization-groups/gnome/vala
> create mode 100644 metadata/stabilization-groups/gnome/vte
>
So semi-formalizing it before I implement parsing it in pkgcore:
1. everything is located under "metadata/stabilization-groups/"
2. We search recursively as much as needed, so all files are included in
any depth.
3. Group name plays similarly to path, so here the group name would be
"@gnome/vte" (at least for `pkgdev bugs` invocations). By using full
path, we are safe from name collisions.
4. The file itself uses similar format to our various profiles files.
Ignore white-spaces before and after, "#" as a comment. Only one
"cat/pkg" per line.
5. I think for now we can go without mandatory copyright header...
How it will affect `pkgdev bugs` invocations? I'll use your sets as
example. Let's say our invocation is `pkgdev bugs dev-libs/glib
@gnome/vala`.
- if a set is passed (anything starting with @), replace it with all the
contents of that set (so "@gnome/vala" equals to "dev-libs/vala-common
dev-lang/vala").
- Drop every package from the pkglist whose latest matching package to
the restricts expression is already latest (so nothing better to do).
- pkgdev bugs builds the full graph as it does today. Let's say it
decided it needs to also add "dev-util/glib-utils".
- For every defined set, all the packages included in graph and in the
set are merged into one bug. This means we would get one bug for
"@gnome/vala" ("dev-libs/vala-common dev-lang/vala") and one bug for
"@gnome/glib" ("dev-libs/glib dev-util/glib-utils"). Notice that it
didn't add the other package in that set ("dev-util/gdbus-codegen")
since it wasn't requested or required.
Does this flow seems logical and flexible enough? I don't think auto
adding whole set if any one of it's package is required is a good idea
since it might explode? If folks want to stable the whole set, explicit
pass it as arg in the invocation.
Do note that I'm open to other flows and usages, everything is open for
me (I didn't start to implement it, just scratches in my notebook).
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-cdr/cdw
# Arthur Zamarin (2023-07-21) # Broken runtime with ncurses version since last 2 years (unusable at # all), no upstream activity of any sort since 2016. # # Removal: 2023-08-20. Bug #910649. app-cdr/cdw OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Package stabilization groups
On 17/07/2023 19.37, Sam James wrote: > > Big fan of the idea & very much in support of it. This also serves > to give us logical groupings of packages which are closely related > and should be bumped together. > >> There was some brief discussion on IRC about how to document these >> groupings, and two main ideas were suggested: >> >> - add a field to metadata.xml to specify the group by an arbitrary name. >> E.g. >> Each package in the group would specify the same value of name="..." >> >> - maintain the groups in a separate place (similar to portage @sets). >> >> Can anyone think of particular advantages or disadvantages to one >> solution versus the other? Any other (better) ideas? >> > > When we discussed this a few months ago on IRC, I also brought up a > related point: > > [2023-05-02T18:38:51+0100] <@sam_> do we want to repeat the group members in > each member, or do tools need to scan for each thing? > [2023-05-02T18:39:07+0100] <@sam_> i.e. does each member have > ..., or do we do name=".../>? > [2023-05-02T18:39:26+0100] <@arthurzam> I think each package says which > groups it is part of > [2023-05-02T18:39:44+0100] <@radhermit> I would do the latter > [...] > [2023-05-02T18:42:42+0100] <@radhermit> technically you could also maintain > them in a separate place like metadata/groups and layer inter-group > dependencies on top of that somehow in the format If you read carefully my messages in IRC linked above, you can see I was supporting per package metadata entry. If you read my latest post to ML, you can see I now prefer central files. After many considerations since then I understood my initial preference was a bad idea :) (I'm noting it here just so folks understand the mismatch between texts and my stance). > I'd prefer the metadata/ at repo root idea because I can see updating > various metadata.xmls being a nuisance. Hmm, I was thinking the opposite (maintaining it in parallel place to the package would be harder), but if you say so (and you help maintain huge clusters of packages so I believe you) then I think we don't have any good reason to go with per package metadata.xml entry? Let's wait for more input, and then we can go with defining the syntax, rules and such... > best, > sam > -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU) OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Package stabilization groups
On 17/07/2023 16.50, Matt Turner wrote:
> On Sun, Jul 16, 2023 at 2:04 PM Arthur Zamarin wrote:
>> Now I'll speak from the point of implementer of `pkgdev bugs`. For me I
>> think both approaches are good, but I would prefer the latter over the
>> former. Nicer syntax, easy cache of all groups, easier to solve the
>> "graph problems" in the tool.
>
> Sounds good to me. Should we have infra create a new git repo for us
> for this purpose?
>
No. I think it should go under normal git repo, and not separate repo. I
see no gains from it being under separate repository, only headache (how
to sync between them).
I think a main index files under
"/metadata/${some_good_name}/${group_name}" would be best.
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] Package stabilization groups
On 16/07/2023 21.11, Ulrich Mueller wrote:
>>>>>> On Sun, 16 Jul 2023, Arthur Zamarin wrote:
>
>> - enables an easier syntax as `pkgdev bugs @group1` to file a single bug
>> for all of them. In Gnome's case as an example, we could have "gnome1",
>> "gnome2", "gnome3", "gnome4", etc - groups standing for multiple
>> "layers/stages" of stabilizing, and then you could just file `pkgdev
>> bugs @gnome{1..4}` to file "at one click" the whole gnome stablereqs.
>
> Can't we do the same that we do for local use flags? Namely, define them
> in metadata.xml, but collect them in one central location?
Do note that this grouping is done at "metadata repo", and not the
normal git repo where development is done. Meaning you need to manually
add the package to the central "index".
> Ulrich
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] Package stabilization groups
On 16/07/2023 17.57, Matt Turner wrote:
> Hello,
>
> Many of us have started using `pkgdev bugs` to file stabilization
> bugs. It works well (Thanks Arthur!) and I encourage everyone to give
> it a try.
Gladly :) You can semi-blame mgorny for the creation of `pkgdev bugs`,
because I started to file stablereqs for @python packages, and at some
point it was too tiring and repetitive, so I was brought to the drawing
table to think of a solution.
> Where possible, it files one stabilization bug per package. This makes
> arch testers' jobs easier and makes the task easier to automate.
>
> But sometimes we do want to stabilize packages together. For example
> major versions of x11-wm/mutter and gnome-base/gnome-shell are tied
> together. If a new mutter is stabilized without the new gnome-shell,
> the tree will still be consistent, but emerge -u @world will warn
> users that the mutter upgrade is blocked.
>
> There was some brief discussion on IRC about how to document these
> groupings, and two main ideas were suggested:
>
> - add a field to metadata.xml to specify the group by an arbitrary name.
> E.g.
> Each package in the group would specify the same value of name="..."
>
> - maintain the groups in a separate place (similar to portage @sets).
>
> Can anyone think of particular advantages or disadvantages to one
> solution versus the other? Any other (better) ideas?
Let me list some things as advantages to each one (since I see an
advantage to one as disadvantage to other).
Advantages of field in metadata.xml:
- local to package, easier to not miss. Easier to follow for the maintainer.
- easier to find which group the current package relates to
Advantages to group files:
- easier to index (one file listing all children, instead of searching
across repo who defines it)
- easier to not repeat group. In the metadata field it might happen to
repeat, less likely since it is easy to search, but similar group names
might be created, merging them into one by mistake, or creating very
similar names and mistaking them. When we have a single file, it is
easier to see the whole picture and verify things.
- since this is compressed information (special files instead of spread
over repo), we could load all of them into app's cache, and make all
computation easier.
- enables an easier syntax as `pkgdev bugs @group1` to file a single bug
for all of them. In Gnome's case as an example, we could have "gnome1",
"gnome2", "gnome3", "gnome4", etc - groups standing for multiple
"layers/stages" of stabilizing, and then you could just file `pkgdev
bugs @gnome{1..4}` to file "at one click" the whole gnome stablereqs.
> Thanks,
> Matt
Now I'll speak from the point of implementer of `pkgdev bugs`. For me I
think both approaches are good, but I would prefer the latter over the
former. Nicer syntax, easy cache of all groups, easier to solve the
"graph problems" in the tool.
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [PATCH] ruby-utils.eclass: Simplify _ruby_implementation_depend
On 14/07/2023 11.37, Sam James wrote: > > Sam James writes: > >> From: konsolebox >> >> Closes: https://bugs.gentoo.org/909529 >> Signed-off-by: Sam James > > ftr, while I find the case really repetitive, I'm not sure if this > crosses the line into unreadable bash or not, so I feel on the fence. > > But I wanted it reviewed on ML in any case, rather than us forgetting > it on BZ. > I agree the code isn't easy to read, but it isn't too hard. I do want to suggest you add a simple comment on the same line bringing an example value for the rubyslot. With an example comment, it becomes trivial to understand (and if someone needs to change it, he know beforehand what format to expect). -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU) OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-dev-announce] Migrating ebuilds to "optimized" cargo.eclass API
On 19/06/2023 18.01, Michał Górny wrote:
> Hi,
>
> The migration requires two changes:
>
> 1. `$(cargo_crate_uris)` (or `$(cargo_crate_uris ${CRATES})`) in SRC_URI
> needs to be replaced by `${CARGO_CRATE_URIS}`. This requires that
> CRATES and GIT_CRATES are declared pre-inherit (this is already enforced
> for CRATES in EAPI 8, but it is not for GIT_CRATES).
>
> 2. The CRATES variable (and other crate lists) need to use `@`
> as the separator between crate name and version instead of `-`.
> The easiest way to do this is to use >=app-portage/pycargoebuild-0.7 to
> generate the variable. You can use the in-place mode to update
> the ebuild, then it will substitute the list in place:
>
> pycargoebuild -i foo-1.2.3.ebuild /directories/with/cargo-lock
>
> Note that pycargoebuild won't replace $(cargo_crate_uris) automatically
> though.
>
I want to add here, that since yesterday, pkgcheck live () is
warning about the "old less optimal" usage and recommends the replacement.
While I know the distrust people have to live ebuilds, the pkgcore stack
is very serious about the live state. As long as you rebuild
periodically the live version (for example using smart-live-rebuild, so
you aren't left with a version from years ago) this is considered
supported by upstream and very stable. I try to cut new pkgcheck
releases every month, but until then feel free to use live.
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: EGO_SUM
y agreeing devs can at least reply shortly their agreement or disagreement. > - Flow > > > 1: https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg95175.html > 2: https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg95279.html > 3: https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg97310.html I must say this conversation around EGO_SUM makes me a little sad the long time it takes, and sometimes it feels like it derails to bad directions (I mean less helpful once) too often. I think we should go to the way Flow - suggest concrete action items (something easier for Council / all devs to vote). Also sorry this mail is a little jumping all over, it is quite hard for me to write long mails in English, so if paragraphs are less coherent, I'll be happy to explain them more :) -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU) OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] cmake.eclass: Set Python3_FIND_UNVERSIONED_NAMES FIRST
On 23/03/2023 11.33, Andreas Sturmlechner wrote:
> This is already committed in kde overlay for testing (e.g. via eclass-
> overrides).
>
> See also:
> https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8287
>
> Bug: https://bugs.gentoo.org/835799
> Signed-off-by: Andreas Sturmlechner
> ---
> eclass/cmake.eclass | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
> index 9195f3b2d1..3c432ceca8 100644
> --- a/eclass/cmake.eclass
> +++ b/eclass/cmake.eclass
> @@ -537,6 +537,7 @@ cmake_src_configure() {
> set(CMAKE_USER_MAKE_RULES_OVERRIDE "${build_rules}" CACHE
> FILEPATH "Gentoo override rules")
> set(CMAKE_INSTALL_DOCDIR "${EPREFIX}/usr/share/doc/${PF}"
> CACHE PATH "")
> set(BUILD_SHARED_LIBS ON CACHE BOOL "")
> + set(Python3_FIND_UNVERSIONED_NAMES FIRST CACHE STRING "")
> _EOF_
>
> if [[ -n ${_ECM_ECLASS} ]]; then
Thank you for adding it. While ideally ebuilds should pass correctly the
python binary, libs and such in the ebuild, this change makes it better
behave when not passed and for overlays, making the global situation better.
Big +1 from me
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/tavern
# Arthur Zamarin (2023-02-04) # pytest plugin, which breaks a lot of python_test of other ebuilds # if installed unless disabled. The package itself is hard to # maintain. No reverse dependencies. # Removal: 2023-03-06. Bug #893212. dev-python/tavern OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Python 3.9 removal and Python 3.11 stable
Hi, everyone. TL;DR: 1. We want to drop Python 3.9 from PYTHON_COMPAT around June 2023. 2. We want to switch to Python 3.11 as the stable compat at around the same time. 3. Python 3.12 is coming at May, which will be hellish. === Dropping Python 3.9 in June === I'm happy to announce that the repo has fully migrated to Python 3.10 compatibility, and the only remaining package with only 3.9 is dev-python/pathlib2, which is a backport. I want to thank all the people who helped with it (the list is long so I won't list them). Currently Python 3.9 is in "security" supported state upstream, i.e. they no longer receive bugfixes except for (some of) security backports. We at Python project are planning to drop 3.9 from PYTHON_COMPAT at around June 2023. Does this sound acceptable to all? == Stable Python 3.11 in June == Since dropping python 3.9 will result in use rebuild for our users, we prefer to set python 3.11 as the stable compat at the same time (do note that while a preference, this isn't a blocker). Which is why we also think to bump the stable python to 3.11 at around June. If you haven't ported your packages, please do so ASAP. If you notice a package which isn't used and isn't ported, consider last-riting it. Any help would be very appreciated. If you need help, ping us on #gentoo-python, we are very active there. === Python 3.12 Beta in May === Python 3.12.0b1 is planned for May, with which we would (most likely) add 3.12 to PYTHON_COMPAT. We are expecting it to be a hard release of many reasons, one of them is removal of deprecated builtin distutils. Knowing of this impending hard work, we want to ease our burden, by dropping py3.9 and stabilizing 3.11. -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU) OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-containers/docker-gc
# Arthur Zamarin (2022-12-31) # EAPI=6 ebuild, live only packages for 1 year! maintainer-needed # package. # Removal: 2023-01-30. Bug #889200. app-containers/docker-gc OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-vim/lightline
# Arthur Zamarin (2022-12-31) # EAPI=6 ebuild, live only packages for 6 years! # Removal: 2023-01-30. Bug #889198. app-vim/lightline OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: sys-auth/google-authenticator-libpam-hardened
# Arthur Zamarin (2022-12-31) # Live only packages for 4 years! # Removal: 2023-01-30. Bug #889196. sys-auth/google-authenticator-libpam-hardened OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: x11-plugins/pidgin-funyahoo-plusplus
# Arthur Zamarin (2022-12-31) # EAPI=6 ebuild, live only packages for 6 years! # Removal: 2023-01-30. Bug #889194. x11-plugins/pidgin-funyahoo-plusplus OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: media-libs/kodi-platform, media-plugins/kodi-game-libretro-fceumm, media-plugins/kodi-peripheral-steamcontroller
# Arthur Zamarin (2022-12-24) # Live only packages for 4 years! Upstream repositories are archived # or inactive. # Removal: 2023-01-23. Bug #888175. media-libs/kodi-platform media-plugins/kodi-game-libretro-fceumm media-plugins/kodi-peripheral-steamcontroller OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: x11-misc/xowl, x11-wm/xoat
# Arthur Zamarin (2022-12-24) # EAPI=6 ebuilds, live only packages for 5.79 years! # maintainer-needed packages for a long time. # Removal: 2023-01-23. Bug #888173. x11-misc/xowl x11-wm/xoat OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
On 06/11/2022 10.34, Sam James wrote: > > ... > > That had two parts: > 1. https://github.com/projg2/nattka/issues/72 & > https://github.com/projg2/nattka/pull/73 (done) > 2. https://github.com/arthurzam/tattoo/issues/1 (not done) I was waiting for nattka-0.4 (which returns the field value) and was hoping to wait until it becomes stable, so it will be able to upgrade nattka on all devboxes easily and just use new API. Seeing this conversation, made me understand that it is desired to do it ASAP, so I added it now with a little ugly code around (import guards to check that nattka supports the new field). So currently tattoo skips all bugs marked with Manual testing. I also plan to create a small dashboard showing special cases of Arch Testing bugs, such as: 1. Bugs with only one arch remaining 2. Bugs blocked by blocker bug 3. Bugs without any info and activity (not blocked, untouched, not done) This is in hopes to have a more organized and priority bugs, to mitigate cases when something somewhere failed, and we lose the bug until pinged. My current plan is to have a script that generated a HTML file that I will host on ~dev space, and will have a scheduled process to regenerate the HTML. I'm still planning the solution and how to schedule it, so no promises :) -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, Arch Teams, pkgcore stack, GURU) OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/tempita
# Arthur Zamarin (2022-11-04) # Upstream repository is gone. Uses internally python 2 code, which # we patch into python 3. Only ebuild uses snapshot tarball from the # dead repo. Doesn't use PEP517 mode. Has issues with python 3.11. # No reverse dependencies in tree. # Removal: 2022-12-04. Bug #879613. dev-python/tempita OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/pathtools
# Arthur Zamarin (2022-10-29) # Last upstream commit in 2016, no tests, implements functions # which are implemented by pathlib Python module. No reverse # dependencies in gentoo tree for a long time. # Removal: 2022-11-28. Bug #878733. dev-python/pathtools OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] New type
On 14/10/2022 20.26, red...@riseup.net wrote: > Hi, I want to use , but it's not available > yet. So i want to know what to do in these cases. > > According to this page: > https://devmanual.gentoo.org/ebuild-writing/misc-files/metadata/, I have > to email here if I want to use a new type value. > > - Redson > Please read at [1], especially the last part which lists what and where you need to add. [1] https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Upstream_remote-id_types -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, Arch Teams, pkgcore stack, GURU) OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: net-misc/electrum-ltc
On 27/09/2022 00.49, Jeff Gazso wrote: > After some trial and error, I managed to modernize the old > net-misc/electrum-ltc ebuild based upon the net-misc/electrum ebuild code. > I still need to tweak a few things, but it's basically done. Thank you for the work on it. > I am not (yet) a Gentoo dev, how do I move forward with the revised > ebuild? > Open a Pull Request in GitHub, and one of our devs will review it. I recommend to read [1] if this is your first time. Please ping me (@arthurzam) so we don't miss it :) [1] https://wiki.gentoo.org/wiki/GitHub_Pull_Requests -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, Arch Teams, pkgcore stack) OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: net-misc/electrum-ltc
On 10/09/2022 18.49, Jeff Gazso wrote: > This one caught me by surprise. > > So, it looks like the versions of net-misc/electrum (the Bitcoin client) > in Gentoo's repository are in pretty good shape. The version of > net-misc/electrum-ltc (the Litecoin client) in the Gentoo repository > looks like it's two years old. (For those who are unfamiliar the > Litecoin client is downstream of the Bitcoin client, both projects share > a lot of the same code.) I checked upstream and the current version of > electrum-ltc appears to have been bumped to Python 3.8 and it looks like > the old aiorpcX (#792219) issue that was causing such a headache has > also been fixed as of a PR this past February. See my note in #792219. Looks like you are correct, but note that we currently have 3.10 as stable version, so electrum-ltc should be at least that version. > Pardon my ignorance, but couldn't this package be salvaged by > repurposing the net-misc/electrum ebuild code to bring the > net-misc/electrum-ltc package current? Is the situation more complicated > than that? If any user manages to fix the issues mentioned in last rite message (mainly bump to at least 3.10 python target), I would gladly cancel the last-rite and mask. If you do it, please ping me in the PR, and I would gladly review it. Those last-rites I did today are mainly for those packages that were stuck in only 3.8, had a bug open for 7-10 month already. If any maintainer can fix those ebuilds, I would happily revert the last-rite. > ~Jeff -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, Arch Teams, pkgcore stack, GURU) OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-analyzer/flent
# Arthur Zamarin (2022-09-10) # Python 3.8 only. EAPI=6 ebuild. 5 open bugs. Issues with newer # dependencies versions. # Removal: 2022-10-10. Bugs #869524, #684334. net-analyzer/flent OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-nds/nsscache
# Arthur Zamarin (2022-09-10) # Python 3.8 only package. Tests are disabled. Newer targets fail # more tests then 3.8 target. # Removal: 2022-10-10. Bug #869521. net-nds/nsscache OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/python-etcd
# Arthur Zamarin (2022-09-10) # Python 3.8 only package, with inactive since 2017 upstream. # Tests fail and doesn't work on newer python targets. # Removal: 2022-10-10. Bug #869512. dev-python/python-etcd OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-misc/electrum-ltc
# Arthur Zamarin (2022-09-10) # Python 3.8 only package, with capped old dependencies, and open # bugs and issues. # Removal: 2022-10-10. Bugs #869506, #695090, #792219, #809272. net-misc/electrum-ltc OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/SaltTesting
# Arthur Zamarin (2022-09-10) # Upstream repository archived. Python 3.8 only, with issues for # newer targets. No reverse dependencies in tree. # Removal: 2022-10-10. Bugs #869503, #747997, #832242 dev-python/SaltTesting OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: www-apps/blohg
# Arthur Zamarin (2022-09-07) # Python 3.8 only package, no maintainer left. # Removal: 2022-10-07. Bug #869107 www-apps/blohg OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-backup/attic
# Arthur Zamarin (2022-09-07) # Python 3.8 only package, 2 open bugs. Recommended to migrate to borg. # No upstream activity since 2015. # Bugs #674822, #830291, #832240 # Removal: 2022-10-07. Bug #869101 app-backup/attic OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH 4/4] rebar.eclass: add support for EAPI=8
Signed-off-by: Arthur Zamarin
---
eclass/rebar.eclass | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
index c982dea5d1..1c7bc20def 100644
--- a/eclass/rebar.eclass
+++ b/eclass/rebar.eclass
@@ -6,7 +6,7 @@
# maintainer-nee...@gentoo.org
# @AUTHOR:
# Amadeusz Żołnowski
-# @SUPPORTED_EAPIS: 6 7
+# @SUPPORTED_EAPIS: 6 7 8
# @BLURB: Build Erlang/OTP projects using dev-util/rebar.
# @DESCRIPTION:
# An eclass providing functions to build Erlang/OTP projects using
@@ -19,15 +19,9 @@
# targets. The eclass workarounds some of these problems. It handles
# installation in a generic way for Erlang/OTP structured projects.
-case "${EAPI:-0}" in
- 0|1|2|3|4|5)
- die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
- ;;
- 6|7)
- ;;
- *)
- die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
- ;;
+case ${EAPI} in
+ 6|7|8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
EXPORT_FUNCTIONS src_prepare src_compile src_test src_install
--
2.37.3
[gentoo-dev] [PATCH 3/4] myspell-r2.eclass: improve code examples format
Signed-off-by: Arthur Zamarin
---
eclass/myspell-r2.eclass | 6 ++
1 file changed, 6 insertions(+)
diff --git a/eclass/myspell-r2.eclass b/eclass/myspell-r2.eclass
index cce75ae4d6..965327ac1b 100644
--- a/eclass/myspell-r2.eclass
+++ b/eclass/myspell-r2.eclass
@@ -16,19 +16,25 @@
# @DEFAULT_UNSET
# @DESCRIPTION:
# Array variable containing list of all dictionary files.
+# @CODE
# MYSPELL_DICT=( "file.dic" "dir/file2.aff" )
+# @CODE
# @ECLASS_VARIABLE: MYSPELL_HYPH
# @DEFAULT_UNSET
# @DESCRIPTION:
# Array variable containing list of all hyphenation files.
+# @CODE
# MYSPELL_HYPH=( "file.dic" "dir/file2.dic" )
+# @CODE
# @ECLASS_VARIABLE: MYSPELL_THES
# @DEFAULT_UNSET
# @DESCRIPTION:
# Array variable containing list of all thesarus files.
+# @CODE
# MYSPELL_THES=( "file.dat" "dir/file2.idx" )
+# @CODE
case ${EAPI} in
7|8)
--
2.37.3
[gentoo-dev] [PATCH 2/4] myspell-r2.eclass: drop support for EAPI<7
- No consumers for EAPI<7 remain in ::gentoo tree
- Simplifies dependency logic
- fix UnquotedVariable of DISTDIR
Signed-off-by: Arthur Zamarin
---
eclass/myspell-r2.eclass | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/eclass/myspell-r2.eclass b/eclass/myspell-r2.eclass
index 6dbd1e19e1..cce75ae4d6 100644
--- a/eclass/myspell-r2.eclass
+++ b/eclass/myspell-r2.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: myspell-r2.eclass
@@ -6,7 +6,7 @@
# Conrad Kostecki
# @AUTHOR:
# Tomáš Chvátal
-# @SUPPORTED_EAPIS: 5 6 7 8
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: An eclass to streamline the construction of ebuilds for new Myspell
dictionaries.
# @DESCRIPTION:
# The myspell-r2 eclass is designed to streamline the construction of ebuilds
for
@@ -30,8 +30,8 @@
# Array variable containing list of all thesarus files.
# MYSPELL_THES=( "file.dat" "dir/file2.idx" )
-case ${EAPI:-0} in
- [5-8])
+case ${EAPI} in
+ 7|8)
;;
*)
die "${ECLASS}: EAPI ${EAPI:-0} not supported"
@@ -43,12 +43,7 @@ EXPORT_FUNCTIONS src_unpack src_install
# Basically no extra deps needed.
# Unzip is required for .oxt libreoffice extensions
# which are just fancy zip files.
-if [[ ${EAPI:-0} != [56] ]]; then
- BDEPEND="app-arch/unzip"
-else
- DEPEND="app-arch/unzip"
- RDEPEND=""
-fi
+BDEPEND="app-arch/unzip"
# by default this stuff does not have any folder in the pack
S="${WORKDIR}"
@@ -65,7 +60,7 @@ myspell-r2_src_unpack() {
case ${f} in
*.oxt)
echo ">>> Unpacking "${DISTDIR}/${f}" to ${PWD}"
- unzip -qoj ${DISTDIR}/${f}
+ unzip -qoj "${DISTDIR}"/${f}
assert "failed unpacking ${DISTDIR}/${f}"
;;
*) unpack ${f} ;;
--
2.37.3
[gentoo-dev] [PATCH 1/4] kodi-addon.eclass: drop support for EAPI<7
- No consumers for EAPI<7 remain in ::gentoo tree
- For those EAPIs, it tries to inherit cmake-utils eclass, which
doesn't exist, so it would just fail!
- Simplify the eclass logic
- Fix UnquotedVariable for EPREFIX
Signed-off-by: Arthur Zamarin
---
eclass/kodi-addon.eclass | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/eclass/kodi-addon.eclass b/eclass/kodi-addon.eclass
index 8cbbad9224..6e7fa26f3c 100644
--- a/eclass/kodi-addon.eclass
+++ b/eclass/kodi-addon.eclass
@@ -1,25 +1,22 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: kodi-addon.eclass
# @MAINTAINER:
# candr...@gentoo.org
-# @SUPPORTED_EAPIS: 4 5 6 7
-# @PROVIDES: cmake cmake-utils
+# @SUPPORTED_EAPIS: 7
+# @PROVIDES: cmake
# @BLURB: Helper for correct building and (importantly) installing Kodi addon
packages.
# @DESCRIPTION:
# Provides a src_configure function for correct CMake configuration
-case "${EAPI:-0}" in
- 4|5|6)
- inherit cmake-utils multilib
- ;;
- 7)
- inherit cmake
- ;;
- *) die "EAPI=${EAPI} is not supported" ;;
+case ${EAPI} in
+ 7) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
+inherit cmake
+
EXPORT_FUNCTIONS src_configure
# @FUNCTION: kodi-addon_src_configure
@@ -28,11 +25,8 @@ EXPORT_FUNCTIONS src_configure
kodi-addon_src_configure() {
mycmakeargs+=(
- -DCMAKE_INSTALL_LIBDIR=${EPREFIX%/}/usr/$(get_libdir)/kodi
+ -DCMAKE_INSTALL_LIBDIR="${EPREFIX}/usr/$(get_libdir)/kodi"
)
- case ${EAPI} in
- 4|5|6) cmake-utils_src_configure ;;
- 7) cmake_src_configure ;;
- esac
+ cmake_src_configure
}
--
2.37.3
[gentoo-dev] Various changes to eclasses
This patchset is part of a branch I opened where I cleaned some simple warning of pkgcheck for UnquotedVariable. As part of this branch, I was instructed kindly to not post the simple changes I did (as they will spam) but do include the serious changes across the eclasses. The full changes can be found at [1], and all changes will be merged together to minimize eclass cache invalidation. [1] https://github.com/gentoo/gentoo/pull/27123
[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs: gui-libs/wlroots, app-text/scdoc, net-fs/sshfs and more
On 14/08/2022 09.58, Joonas Niilola wrote: > Hey, > > these packages are up for grabs: > app-text/scdoc > gui-apps/grim > gui-apps/kanshi > gui-apps/slurp > gui-libs/wlroots I will take them, as those are parts (lib & utilities) of sway window manager that I use and like. Co-maintainers are welcome! > > The usual set. Some outdated, most waiting for stabilizations and > cleanups, some have bugs open. It will take me 2-3 days to go over all open bugs & bumps, but I will clean those up to the high standards of Gentoo. -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, Arch Teams, pkgcore stack, GURU) OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 16/07/2022 20.51, William Hubbs wrote: > On Sat, Jul 16, 2022 at 02:58:04PM +0300, Joonas Niilola wrote: >> On 16.7.2022 14.24, Florian Schmaus wrote: >>> >> >> ++ this sounds most sensible. This is also how I've understood your >> proposal. > > Remember that with EGO_SUM all of the bloated manifests and ebuilds are > on every user's system. > > I added mgorny as a cc to this message because he made it pretty clear > at some point in the previous discussion that the size of these ebuilds > and manifests is unacceptable. > > William I want to give another option. Both ways are allowed by eclass, but by QA policy (or some other decision), it is prohibited to use EGO_SUM in main ::gentoo tree. As a result, overlays and ::guru can use the EGO_SUM or dist distfile (remember, they don't have access to hosting on dev.g.o). -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, Arch Teams, pkgcore stack, GURU) OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] GLEP 83: EAPI deprecation
On 13/07/2022 11.12, Ulrich Mueller wrote: >>>>>> On Mon, 11 Jul 2022, Ulrich Mueller wrote: > > > So, any opinions? Should we go for the longer transition time (and make > overlay maintainers happy), or for a shorter time so that we can tidy up > eclasses sooner? > > Ulrich My personal take on this question. Faster deprecation of EAPI ebuilds in ::gentoo repo (as we can control it), but longer time until we remove it from eclasses. Note that I don't mean here deprecation, only removal. I think that with current EAPI>=6 state, the "weight of supporting" EAPI=6 isn't very heavy, so some extra time for overlays will be nice. I do know that I don't help a lot in eclass maintenance, so if I wrong in this statement, I won't complain of course. Maybe (?) this will also help during bumps of old systems (not that we care too much, as we give them along timeframe for this and they can use snapshots of repo, but why not as an extra bonus). -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, Arch Teams, pkgcore stack, GURU) OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Re: pkgdev new release v0.2.1 with breaking change
On 23/05/2022 20.57, Andrew Ammerlaan wrote: > On 22/05/2022 20:20, Arthur Zamarin wrote: >> I have just released a new version [0] for pkgdev. Outside of multiple >> new features meant for easier developer workflows (like prepare to send >> a last-rite email), there is an important changes in the release which >> affect current users of pkgdev. >> >> ** Important Notice ** >> >> pkgdev now doesn't add the signoff by itself, unless configured. You can >> easily configure it by following the instructions [1], which in short >> corresponds to adding to `~/.config/pkgdev/pkgdev.conf` the lines: >> >> [gentoo] >> push.signoff = true > > Shouldn't this be commit.signoff instead? > > pkgdev push: failed loading config: unknown arguments: --signoff=true > > (The same mistake is in the documentation at [1]) > >> ... > > Best regards, > Andrew > Thank you Andrew, You are absolutely right - this was my mistake in lines. It should be: [gentoo] commit.signoff = true Actually I also got reports of it failing to identify that this is the gentoo repo, so for now, so we are absolutely sure it works, please use: [DEFAULT] commit.signoff = true Once again, I'm sorry for this mistake, and I will fix the docs ASAP. -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, Arch Teams, pkgcore stack, GURU) OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] pkgdev new release v0.2.1 with breaking change
I have just released a new version [0] for pkgdev. Outside of multiple new features meant for easier developer workflows (like prepare to send a last-rite email), there is an important changes in the release which affect current users of pkgdev. ** Important Notice ** pkgdev now doesn't add the signoff by itself, unless configured. You can easily configure it by following the instructions [1], which in short corresponds to adding to `~/.config/pkgdev/pkgdev.conf` the lines: [gentoo] push.signoff = true In case you forgot to perform this, the usual workflow of working with pkgdev (meaning committing and then pushing) would seem to work, but because of missing Signed-off-by line, the push would fail. I also recommend to read the full configuration docs at [1], as now it is possible to configure the "new default" args for pkgdev. Finally I want to call for features requests for the pkgcheck and pkgdev. Myself and other developers are trying to actively maintain the stack, and add new features, QA checks, etc. I want to make those tools nice for Gentoo developers, so I need your requests to improve it. [0] https://github.com/pkgcore/pkgdev/releases/tag/v0.2.1 [1] https://pkgcore.github.io/pkgdev/man/pkgdev.html#config-file-support -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, Arch Teams, pkgcore stack, GURU) OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Change the stabilization request flows
On 23/04/2022 14.22, Ulrich Mueller wrote: >>>>>> On Sat, 23 Apr 2022, Arthur Zamarin wrote: > >> ... > > That's not entirely fool-proof. Sometimes a maintainer's description > suggests that they shouldn't be CCed. (Maybe we need an additional tag > for this to make it machine readable?) I'm all for more machine readable metadata.xml with extra tags for things like that. Also, is that common to have such things? Why would you be marked as maintainer and not be CC for stabilization requests? At least to my understanding of maintainer "job" at Gentoo seem to contradict? Also, if we decide (at least in the current thread) to add a new tag to mark this person as non-CC - what is the approval process for such a change? > Ulrich -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, GURU, Arch Teams) OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [RFC] Change the stabilization request flows
Hi All! As a result of a premature stabilization CC-ARCHES without acknowledgments from maintainers on a bug in last week, and after leio suggested on IRC a change of flows, I want to suggest multiple ideas and get your responses and comments. As some background, we have a tool called nattka [1], which periodically scans all stabilization and keywording bugs, sanity checks them and CC all relevant arches when the bug is "ready". Currently the needed rules to mark the bug as ready are having CC-ARCHES is keywords, having correctly formatted package-list, and having the bug assigned. Around a month ago, I have added a new addition to nattka [2], which auto CC maintainers of all packages in package-list. This was so maintainers are informed of changes to their package. But as you can understand, this isn't error-proof, as even if all maintainers were CC (sadly this didn't work for the bug mentioned above, but doesn't matter for the discussion), the Arches Testers can be too fast and finish the bug before maintainers had time to NAK the process. The first flow I want to introduce is when nattka sees a bug with CC-ARCHES in keyword, but not all maintainers were CC, nattka will CC all maintainers, drop the CC-ARCHES, and comment something a long the lines "wait for maintainers to ACK by adding CC-ARCHES keyword" (of course the text can improve). What are the effects from that addition? In case someone create a request and mistakenly missed a maintainer, the process will pause and wait for re-addition. But if the reporter of bug fills all fields correctly and CC all expected maintainers, nattka won't wait before marking the bug "ready". We have teams and people who know what they do, and file massive amounts of stabilization requests, with knowledge what they do. I don't want to hinder this workflow and make it harder. Also the check who can add the CC-ARCHES keyword is very hard to define (was he part of the project, was he allowed on IRC as one time proxy, maintainer-timeout, etc). I believe all gentoo developers has the knowledge and responsibility, so that if they do a mistake, they will need to follow it and fix it, as appropriate in each case of bad results. Another idea, given by mgorny and sam on IRC, was to use flags on bugzilla. The same way we have currently a flag for "sanity-check" and "bugday", we can do a flag for maintainer ACK. The advantage of using a flag instead of keyword, is the possibility to restrict access to this flag to only users with "editbugs" permission. With all dues respect, we can't expect the same responsibility from non-gentoo-devs as from gentoo-devs, from those we can expect, "editbugs" will be fine. If we decide to go with a flag, we will have backward compatible nattka to work with "old" keyword based way, and maybe we will use nattka to "migrate" the "old" bugs to the new way. I also want to suggest using the deadline field of a bug. For those that don't know, you can set the deadline for a bug by clicking the "show time tracking data" between the bug info and comments. But I want to use this field in the opposite meaning, as "the minimal date we can mark this bug ready". Mainly at java packages stablereq bugs, I saw vaukai creating a bug, and stating "starting from xxx date", which I think is very nice usage, but a user can forget he marked that package. On implementation side, nattka will sanity check the bug, but won't CC all arch teams until this date arrives. I think this is a very small feature, but will be nice to have for such users. My only disadvantage is using misleading now name of "deadline". After such a changes every stabilization bug will have the following possible states: 1. "Bad formatted" bug (not assigned or wrong formatted package list) - Do nothing 2. filed full bug, but without all maintainers included --> CC all, comment on missing maintainers, and drop ACK flag (CC-ARCHES / the flag) 3. file full bug, with all maintainers, without ACK --> do sanity-checks but if all ok do nothing 4. file full bug, with all maintainers, with ACK, with deadline in future --> do sanity-checks but if all ok do nothing 5. file full bug, with all maintainers, with ACK, without deadline or one in past --> do sanity-checks, and CC all arch teams if ok Thank you for reading this wall of text. I wanted to give the most information that I could write so we have informative discussion. I also want to remind that in case you miss a feature, open a discussion or an issue at [1] - we all want to have better tooling for Gentoo. [1] https://github.com/mgorny/nattka [2] https://github.com/mgorny/nattka/commit/de12fad667c9239c757f4f637d17ceef159ad38b -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, Arch Teams, GURU) OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Announcing the Gentoo/LoongArch project
On 17/04/2022 18.33, WANG Xuerui wrote: > Hi everyone, > > A lot have happened since my last progress update regarding the > Gentoo/LoongArch port in January; among other things, I'm a Gentoo developer > now, so I got to edit the project page and announce it myself. :-) > > The project page is at https://wiki.gentoo.org/wiki/Project:LoongArch, where > I have collected some useful information for LoongArch development. > > > ## Trying out > > LoongArch hardware is probably hard to get outside of China, but usable QEMU > linux-user emulation is available via patched qemu package in the > loongson-overlay [1], so you can set up binfmt_misc and try out the stages > just like with any other chroot. Freshly built stages can be downloaded from > several mirrors (all hosted in China though), you can find the links on the > project page. > > > ## State of various fundamental packages > > Both binutils and gcc have the LoongArch support upstreamed, although > binutils still needs some patching for now, for spec conformance. So we're > basically only waiting for linux and glibc. The Linux port is likely 5.19 > material [2], and glibc should follow that; this means we're likely starting > with Linux 5.19, binutils 2.38 (patched), gcc 12.1.0 and glibc 2.36. > > > ## Roadmap update > > Now that I have verified everything with stage builds and installation on > real Loongson 3A5000 hardware, I plan to first upstream the profiles and > toolchain bits to ::gentoo. After that, I'll handle the keywording and > porting/testing of packages for loong, just like any other arch; upstreaming > the various patches one by one, while doing all these. > > As with all other arches, the project would need an email alias; because it's > ARCH=loong, the alias should look like loong@g.o. An IRC channel would be nice > but I doubt how many people would converse there -- we could probably do > without one for now. > > > I'll happily help if you are interested in this niche architecture; feel free > to reach out via mail or IRC. Well, I will gladly help with keywording and testing of packages if I could have access to some devbox (as with all arch teams I'm on). I know this is a *very* future talk, but just know that if we have a devbox Gentoo developers can ssh into, quite fastly we join to help :) For now let me just send you good luck - maintaining arches is quite fun and fulfilling :) > > [1]: https://github.com/xen0n/loongson-overlay > [2]: https://www.spinics.net/lists/linux-arch/msg76936.html > > -- > WANG Xuerui > xe...@gentoo.org > Gentoo Linux developer > PGP: 7C52 19E3 26A0 7311 3EA3 8806 C01F 7214 BC93 1414 > -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, GURU, Arch Teams) OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC] dev-python/namespace-* retirement plan
On 09/04/2022 18.20, Michał Górny wrote:
> Hi, everyone.
>
> TL;DR I think I came up with a feasible plan towards cleanly removing
> dev-python/namespace-* packages that aren't technically needed anymore
> with modern versions of Python.
>
>
> What are namespace packages? Let's take "zope" as an example.
> Normally, various subpackages like "zope.interface" and
> "zope.configuration" would have all to be present in a single directory,
> that is inside the "zope" package. However, if "zope" is made a
> namespace package, its subpackages can be loaded from different
> locations. Notably, in order to test zope.configuration prior to
> installing it, we load it from build tree but its dependency
> zope.interface from system site-packages.
>
> Historically, for this to work, the "zope/__init__.py" had to specify
> some magic incantations. On Gentoo, we've added dev-python/namespace-*
> that installed these magical "__init__.py" files and made all
> subpackages (e.g. dev-python/zope-*) depend on it.
>
> However, Python 3.3 introduced PEP 420 implicit namespaces that made
> magical incantations unnecessary -- if "zope" didn't include
> "__init__.py", it was implicitly treated as a namespace. Unfortunately,
> there were some interoperability issues between the two kinds of magical
> incantations and implicit namespaces. So while we were able to retire
> pkgutil-style namespaces, setuptools-style namespaces remained.
>
> I think we can change that now.
>
>
> I've done some experiments, particularly with dev-python/zope-interface
> and dev-python/zope-configuration. If nobody finds a problem with this
> solution, I think we can aim to bump all packages relying on namespaces
> and retire them in 1-2 months.
>
> The rough idea is to remove RDEP on dev-python/namespace-* from
> the package, and updating python_test to use a temporary pkgutil-style
> incantation (yes, for setuptools-style packages), e.g.:
>
> ```
> python_compile() {
> distutils-r1_python_compile
> find "${BUILD_DIR}" -name '*.pth' -delete || die
> }
>
> python_test() {
> cd "${BUILD_DIR}/install$(python_get_sitedir)" || die
> # this is needed to keep the tests working while
> # dev-python/namespace-zope is still installed
> cat > zope/__init__.py <<-EOF || die
> __path__ = __import__('pkgutil').extend_path(__path__,
> __name__)
> EOF
> eunittest
> rm zope/__init__.py || die
> }
> ```
I quite like that we make the "hack" more local, just in test phase. But
I think this code is quite error prone, and an easy mistake can be made
if someone copies it incorrectly.
Is it possible to add an eclass function to auto create and cleanup this
file, and all I need to do is to pass it the correct namespace ("zope"
in above example)?
Also, by using a common function name, it would be easy to fix it if we
did a mistake and find all consumers when we feel safe to cleanup this code.
One point of failure for this function is how to do the auto cleanup? I
was thinking using environment variables to hold our added magic names,
which is created before `python_test` call and cleans after it is done.
I really prefer if we could call it during prepare phase (so we can
still use auto generated d_e_t calls).
> ...
>
> WDYT?
>
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, GURU, Arch Teams)
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] New Developer: WANG Xuerui (xen0n)
On 19/03/2022 08.44, Gokturk Yuksek wrote: > Hi all, > > It is my pleasure to announce the latest developer addition to our > family: WANG Xuerui. Here is how he describes himself: > > "I'm a software developer from Shanghai, China, and a happy Gentoo user > since 2011. Some of you may already know me via the loongson-overlay, > ARCH=loong bringup patches, or the scattered MIPS bugs and patches over > the years. I'm very glad to be able to join the Gentoo family and help > making my favorite distro even better. I plan to first focus on bringing > up ARCH=loong, generally improving the experience for Loongson hardware > users, then use the expertise to help other ports as well. Hope my MIPS > and RISC-V knowledge (and collection of hardware) will help!" > > We also reached out to his cat for comments and here is how his cat > describes him: > > "Some humans describe Xuerui as a "multipotentialite", and he indeed has > a diverse range of interests. When I am not utilizing the keyboard, he > is allowed to lurk in various open-source projects and randomly review > code/docs on the computer. When his services are no longer necessary, I > allow him to enjoy playing rhythm games, attending live events, and > hanging out with friends." > > Please give him a warm Gentoo welcome! Welcome to the team. Happy to see you here in Gentoo. First time I saw a cat describing a person, in that precise way. Your cat is very smart and nice! -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, GURU, Arch Teams) OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Deprecating repoman
On 11/03/2022 21.51, Joshua Kinard wrote: > On 3/11/2022 13:25, Alec Warner wrote: > > [snip] > >> >> The new workflow with pkgcheck was announced at the end of 2019: >> https://blogs.gentoo.org/mgorny/2019/12/12/a-better-ebuild-workflow-with-pure-git-and-pkgcheck >> >> It's been 2 years, I think we can bring everyone into the fold here. > > I've searched my -dev archives for part of that URL, and the only hits I am > getting is this e-mail thread. Was this URL previously shared on this > mailing list or another? I do not track the Gentoo Blogs, so unless > something is shared to the mailing lists, I will likely miss it. > > That said, I will admit I am uncomfortable with post-commit, pre-push > validation. I get that git is vastly different, and vastly superior, to > CVS. Get it right the first time, and you don't have to worry about fixing > it later -- CVS teaches you that very well, and it still works well for git > workflows. Going back into git post-commit to fix things is still something > I need to learn more about, as my git-fu is still pretty amateurish beyond > the common basics. Especially when dealing with kernel patch maintenance > and maintaining lots of small, discrete changes that kernel upstream prefers. > Just to note, when using pkgdev, I use mainly the command `pkgdev commit -as`, which stands for auto add files in current working pkg and run scan *before commit* - which is identical to `repoman full -dx`. I think I'm going to add configuration mode to pkgdev, so you can set scan mode to on by default (you can pass `--scan false` to disable it). -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, GURU) OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-mobilephone/adb-sync
# Arthur Zamarin (2021-11-19) # Doesn't work with latest versions of adb, source not easily ported # to python 3.9 and 3.10. No upstream activity for 7 years. # Removal on 2021-12-19. Bug #825038. app-mobilephone/adb-sync OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/cheetah-docs
# Arthur Zamarin (2021-10-22) # EAPI=5, no revdeps, dead upstream. As documentation only package, # upstream isn't even closely updated to latest API by cheetah. # Removal on 2021-11-21. Bug #819504. dev-python/cheetah-docs OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/python-ceilometerclient
# Arthur Zamarin (2021-10-10) # Archived upstream, and no longer maintained. Has issues with # python 3.9 and python 3.10. # Extra bugs: #798348 #798351 #812908 # Removal on 2021-11-09. Bug #817401. dev-python/python-ceilometerclient -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, GURU) OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/onkyo-eiscp
# Arthur Zamarin (2021-10-10) # Inactive upstream with reported bugs. Has issues with python 3.9 # and python 3.10. # Extra bugs: #798252 #812734 # Removal on 2021-11-09. Bug #817392. dev-python/onkyo-eiscp -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, GURU) OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/ptvsd
# Arthur Zamarin (2021-10-10) # Archived upstream repo, and deprecated by Microsoft. Doesn't work # with the latest Visual Studio. Has issues with python 3.9 and # python 3.10. # Extra bugs: #798192 #723741 #727212 #730330 # Removal on 2021-11-09. Bug #817389. dev-python/ptvsd -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, GURU) OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/pipfile
# Arthur Zamarin (2021-10-10) # Inactive upstream with reported bugs. Has issues with python 3.9 # and python 3.10. # Removal on 2021-11-09. Bug #817386. dev-python/pipfile -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, GURU) OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-db/sadisplay
# Arthur Zamarin (2021-10-10) # Upstream lost to history. Web archive finds a very broken repo. # Has issues with python 3.9 and python 3.10. # Extra Bugs: #696674, #814572 # Removal on 2021-11-09. Bug #817383. dev-db/sadisplay -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, GURU) OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-vcs/github-pages-publish
# Arthur Zamarin (2021-10-10) # Old project, has problems with symlinks in repo. Fails for new # GitHub projects. # Removal on 2021-11-09. Bug #817380. dev-vcs/github-pages-publish -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, GURU) OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] distutils-r1.eclass: fix formatting
On 9/25/21 9:28 PM, Arthur Zamarin wrote:
> - mark _distutils-r1_check_all_phase_mismatch as @INTERNAL
> - fix list appearance for distutils_enable_tests options
>
> Signed-off-by: Arthur Zamarin
> ---
> eclass/distutils-r1.eclass | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index 1326809a8..3513a74c4 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -369,8 +369,11 @@ distutils_enable_sphinx() {
> # of RDEPEND to test?-BDEPEND. The test-runner argument must be one of:
> #
> # - nose: nosetests (dev-python/nose)
> +#
> # - pytest: dev-python/pytest
> +#
> # - setup.py: setup.py test (no deps included)
> +#
> # - unittest: for built-in Python unittest module
> #
> # Additionally, if --install is passed as the first parameter,
> @@ -618,6 +621,7 @@ _distutils-r1_handle_pyproject_toml() {
> }
>
> # @FUNCTION: _distutils-r1_check_all_phase_mismatch
> +# @INTERNAL
> # @DESCRIPTION:
> # Verify whether *_all phase impls is not called from from non-*_all
> # subphase.
>
Merged
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, GURU)
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] [PATCH] distutils-r1.eclass: fix formatting
- mark _distutils-r1_check_all_phase_mismatch as @INTERNAL
- fix list appearance for distutils_enable_tests options
Signed-off-by: Arthur Zamarin
---
eclass/distutils-r1.eclass | 4
1 file changed, 4 insertions(+)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 1326809a8..3513a74c4 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -369,8 +369,11 @@ distutils_enable_sphinx() {
# of RDEPEND to test?-BDEPEND. The test-runner argument must be one of:
#
# - nose: nosetests (dev-python/nose)
+#
# - pytest: dev-python/pytest
+#
# - setup.py: setup.py test (no deps included)
+#
# - unittest: for built-in Python unittest module
#
# Additionally, if --install is passed as the first parameter,
@@ -618,6 +621,7 @@ _distutils-r1_handle_pyproject_toml() {
}
# @FUNCTION: _distutils-r1_check_all_phase_mismatch
+# @INTERNAL
# @DESCRIPTION:
# Verify whether *_all phase impls is not called from from non-*_all
# subphase.
--
2.33.0
Re: [gentoo-dev] [PATCH 1/2] bzr.eclass: Reinstate eclass
ZR_REPO_URI}"
"${branch_dir}"
+ fi
This logic maybe can be improved and made easier, by defaulting
EBZR_INITIAL_URI to be by default EBZR_REPO_URI (as a result, the first
call to bzr_initial_fetch can be done outside the if), and if the ebuild
writer changed it (check using the if here), then do the next bzr_update.
Or another option, instead of setting by default, do the first fetch as:
bzr_initial_fetch "${EBZR_INITIAL_URI:-${EBZR_REPO_URI}}" "${branch_dir}"
But I think this one is less readable.
+ fi
+ else
+ bzr_update "${EBZR_REPO_URI}" "${branch_dir}"
+ fi
+
+ # Restore sandbox environment and umask
+ SANDBOX_WRITE=${save_sandbox_write}
+ if [[ -n ${save_umask} ]]; then
+ umask "${save_umask}" || die
+ fi
+
+ cd "${branch_dir}" || die "${EBZR}: can't chdir to ${branch_dir}"
+
+ # Save revision number in environment. #311101
+ export EBZR_REVNO=$(${EBZR_REVNO_CMD})
+
+ if [[ -n ${EBZR_WORKDIR_CHECKOUT} ]]; then
+ einfo "checking out ..."
+ ${EBZR_CHECKOUT_CMD} ${EBZR_REVISION:+-r ${EBZR_REVISION}} \
+ . "${EBZR_UNPACK_DIR}" || die "${EBZR}: checkout failed"
+ else
+ einfo "exporting ..."
+ ${EBZR_EXPORT_CMD} ${EBZR_REVISION:+-r ${EBZR_REVISION}} \
+ "${EBZR_UNPACK_DIR}" . || die "${EBZR}: export failed"
+ fi
+ einfo \
+ "revision ${EBZR_REVISION:-${EBZR_REVNO}} is now in
${EBZR_UNPACK_DIR}"
+
+ popd > /dev/null || die "${EBZR}: popd failed"
+}
+
+# @FUNCTION: bzr_src_unpack
+# @DESCRIPTION:
+# Default src_unpack(), calls bzr_fetch.
+bzr_src_unpack() {
+ bzr_fetch
+}
Thank you for working on it!
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, GURU)
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/oset
# Arthur Zamarin (2021-09-11) # # No reverse dependencies. Implements ordered set, which was needed # for the python 2.6 era, and since python 2.7 isn't needed and is # builtin in the language. Upstream isn't active at all. # No other distros package it anymore. # # Removal on 2021-10-11. Bug #812554 -- Arthur Zamarin OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/py-gfm
# Arthur Zamarin (2021-09-11) # # No reverse dependencies. Has issues with porting to python 3.10. # Has known upstream issues with latest GitHub's markdown parsing. # Last year upstream planned to archive the repository, no activity # since. No other distros package it anymore. # Extra bug: #798195 # # Removal on 2021-10-11. Bug #812530 -- Arthur Zamarin OpenPGP_signature Description: OpenPGP digital signature
