[gentoo-dev] Last rites: sys-apps/salinfo
# Arthur Zamarin (2024-09-07) # ia64 only package. Since we drop ia64, we can remove this package. # Removal on 2024-10-07. Bug #939298. sys-apps/salinfo OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Request for Feedback on Java Package Usage on 32 bit arches
Hi everyone, Over the past year, our Java project has faced significant challenges with stabilizing and re-keywording Java packages on both ARM and x86 architectures. These issues, including failing tests and jar miscompiles, have placed a considerable burden on the volunteers maintaining the project. As a member of the architecture team, I believe this situation is unsustainable. To better understand the impact, I’d like to gather information on whether Java packages are being used on your systems, specifically if you're running x86 or ARM architectures. You can check for Java libraries by running the following command:: qlist -I | grep dev-java This will list the Java packages installed on your system, and from there, you can identify the primary consumers of Java in your environment. Please reply to this email with top level consumers (which packages are part of @world package set). While I can't guarantee continued support for Java on x86/ARM due to the current volume of issues, knowing that there is no need for support will help us make more informed decisions and ease the process of addressing these concerns. -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Council, Python, pkgcore stack, QA, Arch Teams) OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: media-sound/SmarTagger
# Arthur Zamarin (2024-08-11) # HOMEPAGE and SRC_URI return 404, Gentoo is last distribution. # Removal on 2024-09-10. Bugs #937775, #675028. media-sound/SmarTagger OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH] 2024-08-07-removal-ia64: add news item
Signed-off-by: Arthur Zamarin --- .../2024-08-07-removal-ia64.en.txt| 34 +++ 1 file changed, 34 insertions(+) create mode 100644 2024-08-07-removal-ia64/2024-08-07-removal-ia64.en.txt diff --git a/2024-08-07-removal-ia64/2024-08-07-removal-ia64.en.txt b/2024-08-07-removal-ia64/2024-08-07-removal-ia64.en.txt new file mode 100644 index 000..cbb4ba1 --- /dev/null +++ b/2024-08-07-removal-ia64/2024-08-07-removal-ia64.en.txt @@ -0,0 +1,34 @@ +Title: Gentoo drops IA-64 support +Author: Arthur Zamarin +Posted: 2024-08-07 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/ia64/17.0 +Display-If-Profile: default/linux/ia64/17.0/desktop +Display-If-Profile: default/linux/ia64/17.0/desktop/gnome +Display-If-Profile: default/linux/ia64/17.0/desktop/gnome/systemd/merged-usr +Display-If-Profile: default/linux/ia64/17.0/developer +Display-If-Profile: default/linux/ia64/17.0/systemd/merged-usr +Display-If-Profile: default/linux/ia64/23.0 +Display-If-Profile: default/linux/ia64/23.0/desktop +Display-If-Profile: default/linux/ia64/23.0/desktop/gnome +Display-If-Profile: default/linux/ia64/23.0/desktop/gnome/systemd +Display-If-Profile: default/linux/ia64/23.0/systemd +Display-If-Profile: default/linux/ia64/23.0/split-usr +Display-If-Profile: default/linux/ia64/23.0/split-usr/desktop +Display-If-Profile: default/linux/ia64/23.0/split-usr/desktop/gnome + +Following the removal of IA-64 support in the Linux kernel and glibc, +and subsequent discussions on our mailing list [1], as well as a vote +by the Gentoo Council [2,3], Gentoo will discontinue all ia64 profiles +and keywords. The primary reason for this decision is the inability of +the Gentoo IA-64 team to support this architecture without kernel +support, glibc support, and a functional development box. + +In one month, all ia64 profiles will be removed, all ia64 keywords will +be dropped from all packages, and all IA-64 related Gentoo bugs will be +closed. + +[1] https://public-inbox.gentoo.org/gentoo-dev/75654daa-c5fc-45c8-a104-fae43b9ca...@gentoo.org/T/ +[2] https://projects.gentoo.org/council/meeting-logs/20240721.txt +[3] https://projects.gentoo.org/council/meeting-logs/20240721-summary.txt -- 2.45.2
[gentoo-dev] [Proposal] Split arch keywords for ppc64 & riscv
Hi all As continuation from previous arch changes and arch status [1], I want to propose the next arch change for the near council meeting: a. Splitting ppc64 keyword into ppc64 and ppc64le Currently the ppc64 arch keyword matches both big endian (ppc64ul) and little endian (ppc64le). While there are similarities, there is quite a big gap in support level across both of them. If I understand the history correctly, ppc64le is the "next gen" after ppc64ul, and it is seen across upstream support, and as a result in the masks. We have many masks on the ppc64 profile, which are there for ppc64ul, and then unmasks for ppc64le. This split of keywords should make it easier for ppc64 maintainers (since less ugliness in profiles), package maintainers (simpler to mark ppc64le only), and for ppc64 users (easier to request keyword for only one side, so no need to handle issues on the other "arch"). I want both arches to be of same state (stable arches, with profiles remaining at current state). b. Splitting riscv keyword into riscv and riscv32 I'm not part of the riscv arch team, but I understood from dilfridge that riscv64 and riscv32 are very different, and having both behind the same keyword creates various issues. Since I already propose spliting ppc64, we can also split riscv on the same wave. [1] https://public-inbox.gentoo.org/gentoo-dev/75654daa-c5fc-45c8-a104-fae43b9ca...@gentoo.org/T/ -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Council, Python, pkgcore stack, QA, Arch Teams) OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: www-apps/rt
# Arthur Zamarin (2024-07-27) # EAPI=6 package, awaits version bump. # Removal on 2024-08-26. Bug #936756. www-apps/rt ### Some extra notes: There is open PR [1] for handling that, on which the maintainer responded 2 times, but even after 2 pings from me, haven't merged it yet. Merging the PR (if tested and it works and the maintainer ACKs) is good enough to un-last-rite. [1] https://github.com/gentoo/gentoo/pull/36737 OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-debug/gdb-apple
# Arthur Zamarin (2024-07-27) # EAPI=6, awaits version bump. This is *-macos prefix only package, so # hard to verify EAPI bump without the maintainer. # Removal on 2024-08-26. Bug #936755. dev-debug/gdb-apple OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: media-video/raspberrypi-omxplayer
# Arthur Zamarin (2024-07-20) # EAPI=6, fails to apply patch during src_prepare. # Removal on 2024-08-19. Bugs #936398, #908957, #908959. media-video/raspberrypi-omxplayer OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: mail-filter/couriersrs
# Arthur Zamarin (2024-07-20) # EAPI=6 package, no reverse dependencies, not maintained in Gentoo for # a long time. # Removal on 2024-08-19. Bugs #936397, #715284, #832000. mail-filter/couriersrs OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: games-*/* EAPI=6 packages
# Arthur Zamarin (2024-07-19) # EAPI=6 games. Feel free to drop any package after bumping it's EAPI. # Removal on 2024-08-18. Bug #936299. games-arcade/sdl-sopwith games-arcade/syobon games-arcade/wop games-mud/crystal games-mud/gmudix games-mud/kildclient games-puzzle/color-lines games-puzzle/einstein games-puzzle/hangman games-puzzle/magiccube4d games-puzzle/scramble games-puzzle/zaz games-rpg/xu4 games-server/monopd games-simulation/cannonsmash games-strategy/crimson OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: gui-wm/hikari
# Arthur Zamarin (2024-07-13) # Maintainer-needed, depends on very old gui-libs/wlroots version, # no activity upstream since Jan 2022. # Removal on 2024-08-12. Bugs #935921, #867808. gui-wm/hikari OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-i18n/fcitx-rime, app-i18n/ibus-rime, app-i18n/rime-data
# Arthur Zamarin (2024-07-05) # rime-data is EAPI=6, and with it last-rite it's reverse-dependencies. # Removal on 2024-08-04. Bugs #93, #935155, #695056, #924139. app-i18n/fcitx-rime app-i18n/ibus-rime app-i18n/rime-data OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: media-video/luvcview
# Arthur Zamarin (2024-07-05) # EAPI=6, no reverse dependencies, various issues with modern C. # Removal on 2024-08-04. Bugs #935553, #875746, #875245, #731094. media-video/luvcview OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-libs/minuit
# Arthur Zamarin (2024-07-05) # EAPI=6, no reverse dependencies, fails tests. # Removal on 2024-08-04. Bugs #935549, #873463, #741508. sci-libs/minuit OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-astronomy/esomidas
# Arthur Zamarin (2024-07-05) # EAPI=6, many compilation and configure issues, more QA issues. # Removal on 2024-08-04. Bugs #935545. sci-astronomy/esomidas OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-project] Council meeting 2024-07-21 - call for agenda items
On 02/07/2024 22.30, Ulrich Mueller wrote: > ... > > The agenda is still open for additional items that the council should > discuss or vote on. For agenda items, please respond to this message > on the gentoo-project mailing list. I want to pass the first plan from previous thread about the Various Gentoo Arches statuses [1], mainly the changes which aren't controversial. I have plan for next meetings, but the next steps warrant more talks in ML. I think those should be separate motions, but I leave this decision to the chairman. a. `alpha - make profile stable` Thanks to matoro's work, alpha dep-tree is nearly done (the latest breakage occurred since last check, so we can say we can get a stable tree). He is responsive for issues and pings, so I believe we can trust this arch. I propose we pass make the alpha profile stable (I mean profile stable, not arch stable). We will apply the motion the moment he finishes fixing the tree (otherwise if we wait, we risk breaking it again without noticing). b. `ia64 - deprecate arch` We don't believe in the possibility of continuing supporting this arch (drop from kernel & glibc, issues with devbox). I think the normal deprecation period of 1 year is fine here. c. `ppc64/32ul - shorten deprecation period` By this "arch" I mean the 32-bit userland on 64 bit kernel. None need it, mostly broken, and all hardware that might need it has better state (normal 64 bit userland). Currently all profiles are 17.0 and deprecated, but I want to ask we shorter the period, since removing it helps a lot in cleanup of ppc64 profiles mess and future keyword split. I think 2 month from motion pass should be good enough? d. `sparc32 - deprecate profiles` Various reasons stated in email thread [1], no opposition. I would like to request shorter window from 1 year, to around 3 month? For an unused profile, I don't think we need to wait the full time? This means all the user facing profiles of: ``` default/linux/sparc default/linux/sparc/17.0 default/linux/sparc/17.0/desktop default/linux/sparc/17.0/developer default/linux/sparc/17.0/systemd/merged-usr default/linux/sparc/23.0 default/linux/sparc/23.0/desktop default/linux/sparc/23.0/systemd default/linux/sparc/23.0/split-usr default/linux/sparc/23.0/split-usr/desktop ``` e. `s390 not s390x - deprecate profiles` I mean here the s390 not s390x variant (confusing), which is the 31 bit variant. Various reasons stated in email thread [1], no opposition. This means all the user facing profiles of: ``` default/linux/s390/17.0 default/linux/s390/17.0/systemd/merged-usr default/linux/s390/23.0 default/linux/s390/23.0/systemd default/linux/s390/23.0/split-usr ``` [1] https://public-inbox.gentoo.org/gentoo-dev/75654daa-c5fc-45c8-a104-fae43b9ca...@gentoo.org/T/ -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Council, Python, pkgcore stack, QA, Arch Teams) OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Arch Status and Future Plans
as mass work. hppa Sigh. Stable 64-bit arch. Out main Gentoo devbox died, and the second one is always stuck compiling gcc for stage3 (a compilation takes 7 days). Here we have a fight in Arch Team. I prefer to destable it, Sam prefers to stable it. This one is tough. ia64 Dev 64-bit arch. Kernel dropped support, glibc dropped support, devbox died - days are short before full exp status or full removal of arch. s390 Dev arch. Has 2 sub-arches: s390 (32-bit) and s390x (64-bit). The latter works well for its job, a good devbox. For s390 32-bit we want to drop the profile, to simplify the profile mess it has (mask&unmasks) for packages that work for 64-bit (like all the rust stuff) and 32-bit stuff (inherits wd40 profile). loong Dev arch. I have no info on it, but it works. Let's not touch :) riscv Dev arch. I don't have much info on it, but I heard some mess with riscv32 and riscv64, so maybe time to split it? I leave it to riscv arch team, which works quite well, but I'll be happy to open discussion for it. alpha Exp arch, with nearly (or maybe already) full correct dep-tree. matoro did a lot of great work here, so I think we should promote it to dev arch, so dep-tree remains unbroken. We dekeyworded a lot of stuff, cleaned it up, so a nice "completion bonus". m68 Exp arch, works ? maybe? I've no idea. Let's not touch :) ==== mips ==== Exp arch, with mostly good dep-tree. Does mips team want to make it dev arch? -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, pkgcore stack, QA, Arch Teams, GURU) OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-astronomy/scamp
# Arthur Zamarin (2024-06-23) # EAPI=6, waiting for a version bump, no reverse-dependencies. # Removal on 2024-07-23. Bugs #934756, #924303. sci-astronomy/scamp OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-libs/h5hut
# Arthur Zamarin (2024-06-22) # EAPI=6, no reverse-dependencies, various issues with modern C, # installs libtools files. # Removal on 2024-07-22. Bugs #934689, #741440, #849920, #832789, # #862714, #828579. sci-libs/h5hut OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-libs/coinor-os
# Arthur Zamarin (2024-06-22) # EAPI=6, failing tests, fails to compile in various envs, various # QA issues. # Removal on 2024-07-22. Bugs #934687, #928028, #862687, #836104, # #741430, #811561, #526442. sci-libs/coinor-os OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-astronomy/aatm
# Arthur Zamarin (2024-06-21) # EAPI=6, not maintained in gentoo for a long time, fails to # configure. # Removal on 2024-07-21. Bugs #934680, #677444, #898100. sci-astronomy/aatm OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites EAPI=6 packages: dev-php/*
# Arthur Zamarin (2024-06-21) # Last dev-php/* EAPI=6 packages, and reverse dependencies of them. # composer has active security vulnerabilities. Others are waiting # for version bumps, and unbundling of dependencies. # Removal on 2024-07-21. Bugs #934666. dev-php/phpDocumentor dev-php/phpcov dev-php/phpdepend dev-php/phpdocumentor-reflection-common dev-php/phpdocumentor-reflection-docblock dev-php/phpdocumentor-type-resolver dev-php/stringparser_bbcode dev-php/symfony-config dev-php/symfony-console dev-php/symfony-dependency-injection dev-php/symfony-event-dispatcher dev-php/symfony-yaml dev-php/composer OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-debug/ald
# Arthur Zamarin (2024-06-20) # EAPI=6, keyworded for x86 only (making it hard to debug), has # open bugs for modern C and not using correct toolchain commands. # Removal on 2024-07-20. Bugs #934621, #925090, #724078, #727438. dev-debug/ald OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: media-gfx/dawn
# Arthur Zamarin (2024-06-20) # EAPI=6, no reverse dependencies, waiting for a version bump. # Removal on 2024-07-20. Bugs #934619, #730758, #713760. media-gfx/dawn OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v4] greadme.eclass: new eclass
On 18/06/2024 17.53, Florian Schmaus wrote:
> On 18/06/2024 16.02, Ulrich Mueller wrote:
>>>>>>> On Tue, 18 Jun 2024, Florian Schmaus wrote:
>>>>> Finally, unlike readme.gentoo-r1.elcass, this eclass does not need
>>>>> to store the content of the readme in an environment variable. Not
>>>>> having to store the content in an environment variable reduces the
>>>>> pollution of the environment (sadly, this only refers to the process
>>>>> environment).
>>
>>>> I'll be honest, I never felt this is really needed? From looking at
>>>> the current -r1 eclass, you could define DOC_CONTENTS just before
>>>> invoking readme.gentoo_create_doc, so you could for example modify as
>>>> you want the message and use `local DOC_CONTENTS="..."`.
>>
>>> readme.gentoo-r1.eclass requires DOC_CONTENTS to be part of the
>>> package's environment to show it later in readme.gentoo_print_elog(),
>>> which is typically invoked in pkg_postinst(). If DOC_CONTENTS is local
>>> to readme.gentoo_create_doc(), then it wont be able in pkg_postinst()
>>> and can potentially not be obtained from the README.gentoo file
>>> because that file may be compressed.
>>
>>> For greadme.eclass, the file is no longer compressed, therefore
>>> greadme.eclass does not need to carry a variable in the package's
>>> environment.
>>
>> These are two different variables that must not be confused
>>[DOC_CONTENTS vs README_GENTOO_DOC_VALUE].
>
> Thanks for pointing this out. I think I understand now what arthur is
> asking for:
>
> src_install() {
> ...
> local DOC_CONTENTS="My README.Gentoo contents"
> readme.gentoo_create_doc
> }
>
> @arthur: is that right?
yes, exactly. Please, I suggest going over the existing eclass, you
might get surprised how much is supported already.
> If so, then we could always add such an API to greadme.eclass too.
> However, it appears that it simply would duplicate what can already be
> done via greadme_stdin. Is there a compelling reason for such an API
> that I am missing?
>
> In any case, I wouldn't be opposed to implement something like this if
> somebody asks for it.
I think you are looking at it from the wrong side. Thinking in this
"impl" possible now, I think *you* are duplicating work stuff which was
supported in readme.gentoo-r1. I don't see anything supportted by
greadme_stdin and unsupported with this `local DOC_CONTENTS` stuff.
What I'm trying to push you into, is understanding if you really need a
new eclass. With all of those things, I believe greadme eclass is just a
duplicate.
I think if there is a small thing you want to have in -r1 eclass, it is
already supported or easily added. The support for a $FILESDIR is
something I see more rare than direct DOC_CONTENTS (in global as common,
and as local as a possible way).
>
>> BTW, I like readme.gentoo-r1's autoformatting, because the message may
>> contain variables (like paths containing EPREFIX) that can expand to
>> different lengths.
>
> Happy to add it.
>
> Any preference regarding the auto-formatting tool? The
> readme.gentoo-r1.eclass uses fold, but fmt (both are in coreutils) would
> probably also be an option (and has a --uniform-spacing option ;)).
>
>
> - Flow
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, QA, Arch Teams, GURU)
OpenPGP_signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-print/kyocera-1x2x-mfp-driver
# Arthur Zamarin (2024-06-17) # EAPI=6, fetch restricted with source gone. # Removal on 2024-07-17. Bug #934456. net-print/kyocera-1x2x-mfp-driver OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v4] greadme.eclass: new eclass
check_live_doc_file ${replaced_version}
> +
> + # Once _GREADME_SHOW is non empty, we found a reason to show the
> + # readme and we can abort the loop.
> + if [[ -n ${_GREADME_SHOW} ]]; then
> + break
> + fi
> + done
> +}
> +
> +# @FUNCTION: greadme_pkg_postinst
> +# @DESCRIPTION:
> +# Conditionally shows the contents of the readme doc via elog.
> +greadme_pkg_postinst() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + if [[ ! -v _GREADME_SHOW ]]; then
> + die "_GREADME_SHOW not set. Did you call greadme_pkg_preinst?"
> + fi
> +
> + if [[ -z ${_GREADME_SHOW} ]]; then
> + # If _GREADME_SHOW is empty, then there is no reason to show
> the contents.
> + return
> + fi
> +
> + local greadme="${EROOT}${_GREADME_REL_PATH}"
> +
> + if [[ ! -f ${greadme} ]]; then
> + ewarn "Unable to show ${_GREADME_FILENAME}, file not installed
> (FEATURES=nodoc enabled?)."
> + return
> + fi
> +
> + local line
> + while read -r line; do elog "${line}"; done < "${greadme}"
> + elog ""
> + elog "(Note: Above message is only printed the first time package is"
> + elog "installed or if the message changes on update. Please look at"
> + elog "${EPREFIX}${_GREADME_REL_PATH} for future reference)"
> +}
> +
> +fi
> +
> +EXPORT_FUNCTIONS pkg_preinst pkg_postinst
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, QA, Arch Teams, GURU)
OpenPGP_signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-print/kyocera-1x2x-mfp-driver
# Arthur Zamarin (2024-06-15) # EAPI=6, fetch restricted, and the file not available to download # any more. # Removal on 2024-07-15. Bug #934368. net-print/kyocera-1x2x-mfp-driver OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-astronomy/predict
# Arthur Zamarin (2024-06-15) # EAPI=6, no reverse dependencies, not packaged on other distributions, # waiting for a version bump (which is hard since ebuild used debian # patches). Not really maintained in Gentoo for a long time. # Removal on 2024-07-15. Bugs #934366, #871378, #716084, #924302. sci-astronomy/predict OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-chemistry/xds-bin
# Arthur Zamarin (2024-06-15) # EAPI=6, no reverse dependencies, manifest doesn't match upstream. # Removal on 2024-07-15. Bugs #934365, #832746. sci-chemistry/xds-bin OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-electronics/vbs
# Arthur Zamarin (2024-06-14) # EAPI=6, many compilation issues, upstream is gone, not maintained for # many years. # Removal on 2024-07-14. Bugs #934240, #725472, #878061, #880493, #882223, #888970, #900679, #879759. sci-electronics/vbs OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-chemistry/namd
# Arthur Zamarin (2024-06-14) # EAPI=6, not maintained for ~7 years in gentoo, waiting for version # bump. Fetch restricted, and fails to build after manual fetch. # Removal on 2024-07-14. Bugs #934228, #686860, #686858, #686856. sci-chemistry/namd OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-chemistry/aqua, sci-chemistry/procheck
# Arthur Zamarin (2024-06-14) # EAPI=6, not maintained in Gentoo for a long time. procheck is # fetch restricted, and the file you download from upstream # doesn't match size and manifests. aqua depends on procheck. # Removal on 2024-07-14. Bugs #928067, #928068. sci-chemistry/aqua sci-chemistry/procheck OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: www-misc/log-toolkit
# Arthur Zamarin (2024-06-14) # EAPI=6, maintainer-needed, no reverse dependencies. # Removal on 2024-07-14. Bugs #934227, #898840. www-misc/log-toolkit OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-misc/blink1
# Arthur Zamarin (2024-06-13) # EAPI=6, maintainer-needed, waiting for a bump, various failures # with modern C. # Removal on 2024-07-13. Bugs #934200, #711348, #726634, #831750. app-misc/blink1 OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-misc/bfgminer
# Arthur Zamarin (2024-06-12) # EAPI=6, maintainer needed, no reverse dependencies. Not maintained in # gentoo for a long time. # Removal on 2024-07-12. Bugs #934156, #636422. net-misc/bfgminer OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-libs/o2scl
# Arthur Zamarin (2024-06-12) # EAPI=6, library with no reverse dependencies, fails tests, has # issues with modern C. # Removal on 2024-07-12. Bugs #934133, #725622, #813240. sci-libs/o2scl OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: dev-php/pear and friends
On 11/06/2024 14.54, Michael Orlitzky wrote:
> On 2024-06-11 07:11:06, Viorel Munteanu wrote:
>>
>> # Viorel Munteanu (2024-06-11)
>> # dev-php/pear, dev-php/PEAR-* and their reverse dependencies: mask for
>> removal
>> # in 30 days.
>> # They are all unmaintained, most of the ebuilds are still EAPI 6, and
>> together
>> # they have around 40 bugs.
>> # Removal: 2024-07-11. Bug #933998.
>> ...
>
> Some of these should be saved:
>
> * app-admin/drush is the last version of drush that works with
>Drupal-7.x (still supported upstream) and doesn't bundle a thousand
>dependencies. I've been patching it to avoid warnings with newer
>versions of PHP.
>
> * dev-php/PEAR-{Auth_SASL,Crypt_GPG,Mail_Mime,Net_IDNA2,Net_Sieve,
> Net_SMTP,Net_Socket,PEAR}
>are all used by Roundcube. Our ebuilds for mail-client/roundcube
>bundle them right now, but they can be unbundled (just rm -r
>the bundled copies). Afterwards these will have revdeps again.
>
> That subset should be relatively bug-free -- one of the authors of
> Roundcube maintains the PEAR packages that it needs. The rest are
> indeed obsolete AFAIK though.
Sounds good to me, then please make sure all that dependency tree needed
for those targets are EAPI bumped, and most QA warnings from pkgcheck
are handled. Currently those packages look unmaintained.
When you (or anyone else) handle those, we can un-last-rite that dep tree.
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, QA, Arch Teams, GURU)
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/2] common-lisp-3.eclass: Support EAPI 8
On 08/06/2024 22.40, Ulrich Müller wrote:
> Minor stylistic changes.
>
> Signed-off-by: Ulrich Müller
> ---
> eclass/common-lisp-3.eclass | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/eclass/common-lisp-3.eclass b/eclass/common-lisp-3.eclass
> index 26d31268a598..12c7221e41ce 100644
> --- a/eclass/common-lisp-3.eclass
> +++ b/eclass/common-lisp-3.eclass
> @@ -1,17 +1,17 @@
> -# Copyright 1999-2023 Gentoo Authors
> +# Copyright 1999-2024 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: common-lisp-3.eclass
> # @MAINTAINER:
> # Common Lisp project
> -# @SUPPORTED_EAPIS: 6 7
> +# @SUPPORTED_EAPIS: 6 7 8
> # @BLURB: functions to support the installation of Common Lisp libraries
> # @DESCRIPTION:
> # Since Common Lisp libraries share similar structure, this eclass aims
> # to provide a simple way to write ebuilds with these characteristics.
>
> case ${EAPI} in
> - 6|7) ;;
> + 6|7|8) ;;
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> esac
>
> @@ -121,7 +121,7 @@ common-lisp-install-sources() {
>
> local fpredicate=$(common-lisp-get-fpredicate "${ftype}")
>
> - for path in "${@}" ; do
> + for path ; do
> if [[ -f ${path} ]] ; then
> common-lisp-install-one-source ${fpredicate} "${path}"
> "$(dirname "${path}")"
> elif [[ -d ${path} ]] ; then
> @@ -148,7 +148,7 @@ common-lisp-install-sources() {
> # Installs ${1} asdf file in CLSOURCEROOT/CLPACKAGE and symlinks it in
> # CLSYSTEMROOT.
> common-lisp-install-one-asdf() {
> - [[ $# != 1 ]] && die "${FUNCNAME[0]} must receive exactly one argument"
> + [[ $# = 1 ]] || die "${FUNCNAME[0]} must receive exactly one argument"
>
> # the suffix «.asd» is optional
> local source=${1%.asd}.asd
> @@ -168,7 +168,7 @@ common-lisp-install-asdf() {
>
> [[ $# = 0 ]] && set - ${CLSYSTEMS}
> [[ $# = 0 ]] && set - $(find . -type f -name \*.asd)
> - for sys in "${@}" ; do
> + for sys ; do
> common-lisp-install-one-asdf ${sys}
> done
> }
LGTM, thanks!
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, QA, Arch Teams, GURU)
OpenPGP_signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Last rites: www-apps/wiliki
# Arthur Zamarin (2024-06-08) # EAPI=6, waiting for a version bump, not maintained for many years. # Removal on 2024-07-08. Bug #933850. www-apps/wiliki OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: www-apache/mod_authnz_external, www-apache/mod_authz_unixgroup, www-apache/mod_maxminddb, www-apache/mod_vdbh, www-apache/modsec-flameeyes
# Arthur Zamarin (2024-06-08) # Various apache modules with no reverse dependencies, EAPI=6, # some maintainer-needed. # Removal on 2024-07-08. Bug #933847. www-apache/mod_authnz_external www-apache/mod_authz_unixgroup www-apache/mod_maxminddb www-apache/mod_vdbh www-apache/modsec-flameeyes OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sys-power/powernowd
# Arthur Zamarin (2024-06-08) # EAPI=6, maintainer-needed, no reverse dependencies. # Removal on 2024-07-08. Bugs #933846, #598678, #916203. sys-power/powernowd OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-analyzer/check_mk_agent
# Arthur Zamarin (2024-06-08) # EAPI=6, no reverse dependencies, maintainer-needed, various QA issues. # Removal on 2024-07-08. Bugs #933843, #695068, #677432. net-analyzer/check_mk_agent OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: media-sound/herrie
# Arthur Zamarin (2024-06-08) # EAPI=6, no reverse dependencies, fails to compile with LLVM or musl, # various QA issues. # Removal on 2024-07-08. Bugs #933837, #832891, #740364, #751697, #403627. media-sound/herrie OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-libs/coinhsl
# Arthur Zamarin (2024-06-08) # EAPI=6, fetch restricted, waiting for a version bump. # Removal on 2024-07-08. Bug #933836. sci-libs/coinhsl OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-p2p/gnut
# Arthur Zamarin (2024-06-08) # EAPI=6, not maintained since cvs days. Keyworded for x86 and ppc # only. Fails to compile with modern C. # Removal on 2024-07-08. Bugs #933824, #927783. net-p2p/gnut OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-libs/h5part
# Arthur Zamarin (2024-06-07) # EAPI=6, no reverse dependencies, failing tests, various QA issues. # Removal on 2024-07-07. Bugs #933768, #849923, #882403, #837020, #741444, #831092, #862717. sci-libs/h5part OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-mail/gnubiff
# Arthur Zamarin (2024-05-31) # EAPI=6, maintainer-needed, incorrect LICENSE, fails to compile with # clang. # Removal on 2024-06-30. Bugs #933241, #889912, #880267, #562822. net-mail/gnubiff OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-emulation/phpvirtualbox
# Arthur Zamarin (2024-05-31) # EAPI=6, no activity upstream, maintianer-needed. # Removal on 2024-06-30. Bugs #933239, #828068. app-emulation/phpvirtualbox OpenPGP_signature.asc Description: OpenPGP digital signature
[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} "${@}"
- l
[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
[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
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
''
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
t I can't talk for them, so I'll be happy 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
