June 2021 - devel - lists.centos.org

forums + portal for {lang}.centos.org sites
by Karanbir Singh 16 Aug '24

16 Aug '24

Hi, Earlier in the evening today Ralph, Fabian and I had a chat about the present state of the language subsites. This email sort of summarises the main issue ( s/w ). We seem to have run into a slight technical hitch with punbb/fluxbb. They dont support LDAP as a backend. And we had decided a few months back that all new rollouts must have ldap backend so we can rollin CentOS-DS / openldap based backend. So we need to look at alternatives, and since the primary focus of these international sites is going be forums : Here is a shortlist ( if there is anything else that people are aware of, please add to this list ) - phpBB - SMF - Fudforum - phorum - fluxbb Requirements: - Must be able to scale ( couple of hundred thousand msgs ) - Must be able to handle ldap auth ( if it cant, whats involved in writing the ldap-auth portion ) - Must address the specific requirements raised by the present www.centos.org forum users ( Can you please fill this section in ? ) - Must support all languages we need ( pure utf8 support would be good ) - Secure - Skin'able Nice to have: - Capable of running multiple instances from a single deployment - responsive community :D Things we will need to do: - Decide on what s/w to use. - Give the ArtWork people enough time to get the look & feel sorted. - Migrate newbb forums from www.centos.org to $system ( hey, english is a language too :D ). - Migrate fr.centos.org into the final s/w - setup {de/es/ja/it/pt_br}.centos.org Actions: Ralph and Fabian are going to work on setting up a test ldap server, once that is online we will then start by installing into our test-vm-farm the various s/w to eval them. If anyone would like to help, please feel free to jump right in. I'll setup a wiki page for this issue, which might be a good place to track progress. -- Karanbir Singh : http://www.karan.org/ : 2522219@icq

22 81

CentOS 8.4 image missing from Docker Hub
by Pierre Riteau 22 Jul '21

22 Jul '21

Hello, I noticed the centos:8 image on Docker Hub is still 8.3.2011, from 7 months ago. Is it planned to push an 8.4 image? Thanks! Best wishes, Pierre Riteau

1 1

Bringing glibc 2.34 snapshots to Fedora 35 and CentOS Stream 9
by Florian Weimer 07 Jul '21

07 Jul '21

TL;DR: glibc 2.34 snapshots are coming. libpthread as a separate library creates problems, so we are removing it. There may be some hickups. Full updates with “dnf update” are recommended. We expect that we will soon be able to import glibc upstream snapshots regularly into Fedora 35 and CentOS Stream 9. We did such regular imports for the past couple of Fedora rawhide releases, but the situation will be slightly different, as explained below. The snapshots will also land in CentOS Stream 9, after a delay as the result of a different testing pipeline. glibc 2.33 and earlier accidentally provided an very generic ROP gadget in the statically linked startup code that is present in every program (even dynamically linked ones). We have removed the ROP gadget and moved that particular initialization code into the dynamically linked part, but that means that the interface between the startup code and the dynamically loaded glibc parts had to change. As a result, any program linked against glibc 2.34 will not run with glibc 2.33 or any earlier version. (Some of you may remember the memcpy(a)GLIBC_2.14 issue, it was similar.) This version requirement will be properly reflected in RPM dependencies. glibc 2.34 removes libpthread as a separate library. This is based on the observation that most processes load libpthread anyway. (On this system, I count 141 out of 159 processes that load libpthread.) One particularly thorny issue is that certain NSS modules depend on libpthread, and if the main program is not linked (indirectly) against libpthread, loading such NSS modules effectively loads libpthread via dlopen, which is something that glibc has never supported well. Furthermore, the availability of some pthread_* functions without -lpthread has been a source of confusion to developers, resulting in both overlinking and underlinking. We started the libpthread transition in glibc 2.33 when we added the __libc_single_threaded variable as a replacement for the weak symbol hacks that some libraries use to detect single-threaded processes. (For example, libstdc++ used to do this to avoid using atomic instructions in std::shared_ptr.) Backwards compatibility for dynamically linked binaries should be preserved (as usual), but we know of one issue on ppc64le, where the weak symbol hacks resulted in slightly corrupt binaries. Upstream glibc did not accept the proposed backwards compatibility enhancement so far. Instead, we will rebuild affected distribution binaries with a binutils version which handles weak symbols slightly differently, avoiding the corruption. As we plan to perform these rebuilds before the new glibc lands in the buildroot, the requirement to upgrade to the new binaries before or at the same time of the upgrade to the glibc upstream snapshot will NOT be reflected in RPM dependencies. A full upgrade using “dnf update” will work, however. In addition to the removal of libpthread, I also hope to remove libdl and librt. This means that new GLIBC_2.34 symbols will be added to libc.so.6 (e.g., timer_create(a)GLIBC_2.34). The librt removal in particular will probably not land with the first imported snapshot. This is unfortunate because RPM does not have a way to express this: there's just a blanket Provides: libc.so.6(GLIBC_2.34), which will already be included in the first snapshot that adds the symbol __lib_start_main@@GLIBC_2.34 (whether or not the RPM package includes timer_create(a)GLIBC_2.34 as well). Some tools in the fedpkg/centpkg/mock sphere try to install builds from the Koji buildroot into installations from composes, without upgrading everything to the current buildroot, so it's possible that glibc won't be upgraded to match the requirements of RPMs directly imported from the buildroot. Developers encountered similar issues with glibc snapshot imports (e.g., around the symbol pthread_getattr_np). Our RPM infrastructure does not have per-symbol dependencies, so there isn't much we can do about it at the packaging level. It's a transitory issue during rawhide/CentOS Stream 9 development; the finished release will add all GLIBC_2.34 symbols in one upgrade, so end users won't see it in a Fedora 34 to Fedora 35 upgrade or a CentOS Stream 8 to CentOS Stream 9 upgrade. We think there is value in providing access to these snapshots early, and will try to make the transitions as smooth as possible, within the constraints outlined above. Thanks, Florian

1 1

CentOS Hyperscale SIG Quarterly Report for 2021Q2
by Davide Cavalca 30 Jun '21

30 Jun '21

Hello, I've published our quarterly update for the Hyperscale SIG activities on the CentOS Blog: https://blog.centos.org/2021/06/centos-hyperscale-sig-quarterly-report-for-… Cheers Davide

1 0

[Storage-SIG] missing centos-release-ceph-pacific in CentOS Stream
by Sandro Bonazzola 30 Jun '21

30 Jun '21

Hi, looking at http://mirror.centos.org/centos/8-stream/extras/x86_64/os/Packages/ I can see only: [image: [ ]] centos-release-ceph-nautilus-1.2-2.el8.noarch.rpm <http://mirror.centos.org/centos/8-stream/extras/x86_64/os/Packages/centos-r…> 2020-05-18 19:53 8.8K [image: [ ]] centos-release-ceph-octopus-1.0-1.el8.noarch.rpm <http://mirror.centos.org/centos/8-stream/extras/x86_64/os/Packages/centos-r…> 2020-05-18 19:53 8.8K but in http://mirror.centos.org/centos/8-stream/storage/x86_64/ there's only Ceph Pacific. Looks like https://koji.mbox.centos.org/koji/buildinfo?buildID=16908 is missing there. Installing it by hand: yum install https://koji.mbox.centos.org/pkgs/packages/centos-release-ceph-pacific/1.0/… I see repo is using $release instead of $stream so looks like it will pick up the wrong repo. -- 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.*

2 3

CBS/koji new (opt-in) feature : enabling EPEL repositories as external repos
by Fabian Arrotin 30 Jun '21

30 Jun '21

Based on previous threads on centos-devel and some requests (including from Hyperscale SIG), we had a look at the best way to let some SIG build *against* EPEL for some needed Requires:/BuildRequires: dependencies The first approach was to consider "importing" epel builds/pkgs into cbs, and let SIGs just "tag-build" in their own tag packages, that would also have permitted them to cherry-pick some versions and also ship these pkgs in their SIG repo if needed also a runtime instead of buildtime, but through some conversations, including with EPEL, we considered that it wasn't the best path. Instead, what is now possible is the following : enabling Epel as externalrepo at *build* time so that if your SIG will *rely* on EPEL packages, you can already build against it and you can then ensure that users consuming pkgs from your SIG would have a dependency on epel itself (simple idea is to have your centos-release-$sig pkg having a Requires: on epel-release itself, already available in Extras) The following EPEL repositories can be enabled (on demand) on CBS : - epel 7 (x86_64, ppc64le, aarch64) - epel 8 Everything (x86_64, ppc64le, aarch64) - epel Next 8 Everything (x86_64, ppc64le, aarch64) Worth clarifying that we're talking about plain rpm pkgs, no modularity content at all. (and reminder CBS doesn't have a way to let you build any module -yet- either) This was initially requested and tested/validated with the Hyperscale SIG through this RFE ticket : https://pagure.io/centos-infra/issue/306 , so if you want to "opt-in", feel free to also create ticket and we can enable these external repositories for your next builds PS: just to clarify : if your SIG had to (re)build some EPEL packages for your own tags, nothing will change : you'll still have to rebuild EPEL upstream src.rpm into your tags to see these packages (built on cbs.centos.org koji) be signed and shipped out, without depending on any change (like ENVR bump) on upstream EPEL repositories Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

1 0

SIGs building against CentOS Stream
by Rich Bowen 29 Jun '21

29 Jun '21

Do we have a list, somewhere, of which SIGs are currently building against CentOS Stream, and/or are working towards that goal, vs those which are still only building against CentOS Linux?

2 1

CBS/koji feature : enabling centos stream 8 buildroot to have access to missing -devel packages
by Fabian Arrotin 29 Jun '21

29 Jun '21

Hi all SIG members using cbs.centos.org, For a long time there was a need for some SIGs (including Infra SIG) to have access to built-but-unreleased -devel packages for CentOs 8/8-stream (https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages) The only option for SIGs in such situation was to then rebuild src.rpm in cbs, to then be able to consume (as BuildRequires: or just Requires:) these freshly built -devel pkgs for their own packages. Example for such RFE : https://pagure.io/centos-infra/issue/316 As it's now permitted to download directly rpm pkgs from https://koji.mbox.centos.org/koji/, that means that it's also possible (see discussion in ticket) to internally point the CBS builders to the koji.mbox CentOS 8 buildroots, and so be able to automatically grab -devel pkgs built but not pushed to public mirror CDN. So if your SIG needs such feature enabled for your build tags, feel free to also create ticket on infra tracker and we can enable centos8s-buildroot external repo (see https://cbs.centos.org/koji/externalrepoinfo?extrepoID=38) , and it was confirmed to be working for the Hyperscale SIG already. Have a nice day ! -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

1 0

ANN: Experimental Workstation LiveDVDs from the Hyperscale SIG
by Neal Gompa 28 Jun '21

28 Jun '21

Hello all, Over the past month or so, I've been working on producing CentOS images with Hyperscale content and customizations to showcase the technologies we're working on to the broader community. The goal is to make it easier for the community to get started with the technologies we're working on and to encourage collaboration between the SIG and the wider community on the things we're working on. Today, I'm pleased to announce one of the first deliverables of that effort: experimental live media! The SIG has produced an experimental Hyperscale Workstation Spin that combines CentOS Stream 8 with the Hyperscale SIG content to offer an early preview into some of the work we're doing. This spin is currently available here: * ISO: https://ngompa.fedorapeople.org/centos/hyperscale/CS8-HS-WORK-LIVE-LATESTDE… * SHA512 checksum: https://ngompa.fedorapeople.org/centos/hyperscale/CS8-HS-WORK-LIVE-LATESTDE… There are some limitations and known issues, though: * UEFI boot is not supported. CBS does not support signing kernels such that we can leverage the Secure Boot infrastructure, so UEFI is not supported at all right now. The issue is tracked here: https://pagure.io/centos-infra/issue/307 * The Anaconda installer icon is missing. This will be fixed with the next release of centos-logos. Upstream issue here: https://github.com/CentOS/centos-logos/issues/1 * SELinux denials with systemd-hostnamed and systemd-oomd. This is being investigated, and fixes will become available in a future systemd update provided by the Hyperscale SIG. * SELinux denials with sssd and useradd. This happens with stock CentOS Stream 8, and is not related to anything we're doing. * All non-English locales aren't showing up in Anaconda despite all locales being installed. This is being actively investigated and will hopefully be resolved in a future release. * "dnf upgrade" is broken due to package conflicts with the DNF stack. This is because our custom version of the RPM+DNF stack has not been refreshed to the latest version pushed into CentOS Stream 8. This is ongoing and should be resolved soon. * VDO is broken. This is a consequence of VDO being an out-of-tree kernel module shipped by Red Hat for RHEL kernels only. The Hyperscale SIG is building its kernels based on the ARK tree that's used by Fedora, and thus lacks support for VDO. If you find any other issues, we would definitely love to hear about them! We have a dedicated issue tracker for Hyperscale spins where we would appreciate bugs to be reported: https://pagure.io/centos-sig-hyperscale/spin-bugs The Hyperscale Workstation spin is built on the GNOME desktop. It is my intent to also offer a KDE Plasma flavor once it becomes reasonably possible. This is blocked on KDE Plasma getting rebuilt in EPEL-Next for the updated Qt5 in CentOS Stream 8. Both desktops are capable of leveraging the technologies being developed by the Hyperscale SIG and we intend to use this to showcase that. We hope you enjoy it as much as I enjoyed making this! Thanks and best regards, Neal (on behalf of the CentOS Hyperscale SIG) -- 真実はいつも一つ！/ Always, there's only one truth!

2 1

Zuul CI timeouts on CentOS Stream 9
by Florian Weimer 27 Jun '21

27 Jun '21

It seems that these jobs have a hard timeout of 30 minutes. It is just not possible to build the glibc RPM in under 30 minutes on a single Haswell-era CPU, so these cycles go to waste because every attempt will time out. Is there a way to opt out of this, to conserve resources? Thanks, Florian

3 4

CentOS website pointing at old twitter account.
by Philip Wyett 26 Jun '21

26 Jun '21

Hi all, A trivial one. The project website is still pointing at old twitter account. git diff attached to resolve. Regards Phil -- *** Playing the game for the games own sake. *** WWW: https://kathenas.org Twitter: @kathenasorg Instagram: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B

2 1

Volunteer(s) wanted to answer questions on Freenode
by Rich Bowen 26 Jun '21

26 Jun '21

As you know, several weeks ago we made the choice to move our main IRC presence from Freenode to Libera.chat due to some changes in the management of the Freenode network. You can, of course, find details about that elsewhere. Meanwhile, due to the name recognition of Freenode, people continue to show up every day on #centos@Freenode to ask questions, and are met with silence, because the experts have moved over to Libera. Those users are therefore not getting their questions answered. The trouble is, Freenode has a policy that we cannot put the new channel location (ie, irc.Libera.chat) in the /topic, and attempts to redirect those people to Libera tend to get people scolded or kicked off channel, which further worsens these users' experience. So ... all that to say ... if you are able to answer beginner-to-intermediate CentOS questions, and are able/willing to hang out on the #centos channel on freenode.net, your presence would be welcome. Network staff have confirmed that it's ok to send people to Libera.chat when we're unable to provide answers, but they would like to attempt rebuild an expert community there. I'm hesitantly willing to assume, for the moment, that this is in good faith - there are, as far as I can tell, some good staff members left there, and, after all, this is about helping users.

3 3

Can CentOS Stream 8 Devel repo be populated
by Troy Dawson 24 Jun '21

24 Jun '21

Back when the CentOS 8 Devel repo[1] was originally introduced, the CentOS Stream 8 Devel repo[2] was kept empty. Now that CentOS 8 is going away, and we are expected to develop on CentOS Stream 8, could we please get CentOS Stream 8 Devel populated with the same packages it once had. I know there is an initiative for all the missing -devel packages to appear somewhere at sometime. But here is my problem. I'm trying to get KDE rebuilt for CentOS Stream 8 due to the updated qt5 that is now in Stream. plasma-nm, a fairly important piece of KDE, requires mobile-broadband-provider-info-devel which is in the Devel repo. >From what I see, the fastest way to get mobile-broadband-provider-info-devel somewhere that I can consume it on Stream is via the Devel repo. Thus my question. Can we get CentOS Stream 8 Devel populated with whatever is in the regular Devel repo. Thanks Troy Dawson [1] - http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/ [2] - http://mirror.centos.org/centos/8-stream/Devel/x86_64/os/Packages/

10 21

[Artwork] CentOS Stream logo
by Rich Bowen 23 Jun '21

23 Jun '21

Hi, Artwork folks (and everyone else!) Some people within Red Hat have a need/desire for a CentOS Stream logo which can be used to distinguish CentOS Linux from CentOS Stream for some messaging. They have proposed the attached for this purpose. There were, in fact, several other proposed ideas, too, and I have pointed them to https://git.centos.org/centos/Artwork/issue/1 to continue that part of the conversation, as many of them involved changes to the core CentOS logo, which is, of course, a much larger conversation. Are there any objections from the Artwork SIG to using the proposed image? I think maybe it's not *strictly* compliant with our brand guidelines. Any thoughts here?

3 4

Wordpress theme: Call for volunteer(s)
by Rich Bowen 20 Jun '21

20 Jun '21

If you are adept at designing Wordpress themes, or adapting existing ones, I am looking for you. While there's nothing wrong with our existing blog theme, it's time to freshen it up, and possibly incorporate some of the CentOS 8 imagery and bring it into the same style family as the main centos.org website. If you're able and willing to work on this, please let me know. Thanks. -- Rich Bowen: CentOS Community Manager rbowen(a)redhat.com @rbowen // @CentOSProject 1 859 351 9166

2 7

[NFV SIG] NFV SIG meeting minutes - 2020-06-16
by Alfredo Moralejo Alonso 16 Jun '21

16 Jun '21

============================================= #centos-meeting: NFV SIG meeting - 2020-06-16 ============================================= Meeting started by amoralej at 15:07:50 UTC. The full logs are available athttps://www.centos.org/minutes/2021/June/centos-meeting.2021-06-16-15.07.… . Meeting summary --------------- * status of OpenvSwitch and OVN 2.15 (amoralej, 15:11:22) * ovn-2021 builds are available for CentOS Stream 8 in official mirrors no (amoralej, 15:11:52) * RDO is moving to openvswitch2.15 and ovn-2021 in Xena release https://review.rdoproject.org/r/c/rdoinfo/+/33919 (amoralej, 15:12:33) Meeting ended at 15:35:31 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * amoralej (38) * dholler (14) * centbot (3) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

CentOS Board welcomes new directors
by Rich Bowen 15 Jun '21

15 Jun '21

The CentOS Board of Directors is delighted to welcome two new directors - Davide Cavalca and Josh Boyer - to the Board. Please join us in welcoming them, and thanking them for their willingness to dedicate some of their time to the endeavor of steering the CentOS Project. Once again, we thank outgoing directors Karsten Wade and Carl Trieloff for their years of service.

3 2

Purpose of composes.centso.org?
by redbaronbrowser 11 Jun '21

11 Jun '21

I am curious about composes.centos.org and it's intended use case or guidance on what it should/can be used for. If it is reasonable, I would like to try to write a dnf plugin to simplify using it for package rollbacks. Is someone else already working on this? Is there a better way to go about doing this? Ultimately, I would like it so when submitting a bug about a regression, it is easy for the user to specify between what compose dates the regression first appeared.

5 6

repomd.xml.asc outdated?
by Leon Fauster 11 Jun '21

11 Jun '21

JFYI: LANG=C yum update --noplugins ... Error: Failed to download metadata for repo 'appstream': repomd.xml GPG signature verification error: Bad GPG signature http://mirror.centos.org/centos-8/8/AppStream/x86_64/os/repodata/ shows repomd.xml 2021-03-16 15:43 repomd.xml.asc 2021-03-03 00:29 -- Leon

5 6

RFC: kmods SIG Proposal
by Peter Georg 11 Jun '21

11 Jun '21

Dear all, I'd like to propose a SIG for CentOS Stream. Please see the proposal below. Note: In case anyone has a better suggestion for a name, please let me know. I'm really terrible at naming things. And sorry in advance for any spelling or grammar mistakes (I'm not a native english speaker). For everyone following the previously posted "RFC: Stream Kernel SIG Proposal": The goal of the "kmods" SIG proposed here has previously been proposed to be added to a potential "Stream Kernel SIG" as a fifth goal. However it seems to make sense to split the various different goals into seperate SIGs. Disclaimer: I used the Hyperscale SIG description (https://wiki.centos.org/SpecialInterestGroup/Hyperscale) as a template. I hope that's OK. Best, Peter Proposal: = kmods SIG = == Goals == The kmods SIG will focus on providing kernel modules currently not available in CentOS Stream. == Status == Proposed: RFC and looking for a sponsoring Governing Board member == What's in scope == This SIG is a good place for any kernel module that is beneficial to CentOS Stream, but cannot be directly contributed to any of the involved upstream projects. These kernel modules may be divided in three categories: === Restore support for deprecated devices === The CentOS Stream kernel includes several kernel modules for which the list of supported devices has been limited by Red Hat. This SIG aims to provide versions of these kernel modules with restored support for as many deprecated and removed devices as possible. A close collaboration with the kernel-plus developers is desired for these kernel modules. === In-kernel modules not enabled for CentOS Stream === Many in-kernel modules are simply disabled for the CentOS Stream kernel. This may either be due to drivers being deprecated and removed compared to older CentOS major releases or never being enabled in the first place. This SIG aims to provide these in-kernel drivers as external kernel modules to enable CentOS Stream running on a broader range of available hardware and provide other beneficial functionality. A close collaboration with the kernel-plus developers is desired for these kernel modules. In addition it is desired to work with upstream to get any valuable kernel modules directly into the CentOS Stream kernel. === Third-party external kernel modules === This SIG also aims to provide third-party kernel modules for CentOS Stream not (yet) available in upstream kernel. == What's not in scope == Anything that can be contributed directly to any of the involved upstream projects is not in scope. This includes, but is not limited to: * New user space packages: These should be submitted to Fedora/EPEL * Support for new architectures currently not supported by CentOS Stream * Third-party kernel modules with non compatible license == Roadmap == * Provide packages for in-kernel modules with restored support for deprecated devices * Provide packages for in-kernel modules that have been supported in older CentOS major releases * Provide packages for further beneficial kernel modules requested by the community == Resources == TBD == Communication == The SIG uses the [[https://lists.centos.org/mailman/listinfo/centos-devel|centos-devel]] mailing list for coordination and communication. TBD: Add note about regular meetings once established. == Membership == The current set of members is: ##begin-members * ... ##end-members The SIG is co-chaired by ... and .... Everybody is welcome to join and contribute to the SIG. Membership can be requested by asking on the [[https://lists.centos.org/mailman/listinfo/centos-devel|centos-devel]] mailing list. Any current member can raise objections and request a simple majority vote on membership applications. SIG members are expected to actively contribute or otherwise remain engaged with the project. Stale members may be removed by a simple majority vote after six months of inactivity. The SIG is co-chaired by two equal chairpersons elected by SIG members for one year. Each chairperson is elected individually using a plurality vote.

14 56

[Cloud SIG] CentOS Cloud SIG meeting minutes (2021-06-10)
by Alfredo Moralejo Alonso 10 Jun '21

10 Jun '21

====================================================== #centos-meeting: CentOS Cloud SIG meeting (2021-06-10) ====================================================== Meeting started by amoralej at 15:07:28 UTC. The full logs are available athttps://www.centos.org/minutes/2021/June/centos-meeting.2021-06-10-15.07.… . Meeting summary --------------- * roll call (amoralej, 15:08:18) * Move jobs from ci.centos.org to new openshift cluster (amoralej, 15:12:36) * LINK: https://jenkins-cloudsig-ci.apps.ocp.ci.centos.org/ (amoralej, 15:13:24) * AGREED: to stay on JJB for the new jenkins (amoralej, 15:22:49) * LINK: https://pagure.io/centos-infra/issue/352 (amoralej, 15:23:48) * LINK: https://centosci.github.io/ocp4-docs/ (amoralej, 15:36:49) * LINK: https://centosci.github.io/ocp4-docs/sops/migration/ (apevec, 15:37:59) * ACTION: amoralej to create a trello card for the migration (amoralej, 15:40:19) * open discussion (amoralej, 15:44:14) Meeting ended at 15:48:27 UTC. Action Items ------------ * amoralej to create a trello card for the migration Action Items, by person ----------------------- * amoralej * amoralej to create a trello card for the migration * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * amoralej (91) * apevec (62) * ykarel (15) * jcapitao (6) * centbot (5) * spotz (4) * jpena (3) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

CentOS Community Code of Conduct
by Rich Bowen 08 Jun '21

08 Jun '21

As per my email in April - https://lists.centos.org/pipermail/centos-devel/2021-April/076769.html - and per the approval of the Board of Directors, we have published the new CentOS Community Code of Conduct: https://www.centos.org/code-of-conduct/ This Code of Conduct is in effect immediately, and the reporting process described in there is in effect immediately. One note: The doc says that it is "a living document and will be updated when and if it is deemed necessary." One change that we forsee very soon is that, rather than me, as Community Architect, being the sole responsible party for reporting CoC incidents, I will be assembling a small CoC committee. While I have identified some of the people who will be part of that committee, I thought it was good to go ahead and publish the CoC as is, and modify it once that committee is all in place. Thanks to everyone that participated in the review process for this policy. --Rich, on behalf of the Board of Directors.

1 0

docker, CVE-2019-13139 and announcements for updates in extras
by Stefan Puiu 05 Jun '21

05 Jun '21

Hi, We run a CentOS 7-based (actually, CentOS 7 atomic host) image on our hardware boards. We ran a third party "security scan" that seems to look at the list of packages in the distro and check if fixes or advisories have been published for the package versions installed. I guess they have a database of CentOS / RHEL advisories and can cross check the versions there. For a while now, the tool has been complaining that the version of docker we ship is vulnerable to CVE-2019-13139. As far as I can tell, we have a version that includes the fix, based on the Red Hat advisory: https://access.redhat.com/errata/RHBA-2019:3092 says we need docker-1.13.1-104.git4ef4b30, and we have 204.git0be3e21. We've tried to raise this with the tool vendor, but they have asked if we have "vendor documentation" for that fix being applied. My understanding is that they mean something like the centos-announce emails announcing the integration of fixes from RHEL to CentOS, with something like, for example, RHSA-2021:0617 being labeled as CESA-2021:0617; they said they couldn't find the corresponding CEBA-2019:3092. Now, I've looked in the centos-announce list archives since October 2019, when the RH advisory was published, and didn't find anything related to Docker. I saw a mention of the CVE in a CentOS bug, though (https://bugs.centos.org/view.php?id=16804). I'm trying to work with the tool vendor to sort this out. As a developer, I think checking the code is the best way; I've found the Docker RH fork on github, which has a RHEL branch that seems to be used in both CentOS and RHEL (https://github.com/projectatomic/docker/tree/docker-1.13.1-rhel). However, probably the tool people have some kind of different process in place. So my question is: is it reasonable to expect any bugfix or security update fetched from RHEL to CentOS to come with an announcement on the centos-announce mailing list? Is there a filter for some packages? I see docker is in extras, not in CentOS-Base, maybe updates to those are not announced? Thanks, Stefan.

3 4

Announcing the latest release of CentOS Linux 8 (2105)
by Rich Bowen 04 Jun '21

04 Jun '21

Release for CentOS Linux 8 (2105) We are pleased to announce the general availability of the latest version of CentOS Linux 8. Effectively immediately, this is the current release for CentOS Linux 8 and is tagged as 2105, derived from Red Hat Enterprise Linux 8.4 Source Code. As always, read through the Release Notes at: http://wiki.centos.org/Manuals/ReleaseNotes/CentOS8.2105 - these notes contain important information about the release and details about some of the content inside the release from the CentOS QA team. These notes are updated constantly to include issues and incorporate feedback from users. ---------- Updates, Sources, and DebugInfos Updates released since the upstream release are all posted, across all architectures. We strongly recommend every user apply all updates, including the content released today, on your existing CentOS Linux 8 machine by just running 'dnf update'. As with all CentOS Linux 8 components, this release was built from sources hosted at git.centos.org. Sources will be available from vault.centos.org in their own dedicated directories to match the corresponding binary RPMs. Since there is far less traffic to the CentOS source RPMs compared with the binary RPMs, we are not putting this content on the main mirror network. If users wish to mirror this content they can do so using the reposync command available in the yum/dnf-utils package. All CentOS source RPMs are signed with the same key used to sign their binary counterparts. Developers and end users looking at inspecting and contributing patches to the CentOS Linux distro will find the code hosted at git.centos.org far simpler to work against. Details on how to best consume those are documented along with a quick start at: http://wiki.centos.org/Sources Debuginfo packages have been signed and pushed. Yum configs shipped in the new release file will have all the context required for debuginfo to be available on every CentOS Linux install. This release supersedes all previously released content for CentOS Linux 8, and therefore we highly encourage all users to upgrade their machines. Information on different upgrade strategies and how to handle stale content is included in the Release Notes. Note that older content, obsoleted by newer versions of the same applications are trim'd off from repos like extras/ and centosplus/ ---------- Download We produced the following installer images for CentOS Linux 8 # CentOS-8.4.2105-aarch64-boot.iso: 677838848 bytes SHA256 (CentOS-8.4.2105-aarch64-boot.iso) = 106d9ce13076441c52dc38c95e9977a83f28a4c1ce88baa10412c1e3cc9b2a2b # CentOS-8.4.2105-aarch64-dvd1.iso: 7325042688 bytes SHA256 (CentOS-8.4.2105-aarch64-dvd1.iso) = 6654112602beec7f6b5c134f28cf6b77aedc05b2a7ece2656dacf477f77c81df # CentOS-8.4.2105-ppc64le-boot.iso: 722780160 bytes SHA256 (CentOS-8.4.2105-ppc64le-boot.iso) = 4a83e12f56334132c3040491e5894e01dfe5373793e73f532c859b958aeeb900 # CentOS-8.4.2105-ppc64le-dvd1.iso: 8484990976 bytes SHA256 (CentOS-8.4.2105-ppc64le-dvd1.iso) = 9cfca292a59a45bdb1737019a6ac0383e0a674a415e7c0634262d66884a47d01 # CentOS-8.4.2105-x86_64-boot.iso: 758120448 bytes SHA256 (CentOS-8.4.2105-x86_64-boot.iso) = c79921e24d472144d8f36a0d5f409b12bd016d9d7d022fd703563973ca9c375c # CentOS-8.4.2105-x86_64-dvd1.iso: 9928966144 bytes SHA256 (CentOS-8.4.2105-x86_64-dvd1.iso) = 0394ecfa994db75efc1413207d2e5ac67af4f6685b3b896e2837c682221fd6b2 Information for the torrent files and sums are available at http://mirror.centos.org/centos/8/isos/ -------- Additional Images Vagrant and Generic Cloud images are available at: http://cloud.centos.org/centos/8/ Amazon Machine Images for Amazon Web Services are published by ID into a number of regions. A table of AMI IDs can be found here: https://wiki.centos.org/Cloud/AWS ---------- Getting Help The CentOS ecosystem is sustained by community driven help and guidance. The best place to start for new users is at http://wiki.centos.org/GettingHelp We are also on social media, you can find the project: on Twitter at :http://twitter.com/CentOS on Facebook at :https://www.facebook.com/groups/centosproject/ on LinkedIn at :https://www.linkedin.com/groups/22405 And you will find the core team and a majority of the contributors on irc, on irc.libera.chat in #centos ; talking about the finer points of distribution engineering and platform enablement. ---------- Contributors This release was made possible due to the hard work of many people, foremost on that list are the Red Hat Engineers for producing a great distribution and the CentOS QA team, without them CentOS Linux would look very different. Many of the team went further and beyond expectations to bring this release to you, and I would like to thank everyone for their help. We are also looking for people to get involved with the QA process in CentOS, if you would like to join this please introduce yourself on the centos-devel list (http://lists.centos.org/mailman/listinfo/centos-devel). Finally, please join me in thanking the donors who all make this possible for us. Enjoy the fresh new release! Thanks, Johnny Hughes

3 2

CentOS Stream 9 Buildsystem Paused over the weekend for power maintenance
by Brian Stinson 04 Jun '21

04 Jun '21

Hi Folks, There is power maintenance going on over this weekend in the datacenter hosting parts of kojihub.stream.centos.org We have paused the buildsystem, and the Merge Request pipelines in Gitlab until we're ready to come back. We expect to re-enable things on Monday morning US time. While this maintenance is ongoing, the web interfaces may also be down. Thanks for your patience, -- Brian Stinson brian(a)bstinson.com

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel June 2021