Not sure how to interpret this, am I missing something here?

[sinatosk]

I filed a bug report for "media-libs/mesa-9999" at https://bugs.gentoo.org/956508 about a recent option removed but one may have accidentality been left in ebuild which is leading to failed build

Sam James mentioned

A bug in the live ebuild cannot be critical. Anyway, thanks.

I didn't know about the critical thing so I thought "ok, I won't do that in the future with live ebuilds"

Then Matt Turner ( comment 3, I'm interpreting this part is towards me )

> Reported: 2025-05-23 23:07 EDT by Jerome C

This is nearly 10 hours after my commit to gentoo.git.

I welcome anyone to report issues, but seriously, can you at least use an up-to-date gentoo.git if you're going to file bugs about live ebuilds?

My first thought was "I am using the latest gentoo.git"

So I checked again and it's on the latest ( just done some dev-python package updates )

Since day one ( after the stage 3 install of Gentoo ) I switched over to using git and only ever used "https://anongit.gentoo.org/git/repo/gentoo.git" git repository although I'm aware of "https://anongit.gentoo.org/git/repo/sync/gentoo.git" and "https://github.com/gentoo-mirror/gentoo.git"

Usually before cloning from https://anongit.gentoo.org/git/repo/gentoo.git I take a look at https://gitweb.gentoo.org/repo/gentoo.git/log/. I'm assuming they're both referring the same underlying git repo?

Looking git logs

https://gitweb.gentoo.org/repo/gentoo.g ... -libs/mesa
https://gitweb.gentoo.org/repo/sync/gen ... -libs/mesa
https://github.com/gentoo-mirror/gentoo ... -libs/mesa

The latest commit I can see ( at the time of writing this post ) is titled "media-libs/mesa: Remove IUSE=d3d9" commit id is e4bc3712bd9186c58f77de347f7625211607f056

Earlier in Matt's post ( comment 3 ) he mentions a commit which looks like it's titled "delete the XA frontend"

I started to wonder if it's DNS poisoning or cache issues so I did my turn VPN off, clear DNS cache and I swear it's all I was seeing

Not sure how to interpret this, am I missing something here?

================================

Was about to post this and did a refresh on the bug report and saw Matt just said

(In reply to Matt Turner from comment #3)
> (If someone knows how to tell what time the actual `git push`es happened,
> let me know)

Figured it out. It's a user preference in Gitlab. With that, I see:

> Marge Bot merged May 23, 2025, 1:40 PM

So I pushed the update to the live ebuild within 2 minutes.

thanks

[sam_]

I think Matt misunderstood. We sometimes get people being very impatient with live ebuilds (there's a history of some very rude people with mesa-9999 especially) and I think he jumped to conclusions.

[sinatosk]

Ok, I'll leave it at that then.

I use multiple live builds, I've done multiple reports ( mostly linux-firmware ) and so far, I've made one false report ( I misread the build log which was my fault of the build error ) and then this issue which I thought I was interpreting something wrong or missed something, the rest have been a breeze

I don't argue with impatient.

Thanks for the fix sam_

[Hu]

Now that sam_ has addressed the main issue, there are a few minor things I wanted to remark on here.

I filed a bug report for "media-libs/mesa-9999" at https://bugs.gentoo.org/956508 about a recent option removed but one may have accidentality been left in ebuild which is leading to failed build

As I read your bug report, you did not explicitly state the current HEAD commit of your gentoo.git. As I understand this case, that omission did not matter, since HEAD as of the time of your posting still contained the bad option, and sam_ pushed the fix later. However, in some cases, you might be able to head off responses like Matt's if you state the HEAD of gentoo.git, so that the developers can see how current (or stale) your tree is. At the least, it will help them quickly determine whether there exist published commits, not present in your local copy, that might be relevant to your problem report.

Usually before cloning from https://anongit.gentoo.org/git/repo/gentoo.git I take a look at https://gitweb.gentoo.org/repo/gentoo.git/log/. I'm assuming they're both referring the same underlying git repo?

I hope this is just a terminology issue, but your phrasing "Usually before cloning from" suggests to me that you are routinely performing git clone of that URL. Please don't do that, since a full (non-shallow) clone downloads all the history from the peer. Clone from it once, retain that clone locally, then use git fetch or git pull to retrieve updates relative to your last fetch. This is much more efficient for you and for the server.

Earlier in Matt's post ( comment 3 ) he mentions a commit which looks like it's titled "delete the XA frontend"

Based on the git log message of the bad commit to gentoo.git, "delete the XA frontend" is a commit in mesa.git. It is the commit where upstream removed XA functionality, and which led to Matt making a gentoo.git commit intended to stop using the now-removed XA functionality.

[sinatosk]

terminology issue on my part, yes, when I said "cloning" ( I was thinking technical details under the hood thing when I read Matt's response )

my command ( snippets ) is actually doing this

emaint sync --auto

eix-update

emerge --fetchonly --update --changed-{deps,slot,use} --with-bdeps=y @world

I later do the emerge without "fetchonly" option

I use git a lot and when reading ( some time ago ) what emerge is doing, I was just thinking "ok, bunch of git wrappers n stuff", i forgot about the "fetchonly" option until you mentioned this.

No, All of the git related stuff here on Gentoo is being managed by the tools provided

but mesa did say they "disabled" ( Phoronix did an article about it which is why I looked at mesa ) but later "removed" and the commit itself is titled "delete the XA frontend".

I was reading this commit from mesa git repo when I was at a restaurant waiting for some food and saw that they removed the "gallium-xa" option too, so I thought "mesa-9999" is going to fail, which later is why I filed the report ( after trying ) and said "accidentality" because... well... mistakes can happen.

The report was about an option still being declared when it's no longer there

I'm not quick too jump into conclusions, hence the "accidental" and later this thread.