Re: [gentoo-dev] [PATCH 1/3] To make "tc_has_feature ada" actually work

[Arsen Arsenović]

looks OK at a glance, but could you summarize the issues the patch set
fixes in the commit messages (and reword them to follow convention
generally)?  it is important to have context while looking at a git log.

Alfredo Tupone  writes:

> Signed-off-by: Alfredo Tupone 
> ---
>  eclass/toolchain.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index a5d4345e7fbf..fd820f60f45d 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -288,31 +288,31 @@ if [[ ${PN} != kgcc64 && ${PN} != gcc-* ]] ; then
>   IUSE+=" objc-gc" TC_FEATURES+=( objc-gc )
>   IUSE+=" libssp objc++"
>  
>   # Stop forcing openmp on by default in the eclass. Gradually phase it 
> out.
>   # See bug #890999.
>   if tc_version_is_at_least 13.0.0_pre20221218 ; then
>   IUSE+=" openmp"
>   else
>   IUSE+=" +openmp"
>   fi
>  
>   IUSE+=" fixed-point"
>   IUSE+=" go"
>   IUSE+=" +sanitize"  TC_FEATURES+=( sanitize )
>   IUSE+=" graphite" TC_FEATURES+=( graphite )
> - IUSE+=" ada"
> + IUSE+=" ada" TC_FEATURES+=( ada )

does this apply for all versions of GCC?

>   IUSE+=" vtv"
>   IUSE+=" jit"
>   IUSE+=" +pie +ssp pch"
>  
>   IUSE+=" systemtap" TC_FEATURES+=( systemtap )
>  
>   tc_version_is_at_least 9.0 && IUSE+=" d" TC_FEATURES+=( d )
>   tc_version_is_at_least 9.1 && IUSE+=" lto"
>   tc_version_is_at_least 10 && IUSE+=" cet"
>   tc_version_is_at_least 10 && IUSE+=" zstd" TC_FEATURES+=( zstd )
>   tc_version_is_at_least 11 && IUSE+=" valgrind" TC_FEATURES+=( valgrind )
>   tc_version_is_at_least 11 && IUSE+=" custom-cflags"
>   tc_version_is_at_least 12 && IUSE+=" ieee-long-double"
>   tc_version_is_at_least 12.2.1_p20221203 ${PV} && IUSE+=" default-znow"
>   tc_version_is_at_least 12.2.1_p20221203 ${PV} && IUSE+=" 
> default-stack-clash-protection"

-- 
Arsen Arsenović


signature.asc
Description: PGP signature

[gentoo-dev] Re: [PATCH 2/3] To build ada we need a c++ compiler too

[Arsen Arsenović]

Hi,

Alfredo Tupone  writes:

> Signed-off-by: Alfredo Tupone 
> ---
>  eclass/toolchain.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index fd820f60f45d..f8e06fa39884 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -2495,31 +2495,31 @@ should_we_gcc_config() {
>  #
>  # Also add a hook so special ebuilds (kgcc64) can control which languages
>  # exactly get enabled
>  gcc-lang-supported() {
>   grep ^language=\"${1}\" "${S}"/gcc/*/config-lang.in > /dev/null || 
> return 1
>   [[ -z ${TOOLCHAIN_ALLOWED_LANGS} ]] && return 0
>   has $1 ${TOOLCHAIN_ALLOWED_LANGS}
>  }
>  
>  _tc_use_if_iuse() {
>   in_iuse $1 && use $1
>  }
>  
>  is_ada() {
>   gcc-lang-supported ada || return 1
> - _tc_use_if_iuse ada
> + _tc_use_if_iuse cxx && _tc_use_if_iuse ada

Is this redundant?  Would gcc-lang-supported c++ (called through the ada
support check) not suffice?

>  }
>  
>  is_cxx() {
>   gcc-lang-supported 'c++' || return 1
>   _tc_use_if_iuse cxx
>  }
>  
>  is_d() {
>   gcc-lang-supported d || return 1
>   _tc_use_if_iuse d
>  }
>  
>  is_f77() {
>   gcc-lang-supported f77 || return 1
>   _tc_use_if_iuse fortran

-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo

[Arsen Arsenović]

Michał Górny  writes:

> 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.
>
>
> 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.
>
> 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.
>
> 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.
>
>
> 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

+1.  All I've seen from "generatative" (read: auto-plagiarizing) A"I" is
spam and theft, and have the full intention of blocking it where-ever my
vote counts.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] Introducing .mailmap?

[Arsen Arsenović]

Sam James  writes:

>
> We should consider adding a .mailmap to gentoo.git.
>
> There's a few reasons:
> * We should accurately map pre-developer-status contributions.
>   For example, it'd be nice if s...@cmpct.info was mapped correctly
>   into s...@gentoo.org when doing git blame.
>
>   We know s...@cmpct.info and s...@gentoo.org are the same person, it
>   feels coherent to tell git that via the mechanism intended for it.
>
> * It's useful for when people retire as well. Not that I plan on going
>   anywhere any time soon (sorry!), but this is both a useful way for
>   people to better "retain credit" *and* for e.g. 'git blame' to work
>   better if they then come back as a contributor but not a developer, which
>   happens on occasion, or if they occasionally contribute with a
>   different email address (we have this for some devs who contribute
>   under a "work context" too).
>
> * It allows people to have git respecting changing their name for
>   various reasons (e.g. we've had contributors start using their real name
>   and vice-versa over the years). 
>
> I was considering this anyway but xgqt pinged me about it after
> I mentioned it on a recent bug (https://bugs.gentoo.org/836936#c12) as well
> which made me think there's perhaps some merit in it.
>
> thanks,
> sam

+1.  I'd like my old contributions mapped too ;)
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: Setting default HOME_MODE in /etc/login.defs

[Arsen Arsenović]

Daniel Simionato  writes:

> Hello,
>  I'd like to start a discussion regarding setting HOME_MODE by default in
> the /etc/login.defs file (owned by sys-apps/shadow package).
>
> Upstream keeps HOME_MODE commented:
> https://github.com/shadow-maint/shadow/blob/3e59e9613ec40c51c19c7bb5c28468e33a4529d5/etc/login.defs#L207
>
> HOME_MODE affects only useradd and newuser commands: if HOME_MODE is set,
> they will use the specified permission when creating a user home directory,
> otherwise the default UMASK will be used.
> Since the default umask is 022, keeping HOME_MODE unset will result in home
> readable home directories created by useradd, which goes against security
> best practices.
>
> The proposal is to set HOME_MODE to 0700, or at least 0750: RedHat and RH
> based distros, OpenSuse, ArchLinux all set it to 0700, Ubuntu has it at
> 0750. Debian and Gentoo are two exceptions, keeping the upstream value of
> HOME_MODE (although login.defs is changed in other ways).
>
> I previously made a PR on github where you can find more details (
> https://github.com/gentoo/gentoo/pull/35231), but as pointed in the
> comments this probably warrants some discussion beforehand.
>
> I can understand the argument against the change, which is keeping in sync
> with upstream and don't risk changing the historic default behaviour of
> tools some users might rely upon.
>
> I do believe though there's merit in providing safer and secure defaults,
> so I would like HOME_MODE to have a safe default value for Gentoo and
> Gentoo based distros.
>
> Have a nice day,
>  Daniel

+1 for 0700.  I also like the umask suggestions.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH 6/8] dev-util/intel_clc: Migrate to llvm-r1

[Arsen Arsenović]

Sam James  writes:

> Michał Górny  writes:
>
>> Closes: https://bugs.gentoo.org/923228
>> Signed-off-by: Michał Górny 
>> ---
>>  dev-util/intel_clc/intel_clc-24.0.0.ebuild | 48 --
>>  dev-util/intel_clc/intel_clc-.ebuild   | 48 --
>>  2 files changed, 18 insertions(+), 78 deletions(-)
>
> Arsen, could you verify this does solve the problem for you, just to be
> sure?

I've confirmed on the PR before seeing this email - yes, it works :-)
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

[gentoo-dev] Re: [PATCH] profiles: workaround sandbox bug with getcwd() configure test (gl_cv_func_getcwd_path_max)

[Arsen Arsenović]

Hi,

Sam James  writes:

> Workaround for sandbox bug which causes this gnulib configure test to take
> many real hours on slower machines, and certainly a huge amount of CPU hours
> on others.
>
> Spoof the same result as configure gets on a modern glibc & musl system for 
> now.
>
> Bug: https://bugs.gentoo.org/447970
> Closes: https://bugs.gentoo.org/922652
> Signed-off-by: Sam James 
> ---

Seems OK.

>  profiles/default/linux/make.defaults | 9 -
>  profiles/features/musl/make.defaults | 7 +++
>  2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/profiles/default/linux/make.defaults 
> b/profiles/default/linux/make.defaults
> index 74dd59d5d8179..4e21cd58fdf22 100644
> --- a/profiles/default/linux/make.defaults
> +++ b/profiles/default/linux/make.defaults
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2023 Gentoo Authors
> +# Copyright 1999-2024 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  #
>  # System-wide defaults for the Portage system
> @@ -54,3 +54,10 @@ LDFLAGS="-Wl,-O1 -Wl,--as-needed"
>  # Prevent automagic use of 64-bit time_t.
>  # https://bugs.gentoo.org/828001
>  enable_year2038="no"
> +
> +# Sam James  (2024-01-22)
> +# Workaround for sandbox bug which causes this gnulib configure test to take
> +# many real hours on slower machines, and certainly a huge amount of CPU 
> hours
> +# on others. Spoof the same result as configure gets on a modern glibc system
> +# for now. See bug #447970 and bug #922652.
> +gl_cv_func_getcwd_path_max="yes"
> diff --git a/profiles/features/musl/make.defaults 
> b/profiles/features/musl/make.defaults
> index 3078bdd61b09c..ca792276e3945 100644
> --- a/profiles/features/musl/make.defaults
> +++ b/profiles/features/musl/make.defaults
> @@ -17,3 +17,10 @@ FEATURES="-multilib-strict"
>  # that use a charset, it causes package collisons.
>  # Note: we use a full path for locale.alias for bug #799437
>  INSTALL_MASK="charset.alias /usr/share/locale/locale.alias"
> +
> +# Sam James  (2024-01-22)
> +# Workaround for sandbox bug which causes this gnulib configure test to take
> +# many real hours on slower machines, and certainly a huge amount of CPU 
> hours
> +# on others. Spoof the same result as configure gets on a modern musl system
> +# for now. See bug #447970 and bug #922652.
> +gl_cv_func_getcwd_path_max="no, but it is partly working"


--
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] New category: dev-build

[Arsen Arsenović]

Hi!

Michał Górny  writes:

> Hi,
>
> Another idea for a new category: dev-build.  Proposed description:
>
>   Build systems and related tools.
>
> Some candidates (there are more):
>
> dev-util/bazel
> dev-util/cmake
> dev-util/cmake-fedora
> dev-util/gn
> dev-util/gtk-doc-am
> dev-util/gyp
> dev-util/meson
> dev-util/muon
> dev-util/netsurf-buildsystem
> dev-util/ninja
> dev-util/samurai
> dev-util/tup
> sys-devel/autoconf*
> sys-devel/automake*
> sys-devel/bmake
> sys-devel/cons
> sys-devel/gettext (not 100% sure about it)

That's a bit of a toss-up, but I think I lean more towards the side of
sys-libs or so (since, while it indeed provides build-time tools, it is
not really a build system component, and it provides a few other libs).

> sys-devel/libtool
> sys-devel/make
> sys-devel/pmake
> sys-devel/qconf
> sys-devel/slibtool

I like the idea.

Have a lovely day!
--
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item

[Arsen Arsenović]

k...@aspodata.se writes:

> Eli Schwartz:
> [...]
>> +Systems which have /usr and / on separate filesystems have always required a
>> +dedicated initramfs to bring up both partitions. Systems where both /usr 
>> and /
>> +are on the same filesystem may use an initramfs if they wish, or choose not
>> +to.
> [...]
>
> Well, that is not technically correct, just have the required kernel
> drivers (eg. AHCI and ext2/4) compiled in and use the same busybox
> commands as in the initrd, but placed in /, to bring up the system
> to the point that /usr is mounted.
>
> I have a static dev, compiled in drivers, busybox init and mount, and
> separate / and /usr on a box here, works perfectly well.
>  Soo, add a clause about what gentoo supports out of the box and that
> you can make it work if you wish.

Is there a need to state this?   To me, it feels obvious, and falls into
the category of 'you can do it but don't expect much help'.  As an
example of entries in this category, I used to use runit for service
management and supervision, and only used the openrc boot target.
Naturally, this worked, but it worked due to me maintaining it, and had
no Gentoo-provided support.

The same is true for many, many configurations, so I don't see the need
to state that explicitly.

>  If there is a general wish I can write an article about how to make
> it work.
>
> Regards,
> /Karl Hammar
>
> -------
> Aspö Data
> Lilla Aspö 148
> S-742 94 Östhammar
> Sweden


--
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] heads up: codeberg changed gzip impls (?) for ${REPO}/archive/${TAG}.tar.gz files

[Arsen Arsenović]

Arsen Arsenović  writes:

> hi,
>
> it seems that codeberg has changed how they produce their archives on
> URLs like <https://codeberg.org/dnkl/foot/archive/${tag}.tar.gz> leading
> to digest failures like <https://bugs.gentoo.org/919135>, as implied by
> the following checks:
>
>   ~$ diff <( <(   ~$ diff <( <(   Binary files /dev/fd/63 and /dev/fd/62 differ
>
> the above shows that compressed content differs while decompressed
> content remains identical.
>
> (dls/foot-1.16.2.tar.gz is downloaded from the master distfiles mirror,
> /var/cache/distfiles/foot-1.16.2.tar.gz is fetched from codeberg at
> around two in the morning last night)
>
> you might want to regenerate manifests for projects fetching from
> /archive/ urls on codeberg.

ps, also filed https://codeberg.org/Codeberg/Community/issues/1366 per
ulms suggestion.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

[gentoo-dev] heads up: codeberg changed gzip impls (?) for ${REPO}/archive/${TAG}.tar.gz files

[Arsen Arsenović]

hi,

it seems that codeberg has changed how they produce their archives on
URLs like  leading
to digest failures like , as implied by
the following checks:

  ~$ diff <(

signature.asc
Description: PGP signature

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arsen Arsenović]

Alexe Stefan  writes:

> On 9/17/23, Arsen Arsenović  wrote:
>> In the meanwhile, while the two downstream volunteers address that, an
>> ::eudev overlay can be established.  As I went over in another email I
>> posted to this thread, it should not be particularly difficult to
>> implement or maintain (nowhere close to LibreSSL, for instance, as eudev
>> didn't diverge nearly as much as LibreSSL did, and since
>> virtual/{lib,}udev exist).
>>
>
> It seems like we will have to do this.
> Should we make a new overlay or use an existing one?
> If we make a new overlay, where should we host it?
>
> There is the without-systemd overlay on github. Should we use that?
> If we make something new, I'd rather it be on something like codeberg.

Up to you.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles

[Arsen Arsenović]

Arsen Arsenović  writes:

[snip]

>> How are they identical.
>
> The last rites message does not say that opentmpfiles and
> systemd-tmpfiles are identical.  That'd do a disservice to the actually
> complete, unmaintained, and (currently) non-CVE-affected implementation
^^ C-h C-h... typo'd.
> in systemd.
>

[snip]
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles

[Arsen Arsenović]

Alexe Stefan  writes:

> One is written in shell, the other is written in c.(no problems here)

Not that implementation language matters.

> One is not part of systemd, the other is.

Both work fine without systemd, but the systemd implementation also
happens not to be unmaintained and happens to be more complete.

> How are they identical.

The last rites message does not say that opentmpfiles and
systemd-tmpfiles are identical.  That'd do a disservice to the actually
complete, unmaintained, and (currently) non-CVE-affected implementation
in systemd.

> I use this on my raspi server, works fine.

'WOMM' is a fairly terrible measure.

> Gentoo really became a systemd distro, further restricting choice by
> the day.

[ignoring this nonsensical statement, notice put here for clarity]


Gentoo devs aren't obliged to maintain software you like to use.
systemd-utils[tmpfiles] works on all Gentoo systems, including
non-systemd ones.  Until that changes (which is unlikely), I doubt there
will be much interest in maintaining a fork from inside Gentoo.

Please take up opentmpfiles maintenance.  You have
https://archives.gentoo.org/gentoo-dev/message/689954cc7fd55402dc4c82aa0ac70efb
to address, and probably some other issues.  See
https://github.com/OpenRC/opentmpfiles/issues/19 for context.

The message above implies that a rewrite in C is necessary.

This should be rather easy.  The systemd implementation is only ~4k LoC
(excluding shared code), so I imagine that a complete reimplementation
should be far less than 10k.  Since this is fairly elementary stuff, it
should be possible to finish in a weekends time.

Submit a PR to re-add opentmpfiles after you're done.

Looking forward to reviewing your contributions upstream.  Have a lovely
day :-)
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arsen Arsenović]

Alexe Stefan  writes:

> Upstream, it's maintained.

See my other emails for an explanation of why looking at a commit graph
is not good enough to tell if something is maintained.

> Downstream, 2 people volunteered.

And proposed ugly 'fixes' (read: hacks).

> So it is maintained.
>
> The incompatibilities are for some desktop specific situations, and
> there is a pr upstream(hacky, but work in progress).

No they aren't.  The APIs eudev is missing (and stubs now) are not in
any way specific to desktop.  I also don't buy that desktop-server
dichotomies exist.

> For servers, or minimal desktops(which is what I expect gentoo is
> mostly used for), eudev is fine.

Sorry, I don't buy that an out of date fork with unfixed known bugs that
regularly trails behind with the hwdb is 'fine'.  Especially when said
fork has no improvements.

The only reason I see to use eudev is 'I prefer it out of principle'.
This is an okay reason, but it *does not* outweigh QA concerns.  As I
said before, if those were to go away, which would be most simply
achieved by reforking up-upstream there would be no reason to omit eudev
anymore, and eudev would hence be back.

I know this is viable since I already tried to do so in order to keep
eudev alive because I expected this ruckus would happen, but nobody
aired interest, and my time to waste is scarce, so I dropped the project
and started using systemd-utils[udev].

In the meanwhile, while the two downstream volunteers address that, an
::eudev overlay can be established.  As I went over in another email I
posted to this thread, it should not be particularly difficult to
implement or maintain (nowhere close to LibreSSL, for instance, as eudev
didn't diverge nearly as much as LibreSSL did, and since
virtual/{lib,}udev exist).

My last refork attempt involved a git-filter-repo based script which
reformatted the systemd repository into one that could be git-merge'd
into a tree with a build system.  This worked, and it would be easy to
keep up-to-date, but I never finished it.

Hope to review your contributions upstream soon, have a lovely day :-)
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arsen Arsenović]

Alexe Stefan  writes:

> Yet another example of choice being restricted by gentoo.
> However, there at least is a better reason for not keeping libressl in
> ::Gentoo, that reason being qt.

... and the swathes of other packages that are not compatible with it...
especially since openssl:3 exists.  Please face reality.

> With eudev, there is even less reason to remove it from ::gentoo.
> The only maintenance burden with eudev is a couple of commits here and
> there, mostly in virtuals.

There's at least two reasons to remove it (it's unmaintained, out of
date, and incompatible), and at most zero to keep it.

Fix upstream and the reasons for removal will be gone, and the (illusion
of) choice will be there again.  Note that I refuse to accept the idea
that this is choice.  The code is the same.

Have a lovely night.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arsen Arsenović]

orbea  writes:

> I just want to reiterate that the overlay suggestion is bad and the
> LibreSSL overlay is a good example of why.

No it's not.  It is not possible to compare a virtual provider against
something hard coded into many packages.

> The result is most of the work is redoing things that ::gentoio has
> already done by copying ebuild changes where actual changes for
> LibreSSL itself or for packages not compatible with it is a vast
> minority of the work.

This only happens due to LibreSSLs failure to be useful
(i.e. compatible).

It is significantly harder to do a LibreSSL overlay as OpenSSL reverse
deps that are being hoisted into using libs that they are not compatible
with reference dev-libs/openssl directly rather than a virtual or two.

  ~/gentoo/repo$ git grep -F dev-libs/openssl | wc -l
  1685
  ~/gentoo/repo$ git grep -F sys-apps/systemd-utils | wc -l
  30

The virtuals are going nowhere.  They still have at least two providers,
even without eudev.

> With eudev besides maintaining the eudev ebuild itself I suspect other
> ebuilds the overlay would have to maintain separate copies of are:
>
> virtual/libudev
> virtual/udev (Why are there two of these?)

They provide different things.  Also, virtuals are extraordinarily low
maintenance.

> sys-kernel/genkernel (?)

I don't see why.

> sys-fs/udev-init-scripts
> sys-fs/mdadm
> net-wireless/bluez

I don't see why (if eudev stays useful by staying compatible).

> sys-apps/systemd-utils

I don't follow.  Wouldn't one just need to add a blocker between eudev
and systemd-utils[udev]?  That can be done in either package, and so,
can be done in the eudev one.

Please elaborate on all of the above.

> And possibly others I missed which have minor changes for eudev, its
> significantly less work for ::gentoo to keep eudev than for a ::eudev
> overlay to exist.

And there is literally no developer (AFAIK) interested in dealing with
this, because eudev is _useless_, and the effort for it is nonzero.  The
effort for it can be made very close to zero if upstream was reforked
and maintained so that it's close to up-upstream.  Doing so would also
benefit a handful of other distros such as Void, Alpine and Devuan.

If there are minor changes to make for eudev that cannot be made in
upstream build systems (see, for instance, the few patches I did for
basu) then that means eudev has failed to do its job.

Basu is actually a decent example of how a 'reductionist' fork of
systemd ought to look like (note that basu is orders of magnitude
simpler, though, so the effort for eudev would still be higher).

Have a lovely night.

>> 
>> > Of course I know I (and anyone else) can do that. So then what's the
>> > point of discussing anything then?  
>> 
>> Just because an argument is widely applicable does not make it
>> invalid.
>> 
>> Note that this argument is seldom the first resort, since, as you
>> note, it's not overly productive.  Indeed, it was not the first
>> resort here. sys-fs/eudev has long overstayed the original removal
>> plan.
>> 
>> > What's the point of having a big tree with hundreds of packages? Why
>> > not have a very minimal tree instead and let everyone go and run
>> > multiple independent repos so we can all do what we want? Then we
>> > wouldn't have any discussion about what to include and what not. In
>> > fact maybe that's not a bad idea.  
>> 
>> I'm not sure how to fit this within the context of the thread.
>> 
>> Have a lovely evening.

-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arsen Arsenović]

orbea  writes:

>> Arsen meant incompatibilities of systemd-udev, not of eudev [1]. No
>> idea what's the current state of udev upstream is though. Alpine uses
>> musl, that's one of reasons why they are interested in eudev.

Indeed.

> Oh, thanks for clarifying my misunderstanding. After re-reading I don't
> know if eudev needs to be reforked, ...

It does.  It's been at least six years.  The current MO (which is to
wait for a problem then cherry pick or copy in a fix) is inefficient,
ineffective, and requires /known problems/ to reappear.

> ... missing functionality that downstreams are using can be added...

Doing this via reimplementation is a waste of effort.

> ... and otherwise focus on cleaning up and improving the code
> independently of systemd. For instance there is no reason that
> LibreSSL should refork OpenSSL.

These are apples and oranges.  OpenSSLs code is significantly worse than
systemd code.  There has also been no major improvement to code in eudev
over upstream counterparts.  I can point to one systemic issue in
systemd code (overuse of VLAs/alloca), which is actively being corrected
(but not in eudev, because it's on life support, rather than being
maintained).

Note that I'm not saying this as solely a Gentoo developer, I'm saying
this because I know what the state of the eudev project is and what it
takes to refork (since I've partly done so), and the advantages and
disadvantages of both the current approach and the one I suggest, and I
see _no_ reason to continue as the project does today.
systemd-utils[udev] is simply the easiest implementation of what I
preach.

Please attempt to bring eudev up to snuff via copying and cherry-picking
before setting your mind on continuing the status quo.  I guarantee that
less time would be spent reforking.  Supporting eudev will be clearly
useful only when that happens.

Have a lovely night.

>> 
>> [1] See 
>> https://gitweb.gentoo.org/proj/eudev.git/commit/?id=f559dc96f4105f605272defac9276ef9cb6f5dc6
>> 
>> >   
>> >>  
>> >>> Of course I know I (and anyone else) can do that. So then what's
>> >>> the point of discussing anything then?  
>> >>
>> >> Just because an argument is widely applicable does not make it
>> >> invalid.
>> >>
>> >> Note that this argument is seldom the first resort, since, as you
>> >> note, it's not overly productive.  Indeed, it was not the first
>> >> resort here. sys-fs/eudev has long overstayed the original removal
>> >> plan.
>> >>  
>> >>> What's the point of having a big tree with hundreds of packages?
>> >>> Why not have a very minimal tree instead and let everyone go and
>> >>> run multiple independent repos so we can all do what we want?
>> >>> Then we wouldn't have any discussion about what to include and
>> >>> what not. In fact maybe that's not a bad idea.  
>> >>
>> >> I'm not sure how to fit this within the context of the thread.
>> >>
>> >> Have a lovely evening.  
>> > 
>> >   
>> 


-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arsen Arsenović]

"Eddie Chapman"  writes:

> Not aiming this at you personally but this argument has been made more
> than once in this thread and I personally don't think it carries any
> weight, because it can be levelled at anyone who raises an issue about
> anything. If you don't like it, then just go and roll your own.

::gentoo is supposed to be a coherent set of packages provided by Gentoo
developers, with a reasonable scope.  eudev no longer fits into the
'coherent' part of that definition, and there are zero advantages to it
over systemd-utils[udev].

The _only_ difference between a sys-fs/eudev::eudev and
sys-fs/eudev::gentoo package that would exist if the former were to be
made into an overlay is that Gentoo developers would be responsible for
the latter.  There are no Gentoo developers interested in being
responsible for the latter (AFAIK), and there is no tangible benefit to
the latter for any Gentoo developer to latch onto.

Seeing as there is at least half a dozen people seemingly interested in
maintaining eudev, why not just form an overlay?  This way,
virtual/{,lib}udev doesn't get polluted with implementations which don't
fullfil the definition of a virtual provider in ::gentoo, nor with
use-flag hacks, but users which wish to use eudev still have access to
it, and upstream eudev gets half a dozen potential contributors, which
are needed, _badly_.  At risk of repeating myself, I'd like to point out
again that the only viable approach for eudev upstream to take is to
re-fork systemd and find a viable way to stay up-to-date, while fixing
up incompatibilities with musl.  I've made proposals a few years ago and
restated them in this thread.

> Of course I know I (and anyone else) can do that. So then what's the
> point of discussing anything then?

Just because an argument is widely applicable does not make it invalid.

Note that this argument is seldom the first resort, since, as you note,
it's not overly productive.  Indeed, it was not the first resort here.
sys-fs/eudev has long overstayed the original removal plan.

> What's the point of having a big tree with hundreds of packages? Why
> not have a very minimal tree instead and let everyone go and run
> multiple independent repos so we can all do what we want? Then we
> wouldn't have any discussion about what to include and what not. In
> fact maybe that's not a bad idea.

I'm not sure how to fit this within the context of the thread.

Have a lovely evening.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: last rites: sys-fs/eudev

[Arsen Arsenović]

Mike Gilbert  writes:

> On Thu, Sep 14, 2023 at 10:25 AM Arsen Arsenović  wrote:
>> Madhu  writes:
>> > systemd-udev cannot be built as a static binary again presumably a
>> > carefully thought out design decision behind its design and
>> > philosophy.
>>
>> Since static linking is seldom a good idea, it is more likely that
>> simply nobody bothered.  I don't recall any udev components in systemd
>> v249 (which is the version I attempted to rebase eudev on top of) which
>> can't be static linked.
>
> The main issue is symbol conflicts with several major projects.
>
> systemd makes careful use of ELF symbol visibility (hidden symbols) to
> prevent conflicts when libudev or libsystemd are linked with other
> projects.
>
> As I understand it, it is up to the linker to apply any visibility
> rules. This doesn't work for static libs since the linker isn't
> actually involved in their creation. A static library is really just
> an archive with a bunch of unlinked ELF objects.
>
> Since the symbol visibility rules are not applied, attempting to link
> against libudev.a or libsystemd.a leads to symbol conflicts in
> packages like LVM2 and cryptsetup. There are some Gentoo bug reports
> about this, but I can't find them immediately.
>
> The systemd project (upstream) has chosen not to work around these
> conflicts by renaming symbols, and instead chooses not to support
> static linking at all. They see static libs as being defective by
> design. If the symbol visibility issue could be resolved at the
> toolchain level, they would probably be more willing to support it.

We can entertain the useless idea of static linking by trying partial
linking.  I can give that a shot later.  Thanks for the background.

Have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: last rites: sys-fs/eudev

[Arsen Arsenović]

Madhu  writes:

[...snip...]
> One of the planned consequences of this tree-cleaning is the removal
> of genkernel, and the use of genkernel to build gentoo's initramfs.
>
> Genkernel uses eudev for udev, and it works because eudev can be built
> statically.
>
> systemd-udev cannot be built as a static binary again presumably a
> carefully thought out design decision behind its design and
> philosophy.

Since static linking is seldom a good idea, it is more likely that
simply nobody bothered.  I don't recall any udev components in systemd
v249 (which is the version I attempted to rebase eudev on top of) which
can't be static linked.  NSS and friends are rather disconnected from
udev-related components, and that's the closest thing I can think of to
requiring shared objects (note, *not* the same as being unusable in a
static-linked scenario).

In addition, there's precisely zero reasons why an initrd must be
composed of static linked components.

> eudev works perfectly well for the job genkernel does, udev is not a
> drop-in replacement for udev in genkernel initramfs because it doesn't
> support static compilation.  Removing eudev leads to a roadmap to
> deprecate genkernel last-rite and remove it.
>
> I know you are a dracut user, but I've been unable to use dracut with
> 1. cryptsetup swap + swsuspend + zfs on root.

I've had an LUKS2 + LVM setup which also had a swap file for suspend
with Dracut a few years back.  You should be able to declare what files
need to be brought up on the cmdline or in the config and have it do the
rest.  I've lost the notes on how exactly I did that since this was
years ago, but I recall that all the information came from
dracut.cmdline(7) (yeah, I know, manpages, unfortunate..), and I recall
needing rd.luks.uuid=, resume=, and presumably root=zfs:... in your
case.  I had my suspend a volume in LVM, though, so my resume= pointed
to /dev/foo/swap.  Please give that a shot (but keep a copy of your
current initrd so that you can retry easily).  There are plenty of
people on IRC who can help with your transition.

Dracut is more flexible than it gets credit for.

> Gentoo actively removes support for individual configurations, and
> only supports is for configurations that fedora has already engineered
> and controls because that is where the devs seem to be coming from.

Developers tend to support tools they use, and developers tend to be
more enthusiastic about tools that everyone uses and contributes to
rather than a few specific ones, produced in-house ages ago, by people
who are either no longer interested in those tools or in Gentoo.  It has
less to do with who made it and more to do with who uses it.

Have a lovely day :)
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arsen Arsenović]

Alexe Stefan  writes:

> It seems like the discussion got way off-topic.
> To see where where at, I'll try to summarize what was said so far.
>
> The claims are that eudev is unmaintained upstream, downstream and has
> open bugs.
> Upstream, last commit was 3 weeks ago.

Please, take into account the contents of said commits.

One of the more recent ones bumps the version in the .pc file while
/stubbing/ only one of the APIs versions up to and including that one
added.

I've originally advocated for keeping eudev, and have put in some effort
to restart the project by essentially reforking systemd 'today' (i.e. at
the time a few years ago).  Since then it has been effectively
demonstrated to me that there is no interest in doing that (which is,
mind you, the only viable path for remaining compatible.  Note that
competition here is perfectly useless, so staying compatible is the only
viable path for the existence of the project *at all*); as a result, I
began to lose motivation to continue, combined with being quite busy
that year, I ended up simply switching to systemd-utils[udev], which was
equivalent, except up-to-date, without ever finishing extracting/porting
the needed shared code.

The merge-base (which is a rough measure but it provides a time frame)
of eudev and systemd is from Nov 2012, since then, only 1.3k commits
were added to the eudev tree (as opposed to the systemd tree, where
57.5k commits were added, note that not all of those, or even many of
those, are udev-related, but many are shared code between udev and other
components).

On top of that, only 143 of those were added to the repository since
Gentoo stopped maintaining eudev.

I estimate ~800 commits were added to systemd's udev since the eudev
project got separated (and then eudev was already trailing long
behind!), without counting shared code, so it's clear that eudev is
failing to keep pace, let alone catch up

I agree that upstream is alive.  That's what life support is.

> Downstream, Orbea said he is willing to help maintain it. He is known
> for his great work on libressl(thank you), so there should be no
> problems here.

LibreSSL is an excellent example of a fork that is only useful if it
remains compatible failing to be useful because it fails to be
compatible.  Thank you for bringing it up, it is quite a good cautionary
tale.  (naturally, I also used that back in the day...)

> Most of those bugs are invalid, outdated or being worked upon.
>
> Are there any other problems here?

The approach of forking in the traditional sense is fundamentally flawed
here.

If you want to keep eudev alive, please, do us all a favor and give
upstream a hand at re-forking systemd, and finding a sustainable
approach for keeping the fork up-to-date.  I originally did this by
filtering down the systemd repository into the appropriate directory
structure, and then adding in a new build system and extracting the
shared code.  The filtered repository can then be used as a branch or
separate repository that's merged into the new build system (either as a
subtree or as the toplevel).  This should have kept most of the code
easy to update.

PS: I had decided to respond to ~5 emails in this thread, but I realized
that the answer to all of them would be exactly what I wrote here.  This
thread feels like a lot of repetition.

Have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] savedconfig.eclass: do not preserve symlink in restore_config

[Arsen Arsenović]

Michael Orlitzky  writes:

> If so, the symlink should point to a superuser-only location to avoid
> creating any new vulnerabilities. We can't fix the general problem, but
> we could at least mention in the docs that symlinks will (now) be
> followed and that users should be careful if they want to maintain the
> files elsewhere.

I believe that the target directory of this cp can be considered
equivalent in terms of access to any superuser-only directory, so I'm
not sure I see the problem with this change.

LGTM
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: EGO_SUM

[Arsen Arsenović]

Andrew Ammerlaan  writes:

> On 30/05/2023 18:35, Arthur Zamarin wrote:
>> My solution is as such:
>> 1. Undeprecate EGO_SUM in eclass
>> 2. Forbid it's usage in ::gentoo (done by pkgcheck, error level, will
>> fail CI and as such we can see the misuse). Overlays are allowed.
>> 3. Maintainer starts talks with upstreams to add release workflow to
>> create vendored source tarball, in hopes of it succeeding. "Start early,
>> to future profit". I see this flow similar to the "always try to
>> upstream patches".
>> 4. Until upstream adds it, in ::gentoo use vendor tarballs.
>> I also think many devs agree with this solution, but I can't talk for
>> them, so I'll be happy agreeing devs can at least reply shortly their
>> agreement or disagreement.
>
> I fully agree with Arthur

+1

> With regards to proxy-maintained packages: The proxy can generate and upload
> the vendor tarball for the proxied, this is not that much extra work.

This expands the required trust in proxy maintainers, in a way which is
unusually easy to double check.

We can automate generating vendor tarballs (or more).  If implemented
such that tarballs are reproducible, it should be easy to verify by
running the same procedure from a different host and verifying.

There would still be a slight cost to an initial 'whitelist package'
step or such, but IMO, that's not a very large cost.  (and, also,
possibly some other mechanism could be implemented)

> Best regards,
> Andrew


-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] profiles: create USE=valgrind global USE flag

[Arsen Arsenović]

Sam James  writes:

> This always has the same meaning in packages - build in annotations to help
> with e.g. custom memory allocators to reduce noise and improve Valgrind's 
> accuracy.
>
> All invalid uses of this were already fixed (cases where it was used to 
> control
> running the testsuite under Valgrind which we don't want to do, it's too flaky
> under sandbox & not reliable with diff arches.)

LGTM.  thanks!

> Signed-off-by: Sam James 
> ---
>  profiles/use.desc | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/profiles/use.desc b/profiles/use.desc
> index 04ca8e845ccd9..675fd291fee22 100644
> --- a/profiles/use.desc
> +++ b/profiles/use.desc
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2022 Gentoo Authors
> +# Copyright 1999-2023 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # Keep them sorted
> @@ -333,6 +333,7 @@ usb - Add USB support to applications that have optional 
> USB support (e.g. cups)
>  v4l - Enable support for video4linux (using linux-headers or userspace 
> libv4l libraries)
>  vaapi - Enable Video Acceleration API for hardware decoding
>  vala - Enable bindings for dev-lang/vala
> +valgrind - Enable annotations for accuracy. May slow down runtime
> slightly. Safe to use even if not currently using dev-util/valgrind
>  vanilla - Do not add extra patches which change default behaviour; DO NOT USE
> THIS ON A GLOBAL SCALE as the severity of the meaning changes drastically
>  vcd - Video CD support
>  vdpau - Enable the Video Decode and Presentation API for Unix acceleration 
> interface


-- 
Arsen Arsenović


signature.asc
Description: PGP signature

[gentoo-dev] Re: [PATCH] unpacker.eclass: Don't assume the default tar is stdin

[Arsen Arsenović]

Arsen Arsenović  writes:

> Despite common misconception, the default GNU tar tarfile is not stdin.
> On some systems, this can cause tar to fail to extract relevant files.
>
> See '(tar)file tutorial' for a description of how the default is picked.
>
> Bug: https://bugs.gentoo.org/903631
> Closes: https://bugs.gentoo.org/903914
> Closes: https://bugs.gentoo.org/903919
>
> Signed-off-by: Arsen Arsenović 
> ---
> This patch does not close https://bugs.gentoo.org/903631, as I intend to
> turn that into a tracker bug.

Or not - amended locally to close it.  See c6.

>  eclass/unpacker.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/unpacker.eclass b/eclass/unpacker.eclass
> index 650de4bd3f75..652527b52ec6 100644
> --- a/eclass/unpacker.eclass
> +++ b/eclass/unpacker.eclass
> @@ -325,7 +325,7 @@ unpack_deb() {
>   $(tc-getBUILD_AR) p "${deb}" "${f}" | ${decomp:-cat}
>   assert "unpacking ${f} from ${deb} failed"
>   fi
> - } | tar --no-same-owner -x
> + } | tar --no-same-owner -xf -
>   assert "unpacking ${deb} failed"
>  }


-- 
Arsen Arsenović


signature.asc
Description: PGP signature

[gentoo-dev] [PATCH] unpacker.eclass: Don't assume the default tar is stdin

[Arsen Arsenović]

Despite common misconception, the default GNU tar tarfile is not stdin.
On some systems, this can cause tar to fail to extract relevant files.

See '(tar)file tutorial' for a description of how the default is picked.

Bug: https://bugs.gentoo.org/903631
Closes: https://bugs.gentoo.org/903914
Closes: https://bugs.gentoo.org/903919

Signed-off-by: Arsen Arsenović 
---
This patch does not close https://bugs.gentoo.org/903631, as I intend to
turn that into a tracker bug.

 eclass/unpacker.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/unpacker.eclass b/eclass/unpacker.eclass
index 650de4bd3f75..652527b52ec6 100644
--- a/eclass/unpacker.eclass
+++ b/eclass/unpacker.eclass
@@ -325,7 +325,7 @@ unpack_deb() {
$(tc-getBUILD_AR) p "${deb}" "${f}" | ${decomp:-cat}
assert "unpacking ${f} from ${deb} failed"
fi
-   } | tar --no-same-owner -x
+   } | tar --no-same-owner -xf -
assert "unpacking ${deb} failed"
 }
 
-- 
2.40.0

[gentoo-dev] Re: Confirm subscription to gentoo-dev@lists.gentoo.org

[Arsen Arsenović]

-- 
Arsen Arsenović

Re: [gentoo-dev] [PATCH 4/4] sys-devel/automake: Fix installing broken Info pages

[Arsen Arsenović]

Florian Schmaus  writes:

> On 26/03/2023 22.30, Arsen Arsenović wrote:
>> This commit replaces the Info page slotting mechanism with simple
>> INFOPATH setting.
>> Closes: https://bugs.gentoo.org/902461
>> Signed-off-by: Arsen Arsenović 
>> ---
>>   sys-devel/automake/automake-1.11.6-r4.ebuild |  84 +
>>   sys-devel/automake/automake-1.16.5-r1.ebuild | 119 +++
>>   sys-devel/automake/automake-.ebuild  |  48 +++-
>>   3 files changed, 220 insertions(+), 31 deletions(-)
>>   create mode 100644 sys-devel/automake/automake-1.11.6-r4.ebuild
>>   create mode 100644 sys-devel/automake/automake-1.16.5-r1.ebuild
>> diff --git a/sys-devel/automake/automake-1.11.6-r4.ebuild
>> b/sys-devel/automake/automake-1.11.6-r4.ebuild
>> new file mode 100644
>> index ..4e0857012d71
>> --- /dev/null
>> +++ b/sys-devel/automake/automake-1.11.6-r4.ebuild
>> @@ -0,0 +1,84 @@
>> +# Copyright 1999-2023 Gentoo Authors
>> +# Distributed under the terms of the GNU General Public License v2
>> +
>> +EAPI=7
>> +
>> +DESCRIPTION="Used to generate Makefile.in from Makefile.am"
>> +HOMEPAGE="https://www.gnu.org/software/automake/;
>> +SRC_URI="mirror://gnu/${PN}/${P}.tar.xz"
>> +
>> +LICENSE="GPL-2"
>> +# Use Gentoo versioning for slotting.
>> +SLOT="${PV:0:4}"
>> +KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 
>> ~riscv ~s390 ~sparc ~x86"
>> +IUSE=""
>> +RESTRICT="test"
>> +
>> +RDEPEND=">=dev-lang/perl-5.6
>> +>=sys-devel/automake-wrapper-10
>> +>=sys-devel/autoconf-2.69:*
>> +sys-devel/gnuconfig"
>> +DEPEND="${RDEPEND}
>> +sys-apps/help2man"
>> +BDEPEND="app-arch/gzip"
>> +
>> +PATCHES=(
>> +"${FILESDIR}"/${PN}-1.10-perl-5.16.patch #424453
>> +"${FILESDIR}"/${PN}-1.11-install-sh-avoid-low-risk-race-in-tmp.patch
>> +"${FILESDIR}"/${PN}-1.13-perl-escape-curly-bracket-r1.patch
>> +)
>> +
>> +src_prepare() {
>> +default
>> +export WANT_AUTOCONF=2.5
>> +export HELP2MAN=true
>> +sed -i -e "/APIVERSION=/s:=.*:=${SLOT}:" configure || die
>> +export TZ="UTC"  #589138
>> +}
>> +
>> +src_compile() {
>> +# Also used in install.
>> +infopath="${EPREFIX}/usr/share/automake-${PV}/info"
>
> Not sure if we have a style policy on this, but I read lowercase variables as
> local-function variables. However, 'infopath', as is, is used in a subsequent
> ebuild phase function. So maybe s/infopath/INFOPATH/ or maybe even MY_INFOPATH
> or AUTOMAKE_INFOPATH?

Yes, fair enough.  I'll update it to MY_INFOPATH.

> - Flow


-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH 1/4] toolchain-autoconf.eclass: Add option to disable Info slotting

[Arsen Arsenović]

Hi Florian,

Florian Schmaus  writes:

> On 26/03/2023 22.30, Arsen Arsenović wrote:
>> Closes: https://bugs.gentoo.org/902461
>> Signed-off-by: Arsen Arsenović 
>> ---
>>   eclass/toolchain-autoconf.eclass | 46 +---
>>   1 file changed, 43 insertions(+), 3 deletions(-)
>> diff --git a/eclass/toolchain-autoconf.eclass
>> b/eclass/toolchain-autoconf.eclass
>> index 2ba27638468e..140ee4c9b5eb 100644
>> --- a/eclass/toolchain-autoconf.eclass
>> +++ b/eclass/toolchain-autoconf.eclass
>> @@ -1,4 +1,4 @@
>> -# Copyright 1999-2022 Gentoo Authors
>> +# Copyright 1999-2023 Gentoo Authors
>>   # Distributed under the terms of the GNU General Public License v2
>> # @ECLASS: toolchain-autoconf.eclass
>> @@ -18,6 +18,20 @@ esac
>>   if [[ -z ${_TOOLCHAIN_AUTOCONF_ECLASS} ]]; then
>>   _TOOLCHAIN_AUTOCONF_ECLASS=1
>>   +# @ECLASS_VARIABLE: TC_AUTOCONF_BREAK_INFOS
>> +# @DESCRIPTION:
>> +# Enables slotting logic on the installed info pages.  This includes
>> +# mangling the pages in order to include a version number.  Empty by
>> +# default, and only exists for existing ebuild revisions to use.  Set
>
> Referring to "existing ebuild revisions" becomes confusing in the future, when
> there are existing ebuilds that do not use this variable.

My intention was that this variable goes away as soon as said revisions
are out of tree, so I wasn't thinking about that time-frame but I'll
clarify and push to my branch.

Thanks, have a lovely day.

> Maybe "and only set by legacy ebuilds to phase out the broken slotting
> logic. New ebuilds should not set this variable."
>
> - Flow


-- 
Arsen Arsenović


signature.asc
Description: PGP signature

[gentoo-dev] [PATCH 4/4] sys-devel/automake: Fix installing broken Info pages

[Arsen Arsenović]

This commit replaces the Info page slotting mechanism with simple
INFOPATH setting.

Closes: https://bugs.gentoo.org/902461
Signed-off-by: Arsen Arsenović 
---
 sys-devel/automake/automake-1.11.6-r4.ebuild |  84 +
 sys-devel/automake/automake-1.16.5-r1.ebuild | 119 +++
 sys-devel/automake/automake-.ebuild  |  48 +++-
 3 files changed, 220 insertions(+), 31 deletions(-)
 create mode 100644 sys-devel/automake/automake-1.11.6-r4.ebuild
 create mode 100644 sys-devel/automake/automake-1.16.5-r1.ebuild

diff --git a/sys-devel/automake/automake-1.11.6-r4.ebuild 
b/sys-devel/automake/automake-1.11.6-r4.ebuild
new file mode 100644
index ..4e0857012d71
--- /dev/null
+++ b/sys-devel/automake/automake-1.11.6-r4.ebuild
@@ -0,0 +1,84 @@
+# Copyright 1999-2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+DESCRIPTION="Used to generate Makefile.in from Makefile.am"
+HOMEPAGE="https://www.gnu.org/software/automake/;
+SRC_URI="mirror://gnu/${PN}/${P}.tar.xz"
+
+LICENSE="GPL-2"
+# Use Gentoo versioning for slotting.
+SLOT="${PV:0:4}"
+KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~riscv 
~s390 ~sparc ~x86"
+IUSE=""
+RESTRICT="test"
+
+RDEPEND=">=dev-lang/perl-5.6
+   >=sys-devel/automake-wrapper-10
+   >=sys-devel/autoconf-2.69:*
+   sys-devel/gnuconfig"
+DEPEND="${RDEPEND}
+   sys-apps/help2man"
+BDEPEND="app-arch/gzip"
+
+PATCHES=(
+   "${FILESDIR}"/${PN}-1.10-perl-5.16.patch #424453
+   "${FILESDIR}"/${PN}-1.11-install-sh-avoid-low-risk-race-in-tmp.patch
+   "${FILESDIR}"/${PN}-1.13-perl-escape-curly-bracket-r1.patch
+)
+
+src_prepare() {
+   default
+   export WANT_AUTOCONF=2.5
+   export HELP2MAN=true
+   sed -i -e "/APIVERSION=/s:=.*:=${SLOT}:" configure || die
+   export TZ="UTC"  #589138
+}
+
+src_compile() {
+   # Also used in install.
+   infopath="${EPREFIX}/usr/share/automake-${PV}/info"
+   econf --infodir="${infopath}"
+
+   local x
+   for x in aclocal automake; do
+   help2man "perl -Ilib ${x}" > doc/${x}-${SLOT}.1
+   done
+}
+
+src_install() {
+   default
+
+   rm \
+   "${ED}"/usr/bin/{aclocal,automake} \
+   "${ED}"/usr/share/man/man1/{aclocal,automake}.1 || die
+
+   # remove all config.guess and config.sub files replacing them
+   # w/a symlink to a specific gnuconfig version
+   local x
+   for x in guess sub ; do
+   dosym ../gnuconfig/config.${x} \
+   /usr/share/${PN}-${SLOT}/config.${x}
+   done
+
+   # Avoid QA message about pre-compressed file in docs
+   local tarfile="${ED}/usr/share/doc/${PF}/amhello-1.0.tar.gz"
+   if [[ -f "${tarfile}" ]] ; then
+   gunzip "${tarfile}" || die
+   fi
+
+   pushd "${D}/${infopath}" >/dev/null || die
+   for f in *.info*; do
+   # Install convenience aliases for versioned Automake pages.
+   ln -s "$f" "${f/./-${PV}.}" || die
+   done
+   popd >/dev/null || die
+
+   local major="$(ver_cut 1)"
+   local minor="$(ver_cut 2)"
+   local idx="$((9-(major*1000+minor)))"
+   newenvd - "06automake${idx}" <<-EOF
+   INFOPATH="${infopath}"
+   EOF
+}
diff --git a/sys-devel/automake/automake-1.16.5-r1.ebuild 
b/sys-devel/automake/automake-1.16.5-r1.ebuild
new file mode 100644
index ..d49dcf79faa3
--- /dev/null
+++ b/sys-devel/automake/automake-1.16.5-r1.ebuild
@@ -0,0 +1,119 @@
+# Copyright 1999-2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+PYTHON_COMPAT=( python3_{9..11} )
+
+inherit python-any-r1
+
+if [[ ${PV} ==  ]] ; then
+   EGIT_REPO_URI="https://git.savannah.gnu.org/r/${PN}.git;
+   inherit git-r3
+else
+   if [[ ${PV/_beta} == ${PV} ]]; then
+   MY_P="${P}"
+   SRC_URI="mirror://gnu/${PN}/${P}.tar.xz
+   https://alpha.gnu.org/pub/gnu/${PN}/${MY_P}.tar.xz;
+   KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~m68k 
~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86 ~x64-cygwin ~amd64-linux ~x86-linux 
~ppc-macos ~x64-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
+   else
+   MY_PV="$(ver_cut 1).$(($(ver_cut 2)-1))b"
+   MY_P="${PN}-${MY_PV}"
+
+   # Alpha/beta releases are not distributed on the usual mirrors.
+   SRC_URI="https://alpha.gnu.org/pub/gnu/${PN}/${MY_P}.tar.xz;
+   fi
+
+  

[gentoo-dev] [PATCH 3/4] sys-devel/autoconf: Add revisions without Info path breaking

[Arsen Arsenović]

Closes: https://bugs.gentoo.org/902461
Signed-off-by: Arsen Arsenović 
---
 sys-devel/autoconf/autoconf-2.13-r8.ebuild | 59 +++
 sys-devel/autoconf/autoconf-2.69-r9.ebuild | 63 
 sys-devel/autoconf/autoconf-2.71-r6.ebuild | 88 ++
 3 files changed, 210 insertions(+)
 create mode 100644 sys-devel/autoconf/autoconf-2.13-r8.ebuild
 create mode 100644 sys-devel/autoconf/autoconf-2.69-r9.ebuild
 create mode 100644 sys-devel/autoconf/autoconf-2.71-r6.ebuild

diff --git a/sys-devel/autoconf/autoconf-2.13-r8.ebuild 
b/sys-devel/autoconf/autoconf-2.13-r8.ebuild
new file mode 100644
index ..69156d4abf78
--- /dev/null
+++ b/sys-devel/autoconf/autoconf-2.13-r8.ebuild
@@ -0,0 +1,59 @@
+# Copyright 1999-2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit toolchain-autoconf
+
+DESCRIPTION="Used to create autoconfiguration files"
+HOMEPAGE="https://www.gnu.org/software/autoconf/autoconf.html;
+SRC_URI="mirror://gnu/${PN}/${P}.tar.gz"
+
+LICENSE="GPL-2"
+SLOT="${PV:0:3}"
+KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~m68k ~mips ~ppc ~ppc64 
~riscv ~s390 ~sparc ~x86 ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos 
~sparc-solaris ~x64-solaris ~x86-solaris"
+IUSE="test"
+RESTRICT="!test? ( test )"
+
+BDEPEND="
+   dev-lang/perl
+   sys-devel/m4
+   test? ( dev-util/dejagnu )
+"
+RDEPEND="
+   ${BDEPEND}
+   sys-apps/texinfo
+   >=sys-devel/autoconf-wrapper-13
+"
+
+PATCHES=(
+   "${FILESDIR}"/${P}-gentoo.patch
+   "${FILESDIR}"/${P}-destdir.patch
+   "${FILESDIR}"/${P}-test-fixes.patch #146592
+   "${FILESDIR}"/${P}-perl-5.26.patch
+   "${FILESDIR}"/${P}-K-R-decls-clang.patch
+   "${FILESDIR}"/${P}-Clang-16-fixes-for-various-tests.patch
+)
+
+src_configure() {
+   # make sure configure is newer than configure.in
+   touch configure || die
+
+   # need to include --exec-prefix and --bindir or our
+   # DESTDIR patch will trigger sandbox hate :(
+   #
+   # need to force locale to C to avoid bugs in the old
+   # configure script breaking the install paths #351982
+   #
+   # force to `awk` so that we don't encode another awk that
+   # happens to currently be installed, but might later be
+   # uninstalled (like mawk).  same for m4.
+   ac_cv_path_M4="m4" \
+   ac_cv_prog_AWK="awk" \
+   LC_ALL=C \
+   econf \
+   --exec-prefix="${EPREFIX}"/usr \
+   --bindir="${EPREFIX}"/usr/bin \
+   --program-suffix="-${PV}" \
+   --infodir="${TC_AUTOCONF_INFOPATH}"
+}
diff --git a/sys-devel/autoconf/autoconf-2.69-r9.ebuild 
b/sys-devel/autoconf/autoconf-2.69-r9.ebuild
new file mode 100644
index ..45c66d96f77c
--- /dev/null
+++ b/sys-devel/autoconf/autoconf-2.69-r9.ebuild
@@ -0,0 +1,63 @@
+# Copyright 1999-2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+if [[ ${PV} ==  ]] ; then
+   EGIT_REPO_URI="https://git.savannah.gnu.org/git/autoconf.git;
+   inherit git-r3
+else
+   SRC_URI="mirror://gnu/${PN}/${P}.tar.xz
+   ftp://alpha.gnu.org/pub/gnu/${PN}/${P}.tar.xz
+   
https://dev.gentoo.org/~polynomial-c/dist/${P}-runstatedir_patches.tar.xz;
+   KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 
~riscv ~s390 ~sparc ~x86 ~x64-cygwin ~amd64-linux ~x86-linux ~ppc-macos 
~x64-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
+fi
+
+inherit toolchain-autoconf
+
+DESCRIPTION="Used to create autoconfiguration files"
+HOMEPAGE="https://www.gnu.org/software/autoconf/autoconf.html;
+
+LICENSE="GPL-3+"
+SLOT="${PV}"
+IUSE="emacs"
+
+BDEPEND="
+   >=sys-devel/m4-1.4.16
+   >=dev-lang/perl-5.6
+"
+RDEPEND="
+   ${BDEPEND}
+   >=sys-devel/autoconf-wrapper-13
+   !~sys-devel/${P}:2.5
+"
+
+[[ ${PV} ==  ]] && BDEPEND+=" >=sys-apps/texinfo-4.3"
+
+PDEPEND="emacs? ( app-emacs/autoconf-mode )"
+
+PATCHES=(
+   "${FILESDIR}"/${PN}-2.69-perl-5.26.patch
+   "${FILESDIR}"/${P}-fix-libtool-test.patch
+   "${FILESDIR}"/${PN}-2.69-perl-5.26-2.patch
+   "${FILESDIR}"/${P}-make-tests-bash5-compatible.patch
+   "${FILESDIR}"/${P}-K-R-decls-clang.patch
+
+   "${WORKDIR}"/patches/${P}-texinfo.patch
+)
+
+src_prepare() {
+   # usr/bin/libtool is provided by binutils-apple, need gnu libtool
+   if [[ ${CHOST} == *-darwin* ]] ; then
+   PATCHES+=( "${FILESDIR}"/${PN}-2.61-darwin

[gentoo-dev] [PATCH 2/4] sys-devel/autoconf: Set TC_AUTOCONF_BREAK_INFOS=yes to prevent changes

[Arsen Arsenović]

Recently, the toolchain-autoconf class was edited not to naively slot
Info pages, breaking them in the process.  To prevent existing revisions
from changing contents, TC_AUTOCONF_BREAK_INFOS was added to permit
using old behavior currently.

Closes: https://bugs.gentoo.org/902461
Signed-off-by: Arsen Arsenović 
---
 sys-devel/autoconf/autoconf-2.13-r2.ebuild | 4 +++-
 sys-devel/autoconf/autoconf-2.13-r7.ebuild | 4 +++-
 sys-devel/autoconf/autoconf-2.69-r5.ebuild | 4 +++-
 sys-devel/autoconf/autoconf-2.69-r8.ebuild | 4 +++-
 sys-devel/autoconf/autoconf-2.71-r1.ebuild | 4 +++-
 sys-devel/autoconf/autoconf-2.71-r5.ebuild | 4 +++-
 6 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/sys-devel/autoconf/autoconf-2.13-r2.ebuild 
b/sys-devel/autoconf/autoconf-2.13-r2.ebuild
index f26c02ae862c..787687f1b8c0 100644
--- a/sys-devel/autoconf/autoconf-2.13-r2.ebuild
+++ b/sys-devel/autoconf/autoconf-2.13-r2.ebuild
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
@@ -33,6 +33,8 @@ PATCHES=(
"${FILESDIR}"/${PN}-2.13-perl-5.26.patch
 )
 
+TC_AUTOCONF_BREAK_INFOS=yes
+
 src_configure() {
# make sure configure is newer than configure.in
touch configure || die
diff --git a/sys-devel/autoconf/autoconf-2.13-r7.ebuild 
b/sys-devel/autoconf/autoconf-2.13-r7.ebuild
index 055d8286769d..b4942c1bcb7b 100644
--- a/sys-devel/autoconf/autoconf-2.13-r7.ebuild
+++ b/sys-devel/autoconf/autoconf-2.13-r7.ebuild
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
@@ -35,6 +35,8 @@ PATCHES=(
"${FILESDIR}"/${P}-Clang-16-fixes-for-various-tests.patch
 )
 
+TC_AUTOCONF_BREAK_INFOS=yes
+
 src_configure() {
# make sure configure is newer than configure.in
touch configure || die
diff --git a/sys-devel/autoconf/autoconf-2.69-r5.ebuild 
b/sys-devel/autoconf/autoconf-2.69-r5.ebuild
index f51aa71c2d0a..947bf12f49b4 100644
--- a/sys-devel/autoconf/autoconf-2.69-r5.ebuild
+++ b/sys-devel/autoconf/autoconf-2.69-r5.ebuild
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
@@ -41,6 +41,8 @@ PATCHES=(
"${WORKDIR}"/patches/${P}-runstatedir_info.patch
 )
 
+TC_AUTOCONF_BREAK_INFOS=yes
+
 src_prepare() {
# usr/bin/libtool is provided by binutils-apple, need gnu libtool
if [[ ${CHOST} == *-darwin* ]] ; then
diff --git a/sys-devel/autoconf/autoconf-2.69-r8.ebuild 
b/sys-devel/autoconf/autoconf-2.69-r8.ebuild
index 3730430ac8a4..1c1ebcfc681e 100644
--- a/sys-devel/autoconf/autoconf-2.69-r8.ebuild
+++ b/sys-devel/autoconf/autoconf-2.69-r8.ebuild
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
@@ -46,6 +46,8 @@ PATCHES=(
"${WORKDIR}"/patches/${P}-texinfo.patch
 )
 
+TC_AUTOCONF_BREAK_INFOS=yes
+
 src_prepare() {
# usr/bin/libtool is provided by binutils-apple, need gnu libtool
if [[ ${CHOST} == *-darwin* ]] ; then
diff --git a/sys-devel/autoconf/autoconf-2.71-r1.ebuild 
b/sys-devel/autoconf/autoconf-2.71-r1.ebuild
index 7ef4e0bcbeb7..9f2ea4b973fe 100644
--- a/sys-devel/autoconf/autoconf-2.71-r1.ebuild
+++ b/sys-devel/autoconf/autoconf-2.71-r1.ebuild
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
@@ -43,6 +43,8 @@ PDEPEND="emacs? ( app-emacs/autoconf-mode )"
 
 PATCHES=( "${FILESDIR}/${P}-time.patch" )
 
+TC_AUTOCONF_BREAK_INFOS=yes
+
 src_prepare() {
# usr/bin/libtool is provided by binutils-apple, need gnu libtool
if [[ ${CHOST} == *-darwin* ]] ; then
diff --git a/sys-devel/autoconf/autoconf-2.71-r5.ebuild 
b/sys-devel/autoconf/autoconf-2.71-r5.ebuild
index 7749d47f435e..722aa8cc1e22 100644
--- a/sys-devel/autoconf/autoconf-2.71-r5.ebuild
+++ b/sys-devel/autoconf/autoconf-2.71-r5.ebuild
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
@@ -50,6 +50,8 @@ PATCHES=(
"${FILESDIR}"/${P}-K-R-decls-clang-deux.patch
 )
 
+TC_AUTOCONF_BREAK_INFOS=yes
+
 src_prepare() {
# usr/bin/libtool is provided by binutils-apple, need gnu libtool
if [[ ${CHOST} == *-darwin* ]] ; then
-- 
2.40.0

[gentoo-dev] [PATCH 1/4] toolchain-autoconf.eclass: Add option to disable Info slotting

[Arsen Arsenović]

Closes: https://bugs.gentoo.org/902461
Signed-off-by: Arsen Arsenović 
---
 eclass/toolchain-autoconf.eclass | 46 +---
 1 file changed, 43 insertions(+), 3 deletions(-)

diff --git a/eclass/toolchain-autoconf.eclass b/eclass/toolchain-autoconf.eclass
index 2ba27638468e..140ee4c9b5eb 100644
--- a/eclass/toolchain-autoconf.eclass
+++ b/eclass/toolchain-autoconf.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: toolchain-autoconf.eclass
@@ -18,6 +18,20 @@ esac
 if [[ -z ${_TOOLCHAIN_AUTOCONF_ECLASS} ]]; then
 _TOOLCHAIN_AUTOCONF_ECLASS=1
 
+# @ECLASS_VARIABLE: TC_AUTOCONF_BREAK_INFOS
+# @DESCRIPTION:
+# Enables slotting logic on the installed info pages.  This includes
+# mangling the pages in order to include a version number.  Empty by
+# default, and only exists for existing ebuild revisions to use.  Set
+# to a non-empty value to enable.
+# @DEPRECATED: none
+: "${TC_AUTOCONF_BREAK_INFOS:=}"
+
+# @ECLASS_VARIABLE: TC_AUTOCONF_INFOPATH
+# @DESCRIPTION:
+# Where to install info files if not slotting.
+TC_AUTOCONF_INFOPATH="${EPREFIX}/usr/share/autoconf-${PV}/info"
+
 toolchain-autoconf_src_prepare() {
find -name Makefile.in -exec sed -i '/^pkgdatadir/s:$:-@VERSION@:' {} + 
|| die
default
@@ -26,7 +40,15 @@ toolchain-autoconf_src_prepare() {
 toolchain-autoconf_src_configure() {
# Disable Emacs in the build system since it is in a separate package.
export EMACS=no
-   econf --program-suffix="-${PV}" || die
+   local myconf=(
+   --program-suffix="-${PV}"
+   )
+   if [[ -z "${TC_AUTOCONF_BREAK_INFOS}" && "${SLOT}" != 0 ]]; then
+   myconf+=(
+   --infodir="${TC_AUTOCONF_INFOPATH}"
+   )
+   fi
+   econf "${myconf[@]}" || die
# econf updates config.{sub,guess} which forces the manpages
# to be regenerated which we dont want to do #146621
touch man/*.1
@@ -65,7 +87,25 @@ slot_info_pages() {
 
 toolchain-autoconf_src_install() {
default
-   slot_info_pages
+   if [[ -n "${TC_AUTOCONF_BREAK_INFOS}" ]]; then
+   slot_info_pages
+   else
+   rm -f dir || die
+
+   local major="$(ver_cut 1)"
+   local minor="$(ver_cut 2)"
+   local idx="$((9-(major*1000+minor)))"
+   newenvd - "06autoconf${idx}" <<-EOF
+   INFOPATH="${TC_AUTOCONF_INFOPATH}"
+   EOF
+
+   pushd "${D}/${TC_AUTOCONF_INFOPATH}" >/dev/null || die
+   for f in *.info*; do
+   # Install convenience aliases for versioned Autoconf 
pages.
+   ln -s "$f" "${f/./-${PV}.}" || die
+   done
+   popd >/dev/null || die
+   fi
 }
 
 fi
-- 
2.40.0

[gentoo-dev] Re: [PATCH] profiles/base: add cache vars for -Wimplicit-function-declaration silencing

[Arsen Arsenović]

Sam James  writes:

> Autoconf has a builtin check to try figure out how to make the compiler
> error out on implicit function declarations. This check necessarily emits
> such a warning/error. We know that -Werror=implicit-function-declaration
> will work on any compiler we care about, so just force that to avoid noise.
>
> This means we don't have to try whitelist 'strchr'.
>
> Signed-off-by: Sam James 
> ---
>  profiles/base/make.defaults | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
> index ab69dbfae58ee..bdffd57047bbc 100644
> --- a/profiles/base/make.defaults
> +++ b/profiles/base/make.defaults
> @@ -181,3 +181,9 @@ ADA_TARGET="gnat_2021"
>  # Default targets for lua{,-single}.eclass
>  LUA_SINGLE_TARGET="lua5-1"
>  LUA_TARGETS="lua5-1"
> +
> +# Sam James  (2023-02-28)
> +# Reduce -Wimplicit-function-declaration noise from autoconf. Any compilers
> +# we care about should match these anyway. See 
> https://wiki.gentoo.org/wiki/Modern_C_porting.
> +export ac_cv_c_undeclared_builtin_options="none needed"
> +export 
> gl_cv_compiler_check_decl_option="-Werror=implicit-function-declaration"

LGTM.

-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] New pre-GLEP: TEST_SUITE_PRESENT variable

[Arsen Arsenović]

 ``src_test`` implementations can be very generic and succeed
> +   without actually performing any testing.  It is therefore reasonable
> +   to default to ``indeterminate`` result when they are used,
> +   and recommend them to explicitly override the variable.
> +
> +3. Explicit ``src_test`` declared in ebuild can generally be assumed
> +   to actually run tests, with the exception of declaring the function
> +   to prevent ``default_src_test`` from running.  It therefore makes
> +   sense to default to ``yes`` but allow ebuilds to override the value
> +   in the latter case.
> +
> +
> +Backwards Compatibility
> +===
> +
> +This GLEP is entirely optional.  The package managers not implementing
> +it will treat the variable as a regular bash variable set by the test
> +phase and ignore it.
> +
> +
> +Reference Implementation
> +
> +
> +TODO
> +
> +
> +Copyright
> +=
> +
> +This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
> +International License.  To view a copy of this license, visit
> +https://creativecommons.org/licenses/by-sa/4.0/.

This approach looks OK to me.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

[gentoo-dev] [PATCH] toolchain.eclass: Register the D tc_feature

[Arsen Arsenović]

This behavior is relied on elsewhere, for setting BDEPENDs correctly.

Signed-off-by: Arsen Arsenović 
---
Hi there,

I was trying to merge GDC, and noticed that the non-selfhost BDEPEND is
missing for GCC 13.  Specifically, the following block was never
enterred:

  # TODO: Add a pkg_setup & pkg_pretend check for whether the active compiler
  # supports D.
  if tc_has_feature d && tc_version_is_at_least 12.0 ; then
# D in 12+ is self-hosting and needs D to bootstrap.
# TODO: package some binary we can use, like for Ada
# bug #840182
BDEPEND+=" d? ( || ( sys-devel/gcc[d(-)] 

Re: [gentoo-dev] dev-python/ package naming policy?

[Arsen Arsenović]

Andrew Ammerlaan  writes:

> On 28/01/2023 19:02, Ulrich Mueller wrote:
>>>>>>> On Sat, 28 Jan 2023, Michał Górny wrote:
>>>> However, it's been pointed out that this makes it hard for people to
>>>> find packages they're looking for.
>> I don't understand this argument. Why would all-lowercase make finding a
>> package harder?
>
> Here's an example, on pypi we have packages:
> - git-python
> - python-git
> - GitPython
> - git-py
>
> Each of these is a different package. The package you usually want is
> GitPython, but if we would name it gitpython or git-python, things would get
> very confusing very quickly. In fact, this package was renamed precisely to
> avoid this confusion in [1]. This is not the only case where there are very
> similarly named packages on pypi. By having a 1 to 1 mapping between names in
> pypi and names in ::gentoo we avoid this confusion.

AFAIK, but I cannot find a source confirming this, PyPI project names
are case-insensitive, so it should be okay to map to all lowercase.

> Best regards,
> Andrew
>
> [1]
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0dec450a90c7490f11df7e69cd9c6709c099285c


-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] Defining TZ in the base system profile?

[Arsen Arsenović]

Michał Górny  writes:

> On Wed, 2023-01-18 at 20:48 -0500, Joshua Kinard wrote:
>> So this article[1] from 2017 popped up again on the tech radar via 
>> hackernews[2] and a few other sites[3].  It 
>> annotates how if the envvar TZ is undefined on a Linux system, it causes 
>> glibc to generate a number of 
>> additional syscalls, mainly stat-related calls (in my tests, newfstatat()).  
>> If defined to an actual value, 
>> such as ":/etc/localtime" (or even an empty string), glibc will instead 
>> generate far fewer, if any at all, of 
>> these stat-related syscalls.
>> 
>> [...]
>> So is adding a default definition of TZ to our base system /etc/profile 
>> something we want to look at?  I 
>> haven't tried any other methods of benchmarking to see if not making those 
>> additional syscalls is just placebo 
>> or if there are actual impacts.  Given how long this oddity has been around, 
>> I can't tell if it's a genuine 
>> bug in glibc, an unoptimized corner case, or just a big nothingburger.
>> 
>
> Am I correct that there's no real difference between setting it to
> ":/etc/localtime" and the actual timezone?
>
> I suppose it would make sense to default it.

Correct, from ``(libc)TZ Variable'':

   If the ‘TZ’ environment variable does not have a value, the operation
chooses a time zone by default.  In the GNU C Library, the default time
zone is like the specification ‘TZ=:/etc/localtime’ (or
‘TZ=:/usr/local/etc/localtime’, depending on how the GNU C Library was
configured; *note Installation::).  Other C libraries use their own rule
for choosing the default time zone, so there is little we can say about
them.

I don't suspect any downside to this approach.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] How to add -std=c++14 to CXXFLAGS of a cmake.eclass based package?

[Arsen Arsenović]

Hi,

Andrey Grozin  writes:

> Hello *,
>
> I'm trying to package a new version of sci-visualization/gle which now uses
> cmake. After some patching CMakeLists.txt, it configures successfully. But at
> build time it spits zillion errors
>
> error: ISO C++17 does not allow dynamic exception specifications
>
> The natural thing to try is to add -std=c++14 to CXXFLAGS. So I tried
>
> src_compile() {
> CXXFLAGS="${CXXFLAGS} -std=c++14" cmake_src_compile
> }
>
> but this makes no difference, c++17 is still used. How to convince
> cmake_src_compile to use -std=c++14?
>
> Thanks in advance,
> Andrey


audacity-2.4.2-r3.ebuild has something for this already:
``append-cxxflags -std=gnu++14''

Check out flag-o-matic.eclass.  Note that the build system could still
be overriding it, so if that fails, I'd check the compilation commands
for -std=... parameters, as well as CXX_STANDARD_LEVEL, or whatever
cmake calls it.

Hope that helps, have a great day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] Proposal to undeprecate EGO_SUM

[Arsen Arsenović]

Hey,

On Friday, 30 September 2022 02:36:05 CEST William Hubbs wrote:
> I don't know for certain about a vendor tarball, but I do know there
> are instances where a vendor tarball wouldn't work.
> app-containers/containerd is a good example of this, That is why the
> vendor tarball idea was dropped.
It is indeed not possible to verify vendor tarballs[1].  The proposed 
solution Go people had would also require network access.

> Upstream doesn't need to provide a tarball, just an up-to-date
> "vendor" directory at the top level of the project. Two examples that
> do this are docker and kubernetes.
Upstreams doing this sounds like a mess, because then they'd have to 
maintain multiple source trees in their repositories, if I understand 
what you mean.

An alternative to vendor tarballs is modcache tarballs. These are 
absolutely massive (~20 times larger IIRC), though, they are verifiable.

opinion: I see no way around it. Vendor tarballs are the way to go.  For 
trivial cases, this can likely be EGO_SUM, but it scales exceedingly 
poorly, to the point of the trivial case being a very small percentage 
of Go packages.  I proposed authenticated automation on Gentoo 
infrastructure as a solution to this, and implemented (a slow and 
unreliable) proof of concept (posted previously).  The obvious question 
of "how will proxy maintainers deal with this" is also relatively 
simple: giving them authorization for a subset of packages that they'd 
need to work on. This is an obvious increase in the barrier of entry for 
fresh proxy maintainers, but it's still likely less than needing 
maintainers to rework ebuilds to use vendor tarballs on dev.g.o.


[1]: https://github.com/golang/go/issues/27348
-- 
Arsen Arsenović


signature.asc
Description: This is a digitally signed message part.