devel

devel@lists.centos.org

4604 discussions

[Storage-SIG][BugReport] ceph-common broken dependencies on CentOS Stream 8 / ppc64le
by Sandro Bonazzola 22 Sep '21

22 Sep '21

Hi, oVirt CI started to report the following error: Error: Problem: package ceph-common-2:16.2.6-1.el8s.ppc64le requires libpmemobj.so.1()(64bit), but none of the providers can be installed - cannot install the best candidate for the job - package libpmemobj-1.9.2-1.module_el8.4.0+806+82bbed84.ppc64le is filtered out by modular filtering - package libpmemobj-1.9.2-1.module_el8.5.0+756+4cdc1762.ppc64le is filtered out by modular filtering Can you please have a look? 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 1

Stream 9 and dnf-automatic
by Patrick Riehecky 19 Sep '21

19 Sep '21

I've been thinking about the defaults in CentOS Stream 9 and wanted to chat about the workflows of the system. I'd like to make the following proposal to see what people think about it: * add `dnf-automatic` to comps.xml @BASE as a "default" package * set `dnf-automatic-install.timer` to enabled via `system-preset` similar to `90-default.preset` Before imminently saying "No, absolutely not" lets look at the workflow options: When setting defaults for updates, there are a few choices: * do not apply * notify the user/admin * apply and notify the admin * apply but do not notify The "apply but do not notify" option feels like a non-starter to me. Silent system changes are not good. The current default in CentOS Stream 8 is "do not apply". I've no interest in changing CentOS Stream 8 on this front. # I'd like to ask, is this a good default? For professional admins with a clear policy on testing and scheduling updates, I believe it is a good default. For novices who may not have these processes and procedures in place, I believe this is not a good default. For these folks I'd recommend "apply and notify the admin". # Why change? I'd like to ask a specific question: 48 hours after the release of update packages for Heartbleed or ShellShock, how many CentOS systems in - in their default configuration - installed the updates? Or perhaps a more pointed question, how many folks running EL7 still haven't applied those patches? If the default was "apply and notify the admin", we'd be confident that most folks out there are patched. The default state would generally result in more secure hosts as the updates get applied. Stream 9 is a continuous delivery OS but, if folks don't apply the updates, are they delivered? The current recommendations from the scap-security-guide are: - install and enable dnf-automatic - configure dnf-automatic to apply updates - set a location for `root`'s email via /etc/aliases This is an "apply and notify the admin" workflow. Scientific Linux defaults to "apply and notify the admin". The SL community is comfortable with this default. # Why is the default "do not apply"? As I see it there are basically a few options: A) any change to the system state creates risk of unplanned outage/bugs/behavior changes. B) as a community we trust system admins to "do the right thing" for their environment. C) if we publish a buggy update and it gets applied by default, that isn't great for our reputation. Argument (A) is really strong. Sites with a clear policy on testing and scheduling updates have those policies explicitly because of these risks. To be clear, I like and support those policies. Everyone should have them. But not everyone does. I think Argument (B) can bend in any direction. If we can trust an admin to "do the right thing" and install updates on a schedule of their choosing, can we not also trust them to add `systemctl disable dnf-automatic-install.timer` to their kickstart/puppet/ansible/etc? As a default, but - not mandatory package - it could also be excluded with `-dnf-automatic` in the `%packages` section. I'm not sure that Argument (C) is terribly strong. A giant botnet of unpatched hosts isn't great either. I'm not sure that is our responsibility, but "safer defaults" feels like a good call. # Further reading https://fedoraproject.org/wiki/AutoUpdates#Why_use_Automatic_updates.3F https://github.com/ComplianceAsCode/content/issues/5180

4 4

Pre-release version of CentOS Stream 9.
by Thomas Stephen Lee 16 Sep '21

16 Sep '21

Hi, How do we go about installing a pre-release version of CentOS Stream 9 ? Thanks --- Lee

5 6

Board AMA, #centos-meeting, Wednesday, 14:00 UTC
by Rich Bowen 15 Sep '21

15 Sep '21

Reminder: On Wednesday, September 15th, at 14:00 UTC, (some of the) the board of directors will be available in #centos-meeting on Libera.chat IRC network, for your questions. This is a good time to ask about the board meeting that happened last week. (Today has gotten away from me, but I will attempt to post the meeting minutes tomorrow morning) or, really, any board-level topic. --Rich

1 3

Schedule and Registration for CentOS Dojo
by Rich Bowen 07 Sep '21

07 Sep '21

The (tentative) schedule and registration for the upcoming CentOS Dojo are now available. Join us for two days of technical and community talks. Details at https://wiki.centos.org/Events/Dojo/October2021 Registration is free, and the event is online. --Rich

1 0

Proposal: Add pkg- prefix to package names in CentOS dist-git
by Florian Weimer 06 Sep '21

06 Sep '21

Gitlab cannot support an undocumented set of Git repository names. Currently, this list appears to contain at least these names: badges blame blob builds commits create create_dir edit files find_file new preview raw refs tree update wikis There may be additional constraints for: environments gitlab-lfs info We have at least one collision today, tree. One way to avoid these problems is to prefix all package names with “pkg-”. This way, future collisions become extremely unlikely, at the cost of a one-time large rename. The alternative would be to main an exception mechanism for colliding package names such as “tree”. This has been the current approach, but as far as I can tell, it is not working. Implementing this change depends on the completion of the package removal process because it does not appear worthwhile to rename packages which no longer exist in the distribution. Thanks, Florian

7 15

CentOS SIG spin policy and guidelines
by Davide Cavalca 03 Sep '21

03 Sep '21

Hello, as discussed during the last Board meeting, we have drafed a policy for CentOS SIGs that would like to produce distribution spins. You can find the current draft at https://hackmd.io/pPixYTZ8QmyJcjoJq_V9dA . We'd welcome any comments and feedback from the community to help get this finalized. Thanks! Cheers Davide

1 0

PackagingCon call for presentations
by Rich Bowen 01 Sep '21

01 Sep '21

The PackagingCon call for presentations has been extended another week, so if this is something that you're interested in, you still have a couple of days to get something in. https://pretalx.com/packagingcon-2021/cfp Event details at https://packaging-con.org/

1 0

GNOME crashes in Wayland whenever I try to move a file in Nautilus
by Steven R 01 Sep '21

01 Sep '21

This behavior only started after this morning's pile of updates. I run GNOME with Wayland, and whenever I try to move a file in Nautilus, the GNOME session crashes, and I'm thrown into a console. I tried an older kernel, and the behavior is the same. This only happens in Wayland. In an X11 session, everything works, so the workaround is to run X11. I saw that gnome-shell was one of the packages upgraded today. Is that where a bug should be filed? I don't know where to look for this in the logs.

4 7

CentOS Stream 9 timetable
by Steven Rosenberg 30 Aug '21

30 Aug '21

Can anybody provide a rough estimate on a release (Alpha, Beta, RC, etc) of CentOS Stream 9 -- the point where we can install and then update from the repo?

5 6

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