Trying to merge app-accessibility/at-spi2-core-2.48.3, I got at-spi2-core-2.48.3/meson.build:1:0: ERROR: Meson version is 0.60.3 but project requires >= 0.63.0 Reproducible: Always Steps to Reproduce: Note: This is an old system, so don't get upset by any old versions here. :-) 1. emerge -1av app-accessibility/at-spi2-core app-accessibility/at-spi2-atk dev-libs/atk 2. [nomerge ] app-accessibility/at-spi2-core-2.48.3:2::XXX [2.40.3:2::gentoo] USE="X introspection -dbus-broker% -gtk-doc -systemd% -test" ABI_X86="(64) -32 (-x32)" [blocks b ] <app-accessibility/at-spi2-atk-2.46.0 ("<app-accessibility/at-spi2-atk-2.46.0" is soft blocking app-accessibility/at-spi2-core-2.48.3) [ebuild U ] app-accessibility/at-spi2-atk-2.46.0:2::XXX [2.38.0:2::gentoo] USE="(-test%)" ABI_X86="(64) -32 (-x32)" 0 KiB [blocks b ] <dev-libs/atk-2.46.0 ("<dev-libs/atk-2.46.0" is soft blocking app-accessibility/at-spi2-core-2.48.3) [ebuild U ] dev-libs/atk-2.46.0::XXX [2.36.0::gentoo] USE="introspection (-gtk-doc%)" ABI_X86="(64) -32 (-x32)" 0 KiB [ebuild U ] app-accessibility/at-spi2-core-2.48.3:2::XXX [2.40.3:2::gentoo] USE="X introspection -dbus-broker% -gtk-doc -systemd% -test" ABI_X86="(64) -32 (-x32)" 542 KiB Total: 3 packages (3 upgrades), Size of downloads: 542 KiB Conflict: 2 blocks (all satisfied) Actual Results: However, app-accessibility/at-spi2-core breaks with error in the configure phase: * Messages for package app-accessibility/at-spi2-core-2.48.3: * ERROR: app-accessibility/at-spi2-core-2.48.3::XXX failed (configure phase): * (no error message) * * Call stack: * ebuild.sh, line 127: Called src_configure * environment, line 2886: Called meson-multilib_src_configure * environment, line 1748: Called multilib-minimal_src_configure * environment, line 1957: Called multilib_foreach_abi 'multilib-minimal_abi_src_configure' * environment, line 2207: Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure' * environment, line 1912: Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure' * environment, line 1910: Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_configure' * environment, line 642: Called multilib-minimal_abi_src_configure * environment, line 1951: Called multilib_src_configure * environment, line 2424: Called meson_src_configure * environment, line 1850: Called die * The specific snippet of code: * "${mesonargs[@]}" ) || die * Expected Results: Smooth installation. On the other hand, since this is an old system, such "glitches" are expected. It has the "advantage" that we get to see dependencies that would otherwise remain undetected. ;-) The error in the log was at-spi2-core-2.48.3/meson.build:1:0: ERROR: Meson version is 0.60.3 but project requires >= 0.63.0 so actually, the at-spi2-core-2.48.3 ebuild is missing a build dependency on meson>=0.63.0. Solution ======= I went to https://gitweb.gentoo.org/repo/gentoo.git/plain/dev-util/meson/meson-0.63.3.ebuild?id=8a68597b30c130394040254e3562116b7e897ee7 https://gitweb.gentoo.org/repo/gentoo.git/plain/dev-util/meson/files/meson-0.63-xtools-support.patch?id=8a68597b30c130394040254e3562116b7e897ee7 and grabbed the meson-0.63.3.ebuild and also the files/meson-0.63-xtools-support.patch patch. The patch did not want be applied, by no means! Since it was not important (dealt with xtools, an Apple linker), I disabled it - who cares! (There is no "xtools" package and of those that have "xtools" in the name, none is installed...) Now this installed meson-0.63.0! - which paved the way for the installation of the atk packages above. :-) Which made installation of chrome possible! Which allowed me to FINALLY! use lighthouse! :-)
floppym et al, should we maybe just bump it up significantly in the eclass at this point again?
Couldn't you just upgrade meson to the latest that's available now though? Which is what a correct dep would have had you do too without the failure. As opposed to trying to upgrading to only meson-0.63 specifically
No objection to bumping the dependency to latest stable.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ba4ac01d12927b6d4ae155fc2f765e572ee76909 commit ba4ac01d12927b6d4ae155fc2f765e572ee76909 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2023-10-30 18:54:08 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2023-10-30 18:54:08 +0000 meson.eclass: depend on >=dev-util/meson-1.2.1 Bug: https://bugs.gentoo.org/916536 Signed-off-by: Mike Gilbert <floppym@gentoo.org> eclass/meson.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
I tried to upgrade to the latest meson 1.1.1, however that was not possible because during the "ebuild ... digest" command, I got ebuild meson-1.1.1.ebuild digest * ERROR: dev-util/meson-1.1.1::XXX failed (depend phase): * pypi.eclass could not be found by inherit() * * Call stack: * ebuild.sh, line 618: Called source '/usr/local/portage/overlays/XXX/dev-util/meson/meson-1.1.1.ebuild' * meson-1.1.1.ebuild, line 13: Called inherit 'pypi' * ebuild.sh, line 264: Called die * The specific snippet of code: * [[ -z ${location} ]] && die "${1}.eclass could not be found by inherit()" * Thus I would probably have to go to the eclasses repository and download pypi.eclass, however I was not that brave, as there was no way to know that pypi.eclass would work with the eclasses of a system that has gone ~20 months without update. I thus chose the path of minimum friction and downloaded meson-0.63.0 from the link I gave - which Just Works (TM). :-)
If you do it the way you have already done in that commit meson.eclass: depend on >=dev-util/meson-1.2.1 then you will be denying people like me the possibility of selectively upgrading the atk packages. There will be no way to know that actually meson-0.63.0 will also do, so people who have not upgraded THEIR WHOLE SYSTEM to the latest and greatest versions will be denied this possibility - because pypi.eclass will be necessary and there will be no way for the average user to know how "encapsulated" (read: decoupled from other eclasses) that eclass is. So the average user will think "oh, I need a new eclass here, so I probably must upgrade the whole system - forget it". That was my very first thought, actually. Such an upgrade takes no less than 2 full working months! I speak from painful experience and I have been a die-hard Gentoo user since mid-2000s. The system I run, is the same one I started back then - I have never used "start from scratch" again since then, not even in the transition 32->64 bit. Think about that. One might think "well, not a big deal, why selectively upgrade atk packages in an old system?" - but I already gave the answer to this: atk packages are needed for the newest binary of chrome browser, which is needed for lighthouse (which I installed directly through npm, as there is no package). Now tell me: why should an old system be denied the possibility of using lighthouse/chrome, just because the version of meson was set way too high? So setting >=dev-util/meson-1.2.1 where >=meson-0.63.0 would have sufficed is a really bad idea IMHO.
The plan was already to crank it to support some changes in the eclass to use some options for Python, not just for the sake of it here. We can't support every possible use case and I don't think it's particularly worth it to depend on an older version when it was planned anyway for what you've described. I think you're doing something wrong if upgrades take that long.
(In reply to Sam James from comment #7) > I think you're doing something wrong if upgrades take that long. Certainly I have to clean my world file. And certainly I cannot cope well with what I call "Python hell". :-) I would love to give it a try but I can't risk it - I'm in the middle of important work. That's why I also don't even dare to reboot: uptime -p up 1 year, 1 week, 4 days, 15 hours, 27 minutes ps fax | wc -l 1024 htop Tasks: 544, 1270 thr ... Hundreds of open files, distributed across 30 or so virtual desktops. Forget it. Thanks anyway.
It is *more* practical to support selective partial updates on Gentoo than on most other package managers. That is not the same as universally practical. It seems you do recognize that -- you're already at the stage of selectively backporting ebuilds you want to old versions of the ::gentoo tree. What, precisely, was your plan to handle things if at-spi2-core itself required an eclass that was "only" available since early 2023 and did not exist 20 months ago? What was your plan to handle things if at-spi2-core upstream decided to start internally using and requiring meson 1.2.1? If your current work is so complex and fragile that you don't even dare to *reboot* then I would not advise upgrading packages which a desktop environment internally uses -- do you use gnome? What happens if all gtk2 software including gnome stops working because your gtk version can't handle the new at-spi2-core version? Have you checked that they are compatible? Gentoo can try to ensure that all versions of packages still in the tree are compatible. Gentoo can offer infrastructure for bringing your own packages without undue fuss. Gentoo can try to support upgrading your entire system to a consistent state across great time periods. I think it's probably beyond Gentoo to support arbitrarily cherry-picking commits from gentoo.git and trying to use them as-is.
If you're already at the state of affairs where you're maintaining a repository tree that is based on ::gentoo but is not in fact ::gentoo, have you tried manually updating the meson ebuild to a new version yourself? Simply bumping the version and using the ebuild you inherited from the base ::gentoo repository of ~20 months ago should hopefully be enough. Meson's installation process hasn't really changed in a long time.
(In reply to Eli Schwartz from comment #9) > It is *more* practical to support selective partial updates on Gentoo than > on most other package managers. Agreed. Never said otherwise. > What, > precisely, was your plan to handle things if at-spi2-core itself required an > eclass that was "only" available since early 2023 and did not exist 20 > months ago? The plan in this case was to "forget it, wait until a full system upgrade is on its way" - that's probably ~6 months from now. The consequence would be that I would not be able to use lighthouse to test my web application, since it needs Chrome and current Chrome needs the updated atk packages - I can live with that. I *cannot* live with "stop work and take care of a system upgrade that runs the risk of taking up to 2 months to finish. Don't get me on this. See https://forums.gentoo.org/viewtopic-t-1146987.html https://forums.gentoo.org/viewtopic-t-1147180.html https://forums.gentoo.org/viewtopic-t-1146998.html for *some* of my struggles. Let's not discuss this further. > What was your plan to handle things if at-spi2-core upstream decided to > start internally using and requiring meson 1.2.1? > Same as above. > If your current work is so complex and fragile that you don't even dare to > *reboot* then I would not advise upgrading packages which a desktop > environment internally uses -- do you use gnome? No. I use fvwm2. Of course gtk2/3 applications are around. > What happens if all gtk2 > software including gnome stops working because your gtk version can't handle > the new at-spi2-core version? Have you checked that they are compatible? > I emerged all three atk-related packages on one step, the core package being only one of them: emerge -1av app-accessibility/at-spi2-core app-accessibility/at-spi2-atk dev-libs/atk No other piece of (GTK or not) software needed to be rebuilt. I guess this is safe, but no, I didn't check explicitly if the newer atk versions invalidate my somewhat older GTK applications - should I worry? > Gentoo can try to ensure that all versions of packages still in the tree are > compatible. Gentoo can offer infrastructure for bringing your own packages > without undue fuss. Gentoo can try to support upgrading your entire system > to a consistent state across great time periods. Agree to all. Never suggested otherwise. The crux is: time. You need time. Either you spend it in small chunks, or in big ones, depending on whether you upgrade frequently or infrequently. But you have to spend it anyway. And I don't have that time right now. Thanks to Gentoo's carefully programmed infrastructure (portage, eclasses, ebuilds), "selective upgrades" work incredibly well, even after 20 months. So well, in fact, that I don't feel real pressure to upgrade the whole system right now. It's like using a quality product well beyond its perceived end-of-life. It won't break, exactly because it's such a good quality. :-) > I think it's probably > beyond Gentoo to support arbitrarily cherry-picking commits from gentoo.git > and trying to use them as-is. All I said was if your problem is "this project needs at least meson-0.63.0", then add this condition to the ebuild, but don't be "overzealous" and add >=meson-1.2.1 without reason, because then you *unnecessarily* deny people like me the possibility of "cherry-pick" upgrades, as you call them. Now, Sam offered some explanation as to why the >=meson-1.2.1 condition *is* necessary. Even if he didn't go into details, I trust the reasons are valid, so I didn't pursue it further. There is a fine difference between what I said and what you make out of it ("support arbitrarily cherry-picking commits from gentoo.git"). "Support" is a commitment. "Try to not be overzealous with *minimum* version requirements" is not a commitment - it's rather a...guiding principle. :-)
(In reply to Eli Schwartz from comment #10) > If you're already at the state of affairs where you're maintaining a > repository tree that is based on ::gentoo but is not in fact ::gentoo, have > you tried manually updating the meson ebuild to a new version yourself? > Simply bumping the version and using the ebuild you inherited from the base > ::gentoo repository of ~20 months ago should hopefully be enough. Meson's > installation process hasn't really changed in a long time. No, I didn't try this. That would probably be the last resort... A reason I did not try it was that, trying the ::gentoo meson-1.1.1.ebuild, I got stuck in the digest phase: ebuild meson-1.1.1.ebuild digest * ERROR: dev-util/meson-1.1.1::XXX failed (depend phase): * pypi.eclass could not be found by inherit() * * Call stack: * ebuild.sh, line 618: Called source '/usr/local/portage/overlays/XXX/dev-util/meson/meson-1.1.1.ebuild' * meson-1.1.1.ebuild, line 13: Called inherit 'pypi' * ebuild.sh, line 264: Called die * The specific snippet of code: * [[ -z ${location} ]] && die "${1}.eclass could not be found by inherit()" * so I thought "if v.1.1.1 needs pypi to build, then I'm lost, I cannot handle this", because I know (from the old days) that pypi should be avoided, if we use portage. I got scared. :-) I have done this trick (old ebuild with newer version) on other occasions though and it worked very well. Another reason I didn't try is that I was able to find the 0.63.0 version in the links I gave, so I was content with that. :-)
(In reply to segmentation fault from comment #12) > so I thought "if v.1.1.1 needs pypi to build, then I'm lost, I cannot handle > this", because I know (from the old days) that pypi should be avoided, if we > use portage. I got scared. :-) > > I have done this trick (old ebuild with newer version) on other occasions > though and it worked very well. > > Another reason I didn't try is that I was able to find the 0.63.0 version in > the links I gave, so I was content with that. :-) The good news is that per https://devmanual.gentoo.org/eclass-reference/pypi.eclass/index.html The purpose of pypi.eclass is limited to defining $SRC_URI and $S for you (by calculating it in a similar manner to what used to require mirror://pypi/....). It was introduced to the meson ebuild in https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d1ab501c38a13aeea6d2b4a61e408b523b620d46 ``` - SRC_URI="mirror://pypi/${PN:0:1}/${PN}/${MY_P}.tar.gz" + inherit pypi ```
I decided to give it a try. I grabbed a copy of pypi.eclass: wget https://gitweb.gentoo.org/repo/gentoo.git/plain/eclass/pypi.eclass mv -iv pypi.eclass /usr/portage/eclass/ Then I downloaded a copy of dev-util/meson to my local overlay: wget -np -r -k -N -nc -l 0 https://gitweb.gentoo.org/repo/gentoo.git/plain/dev-util/meson/ and then moved the .ebuild files, as well as the contents of the "files" directory to their respective places in dev-util/meson/ of my own local repository. Next step was the "digest" phase: ebuild meson-1.1.1.ebuild digest * ERROR: dev-util/meson-1.1.1::XXX failed (depend phase): * Invalid implementation in PYTHON_COMPAT: python3_11 I "only" have python 2.7, 3.6, 3.7, 3.8, 3.9 and 3.10 - but PYTHON_COMPAT in the 1.1.1 ebuild says it can install only in 3.10, 3.11 and 3.12: PYTHON_COMPAT=( python3_{10..12} pypy3 ) Certainly, I can go and change it to PYTHON_COMPAT=( python3_{10} pypy3 ) to use the only version that is common. But I am a bit reluctant: doing so will install meson-1.1.1 on python 3.10 only, while now I have meson-0.63.0 installed on all my three python targets: 3.8, 3.9 and 3.10. Question: doesn't that put me in some disadvantage? What if I need to run meson with, say, python 3.8 in my old system? Or will such a situation not occur and it suffices to have *some* meson version in *some* python slot and all is guaranteed to be OK? Another question: should I change PYTHON_COMPAT to include my lower versions: PYTHON_COMPAT=( python3_{8..10} pypy3 ) You see, the problem is with the "semantics" of "COMPAT": does it mean "we guarantee meson-1.1.1 to be compatible with these versions, but may also be with older ones too", or does it mean "python 3.10 is the lowest version that will work with meson-1.1.1, all earlier versions of python are NOT compatible with it"?
(In reply to segmentation fault from comment #14) > Another question: should I change PYTHON_COMPAT to include my lower versions: > > PYTHON_COMPAT=( python3_{8..10} pypy3 ) To answer my own question: Yes! Looking at https://github.com/mesonbuild/meson, we see: Dependencies Python (version 3.7 or newer) Ninja (version 1.8.2 or newer) Latest Meson version supporting previous Python versions: Python 3.6: 0.61.5 Python 3.5: 0.56.2 Python 3.4: 0.45.1 so with v.1.1.1 I can even set PYTHON_COMPAT=( python3_{7..10} pypy3 ) since current version is 1.2.3 and it supports >=3.7. So I changed it in all ebuilds in my local repository and ran ebuild meson-1.1.1.ebuild digest egencache --update --repo='XXX' eix-update emerge -1av dev-util/meson which installed the latest stable meson-1.2.1-r1 into my python targets: PYTHON_TARGETS="python3_8 python3_9 python3_10 -pypy3" So now everyone is happy! :-) Thanks to Eli Schwartz for insisting to try this.
