Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

Dne 06. 05. 24 v 1:56 odp. Florian Festi napsal(a): RPM has deprecated the %patchN syntax in favor of %patch -PN where N is the patch number for a year now. See the RPM documentation for more information [1]. In current RPM versions, this syntax only emits a deprecation warning, but support for

Re: SPDX Statistics - L'Aigle meteorite edition

Dne 03. 05. 24 v 10:44 dop. Tim Landscheidt napsal(a): Maybe I misunderstood the original post, but I did not per- ceive the intent of the data's publication to be informative and useful, but to motivate (converting the licenses). This. And to provide at least some estimates. When we started

Re: SPDX Statistics - L'Aigle meteorite edition

Dne 03. 05. 24 v 1:59 dop. Gary Buhrmaster napsal(a): Joking aside, I do agree the non-trivial conversions are likely to be the hard ones, and there will be a very long tail (many years more) for 100% as the work to deal with some of those hard ones may require expertise that is in limited or

Re: Files missing in RPM database

Dne 01. 05. 24 v 7:20 odp. Christoph Karl via devel napsal(a): *) Removal or Upgrade of RPMs/distribution should not left files behind. Two cases where files are intentionaly left behind: 1) configuration files This can be handled by:   rpmconf --all --conf 2) %ghost files - usually log

Re: Non-responsive maintainer check for lkundrak

Dne 30. 04. 24 v 12:25 odp. Tomi Lähteenmäki napsal(a): Hi, I'm trying to reach the maintainer of phosh [1] and phoc [2]. Allan has tried to reach out for him without success [3] so I created bug [4] for this non-responsive maintainer check. If someone knows how to contact him, please let me

SPDX Statistics - L'Aigle meteorite edition

Hot news:    Automated migration of "trivial" conversions is in process. I migrated bunch of licenses that are only seldomly used. The bigger group (GPL*) are waiting at the starting line, but Jilayne asked me to wait a moment as she wants to check few things. I expect that the progress

Re: [SPDX] Mass license change ASL 1.0 to Apache-1.0

Dne 14. 04. 24 v 4:53 odp. Miroslav Suchý napsal(a): I am going to do the mass change of the license from ASL 1.0 to Apache-1.0 Done -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel

Re: [SPDX] Mass license change AGPLv3+ to AGPL-3.0-or-later

Dne 12. 04. 24 v 11:22 dop. Miroslav Suchý napsal(a): I am going to do the mass change of the license from AGPLv3+ to AGPL-3.0-or-later Done -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list

Re: [SPDX] Mass license change Artistic 2.0 to Artistic-2.0

Dne 11. 04. 24 v 1:04 odp. Miroslav Suchý napsal(a): I am going to do the mass change of the license from Artistic 2.0 to Artistic-2.0 Done -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

Dne 17. 04. 24 v 9:20 dop. Zbigniew Jędrzejewski-Szmek napsal(a): By adding this functionality to Mock itself. It can be optional (--add-determinism). And then Mock can call   add-determinism $chroot/%buildroot/ I don't think we should make this particular functionality special. We have a

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

Dne 16. 04. 24 v 10:04 odp. Zbigniew Jędrzejewski-Szmek napsal(a): Hmm, how would that work? We call mock, which calls systemd-nspawn, which runs rpmbuild, and the build env is completely isolated from the host. By adding this functionality to Mock itself. It can be optional

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

Dne 13. 04. 24 v 1:16 odp. Zbigniew Jędrzejewski-Szmek napsal(a): The proposal explicitly states that we don't want Perl in all buildroots. How many seconds we save by NOT pulling Perl? Per each build? In total for whole release cycle? How many seconds we loose (lost) by refactoring the

Re: [SPDX] Mass license change OSL 2.0, ERPL, EU Datagrid, SPL

Dne 08. 04. 24 v 8:23 dop. Miroslav Suchý napsal(a): Hi. I am going to do the mass change of the license from OSL 2.0 to OSL-2.0 The proposed diff is in attachment. Affected package: dirvish Change from ERPL to ErlPL-1.1 Affected packages: erlang-gen_leader erlang-p1_pgsql Change from

[SPDX] Mass license change ASL 1.0 to Apache-1.0

: http://cronolog.org/download/%{name}-%{version}.tar.gz BuildRequires: gcc @@ -46,6 +46,9 @@ %{_infodir}/* %changelog +* Sun Apr 14 2024 Miroslav Suchý - 1.6.2-40 +- convert license to SPDX + * Wed Jan 24 2024 Fedora Release Engineering - 1.6.2-39 - Rebuilt for https

Re: [SPDX] Mass license change ZPLv2.1 to ZPL-2.1

Dne 06. 04. 24 v 10:00 odp. Miroslav Suchý napsal(a): Hi. I am going to do the mass change of the license from ZPLv2.1 to ZPL-2.1 Done -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list

Re: [SPDX] Mass license change MPLv2.0 to MPL-2.0

Dne 06. 04. 24 v 10:14 dop. Miroslav Suchý napsal(a): I am going to do the mass change of the license from MPLv2.0 to MPL-2.0 Done. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel

[SPDX] Mass license change AGPLv3+ to AGPL-3.0-or-later

:https://sourceforge.net/projects/conspy/ Source0:https://sourceforge.net/projects/conspy/files/%{name}-%{version}-1/%{name}-%{version}.tar.gz @@ -40,6 +40,9 @@ %{_bindir}/%{name} %changelog +* Fri Apr 12 2024 Miroslav Suchý - 1.14-14 +- convert license to SPDX + * Wed Jan 24 2024 Fedora

Re: [SPDX] Mass license change EUPL 1.2 to EUPL-1.2

Dne 05. 04. 24 v 10:49 dop. Miroslav Suchý napsal(a): Hi. I am going to do the mass change of the license from EUPL 1.2 to EUPL-1.2. The proposed diff is in attachment. Affected packages: AusweisApp2 rust-tpm2-policy dbus-parsec Unless somebody stop me, I will do this change directly

SPDX Statistics - Human Space Flight edition

Hot news: https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ contains usage column for licenses that are allowed for something (documentation, firmware...)    Automated migration of "trivial" conversions have started (see other threads in this mailing list). Two weeks ago we had:

[SPDX] Mass license change Artistic 2.0 to Artistic-2.0

(-,news,news) %{_datadir}/news/bin/filter/filter_innd.pl %changelog +* Thu Apr 11 2024 Miroslav Suchý - 20020501-32 +- convert license to SPDX + * Wed Jan 24 2024 Fedora Release Engineering - 20020501-31 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild diff -Naur rpm

Re: convert everything to rpmautospec?

Dne 08. 04. 24 v 2:55 odp. Emmanuel Seyman napsal(a): FTR, I have no idea what "salami tactics" is. https://en.wikipedia.org/wiki/Salami_slicing_tactics Something that would be unacceptable to be done in one step is possible when you do that in tiny steps. You cannot eat whole salami, but

Re: convert everything to rpmautospec?

Dne 07. 04. 24 v 5:15 odp. Zbigniew Jędrzejewski-Szmek napsal(a): I think it's time to switch to rpmautospec completely. -1 from me. While I enjoy simplicity of rpmautospec in some of my packages. I have bunch of packages where the spec is present also in upstream and the package is build

[SPDX] Mass license change ZPLv2.1 to ZPL-2.1

} -License:ZPLv2.1 +Release:7%{?dist} +License:ZPL-2.1 Summary:Library for writing Nagios (Icinga) plugins URL:https://nagiosplugin.readthedocs.io @@ -57,6 +57,9 @@ %{python3_sitelib}/nagiosplugin/ %changelog +* Sat Apr 06 2024 Miroslav Suchý - 1.3.3

[SPDX] Mass license change MPLv2.0 to MPL-2.0

+License: MPL-2.0 URL: https://github.com/%{upstream}/%{realname} VCS: scm:git:https://github.com/%{upstream}/%{realname}.git Source0: https://github.com/%{upstream}/%{realname}/archive/%{version}/%{realname}-%{version}.tar.gz @@ -59,6 +59,9 @@ %changelog +* Sat Apr 6 2024 Miroslav Suchý

[SPDX] Mass license change EUPL 1.2 to EUPL-1.2

+* Fri Apr 05 2024 Miroslav Suchý - 0.4.0-8 +- convert license to SPDX + * Wed Jan 24 2024 Fedora Release Engineering - 0.4.0-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild diff -Naur rpm-specs.orig/rust-tpm2-policy.spec rpm-specs/rust-tpm2-policy.spec --- rpm-specs.orig/rust

Re: [SPDX] Mass license change: Intro and change of "Bitstream Vera" to "Bitstream-Vera"

Dne 28. 03. 24 v 12:40 odp. Miroslav Suchý napsal(a): I will do the change only for: ./bitstream-vera-fonts.spec:License: Bitstream Vera ./bpg-fonts.spec:License:   Bitstream Vera ./bpg-fonts.spec:License:   Bitstream Vera ./bpg-fonts.spec:License:   Bitstream Vera ./bpg

Re: Three steps we could take to make supply chain attacks a bit harder

Dne 01. 04. 24 v 3:16 dop. Kilian Hanich via devel napsal(a): Also, I have seen build setups which encode the status of tests in the eventual binary and as such info page or integrated bug report generators. Often because some distros sometimes turned them off or ships software even with failed

Re: Three steps we could take to make supply chain attacks a bit harder

Dne 31. 03. 24 v 10:58 dop. Adam Williamson napsal(a): 1. Westill don't have compulsory 2FA for Fedora packagers. We *still don't have compulsory 2FA for Fedora packagers*. *WE STILL DON'T HAVE COMPULSORY 2FA FOR FEDORA PACKAGERS*. Fair enough. Let's do something about it:

Re: Three steps we could take to make supply chain attacks a bit harder

Dne 30. 03. 24 v 10:37 dop. Richard W.M. Jones napsal(a): I'm not pretending these will solve everything, but they should make attacks a little harder in future. 4) Fetch build artifacts before executing tests https://github.com/rpm-software-management/mock/issues/1352 (3) We should have a

Re: Three steps we could take to make supply chain attacks a bit harder

Dne 30. 03. 24 v 1:25 odp. Chris Adams napsal(a): Using a signed tarball is ideally better than a git tag (it's an extra level of author attestation). In this case signed tarball would not help at all. And git-tag would prevent this attack. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit

SPDX Statistics - Comenius edition

Hot news:     The last phase https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4 has been approved with FESCO. Two weeks ago we had: * 23821spec files in Fedora * 30463license tags in all spec files * 11091 tags have not been converted to SPDX yet * 4996 tags can be trivially

Re: [SPDX] Mass license change: Intro and change of "Bitstream Vera" to "Bitstream-Vera"

Dne 28. 03. 24 v 10:59 dop. Zbigniew Jędrzejewski-Szmek napsal(a): I also think the conversion should only be done if the full License string can be converted. Partial conversion is confusing, and there is not much value, since trivial conversion is, well, trivial, and whoever will eventually

Re: [SPDX] Mass license change: Intro and change of "Bitstream Vera" to "Bitstream-Vera"

Dne 26. 03. 24 v 6:00 odp. Artur Frenszek-Iwicki napsal(a): If we're going to introduce any kind of (semi-)automatic conversion of existing license tags, I think it'd be good to make "convert «and» and «or» to upper-case" part of the process. A.FI.

[SPDX] Mass license change: Intro and change of "Bitstream Vera" to "Bitstream-Vera"

Hi. The last phase of SPDX migration has been approved    https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4 Part of this change is automatic changes of "trivial" changes. Let's do a step back and state loudly what is and what is not trivial change: By trivial we understand change

Obsoleted packages in F40

I just upgraded my workstation to F40 and it surprised how many packages were reported by `remove-retired-packages`. There was lots of orphaned packages - there is nothing to do about them. But there was lot of packages that were removed intentionally. See the list at the end of my email. I

Re: Introduction and package submission question

Dne 24. 03. 24 v 12:32 dop. None via devel napsal(a): Hello everyone! My name is Jonathon Hyde, and I want to become a packager for Fedora. I'm excited to contribute back something to a project that I have been using for so long. I haven't made my first package submission yet, but I wanted

Re: SPDX Statistics - Book Smugglers edition

Dne 21. 03. 24 v 19:47 kloc...@fedoraproject.org napsal(a): Those trivial substs probably would cover +90% of all packages in time in my estimation. See https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit#gid=0 The "trivial" conversion is possible for

Re: SPDX Statistics - Book Smugglers edition

Dne 20. 03. 24 v 15:20 Fabio Valentini napsal(a): Migrating the License tag from Callaway to SPDX identifiers is only the "easy" part of the transition. Re-reviewing package contents and re-classifying licenses is the non-trivial part, and that definitely can't be scripted. *nod* 1) Trivial

SPDX Statistics - Book Smugglers edition

Hot news:     The last phase has been announce https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4 and we will proceed when approved with FESCO. RC2 of SPDX v.3 specification has been published. https://spdx.github.io/spdx-spec/v3.0/

Re: [Fedora-legal-list] Trivy for licenses

Dne 03. 03. 24 v 20:22 Philippe Ombredanne napsal(a): It is mostly based on google/licenseclassifier which had a single commit in the last 17 months, and this means this is not more maintained than askalono (and frankly both are fairly lightweight tools for license detection). Trivy adds SPDX

Re: Trivy for licenses

Dne 03. 03. 24 v 7:35 Maxwell G napsal(a): Has anyone every used trivy [1] to scan for licenses? It appears more robust and better maintained than askalono-cli and can detect files with multiple licenses and licenses embedded in file headers.  I have been running it with "trivy fs --scanners

SPDX Statistics - Beginning of the year edition

Hot news:     fedora-license-data has Copr project https://copr.fedorainfracloud.org/coprs/g/osci/fedora-license-data where new package is built whenever new PR is merged     The last phase is ready for wrangler https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4 and we will proceed

Re: SPDX Statistics - Please Please Me edition

Dne 26. 02. 24 v 15:51 Richard Hughes napsal(a): If the SPDX listing isn't using src.fedoraproject.org and instead using something like bugzilla please yell. Being listed as maintaining all those also makes the packager-dashboard basically useless for me too.  I am using a script:

Re: mock: ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer

Dne 21. 02. 24 v 18:34 Jun Aruga (he / him) napsal(a): But I am afraid I am customizing the file /etc/mock/fedora-rawhide-x86_64.cfg . It's not the original one from the RPM any more. I should use the original one and it's better to manage my own custom setting in the `~/.config/mock.cfg`?

Re: mock: ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer

Dne 21. 02. 24 v 17:38 Jun Aruga (he / him) napsal(a): $ mock -r fedora-rawhide-x86_64 --shell --setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off /usr/bin/dnf-3 --disableplugin=versionlock install @buildsys-build This is suspicious. It should use DNF5 now. What is

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

Do you want to make Fedora 40 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 # This is last time we should do that :) sudo dnf module reset '*' dnf

Re: Feedback wanted - pruning old rawhide chroots in Copr

Dne 19. 02. 24 v 14:59 Kevin Kofler via devel napsal(a): Instead of coming up with new aggressive pruning schemes, Copr really needs to come up with a reasonable amount of storage to satisfy user demands. HDDs in the multi-TB-range are available for fairly low budgets (extremely low by the

Feedback wanted - pruning old rawhide chroots in Copr

In Copr build system, we noticed that Fedora rawhide chroots can became large and they stay forever as rawhide is never EOLed. We plan to work on this soon, but we are not sure what is best approach. I want to ask you - the users of Copr - what will be convenient for you? The problem is

SPDX Statistics - Please Please Me edition

Hot news:     SPDX did a new release of license list with 43 new licenses. Most of them were added thank to Fedora maintainers https://github.com/spdx/license-list-XML/releases Two weeks ago we had: * 23711spec files in Fedora * 30306license tags in all spec files * 11542 tags have not

Re: Why branched config pointed to rolling config?

Dne 15. 02. 24 v 6:38 Mikhail Gavrilov napsal(a): I think that getting the f41 package with fedora-40 config looks at least odd. And one of the solutions is making rolling config pointed to branch config rather than the other way around. Than you will get f40 packages with rawhide config.

Re: Why branched config pointed to rolling config?

Dne 14. 02. 24 v 14:56 Michael J Gruber napsal(a): Why branched config pointed to rolling config? # ls -ln | grep fedora-40 lrwxrwxrwx. 1 0 135 26 Jan 11 20:46 fedora-40-aarch64.cfg -> fedora-rawhide-aarch64.cfg lrwxrwxrwx. 1 0 135 23 Jan 11 20:46 fedora-40-i386.cfg ->

Re: Does ccache ever help with kernel mock build?

Dne 13. 02. 24 v 9:08 Julian Sikorski napsal(a): Could this be the reason for ccache not working? I wonder whether it is Mock problem, Ccache issue or problem in packaging? Does the ccache speadup the build when you run it with plain rpmbuild and ccache on host? -- Miroslav Suchy, RHCA Red

Re: Does ccache ever help with kernel mock build?

Dne 12. 02. 24 v 23:01 Julian Sikorski napsal(a): Do I need to install ccache on the host as well? No. Mock installs the ccache into buildroot. It is injected as additional Build requires https://github.com/rpm-software-management/mock/blob/main/mock/py/mockbuild/plugins/ccache.py#L35 --

Re: Does ccache ever help with kernel mock build?

Dne 12. 02. 24 v 19:29 Julian Sikorski napsal(a): Hello, has anyone successfully managed to get ccache to speed up kernel mockbuilds, be it SRPMS from kernel-ark or from dist-git? I gave it a brief shot but saw no difference, if anything the build was slower. The machine I am building on has

Re: dnf-4.19.0 without filelists in Rawhide soon

Dne 09. 02. 24 v 16:29 Florian Weimer napsal(a): What's the impact on mock and older chroots? Just use bootstrap chroot? Yes, in rawhide if you build package for older chroot, you will have to use bootstrap chroot. It is enabled by default. You will have problems if you disabled it manually.

SPDX Statistics - Selkirk edition

Hot news: Richard and I had several days PTOs, so the progress of MR in fedora-license-data was affected by this. Now lets dive into numbers: Two weeks ago we had: * 23681 spec files in Fedora * 30232license tags in all spec files * 11697 tags have not been converted to SPDX yet *

Re: Mass change of LicenseRef-KDE-Accepted-* licenses

Dne 29. 01. 24 v 13:58 Ben Beasley napsal(a): Could you please double-check this change? I noticed that in spacebar, LicenseRef-KDE-Accepted-GPL was the actual name of a license file in the %files section; this was replaced with (GPL-2.0-only OR GPL-3.0-only), which causes the package to

Staled PRs at https://src.fedoraproject.org/rpms/

During my work on SPDX migration I filed hundreds of pull request and as part of that work I always check if there is already open PRs for a package. It surprised me how many packages has open PR. I understand when there is open PR with blocker or ongoing discussion. But I have seen PRs that

Re: Interesting difference between Koji and COPR (_isa macro)

Dne 24. 01. 24 v 18:02 Dan Horák napsal(a): It seems like %{?_isa} is not defined for noarch packages in Koji but it is in COPR. Is that a known problem/feature? it could be because COPR always does an archful build (like plain mock builds do), while koji knows noarch is a separate arch Mock

Re: Fedora 40 Mass Rebuild *finish* delayed

Dne 24. 01. 24 v 10:51 Aoife Moloney napsal(a): All other milestones remain the same at this time and the published schedule[4] has been updated to reflect these changes. https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html Branching is set to 2024-02-06 while mass rebuilds are

Mass change of LicenseRef-KDE-Accepted-* licenses

Lots of packages in Fedora use license LicenseRef-KDE-Accepted-GPL and LicenseRef-KDE-Accepted-LGPL. These licenses were never approved. It took lots of time to discuss it and document it. We finally come with:

SPDX Statistics - Lisa edition

Hot news: https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_3 was approved. I generated license analysis using scancode-toolkit for all remaining packages http://miroslav.suchy.cz/fedora/spdx-reports/ Now lets dive into numbers: Two weeks ago we had: * 23542 spec files in Fedora

Re: SPDX Statistics - Eight-hour day edition

Dne 05. 01. 24 v 8:14 Miroslav Suchý napsal(a): To ease the migration I created a scantool-tookit reports for remaining packages. It is available here http://miroslav.suchy.cz/fedora/spdx-reports/ Right now there are missing packages from ELN set and all other missing Fedora packages from

Re: Fedora Linux 37 is EOL

Dne 07. 01. 24 v 6:15 Jens-Ulrik Petersen napsal(a): (Replying to devel list) Can someone please update https://docs.fedoraproject.org/en-US/releases/eol/#_unsupported_fedora_linux_releases to correct the EOL date for F37 to 5th Dec? Or should I open a releng ticket for that? PR is enough

Re: SPDX Statistics - Eight-hour day edition

Dne 05. 01. 24 v 7:38 Miroslav Suchý napsal(a): Hot news: I forgot to mention one thing: To ease the migration I created a scantool-tookit reports for remaining packages. It is available here http://miroslav.suchy.cz/fedora/spdx-reports/ Right now there are missing packages from ELN set

SPDX Statistics - Eight-hour day edition

Hot news: The process of adding licenses is back on track. https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_3 has been submitted. Now lets dive into numbers: Two weeks ago we had: * 23562 spec files in Fedora * 30067license tags in all spec files * 11907 tags have not been

Re: ARM PAC on koji vs COPR

Dne 03. 01. 24 v 14:46 Jarek Prokop napsal(a): 4. Why do koji and copr have CPU flag set that differs so much? Is our koji infra OK? For convenience of readers: Koji: Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs Copr: Flags:

SPDX Statistics - Public Christmas Tree edition

Hot news: We added new license LicenseRef-Fedora-Firmware that we use for firmware that does not have clear license declarations and only "Redistributable..."-like declarations. https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/460/diffs The process of adding the licenses

Re: Building the boot.iso with dnf5

Dne 09. 12. 23 v 12:57 Peter Robinson napsal(a): It was my understanding the switch to dnf5 was delayed until F-41 so I don't think we should be using it for this either until it's the default in Fedora as well. It was delayed because it was not ready for general usage. E.g. some functionality

SPDX Statistics - Freeze 'Em All edition

Hot news: We added new license LicenseRef-Not-Copyrightable that should be used for packages like foo-filesystem that e.g., create just directories and does not have copyrightable code nor content. The process of adding the licenses on list is still very slow recently. I made an error when

Re: Copr builds are stuck at package signing

Dne 06. 12. 23 v 12:52 František Šumšal napsal(a): Hey, Thanks to Packit I noticed that a lot of our jobs are running longer than usual, and a quick glance at the Copr task queue[0] tells me there's something fishy going on. I opened a couple of jobs[1][2][3] and all of ... Looks like the

[EPEL-devel] Re: Network rules to use mock on RHEL8

Dne 03. 12. 23 v 20:46 Emmanuel Seyman napsal(a): Hello, all. Wanting to promote RPM packages, I'm trying to use mock on an RHEL8 VM that does not have unrestricted access to the internet. This fails miserably, as you would expect it to. I've already established that I need access to: *

SPDX Statistics - Origin of Species edition

Hot news: I have started looking at Cavil - tool that audit the licensing info after each commit. The process of adding the licenses on list is still very slow recently. Now lets dive into numbers: Two weeks ago we had: * 23365 spec files in Fedora * 29583license tags in all spec files *

Re: How can I delete a rawhide Bodhi update?

Dne 23. 11. 23 v 17:04 Petr Pisar napsal(a): That's the glory automation which creates updates after finishing a build on behalf of the user wihout ownership by the user. Once there is such update created, you only can file a ticket against relengs (or infra) to delete the update. Without

Re: Why I won't run for FESCo

Dne 22. 11. 23 v 20:40 Miro Hrončok napsal(a): *I am tired.* When I joined FESCo 5 years ago, I had the enthusiasm and energy. Enthusiasm - I think this is most important part. For anyone considering running for FESCO. If anyone from the audience is considering running for FESCO, but you

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: 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

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: 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

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 - 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: 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: 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

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: 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.

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

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: 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

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: 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 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

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

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

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: 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: 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

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

  1   2   3   4   5   6   7   8   9   10   >