Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
Hello! There are two things to consider, both mean that I can't really ever say "yes we will do it" for a request like that. - None of the anaconda devs are qualified enough to decide if we could accept such a change. It's a bootloader thing. What we would do is delegate to somebody working with bootloaders to see if it's technically viable. Likely that would be Peter Jones (CCed). - Anaconda is intertwined with Fedora, so there would have to be a change process and all that. The current audience in this thread is likely the same as you'd get for the hypothetical change, anyway... Hope that helps? Best, Vladimir On Thu, May 11, 2023 at 12:34 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Wed, May 10, 2023 at 02:25:07PM +0100, Richard Hughes wrote: > > On Wed, 10 May 2023 at 11:55, Zbigniew Jędrzejewski-Szmek > > wrote: > > > Especially not by making some small change contingent on moonshot > proposals. > > > But I think that a) the current proposal is just a band-aid, and > > > b) to make things better we don't need to make huge changes. > > > > Okay, please open a _new_ change proposal with what you want to > > happen: expanding the scope like you suggest feels like me getting > > tricked to work on your much bigger change that's not terribly > > well-defined or tested. > > > > > ...Anaconda needs to *lose* a feature where it > > > refuses VFAT for /boot [1], the various places which create partitions > > > need to be modified to inject the right partition-type UUID instead of > > > made-up one, and instead of creating two partitions with different fs > > > types, create just one. None of this is rocket science. > > > > Perhaps you'd like to push this feature. I'd happily retract my > > smaller proposal if you've got patches ready for anaconda, have tested > > this on all platforms, and have all the votes. > > I'm adding some folks who made some recent Anaconda commits in CC. > For reference, the mail I'm replying to is at [1], and my earlier > proposal is at [2]. > > Would you be open to modifying Anaconda like this? > I think the code changes would be fairly easy, and I would be happy > to prepare a patch, but I don't want to do this if there's no chance > of it being accepted. > > [1] > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GCIOR4CRMYYMWPT7ZVVPNO5Y4SDUKAKG/ > [2] > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/X47VLKL4363HMMPNZ5R7N2FPMXG5RAWJ/ > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Vladimír Slávik Software Engineer, Platform Engineering Red Hat Czech, s.r.o. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: nodejs broken?
We're seeing the same with anaconda webui - any invocation of node leads to
segmentation fault - npm, npx... nothing works.
On Tue, May 2, 2023 at 11:28 AM Sandro Mani wrote:
>
> On 02.05.23 11:24, Iñaki Ucar wrote:
>
> On Tue, 4 Apr 2023 at 16:23, Stephen Gallagher
> wrote:
>
> On Tue, Apr 4, 2023 at 9:45 AM Sérgio Basto
> wrote:
>
> On Thu, 2023-03-16 at 11:19 -0400, Stephen Gallagher wrote:
>
> On Wed, Mar 15, 2023 at 1:16 PM Jerry James
>
>
> ...
>
> I found a problem related with yarnpkg rpm, the macro % __find_requires
> finds that yarn scripts uses and needs /usr/bin/node , which is added
> to the requires of rpm [1] and this makes yarnpkg pull nodejs (18) even
> when nodejs20 is installed .
> To avoid this rpm automatic requires, we may add to yarnpkg.spec [2]
>
> [2]
> %global __script_requires %{nil}
>
> [1]
> dnf repoquery yarnpkg --available --requires -q
> /usr/bin/bash
> /usr/bin/node
> /usr/bin/sh
>
>
> I'm not sure what you think is a bug here? Do you think `yarnpkg`
> should use *any* nodejs version that's installed? The whole point of
> the way this is broken down is that we have a default version (18, in
> this case) with the option to install 16 and 20 in parallel, but you
> have to do extra work if you want to *use* those non-default versions
> (such as patching shebang lines).
>
> This is broken again in rawhide:
>
> $ dnf -qy install yarnpkg
> $ ll /usr/bin/node*
> lrwxrwxrwx. 1 root root 7 Apr 28 00:00 /usr/bin/node -> node-20
> -rwxr-xr-x. 1 root root 28272 Apr 28 00:00 /usr/bin/node-20
> lrwxrwxrwx. 1 root root39 Mar 21 00:00 /usr/bin/nodejs-yarn ->
> ../lib/node_modules_19/yarn/bin/yarn.js
>
> If yarn should be pinned to a node version, please rebuild yarn when
> there's a major version change. And it would be nice if there's a
> mechanism to detect such a breakage. I.e. a nodejs(abi) version or
> something like that.
>
> AFAICS nodejs is generally broken in rawhide (both nodejs20 and nodejs18),
> i.e. just
>
> $ node
> >
> Segmentation fault (core dumped)
>
> gdb:
>
> Thread 3 "node" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x72ffe6c0 (LWP 1565850)]
> 0x757db195 in
> v8::internal::compiler::SpecialRPONumberer::ComputeAndInsertSpecialRPO(v8::internal::compiler::BasicBlock*,
> v8::internal::compiler::BasicBlock*) () from /lib64/libnode.so.115
>
> Sandro
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
Vladimír Slávik
Software Engineer, Platform Engineering
Red Hat Czech, s.r.o.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Self introduction: Vladimir Slavik
Hello Fedora, I'm Vladimír Slávik, I have worked on the anaconda installer at Red Hat for some 3 years now, and somehow I managed to neglect this introductory email... Before making^W bugfixing software for living, I spent an inordinate amount of time translating Battle for Wesnoth and maintaining Simutrans data. While I mostly work with Python professionally, personally I'm using Pascal and its current era derivatives a lot. Best, Vladimir -- Vladimír Slávik Software Engineer, Platform Engineering Red Hat Czech, s.r.o. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F36 Change: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)
Thank you, I have added feedback from this discussion to the Change page. https://fedoraproject.org/wiki/Changes/Users_are_admins_by_default_in_Anaconda#Feedback (This does not mean the discussion is over, just that there was enough to go and edit the page.) Best, VS On Mon, Nov 29, 2021 at 8:35 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Users_are_admins_by_default_in_Anaconda > > = Users are administrators by default in the installer GUI = > > == Summary == > > The Anaconda installer GUI will have the administrative rights > checkbox on the User screen ticked by default. > > == Owner == > > * Name: [[User:Vladimirslavik| Vladimir Slavik]] > * Email: vsla...@redhat.com > > > == Detailed Description == > > Currently, the Anaconda installer GUI presents an unticked checkbox > "Make this user administrator" on the user setup screen by default. > This means users have to discover the control, understand its meaning, > and consciously decide to change the value from the default one. > > However, computer usage by individuals is heavily skewed towards > single user machines where the (sole) user has administrative powers > over the machine by invoking `sudo`. This has been always reflected by > the design of the screen, which allows only a single user to be > created. The GNOME first time setup also creates a single user - and > makes them an administrator without asking. > > The proposed change merely changes the default GUI state to be in line > with this expectation. > > Further, this change of defaults complements the default for root > account. The redesign of root setup screen in Fedora 35 makes it clear > that root should be left locked. This change makes it clear that the > user should be the administrator. Together, these defaults will let > the user satisfy all user account options by filling in nothing more > than the user name and the password (twice to confirm). > > > == Benefit to Fedora == > > One less footgun in the installer for entry-level users. They will be > able to rely on defaults and achieve the expected outcome. > > == Scope == > > * Proposal owners: Isolated change - adjust Anaconda code to do so as > suggested here. Low effort. > * Other developers: No changes needed. > * Release engineering: Different defaults ''could'' impact installer > testing. [https://pagure.io/releng/issues #Releng issue number] > * Policies and guidelines: N/A > * Trademark approval: N/A > * Alignment with Objectives: None. > > == Upgrade/compatibility impact == > > No impact. Installation implies teardown of previous system, including > users. > > == How To Test == > > Start Anaconda installer for the Server variant, open the user setup > screen, "Make this user administrator" is checked = pass. > > Should be variant / spin / hardware agnostic, with the caveat that the > presence of user screen is configurable, so in many cases the screen > is not reachable. > > Kickstart installs are not affected. > > == User Experience == > > Users installing Fedora will no longer be forced to spend time > deciding how to arrange the administrative powers (they, root, both?) > and configuring that. They will be able to fill in user name and > password and the default configuration will be valid. They can give in > to the power of defaults. > > For users that want to configure the system differently from the > majority use case, the controls to do so are still as they were, only > the defaults are different. > > For those installing Fedora manually often, muscle memory for user > screen will break, as the checkbox will no longer have to be toggled. > > == Dependencies == > > None. > > == Contingency Plan == > > Any Fedora QA and OpenQA changes reflecting this will have to be > reverted. Other than that, there is no technical or process > requirement for this change, so no impact. The change does not happen > and previous defaults remain. > > * Contingency mechanism: N/A > * Contingency deadline: N/A > * Blocks release? No > > == Documentation == > > * https://github.com/rhinstaller/anaconda/pull/3719 > > == Release Notes == > > In the User spoke, the "Make this user administrator" checkbox is now > checked by default. This improves installation experience for users > who do not know and need to rely on the default values to guide them. > > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-l
Re: F36 Change: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)
Thanks, I have edited the release note on the proposal page. VS On Wed, Dec 1, 2021 at 5:23 PM Jiri Konecny wrote: > > Dne 01. 12. 21 v 16:16 Jonathan Wakely napsal(a): > > On Mon, 29 Nov 2021 at 19:36, Ben Cotton wrote: > >> == Release Notes == > >> > >> In the User spoke, the "Make this user administrator" checkbox is now > >> checked by default. This improves installation experience for users > >> who do not know and need to rely on the default values to guide them. > > What's the context of this text? Is it in a section that is > > specifically about anaconda? Because "the User spoke" isn't very > > meaningful on its own. Arguably talking about spokes at all isn't very > > meaningful for end users who are reading the release notes. I did a > > double-take when reading it, until remembered that's the anaconda > > terminology, and I've been using anaconda for years and years. > Yes, you are correct it's the Anaconda context. Good point, maybe it > would be good to change the proposal a bit to clarify that? > > Jirka > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Vladimír Slávik Software Engineer, Platform Engineering Red Hat Czech, s.r.o. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)
Hi Brandon, this applies to all variants that display the user screen. Looking at the profiles we have, that means Server, KDE, Kinoite, IoT. Where this does *not* apply is Workstation and Silverblue. I believe the anaconda repository has all the relevant profiles, so hopefully that list is complete enough. It also applies to everything derived from the RHEL profile - alma, rocky, centos,... but these are not relevant for this discussion, I think. Best, Vladimir On Mon, Nov 29, 2021 at 9:15 PM Brandon Nielsen wrote: > On 11/29/21 1:33 PM, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/Users_are_admins_by_default_in_Anaconda > > > > = Users are administrators by default in the installer GUI = > > > > == Summary == > > > > The Anaconda installer GUI will have the administrative rights > > checkbox on the User screen ticked by default. > > > > == Owner == > > > > * Name: [[User:Vladimirslavik| Vladimir Slavik]] > > * Email: vsla...@redhat.com > > > > > > == Detailed Description == > > > > Currently, the Anaconda installer GUI presents an unticked checkbox > > "Make this user administrator" on the user setup screen by default. > > This means users have to discover the control, understand its meaning, > > and consciously decide to change the value from the default one. > > > > However, computer usage by individuals is heavily skewed towards > > single user machines where the (sole) user has administrative powers > > over the machine by invoking `sudo`. This has been always reflected by > > the design of the screen, which allows only a single user to be > > created. The GNOME first time setup also creates a single user - and > > makes them an administrator without asking. > > > > The proposed change merely changes the default GUI state to be in line > > with this expectation. > > > > Further, this change of defaults complements the default for root > > account. The redesign of root setup screen in Fedora 35 makes it clear > > that root should be left locked. This change makes it clear that the > > user should be the administrator. Together, these defaults will let > > the user satisfy all user account options by filling in nothing more > > than the user name and the password (twice to confirm). > > > > > > [Snip] > > > > > == How To Test == > > > > Start Anaconda installer for the Server variant, open the user setup > > screen, "Make this user administrator" is checked = pass. > > > > Should be variant / spin / hardware agnostic, with the caveat that the > > presence of user screen is configurable, so in many cases the screen > > is not reachable. > > > > Kickstart installs are not affected. > > > > [Snip] > > "Detailed Description" section mentions GNOME, "How To Test" describes > the server variant. Which specific variants does this all apply to? > > If I recall correctly, the KDE spin already differs from Workstation in > this regard. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Vladimír Slávik Software Engineer, Platform Engineering Red Hat Czech, s.r.o. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Rules for adding users to groups at install time by default
Hello, anaconda has a bug about adding new users to the "vboxsf" group to help with sharing folders. https://bugzilla.redhat.com/show_bug.cgi?id=1820911 As far as I can tell, the group depends on having the guest additions package installed. Without detecting the platform, the easiest way to fulfill the request is to just try adding the user to the group and skipping if it doesn't exist. Is there any policy about this - adding users to groups? Best, Vladimir -- Vladimír Slávik Software Engineer, Platform Engineering Red Hat Czech, s.r.o. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Anaconda quick-docs need review
So, checking after some days: Is there anything left for me to do about Anaconda quick docs? I'm not entirely sure, sorry... Best, V+ On Fri, Mar 13, 2020 at 11:17 PM Adam Williamson wrote: > On Fri, 2020-03-13 at 17:37 -0400, Matthew Miller wrote: > > On Tue, Mar 10, 2020 at 08:55:16AM +, Ankur Sinha wrote: > > > I honestly don't know. These were converted along with a bunch of other > > > wiki pages when the quick-docs were initially populated. I'll remove > > > them from the quick-docs now. > > > > For context: I made the initial list of quick docs from the most popular > > pages which seemed user-focused on the wiki. So that's how this got > there. > > > > > No, the wiki isn't going away but it is meant to be more of a scratch > > > pad for contributors now. Relatively static information is slowly being > > > moved to the docs. This includes user-facing documentation, and other > > > bits like SOP documents for various teams. For example: > > > https://docs.fedoraproject.org/en-US/engineering/ > > > > +1 > > > > A few years ago, Mo Duffy and I identified something like two dozen > totally > > different ways in which the project uses the wiki, from docs to policies > to > > scratch pads to meet notes to QA test matrices to user pages to I don't > even > > remember what now but I am not making up the number. > > > > Having this all together results in a poor user experience for people who > > want to read current and authoritative docs without being one click away > > from what's basically very perplexing deep-knowledge territory. So, we > > decided to create a separated docs site. > > However, now we've started moving things like policies onto that docs > site. I also feel it bears pointing out that you can get from the docs > site to the wiki, or from the wiki from the docs site, or from either > of those things to absolutely anywhere else on the internet, with "one > click" :) > > I know everyone knows I'm the #1 Wiki Fan, but I really don't grok a > lot of the justification for it being Bad. The justification I *can* > get behind is that it's a PITA to maintain, and for that I apologize to > smooge whenever I remember to ;). But I never really quite got this "oh > it's bad to have different things in one site" argument. Why is it bad? > What's the practical difference between them being there and them being > on different sites, if we still link between them and they're all > "Fedora"? > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Vladimír Slávik Software Engineer, Platform Engineering Red Hat Czech, s.r.o. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Anaconda quick-docs need review
Hi! Anaconda dev here (a new one, but never mind). Comparing to the other topics in quick docs, the Anaconda pages in the queue are very technical, and I'd say more of a fringe topic than eg. httpd or kernel. So are quick docs really the right place for this? Is the wiki is going away? If so, maybe let's have these as quick docs for now. But if not, I think the majority of the info is detrimental alongside the other quick docs. (One exception could be Anaconda Updates.) Also, this information can go to other places without being lost. We have some docs in the repo, some as a standalone book, etc... Best, Vladimir On Thu, Mar 5, 2020 at 7:33 PM Ankur Sinha wrote: > Hi, > > There are some quick-docs related to Anaconda that need review but > require specialist Anaconda knowledge. > > Could someone that knows Anaconda well (the devs?) please look at these? > > - Creating a product image: > https://pagure.io/fedora-docs/quick-docs/issue/218 > - Anaconda logging: https://pagure.io/fedora-docs/quick-docs/issue/217 > - Anaconda updates: https://pagure.io/fedora-docs/quick-docs/issue/216 > > and the Anaconda page in general: > https://docs.fedoraproject.org/en-US/quick-docs/anaconda/anaconda/ > > Should these reside in the quick-docs at all? If not please let us know > and we'll remove them. > > -- > Thanks, > Regards, > Ankur Sinha "FranciscoD" (He / Him / His) | > https://fedoraproject.org/wiki/User:Ankursinha > Time zone: Europe/London > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Vladimír Slávik Software Engineer, Platform Engineering Red Hat Czech, s.r.o. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
