devel February 2021

devel@lists.stg.fedoraproject.org

226 participants
377 discussions

Status update for the new AAA system
by Aurelien Bompard 05 Mar '21

05 Mar '21

Hey folks! As you've probably heard before, we're upgrading our authentication system to something that is based on FreeIPA. Here's a quick status report on that initiative. We're currently in an integration phase, figuring out the smaller details of configuration and infrastructure setup before we switch production. - The infra team wants to do a couple things that FreeIPA does not support out of the box, like enforcing 2FA for specific services such as sudo, so we need to think about how we want to do it. - Also, using kinit with 2FA tokens proved to be more complex than we'd like it to be. - We're trying out a more continuous approach to importing accounts, because a full run takes 3 days and during the migration we'll want to run the import script without having a 3 days downtime. - We also have to do some FreeIPA performance tuning, because we have something like 120k accounts and the default configuration is not appropriate for that amount of data, especially when we want to list all groups or worse, all users. To sum it up, we're currently working on integration and migration preparation. We need to fix these issues before we go to prod, but it's a bit difficult to say how long it's going to take (especially with perf tuning, fix one perf issue and there can be another one right behind). One sure thing is that it's better to have these issues now rather than after the switch to prod. Cheers! Aurélien

5 8

OCaml 4.12
by Jerry James 04 Mar '21

04 Mar '21

Richard, I see that the OCaml 4.12 release is not expected to happen until next week, after the beta freeze: https://discuss.ocaml.org/t/ocaml-4-12-0-first-release-candidate/7294 Some of my OCaml packages are currently not installable, due to the dynlink hiccup, I think. Rather than enter beta freeze with them in this state, I would like to rebuild them. I was thinking about proceeding with the updates needed for OCaml 4.12, since I have to build these packages anyway, and the updated versions also work with OCaml 4.11. As a reminder, these are the updates: - ocaml-base: 0.14.0 -> 0.14.1 - ocaml-migrate-parsetree: 1.8.0 -> 2.1.0 - ocaml-ppxlib: 0.15.0 -> 0.22.0 - ocaml-bisect-ppx: 2.5.0 -> 2.6.0 - ocaml-tyxml: apply this pull request to switch to ppxlib: https://github.com/ocsigen/tyxml/pull/271 - ocaml-lwt: 5.3.0 -> 5.4.0 - ocaml-ppx-deriving: 5.1 -> 5.2.1 - ocaml-ppx-optcomp: 0.14.0 -> 0.14.1 - ocaml-ppx-sexp-conv: 0.14.1 -> 0.14.2 - ocaml-sedlex: 2.2 -> 2.3 - ocaml-ppx-custom-printf: 0.14.0 -> 0.14.1 - ocaml-ppx-fields-conv: 0.14.1 -> 0.14.2 - Retire ocaml-ppx-tools-versioned along with a number of other package builds just to fix dependencies. That would also simplify things for you when OCaml 4.12 is released, as all of these updates would already be in place. What do you think? Also, I would like to update ocaml-ocamlgraph to version 2.0.0 at some point. The only Fedora consumers are frama-c and ocaml-dose3. The current version of frama-c can already be built with either ocamlgraph 1.x or 2.x. The version of ocaml-dose3 in Fedora (5.0.1) cannot be built with ocamlgraph 2.x. However, upstream has moved here: https://gitlab.com/irill/dose3 and released a 6.x series that supports ocamlgraph 2.x. Unfortunately, there are issues with moving to version 6.x. First, and easiest, the new versions depend on camlbz2 and parmap, neither of which are in Fedora. I've put together spec files for those two and can submit them for review if nobody else wants to do so. Second, upstream removed support for RPM in this commit: https://gitlab.com/irill/dose3/-/commit/e656b5783f1fc5fd75e0e2716b0a40aca28… I don't know why. The commit message does not give a reason, and this change is not mentioned in the project changelog. I assume RPM support is important for the Fedora build of ocaml-dose3. I don't know what the best approach is to resolve this issue, but it is blocking the ocamlgraph update. Any thoughts on the matter are appreciated. Regards, -- Jerry James http://www.jamezone.org/

6 27

Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
by Ben Cotton 04 Mar '21

04 Mar '21

https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main == Summary == This Change will move Fedora git repositories to use "main" as the default git branch instead of "master". Specific repositories will be manually moved and default git branch for new projects will be set to use "main". The Fedora Community strives to be open and welcoming. Some language around our git repositories is dated and could be more inclusive. Many git repositories currently use "master" as the default branch. This Change will move many repositories (see below) to use a "main" branch as default. This small bit of naming adjustment is in-line with Fedora's vision for free and open source software built by inclusive, welcoming, and open-minded communities. == Owner == * Name: [[User:Kevin| Kevin Fenzi]], [[User:bcotton| Ben Cotton]], [[User:pingou| pingou]], [[User:mohanboddu| Mohan Boddu]], [[User:till| Till Maas]] * Email: kevin(a)scrye.com, bcotton(a)redhat.com, pingou(a)pingoured.fr, mboddu(a)bhujji.com, opensource(a)till.name == Detailed Description == The Fedora Project controls a number of git repositories. This change will move the default branch (that is, the git branch used when nothing is specified) from 'master' to 'main'. Existing git clones will need to pull to get the changed default branch. Existing Pull Requests against the 'master' branch will need to be rebased against the 'main' branch. Documentation will be updated. == Benefit to Fedora == The Fedora Project will be a more welcoming place for new contributors. == Scope == This change will take place in a number of phases: === Phase0 - 2020-12-14 === A guide will be published to explain how maintainers/project managers can change the default branch on pagure.io, which they can then do based in their projects desires. === Phase1 - 2020-12-15 === The following repos will be switched: src.fedoraproject.org/flatpacks/* pagure.io: releng releng/* fedora-comps fedora-kickstarts fedora-infrastructure fedora-lorax-templates fedora-mediawikitheme fedora-packager fedora-infra/* infra-docs koji-fedmsg-plugin workstation-ostree-config pungi-fedora github.com fedora-infra/* === Phase2 - 2021-01-13 === src.fedoraproject.org/* pagure.io default for new projects will be changed to 'main' * Proposal owners: Switching all above listed projects git repos to use 'main' Deleting the 'master' branch Announcing when changes have been made on devel-announce / other lists. * Other developers: Other developers are encouraged to change their upstream projects on pagure.io, github or gitlab. * Release engineering: Releng will adjust any scripts that assume 'master' branch to use 'main' instead. The list includes and maybe few more [https://pagure.io/releng/blob/master/f/scripts/update-critpath.py update-critpath.py] [https://pagure.io/releng/blob/master/f/scripts/block_retired.py block_retired.py] [https://pagure.io/releng/blob/master/f/scripts/update-docs.sh update-docs.sh] [https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py find_unblocked_orphans.py] [https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-second-run.py mass-rebuild-second-run.py] [https://pagure.io/releng/blob/master/f/scripts/adjust-eol-modules.py adjust-eol-modules.py] [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py adjust-eol-modules.py] [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py adjust-eol-modules.py] [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol.py adjust-eol.py] [https://pagure.io/releng/blob/master/f/scripts/pdc/create-new-release-branc… create-new-release-branches.py] [https://pagure.io/releng/blob/master/f/scripts/pdc/create-branch.py create-branch.py] [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-all.py adjust-eol-all.py] [https://pagure.io/releng/blob/master/f/scripts/check-unretirement.py check-unretirement.py] [https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-special.py mass-rebuild-special.py] [https://pagure.io/releng/blob/master/f/scripts/need-rebuild.py need-rebuild.py] [https://pagure.io/releng/blob/master/f/scripts/distgit-branch-unused.py distgit-branch-unused.py] [https://pagure.io/releng/blob/master/f/scripts/create-new-release-branches.… create-new-release-branches.py] * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Objectives: == Upgrade/compatibility impact == Users with old checkouts will need to update their git configuration or re-clone repositories that have changed before they can see any new changes. Repos used to build content for docs.fedoraproject.org can change the default git branch, but the Antora module version (in `antora.yml`) should remain `master` pending support for alternate "unversioned" versions upstream. == How To Test == # git clone <one of the listed repositories> # cd <repositoryname> # git branch should return: `* main` == User Experience == Users and developers will see more welcoming language and that the fedora project expended effort to be more welcoming to them. == Dependencies == none == Contingency Plan == * Contingency mechanism: Revert repositories, scripts, and docs back to the unwelcoming 'master' * Contingency date: 2020-01-13 == Documentation == A short guide on how to change this for pagure.io will be produced. == Release Notes == Many git repositories used to create Fedora releases were moved to use a 'main' branch instead of a 'master' branch. The Fedora Project envisions a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

37 97

Building custom kernels
by Julian Sikorski 03 Mar '21

03 Mar '21

Hi, I am trying to test some Renoir s2idle patches [1]. It appears that Fedora kernel source is now maintained on gitlab as kernel-ark [2]. What I tried is adding the patches to the fedora-5.11 branch and running make dist-srpm, but it failed due to config mismatch on CONFIG_INIT_STACK_NONE: Processing /home/julas/cvs/fedora/kernel-ark/redhat/configs/kernel-aarch64-fedora.config ... Error: Mismatches found in configuration files Found CONFIG_INIT_STACK_NONE=y after generation, had CONFIG_INIT_STACK_NONE=is not set in Source tree make[1]: *** [Makefile:145: dist-configs-check] Błąd 1 Is this expected? Is there a better way of testing patches on Fedora kernels? Thanks for the help in advance. Best regards, Julian [1] https://gitlab.freedesktop.org/drm/amd/-/issues/1230 [2] https://gitlab.com/cki-project/kernel-ark

5 14

Fedora 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)
by Ben Cotton 03 Mar '21

03 Mar '21

https://fedoraproject.org/wiki/Changes/rpmautospec == Summary == The goal of this change is to deploy in production the [https://docs.pagure.org/fedora-infra.rpmautospec/ rpmautospec] project. With it, the content of the `Release` and `%changelog` fields in spec files can be auto-generated, either locally or in the builder using the information present in the git repo (in the form of git tags). Note: This proposal is about changing the way the `Release` and `%changelog` sections of the '''spec files''' are filled, not about removing them from the SRPM or binary RPM. == Owner == * Name: [[User:pingou| Pierre-Yves Chibon]] * Email: pingou - at - pingoured.fr * Name: [[User:nphilipp| Nils Philippsen]] * Email: nphilipp - at - redhat.com == Detailed Description == rpmautospec offers packagers who want to use it the possibility of replacing the content of the `Release` of their spec file by `Release: %autorel` and/or replace the content of the `%changelog` section of their spec file by: %changelog %autochangelog Both `%autorel` and `%autochangelog` are RPM macros that will be expanded or replaced when the SRPM is built on the build system by their corresponding values according to rpmautospec. An overview of how rpmautospec works can be found at: https://docs.pagure.org/fedora-infra.rpmautospec/principle.html. We will describe below how each macro works. === The %autorel macro === To determine the next release information, rpmautospec relies on the build history of the package. This information is extracted from the buildsystem when running as a koji plugin and from git tags when running outside of the buildsystem. Using the build history of the package (ie a list of NEVRs) as well as the information provided by the packager in the spec file, rpmautospec then computes the next best release number for the package. Once defined, it prepends a suitably defined %autorel macro to the top of the spec file, freezing the computed value of the release number and thus allowing reproducible builds of the SRPM. The [https://docs.pagure.org/fedora-infra.rpmautospec/autorel.html documentation of the autorel macro] describes how packagers can use it to provide extra information. === The %autochangelog macro === The %autochangelog macro is in fact more a placeholder that rpmautospec fills in during the creation of the SRPM (or when ran manually on a project). rpmautospec uses two sources of information to automatically generate the changelog: * an optional `changelog` file that packagers can add to the repository * the git history of the spec file rpmautospec will include the `changelog` as is in the `%changelog` section and will use all the commits made to the repository after the last change of the `changelog` file to generate the changelog. In other words, if the packager has a repository created on January 10th and works on it for 6 months, adds a `changelog` file on June 1st. All the commits made before that commit of June 1st will be ignored in favor of the content of the `changelog` file. Similarly, if the packager then edits the file on July 1st, all the commits prior to that commit of July 1st will be ignored. All the commits involving files ending with either ".spec" or ".patch" (this list can be expended if desired) and made after July 1st will be used to generate the changelog. == Benefit to Fedora == In short: easier packaging in Fedora for the packagers who opt-in. The `Release` and `%changelog` fields are the two most conflicting fields in RPM spec files. They impact most pull requests if they involve updating the package or if the package is updated/rebuilt while pull-request are being reviewed. We currently have three different change logs per package and while they target different audiences (package maintainer: git, sysadmin: %changelog and end-user: bodhi notes) they overlap a lot and in most cases are redundant. With this proposal, package maintainers will only have to cope with two changelogs: git and bodhi notes. == Scope == * Proposal owners: ** Finish the work on the %autorel macro to support some of the use cases not implemented currently ** Adjust the packaging so rpmautospec does not live in a specific, versionized python environment (and thus could be use to bootstrap python) ** Adjust rpmdev-bumpspec (used by releng for mass-rebuilds) so it ignores spec files using %autorel/%autochangelog ** Adjust the mass-rebuild script so it only adds a suitable git commit log message for spec files using %autorel/%autochangelog ** Adjust fedpkg to skip the NEVR check when using rpmautospec ** Add dependency on rpmautospec on redhat-rpm-config * Other developers: ** Opt-in for those who want to use it ** Test changes in staging ** Provide feedback * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: Packaging guidelines should be adjust to explain how rpmautospec works and can be used. Documentation at: https://docs.pagure.org/fedora-infra.rpmautospec/ should provide a good basis for this * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == Not applicable == How To Test == In staging: * Use `stg-koji` instead of `koji` * Use `fedpkg-stage` instead of `fedpkg` (``dnf install fedpkg-stage``) * Run `kinit <accountname>@STG.FEDORAPROJECT.ORG` * Test with rawhide as rpmautospec is only available there in staging at this point * Install `rpmautospec-rpm-macros` to build packages locally. * Edit the spec file to use either macro (or both) * (Optional) Run `rpmautospec` on the git repository of your choice to see what it does (you may have to run `rpmautospec tag-package` the first time you run it). * Build the package * Check its release or changelog according to the macro set In production: * Edit the spec file to use either macro (or both) * (Optional) Run `rpmautospec` on the git repository of your choice to see what it does (you may have to run `rpmautospec tag-package` the first time you run it). * Build the package * Check its release or changelog according to the macro set Issues can be reported at: https://pagure.io/fedora-infra/rpmautospec/issues Note that using this approach has some peculiarities, we've documented the ones we've encountered at: https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html == User Experience == Packagers not opting-in should not be affected in any way by this change. Packagers opting-in should be able to stop worrying (or worry much less) about the content of the Release/%changelog fields in their spec file. == Dependencies == None == Contingency Plan == * Contingency mechanism: rpmautospec is not deployed in koji * Contingency deadline: N/A (this isn't tied to a Fedora release) * Blocks release? No == Documentation == All the upstream documentations can be https://docs.pagure.org/fedora-infra.rpmautospec/ == Release Notes == N/A, this change will not affect end-users (except maybe for some changes in the content of the rpm changelog). -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

11 23

How to build RISC-V Fedora disk image by muself
by Jinyan 02 Mar '21

02 Mar '21

I tried to boot fedora in qemu according to the steps given in [1]. During this process, I used the disk image named `Fedora-Developer- Rawhide-*.raw.xz`. I am curious about what is inside and how to compile and generate it. Where can I get the steps to generate it ? Thank you [1] https://fedoraproject.org/wiki/Architectures/RISC-V/Installing

7 8

systemd-resolved fallback DNS servers: usability vs. GDPR
by Tadej Janež 02 Mar '21

02 Mar '21

Hi, I would like to question the decision that was made by systemd maintainers to remove the fallback DNS server list: https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c3f… And then backported to F33: https://src.fedoraproject.org/rpms/systemd/c/ed795fb1fc9a2c20ebcac34bdf7e7c… On F33, this actually breaks a working vanilla cloud instance by removing the fallback DNS server list in a systemd upgrade, effectively leaving the system with no DNS servers configured. I described this in more detail here: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org… Zbigniew Jędrzejewski-Szmek wrote the following in the commit message accompanying the fallback DNS server list removal: > So hopefully users will not see any effect from the change done in > this patch. Right now I think it is better to avoid the legal and > privacy risk. If it turns out this change causes noticable problems, > we might want to reconsider. In particular we could use the fallback > servers only in containers and such which are not "personal" machines > and there is no particular person attached to them. I would argue that the change causes noticeable problems and we want to reconsider this change. In particular, I think cloud image users would prefer to have their cloud instances usable out of the box, i.e. have DNS working out-of-the box. Don't get me wrong, I understand the privacy concerns and I think Fedora should strive to protect the privacy of its users as much as possible, but at the same time, the circumstances of a cloud instance are probably very different from a e.g. workstation instance. Possible solutions that come to mind: 1) Use different defaults for different Fedora editions, e.g. container and cloud images include the fallback DNS servers list while workstation (and similar) images don't. 2) Pick a reputable DNS resolver that preserves users' privacy and doesn't log anything and configure it as a fallback DNS server. Here is a good summary of DNS resolvers and their privacy: https://privacytools.io/providers/dns/#dns Thoughts? Regards, Tadej P.S. I'm subscribed, but please keep me in Cc so I'll notice replies sooner.

16 55

sssd: No %post/%preun/%postun?!?
by Richard Shaw 02 Mar '21

02 Mar '21

Per the packaging guidelines these don't seem to be optional: https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_syst… Additionally, at a minimum systemctl daemon-reload should be run. It looks like there is some sort of default behavior but it's not correct. Warning: The unit file, source configuration file or drop-ins of sssd-kcm.socket changed on disk. Run 'systemctl daemon-reload' to reload units. Warning: The unit file, source configuration file or drop-ins of sssd-kcm.service changed on disk. Run 'systemctl daemon-reload' to reload units. Even the base sssd service seems to be missing daemon-reload: Warning: The unit file, source configuration file or drop-ins of sssd.service changed on disk. Run 'systemctl daemon-reload' to reload units. For the other services provided the default behavior seems to be of the try-restart variety but all (most?) of these are indirectly started by socket activation so should be using %systemd_postun and not %systemd_postun_with_restart: Failed to try-restart sssd-autofs.service: Operation refused, unit sssd-autofs.service may be requested by dependency only (it is configured to refuse manual start/stop). See system logs and 'systemctl status sssd-autofs.service' for details. Failed to try-restart sssd-nss.service: Operation refused, unit sssd-nss.service may be requested by dependency only (it is configured to refuse manual start/stop). See system logs and 'systemctl status sssd-nss.service' for details. Failed to try-restart sssd-pac.service: Operation refused, unit sssd-pac.service may be requested by dependency only (it is configured to refuse manual start/stop). See system logs and 'systemctl status sssd-pac.service' for details. Failed to try-restart sssd-pam.service: Operation refused, unit sssd-pam.service may be requested by dependency only (it is configured to refuse manual start/stop). See system logs and 'systemctl status sssd-pam.service' for details. Failed to try-restart sssd-ssh.service: Operation refused, unit sssd-ssh.service may be requested by dependency only (it is configured to refuse manual start/stop). See system logs and 'systemctl status sssd-ssh.service' for details. Failed to try-restart sssd-sudo.service: Operation refused, unit sssd-sudo.service may be requested by dependency only (it is configured to refuse manual start/stop). See system logs and 'systemctl status sssd-sudo.service' for details. Looking at my dnf rpm log, this seems to have been going on for quite some time and I can't believe I'm the first to notice... Thanks, Richard

3 4

split-DNS, resolvconf on Fedora
by Petr Menšík 01 Mar '21

01 Mar '21

Hi, I have submitted new package openresolv [1], which provides resolvconf tool, similar to Debian's resolvconf package. Why? I thought about common interface to various DNS cache implementations for workstations and different VPN providers available. While I think the best place to direct, which interface resolvers should handle given domains. resolvconf handles conflicting requests from different interfaces, when multiple DNS resolver providers are configured by connection. Current Fedora 33 already has /usr/sbin/resolvconf provided by systemd-resolved. It provides split-DNS implementation in default Fedora installation[2]. Problem is this is useful only in case systemd-resolved service is running and used. When it is disabled, its resolvconf just fails. But because systemd-resolved does not have its own subpackage, the daemon can be only disabled, not uninstalled. My question is, how should dhclient or vpn provider check resolvconf is installed and enabled? It usually checks [ -x /usr/sbin/resolvconf ] in Debian from shell, but because resolvconf is always present on Fedora, it cannot work. Unlike Debian, where systemd does not provide resolvconf. How could it therefore check, how should be /etc/resolv.conf updated? How would dhclient know, when to rewrite /etc/resolv.conf itself or when to use resolvconf for coordinated changes? I think Network Manager should manage DNS domains list per connection IMO. But in cases VPN provider is not configured via NM or NM is not even used, I think resolvconf is good alternative to set and restore the system's /etc/resolv.conf, when any VPN service is started. Only systemd-resolved and dnsmasq can support split-DNS from NM. openresolv is written only in shell, has no other dependencies. It could support multiple DNS implementations as a local cache[3]. It currently breaks systemd's symlink /usr/sbin/resolvconf, it uses alternatives links. But systemd package does not use it, so after uninstallation of openresolv, resolvconf remains broken. I think this has to be solved by systemd package. Do you have any opinion, how should resolvconf be supported on Fedora? Any opinion against it? 1. https://src.fedoraproject.org/rpms/openresolv 2. https://fedoraproject.org/wiki/Changes/systemd-resolved#Split_DNS 3. https://roy.marples.name/projects/openresolv/configuration/ -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik(a)redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

9 19

Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git
by Miro Hrončok 01 Mar '21

01 Mar '21

Hello, When we work on rebuilding Python packages with new Python version and when other provenpackagers rebuild multiple packages at once, I've seen several problems with packages failing to build from source and/or creating unexpected breakage in rawhide when built. Usually, some of the following happens: 1. Untested changes Packager pushes a "simple update" to dist git without checking if it even builds. It doesn't. Packager has no time to fix this, so they move on for now. Or they submit a build but never check if it actually built. Provenpackagers who need to rebuild the package need to figure this out and fix the problem if it is trivial, or revert the recent commit, when the failure blocks them. IMHO Provenpackagers should not need to worry about this. Changes should be at least smoke tested by a mock/scratch build and installation check before shipping them. 2. Changes that work but are waiting on external factors Packager pushes a breaking change to dist git (such as a soname bump) before coordinating the change with the dependent packages, not intending to immediately build it. A provenpackager rebuilds the package for a different reason (such as a different soname bump), accidentally shipping the not-yet-wanted upgrade to rawhide. IMHO Provenpackagers should not need to worry about this. Commits should land in dist git only when they are intended to be built (close to) immediately. The only reasonable exception is when building the pushed changes in a side tag and even then, packagers should communicate their intentions. 3. Work-in-progress changes Packager works on a package. They have a work in progress solution to their problem, but no time to finish. They push a "WIP" commit that either breaks the build or produces a broken package. The symptoms are similar to (1) or (2). I've heard packagers saying "but this is rawhide, this is where development happens, so this is expected" - I disagree. --- I'd like to explicitly say that neither of this is considered a good behavior. I'd like to have a policy that more or less says: 1. Packagers MUST NOT push changes that are not considered ready to be built and shipped at the time of the push. Using Pull Requests (clearly marked as not ready to be merged) is a better place to present/save changes that are not ready yet. 2. Packagers SHOULD preemptively check if the changes they intend to push work. At least checking if the intended change builds and the package installs with it is strongly recommended. In cases where the check is skipped for time reasons (e.g. when a testing build takes several hours and the changes are urgent), packagers SHOULD be ready to fix the build/installation failure in timely manner after it is discovered by the actual build. Before I try to word it more carefully I'd like to hear some feedback on this. What do you think? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

23 69

← Newer
1
2
3
4
5
6
7
...
38
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 February 2021