Re: [gentoo-dev] Package stabilization groups
On Mon, Jul 17, 2023 at 19:39:30 +0300, Arthur Zamarin wrote:
> 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.
>
/metadata/stable-goups/${group_name} perhaps? Then you can adapt Ionen's
example as:
$ cat /path/to/repo/metadata/stable-groups/qt
dev-qt/package
dev-qt/package2
Easy to read, easy to write :)
- Oskari
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
On Mon, Jul 17, 2023 at 4:27 PM Sam James wrote: > > Haven't we been keeping these because we still need to decide on a > > policy about what to do with dead acct-*/* packages? > > Right. https://bugs.gentoo.org/781881 is still open. Flow could ping > the QA team and ask if it should be closed, given the opinion there > seems to be that there's no need to keep them, but I think it's wrong > to do this pre-empting a policy decision, given it essentially forces > the "don't keep them" path. The bug has been open for several months without comment. If a policy were going to materialize, I think it would have happened by now. Forcing the issue by sending this last rites notice seems acceptable to me.
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
Matt Turner writes: > On Mon, Jul 17, 2023 at 3:43 PM Florian Schmaus wrote: >> >> # Florian Schmaus (2023-07-17) >> # Obsolete acct-* packages which became leaf packages. >> # Removal on 2023-08-17. >> acct-user/artifactory >> acct-group/artifactory >> acct-user/cinder >> acct-group/cinder >> acct-user/glance >> acct-group/glance >> acct-user/heat >> acct-group/heat >> acct-user/keystone >> acct-group/keystone >> acct-user/litecoin >> acct-group/litecoin >> acct-user/logcheck >> acct-group/logcheck >> acct-user/minbif >> acct-group/minbif >> acct-user/minio >> acct-group/minio >> acct-user/netbox >> acct-group/netbox >> acct-user/neutron >> acct-group/neutron >> acct-user/nova >> acct-group/nova >> acct-user/placement >> acct-group/placement >> acct-user/quagga >> acct-group/quagga >> acct-user/rplayd >> acct-group/rplayd >> acct-user/rstudio-server >> acct-group/rstudio-server >> acct-user/rundeck >> acct-group/rundeck >> acct-user/sguil >> acct-group/sguil >> acct-user/sigh >> acct-group/sigh >> acct-user/smokeping >> acct-group/smokeping >> acct-user/sobby >> acct-group/sobby >> acct-user/spread >> acct-group/spread >> acct-user/stg >> acct-group/stg >> acct-user/swift >> acct-group/swift >> acct-user/thttpd >> acct-group/thttpd >> acct-group/gpio >> acct-group/simplevirt >> acct-group/spi > > Haven't we been keeping these because we still need to decide on a > policy about what to do with dead acct-*/* packages? Right. https://bugs.gentoo.org/781881 is still open. Flow could ping the QA team and ask if it should be closed, given the opinion there seems to be that there's no need to keep them, but I think it's wrong to do this pre-empting a policy decision, given it essentially forces the "don't keep them" path. signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
On Mon, Jul 17, 2023 at 3:43 PM Florian Schmaus wrote: > > # Florian Schmaus (2023-07-17) > # Obsolete acct-* packages which became leaf packages. > # Removal on 2023-08-17. > acct-user/artifactory > acct-group/artifactory > acct-user/cinder > acct-group/cinder > acct-user/glance > acct-group/glance > acct-user/heat > acct-group/heat > acct-user/keystone > acct-group/keystone > acct-user/litecoin > acct-group/litecoin > acct-user/logcheck > acct-group/logcheck > acct-user/minbif > acct-group/minbif > acct-user/minio > acct-group/minio > acct-user/netbox > acct-group/netbox > acct-user/neutron > acct-group/neutron > acct-user/nova > acct-group/nova > acct-user/placement > acct-group/placement > acct-user/quagga > acct-group/quagga > acct-user/rplayd > acct-group/rplayd > acct-user/rstudio-server > acct-group/rstudio-server > acct-user/rundeck > acct-group/rundeck > acct-user/sguil > acct-group/sguil > acct-user/sigh > acct-group/sigh > acct-user/smokeping > acct-group/smokeping > acct-user/sobby > acct-group/sobby > acct-user/spread > acct-group/spread > acct-user/stg > acct-group/stg > acct-user/swift > acct-group/swift > acct-user/thttpd > acct-group/thttpd > acct-group/gpio > acct-group/simplevirt > acct-group/spi Haven't we been keeping these because we still need to decide on a policy about what to do with dead acct-*/* packages?
[gentoo-dev] Last rites: obsolete acct-* packages
# Florian Schmaus (2023-07-17) # Obsolete acct-* packages which became leaf packages. # Removal on 2023-08-17. acct-user/artifactory acct-group/artifactory acct-user/cinder acct-group/cinder acct-user/glance acct-group/glance acct-user/heat acct-group/heat acct-user/keystone acct-group/keystone acct-user/litecoin acct-group/litecoin acct-user/logcheck acct-group/logcheck acct-user/minbif acct-group/minbif acct-user/minio acct-group/minio acct-user/netbox acct-group/netbox acct-user/neutron acct-group/neutron acct-user/nova acct-group/nova acct-user/placement acct-group/placement acct-user/quagga acct-group/quagga acct-user/rplayd acct-group/rplayd acct-user/rstudio-server acct-group/rstudio-server acct-user/rundeck acct-group/rundeck acct-user/sguil acct-group/sguil acct-user/sigh acct-group/sigh acct-user/smokeping acct-group/smokeping acct-user/sobby acct-group/sobby acct-user/spread acct-group/spread acct-user/stg acct-group/stg acct-user/swift acct-group/swift acct-user/thttpd acct-group/thttpd acct-group/gpio acct-group/simplevirt acct-group/spi - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Package stabilization groups
On Mon, Jul 17, 2023 at 08:34:45PM +0300, Arthur Zamarin wrote: > 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? imo seeing/setting it all in one place is simpler, ultimately it's about managing a group (whole) and I don't think is super important on the individual packages. e.g. [qt] dev-qt/package dev-qt/package2 Can visualize and don't have to go set this in each one of them. fwiw repo-cd could be given a hook to grep that file, and be able to say that a package is part of a stabilization group -- and if nattka automatically looks at groups it'll also be hard to overlook when filing bugs. Regardless of approach, some kind of central file (generated or not) would certainly be nice not to end up grepping all metadata.xml in the tree to figure out which packages are part of a group. -- ionen signature.asc Description: PGP 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
Matt Turner writes: > 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. > > 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. > 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 signature.asc Description: PGP 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] [PATCH] git-r3.eclass: Use '__init__' as initial branch
On Mon, Jul 17, 2023 at 12:01 PM Ulrich Mueller wrote: > > > On Mon, 17 Jul 2023, konsolebox wrote: > > >> Maybe the commit message could shortly explain why this is needed, > >> or what problem is fixed by it? > > > It silences the default branch warning. > > Add this sentence to the commit message then? I will do that. > > If that's unwanted, kindly just close the issue. > > Huh? He's just saying if we don't want the patch, that's okay with him.
Re: [gentoo-dev] [PATCH] git-r3.eclass: Use '__init__' as initial branch
> On Mon, 17 Jul 2023, konsolebox wrote: >> Maybe the commit message could shortly explain why this is needed, >> or what problem is fixed by it? > It silences the default branch warning. Add this sentence to the commit message then? > If that's unwanted, kindly just close the issue. Huh?
Re: [gentoo-dev] [PATCH] git-r3.eclass: Use '__init__' as initial branch
On Mon, Jul 17, 2023, 22:53 Ulrich Mueller, wrote: > > On Mon, 17 Jul 2023, Matt Turner wrote: > > > From: konsolebox > > Closes: https://bugs.gentoo.org/841392 > > Signed-off-by: Matt Turner > > Maybe the commit message could shortly explain why this is needed, > or what problem is fixed by it? > It silences the default branch warning. If that's unwanted, kindly just close the issue. >
Re: [gentoo-dev] [PATCH] meson.eclass: allow disabling verbose compilation
On Mon, Jul 17, 2023 at 10:56 AM Adrian Schollmeyer wrote:
> Am Montag, dem 17.07.2023 um 10:51 -0400 schrieb Matt Turner:
> > This works similar to cmake.eclass's ${CMAKE_VERBOSE}.
>
> Why not use MESON_VERBOSE as well? Avoids double negation in the code
> (not unset -> verbose vs. MESON_VERBOSE == true -> verbose) and keeps
> the variable naming similar to cmake.eclass.
>
> nex
I personally agree -- I was just sending the patch as-is from GitHub.
[gentoo-dev] Re: [PATCH] meson.eclass: allow disabling verbose compilation
On Mon, Jul 17, 2023 at 10:51 AM Matt Turner wrote:
>
> From: Jonas Rakebrandt
>
> This works similar to cmake.eclass's ${CMAKE_VERBOSE}.
... except that it's _QUIET, rather than _VERBOSE.
I've sent patches to add NINJA_VERBOSE to ninja-utils.eclass and
another to support CMAKE_VERBOSE with ninja.
This makes me think we should keep things consistent here by switching
this to MESON_VERBOSE.
[gentoo-dev] [PATCH 2/2] cmake.eclass: Support CMAKE_VERBOSE with ninja
Signed-off-by: Matt Turner
---
eclass/cmake.eclass | 4
1 file changed, 4 insertions(+)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index d70f2cbf1fac..16b3e300ccae 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -651,6 +651,10 @@ cmake_build() {
;;
ninja)
[[ -e build.ninja ]] || die "build.ninja not found.
Error during configure stage."
+ case ${CMAKE_VERBOSE} in
+ OFF) NINJA_VERBOSE=OFF eninja "$@" ;;
+ *) eninja "$@" ;;
+ esac
eninja "$@"
;;
esac
--
2.41.0
[gentoo-dev] [PATCH 1/2] ninja-utils.eclass: Add NINJA_VERBOSE
ninja operates in one of three modes:
- verbose (with -v): prints build commands
- quiet (with --quiet): prints nothing
- normal: prints [XX/YY]-style build status updates
samurai works the same way, except it does not have a quiet mode.
Thus we can't simply override ninja-utils' hard-coded flag from callers
of eninja.
Signed-off-by: Matt Turner
---
eclass/ninja-utils.eclass | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/eclass/ninja-utils.eclass b/eclass/ninja-utils.eclass
index e6d8c9e6c0a9..26ba31678f01 100644
--- a/eclass/ninja-utils.eclass
+++ b/eclass/ninja-utils.eclass
@@ -48,6 +48,12 @@ _NINJA_UTILS_ECLASS=1
# supposed to be set in make.conf. If unset, eninja() will convert
# MAKEOPTS instead.
+# @ECLASS_VARIABLE: NINJA_VERBOSE
+# @USER_VARIABLE
+# @DESCRIPTION:
+# Set to OFF to disable verbose messages during compilation
+: "${NINJA_VERBOSE:=ON}"
+
inherit multiprocessing
case "${NINJA}" in
@@ -80,7 +86,12 @@ get_NINJAOPTS() {
# also supports being called via 'nonfatal'.
eninja() {
[[ -n "${NINJA_DEPEND}" ]] || ewarn "Unknown value '${NINJA}' for
\${NINJA}"
- set -- "${NINJA}" -v $(get_NINJAOPTS) "$@"
+ local v
+ case "${NINJA_VERBOSE}" in
+ OFF) ;;
+ *) v="-v"
+ esac
+ set -- "${NINJA}" ${v} $(get_NINJAOPTS) "$@"
echo "$@" >&2
"$@" || die -n "${*} failed"
}
--
2.41.0
Re: [gentoo-dev] [PATCH] meson.eclass: allow disabling verbose compilation
Hi,
Am Montag, dem 17.07.2023 um 10:51 -0400 schrieb Matt Turner:
> This works similar to cmake.eclass's ${CMAKE_VERBOSE}.
Why not use MESON_VERBOSE as well? Avoids double negation in the code
(not unset -> verbose vs. MESON_VERBOSE == true -> verbose) and keeps
the variable naming similar to cmake.eclass.
nex
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] git-r3.eclass: Use '__init__' as initial branch
> On Mon, 17 Jul 2023, Matt Turner wrote: > From: konsolebox > Closes: https://bugs.gentoo.org/841392 > Signed-off-by: Matt Turner Maybe the commit message could shortly explain why this is needed, or what problem is fixed by it? signature.asc Description: PGP signature
[gentoo-dev] [PATCH] meson.eclass: allow disabling verbose compilation
From: Jonas Rakebrandt
This works similar to cmake.eclass's ${CMAKE_VERBOSE}.
Closes: https://github.com/gentoo/gentoo/pull/28942
Signed-off-by: Jonas Rakebrandt
Signed-off-by: Matt Turner
---
eclass/meson.eclass | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 2c274b213191..1acdee9325b2 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -55,6 +55,12 @@ BDEPEND=">=dev-util/meson-0.62.2
# Build directory, location where all generated files should be placed.
# If this isn't set, it defaults to ${WORKDIR}/${P}-build.
+# @ECLASS_VARIABLE: MESON_QUIET
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Disables verbose messages during compilation if non-empty.
+
# @ECLASS_VARIABLE: EMESON_BUILDTYPE
# @DESCRIPTION:
# The buildtype value to pass to meson setup.
@@ -385,10 +391,14 @@ meson_src_compile() {
-C "${BUILD_DIR}"
--jobs "$(makeopts_jobs "${MAKEOPTS}" 0)"
--load-average "$(makeopts_loadavg "${MAKEOPTS}" 0)"
- --verbose
- "$@"
)
+ if [[ -z ${MESON_QUIET} ]]; then
+ mesoncompileargs+=( --verbose )
+ fi
+
+ mesoncompileargs+=( "$@" )
+
set -- meson compile "${mesoncompileargs[@]}"
echo "$@" >&2
"$@" || die "compile failed"
--
2.41.0
[gentoo-dev] [PATCH] git-r3.eclass: Use '__init__' as initial branch
From: konsolebox
Closes: https://bugs.gentoo.org/841392
Signed-off-by: Matt Turner
---
eclass/git-r3.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index e9fdf2ac3a42..5ac141962b12 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -344,7 +344,7 @@ _git-r3_set_gitdir() {
umask "${EVCS_UMASK}" || die "Bad options to umask:
${EVCS_UMASK}"
fi
mkdir "${GIT_DIR}" || die
- git init --bare || die
+ git init --bare -b __init__ || die
if [[ ${saved_umask} ]]; then
umask "${saved_umask}" || die
fi
@@ -874,7 +874,7 @@ git-r3_checkout() {
# use git init+fetch instead of clone since the latter doesn't
like
# non-empty directories.
- git init --quiet || die
+ git init --quiet -b __init__ || die
# setup 'alternates' to avoid copying objects
echo "${orig_repo}/objects" >
"${GIT_DIR}"/objects/info/alternates || die
# now copy the refs
--
2.41.0
Re: [gentoo-dev] Package stabilization groups
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?
