Re: dnspython 2.0.0rc1 (without Python 2 support)
dnspython 2.0.0 has been released upstream and it's available in COPR: https://copr.fedorainfracloud.org/coprs/lbalhar/dns/ The builds are okay except the two mentioned before. I'll coordinate update with https://bugzilla.redhat.com/show_bug.cgi?id=1737930 Lumír On 7/7/20 8:30 AM, Lumir Balhar wrote: python-dns 2.0.0rc2 is ready in the COPR. - mailman3 FTBFS because it has missing dependencies in rawhide - python-ryu FTBFS but the problem is only in COPR (probably caused by an empty resolv.conf) and it builds fine in mock. Lumír On 6/25/20 12:30 PM, Lumir Balhar wrote: Hello. tl;dr - if your package [build]requires python3-dns, please test it with python-dns from COPR [0] and let me know in case of any troubles. I'm slowly getting ready to update python-dns to 2.0.0 which drops Python 2 support. dnspython is still a release candidate but the final release should be available soon. Only mailman and trac-spamfilter-plugin depend on python2-dns. A new version of trac-spamfilter-plugin should be released soon [0] so we can update both together but I have no idea about plans for mailman. Is there any ETA for Python 3 support there? It seems that all packages with build-dependency on python3-dns build fine [0] except python-ryu but the issue there seems to be caused by eventlet [2]. Have a nice day. Lumír [0] https://copr.fedorainfracloud.org/coprs/lbalhar/dns/ [1] https://bugzilla.redhat.com/show_bug.cgi?id=1737930 [2] https://github.com/eventlet/eventlet/issues/619 ___ 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 ___ 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 ___ 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
[389-devel] 389 DS nightly 2020-07-20 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/07/20/report-389-ds-base-1.4.4.4-20200719git654d0ff.fc32.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
Re: Serial port sniffing?
Once upon a time, Richard Shaw said: > I would like to monitor serial port communications read only, but I haven't > found a tool that makes that easy in the Fedora repos. You might look at an eBPF script - for example, there's a "ttysnoop" in the bcc-tools package (it's /usr/share/bcc/tools/ttysnoop). You might be able to adapt that to your needs. -- Chris Adams ___ 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: Serial port sniffing?
On 7/19/20 2:23 PM, Richard Shaw wrote: I would like to monitor serial port communications read only, but I haven't found a tool that makes that easy in the Fedora repos. Are you just wanting to listen to what's coming in or do you want to intercept communication between a process and the serial port? ___ 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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 705 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 444 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 154 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 94 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-19d171a465 python34-3.4.10-5.el7 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8dd45257ad seamonkey-2.53.3-1.el7 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2f9c63b80c php-horde-kronolith-4.2.29-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-dab5d98f39 cacti-1.2.13-1.el7 cacti-spine-1.2.13-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-07adc005e6 mbedtls-2.7.16-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-30513f3084 singularity-3.6.0-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-192ef0b5e1 hostapd-2.9-3.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3d8bba637d clamav-0.102.4-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2c80eb66b5 matio-1.5.17-3.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing cmake3-3.17.3-3.el7 Details about builds: cmake3-3.17.3-3.el7 (FEDORA-EPEL-2020-a911888c3e) Cross-platform make system Update Information: - Backport support for out-of-source builds controlled by __cmake3_in_source_build macro ChangeLog: * Sun Jul 19 2020 Neal Gompa - 3.17.3-3 - Backport support for out-of-source builds controlled by __cmake3_in_source_build macro - Backport cmake3_build and cmake3_install macros - Backport ctest3 macro ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ff58160b15 libslirp-4.3.1-1.el8 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-672e6676c7 seamonkey-2.53.3-1.el8 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-12d0e14fab cacti-1.2.13-1.el8 cacti-spine-1.2.13-1.el8 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1c906e59bb mbedtls-2.16.7-1.el8 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-442e619b4a singularity-3.6.0-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-31b5963358 tor-0.4.3.6-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a0f28fffcf bashtop-0.9.24-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-cf34e230c7 clamav-0.102.4-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing plasma-applet-translator-0.4-1.el8 Details about builds: plasma-applet-translator-0.4-1.el8 (FEDORA-EPEL-2020-2241343a75) Plasma 5 applet for translate-shell Update Information: Update to 0.4. Update to 0.3. ChangeLog: * Sun Jul 19 2020 Vasiliy Glazov - 0.4-1 - Update to 0.4 * Fri Jul 10 2020 Vasiliy Glazov - 0.3-1 - Update to 0.3 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[Bug 1858654] New: perl-DBD-Pg-3.14.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1858654 Bug ID: 1858654 Summary: perl-DBD-Pg-3.14.0 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DBD-Pg Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, dev...@gunduz.org, john.j5l...@gmail.com, jples...@redhat.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, prais...@redhat.com, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 3.14.0 Current version/release in rawhide: 3.12.3-1.fc33 URL: http://search.cpan.org/dist/DBD-Pg/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2809/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Self Introduction: Christoph Karl
Welcome Christoph! On Sat, 18 Jul 2020 at 09:49, Christoph Karl wrote: > Hallo, > > my name is Christoph Karl. > I am a long time Fedora user, but I plan to change to CentOS 8. > So I would like to see some more packages in the EPEL repo. > So I plan to help with this as a co-maintainer. > I have a little bit experience with packaging, > but I am on may way learning more. > First packages should/will be qjackctl and qsynth. > > Best regards > > Christoph > ___ > 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 > -- David Kirwan Software Engineer Community Platform Engineering @ Red Hat T: +(353) 86-8624108 IM: @dkirwan ___ 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
Serial port sniffing?
I would like to monitor serial port communications read only, but I haven't found a tool that makes that easy in the Fedora repos. Anyone have suggestions? Thanks, Richard ___ 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
Help me bring AVIF to Fedora
Hello, I'd like some help to review: - libavif: https://bugzilla.redhat.com/show_bug.cgi?id=1858419 - qt-avif-image-plugin: https://bugzilla.redhat.com/show_bug.cgi?id=1858639 I can swap with anything. Best regards, Robert-André ___ 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: Self Introduction Ludovic Hirlimann
On 7/17/20 8:14 AM, Ludovic Hirlimann via devel wrote: Hi, I'm ludo. I've been involved with opensource for a long time now (using my first linux in 1996). I have been a mozilla employee for 10 years (as the Thunderbird QA lead and then as an IT staffer). I'm back to linux since 2015 (used FreeBSD and MacOSX since 2000). I choose Fedora as my distribution of choice and been running it since version 21. I like opendata and have particpated in musicbrainz and still participate to openstreetmap. I've always like maps and thus I'd like to join de Fedora packaging community to maintain, or help maintain two packages that are Map related : josm and qgis. I don't have much experience in maintaining packages but I'm more than willing to learn. Have a nice day. Ludovic You probably want to mention that you are looking for a sponsor so that you can become a packager (at least, I think that is what you are looking to do) and what your FAS name is. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ 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
google-benchmark soversion bump
Hello all. Google-benchmark 1.5.1 update will include a soversion bump from 0 to 1. All dependent packages must be rebuilt. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: Ditch RPM in favor of DPKG
Yeah, let's please just stop this thread? I can't see anything further productive coming out of it. Thank you. -- 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://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
[build system] New optimization failed to follow /Usr Merge
Hello team, when doing a scratch build [1], I noticed some changes like these lines on %build: '/builddir/build/BUILD/partio-1.10.1/build/Linux-5.6.15-x86_64-optimize' and on %install i.e. -- Installing: /builddir/build/BUILDROOT/partio-1.10.1-3.fc33.x86_64/builddir/build/BUILD/partio-1.10.1/Linux-5.6.15-x86_64-optimize/lib64/libpartio.so.1.5.2 It seems someone forgot that Fedora adopted /usr Merge method since the 17 release [3,4] which should look like -- Installing: /builddir/build/BUILDROOT/partio-1.10.1-3.fc33.x86_64/builddir/build/BUILD/partio-1.10.1/Linux-5.6.15-x86_64-optimize/usr/lib64/libpartio.so.1.5.2 Although the optimization is welcome, that issue should get addressed to avoid confusion among maintainers. Thank you. References: [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=47438458 [2] https://kojipkgs.fedoraproject.org//work/tasks/8470/47438470/build.log [3] https://fedoraproject.org/wiki/Features/UsrMove [4] https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ 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: fedora-minimal container and registry negative feedback
On Sun, Jul 19, 2020 at 11:12:53AM +0200, Athos Ribeiro wrote: > On Tue, Jun 30, 2020 at 09:22:45AM +, Dridi Boukelmoune wrote: > > > The tag page for fedora-minimal seems to be working > > > https://registry.fedoraproject.org/repo/fedora-minimal/tags/. Do you have > > > a link of the page that is blank ? > > I get a blank page for this one as well (and for all the other tag > pages). > > This used to work though, and there hasn't been any changes in the reg > package. > > Could anyone take a look in the `reg server` logs and also check if the > static content has been generated? It has not. I did a bit of investigation, but I could not get it working. It may be related to missing signatures after the datacenter move. I've filed: https://pagure.io/fedora-infrastructure/issue/9149 with my findings. kevin -- > > > That's the very link from which I get a blank page, and Firefox > > reports an empty resource (^U to view source). > > > > The developer console on the other hand gives me the following warning: > > > > > The character encoding of the HTML document was not declared. The > > > document will render with garbled text in some browser configurations > > > if the document contains characters from outside the US-ASCII range. > > > The character encoding of the page must be declared in the document > > > or in the transfer protocol. > > > > Which is logical since the content-type header doesn't give a charset and > > the response body is empty. > > > > Trying with curl -v I see the following response: > > > > < HTTP/2 200 > > < date: Tue, 30 Jun 2020 09:18:47 GMT > > < server: Apache > > < strict-transport-security: max-age=31536000; includeSubDomains; preload > > < x-frame-options: SAMEORIGIN > > < x-xss-protection: 1; mode=block > > < x-content-type-options: nosniff > > < referrer-policy: same-origin > > < last-modified: Tue, 30 Jun 2020 08:25:07 GMT > > < etag: "0-5a948e9b307cf" > > < accept-ranges: bytes > > < content-length: 0 > > < apptime: D=193 > > < x-fedora-proxyserver: proxy10.iad2.fedoraproject.org > > < x-fedora-requestid: XvsDdwgZ9DOnVuTIdll6NQE > > < content-type: text/html > > > > Note the explicit zero content length. > > > > HTH, > > Dridi > > ___ > > 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 > ___ > 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 signature.asc Description: PGP signature ___ 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: fedbot spamming in #fedora
On Fri, Jul 17, 2020 at 05:34:13PM +0200, Germano Massullo wrote: > Is it necessary to have in #fedora IRC channel, fedbot spamming 48 times > per day about Fedora respins update? > > [16:51] *** F32-20200715 updated lives available: > https://tinyurl.com/Live-respins2 Built by the Fedora Respin Sig more > info #fedora-respins *** Copying jbwilla on this for comment. kevin signature.asc Description: PGP signature ___ 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: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
On Mon, Jul 13, 2020 at 10:17:11AM +0200, Nicolas Mailhot via devel wrote: > Le dimanche 12 juillet 2020 à 13:07 -0700, Kevin Fenzi a écrit : > > On Sun, Jul 05, 2020 at 02:15:23PM +0200, Nicolas Mailhot via devel > > wrote: > > > > > > This is now done in the latest code refresh and in the test copr > > > https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/bc4e6a79355f3a2b73abeea7e5c0e1f53b09579e?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump > > > https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/ > > > > > > I fleshed out the change page a little too > > > https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping > > > > So I finally carved out a few minutes to look at this, but... > > Thank you for taking a look at it > > > > > https://copr-dist-git.fedorainfracloud.org/cgit/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/sil-charis-fonts.git > > seems to not exist? Is that some copr issue? > > I honestly do not know. The copr was created with a mass import of > srpms themselves created by rpmbuild -bs. I mainly use copr to check > the srpm I build locally in mock work in another system before feeding > them to koji, so I never used the git part of copr much. ok. No worries. > > Looking in the src.rpms I see some of the files I want to look at are > > oddly empty? > > > > ➜ ~ od -c rpmbuild/SOURCES/buildsys.conf > > 000 \n > > 016 > > > > Is that because it's the 'before' src.rpm without the version > > information injected yet? > > Yes, almost all of the srpm have not been bumped before they were fed > to copr, so they only include the minimal whitespace necessary for > rpmbuild to register them as sources (the evil "your source is less > than 13 bytes" rpmbuild assertion). > > IIRC, I scratched sources for most of them to check the new spectool > had not problem with the specs, so they won’t have any bump history in > them. > > You have an example of bumped srpm in adf-accanthis-fonts (with an > almost full buildsys.conf though this package do not use the postbuild > counter). > > > Might be nice for these files to have a small > > doc block at the top? > > The detached changelog – certainly not, that would complexify its > maintenance quite a lot. The conf file, why not, that’s fairly trivial > to add. > > Tough it is a litteral key = value file with no fancy formatting nor > even ini-like sections, and a handful of variables. Very boring KISS > stuff. Sure, but a file with 16 spaces and a newline is pretty confusing. > > Or at least the wiki page could explain each file, > > whats in it and whats the format for it. > > > > I really dislike having a second commit to say 'yes, this build was > > the last one'. Could you generate that info in advance and just > > commit it before the build? > > Well I really dislike people who commit that a build happened when it > has not yet, and who rewrite git history multiple times to "fix" when > they guess wrong:) Or worse, who do *not* rewrite git, and have a > changelog that clearly does not correspond to their build history. But then you know that exact thing was built. With this setup you look at the git hash in koji and... it's the next commit after that thats exactly this build? Thats really messy. > > The release part of autobumping will only happen if the spec needs it. > ie if the release the packager stored in the spec already makes the evr > newer than the last recorded evr no bump will happen. Changelog, not > sure, I suppose I could tie it up to release bumping so if one does not > happen the other does not happen either (that would make the code more > complex, but not too hard to add). > > However, is not possible and it won’t be possible to pre-fill > buildsys.conf because the decision to bump or not is made by comparing > the current evr to the one stored in there. So if you pre-bump the > file, the logic will decide you have already done the corresponding > build (which, if I follow you correctly will be *true*) and add another > release bump to make sure two consecutive builds in a branch have > different evrs. Right, I was suggesting _changing_ your macros for this workflow. maintainer makes changes, runs scratch builds, tests, etc. They decide everything is good for an official build. They generate the files and the macros just use those generated files, they don't bump anything or require a post build checkin. > > Basically, what you want is to reproduce a build you already did some > other way. Then just set the variable that triggers reproducible mode > and you’ll be done (that would require koji/copr cooperation however). > > If anything changed in the buildroots you build against your build may > fail the same way it fails today, and your git and changelog will be a > lie the same way they are a lie today, but
Re: Remove all non UK/USA English spell checker variants from default Fedora installation
British English is not a dialect. As for being the most commonly used by non-native speakers I disagree. That largely depends on where those non-native speakers are from. In many countries "the" English is British, with the US spelling being a movie/gaming thing. For many, the default when they go to school is British spelling and they're even told that that's "the only one correct". Said that, what exactly are we gaining by not adding UK ? Regards, Silvia FAS: Lailah On Sun, 19 Jul 2020 at 17:47, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Jul 18, 2020 at 03:21:41PM +0200, Kevin Kofler wrote: > > Germano Massullo wrote: > > > Since the huge list is brought by hunspell-en, can we just ship Fedora > > > with hunspell-en-GB and hunspell-en-US ? > > > > I would even argue for shipping en_US only. It is the default language > of > > the distribution. Why would British be any more worth shipping than any > > other language out there? > > +1. en_US the default and the most commonly used English dialect, with > en_US messages often used by people who are not native speakers. All > other dialects are mostly of interest for speakers of that dialect and > don't need to be shown by default. > > 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 > ___ 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: Remove all non UK/USA English spell checker variants from default Fedora installation
On Sat, Jul 18, 2020 at 03:21:41PM +0200, Kevin Kofler wrote: > Germano Massullo wrote: > > Since the huge list is brought by hunspell-en, can we just ship Fedora > > with hunspell-en-GB and hunspell-en-US ? > > I would even argue for shipping en_US only. It is the default language of > the distribution. Why would British be any more worth shipping than any > other language out there? +1. en_US the default and the most commonly used English dialect, with en_US messages often used by people who are not native speakers. All other dialects are mostly of interest for speakers of that dialect and don't need to be shown by default. 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
Re: Remove all non UK/USA English spell checker variants from default Fedora installation
On 7/18/20 8:44 AM, Germano Massullo wrote: All desktop oriented Fedora installers install on the system packages: hunspell hunspell-en hunspell-en-GB hunspell-en-US When a user opens the language list of the spell checker, is has ~24 different English options, like English (Antigua and Barbuda), English (Australia), English (Bahamas), English (Belize), etc. (See screenshot [1]) People who are not native English speakers have this list even bigger because they will have their own language entry, plus others. That will be a good enhancement but I would argue that all country specific dictionaries should be on their own package. The Spanish list is no small either, that the Firefox and Thunderbird UI for selection becomes a popup menu bigger than most screens Since the huge list is brought by hunspell-en, can we just ship Fedora with hunspell-en-GB and hunspell-en-US ? Another option could be to move all non GB/USA English variants to other hunspell-en-* packages as I said in ticket [2] [1]: https://bugzilla.redhat.com/attachment.cgi?id=1701536 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1858241 ___ 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 ___ 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
Fedora rawhide compose report: 20200719.n.0 changes
OLD: Fedora-Rawhide-20200718.n.1 NEW: Fedora-Rawhide-20200719.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 10 Downgraded packages: 1 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 141.32 MiB Size of downgraded packages: 285.06 KiB Size change of upgraded packages: 1.81 MiB Size change of downgraded packages: 44 B = ADDED IMAGES = Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20200719.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: 7kaa-2.15.4p1-1.fc33 Old package: 7kaa-2.15.4-1.fc33 Summary: Seven Kingdoms: Ancient Adversaries RPMs: 7kaa 7kaa-data Size: 36.37 MiB Size change: -367 B Changelog: * Tue Jul 14 2020 Andy Mender - 2.15.4p1-1 - Bump version and add note about music files to description Package: capnproto-0.8.0-1.fc33 Old package: capnproto-0.7.0-6.fc33 Summary: A data interchange format and capability-based RPC system RPMs: capnproto capnproto-devel capnproto-libs Size: 10.67 MiB Size change: 748.12 KiB Changelog: * Sat Jul 18 2020 Neal Gompa - 0.8.0-1 - Update to 0.8.0 (#1827443) - Drop backported patches Package: dummy-test-package-crested-0-835.fc33 Old package: dummy-test-package-crested-0-832.fc33 Summary: Dummy Test Package called Crested RPMs: dummy-test-package-crested Size: 58.78 KiB Size change: 92 B Changelog: * Sat Jul 18 2020 packagerbot - 0-833 - rebuilt * Sat Jul 18 2020 packagerbot - 0-834 - rebuilt * Sun Jul 19 2020 packagerbot - 0-835 - rebuilt Package: dummy-test-package-gloster-0-927.fc33 Old package: dummy-test-package-gloster-0-923.fc33 Summary: Dummy Test Package called Gloster RPMs: dummy-test-package-gloster Size: 64.17 KiB Size change: 196 B Changelog: * Sat Jul 18 2020 packagerbot - 0-924 - rebuilt * Sat Jul 18 2020 packagerbot - 0-925 - rebuilt * Sat Jul 18 2020 packagerbot - 0-926 - rebuilt * Sun Jul 19 2020 packagerbot - 0-927 - rebuilt Package: golang-github-klauspost-compress-1.10.10-1.fc33 Old package: golang-github-klauspost-compress-1.10.9-1.fc33 Summary: Optimized compression packages RPMs: golang-github-klauspost-compress-devel Size: 290.67 KiB Size change: -19.88 KiB Changelog: * Sat Jul 18 2020 Dominik Mierzejewski - 1.10.10-1 - update to 1.10.10 (#1850299) Package: mir-1.8.0-2.fc33 Old package: mir-1.8.0-1.fc33 Summary: Next generation display server RPMs: mir-client-libs mir-common-libs mir-demos mir-devel mir-doc mir-server-libs mir-test-libs-static mir-test-tools mir-utils python3-mir-perf-framework Size: 21.47 MiB Size change: 1.76 KiB Changelog: * Sat Jul 18 2020 Neal Gompa - 1.8.0-2 - Rebuilt for capnproto 0.8.0 Package: nbdkit-1.21.19-1.fc33 Old package: nbdkit-1.21.18-1.fc33 Summary: NBD server RPMs: nbdkit nbdkit-bash-completion nbdkit-basic-filters nbdkit-basic-plugins nbdkit-cc-plugin nbdkit-cdi-plugin nbdkit-curl-plugin nbdkit-devel nbdkit-example-plugins nbdkit-ext2-filter nbdkit-guestfs-plugin nbdkit-gzip-filter nbdkit-iso-plugin nbdkit-libvirt-plugin nbdkit-linuxdisk-plugin nbdkit-lua-plugin nbdkit-nbd-plugin nbdkit-ocaml-plugin nbdkit-ocaml-plugin-devel nbdkit-perl-plugin nbdkit-python-plugin nbdkit-ruby-plugin nbdkit-server nbdkit-ssh-plugin nbdkit-tar-filter nbdkit-tar-plugin nbdkit-tcl-plugin nbdkit-tmpdisk-plugin nbdkit-torrent-plugin nbdkit-vddk-plugin nbdkit-xz-filter Added RPMs: nbdkit-cdi-plugin Size: 8.58 MiB Size change: 213.71 KiB Changelog: * Sat Jul 18 2020 Richard W.M. Jones - 1.21.19-1 - New upstream development version 1.21.19. - New nbdkit-cdi-plugin. Package: rr-5.3.0-16.20200427gitbab9ca9.fc33 Old package: rr-5.3.0-14.20200427gitbab9ca9.fc33 Summary: Tool to record and replay execution of applications RPMs: rr rr-testsuite Size: 18.01 MiB Size change: 197.36 KiB Changelog: * Sat Jul 18 2020 Neal Gompa - 5.3.0-15.20200427gitbab9ca9 - Rebuilt for capnproto 0.8.0 * Sat Jul 18 2020 Neal Gompa - 5.3.0-16.20200427gitbab9ca9 - Rebuilt for capnproto 0.8.0 again Package: sonic-visualiser-4.1-1.fc33 Old package: sonic-visualiser-4.0.1-1.fc32 Summary: A program for viewing and exploring audio data RPMs: sonic-visualiser Size: 20.08 MiB Size change: 635.97 KiB Changelog: * Sat Jul 18 2020 Neal Gompa - 4.0.1-2 - Rebuilt for capnproto 0.8.0 * Sat Jul 18 2020 Neal Gompa - 4.1-1 - Update to 4.1 Package: zabbix-1:4.0.22-1.fc33 Old package: zabbix-1:4.0.19-3.fc33 Summary: Open-source monitoring solution for your IT infrastructure RPMs: zabbix zabbix-agent
Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
Hello, On Sunday, July 19, 2020 2:53:32 AM MDT John M. Harris Jr wrote: > On Sunday, July 19, 2020 1:47:23 AM MST Alexey A. wrote: > > > >Killing users' programs needlessly is not welcome > > > > > > Setting limits for cgroup (MemoryMax, MemorySwapMax) leads to "Killing > > users' programs needlessly": system-wide available memory may be not > > exhausted, but OOM killer will be invoked in this cgroup. > > > I'm sure we can all agree that only killing off the software that people > complain causes these events is better than killing off everything else just > because the system doesn't have a ton of RAM available. > > > > >The goal is to ensure the kernel can keep doing its job, it's > > >not going to try to figure out what you intend for userspace, as well it > > >shouldn't. > > > > > > The goal is to ensure the kernel can keep doing its job *and userspace* > > doing its job. I don't need a system where the kernel is alive, but > > userspace is dead. > > > Userspace isn't dead when a system is thrashing. Your software is still > running. If it gets killed, you're most likely going to lose your data. While this is true, most people will powercycle the machine at this point anyway out of frustration if nothing else. I certainly have powercycled machines in this state before. Powercycling a machine is going to potentially lose more data than just killing a runaway firefox or chrome process. Ariadne ___ 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: fedora-minimal container and registry negative feedback
On Tue, Jun 30, 2020 at 09:22:45AM +, Dridi Boukelmoune wrote: The tag page for fedora-minimal seems to be working https://registry.fedoraproject.org/repo/fedora-minimal/tags/. Do you have a link of the page that is blank ? I get a blank page for this one as well (and for all the other tag pages). This used to work though, and there hasn't been any changes in the reg package. Could anyone take a look in the `reg server` logs and also check if the static content has been generated? That's the very link from which I get a blank page, and Firefox reports an empty resource (^U to view source). The developer console on the other hand gives me the following warning: The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol. Which is logical since the content-type header doesn't give a charset and the response body is empty. Trying with curl -v I see the following response: < HTTP/2 200 < date: Tue, 30 Jun 2020 09:18:47 GMT < server: Apache < strict-transport-security: max-age=31536000; includeSubDomains; preload < x-frame-options: SAMEORIGIN < x-xss-protection: 1; mode=block < x-content-type-options: nosniff < referrer-policy: same-origin < last-modified: Tue, 30 Jun 2020 08:25:07 GMT < etag: "0-5a948e9b307cf" < accept-ranges: bytes < content-length: 0 < apptime: D=193 < x-fedora-proxyserver: proxy10.iad2.fedoraproject.org < x-fedora-requestid: XvsDdwgZ9DOnVuTIdll6NQE < content-type: text/html Note the explicit zero content length. HTH, Dridi ___ 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 ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
> Userspace isn't dead If something looks like dead it is dead. A userspace that does not respond to user actions is a dead userspace. вс, 19 июл. 2020 г. в 17:54, John M. Harris Jr : > On Sunday, July 19, 2020 1:47:23 AM MST Alexey A. wrote: > > >Killing users' programs needlessly is not welcome > > > > Setting limits for cgroup (MemoryMax, MemorySwapMax) leads to "Killing > > users' programs needlessly": system-wide available memory may be not > > exhausted, but OOM killer will be invoked in this cgroup. > > I'm sure we can all agree that only killing off the software that people > complain causes these events is better than killing off everything else > just > because the system doesn't have a ton of RAM available. > > > >The goal is to ensure the kernel can keep doing its job, it's > > >not going to try to figure out what you intend for userspace, as well it > > >shouldn't. > > > > The goal is to ensure the kernel can keep doing its job *and userspace* > > doing its job. I don't need a system where the kernel is alive, but > > userspace is dead. > > Userspace isn't dead when a system is thrashing. Your software is still > running. If it gets killed, you're most likely going to lose your data. > > -- > John M. Harris, Jr. > > ___ > 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 > ___ 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: Remove all non UK/USA English spell checker variants from default Fedora installation
Nicolas Mailhot via devel writes: > Practically some people do care about original English. And, there is > little to win deployment side, In theory there is: common local names of people, places, and organizations. I don't know how many of those English variants include very many of them, though. > all those spellcheckers share a common trunk, the only annoying > cost of more English variants is their footprint in language > selectors Fix the selectors to be multistage. Select English, you get a list of variants, with an initial default to that closest to the system locale. ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Sunday, July 19, 2020 1:47:23 AM MST Alexey A. wrote: > >Killing users' programs needlessly is not welcome > > Setting limits for cgroup (MemoryMax, MemorySwapMax) leads to "Killing > users' programs needlessly": system-wide available memory may be not > exhausted, but OOM killer will be invoked in this cgroup. I'm sure we can all agree that only killing off the software that people complain causes these events is better than killing off everything else just because the system doesn't have a ton of RAM available. > >The goal is to ensure the kernel can keep doing its job, it's > >not going to try to figure out what you intend for userspace, as well it > >shouldn't. > > The goal is to ensure the kernel can keep doing its job *and userspace* > doing its job. I don't need a system where the kernel is alive, but > userspace is dead. Userspace isn't dead when a system is thrashing. Your software is still running. If it gets killed, you're most likely going to lose your data. -- John M. Harris, Jr. ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
>Killing users' programs needlessly is not welcome Setting limits for cgroup (MemoryMax, MemorySwapMax) leads to "Killing users' programs needlessly": system-wide available memory may be not exhausted, but OOM killer will be invoked in this cgroup. >The goal is to ensure the kernel can keep doing its job, it's >not going to try to figure out what you intend for userspace, as well it >shouldn't. The goal is to ensure the kernel can keep doing its job *and userspace* doing its job. I don't need a system where the kernel is alive, but userspace is dead. вс, 19 июл. 2020 г. в 12:42, John M. Harris Jr : > On Saturday, July 18, 2020 6:33:11 PM MST Brandon Nielsen wrote: > > What about the case of the developer whose code accidentally does > > something that blows through all available memory, leading to swap > > thrashing. I've been there. The system is very much unusable, to the > > point where a user without the knowledge of the magic sysrq key will > > almost certainly be reaching for the power button. > > Well, sysrq is disabled by default in Fedora anyway. I get what you mean, > however, as I also re-enable it. > > > Or when a compile takes more memory than you expect, leading to the > > same? Again, I've been there. The system is absolutely unusable for any > > regular user use-case I can think of. > > This is another example that came up, and cgroups can help with that as > well. > > > Decompression "bomb" (malicious or otherwise) on a memory taxed system? > > Again, definitely unusable. > > > > Web browsers are definitely not the only way thrashing can be > > encountered. While I agree resource limits via cgroups or other method > > are needed, an EarlyOOM emergency brake is definitely welcome as well. > > The kernel OOM killer is certainly not adequate for an interactive user > > session in my experience. > > Killing users' programs needlessly is not welcome, at least not by me, and > I'd > certainly hope others wouldn't stand for it either. The correct solution > is to > prevent the few programs that this is an issue with from eating all of our > RAM, not killing everything but those. The kernel OOM killer does its job, > and > it does it well. The goal is to ensure the kernel can keep doing its job, > it's > not going to try to figure out what you intend for userspace, as well it > shouldn't. > > -- > John M. Harris, Jr. > > ___ > 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 > ___ 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
