devel January 2021

devel@lists.fedoraproject.org

216 participants
347 discussions

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

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

Needing Some Maintenance Help
by Erich Eickmeyer 20 Feb '21

20 Feb '21

Hi All, Over the course of the past few months, I have become employed by a company to provide their user software experience. This has limited the time that I have, and, unfortunately, my involvement in Fedora has, and needs to, decrease. I currently maintain the Fedora Jam lab, and would like some help with that. Just last night, while I was trying to relax after my day, I was CC'd on two bug reports only because I'm Jam's maintainer, when really the responsibility for the issues in question (pipewire related in Rawhide) lie on the change owner(s) for the Pipewire-By-Default change. I fixed a couple of packages only as a courtesy that were related to the issue (unable to install the @audio group), but that responsibility lies with the change owner(s), of which I'm not a part due to time restrictions. I removed myself from the bug report after that and had explained that they needed to add the change owner(s). This same person that CC'd me on that decided to then file a bug report against Jam 34 which is currently FTBFS due to the aforementioned issue with the @audio group. Since we (spin/lab maintainers) get automated emails about these things, I told them not to file bug reports against spins/labs in the future and closed it as errata. I realize this person was only trying to help, but it caused me some undo stress. This made me realize that I need to take a step back. Not only have I gained employment with a company that is using Ubuntu as their base (specifically Kubuntu with Ubuntu Studio partnership), but I've also become a MOTU with Ubuntu ("Master Of The Universe [repository]", much like a proven packager here). As such, Fedora isn't exactly integral to what I do, but I'd like to keep my rpm packaging skills somewhat sharpened, which is why I'll be keeping certain packages that I have direct involvement upstream with (e.g. studio-controls). So, here's what I'm looking for: * Someone to help me maintain Jam * Including fedora-jam-backgrounds and fedora-jam-kde-theme packages * Co-maintainers and/or new maintainers for the following packages: * Add64 * dssi * dssi-vst * fluidsynth * fluidsynth-dssi * freqtweak * giada * gnome-guitar * harmonyseq * hexter-dssi * jackctlmmc * jmeters * libinstpatch * lv2-c++-tools * lv2-fabla * lv2-ll-plugins * lv2-mdaEPiano * lv2-newtonator * lv2-sorcer * lv2-swh-plugins * lv2-vocoder-plugins * meterbridge * python-alsaaudio * python-jack-client * radium-compressor * realTimeConfigQuickScan * soundtracker * whysynth-dssi * xsynth-dssi Simply let me know which package you'd like and if you'd like to maintain or co-maintain along with your fas username. Thanks in advance, Erich -- Erich Eickmeyer Maintainer Fedora Jam

4 3

[ELN] Is it really necessary to build a package 100+ times when there is a bootstrap issue?
by Miro Hrončok 20 Feb '21

20 Feb '21

This topic was brought up several times already, but I don't think there has been a satisfactory answer to it yet. So let's try again. We have recently updated python-elementpath-2.1.1-2.fc34 and python-xmlschema-1.4.1-1.fc34 -- it requires a very simple bootstrapping that can be seen in the git history. https://bodhi.fedoraproject.org/updates/FEDORA-2021-eb7554bd39 I know that the ELN rebuild tooling cannot handle bootstrapping and I know it has been told this will eventually be solved. I appreciate that it is planned. But in the meantime, is it really necessary to build the packages 100/111 times? https://src.fedoraproject.org/rpms/python-elementpath/c/5de3aa397bda5550047… https://src.fedoraproject.org/rpms/python-xmlschema/c/0c1384c7aaed1d6404bdf… Could you please not do that? I realize that sometimes dependency issues are transient. I sometimes beat packages with a stick until they build as well, but more than 100 builds in less than two weeks feels a little far fetched. Please, make the automation stop and inspect the problem by a human after a reasonable amount of trials (I'd say 3, possibly 12, but not 100+). Alternatively at least slow down the firing rate with time. After two weeks of failures it might make sense to give it a try every other day, but not every other hour. Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 2

Change in glibc about _STAT_VER in Fedora rawhide?
by Jan Pazdziora 18 Feb '21

18 Feb '21

Hello, it seems that both fakeroot and fakechroot fail to build in Fedora rawhide (at least partially) because _STAT_VER is no longer declared in the current glibc (or rather, its headers): https://bugzilla.redhat.com/show_bug.cgi?id=1889862 https://bugzilla.redhat.com/show_bug.cgi?id=1901049 The bugzillas are filed against their respective components but I wonder if we have any guidance from the glibc point of view about how these components should proceed. Or is the loss of _STAT_VER an omission and will it come back? -- Jan Pazdziora Product Owner, Platform Security Readiness, Red Hat

3 5

Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
by Ben Cotton 16 Feb '21

16 Feb '21

https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression == Summary == On variants using btrfs as the default filesystem, enable transparent compression using zstd. Compression saves space and can significantly increase the lifespan of flash-based media by reducing write amplification. It can also increase read and write performance. == Owners == * Name: [[User:salimma|Michel Salim]], [[User:dcavalca|Davide Cavalca]], [[User:josef|Josef Bacik]] * Email: michel(a)michel-slm.name, dcavalca(a)fb.com, josef(a)toxicpanda.com == Detailed description == Transparent compression is a btrfs feature that allows a btrfs filesystem to apply compression on a per-file basis. Of the three supported algorithms, zstd is the one with the best compression speed and ratio. Enabling compression saves space, but it also reduces write amplification, which is important for SSDs. Depending on the workload and the hardware, compression can also result in an increase in read and write performance. See https://pagure.io/fedora-btrfs/project/issue/5 for details. This was originally scoped as an optimization for https://fedoraproject.org/wiki/Changes/BtrfsByDefault during Fedora 33. == Benefit to Fedora == Better disk space usage, reduction of write amplification, which in turn helps increase lifespan and performance on SSDs and other flash-based media. It can also increase read and write performance. == Scope == * Proposal owners: ** Update anaconda to perform the installation using <code>mount -o compress=zstd:1</code> ** Set the proper option in fstab (alternatively: set the XATTR) ** Update disk image build tools to enable compression: *** lorax *** appliance-tools *** osbuild *** imagefactory ** [optional] Add support for [https://github.com/kdave/btrfs-progs/issues/328 setting compression level when defragmenting] ** [optional] Add support for [https://github.com/kdave/btrfs-progs/issues/329 setting compression level using `btrfs property`] * Other developers: ** anaconda: review PRs as needed * Release engineering: https://pagure.io/releng/issue/9920 * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == This Change only applies to newly installed systems. Existing systems on upgrade will be unaffected, but can be converted manually with <code>btrfs filesystem defrag -czstd -r</code>, updating `/etc/fstab` and remounting. == How to test == Existing systems can be converted to use compression manually with <code>btrfs filesystem defrag -czstd -r</code>, updating `/etc/fstab` and remounting. == User experience == Compression will result in file sizes (e.g. as reported by du) not matching the actual space occupied on disk. The [https://src.fedoraproject.org/rpms/compsize compsize] utility can be used to examine the compression type, effective compression ration and actual size. == Dependencies == Anaconda will need to be updated to perform the installation using <code>mount -o compress=zstd:1</code> == Contingency plan == * Contingency mechanism: will not include PR patches if not merged upstream and will not enable * Contingency deadline: Final freeze * Blocks release? No * Blocks product? No == Documentation == https://btrfs.wiki.kernel.org/index.php/Compression == Release Notes == Transparent compression of the filesystem using zstd is now enabled by default. Use the compsize utility to find out the actual size on disk of a given file. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

9 17

Copr in 2020 and outlook for 2021
by Miroslav Suchý 15 Feb '21

15 Feb '21

Let me sum up what we - the Copr team - did in 2020: * We enabled CDN for repos. https://fedora-copr.github.io/posts/copr-cdn * We enabled runtime dependecies on repositories https://fedora-copr.github.io/posts/runtime-dependencies * We migrated all our servers from PHX datacenter to AWS. With zero downtime for your repos. * Pavel Raiskup became the new Mock project leader, and he released seven new versions of Mock during 2020. https://github.com/rpm-software-management/mock/wiki * Our small team has been renamed to Community Packaging Team (CPT) because beside Copr, we maintain other tools as well: Mock, dist-git, Tito... * We drove changes in createrepo_c, which allowed us better throughput. Now, Copr can build thousands of builds per day. * We worked on Fedora packages website, which was outdated and do not work on recent Fedora. Unfortunately, it will not be likely used, and static pages will be used as it will require less maintenance. * We introduced Project scoring for projects in Copr (up/down vote) http://frostyx.cz/posts/upvoting-projects-in-copr * We allowed you to delete multiple builds at once. https://fedora-copr.github.io/posts/deleting-list-of-builds * You can use Github Actions now https://pavel.raiskup.cz/blog/github-push-actions-and-copr.html * We created modulemd-tools for low-level handling of repositories and modules. And tool for generating module-build-macros. https://github.com/rpm-software-management/modulemd-tools * We worked hard on better EOL handling of Copr repositories. * We parallelized copr-dist-git imports. * We wrote code for Ansible DNF Copr module. This still needs to land in a proper place like Ansible Galaxy. https://pagure.io/copr/copr/blob/master/f/ansible * We provided --isolation=* and --bootstrap=* knob in Copr * We started an experimental "external dependencies" feature in Mock. https://github.com/rpm-software-management/mock/wiki/Feature-external-deps * We created a new python module "templated-dictionary" as a spin-off from Mock's code. https://github.com/xsuchy/templated-dictionary * We wrote four articles "4 cool new projects to try in COPR" https://fedoramagazine.org/tag/copr/ * Users now have the ability to change the build timeout up to a maximum of 48 hours * Users can group builds in batches now. https://pavel.raiskup.cz/blog/build-ordering-by-batches-in-copr.html We already have plans to do: * Verify GPG checks in DNF using DNSSEC. https://pagure.io/copr/copr/issue/406 * Improve hooks (in cooperation with Packit team) * We are going to EOL APIv1 and APIv2 https://fedora-copr.github.io/posts/EOL-APIv1-APIv2 What will we do in 2021? We have some ideas. Some of them are yours, some of them are ours. At the end of this email is a link to Google Form where you can vote what you would like to get. We will consider your vote. (listed in no specific order) * When you create a project, you may specify that it will be for Package Review. We do some settings for you, and `rpminspect` will be run automatically at the end of the build. We can guide users on how to file Package Review BZ. Or do that automatically on their behalf. * Contribute to fedpkg/Koji that tagged commits will be automatically built in Koji and may be automatically sent to Bodhi. * Help with automatic changelog entries. * Native support for Fedora in Travis. * Continue on external dependencies. https://github.com/rpm-software-management/mock/wiki/Feature-external-deps * Finish rpm-spec-wizard https://github.com/xsuchy/rpm-spec-wizard * Better integration with Koshei. * Automatic rebuilds in Copr when dependency change (likely with the help of Koshei) * Enhance release-monitoring and rebase-helper to automatically open PR in Pagure when new version is available. * Enhance `Mock --chain` to try to set %bootstrap when standard loop fails. When the set succeeds, rebuild the bootstrapped package again without %bootstrap macro. https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping * Improve the process of finding a sponsor for the first package. * Contribute to fedpkg/koji to have machine-readable output. Please vote here: https://forms.gle/UuH86ECzfZNHJgEr8 The results are intentionally publicly available. You may check them anytime. CPT team consist of Pavel Raiskup, Silvie Chlupova, Jakub Kadlcik and this year we also had in the team Dominik Turecek and Tomas Hrnciar. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

5 9

Attempting to allow for a source of truth for Fedora release cycle information: releasestream
by Adam Williamson 11 Feb '21

11 Feb '21

Hi folks! Before the RH holiday shutdown, I started a new project designed to address a long-standing pain point in Fedora: we don't really have a good source of truth for release cycle information. I'm thinking of situations where something: * Needs to know what the "current stable" Fedora release(s) are * Needs to know if Fedora X is Branched * Needs to know whether Fedora X Beta happened yet * Needs to know whether Fedora X is frozen ...etc etc etc. Some of this information is available...sort of...from various different systems, with various awkward caveats that I won't dive into unless someone asks. But there isn't really a single source of truth for it, and some of it just isn't really available in any easily machine-consumable way. So I wrote releasestream: https://pagure.io/fedora-qa/releasestream releasestream is intended to be a system that will let us do this. It is a very very simple webapp with three capabilities: * It can read a simple record ("stream") of "release events" for a "release" and produce several static JSON representations of the information * It can write an entry to one of these streams in response to a properly-formatted POST request * It can publish a message when a new entry is received that is all it does. The "releases" and "events" are entirely arbitrary; a "release" can be any string, and so can the "state" for a given "event". An "event" is defined as a state being either reached or left; any number of events for the same state can be present for a release. The JSON outputs are basically "states by release" and "releases by state", as you might want either depending on what you're doing. You can conveniently look up "what releases are currently in state X?" or "what states is release X currently in?". This all works right now; the main thing that isn't implemented yet is any form of authentication. Right now if you can talk to the server you can submit events. I wanted to check if there is interest in moving forward with this, and discuss various options, before working on that. There is a ticket where I sketched out various possible approaches: https://pagure.io/fedora-qa/releasestream/issue/2 My idea for using this is basically that we deploy an 'official' releasestream instance in infra, and then find things that do the actual work of moving Fedora releases into and out of given "states" and tack on a bit at the end to tell releasestream about it. So when e.g. Mohan is putting Fedora 34 into the Beta freeze, we would add a "submit 'enter freeze' event to releasestream" to that process somehow - ideally something that has to be run as part of the process anyway would send the POST, but in a pinch a human could do it too. When Fedora 34 is being 'released', we tweak that process to include sending a releasestream event POST. And so on. The thing I like about this design is that there's a low barrier to entry, and can easily be adopted piecemeal but still be immediately useful for some things - as long as the event your code needs to watch for has been "onboarded", you're good. It also allows for the implementation details of a state change to change radically - it can go from being done by a human to being done by system X to being done by system Y, and all that needs to happen is to ensure the same dead simple POST request is sent to the same server. So, what do folks think? Does this seem like a good idea? Should I go ahead with trying to get it deployed and onboard things to it? Any comments, ideas, potential problems? Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

6 10

Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)
by Ben Cotton 11 Feb '21

11 Feb '21

https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot == Summary == This change will remove make from the default buildroot in Koji and mock. == Owner == * Name: [[User:tstellar| Tom Stellard]] * Email: <tstellar(a)redhat.com> == Detailed Description == ===== Phase 1: Analysis ===== For this change, we will start by creating a list of all packages that have a build-time dependency on make. This will be done by analyzing spec files and also by rebuilding all packages in Fedora with make removed from the buildroot to see which packages fail to build. Once we have this list, we will remove packages that already have BuildRequires:make in their spec file, and this final list[1] will be all the packages that need to be updated in Phase 2. [1] https://github.com/tstellar/fedora-change-make-buildroot/blob/main/needs_br… ===== Phase 2: Package Updates ===== Once we have the list of packages that need to be updated, we will proceed with adding BuildRequires: make to all spec files that require it. This new BuildRequires will be added to the line after the last BuildRequires in the spec file. The release number for packages will '''*not*''' be incremented for this change. The spec file updates will be automated and changes will be pushed directly to dist-git once they are ready. ===== Phase 3: Update Buildroot ===== Once package spec files have been updated, then we can proceed with removing make from the BuildRoot. This will be done by removing make from the build group in Koji and by removing make from the buildsys-build group in comps (fedora-comps). In order to avoid issues with Koschei, this change will need to be made as close as possible to the start of the mass rebuild. If possible, we will try to first remove make from the mass rebuild side-tag and then remove it from rawhide after the rebuild completes. ===== Phase 4: Monitor Failures ===== Once all the changes are in place, we will continue to monitor koji builds to see if there are any failures related to this change. We expect that the analysis done in Phase 1 would give us the complete list of packages that need to be updated, but it is always possible that something will be missed. == Feedback == * Removing make from the Buildroot without rebuilding the packages first has the potential to cause mass failures in Koschei. This is because Koschei builds from the latest SRPM and not from dist-git. We can minimize this problem by removing make from the buildroot as close as possible to the mass rebuild. The proposal has been updated now to account for this issue. == Benefit to Fedora == Based on my research[1], Fedora Rawhide has 22,309 packages, and there are approximately 10,378 packages that either use make explicitly or fail to build when make is removed form the buildroot. This means that there are around 11,931 packages that don't need make. Removing make from the BuildRoot will reduce the network traffic, download times, and disk usage for these builds in Koji and also for users doing builds with mock. Removing make (and its dependencies) will: * Reduce the BuildRoot download size by: 7.3 MB [2]: ** make: 539k ** gc: 104k ** guile22: 6.6M ** libtool-ltdl: 36k * Reduce the BuildRoot install size by; 46 MB [2]: ** make: 1.6M ** gc: 229k ** guile22: 44M ** libtool-ltdl: 71k [1] https://github.com/tstellar/fedora-change-make-buildroot [2] Package sizes are from the x86_64 packages. == Scope == * '''Proposal owners:''' Tom Stellard * '''Package Maintainers:''' Fedora package maintainers should report bugs if they think there is a problem caused by this change, but otherwise there will be no action required by them. * '''Proven Packager:''' The proposal owner will need to either apply for provenpackager status or get the help of someone with provenpackager status in order to make the spec file changes that are required. * '''Release engineering:''' [https://pagure.io/releng/issue/9829 #9829] (a check of an impact with Release Engineering is needed) * '''Policies and guidelines:''' The packager guidelines will need to be updated to mention that BuildRequires: make is now required for all packages that need make. * '''Trademark approval:''' N/A (not needed for this Change) * '''Alignment with Objectives:''' This aligns with the Fedora Minimization [https://pagure.io/minimization/issue/12 objective]. == Upgrade/compatibility impact == This should not impact upgrades. == How To Test == This change can be tested by rebuilding affected packages. The goal is to complete this before the mass rebuild to ensure maximum testing coverage. == User Experience == Fedora users will not notice any difference with this change. This will only impact Fedora package maintainers. == Dependencies == gcc < 11 will fail if the -flto=auto option is used when make is not installed. Phase 3 cannot be completed until gcc 11 lands in rawhide, but Phase 1 and Phase 2 are not blocked by this. == Contingency Plan == * '''Contingency mechanism:''' If we discover critical issues during phase 4, then Fedora Release Engineering will need to re-add make into the buildroot. * '''Contingency deadline:''' 2021-02-23 (F34 Beta Freeze) * '''Blocks release?''' No * '''Blocks product?''' No == Documentation == The packager guidelines will need to be updated to mention that BuildRequires: make is now required for all packages that need make. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

23 56

git push permission denied
by Neal Becker 10 Feb '21

10 Feb '21

I just had to setup a new machine, and new ssh keys. I visited https://admin.fedoraproject.org/accounts/user/edit/xxxx I chose my new id_rsa.pub to upload. But I get: git push --verbose Pushing to ssh://nbecker@pkgs.fedoraproject.org/mercurial Permission denied (publickey). fatal: The remote end hung up unexpectedly Hints?

4 5

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 January 2021