devel

devel@lists.centos.org

8 participants
4617 discussions

Update: State of CentOS Linux 8, and CentOS Stream
by Rich Bowen 15 Jan '20

15 Jan '20

We wanted to update you on what is happening, largely out of sight to most of the community, on the CentOS Linux 8 front. We have appreciated the patience of the community, but we understand that your patience won’t last forever. A lot of the work in rebuilding RHEL sources into CentOS Linux is handled by automation scripts. Due to the changes between RHEL 7 and RHEL 8, many of these scripts no longer work, and had to be fixed to reflect the new layout of the buildroot. This work has been largely completed, allowing us to pull the source from Red Hat without a lot of manual work. This, in turn, should make the process of rebuilding RHEL 8.2 go much more smoothly than RHEL 8.0 and 8.1 have done. Once 8.1 has been released, work will begin on bringing this new codebase, along with CentOS Stream, in to CBS (https://wiki.centos.org/HowTos/CommunityBuildSystem) so that SIGs can build packages for CentOS Linux 8 and CentOS Stream. We will discuss this, and give updates of progress, on the centos-devel mailing list over the coming weeks. Some of you have observed that the CentOS team tends to prioritize doing the work over talking about it. While that’s not all bad, it does tend to leave most of you in the dark as to what it is that is being worked on, and we’re committed to greater transparency going forward. Once again, we appreciate your patience as we work through the growing pains of the 8 branch. We hope to share a more detailed (projected) timeline in the days to come, with the caveat that timelines always change as they are being worked. -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166

4 4

java packages copr building issues when targeting centos-stream / epel8
by Sandro Bonazzola 13 Jan '20

13 Jan '20

Hi, not sure which mailing list to point for asking, but I've an issue while building unboundid-ldapsdk for el8 in copr. When trying to build I get dnf error: DEBUG util.py:596: No matches found for the following disable plugin patterns: local, spacewalk DEBUG util.py:598: Copr repository 46 kB/s | 3.6 kB 00:00 DEBUG util.py:596: Error: DEBUG util.py:596: Problem: conflicting requests DEBUG util.py:596: - package javapackages-local-5.3.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering DEBUG util.py:598: (try to add '--skip-broken' to skip uninstallable packages) javapackages-local is provided in CentOS Stream / EPEL both by CentOS-8 - PowerTools(javapackages-tools-5.3.0-2.module_el8.0.0+30+832da3a1.noarch.rpm <http://mirror.centos.org/centos/8-stream/PowerTools/x86_64/os/Packages/java…>) repo and CentOS-8 - AppStream( javapackages-tools-5.3.0-1.module_el8.0.0+11+5b8c10bd.noarch.rpm <http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/Packages/javap…> ). Is there a way for building in copr any java package using javapackages-local? I couldn't find a way to tell the system which module to enable or not. Thanks, -- 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 2

Re: [CentOS-devel] A Big Idea for a New Decade [was: Minutes for CentOS Board of Directors 2019-12-18 Meeting]
by Neal Gompa 12 Jan '20

12 Jan '20

On Mon, Jan 6, 2020 at 4:13 PM Matthew Miller <mattdm(a)mattdm.org> wrote: > > On Fri, Jan 03, 2020 at 03:13:53PM -0500, Karsten Wade wrote: > > As a centralizing effort, the Board agreed to revisiting the goals > > document created five years ago, and to undergo an effort to refresh those > > goals in the light of the project’s evolution. The Board will be inviting > > various stakeholders into these discussions as we undergo a public > > revision of the goals at the start of 2020. > > Wow, five years goes fast! I'd like to raise an idea for discussion and > thought, and possible further discussion between the Fedora Council and the > CentOS board. [I'm posting this in both groups.] > > Around the same time the CentOS goals were being created, Fedora was working > on plans for "Fedora.next", which included among other things Fedora Server. > I won't rehash all that here, but in short: while that succeeded at some of > its goals, it never really had the user adoption we'd hoped for. Of course, > some of that is simply a matter of lifecycle: while a fast-moving server OS > is useful in some very real cases, it's decidedly niche. > > When Fedora launched that plan, CentOS wasn't really in the "family", and > after, we just kind of existed in parallel, with some very loose > collaboration in areas like EPEL. > > Of course, things are different now. Therefore, I propose that in this next > decade, we make that collaboration stronger. Together, we have a very nice > answer to the fundamental problem of unified operating systems. That is, > some parts move too fast and other parts move too slowly. Between Fedora and > CentOS, we have answers to both! And, with the in-progress dist-git merge, > we even have both _in the same place_. > > Specifically, I'd like to suggest three things. > > First, let's replace Fedora Server as a user-focused artifact with CentOS > Stream. There's still a need for a Fedora Server as an upstream, but most > users of Fedora as a server are making custom builds (or using the basic > Cloud image), not using Fedora Server per se. So, I think we should stop > marketing that to users, and steer people with server use cases outside of > the fast-moving niche to CentOS Stream. The current story of CentOS and > Fedora is pretty confusing to users, and Stream only makes it more so. Let's > simplify things! > > Second, where there's overlap, let's look at merging Fedora and CentOS SIGs > into joint bodies. We have groups like the cloud image SIGs which are > basically doing the exact same thing in two different ways. Same thing with > containers. We also have huge overlaps in documentation and community user > support and all sorts of non-technical project areas. I'm not saying these > all need to be smooshed together, but where it makes sense let's work > together. This, too, brings simplification to the "what's with CentOS vs. > Fedora" story: rather than making contributors pick, we can welcome all with > open arms. > > And finally, let's really take advantage of a merged dist-git repository, > and the capabilities that Modularity gives us. SIGs building things for > CentOS should be able to directly reference Fedora branches where > faster-moving software is useful — and people building things in Fedora > should be able to pull in branches from Stream where a slower-moving version > would make sense. And we could even make additional shared branches where > necessary, using modularity to make optional streams which could be used in > CentOS SIGs, EPEL, or a Fedora OS. > > What do you think? > First, sorry that this email probably doesn't thread will with either one or the other target mailing lists... I had to pick one to thread with, and other slightly loses. The downside of the initial email not being sent to both MLs at once. :( In concept, I certainly see value in bringing CentOS and Fedora closer. However, I think eliminating Fedora variants in favor of CentOS Stream ones (aka rhel-rawhide based variants) is probably premature. There are several issues with doing this as it currently stands: 1. CentOS Koji is pretty closed to a couple of folks in CentOS and Red Hat. This also includes blocking the download of artifacts from Koji. For reasons I don't understand, CentOS is still gated by the RHEL QE folks, and thus RPMs built in Koji cannot be downloaded until they are finally published. This ruins any testing/development before releasing to users. The CBS is a worthless substitute since it's purely for addons. I've been around long enough to remember when Fedora was like this, and back then, it wasn't really considered "okay" for Fedora to be like that (the intent was always there to fix it, and we eventually did!). Today, however, it is considered "okay", and that's a problem. 2. The CentOS community is simply not mature enough to take on the role Fedora does in any meaningful capacity. We already know that this is a problem even with Fedora EPEL, and I strongly believe the issue would be massively magnified if those transitioned to the CentOS Project. The CentOS community is largely a user community that takes and does not give back much, if at all. I've experienced variations of this issue when people (even from Red Hat!) have done finger-pointing to *me* with my packages in EPEL without any acknowledgement that they could have helped. It's depressing that even some Red Hatters consider EPEL not worth contributing to, but still worth being upset about. 3. Today, the CentOS Project is (sadly) a community project in a very superficial sense. Aside from the Virt SIG's Xen subgroup, all SIGs are basically Red Hat product teams, with varying degrees of allowances for community contributions. The community processes within CentOS are mostly nonfunctional because they've had no reason to develop it. There has been very little community development for CentOS. Even with Fermilab and CERN shutting down Scientific Linux, I haven't seen anything from those people coming "into the fold". There's been no outreach or collaboration with other CentOS based derivatives, commercial or otherwise. The private discussions I've had on the matter seem to indicate that there's still ambivalence, if not outright antipathy and hostility toward the broader ecosystem of CentOS derivatives. What I'm more concerned about is that if you eliminate Fedora from any meaningful server based development, you strip all the opportunities for people to iterate on server-oriented changes before they go into rhel-rawhide and push into CentOS Stream. You also essentially kneecap any motivation for other things related to server environments to iterate faster (such as language stacks that are heavily used for web service software) because you've eliminated the major ability for that to ship to users and contributors. It also further accelerates a trend that I think we need to reverse where people consider Fedora unacceptable for server roles. If anything, Fedora is a lot better at being used for servers then it was five years ago. I've personally *stopped* using CentOS for servers because Fedora has gotten so good at it. Upgrades are a breeze and stuff generally works. When it doesn't, it's fixable! That last part is key. With CentOS, it's not, because it has to bounce back into Red Hat first. And Red Hat doesn't really care about issues discovered by CentOS users, and there are no "CentOS developers". So, what this long email is actually saying is that I think it's an interesting idea to bring the two projects together, but eliminating aspects of Fedora in favor of CentOS is premature because CentOS has not actually developed as a community project. Maybe it's worth revisiting after six years of actual community development? -- 真実はいつも一つ！/ Always, there's only one truth!

14 30

Minutes for CentOS Board of Directors 2019-12-18 Meeting
by Karsten Wade 10 Jan '20

10 Jan '20

>From https://blog.centos.org/2020/01/minutes-for-centos-board-of-directors-2019-… Public minutes On 2019-12-18 the CentOS Board of Directors held the final meeting of the 2019 calendar year. The meeting was focused primarily on how the Board can lead the project further into being a contributor-centric open source project while continuing to deliver value to our community of users. Of particular interest is growing participation in CentOS Streams in addition to ongoing efforts around CentOS SIGs. As a centralizing effort, the Board agreed to revisiting the goals document created five years ago, and to undergo an effort to refresh those goals in the light of the project’s evolution. The Board will be inviting various stakeholders into these discussions as we undergo a public revision of the goals at the start of 2020. In support of these efforts, the Board came to the following decisions, resolutions, and agreements: 1. Image creation, signing, and distribution: 1. AGREED: Board agrees there is a significant technical debt in the content flow. To address this the Board authorizes Community Platform Engineering (CPE) to commit engineering toward addressing this in early CY 2020. 2. ACTION: Jim to work with Fabian/CPE to begin working on a signing and release solution for SIGs, work starting in Jan 2020. 3. ACTION: Prioritize transparency and reporting to foster a better understanding of the build process for CentOS Linux 8, with an emphasis on the update lag/point release challenges 2. Project strategic goals: 1. AGREED: Undergo a revision of the project goals, to include a range of topics from technical to social/cultural. Do this work transparently, reaching out to specific community members and stakeholders such as RHEL Engineering. 3. Consent agenda items: 1. AGREED: Secretary role revitalized -- not formally in the governance yet, role is delegated meeting organization and management duties from the Chair to include calling for meetings, managing the private and public agenda for meetings, and handling the creation and release of private and public minutes. Karsten Wade has volunteered to take this role until approximately June 2020. 2. ACTION: Early in 2020 Karsten & KB to draft governance updates to reflect the Secretary role. AGREED: Board confirms support for planning a shift to sharing auth backends with the Fedora Project. -- Karsten Wade [he/him/his]| Senior Community Architect | @quaid Red Hat Open Source Program Office (OSPO) : @redhatopen https://community.redhat.com | https://next.redhat.com | https://theopensourceway.org gpg: AD0E0C41 | https://red.ht/sig

9 15

Re: [CentOS-devel] keepassxc dependency issue
by Andy Hall 09 Jan '20

09 Jan '20

On Wed 8 Jan 2020 Troy Dawson wrote... "I wonder if it's a matter of epel-playground vs epel. It looks like you have to have both enabled if you want to install it." That was exactly it - thanks very much.

1 0

[cloudSIG] Meeting Logs
by Rain Leander 09 Jan '20

09 Jan '20

Mostly chatting, nothing urgent. If you're keen to join, we're thinking of shifting the meeting one hour earlier and we'd love your input. Please let us know! #centos-meeting: CentOS Cloud SIG meeting (2020-01-09)Meeting started by leanderthal at 15:02:32 UTC (full logs <https://www.centos.org/minutes/2020/January/centos-meeting.2020-01-09-15.02…> ). Meeting summary 1. *rollcall* (leanderthal <https://www.centos.org/minutes/2020/January/centos-meeting.2020-01-09-15.02…>, 15:02:40) 2. *open floor* (leanderthal <https://www.centos.org/minutes/2020/January/centos-meeting.2020-01-09-15.02…>, 15:10:33) Meeting ended at 15:20:11 UTC (full logs <https://www.centos.org/minutes/2020/January/centos-meeting.2020-01-09-15.02…> ). Action items 1. (none) People present (lines said) 1. leanderthal (21) 2. smooge (10) 3. centbot (3) -- K Rain Leander OpenStack Community Liaison Open Source Program Office https://www.rdoproject.org/ http://community.redhat.com

1 0

Update from CentOS PaaS SIG
by Gleidson Nascimento 09 Jan '20

09 Jan '20

Hello from CentOS PaaS SIG! We have recently published an update on CentOS blog [1] about OKD v4 and its current state on CentOS. [1] https://blog.centos.org/2020/01/centos-paas-sig-quarterly-report-2/ Thanks, Gleidson

4 3

Re: [CentOS-devel] A Big Idea for a New Decade [was: Minutes for CentOS Board of Directors 2019-12-18 Meeting]
by Patrick Laimbock 08 Jan '20

08 Jan '20

-----Original message----- >From: Carl George<carl(a)redhat.com> >Sent: Wednesday 8th January 2020 17:01 >To: The CentOS developers mailing list. <centos-devel(a)centos.org> >Subject: Re: [CentOS-devel] A Big Idea for a New Decade [was: Minutes for CentOS Board of Directors 2019-12-18 Meeting] > >> While I agree with consolidation, over time, of the SIGs, I do think the name >> should be “Enterprise Linux Community SIGs” or similar. I get that Red Hat has >> a massive influence in all four flavours (Fedora, RHEL, CentOS, Streams), but >> for someone new to the communities, it could be confusing to refer to them as >> “Red Hat”, as most people outside the community see “Red Hat” as referring only >> to “RHEL” and not the wider Enterprise Linux ecosystem. > >Fedora is not Enterprise Linux. To me, the name "Enterprise Linux Community" >excludes Fedora. Im not married to the name "Red Hat Community", but its the >best name I can think of that accurately conveys the scope. What term would >you use to describe the entire ecosystem of Fedora, RHEL, CentOS, CentOS >Stream, and EPEL? Ive always called this the "Red Hat ecosystem". To me the Red Hat ecosystem has always been RHEL plus all RHXXX products plus upstream work. The entire ecosystem is all RPM based but "RPM Community SIGs" is not inclusive enough so does not do it for me. How about "Open Community SIGs" or "Open Linux Community SIGs"? It's neutral. It's Open. This is the way :-) Best, Patrick

1 0

keepassxc dependency issue
by Andy Hall 08 Jan '20

08 Jan '20

please advise if there is a repo which needs enabling on centos 8 for this to work $ cat /etc/centos-release CentOS Linux release 8.1.1911 (Core) $ sudo yum install keepassxc [sudo] password for ahall: Last metadata expiration check: 0:12:51 ago on Wed 08 Jan 2020 07:52:00 GMT. Error: Problem: conflicting requests - nothing provides libsodium.so.23()(64bit) needed by keepassxc-2.4.3-4.epel8.playground.x86_64 - nothing provides libargon2.so.1()(64bit) needed by keepassxc-2.4.3-4.epel8.playground.x86_64 - nothing provides libykpers-1.so.1()(64bit) needed by keepassxc-2.4.3-4.epel8.playground.x86_64 - nothing provides libykpers-1.so.1(LIBYKPERS_1.0)(64bit) needed by keepassxc-2.4.3-4.epel8.playground.x86_64 - nothing provides libykpers-1.so.1(LIBYKPERS_1.5)(64bit) needed by keepassxc-2.4.3-4.epel8.playground.x86_64 - nothing provides libykpers-1.so.1(LIBYKPERS_1.8)(64bit) needed by keepassxc-2.4.3-4.epel8.playground.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) I don't see the required packages for 8 here: https://pkgs.org/download/libsodium https://pkgs.org/download/libargon2 https://pkgs.org/download/libykpers-1 thanks very much

3 2

clusterlabs & HA
by lejeczek 08 Jan '20

08 Jan '20

hi everybody, I see there is a ticket for resurrection of HA in 8 but I was hoping devel could clarify or maybe even officially declare the future of HA stack(as we have it in 7) with regards to 8. Please? many thanks, L.

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel