Re: Devtoolset for epel7 for build in Copr

Dne 23. 02. 22 v 19:22 Dmitry Butskoy napsal(a): Ben Beasley wrote: Yes, the devtoolsets work nicely if you supply the appropriate incantations. I haven’t tried in COPR specifically I've just tried and it seems that devtoolset are not available for epel7 builds in Copr. (For epel7, I

Re: More declarative RPMs

Dne 16. 02. 22 v 9:43 Aleksandra Fedorova napsal(a): doesn't say anything about scriptlets being discouraged: because we are far from using a word "discouraged". But yes, filetriggers and other similar methods should be prefered. Miroslav ___ devel

Re: More declarative RPMs

Dne 15. 02. 22 v 22:08 Matthew Kenigsberg napsal(a): It sounds like there's already some effort to make tasks in RPMs like adding users more declarative:https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/ Which is still not finished and you still need to call the old

Re: What has the PDC ever done for us?

Dne 18. 03. 22 v 8:26 Tomas Hrcka napsal(a): > distgit is basically pagure in it has a DB we were thinking about moving > package-specific data like EOL to in information already stored in the DB > for each repository. I cannot parse your sentence. Does it mean there is one

Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)

Dne 04. 04. 22 v 10:29 Peter Robinson napsal(a): How will this key be distributed on the distro filesystem or on the web? The pub keys will be both, I've added a paragraph to the detailed description. Please add it as TYPE 61 DNS record as well:

Re: Action Required: Bugzilla - API Authentication changes

Dne 01. 02. 22 v 12:37 Miro Hrončok napsal(a): Target Dates: https://bugzilla.stage.redhat.com - Mon 07th Feb 00:00 UTC https://bugzilla.redhat.com - Mon 28th Feb 00:00 UTC This is challenging. Especially when the support in python-bugzilla landed just few weeks ago. I would really expect

Re: CVE-2021-4034: why is pkexec still a thing?

Dne 27. 01. 22 v 0:18 Adam Williamson napsal(a): BTW, bonus follow-up to this: as part of researching the background of polkit, I noticed that we never actually entirely got done moving off usermode:( There are still over a dozen packages in the distro that require it: Moving off to where?

Re: CVE-2021-4034: why is pkexec still a thing?

Dne 31. 01. 22 v 20:39 Adam Williamson napsal(a): but very soon I discovered that documentation of PolicyKit is nearly non-existent. At least, it is not sufficient to do the migration. After reading the code I found that it is likely missing functionality of consolehelper. I had a discussion

Re: F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)

Dne 18. 01. 22 v 15:28 Ben Cotton napsal(a): ** Upgrade {{package|sddm}} to the latest snapshot and introduce mutually exclusive sddm-wayland-generic and sddm-x11 greeter configuration packages. ** Modify {{package|plasma-workspace}} to switch SDDM to Wayland *** Enable installation of the SDDM

Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

Dne 21. 01. 22 v 17:08 Roberto Sassu via devel napsal(a): (note for the infrastructure mailing list: please check if the changes I'm proposing could be tested in the Fedora infrastructure, like Copr) Copr does not use `rpmsign` at all. Copr uses `obs-sign` [1]. The benefits of obs-sign is that

Re: Bodhi 6.0: What's new

Dne 06. 04. 22 v 14:31 Aurelien Bompard napsal(a): * For other Fedora systems, we use Kerberos authentication, are there some plans to add it? Nope, there's no plan for that at the moment. FYI We recently added the Kerberos support to Copr cli. You can steal the code here:

Re: SPDX Statistics - Passenger pigeon edition

Dne 02. 09. 23 v 13:07 Zbigniew Jędrzejewski-Szmek napsal(a): "python-lit warning: valid as old and new and no changelong entry, please check" The License string is valid as both the old-style Fedora license and a SPDX expression, and the tooling did not match anything in the changelog that

Re: Automate your Fedora package maintenance using Packit

Dne 15. 09. 23 v 13:18 Ankur Sinha napsal(a): I guess it should be possible to make packit (or the-new-hotness?) run licensecheck on the new sources and include that in the PR comment too, perhaps also with a list of packages that depend on the one being updated as an "impact check"? It is

Re: SPDX Statistics - Voyager 2 edition

Dne 28. 08. 23 v 15:36 Richard Fontana napsal(a): As for + being valid SPDX syntax, can that be supported by fedora-license-validate or whatever the tool is called today? That's probably a good idea, though it would seem to be predicated on us documenting that any "allowed" license identifier

SPDX Statistics - Passenger pigeon edition

Two weeks ago we had: * 23030 spec files in Fedora * 29469license tags in all spec files * 16716 tags have not been converted to SPDX yet * 6149tags can be trivially converted using `license-fedora2spdx` * Progress: 43.28% ██ 100% ELN subset: 895 out of 2492 packages are not

Re: SPDX MIT license , what todo ?

Dne 08. 09. 23 v 2:39 Neal Gompa napsal(a): xdg-utils is a MIT License [1] what SPDX license have [2] ? if it is already a valid SPDX formula , what I should write on changelog ? Do nothing. This transition is a no-op for you. Nope. If he does nothing I will still report it in statistics as:

Re: SPDX MIT license , what todo ?

Dne 08. 09. 23 v 22:42 Sandro napsal(a): I believe, and Miroslav will correct me if I'm wrong, the script looks at the changelog and searches for SPDX. As long as there's a changelog entry, the package is considered migrated. However, if the License: tag value changes, it is recommended to

Re: Access superseded Fedora RPMs

Dne 08. 09. 23 v 21:58 Kai A. Hiller napsal(a): I’m trying to recreate – on the level of RPMs – a Fedora system as resolved by DNF at an earlier moment in time (think lockfile). Collecting a list of the installed RPMs and their versions for a given system is easily done via `dnf list

SPDX Statistics - Marco Polo edition

Two weeks ago we had: * 23128 spec files in Fedora * 29572license tags in all spec files * 16519 tags have not been converted to SPDX yet * 6059tags can be trivially converted using `license-fedora2spdx` * Progress: 44.14% ██ 100% ELN subset: 825 out of 2479 packages are not

Re: SPDX Statistics - Marco Polo edition

I forgot to add one important piece of news about rust packages: Because Fabio reported that all crates (rust-*) has been migrated. I added all rust-* packages that has "valid as SPDX but no changelog entry" to ignore list

Re: Execute RPM dependency generators on the .spec file which ships them

Dne 16. 10. 23 v 16:16 Vít Ondruch napsal(a): Can somebody help me please with a package review? The package can't be simpler. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2244428 Thx in advance Done. You are welcome. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT,

SPDX Statistics - Wichterle edition

Hot news: fedora-license data now includes machine readable field with known exceptions to use otherwise not-allowed exception https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/422 This  field is already exported to JSON and license-validate understand it: $

Re: OK to have same license file in multiple sub-packages?

Dne 31. 10. 23 v 18:21 Kalev Lember napsal(a): On Tue, Oct 31, 2023 at 5:47 PM Miroslav Suchý wrote: How it conflicts? %files %license LICENSE %files doc %license LICENSE should not create any conflicts. And this is recomended way to do it. I guess the conflicts

Re: OK to have same license file in multiple sub-packages?

Dne 31. 10. 23 v 16:10 Tom Stellard napsal(a): Hi, I've run into a problem with the cmake package, and I'm trying to figure out how to solve it.  This issue is that the cmake license files are included in both the cmake and cmake-doc packages.  This creates a conflict when up trying to update

Re: Intention to tighten RPM crypto-policy back

Dne 19. 09. 23 v 11:19 Alexander Sosedkin napsal(a): Because of that, I'd like to revert that RPM policy relaxation https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5 in (f39) rawhide and align RPM security with the rest of the policy.

SPDX Statistics - Munich Agreement edition

Hot news: we are over 50 %!!! With almost 4k license tags converted in past 2 weeks. How it was possible? First - it is because you rocks and really lots of work has been done. Both on our (Change owners) side and on you as package maintainers. But the biggest impact was migration of texlive

Re: SPDX Statistics - Munich Agreement edition

Dne 03. 10. 23 v 9:31 John Reiser napsal(a): Especially because texlive was such an outlier, then any linear estimate should state the starting and ending dates that were used for the projection. https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit#gid=0

Re: Specify koji build machine mem req via. spec file

Dne 04. 10. 23 v 11:43 Martin Stransky napsal(a): Hello guys, Is there's a way how to set requested amount of ram for koji builders? I'd like to use it as Firefox builds fail recently due low memory, like https://bugzilla.redhat.com/show_bug.cgi?id=2241690 Thanks, Martin Related - rpm has

Re: How to deal with COPR and RPMAutoSpec

Dne 18. 10. 23 v 16:12 Diego Herrera napsal(a): What I usually do when I need for COPR to handle rpmautospec is to set the source type to "Custom", and use the following script: #! /bin/sh -x git clone cd spectool -g rpmautospec process-distgit Set the Buildroot dependencies to "git

SPDX Statistics - Miracle of the Sun edition

Hot news: There was new release of SPDX License list. If you want to see impact of Fedora work you can check number of new licenses in recent releases and compare https://github.com/spdx/license-list-XML/releases and compare it with content of the releases before we started migrating

Re: Mock v5.0 released (and mock-core-configs v39)

Dne 14. 08. 23 v 21:30 Michael J Gruber napsal(a): Is this supposed to work now? With mock-5.0-1.fc38.noarch and after scrubbing, the image is pulled but then not used because it is "not marked ready" (rawhide, f39, f38). Am I holding it wrong? 1) When image is not marked ready then it is

Heads up: merging SPDX related PRs

Over the time we had several workshops about SPDX. Some people did the SPDX migrations for others (me included). Some of the PR are not merged yet. E.g. https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/251 https://src.fedoraproject.org/rpms/anaconda-user-help/pull-request/2

SPDX Statistics - Voyager 2 edition

tl;dr summary - we are slowing down again, huge progress with adding new licenses Two weeks ago we had: * 22983 spec files in Fedora * 29406license tags in all spec files * 16915 tags have not been converted to SPDX yet * 6242tags can be trivially converted using `license-fedora2spdx` *

Re: Heads up: merging SPDX related PRs

Dne 21. 08. 23 v 10:32 Florian Weimer napsal(a): Over the time we had several workshops about SPDX. Some people did the SPDX migrations for others (me included). Some of the PR are not merged yet. E.g. https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/251 The License: field

Re: SPDX Statistics - Voyager 2 edition

Dne 22. 08. 23 v 1:08 Fabio Valentini napsal(a): On Sun, Aug 20, 2023 at 9:11 AM Miroslav Suchý wrote: New projection when we will be finished is 2025-01-11 (we are slowing down. Again. :( ). Pure linear approximation. It might not be as bad as you think! All rust-* packages had been

Re: SPDX Statistics - Voyager 2 edition

Dne 22. 08. 23 v 21:05 Fabio Valentini napsal(a): There's four packages that use "MPL-2.0+" which is not a valid SPDX identifier. Not sure what to do about them, since I don't want to ignore upstream license specification and change them to just "MPL-2.0". I checked the sized-chunks

Re: SPDX Statistics - Voyager 2 edition

Dne 22. 08. 23 v 22:55 Richard Fontana napsal(a): The use of `+` is documented at https://spdx.github.io/spdx-spec/v2-draft/SPDX-license-expressions/ (there's probably a more recent version) D.3 Simple license expressions A simple is composed one of the following: An SPDX License List Short

Donate 1 minute of your time to test upgrades from F38 to F39

Do you want to make Fedora 39 better? Please spend 1 minute of your time and try to run: # Run this only if you use default Fedora modules # next time you run any DNF command default modules will be enabled again sudo dnf module reset '*' dnf --releasever=39

Re: SPDX Statistics - Voyager 2 edition

Dne 23. 08. 23 v 21:39 Richard Fontana napsal(a): We are only treating the *GPL family differently because of SPDX's (possibly unfortunate) decision to do the same. But technically |    GPL-2.0-or-later+ | |is a valid SPDX string. Right? | -- Miroslav Suchy, RHCA Red Hat, Manager, Packit

Re: Heads up: merging SPDX related PRs

Dne 23. 08. 23 v 12:44 Sandro napsal(a): On 20-08-2023 12:19, Miroslav Suchý wrote: If you are workshop participant and have PR opened for longer than 14 days then let me know and I will merge it. Here's the one I made during Flock workshop: https://src.fedoraproject.org/rpms/90-Second

Re: F38 Change: Major upgrade of Microdnf (Self-Contained Change proposal)

Dne 20. 04. 22 v 8:55 Jaroslav Mracek napsal(a): I've gotta ask... How much memory does the new dnf daemon take while idle? We do not have any measurements right now. Please feel free to test it. We have a repository with DNF5/Microdnf nightly builds -

Re: A way to prepare custom source tarballs from .spec file to improve CI experience

Dne 21. 04. 22 v 13:20 Vít Ondruch napsal(a): Now I am looking for feedback about general approach. Of course it could be somehow polished and improved to hide some boiler plate. This part: %{echo:%( [ ! -e %{S:1} ] && Looks really clumsy. After reading the

Re: A way to prepare custom source tarballs from .spec file to improve CI experience

Dne 25. 04. 22 v 10:41 Vít Ondruch napsal(a): 1) Standalone script is kind of against RPM philosophy, where the idea always was that the .spec file should contain everything. We already have signature of source files as additional source. But the additional section as suggested by Marián

SPDX Statistics - Kristallnacht edition

Hot news: Robert-Andre Mauchin packaged python-spdx-tools for Fedora. For scancode-toolkit - all dependencies are finally reviewed and present in Fedora, scancode-toolkit is in the middle of review. Big thanks to Robert and everybody who did the package reviews. The process of adding the

Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)

Dne 17. 05. 22 v 17:01 Miro Hrončok napsal(a): Is this going to be part of phase 1? Could you please explicitly say that in the change proposal? No, it is not part of phase 1. Sorry for the confusion. I meant, yes we will do the automatic conversion one day. But according to current plan,

Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)

Dne 17. 05. 22 v 16:38 Vitaly Zaitsev via devel napsal(a): But I think this change also requires automatic conversion of all available SPECs, because manual conversion will take years. We will do automatic conversion (openning PR) when the conversion can be done automatically. But there are

Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)

Dne 17. 05. 22 v 16:18 Miro Hrončok napsal(a): So, is it actually allowed to use SPDX identifiers when this phase is activated, or not? SPDX identifiers will be allowed when all these conditions will be met: * Change approved by FESCO * after F38 branching * documentation with conversion

Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)

Dne 17. 05. 22 v 16:59 Miro Hrončok napsal(a): Thanks for the explanation. Could this be explicitly written in the change proposal? Yes. I will amend the proposal with FAQ posted in this thread. Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and

Re: How much free space in /var is required for upgrades?

Dne 13. 05. 22 v 20:54 Jason L Tibbitts III napsal(a): 3) Is there any better way to handle a lack of space in /var during an RPM transaction? I very often mount /var/cache/dnf as tmpfs as servers have more memory/swap than rootfs. 4) Can we estimate how large the file will grow, and refuse

Re: SPDX identifiers in old branches?

Dne 25. 05. 22 v 14:40 Daniel P. Berrangé napsal(a): E, please no. Apps need to know whether a given RPM is using SPDX or not, independantly of whether they have Fedora git source history available. We just need to record this fact in the specfile explicitly, so it is available both to

remove-retired-packages feedback

If you already upgraded to Fedora 36 - what is your feedback about https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/sysadmin/System_Utilities/#remove-retired-packages Did you run the command `remove-retired-packages`? Do you find it useful? Comments and ideas are welcome either

SPDX identifiers in old branches?

As reaction to   https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1 there were two similar feedbacks: * maintainer of package wants to use SPDX in both new and old branches (including f36, epel7...) * Bodhi cannot recognize old short names in old branches and new SPDX formulas in

Re: SPDX identifiers in old branches?

Dne 25. 05. 22 v 6:28 Gary Buhrmaster napsal(a): I interpreted the proposal as adding a new stanza SPDX: in addition to License: which requires changing the definition Nope. No new tag. We will use the old License tag. Just instead of   License: $short_name will be   License: $spdx And

Re: SPDX identifiers in old branches?

Dne 25. 05. 22 v 2:44 Miro Hrončok napsal(a): 2) There are tags that might mean slightly different things in each notation. E.g. MIT. Is this package licensed with the SPDX MIT? Or is it a old-style MIT that might mean different SPDX notation? Note that the old-style MIT seems to be a superset

Re: [RFC] Build tag in RPM: from NVR to NVRB

Dne 23. 06. 22 v 14:24 Aleksandra Fedorova napsal(a): 1) An user rebuilds a package from Fedora dist-git in local mock, what will be the value of the build tag? How will the local build sort over the official Fedora builds? Afaik currently, if you do a local build, you need to bump an NVR to

Re: Can we start changing License to SPDX now?

Dne 29. 06. 22 v 9:47 Zbigniew Jędrzejewski-Szmek napsal(a): Or should we wait until updating to SPDX identifiers? That's my understanding. The plan is to not treat the wiki as the authoritative source, but instead to generate a

Re: F37 proposal: Linux Firmware Minimization (late System-Wide Change proposal)

Dne 01. 07. 22 v 19:54 Ben Cotton napsal(a): == Detailed Description == The `linux-firmware` RPM is very large (175M src.rpm, 287M *.noarch.rpm per 20211027-126) that bundles most of the system firmware loaded by the kernel, regardless of whether it’s actually needed. Some additional firmwares

Re: F37 proposal: Preset All Systemd Units on First Boot (Self-Contained Change proposal)

Dne 06. 07. 22 v 20:13 Ben Cotton napsal(a): https://fedoraproject.org/wiki/Changes/Preset_All_Systemd_Units_on_First_Boot This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only

Re: proposal idea: EOL notifications

Dne 08. 07. 22 v 4:59 Stewart Smith via devel napsal(a): Another - what do we do about, e.g., Fedora IoT and Fedora CoreOS, which have their own somewhat different release/life cycles? What about module lifecycles? What is it about*lifecycles* that's important, anyway? Don't we maybe want to

Golang

I have been asked to add support for Go external dependencies to Mock   https://github.com/rpm-software-management/mock/issues/919 I tried to get the information from https://developer.fedoraproject.org/tech/languages/go/go-packages.html However, the information there seems to be outdated.

Re: Fedora Copr - EPEL-9 buildroot

Dne 09. 06. 22 v 21:37 Neal Gompa napsal(a): In addition, trying to do a build with the proper CentOS 9 Stream repository also fails - as the moce config used there is the plain centos-stream-9-x86_64, not the '+epel' variant used in EPEL-9. I do understand this last issue (CentOS 9 Stream

fedora-obsolete-packages for arch specific issues

We have specific issues during an Fedora upgrade. In past, it was issue with rdma-core [1] during upgrade to F34. Nowadays, for upgrade to F36, we have an issue with lilv [2] [1] https://bugzilla.redhat.com/show_bug.cgi?id=1919864 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2052588 Both

Re: A way to prepare custom source tarballs from .spec file to improve CI experience

Dne 26. 04. 22 v 12:40 Vít Ondruch napsal(a): Dne 25. 04. 22 v 10:41 Vít Ondruch napsal(a): We already have signature of source files as additional source. Do you mean the 'sources' file? I mean https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_signatures Miroslav

Re: Fedora 36 Release Notes, do we have some?

Dne 10. 05. 22 v 11:40 Peter Boy napsal(a): Additionally, as fas as I see, docs team has no ==contentwise== workflow either (and can’t provide one because it doesn’t govern the process). There is a technical workflow, though, to ensure there is a file to be the next release notes and a way to

Re: Important changes to software license information in Fedora packages (SPDX and more!)

Dne 02. 08. 22 v 10:24 Florian Weimer napsal(a): * Richard Fontana: Looks like the License: field is limited to 70 characters if I am reading this correctly: https://github.com/rpm-software-management/rpm/blob/2b5b271b0e013c1b023df7f5775a59cb4078d5f5/docs/manual/spec.md#license I don't think

Re: rpmlint and SPDX licenses: W: invalid-license BSD-3-Clause

Dne 31. 08. 22 v 11:50 Miro Hrončok napsal(a): Hello license folks. I see that Fedora's rpmlint is yet to be taught to understand SPDX: python3-lxml.x86_64: W: invalid-license BSD-3-Clause python3-lxml.x86_64: W: invalid-license MIT-CMU Is this support tracked somewhere? I know openSUSE

Donate 1 minute of your time to test upgrades from F36 to F37

Do you want to make Fedora 37 better? Please spend 1 minute of your time and try to run: # Run this only if you use default Fedora modules # next time you run any DNF command default modules will be enabled again sudo dnf module reset '*' dnf --releasever=37

Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)

Quick heads up where we are: * people started voluntary migrating the identifiers to SPDX. When the license is not on our list, you can open issue or even merge request here: https://gitlab.com/fedora/legal/fedora-license-data Richard and Jilayne are doing awesome work reviewing the license

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

Dne 12. 10. 22 v 17:02 Mattia Verga via devel napsal(a): My guess is that dnf5 is an entirely different beast than dnf. dnf was written in python, dnf5 is written in C (?), so it's not just a major version upgrade. It is different beast for developers and author of plugins. Otherwise 1) it has

Re: Propositions to improve the documentation

Dne 12. 10. 22 v 12:03 Sébastien Le Roux napsal(a): Dear All, I joined the packaging team recently, or should I say I joined the mailing list, since for the rest I am still looking for a sponsor and all that ... anyway I want to share few ideas with you ... In my first messages I highlighted

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

Dne 12. 10. 22 v 12:28 Vít Ondruch napsal(a): So since I don't think the DNF5 name and especially the package name was elaborated here and my wish in package review to have the package name just `dnf` was completely ignored [1], I'll ask here. Why `dnf5` and not `dnf` version 5. If it is not

Re: Copr delete-by-default expiration policy still unacceptable

Dne 13. 10. 22 v 6:12 Kevin Kofler via devel napsal(a): I am really angry at Copr's expiration policy once again. It looks like I missed the deadline to renew the expired chroots (I still do not get any notification mails, they end up eaten in a spam filter somewhere), so once again a lot of

Re: Copr delete-by-default expiration policy still unacceptable

Dne 13. 10. 22 v 15:27 Stephen Smoogen napsal(a): The problem is that they HAVE been running out of disk space quite regularly. This is not a new problem as COPR has bounced off of zero storage over time as various 'newer' hardware is moved over for their usage. Currently, the storage they are

Re: Copr delete-by-default expiration policy still unacceptable

Dne 13. 10. 22 v 14:41 Kevin Kofler via devel napsal(a): At least allow the opt-out per maintainer. I would suggest to add the permanent opt-out checkbox, mark it "(BETA)", and then evaluate how many maintainers actually check that checkbox and how much resource usage is actually caused by it.

Re: Copr delete-by-default expiration policy still unacceptable

Dne 13. 10. 22 v 16:24 Josh Boyer napsal(a): Would you be willing to pay for that feature? BTW I have been seriously probing for some time whether people would be willing to pay for private repositories. And this is my first time mentioning it in public space :) Miroslav

Re: Copr delete-by-default expiration policy still unacceptable

Dne 13. 10. 22 v 17:18 PGNet Dev napsal(a): Another option is to get the containerized COPR efforts polished & available.  Then, any/all could spin them up easily (aka, far easier than now), and deploy locally, &/or make available ... and, charge some reasonable fee for those downloads.

Re: Copr delete-by-default expiration policy still unacceptable

Dne 13. 10. 22 v 17:06 Neal Gompa napsal(a): Considering services like packagecloud.io and others exist and do manage to make money storing repositories and builds, I think it's pretty workable for COPR too. It would require some advertising and such to get it out there, but it'd be workable.

Re: Process to remove "abandoned" packages?

Dne 09. 08. 22 v 12:20 Vít Ondruch napsal(a): However, if I really wanted to do this, I'd need to ask Mo, possibly use unresponsive maintainer policy. But that is too much hassle, so I'll probably leave it alone. Seems to me like similar process to what you suggests. The timeout will be

SPDX Statistics - Christmas edition

2 weeks ago we had: 23148 spec files in Fedora > 29121 license tags in all spec files > 24483 tags have not been converted to SPDX yet > 10099 tags can be trivially converted using `license-fedora2spdx` Today we have * 23184 spec files in Fedora * 29200 license tags in all spec files *

Copr - look back at 2022

Let me sum up what the Copr team did during 2022. The review of 2021 can be found at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/R2MWYN7CRF34WKSRUUYNLAISQB47MHXI/

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

Dne 02. 01. 23 v 22:01 Richard Shaw napsal(a): Also mock builds seem fine. I tested this now on F37 with a few different scenarios: - fedpkg mockbuild - git commit --allow-empty -m Rebuild && fedpkg mockbuild - fedpkg srpm && mock *.src.rpm seem to generate the expected

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

Dne 10. 01. 23 v 9:29 Vitaly Zaitsev via devel napsal(a): On 10/01/2023 08:16, Zbigniew Jędrzejewski-Szmek wrote: If rpmautospec is used in COPR, and the build is started in a compatible way, the release field should be the same as in koji. Steps to reproduce: 1. Create a new COPR project.

Re: Change Proposal: replace dnf with dnf5

Dne 10. 01. 23 v 23:44 Richard W.M. Jones napsal(a): On Tue, Jan 10, 2023 at 02:13:37PM -0500, David Cantrell wrote: https://pagure.io/fesco/issue/2870 https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5 This change proposal has been under discussion and revision for a while. A lot of

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

Dne 02. 01. 23 v 22:39 Otto Liljalaakso napsal(a): Also, 'mock --buildsrpm' will not convert them. Perhaps Vitaly meant mock should support such usage? Mock cannot add such support, because Mock rarely operate on top of dist-git (or even git). So there is no way how to retrieve git log.

License change - python-flask-whooshee

The package python-flask-whooshee changed license from GPLv2+ to BSD-3-Clause. The change actually happened in upstream after version 0.3.0 (and we have now 0.8.2). Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send

SPDX Statistics - Malanka edition

Two weeks ago we had: * 23184 spec files in Fedora * 29200 license tags in all spec files * 23682 tags have not been converted to SPDX yet * 9377 tags can be trivially converted using `license-fedora2spdx` Today we have: * 23030 spec files in Fedora * 29390 license tags in all spec files

SPDX Office hours

Hello. the owners of SPDX Change proposal want to have this Change as smooth as possible. And we decided to setup Office hours. Do you have any questions about SPDX migration? Do you hesitate about what steps you should take? How to proceed with your package? We will do our best to help you.

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a): produces bogus changelog messages and artificially inflates Release counters. I always wondered why people are afraid of gaps in numbering? It is just a number. The number will not object if you skip some of them. :) Or it is

Re: Inactive packagers to be removed after the F37 release

Dne 28. 11. 22 v 19:20 Mattia Verga via devel napsal(a): - rpms/python-copr-common - rpms/python-flask-whooshee Taken. M. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: SPDX Statistics

Dne 06. 12. 22 v 13:01 Michael J Gruber napsal(a): Can I put the new tags in the same macro, e.g.: ``` %global foundry ADF -%global fontlicense GPLv2+ with exceptions +%global fontlicense GPL-2.0-or-later WITH Font-exception-2.0 Yes please. Miroslav

Re: Small rant: installer environment size

Dne 08. 12. 22 v 13:58 Peter Robinson napsal(a): Ideas on how to solve that problem welcome. Do we need - at install time - firmware for: * v4l * dvb * cameras ? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email

Re: Small rant: installer environment size

Dne 08. 12. 22 v 17:52 Adam Williamson napsal(a): No, and we're looking at splitting those out, but the fact is they are a tiny amount of the overall firmware collection. You could even argue either way for something like bluetooth due to it sometimes being used by keyboards. We actually

Re: Small rant: installer environment size

Dne 08. 12. 22 v 19:33 Adam Williamson napsal(a): On that note, /usr/share/doc, /usr/share/man, and /usr/share/info could be removed from the installer image if they are present. That likely won't free a whole lot of space, but it's not nothing. All of those are already stripped:

Orphaned python-gzipstream

Hi. I have just orphaned python-gzipstream. https://src.fedoraproject.org/rpms/python-gzipstream If you want to keep it running then feel free to take it. I have not used this library for ages. This was part of Spacewalk project

Re: SPDX Statistics - Advent edition

Dne 16. 12. 22 v 15:59 Richard Shaw napsal(a): I appreciate the effort so I hate to ask, but can we get a similar list but grouped by maintainer? I don't have a lot of free time these days and it would make my life easier :) I can write it on my TODO list. At the same time - this is for sure

SPDX Statistics - Advent edition

16 days ago we had: 23084 spec files in Fedora > 29041 license tags in all spec files 24865 tags have not been converted to SPDX yet - it is much higher compared to previous run because last time my script actually counted packages instead of tags. > 10325 tags can be trivially converted

Re: copr and centos9 ?

Dne 21. 12. 22 v 16:14 Mark Olesen via devel napsal(a): I'm using copr for https://copr.fedorainfracloud.org/coprs/openfoam/openfoam/ and now finally also enabled for building on epel9 and centos-stream-9 (both x86_64). With the centos-stream-9 I get these messages: Updating Subscription

Re: SPDX Statistics

Dne 01. 12. 22 v 16:43 Tomasz Torcz napsal(a): What does this warning mean? ladvd warning: valid as old and new and no changelong entry, please check Hmm, let me look. The ladvd license is ICS https://src.fedoraproject.org/rpms/ladvd/blob/rawhide/f/ladvd.spec#_10 and both

Re: Should the policy documents better reflect real package maintenance practice?

Dne 24. 11. 22 v 9:52 Vít Ondruch napsal(a): I think that the documentation is right and should be honored. For the audience - the documentation is here: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#philosophy Updates in stable should be exception, if there really is no other

SPDX Statistics

3 weeks ago it was: 1. As of 2022-10-27: 1. There are 23302 spec files in Fedora 2. 264 mentions "SPDX" in the spec changelog 3. out of the remaining, 173 packages mention "SPDX" in dist-git log 4. 22865 packages need to be migrated

<    3   4   5   6   7   8   9   10   11   >