Re: Delta RPMs in Fedora 34
Dne 05. 01. 21 v 0:29 Matthew Miller napsal(a): > So, the first thing we need to do to fix this is move deltarpm creation out > of the updates process. Right. > Kevin Fenzi tells me this would mean we'd need a > separate delta RPMs repo, Why? You can do that in the same repo. You just need once per X days/hours run createrepo_c --deltas --num-deltas X -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Self Introduction -- Derek Pressnall
Dne 29. 12. 20 v 12:02 Fabio Valentini napsal(a): On Mon, Dec 28, 2020 at 2:21 PM Derek Pressnall wrote: (snip) Welcome to Fedora! Meanwhile, a couple additional questions. Right now I have a template of the spec file in the project's Git repo. Should the spec file be in its own repo (or possibly an orphaned branch of this repo)? That way all packaging-specific items can be versioned separately from the app itself. Secondly, I'll put the above Makefile modifications in shortly, but it may be a bit before the next posted release of Snebu. So for the purpose of the RPM, should I put them in as patches (that are owned by the rpm) until the next Snebu release comes out? Thanks. Since you're aiming to submit the package as an official Fedora package, the .spec file should not live upstream. For Fedora packages, the Fedora dist-git repository is considered the "source of truth" for a package's .spec files: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity So you actually shouldn't track the .spec file in the upstream project's git repo, but use the official git repo provided for every Fedora package instead. OTOH, if you have .spec file in upstream repository, you could try to use Packit: https://packit.dev/ https://packit.dev/docs/packit-as-a-service/ Vít As for the second question, yes, a .patch file sounds like the best way to do that until the next release has those changes. Fabio (decathorpe) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org OpenPGP_0x0CE09EE79917B87C.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
* Matthew Miller: > I also remember when this was a killer feature for Fedora, and without any > real way of judging use and demand, I'm hesitant to kill it off. Is it really saving bandwidth, though? The reported savings are generally very small for me. Downloading the metadata costs something as well. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: How to easily automate test builds in a COPR project
On Thu, Dec 31, 2020 at 3:46 PM Till Maas wrote: > > Hi, > > On Thu, Dec 31, 2020 at 07:58:53AM -0600, Richard Shaw wrote: > > > 4. Build the packages in COPR. > > > > Easy enough using a bash script but is there a better way? > > packit allows to create test builds in COPR based on GitHub PRs and > probably also releases. Maybe this can make it easier for you, too: > https://packit.dev/ > > Cheers > Till You could host the repositories on GitHub (or GitLab) and get the benefits of packit: builds in copr, results in pull requests and tests via testing farm [1]. Though we don't have a way in packit to automatically pull upstream content into your (downstream) git repos, yet. Having this set up with upstream release monitoring would be interesting, or alternatively, you could set up a github action [2] or gitlab job [3] to pull upstream content periodically. I can help you out to set this up if needed. [1] https://packit.dev/docs/testing-farm/ [2] https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#scheduled-events [3] https://docs.gitlab.com/ee/ci/pipelines/schedules.html Tomas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
What's the progress on this change? Is it going to land in one week? I just want to be sure that our tooling is ready and works with this change since we hardcode "fedora-master" in many places. Thanks! Tomas On Thu, Dec 3, 2020 at 4:06 PM Ben Cotton wrote: > > 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: ke...@scrye.com, bcot...@redhat.com, pin...@pingoured.fr, > mbo...@bhujji.com, opensou...@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-branches.py > 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.py > create-new-release-branches.py] > > * Policies and guidelines: N/A > > *
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
Hi, On 12/30/20 11:52 PM, Neal Gompa wrote: > On Wed, Dec 30, 2020 at 5:48 PM Marius Schwarz wrote: >> >> Am 30.12.20 um 22:14 schrieb Michel Alexandre Salim: >>> - a separate partition for storing GRUB config, no matter what >>> architecture, is probably the ideal solution >> Not always. In VMs you would reduce the amount of partitions to ease up >> things. The main problem with Vms is, that you have LTS based linux >> distros on the host systems which can't mount the vm guest, if the guest >> uses newer filesystems. If you then use BTRFS on the boot partition or >> store grub configs in partionheaders, you can't access those from the >> guest making it impossible to change the bootconfig, if it fails for >> some stupid reasons like older pygrub ( xen ) boot loaders, which can't >> handle the kernel images compression/format. Happend last with Xenserver >> and Kernel 5.9. >> >> For this, i.E. me, choose to store the boot config on / so we have just >> one partition with ext4, which can easily mounted on the host, as ext4 >> can be handled by the older LTS systems on the host. >> >> As Fedora is a good server os, if the ui parts have been removed ;), it >> should be taken into any consideration, that it may not be a bare metal >> installation you make plans for. It still needs to run in good old >> stable setups ;) >> > > The issues Michel is referring to do not apply to Fedora Server using > Btrfs, because outside of Workstation, currently no variant of Fedora > has cross-layer integration with the bootloader. I do not think that that is entirely true, well it depends on if anaconda also sets the menu_auto_hide=1 variable for other variants. The grub hidden boot menu stuff: https://fedoraproject.org/wiki/Changes/HiddenGrubMenu https://hansdegoede.livejournal.com/19081.html Should mostly work, assuming they at least use a systemd user-session. The boot menu being hidden or not depends on the boot_success grubenv variable, which gets set by a systemd-timer in the systemd-user session of non-system (aka normal) users if the user-session has lasted at least 2 minutes. And since Fedora 33, the integration to force the boot-menu to be shown is using the standard systemd DBUS APIs for this, so that e.g. : systemctl reboot -boot-loader-menu=60 To cause the menu to show next boot with a timeout of 60 seconds works now, except for a selinux bug which will hopefully be resolved soon: https://bugzilla.redhat.com/show_bug.cgi?id=1856399 So other desktop-environments / spins / variants could also integrate more closely with the hidden-boot-menu stuff, which is a pre-requisite for getting a fully flicker free boot. I would be happy to answer any questions people may have about this, but I'm afraid I do not have the time to actively help with this (outside of answering questions). As for writing docs, the FAQ on my blog answers all end-user questions that I know about. But yes we could use some more docs to help other variants integrate better with this. If someone wants to start a wiki page based on the Change + FAQ pages and then extend that as closer integration is added to other variants, go for it. Feel free to take all the text I wrote on this and put it under any FOSS license of your choice. > That is, Fedora KDE does not currently have integration at the desktop > level to trigger different GRUB states like GNOME will in Workstation. If the KDE folks want to work on this, I'm happy to provide assistance, see above. > Cockpit in Fedora Server Edition also lacks this ability. I think that on servers just always showing the boot menu is fine and some even find this desirable. > Most of this is due to missing documentation to actually *implement* > the capability in other variants. But the side effect is that the > concern we have is pretty much exclusive to Fedora Workstation. See above, I admit this is not that well documented. But I have always answered questions on this from various people, including other distros who have implemented this from scratch themselves. So the info is available in a way. And if someone can turn my emails into docs for this then that would be even better. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
> Is it really saving bandwidth, though? The reported savings are > generally very small for me. Downloading the metadata costs something > as well. In F33, mostly so. I generally keep up to date (update once a week), but available deltarpms have been lesser compared to earlier versions. I used deltarpm from the day it was introduced in Fedora, and found it quite useful due to limited internet connection (speed/bandwidth/data limit) — for instance TeXLive package updates (which, afait, doesn’t generate deltarpms in f33) etc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
On Mon, Jan 4, 2021, at 6:29 PM, Matthew Miller wrote: > > I also remember when this was a killer feature for Fedora, and without any > real way of judging use and demand, I'm hesitant to kill it off. But that's > definitely plan B. We can point people who are in low-bandwidth situations > at Silverblue, CoreOS, and Kinoite as the preferred approach. Please don't use phrasing like this that implies e.g. CoreOS is distinct from "Fedora". A much technically clearer way to say this would be "traditional dnf Fedora" versus rpm-ostree. But even then it's not fully distinct because rpm-ostree also links to libdnf and whenever you use package layering, it's all the same RPM tools on the wire. Though...ah right, the deltarpm implementation lives in the dnf Python code, not the libdnf library, so rpm-ostree doesn't do that. Second - and this should be emphasized - a common case at least on Silverblue is that you run dnf inside a toolbox-style container (or more than one!). So all bandwidth improvements apply there too. In other words this (implict) contrast between the two is false because in both cases there are hybrids. Now speaking of deltas - really delta implementations are going to benefit from a stronger "cadence" to releases, exactly much like what we do for CoreOS (but not Silverblue/IoT) today. The relationship of such a system and Bodhi is...messy. ostree deltas are also *much* better than deltarpm in various ways (most notably the CPU intensive part is bsdiff which we only use selectively instead of the whole thing). On the other hand, we really want deltas too for containers; that's https://github.com/containers/image/pull/902 A very tricky case is the intersection of all of these; for my "dev container"/toolbox on my Silverblue workstation I use a custom container built on a server with all of my tools, but I do often `yum update` inside it since that works incrementally and online. (But I do periodically flush and re-pull) If we implemented container deltas I'd be a lot more likely to use `podman` to update it instead. But anyways, please either explicitly spell out "Fedora CoreOS" to avoid an implicit contrast and making it seem like a separate thing from "Fedora", or go more technical and say "rpm-ostree variant" or so. Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
On Tue, Jan 5, 2021 at 8:34 AM Colin Walters wrote: > > > > On Mon, Jan 4, 2021, at 6:29 PM, Matthew Miller wrote: > > > > I also remember when this was a killer feature for Fedora, and without any > > real way of judging use and demand, I'm hesitant to kill it off. But that's > > definitely plan B. We can point people who are in low-bandwidth situations > > at Silverblue, CoreOS, and Kinoite as the preferred approach. > > Please don't use phrasing like this that implies e.g. CoreOS is distinct from > "Fedora". > But as of right now, it *is*. Perhaps that will change if FCOS realigns with Fedora as part of being promoted to Edition status, but right now, it's different enough content-wise that it's less like Fedora than most of us would want it to be. > A much technically clearer way to say this would be "traditional dnf Fedora" > versus rpm-ostree. > > But even then it's not fully distinct because rpm-ostree also links to libdnf > and whenever you use package layering, it's all the same RPM tools on the > wire. Though...ah right, the deltarpm implementation lives in the dnf Python > code, not the libdnf library, so rpm-ostree doesn't do that. > > Second - and this should be emphasized - a common case at least on Silverblue > is that you run dnf inside a toolbox-style container (or more than one!). So > all bandwidth improvements apply there too. In other words this (implict) > contrast between the two is false because in both cases there are hybrids. > > Now speaking of deltas - really delta implementations are going to benefit > from a stronger "cadence" to releases, exactly much like what we do for > CoreOS (but not Silverblue/IoT) today. The relationship of such a system and > Bodhi is...messy. > ostree deltas are also *much* better than deltarpm in various ways (most > notably the CPU intensive part is bsdiff which we only use selectively > instead of the whole thing). > Cadence only matters if the infrastructure around delta fetching requires it to care. In the case of RPM-OSTree and Flatpak, this is not a problem as long as you're using native OSTree remotes. If you're using OCI image remotes instead, then you *do* have to care about cadence because you have to maintain images and generate deltas based on possible options. The latter option is how we deliver Flatpaks, and so we have the same problem we have with DeltaRPMs. > On the other hand, we really want deltas too for containers; that's > https://github.com/containers/image/pull/902 > > A very tricky case is the intersection of all of these; for my "dev > container"/toolbox on my Silverblue workstation I use a custom container > built on a server with all of my tools, but I do often `yum update` inside it > since that works incrementally and online. (But I do periodically flush and > re-pull) If we implemented container deltas I'd be a lot more likely to use > `podman` to update it instead. Addressing the underlying issue here: container deltas and OSTree deltas are considerably worse for constrained bandwidth than RPM deltas. Outside of the USA (in the general case) and within the USA (in several parts of the country), it is extremely common to have extremely limited bandwidth availability and even more common to have low throughput. As that will basically never change, we have to work with that framework. Regular Fedora variants offer users the ability to pick and choose updates based on their situation. If DeltaRPMs were implemented in our infrastructure correctly, those users would be very well-served by being able to publish a sliding window of the last 30 days of delta RPM content. What's particularly galling here is that we have all the necessary inputs to do it, since Koji keeps everything and Bodhi knows everything that's ever been pushed. It's pretty much a Pungi restriction that we've never been able to do this properly. To be blunt, I would have never done Zchunk metadata if it was going to be used as a tool to kill DeltaRPMs. I firmly believe we need both to have a comprehensive offering that accommodates the needs of Fedora users across the world. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Schedule for Wednesday's FESCo Meeting (2021-01-06)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2021-01-06 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #2527 F34 Change: Use ibus-m17n as the default IME for Vietnamese https://pagure.io/fesco/issue/2527 APPROVED (+4, 0, 0) #2526 F34 Change: LLVM 12 https://pagure.io/fesco/issue/2526 APPROVED (+5, 0, 0) #2525 Updates Policy exception for black (python-black) https://pagure.io/fesco/issue/2525 APPROVED (+4, 0, 0) #2524 F34 Change: Boost 1.75 upgrade https://pagure.io/fesco/issue/2524 APPROVED (+5, 0, 0) #2523 F34 Change: Stop Shipping Individual Nodejs Library Packages https://pagure.io/fesco/issue/2523 APPROVED (+4, 0, 0) #2521 F34 Change: Stratis 2.3.0 https://pagure.io/fesco/issue/2521 APPROVED (+5, 0, 0) #2520 F34 Change: Ignore Anaconda kernel boot parameters without 'inst.' prefix https://pagure.io/fesco/issue/2520 APPROVED (+5, 0, 0) #2518 F34 Change: Ruby 3.0 https://pagure.io/fesco/issue/2518 APPROVED (+6, 0, 0) #2517 F34 Change: ntp replacement https://pagure.io/fesco/issue/2517 APPROVED (+5, 0, 0) #2515 F34 Change: Xwayland as a standalone package https://pagure.io/fesco/issue/2515 APPROVED (+4, 0, 0) #2514 F34 Change: ibus-anthy for default Japanese IME https://pagure.io/fesco/issue/2514 APPROVED (+3, 1, 0) #2506 Nonresponsive maintainer: John Dennis (jdennis) https://pagure.io/fesco/issue/2506 APPROVED (+4, 0, 0) = Followups = #2473 updates policy is out of date https://pagure.io/fesco/issue/2473 Please review the latest pull request (https://pagure.io/fesco/fesco-docs/pull-request/41). = New business = #2535 F34 Change: Enable systemd-oomd by default for all variants https://pagure.io/fesco/issue/2535 #2532 F34 Change: Enable spec file preprocessing https://pagure.io/fesco/issue/2532 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Updates Policy exception for black (python-black)
On 05. 01. 21 15:07, Zbigniew Jędrzejewski-Szmek wrote: #2525 Updates Policy exception for black (python-black) https://pagure.io/fesco/issue/2525 APPROVED (+4, 0, 0) Upgraded black is in bodhi: F33: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a453d7234b F32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-121b1af33c I would rather not push it stable without karma, so if you use black from RPM, please upgrade and test it. Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
List of long term FTBFS packages to be retired in February
Dear maintainers. Based on the current fail to build from source policy, the following packages will be retired from Fedora 34 approximately one week before branching (February 2021). Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ Note that some listed packages are orphaned and hence may be retired even sooner. The packages in rawhide were not successfully built at least since Fedora 32. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers Latest build VirtualGL gsgatlinFedora 31 boo elsupergomez, orphan, tpokorra Fedora 31 sugar-flipstickscallkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31 sugar-getiabookscallkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31 sugar-infoslicercallkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31 sugar-labyrinth callkalpa, chimosky, pbrobinson Fedora 31 sugar-ruler callkalpa, chimosky Fedora 31 sugar-starchart callkalpa, chimosky, orphan Fedora 31 sugar-view-slides callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31 No packages require above mentioned packages. Affected (co)maintainers callkalpa: sugar-labyrinth, sugar-starchart, sugar-ruler, sugar-getiabooks, sugar-infoslicer, sugar-view-slides, sugar-flipsticks chimosky: sugar-labyrinth, sugar-starchart, sugar-ruler, sugar-getiabooks, sugar-infoslicer, sugar-view-slides, sugar-flipsticks elsupergomez: boo gsgatlin: VirtualGL pbrobinson: sugar-labyrinth, sugar-getiabooks, sugar-infoslicer, sugar-view-slides, sugar-flipsticks tpokorra: boo tuxbrewr: sugar-getiabooks, sugar-infoslicer, sugar-view-slides, sugar-flipsticks ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
NTP change (was Re: Schedule for Wednesday's FESCo Meeting (2021-01-06))
Once upon a time, Zbigniew Jędrzejewski-Szmek said: > #2517 F34 Change: ntp replacement > https://pagure.io/fesco/issue/2517 > APPROVED (+5, 0, 0) I changed my stratum 1 server from ntpd to chronyd+ntp-refclock... had a few small bumps to figure out (getting the NTP, PPS, and chrony services correct), but it is working. It might be useful for others to document how I have it working - where would be a good place for that? Submit a README example or something? -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
On Tue, Jan 05, 2021 at 08:49:20AM -0500, Neal Gompa wrote: > On Tue, Jan 5, 2021 at 8:34 AM Colin Walters wrote: > > Now speaking of deltas - really delta implementations are going to benefit > > from a stronger "cadence" to releases, exactly much like what we do for > > CoreOS (but not Silverblue/IoT) today. The relationship of such a system > > and Bodhi is...messy. > > ostree deltas are also *much* better than deltarpm in various ways (most > > notably the CPU intensive part is bsdiff which we only use selectively > > instead of the whole thing). > > > > Cadence only matters if the infrastructure around delta fetching > requires it to care. In the case of RPM-OSTree and Flatpak, this is > not a problem as long as you're using native OSTree remotes. If you're > using OCI image remotes instead, then you *do* have to care about > cadence because you have to maintain images and generate deltas based > on possible options. The latter option is how we deliver Flatpaks, and > so we have the same problem we have with DeltaRPMs. > > > On the other hand, we really want deltas too for containers; that's > > https://github.com/containers/image/pull/902 > > > > A very tricky case is the intersection of all of these; for my "dev > > container"/toolbox on my Silverblue workstation I use a custom container > > built on a server with all of my tools, but I do often `yum update` inside > > it since that works incrementally and online. (But I do periodically flush > > and re-pull) If we implemented container deltas I'd be a lot more likely > > to use `podman` to update it instead. > > Addressing the underlying issue here: container deltas and OSTree > deltas are considerably worse for constrained bandwidth than RPM > deltas. Outside of the USA (in the general case) and within the USA > (in several parts of the country), it is extremely common to have > extremely limited bandwidth availability and even more common to have > low throughput. As that will basically never change, we have to work > with that framework. > > Regular Fedora variants offer users the ability to pick and choose > updates based on their situation. If DeltaRPMs were implemented in our > infrastructure correctly, those users would be very well-served by > being able to publish a sliding window of the last 30 days of delta > RPM content. What's particularly galling here is that we have all the > necessary inputs to do it, since Koji keeps everything and Bodhi knows > everything that's ever been pushed. It's pretty much a Pungi > restriction that we've never been able to do this properly. Another thought: we could use popcon-like information to generate delta rpms only for N% most popular packages (10%?). This would significantly cut down on the cost of generation, without really affecting average user savings. Yet another reason why popcon would be useful. > To be blunt, I would have never done Zchunk metadata if it was going > to be used as a tool to kill DeltaRPMs. I firmly believe we need both > to have a comprehensive offering that accommodates the needs of Fedora > users across the world. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
Hi, > we aren't making very many, which makes them even less useful. Plus, we're > only making them between updates and for packages where those updates are > frequent, that means you need to keep on top of things, which may be best > practice but is most difficult for low-bandwidth users who might most > benefit in the first place. I'm a low bandwidth user. And my setup basically is: (1) route all updates though a squid caching proxy. (2) configure all fedora machines to use the same fixed mirror. (3) disable drpms. (4) disable zchunk. There are always cases where you need the full rpm anyway (for example fresh installs with update repo enabled), so just loading (+caching!) the full rpms and don't bother with drpms works better overall. The problem with zchunk is that it isn't cache-friendly. squid can't cache range requests. And even in case of a full download (fresh install) I've seen zchunk metadata being re-downloaded when requested again ... take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Self Introduction: Frédéric Pierret (fepitre)
Hi, My name is Frédéric and you can reach me on Github as "fepitre" (https://github.com/fepitre). I'm currently a member of Qubes OS (https://github.com/QubesOS) core team since 2016. In this project, my work consists in releasing (building, packaging, testing or continuous integration) the OS at every stages. Qubes OS has its dom0 based on a customized Fedora for embedding our custom Xen version and Qubes specific components. For example, our own Qubes specific libraries or tools, kernel or even custom Anaconda installer. Moreover, we build our own VM templates from scratch for VMs for which I'm a maintainer of the Fedora, Debian, CentOS or Gentoo ones. For the Fedora/CentOS work on Qubes OS, I have several COPR repositories https://copr.fedorainfracloud.org/coprs/fepitre/ for which I've built some of Fedora packages for CentOS not in EPEL or maybe some of you have seen my few PRs this summer in order to ease me the build of a larger python3.8 repository for CentOS 8+. I'm contacting you because I would like to propose my help for either Fedora or EPEL packaging. Notably, I'm recently involved in reproducible topics (https://reproducible-builds.org/) for which I'm trying to implement RPM support and packaging for tools like `reprotest` (see https://salsa.debian.org/reproducible-builds/reprotest/-/merge_requests/10 or https://salsa.debian.org/reproducible-builds/disorderfs/-/merge_requests/4). The idea is to help into reviving Fedora reproducible builds topic (see https://tests.reproducible-builds.org/rpms/fedora-23.html). I'm using Redhat linux distribution family for more than 20 years so I guess it's time to propose my help into this community effort. Best regards, Frédéric OpenPGP_0x484010B5CDC576E2.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
On Mon, Jan 04, 2021 at 06:29:13PM -0500, Matthew Miller wrote: > I also remember when this was a killer feature for Fedora, and without any > real way of judging use and demand, I'm hesitant to kill it off. But that's > definitely plan B. We can point people who are in low-bandwidth situations > at Silverblue, CoreOS, and Kinoite as the preferred approach. It is also very difficult to measure - for my part I'm happy for every MB saved when downloading updates at home, because it directly translates into waiting time. At work I don't have a bandwidth problem, so it's way less of an issue there. But I don't see anywhere how much the potential is - iirc correctly it sometimes saves hundreds of MBs, which translates into something like 10-20 Minutes saved time. Even though it's an after-the-fact information I'm still happy it doing its job. (Interestingly on the last update almost half of the md5 sums mismatched for the drpms, which increased download size from 12.3MB to 14.0MB - but this seems to be a rare problem) Personally I'd like to stay on regular Fedora Workstation / Fedora Server - I'd probably decide to take increased download times instead of switching distros/editions if drpm gets removed. All the best, Astra signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Mass spec file change: Adding BuildRequires: make
On 11/30/20 2:06 PM, Tom Stellard wrote: Hi, As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed. If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update. I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes: Dec 14: Update first 50 packages. Dec 16: Next 1000. Dec 18: Next 1000. Jan 4: Next 1000. Jan 5: Next 1000. Here is the list of packages I'll be updating today: https://fedorapeople.org/~tstellar/br_make_day5.txt -Tom Jan 6: Next 1000. Jan 7: Next 1000. Jan 8: Rest of packages. The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20). Thanks, Tom [1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
On Tue, 5 Jan 2021 at 03:50, Miroslav Suchý wrote:
> Dne 05. 01. 21 v 0:29 Matthew Miller napsal(a):
> > So, the first thing we need to do to fix this is move deltarpm creation
> out
> > of the updates process.
>
> Right.
>
> > Kevin Fenzi tells me this would mean we'd need a
> > separate delta RPMs repo,
>
> Why? You can do that in the same repo. You just need once per X days/hours
> run
> createrepo_c --deltas --num-deltas X
>
>
Get pungi and all the other tools in the build system which touch the repos
and expect things to be done in a certain way to not break, corrupt or make
releng's life a daily nightmare and you are golden.
Remember the Fedora build system is a Rube Goldberg machine[1] where every
group who has a new idea about how to make Linux easier to
compose/consume/etc have stuck something in. None of them have been
designed really to work with each other and various parts are completely
running on luck and mad patching (hi PDC). Everytime someone says 'just do
this one thing' it turns into a cascade of broken bits where everyone
spends a month or 2 blaming (1) releng for adding in one more thing and (2)
every other group for messing with their perfect tool. Since we usually
have 1-2 months to get something in place before the next release.. that
means we have whatever time left over from the poop-throwing festival to
monkey-patch it for another release and then live with the system breaking
daily for a couple of months. [Then watch Kevin and Mohan grow more
Stockholm syndrome to say that the system is fine.. just like the previous
release engineers who have departed from Fedora.]
Patches, ideas and fixes are indeed helpful, but what would be more helpful
is getting everyone with a say on the build system and their one thing that
they want from Release Engineering in a room to work out what the entire
developer and build system experience should be with an idea of how to make
it more manageable and more able to slot in things in and out versus
'ah {'mass rebuild','beta release','final release','2 week holiday'}
is in 2 days get that tool working'
[1] https://en.wikipedia.org/wiki/Rube_Goldberg_machine
--
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
>
--
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Self Introduction: Frédéric Pierret (fepitre)
On Tue, Jan 5, 2021 at 9:45 AM Frédéric Pierret wrote: > > Hi, > > My name is Frédéric and you can reach me on Github as "fepitre" > (https://github.com/fepitre). > > I'm currently a member of Qubes OS (https://github.com/QubesOS) core team > since 2016. In this project, my work consists in releasing (building, > packaging, testing or continuous integration) the OS at every stages. Qubes > OS has its dom0 based on a customized Fedora for embedding our custom Xen > version and Qubes specific components. For example, our own Qubes specific > libraries or tools, kernel or even custom Anaconda installer. Moreover, we > build our own VM templates from scratch for VMs for which I'm a maintainer of > the Fedora, Debian, CentOS or Gentoo ones. > > For the Fedora/CentOS work on Qubes OS, I have several COPR repositories > https://copr.fedorainfracloud.org/coprs/fepitre/ for which I've built some of > Fedora packages for CentOS not in EPEL or maybe some of you have seen my few > PRs this summer in order to ease me the build of a larger python3.8 > repository for CentOS 8+. > > I'm contacting you because I would like to propose my help for either Fedora > or EPEL packaging. Notably, I'm recently involved in reproducible topics > (https://reproducible-builds.org/) for which I'm trying to implement RPM > support and packaging for tools like `reprotest` (see > https://salsa.debian.org/reproducible-builds/reprotest/-/merge_requests/10 or > https://salsa.debian.org/reproducible-builds/disorderfs/-/merge_requests/4). > The idea is to help into reviving Fedora reproducible builds topic (see > https://tests.reproducible-builds.org/rpms/fedora-23.html). > > I'm using Redhat linux distribution family for more than 20 years so I guess > it's time to propose my help into this community effort. > Welcome to Fedora, Frédéric! I'm looking forward to see efforts around reproducible builds in Fedora. :) -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Thu, Dec 31, 2020 at 06:28:22PM +0800, Qiyu Yan wrote: > Vitaly Zaitsev via devel > 于2020年12月31日周四 下午6:12写道： > > > > On 30.12.2020 20:53, Ben Cotton wrote: > > > This change makes the GRUB configuration files layout to be consistent > > > across all the supported architectures. Currently EFI is a special > > > case since the GRUB configuration file and environment variables block > > > are stored in the EFI System Partition (ESP) instead of the boot > > > partition (or `/boot` directory if no boot partition is used). > > > > Why not switch from the ancient GRUB2 to the modern systemd-boot? > iirc systemd-boot don't support legacy BIOS system. You can install systemd-boot and grub2-pc side-by-side, sharing the bls boot configuration, and have a system bootable in both uefi and bios mode. We don't have systemd-boot on !x86 though. aarch64 didn't work last time I tried. armhfp seems to not be supported (at least the fedora rpm hasn't binaries). s390x and ppc are not efi platforms. So if we want cross-platform consistency grub2 is the best option we have. The config file is ugly, but thanks to bls you can largely ignore that now. No need to touch it for kernel updates etc. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Self Introduction: Frédéric Pierret (fepitre)
Welcome Frédéric! On Tue, 2021-01-05 at 15:44 +0100, Frédéric Pierret wrote: > Hi, > > My name is Frédéric and you can reach me on Github as "fepitre" ( > https://github.com/fepitre). > > I'm currently a member of Qubes OS (https://github.com/QubesOS) core > team since 2016. In this project, my work consists in releasing > (building, packaging, testing or continuous integration) the OS at > every stages. Qubes OS has its dom0 based on a customized Fedora for > embedding our custom Xen version and Qubes specific components. For > example, our own Qubes specific libraries or tools, kernel or even > custom Anaconda installer. Moreover, we build our own VM templates > from scratch for VMs for which I'm a maintainer of the Fedora, > Debian, CentOS or Gentoo ones. > > For the Fedora/CentOS work on Qubes OS, I have several COPR > repositories https://copr.fedorainfracloud.org/coprs/fepitre/ for > which I've built some of Fedora packages for CentOS not in EPEL or > maybe some of you have seen my few PRs this summer in order to ease > me the build of a larger python3.8 repository for CentOS 8+. > > I'm contacting you because I would like to propose my help for either > Fedora or EPEL packaging. Notably, I'm recently involved in > reproducible topics (https://reproducible-builds.org/) for which I'm > trying to implement RPM support and packaging for tools like > `reprotest` (see > https://salsa.debian.org/reproducible-builds/reprotest/-/merge_requests/10 > or > https://salsa.debian.org/reproducible-builds/disorderfs/-/merge_requests/4 > ). The idea is to help into reviving Fedora reproducible builds topic > (see https://tests.reproducible-builds.org/rpms/fedora-23.html). > > I'm using Redhat linux distribution family for more than 20 years so > I guess it's time to propose my help into this community effort. > Help with Fedora or EPEL packaging is definitely welcome! Really interested in reproducible builds as well, and any help I can provide to help Qubes as well. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Orphaning python-orderedset and auto-destdir
I took python-orderedset. On 12/30/20 4:41 PM, Jerry James wrote: > I maintain packages that used to BR the packages in $SUBJECT, but with > their latest versions no longer do. I'm orphaning these packages. If > you need them, please pick them up. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
On Tue, Jan 05, 2021 at 11:30:10AM +0100, Florian Weimer wrote: > > I also remember when this was a killer feature for Fedora, and without any > > real way of judging use and demand, I'm hesitant to kill it off. > > Is it really saving bandwidth, though? The reported savings are > generally very small for me. Downloading the metadata costs something > as well. If we made a lot more of them, they could save significant bandwidth. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
* Matthew Miller: > On Tue, Jan 05, 2021 at 11:30:10AM +0100, Florian Weimer wrote: >> > I also remember when this was a killer feature for Fedora, and without any >> > real way of judging use and demand, I'm hesitant to kill it off. >> >> Is it really saving bandwidth, though? The reported savings are >> generally very small for me. Downloading the metadata costs something >> as well. > > If we made a lot more of them, they could save significant bandwidth. The metadata would also be much larger, and so would be the battery usage to recompress the payload. 8-( Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Fwd: Thoughts on the file system layout
This may be of interest to us as well... -- Forwarded message - From: Ludwig Nussel Date: Tue, Jan 5, 2021 at 11:03 AM Subject: Thoughts on the file system layout To: Hi, While working on MicroOS, UsrMerge, UsrEtc, playing with systemd features I was wondering where that could lead us to. I'm sure we didn't utilize the full potential of what we can do with our OS yet. So I've tried to dump my thoughts into an article: https://github.com/lnussel/lnussel.github.io/blob/fs/_posts/2020-12-16-fslayout.md tl;dr rpms to only operate below /usr and nowhere else. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Updating armadillo and dependent packages (rawhide)
Hi, a bit later than what I expected (holidays are a busy time as well :-) ) I will update armadillo to 10.1.0. This implies an so bump and so I will update it in a side tag together with the dependent packages gdal and mlpack. I intend to do this for rawhide, and later for Fedora 33 and 32. Best regards, -- José Abílio___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Self Introduction: Frédéric Pierret (fepitre)
Am 05.01.21 um 16:01 schrieb Neal Gompa: Welcome to Fedora, Frédéric! I'm looking forward to see efforts around reproducible builds in Fedora. :) +1 from me. I think this is really on example where free software can really show its strengths and if there is some easy tooling in Fedora to ensure packages are reproducible I'd start migrating my (mostly Python) packages to ensure they can be built reproducibly (or at least nag upstream about it). Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
On Tue, Jan 5, 2021 at 3:46 PM Florian Weimer wrote: > The metadata would also be much larger, and so would be the battery > usage to recompress the payload. 8-( And while the bandwidth reduction has value, cpu and wallclock time to rebuild the rpm is substantially increased for low end devices such as ARM SoCs with slow (compared to recent gen x86) cpus, and slow (compared to recent nvme) storage devices such as sd cards compared to just downloading the entire rpm. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Self Introduction: Frédéric Pierret (fepitre)
On Tue, Jan 05, 2021 at 03:44:31PM +0100, Frédéric Pierret wrote: > I'm using Redhat linux distribution family for more than 20 years so I > guess it's time to propose my help into this community effort. Welcome! Glad to have you here! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
Dne 24. 12. 20 v 22:54 Matthew Almond via devel napsal(a): Depends on how it got there, and what you asked for. Here's some examples: 1. cp foo.rpm /var/cache/dnf//Packages/ && dnf install foo ...will fail the librepo full file check, and it'll be re- downloaded. 2. dnf install /root/foo.rpm || rpm -i /root/foo.rpm (not actually tested) will likely fail with CPIO/payload error Note that tools like rpm2cpio and rpm2archive will also fail on transcoded rpms. I have an open task to make the dnf plugin not transcode with 'yumdownloader' or 'dnf download' (plugin) as those are reasonable command to run. I will look at making error messages better and/or making some of these use cases work. This concerns us (speaking for RPM and DNF people) a little bit. If the transcoded RPM cannot be used as a regular RPM, it probably should have a different identity, for example a different suffix than .rpm. RPM and DNF are designed for generic use cases. I see these transcoded packages as a "cache" tailored for btrfs based systems only. It would be probably good to draw a border between them. If I understand it correctly, the transcoding happens on each host. Have you considered transcoding all RPMs in a repo on server instead? Or would that be inefficient and increase network traffic too much? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
Dne 05. 01. 21 v 0:50 Kevin Fenzi napsal(a): On Mon, Jan 04, 2021 at 06:29:13PM -0500, Matthew Miller wrote: On Mon, Jan 04, 2021 at 10:21:15PM +, Matthew Almond via devel wrote: There's been a lot of interesting talk about the state and future of drpm. I'd like to propose we continue the conversation about that with a different subject line :) Okay, fair. I have a proposal. Right now, the problem is that making delta rpms is expensive, and therefore we aren't making very many, which makes them even less useful. Plus, we're only making them between updates and for packages where those updates are frequent, that means you need to keep on top of things, which may be best practice but is most difficult for low-bandwidth users who might most benefit in the first place. So, the first thing we need to do to fix this is move deltarpm creation out of the updates process. Kevin Fenzi tells me this would mean we'd need a separate delta RPMs repo, which doesn't sound like a bad thing to me, but we're not sure offhand if DNF can handle that without modification. Yeah, I don't recall how dnf looks for drpms. Right now they are in the same repo, using the same repodata. If we moved them to a new repo would they get found correctly? This would let us make the delta RPMs asynchronously and not block updates. And, it would also give us the ability to roughly see how important they are to users, because we could see how popular that repository is compared to the updates repo. I also remember when this was a killer feature for Fedora, and without any real way of judging use and demand, I'm hesitant to kill it off. But that's definitely plan B. We can point people who are in low-bandwidth situations at Silverblue, CoreOS, and Kinoite as the preferred approach. Yeah, I came up with one more possible way we could get more drpms with our current setup, but need to talk to pungi maintainers and see if it's doable. :) After that, it's either split things out or drop drpms I think. To be honest, I don't understand why drpms are related to Pungi at all. Deltas are optional, if they're not available, a normal RPM is used. They can be processed asynchronously (as mentioned earlier in this thread) and injected in repos once they're ready. Please note that we're talking about 74 drpms in F33.x86_64 updates repo: http://ftp.fi.muni.cz/pub/linux/fedora/linux/updates/33/Everything/x86_64/drpms/ Sometimes I'm wondering if it's worth it and if Fedora shouldn't move away from drpms. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents Note that this change was submitted after the deadline, but since it can be shipped in an complete state, I am still processing it for Fedora 34. == Summary == We want to add signatures to individual files that are part of shipped RPMs. These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files. == Owner == * Name: [[User:Puiterwijk| Patrick Uiterwijk]] * Email: puiterw...@redhat.com * Name: [[User:Pbrobinson| Peter Robinson]] * Email: pbrobin...@gmail.com == Detailed Description == During signing builds, the files in it will be signed with IMA signatures.. These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults. == Benefit to Fedora == Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies. == Scope == * Proposal owners: The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults. * Other developers: Nothing needed from other developers * Release engineering: A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself. * Policies and guidelines: No impact * Trademark approval: No impact * Alignment with Objectives: This aligns with the Internet of Things objective. == Upgrade/compatibility impact == For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature. == How To Test == The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`. This should result in the system reporting “: verification is OK”. The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow). == User Experience == If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system. == Dependencies == No external package dependencies. == Contingency Plan == * Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise. If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release. * Contingency deadline: We could ship with this feature in an unfinished state. * Blocks release? No * Blocks product? N/A == Documentation == Documentation to follow. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Tue, Jan 05, 2021 at 12:26:45PM +0100, Tomas Tomecek wrote: > What's the progress on this change? Is it going to land in one week? I For src.fedoraproject.org yes. It's planned for next week. (some pagure.io projects we control should go tomorrow (Phase1)) > just want to be sure that our tooling is ready and works with this > change since we hardcode "fedora-master" in many places. We are meeting up later today to do some planning, I hope we can get staging moved over sooner and then you could test against that? kevin -- > Thanks! > > Tomas > > On Thu, Dec 3, 2020 at 4:06 PM Ben Cotton wrote: > > > > 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: ke...@scrye.com, bcot...@redhat.com, pin...@pingoured.fr, > > mbo...@bhujji.com, opensou...@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-branches.py > > 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/adju
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On Tue, Jan 05, 2021 at 01:05:01PM -0500, Ben Cotton wrote: > We want to add signatures to individual files that are part of shipped RPMs. This is for _every file_ in every RPM? Or some files in some RPMs? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On Tue, Jan 5, 2021 at 1:05 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents > > Note that this change was submitted after the deadline, but since it can be > shipped in an complete state, I am still processing it for Fedora 34. > > > == Summary == > We want to add signatures to individual files that are part of shipped RPMs. > These signatures will use the Linux IMA (Integrity Measurement Architecture) > scheme, which means they can be used to enforce runtime policies to ensure > execution of only trusted files. > > == Owner == > * Name: [[User:Puiterwijk| Patrick Uiterwijk]] > * Email: puiterw...@redhat.com > * Name: [[User:Pbrobinson| Peter Robinson]] > * Email: pbrobin...@gmail.com > > > == Detailed Description == > > During signing builds, the files in it will be signed with IMA signatures.. > These signatures will be made with a key that’s kept by the Fedora > Infrastructure team, and installed on the sign vaults. > > > == Benefit to Fedora == > > Having all files signed with a verifiable key means that system owners can > use the kernel Integrity and Measurement Architecture (IMA) to enforce only > verified files can be executed, or define other policies. > > == Scope == > * Proposal owners: > The proposal owners will write the code for sigul to pass the required > arguments, generate the keys in Infrastructure and get them deployed to the > sign vaults. > > * Other developers: > Nothing needed from other developers > > * Release engineering: > A mass rebuild would be nice (as it ensures all packages are signed), but is > not required to implement the change itself. > While having IMA is nice, can we *please* have repodata signing too? It's been asked many times over the past decade[1][2][3][4][5], and even if we don't enable it in our repo configuration files by default, it'd be great to have it optionally available for users to leverage. [1]: https://pagure.io/releng/issue/1501 [2]: https://pagure.io/koji/issue/835 [3]: https://pagure.io/pungi/issue/506 [4]: https://pagure.io/releng/issue/133 [5]: https://pagure.io/fedora-infrastructure/issue/9436 -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On Tue, Jan 5, 2021, at 1:05 PM, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents There's a bunch of related discussion in https://github.com/coreos/rpm-ostree/issues/1883 I think probably rather than having RPMs *also* include IMA signatures by default it'd be better to document/support tooling to implement the model of "add local signatures from a local key" that hooks into an unpacking procedure from tools like dnf/rpm-ostree, as well as podman. For all 3 the obvious thing to do is basically have a policy that "bridges" upstream transport integrity signatures (GPG) into signing with a local key. Basically all 3 would want a config file like: ``` $ cat > /etc/containers/storage.conf << EOF [ima] key=kernel-keyring://... ``` That'd be better because it would also apply to not-RPM sources and also better match what one needs to do for a truly "sealed" system as noted in that rpm-ostree issue where the system configuration is also locked, etc. AFAICS the documentation for IMA is...not great. I think this is related to its "meh" benefit with respect to security - we don't enable it by default because the benefit isn't really worth the cost in the general case. I found https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/enhancing-security-with-the-kernel-integrity-subsystem_managing-monitoring-and-updating-the-kernel but it's pretty sparse. The upstream docs https://sourceforge.net/p/linux-ima/wiki/Home/ of course suffer badly from the fact that they're generic to both distribution and software management system. I'm guessing based on the submitters at least some of this is intended to apply to an rpm-ostree based system? Would like to take some design if that's the case to that issue, but we can also discuss here. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
* Ben Cotton: > During signing builds, the files in it will be signed with IMA > signatures.. These signatures will be made with a key that’s kept by > the Fedora Infrastructure team, and installed on the sign vaults. What is the impact on RPM database size? Will GPLv3 packages be excluded, or will the signing keys be provided upon request? Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
On Tue, Jan 05, 2021 at 09:49:59AM +0100, Miroslav Suchý wrote: > Dne 05. 01. 21 v 0:29 Matthew Miller napsal(a): > > So, the first thing we need to do to fix this is move deltarpm creation out > > of the updates process. > > Right. > > > Kevin Fenzi tells me this would mean we'd need a > > separate delta RPMs repo, > > Why? You can do that in the same repo. You just need once per X days/hours run > createrepo_c --deltas --num-deltas X On Tue, Jan 05, 2021 at 06:30:37PM +0100, Daniel Mach wrote: > > To be honest, I don't understand why drpms are related to Pungi at all. > > Deltas are optional, if they're not available, a normal RPM is used. > They can be processed asynchronously (as mentioned earlier in this thread) > and injected in repos once they're ready. > > Please note that we're talking about 74 drpms in F33.x86_64 updates repo: > http://ftp.fi.muni.cz/pub/linux/fedora/linux/updates/33/Everything/x86_64/drpms/ > > Sometimes I'm wondering if it's worth it and if Fedora shouldn't move away > from drpms. so, ok then. I guess people are still confused about this. Here's my attempt to explain in detail how it currently works: When bodhi does an updates push (say for f33-updates), it does a lot of things. It checks the updates that are pending f33 stable updates, it locks them so no one can mess with them in the ui until it's done, it makes sure they are signed, it tells koji to move the tags the packages are tagged into into f33-updates, then it calls pungi to actually do the heavy lifting. This pungi process then talks to koji and says "hey, give me the latest tagged packages for the 'f33-updates' tag signed with key xyz. It puts them in directories for arch and type and such and runs createrepo_c to make the repodata. This is the point where it makes drpms. In order to make a drpm createpo_c needs to know what you want to make drpms for. It also has to have both the OLD and NEW versions available to make the drpm. createrepo_c also makes the normal repodata In our above case pungi has the current repos it's making and the f33-updates repo. Thus all the drpms it can make are ones where a new package version is being added to the repos and there is an older version available in f33-updates. It doesn't have access to all those versions before or after the ones it has. It only has those two. Once pungi is done, bodhi then does more things (emailing people, updating notes, etc) and... importantly, updates the repodata with the security information (so you can know what are security updates, etc). Then, that entire tree is synced to the master mirrors. On the next f33-updates push the entire process runs again. It never _updates_ existing repos, it always creates them. This means that if you have foo-1.0-1 in f33-updates, foo-1.1-1 comes along, it will make a drpm between them, that will exist _only_ on the day it added foo-1.1-1. The next day it will be gone. This is why there are so few drpms. It's only generating them for the things that it could at the time of the last push. So if you happen to update during a day where there were things updated that you have installed you would see the drpms. If you happen to update the next day, you would not. So, my last thought was to teach pungi about all the old updates trees (which are in the same directory as it makes the new one) and have it gather all the old drpms from those and expire them at some configurable time. This would not use more cycles to make them, and would make the chances of a user being able to use them much higher. But I am not sure this is possible/if pungi maintainers are willing to implement this. It would mean that createrepo_c would need to know about those old drpms to add them to metadata. Failing that we could move the drpm creation to another process/repo, but... drpms have to be in the same repodata as the repo they are for right? Or can they be in another one? Hope that clarifies more than it confuses... kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On Tue, Jan 05, 2021 at 07:41:05PM +0100, Florian Weimer wrote: > Will GPLv3 packages be excluded, or will the signing keys be provided > upon request? https://www.gnu.org/licenses/gpl-faq.en.html#GiveUpKeys Q: I use public key cryptography to sign my code to assure its authenticity. Is it true that GPLv3 forces me to release my private signing keys? A: No. The only time you would be required to release signing keys is if you conveyed GPLed software inside a User Product, and its hardware checked the software for a valid cryptographic signature before it would function. In that specific case, you would be required to provide anyone who owned the device, on demand, with the key to sign and install modified software on the device so that it will run. If each instance of the device uses a different key, then you need only give each purchaser a key for that instance -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On Tue, Jan 05, 2021 at 01:38:48PM -0500, Neal Gompa wrote: > > While having IMA is nice, can we *please* have repodata signing too? Why? It gets us nothing really... adds complexity and issues. We would definiltey need to improve dnf's handling of signed repos before we did at least. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
Dne 05. 01. 21 v 15:31 Zbigniew Jędrzejewski-Szmek napsal(a): > Yet another reason why popcon would be useful. https://github.com/xsuchy/popcon-for-fedora-old Feel free to take it :) -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On Tue, Jan 5, 2021 at 1:51 PM Kevin Fenzi wrote: > > On Tue, Jan 05, 2021 at 01:38:48PM -0500, Neal Gompa wrote: > > > > While having IMA is nice, can we *please* have repodata signing too? > > Why? It gets us nothing really... adds complexity and issues. > And IMA has the same problem. IMA is worse because it's so poorly understood that I doubt anyone knows how to even use it. > We would definiltey need to improve dnf's handling of signed repos > before we did at least. > No, we only need to do that to change the defaults so that we *always* use them. But those improvements will never happen as long as we don't have any repos that offer signed repodata. Signed repodata can be used by those who care about it as soon as it's available. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
Dne 05. 01. 21 v 19:44 Kevin Fenzi napsal(a): > On the next f33-updates push the entire process runs again. It never > _updates_ existing repos, it always creates them. Ahh. So this all worked when we run the the process once per week. But because we run it every day now, the deltas are minimal. It just took us several months to notice. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On Tue, 2021-01-05 at 13:05 -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents > > Note that this change was submitted after the deadline, but since it > can be shipped in an complete state, I am still processing it for > Fedora 34. > > > == Summary == > We want to add signatures to individual files that are part of > shipped RPMs. > These signatures will use the Linux IMA (Integrity Measurement > Architecture) scheme, which means they can be used to enforce runtime > policies to ensure execution of only trusted files. > Is there any relation between this and fapolicyd, that seems to be developed mostly by Red Hat employees? https://github.com/linux-application-whitelisting/fapolicyd -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Tue, 2021-01-05 at 18:18 +0100, Daniel Mach wrote: > Dne 24. 12. 20 v 22:54 Matthew Almond via devel napsal(a): > > Depends on how it got there, and what you asked for. Here's some > > examples: > > > > 1. cp foo.rpm /var/cache/dnf//Packages/ && dnf install foo > > ...will fail the librepo full file check, and it'll be re- > > downloaded. > > 2. dnf install /root/foo.rpm || rpm -i /root/foo.rpm > > (not actually tested) will likely fail with CPIO/payload error > > > > Note that tools like rpm2cpio and rpm2archive will also fail on > > transcoded rpms. I have an open task to make the dnf plugin not > > transcode with 'yumdownloader' or 'dnf download' (plugin) as those > > are > > reasonable command to run. I will look at making error messages > > better > > and/or making some of these use cases work. > > > > This concerns us (speaking for RPM and DNF people) a little bit. > If the transcoded RPM cannot be used as a regular RPM, it probably > should have a different identity, for example a different suffix > than > .rpm. RPM and DNF are designed for generic use cases. I see these > transcoded packages as a "cache" tailored for btrfs based systems > only. > It would be probably good to draw a border between them. > > If I understand it correctly, the transcoding happens on each host. > Have > you considered transcoding all RPMs in a repo on server instead? Or > would that be inefficient and increase network traffic too much? > The transcoded RPM is a valid RPM for the rpm program and most use cases. It's got all the original headers, so querying it (-qp) works perfectly, and it's still signed, and it's only produced in concert with dnf/librepo which validates that the file downloaded is the one described in the repo. Notably it doesn't work with rpm2cpio and rpm2archive (and yes, I'd like to have a better story there). You typically get these through 'dnf download'. When I implemented the plugin for yum, I was able to avoid transcoding, but on dnf it's not implemented yet. Signature *verification* partially works. Everything to do with signatures on just the header works (and the header describes the payload digest). There is one specific area which needs fixed: regular RPMs are read, digested, and signature verified before decompression. We need to guard against malicious compressed payloads that either perform a DoS on space/time, or worse (but more difficult) could exploit a bug in a decompression library. I am actively working on this. The bottom line is that in every place you'd expect to see an rpm, and use it later, you have exactly the same number of things in the same place. If you want to reflink clone the dnf cache into a container - it'll work (really well). If you want to clean up the cache in some selective way. The interface for the cache remains the same. On server side: no this doesn't make sense: you'd save on decompressing, but you'd use 2x the bandwidth and space on server side. You'll also need to keep the original rpms for clients that don't or can't use reflinking, so it's more like 2.5x the space, which I think is unreasonable. I do think there's some room in the future to think and talk about how repos could be changed to take better advantage of this. I got some feedback on RPM PR ( https://github.com/rpm-software-management/rpm/pull/1470#issuecomment-754025728 ) which is somewhere along the lines of what I was already thinking. That said, I'm aware that I'm being ambitious with this change request, and I'm focused on trying to integrate things that have been written/exist and can be demonstrated first. Hope these explanations help! Thanks for the feedback :) Matthew. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Release 5.6.1 of Sundials
side-tag created for sundials-5.6.1: $ koji list-tagged --latest f34-build-side-35531 Build Tag Built by sundials-5.6.1-1.fc34 f34-build-side-35531 sagitter On 23/12/20 22:28, Antonio T. sagitter wrote: Hi all. Next release of Sundials will be the 5.6.1: https://github.com/LLNL/sundials/releases/tag/v5.6.1 (Included changes of the 5.6.0 [1]) I'll update Sundials in Rawhide after the New Years'Day [1] https://github.com/LLNL/sundials/releases/tag/v5.6.0 ___ -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0x29FBC85D7A51CC2F GPG key server: https://keys.gnupg.net/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
On Tue, Jan 05, 2021 at 08:01:04PM +0100, Miroslav Suchý wrote: > Dne 05. 01. 21 v 19:44 Kevin Fenzi napsal(a): > > On the next f33-updates push the entire process runs again. It never > > _updates_ existing repos, it always creates them. > > Ahh. So this all worked when we run the the process once per week. It worked differently back when we used mash to create updates, I think because we also did drpms from the GA/base repo. Which we could do now, but It would only help users on their initial 'dnf update'. > But because we run it every day now, the deltas are > minimal. It just took us several months to notice. It's been this way since we moved to pungi. 3+ years. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On Tue, Jan 5, 2021 at 1:39 PM Neal Gompa wrote: > > On Tue, Jan 5, 2021 at 1:05 PM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents > > > > Note that this change was submitted after the deadline, but since it can be > > shipped in an complete state, I am still processing it for Fedora 34. > > > > > > == Summary == > > We want to add signatures to individual files that are part of shipped RPMs. > > These signatures will use the Linux IMA (Integrity Measurement > > Architecture) scheme, which means they can be used to enforce runtime > > policies to ensure execution of only trusted files. > > > > == Owner == > > * Name: [[User:Puiterwijk| Patrick Uiterwijk]] > > * Email: puiterw...@redhat.com > > * Name: [[User:Pbrobinson| Peter Robinson]] > > * Email: pbrobin...@gmail.com > > > > > > == Detailed Description == > > > > During signing builds, the files in it will be signed with IMA signatures.. > > These signatures will be made with a key that’s kept by the Fedora > > Infrastructure team, and installed on the sign vaults. > > > > > > == Benefit to Fedora == > > > > Having all files signed with a verifiable key means that system owners can > > use the kernel Integrity and Measurement Architecture (IMA) to enforce only > > verified files can be executed, or define other policies. > > > > == Scope == > > * Proposal owners: > > The proposal owners will write the code for sigul to pass the required > > arguments, generate the keys in Infrastructure and get them deployed to the > > sign vaults. > > > > * Other developers: > > Nothing needed from other developers > > > > * Release engineering: > > A mass rebuild would be nice (as it ensures all packages are signed), but > > is not required to implement the change itself. > > > > While having IMA is nice, can we *please* have repodata signing too? > It's been asked many times over the past decade[1][2][3][4][5], and > even if we don't enable it in our repo configuration files by default, > it'd be great to have it optionally available for users to leverage. I'd suggest starting a separate thread on this, or better, create a separate Change. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: thinking journal retention timelimits
Matthew Miller writes: > Logs can accidentally contain sensitive data, and it's just plain > faster to work with them when there's less. I propose we set this to > something like six months by default. If there are non-negligible speed impacts from large logs, this seems like a problem with systemd-journald - plain text doesn't have this problem. Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
On Tue, 2021-01-05 at 08:49 -0500, Neal Gompa wrote: > To be blunt, I would have never done Zchunk metadata if it was going > to be used as a tool to kill DeltaRPMs. I firmly believe we need both > to have a comprehensive offering that accommodates the needs of > Fedora users across the world. Hey Neal, I'm not sure where you're going with that first sentence, but I think it's pretty obvious that zchunk and deltarpms solve different problems and, following this thread, I don't think anyone has suggested that we should kill deltarpms *because* we have zchunk metadata. When we first brought deltarpms into Fedora, a savings of 60-90% when doing updates was normal. Now that we're losing the deltarpms after each push (as we have been for the last three years), the savings is significantly lower (I normally see less than 10%) and that makes it hard to be motivated to fix the bugs that inevitably arise. It sounds like there might be a plan to keep deltarpms beyond a single push, and, if that happens, I will be more than happy to keep on dealing with deltarpm bugs. :) Thanks, Jonathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
Zbigniew Jędrzejewski-Szmek writes: > On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/golang1.16 >> >> == Summary == >> Rebase of Golang package to upcoming version 1.16 in Fedora 34, > > No complaint about the Change, but... > can we please stop saying "rebase"? > > That verb made sense when packaging was about a stack of patches and > hacks. Nowadays maybe 90% of packages are just the upstream version, > and another 9% have patches backported from git that will be dropped > on the update to the next upstream version. Talking about a "rebase" > is mostly confusing. Not really a defense, but this is what we call it internally for RHEL. So even if we officially change the name, most of us are likely to keep calling it rebase out of habit. (And it does make sense for RHEL where backporting more patches is the norm. I'm uncomfortable with the assertion that ~99% of all packages have no downstream-only packages, but that might just be my bias in the opposite direction, since I maintain a couple that do.) Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On Tue, Jan 5, 2021 at 6:39 PM Neal Gompa wrote: > > On Tue, Jan 5, 2021 at 1:05 PM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents > > > > Note that this change was submitted after the deadline, but since it can be > > shipped in an complete state, I am still processing it for Fedora 34. > > > > > > == Summary == > > We want to add signatures to individual files that are part of shipped RPMs. > > These signatures will use the Linux IMA (Integrity Measurement > > Architecture) scheme, which means they can be used to enforce runtime > > policies to ensure execution of only trusted files. > > > > == Owner == > > * Name: [[User:Puiterwijk| Patrick Uiterwijk]] > > * Email: puiterw...@redhat.com > > * Name: [[User:Pbrobinson| Peter Robinson]] > > * Email: pbrobin...@gmail.com > > > > > > == Detailed Description == > > > > During signing builds, the files in it will be signed with IMA signatures.. > > These signatures will be made with a key that’s kept by the Fedora > > Infrastructure team, and installed on the sign vaults. > > > > > > == Benefit to Fedora == > > > > Having all files signed with a verifiable key means that system owners can > > use the kernel Integrity and Measurement Architecture (IMA) to enforce only > > verified files can be executed, or define other policies. > > > > == Scope == > > * Proposal owners: > > The proposal owners will write the code for sigul to pass the required > > arguments, generate the keys in Infrastructure and get them deployed to the > > sign vaults. > > > > * Other developers: > > Nothing needed from other developers > > > > * Release engineering: > > A mass rebuild would be nice (as it ensures all packages are signed), but > > is not required to implement the change itself. > > > > While having IMA is nice, can we *please* have repodata signing too? > It's been asked many times over the past decade[1][2][3][4][5], and > even if we don't enable it in our repo configuration files by default, > it'd be great to have it optionally available for users to leverage. This is completely unrelated please don't try and derail the topic. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On Tue, Jan 5, 2021 at 6:41 PM Florian Weimer wrote: > > * Ben Cotton: > > > During signing builds, the files in it will be signed with IMA > > signatures.. These signatures will be made with a key that’s kept by > > the Fedora Infrastructure team, and installed on the sign vaults. > > What is the impact on RPM database size? They're stored in xattr so it shouldn't have any noticeable impact, although Patrick can confirm the details of that. > Will GPLv3 packages be excluded, or will the signing keys be provided > upon request? The public key? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On Tue, Jan 5, 2021 at 6:59 PM Neal Gompa wrote: > > On Tue, Jan 5, 2021 at 1:51 PM Kevin Fenzi wrote: > > > > On Tue, Jan 05, 2021 at 01:38:48PM -0500, Neal Gompa wrote: > > > > > > While having IMA is nice, can we *please* have repodata signing too? > > > > Why? It gets us nothing really... adds complexity and issues. > > > > And IMA has the same problem. IMA is worse because it's so poorly > understood that I doubt anyone knows how to even use it. Well that's one of the things we're aiming to do here is to improve the tools and the process and the documentation. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
* Peter Robinson: > On Tue, Jan 5, 2021 at 6:41 PM Florian Weimer wrote: >> >> * Ben Cotton: >> >> > During signing builds, the files in it will be signed with IMA >> > signatures.. These signatures will be made with a key that’s kept by >> > the Fedora Infrastructure team, and installed on the sign vaults. >> >> What is the impact on RPM database size? > > They're stored in xattr so it shouldn't have any noticeable impact, > although Patrick can confirm the details of that. If the signatures end up in RPM headers, they will land in the RPM database, too. “rpm -qla | wc -l” shows around 28,589 files for me, in the Fedora 33 container image. / seems to need 183 MiB right now. If the signatures land in the RPM database and the file system, I expect at least 96 bytes per file signature (digests in the header are traditionally hex-encoded, I think). That translates to 2.6 MiB, or ~1.4% size increase. But quite likely there is some per-block overhead, so the numbers should be worse. >> Will GPLv3 packages be excluded, or will the signing keys be provided >> upon request? > > The public key? The private key. IMA is typically used for some form of remote attestation, I think. I'm not sure if it is possible to distribute hardware with IMA enforcement. And as long as enforcement can be turned of trivially (as required by the GPLv3, as far as I can tell), IMA seems to be pretty useless. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
On Tue, Jan 5, 2021 at 2:40 PM Robbie Harwood wrote: > > Zbigniew Jędrzejewski-Szmek writes: > > > On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote: > >> https://fedoraproject.org/wiki/Changes/golang1.16 > >> > >> == Summary == > >> Rebase of Golang package to upcoming version 1.16 in Fedora 34, > > > > No complaint about the Change, but... > > can we please stop saying "rebase"? > > > > That verb made sense when packaging was about a stack of patches and > > hacks. Nowadays maybe 90% of packages are just the upstream version, > > and another 9% have patches backported from git that will be dropped > > on the update to the next upstream version. Talking about a "rebase" > > is mostly confusing. > > Not really a defense, but this is what we call it internally for RHEL. > So even if we officially change the name, most of us are likely to keep > calling it rebase out of habit. I agree with you, Robbie. It'll hang around and we'll have to deal with it for a long time. However, even internally in RHEL we're starting to see "rebase" be really hard to understand. One team will mean "grab a new tarball that only contains a limited set of bug fixes" and another team will mean "grab an entirely new major version release that breaks ABI and on-disk format". We should honestly look at how to articulate these kinds of things better, both in Fedora and in RHEL. "Rebase" is quickly becoming meaningless. josh > (And it does make sense for RHEL where backporting more patches is the > norm. I'm uncomfortable with the assertion that ~99% of all packages > have no downstream-only packages, but that might just be my bias in the > opposite direction, since I maintain a couple that do.) > > Thanks, > --Robbie > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On Tue, Jan 5, 2021, at 3:19 PM, Florian Weimer wrote: > ... IMA seems to be pretty useless. This is a complex and highly nuanced topic because IMA is both a mechanism and a set of potential *policies* that one can use, and a whole lot depends on the exact policy in use. Like SELinux in that it's a highly flexible thing; and related to that because IMA isn't the default in any mainstream distribution (that I can think of) it ends up being a "secondary" mechanism. There have definitely been multiple cases in the past where SELinux policy stops a chain of compromise - a great example is https://seclists.org/oss-sec/2019/q1/119 (The ostree read-only bind mount over /usr also stopped it, a great example of defense-in-depth) And one can definitely construct scenarios where an enforced IMA policy like `ima_tcb` would stop a similar chain - in the case of that runc flaw the attacker wouldn't have access to the signing key and so couldn't write a new binary that could be executed by root. But an ima_tcb policy would also e.g. break tooling like Ansible which is all about copying dynamic Python code from a remote host and executing it as root. And really that's a root problem in all security systems like this: it's just really hard to usefully distinguish between "code injected by a compromised privileged process" and "change the admin wants to make to their own computer". I think the Change authors here trying to make it easier to enable IMA without the really awful hack of "boot up your installed system and run these shell scripts to sign", which is a laudable goal. Having pre-signed OS binaries would definitely help, but...in any kind of general case users are going to want to run code *not* from the distribution, so the tooling and docs need to generalize to user-owned keys. Also there's the inverse problem in that a lot of people will want to use IMA as a form of "application whitelisting" but there's...a lot of RPMs in Fedora. Less of a concern for RHEL at least. Anyways again I think a much more flexible user story is: "As a Fedora IoT user I want to provide a key to use for IMA signatures of the operating system (rpm-ostree) (and potentially container images, etc.) and have the first-boot process handle IMA signing for me and automatically apply this across upgrades too." The key would e.g. be stored in a TPM on device. A simple way to think of this is as a parallel with TPM-bound-LUKS (clevis) that we landed in Ignition - make it as easy as possible for admins to enable. Having pre-signed binaries isn't strictly necessary for that. The generalization of course of this is the model mentioned in the rpm-ostree issue where rather than doing signatures per-device you perform centralized image builds and seal /etc too, but as noted it's a rather large change in systems management (notable security benefits, breaks a lot of management tooling and greatly hampers one's ability to go in and test a change on a system). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: gpg-agents all over the place
Hello Roberto, - Original Message - > From: "Roberto Ragusa" > To: devel@lists.fedoraproject.org > Sent: Thursday, December 24, 2020 5:20:38 PM > Subject: Re: gpg-agents all over the place > > On 12/23/20 1:56 PM, Oron Peled wrote: > > > More problematic, but possible. > > > > The key is using "--pinentry-mode=loopback" (I don't have my scripts in > > front of me for further details) > There are simple use cases that are very problematic. > Consider this: > > [me@localhost tmp]$ date >date.txt > [me@localhost tmp]$ gpg --pinentry-mode=loopback -c date.txt ### this asks > for a passphrase > [me@localhost tmp]$ ls -l > total 8 > -rw-rw-r-- 1 me me 32 Dec 24 16:59 date.txt > -rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg > [me@localhost tmp]$ rm date.txt > [me@localhost tmp]$ gpg --pinentry-mode=loopback date.txt.gpg ### this does > not ask! > gpg: WARNING: no command supplied. Trying to guess what you mean ... > gpg: AES encrypted data > gpg: encrypted with 1 passphrase > [me@localhost tmp]$ ls -l > total 8 > -rw-rw-r-- 1 me me 32 Dec 24 17:00 date.txt > -rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg > > that would be a very simple tutorial about symmetric encryption and it is > absolutely surprising, since decryption happens without any need to supply > the passphrase. > Because an agent was forked and it remembers the symmetric > passphrase I've used! Crazy. > > So let's see if we can use --batch: using it on encryption conflicts with > pineentry, > using it on decryption doesn't disable the gpg-agent usage. > > We should try to avoid the agent, let's see in the man page: > --use-agent > --no-use-agent >This is dummy option. gpg always requires the agent. > Wow, the option you want, but with a dummy implementation. > > There is a --no-autostart, let's try it: more wasted time. > > The use case I care about is for a script that reads some data > from an encrypted file, asking me the passphrase when necessary. > Something like: > > token="$(gpg1 --output - secrets.gpg | grep ^token= | cut -d= -f2)" > # use $token > > The passphrase should not be hardcoded in the script or remembered by > a magic gpg-agent forked behind my back. > > My only solution has been: >dnf install gnupg1 did you try `--no-symkey-cache` option? It disables password caching during the session: # date > date.txt # gpg --pinentry-mode=loopback --no-symkey-cache -c date.txt gpg: directory '/root/.gnupg' created gpg: keybox '/root/.gnupg/pubring.kbx' created # gpg --pinentry-mode=loopback --no-symkey-cache date.txt.gpg gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: AES.CFB encrypted data gpg: encrypted with 1 passphrase gpg: decryption failed: Bad session key # gpg --pinentry-mode=loopback --no-symkey-cache date.txt.gpg gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: AES.CFB encrypted data gpg: encrypted with 1 passphrase gpg: decryption failed: Bad session key # gpg --pinentry-mode=loopback --no-symkey-cache date.txt.gpg gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: AES.CFB encrypted data gpg: encrypted with 1 passphrase File 'date.txt' exists. Overwrite? (y/N) N Enter new filename: date2.txt # diff date.txt date2.txt # rpm -q gnupg2 gnupg2-2.2.23-1.fc33.x86_64 Regards Jiri > > Regards. > > -- > Roberto Ragusamail at robertoragusa.it > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
HOWTO: Change default branch on pagure.io projects
Per https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main#Phase0_-_2021-01-05 here's a short guide for any interested folks on how to change the default branch in pagure.io projects: Switching default branch from ‘master’ to ‘main’ on pagure.io If you have an existing project using ‘master’ as it’s default branch: git clone ssh://g...@pagure.io/YOURPROJECT.git (This checks out your repo with it’s current ‘master’ branch) git checkout -b main (This creates a local ‘main’ branch) git push (This pushes the new ‘main’ branch to pagure.io) Go to your project, Settings, “Default Branch”, set to ‘main’, click “Make Default” (This switches the ‘default’ branch you get if you do not specify one) git push origin :master (This deletes the old ‘master’ branch) If you have are just creating a new project: When creating the project specify ‘main’ as the default branch. (This will be changed soon to default that way) Q&A: Q: What happens to pull-requests that are against the old ‘main’ branch? A: They will show an error, you will need to get the submitter to open a new pull-request against the new branch name (we will be fixing pagure so it allows updating the target branch of a PR in the (near) future) Q: I want to call the default branch something else, do I have to use ‘main’? A: main is becoming a industry wide name, so people are going to expect it. That said, it's your project and you can name it anything you like. Q: What happens to Documentation/Issues/Pull Requests repos associated to the projects? A: We are not changing anything on theses repos for now, we will update you when we change the default branch on these repos. Q: What happens to users who have a checkout of the old default branch? A: If they do a 'git pull' they will get: * [new branch] main -> origin/main Your configuration specifies to merge with the ref 'refs/heads/master' from the remote, but no such ref was fetched. They need to do 'git checkout main' and pull will work fine again. As a reminder, on 2021-01-06 (tomorrow), we will be changing the following pagure.io repos to use 'main' as default branch: 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 fedora-docs/* fedora-docs-i18n/* See https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main for more information. kevin signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: runtime dependencies not in Requires spec section
Kevin Kofler via devel wrote: > Rex Dieter wrote: >> It's a linked library, so *yes*, rpmbuild will add it. > > Depends on whether the application links directly to libQt5Svg.so.5 or > whether it uses it only through the plugin-based imageformats In this context, for the software/package in question, I verified that it links libQt5Svg.so.5 -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Mass spec file change: Adding BuildRequires: make
On 1/5/21 6:58 AM, Tom Stellard wrote:
On 11/30/20 2:06 PM, Tom Stellard wrote:
Hi,
As part of the f34 change request[1] for removing make from the
buildroot, I will be doing a mass update of packages[2] to add
BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your
packages on your own, please do so before Dec 14, which is when I will
begin doing the mass update.
I will be doing the updates in batches, so that if there is a mistake
the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages.
Dec 16: Next 1000.
Dec 18: Next 1000.
Jan 4: Next 1000.
Jan 5: Next 1000.
Here is the list of packages I'll be updating today:
https://fedorapeople.org/~tstellar/br_make_day5.txt
There were some issues reported with my update script, so I'm going to
take the day to test some changes rather than doing a mass update. The
problems that were reported are BuildRequires: make being added to
sub-packages and also inside of multi-line conditions like:
%{?enablefeature:
BuildRequires: foo
}
The main change I'm going to be making is to insert BuildRequires: make
before the first BuildRequires in the file instead of after the last.
This should avoid the issue with sub-packages and should also reduce the
number of manual changes I need to make. Currently, if the script sees
%endif anywhere near where BuildRequires: make was inserted, it will
skip making the change, and these conditionals seem to occur more
frequently at the end of the BuildRequires list than at the beginning.
-Tom
-Tom
Jan 6: Next 1000.
Jan 7: Next 1000.
Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass
rebuild (Jan 20).
Thanks,
Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
[2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
Ben Cotton wrote: > == Summary == > We want to add signatures to individual files that are part of shipped > RPMs. These signatures will use the Linux IMA (Integrity Measurement > Architecture) scheme, which means they can be used to enforce runtime > policies to ensure execution of only trusted files. > > == Owner == > * Name: [[User:Puiterwijk| Patrick Uiterwijk]] > * Email: puiterw...@redhat.com > * Name: [[User:Pbrobinson| Peter Robinson]] > * Email: pbrobin...@gmail.com I am opposed to this Change, because it increases the file size of all RPMs and the size of the RPM database (and hence, of all installed systems, including, but not limited to, the live images) to implement what basically amounts to "Treacherous Computing" [ https://www.gnu.org/philosophy/can-you-trust.en.html ]. Neither do I consider it acceptable to ban execution of non-centrally-signed binaries, nor do I consider it acceptable to bloat all our packages with per-file signatures that are ultimately redundant with the package signatures that already guarantee the integrity of all files in the package. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: HOWTO: Change default branch on pagure.io projects
Hi Kevin, thanks for the HOWTO. Some comments from trying it: > > git push > (This pushes the new ‘main’ branch to pagure.io) This should be: git push --set-upstream origin main > git push origin :master > (This deletes the old ‘master’ branch) git push origin :master remote: Branch deletion is not allowed remote: Denied push for ref 'refs/heads/master' for user '**' remote: All changes have been rejected Best regards Wolfgang ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Fedora-Cloud-33-20210106.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210105.0): ID: 752235 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/752235 ID: 752242 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/752242 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
