Re: [gentoo-dev] The uncertain future of repository mirrors
Am Freitag, 21. März 2025, 14:32:31 Mitteleuropäische Normalzeit schrieb Michał Górny: > Hello, everyone. > > TL;DR: I'm thinking of shutting down all gentoo-mirror repositories, > except for gentoo and guru. > > > Over 10 years ago, I've started the repository mirror & CI project. > What started as a bunch of shell scripts on a user-donated server, has > organically grown into a bigger bunch of shell scripts managed by Infra. > Nevertheless, it's still a bunch of hacks glued together. > > Things don't work well all the time. Sometimes stuff randomly crashes, > and I have to SSH and remove local checkouts to make it work. Sometimes > the git repositories used to transfer logs grow so big they kill infra. > Often some repository starts crashing this or another part and needs to > be disabled. > > To be honest, I have no energy to keep maintaining this. I'm really > tired of having to deal with stuff crashing and spamming my mailbox with > failure mails. I'm tired of having to go through all the infra hoops > just to disable another repository that can't work for one reason or > another. In fact, I'm even tired that whenever people add new > repositories to api.gentoo.org, I have to go through that idiotic GitHub > clickety-click UI to stop receiving notifications for everything that > happens in these repositories. > > So what I'm thinking about is winding most of the project down. We'd > stop mirroring third-party repositories, and remove most of gentoo- > mirror organization. What I'd like to leave is mirroring of gentoo > and guru repositories, since these two we have control of, and are very > important to Gentoo users. > > So, well, unless someone convinces me otherwise, I'm going to disable > all other repositories over the next weekend, and remove their mirrors. > Gentoo and GURU will still be mirrored, and CI will keep running > as usual. First of all, thank you for running it in the first place! Maybe you like to also continuing mirroring semi-official dev repos like kde and qt. They are exclusively maintained by Gentoo devs, very large, and beneficial for users who want bleeding edge software. I would expect that these repos are not the main factor of the maintenance due to their high quality. And, if I'm right, this reduces sync times per user since the CI's metadata creation (I remember the days, when eix-sync needed extremely long). Currently, you completely provide the repo mirror infrastructure and also deal with all the problems. Is it possible to shift this in a large part to the overlay maintainer (in a opt-in approach)? E.g. something like this (I don't know if the Gentoo git directly provide a CI for users, but maybe Github can do this): - Per default a overlay is not mirrored, this is an "award" that must be earned. - Enable a CI controlled by each overlay dev (overlay devs must take care of the CI scripts, they get all the emails). - (Just) provide CI scripts that do the necessary overlay checking (if I'm not wrong, you already need these scripts for Gentoo and GURU). - Overlay devs are responsible to run these CI scripts in their overlay, fix errors etc. - Provide infrastructure that provides a mirror with metadata only for overlays that have enabled the CI, pass it, and the overlay dev asked for being mirrored. - Before mirroring a commit, wait for the overlay CI to pass to make sure to get no errors on your side. - If an overlay dev somehow changes the CI scripts in a way that it make the mirroring infrastructure to fail: Remove the overlay permanently. Best, Gerion signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: The uncertain future of repository mirrors
On 2025-03-21, Michał Górny wrote: > Hello, everyone. > > TL;DR: I'm thinking of shutting down all gentoo-mirror repositories, > except for gentoo and guru. > > > Over 10 years ago, I've started the repository mirror & CI project. > What started as a bunch of shell scripts on a user-donated server, has > organically grown into a bigger bunch of shell scripts managed by Infra. > Nevertheless, it's still a bunch of hacks glued together. > > Things don't work well all the time. Sometimes stuff randomly crashes, > and I have to SSH and remove local checkouts to make it work. Sometimes > the git repositories used to transfer logs grow so big they kill infra. > Often some repository starts crashing this or another part and needs to > be disabled. > > To be honest, I have no energy to keep maintaining this. I'm really > tired of having to deal with stuff crashing and spamming my mailbox with > failure mails. I'm tired of having to go through all the infra hoops > just to disable another repository that can't work for one reason or > another. In fact, I'm even tired that whenever people add new > repositories to api.gentoo.org, I have to go through that idiotic GitHub > clickety-click UI to stop receiving notifications for everything that > happens in these repositories. > > So what I'm thinking about is winding most of the project down. We'd > stop mirroring third-party repositories, and remove most of gentoo- > mirror organization. What I'd like to leave is mirroring of gentoo > and guru repositories, since these two we have control of, and are very > important to Gentoo users. > > So, well, unless someone convinces me otherwise, I'm going to disable > all other repositories over the next weekend, and remove their mirrors. > Gentoo and GURU will still be mirrored, and CI will keep running > as usual. I believe there's a good reason to also keep the "science" overlay mirrored, as otherwise it will be probably removed from Repology: https://github.com/repology/repology-updater/blob/94a135accee475d72ff32a1eb8982b8b307847c1/repos.d/gentoo/overlays.yaml#L90
[gentoo-dev] Last rites: dev-python/pip-run, dev-python/autocommand, dev-python/jaraco-env
# Michał Górny (2025-03-23) # dev-python/pip-run is a NIH package with significant number of NIH # deps. New versions require "coherent" build system that's designed # to be completely incompatible with downstream packaging. # No revdeps left. # # Includes a number of NIH dependencies, some of them abandoned. # # Removal on 2025-04-22. Bug #951933. dev-python/autocommand dev-python/jaraco-env dev-python/pip-run -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: dev-python/django-bootstrap5
On Tue, 18 Mar 2025 06:56:24 +0100 Michał Górny wrote: > > Bug fixed, and python team removed > > The tests still fail: > > FAILED (failures=3, errors=1) > Here they are not. Maybe I miss further dependency. Mind to share the log ? Alfredo
Re: [gentoo-dev] [PATCH] 1/1] autotools.eclass: add slibtool dir for aclocal
Eli Schwartz writes:
> On 3/14/25 11:31 AM, orbea wrote:
>> Changing it as you suggested I think would be significantly more
>> complicated and would require refactoring the eclass.
>
>
> Yes, it's unfortunately the type of thing that would be a somewhat
> involved change. :(
>
>
>> However I wonder if my patch still has merit since in the case of
>> slibtoolize it only needs to be set for aclocal and not all the other
>> tools that are executed during eautoreconf? Although including it
>> everywhere doesn't seem to cause any problems yet either.
>
>
> Not sure I understand what you mean. :) This is only used for aclocal
> either way.
>
> And your patch is I think fundamentally correct.
>
> The externally injected AT_SYS_M4DIR documented in the wiki is an
> understandable hack but nonetheless a *hack* and we should move away
> from it by treating slibtool the same as our generic aclocal handling.
>
> That's true even though I'd *also* like to see AT_SYS_M4DIR unbroken. It
> is nominally for "cases such as slibtool but where the user / system
> integrator has added it in ways ::gentoo cannot predict", but given
> slibtool is packaged in ::gentoo it is eminently reasonable to just
> include it directly in the list.
>
> ...
>
> Hmm, now that makes me think. Sam, maybe we can fix AT_SYS_M4DIR by
> making it not get passed as -I but instead get concatenated into
> ${T}/aclocal/dirlist
I agree, and I think it was an oversight to not do that when introducing
it...
Eli or orbea, do you want to send a patch for that (on top of this one)?
[gentoo-dev] [PATCH] cargo.eclass: Only tell Cargo to cross-compile when actually needed
This avoids the build host vs target flag separation issue. Sometimes it
is important for the build host to use the right flags. We cannot fix
this for cross-compiling now, but it should at least work for native
builds.
Closes: https://bugs.gentoo.org/951740
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index dae2b93f24f31..95d485ab20c34 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -448,7 +448,9 @@ _cargo_gen_git_config() {
# Return the directory within target that contains the build, e.g.
# target/aarch64-unknown-linux-gnu/release.
cargo_target_dir() {
- echo "${CARGO_TARGET_DIR:-target}/$(rust_abi)/$(usex debug debug
release)"
+ local abi
+ tc-is-cross-compiler && abi=/$(rust_abi)
+ echo "${CARGO_TARGET_DIR:-target}${abi}/$(usex debug debug release)"
}
# @FUNCTION: cargo_update_crates
@@ -762,6 +764,10 @@ cargo_env() {
# locally. Do this in a subshell so that they remain set
afterwards.
unset CARGO_BUILD_RUSTFLAGS CARGO_ENCODED_RUSTFLAGS RUSTFLAGS
+ # Only tell Cargo to cross-compile when actually needed to
avoid the
+ # aforementioned build host vs target flag separation issue.
+ tc-is-cross-compiler || unset CARGO_BUILD_TARGET
+
"${@}"
)
}
--
2.48.1
Re: [gentoo-dev] Last rites: dev-python/django-bootstrap5
On Sun, 23 Mar 2025 14:22:30 +0100 Michał Górny wrote: > On Sun, 2025-03-23 at 08:39 +0100, Alfredo Tupone wrote: > > On Tue, 18 Mar 2025 06:56:24 +0100 > > Michał Górny wrote: > > > > > > Bug fixed, and python team removed > > > > > > The tests still fail: > > > > > > FAILED (failures=3, errors=1) > > > > > Here they are not. Maybe I miss further dependency. > > Mind to share the log ? > > > > Attached. > Fixed, thanks Alfredo
