devel

devel@lists.centos.org

3 participants
4613 discussions

[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

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