| Summary: | dev-lang/spidermonkey-102.1.0: ERROR: Rust compiler 1.58.1 is too old. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Roman Gruber <roman.gruber> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Roman Gruber
2022-08-18 19:31:23 UTC
Please attach the full build.log and emerge --info. Please update your system. We don't have rust-1.58 in tree anymore. (In reply to Joonas Niilola from comment #2) > Please update your system. We don't have rust-1.58 in tree anymore. Upgrading an older system will fail because there's no obligation for newer Rust to be emerged before SpiderMonkey. The dep in SpiderMonkey must be fixed. (In reply to Sam James from comment #3) > (In reply to Joonas Niilola from comment #2) > > Please update your system. We don't have rust-1.58 in tree anymore. > > Upgrading an older system will fail because there's no obligation for newer > Rust to be emerged before SpiderMonkey. The dep in SpiderMonkey must be > fixed. (it already has >=rust-1.51.0, it just needs to be bumped to 1.59.0). (In reply to Sam James from comment #3) > > Upgrading an older system will fail because there's no obligation for newer > Rust to be emerged before SpiderMonkey. The dep in SpiderMonkey must be > fixed. But --with-bdeps=y is the default now right? (In reply to Sam James from comment #4) > > (it already has >=rust-1.51.0, it just needs to be bumped to 1.59.0). It should've been plain virtual/rust and no version restrictions since the current tree state satisfies the dep. (In reply to Joonas Niilola from comment #5) > (In reply to Sam James from comment #3) > > > > Upgrading an older system will fail because there's no obligation for newer > > Rust to be emerged before SpiderMonkey. The dep in SpiderMonkey must be > > fixed. > > But --with-bdeps=y is the default now right? > That doesn't make any difference. > > (In reply to Sam James from comment #4) > > > > (it already has >=rust-1.51.0, it just needs to be bumped to 1.59.0). > > It should've been plain virtual/rust and no version restrictions since the > current tree state satisfies the dep. That's not how dep restrictions work. That would mean that you expect everyone to be fully up to date by the time any old deps are removed. We tend to keep dep bounds for ~2 years. Portage does not aggressively update everything in *DEPEND before merging a package (hence merge order might not be what you expect). (In reply to Sam James from comment #6) > > That doesn't make any difference. > It should when you update your system normally, "-uavDU world". But indeed I thought spidermonkey:102 will be pulled by an update, but currently no package depends on it. So I can see how "emerge --sync ; emerge spidermonkey" can happen for developers with gentoo installed. (In reply to Joonas Niilola from comment #7) > (In reply to Sam James from comment #6) > > > > That doesn't make any difference. > > > > It should when you update your system normally, "-uavDU world". > It's not about "will Rust get updated", it's about "will Rust be scheduled for an update *before* SpiderMonkey", that's why --with-bdeps isn't relevant here. A simpler hypothetical example: - A new libxslt (1.1.36) needs a newish version of libxml2 (1.1.35). - There is no version <1.1.35 in tree for about 3 months now if I remember right. - Portage is free, on a world upgrade (say, for a system which went 4 months without updates system), to upgrade libxslt *then* libxml2, which will result in a build failure for libxslt if I don't make the dependency in libxslt correct. (In reply to Sam James from comment #8) > > It's not about "will Rust get updated", it's about "will Rust be scheduled > for an update *before* SpiderMonkey", that's why --with-bdeps isn't relevant > here. > > A simpler hypothetical example: > - A new libxslt (1.1.36) needs a newish version of libxml2 (1.1.35). > - There is no version <1.1.35 in tree for about 3 months now if I remember > right. > - Portage is free, on a world upgrade (say, for a system which went 4 months > without updates system), to upgrade libxslt *then* libxml2, which will > result in a build failure for libxslt if I don't make the dependency in > libxslt correct. Yes, that makes sense. In my eyes though rust-1.58 was dropped in May (~3 months ago) so I expected everyone to have updated systems. Anyway I can understand how it may not happen. Gonna fix this and #865665 and do other minor from-firefox-esr ebuild updates tomorrow. Sounds good! Frustratingly, some things like this are often kind of catastrophic if someone has a pending Python upgrade due, as things can be upgraded in an order such that e.g. emerge doesn't work anymore if a build fails in between say, python-exec & portage. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bd1391f06d632e35af2050caf7de942a9cf61748 commit bd1391f06d632e35af2050caf7de942a9cf61748 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-08-19 08:08:56 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-08-19 08:15:47 +0000 dev-lang/spidermonkey: 102 fixes - bump minimum required rust version, - install ProfilingCategoryList.h, - minor updates (CHECKREQS, mach exports...). Bug: https://bugs.gentoo.org/865665 Closes: https://bugs.gentoo.org/865713 Signed-off-by: Joonas Niilola <juippis@gentoo.org> dev-lang/spidermonkey/Manifest | 1 + .../spidermonkey/spidermonkey-102.1.0-r1.ebuild | 404 +++++++++++++++++++++ 2 files changed, 405 insertions(+) |
