Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Sat, Jul 16, 2022 at 10:20:01PM +0200, Ulrich Mueller wrote: > > On Sat, 16 Jul 2022, William Hubbs wrote: > > The only question is, is there a way to reliably tell whether or not > > we are in the main tree? > > An eclass has no legitimate way to find out in which repository it is. > The rationale is that users should be able to copy ebuilds and eclasses > to their local overlays, and they should work there in the same way. > > There is an internal (and undocumented) Portage variable, but that > shouldn't be used. In that case, I'm left with two options. 1) continue with deprecating and removing EGO_SUM. 2) (suggested on IRC) allow EGO_SUM as long as it has below a certain low number of entries. It would need to be kept small to keep ebuilds and manifests from bloating too much. Thoughts? William signature.asc Description: PGP signature
[gentoo-dev] [PATCH v3] java-pkg-simple.eclass: Automatic-Module-Name
The new variable JAVA_AUTOMATIC_MODULE_NAME can be defined in the
ebuild. Its value will be transferred to the MANIFEST.MF of the jar
file.
Closes: https://bugs.gentoo.org/857468
Signed-off-by: Volkmar W. Pogatzki
---
eclass/java-pkg-simple.eclass | 12
1 file changed, 12 insertions(+)
diff --git a/eclass/java-pkg-simple.eclass b/eclass/java-pkg-simple.eclass
index 1e101a828c4..c0a6b4d21df 100644
--- a/eclass/java-pkg-simple.eclass
+++ b/eclass/java-pkg-simple.eclass
@@ -134,6 +134,12 @@ fi
# JAVA_MAIN_CLASS="org.gentoo.java.ebuilder.Main"
# @CODE
+# @ECLASS_VARIABLE: JAVA_AUTOMATIC_MODULE_NAME
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# The value of the Automatic-Module-Name entry, which is going to be added to
+# MANIFEST.MF.
+
# @ECLASS_VARIABLE: JAVADOC_ARGS
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -418,6 +424,12 @@ java-pkg-simple_src_compile() {
jar_args="cf ${JAVA_JAR_FILENAME}"
fi
jar ${jar_args} -C ${classes} . || die "jar failed"
+ if [[ -v JAVA_AUTOMATIC_MODULE_NAME ]]; then
+ cat > "${T}/add-to-MANIFEST.MF" <<< "Automatic-Module-Name:
${JAVA_AUTOMATIC_MODULE_NAME}" \
+ || die "add-to-MANIFEST.MF failed"
+ jar ufmv ${JAVA_JAR_FILENAME} "${T}/add-to-MANIFEST.MF" \
+ || die "updating MANIFEST.MF failed"
+ fi
}
# @FUNCTION: java-pkg-simple_src_install
--
2.35.1
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
> On Sat, 16 Jul 2022, William Hubbs wrote:
> I could force this in the eclass with the following flow if I know how
> to tell if the ebuild inheriting it is in the main tree or not:
> # in_main_tree is a place holder for a test to see if the ebuld running
> # this is in the tree
> if [[ -n ${EGO_SUM} && in_main_tree ]]; then
> eqawarn "EGO_SUM is not allowed in the main tree"
> eqawarn "This will become a fatal error in the future"
> fi
> The only question is, is there a way to reliably tell whether or not
> we are in the main tree?
An eclass has no legitimate way to find out in which repository it is.
The rationale is that users should be able to copy ebuilds and eclasses
to their local overlays, and they should work there in the same way.
There is an internal (and undocumented) Portage variable, but that
shouldn't be used.
Ulrich
signature.asc
Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Sat, Jul 16, 2022 at 06:46:40PM +, Robin H. Johnson wrote:
> On Sat, Jul 16, 2022 at 09:31:35PM +0300, Arthur Zamarin wrote:
> > I want to give another option. Both ways are allowed by eclass, but by
> > QA policy (or some other decision), it is prohibited to use EGO_SUM in
> > main ::gentoo tree.
> >
> > As a result, overlays and ::guru can use the EGO_SUM or dist distfile
> > (remember, they don't have access to hosting on dev.g.o).
> Yes; this is the option I was trying to propose as an intermediate step
> until we have indirect Manifests that provide the best of both worlds
> (not bloating the tree, and not requiring creation of dep tarballs).
I could force this in the eclass with the following flow if I know how
to tell if the ebuild inheriting it is in the main tree or not:
# in_main_tree is a place holder for a test to see if the ebuld running
# this is in the tree
if [[ -n ${EGO_SUM} && in_main_tree ]]; then
eqawarn "EGO_SUM is not allowed in the main tree"
eqawarn "This will become a fatal error in the future"
fi
The only question is, is there a way to reliably tell whether or not
we are in the main tree?
William
signature.asc
Description: PGP signature
Re: [gentoo-dev] Create an index for all qa notices
On Sat, Jul 16, 2022 at 08:42:39PM +0200, Agostino Sarubbo wrote: > Hello all, > > I noticed that we have many people that, after received a bug report, ask for > what the > reported 'qa notice' means. > > Sometimes there is a tracker and people can take an hint from the resolved > bugs but > when there aren't a lot of info I feel they are a bit lost. Somewhat orthogonally, it would be a great help to include common causes, solutions, and reproduction instructions directly in the bug reports and/or trackers. > Today, by pure chance, I stumbled upon the "Rust Compiler Error Index" and I > thought: > why we don't do the same thing with our qa notices? > > I think that devmanual could be the right place and each QA notice should > have an > 'identification code'. > In that way we can link the error in the qa notice like: > > https://devmanual.gentoo.org/appendices/qa-notices/qa0001[1] > https://devmanual.gentoo.org/appendices/qa-notices/qa0002[2] > > and so on. > > > Reference: https://doc.rust-lang.org/error-index.html[3] > > What do you think? > > Agostino > > > [1] https://devmanual.gentoo.org/appendices/qa-notices/qa0001 > [2] https://devmanual.gentoo.org/appendices/qa-notices/qa0002 > [3] https://doc.rust-lang.org/error-index.html signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Sat, Jul 16, 2022 at 09:31:35PM +0300, Arthur Zamarin wrote: > I want to give another option. Both ways are allowed by eclass, but by > QA policy (or some other decision), it is prohibited to use EGO_SUM in > main ::gentoo tree. > > As a result, overlays and ::guru can use the EGO_SUM or dist distfile > (remember, they don't have access to hosting on dev.g.o). Yes; this is the option I was trying to propose as an intermediate step until we have indirect Manifests that provide the best of both worlds (not bloating the tree, and not requiring creation of dep tarballs). -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
[gentoo-dev] Create an index for all qa notices
Hello all, I noticed that we have many people that, after received a bug report, ask for what the reported 'qa notice' means. Sometimes there is a tracker and people can take an hint from the resolved bugs but when there aren't a lot of info I feel they are a bit lost. Today, by pure chance, I stumbled upon the "Rust Compiler Error Index" and I thought: why we don't do the same thing with our qa notices? I think that devmanual could be the right place and each QA notice should have an 'identification code'. In that way we can link the error in the qa notice like: https://devmanual.gentoo.org/appendices/qa-notices/qa0001[1] https://devmanual.gentoo.org/appendices/qa-notices/qa0002[2] and so on. Reference: https://doc.rust-lang.org/error-index.html[3] What do you think? Agostino [1] https://devmanual.gentoo.org/appendices/qa-notices/qa0001 [2] https://devmanual.gentoo.org/appendices/qa-notices/qa0002 [3] https://doc.rust-lang.org/error-index.html
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 16/07/2022 20.51, William Hubbs wrote: > On Sat, Jul 16, 2022 at 02:58:04PM +0300, Joonas Niilola wrote: >> On 16.7.2022 14.24, Florian Schmaus wrote: >>> >> >> ++ this sounds most sensible. This is also how I've understood your >> proposal. > > Remember that with EGO_SUM all of the bloated manifests and ebuilds are > on every user's system. > > I added mgorny as a cc to this message because he made it pretty clear > at some point in the previous discussion that the size of these ebuilds > and manifests is unacceptable. > > William I want to give another option. Both ways are allowed by eclass, but by QA policy (or some other decision), it is prohibited to use EGO_SUM in main ::gentoo tree. As a result, overlays and ::guru can use the EGO_SUM or dist distfile (remember, they don't have access to hosting on dev.g.o). -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, Arch Teams, pkgcore stack, GURU) OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Sat, Jul 16, 2022 at 02:58:04PM +0300, Joonas Niilola wrote: > On 16.7.2022 14.24, Florian Schmaus wrote: > > > > That reads as if you wrote it under the assumption that we can only > > either use dependency tarballs or use EGO_SUM. At the same time, I have > > not seen an argument why we can not simply do *both*. > > > > EGO_SUM has numerous advantages over dependency tarballs, but can not be > > used if the size of the EGO_SUM value crosses a threshold. So why not > > mandate dependency tarballs if a point is crossed and otherwise allow > > EGO_SUM? That way, we could have the best of both worlds. > > > > - Flow > > > > ++ this sounds most sensible. This is also how I've understood your > proposal. Remember that with EGO_SUM all of the bloated manifests and ebuilds are on every user's system. I added mgorny as a cc to this message because he made it pretty clear at some point in the previous discussion that the size of these ebuilds and manifests is unacceptable. William signature.asc Description: PGP signature
[gentoo-dev] [PATCH] flag-o-matic.eclass: respect -fuse-ld in test-flags-CCLD
Closes: https://bugs.gentoo.org/832377
Signed-off-by: Sam James
---
eclass/flag-o-matic.eclass | 9 +
1 file changed, 9 insertions(+)
diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
index 5e6269b21b17..00786c2f74bb 100644
--- a/eclass/flag-o-matic.eclass
+++ b/eclass/flag-o-matic.eclass
@@ -573,6 +573,15 @@ _test-flag-PROG() {
c+ld)
in_ext='c'
in_src='int main(void) { return 0; }'
+
+ if is-ldflagq -fuse-ld=* ; then
+ # Respect linker chosen by user so we don't
+ # end up giving false results by checking
+ # with default linker. bug #832377
+ fuse_ld_value=$(get-flag -fuse-ld=*)
+ cmdline_extra+=(${fuse_ld_value})
+ fi
+
cmdline_extra+=(-xc)
;;
esac
--
2.37.1
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 16.7.2022 14.24, Florian Schmaus wrote: > > That reads as if you wrote it under the assumption that we can only > either use dependency tarballs or use EGO_SUM. At the same time, I have > not seen an argument why we can not simply do *both*. > > EGO_SUM has numerous advantages over dependency tarballs, but can not be > used if the size of the EGO_SUM value crosses a threshold. So why not > mandate dependency tarballs if a point is crossed and otherwise allow > EGO_SUM? That way, we could have the best of both worlds. > > - Flow > ++ this sounds most sensible. This is also how I've understood your proposal. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 15/07/2022 23.34, William Hubbs wrote: On Mon, Jun 27, 2022 at 01:43:19AM +0200, Zoltan Puskas wrote: In summary, IMHO the EGO_SUM way of handling of go packages has more benefits than drawbacks compared to the vendor tarballs. EGO_SUM can cause portage to break; that is the primary reason support is going away. We attempted another solution that was refused, so the only option we have currently is to build the dependency tarballs. That reads as if you wrote it under the assumption that we can only either use dependency tarballs or use EGO_SUM. At the same time, I have not seen an argument why we can not simply do *both*. EGO_SUM has numerous advantages over dependency tarballs, but can not be used if the size of the EGO_SUM value crosses a threshold. So why not mandate dependency tarballs if a point is crossed and otherwise allow EGO_SUM? That way, we could have the best of both worlds. - Flow
