[gentoo-dev] Last rites: dev-ruby/textpow and dev-ruby/ultraviolet
# Hans de Graaff (2022-12-03) # ruby27-only packages with no other reverse dependencies. # Last releases in 2013 and 2015. Removal in 30 days. dev-ruby/textpow dev-ruby/ultraviolet signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 2/3 v2] tree-sitter-grammar.eclass: Add src_test implementation
These packages have a standard way of implementing a test corpus that can be invoked by "tree-sitter test" from dev-util/tree-sitter-cli. Some have additional platform-specific tests that are invoked in a custom manner, but these are on top of the basic test corpus. See: https://tree-sitter.github.io/tree-sitter/creating-parsers#command-test Bug: https://bugs.gentoo.org/844223 Closes: https://github.com/gentoo/gentoo/pull/28529 Signed-off-by: Matoro Mahri --- eclass/tree-sitter-grammar.eclass | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/eclass/tree-sitter-grammar.eclass b/eclass/tree-sitter-grammar.eclass index acdb8a7ad73..c607ea9ddfb 100644 --- a/eclass/tree-sitter-grammar.eclass +++ b/eclass/tree-sitter-grammar.eclass @@ -29,7 +29,11 @@ S="${WORKDIR}"/${PN}-${TS_PV:-${PV}}/src # Needed for tree_sitter/parser.h DEPEND="dev-libs/tree-sitter" -EXPORT_FUNCTIONS src_compile src_install +BDEPEND+=" test? ( dev-util/tree-sitter-cli )" +IUSE+=" test" +RESTRICT+=" !test? ( test )" + +EXPORT_FUNCTIONS src_compile src_test src_install # @ECLASS_VARIABLE: TS_PV # @PRE_INHERIT @@ -89,6 +93,16 @@ tree-sitter-grammar_src_compile() { -o "${WORKDIR}"/${soname} } +# @FUNCTION: tree-sitter-grammar_src_test +# @DESCRIPTION: +# Runs the Tree Sitter parser's test suite. +# See: https://tree-sitter.github.io/tree-sitter/creating-parsers#command-test +tree-sitter-grammar_src_test() { + debug-print-function ${FUNCNAME} "${@}" + + (cd .. && tree-sitter test) || die "Test suite failed" +} + # @FUNCTION: tree-sitter-grammar_src_install # @DESCRIPTION: # Installs the Tree Sitter parser library. -- 2.38.1
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On Sat, Dec 3, 2022 at 2:09 AM Michał Górny wrote: > > Hi, > > I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug > states with a simple NEW state. Why? > > 1. Only a handful of developers actually uses these two statuses > in a meaningful way. > > 2. Some users are confused and demotivated by having their bugs stay > UNCONFIRMED for a long time. I think I could be counted among the devs who at least try to use the two statuses. If I stumble upon bugs that I have run into myself, I will flip them from UNCONFIRMED to CONFIRMED. On the opposite end, I occasionally downgrade bugs from CONFIRMED to UNCONFIRMED if they are particularly strange looking and were filed by a script (tinderbox). Anyway, if you decide to make the change, please ensure that it doesn't generate a bunch of pointless bugmail. I have noticed that some devs will replace obsolete values in Product/Component without making any other meaningful changes to the bug. Let's avoid that situation if possible here.
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
Hi all, I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug states with a simple NEW state. Why? 1. Only a handful of developers actually uses these two statuses in a meaningful way. 2. Some users are confused and demotivated by having their bugs stay UNCONFIRMED for a long time. As someone who is very active on bugzilla I think the users are happy about - real activity and - polite, precise and clear answers Renaming tags will rather confuse. Yes, some tickets are open for long times (this is not a Gentoo-only problem) We should not hide this with Newspeak. I suggest to keep it as it is, because sometimes it makes sense to confirm a bug. Are not demotivated, because of the name of the tag. They are demotivated, if - bugs remain open/unanswered for long time - they are told "my dev time is too expensive for your problems" in an impolite way -- Best, Jonas
[gentoo-dev] [PATCH 3/3] dev-libs/tree-sitter-cpp: restrict tests
Requires sample files from tree-sitter-c to be available, but these files are not installed with dev-libs/tree-sitter-c, and are instead expected to be pulled down via making the tree-sitter-c javascript wrapper package a dependency in package.json. However since we invoke "tree-sitter test" directly rather than via "npm test" the source package for tree-sitter-c will not be available. Bug: https://bugs.gentoo.org/844223 See: https://github.com/gentoo/gentoo/pull/28529 Signed-off-by: Matoro Mahri --- dev-libs/tree-sitter-cpp/tree-sitter-cpp-0.20.0.ebuild | 3 +++ 1 file changed, 3 insertions(+) diff --git a/dev-libs/tree-sitter-cpp/tree-sitter-cpp-0.20.0.ebuild b/dev-libs/tree-sitter-cpp/tree-sitter-cpp-0.20.0.ebuild index dd304585137..654df3497df 100644 --- a/dev-libs/tree-sitter-cpp/tree-sitter-cpp-0.20.0.ebuild +++ b/dev-libs/tree-sitter-cpp/tree-sitter-cpp-0.20.0.ebuild @@ -11,3 +11,6 @@ HOMEPAGE="https://github.com/tree-sitter/tree-sitter-cpp; LICENSE="MIT" SLOT="0" KEYWORDS="amd64" + +# requires test data from tree-sitter-c +RESTRICT="test" -- 2.38.1
[gentoo-dev] [PATCH 2/3] tree-sitter-grammar.eclass: Add src_test implementation
These packages have a standard way of implementing a test corpus that can be invoked by "tree-sitter test" from dev-util/tree-sitter-cli. Some have additional platform-specific tests that are invoked in a custom manner, but these are on top of the basic test corpus. See: https://tree-sitter.github.io/tree-sitter/creating-parsers#command-test Bug: https://bugs.gentoo.org/844223 Closes: https://github.com/gentoo/gentoo/pull/28529 Signed-off-by: Matoro Mahri --- eclass/tree-sitter-grammar.eclass | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/eclass/tree-sitter-grammar.eclass b/eclass/tree-sitter-grammar.eclass index acdb8a7ad73..958b2ce21c7 100644 --- a/eclass/tree-sitter-grammar.eclass +++ b/eclass/tree-sitter-grammar.eclass @@ -29,7 +29,10 @@ S="${WORKDIR}"/${PN}-${TS_PV:-${PV}}/src # Needed for tree_sitter/parser.h DEPEND="dev-libs/tree-sitter" -EXPORT_FUNCTIONS src_compile src_install +BDEPEND+=" test? ( dev-util/tree-sitter-cli )" +IUSE+=" test" + +EXPORT_FUNCTIONS src_compile src_test src_install # @ECLASS_VARIABLE: TS_PV # @PRE_INHERIT @@ -89,6 +92,16 @@ tree-sitter-grammar_src_compile() { -o "${WORKDIR}"/${soname} } +# @FUNCTION: tree-sitter-grammar_src_test +# @DESCRIPTION: +# Runs the Tree Sitter parser's test suite. +# See: https://tree-sitter.github.io/tree-sitter/creating-parsers#command-test +tree-sitter-grammar_src_test() { + debug-print-function ${FUNCNAME} "${@}" + + (cd .. && tree-sitter test) || die "Test suite failed" +} + # @FUNCTION: tree-sitter-grammar_src_install # @DESCRIPTION: # Installs the Tree Sitter parser library. -- 2.38.1
[gentoo-dev] [PATCH 1/3] profiles/features/wd40: mask USE=test tree-sitter-grammar.eclass pkgs
dev-util/tree-sitter-cli will now be a conditional test dep for packages inheriting tree-sitter-grammar.eclass, which is written in rust, so mask it on rustless profiles. Bug: https://bugs.gentoo.org/844223 See: https://github.com/gentoo/gentoo/pull/28529 Signed-off-by: Matoro Mahri --- profiles/features/wd40/package.use.mask | 26 + 1 file changed, 26 insertions(+) diff --git a/profiles/features/wd40/package.use.mask b/profiles/features/wd40/package.use.mask index 4dd5915ab85..c86a7036962 100644 --- a/profiles/features/wd40/package.use.mask +++ b/profiles/features/wd40/package.use.mask @@ -1,6 +1,32 @@ # Copyright 1999-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 +# matoro (2022-12-01) +# tree-sitter-grammar.eclass adds dev-util/tree-sitter-cli as test dep +dev-libs/tree-sitter-bash test +dev-libs/tree-sitter-c test +dev-libs/tree-sitter-c-sharp test +dev-libs/tree-sitter-cpp test +dev-libs/tree-sitter-css test +dev-libs/tree-sitter-embedded-template test +dev-libs/tree-sitter-go test +dev-libs/tree-sitter-haskell test +dev-libs/tree-sitter-html test +dev-libs/tree-sitter-java test +dev-libs/tree-sitter-javascript test +dev-libs/tree-sitter-jsdoc test +dev-libs/tree-sitter-json test +dev-libs/tree-sitter-julia test +dev-libs/tree-sitter-ocaml test +dev-libs/tree-sitter-php test +dev-libs/tree-sitter-python test +dev-libs/tree-sitter-ql test +dev-libs/tree-sitter-ruby test +dev-libs/tree-sitter-rust test +dev-libs/tree-sitter-scala test +dev-libs/tree-sitter-tsq test +dev-libs/tree-sitter-typescript test + # Sam James (2022-11-19) # GNOME packages pulling in e.g. gjs which then needs Rust. dev-util/glade gjs -- 2.38.1
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On 12/3/22 08:59, Florian Schmaus wrote: On 03/12/2022 14.50, Michał Górny wrote: On Sat, 2022-12-03 at 14:45 +0100, Florian Schmaus wrote: I think having UNCONFIRMED / CONFIRMED *helps* the issue reporter, and other (affected) persons, to decide if they need to "chase" the issue's assigned entity. Assume looking at the open bugs list of a developer. If the developer has old bugs in UNCONFIRMED state, you may want to issue a friendly ping. Sure, strictly speaking, this would require all bugs to drop back to UNCONFIMRED when the bug assignee changes. But even without such an implicit mechanism, those two states provide some value. I don't understand how UNCONFIRMED/CONFIRMED makes any difference here. If I file a bug against some package, it is CONFIRMED by default. If an unprivileged user files it, it's UNCONFIRMED. In both cases the assignee didn't do anything. The assignee not doing anything keeps the bug UNCONFIRMED if it is filled by an unprivileged user. That makes the bug distinguishable from a bug that got "verified" by the assignee. Yes, if *you* (as dev) fill a bug, then it is implicitly CONFIRMED (whether or not that is sensible is a different discussion). I do not see how this would invalidate my case, though. - Flow The kernel may be a special case, but personally I use unconfirmed and don't 'confirm' it until it's determined if it's a real kernel bug. Sometimes the kernel is the messenger and not the cause. But this is not a documented process and only exists in my head. Whatever the consensus is I can live with. -- Mike Pagano Gentoo Developer - Kernel Project Gentoo Sources - Lead E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On 03/12/2022 14.50, Michał Górny wrote: On Sat, 2022-12-03 at 14:45 +0100, Florian Schmaus wrote: I think having UNCONFIRMED / CONFIRMED *helps* the issue reporter, and other (affected) persons, to decide if they need to "chase" the issue's assigned entity. Assume looking at the open bugs list of a developer. If the developer has old bugs in UNCONFIRMED state, you may want to issue a friendly ping. Sure, strictly speaking, this would require all bugs to drop back to UNCONFIMRED when the bug assignee changes. But even without such an implicit mechanism, those two states provide some value. I don't understand how UNCONFIRMED/CONFIRMED makes any difference here. If I file a bug against some package, it is CONFIRMED by default. If an unprivileged user files it, it's UNCONFIRMED. In both cases the assignee didn't do anything. The assignee not doing anything keeps the bug UNCONFIRMED if it is filled by an unprivileged user. That makes the bug distinguishable from a bug that got "verified" by the assignee. Yes, if *you* (as dev) fill a bug, then it is implicitly CONFIRMED (whether or not that is sensible is a different discussion). I do not see how this would invalidate my case, though. - Flow
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On Sat, 2022-12-03 at 14:45 +0100, Florian Schmaus wrote: > I think having UNCONFIRMED / CONFIRMED *helps* the issue reporter, and > other (affected) persons, to decide if they need to "chase" the issue's > assigned entity. > > Assume looking at the open bugs list of a developer. If the developer > has old bugs in UNCONFIRMED state, you may want to issue a friendly > ping. Sure, strictly speaking, this would require all bugs to drop back > to UNCONFIMRED when the bug assignee changes. But even without such an > implicit mechanism, those two states provide some value. I don't understand how UNCONFIRMED/CONFIRMED makes any difference here. If I file a bug against some package, it is CONFIRMED by default. If an unprivileged user files it, it's UNCONFIRMED. In both cases the assignee didn't do anything. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On 03/12/2022 13.20, Michał Górny wrote: On Sat, 2022-12-03 at 13:10 +0100, Florian Schmaus wrote: On 03/12/2022 12.34, Michał Górny wrote: On Sat, 2022-12-03 at 11:42 +0100, Florian Schmaus wrote: On 03/12/2022 08.09, Michał Górny wrote: Hi, I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug states with a simple NEW state. Why? 1. Only a handful of developers actually uses these two statuses in a meaningful way. 2. Some users are confused and demotivated by having their bugs stay UNCONFIRMED for a long time. While I do not strictly oppose that change, I like the UNCONFIRMED / CONFIRMED states. I don't know how 1. is an argument for removing it. Quite the contrary, the statement itself says that the feature is used. Furthermore, it is not my observation that only a handful of developers use it. Most open bugs are in the CONF state [1], so I would conclude that most use the feature. Of course, that depends on your definition of "used in a meaningful way". For me, CONFIRMED was always about someone, usually a -dev, acknowledging that the bug reports a valid issue that needs to be addressed (either by Gentoo or upstream). Is that using it in a meaningful way? Does that imply that bugs that are UNCONFIRMED are not worth our effort? No, not all. Could you elaborate how you derive this implication? I had always assumed that UNCONFIRMED means that nobody (as in, no dev) looked at the issue report and vetted its validity. Nothing more, nothing less. I'm trying to understand what actual value this has. Unless it's data for the sake of having data. That is a valid concern. I think having UNCONFIRMED / CONFIRMED *helps* the issue reporter, and other (affected) persons, to decide if they need to "chase" the issue's assigned entity. Assume looking at the open bugs list of a developer. If the developer has old bugs in UNCONFIRMED state, you may want to issue a friendly ping. Sure, strictly speaking, this would require all bugs to drop back to UNCONFIMRED when the bug assignee changes. But even without such an implicit mechanism, those two states provide some value. A similar case can be made for IN_PROGRESS. However, I see how one could argue that IN_PROGRESS provides more value than UNCONFIRMED / CONFIRMED. As I said, I do not strictly oppose this change. But since this is a RFC, I commented. :) Maybe it is just me being used to bug transition states being NEW / UNCONFIRMED → CONFIRMED → IN_PROGRESS → CLOSED (with intermediate states being optional) - Flow
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On Sat, 2022-12-03 at 13:10 +0100, Florian Schmaus wrote: > On 03/12/2022 12.34, Michał Górny wrote: > > On Sat, 2022-12-03 at 11:42 +0100, Florian Schmaus wrote: > > > On 03/12/2022 08.09, Michał Górny wrote: > > > > Hi, > > > > > > > > I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug > > > > states with a simple NEW state. Why? > > > > > > > > 1. Only a handful of developers actually uses these two statuses > > > > in a meaningful way. > > > > > > > > 2. Some users are confused and demotivated by having their bugs stay > > > > UNCONFIRMED for a long time. > > > > > > While I do not strictly oppose that change, I like the UNCONFIRMED / > > > CONFIRMED states. > > > > > > I don't know how 1. is an argument for removing it. Quite the contrary, > > > the statement itself says that the feature is used. Furthermore, it is > > > not my observation that only a handful of developers use it. Most open > > > bugs are in the CONF state [1], so I would conclude that most use the > > > feature. Of course, that depends on your definition of "used in a > > > meaningful way". For me, CONFIRMED was always about someone, usually a > > > -dev, acknowledging that the bug reports a valid issue that needs to be > > > addressed (either by Gentoo or upstream). Is that using it in a > > > meaningful way? > > > > Does that imply that bugs that are UNCONFIRMED are not worth our effort? > > No, not all. Could you elaborate how you derive this implication? > > I had always assumed that UNCONFIRMED means that nobody (as in, no dev) > looked at the issue report and vetted its validity. Nothing more, > nothing less. > I'm trying to understand what actual value this has. Unless it's data for the sake of having data. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
> On Sat, 03 Dec 2022, Ulrich Mueller wrote: > Some people found that not satisfactory, so NEW and ASSIGNED were > replaced by CONFIRMED and IN_PROGRESS. (We also had status REOPENED > which was removed with the same change.) Unfortunately, I cannot find > the old discussion, but [1] suggests that the change took place in 2011 > or before. In 2011, actually. Discussion is here: https://archives.gentoo.org/gentoo-dev/message/a22baae8830ca806684da98ce7698206 "Right now, it seems logical to use UNCONFIRMED for the new bugs and let devs (re-)confirm them as necessary. I think it might be even a good idea to limit the possibility of setting 'CONFIRMED' to devs. Otherwise, I see users bumping each of their bugs to 'CONFIRMED' immediately." https://archives.gentoo.org/gentoo-dev/message/33e6f39fbfafe95c18c563b12c61d9f0 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On 03/12/2022 12.34, Michał Górny wrote: On Sat, 2022-12-03 at 11:42 +0100, Florian Schmaus wrote: On 03/12/2022 08.09, Michał Górny wrote: Hi, I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug states with a simple NEW state. Why? 1. Only a handful of developers actually uses these two statuses in a meaningful way. 2. Some users are confused and demotivated by having their bugs stay UNCONFIRMED for a long time. While I do not strictly oppose that change, I like the UNCONFIRMED / CONFIRMED states. I don't know how 1. is an argument for removing it. Quite the contrary, the statement itself says that the feature is used. Furthermore, it is not my observation that only a handful of developers use it. Most open bugs are in the CONF state [1], so I would conclude that most use the feature. Of course, that depends on your definition of "used in a meaningful way". For me, CONFIRMED was always about someone, usually a -dev, acknowledging that the bug reports a valid issue that needs to be addressed (either by Gentoo or upstream). Is that using it in a meaningful way? Does that imply that bugs that are UNCONFIRMED are not worth our effort? No, not all. Could you elaborate how you derive this implication? I had always assumed that UNCONFIRMED means that nobody (as in, no dev) looked at the issue report and vetted its validity. Nothing more, nothing less. - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
> On Sat, 03 Dec 2022, Michał Górny wrote: >> > I'd like to propose replacing the current UNCONFIRMED and CONFIRMED >> > bug states with a simple NEW state. Why? >> >> > 1. Only a handful of developers actually uses these two statuses >> > in a meaningful way. >> >> > 2. Some users are confused and demotivated by having their bugs stay >> > UNCONFIRMED for a long time. >> >> Then rename UNCONFIRMED to NEW-WITH-SUGAR-ON-TOP-WE-ARE-A-HAPPY- >> COMMUNITY, > Done. Seriously, we had UNCONFIRMED, NEW, and ASSIGNED before. The default status used to be NEW, but with "expert" reporting users could explicitly assign the status to UNCONFIRMED. Some people found that not satisfactory, so NEW and ASSIGNED were replaced by CONFIRMED and IN_PROGRESS. (We also had status REOPENED which was removed with the same change.) Unfortunately, I cannot find the old discussion, but [1] suggests that the change took place in 2011 or before. The Bugzilla Guide [2] still has the old wording: | • UNCONFIRMED - You're generally not going to see this too often. | This means that a bug reporter has opened a bug using the advanced | method and is uncertain their bug is an actual bug. | • NEW - Bugs that are first opened are considered new. Tracing the history of that text, it was the same in 2005 [3], and seems to originate from [4]. A previous discussion about this topic (started by you :) can be found in [5], BTW. Ulrich [1] https://bugs.gentoo.org/391203#c1 [2] https://wiki.gentoo.org/wiki/Bugzilla/Guide#Working_with_a_bug [3] https://gitweb.gentoo.org/archive/proj/gentoo.git/commit/xml/htdocs/doc/en/bugzilla-howto.xml?id=6947795f3817a6779a81d768e9a5a07380d56aa4 [4] https://bugs.gentoo.org/97274 [5] https://archives.gentoo.org/gentoo-dev/message/b24ea134d3555cd25560090cf4a87657 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On Sat, 2022-12-03 at 11:42 +0100, Florian Schmaus wrote: > On 03/12/2022 08.09, Michał Górny wrote: > > Hi, > > > > I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug > > states with a simple NEW state. Why? > > > > 1. Only a handful of developers actually uses these two statuses > > in a meaningful way. > > > > 2. Some users are confused and demotivated by having their bugs stay > > UNCONFIRMED for a long time. > > While I do not strictly oppose that change, I like the UNCONFIRMED / > CONFIRMED states. > > I don't know how 1. is an argument for removing it. Quite the contrary, > the statement itself says that the feature is used. Furthermore, it is > not my observation that only a handful of developers use it. Most open > bugs are in the CONF state [1], so I would conclude that most use the > feature. Of course, that depends on your definition of "used in a > meaningful way". For me, CONFIRMED was always about someone, usually a > -dev, acknowledging that the bug reports a valid issue that needs to be > addressed (either by Gentoo or upstream). Is that using it in a > meaningful way? Does that imply that bugs that are UNCONFIRMED are not worth our effort? -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On 03/12/2022 08.09, Michał Górny wrote: Hi, I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug states with a simple NEW state. Why? 1. Only a handful of developers actually uses these two statuses in a meaningful way. 2. Some users are confused and demotivated by having their bugs stay UNCONFIRMED for a long time. While I do not strictly oppose that change, I like the UNCONFIRMED / CONFIRMED states. I don't know how 1. is an argument for removing it. Quite the contrary, the statement itself says that the feature is used. Furthermore, it is not my observation that only a handful of developers use it. Most open bugs are in the CONF state [1], so I would conclude that most use the feature. Of course, that depends on your definition of "used in a meaningful way". For me, CONFIRMED was always about someone, usually a -dev, acknowledging that the bug reports a valid issue that needs to be addressed (either by Gentoo or upstream). Is that using it in a meaningful way? And 2. doesn't appear to be a solution but helps disguise the underlying issue. We should instead educate users that Gentoo, like most volunteer-driven FOSS projects, is short on the workforce. Therefore users can only expect that some bugs will be handled immediately, while others may lay dormant for an extended period (for different reasons). Ultimately, the central angle to tackle this issue is e to empower users to fix the problems themselves or at least provide minimal reproducers and debugging information. We already put in much effort (and we are IMHO quite good at it already), but it requires continuous effort… - Flow 1: https://bugs.gentoo.org/buglist.cgi?component=Current%20packages_id=6623145=Gentoo%20Linux=--- OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last-rites: dev-util/boost-build
# Andreas Sturmlechner (2022-12-03) # No purpose anymore after signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On 12/3/22 10:53, Michał Górny wrote: On Sat, 2022-12-03 at 09:39 +0100, Ulrich Mueller wrote: Then rename UNCONFIRMED to NEW-WITH-SUGAR-ON-TOP-WE-ARE-A-HAPPY- COMMUNITY, Done. I do search for bugs using pybugz and gre3p for CONFIRMED and do wonder if/when I shall grep for NEW too ? -- Toralf PGP 23217DA7 9B888F45 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On Sat, 2022-12-03 at 09:39 +0100, Ulrich Mueller wrote: > > > > > > On Sat, 03 Dec 2022, Michał Górny wrote: > > > I'd like to propose replacing the current UNCONFIRMED and CONFIRMED > > bug states with a simple NEW state. Why? > > > 1. Only a handful of developers actually uses these two statuses > > in a meaningful way. > > > 2. Some users are confused and demotivated by having their bugs stay > > UNCONFIRMED for a long time. > > Then rename UNCONFIRMED to NEW-WITH-SUGAR-ON-TOP-WE-ARE-A-HAPPY- > COMMUNITY, Done. -- Best regards, Michał Górny
Re: [gentoo-dev] Last rites: x11-themes/mate-themes-meta
> On Sat, 03 Dec 2022, Sam James wrote: > # Oz Tiram (2022-12-03) > # Mate-desktop no longer supports gtk+:2, so there is > # no need for this package. Removal on 2023-01-03. > x11-themes/mate-themes-meta Is x11-themes/mate-themes obsolete then? mate-base/mate[themes] no longer depends on it after removal of this intermediate metapackage. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
> On Sat, 03 Dec 2022, Michał Górny wrote: > I'd like to propose replacing the current UNCONFIRMED and CONFIRMED > bug states with a simple NEW state. Why? > 1. Only a handful of developers actually uses these two statuses > in a meaningful way. > 2. Some users are confused and demotivated by having their bugs stay > UNCONFIRMED for a long time. Then rename UNCONFIRMED to NEW-WITH-SUGAR-ON-TOP-WE-ARE-A-HAPPY-COMMUNITY, and leave CONFIRMED alone? :) However, I suspect that the real problem isn't the status label, but when there's no action on the bug (sometimes for months or years). Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] app-alternatives.eclass: New eclass to streamline app-alternatives/*
On Sat, 2022-12-03 at 09:19 +0100, Ulrich Mueller wrote: > > > > > > On Sat, 03 Dec 2022, Michał Górny wrote: > > > --- /dev/null > > +++ b/eclass/app-alternatives.eclass > > @@ -0,0 +1,84 @@ > > +# Copyright 2022 Gentoo Authors > > +# Distributed under the terms of the GNU General Public License v2 > > + > > +# @ECLASS: app-alternatives.eclass > > +# @MAINTAINER: > > +# Michał Górny > > +# @AUTHOR: > > +# Michał Górny > > +# @SUPPORTED_EAPIS: 8 > > +# @BLURB: Common logic for app-alternatives/* > > +# @DESCRIPTION: > > +# This eclass provides common logic shared by app-alternatives/* > > +# ebuilds. A global ALTERNATIVES variable needs to be declared > > +# that lists available options and their respective dependencies. > > +# HOMEPAGE, S, LICENSE, SLOT, IUSE, REQUIRED_USE and RDEPEND are > > set. > > +# A get_alternative() function is provided that prints the > > determines > > Grammar? Nope, ^w error. > > > +# the selected alternative and prints its respective flag name. > > + > > +case ${EAPI} in > > + 8) ;; > > + *) die "${ECLASS}: EAPI ${EAPI} unsupported." > > ${EAPI:-0} here? Sure. > > > +esac > > + > > +if [[ ! ${_APP_ALTERNATIVES_ECLASS} ]]; then > > +_APP_ALTERNATIVES_ECLASS=1 > > + > > +# @ECLASS_VARIABLE: ALTERNATIVES > > +# @PRE_INHERIT > > +# @REQUIRED > > +# @DESCRIPTION: > > +# Array of "flag:dependency" pairs specifying the available > > +# alternatives. The default provider must be listed first. > > + > > +# @FUNCTION: _app-alternatives_set_globals > > +# @INTERNAL > > +# @DESCRIPTION: > > +# Set ebuild metadata variables. > > +_app-alternatives_set_globals() { > > + debug-print-function ${FUNCNAME} "${@}" > > + > > + if [[ $(declare -p ALTERNATIVES) != "declare -a"* ]]; then > > The more modern (and presumably, more reliable) check would be: > > if [[ ${ALTERNATIVES@a} != *a* ]]; then > > Since the eclass supports EAPI 8 only, bash-5.0 is guaranteed, so the > feature will be available. Ok. > > > + die 'ALTERNATIVES must be an array.' > > + elif [[ ${#ALTERNATIVES[@]} -eq 0 ]]; then > > + die 'ALTERNATIVES must not be empty.' > > + fi > > + > > + HOMEPAGE=" > > https://wiki.gentoo.org/wiki/Project:Base/Alternatives; > > + S=${WORKDIR} > > + > > + LICENSE="CC0-1.0" > > + SLOT="0" > > + > > + # yep, that's a cheap hack adding '+' to the first flag > > + IUSE="+${ALTERNATIVES[*]%%:*}" > > + REQUIRED_USE="^^ ( ${ALTERNATIVES[*]%%:*} )" > > + RDEPEND="" > > + > > + local flag dep > > + for flag in "${ALTERNATIVES[@]}"; do > > + [[ ${flag} != *:* ]] && die "Invalid ALTERNATIVES > > item: ${flag}" > > + dep=${flag#*:} > > + flag=${flag%%:*} > > + RDEPEND+=" > > + ${flag}? ( ${dep} ) > > + " > > Why two newlines? A single space should be enough. What's the difference? It will be normalized by the PM anyway. > > > + done > > +} > > +_app-alternatives_set_globals > > + > > +# @FUNCTION: get_alternative > > +# @DESCRIPTION: > > +# Get the flag name for the selected alterantive (i.e. the USE flag > > set). > > Typo. Sam already spotted this one. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH] app-alternatives.eclass: New eclass to streamline app-alternatives/*
> On Sat, 03 Dec 2022, Michał Górny wrote: > --- /dev/null > +++ b/eclass/app-alternatives.eclass > @@ -0,0 +1,84 @@ > +# Copyright 2022 Gentoo Authors > +# Distributed under the terms of the GNU General Public License v2 > + > +# @ECLASS: app-alternatives.eclass > +# @MAINTAINER: > +# Michał Górny > +# @AUTHOR: > +# Michał Górny > +# @SUPPORTED_EAPIS: 8 > +# @BLURB: Common logic for app-alternatives/* > +# @DESCRIPTION: > +# This eclass provides common logic shared by app-alternatives/* > +# ebuilds. A global ALTERNATIVES variable needs to be declared > +# that lists available options and their respective dependencies. > +# HOMEPAGE, S, LICENSE, SLOT, IUSE, REQUIRED_USE and RDEPEND are set. > +# A get_alternative() function is provided that prints the determines Grammar? > +# the selected alternative and prints its respective flag name. > + > +case ${EAPI} in > + 8) ;; > + *) die "${ECLASS}: EAPI ${EAPI} unsupported." ${EAPI:-0} here? > +esac > + > +if [[ ! ${_APP_ALTERNATIVES_ECLASS} ]]; then > +_APP_ALTERNATIVES_ECLASS=1 > + > +# @ECLASS_VARIABLE: ALTERNATIVES > +# @PRE_INHERIT > +# @REQUIRED > +# @DESCRIPTION: > +# Array of "flag:dependency" pairs specifying the available > +# alternatives. The default provider must be listed first. > + > +# @FUNCTION: _app-alternatives_set_globals > +# @INTERNAL > +# @DESCRIPTION: > +# Set ebuild metadata variables. > +_app-alternatives_set_globals() { > + debug-print-function ${FUNCNAME} "${@}" > + > + if [[ $(declare -p ALTERNATIVES) != "declare -a"* ]]; then The more modern (and presumably, more reliable) check would be: if [[ ${ALTERNATIVES@a} != *a* ]]; then Since the eclass supports EAPI 8 only, bash-5.0 is guaranteed, so the feature will be available. > + die 'ALTERNATIVES must be an array.' > + elif [[ ${#ALTERNATIVES[@]} -eq 0 ]]; then > + die 'ALTERNATIVES must not be empty.' > + fi > + > + HOMEPAGE="https://wiki.gentoo.org/wiki/Project:Base/Alternatives; > + S=${WORKDIR} > + > + LICENSE="CC0-1.0" > + SLOT="0" > + > + # yep, that's a cheap hack adding '+' to the first flag > + IUSE="+${ALTERNATIVES[*]%%:*}" > + REQUIRED_USE="^^ ( ${ALTERNATIVES[*]%%:*} )" > + RDEPEND="" > + > + local flag dep > + for flag in "${ALTERNATIVES[@]}"; do > + [[ ${flag} != *:* ]] && die "Invalid ALTERNATIVES item: ${flag}" > + dep=${flag#*:} > + flag=${flag%%:*} > + RDEPEND+=" > + ${flag}? ( ${dep} ) > + " Why two newlines? A single space should be enough. > + done > +} > +_app-alternatives_set_globals > + > +# @FUNCTION: get_alternative > +# @DESCRIPTION: > +# Get the flag name for the selected alterantive (i.e. the USE flag set). Typo. > +get_alternative() { > + debug-print-function ${FUNCNAME} "${@}" > + > + local flag > + for flag in "${ALTERNATIVES[@]%%:*}"; do > + usev "${flag}" && return > + done > + > + die "No selected alternative found (REQUIRED_USE ignored?!)" > +} > + > +fi