Re: [gentoo-dev] Package up for grabs
On 08/06/2017 02:27 AM, tom...@gentoo.org wrote: > Quoting Daniel Campbell (2017-07-31 04:16:30) >> On 07/19/2017 02:33 AM, Amy Liffey wrote: >>> The following package is up for grabs: >>> >>> dev-lang/gforth >>> >>> Best regards, >>> Amy Liffey >>> >> I can take this one; I'd hate to see Forth support go missing on Gentoo. >> I'm open to co-maintainers as well. >> > Ok, as I have done some quite Forth programming in the past, let me step in. > > Thomas > >> ~zlg >> >> -- >> Daniel Campbell - Gentoo Developer >> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net >> fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 >> > > Sounds great. Would you like me to do the honors of updating metadata.xml later tonight? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
On Thu, 3 Aug 2017 19:21:12 +0200
Jonas Stein wrote:
> We have already some HOMEPAGES which are constructed by eclass magic
> [2]. These do not link to a useful website usually.
Statistically, that 99% of perl-module.eclass consumers do just this in
a useful way with factoring in ${PN} automatically, might tilt those
odds of "Usual"
It would be a net reduction in usefulness if every single
perl-module.eclass consumer was required to hard-code a human usable
HOMEPAGE.
In fact, one of the things we have as a future option is changing the
"base part" of these automatically generated URL's so they reference a
useful homepage on metacpan.org instead of search.cpan.org.
I'm glad we're not considering doing that manually for every ebuild.
Though, neither of these really are considered "the" home page, but
these projects don't typically even *have* "a" homepage, they're
simply external-indexes of uploaded data, and they serve as defacto
homepages, and metadata inside that uploaded data can direct users to
the "real" home page.
So in a sense, these home pages also serve like a kind of resolver.
But people practically never use that "real" homepage, the defacto home
pages are what people care for.
> A string is also less error prone. We have already many broken
> HOMEPAGES
That clearly depends on circumstances, if well tuned, every ebuild hand
coding its home pages *increases* the net error prone-ness ( at least,
it does for CPAN ), because it creates quite literally thousands of
places humans might encode a home page wrong.
And at least with CPAN, if the autogenerated homepage does not resolve,
that usually doesn't mean you made a mistake in generating the
homepage: It usually means you made big bungles somewhere else and the
ebuild won't even work, and/or upstream have pulled their rip cord and
have deleted all their files from public servers.
But this subject kinda reduces to a long-living decision quandry: "to
de-duplicate and unify, or not to deduplicate and keep sparse".
There are so many benefits and trade-offs to either. It only makes
sense to let the decision follow the nature of the problem at hand, not
creating a blind rule that must be followed religiously.
pgpzTOO1_UtNy.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] java-pkg-opt-2.eclass: fix java-pkg-opt-2_src_prepare to always call eapply_user for EAPI-6+
On Sun, 30 Jul 2017 22:08:18 +0100 James Le Cuirot wrote: > On Sun, 30 Jul 2017 14:32:53 +0300 > Andrew Savchenko wrote: > > > For EAPI 6+ java-pkg-opt-2_src_prepare() has eapply_user call via > > java-utils-2_src_prepare() from java-utils-2.eclass. But > > java-utils-2_src_prepare() call is conditional and in case when > > package is build with USE=-java java-utils-2_src_prepare() is not > > called, hence eapply_user is not called in src_prepare phase and > > ebuild fails. > > > > The following patch fixes this by calling eapply_user if java USE > > is disabled _and_ EAPI is 6+. > > This makes sense so no problem here. > > > [pedantic mode on] > > Strictly speaking when EAPI is other than [0-5]. The way java-* > > eclasses are now, they assume ![0-5] == 6+. It may be speculated > > that this is not entirely correct and many other eclasses > > explicitly deny all unknown EAPIs. If someone is interesting in > > fixing this issue, please handle it with the java team and do not > > mix it into the problem described at the beginning. My goal now is > > to fix eapply_user issue which cases trouble for any EAPI 6 > > packages with optional java support and default src_prepare() at > > the ebuild scope. > > [pedantic mode off] > > Agreed. I don't think java-utils-2_src_prepare() should be changed in > this regard as the behaviour may continue to be correct but the eclass > should have a global EAPI check that forbids anything beyond 6 like > other eclasses do. Applied in the tree. The whitespace change from the original patch is removed. Best regards, Andrew Savchenko pgp3wWgzigZOK.pgp Description: PGP signature
