Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
Depend on >=mate-desktop-$(ver_cut 1-2) to avoid build failures for now
as a quick workaround.
The maintainers should check whether each package really needs it and
also consider a possible QA check in the eclass given some of them
seem to have a pattern in configure.ac for this, but given the bug has
been open for a whlie, I'd rather have some of the deps be unnecessarily
tight (not that it's even that tight) than as-it-was.
Note that couldn't use ${MATE_BRANCH} as it says:
> # Major and minor numbers of the version number, unless live.
> # If live ebuild, will be set to '9999'.
which made me wonder if it's actually meant to be 1-2 or 1-3 in ver_cut
or what.
Anyway, in summary:
* Apply a fix which makes things better, even if it's slightly overkill;
* Someone needs to audit these to find the actual minimum versions
(some truly do need this, some need just something older, although
unclear if upstream carefully update these or ont);
* A QA check may be wise.
Bug: https://bugs.gentoo.org/935279
Bug: https://bugs.gentoo.org/936079
Signed-off-by: Sam James <sam@gentoo.org>
ruby32 has been stable on all arches for some time now and people have
had time to update to ruby32. Remove ruby31 in preparation for its
masking in April 2025.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
Hans de Graaff
Repository mirror & CI
Miroslav Šulc
Sam James
Petr Vaněk
Viorel Munteanu
Patrick Lauer