devel October 2020

devel@lists.fedoraproject.org

226 participants
416 discussions

F34 Change proposal: MariaDB 10.5 (Self-Contained Change)
by Ben Cotton 18 Nov '20

18 Nov '20

https://fedoraproject.org/wiki/Changes/MariaDB_10.5 == Summary == Update of MariaDB ('mariadb' package) in Fedora from 10.4 to 10.5 version. [[Category:Package MariaDB]] == Owner == * Name: [[User:mschorm| Michal Schorm]] * Email: mschorm(a)redhat.com == Detailed Description == Update of MariaDB package in Fedora from 10.4 version to 10.5 version. == Benefit to Fedora == I'm cooperating with the upstream to bring the latest stable software to Fedora users. 10.5 series introduces number of enhancements, which cannot be found in previous series. Overview of the new features can be found here: https://mariadb.com/kb/en/changes-improvements-in-mariadb-105/ == Scope == * Proposal owners: **Prepare MariaDB 10.4 as a module for Rawhide and atleast one stable Fedora release (done) so users which want to stay on the current release have the possibility. This also serve as a failover mechanism in case of issues with the 10.5. **Prepare MariaDB 10.5 as a module for Rawhide and atleast one stable Fedora release (done in Rawhide; the rest in BODHI) so users can test the 10.5 in advance. (installing 10.5 module on already stable release) This also serve as a upgrade path - users can install 10.5 module on Fedora release which have 10.4 in base; and then upgrade to 10.5 module on a Fedora release which will have 10.5 in base. **Release MariaDB 10.5 to Rawhide (blocked; 10.5 modules needs testing first) **Check software that requires or depends on 'mariadb' or 'galera' package for incompatibilities This shouldn't be an issue in general, as vast majority of the software requires client library, provided by "mariadb-connector-c" package, which won't change. **Gather user input on the changes between MariaDB 10.4 and 10.5 * Other developers: N/A (not a System Wide Change) * Release engineering: * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == The MariaDB client library is compatible, so the shouldn't be any issues and / or need for rebuild of dependent packages. ==='''UPDATE (10/2020)'''=== MariaDB 10.5 modules are now available for Fedora Rawhide and in BODHI for the stable releases == How To Test == Usual testing as when upgrading between major MariaDB versions. Test that all other software runs well with MariaDB 10.5. Report any issues, so I can reach the different upstreams and check if they plan update their software to support MariaDB 10.5 and when. == User Experience == The users will have to upgrade their databases the same way as between major MariaDB versions. If the users want to stick with MariaDB 10.4 for a little longer, the MariaDB 10.4 module is available for them in all stable Fedora releases as well as in Rawhide. If the users want to test the 10.5 series beforehand, the MariaDB 10.5 module is available. == Dependencies == Since the client library ('mariadb-connector-c') is not changing, dependent software should work fine. Only a rare cases builds against the server part of MariaDB. (e.g. building a server plugin) == Contingency Plan == Modules will provide the functional version of MariaDB 10.4, available to all users. * Contingency mechanism: Fedora Modules for 10.4 available * Contingency deadline: already in place * Blocks release? N/A (not a System Wide Change) * Blocks product? N/A (not a System Wide Change) == Documentation == Upgrade startegy: https://mariadb.com/kb/en/library/upgrading-from-mariadb-104-to-mariadb-105/ Upgrading and incompatibilities: https://mariadb.com/kb/en/library/upgrading-from-mariadb-104-to-mariadb-105… == Release Notes == Release notes for each release: https://mariadb.com/kb/en/library/release-notes-mariadb-105-series/ Overall overview of the changes and improvements: https://mariadb.com/kb/en/library/changes-improvements-in-mariadb-105/ -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

6 10

Btrfs question for Fedora 33 beta. How can I add nocow to /var
by Leslie Satenstein 13 Nov '20

13 Nov '20

I am looking to some performance considerations for the /etc/fstab btrs default config generated by anaconda. It appears to have created a subvol for root (root00) and for home (home00). I would like to put in /opt with it's subvol, and to migrate the /var to a subvol where I can specify nodatacow. Leaving /var as a directory under /, without specifying nodatacow concerns me as it is a very "busy" directory, and can fill up the root00 subvol quite quickly. I tried to create the two subvars, without success. I even went so far as to examine the grub menu entries. Is this not possible with Fed33 beta?

4 10

[ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide
by Aleksandra Fedorova 12 Nov '20

12 Nov '20

Hi, all, this is the informational message, no action required. Upon agreement between gcc maintainers and ELN SIG we would like to switch ELN buildroot to use GCC11 ahead of Fedora Rawhide. Though ELN is defined as the buildroot where Fedora Rawhide code is rebuilt into EL-like environment, in the ELN proposal we also mentioned that ELN can be used to test certain buildroot-related features on the side so it doesn't block Fedora Rawhide development. We think that GCC11 is one such feature, where we can benefit from testing it first on a small subset of the Fedora content in a separate environment. We would like to invite everyone to join this effort. The work is currently tracked on Github: https://github.com/fedora-eln/eln/issues/8 Once GCC11 is merged to the eln tag in koji, one would be able to use it via, for example, mock or container environment: quay.io/fedoraci/fedora:eln-x86_64 For more info on ELN please refer to ELN Docs (as soon as I update them, which hopefully happens later today): https://docs.fedoraproject.org/en-US/eln/ -- Aleksandra Fedorova bookwar at #fedora-devel and #fedora-ci

19 63

FESCo election nominations are now open
by Ben Cotton 06 Nov '20

06 Nov '20

Beginning today through 11 Nov, you may nominate candidates for the 5 open seats on the Fedora Engineering Steering Committee (FESCo). To nominate yourself (or others, if you check with them first), visit: https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations FESCo is currently selecting the questions for the interview questionnaire, which will be finalized before the beginning of the interview period. For more information, see the Community Blog post: https://communityblog.fedoraproject.org/fedora-33-elections-nominations-now… -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…

1 1

ld segfaults on rawhide
by Christoph Junghans 06 Nov '20

06 Nov '20

Hi, I am getting the following error on all archs on rawhide: collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped in https://koji.fedoraproject.org/koji/taskinfo?taskID=54629411 any ideas? Christoph -- Christoph Junghans Web: http://www.compphys.de

7 12

GitLab AMA Topic Discussion: Permissions & Access
by Aoife Moloney 05 Nov '20

05 Nov '20

Hi everyone, Thanks again for your involvement in the GitLab AMA session on IRC in September. As promised, this is the first of a 5-part series breaking down main topics that came up during the session. I will send a topic every week for discussion to both Fedora and CentOS devel lists. I have pulled the relevant questions and answers from the original hackmd doc into one email. If you would like to discuss this topic specifically, here might be a good place to do so. I dont consider myself technical enough to weigh in on details, but I am happy to facilitate as best I can via email. And more importantly (for me), learn from the discussion too. Here are some links to resources as well: * 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/1pjX1cVnTjekOLVowj5UiQ?view ## Topic: Permission and Access - Question: Fedora has a group-based access system. People in the `packager` group have (commit) access to only the packages they maintain. People in the `provenpackager` group have (commit) access to all the active packages, but a few (for legal reason). People in the `releng` group have commit access to all the packages. Is this an access model that GitLab can support? If not, how would this work in a GitLab world? How would notifications work (Esp consider people in the `provenpackager` or `releng` group do not want to be notified for all the projects they have access to)? - Answer: What I explored was something along the lines of : - Packager → Using GitLab’s Maintainer or Developer role for the project they maintain (Maintainer have the ability to access project settings and change pretty much everything there, so that might be blocking here, Developer only have commit access, so we need another way to change some settings for Packagers) - Co-Maintainer → Using GitLab’s Developer role (commit access) - Proven-Packager → GitLab’s Developer role on all repo (expect 2) - Release Engineer/Admin/etc .. → GitLab’s Owner role on all repos - This is not an exact matching with what we currently have but should give us a way to experiment with this and look at what is acceptable or not. - There is also a GitLab ticket (https://gitlab.com/gitlab-org/gitlab/-/issues/7626) to implement policies for the project that could give more granular control of permissions. - Gitlab’s notifications are quite granular and can be managed at the different levels (Merge Requests, Projects, Group, Global) https://docs.gitlab.com/ee/user/profile/notifications.html#global-notificat… - Question: Fedora supports the concept of a retired `project` (ie: archived) that no-one can commit to. Does GitLab have an equivalent concept? (The retired status is not something project admins can change) - Answer: There is an option to have a “retired” group which is configured to have nobody with commit access. Then retiring a project would simply mean to move the project from the “rpm” group to “retired” group for example. There is also possibility to simply archive projects https://docs.gitlab.com/ee/user/project/settings/#archiving-a-project - Question: could gitlab (inc) maintain a Community Edition GitLab instance that Fedora uses? - Answer: There is no plan to create custom versions of GitLab for customers. Instead, GitLab encourages paid customers and free users alike to contribute upstream to make sure that GitLab continues to work well for the most amount of users possible. As an open core company, GitLab has a public roadmap and works with its community members to build a great product. GitLab regularly engages with its community and takes into account its feedback. As a result, features are often ported down into lower tiers in order to make the Community Edition and Free tiers continuously more useful (see example of 18 features moved to open source). GitLab hosting is available to users of GitLab.com SaaS, but GitLab does not offer hosting and management for GitLab CE or EE instances. - Question: Can project creation be restricted to a specific group of people in GitLab? - Answer: Yes this can be configured at the instance level (https://gitlab.com/help/user/admin_area/settings/visibility_and_access_cont…) or at the group level (https://gitlab.com/help/user/group/index.md#default-project-creation-level) - Question: Can project (main project, not fork) deletion be restricted to a specific group of people in GitLab? (ie: project owner/maintainer must not be allowed to delete a main project, they can delete their own fork of course) - Answer: There is an issue https://gitlab.com/gitlab-org/gitlab/-/issues/233379 that could help with this by requiring an additional person approve the deletion & there’s a related issue https://gitlab.com/gitlab-org/gitlab/-/issues/227468 to create a list of authorized approvers for these types of changes (not MRs) that sounds aligned with this ask - Question: How would group membership be sync to GitLab? - Answer: We are still not 100% clear on that, since GitLab supports OpenIDC & we will need to investigate if we could make use of the group scope returned by AAA. Otherwise we will need a solution to sync the groups to GitLab most likely using API calls. - Question:Will there be better support for Podman in CI workflows in GitLab? - Answer: Short term solution might be using a custom executor, long term solution would be getting the Runner executor podman (#4185) feature request issue scheduled and closed. Ultimately product team schedules work, while everyone can contribute MRs or fixes ahead of schedule. In the past, I've seen a lot of enthusiasm from GitLab team members in helping solve problems from Open Source Program members whenever possible. These are all the questions that had answers I could spot from the larger hackmd document, however my apologies if I missed any. next week I will pull in all the questions and answers on 'Message Bus' in a new email and send for discussion. I know there are still some questions unanswered so I will try to chase down answers to these, but it could take some time. If I can get them answered over the next few weeks, I will send a 'misc' topic email at the end of these few weeks worth of emails. I hope you find this helpful and it is going to take some time to work through everything so thank you for your patience and involvement in this, it is very much appreciated. Kindest regards, Aoife -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…

6 7

odd behaviour for copr builds and openmpi
by Mark Olesen 04 Nov '20

04 Nov '20

This will presumably also affect Fedora, but need to recheck. We are experiencing some very odd build behaviour using copr to compile for various Fedora and CentOS/RedHat versions (https://copr.fedorainfracloud.org/coprs/openfoam/openfoam) The built package on centos8 is automatically given the requirement - libmpi.so.40()(64bit) But the openmpi package actually provides - libmpi.so.40()(64bit)(openmpi-x86_64) Anyone have an idea what is going wrong here? /mark

3 4

EOL and Obsoletes in Modularity
by Martin Curlej 03 Nov '20

03 Nov '20

Hi, EOL and Obsoletes were planned as a feature of Modularity. The feature should enable to set shorter/longer life cycles on Modules than the OS release. The initial idea was to set this information in the disgit metadata of a Module. As time went by the requirements have changed. From my point of view right now it seems that this information should not be a part of the module (disgit, repository metadata). It is prone to human error when we leave this in the hands of a packager. So this would need a review of Engineering to be reliable. Next is that a lot of 3rd parties like to handle the EOL and Obsoletes of packages/modules by other means, which makes this redundant. Also, as the release cycle of Fedora is so fast, I am not sure this is a necessary feature at all I spoke to people in the community and I got mixed information/opinions, so I want to open a discussion about this feature. So WDYT? Is this necessary for Fedora? If yes, how should we handle this? -- Martin Curlej Software Engineer, Product Owner Modularity Red Hat <https://www.redhat.com> mcurlej(a)redhat.com <https://red.ht/sig>

11 22

DevConf.CZ CfP open
by Ben Cotton 02 Nov '20

02 Nov '20

If you haven't seen the Community Blog post[1], the DevConf.CZ Call for Proposals is open. DevConf.CZ will be a virtual event this time and held in February. Like in years past, there is a dedicated Fedora track, as well as tracks for other technical areas. If you have something you are working on that you want to share, submit your proposal by 1 November. [1] https://communityblog.fedoraproject.org/devconf-cz-cfp-now-open/ -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 1

Orphaned packages
by Jan Synacek 02 Nov '20

02 Nov '20

7 9

← Newer
1
2
3
4
5
6
7
...
42
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel October 2020