Re: Coq uninstallable - requires antlr4-python3-runtime = 1:4.7.2-4.fc32?
On Fri, Dec 06, 2019 at 07:42:47PM +0900, Mamoru TASAKA wrote: > Richard W.M. Jones wrote on 2019/12/06 19:22: > >On Thu, Dec 05, 2019 at 04:12:23PM -0700, Jerry James wrote: > >>Hi Richard, > >> > >>On Thu, Dec 5, 2019 at 3:56 PM Richard W.M. Jones wrote: > >> > >>>Just built coq in a side tag for OCaml 4.09. However it > >>>can't install for the next build: > >>> > >>>DEBUG util.py:596: Error: > >>>DEBUG util.py:596: Problem: conflicting requests > >>>DEBUG util.py:596:- nothing provides antlr4-python3-runtime = > >>>1:4.7.2-4.fc32 needed by coq-8.9.1-7.fc32.x86_64 > >>> > >>>Any ideas on this one? Latest antlr4 package is 4.5.something ... > >>> > >> > >>Yes, this is an absolutely horrible bit of brain damage. I've been trying > >>for quite a long time now to get the antlr maintainers to (a) update to > >>4.7.x and (b) add the python3 runtime as a subpackage. I've discussed this > >>on fedora-devel-list and there's still an open bug about it. I've been > >>told a few times that it is being worked on, yet it somehow keeps failing > >>to arrive. > >> > >>Since coq *must* have the python3 runtime, and it *must* be version 4.7.2 > >>or later, I bundled the python runtime into the coq package last January, > >>because coq was completely broken for F29. Nothing has changed since. > >> > >>So to build coq and have the result be installable, in addition to bumping > >>Release, you also have to bump antlr4rel (see line 5 of coq.spec). > >> > >>This is stupid and wrong and I hate it, but it isn't going to change until > >>somebody actually starts maintaining the antlr package. > > > >I suppose I misunderstood what needs to be done. I bumped antlr4rel > >on line 5 of coq.spec, rebuilt coq, but it is still uninstallable, > >see: > > > >https://kojipkgs.fedoraproject.org//work/tasks/7837/39447837/root.log > > > >Rich. > > > > You have to remove extra .1 from > https://src.fedoraproject.org/rpms/coq/blob/master/f/coq.spec#_143 > and bump %antlr4rel again. It's working after that, thanks. 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://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: Coq uninstallable - requires antlr4-python3-runtime = 1:4.7.2-4.fc32?
Richard W.M. Jones wrote on 2019/12/06 19:22: On Thu, Dec 05, 2019 at 04:12:23PM -0700, Jerry James wrote: Hi Richard, On Thu, Dec 5, 2019 at 3:56 PM Richard W.M. Jones wrote: Just built coq in a side tag for OCaml 4.09. However it can't install for the next build: DEBUG util.py:596: Error: DEBUG util.py:596: Problem: conflicting requests DEBUG util.py:596:- nothing provides antlr4-python3-runtime = 1:4.7.2-4.fc32 needed by coq-8.9.1-7.fc32.x86_64 Any ideas on this one? Latest antlr4 package is 4.5.something ... Yes, this is an absolutely horrible bit of brain damage. I've been trying for quite a long time now to get the antlr maintainers to (a) update to 4.7.x and (b) add the python3 runtime as a subpackage. I've discussed this on fedora-devel-list and there's still an open bug about it. I've been told a few times that it is being worked on, yet it somehow keeps failing to arrive. Since coq *must* have the python3 runtime, and it *must* be version 4.7.2 or later, I bundled the python runtime into the coq package last January, because coq was completely broken for F29. Nothing has changed since. So to build coq and have the result be installable, in addition to bumping Release, you also have to bump antlr4rel (see line 5 of coq.spec). This is stupid and wrong and I hate it, but it isn't going to change until somebody actually starts maintaining the antlr package. I suppose I misunderstood what needs to be done. I bumped antlr4rel on line 5 of coq.spec, rebuilt coq, but it is still uninstallable, see: https://kojipkgs.fedoraproject.org//work/tasks/7837/39447837/root.log Rich. You have to remove extra .1 from https://src.fedoraproject.org/rpms/coq/blob/master/f/coq.spec#_143 and bump %antlr4rel again. Regards, Mamoru ___ 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: Should we discontinue the Python Classroom Lab?
Le jeudi 05 décembre 2019 à 16:42 -0700, John M. Harris Jr a écrit : > > Why in the world was Docker removed? Docker is the most popular > container > technology, so if we must embrace the "container" systems, why not > include the most popular in Fedora? Because moby (née docker) is a trainwreck on the technical side (sky- high bundling of git snapshots, with disagreement on the correct snapshot to bundle between various components, that make maintaining docker, and pulling it forward, for example for changes cgroup-side, a major endeavour). In other words: classical technical debt accumulations. Lots of unhealthy technical compromises, to be first to market, and get adopted (that worked fine), and no plan to deal with what happens afterwards (long term maintenance, evolution, and support). Regards, -- Nicolas Mailhot ___ 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: Coq uninstallable - requires antlr4-python3-runtime = 1:4.7.2-4.fc32?
On Thu, Dec 05, 2019 at 04:12:23PM -0700, Jerry James wrote: > Hi Richard, > > On Thu, Dec 5, 2019 at 3:56 PM Richard W.M. Jones wrote: > > > Just built coq in a side tag for OCaml 4.09. However it > > can't install for the next build: > > > > DEBUG util.py:596: Error: > > DEBUG util.py:596: Problem: conflicting requests > > DEBUG util.py:596:- nothing provides antlr4-python3-runtime = > > 1:4.7.2-4.fc32 needed by coq-8.9.1-7.fc32.x86_64 > > > > Any ideas on this one? Latest antlr4 package is 4.5.something ... > > > > Yes, this is an absolutely horrible bit of brain damage. I've been trying > for quite a long time now to get the antlr maintainers to (a) update to > 4.7.x and (b) add the python3 runtime as a subpackage. I've discussed this > on fedora-devel-list and there's still an open bug about it. I've been > told a few times that it is being worked on, yet it somehow keeps failing > to arrive. > > Since coq *must* have the python3 runtime, and it *must* be version 4.7.2 > or later, I bundled the python runtime into the coq package last January, > because coq was completely broken for F29. Nothing has changed since. > > So to build coq and have the result be installable, in addition to bumping > Release, you also have to bump antlr4rel (see line 5 of coq.spec). > > This is stupid and wrong and I hate it, but it isn't going to change until > somebody actually starts maintaining the antlr package. I suppose I misunderstood what needs to be done. I bumped antlr4rel on line 5 of coq.spec, rebuilt coq, but it is still uninstallable, see: https://kojipkgs.fedoraproject.org//work/tasks/7837/39447837/root.log Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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 mirror selection (was: Allow comments and discussion even though an update was pushed) to stable
On Friday, 06 December 2019 at 10:57, Petr Pisar wrote: [...] > Maybe DNF could support setting a prefered mirror while still checking > for the latest metadata because in my experience the automatic mirror > selection does not always provide the best performance. (E.g. when > I connected an IPv6 only host in Germany, it resorted to a USA mirror.) I got hit by that as well when I deployed IPv6. GeoIP/geolite2 simply has wrong information about where your IP is located. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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: Allow comments and discussion even though an update was pushed to stable
On 2019-12-06, Johannes Lips wrote: > It really depends which mirrors you are using and if you are unlucky > the updates get pushed to stable, before it reaches updates-testing > for you and then again there's nothing to add, once it's pushed. > If you use metalink in your repository configuration (a default configuration), DNF always asks Fedora servers for the metadata. Thus DNF always gets the latest metadata. Then when downloading packages, outdated mirros are automatically excluded. If you manually changed the configuration to baseurl, then you deliberately bypass Fedora infrastructure and you are at the mercy of the mirror administrators. Maybe DNF could support setting a prefered mirror while still checking for the latest metadata because in my experience the automatic mirror selection does not always provide the best performance. (E.g. when I connected an IPv6 only host in Germany, it resorted to a USA mirror.) -- Petr ___ 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
[Test-Announce] Fedora 32 Rawhide 20191206.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 32 Rawhide 20191206.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: pungi - 20191203.n.1: pungi-4.1.41-1.fc32.src, 20191206.n.0: pungi-4.1.41-2.fc32.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/32 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191206.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191206.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191206.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191206.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191206.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191206.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191206.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-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/test-annou...@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: Modularity and all the things
On 2019-12-05, Brian (bex) Exelbierd wrote: > --===6343409591866461936== > Content-Type: multipart/alternative; boundary="3a3ad80598f34f04" > > --3a3ad80598f34f04 > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > On Wed, Nov 20, 2019 at 12:13 PM Petr Pisar wrote: > >> On 2019-11-19, John M. Harris Jr wrote: >> > On Tuesday, November 19, 2019 4:42:31 AM MST Petr Pisar wrote: >> >> Manual work. Random commiters skipping them. >> > >> > If your goal is to make it so that "Random commiters" are packagers, >> that's >> > going to fall flat very quickly - as they'll just throw one version of >> the >> > package in, never think about it again. That is an untenable situation. >> > >> No. Random commiter is some one who does not know that the two >> branches have to be kept in synchronization. In other words someone else >> than the maintainer. E.g. If there is a guideline change or a SONAME >> bump then somebody touches your package. >> > > While not perfect, this would be an ideal use of the README file in the > master branch. This could specify things like, where to report bugs, if a > proven packager should try to contact the customary maintainer in advance, > if possible, how branches are maintained, etc. > You don't need a README. We have Bugzilla entry for each component. Morover nobody's going to checkout master branch if he's going to commit into a different branch. And nobody's going to read any READMEs if he's going change hunders or thousands of packages. I'm sorry but that does not scale. -- Petr ___ 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-Cloud-31-20191206.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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: Allow comments and discussion even though an update was pushed to stable
On Fri, Dec 06, 2019 at 07:51:40AM +0100, Fabio Valentini wrote: >On Fri, Dec 6, 2019, 07:35 Johannes Lips <[1]johannes.l...@gmail.com> >wrote: > > Hi all, > > I was recently bit by a bug, which was caused by a mismatch between > texlive-biblatex and biber. The technical side is not so important, only > so much that they need each other in a pretty specific version, which is > not reflected on the rpm level. > What I found weird is that you can't comment on an update, which is > already pushed to stable. A lot of users are only hit by a bug, once it > reaches stable and then you don't have any possibility to highlight a > bug report or an issue with this update. > >I agree, this is definitely a regression with newer bodhi versions (5.0+ I >think). I also often get hit by bugs in updates that are either queued for >stable, or already pushed. The best place to discuss this is likely the upstream issue tracker and more precisely, likely this ticket: https://github.com/fedora-infra/bodhi/issues/3748 Pierre ___ 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: Allow comments and discussion even though an update was pushed to stable
On Fri, Dec 6, 2019, 08:46 Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > Il 06/12/19 07:34, Johannes Lips ha scritto: > > Hi all, > > > > I was recently bit by a bug, which was caused by a mismatch between > texlive-biblatex and biber. The technical side is not so important, only so > much that they need each other in a pretty specific version, which is not > reflected on the rpm level. > > What I found weird is that you can't comment on an update, which is > already pushed to stable. A lot of users are only hit by a bug, once it > reaches stable and then you don't have any possibility to highlight a bug > report or an issue with this update. I would like to have the possibility > to add such an information to an update, which introduced the issue. > That was requested and discussed long time ago in > https://github.com/fedora-infra/bodhi/issues/2050 > > The rationale behind this was about the nonsense to have users > commenting on an already pushed update, since this cannot be undone. > > My opinion is that once an update is pushed to stable, new bugs should > be reported in Bugzilla, not as comments in Bodhi. However there's an > open discussion about restoring the previous behavior: > https://github.com/fedora-infra/bodhi/issues/3748 > > > Also I would like to ask if it is possible for important updates, like > the texlive one to increase the stable karma. It really depends which > mirrors you are using and if you are unlucky the updates get pushed to > stable, before it reaches updates-testing for you and then again there's > nothing to add, once it's pushed. > > > The stable-karma and stable-days parameters can be set by the user in > the web form or by CLI. By default stable-karma is set to 3, but it can > be changed when creating the update. > Right. So should the default of -3/+3 be changed for "critpath" packages? They already need 14 days in testing, but they also get orders of magnitude more feedback, so raising the karma limits to -2/+6 or something like that sounds reasonable to me. On the other hand, I wouldn't even have any objections to changing the defaults to something like -2/+6 for all packages, since it wouldn't make any difference at all for the majority of packages that reach 7 days in testing without any feedback whatsoever. Fabio > Mattia > > > ___ > 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
Unresponsive maintainer: moezroy / Moez Roy (davfs2)
Hi, following the policy for non-responsive package maintainers [0], I'm asking here if anybody knows how to contact moezroy (Moez Roy). Moez, if you're still interested in maintaining your packages, please respond. There several open bugs without response [1], including bug 1762083 [2] where a user tried several times to get a response. I submitted a simple pull request [3] which fixes the license declaration (davfs2 switched its license 10 years ago!) and enables source file verification but no response there either. (I also sent a direct email in November.) Mandatory non-responsive maintainer bug: https://bugzilla.redhat.com/show_bug.cgi?id=1780491 Felix [0]: https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ [1] https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=moez.roy%40gmail.com_to1=1=substring_id=10696936_format=advanced [2] https://bugzilla.redhat.com/show_bug.cgi?id=1762083 [3] https://src.fedoraproject.org/rpms/davfs2/pull-request/1 ___ 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
SSL_DEFAULT_CIPHER_LIST vs PROFILE=DEFAULT vs no set_cipher_list()
https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/#_cc_applications
says that I need to patch application (if it does not have config
file) to use "PROFILE=SYSTEM" as the argument to the cipher list.
However, when I was looking into the library which uses this function
(rust-openssl), I found following piece of code:
/// Creates a new builder for TLS connections.
///
/// The default configuration is subject to change, and is
currently derived from Python.
pub fn builder(method: SslMethod) -> Result {
let mut ctx = ctx(method)?;
ctx.set_default_verify_paths()?;
ctx.set_cipher_list(
"DEFAULT:!aNULL:!eNULL:!MD5:!3DES:!DES:!RC4:!IDEA:!SEED:!aDSS:!SRP:!PSK",
)?;
setup_verify( ctx);
Ok(SslConnectorBuilder(ctx))
}
https://github.com/sfackler/rust-openssl/blob/9ba802ad437447ac71f99d89653b35072bf5ccd9/openssl/src/ssl/connector.rs#L62-L74
Then I looked at CPython and found that it does this:
/* Ignored in SSLContext constructor, only used to as
_ssl.DEFAULT_CIPHER_STRING */
#define PY_SSL_DEFAULT_CIPHER_STRING SSL_DEFAULT_CIPHER_LIST
And then it just ignores call to SSL_CTX_set_cipher_list().
So my question would be: Should I patch rust-openssl to use
PROFILE=DEFAULT or I should just remove that call entirely? It is not
very clear to me from the guidelines. Also since I want to get this
upstream, which option is more portable?
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default
On Do, 05.12.19 16:33, John M. Harris Jr (joh...@splentity.com) wrote: > > Locking down the OS itself and locking down the user's home are two > > different things, because OS integrity should be bound to different > > mechanisms than user data encryption. (i.e. OS integrity should be > > bound to vendor trust or TPM, while user data should be bound to > > user's security credentials). > > I could not disagree more. That would be fine if the trust were the user or > the organization that owns the machine, but not vendor trust or anything of > the like. It's not some third party's system, it's the user or organization's. > Additionally, it's much easier to get a third party to sign something for you > than to get the users themselves, or an organization, to sign it. Humm, so you turn off gpg verification of RPMs you install? Nah, you don't, because you put trust in Fedora that the RPMs they build are somewhat safe to use. That's what vendor trust means. Since regular users (and even very technical ones) cannot personally validate the trustworthiness of compiled code we outsource that to distributions, and trust the vendor's benevolence and understanding of things. And that's the correct way to build integrity for OS resources. Lennart -- Lennart Poettering, Berlin ___ 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
