[gentoo-dev] [PATCH 3/3] Summary for 20231210 meeting.
License: CC-BY-SA-4.0 Signed-off-by: Matt Turner --- meeting-logs/20231210-summary.txt | 71 +++ meeting-logs/20231210-summary.txt.asc | 10 2 files changed, 81 insertions(+) create mode 100644 meeting-logs/20231210-summary.txt create mode 100644 meeting-logs/20231210-summary.txt.asc diff --git a/meeting-logs/20231210-summary.txt b/meeting-logs/20231210-summary.txt new file mode 100644 index 000..c1dca69 --- /dev/null +++ b/meeting-logs/20231210-summary.txt @@ -0,0 +1,71 @@ +Summary of Gentoo council meeting 10 December 2023 + +Agenda +== + +1. Roll call +2. Foundation dissolution status update +3. Clarification of allarches stabilization policy +4. GLEP84 acceptance +5. Open bugs with council participation +6. Arch status review +7. Open floor + +Roll Call += + +Present: ajak, dilfridge, mattst88, mgorny (late), sam, soap, ulm + +Foundation dissolution status update + +mattst88 emailed the X.Org Board of Directors to ask for their experience with +SPI in November and pinged them again on December 5. He asked in their IRC +channel (#xf-bod on OFTC) as well on Dec 9. No response at the time of the +Council meeting [*] + +[*] We received a reply via email on Dec 12 from X.Org Board Member Ricardo +Garcia: + +> Regarding your questions, it's my understanding SPI are sometimes slow to +> reply to some questions and required actions, and the X.Org Foundation is +> now in the process of moving to SFC hoping that some of those problems are +> solved. +> +> The experience of joining an umbrella organization is generally good (but +> other board members with more experience should chime in on this), in the +> sense that it removes a fair amount of work from the treasurer and other +> board members. + +Clarification of allarches stabilization policy +=== +ulm asks for a clarification of the allarches stabilization policy: + +> I'd like the council to clarify the allarches stabilisation policy. +> In particular, can we allow self-stabilisation by maintainers for +> allarches packages, if the requirements for testing the package are +> fulfilled on at least one arch (e.g. stable system or stable chroot). + +Council agrees. + +GLEP84 approval +=== +Motion: Accept GLEP 84 (https://www.gentoo.org/glep/glep-0084.html) +Accepted 6-0 + +Open bugs with council involvement +== +None. + +Arch status review +== +No changes required at this time. + +Some discussion of ia64 support being dropped from core upstream projects. +Likely means the end of the ia64 Gentoo port in the near future. + +Open floor +== +Gentoo was not granted a booth for FOSDEM 2024. dilfridge has emailed the +organizers in the hopes of changing this. + +This work is licensed under the CC BY-SA 4.0 License. diff --git a/meeting-logs/20231210-summary.txt.asc b/meeting-logs/20231210-summary.txt.asc new file mode 100644 index 000..9b501ef --- /dev/null +++ b/meeting-logs/20231210-summary.txt.asc @@ -0,0 +1,10 @@ +-BEGIN PGP SIGNATURE- +Version: GnuPG v2 + +iOoEABYKAJIWIQReryEEmoa4pUzLG/qs6yl0DJpOlwUCZaAmcV8UgAAuAChp +c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0NUVB +RjIxMDQ5QTg2QjhBNTRDQ0IxQkZBQUNFQjI5NzQwQzlBNEU5NxQcbWF0dHN0ODhA +Z2VudG9vLm9yZwAKCRCs6yl0DJpOl8fVAP4mHzGl/l59I6Gl2smRtoGi/cL71L+E +I6W3MiHEzolEawEA2PM0v2dAPcVHQ3PM1qItBn/Tp15h3EcMqpIPBVljuAk= +=3MPH +-END PGP SIGNATURE- -- 2.43.0
[gentoo-dev] [PATCH 2/3] Summary for 20231112 meeting.
License: CC-BY-SA-4.0 Signed-off-by: Matt Turner --- meeting-logs/20231112-summary.txt | 34 +++ meeting-logs/20231112-summary.txt.asc | 10 2 files changed, 44 insertions(+) create mode 100644 meeting-logs/20231112-summary.txt create mode 100644 meeting-logs/20231112-summary.txt.asc diff --git a/meeting-logs/20231112-summary.txt b/meeting-logs/20231112-summary.txt new file mode 100644 index 000..4c6fd7c --- /dev/null +++ b/meeting-logs/20231112-summary.txt @@ -0,0 +1,34 @@ +Summary of Gentoo council meeting 12 November 2023 + +Agenda +== + +1. Roll call +2. Foundation dissolution status update +3. Open bugs with council participation +4. Open floor + +Roll Call += + +Present: ajak, dilfridge, mattst88, mgorny, sam, soap, ulm + +Foundation dissolution status update + +ulm and dilfridge emailed SPI and received prompt and positive responses. SPI +is open to accepting the Gentoo Foundation. + +mattst88 emailed the X.Org Board of Directors to ask for their experience with +SPI because he heard a rumor that they were not happy and were planning to +switch to a different umbrella. No response by the time of the meeting. + +Open bugs with council involvement +== +None. + +Open floor +== +arthurzam requested approval (not acceptance) of GLEP84 before he began +implementation. No further concerns, so Council agrees it's ready. + +This work is licensed under the CC BY-SA 4.0 License. diff --git a/meeting-logs/20231112-summary.txt.asc b/meeting-logs/20231112-summary.txt.asc new file mode 100644 index 000..c4f4388 --- /dev/null +++ b/meeting-logs/20231112-summary.txt.asc @@ -0,0 +1,10 @@ +-BEGIN PGP SIGNATURE- +Version: GnuPG v2 + +iOoEABYKAJIWIQReryEEmoa4pUzLG/qs6yl0DJpOlwUCZaAh6V8UgAAuAChp +c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0NUVB +RjIxMDQ5QTg2QjhBNTRDQ0IxQkZBQUNFQjI5NzQwQzlBNEU5NxQcbWF0dHN0ODhA +Z2VudG9vLm9yZwAKCRCs6yl0DJpOlxxrAQCuJWghhBFhw+4N74uJJpnC0EDrKbCD +X6F1rpOTaK7a/QD9GR3R1+zHzBELXGBwzchkqL3aMUgp6KmB1bh8XMErRAY= +=3xnE +-END PGP SIGNATURE- -- 2.43.0
[gentoo-dev] [PATCH 1/3] Log for 20231210 meeting.
License: CC-PDM-1.0 (raw IRC log, not copyrightable) Signed-off-by: Matt Turner --- meeting-logs/20231210.txt | 163 ++ meeting-logs/20231210.txt.asc | 10 +++ 2 files changed, 173 insertions(+) create mode 100644 meeting-logs/20231210.txt create mode 100644 meeting-logs/20231210.txt.asc diff --git a/meeting-logs/20231210.txt b/meeting-logs/20231210.txt new file mode 100644 index 000..af9cca6 --- /dev/null +++ b/meeting-logs/20231210.txt @@ -0,0 +1,163 @@ +14:00 <@ mattst88> | meeting time! +14:00 <@ mattst88> | !proj council +14:01 < willikins> | (coun...@gentoo.org) ajak, dilfridge, mattst88, mgorny, sam, soap, ulm +14:01 * | dilfridge here +14:01 <@ sam_> | \o +14:01 <@ mattst88> | Roll call! +14:01 * | ulm here +14:01 * | mattst88 here +14:01 * | ajak here +14:01 * | sam_ here +14:01 * | dilfridge here +14:02 <@ mattst88> | soap, mgorny: ping. we'll wait a few minutes +14:05 <@ mattst88> | alright, let's get started +14:05 <@ mattst88> | 2. Foundation dissolution status update +14:05 <@ mattst88> | ulm, dilfridge: want to comment? +14:05 <@ dilfridge> | not much new from me +14:05 <@ mattst88> | okay +14:05 <@ulm> | no news from our side +14:06 <@ dilfridge> | I talked to tomaw a bit but spi doesnt handle much for oftc +14:06 <@ sam_> | I think mattst88 pinged X11 again, and dilfridge spo- +14:06 <@ulm> | has anyone talked to other distros? +14:06 <@ mattst88> | I pinged the X.Org board by email and on #xf-bod on OFTC and never heard anything back :( +14:06 <@ dilfridge> | also, I wanted to read the logs of the spi board meeting but didnt get to it +14:06 <@ dilfridge> | => holidays +14:07 <@ mattst88> | okay, thanks +14:07 <@ulm> | we'll go ahead with SPI only if we get the council's mandate for it +14:07 <@ mattst88> | okay, next topic +14:07 <@ ajak> | i think i'd want some kind of "yeah they're fine" from a third party before fully committing +14:07 <@ mattst88> | from ulm: +14:08 <@ dilfridge> | ajak++ +14:08 <@ulm> | wfm +14:08 <@ mattst88> | I'd like the council to clarify the allarches stabilisation policy. +14:08 <@ mattst88> | In particular, can we allow self-stabilisation by maintainers for +14:08 <@ mattst88> | allarches packages, if the requirements for testing the package are +14:08 <@ mattst88> | fulfilled on at least one arch (e.g. stable system or stable chroot). +14:08 <@ mattst88> | --- +14:08 <@ mattst88> | this seems fine to me, IMO +14:08 <@ dilfridge> | works for me +14:08 <@ sam_> | sure +14:08 <@ulm> | just asking for a nod from the council if it's ok like this +14:09 <@ sam_> | no reason not to and I think it's been applied like this at least by some in the past too +14:09 <@ ajak> | yes, allarches shouldn't change the calculus of maintainer-stabilization +14:09 <@ mattst88> | yep, any need for a vote? +14:09 <@ soap> | sorry, was in the train +14:09 <+ arthurzam> | only keywording/rekeywording should go through the full arch testing +14:09 <+ arthurzam> | no issue with stabling +14:09 <@ulm> | I don't need one unless someone would disagree +14:09 * | soap here now +14:09 <@ mattst88> | hello soap :) +14:09 <@ dilfridge> | seems like we're all on the same pahe +14:09 <@ mattst88> | ulm: okay, thank you +14:09 <@ dilfridge> | page +14:10 <@ mattst88> | next topic +14:10 <@ mattst88> | arthurzam requests Council approval of a few changes to GLEP 84 +14:10 <+ arthurzam> | (this is a new GLEP) +14:10 <@ mattst88> | the link in the email seems to not work (https://gitweb.gentoo.org/data/glep.git/tree/glep-0084.rst?h=glep-0084) +14:10 <@ dilfridge> | that's the package.mask format? +14:11 <@ulm> | it's acceptance of the GLEP, right? +14:11 <+ arthurzam> | https://www.gentoo.org/glep/glep-0084.html +14:11 <+ arthurzam> | Yes +14:11 <@ mattst88> | I'm fine with this. does anyone have any concerns? +14:12 <@ sam_> | no, very happy indeed, thank you for doing it +14:12 <@ soap> | thanks arthurzam! +14:13 <@ mattst88> | awesome, time for a vote I think? +14:13 <@ mattst88> | Motion: Accept GLEP 84 (https://www.gentoo.org/glep/glep-0084.html) +14:13 * | ajak yes +14:13 * | mattst88 yes +14:13 * | sam_ yes +14:13 * | ulm yes +14:14 * | soap yes +14:14 * | dilfridge yes +14:14 <@ mattst88> | yay, 6-0 +14:14 <@ matts
[gentoo-dev] Re: GNOME needs a new maintainer in Gentoo
On Wed, Sep 20, 2023 at 10:31 AM Matt Turner wrote: > IMO, the state of the project is really good. We've been adding > alpha/beta/rc versions in order to catch and report problems to > upstream and to give us time to sort out important issues beforehand. > Most of GNOME 45 is already in ::gentoo under package.mask. Final update: - I've cleaned up the alpha/beta/rc versions and unmasked everything that had a stable release. - I filed a couple of rekeywording bugs where packages gained a new dependency. - I dropped sparc and ia64 keywords on a handful of GNOME packages that would have otherwise required rekeywording gui-libs/libadwaita, dev-libs/appstream, and some other things that didn't seem useful on these platforms. - I've dropped myself from the GNOME project and the mail alias.
[gentoo-dev] GNOME needs a new maintainer in Gentoo
Hello, Happy GNOME 45.0 release day! I've been maintaining the GNOME packages in Gentoo, essentially alone, since GNOME 3.38 (Sept 2020). After adding seven major versions of GNOME to Gentoo, I've decided to stop. So, the GNOME project needs a new maintainer. Preferably multiple. A quick accounting shows that I've done 1350 bumps of GNOME packages in the last 3 years (and reviewed and merged another 530 from Guillermo who has been contributing for only 1 year now). In upstream GNOME projects I've landed about 100 merge requests. IMO, the state of the project is really good. We've been adding alpha/beta/rc versions in order to catch and report problems to upstream and to give us time to sort out important issues beforehand. Most of GNOME 45 is already in ::gentoo under package.mask. When I forced myself into the GNOME team, there were a lot of bits of knowledge that were only accessible by being yelled at by the lead. I've tried to remedy that and to document important things to know. To that end, I've maintained a few pages on the Wiki: Somewhat of a guide for bumping GNOME packages: https://wiki.gentoo.org/wiki/Project:GNOME/GNOME_Bumping_Guide Notes about why packages listed on packages.gentoo.org's Outdated page haven't been handled: https://wiki.gentoo.org/wiki/Project:GNOME/GNOME_bumping_notes A table of unit testing results (from src_test) for GNOME packages: https://wiki.gentoo.org/wiki/Project:GNOME/GNOME_Unit_Test_Status libsoup:3.0 transition status (mostly behiind us at this point) https://wiki.gentoo.org/wiki/Project:GNOME/libsoup:3_transition I'll still be around, and I'm happy to help ramp up a developer that wants to take over. Guillermo has been doing great and has been an incredible help. I hope he'll become a Gentoo developer, but the project really needs more than a single person maintaining things. Matt
Re: [gentoo-dev] last rites: sys-fs/eudev
On Thu, Sep 14, 2023 at 10:17 AM Eddie Chapman wrote: > Of course whether the Gentoo community would deem me as a suitable > maintainer and be willing to accept me as such is another matter entirely. You don't need any permissions from us to go fix eudev upstream. Please focus on that (if you want) and less on filling our inboxes.
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan wrote: > > On 9/13/23, Matt Turner wrote: > > On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman wrote: > >> Why would you think that by having an alternative in tree it means that > >> everyone else is then forced into doing work that they don't want to and > >> it will inconvenience everyone? > > > > Because it's already happened! > > > > commit 6404b064d63d182da4a8a193533a188cdf832d41 > > Author: Mike Gilbert > > Date: Sun Jul 30 14:07:47 2023 -0400 > > > > virtual/libudev: add eudev and sticky-tags USE flags > > > > eudev lacks API support for the new libudev functions that > > differentiate > > between sticky and current tags on device events. > > > > Add a USE flag so we can depend on the new API from libgudev. > > > > > > commit 319b4ed88674af738bd3fd90e56dc06c88de15db > > Author: Mike Gilbert > > Date: Sun Jul 30 14:10:44 2023 -0400 > > > > dev-libs/libgudev: depend on virtual/libudev[sticky-tags] > > > > > > And as a result we have had at least three bug reports from users > > complaining that they cannot update: > > > > https://bugs.gentoo.org/913702 > > https://bugs.gentoo.org/913900 > > https://bugs.gentoo.org/913954 > > > >> What if someone came along now and said > >> they were willing to "step up" and maintain eudev and they were suitably > >> qualified? Is that really going to force everyone else to modify their > >> ways? > > > > It doesn't matter what people say. It matters what they do. And so far > > no one has done anything in more than two years to make eudev worth > > keeping. > > > > But the core of the issue for me is -- how is eudev even the slightest > > bit better in any way than systemd-utils[udev]? > > > > > > Is it such a burden to make a couple of commits once in a while? I see no commits from your email address in gentoo.git, so that might be a question for you. > How many commits were made in the last year to accommodate eudev? I'm not your monkey. > Regarding the bugs, what else did you expect when no news item was given? Right, we should have done something *else* to keep eudev going. Welcome to my killfile.
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman wrote: > Why would you think that by having an alternative in tree it means that > everyone else is then forced into doing work that they don't want to and > it will inconvenience everyone? Because it's already happened! commit 6404b064d63d182da4a8a193533a188cdf832d41 Author: Mike Gilbert Date: Sun Jul 30 14:07:47 2023 -0400 virtual/libudev: add eudev and sticky-tags USE flags eudev lacks API support for the new libudev functions that differentiate between sticky and current tags on device events. Add a USE flag so we can depend on the new API from libgudev. commit 319b4ed88674af738bd3fd90e56dc06c88de15db Author: Mike Gilbert Date: Sun Jul 30 14:10:44 2023 -0400 dev-libs/libgudev: depend on virtual/libudev[sticky-tags] And as a result we have had at least three bug reports from users complaining that they cannot update: https://bugs.gentoo.org/913702 https://bugs.gentoo.org/913900 https://bugs.gentoo.org/913954 > What if someone came along now and said > they were willing to "step up" and maintain eudev and they were suitably > qualified? Is that really going to force everyone else to modify their > ways? It doesn't matter what people say. It matters what they do. And so far no one has done anything in more than two years to make eudev worth keeping. But the core of the issue for me is -- how is eudev even the slightest bit better in any way than systemd-utils[udev]?
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, Sep 12, 2023 at 4:25 PM orbea wrote: > > On Tue, 12 Sep 2023 14:51:34 -0400 > Matt Turner wrote: > > > On Tue, Sep 12, 2023 at 11:35 AM orbea wrote: > > > > > > On Tue, 12 Sep 2023 15:17:00 +0100 > > > Sam James wrote: > > > > > > > Rich Freeman writes: > > > > > > > > > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman > > > > > wrote: > > > > >> in Gentoo. Have any of these 4 maintainers publicly said > > > > >> (anywhere) that they are not interested in being maintainers > > > > >> anymore (which is fine if that is the case)? We're not talking > > > > >> here about a lone maintainer of some peripheral package that's > > > > >> disappeared leaving an orphaned package. > > > > > > > > > > It isn't like somebody is censoring the lists or waging commit > > > > > wars on the metadata.xml/mask file. If somebody was eager to > > > > > maintain it I'm sure they'd have spoken up. > > > > > > > > > >> I'm an outsider to Gentoo development (just a heavy user for > > > > >> over a decade both personally and professionally) so I might > > > > >> have missed something. I just find it puzzling. > > > > > > > > > > I'm not puzzled by what is going on, or by your email, because > > > > > it happens basically anytime a high-profile package is > > > > > treecleaned. Yes, Gentoo is about choice, but somebody has to > > > > > actually do work to make the choices viable. There are always > > > > > more people interested in using software than maintaining it. > > > > > The frustration is completely understandable, but also kinda > > > > > unavoidable. > > > > > > > > > > Repo QA standards don't mean that it has to barely work for your > > > > > specific use case. The package has to deal with compatibility > > > > > issues with stuff you don't use as well, which is why > > > > > maintaining a system package can be hard work. It is usually > > > > > less of an issue for more ordinary applications, which tend to > > > > > have fewer interactions. If it is "good enough" for you as it > > > > > is, then just move it to a private overlay and keep using it. > > > > > You probably would need to override a virtual or two as well. > > > > > Or publish your work somewhere others can use it. > > > > > > > > Yes. We value having a coherent system with decent UX and we have > > > > to choose what we can support. Users are free to override those > > > > choices in local repositories - and if they want advice on the > > > > best way to do so, they're free to ask. > > > > > > > > > > As evidenced by the ::libressl overlay where I am repeatedly > > > copy/pasting changes from ::gentoo that have nothing to do with > > > libressl this is not a very good solution. This is a huge amount of > > > redundant and pointless effort that would be better suited being > > > directly in the ::gentoo repo. > > > > I think most people aren't going to be swayed by "it's really > > inefficient for me to do $xyz outside of ::gentoo" where xyz is > > something that they find useless. > > It doesn't matter if it sways you or not, the reality is that your > argument amounts to forcing people to do a lot of extra redundant work > solving problems that have already been solved out of spite. The lack of awareness here is really something.
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, Sep 12, 2023 at 1:24 PM Alexe Stefan wrote: > All this makes me wonder, what really is the reason for this shitshow. > Something tells me systemd and it's shims will never be without a > maintainer, regardless of how "popular" they are among gentoo folks. > All this seems like intentional crippling of systemd alternatives. I > don't use eudev, but I don't like seeing choice being taken away for > such paper-thin reasons. > The "reasons" listed for the removal are "dead upstream", which is > false, and open "bugs", most of which are at most differences in the > default behavior. > I use a static /dev. That won't just stop working after an update, > regardless of how much money changes hands. > > What does eudev need to do and doesn't do? From discussion in various > places, I understand that it must set permissions for a devtmpfs and > maybe create some symlinks. Does it not do that? > I know that Lennart wants to do everything and do it poorly, but eudev > doesn't have to do that too. What's the point of a for then? > > Overlays were mentioned in this thread. If we remove everything from > ::gentoo in favor of overlays, what is the point of ::gentoo then? Do > devs receive prizes based on how many useful packages they remove? > Don't answer that, we all already know the answer. > > There is this quote from "the doctor" on the forums that sums up all > the insanity: > > >As for software depending on what /dev you use, maybe he hasn't been paying > >>attention but there is no sane reason any userspace application should care > >how >the entries in /dev are made. There is also no sane reason to break > >your API >every few months when the good idea fairy comes to call. > > As for this: > > >Alexe Stefan writes: > > >> Must eudev be 100% compatible with all the garbage that gets shoved > >> into udev to stay in ::gentoo? I don't see mdev being held to that > >> standard. > > >Please don't top-post. > > >mdev is not a provider of virtual/libudev and doesn't pretend to be > >via its pkgconfig file. > > What if eudev has to pretend, not because of build or runtime > failures, but because of needless pesky pkgconfig checks? Should the > default eudev setup include virtual/libudev in package.provided? I > think it's better the way it is. > Lots of bad faith in this post. This is bad and you should feel bad.
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, Sep 12, 2023 at 11:35 AM orbea wrote: > > On Tue, 12 Sep 2023 15:17:00 +0100 > Sam James wrote: > > > Rich Freeman writes: > > > > > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman > > > wrote: > > >> in Gentoo. Have any of these 4 maintainers publicly said > > >> (anywhere) that they are not interested in being maintainers > > >> anymore (which is fine if that is the case)? We're not talking > > >> here about a lone maintainer of some peripheral package that's > > >> disappeared leaving an orphaned package. > > > > > > It isn't like somebody is censoring the lists or waging commit wars > > > on the metadata.xml/mask file. If somebody was eager to maintain > > > it I'm sure they'd have spoken up. > > > > > >> I'm an outsider to Gentoo development (just a heavy user for over > > >> a decade both personally and professionally) so I might have > > >> missed something. I just find it puzzling. > > > > > > I'm not puzzled by what is going on, or by your email, because it > > > happens basically anytime a high-profile package is treecleaned. > > > Yes, Gentoo is about choice, but somebody has to actually do work > > > to make the choices viable. There are always more people > > > interested in using software than maintaining it. The frustration > > > is completely understandable, but also kinda unavoidable. > > > > > > Repo QA standards don't mean that it has to barely work for your > > > specific use case. The package has to deal with compatibility > > > issues with stuff you don't use as well, which is why maintaining a > > > system package can be hard work. It is usually less of an issue > > > for more ordinary applications, which tend to have fewer > > > interactions. If it is "good enough" for you as it is, then just > > > move it to a private overlay and keep using it. You probably would > > > need to override a virtual or two as well. Or publish your work > > > somewhere others can use it. > > > > Yes. We value having a coherent system with decent UX and we have > > to choose what we can support. Users are free to override those > > choices in local repositories - and if they want advice on the best > > way to do so, they're free to ask. > > > > As evidenced by the ::libressl overlay where I am repeatedly > copy/pasting changes from ::gentoo that have nothing to do with > libressl this is not a very good solution. This is a huge amount of > redundant and pointless effort that would be better suited being > directly in the ::gentoo repo. I think most people aren't going to be swayed by "it's really inefficient for me to do $xyz outside of ::gentoo" where xyz is something that they find useless. > What would be required so this is not required for eudev too? At the > risk of repeating myself its working on my systems and I am willing to > look at bugs and put in effort into keeping it functional. > > I don't think this is a matter of not having people willing to put > effort in, but that no one wants to let them have the chance. Conspiracy alert! It's been more than 2 years since https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html People have had plenty of time. More chances than were fair have been given. Nothing has changed, except eudev has further diverged from upstream udev.
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, Sep 12, 2023 at 11:04 AM Eddie Chapman wrote: > Yes I regularly do this if there is a piece of software not in the tree, I > have a local repo full of stuff. But this argument doesn't hold as much > weight when it comes to a package like this which is integrated in the > core of the system. People who really want to continue using it are going > to experience a lot of pain trying to maintain it for themselves out of > tree, much more so than they would normally. That's one reason why I think > the decision deserves more scrutiny. Yes, people who insist on using a piece of software that's basically stagnant are going to have trouble trying to maintain it themselves. You're right. You're just missing that this is because of upstream eudev not backporting anything anymore. Take a look at https://openhub.net/p/eudev 12 month summary * 22 Commits - Down -97 (81%) from previous 12 months * 5 Contributors - Down -5 (50%) from previous 12 months There used to be backports from upstream udev like this: https://github.com/eudev-project/eudev/commit/9d4010a3629ebc1d915b7f2d3e2d7be83d79b4f4 But it seems that no one does that anymore since blueness stopped. blueness -- one of the original maintainers of eudev and the author of the news item that says the reason for eudev's existence no longer applies... So tl;dr: we're sorry eudev is no longer viable. We kept it in ::gentoo for far longer than it should have been.
[gentoo-dev] Last Rites: net-wireless/blueberry and net-wireless/gnome-bluetooth:2
# Olivier Laurantin (2023-08-29) # Masked for removal on 2023-10-01 # net-wireless/blueberry will never work with recent gnome-bluetooth versions # and is the only package requiring net-wireless/gnome-bluetooth:2 net-wireless/blueberry net-wireless/gnome-bluetooth:2 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] cmake.eclass: Remove duplicate eninja call from cmake_build
On Wed, Aug 23, 2023 at 2:51 AM Michał Górny wrote:
>
> Signed-off-by: Michał Górny
> ---
> eclass/cmake.eclass | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
> index fb3f9b6352be..d0f6d0b4bd91 100644
> --- a/eclass/cmake.eclass
> +++ b/eclass/cmake.eclass
> @@ -661,7 +661,6 @@ cmake_build() {
> OFF) NINJA_VERBOSE=OFF eninja "$@" ;;
> *) eninja "$@" ;;
> esac
> - eninja "$@"
> ;;
> esac
>
> --
> 2.42.0
Oops. Thanks. Looks good to me.
[gentoo-dev] Last Rites: net-libs/rest:0.7
# Matt Turner (2023-08-14) # Dead slot depending on libsoup:2.4 # Removal on 2023-09-14. net-libs/rest:0.7 signature.asc Description: PGP signature
[gentoo-dev] Last Rites: gnome-extra/synapse
# Matt Turner (2023-08-14) # Unmaintained in Gentoo and upstream. Last release was 2018, last commit # upstream was 2021. Only reverse dependency of dead net-libs/rest:0.7. # Removal on 2023-09-14. gnome-extra/synapse signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC PATCH] metadata: Add gnome package stabilization groups
On Fri, Jul 21, 2023 at 2:22 PM Arthur Zamarin wrote:
>
> On 19/07/2023 19.10, Matt Turner wrote:
> > Signed-off-by: Matt Turner
> > ---
> > Feel free to bikeshed the location, structure, file-format, etc.
> >
> > metadata/stabilization-groups/gnome/evolution | 3 +++
> > metadata/stabilization-groups/gnome/glib | 3 +++
> > metadata/stabilization-groups/gnome/gnome-shell | 4
> > metadata/stabilization-groups/gnome/gobject-introspection | 2 ++
> > metadata/stabilization-groups/gnome/sysprof | 3 +++
> > metadata/stabilization-groups/gnome/vala | 2 ++
> > metadata/stabilization-groups/gnome/vte | 3 +++
> > 7 files changed, 20 insertions(+)
> > create mode 100644 metadata/stabilization-groups/gnome/evolution
> > create mode 100644 metadata/stabilization-groups/gnome/glib
> > create mode 100644 metadata/stabilization-groups/gnome/gnome-shell
> > create mode 100644
> > metadata/stabilization-groups/gnome/gobject-introspection
> > create mode 100644 metadata/stabilization-groups/gnome/sysprof
> > create mode 100644 metadata/stabilization-groups/gnome/vala
> > create mode 100644 metadata/stabilization-groups/gnome/vte
> >
>
> So semi-formalizing it before I implement parsing it in pkgcore:
>
> 1. everything is located under "metadata/stabilization-groups/"
> 2. We search recursively as much as needed, so all files are included in
> any depth.
> 3. Group name plays similarly to path, so here the group name would be
> "@gnome/vte" (at least for `pkgdev bugs` invocations). By using full
> path, we are safe from name collisions.
> 4. The file itself uses similar format to our various profiles files.
> Ignore white-spaces before and after, "#" as a comment. Only one
> "cat/pkg" per line.
> 5. I think for now we can go without mandatory copyright header...
>
>
>
> How it will affect `pkgdev bugs` invocations? I'll use your sets as
> example. Let's say our invocation is `pkgdev bugs dev-libs/glib
> @gnome/vala`.
>
> - if a set is passed (anything starting with @), replace it with all the
> contents of that set (so "@gnome/vala" equals to "dev-libs/vala-common
> dev-lang/vala").
>
> - Drop every package from the pkglist whose latest matching package to
> the restricts expression is already latest (so nothing better to do).
>
> - pkgdev bugs builds the full graph as it does today. Let's say it
> decided it needs to also add "dev-util/glib-utils".
>
> - For every defined set, all the packages included in graph and in the
> set are merged into one bug. This means we would get one bug for
> "@gnome/vala" ("dev-libs/vala-common dev-lang/vala") and one bug for
> "@gnome/glib" ("dev-libs/glib dev-util/glib-utils"). Notice that it
> didn't add the other package in that set ("dev-util/gdbus-codegen")
> since it wasn't requested or required.
>
> Does this flow seems logical and flexible enough? I don't think auto
> adding whole set if any one of it's package is required is a good idea
> since it might explode? If folks want to stable the whole set, explicit
> pass it as arg in the invocation.
>
> Do note that I'm open to other flows and usages, everything is open for
> me (I didn't start to implement it, just scratches in my notebook).
Yeah, this sounds spot on to me.
Thanks Arthur!
Re: [gentoo-dev] [PATCH v2] meson.eclass: allow disabling verbose compilation
On Thu, Jul 20, 2023 at 11:06 AM Florian Schmaus wrote:
>
> On 20/07/2023 17.00, Matt Turner wrote:
> > On Wed, Jul 19, 2023 at 3:23 AM Florian Schmaus wrote:
> >>
> >> On 18/07/2023 18.44, Matt Turner wrote:
> >>> From: Jonas Rakebrandt
> >>>
> >>> This works similar to cmake.eclass's ${CMAKE_VERBOSE}.
> >>>
> >>> Closes: https://github.com/gentoo/gentoo/pull/28942
> >>> Signed-off-by: Jonas Rakebrandt
> >>> Signed-off-by: Matt Turner
> >>> ---
> >>>eclass/meson.eclass | 15 +--
> >>>1 file changed, 13 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> >>> index 2c274b213191..3b30f66bf30a 100644
> >>> --- a/eclass/meson.eclass
> >>> +++ b/eclass/meson.eclass
> >>> @@ -55,6 +55,12 @@ BDEPEND=">=dev-util/meson-0.62.2
> >>># Build directory, location where all generated files should be placed.
> >>># If this isn't set, it defaults to ${WORKDIR}/${P}-build.
> >>>
> >>> +# @ECLASS_VARIABLE: MESON_VERBOSE
> >>> +# @USER_VARIABLE
> >>> +# @DESCRIPTION:
> >>> +# Set to OFF to disable verbose messages during compilation
> >>> +: "${MESON_VERBOSE:=ON}"
> >>> +
> >>># @ECLASS_VARIABLE: EMESON_BUILDTYPE
> >>># @DESCRIPTION:
> >>># The buildtype value to pass to meson setup.
> >>> @@ -385,10 +391,15 @@ meson_src_compile() {
> >>>-C "${BUILD_DIR}"
> >>>--jobs "$(makeopts_jobs "${MAKEOPTS}" 0)"
> >>>--load-average "$(makeopts_loadavg "${MAKEOPTS}" 0)"
> >>> - --verbose
> >>> - "$@"
> >>>)
> >>>
> >>> + case ${MESON_VERBOSE} in
> >>> + OFF) ;;
> >>> + *) mesoncompileargs+=( --verbose ) ;;
> >>> + esac
> >>
> >> No strong opinion, just to educate myself, but is there an advantage of
> >> using case/easc over if/fi here?
> >>
> >> That is
> >>
> >> if [[ ${MESON_VERBOSE} != off ]]; then
> >> mesoncompileargs+=( --verbose )
> >> fi
> >>
> >> or even the shell-style short idiom using ||.
> >
> > No advantage as far as I'm aware. I was just copying the style used in
> > cmake.eclass.
> >
> > I really wish bash just had boolean types :(
>
> While the bash language has no boolean datatype, you can exploit the
> fact that 'true' and 'false' are usually shell builtins:
>
> : "${MESON_VERBOSE:=true}"
>
> and then later
>
> if $MESON_VERBOSE; then
> mesoncompileargs+=( --verbose )
> fi
Oh neat, thanks for the info!
Re: [gentoo-dev] [PATCH v2] meson.eclass: allow disabling verbose compilation
On Wed, Jul 19, 2023 at 3:23 AM Florian Schmaus wrote:
>
> On 18/07/2023 18.44, Matt Turner wrote:
> > From: Jonas Rakebrandt
> >
> > This works similar to cmake.eclass's ${CMAKE_VERBOSE}.
> >
> > Closes: https://github.com/gentoo/gentoo/pull/28942
> > Signed-off-by: Jonas Rakebrandt
> > Signed-off-by: Matt Turner
> > ---
> > eclass/meson.eclass | 15 +--
> > 1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> > index 2c274b213191..3b30f66bf30a 100644
> > --- a/eclass/meson.eclass
> > +++ b/eclass/meson.eclass
> > @@ -55,6 +55,12 @@ BDEPEND=">=dev-util/meson-0.62.2
> > # Build directory, location where all generated files should be placed.
> > # If this isn't set, it defaults to ${WORKDIR}/${P}-build.
> >
> > +# @ECLASS_VARIABLE: MESON_VERBOSE
> > +# @USER_VARIABLE
> > +# @DESCRIPTION:
> > +# Set to OFF to disable verbose messages during compilation
> > +: "${MESON_VERBOSE:=ON}"
> > +
> > # @ECLASS_VARIABLE: EMESON_BUILDTYPE
> > # @DESCRIPTION:
> > # The buildtype value to pass to meson setup.
> > @@ -385,10 +391,15 @@ meson_src_compile() {
> > -C "${BUILD_DIR}"
> > --jobs "$(makeopts_jobs "${MAKEOPTS}" 0)"
> > --load-average "$(makeopts_loadavg "${MAKEOPTS}" 0)"
> > - --verbose
> > - "$@"
> > )
> >
> > + case ${MESON_VERBOSE} in
> > + OFF) ;;
> > + *) mesoncompileargs+=( --verbose ) ;;
> > + esac
>
> No strong opinion, just to educate myself, but is there an advantage of
> using case/easc over if/fi here?
>
> That is
>
> if [[ ${MESON_VERBOSE} != off ]]; then
> mesoncompileargs+=( --verbose )
> fi
>
> or even the shell-style short idiom using ||.
No advantage as far as I'm aware. I was just copying the style used in
cmake.eclass.
I really wish bash just had boolean types :(
[gentoo-dev] [RFC PATCH] metadata: Add gnome package stabilization groups
Signed-off-by: Matt Turner --- Feel free to bikeshed the location, structure, file-format, etc. metadata/stabilization-groups/gnome/evolution | 3 +++ metadata/stabilization-groups/gnome/glib | 3 +++ metadata/stabilization-groups/gnome/gnome-shell | 4 metadata/stabilization-groups/gnome/gobject-introspection | 2 ++ metadata/stabilization-groups/gnome/sysprof | 3 +++ metadata/stabilization-groups/gnome/vala | 2 ++ metadata/stabilization-groups/gnome/vte | 3 +++ 7 files changed, 20 insertions(+) create mode 100644 metadata/stabilization-groups/gnome/evolution create mode 100644 metadata/stabilization-groups/gnome/glib create mode 100644 metadata/stabilization-groups/gnome/gnome-shell create mode 100644 metadata/stabilization-groups/gnome/gobject-introspection create mode 100644 metadata/stabilization-groups/gnome/sysprof create mode 100644 metadata/stabilization-groups/gnome/vala create mode 100644 metadata/stabilization-groups/gnome/vte diff --git a/metadata/stabilization-groups/gnome/evolution b/metadata/stabilization-groups/gnome/evolution new file mode 100644 index ..21bbcf804e94 --- /dev/null +++ b/metadata/stabilization-groups/gnome/evolution @@ -0,0 +1,3 @@ +gnome-extra/evolution-data-server +gnome-extra/evolution-ews +mail-client/evolution diff --git a/metadata/stabilization-groups/gnome/glib b/metadata/stabilization-groups/gnome/glib new file mode 100644 index ..51a5659dd725 --- /dev/null +++ b/metadata/stabilization-groups/gnome/glib @@ -0,0 +1,3 @@ +dev-libs/glib +dev-util/gdbus-codegen +dev-util/glib-utils diff --git a/metadata/stabilization-groups/gnome/gnome-shell b/metadata/stabilization-groups/gnome/gnome-shell new file mode 100644 index ..ddf76f8f88f4 --- /dev/null +++ b/metadata/stabilization-groups/gnome/gnome-shell @@ -0,0 +1,4 @@ +gnome-base/gnome-shell +gnome-extra/gnome-shell-extensions +gnome-extra/gnome-shell-frippery +x11-wm/mutter diff --git a/metadata/stabilization-groups/gnome/gobject-introspection b/metadata/stabilization-groups/gnome/gobject-introspection new file mode 100644 index ..8baf4ae59124 --- /dev/null +++ b/metadata/stabilization-groups/gnome/gobject-introspection @@ -0,0 +1,2 @@ +dev-libs/gobject-introspection +dev-libs/gobject-introspection-common diff --git a/metadata/stabilization-groups/gnome/sysprof b/metadata/stabilization-groups/gnome/sysprof new file mode 100644 index ..66a338916039 --- /dev/null +++ b/metadata/stabilization-groups/gnome/sysprof @@ -0,0 +1,3 @@ +dev-util/sysprof +dev-util/sysprof-capture +dev-util/sysprof-common diff --git a/metadata/stabilization-groups/gnome/vala b/metadata/stabilization-groups/gnome/vala new file mode 100644 index ..2e4d5a33748d --- /dev/null +++ b/metadata/stabilization-groups/gnome/vala @@ -0,0 +1,2 @@ +dev-lang/vala +dev-libs/vala-common diff --git a/metadata/stabilization-groups/gnome/vte b/metadata/stabilization-groups/gnome/vte new file mode 100644 index ..ce25ab265262 --- /dev/null +++ b/metadata/stabilization-groups/gnome/vte @@ -0,0 +1,3 @@ +gui-libs/vte +gui-libs/vte-common +x11-libs/vte -- 2.41.0
[gentoo-dev] [PATCH v2] meson.eclass: allow disabling verbose compilation
From: Jonas Rakebrandt
This works similar to cmake.eclass's ${CMAKE_VERBOSE}.
Closes: https://github.com/gentoo/gentoo/pull/28942
Signed-off-by: Jonas Rakebrandt
Signed-off-by: Matt Turner
---
eclass/meson.eclass | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 2c274b213191..3b30f66bf30a 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -55,6 +55,12 @@ BDEPEND=">=dev-util/meson-0.62.2
# Build directory, location where all generated files should be placed.
# If this isn't set, it defaults to ${WORKDIR}/${P}-build.
+# @ECLASS_VARIABLE: MESON_VERBOSE
+# @USER_VARIABLE
+# @DESCRIPTION:
+# Set to OFF to disable verbose messages during compilation
+: "${MESON_VERBOSE:=ON}"
+
# @ECLASS_VARIABLE: EMESON_BUILDTYPE
# @DESCRIPTION:
# The buildtype value to pass to meson setup.
@@ -385,10 +391,15 @@ meson_src_compile() {
-C "${BUILD_DIR}"
--jobs "$(makeopts_jobs "${MAKEOPTS}" 0)"
--load-average "$(makeopts_loadavg "${MAKEOPTS}" 0)"
- --verbose
- "$@"
)
+ case ${MESON_VERBOSE} in
+ OFF) ;;
+ *) mesoncompileargs+=( --verbose ) ;;
+ esac
+
+ mesoncompileargs+=( "$@" )
+
set -- meson compile "${mesoncompileargs[@]}"
echo "$@" >&2
"$@" || die "compile failed"
--
2.41.0
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
On Mon, Jul 17, 2023 at 3:43 PM Florian Schmaus wrote: > > # Florian Schmaus (2023-07-17) > # Obsolete acct-* packages which became leaf packages. > # Removal on 2023-08-17. > acct-user/artifactory > acct-group/artifactory > acct-user/cinder > acct-group/cinder > acct-user/glance > acct-group/glance > acct-user/heat > acct-group/heat > acct-user/keystone > acct-group/keystone > acct-user/litecoin > acct-group/litecoin > acct-user/logcheck > acct-group/logcheck > acct-user/minbif > acct-group/minbif > acct-user/minio > acct-group/minio > acct-user/netbox > acct-group/netbox > acct-user/neutron > acct-group/neutron > acct-user/nova > acct-group/nova > acct-user/placement > acct-group/placement > acct-user/quagga > acct-group/quagga > acct-user/rplayd > acct-group/rplayd > acct-user/rstudio-server > acct-group/rstudio-server > acct-user/rundeck > acct-group/rundeck > acct-user/sguil > acct-group/sguil > acct-user/sigh > acct-group/sigh > acct-user/smokeping > acct-group/smokeping > acct-user/sobby > acct-group/sobby > acct-user/spread > acct-group/spread > acct-user/stg > acct-group/stg > acct-user/swift > acct-group/swift > acct-user/thttpd > acct-group/thttpd > acct-group/gpio > acct-group/simplevirt > acct-group/spi Haven't we been keeping these because we still need to decide on a policy about what to do with dead acct-*/* packages?
Re: [gentoo-dev] [PATCH] git-r3.eclass: Use '__init__' as initial branch
On Mon, Jul 17, 2023 at 12:01 PM Ulrich Mueller wrote: > > > On Mon, 17 Jul 2023, konsolebox wrote: > > >> Maybe the commit message could shortly explain why this is needed, > >> or what problem is fixed by it? > > > It silences the default branch warning. > > Add this sentence to the commit message then? I will do that. > > If that's unwanted, kindly just close the issue. > > Huh? He's just saying if we don't want the patch, that's okay with him.
Re: [gentoo-dev] [PATCH] meson.eclass: allow disabling verbose compilation
On Mon, Jul 17, 2023 at 10:56 AM Adrian Schollmeyer wrote:
> Am Montag, dem 17.07.2023 um 10:51 -0400 schrieb Matt Turner:
> > This works similar to cmake.eclass's ${CMAKE_VERBOSE}.
>
> Why not use MESON_VERBOSE as well? Avoids double negation in the code
> (not unset -> verbose vs. MESON_VERBOSE == true -> verbose) and keeps
> the variable naming similar to cmake.eclass.
>
> nex
I personally agree -- I was just sending the patch as-is from GitHub.
[gentoo-dev] Re: [PATCH] meson.eclass: allow disabling verbose compilation
On Mon, Jul 17, 2023 at 10:51 AM Matt Turner wrote:
>
> From: Jonas Rakebrandt
>
> This works similar to cmake.eclass's ${CMAKE_VERBOSE}.
... except that it's _QUIET, rather than _VERBOSE.
I've sent patches to add NINJA_VERBOSE to ninja-utils.eclass and
another to support CMAKE_VERBOSE with ninja.
This makes me think we should keep things consistent here by switching
this to MESON_VERBOSE.
[gentoo-dev] [PATCH 2/2] cmake.eclass: Support CMAKE_VERBOSE with ninja
Signed-off-by: Matt Turner
---
eclass/cmake.eclass | 4
1 file changed, 4 insertions(+)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index d70f2cbf1fac..16b3e300ccae 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -651,6 +651,10 @@ cmake_build() {
;;
ninja)
[[ -e build.ninja ]] || die "build.ninja not found.
Error during configure stage."
+ case ${CMAKE_VERBOSE} in
+ OFF) NINJA_VERBOSE=OFF eninja "$@" ;;
+ *) eninja "$@" ;;
+ esac
eninja "$@"
;;
esac
--
2.41.0
[gentoo-dev] [PATCH 1/2] ninja-utils.eclass: Add NINJA_VERBOSE
ninja operates in one of three modes:
- verbose (with -v): prints build commands
- quiet (with --quiet): prints nothing
- normal: prints [XX/YY]-style build status updates
samurai works the same way, except it does not have a quiet mode.
Thus we can't simply override ninja-utils' hard-coded flag from callers
of eninja.
Signed-off-by: Matt Turner
---
eclass/ninja-utils.eclass | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/eclass/ninja-utils.eclass b/eclass/ninja-utils.eclass
index e6d8c9e6c0a9..26ba31678f01 100644
--- a/eclass/ninja-utils.eclass
+++ b/eclass/ninja-utils.eclass
@@ -48,6 +48,12 @@ _NINJA_UTILS_ECLASS=1
# supposed to be set in make.conf. If unset, eninja() will convert
# MAKEOPTS instead.
+# @ECLASS_VARIABLE: NINJA_VERBOSE
+# @USER_VARIABLE
+# @DESCRIPTION:
+# Set to OFF to disable verbose messages during compilation
+: "${NINJA_VERBOSE:=ON}"
+
inherit multiprocessing
case "${NINJA}" in
@@ -80,7 +86,12 @@ get_NINJAOPTS() {
# also supports being called via 'nonfatal'.
eninja() {
[[ -n "${NINJA_DEPEND}" ]] || ewarn "Unknown value '${NINJA}' for
\${NINJA}"
- set -- "${NINJA}" -v $(get_NINJAOPTS) "$@"
+ local v
+ case "${NINJA_VERBOSE}" in
+ OFF) ;;
+ *) v="-v"
+ esac
+ set -- "${NINJA}" ${v} $(get_NINJAOPTS) "$@"
echo "$@" >&2
"$@" || die -n "${*} failed"
}
--
2.41.0
[gentoo-dev] [PATCH] meson.eclass: allow disabling verbose compilation
From: Jonas Rakebrandt
This works similar to cmake.eclass's ${CMAKE_VERBOSE}.
Closes: https://github.com/gentoo/gentoo/pull/28942
Signed-off-by: Jonas Rakebrandt
Signed-off-by: Matt Turner
---
eclass/meson.eclass | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 2c274b213191..1acdee9325b2 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -55,6 +55,12 @@ BDEPEND=">=dev-util/meson-0.62.2
# Build directory, location where all generated files should be placed.
# If this isn't set, it defaults to ${WORKDIR}/${P}-build.
+# @ECLASS_VARIABLE: MESON_QUIET
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Disables verbose messages during compilation if non-empty.
+
# @ECLASS_VARIABLE: EMESON_BUILDTYPE
# @DESCRIPTION:
# The buildtype value to pass to meson setup.
@@ -385,10 +391,14 @@ meson_src_compile() {
-C "${BUILD_DIR}"
--jobs "$(makeopts_jobs "${MAKEOPTS}" 0)"
--load-average "$(makeopts_loadavg "${MAKEOPTS}" 0)"
- --verbose
- "$@"
)
+ if [[ -z ${MESON_QUIET} ]]; then
+ mesoncompileargs+=( --verbose )
+ fi
+
+ mesoncompileargs+=( "$@" )
+
set -- meson compile "${mesoncompileargs[@]}"
echo "$@" >&2
"$@" || die "compile failed"
--
2.41.0
[gentoo-dev] [PATCH] git-r3.eclass: Use '__init__' as initial branch
From: konsolebox
Closes: https://bugs.gentoo.org/841392
Signed-off-by: Matt Turner
---
eclass/git-r3.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index e9fdf2ac3a42..5ac141962b12 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -344,7 +344,7 @@ _git-r3_set_gitdir() {
umask "${EVCS_UMASK}" || die "Bad options to umask:
${EVCS_UMASK}"
fi
mkdir "${GIT_DIR}" || die
- git init --bare || die
+ git init --bare -b __init__ || die
if [[ ${saved_umask} ]]; then
umask "${saved_umask}" || die
fi
@@ -874,7 +874,7 @@ git-r3_checkout() {
# use git init+fetch instead of clone since the latter doesn't
like
# non-empty directories.
- git init --quiet || die
+ git init --quiet -b __init__ || die
# setup 'alternates' to avoid copying objects
echo "${orig_repo}/objects" >
"${GIT_DIR}"/objects/info/alternates || die
# now copy the refs
--
2.41.0
Re: [gentoo-dev] Package stabilization groups
On Sun, Jul 16, 2023 at 2:04 PM Arthur Zamarin wrote: > Now I'll speak from the point of implementer of `pkgdev bugs`. For me I > think both approaches are good, but I would prefer the latter over the > former. Nicer syntax, easy cache of all groups, easier to solve the > "graph problems" in the tool. Sounds good to me. Should we have infra create a new git repo for us for this purpose?
Re: [gentoo-dev] Package stabilization groups
On Sun, Jul 16, 2023 at 11:15 AM Fabian Groffen wrote: > > On 16-07-2023 10:57:54 -0400, Matt Turner wrote: > > Hello, > > > > Many of us have started using `pkgdev bugs` to file stabilization > > bugs. It works well (Thanks Arthur!) and I encourage everyone to give > > it a try. > > > > Where possible, it files one stabilization bug per package. This makes > > arch testers' jobs easier and makes the task easier to automate. > > > > But sometimes we do want to stabilize packages together. For example > > major versions of x11-wm/mutter and gnome-base/gnome-shell are tied > > together. If a new mutter is stabilized without the new gnome-shell, > > the tree will still be consistent, but emerge -u @world will warn > > users that the mutter upgrade is blocked. > > > > There was some brief discussion on IRC about how to document these > > groupings, and two main ideas were suggested: > > > > - add a field to metadata.xml to specify the group by an arbitrary name. > > E.g. > > Each package in the group would specify the same value of name="..." > > > > - maintain the groups in a separate place (similar to portage @sets). > > > > Can anyone think of particular advantages or disadvantages to one > > solution versus the other? Any other (better) ideas? > > I don't know how widespread the problem is, and how much it can be > generalised, but could you perhaps use a virtual, such that > stabilisation of the virtual means the deps must be satisfied? Heh, I guess we could do that if we had no other options.
[gentoo-dev] Package stabilization groups
Hello, Many of us have started using `pkgdev bugs` to file stabilization bugs. It works well (Thanks Arthur!) and I encourage everyone to give it a try. Where possible, it files one stabilization bug per package. This makes arch testers' jobs easier and makes the task easier to automate. But sometimes we do want to stabilize packages together. For example major versions of x11-wm/mutter and gnome-base/gnome-shell are tied together. If a new mutter is stabilized without the new gnome-shell, the tree will still be consistent, but emerge -u @world will warn users that the mutter upgrade is blocked. There was some brief discussion on IRC about how to document these groupings, and two main ideas were suggested: - add a field to metadata.xml to specify the group by an arbitrary name. E.g. Each package in the group would specify the same value of name="..." - maintain the groups in a separate place (similar to portage @sets). Can anyone think of particular advantages or disadvantages to one solution versus the other? Any other (better) ideas? Thanks, Matt
[gentoo-dev] Last Rites: dev-perl/Gtk2-Notify
# Matt Turner (2023-07-06) # Dead package. No reverse dependencies. # Removal on 2023-08-06. dev-perl/Gtk2-Notify signature.asc Description: PGP signature
[gentoo-dev] Last Rites: x11-libs/libwnck:1
# Matt Turner (2023-06-22) # Dead slot. Depends on x11-libs/gtk+:2. # Removal on 2023-07-22. Bug #769500. x11-libs/libwnck:1 signature.asc Description: PGP signature
[gentoo-dev] Last Rites: dev-perl/gnome2-wnck
# Matt Turner (2023-06-22) # Dead package. Depends on x11-libs/libwnck:1. # Removal on 2023-07-22. Bug #774906. dev-perl/gnome2-wnck signature.asc Description: PGP signature
[gentoo-dev] Last Rites: media-sound/gmusicbrowser
# Matt Turner (2023-06-22) # Depends on deprecated packages: #- dev-perl/Gtk2 #- dev-perl/Gtk2-Notify #- dev-perl/gnome2-wnck # No maintainer in Gentoo. Seems unmaintained upstream as well. # Removal on 2023-07-22. Bug #774909. media-sound/gmusicbrowser signature.asc Description: PGP signature
Re: [gentoo-dev] What happened to gcc-12.3.0?
On Thu, Jun 15, 2023 at 12:02 AM Joshua Kinard wrote: Options? I mean, if anyone knows magic to make gcc build faster, I am all ears, but ever since the switch to > C++, the time needed for it to build itself has just been absolutely > horrendous. And it gets worse with each > new release, for some reason. EXTRA_ECONF=--disable-bootstrap See https://bugs.gentoo.org/705406#c1
[gentoo-dev] Re: [PATCH v2] profiles: promote USE=vulkan to global USE flag
On Mon, May 22, 2023 at 4:27 PM Sam James wrote: > > Thanks to leio for this improved phrasing. > > Signed-off-by: Sam James > --- > profiles/use.desc | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/profiles/use.desc b/profiles/use.desc > index 2d5489acc568..47438c839071 100644 > --- a/profiles/use.desc > +++ b/profiles/use.desc > @@ -344,6 +344,7 @@ videos - Install optional video files (used in some games) > vim-syntax - Pulls in related vim syntax scripts > vnc - Enable VNC (remote desktop viewer) support > vorbis - Add support for the OggVorbis audio codec > +vulkan - Add support for 3D graphics and computing via the Vulkan > cross-platform API > wavpack - Add support for wavpack audio compression tools > wayland - Enable dev-libs/wayland backend > webkit - Add support for the WebKit HTML rendering/layout engine > -- > 2.40.1 > Looks good to me.
[gentoo-dev] Last Rites: gnome-extra/gucharmap:0
# Matt Turner (2023-05-12) # Dead slot. Only reverse dependency is stardict which is masked for removal # Removal on 2023-06-12 gnome-extra/gucharmap:0 signature.asc Description: PGP signature
[gentoo-dev] Last Rites: app-text/stardict and friends
[Also mark eclass/stardict.eclass as @DEAD] # Matt Turner (2023-05-11) # Console version of stardict which is masked for removal. Only reverse # dependencies are app-dicts/stardict-* (via stardict.eclass). # Bug #905901. Removal on 2023-06-11 app-text/sdcv # Matt Turner (2023-05-11) # Dictionaries for app-text/stardict which is masked for removal. # Bug #905901. Removal on 2023-06-11 app-dicts/stardict-cdict-en-zh-big5 app-dicts/stardict-cdict-en-zh-gb app-dicts/stardict-cedict-zh-en-big5 app-dicts/stardict-cedict-zh-en-gb app-dicts/stardict-dictd-devils app-dicts/stardict-freedict-eng-deu app-dicts/stardict-freedict-eng-fra app-dicts/stardict-freedict-eng-ita app-dicts/stardict-freedict-eng-lat app-dicts/stardict-freedict-eng-rus app-dicts/stardict-freedict-eng-spa app-dicts/stardict-freedict-eng-swe app-dicts/stardict-freedict-eng-tur app-dicts/stardict-freedict-tur-deu app-dicts/stardict-freedict-tur-eng app-dicts/stardict-jmdict-en-ja app-dicts/stardict-jmdict-ja-en app-dicts/stardict-langdao-en-zh-gb app-dicts/stardict-langdao-zh-en-gb app-dicts/stardict-mova-smiley app-dicts/stardict-oxford-en-zh-gb app-dicts/stardict-quick-eng-jpn app-dicts/stardict-quick-jpn-eng app-dicts/stardict-quick-ru-en app-dicts/stardict-xdict-en-zh-big5 app-dicts/stardict-xdict-en-zh-gb app-dicts/stardict-xdict-zh-en-big5 app-dicts/stardict-xdict-zh-en-gb # Matt Turner (2023-05-11) # Depends on many deprecated packages, such as # - app-text/enchant:0 # - app-text/gnome-doc-utils # - gnome-extra/gucharmap:0 # - x11-libs/gtk+:2 # No reverse dependencies. # Bug #905901. Removal on 2023-06-11 app-text/stardict signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2] 2023-05-08-openssh-configuration-changes: add item
On Mon, May 8, 2023 at 1:04 PM Ulrich Mueller wrote: > > > On Mon, 08 May 2023, Sam James wrote: > > > +++ > > b/2023-05-08-openssh-configuration-changes/2023-05-08-openssh-configuration-changes.en.txt > > https://www.gentoo.org/glep/glep-0042.html#news-item-identities > "This identifier will be in the form -mm-dd-short-name [...]. > The short-name is a very short name describing the news item > (e.g. yoursql-updates) [...]. While there is no hard restriction on > the length of short-name, limiting it to 20 characters is strongly > recommended." But why? We're not concerned about file system limits, are we?
[gentoo-dev] Last Rites: net-irc/kvirc
# Matt Turner (2023-05-08) # Package is unmaintained and appears quite dead (e.g. SSL certificate for the # homepage expired in 2021). Only version is a snapshot from 2021. No Python # 3.11 support. Depends on app-text/enchant:0. # Bug #905955. Removal on 2023-06-08 net-irc/kvirc signature.asc Description: PGP signature
[gentoo-dev] Last Rites: net-im/mcabber
# Matt Turner (2023-05-08) # Package is unmaintained and appears quite dead. Last release in 2020. Broken # with stable glib-2.76. Depends on app-text/enchant:0. # Bug #905954. Removal on 2023-06-08 net-im/mcabber signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EGO_SUM
On Tue, May 2, 2023 at 3:33 PM Florian Schmaus wrote: > I performed a tree-wide analysis regarding EGO_SUM and IIRC published > the results in my previous post about EGO_SUM last year. > https://dev.gentoo.org/~flow/ego_sum-2022-01-01.txt shows the analysis > results for ::gentoo as of 2022-01-01 (I've recently updated the file to > contain the Manifest-size too). > > Minikube (#833478) and k3s (#833477) appear there, too, with > package-directory sizes over one MiB. However, those packages are under > the top five of packages using EGO_SUM by package-directory size. > > They do not represent the average Go package. > > The mean size of a Manifest of a package using EGO_SUM was 186 KiB, and > the median was even lower at 84 KiB. Only a tiny percentage of packages, > below 5%, had a Manifest-size above one MiB. It sounds like you've identified a compelling rationale for a Manifest size limit.
Re: [gentoo-dev] Re: EGO_SUM
On Wed, Apr 26, 2023 at 3:31 PM Andrew Ammerlaan wrote: > > On 26/04/2023 18:12, Matt Turner wrote: > > On Wed, Apr 26, 2023 at 11:31 AM Florian Schmaus wrote: > >> The discussion would be more productive if someone who is supporting the > >> EGO_SUM deprecation could rationally summarize the main arguments why we > >> deprecated EGO_SUM. > > > > You're requesting the changes. It's on you to read the previous > > threads and try to understand. It's not others' responsibilities to > > justify the status quo to you, but tl;dr is Manifest files grew to > > insane sizes for golang packages with many dependencies, and the > > Manifest size is a cost all Gentoo users pay regardless of whether > > they use the package. > > > > This is a valid point and I think it is clear. What is not clear however > is why the EGO_SUM method should be dropped entirely instead of keeping > it as an option for overlays (with an appropriate warning). As I > remember this is where the discussion got 'stuck' last time. > > There are other cases where things are possible but prohibited in > ::gentoo by policy. E.g. the acct-user eclass allows setting > ACCT_USER_ID to -1 for dynamic assignment, but we do not allow this in > ::gentoo. I don't see why we could not do the same for EGO_SUM, keep it > as an option, while disallowing it in ::gentoo. I suspect allowing it unrestricted in overlays is fine—which seems to be the major practical issue that spurred this thread. Sam suggested a requirement for a maximum Manifest size (presumably thinking about ::gentoo), and Florian replied: > Asking to impose an artificial limit is based on the same unfounded > belief under which EGO_SUM was deprecated in the first place. I am > worried that if we follow this, then a potential next step is to argue > about adding packages to ::gentoo. So I think that's where the disagreement is.
[gentoo-dev] Last Rites: x11-apps/scripts
# Matt Turner (2023-04-26) # Package contains only a script that runs an X application on a remote system # with rsh (use ssh -Y instead), and two scripts that were probably used for # converting the old BDF fonts to XLFD names back in the early 90's. None of # these are useful today. # Removal on 2023-05-26 x11-apps/scripts signature.asc Description: PGP signature
[gentoo-dev] Re: EGO_SUM
On Wed, Apr 26, 2023 at 11:31 AM Florian Schmaus wrote: > The discussion would be more productive if someone who is supporting the > EGO_SUM deprecation could rationally summarize the main arguments why we > deprecated EGO_SUM. You're requesting the changes. It's on you to read the previous threads and try to understand. It's not others' responsibilities to justify the status quo to you, but tl;dr is Manifest files grew to insane sizes for golang packages with many dependencies, and the Manifest size is a cost all Gentoo users pay regardless of whether they use the package.
[gentoo-dev] Last Rites: x11-libs/libdmx
# Matt Turner (2023-04-10) # DMX support was dropped from the Xserver in v21.1.0 and had been broken for # 14 years previous to its removal. See # https://cgit.freedesktop.org/xorg/xserver/commit/?id=b3b81c8c2090cd49410960a021baf0d27fdd2ab3 # Removal on 2023-05-10 x11-libs/libdmx signature.asc Description: PGP signature
[gentoo-dev] Last Rites: media-fonts/font-bitstream-speedo
# Matt Turner (2023-04-10) # speedo support was dropped from libXfont ~14 years ago. See # https://www.x.org/wiki/DeprecatedInX11R7/ # https://gitlab.freedesktop.org/xorg/lib/libxfont/-/commit/85b66b8a7f3095f10437c8ecb3dcbfe68c9cfced # Removal on 2023-05-10 media-fonts/font-bitstream-speedo signature.asc Description: PGP signature
[gentoo-dev] [PATCH 3/3] gnome.org.eclass: Handle GNOME's .alpha/.beta/.rc versioning
Tested by removing SRC_URI and S overrides in evince-44_rc.ebuild and
glib-networking-2.76_beta.ebuild and confirming that we fetch the same
distfile and build from the same source directory.
Also confirmed that (alpha|beta|rc). works by making a
glib-networking-2.76_beta1.ebuild and seeing that we attempt to fetch
glib-networking-2.76.beta.1.tar.xz.
Signed-off-by: Matt Turner
---
eclass/gnome.org.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/gnome.org.eclass b/eclass/gnome.org.eclass
index d5f9102e5818..760dc2ba0b66 100644
--- a/eclass/gnome.org.eclass
+++ b/eclass/gnome.org.eclass
@@ -64,8 +64,8 @@ fi
# See https://discourse.gnome.org/t/new-gnome-versioning-scheme/4235
: "${GNOME_ORG_PV:=$(ver_rs 1- .)}"
-SRC_URI="mirror://gnome/sources/${GNOME_ORG_MODULE}/${GNOME_ORG_RELEASE}/${GNOME_ORG_MODULE}-${PV}.tar.${GNOME_TARBALL_SUFFIX}"
+SRC_URI="mirror://gnome/sources/${GNOME_ORG_MODULE}/${GNOME_ORG_RELEASE}/${GNOME_ORG_MODULE}-${GNOME_ORG_PV}.tar.${GNOME_TARBALL_SUFFIX}"
-S="${WORKDIR}/${GNOME_ORG_MODULE}-${PV}"
+S="${WORKDIR}/${GNOME_ORG_MODULE}-${GNOME_ORG_PV}"
fi
--
2.39.2
[gentoo-dev] [PATCH 2/3] gnome.org.eclass: Add GNOME_ORG_PV variable
Provides the package version in the format used upstream by GNOME
projects.
Signed-off-by: Matt Turner
---
eclass/gnome.org.eclass | 7 +++
1 file changed, 7 insertions(+)
diff --git a/eclass/gnome.org.eclass b/eclass/gnome.org.eclass
index 2add88ef59f7..d5f9102e5818 100644
--- a/eclass/gnome.org.eclass
+++ b/eclass/gnome.org.eclass
@@ -57,6 +57,13 @@ else
: "${GNOME_ORG_RELEASE:=$(ver_cut 1-2)}"
fi
+# @ECLASS_VARIABLE: GNOME_ORG_PV
+# @DESCRIPTION:
+# PV in the GNOME version scheme format.
+# The package version in the format used upstream by GNOME projects.
+# See https://discourse.gnome.org/t/new-gnome-versioning-scheme/4235
+: "${GNOME_ORG_PV:=$(ver_rs 1- .)}"
+
SRC_URI="mirror://gnome/sources/${GNOME_ORG_MODULE}/${GNOME_ORG_RELEASE}/${GNOME_ORG_MODULE}-${PV}.tar.${GNOME_TARBALL_SUFFIX}"
S="${WORKDIR}/${GNOME_ORG_MODULE}-${PV}"
--
2.39.2
[gentoo-dev] [PATCH 1/3] gnome.org.eclass: Rename GNOME_ORG_PVP -> GNOME_ORG_RELEASE
I don't think PVP stood for anything.
Signed-off-by: Matt Turner
---
eclass/gnome.org.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/gnome.org.eclass b/eclass/gnome.org.eclass
index 99b0090fda7c..2add88ef59f7 100644
--- a/eclass/gnome.org.eclass
+++ b/eclass/gnome.org.eclass
@@ -47,17 +47,17 @@ fi
# Leave unset if package name matches module name.
: "${GNOME_ORG_MODULE:=$PN}"
-# @ECLASS_VARIABLE: GNOME_ORG_PVP
+# @ECLASS_VARIABLE: GNOME_ORG_RELEASE
# @INTERNAL
# @DESCRIPTION:
# Components of the version number that correspond to a 6 month release.
if ver_test -ge 40.0; then
- : "${GNOME_ORG_PVP:=$(ver_cut 1)}"
+ : "${GNOME_ORG_RELEASE:=$(ver_cut 1)}"
else
- : "${GNOME_ORG_PVP:=$(ver_cut 1-2)}"
+ : "${GNOME_ORG_RELEASE:=$(ver_cut 1-2)}"
fi
-SRC_URI="mirror://gnome/sources/${GNOME_ORG_MODULE}/${GNOME_ORG_PVP}/${GNOME_ORG_MODULE}-${PV}.tar.${GNOME_TARBALL_SUFFIX}"
+SRC_URI="mirror://gnome/sources/${GNOME_ORG_MODULE}/${GNOME_ORG_RELEASE}/${GNOME_ORG_MODULE}-${PV}.tar.${GNOME_TARBALL_SUFFIX}"
S="${WORKDIR}/${GNOME_ORG_MODULE}-${PV}"
--
2.39.2
[gentoo-dev] Last Rites: net-libs/libgfbgraph, net-libs/libzapojit, net-misc/gnome-online-miners
# Matt Turner (2023-03-30) # gnome-online-miners and libzapojit are archived upstream. All three packages # are stuck on libsoup-2.4. gnome-photos is the only reverse dependency of # gnome-online-miners, and it works without it. # Removal on 2023-04-30. net-libs/libgfbgraph net-libs/libzapojit net-misc/gnome-online-miners signature.asc Description: PGP signature
[gentoo-dev] [PATCH] gnome.org.eclass: Handle GNOME's .alpha/.beta/.rc versioning
Signed-off-by: Matt Turner
---
eclass/gnome.org.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/gnome.org.eclass b/eclass/gnome.org.eclass
index 05025f5f58fa..215c9be3f043 100644
--- a/eclass/gnome.org.eclass
+++ b/eclass/gnome.org.eclass
@@ -57,8 +57,8 @@ else
: ${GNOME_ORG_PVP:=$(ver_cut 1-2)}
fi
-SRC_URI="mirror://gnome/sources/${GNOME_ORG_MODULE}/${GNOME_ORG_PVP}/${GNOME_ORG_MODULE}-${PV}.tar.${GNOME_TARBALL_SUFFIX}"
+SRC_URI="mirror://gnome/sources/${GNOME_ORG_MODULE}/${GNOME_ORG_PVP}/${GNOME_ORG_MODULE}-${PV/_/.}.tar.${GNOME_TARBALL_SUFFIX}"
-S="${WORKDIR}/${GNOME_ORG_MODULE}-${PV}"
+S="${WORKDIR}/${GNOME_ORG_MODULE}-${PV/_/.}"
fi
--
2.39.2
[gentoo-dev] Last Rites: x11-apps/xdbedizzy and x11-apps/xf86dga
# Matt Turner (2023-03-04) # Test applications that don't really have any business being packaged. # Removal on 2023-04-04. x11-apps/xdbedizzy x11-apps/xf86dga signature.asc Description: PGP signature
[gentoo-dev] Last Rites: gnome-base/gconf and gnome-extra/gconf-editor
# Matt Turner (2023-03-04) # Long deprecated, GNOME 2-era packages. # Removal on 2023-04-04. Bug #873841 gnome-base/gconf gnome-extra/gconf-editor signature.asc Description: PGP signature
[gentoo-dev] Last Rites: app-office/upwork
# Matt Turner (2023-03-03) # No commits from maintainer in more than two years. Downloads are broken for # 18 months (bug #809551), depends on deprecated gconf (bug #873856) # Removal on 2023-04-03. Bug #873856 app-office/upwork signature.asc Description: PGP signature
[gentoo-dev] Last Rites: gnome-extra/seahorse-nautilus and x11-libs/libcryptui
# Matt Turner (2023-02-25) # Packages are unmaintained and archived upstream. # Removal on 2023-03-27. Bug #897748 gnome-extra/seahorse-nautilus x11-libs/libcryptui signature.asc Description: PGP signature
[gentoo-dev] Last Rites: sys-fs/genfstab
# Matt Turner (2023-02-23) # Added by proxied maintainer who then quit (twice) and deleted the github repo # SRC_URI pointed at. # Removal on 2023-03-23. sys-fs/genfstab signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass: add glib-compile-resources
On Thu, Feb 2, 2023 at 5:24 PM uis wrote: > > This is part of patch for bug 779871. > Added GLIB_COMPILE_RESOURCES path here near GLIB_COMPILE_SCHEMAS. > Also removed @INTERNAL for GLIB_COMPILE_SCHEMAS because it is already used > outside of gnome2-utils. Looks good to me. I can write a commit message and push this, but it would be nice to get your Signed-off-by tag. See https://www.gentoo.org/glep/glep-0076.html
[gentoo-dev] Last rites: media-gfx/colorhug-client
# Matt Turner (2022-12-21) # Archived upstream, now that fwupd can handle updates. # Removal on 2023-01-20. media-gfx/colorhug-client signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-cpp/atkmm:2.36
# Matt Turner (2022-12-21) # No reverse dependencies. GTK 4 doesn't use it. # See https://gitlab.gnome.org/GNOME/atkmm/-/issues/4 # Removal on 2023-01-20. dev-cpp/atkmm:2.36 signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: www-servers/boa
On Fri, Dec 2, 2022 at 12:20 PM Peter Stuge wrote: > If you wanted to encourage me to become a Gentoo developer and (among > other things) improve the lastriting process then you missed the mark, > in fact your behavior consistently remains one strong reason for me > to *not* become a Gentoo developer. I doubt that's the most significant thing standing in the way.
Re: [gentoo-portage-dev] [PATCH 2/2] Add caching to _slot_operator_check_reverse_dependencies
On Thu, Nov 24, 2022 at 10:36 PM Pin-yen Lin wrote: > > Add lru_cache to speed up the running time of "Calculating > dependencies". > > In a ChromeOS use case, this patch decreases the running time from > 311s to 197s with almost no memory usage increase. > > Signed-off-by: Pin-yen Lin Thank you! With recent subslot rebuilds (icu, boost, poppler), I measure an improvement of 19%! Benchmark 1: emerge @world -vuNDp Time (mean ± σ): 42.668 s ± 0.555 s[User: 42.095 s, System: 0.315 s] Range (min … max): 41.572 s … 43.342 s10 runs Benchmark 2: emerge @world -vuNDp Time (mean ± σ): 35.991 s ± 0.154 s[User: 35.409 s, System: 0.332 s] Range (min … max): 35.831 s … 36.306 s10 runs Summary 'emerge @world -vuNDp' ran 1.19 ± 0.02 times faster than 'emerge @world -vuNDp'
[gentoo-dev] Packages up for grabs: telepathy related packages
GNOME 43 will no longer need these packages. They seem to be in varying states of decay upstream. - net-im/telepathy-connection-managers - net-libs/farstream - net-libs/sofia-sip - net-libs/telepathy-farstream - net-voip/telepathy-gabble - net-voip/telepathy-rakia - net-voip/telepathy-salut These are maintained upstream, but GNOME 43 doesn't need them. gstreamer@ was a backup (and is now the primary) maintainer of media-plugins/gst-plugins-libnice, so it should probably take over net-libs/libnice as well. - media-plugins/gst-plugins-libnice - net-libs/libnice I've dropped gnome@ as a maintainer of all of these packages. signature.asc Description: PGP signature
[gentoo-dev] [PATCH] targets: Drop /etc/asound.state creation
alsa creates this file at runtime at /var/lib/alsa/asound.state in
modern times.
Signed-off-by: Matt Turner
---
targets/support/livecdfs-update.sh | 3 ---
1 file changed, 3 deletions(-)
diff --git a/targets/support/livecdfs-update.sh
b/targets/support/livecdfs-update.sh
index e750e785..251a6887 100755
--- a/targets/support/livecdfs-update.sh
+++ b/targets/support/livecdfs-update.sh
@@ -125,9 +125,6 @@ then
http://www.linux-usb.org/usb.ids
fi
-# touch /etc/asound.state
-touch /etc/asound.state
-
# Tweak the MOTD for Gentoo releases
case ${clst_livecd_type} in
gentoo-release-universal)
--
2.37.4
[gentoo-dev] [PATCH 5/5] catalyst: Drop livecd/{xinitrc,xsession,xdm}
This is functionality better implemented in fsscripts outside of catalyst. Signed-off-by: Matt Turner --- catalyst/targets/livecd_stage2.py| 3 -- doc/catalyst-spec.5.txt | 20 - examples/livecd-stage2_template.spec | 24 --- examples/stage4_template.spec| 10 - livecd/files/livecd.motd.txt | 3 -- targets/livecd-stage2/controller.sh | 9 targets/stage4/controller.sh | 8 targets/support/livecdfs-update.sh | 63 +--- 8 files changed, 1 insertion(+), 139 deletions(-) diff --git a/catalyst/targets/livecd_stage2.py b/catalyst/targets/livecd_stage2.py index 832e0998..1a798a1e 100644 --- a/catalyst/targets/livecd_stage2.py +++ b/catalyst/targets/livecd_stage2.py @@ -39,9 +39,6 @@ class livecd_stage2(StageBase): "livecd/users", "livecd/verify", "livecd/volid", -"livecd/xdm", -"livecd/xinitrc", -"livecd/xsession", "repos", ]) diff --git a/doc/catalyst-spec.5.txt b/doc/catalyst-spec.5.txt index f6251597..1abf9efb 100644 --- a/doc/catalyst-spec.5.txt +++ b/doc/catalyst-spec.5.txt @@ -395,26 +395,6 @@ This is typically used for adding the documentation, distfiles, snapshots, and stages to the official media. These files will not be available if `docache` is enabled, as they are outside the loop. -*/xinitrc*:: -This is used by catalyst to copy the specified file to -`/etc/X11/xinit/xinitrc` and is used by the */type* -`generic-livecd`. While the file will still be copied for any -*/type*, catalyst will only create the necessary `/etc/startx` -for those types, so X will not be automatically started. This is -useful also for setting up X on a CD where you do not wish X to start -automatically. We do not use this on the release media. This setting -is supported by the `stage4` and `livecd` targets. - -*livecd/xdm*:: -This is used by catalyst to determine which display manager you wish -to become the default (example: `gdm`). This is used on the official -Gentoo LiveCD and is valid for any `livecd/type`. - -*livecd/xsession*:: -This is used by catalyst to determine which X session should be -started by default by the display manager (example: `gnome`). This is -used on the official Gentoo LiveCD and is valid for any livecd/type. - */users*:: This option is used to create non-root users on your target. It takes a space separated list of user names. These users will be added to diff --git a/examples/livecd-stage2_template.spec b/examples/livecd-stage2_template.spec index 8e179b73..efbc6d82 100644 --- a/examples/livecd-stage2_template.spec +++ b/examples/livecd-stage2_template.spec @@ -202,30 +202,6 @@ livecd/overlay: # livecd/root_overlay: livecd/root_overlay: -# This is used by catalyst to copy the specified file to /etc/X11/xinit/xinitrc -# and is used by the livecd/type and generic-livecd. While the file will still -# be copied for any livecd/type, catalyst will only create the necessary -# /etc/startx for those types, so X will not be automatically started. This is -# useful also for setting up X on a CD where you do not wish X to start -# automatically. We do not use this on the release media, so it is left blank. -# example: -# livecd/xinitrc: -livecd/xinitrc: - -# This is used by catalyst to determine which display manager you wish to -# become the default. This is used on the official Gentoo LiveCD and is valid -# for any livecd/type. -# example: -# livecd/xdm: gdm -livecd/xdm: - -# This is used by catalyst to determine which X session should be started by -# default by the display manager. This is used on the official Gentoo LiveCD -# and is valid for any livecd/type. -# example: -# livecd/xsession: gnome -livecd/xsession: - # This option is used to create non-root users on your CD. It takes a space # separated list of user names. These users will be added to the following # groups: users,wheel,audio,games,cdrom,usb diff --git a/examples/stage4_template.spec b/examples/stage4_template.spec index 5d9a390c..a7a3e766 100644 --- a/examples/stage4_template.spec +++ b/examples/stage4_template.spec @@ -161,16 +161,6 @@ stage4/rcdel: # stage4/root_overlay: stage4/root_overlay: -# This is used by catalyst to copy the specified file to /etc/X11/xinit/xinitrc -# and is used by the stage4/type generic-livecd. While the file will still be -# copied for any stage4/type, catalyst will only create the necessary -# /etc/startx for those types, so X will not be automatically started. This is -# useful also for setting up X on a CD where you do not wish X to start -# automatically. We do not use this on the release media, so it is left blank. -# example: -# stage4/xinitrc: -stage4/xinitrc: - # This option is used to create groups. It takes a carriage-return separated # list of group names. For instance: # stage4/groups: diff --git a/livecd/files/l
[gentoo-dev] [PATCH 4/5] targets: Remove openglify usage
This script was removed from livecd-tools in commit 8e2a9c0 ("remove
openglify") in 2011.
Signed-off-by: Matt Turner
---
targets/support/livecdfs-update.sh | 3 ---
1 file changed, 3 deletions(-)
diff --git a/targets/support/livecdfs-update.sh
b/targets/support/livecdfs-update.sh
index b7548347..64a9e4b2 100755
--- a/targets/support/livecdfs-update.sh
+++ b/targets/support/livecdfs-update.sh
@@ -131,9 +131,6 @@ then
http://www.linux-usb.org/usb.ids
fi
-# Setup opengl in /etc (if configured)
-[ -x /usr/sbin/openglify ] && /usr/sbin/openglify
-
# Setup configured display manager
if [ -n "${clst_livecd_xdm}" ]
then
--
2.37.4
[gentoo-dev] [PATCH 3/5] targets: Remove gconf usage
Bug: https://bugs.gentoo.org/873841
Signed-off-by: Matt Turner
---
livecd/files/livecd-local.start| 5 -
targets/support/livecdfs-update.sh | 24
2 files changed, 29 deletions(-)
diff --git a/livecd/files/livecd-local.start b/livecd/files/livecd-local.start
index 3615569c..a7bb2bef 100644
--- a/livecd/files/livecd-local.start
+++ b/livecd/files/livecd-local.start
@@ -4,11 +4,6 @@
# This is a good place to load any misc.
# programs on startup ( 1>&2 )
-#if [ -d /usr/livecd/gconf ]
-#then
-# ln -sf /usr/livecd/gconf /etc/gconf
-#fi
-
#if [ -d /usr/livecd/db ]
#then
# ln -sf /usr/livecd/db /var/db
diff --git a/targets/support/livecdfs-update.sh
b/targets/support/livecdfs-update.sh
index cf2cf62f..b7548347 100755
--- a/targets/support/livecdfs-update.sh
+++ b/targets/support/livecdfs-update.sh
@@ -178,19 +178,6 @@ rm -f /etc/generic.motd.txt /etc/universal.motd.txt
/etc/minimal.motd.txt /etc/l
# Post configuration
case ${clst_livecd_type} in
gentoo-release-live*)
- # Setup Gnome theme
- if [ "${clst_livecd_xsession}" == "gnome" ]
- then
- gconftool-2 --direct \
- --config-source
xml:readwrite:/etc/gconf/gconf.xml.defaults \
- --type string --set
/desktop/gnome/interface/font_name "Sans 9"
- fi
-
- # Remove locking on screensaver
- gconftool-2 --direct \
-
--config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s \
- -t bool /apps/gnome-screensaver/lock_enabled false
>/dev/null
-
# Setup GDM
if [ "${clst_livecd_xdm}" == "gdm" ]
then
@@ -232,8 +219,6 @@ case ${clst_livecd_type} in
mkdir -p /usr/livecd
cp -r ${clst_repo_basedir}/${clst_repo_name}/{profiles,eclass}
/usr/livecd
rm -rf
/usr/livecd/profiles/{co*,default-{1*,a*,b*,d*,h*,i*,m*,p*,s*,x*},g*,hardened-*,n*,x*}
- mv -f /etc/gconf /usr/livecd
- ln -sf /usr/livecd/gconf /etc/gconf
mv -f /var/db /usr/livecd
ln -sf /usr/livecd/db /var/db
@@ -274,15 +259,6 @@ case ${clst_livecd_type} in
fi
;;
generic-livecd )
- # This is my hack to reduce tmpfs usage
- mkdir -p /usr/livecd
-
- if [ -d /etc/gconf ]
- then
- mv -f /etc/gconf /usr/livecd
- ln -sf /usr/livecd/gconf /etc/gconf
- fi
-
touch /etc/startx
;;
esac
--
2.37.4
[gentoo-dev] [PATCH 2/5] targets: Remove remnants of support for the installer
Signed-off-by: Matt Turner
---
livecd/files/livecd.motd.txt | 2 --
targets/support/livecdfs-update.sh | 16 +---
2 files changed, 1 insertion(+), 17 deletions(-)
diff --git a/livecd/files/livecd.motd.txt b/livecd/files/livecd.motd.txt
index fe4c0918..9f8e2396 100644
--- a/livecd/files/livecd.motd.txt
+++ b/livecd/files/livecd.motd.txt
@@ -1,8 +1,6 @@
To (re)start X Windows, please type "##DISPLAY_MANAGER" at the prompt below.
There is also a rescue session for X using twm if you simply use "startx".
-You can start the installer by typing "installer" at the prompt below.
-
Please report any bugs you find to https://bugs.gentoo.org. Be sure to include
detailed information about how to reproduce the bug you are reporting.
diff --git a/targets/support/livecdfs-update.sh
b/targets/support/livecdfs-update.sh
index 3f47012b..cf2cf62f 100755
--- a/targets/support/livecdfs-update.sh
+++ b/targets/support/livecdfs-update.sh
@@ -228,12 +228,8 @@ case ${clst_livecd_type} in
fi
fi
- # This gives us our list of system packages for the installer
- mkdir -p /usr/livecd
- ### XXX: Andrew says we don't need this anymore
- USE="-* $(cat /var/db/pkg/sys-libs/glibc*/USE)" emerge -eqp
@system | grep -e '^\[ebuild' | sed -e 's:^\[ebuild .\+\] ::' -e 's: .\+$::' >
/usr/livecd/systempkgs.txt
-
# This is my hack to reduce tmpfs usage
+ mkdir -p /usr/livecd
cp -r ${clst_repo_basedir}/${clst_repo_name}/{profiles,eclass}
/usr/livecd
rm -rf
/usr/livecd/profiles/{co*,default-{1*,a*,b*,d*,h*,i*,m*,p*,s*,x*},g*,hardened-*,n*,x*}
mv -f /etc/gconf /usr/livecd
@@ -273,16 +269,6 @@ case ${clst_livecd_type} in
[ -e
/usr/share/applications/gentoo-handbook.desktop ] && \
cp -f
/usr/share/applications/gentoo-handbook.desktop \
/home/${username}/Desktop
- # Copy our installer icons
- if [ -e
/usr/share/applications/installer-gtk.desktop ]
- then
- cp -f
/usr/share/applications/installer-{gtk,dialog}.desktop /home/${username}/Desktop
- sed -i -e \
-
's:Exec=installer-dialog:Exec=sudo installer-dialog:' \
-
/home/${username}/Desktop/installer-dialog.desktop
- sed -i -e
's:Exec=installer-gtk:Exec=installer:' \
-
/home/${username}/Desktop/installer-gtk.desktop
- fi
chown -R ${username}:100 /home/${username}
done
fi
--
2.37.4
[gentoo-dev] [PATCH 1/5] targets: Fix enabling PermitRootLogin
The default changed to "prohibit-password" many moons ago, so our ISOs would not have allowed root logins if not for net-misc/openssh's IUSE=livecd, which handles this in the ebuild. Let's go ahead and fix it, so that we can consider removing openssh's livecd USE flag which would allow us to avoid rebuilding the package for the ISO. Signed-off-by: Matt Turner --- targets/support/livecdfs-update.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/targets/support/livecdfs-update.sh b/targets/support/livecdfs-update.sh index b7ead552..3f47012b 100755 --- a/targets/support/livecdfs-update.sh +++ b/targets/support/livecdfs-update.sh @@ -7,7 +7,8 @@ source /tmp/chroot-functions.sh # Allow root logins to our CD by default if [ -e /etc/ssh/sshd_config ] then - sed -i 's:^#PermitRootLogin\ yes:PermitRootLogin\ yes:' \ + sed -i \ + -e '/^#PermitRootLogin/c# Allow root login with password on livecds.\nPermitRootLogin Yes' \ /etc/ssh/sshd_config fi -- 2.37.4
[gentoo-dev] Last Rites: x11-misc/xnee
# Matt Turner (2022-11-14) # Unmaintained in Gentoo since at least the transition to git. Last release in # 2014. Depends on x11-libs/gtk+:2 and gnome-base/gconf. Fails to build with # (1) clang-16, (2) with LTO, (3) with -fno-common. # Bugs #812137, #864763, #871405, #873886 # Removal on 2022-12-14 x11-misc/xnee signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 2/2] font.eclass: Remove racy pkg_postinst code
On Mon, Nov 7, 2022 at 11:11 PM Sam James wrote:
>
>
>
> > On 8 Nov 2022, at 01:10, Matt Turner wrote:
> >
> > Noticed on ChromeOS when installing a large number of font packages in
> > parallel:
> >
> > /usr/share/fonts/noto/NotoSerifThai-Regular.ttf#new' from 0004 (--r--)
> > to 2440 (r--r-S---)
> > * ERROR: media-fonts/ipaex-004.01-r1::chromiumos failed (postinst phase):
> > * failed to fix font files perms
> >
> > The "#new" filename is the hint. Portage uses "#new" suffixes when
> > copying files to the system, and then renames them to their final
> > filenames.
> >
> > This code was executing while another font was in the process of being
> > copied to the system. Font packages should just ensure that they install
> > files with correct permissions to begin with, and all except
> > media-fonts/x11fonts-jmk already use 0644 permissions.
> > media-fonts/x11fonts-jmk used 0444 (which was probably fine) until the
> > previous commit which changes its installed files to 0644.
> >
> > Bug: https://bugs.gentoo.org/187774
> > Signed-off-by: Matt Turner
> > ---
> > eclass/font.eclass | 6 --
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/eclass/font.eclass b/eclass/font.eclass
> > index 4970c959f7c..0196755ce3e 100644
> > --- a/eclass/font.eclass
> > +++ b/eclass/font.eclass
> > @@ -186,12 +186,6 @@ font_src_install() {
> > # @DESCRIPTION:
> > # Updates fontcache if !prefix and media-libs/fontconfig installed
> > _update_fontcache() {
> > - if [[ -d "${EROOT}"/usr/share/fonts ]] ; then
> > - # unreadable font files = fontconfig segfaults
> > - find "${EROOT}"/usr/share/fonts/ -type f '!' -perm 0644 \
> > - -exec chmod -v 0644 2>/dev/null {} + || die "failed to fix font files
> > perms"
> > - fi
> > -
> > if [[ -z ${ROOT} ]] ; then
> > if has_version media-libs/fontconfig ; then
> > ebegin "Updating global fontcache"
> > --
>
> Can we put an fperms call in src_install just in case (like the eclass
> originally had
> before moved to pkg_postinst)?
We can if you think it's necessary, but to be honest I think that the
original bug should have been WONTFIX. The user was manually
installing fonts into their system and then complained that things
didn't work when they configured the fonts with the wrong permissions.
I don't think fonts getting installed with unreadable permissions is a
real problem.
[gentoo-dev] [PATCH 2/2] font.eclass: Remove racy pkg_postinst code
Noticed on ChromeOS when installing a large number of font packages in
parallel:
/usr/share/fonts/noto/NotoSerifThai-Regular.ttf#new' from 0004 (--r--) to
2440 (r--r-S---)
* ERROR: media-fonts/ipaex-004.01-r1::chromiumos failed (postinst phase):
* failed to fix font files perms
The "#new" filename is the hint. Portage uses "#new" suffixes when
copying files to the system, and then renames them to their final
filenames.
This code was executing while another font was in the process of being
copied to the system. Font packages should just ensure that they install
files with correct permissions to begin with, and all except
media-fonts/x11fonts-jmk already use 0644 permissions.
media-fonts/x11fonts-jmk used 0444 (which was probably fine) until the
previous commit which changes its installed files to 0644.
Bug: https://bugs.gentoo.org/187774
Signed-off-by: Matt Turner
---
eclass/font.eclass | 6 --
1 file changed, 6 deletions(-)
diff --git a/eclass/font.eclass b/eclass/font.eclass
index 4970c959f7c..0196755ce3e 100644
--- a/eclass/font.eclass
+++ b/eclass/font.eclass
@@ -186,12 +186,6 @@ font_src_install() {
# @DESCRIPTION:
# Updates fontcache if !prefix and media-libs/fontconfig installed
_update_fontcache() {
- if [[ -d "${EROOT}"/usr/share/fonts ]] ; then
- # unreadable font files = fontconfig segfaults
- find "${EROOT}"/usr/share/fonts/ -type f '!' -perm 0644 \
- -exec chmod -v 0644 2>/dev/null {} + || die "failed to
fix font files perms"
- fi
-
if [[ -z ${ROOT} ]] ; then
if has_version media-libs/fontconfig ; then
ebegin "Updating global fontcache"
--
2.37.4
[gentoo-dev] [PATCH 1/2] media-fonts/x11fonts-jmk: Install files with 0644 permissions
font.eclass has some racy code in pkg_postinst() that changes
permissions of already-installed files. I want to remove that to avoid
the race. This is the only package that installs fonts with permissions
other than 0644, so override that in src_install().
The claim in font.eclass is that fontconfig segfaults if fonts are
unreadable, but that claim dates to 2007 (bug #187774). Additionally,
0444 is readable, but who knows. Let's just keep things working how they
have been since 2007.
Bug: https://bugs.gentoo.org/187774
Signed-off-by: Matt Turner
---
media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild
b/media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild
index 70ad93064b5..f24d067c412 100644
--- a/media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild
+++ b/media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild
@@ -32,6 +32,6 @@ src_configure() {
}
src_install() {
- emake install INSTALL_DIR="${ED}/usr/share/fonts/jmk"
+ emake install INSTDATFLAGS="-m 0644"
INSTALL_DIR="${ED}/usr/share/fonts/jmk"
einstalldocs
}
--
2.37.4
[gentoo-dev] Looking for dedicated ModemManager maintainer
The following packages are currently maintained by GNOME for no real reason other than they're a dependency of networkmanager: net-misc/modemmanager net-libs/libmbim net-libs/libqmi net-libs/libqrtr-glib But I don't have any ability to test them. I'd really appreciate a dedicated maintainer take them over—someone who can actually test the packages. The packages appear to be in good shape. Recently-released versions have switched to meson, and I've made a PR here [0] for libmbim and libqmi. (In the same vein I wouldn't mind someone taking over NetworkManager...) Someone lighten my load, please? [0] https://github.com/gentoo/gentoo/pull/28163
[gentoo-dev] Last Rites: sci-electronics/drahnr-oregano
# Matt Turner (2022-11-01) # Added by a proxied maintainer in 2018 who then never touched it again before # disappearing. Doesn't build with Python 3.9. Depends on gnome-base/gconf. # Bugs #846233, #873877 # Removal on 2022-12-01 sci-electronics/drahnr-oregano signature.asc Description: PGP signature
[gentoo-dev] Last Rites: x11-libs/vte:0
# Matt Turner (2022-11-01) # Dead slot. No reverse dependencies that are not masked for removal. # Removal on 2022-12-01 x11-libs/gnome-pty-helper x11-libs/vte:0 signature.asc Description: PGP signature
[gentoo-dev] Last Rites: ruby-gnome packages without consumers
# Matt Turner (2022-11-01) # No reverse dependencies. Depends on deprecated and unmaintained packages: # - media-libs/clutter # - media-libs/clutter-gst # - media-libs/clutter-gtk # - x11-libs/gtksourceview:2.0 # - x11-libs/gtksourceview:3.0 # - x11-libs/gtksourceview:4 # - x11-libs/vte:0 # Bug #877153 # Removal on 2022-12-01 dev-ruby/ruby-clutter dev-ruby/ruby-clutter-gdk dev-ruby/ruby-clutter-gstreamer dev-ruby/ruby-clutter-gtk dev-ruby/ruby-gdk3 dev-ruby/ruby-gegl dev-ruby/ruby-gnome2 dev-ruby/ruby-gnumeric dev-ruby/ruby-gsf dev-ruby/ruby-gstreamer dev-ruby/ruby-gtk3 dev-ruby/ruby-gtksourceview dev-ruby/ruby-gtksourceview3 dev-ruby/ruby-gtksourceview4 dev-ruby/ruby-libsecret dev-ruby/ruby-rsvg dev-ruby/ruby-vte dev-ruby/ruby-vte3 dev-ruby/ruby-webkit2-gtk dev-ruby/ruby-wnck3 signature.asc Description: PGP signature
Re: [gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?
On Sat, Oct 29, 2022 at 12:53 PM Piotr Karbowski wrote: > > On 29/10/2022 18.22, Matt Turner wrote: > > Have you seen these commits? > > I did not, thanks. Seems like the solution. Is there a reason why llvm:N > do not pull in lld:N in that case? lld isn't a dependency of llvm; it's the same reason why llvm:N doesn't depend on clang:N.
Re: [gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?
On Sat, Oct 29, 2022 at 12:01 PM Piotr Karbowski wrote: > The state for this very moment is that we can have many versions of llvm > around, however we can at most have only one ld.lld installed. Usually > matching the lowest version of clang installed. Have you seen these commits? commit 15aad9556ba01ff38a14775dedd8ee088c27c30f Author: Michał Górny Date: Fri Oct 14 19:47:20 2022 +0200 sys-devel/lld: Enable slotting on 13.0.1 Signed-off-by: Michał Górny commit f1a40a736023a8f1be25e478ef657cf4c772306b Author: Michał Górny Date: Fri Oct 14 17:37:47 2022 +0200 sys-devel/lld: Enable slotting on 14.0.6 Signed-off-by: Michał Górny commit ea9e70d251dd711b91ac3d6da48ab09ce564f3ea Author: Michał Górny Date: Fri Oct 14 14:58:56 2022 +0200 sys-devel/lld: Enable slotting on LLD 15+ Signed-off-by: Michał Górny
[gentoo-dev] Last Rites: x11-terms/lilyterm
# Matt Turner (2022-10-14) # Last upstream release in 2013. Last upstream commit in 2019. No maintainer in # Gentoo. No reverse dependencies. EAPI=6. # Depends on unmaintained packages: # - x11-libs/vte:0 # Bug #811540. # Removal on 2022-11-14 x11-terms/lilyterm signature.asc Description: PGP signature
[gentoo-dev] Last Rites: x11-misc/gtkdialog
# Matt Turner (2022-10-14) # Unmaintained upstream with last commit in 2013. No reverse dependencies. # Depends on unmaintained packages: # - x11-libs/gtk+:2 # - x11-libs/vte:0 # Bugs #769131, #875704. # Removal on 2022-11-14 x11-misc/gtkdialog signature.asc Description: PGP signature
[gentoo-dev] Last Rites: net-libs/gnet
# Matt Turner (2022-10-14) # Unmaintained upstream. Last release in 2008. Only reverse dependency is # gnome-mud, which is masked for removal. # Bugs #349301, #713152, #802723, #808435, #870730, #877079. # Removal on 2022-11-14 net-libs/gnet signature.asc Description: PGP signature
[gentoo-dev] Last Rites: games-mud/gnome-mud
# Matt Turner (2022-10-14) # Needs upstream work to modernize codebase. Depends on lots of unmaintained # packages: # - app-text/rarian # - gnome-base/gconf # - gnome-base/libglade # - net-libs/gnet:2 # - x11-libs/gtk+:2 # - x11-libs/vte:0 # Bugs #670904, #873859 # Removal on 2022-11-14 games-mud/gnome-mud signature.asc Description: PGP signature
[gentoo-dev] Last Rites: net-im/empathy
# Matt Turner (2022-10-12) # Unmaintained and archived upstream. Last release in 2017. # Bug #597960. # Removal on 2022-11-12 net-im/empathy signature.asc Description: PGP signature
[gentoo-dev] Last Rites: x11-libs/libva-vdpau-driver
# Matt Turner (2022-10-01) # Unmaintained upstream. Last commit was 10 years ago today. # Unclear if it does anything useful. Many open bugs: #584352, #833102, # #852728, #866557, #875278. # Removal on 2022-11-05 x11-libs/libva-vdpau-driver signature.asc Description: PGP signature
[gentoo-dev] Last Rites: media-sound/gmpc and associated plugins
# Matt Turner (2022-10-01) # Depends on lots of unmaintained packages: # - app-text/gnome-doc-utils # - dev-libs/libunique:1 # - dev-util/gob # - x11-libs/gtk+:2 # Last commit to upstream repository in 2015. Most plugins saw their last # upstream commit 10+ years ago. Unmaintained in Gentoo since 2016. Many open # bugs: #582138, #686800, #689364, #721246, #799263, #808447, #808450, #808456, # #831024. # Removal on 2022-11-01 media-sound/gmpc media-plugins/gmpc-alarm media-plugins/gmpc-albumview media-plugins/gmpc-avahi media-plugins/gmpc-awn media-plugins/gmpc-discogs media-plugins/gmpc-extraplaylist media-plugins/gmpc-jamendo media-plugins/gmpc-last-fm media-plugins/gmpc-libnotify media-plugins/gmpc-lyrics media-plugins/gmpc-lyricwiki media-plugins/gmpc-magnatune media-plugins/gmpc-mdcover media-plugins/gmpc-mmkeys media-plugins/gmpc-mserver media-plugins/gmpc-playlistsort media-plugins/gmpc-shout media-plugins/gmpc-tagedit signature.asc Description: PGP signature
[gentoo-dev] Last Rites: x11-base/xorg-x11
# Matt Turner (2022-10-01) # Metapackage that has outlived its purpose. Made some sense in the immediate # aftermath of X.Org modularization 15 years ago. # Removal on 2022-11-01. Bugs #755233, #872119. x11-base/xorg-x11 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH data/xml-schema 1/2] metadata.xsd: Add gnome remote-id
On Tue, Sep 13, 2022 at 12:00 PM Michał Górny wrote: > > On Tue, 2022-09-13 at 10:36 -0400, Matt Turner wrote: > > On Tue, Sep 13, 2022 at 2:38 AM Michał Górny wrote: > > > > > > On Mon, 2022-09-12 at 20:58 -0400, Matt Turner wrote: > > > > Signed-off-by: Matt Turner > > > > --- > > > > metadata.xsd | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/metadata.xsd b/metadata.xsd > > > > index 87972cb..cced33d 100644 > > > > --- a/metadata.xsd > > > > +++ b/metadata.xsd > > > > @@ -279,6 +279,7 @@ > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > > > Some examples, please. Are these somehow "global" identifiers or > > > specific to their GitLab instances? > > > > This would be for gitlab.gnome.org. E.g. for x11-terms/gnome-terminal > > whose git repo is located at > > https://gitlab.gnome.org/GNOME/gnome-terminal.git, we'd have > > > > GNOME/gnome-terminal > > > > Similar situation for 'freedesktop' in patch 2/2, for > > gitlab.freedesktop.org. > > > > Well, then I guess I'd prefer if these were "gnome-gitlab" > and "freedesktop-gitlab" to make it clear which services the names > correspond to. Sure, will do.
Re: [gentoo-dev] [PATCH data/xml-schema 2/2] metadata.xsd: Add freedestkop remote-id
On Tue, Sep 13, 2022 at 11:09 AM Ulrich Mueller wrote: > > >>>>> On Tue, 13 Sep 2022, Matt Turner wrote: > > > > > > > > > + > > > > > > > > Alphabetical order? Oops, sorry. Yes!
Re: [gentoo-dev] [PATCH data/xml-schema 1/2] metadata.xsd: Add gnome remote-id
On Tue, Sep 13, 2022 at 2:38 AM Michał Górny wrote: > > On Mon, 2022-09-12 at 20:58 -0400, Matt Turner wrote: > > Signed-off-by: Matt Turner > > --- > > metadata.xsd | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/metadata.xsd b/metadata.xsd > > index 87972cb..cced33d 100644 > > --- a/metadata.xsd > > +++ b/metadata.xsd > > @@ -279,6 +279,7 @@ > > > > > > > > + > > > > > > > > Some examples, please. Are these somehow "global" identifiers or > specific to their GitLab instances? This would be for gitlab.gnome.org. E.g. for x11-terms/gnome-terminal whose git repo is located at https://gitlab.gnome.org/GNOME/gnome-terminal.git, we'd have GNOME/gnome-terminal Similar situation for 'freedesktop' in patch 2/2, for gitlab.freedesktop.org.
[gentoo-dev] [PATCH data/xml-schema 2/2] metadata.xsd: Add freedestkop remote-id
Signed-off-by: Matt Turner --- metadata.xsd | 1 + 1 file changed, 1 insertion(+) diff --git a/metadata.xsd b/metadata.xsd index cced33d..a8a1467 100644 --- a/metadata.xsd +++ b/metadata.xsd @@ -281,6 +281,7 @@ + -- 2.35.1
[gentoo-dev] [PATCH data/xml-schema 1/2] metadata.xsd: Add gnome remote-id
Signed-off-by: Matt Turner --- metadata.xsd | 1 + 1 file changed, 1 insertion(+) diff --git a/metadata.xsd b/metadata.xsd index 87972cb..cced33d 100644 --- a/metadata.xsd +++ b/metadata.xsd @@ -279,6 +279,7 @@ + -- 2.35.1
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
On Fri, Jul 22, 2022 at 7:57 AM Joonas Niilola wrote: > > Cross-posting to gentoo-dev and -project lists due to technical and > non-technical nature. Reply-to is set to -project. > > Once again new council has been elected: congratulations to the chosen > members! And once again many nominees expressed their wishes to see more > non-developer contributors to become official developers. Yet, only very > few people (if any) are interested in mentoring them. I get it, the > relationship between a mentor and their mentee is very intimate, and > mentoring takes a lot of time. While the Github PRs are helping us > increase the user contributions merged, perhaps it's distancing us from > creating stronger bonds with the contributors? But more about this topic > later. > > > 1st RFC: "Trusted contributor model" > > I'm proposing us to giving special commit access to our well-reputable > contributors (mostly proxied maintainers). They'd have access _only_ to > their maintained package in git-tree. To understand what I mean, check > git shortlog -s -n net-im/telegram-desktop-bin/ > git shortlog -s -n net-im/signal-desktop-bin/ > > There are few packages like these where I'd already trust the core > proxied maintainer to commit at their will. It's as ajak said during the > council election; _We_ are the bottleneck currently reviewing and > _testing_ contributions, and with these two examples above, 99 % of time > everything's in condition and we just need to merge. Obviously if these > trusted contributors had to touch another package, or anything in > profiles/ (just basically anything outside their dedicated package > directory) they'd have to do a PR or .patch file to be merged by > official developers. And they'd still need a proxy Gentoo > developer/project listed in metadata, at least for now, to take > responsibility. > > On the technical side I'm not sure how to achieve this, but I know it > can be done. For example the sync-repos are compiled like this all the > time. If this proposal gains support, I'm willing to start figuring it > out more in-depth. > > AFAIK Fedora and Arch have somewhat similar systems in place already. How would you suggest we track who has commit access, etc? The same way we do with developers, via a developer bug? I ask because I've noticed a lot of inactive proxied maintainers—one of which had been listed in metadata.xml for 6 years but had never committed to ::gentoo.
[gentoo-dev] [PATCH] vala.eclass: Raise minimum supported version to 0.50
And remove the 0.42 special case while we're here.
Signed-off-by: Matt Turner
---
eclass/vala.eclass | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/eclass/vala.eclass b/eclass/vala.eclass
index 076ef906606..4e668d939fa 100644
--- a/eclass/vala.eclass
+++ b/eclass/vala.eclass
@@ -49,11 +49,10 @@ vala_api_versions() {
local minimal_supported_minor_version minor_version
# Dependency atoms are not generated for Vala versions older than
0.${minimal_supported_minor_version}.
- minimal_supported_minor_version="46"
+ minimal_supported_minor_version="50"
for ((minor_version = ${VALA_MAX_API_VERSION#*.}; minor_version >=
${VALA_MIN_API_VERSION#*.}; minor_version = minor_version - 2)); do
- # 0.42 is EOL and removed from tree; remove special case once
minimal_support_minor_version >= 44
- if ((minor_version >= minimal_supported_minor_version)) &&
((minor_version != 42)); then
+ if ((minor_version >= minimal_supported_minor_version)); then
echo "0.${minor_version}"
fi
done
--
2.35.1
Re: [gentoo-dev] Re: Introduce a pandoc virtual
On Fri, Jun 3, 2022 at 12:35 PM Maciej Barć wrote: > > > But you'll have to match KEYWORDS for both options first. > > Afaik KEYWORDS of virtuals are a union of KEYWORDS of it's dependencies. > pandoc has "~amd64 ~x86", pandoc-bin has "~amd64" now, with possibility > of "~arm64" (only those 2 arches are precompiled by upstream). > > From Devmanual: > > the developer can immediately set the KEYWORDS of a virtual to the union of > > KEYWORDS of its providers. I agree with you.
[gentoo-dev] Last Rites: gnome-extra/gnome-documents
# Matt Turner (2022-05-23) # Dead package upstream. Depends on dead app-misc/tracker:0. # Removal on 2022-06-23. Bug #846605 gnome-extra/gnome-documents signature.asc Description: PGP signature
[gentoo-dev] dev-cpp/gconfmm: Last Rites
# Matt Turner (2022-05-19) # Dead package upstream for more than 7 years. # Removal on 2022-06-19. dev-cpp/gconfmm signature.asc Description: PGP signature
[gentoo-dev] dev-cpp/libglademm: Last Rites
# Matt Turner (2022-05-19) # Dead package upstream for more than 10 years. # Removal on 2022-06-19. Bug #808237 dev-cpp/libglademm signature.asc Description: PGP signature
