You may have seen, a few days ago, that the Fedora project announced[1]
a new Code of Conduct for their community.
What you may not have known is that the CentOS project was involved in
the crafting of that Code, so that we could also use it here.
Yeah, I know, this is something we should have done a long time ago.
But, you know what they say about the best time to plant a tree. (The
best time to plant a tree is 20 years ago. The second best time is today.)
As we continue to work to make all aspects of the CentOS Project more
open and transparent, it is important that we create an open, welcoming
community where all people, from all backgrounds, feel safe in their
participation. This allows for a broader contributor pool, with more
ideas and more community ownership of the resulting outcomes.
And it's just the right thing to do.
It is our intent to take the text of the Fedora CoC, and replace
'Fedora' with 'CentOS' everywhere, and propose it here. There will, of
course, be other small changes to the text (Board vs Council, and so on)
but not to the details of the Code itself, and how we intend to address
reports. We're holding off on those edits so that our version doesn't
drift from theirs, during their 2 week comment period. (Ends April 26th.)
The document is derived from the Contributor Covenant, along with work
that has been ongoing in the Fedora project for some time. Note also
that the Contributor Covenant is also the source material for the CoC
used by the Linux kernel project.[2]
To that end, we encourage you to engage in the discussion around the
Fedora CoC, because any changes made there will influence what we end up
with here. And we also encourage discussion on centos-devel[3], for
anything that you feel is specific to our community.
--Rich, on behalf of the CentOS Board of Directors
[1]
https://communityblog.fedoraproject.org/policy-proposal-new-code-of-conduct/
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
[3] https://lists.centos.org/mailman/listinfo/centos-devel
Hello,
I recently packaged a utility in Fedora 34[1] that enterprise cloud users
might find helpful so I'd like to package it for CentOS 8 Stream and
CentOS 9 Stream as well.
I've been following the CentOS Stream Contributing wiki page[2] to
figure out how to get started with this. However, it seems like all of
these instructions are only relevant if the package that someone would
want to contribute to already has its own repo in the dist-git.
I've made some good progress on the CentOS 8 Stream package already, and
I'm used to the Fedora process where this is about the time that I'd post
it for review soon as part of the authorization process for getting a new
repo in the dist-git.
Is there a CentOS equivalent to the Fedora package review process for
getting a repo created?
Thank you,
Connor
[1] https://src.fedoraproject.org/rpms/rust-sevctl
[2] https://wiki.centos.org/Contribute/CentOSStream
Hi,
while verifying https://gerrit.ovirt.org/#/c/ovirt-release/+/114299/
noticed we are missing Advanced Virtualization builds for aarch64 and
ppc64le on CentOS Stream.
I guess it's similar to what happened with ovirt 4.4 and tracked here:
https://pagure.io/centos-infra/issue/254
Eduardo can you follow up on this and ensure we have ppc64le and aarch64
packages there?
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://www.redhat.com/>
*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.*
Hi everyone,
I would like to share with you all a proposal I have submitted on creating
a SIG dedicated to reviewing and triaging feature requests that come from
CentOS Stream development intended for future RHEL releases.
The full proposal can be read on the CentOS wiki [0] and an issue has been
opened on the CentOS board tracker [1] for review and decision.
Here is the proposal summary and I welcome any thoughts, feedback and
discussion:
Purpose
The purpose of this SIG will be to serve as a gate for feature requests
that are first developed in CentOS Stream from contributors who wish to
request these features to be included in future RHEL releases and are then
filed in bugzilla. The SIGs overall goal is to make sure that features
which have been filed and have technical merit are triaged internally to
the correct venue for further review and development. The SIG will take
ownership of regular bugzilla reviews filed under Stream and map feature
requests from these bugzillas against the formal RHEL Feature Request
criteria to identify and file qualifying requests inside Red Hat to achieve
this.
I hope you all have a lovely weekend!
Kindest regards,
Aoife,
[0] - https://wiki.centos.org/SpecialInterestGroup/StreamFeatureRequest
[1] - https://git.centos.org/centos/board/issue/33
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
Hi,
There are 2 versions of squid module available for CentOS 8
http://mirror.centos.org/centos-8/8.3.2011/AppStream/x86_64/os/Packages/
squid-4.4-8.module_el8.3.0+623+2bb85980.2.x86_64.rpm
squid-4.11-3.module_el8.3.0+558+7bf80f5f.x86_64.rpm
But the output of yum module info does not give corresponding information
[root@127162ed7c15 /]# yum module info squid
Last metadata expiration check: 0:00:12 ago on Tue Apr 13 18:15:31 2021.
Name : squid
Stream : 4 [d][a]
Version : 8030020201223011621
Context : 30b713e6
Architecture : x86_64
Profiles : common [d]
Default profiles : common
Repo : appstream
Summary : Squid - Optimising Web Delivery
Description : an initial version of the squid caching proxy module
Requires : platform:[el8]
Artifacts : libecap-0:1.0.1-2.module_el8.3.0+395+6cb406eb.src
: libecap-0:1.0.1-2.module_el8.3.0+395+6cb406eb.x86_64
: libecap-debuginfo-0:1.0.1-2.module_el8.3.0+395+6cb406eb.x86_64
: libecap-debugsource-0:1.0.1-2.module_el8.3.0+395+6cb406eb.x86_64
: libecap-devel-0:1.0.1-2.module_el8.3.0+395+6cb406eb.x86_64
: squid-7:4.4-8.module_el8.3.0+623+2bb85980.2.src
: squid-7:4.4-8.module_el8.3.0+623+2bb85980.2.x86_64
: squid-debuginfo-7:4.4-8.module_el8.3.0+623+2bb85980.2.x86_64
: squid-debugsource-7:4.4-8.module_el8.3.0+623+2bb85980.2.x86_64
One thing is, I would have expected both versions of squid listed. But CentOS repodata seems to generally list one version of the module?
The other thing is that squid 4.4-8 has a modification date 2020-12-23 02:14, while squid 4.11-3 dates from 2020-11-04 02:43.
The newer package is older, so only the older package is made available?
kind regards, markus
Hello,
My name is Louis and I'm the core maintainer of Clar:
https://github.com/quay/clair
Clair is a project for scanning containers for vulnerabilities.
We'd like to support CentOS but we need a little help in the form of
information gathering.
For Clair to properly support a distribution we typically require it to
have an official upstream vulnerability database. For example, RHEL has
their own Oval 2 feeds as does
Ubuntu, Suse, etc...
What we are trying to determine is how we can extract packages from CentOS
containers and match against known vulnerabilities.
We have the first half worked out already, we have generic RPM database
scanners which extract package names and versions.
The second half is where we need some more information.
A few questions:
* Does CentOS maintain its own security database for packages in its
downstream repositories ?
* If not, can we reliably treat any CentOS packages (name, versions)
identical to the way we treat RHEL packages. (For instance if we find
package A with version B can we attempt to match this against RHEL's Oval
v2 stream?)
* Can you provide any information on package naming, versioning, and
packaging that creates a difference between RHEL packages and CentOS?
Thank you for your time, I look forward to hearing back.
Rich, everyone!
I've been re-designing the web browser's default page and am wondering
what content you think it should have in order to be great?
I would like to make a collaborative effort of it and am looking for
the correct way to do it in our community.
This is a welcome page. The first we'll see when the web browser is
opened. It also would be visible in the screenshot section the wiki has
on the front page (following Akemi's tradition here :)
https://gitlab.com/areguera/centos-indexhtml
Best regards,
--
Alain Reguera Delgado <alain.reguera(a)gmail.com>