Re: Orphan Hoard (a memory allocator) again in Fedora
On Fri, Jul 06, 2018 at 08:11:26AM +1000, Emery Berger wrote: > Yeah, I intended to become a packager but found the instructions a bit > opaque. If someone can point me to a quick start guide or similar I’d be > happy to do this in the next few weeks (I am currently traveling overseas). https://fedoraproject.org/wiki/Join_the_package_collection_maintainers Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TJIF75TLS2D2GA7MEFA7B4XJURCM2BHH/
Annobin: "causes a section type conflict with..."
This afternoon, I received email from koschei, telling me that
polymake's builds have started to fail:
https://apps.fedoraproject.org/koschei/package/polymake?collection=f29
The failure is due to this:
/builddir/build/BUILD/polymake-3.2/include/core/polymake/internal/shared_object.h:410:9:
error: ‘void pm::shared_object::leave() [with Object
= pm::sparse2d::Table; TParams =
{pm::AliasHandlerTag}]’ causes a section
type conflict with ‘const pm::perl::RegistratorQueue&
polymake::common::get_registrator_queue(polymake::mlist,
std::integral_constant) [with
Tag = polymake::common::GlueRegistratorTag;
pm::perl::RegistratorQueue::Kind kind =
(pm::perl::RegistratorQueue::Kind)1]’
void leave()
^
"Huh," I thought, "that's weird. Well, I'll look into that after I
kick off this mock build of openfst 1.6.8". Then the openfst build
also failed with the same kind of "section type conflict" error.
On a hunch, I added this to openfst.spec and tried again:
%undefine _annotated_build
The mock build succeeded. Did somebody just do something to annobin
today? If so, can you please undo it?
--
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/A637TVN7ZGMRFJ6YSGZL6TCIBEELBW3N/
Re: F29 Self Contained Change: Deprecate YUM 3
On 06/27/2018 03:18 AM, Lubomír Sedlář wrote: > Removing Yyum would mean that there will no longer be /usr/bin/pungi > available in Fedora. This is not a problem for any work done by release > engineering, but it is still used by people creating spins. > > So this is a call to action: if anyone wants to continue using it, now > is the time to come up and port it to DNF (and Python 3). Sorry for my delay in replying here... been busy. ;( Looking at the list of things that would go away (from the wiki page): cobbler ddiskit diskimage-builder dlrn dnf-plugins-core ? dnf-plugins-core is kind of important, is this a false positive? Or does it mean python2-dnf-plugin*? fusioninventory-agent grinder imgbased kiwi koji koji is kinda important. I think this is meaning python2-koji? I would hope python3-koji/koji stays around? koji-containerbuild We like containers these days, don't we? libtaskotron And testing? lpf mach mash mirrormanager And mirrors (this one isn't as important as we run mirrormanager on rhel, but still) nagios-plugins-check-updates osc perl-Fedora-Rebuild plague pulp-rpm repo_manager repoview retrace-server This also runs on rhel, but sooner or later will need porting. rpm-ostree-toolbox sigul This is kinda important. snake system-config-kickstart yum-axelget yum-rhn-plugin yum-updatesd So, I'm personally not too keen on this at this point. I suppose if it happens then we will need to maintain/keep a fork of yum3 in infrastructure for tools, at which point it might be best to just keep it in the distro. I don't know the porting plans for all the above stuff, but I would personally really prefer retiring only after they were ported or at least we know there's a plan for them. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4ANJI5BPX2RYPNXNGJKGHQCXIYRUKIKS/
Re: installing glibc-minimal-langpack in buildroots
On Thu, 5 Jul 2018 at 16:08, Zbigniew Jędrzejewski-Szmek wrote: [..] > Anyway, the langpacks split was made with full awareness of %_install_langs, > see https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging. Yep and simple this makes glibcs.spec one of the most complicated Fedora specs files by implementing generate set of sub packages to install lang dependent resources. If glibc and few other packages will be only using %lang() and everything aroud will be adding proper %_install_langs settings it will be not necessary to create next almost 200 glibc sub packages. Even separation glibc-minimal-langpack files is pointless because those files must be installed always to not have constantly annoying warning messages about missing locale "C" files. [..] > > Result is obvious: number of *langpack* packages is growing. > I don't think this is a big problem. The number of languages that can > be supported can't go much higher (in principle there's maybe ~2000 languages > alive nowadays, but most of them are dying quickly, and are unlikely to ever > get glibc locale support). The 192 langpacks we have now is nothing compared > to the texlive package list. Just please correct me if I'm wrong. Does it mean that someone already started thinking about generate another 2k TeX packages? =8-O If it is true I'll put my private money to fund for this person special IgNoble price :) Fedora has those only glibc sub packages because nothing OOTB in installer adds /etc/rpm/macros file with single line of text forefeet start install first package. Many packages have already marked man pages and gettext .mo files which have proper %lang() metadata. How you can compare probably single python code modification in kickstart code to number of man/hour resources spend by all Fedora packagers which are maintaining *langpack* sub packages scheme and man/hour resources already spent by Fedora end users choosing those langpacks? Yes .. this is level; of the "elegance and simplicity" which many Fedora packages already are trying hardly avoid by any cost. Again .. just please try sometimes to think a bit broader. If you will repeat enough times "I don't think this is a big problem" by a mass of those even smallest issues at least one big problem sooner or later will start kicking back. You already must know that this effect is well know in engendering and its name is "dead by thousands cuts". Someone implementing langpacks in glibc have been trying to not install some resources at the same time lost all other .mo and %lang) depended files installed in the system. This like trying to move around few buckets of sand sitting in the middle of the desert. How big proportion is between those disk space which is possible to "save" by using proper set of *langpack* packages you can check on you own system by add /etc/rpm/macros with line like: %_install_langs en,pl (or any other set of the languages) is possible to check by run below oneliner: # rpm --rebuilddb; dnf cean all; df -k /; rpm -qal|grep LC_MESSAGES|xargs rpm -qf 2>&1|sort|uniq| xargs dnf -yq reinstall; rpm --rebuilddb; df -k / and compare reduction used disk space to summary size of all Fedora glibc-langpack* packages. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UDFAFJOR23NC7KCOFSWGWYOYFO33UXV6/
Orphan Hoard (a memory allocator) again in Fedora
Hoard, a memory allocator, fails to build in Fedora for a long time. I posted about this over a year ago: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2B254TXRF443HGGT2NELAQXEYFTQBLEN/ at which time the upstream owner claimed they would become a packager and fix it. However that didn't happen, so I'm really going to orphan it now, and recommend that it is retired asap. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DNH742K4YL4Y5ODI6VXTE6AJL7W6RVAH/
Re: installing glibc-minimal-langpack in buildroots
On Thu, Jul 05, 2018 at 03:33:42PM +0100, Tomasz Kłoczko wrote: > On Thu, 5 Jul 2018 at 13:33, Zbigniew Jędrzejewski-Szmek > wrote: > > > > Hi, > > > > Right now glibc-all-langpacks is installed in buildroots (mock, koji, …). > > It is 24 MB, out of the total of 145 MB. Replacing it with > > glibc-minimal-langpack, > > which has negligible size, would decrease the buildroot size by 17%. > > BTW glibc langpacks sub packages. > IMO this solution is wrong because it is not compliant with what provides rpm. > Instead relating on rpm settings usually dropped into /etc/rpm/macros like: > > %_install_langs en,pl > > Someone is trying to implement installed languages support on subpackages > layer. I'm not sure if I understand what you are criticizing: the langpacks split, or my proposal, or what. Anyway, the langpacks split was made with full awareness of %_install_langs, see https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging. [...] > Result is obvious: number of *langpack* packages is growing. I don't think this is a big problem. The number of languages that can be supported can't go much higher (in principle there's maybe ~2000 languages alive nowadays, but most of them are dying quickly, and are unlikely to ever get glibc locale support). The 192 langpacks we have now is nothing compared to the texlive package list. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6DLHDAOKCZNK4M47SALEYXPNSOI5BLZA/
Re: installing glibc-minimal-langpack in buildroots
On Thu, 5 Jul 2018 at 13:33, Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > Right now glibc-all-langpacks is installed in buildroots (mock, koji, …). > It is 24 MB, out of the total of 145 MB. Replacing it with > glibc-minimal-langpack, > which has negligible size, would decrease the buildroot size by 17%. BTW glibc langpacks sub packages. IMO this solution is wrong because it is not compliant with what provides rpm. Instead relating on rpm settings usually dropped into /etc/rpm/macros like: %_install_langs en,pl Someone is trying to implement installed languages support on subpackages layer. In other words all glibc %files entries which needs to be installed when exact language support is needed should have proper %llang() meta data and with such macros all those resources can be incorporated into main glibc package. Problem with above approach only is that nothing in kickstart installer is setting up rpm settings before install first package (even in interactive or batch mode is possible to pass such settings) so in this situation people started looking for "other solutions" assuming that because this such feature so long (kickstart has already +20y?) not been provided nothing on packaging layer handles such settings. Result is obvious: number of *langpack* packages is growing. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/D4HXANVGXUTOYOSNXIJPE4U25UN4FM4D/
Re: installing glibc-minimal-langpack in buildroots
On Thu, Jul 05, 2018 at 01:19:38PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jul 05, 2018 at 02:41:01PM +0200, Florian Weimer wrote: > > On 07/05/2018 02:28 PM, Stephen Gallagher wrote: > > >So if we made this change, it should > > >probably go through the System-Wide Change process, the same as > > >any other item we remove from the default buildroot. > > > > I agree that it is a useful change, but also that it should go > > through the Change process. > OK. > > > On 07/05/2018 02:28 PM, Stephen Gallagher wrote: > > >My concern there would be that any package that needs langpacks > > >available in its build-system will now need to request them > > >specifically (for example, if the package does tests of > > >localization in %check). > I wonder how many such packages there are. I have seen many packages > which fail in an non-unicode locale, especially in tests. > glibc-minimal-langpack > contains C.UTF-8 so that is should not be an issue. So far I haven't > seen packages that would depend on the presence of some specific > locales, except that many packages need *some* utf-8 locale so they > set some specific one, usually en_US.utf8. A quick grep shows that > there's maybe a 50 such packages that would need to be adjusted. https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EFN2W633NCTS5J7WWL74IFEH7LXBSUJ3/
Re: installing glibc-minimal-langpack in buildroots
On Thu, Jul 05, 2018 at 02:41:01PM +0200, Florian Weimer wrote: > On 07/05/2018 02:28 PM, Stephen Gallagher wrote: > >So if we made this change, it should > >probably go through the System-Wide Change process, the same as > >any other item we remove from the default buildroot. > > I agree that it is a useful change, but also that it should go > through the Change process. OK. > On 07/05/2018 02:28 PM, Stephen Gallagher wrote: > >My concern there would be that any package that needs langpacks > >available in its build-system will now need to request them > >specifically (for example, if the package does tests of > >localization in %check). I wonder how many such packages there are. I have seen many packages which fail in an non-unicode locale, especially in tests. glibc-minimal-langpack contains C.UTF-8 so that is should not be an issue. So far I haven't seen packages that would depend on the presence of some specific locales, except that many packages need *some* utf-8 locale so they set some specific one, usually en_US.utf8. A quick grep shows that there's maybe a 50 such packages that would need to be adjusted. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Q7D7A3UEAUMLHEZIG4EXHJDHPWKZXRS3/
Re: F29 System Wide Change: Modules for Everyone
On Wed, Jul 4, 2018, at 9:17 AM, Zbigniew Jędrzejewski-Szmek wrote: > > - something else ? The rpm-ostree tracking issue is here: https://github.com/projectatomic/rpm-ostree/issues/1435 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UCF62PS23B4H34KPALHWZXRD3TL3KIGR/
Re: installing glibc-minimal-langpack in buildroots
On 07/05/2018 02:28 PM, Stephen Gallagher wrote: On Thu, Jul 5, 2018 at 8:25 AM Zbigniew Jędrzejewski-Szmek mailto:zbys...@in.waw.pl>> wrote: Hi, Right now glibc-all-langpacks is installed in buildroots (mock, koji, …). It is 24 MB, out of the total of 145 MB. Replacing it with glibc-minimal-langpack, which has negligible size, would decrease the buildroot size by 17%. glibc Requires glibc-langpack, and Suggests glibc-all-langpacks, so it gets installed automatically to satisfy that dependency. If a different package providing glibc-langpack is installed, glibc-all-langpacks would be skipped. I think glibc-minimal-langpack should be enough in the buildroot. What about adding glibc-minimal-langpack to @Buildsystem ? My concern there would be that any package that needs langpacks available in its build-system will now need to request them specifically (for example, if the package does tests of localization in %check). So if we made this change, it should probably go through the System-Wide Change process, the same as any other item we remove from the default buildroot. I agree that it is a useful change, but also that it should go through the Change process. We are aware of the locale size issue and want to reduce it, but it is not easy, and other more pressing matters tend to intervene. 8-( Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QA7XE6AQZYAWY376BHUBLHA33VA3HGTQ/
Re: installing glibc-minimal-langpack in buildroots
On Thu, Jul 5, 2018 at 8:25 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > Hi, > > Right now glibc-all-langpacks is installed in buildroots (mock, koji, …). > It is 24 MB, out of the total of 145 MB. Replacing it with > glibc-minimal-langpack, > which has negligible size, would decrease the buildroot size by 17%. > > glibc Requires glibc-langpack, and Suggests glibc-all-langpacks, so it > gets installed automatically to satisfy that dependency. If a different > package providing glibc-langpack is installed, glibc-all-langpacks would > be skipped. > > I think glibc-minimal-langpack should be enough in the buildroot. > What about adding glibc-minimal-langpack to @Buildsystem ? > > My concern there would be that any package that needs langpacks available in its build-system will now need to request them specifically (for example, if the package does tests of localization in %check). So if we made this change, it should probably go through the System-Wide Change process, the same as any other item we remove from the default buildroot. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BODOYVKIKB3MB3Y65SVF6SMGEBI4PHON/
installing glibc-minimal-langpack in buildroots
Hi, Right now glibc-all-langpacks is installed in buildroots (mock, koji, …). It is 24 MB, out of the total of 145 MB. Replacing it with glibc-minimal-langpack, which has negligible size, would decrease the buildroot size by 17%. glibc Requires glibc-langpack, and Suggests glibc-all-langpacks, so it gets installed automatically to satisfy that dependency. If a different package providing glibc-langpack is installed, glibc-all-langpacks would be skipped. I think glibc-minimal-langpack should be enough in the buildroot. What about adding glibc-minimal-langpack to @Buildsystem ? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ETKQK6K5W2NGI2DSSRKFJDTBME6EI7DE/
Re: Your package requires Python 3.6, rebuild it!
On Wed, Jul 04, 2018 at 09:58:15PM +0200, Miro Hrončok wrote: > On 4.7.2018 21:51, Sérgio Basto wrote: > >since 2018-07-02 14:28 [1] we don't have compose this mean build root > >on copr aren't update , and we can't test it > > Try adding > http://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/ as a > repo to copr. there should be no more problems like iwth the > f29-python side tag, where packages had newer versions in rawhide > still depending on 3.6. Alternatively, build in mock: $ fedpkg srpm && mock --enablerepo=local whatever.src.pm (Repo 'local' pulls directly from koji.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DXWIO4CIKCKXT2PREKXWCOKDZIWXH4T7/
Re: Intent to orphan: perl-Mail-DKIM and python-beaker
On 5.7.2018 07:40, Emmanuel Seyman wrote: * Miro Hrončok [04/07/2018 23:12] : Anybody who wants perl-Mail-DKIM (needed by amavisd-new, spamassassin) before I orphan it? I'll take it (fas: eseyman). Thank you, it's yours now. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VRDVCW7E4YI2K6AG5VI4RH2TN74UGMDE/
Re: F29 System Wide Change: Modules for Everyone
On Wed, Jul 04, 2018 at 02:21:58PM +0100, Richard Hughes wrote: > > - pkcon ? > > - Gnome Software ? > I've been talking internally about this. The idea is for pkcon and > GNOME Software to have a superficial view of what modules are, but not > to actually expose all the nitty-gritty detail. It's on my radar to > make this work correctly. I think I said this elsewhere in this thread, but it doesn't hurt to repeat. :) I think this generally makes sense, because I don't expect modules to be the primary means through which users select different streams of graphical applications. For that kind of thing, Flatpak (or, Neal, Snaps) make sense. And GNOME Software only does GUI apps anyway. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XCY5QANOZ2TX6JW6SEQKIWIPPFE465CX/
Re: F29 System Wide Change: Modules for Everyone
On Wed, Jul 04, 2018 at 01:17:06PM +, Zbigniew Jędrzejewski-Szmek wrote: > Hmm, all those details… What about a checklist? ;) > - dnf ✓ > - dnfdragora ? > - pkcon ? > - Gnome Software ? > - yum - (not needed) > - something else ? microdnf and cockpit -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/URCRB64ITDHH2GPAJRBFVKGRKQDS72CH/
