devel

devel@lists.centos.org

2 participants
4653 discussions

Hyperscale SIG (Proposed)
by Rich Bowen 06 Jan '21

06 Jan '21

FYI: A Hyperscale SIG has been proposed, and will be considered in next week's board meeting. Details may be found here: https://wiki.centos.org/SpecialInterestGroup/Hyperscale --Rich

1 0

Why gnutls update was built for c8 but not c8s?
by Igor Raits 06 Jan '21

06 Jan '21

Hello, The https://git.centos.org/rpms/gnutls/c/3ec527a2c4ad3bad520b1004a50c075d94cc80… has been imported month ago, but there was just build for c8 from today and none for c8s. Is the process of building automated, or who is responsible for building the updates for c8s? Thanks in advance for your help!

1 0

should we expect to close CentOS Stream bugs as dups of RHEL?
by Ken Dreyer 06 Jan '21

06 Jan '21

Hi folks, This RHBZ tracks a problem in CentOS Stream: https://bugzilla.redhat.com/show_bug.cgi?id=1901449 Today someone closed it as a duplicate of RHEL 8.4: https://bugzilla.redhat.com/show_bug.cgi?id=1901449 When is it appropriate to track a bug against RHEL 8.4 vs CentOS Stream? What do we expect community members (inside and outside RH) to do in these cases? - Ken

11 14

Re: [CentOS-devel] Multiple Geo Rep issues due to SELINUX on CentOS 8.3
by Strahil Nikolov 05 Jan '21

05 Jan '21

Did anyone receive that e-mail ? Any hints ? Best Regards, Strahil Nikolov В 19:05 +0000 на 30.12.2020 (ср), Strahil Nikolov написа: > Hello All, > > I have been testing Geo Replication on Gluster v 8.3 ontop CentOS > 8.3. > It seems that everything works untill SELINUX is added to the > equasion. > > So far I have identified several issues on the Master Volume's nodes: > - /usr/lib/ld-linux-x86-64.so.2 has a different SELINUX Context than > the target that it is pointing to. For details check > https://bugzilla.redhat.com/show_bug.cgi?id=1911133 > > - SELINUX prevents /usr/bin/ssh from search access to > /var/lib/glusterd/geo-replication/secret.pem > > - SELinux is preventing /usr/bin/ssh from search access to .ssh > > - SELinux is preventing /usr/bin/ssh from search access to > /tmp/gsyncd-aux-ssh-tnwpw5tx/274d5d142b02f84644d658beaf86edae.sock > > Note: Using 'semanage fcontext' doesn't work due to the fact that > files created are inheriting the SELINUX context of the parent dir > and you need to restorecon after every file creation by the geo- > replication process. > > - SELinux is preventing /usr/bin/rsync from search access on > .gfid/00000000-0000-0000-0000-000000000001 > > Obviously, those needs fixing before anyone is able to use Geo- > Replication with SELINUX enabled on the "master" volume nodes. > > Should I open a bugzilla at bugzilla.redhat.com for the selinux > policy? > > Further details: > [root@glustera ~]# cat /etc/centos-release > CentOS Linux release 8.3.2011 > > [root@glustera ~]# rpm -qa | grep selinux | sort > libselinux-2.9-4.el8_3.x86_64 > libselinux-utils-2.9-4.el8_3.x86_64 > python3-libselinux-2.9-4.el8_3.x86_64 > rpm-plugin-selinux-4.14.3-4.el8.x86_64 > selinux-policy-3.14.3-54.el8.noarch > selinux-policy-devel-3.14.3-54.el8.noarch > selinux-policy-doc-3.14.3-54.el8.noarch > selinux-policy-targeted-3.14.3-54.el8.noarch > > [root@glustera ~]# rpm -qa | grep gluster | sort > centos-release-gluster8-1.0-1.el8.noarch > glusterfs-8.3-1.el8.x86_64 > glusterfs-cli-8.3-1.el8.x86_64 > glusterfs-client-xlators-8.3-1.el8.x86_64 > glusterfs-fuse-8.3-1.el8.x86_64 > glusterfs-geo-replication-8.3-1.el8.x86_64 > glusterfs-server-8.3-1.el8.x86_64 > libglusterd0-8.3-1.el8.x86_64 > libglusterfs0-8.3-1.el8.x86_64 > python3-gluster-8.3-1.el8.x86_64 > > > [root@glustera ~]# gluster volume info primary > > Volume Name: primary > Type: Distributed-Replicate > Volume ID: 89903ca4-9817-4c6f-99de-5fb3e6fd10e7 > Status: Started > Snapshot Count: 0 > Number of Bricks: 5 x 3 = 15 > Transport-type: tcp > Bricks: > Brick1: glustera:/bricks/brick-a1/brick > Brick2: glusterb:/bricks/brick-b1/brick > Brick3: glusterc:/bricks/brick-c1/brick > Brick4: glustera:/bricks/brick-a2/brick > Brick5: glusterb:/bricks/brick-b2/brick > Brick6: glusterc:/bricks/brick-c2/brick > Brick7: glustera:/bricks/brick-a3/brick > Brick8: glusterb:/bricks/brick-b3/brick > Brick9: glusterc:/bricks/brick-c3/brick > Brick10: glustera:/bricks/brick-a4/brick > Brick11: glusterb:/bricks/brick-b4/brick > Brick12: glusterc:/bricks/brick-c4/brick > Brick13: glustera:/bricks/brick-a5/brick > Brick14: glusterb:/bricks/brick-b5/brick > Brick15: glusterc:/bricks/brick-c5/brick > Options Reconfigured: > changelog.changelog: on > geo-replication.ignore-pid-check: on > geo-replication.indexing: on > storage.fips-mode-rchecksum: on > transport.address-family: inet > nfs.disable: on > performance.client-io-threads: off > cluster.enable-shared-storage: enable > > I'm attaching the audit log and sealert analysis from glustera (one > of the 3 nodes consisting of the 'master' volume). > > > Best Regards, > Strahil Nikolov >

1 0

RFC: CentOS 8 SIG
by redbaronbrowser 05 Jan '21

05 Jan '21

This is an introductory Request For Comment to purpose a community SIG to run CentOS 8 from Jan 1, 2022 to June 30, 2024. The responsiblity of the SIG members will be to maintain a repository of Stream 8 packages which have been accepted for publication into RHEL 8 The benefit to the CentOS community should be two fold: (1) Hopefully smooth the transistion from CentOS 8 to either Stream or Elephant (2) Provide a repository for Stream 8 members to perform a dnf downgrade as needed The purposed SIG is also seeking a CentOS Governing board member as a sponsor.

4 4

SIG representatives for January Board meeting
by Rich Bowen 05 Jan '21

05 Jan '21

In our attempt to increase the openness of the board meeting process, the board has asked for a phased approach, with SIG leaders attending the meetings, before we open them entirely to the project, so that we can assess whether we're still able to complete business in the allotted time with more attendees. We appreciate your patience. To that end, I ask that each SIG let me know who they would like to send as a representative to the January board meeting (Wednesday, January 13th, 21:00 UTC) so that they can be added to the invite list for the meeting. You may send this info to me, or to Thomas Oulevey, board secretary. Thanks.

1 0

what uses the messages on mqtt.git.centos.org?
by Ken Dreyer 05 Jan '21

05 Jan '21

Hi folks, I was reading about the MQTT broker at mqtt.git.centos.org? (https://wiki.centos.org/Sources) Does anything in CentOS infrastructure consume those messages (for example, to automatically build packages in Koji based on Pagure pushes)? I was also wondering about https://github.com/CentOS/ansible-role-kojihub/commits/master/files/plugins… , does any other tool consume those messages? - Ken

4 3

Re: [CentOS-devel] Vote of Confidence
by Mark Mielke 04 Jan '21

04 Jan '21

On Sat, Jan 2, 2021 at 8:50 AM orkcu via CentOS-devel <centos-devel(a)centos.org> wrote: > I don't think CentOS (or any other clone/rebuild) was ever a Bazaar, it can not be if the goal is to be a good clone/rebuild. > Since the very beginning the control was in a handful of people, very tight, and I remember one crisis when the founder didn't want (was unable/unavailable) to release control of dns domain, sign keys and few other main components that now you complain RedHat don't want to release I think you are right. The original intent, and the announcements and documentation for the project suggested something greater, but the reality turned out to be difficulty in delegation and scale. This is a common problem for volunteer or non-profit organizations. It doesn't matter if you have 3000 people willing to work on your project for free, if you can't effectively assign them work to do. It's worse if you can't even scale beyond a small number like "3", as these 3 eventually move on, and there is no succession plan, resulting in the project failing. For many of us - I think we had a naive trust that this would be figured out, and we would be invited when the time came to invite us. However, it didn't happen, and in 2014, Red Hat offered to take the reins. It's not that Red Hat set out to destroy the community - it is only that Red Hat has a conflict of interest, and it is really difficult for this conflict of interest to not eventually result in favouring certain self-interest outcomes over other non self-interest outcomes, and this is exactly what is happening in 2021. In effect, it was an inevitable conclusion. It was even predicted by several people in 2014. A similar thing is playing out in Rocky right now, however, there is a great deal of accumulated know-how, access to resources, and sober reflection on what went wrong leading up to 2014 and 2020. 3000+ people willing to work for free, but probably only 70 will be able to directly contribute, and initially the number will be a lot fewer as the initial setup takes place. This is why I say that Rocky is what CentOS should have been in 2014. We all know it wasn't. Now there is a chance to fix this. It could be a very good thing. > I don't like CentOS to evolve to Stream, I agree there is a need of a cheap RHEL's quality distribution, and I think all the arguments given so far at the end (in the very bottom) it is about cost (money), from the people complaining about the end because we are losing a very good distro that was free/gratis, from RedHat it is about moving the money to a direction that might provide better benefits for the company. > If RedHat would offer its RHEL with a minimum price (20? 50? 100?) for self support and then charge for a ticket a good amount of money ( like 200? 500?), that might work for a lot of people who are complaining now, I think we all understand that everyone need to have an income to feed its needs, even the small shops that are trying to save in (software) costs as much as possible. If Red Hat had agreed to this in 2016 and 2017 when I was asking for a reasonable solution to our problem, the company I work for would still be a Red Hat only shop. This was an opportunity missed then, and I believe it will be an opportunity missed when the new plans are announced. I don't believe the new subscription plans will be enough to make them an attractive option, and after the stumble with CentOS, even a good subscription plan that might meet some use cases will be frowned upon as a result of this debacle. > Bottom line, I don't think we ever had a community built OS in CentOS, we had people of the community assisting in testing and QA, but not even that was open to the public. I might be wrong but I think even before 2014 we had builders that were not (much) active in mailing list or IRC, and that is OK, each person have different strengths. I don't think you are wrong. Healthy communities need to prioritize delegation and scalability. It means investing specific effort in ensuring that people of different skills and capabilities can successfully contribute to the project. -- Mark Mielke <mark.mielke(a)gmail.com>

7 9

Package AppStreams variants in CentOS Stream?
by Leon Fauster 04 Jan '21

04 Jan '21

Hey, corresponding to CentOS 8 Stream: will ALL package/module versions for the different AppStreams be available? Some appstreams are only available as latest version (maven, nginx, perl, php). Wish you all some nice and healthy Christmas days, Leon

3 4

Vote of Confidence
by redbaronbrowser 03 Jan '21

03 Jan '21

This is an *UNOFFICIAL* non-binding vote to help provide an assessment of the state of the CentOS community and provoke further discussion. On November 11th (7 weeks ago), the CentOS governance board voted to reduce the life span of CentOS 8 from 10 years to 2 years. One board member, Karsten Wade, this is part of Red Hat effort to close the openness gap. He also explained that there is an elephant of which the community has only been shown parts with a flashlight. The CentOS governance page describe the governing board as being like a greenhouse. Why is the greenhouse so darken that it can hide an elephant such that over the last 7 weeks it has never been fully shown in the brightness of day? Part of the problem is the governance board is packed with people that are not active members of the CentOS community and have made no effort to explain the board's actions to the community. Please vote on each of the following items with +1 (in favor), 0 (sustain), -1 (reject). If you vote to reject an item, please explain why. Should Brian Exelbierd be asked to resign from the CentOS governance board? Should Mike McLean be asked to resign from the CentOS governance board? Should Carl Trieloff be asked to resign from the CentOS governance board? Should Rich Bowen be asked to resign from the CentOS governance board? Is obfuscating the CentOS kernel patches consistent with Red Hat attempting to close the openness gap? Are you likely to ever assist with Stream if the CentOS 8 End of Life is December 31, 2021? Would you be more likely to help with Stream if the CentOS 8 End of Life was set to June 30, 2024? Please keep in mind this vote is *UNOFFICIAL* and only for the purpose of promoting discussion. Template for responding: BE resign: [+1|0|-1] [-1 reason] MM resign: [+1|0|-1] [-1 reason] CT resign: [+1|0|-1] [-1 reason] RB resign: [+1|0|-1] [-1 reason] Obfuscation = Openness: [+1|0|-1] [-1 reason] EOL 2021: [+1|0|-1] [-1 reason] EOL 2024: [+1|0|-1] [-1 reason]

7 10

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