devel June 2021

devel@lists.centos.org

36 participants
30 discussions

anaconda dependency calculation?
by Nicholas Byrne 04 Aug '25

04 Aug '25

Hi all, I'm trying to find a tool that calculates all dependencies for a specific package or group of packages for use with CentOS 5 (beta) with the intention of putting together a custom single CD build of CentOS 5. With CentOS 4 i used a python script that used the hdrlist module to find all dependencies which borrowed code from a number of sources. I've looked at yumdownloader and how it checks dependencies (using the --resolve option) but if i pass it the list of packages defined in say the Base and the Core yum groups which generally form an absolute minimal install i end up with about 200 packages. If i do a custom install (using beta 1 disks) and deselect everything i end up with over 300 packages. So i'm guessing anaconda calculates dependencies in a slightly different way, can anyone point me to files/code where i should be looking to find out? Thanks very much in advance for help Nick This e-mail is the property of Quadriga Worldwide Ltd, intended for the addressee only and confidential. Any dissemination, copying or distribution of this message or any attachments is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from Quadriga may be monitored. Quadriga cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of Quadriga.

6 11

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel June 2021