devel October 2020

devel@lists.stg.fedoraproject.org

226 participants
409 discussions

Release rpkg-1.61 and fedpkg-1.39
by Ondrej Nosek 15 Dec '20

15 Dec '20

Hi all, a new version rpkg-1.61 together with fedpkg-1.39 are released containing both features and bugfixes. Some bugfixes were released earlier as patches. Currently, Fedora 32, epel7, epel8 and rawhide packages are in the testing repository, feel free to try these waiting distributions in Bodhi. I will update Fedora 33 and Fedora 31 packages later today because previous updates are going to stable very soon and I do not want to obsolete them now. Version for epel6 won't be released. Changelog (web documentation): https://docs.pagure.org/rpkg/releases/1.61.html https://docs.pagure.org/fedpkg/releases/1.39.html Updates: https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.61-1.el8&builds=rpkg… Alternative link: https://bodhi.fedoraproject.org/updates/?packages=rpkg&page=1 rpkg is also available from PyPI. Thanks to all contributors. Regards

1 1

%lua_requires behaves differently in F33+
by Michel Alexandre Salim 08 Dec '20

08 Dec '20

Hi, Björn added some useful Lua packaging macros in https://bugzilla.redhat.com/show_bug.cgi?id=1447324 One of them, %lua_requires, adds a dependency on either `lua(abi) = %{lua_version}` or, on EL6 and below, on lua >= current version and lua < next version. Somehow this seems to be automatically applied on Fedora 33 and above -- without adding any manual require on lua(abi) e.g. lua-lunitx on Fedora 33 https://bodhi.fedoraproject.org/updates/FEDORA-2020-7c23dc64c0 on Fedora 32, though, the macro is not automatically invoked (so the update below is bad and I need to redo it) https://bodhi.fedoraproject.org/updates/FEDORA-2020-9074133de4 In fact, trying to use %lua_requires does not seem to work, with and without curly braces: error: line 15: Unknown tag: %lua_requires error: line 15: Unknown tag: %{lua_requires} Could someone help explain these two behaviors? I'm working on resuming the Lua packaging draft so I want to have a canonical example on how the macros are supposed to be used. PS Björn -- we should consider moving the macros out of lua-devel and into lua-rpm-macros, that lua-devel then depends on. That will fix the inability to get these macros out to EPEL6 and EPEL7 - on those, lua packages can just BR the macro package directly. -- Michel Alexandre Salim profile: https://keyoxide.org/michel@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2

3 10

Disabling Fedora 30 chroots in Copr
by Jakub Kadlcik 23 Nov '20

23 Nov '20

Hello, we have just disabled Fedora 30 chroots in Copr. According to the Fedora wiki [1], Fedora 30 reached the end of its life on 2020-05-26 and therefore we are disabling it in Copr. That effectively means that from this moment, it is no longer possible to submit builds for the following chroots: - fedora-30-x86_64 - fedora-30-i386 - fedora-30-ppc64le - fedora-30-aarch64 - fedora-30-armhfp [1] https://fedoraproject.org/wiki/End_of_life Jakub

4 12

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 05 Nov '20

05 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

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