devel

devel@lists.centos.org

2 participants
4653 discussions

GitLab AMA Topic Follow Up: Branches
by Aoife Moloney 14 Dec '20

14 Dec '20

Hi everyone, I know there's a lot going on in CentOS right now, but I still wanted to share with you all the follow up on the GItLab AMA session on Branches, in case you wished to read about it. So below are some links to the original documents and chat logs from the IRC session, and the main body of this mail is the questions and answers pulled directly from the Q&A sheet that specifically relate to branches. * Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w * Chat log from session https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_w… * AMA Blog post https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346 * Here is this email in hackmd if you wish to view it there: https://hackmd.io/me-0oLN-Qtmff1qMX2S-DA?view ## Topic: Branches Force pushing - Protected Branches - Question: Fedora forbids force-push in the main projects but allows them in forks. Would this be feasible in GitLab in a way that people cannot revert? - Answer: This can be done with Protected branches, basically (https://docs.gitlab.com/ee/user/project/protected_branches.html#protected-b…) Archived branches - Protected Branches - Question: Fedora supports the concept of retired git `branch` (ie: archived) that no-one can commit. Does GitLab have an equivalent concept? (The retired status is not something project admins can change) - Answer: Yes this is possible with Protected Branches https://docs.gitlab.com/ee/user/project/protected_branches.html#protected-b… - Question: Extending to above question, the sla's or eol dates are coming from a 3rd party service, when a user pushes to git branch, it will check the eol in that service and rejects it if it is already eol'd. Is this possible in GitLab? - Answer: Instead of this we would probably use the Protected Branches in GitLab. We could leverage the APIs to mass configure the branches on eol dates. That would mean that for each git push we don’t need to look at a 3rd party service to know if we can push or not. - Question: It is not allowed for users to delete the branches, only certain people with certain access levels are allowed to perform this operation. Is this possible in GitLab? - Answer: Yes protected branches can be used here https://docs.gitlab.com/ee/user/project/protected_branches.html#protected-b… Push permissions - Question: In CentOS, members of a group (say: storage-sig) can push to any branch starting with c<int>-<sig-name>-* (so for example, they can push to : c8-storage-sig-v2.0 or c7-storage-sig), but they cannot push to any other branches, like: c8, c7 or any of the branches starting with c8-kernel-sig and so on. Would this be doable in GitLab? (in a way that project owner/maintainer cannot edit?) - Answer: A Custom Push Rule and server hook (pre-recieve Git hooks behind the scenes) could help with this. - Question: Can we set permissions at branch level? Esp can we set them with some regex matching? - Answer: permissions accept wildcards, but not regexes. Regex can be used with custom push rules. See https://docs.gitlab.com/ee/push_rules/push_rules.html and https://docs.gitlab.com/ee/user/project/protected_branches.html#configuring…. Hiding branches - Question: Is it possible to hide these retired branches from the UI? Say, hide branch names with f30 or lower? - Answer: This is not possible currently - Question: Currently a user is not allowed to rewrite the history. Is it possible? It would be nice to allow only certain people to do so. Although we might not use this, but its good to have just in case if we ever need it. - Answer: by default, only the `master` branch is protected against force push and deletion. It’s possible to configure other branches to be protected and who has permission to override. https://docs.gitlab.com/ee/user/project/protected_branches.html#configuring… Branch level orphaning - Question: Orphaning a package or repo? A maintainer (owner) of the package can decide to orphan a package, the maintainer should only be able to assign the package to the `orphan` user or any of the other maintainers of the package only. Is this possible to set this branch level as well? - Answer: Yes, in the sense that who is allowed to push or merge to a specific branch is controllable at the user or group level. This can be at the specific branch level or based on a wildcard match based on branch name. See configuring protected branches for more details. There is one more topic from the AMA session on Naming issues with `+` and I will include any other Q&A's from the sheet that have not been posted yet. This will be out next week. I hope you have been finding this concentrated topic email useful and informative. This has been an extremely different year for everyone & we as a team have found ourselves with very little time to give to this project since the initial announcement, but I hope to engage with the community much more directly in 2021 as I work through this GitLab project formally to make sure we are making the best choices for everyone, straight through from end user to sys-admin, and everyone in between. Have a lovely weekend everyone and thank you again for your engagement and patience! Kindest regards, Aoife -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

4 5

CentOS 8 Stream Migration from CentOS 8 Linux
by Agarwal, Swati 14 Dec '20

14 Dec '20

Dear CentOS Team, This is regarding latest notification released for CentOS 8 stream replacement from CentOS 8 Linux. We have some queries in which we need your inputs as we have many Clients using CentOS 8 Linux on their production environments: * The packages which are available in Centos 8, will the same packages be available in Centos stream 8 ? * RHEL is doing some CVE fixes for Centos 8 and they have given temporary fixes so RHEL will push those fixes in Centos Stream 8 and what will be their impacts ? * We have upgraded from Centos 8 to Centos stream 8 by following the steps below. a.) dnf install centos-release-stream b.) dnf swap centos-{linux,stream}-repos c.) dnf distro-sync d.) cat /etc/centos-releas Expected output : CentOS Stream release 8. Did we miss anything ? * Suppose if RHEL is developing a package so it won't be available in CentOS Stream 8 and if it is available then what will be the impact ? * After upgrading from Centos8 Linux to CentOS Stream release 8, can we compare the versions of packages before & after and see which got updated * using # rpm -qa * After CentOS stream, what will vault.centos.org show ? Also, will it be same as shown in access.redhat.com/downloads/packages from RedHat ? * https://access.redhat.com/downloads/content/69/ver=/rhel---7/7.9/x86_64/pac… * https://vault.centos.org/7.7.1908/os/Source/SPackages/ * The Packages that are currently shown in access.redhat.com/downloads/packages or vault.centos.org are officially released ones. After CentOS Stream for CentOS8, the Packages shown in access.redhat.com/downloads/packages or vault.centos.org would be Beta releases or Officially released ones ? Please help us to answer above questions. -Br Swati

2 1

[CentOS-devel] https://blog.centos.org/2020/12/future-is-centos-stream/
by Rich Bowen 13 Dec '20

13 Dec '20

The future of the CentOS Project is CentOS Stream, and over the next year we’ll be shifting focus from CentOS Linux, the rebuild of Red Hat Enterprise Linux (RHEL), to CentOS Stream, which tracks just ahead of a current RHEL release. CentOS Linux 8, as a rebuild of RHEL 8, will end at the end of 2021. CentOS Stream continues after that date, serving as the upstream (development) branch of Red Hat Enterprise Linux. Meanwhile, we understand many of you are deeply invested in CentOS Linux 7, and we’ll continue to produce that version through the remainder of the RHEL 7 life cycle. https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates CentOS Stream will also be the centerpiece of a major shift in collaboration among the CentOS Special Interest Groups (SIGs). This ensures SIGs are developing and testing against what becomes the next version of RHEL. This also provides SIGs a clear single goal, rather than having to build and test for two releases. It gives the CentOS contributor community a great deal of influence in the future of RHEL. And it removes confusion around what “CentOS” means in the Linux distribution ecosystem. When CentOS Linux 8 (the rebuild of RHEL8) ends, your best option will be to migrate to CentOS Stream 8, which is a small delta from CentOS Linux 8, and has regular updates like traditional CentOS Linux releases. If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options. We have an FAQ - https://centos.org/distro-faq/ - to help with your information and planning needs, as you figure out how this shift of project focus might affect you. [See also: Red Hat's perspective on this. https://www.redhat.com/en/blog/centos-stream-building-innovative-future-ent…]

44 122

[EXT] Re: https://blog.centos.org/2020/12/future-is-centos-stream/
by JD Maloney 12 Dec '20

12 Dec '20

>On 10/12/2020 16.50, Rich Bowen wrote: >> >> >>* On 12/9/20 12:32 PM, David Hrbáč wrote: *>>>* I don't use CentOS Stream, I use RHEL. I use RHEL to develop software *>>>* for RHEL and compatible OS clones, including CentOS. If Stream *>>>* retains *>>>* binary compatibility, and specifically kernel ABI compatibility, then *>>>* the users of the software packages we develop can continue to use *>>>* them. *>>>* If not, they can't. Simple as that. So please don't push rolling *>>>* kernel *>>>* updates to Stream that break the kernel ABI. *>>>>>>>>>* Rolling kernel updates are going to kill all the traditional HPC *>>>* clusters. Almost 25% of the TOP 500 HPC clusters run CentOS. See *>>>* https://www.top500.org/statistics/list/ <https://www.top500.org/statistics/list/> *>>>* <https://www.top500.org/statistics/list/ <https://www.top500.org/statistics/list/>> *>> >>* I was under the impression that practically all of those run custom *>>* kernels anyway, right? * > Obviously in no way generally valid: In the last ~5 years I have been > involved in / responsible for the administration of two systems that > have been listed in the TOP500 (both lower half of TOP500, but top field > of Green 500 at their respective time). Both systems are running CentOS > 7 with vanilla kernel. We only add external 3rd party kernel modules as > required. > There have been plans/conversations/ideas about updating the newer > system to CentOS Linux 8 soon. However, with the changed perspective of > CentOS, this plan is now dead as well. Depending on how CentOS Stream > works out (i.e., kernel ABI compatibility to current RHEL minor > release), switching to CentOS Stream might be an option. Same here, almost a decade in HPC and have admin'd multiple systems in the Top 100, attended SC conferences regularly, as well as other gatherings in the HPC community, all the systems I know of personally, and I know of a few in the Top 10; dozens in the Top 100, currently run vanilla kernels. While I can't speak for all of the vast amount of Supercomputing centers, from all my experience I don't know of many places that run custom kernels. >> Can you elaborate on what you mean by rolling kernel updates? If you >> mean wholesale kernel rebases (e.g. kernel-5.8 -> kernel-5.9), that's >> not what Stream will be doing. >> Stream will include more frequent updates of the *RHEL* kernel, where >> we take the RHEL kABI whitelist very seriously. It is literally the >> RHEL kernel. In the context of HPC deployments, they could use Stream >> and choose when to update and reboot those machines based on the >> kernel updates that come out, just as the would with CentOS Linux. This isn't possible, I'll use an example from IBM as maybe that'll help illustrate it better. When RHEL 8.3 was released (for example but same applies to 7.8, 7.9, 8.1, 8.2, etc.), we couldn't just upgrade to it as the kernel changes break the ability to build the kernel module for IBM Spectrum Scale -- the cluster's main shared file system (eg. running mmbuildgpl would fail, you would have to downgrade the kernel to the prior .x release's version to get it to run); and the Lustre project is in the same boat; btw these two file systems service the VAST majority of HPC systems around the world. We also have to build Mellanox (Nvidia Networking) OFED against the kernel and use their drivers that are released with RHEL updates. Upgrading the kernel to something ahead of the latest official RHEL release (eg. the current, what will be the 8.4 kernel, in Stream) would break both cluster networking and storage pretty much every time, it has every .x --> .(x+1) release I've ever seen over the past 4 years, which would render the entire cluster unusable. Thus I just do not see a way as you guys describe it where Stream could ever be a viable option as we need the kernel to freeze, have vendors get their drivers and software to work with it, THEN deploy it. What is in Stream will always be too far ahead of what the vendors have available and built/tested against. We could use yum/dnf to lock the kernel versions (and some other supporting packages) but that could have other implications and adds a lot of fragility as one is essentially trying to un-stream a stream release. This move has alienated the HPC community from CentOS, and the naivety that RH folks are showing about the HPC ecosystem is even more saddening. HPC users that are on CentOS 7 will likely get stuck there for a bit, while they re-evaluate offerings and look for where to jump to next, which is sad as 8 has/had a lot of nice things. Those who have already jumped to CentOS 8 are now in a very tricky spot, which can not be understated. Red Hat's lack of plan to go along with this announcement is mind boggling, something I'd expect from some Silicon Valley startup, not a seasoned industry player. A "hang tight we'll get back to you on a new offering in 1H 2021" (and if you don't like/can't afford our offer congrats you now have 6 months to lift and shift your entire environment and the dozens to hundreds of end-user applications you support) is an insult to folks who run these systems. I completely get the benefits of CentOS Stream for RHEL development, it makes a lot of sense and for that I think Stream is a great thing. Also likely a good thing for the hyperscalers who likely run most, if not all, their stuff in user space and have large development budgets to support their operations. Though I've yet to see an answer from RH, about why both CentOS proper and Stream couldn't continue as they were since they aren't mutually exclusive. We're left to assume it's about extracting more money from users and (an attempt at) forcing more community/vendor involvement further upstream. JD

1 0

Re: [CentOS-devel] Ceph on arm32 - failing to compile devtoolset-8-gcc-8.3.1-3.1.el7.src.rpm
by Oliver Weinmann 12 Dec '20

12 Dec '20

Hi Pablo, thanks a lot for your reply. The src.rpm I'm using is this one: https://cbs.centos.org/kojifiles/packages/devtoolset-8-gcc/8.3.1/3.1.el7/sr… It's gcc8 so the patch you linked is not really fitting. :( If you have time and could take a look that would be really cool. Best Regards, Oliver Am 12.12.2020 um 10:26 schrieb Pablo Sebastián Greco: > > On 11/12/20 11:28, Oliver Weinmann via CentOS-devel wrote: >> Hi Folks, >> >> For a small home project I would like to get cephadm working on my >> Odroid HC-2 (armhf 32). Maybe this is not going to work but I want to >> at least give it a try. I see that there are only arm64 packages and >> containers available from the Ceph repo. So I thought I just go ahead >> and compile the dependency packages myself and build a new container >> with CentOS7 arm32. Luckily there is a CentOS 7 arm32 container but I >> still need to compile the packages. After downloading all the src >> rpms i started building them and now I ended up to compile this >> package from the SCL repo as it is not available for arm32: >> >> devtoolset-8-gcc-8.3.1-3.1.el7.src.rpm >> >> It fails with an error of: >> >> checking if mkdir takes one argument... no >> *** Configuration armv7hl-redhat-linux-gnu7E not supported >> make[2]: *** [configure-stage1-gcc] Error 1 >> make[2]: Leaving directory >> `/root/rpmbuild/BUILD/gcc-8.3.1-20190311/obj-armv7hl-redhat-linux7E' >> make[1]: *** [stage1-bubble] Error 2 >> make[1]: Leaving directory >> `/root/rpmbuild/BUILD/gcc-8.3.1-20190311/obj-armv7hl-redhat-linux7E' >> make: *** [profiledbootstrap] Error 2 >> error: Bad exit status from /var/tmp/rpm-tmp.knxvjm (%build) > This looks very close to this fix we had to add to make gcc work on > arm > https://git.centos.org/rpms/devtoolset-7-gcc/blob/c7/f/SPECS/gcc.spec#_319 > (I'm linking to gcc7 because I can't find the other commit, but it is > the same thing). > Let me know if that helps and if it is still failing, point me to as > spec file or an srpm and I'll take a look. >> >> >> RPM build errors: >> Bad exit status from /var/tmp/rpm-tmp.knxvjm (%build) >> >> real 13m36.412s >> user 17m57.828s >> sys 3m47.905s >> >> I looked up the build log for arm64 and so I figured out that the >> next step is to access a directory called arm here: >> >> /root/rpmbuild/BUILD/gcc-8.3.1-20190311/gcc/config >> >> in the extracted source. Somehow the build process thinks my system >> is armv7hl-redhat-linux-gnu7E instead of arm and so it tries to >> access the armv7hl-redhat-linux-gnu7E directory which doesn't exist >> and fails. I simply created a symlink and this seems to be working. >> >> ln -sf arm armv7hl-redhat-linux-gnu7E >> >> Not sure if this is in general a bad idea. So I got a lot further. >> But then it fails again with this error: >> >> In file included from /usr/include/features.h:399, >> from /usr/include/stdio.h:27, >> from ../.././libgcc/../gcc/tsystem.h:87, >> from ../.././libgcc/libgcc2.c:27: >> /usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-soft.h: No such >> file or directory >> # include <gnu/stubs-soft.h> >> ^~~~~~~~~~~~~~~~~~ >> compilation terminated. >> make[3]: *** [_muldi3.o] Error 1 >> make[3]: Leaving directory >> `/root/rpmbuild/BUILD/gcc-8.3.1-20190311/armv7l-unknown-linux-gnueabihf/libgcc' >> make[2]: *** [all-stage1-target-libgcc] Error 2 >> make[2]: Leaving directory `/root/rpmbuild/BUILD/gcc-8.3.1-20190311' >> make[1]: *** [stage1-bubble] Error 2 >> make[1]: Leaving directory `/root/rpmbuild/BUILD/gcc-8.3.1-20190311' >> make: *** [all] Error 2 >> >> real 88m2.283s >> user 67m23.211s >> sys 6m7.984s >> >> I can't find any good info on google on how to deal with this one. >> Any ideas? >> >> Best Regards, >> >> Oliver >> >> >> > Pablo.

1 0

Ceph on arm32 - failing to compile devtoolset-8-gcc-8.3.1-3.1.el7.src.rpm
by Oliver Weinmann 11 Dec '20

11 Dec '20

Hi Folks, For a small home project I would like to get cephadm working on my Odroid HC-2 (armhf 32). Maybe this is not going to work but I want to at least give it a try. I see that there are only arm64 packages and containers available from the Ceph repo. So I thought I just go ahead and compile the dependency packages myself and build a new container with CentOS7 arm32. Luckily there is a CentOS 7 arm32 container but I still need to compile the packages. After downloading all the src rpms i started building them and now I ended up to compile this package from the SCL repo as it is not available for arm32: devtoolset-8-gcc-8.3.1-3.1.el7.src.rpm It fails with an error of: checking if mkdir takes one argument... no *** Configuration armv7hl-redhat-linux-gnu7E not supported make[2]: *** [configure-stage1-gcc] Error 1 make[2]: Leaving directory `/root/rpmbuild/BUILD/gcc-8.3.1-20190311/obj-armv7hl-redhat-linux7E' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/root/rpmbuild/BUILD/gcc-8.3.1-20190311/obj-armv7hl-redhat-linux7E' make: *** [profiledbootstrap] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.knxvjm (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.knxvjm (%build) real 13m36.412s user 17m57.828s sys 3m47.905s I looked up the build log for arm64 and so I figured out that the next step is to access a directory called arm here: /root/rpmbuild/BUILD/gcc-8.3.1-20190311/gcc/config in the extracted source. Somehow the build process thinks my system is armv7hl-redhat-linux-gnu7E instead of arm and so it tries to access the armv7hl-redhat-linux-gnu7E directory which doesn't exist and fails. I simply created a symlink and this seems to be working. ln -sf arm armv7hl-redhat-linux-gnu7E Not sure if this is in general a bad idea. So I got a lot further. But then it fails again with this error: In file included from /usr/include/features.h:399, from /usr/include/stdio.h:27, from ../.././libgcc/../gcc/tsystem.h:87, from ../.././libgcc/libgcc2.c:27: /usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-soft.h: No such file or directory # include <gnu/stubs-soft.h> ^~~~~~~~~~~~~~~~~~ compilation terminated. make[3]: *** [_muldi3.o] Error 1 make[3]: Leaving directory `/root/rpmbuild/BUILD/gcc-8.3.1-20190311/armv7l-unknown-linux-gnueabihf/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/root/rpmbuild/BUILD/gcc-8.3.1-20190311' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/root/rpmbuild/BUILD/gcc-8.3.1-20190311' make: *** [all] Error 2 real 88m2.283s user 67m23.211s sys 6m7.984s I can't find any good info on google on how to deal with this one. Any ideas? Best Regards, Oliver

1 0

mdevctl missing in AppStream
by Sandro Bonazzola 11 Dec '20

11 Dec '20

Hi, I'm looking for mdevctl package which should be in AppStream but I can't find it. I see the package is on git: https://git.centos.org/rpms/mdevctl/tree/c8 Any clue? -- 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. <https://mojo.redhat.com/docs/DOC-1199578>*

1 0

CentOS-Gold3 at Arizona State University
by Nick Piacentine 11 Dec '20

11 Dec '20

Hello, Could you please confirm that you are no longer using this server? I'm trying to clear out rack space, and my firewall doesn't show any use in the past 2+ years. Would you like us to dispose of the hardware, or is there another use you have for the 7+ year old hardware? Thanks, Nick ----- Nick Piacentine Director, Information Technology Mars Space Flight Facility & Instrument Development Lab Arizona State University

1 0

koji-ansible and CentOS Stream
by Ken Dreyer 10 Dec '20

10 Dec '20

Hey folks, I'm not sure where the current CentOS Stream Koji configuration is stored at the moment, but I wanted to link to this project for managing Koji configs with Ansible: https://github.com/ktdreyer/koji-ansible Some teams are using this to manage some large Koji instances inside Red Hat, and it's been working well. It's good for managing initial configurations ("day 1 operations") as well as making changes over time ("day 2 operations"). Like most stuff with Ansible, it makes configurations repeatable and easier to review. As an example, I captured some of our Storage SIG CBS tag and target configurations in Ansible here: https://github.com/ktdreyer/storage-sig-utils/tree/master/ansible It would be great to use koji-ansible as we ramp up CentOS Stream. I'd be happy to help answer any questions about this tool. - Ken

1 0

https://blog.centos.org/2020/12/future-is-centos-stream/
by Konstantin Boyandin 10 Dec '20

10 Dec '20

Hello, > The future of the CentOS Project is CentOS Stream, and over the next > year we’ll be shifting focus from CentOS Linux, the rebuild of Red Hat > Enterprise Linux (RHEL), to CentOS Stream, which tracks just ahead of a > current RHEL release. CentOS Linux 8, as a rebuild of RHEL 8, will end > at the end of 2021. CentOS Stream continues after that date, serving as > the upstream (development) branch of Red Hat Enterprise Linux. > > Meanwhile, we understand many of you are deeply invested in CentOS Linux > 7, and we’ll continue to produce that version through the remainder of > the RHEL 7 life cycle. > https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates Yeah, deeply, in many a sense. I am a sysadmin, attending to quite a lot of systems, and CentOS was a real blessing. Now, as I see it, CentOS is becoming a sandbox for upcoming RHEL minor releases, so one can bid farewell to free to use, stable, reliable and predictable OS. I am currently in process of upgrading multiple CentOS-driven systems, so this piece of news has become a nasty surprise. Looks like a major decision should be taken right now. Apart from migrating to Oracle Linux (which I wouldn't like at all), and buying RHEL itself, what are other possible alternatives (just curious)? Thanks. Sincerely, Konstantin

12 16

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