Re: fedrq - new repoquerying tool
On Sun Feb 12, 2023 at 13:40 +, Maxwell G via devel wrote: > > Though, it would be nice to have an easier subcommand or option just for > > that, as it will be, I think, the most required use case. Maybe a 'fedrq > > whatrequires --soname-bump SRCNAME'? > > Thanks for trying it out and for the feedback! I don't want to tack this > on to `whatrequires`, but a separate subcommand might be warranted. Name > suggestions are welcome. subpkgs-whatrequires is accurate but way too > long :). I created an issue for this in fedrq's issue tracker [1]. > > > [1] https://todo.sr.ht/~gotmax23/fedrq/13 > This is now available on the main branch. $ fedrq whatrequires -F source $(fedrq subpkgs SRCNAME) can be replaced with $ fedrq whatrequires-src -F source SRCNAME or $ fedrq wrsrc -F source SRCNAME wrsrc is an alias for whatrequires-src. If you want, you can install https://copr.fedorainfracloud.org/coprs/gotmax23/fedrq-dev/build/5519594/ or $ pip install 'git+https://git.sr.ht/~gotmax23/fedrq#main' to try it out. I'll cut a release later this week. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: fedrq - new repoquerying tool
On Sun Feb 12, 2023 at 08:12 +, Mattia Verga via devel wrote: > Il 12/02/23 06:31, Maxwell G via devel ha scritto: > > For reverse dependency rebuilds, you probably want the following > > command: > > > > ``` > > $ fedrq whatrequires -X -F source $(fedrq subpkgs SRCNAME) # equivalent > > $ fedrq subpkgs SRCNAME | fedrq whatrequires -X -i -F source # equivalent > > ``` > > > > This accounts for any package that depends on any subpackage/binary RPM > > produced by SRCNAME at buildtime and/or runtime, and spits out the names > > of the source packages that need to be rebuilt. For simple packages that > > output only one RPM, `fedrq whatrequires -F source PKGNAME` is > > sufficient. > > > Thanks for this! I never found a (easy) way to make dnf output the exact > reverse dependency of libindi, for example, and your tool does that well > with an easy to understand output: > > $ fedrq whatrequires -F source $(fedrq subpkgs libindi) > indi-3rdparty-drivers > indi-3rdparty-libraries > kstars > libindi > phd2 > stellarium > > Though, it would be nice to have an easier subcommand or option just for > that, as it will be, I think, the most required use case. Maybe a 'fedrq > whatrequires --soname-bump SRCNAME'? Thanks for trying it out and for the feedback! I don't want to tack this on to `whatrequires`, but a separate subcommand might be warranted. Name suggestions are welcome. subpkgs-whatrequires is accurate but way too long :). I created an issue for this in fedrq's issue tracker [1]. [1] https://todo.sr.ht/~gotmax23/fedrq/13 -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
fedrq - new repoquerying tool
Hi Fedorians, I've been working on a repoquerying tool called fedrq [1] that I'd like to share with you. Here's the elevator pitch: fedrq provides a friendly interface to query the Fedora repositories. It makes it really easy to query across Fedora and EPEL branches. It uses the dnf Python bindings (libdnf5 backend is almost done) and doesn't shell out to dnf repoquery. Amongst other things, fedrq allows querying for reverse dependencies, packages that contain a certain Provide or file, subpackages of an SRPM, and general package metadata. My favorite features are the easy branch switching, `fedrq subpkgs` (there's no real equivalent in dnf repoquery), and the ability to dump package metadata as JSON. The many threads about how to properly query for dependencies when doing SO name bump rebuilds and my own frustrations with dnf repoquery inspired this tool. You can install fedrq from PyPI or from gotmax23/fedrq [2] on Copr. The EXAMPLES section of fedrq(1) [3] provides a good intro and demonstration of fedrq's functionality. The tool is very much a WIP and any feedback is appreciated. For reverse dependency rebuilds, you probably want the following command: ``` $ fedrq whatrequires -X -F source $(fedrq subpkgs SRCNAME) # equivalent $ fedrq subpkgs SRCNAME | fedrq whatrequires -X -i -F source # equivalent ``` This accounts for any package that depends on any subpackage/binary RPM produced by SRCNAME at buildtime and/or runtime, and spits out the names of the source packages that need to be rebuilt. For simple packages that output only one RPM, `fedrq whatrequires -F source PKGNAME` is sufficient. [1] https://sr.ht/~gotmax23/fedrq/ [2] https://copr.fedorainfracloud.org/coprs/gotmax23/fedrq/ [3] https://gotmax23.srht.site/fedrq/fedrq.1.html#EXAMPLES -- Thanks, Maxwell G (@gotmax23) Pronouns: He/They ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Hoping to disable i686 and 32-bit arm for Podman and related tools for existing Fedora releases
2023-02-07T11:43:53Z Lokesh Mandvekar :
> We (podman upstream and fedora maintainers) are hoping to disable i686
> and 32-bit arm builds for Podman and some related tools under
> https://github.com/containers org. We would like to do this also for
> released Fedora versions, and not just the upcoming ones.
>
> What Fedora paperwork do we need in place to get this going?
arm32 has been removed entirely from F37+. I don't think excluding
packages from arm32 at this point in the F36 release cycle is
acceptable. Wait until the release goes EOL.
As for i686, you don't need extra paperwork thanks to exclude packages
thanks to
https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval.
You just need to properly handle dependent packages. You cannot
ExcludeArch a package unless all of its dependents are also excluded.
It's recommended to exclude Go packages with
`ExclusiveArch: %{golang_arches_future}`.
For other packages, a regular `ExcludeArch: %{ix86}` is sufficient.
Here's some of the dependents you need to account for:
---
$ cat
Re: F39 proposal: Mass Retire Golang Leaves (Self-Contained Change proposal)
On Fri Feb 3, 2023 at 01:42 +, Maxwell G wrote:
> (see the attachment)
Here it is!
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
diff --git a/blocker.patch b/blocker.patch
new file mode 100644
index 000..76999f4
--- /dev/null
+++ b/blocker.patch
@@ -0,0 +1,24 @@
+From 90303acd82a190711f6b902a25341dff459780ca Mon Sep 17 00:00:00 2001
+From: Maxwell G
+Date: Sat, 21 Jan 2023 18:16:39 -0600
+Subject: [PATCH] blocker
+
+---
+ rpm/macros.d/macros.go-srpm | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/rpm/macros.d/macros.go-srpm b/rpm/macros.d/macros.go-srpm
+index d589894..d3d232c 100644
+--- a/rpm/macros.d/macros.go-srpm
b/rpm/macros.d/macros.go-srpm
+@@ -117,6 +117,7 @@ else
+ exclusive_arches = "%{golang_arches_future}"
+ end
+ print( "BuildRequires: go-rpm-macros\\n")
++print( "BuildRequires: blocker\\n")
+ print(rpm.expand("ExclusiveArch: " .. exclusive_arches .. "\\n"))
+ local fedora = require "fedora.common"
+ local go = require "fedora.srpm.go"
+--
+2.39.0
+
diff --git a/go-rpm-macros.spec b/go-rpm-macros.spec
index 1ca030b..1a278cc 100644
--- a/go-rpm-macros.spec
+++ b/go-rpm-macros.spec
@@ -19,29 +19,32 @@ Version: 3.2.0
%global gopath %{_datadir}/gocode
Name: go-rpm-macros
+Epoch: 1
Release: %autorelease
Summary: Build-stage rpm automation for Go packages
License: GPL-3.0-or-later
URL: %{forgeurl}
Source:%{forgesource}
+Patch: blocker.patch
-Requires: go-srpm-macros = %{version}-%{release}
-Requires: go-filesystem = %{version}-%{release}
+Requires: go-srpm-macros = %{?epoch:%{epoch}:}%{version}-%{release}
+Requires: go-filesystem = %{?epoch:%{epoch}:}%{version}-%{release}
Requires: golist
+Requires: blocker
%ifarch %{golang_arches}
Requires: golang
Provides: compiler(golang)
Provides: compiler(go-compiler) = 2
-Obsoletes: go-compilers-golang-compiler < %{version}-%{release}
+Obsoletes: go-compilers-golang-compiler < %{?epoch:%{epoch}:}%{version}-%{release}
%endif
%ifarch %{gccgo_arches}
Requires: gcc-go
Provides: compiler(gcc-go)
Provides: compiler(go-compiler) = 1
-Obsoletes: go-compilers-gcc-go-compiler < %{version}-%{release}
+Obsoletes: go-compilers-gcc-go-compiler < %{?epoch:%{epoch}:}%{version}-%{release}
%endif
%description
@@ -55,6 +58,7 @@ pull it in for Go packages only.
Summary: Source-stage rpm automation for Go packages
BuildArch: noarch
Requires: redhat-rpm-config
+Requires: blocker
%description -n go-srpm-macros
This package provides SRPM-stage rpm automation to simplify the creation of Go
@@ -69,6 +73,7 @@ go-srpm-macros will pull in for Go packages only.
%package -n go-filesystem
Summary: Directories used by Go packages
License: LicenseRef-Fedora-Public-Domain
+Requires: blocker
%description -n go-filesystem
This package contains the basic directory layout used by Go packages.
@@ -77,7 +82,7 @@ This package contains the basic directory layout used by Go packages.
Summary: RPM spec templates for Go packages
License: MIT
# go-rpm-macros only exists on some architectures, so this package cannot be noarch
-Requires: go-rpm-macros = %{version}-%{release}
+Requires: go-rpm-macros = %{?epoch:%{epoch}:}%{version}-%{release}
#https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51
#Requires: redhat-rpm-templates
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Mass Retire Golang Leaves (Self-Contained Change proposal)
On Fri Feb 3, 2023 at 02:00 +0100, Miro Hrončok wrote: > On 02. 02. 23 17:06, Ben Cotton wrote: > > # Create a blank ''blocker'' package that Conflicts with the to be > > removed packages. > > # Create a new Copr with the blocker package in its default buildroot. > > This will simulate the actual removal of these packages. > > Was this verified to actually work that way? Isn't the conflicting > default-installed package removed when something that is conflicting is about > to be installed? Yes, I did confirm it. You're right that just adding the package to the buildroot doesn't work. I also built a modified go-rpm-macros to ensure that blocker is pulled in (see the attachment); %gometa explicitly adds `BuildRequires: blocker` to specfiles and every go-rpm-macros subpackage has `Requires: blocker`. I already found a couple false positives. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Tue Jan 24, 2023 at 22:44 +0100, Sandro wrote: > Development of Bottles is moving fast and we have been struggling to > keep up with upstream releases, especially since the introduction of > Rust components. What (rust) dependencies are missing? Is it just python-orjson? I worked on packaging that last night. It seems this library is gaining in popularity. Four new rust dependencies and updating pyo3 to 0.17 (while creating compat packages for 0.16) are needed. Updating pyo3 is straightforward and Fabio started working on it (thanks!). https://copr.fedorainfracloud.org/coprs/gotmax23/orjson/builds/ https://git.sr.ht/~gotmax23/fedora-python-orjson I'm not sure I can commit to maintaining these myself, though. Let me know if you're interested in helping out. > Upstream has approached the maintainers [1,2] and asked us to retire the > package in favor of the Flatpak packages provided by upstream. I wish this upstream was more friendly to distribution packagers... Approaching downstream maintainers like this feels inappropriate and somewhat antithetical to the tenets of OSS. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
> Can take this if no-one else is interested (@Sergio Basto?) > > > docker-compose lsm5, orphan, ttomecek 1 weeks > > ago The Python docker-compose is deprecated upstream in favor of the Compose V2 Docker CLI Plugin written in Go. The latter is not yet packaged for Fedora. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Cfitsio soname bump, side tag created
On Thu Jan 12, 2023 at 01:19 +0100, Sergio Pascual wrote: > El vie, 30 dic 2022 a las 2:33, Maxwell G via devel (< > devel@lists.fedoraproject.org>) escribió: > > > On Thu Dec 29, 2022, Maxwell G via devel wrote: > > > On Thu Dec 29, 2022, Maxwell G via devel wrote: > > > > On Wed Dec 28, 2022 at 15:00 +0100, Sergio Pascual wrote: > > > > > Hello again, as stated before [1], I'm updating cfitsio to 4.2. I > > have > > > > > created a side tag f38-build-side-61457 > > > > > > > > > > I have already built cfitsio, CCfits and wcslib. > > > > > > > > > > > @music already built luminance-hdr. I'm submitting builds for the rest. > > > > > > > > > The builds have finished. The following packages failed to build after > > > being rebuilt a total of three times: > > > > > > name:taskid:status > > > -- > > > astrometry:95679269:failed > > > esorex:95679267:failed > > > python-astropy:95679270:failed > > > python-healpy:95679272:failed > > > > > > > > > esorex and python-astropy are preexisting failures. python-healpy and > > > astrometry depend on python-astropy and are failing with > > > > > > DEBUG util.py:443: No matches found for the following disable plugin > > patterns: local, spacewalk, versionlock > > > DEBUG util.py:445: Package pkgconf-pkg-config-1.8.0-3.fc37.aarch64 is > > already installed. > > > DEBUG util.py:443: Error: > > > DEBUG util.py:443: Problem: conflicting requests > > > DEBUG util.py:443:- nothing provides libcfitsio.so.9()(64bit) needed > > by python3-astropy-5.1-3.fc38.aarch64 > > > DEBUG util.py:445: (try to add '--skip-broken' to skip uninstallable > > packages) > > > DEBUG util.py:596: Child return code was: 1 > > > > I've submitted > > https://src.fedoraproject.org/rpms/python-astropy/pull-request/2/. > > > > > Hello, I have built python-astropy 5.2 in the side tag, we can continue > with the packages depending on it. I have taken care of esorex too Great! I rebuilt the last two packages and submitted an update: https://bodhi.fedoraproject.org/updates/FEDORA-2023-5e54e85176 -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in February
On Wed Jan 11, 2023 at 13:58 +0100, Miro Hrončok wrote: > golang-github-d2g-dhcp4servereclipseo, go-sig I need a package review to fix this: https://bugzilla.redhat.com/show_bug.cgi?id=2160202 -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in February
On Wed Jan 11, 2023 at 13:58 +0100, Miro Hrončok wrote: > Based on the current fail to build from source policy, the following packages > should be retired from Fedora 38 approximately one week before branching. > golang-github-gin-gonic eclipseo, go-sig I've fixed this: https://bugzilla.redhat.com/show_bug.cgi?id=2045509 -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help with Rust packaging
Jan 7, 2023 4:41:29 PM Lumír Balhar : y-py upstream uses maturin as a build backend which is not available in Fedora yet so I had to add some metadata manually to port it to setuptools-rust Why not package maturin? Is there something particularly problematic about maturin (e.g. lots of missing dependencies) or is it just lack of time? -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Mon Jan 2, 2023 at 11:46 -0600, Robby Callicotte via devel wrote: > I went ahead and took vim-nerdtree. FYI: Nerdtree is unmaintained upstream: https://github.com/preservim/nerdtree/issues/1280 -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rpmautospec howto do a rebuild for something
On Mon Jan 2, 2023 at 12:32 +, Sérgio Basto wrote: > I need rebuild a package that is using rpmautospec , how I can rebuild > the package and increase relversion ? `git commit --allow-empty -m "Changelog entry here"` will do what you want. The empty commit will result in a release and changelog bump. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Mon Jan 2, 2023 at 09:57 +0100, Miroslav Suchý wrote: > 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. :) The release number shows how many builds of the same version have been made. A high release is also baseline indicator that a package/project is stale downstream and/or upstream. When the first build of foo v1.5.0 is foo-1.5.0-6 because the author took the time to split up logical changes into separate commits, the value of that release number is lost. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Cfitsio soname bump, side tag created
On Thu Dec 29, 2022, Maxwell G via devel wrote: > On Thu Dec 29, 2022, Maxwell G via devel wrote: > > On Wed Dec 28, 2022 at 15:00 +0100, Sergio Pascual wrote: > > > Hello again, as stated before [1], I'm updating cfitsio to 4.2. I have > > > created a side tag f38-build-side-61457 > > > > > > I have already built cfitsio, CCfits and wcslib. > > > > > @music already built luminance-hdr. I'm submitting builds for the rest. > > > The builds have finished. The following packages failed to build after > being rebuilt a total of three times: > > name:taskid:status > -- > astrometry:95679269:failed > esorex:95679267:failed > python-astropy:95679270:failed > python-healpy:95679272:failed > > > esorex and python-astropy are preexisting failures. python-healpy and > astrometry depend on python-astropy and are failing with > > DEBUG util.py:443: No matches found for the following disable plugin > patterns: local, spacewalk, versionlock > DEBUG util.py:445: Package pkgconf-pkg-config-1.8.0-3.fc37.aarch64 is > already installed. > DEBUG util.py:443: Error: > DEBUG util.py:443: Problem: conflicting requests > DEBUG util.py:443:- nothing provides libcfitsio.so.9()(64bit) needed by > python3-astropy-5.1-3.fc38.aarch64 > DEBUG util.py:445: (try to add '--skip-broken' to skip uninstallable > packages) > DEBUG util.py:596: Child return code was: 1 I've submitted https://src.fedoraproject.org/rpms/python-astropy/pull-request/2/. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Cfitsio soname bump, side tag created
On Thu Dec 29, 2022 at 09:40 HST, Maxwell G via devel wrote: > On Wed Dec 28, 2022 at 15:00 +0100, Sergio Pascual wrote: > > Hello again, as stated before [1], I'm updating cfitsio to 4.2. I have > > created a side tag f38-build-side-61457 > > > > I have already built cfitsio, CCfits and wcslib. > > @music already built luminance-hdr. I'm submitting builds for the rest. The builds have finished. The following packages failed to build after being rebuilt a total of three times: name:taskid:status -- astrometry:95679269:failed esorex:95679267:failed python-astropy:95679270:failed python-healpy:95679272:failed esorex and python-astropy are preexisting failures. python-healpy and astrometry depend on python-astropy and are failing with DEBUG util.py:443: No matches found for the following disable plugin patterns: local, spacewalk, versionlock DEBUG util.py:445: Package pkgconf-pkg-config-1.8.0-3.fc37.aarch64 is already installed. DEBUG util.py:443: Error: DEBUG util.py:443: Problem: conflicting requests DEBUG util.py:443:- nothing provides libcfitsio.so.9()(64bit) needed by python3-astropy-5.1-3.fc38.aarch64 DEBUG util.py:445: (try to add '--skip-broken' to skip uninstallable packages) DEBUG util.py:596: Child return code was: 1 -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Cfitsio soname bump, side tag created
On Wed Dec 28, 2022 at 15:00 +0100, Sergio Pascual wrote: > Hello again, as stated before [1], I'm updating cfitsio to 4.2. I have > created a side tag f38-build-side-61457 > > I have already built cfitsio, CCfits and wcslib. Affected packages are: > > astrometry > bes > CCfits > cpl > elements-alexandria > gdal > healpix > indi-3rdparty-gphoto > kstars > kst > LabPlot > libindi > luminance-hdr > perl-Astro-FITS-CFITSIO > phd2 > python-astropy > python-fitsio > python-healpy > root > siril > skyviewer > sourcextractor++ > ufraw > vips > wcslib > > Best regards, Sergio @music already built luminance-hdr. I'm submitting builds for the rest. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?
On Sun Dec 25, 2022 at 09:02 -0500, Sam Varshavchik wrote: > rpm -E '%__global_ldflags' > > is also needed for LDFLAGS. %__global_ldflags is deprecated. You should use %build_ldflags instead[1]. Also, %build_cflags, %build_cxxflags, and friends are preferred to %optflags AFAIK. [1]: https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_130 -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Golang bundled() Provides generator
Hi Fedorians, A recent PR reminded me that I never properly announced the new (well, four months old) bundled() Provides generator for Golang projects[1]. This can be used to simplify generating these Provides when bundling is justified in Fedora[2] or for (EP)EL. Simply mark the vendor/modules.txt file generated by `go mod vendor` with `%license` and the generator will take care of the rest. This removes the need for long lists of Provides that clutter specfiles and have to be updated after each upstream release. It's up to package maintainers to inspect the Provides for correctness when opting in to this generator. Please let us know if you find any bugs. The generator is available in all Fedora branches and on EPEL 9 (part of go-rpm-macros-epel that shadows RHEL's go-rpm-macros). go-rpm-macros has been updated in c9s, so I'll remove the generator from go-rpm-macros-epel when the next RHEL 9 minor release comes out. [1]: https://pagure.io/go-rpm-macros/c/226596177c63c3dc180b5aeda45fe3b18706e877?branch=master and https://pagure.io/go-rpm-macros/c/c32fbbd25bbcedee8c0b898d3653255b18a0d30e?branch=master [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_bundled_or_unbundled -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Polymake soname bump
On Mon Dec 19, 2022 at 15:56 -0700, Jerry James wrote: > On Mon, Dec 19, 2022 at 3:54 PM Maxwell G via devel > wrote: > > On Mon Dec 19, 2022 at 14:10 -0700, Jerry James wrote: > > > If all goes well, I will do the same for F37. > > > > I don't think this soname bump should happen in a stable release. > > Because ... ? The new version is backwards API compatible (although > not ABI compatible) with the previous version, I'm going to rebuild > the only consumer of the library, and the new version fixes bugs. > What is your objection? ABI incompatible updates are against the Updates Policy for stable releases: > ABI changes in general are very strongly discouraged, they force > larger update sets on users and they make life difficult for > third-party packagers. -- https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Polymake soname bump
On Mon Dec 19, 2022 at 14:10 -0700, Jerry James wrote: > If all goes well, I will do the same for F37. I don't think this soname bump should happen in a stable release. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: duktape soname bump
On Fri Dec 16, 2022 at 20:31 +0100, Frantisek Zatloukal wrote: > I wish I could write that I am going to build duktape 2.7.0 which bumps the > soname. However, my brain kind of misfired and I didn't, for some reason, > announce this upfront. The changes are minor, ABI changing stuff, I've > taken care of rebuilding all the dependencies (main maintainers of those > are in BCC): > - gerbera > - libproxy > - polkit > - python-dukpy > In any case, thank you for taking the time to properly rebuild the packages and not break the distribution. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Include minor version number in packaged Python shebangs
On Fri Dec 9, 2022 at 22:04 +, Audrey Toskin wrote: > DNF modules let you install multiple different versions of Python 3, > and the `alternatives` tool lets you change which is the default > version invoked by `/usr/bin/python3`. This is not the case on any current Fedora release. AFAIK, only EL 8 manages /usr/bin/python3 with alternatives. In current releases, /usr/bin/python3 always points to the default system python interpreter even if you have other python interpreter packages on your system. > However, at least for *Enterprise Linux 8, it seems a lot of packages > were built assuming the distro's default Python 3.6, but at runtime > only invoke "Python 3", not 3.6 specifically. In EPEL, packages with /usr/bin/python3 shebangs are meant to be executed with python3.6. You are correct that this falls apart when the python3 alternative points to a different Python interpreter. This oversight has been fixed[1] so new package builds that are meant for python3.6 have /usr/bin/python3.6 interpreters. We have not rebuilt existing packages so they are still affected by this. Therefore, it is recommended to keep python3 as /usr/bin/python3.6. [1]: https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/thread/RE3PG72B5AX7NTACPDSBGOWCMN7I3OQJ/ > It seems that I still need Python 3.6 for most packages installed via > DNF on EL8, Correct. > So, the workaround to having both installed on my system at the same > time would be to edit the shebangs to include the minor version of > Python that each application requires. It'd be better to set the python3 alternative to python3.6 (alternatives --set python3 /usr/bin/python3.6). Local modifications like this are not recommended. They will be discarded on updates. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Starting Flatpak SIG
On Thu Dec 8, 2022 at 17:29 +, Timothée Ravier wrote: > > Do we need a mailing list? My initial gut feeling is no, but I'm > > interested in what other people think. > > I think we don't. Tracking conversations and issues is much easier with a > tracker than mailing lists. I think it's helpful to have a mailing list for discussion and leave the issue tracker for tracking bugs/RFEs or other work that's already agreed upon. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon
On Fri Dec 2, 2022 at 13:30 -0800, Adam Williamson wrote: > What does everyone else think? Has the time come? Or is there more we > need to do to make side tags usable for all cases before getting rid of > overrides? -1. For many use cases, side tags are the correct solution and buildroot overrides should not be used. However, there are occasions where they are still useful. If people are improperly using buildroot overrides and breaking the buildroot, the correct solution is education and documentation, not banning them entirely. Examples: 1. There is a Go compiler release that has patches for a CVE (i.e. almost every Go release ). I create buildroot overrides so all new builds are able to immediately start using it. 2. The same thing above but with other Go libraries that are statically linked into Go binaries. 3. There is a bug in macros that break builds. The fix should be available in the buildroot for all new builds immediately. 4. Some other buildtime only dependency update provides a bugfix that is needed for packages that BuildRequire it. On Fri Dec 2, 2022 at 23:21 +0100, Fabio Valentini wrote: > Not sure if we should turn them off entirely, but we could restrict > their use somewhat? For example, only allow people in "releng" or "qa" > groups to file them. I'd prefer not to have to bother releng every time I need to do this. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2022-11-29)
On Tue Nov 29, 2022 at 22:13 +, Zbigniew Jędrzejewski-Szmek wrote: > I just saw gotmax's comment after pasting this in ;) And I saw you beat me to replying to Kevin after I had already sent the same thing. The more the merrier I guess :). -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2022-11-29)
Nov 29, 2022 2:31:29 PM Kevin Kofler via devel : Stephen Gallagher wrote: Following is the list of topics that will be discussed in the FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on irc.libera.chat. does anyone have a complete log? It does not show up on meetbot.fedoraproject.org, and the raw log at https://meetbot-raw.fedoraproject.org/fedora-meeting/2022-11-29/fesco.2022-11-29-17.00.log.txt is truncated. Yeah, zodbot broke during the meeting :(. I pasted my logs here[1]. [1]: https://paste.sr.ht/~gotmax23/3576b21a357f5da14cc5871925d1f45999197b62 -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)
On Tue Nov 29, 2022 at 12:57 CST, Jeremy Linton wrote: > Hi, > > > On 6/16/22 15:53, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer > > > > 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 be implemented if approved > > by the Fedora Engineering Steering Committee. > > Given how this just went in the FESCo meeting, I might toss out an > alternative I've not seen anyone else suggest. > > Why not turn this on just for rawhide and leave it off for the main > distro releases? > > That is sorta what happens with the kernel already (extra debug > options). Its not perfect but rawhide is largely intended to be the dev > target anyway, so this solves both the "how do I do detailed > testing/profiling" as well as maintaining peak performance for everyone > else. I don't think those two things are analogous. It's possible to install a non-debug kernel on Rawhide. This is a distro-wide change that affects every package. Also, as Vitaly said, doing two mass rebuilds is untenable. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Red Hat Bugzilla fonts
On Tue Nov 29, 2022 at 18:51 +0100, Vitaly Zaitsev via devel wrote: > Hello. > > RHBZ began to demand Microsoft font "Segoe UI" since yesterday: > > font-family: SFMono-Medium, SF Mono, Segoe UI Mono, "Roboto Mono", > "Ubuntu Mono", Menlo, Courier, monospace > > > SFMono-Medium, SF Mono > > Not packaged and not installed by default on Fedora, so the Segoe UI > Mono is used. > > Is this okay? I think only open-source and packaged fonts should be used. > I believe Ubuntu fonts' license is also not permitted for Fedora. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
On Thu Nov 10, 2022 at 15:23 -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes > > 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 be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > > The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`. > When an RPM package is built, mtimes of packaged files will be clamped > to `$SOURCE_DATE_EPOCH` which is already set to the date of the latest > `%changelog` entry. As a result, more RPM packages will be > reproducible: The actual modification time of files that are e.g. > modified in the `%prep` section or built in the `%build` section will > not be reflected in the resulting RPM packages. Files in RPM packages > will have mtimes that are independent of the time of the actual build. > Will packagers still be required to use install -p, cp -p, etc. to preserve mtimes? For some packages, the source archives mtimes will be lower than $SOURCE_DATE_EPOCH, but e.g. for ancillary Source files (e.g. systemd units) stored in distgit, using -p won't make a difference, because the mtimes aren't preserved when Koji clones the distgit repository. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny
On Thu Nov 24, 2022 at 12:25 +0100, Miro Hrončok wrote: > On 24. 11. 22 3:38, Maxwell G via devel wrote: > > On Thu Nov 24, 2022 at 02:39 +0100, Miro Hrončok wrote: > >> go-compilers > >> go-srpm-macros > > > > These should both be orphaned. go-srpm-macros has been retired, as it's > > now a subpackage of go-rpm-macros. > > But it exists on Fedora 36 and needs a maintainer there. It will likely be > auto-orphaned once Fedora 36 EOLs. Should I give it to you? It's not part of the Fedora 36 composes, because go-rpm-macros's go-srpm-macros subpackage has a higher NEVR, but feel free to assign it to me. > > > go-compilers is Obsoleted by > > go-rpm-macros itself, but it looks like it has not yet been retired. > > I've gone ahead and done that. This split happened a few years ago, but > > the old packages were never properly removed. > > Ack. Technically also needs a maintainer but less important considering ti is > obsoleted. Users do report bugzillas for whatever component, so I do > recommend > having a responsive/responsible bugzilla PoC even for this one. You can also assign this one to me. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny
On Thu Nov 24, 2022 at 02:39 +0100, Miro Hrončok wrote: > go-compilers > go-srpm-macros These should both be orphaned. go-srpm-macros has been retired, as it's now a subpackage of go-rpm-macros. go-compilers is Obsoleted by go-rpm-macros itself, but it looks like it has not yet been retired. I've gone ahead and done that. This split happened a few years ago, but the old packages were never properly removed. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: moby-engine (also known as Docker) maintenance in Fedora
On Wed Nov 16, 2022 at 08:25 -0500, Dusty Mabe wrote: > On 11/16/22 06:09, Dan Čermák wrote: > > On November 14, 2022 7:18:45 PM UTC, "Timothée Ravier" > > wrote: > > I'm using docker for $dayjob and would be willing to help out a bit, but I > > will not be the main maintainer, as I don't feel comfortable taking such a > > huge package and lack the cycles for that. Yes, the package is complicated :(. It could use some cleanup (see the end of [1]), but I'm trying to step away from the package, and I haven't had time to. [1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DMPZRAUO3H5EHOCZDULYORYJVQU2WBIJ/ > I think there are others that would be willing to help mentor you if > you'd be interested in the challenge (with help). The Golang SIG has > regular meetings and various ways to communicate, which might be a > good way to engage: https://fedoraproject.org/wiki/SIGs/Go That's true. Our next meeting is the 21st at 19:00 UTC in #fedora-golang. As always, anybody is welcome to attend :). > >> This notably impacts Fedora CoreOS as we are including the moby-engine > >> package by default to let users pick their container engine of choice > >> whithout deciding for them in advance. We offer both major container > >> engines by default in the image (podman and moby-engine). > > > > No offense, but this sounds like that this is something the Fedora coreos > > team should tackle. Given that Fedora coreos appears to be driven to a > > large extend by redhat (at least that's my impression, please correct me if > > I'm wrong), I find it a bit odd that the business is asking volunteers to > > step up to help the business out... > > No offense taken. This is a great opportunity to add some clarity. Red Hat > doesn't ship Docker in products any longer. It was dropped in RHEL8+: > https://access.redhat.com/solutions/3696691 Yes, Docker and Containerd are no longer Supported in RHEL, but that's besides the point here. Fedora CoreOS ships moby-engine. The CoreOS Working Group apparently care about moby-engine and want it to be included in FCOS. I picked up on this and asked if they'd be willing to help maintain it. The two developers involved (who are paid by RH to work on FCOS) made clear that they are uninterested in doing so[^1] and took it upon themselves to find a volunteer to maintain the package. We got more contributions from an outside contributor who wasn't a package maintainer (3 PRs which involved rebasing patches, updating dependencies, and diagnosing build failures) than the FCOS team (0 PRs, 5 pings on their issue tracker and IRC, this email). I'm not trying to cause unnecessary strife here and they have apologized, but I'd be dishonest if I said I wasn't disappointed with the way this situation was handled. [^1]: which is alright. Everyone is free to choose what packages they do or don't want to maintain. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help understanding Fedora CI failure wrt RPM Sequoia
On Tue Nov 8, 2022 at 12:13 +0200, Panu Matilainen wrote: > Hey, > > Thought I'd try to get on with the times and do the Sequoia change via a > PR instead of just pushing as we've traditionally done. So far so good, > but it throws up an error which I have no idea how to debug: > > https://artifacts.dev.testing-farm.io/700d486d-d409-44fe-b7c3-01634243558e/ > > > Unknown Error occured: An rpm exception occurred: package not installed > > Okay, something failed, and it appears to be related to this very change > as the tests pass with a "no-op" PR. And in that case, a good thing it > got caught. But how on earth to debug this? I don't see anything even > remotely relevant in the accompanying logs, nor did I find any obvious > way to run this stuff locally. > > Help, Obi-Wan KenoCI. > > - Panu - I did some debugging in [1]. See my comment in that PR for more information. [1]: https://src.fedoraproject.org/rpms/rpm/pull-request/29 -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Silent changes in Packaging Guidelines
On Thu Nov 3, 2022 at 06:50 +0100, Kevin Kofler via devel wrote:
> When will this silliness ever stop? It just does not make sense to
> explicitly list every single file in the RPM. Wildcards are often the only
> reasonable way.
Nobody is saying that you have to list every single file in the package
or that e.g. adding `%{_datadir}/%{name}/` to %files is prohibited. It
is simply not allowed to glob absolutely everything under a shared
directory. For instance, ansible-core installs 11 different binaries
into %{_bindir} that all start with `ansible` that would be tedious to
list out manually. Instead of globing all of %{_bindir} with
`%{_bindir}/*, I could add `%{_bindir}/ansible*` which complies with
this guideline and is just as simple.
I think this is a sensible rule as it prevents conflicts and other
issues from popping up on updates when a package's build scripts start
installing new files. When reviewing Go packages, I've caught multiple
issues with `%{_bindir}/*` globs that hide conflicting files and/or
test/utility binaries that shouldn't be shipped to begin with.
Unfortunately, go2rpm generates specfiles with these globs by default.
FWIW, this is a SHOULD guideline not a MUST guideline, but I don't see a
case where such broad globs are justifiable.
As for the other complaint, I subscribe to the FPC issue tracker[1] to
to keep up with guidelines changes. There's also the packaging list, but
not a lot of active discussion happens there. I agree that it would be
beneficial to make changes more visible.
[1]: https://pagure.io/packaging-committee
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Python 3.12 (System-Wide Change proposal)
On Tue Oct 25, 2022 at 15:46 -0400, Ben Cotton wrote: > * 2023-07-17: Expected side tag-merge (pessimistic) > * 2023-07-19: Fedora 39 Mass Rebuild > ** The mass rebuild happens with the fourth beta. We might need to > rebuild Python packages later in exceptional case. > ** If the Koji side-tag is not merged yet at this point, we defer the > change to Fedora 38. Should this be Fedora 40? -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Deprecate python-toml (Self-Contained Change proposal)
On Sat Oct 15, 2022 at 19:23 +0200, Miro Hrončok wrote: > > Perhaps the "Migrating to tomllib on Python 3.11+ and falling back to > > tomli" approach should be more strongly recommended? tomllib is based > > off of tomli's code and is yet another thing that has to be bootstrapped > > during Python rebuilds. python-toml AND python-tomli have been removed > > from ELN/RHEL 10, as they're both made redundant by tomllib. > > Sure, "Migrating to tomllib on Python 3.11+ and falling back to tomli" is the > recommended approach. How do I make that more visible? I think the admonitions you added convey that well. I would also rearrange the suggestions so the recommended approach is the first thing that people see. Something like: 1.4 Detailed Description 1.4.1 List of components still (Build)Requiring python3-toml 1.4.2 Migrating to tomllib on Python 3.11+ and falling back to tomli 1.4.3 Migrating to tomllib 1.4.4 Migrating to tomli 1.4.5 Migrating to tomli-w > I've removed the "fallback to toml" option entirely now when toml is in EPEL > 8 > (thanks for that). Sure! I started working on tomli for EPEL 7, so that should be covered as well. > > I wonder if it would make sense to also phase out python-tomli at some > > point. > > I was thinking about deprecating that one as well, but I thought perhaps it's > too soon for some upstreams. > I am slowly walking trough upstream projects and dealing with the tomli > dependency. Chances are, we might get rid of it naturally without deprecation. I think that's a good approach. It makes sense to avoid deprecating packages when a gentler approach would work. > When we deal with RHEL 10, patching tomli imports > to make them tomllib imports seems "trivial" (unlike migrating from toml). Yeah, you still have to change the imports, but you don't have to deal with TOMLDecodeError or opening files in bytes mode. > One slight correction: Neither python-tomli nor python-toml has not been > removed from ELN, they will only be removed once not depended upon by other > ELN > pacakges. > > https://tiny.distro.builders/view-rpm--view-eln--python3-tomli.html > https://tiny.distro.builders/view-rpm--view-eln--python3-toml.html Ah, I see; they've been marked as unwanted but not yet removed. > > FWIW, the list of packages that directly require tomli is > > relatively small. > > > > $ ./python_toml_deps.py python3-tomli > > Runtime dependents of python3-tomli: > > 3. python3-flit > > 4. python3-flit-core > > Flit has been dealt with upstream: > > https://github.com/pypa/flit/commit/dba0f317c52 It's been dealt with upstream, but the python-flit package needs to be changed to not pull it in unconditionally. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Deprecate python-toml (Self-Contained Change proposal)
On 22/10/06, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/DeprecatePythonToml
>
> 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 be implemented if approved
> by the Fedora Engineering Steering Committee.
>
>
> == Summary ==
> The {{package|python-toml}} (`python3-toml`) package will be
> [https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/
> deprecated] in [[Releases/38|Fedora 38]]. The
> [https://pypi.org/project/toml/ upstream toml package] is considered
> unmaintained (see [[#Detailed_Description|description]]) and Python
> 3.11 contains [https://peps.python.org/pep-0680/ a TOML-reading
> library in the standard library]. Existing Fedora packages depend on
> {{package|python-toml}}, so we cannot remove it yet. Packagers are
> encouraged to work with upstreams to switch to
> [https://peps.python.org/pep-0680/
> tomllib]/[https://pypi.org/project/tomli/ tomli] for reading toml or
> [https://pypi.org/project/tomli/ tomli-w] for writing it. But
> {{package|python-toml}} remains available until it is a leaf package,
> it will be removed then (possibly not yet in Fedora 38).
From the table of contents:
> 1.4 Detailed Description
>
> 1.4.1 List of components still (Build)Requiring python3-toml
> 1.4.2 Migrating to tomllib
> 1.4.3 Migrating to tomli
> 1.4.4 Migrating to tomllib on Python 3.11+ and falling back to tomli
> 1.4.5 Migrating to tomllib on Python 3.11+ and falling back to toml
> 1.4.6 Migrating to tomli-w
Perhaps the "Migrating to tomllib on Python 3.11+ and falling back to
tomli" approach should be more strongly recommended? tomllib is based
off of tomli's code and is yet another thing that has to be bootstrapped
during Python rebuilds. python-toml AND python-tomli have been removed
from ELN/RHEL 10, as they're both made redundant by tomllib.
I wonder if it would make sense to also phase out python-tomli at some
point. FWIW, the list of packages that directly require tomli is
relatively small.
$ ./python_toml_deps.py python3-tomli
Runtime dependents of python3-tomli:
1. pyp2spec
2. python3-check-manifest
3. python3-flit
4. python3-flit-core
5. python3-pep517
6. python3-pytest
7. python3-setuptools_scm
8. python3-sphinx-theme-builder
9. python3-towncrier
10. python3-versioningit
Buildtime dependents of python3-tomli:
1. bst-external
2. hatch
3. pyp2spec
4. pytest
5. python-diff-cover
6. python-flit
7. python-pep517
8. python-pyproject-metadata
9. python-setuptools_scm
10. python-sphinx-theme-builder
11. python-towncrier
12. python-versioningit
13. python3-mypy
14. sagemath
Source RPM names:
1. bst-external
2. hatch
3. pyp2spec
4. pytest
5. python-check-manifest
6. python-diff-cover
7. python-flit
8. python-pep517
9. python-pyproject-metadata
10. python-setuptools_scm
11. python-sphinx-theme-builder
12. python-towncrier
13. python-versioningit
14. python3-mypy
15. sagemath
(This list was generated with [0]. Unlike dnf repoquery[1], this script
accounts for conditional dependencies on "python3 < 3.11".)
[0]:
https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/python_toml_deps.py
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2132462
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)
On Thu Oct 13, 2022 at 17:12 +0200, Kevin Kofler via devel wrote: > > And using Let's Encrypt for private mirrors is sufficiently painful that I > > wouldn't recommend it. > > Set up a subdomain like vpn.example.com, point it to the public IP, then > configure the VPN's internal DNS to resolve vpn.example.com to the VPN- > internal address instead, the /etc/hosts on the VPN server itself to resolve > it to 127.0.0.1, and the mirror server on port 443 (whereas port 80 is > reserved for certbot's builtin temporary (and world-readable) webserver with > the http-01 challenge) to accept connections only from the VPN and from > localhost and to use the Let's Encrypt certificate. Been there, done that > (not for a repository mirror though, my employer is small enough for that > not to be worthwhile). I assume that this approach should also work for a > physical LAN in lieu of the VPN. Let's Encrypt also supports the dns-01 challenge[1] that doesn't require any publicly available IPs. Using dns verification is required to obtain a Let's Encrypt wildcard certificate. [1]: https://letsencrypt.org/docs/challenge-types/#dns-01-challenge -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF5 Blockers
On Wed Oct 5, 2022, Maxwell G via devel wrote: > Hi Fedorians, > > I think we should define a more through list of blockers/criteria that > dnf5 needs to meet before it can replace the current dnf. > > The DNF maintainers have their list of requirements, but it would be > helpful for the wider community to test dnf5 and report which currently > unimplemented features/usecases would block them from adopting it. > Hopefully, the more popular, for lack of a better word, blockers can be > incorporated into the Change Proposal or otherwise required by FESCo as > a prerequisite for this change. This should help the DNF maintainers > prioritize, keep everyone on the same page, and ensure that dnf5 doesn't > prematurely become the default. Some of mine: - `dnf repoquery` -- Currently, `dnf5 repoquery` nowhere near meets the capabilities of the old version. This is the most important to me. - `dnf config-manager` - `dnf copr` - `dnf system-upgrade` - `dnf needs-restarting` - nice to have - Documentation for the Python API. Currently, the C++ library is documented, but the Python bindings are not. I saw someone else ask for this, and now I'm adding it to my blockers :). The current Python API documentation is great, so I wouldn't want to lose that. - A fully populated manpage. dnf5's manpage is nearly empty right now. Compatibility: - The `dnf update` alias is missing - `--refresh` is missing - The old dnf has some zypper style aliases (e.g. in for install, dsync for distro-sync). I don't use them, but I noticed they were missing. - I'm not sure what will happen with the old yum-utils aliases (e.g. /usr/bin/repoquery). I always use `dnf repoquery`, but I'd reckon that many others use the alias. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
DNF5 Blockers
Hi Fedorians, I think we should define a more through list of blockers/criteria that dnf5 needs to meet before it can replace the current dnf. The DNF maintainers have their list of requirements, but it would be helpful for the wider community to test dnf5 and report which currently unimplemented features/usecases would block them from adopting it. Hopefully, the more popular, for lack of a better word, blockers can be incorporated into the Change Proposal or otherwise required by FESCo as a prerequisite for this change. This should help the DNF maintainers prioritize, keep everyone on the same page, and ensure that dnf5 doesn't prematurely become the default. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SRPM macros, EPEL, and side tags
On Thu Oct 6, 2022 at 1:35 AM +0200, Miro Hrončok wrote: > On 05. 10. 22 23:24, Kevin Fenzi wrote: > > On Wed, Oct 05, 2022 at 08:40:12PM -, Artur Frenszek-Iwicki wrote: > >> Hi all, > >> > >> some time ago I've built the Free Pascal Compiler [0] for EPEL9, > >> and recently I got the idea it might be good to do the same with > >> the Lazarus IDE [1]. Testing things locally with mock, > >> I realized that Lazarus used a macro from fpc-srpm-macros [2], > >> which hasn't been built for EPEL9 yet. > >> > >> No biggie, I thought. I created a side tag, built fpc-srpm-macros there, > >> then added "BuildRequires: fpc-srpm-macros" to the Lazarus spec > >> and tried building it in the side tag. The build failed, and looking at > >> root.log, the fpc-srpm-macros package was not installed [3]. > > > > srpm's are built in a different buildroot koji has defined as > > 'srpm-build'. > > > > You can see whats in this with a 'koji list-groups epel9-build' > > > > So yeah, you need something to pull in that fpc-srpm-macros, > > (likely epel-release) or have it added to the srpm-build group. > > I believe more appropriate package is epel-rpm-macros. > > $ repoquery --repo=epel9 --requires epel-rpm-macros > (pyproject-rpm-macros if python3-rpm-macros) > ansible-srpm-macros > go-srpm-macros-epel > redhat-release >= 9 Yup, this is my understanding as well. In Fedora, *-srpm-macros packages are pulled in by adding having redhat-rpm-config depend on them. Macro packages that we want in EPEL that aren't in RHEL are usually added as dependencies of epel-rpm-macros. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fwd: Fwd: CVE Tracking Bugs
Forwarded message from Pete Allor on Fri Sep 30, 2022: No worries Max. I think my team is working through Ben and the first parts of adjusting the backend and our process should be out shortly. We can continue to adjust to finetune to your needs. As we work through this and adjust, if you have other inputs or desires, feel free to let me know and I will ensure we address them accordingly. Best, Pete On Fri, Sep 30, 2022 at 6:03 PM Maxwell G wrote: > Hi Pete, et. al, > > On Fri Sep 16, 2022, Maxwell G via devel wrote: > > I am forwarding this to the list to keep the community in the > > loop. I will respond in more detail later. > > I apologize for taking so long to actually respond to this. It seems > this slipped under my radar. > > > From: Pete Allor > > Date: Tue, 13 Sep 2022 20:49:04 -0400 > > Maxwell, > > One of my folks pointed this post out to me today. From a ProdSec > > perspective, you can reach out directly to me. > > > > The PSIRT Team and their work on CVEs report up through me, so I will be > > glad to have a discussion with you and why my folks are not supporting > you > > fully and how to fix that. > > > > I think the main thrust you are pointing to is that as the CNA for > Fedora, > > we should not be mixing all Red Hat errata into the Fedora project. > > Meaning keeping them more separated and distinct. That may not address > > all concerns, but I think it would be a good starting point to keep the > > focus correct and distinct, not overload on messages and bring attention > to > > what is critical / important so they are not missed. > > Yes, I agree; that would definitely cut down the amount of unactionable > notifications we get. > > The other main issue is the way effected packages are determined. > Often, CVE bugs are filed against packages that have already been > patched or that were never effected to begin with. > > Thank you again for reaching out, and I apologize for my overly ranty > initial email! > > -- > Maxwell G (@gotmax23) > Pronouns: He/Him/His > > -- Pete Allor, Director, Red Hat Product Security - Secure Engineering (m) 1-404-200-4630 ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fwd: Fwd: CVE Tracking Bugs
Hi Pete, et. al, On Fri Sep 16, 2022, Maxwell G via devel wrote: > I am forwarding this to the list to keep the community in the > loop. I will respond in more detail later. I apologize for taking so long to actually respond to this. It seems this slipped under my radar. > From: Pete Allor > Date: Tue, 13 Sep 2022 20:49:04 -0400 > Maxwell, > One of my folks pointed this post out to me today. From a ProdSec > perspective, you can reach out directly to me. > > The PSIRT Team and their work on CVEs report up through me, so I will be > glad to have a discussion with you and why my folks are not supporting you > fully and how to fix that. > > I think the main thrust you are pointing to is that as the CNA for Fedora, > we should not be mixing all Red Hat errata into the Fedora project. > Meaning keeping them more separated and distinct. That may not address > all concerns, but I think it would be a good starting point to keep the > focus correct and distinct, not overload on messages and bring attention to > what is critical / important so they are not missed. Yes, I agree; that would definitely cut down the amount of unactionable notifications we get. The other main issue is the way effected packages are determined. Often, CVE bugs are filed against packages that have already been patched or that were never effected to begin with. Thank you again for reaching out, and I apologize for my overly ranty initial email! -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
On Sat Sep 24, 2022, Maxwell G wrote: > On Tue Sep 6, 2022, Ben Cotton wrote: > > == Upgrade/compatibility impact == > > The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`, > > and DNF plugins (core and extras). python3-dnf and LIBDNF (`libdnf`, > > `python3-hawkey`) will be obsoleted by `fedora-obsolete-packages`. > > I am worried about removing python3-dnf this early. As far as I can > tell, the new Python libdnf bindings are very much not a drop in > replacement. There are a fair amount of tools and scripts that depend on > python3-dnf. The change proposal listed some of them, but Ansible's dnf > module is notably missing. I filed https://github.com/ansible/ansible/issues/78898 about Ansible's dnf module. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Updates to nextcloud
Sep 25, 2022 4:22:14 AM Avi Alkalay : I’ll check your links but I’m not sure it is clear for me what else should I do beyond the PR, bug report and Copr builds. After your message, it is still unclear for me if maintainers will take over and accept my PR. Hi Avi, It looks like the pull request has only been open for two days. You've done all that's is needed. Allow the maintainers some time to review your pull request. If you are interested in co-maintaing the package, you can ask the maintainers by emailing nextcloud-maintain...@fedoraproject.org. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
On Tue Sep 6, 2022, Ben Cotton wrote: > == Upgrade/compatibility impact == > The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`, > and DNF plugins (core and extras). python3-dnf and LIBDNF (`libdnf`, > `python3-hawkey`) will be obsoleted by `fedora-obsolete-packages`. I am worried about removing python3-dnf this early. As far as I can tell, the new Python libdnf bindings are very much not a drop in replacement. There are a fair amount of tools and scripts that depend on python3-dnf. The change proposal listed some of them, but Ansible's dnf module is notably missing. Personal user scripts (such as the one I use for Go CVE rebuilds) and some of releng's scripts will also be broken. I don't think we should proceed with removing python3-dnf until the majority of the important dependent software is ported. (To be clear, I don't consider my personal scripts to be important dependent software :). In general, I think the "If DNF5 will be not ready to replace DNF" contingent needs to have definite criteria and the compatibility section needs to be expanded. Of course FESCo can do as they see fit, but I personally have qualms with approving a major change like this in advanced of an actual stable release and major testing, especially without a clear definition of when DNF5 is considered ready to replace DNF4. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Non-responsive maintainer check for olem
On Fri Sep 2, 2022, Maxwell G via devel wrote:
>
> Sep 2, 2022 5:36:41 AM Fabio Valentini :
>
> > Does anybody know whether olem still wants to maintain their Fedora
> > packages?
> I'm fairly sure that they no longer wish to maintain Fedora packages. I
> reached out to them about moby-engine and containerd at the end of May,
> and they said they no longer have time to maintain them. I have been
> maintaining those packages myself for a while.
>
> Side note: I have asked for co-maintainers for those packages a couple
> times, but so far, I have not found any. Perhaps one of the CoreOS people
> would be interested? It seems those packages are used a lot there based
> on the bug reports we've gotten.
It looks like the nonresponsive maintainer process is going to proceed.
I've done some analysis of the Go packages that will be orphaned so the
Go SIG can figured out how to handle this. This was done by hand, so
please excuse any errors.
The following packages are dependencies of golang-github-docker{,-cli} and/or
containerd:
1. golang-github-hanwen-fuse
2. golang-github-fvbommel-sortorder
3. golang-github-containerd-nri
4. golang-github-moby-locker
5. golang-github-moby-term
6. golang-github-tonistiigi-rosetta
7. golang-github-google-containerregistry
8. golang-github-containerd-stargz-snapshotter (FTBFS)
9. golang-github-kyokomi-emoji is a dependency of hugo
olem also maintained open-policy-agent and some of its
dependencies:
- open-policy-agent
- golang-github-yashtewari-glob-intersection (open-policy-agent is the only
dependent)
- golang-uber-automaxprocs (dependency of both open-policy-agent and
clash)
This maintainer also maintained golang-github-jsonnet-bundler and
golang-github-containerd-cni. These packages are leaves. I sent a
separate message to the golang list about retiring these. I suppose we
could just wait for it to happen automatically.
Many of these libraries are out of date, but only one of them FTBFS
(according to Koschei), which I'd consider pretty good. Updating these
packages will likely require packaging a bunch of new dependencies. I
think eclipseo has been doing some work on the docker side of things,
though. Thanks for that!
I have been keeping containerd and moby-engine up to date. moby-engine
could use a cleanup. Currently, docker-proxy
(github.com/moby/libnetwork), docker-init (bundled tini-static), dockerd
(github.com/moby/moby), and the docker cli (github.com/docker/cli) are
all part of the moby-engine package. This makes the specfile rather
cumbersome. Ideally, it should be split up. I just haven't had the time
to do so. docker cli should be straightforward.
github.com/moby/libnetwork will soon be merged into
github.com/moby/moby, so docker-proxy doesn't make sense to split out
right now. For docker-init, we should investigate whether we could
configure docker to look for the existing tini-static binary or at least
create a symlink. It expects the binary to be installed to
%{_libexecdir}/docker/docker-init. I am really not a fan of the bundled
tini-static.
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: update libXft to 2.3.6
Sep 18, 2022 Otto Liljalaakso : 18. syyskuuta 2022 1.53.45 GMT+03:00 Thomas Dickey kirjoitti: The release monitoring project for libXft (https://release-monitoring.org/project/1777/) doesn't appear to have noticed the release of 2.3.6 a week ago. Any clues on how to fix this? When I open that link, it shows 2.3.6 as the latest release. Maybe there just was some lag? It says "retrieved on 2022-09-10", though, strange that you still did not see it a week later. I fixed the release-monitoring.org listing earlier but then forgot to update the mailing list. The filtering and version prefix settings were incorrect. Once I sorted that out, the version showed up property. I apologize for the confusion! -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fwd: Fwd: CVE Tracking Bugs
Hi Huzaifa,
Thank you for your response and for getting it to me despite the issues
with the mailing list.
You have to subscribe[1] to the devel list to post to it. There
has been a lot of good discussion about this on the ML since my
original post[2].
I am forwarding this to the list to keep the community in the
loop. I will respond in more detail later.
[1]: https://lists.fedoraproject.org/admin/lists/devel.lists.fedoraproject.org/
[2]:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ETPDV57SDTABYN6P6MGRZWRRCXVFLPZD/
Best,
Maxwell
Forwarded message from Huzaifa Sidhpurwala on Sat Sep 17, 2022:
Hello Max,
Pete tried to send this email to devel list, but it got rejected, so i
thought i will forward this to you directly.
-- Forwarded message -
From: Pete Allor
Date: Wed, Sep 14, 2022 at 6:47 AM
Subject: Fwd: CVE Tracking Bugs
To: Huzaifa Sidhpurwala , Przemyslaw Roguski
, Clifford Perry
Can you all get this email to Maxwell?
-- Forwarded message -
From:
Date: Tue, Sep 13, 2022 at 9:13 PM
Subject: Re: CVE Tracking Bugs
To:
Your message to the devel mailing-list was rejected for the following
reasons:
The message is not from a list member
The original message as received by Mailman is attached.
-- Forwarded message --
From: Pete Allor
To: devel@lists.fedoraproject.org
Cc:
Bcc:
Date: Tue, 13 Sep 2022 20:49:04 -0400
Subject: Re: CVE Tracking Bugs
Maxwell,
One of my folks pointed this post out to me today. From a ProdSec
perspective, you can reach out directly to me.
The PSIRT Team and their work on CVEs report up through me, so I will be
glad to have a discussion with you and why my folks are not supporting you
fully and how to fix that.
I think the main thrust you are pointing to is that as the CNA for Fedora,
we should not be mixing all Red Hat errata into the Fedora project.
Meaning keeping them more separated and distinct. That may not address
all concerns, but I think it would be a good starting point to keep the
focus correct and distinct, not overload on messages and bring attention to
what is critical / important so they are not missed.
I am traveling this week. Can we set a meeting next week to discuss
further?
Pete
***
Hi Fedorians,
I think the security tracking bug filing process needs to be amended. The
current process is quite frustrating for me and other contributors. This
is especially bad for Go CVEs, which there are lot of.
Red Hat Product Security creates a single tracking bug for Fedora{, EPEL}
_and_ all Red Hat products and CCs a bunch of Fedora maintainers. They
then create separate bugs for each package that they deem affected. The
affected packages are oftened determined in a manner that appears
overzealous and arbitrary.
After the bugs are created, we get spammed with a bunch of notifications
about private bugs, RH product errata, and various other things that are
completely irrelevant to Fedora. These messages flood my Bugzilla mailbox
and obscure actual issues that I need to address. I do not really care
whether a Go CVE has been mitigated in Red Hat Advanced Cluster
Management for Kubernetes 2.4 for RHEL 8"
or "Red Hat Advanced Cluster Management for Kubernetes 2.5 for RHEL 8"
or "Red Hat Advanced Cluster Management for Kubernetes 2.6 for RHEL 8."
---
Some particularly egregious examples:
I maintain an Ansible kubernetes collection, and they reported it as
vulnerable to some CVE with a specific Openshift component. The
collection not vulnerable. They provided no actionable information, and
the description was unclear. When I asked why it was reported, they said
that the package "used OpenShift."
A couple Go CVEs ago[^1], they created bugs against hundreds of Go
libraries. They arbitrarily chose branches and packages. The bugs were
not actionable by packagers of individual go libraries. Only applications
that provide binaries need to be rebuilt. They were reported shortly
before the F34 EOL, so we got a huge amount of emails after the bugs were
automatically closed. In fact, a Go packager reported that these messages
from the _security_ team DOSed their mail server. To their credit, they
have fixed this issue after one of the other Go SIG people talked to
them. Now, these bugs are only filed against the golang component.
[^1]: Really, it was a couple Go releases ago. There are multiple CVEs
reported with each Go release these days.
Another time, their automation posted the exact same comment over 200
times.
---
First and foremost, there needs to be a clear way for packagers to report
problems with this process to prodsec.
I don't think Fedora packagers should be CCed on these global trackers.
We could create a separate "Security Response" component under the
"Fedora" Bugzilla product to create tracker bugs for CVEs that affect
multiple Fedora components, or we could ask prodsec to only CC Fedora
maintainers on the child,
Re: Non-responsive maintainer check for golang-github-prometheus-common-devel
Hi Tobias, On Fri Sep 16, 2022, Tobias Zellner wrote: > some weeks ago I opened the bug > https://bugzilla.redhat.com/show_bug.cgi?id=2109630 I commented on your bug and submitted a fix. > Since there is no response to this bug, and following your guide lines > (https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/), > I opend Non-responsive maintainer check f a for this package For the record, the maintainer is fpokorny. Indeed, it seems that maintainer is unresponsive. They haven't had any recent activity in distgit. Other Go SIG members have been maintaining their packages for some time. They are also slated to be removed[1] from the packager group as part of the new Inactive Packager process[2]. This won't actually happen until the end of October, so feel free to continue with the standard Nonresponsive Maintainer process. [1]: https://pagure.io/find-inactive-packagers/issue/222 [2]: https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: CVE Tracking Bugs
On Mon Sep 12, 2022, Vít Ondruch wrote: > > Dne 09. 09. 22 v 17:09 Maxwell G via devel napsal(a): > > On Friday, September 9, 2022 Vít Ondruch wrote: > >> However, I think that the idea is that whatever should be said about the > >> CVE should be said in the main tracer. The fedora tracker should be used > >> just to not forget to fix this in Fedora. > > Why not both? We shouldn't have to reference two different bugs to figure > > out > > what's going on. > > > > > > First of all, what is the information you would like to put to either of > the trackers? Currently, the Fedora trackers contain > This is an automatically created tracking bug! It was created to ensure > that one or more security vulnerabilities are fixed in affected versions > of fedora-all. > > For comments that are specific to the vulnerability please use bugs filed > against the "Security Response" product referenced in the "Blocks" field. > > For more information see: > http://fedoraproject.org/wiki/Security/TrackingBugs > > When submitting as an update, use the fedpkg template provided in the next > comment(s). This will include the bug IDs of this tracking bug as well as > the relevant top-level CVE bugs. > > Please also mention the CVE IDs being fixed in the RPM changelog and the > fedpkg commit message. > > NOTE: this issue affects multiple supported versions of Fedora. While only > one tracking bug has been filed, please correct all affected versions at > the same time. If you need to fix the versions independent of each other, > you may clone this bug as appropriate. while the main bug has the actual description. I'm saying that the description should be copied to the Fedora tracker. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: libFLAC soname bump
On Mon Sep 12, 2022 at 11:29 AM CDT, Michel Alexandre Salim wrote:
> >
> > Would a proven packager be willing to take care of it? The new flac is
> > now built in --target=f38-build-side-58420. libsndfile and audiofile
> > need to be rebuilt next as some of the other packages depend on them.
> >
>
> Sure, what do you need done? Just push an update from that sidetag, or
> actually do some rebuilds as well?
It sounds like they need all of those packages to be rebuilt:
```
$ koji list-tagged f38-build-side-58420
Build Tag Built by
flac-1.4.0-1.fc38 f38-build-side-58420 mlichvar
```
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: CVE Tracking Bugs
On Friday, September 9, 2022 Vít Ondruch wrote: > However, I think that the idea is that whatever should be said about the > CVE should be said in the main tracer. The fedora tracker should be used > just to not forget to fix this in Fedora. Why not both? We shouldn't have to reference two different bugs to figure out what's going on. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: CVE Tracking Bugs
On Thursday, September 8, 2022 Neal Gompa wrote: > Fedora maintainers are CC'd often on the parent bug to bypass the > private bug status while a bug is "under development". This has > happened a few times for me as a maintainer of crypto-adjacent > packages. That's a good point. I guess they could fix that by copying the description into the Fedora bug like Kevin said and/or making those "under development" security bugs private to all Fedora contributors instead of CCing specific people. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
Sep 8, 2022 8:45:19 AM Maxwell G via devel : On Thursday, September 8, 2022 Jaroslav Mracek wrote: First of all we are not going to remove old DNF from the distribution. Isn't that what The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`, and DNF plugins (core and extras). python3-dnf and LIBDNF (`libdnf`, `python3-hawkey`) will be obsoleted by `fedora-obsolete-packages`. says? Sorry, I was unclear. I meant to say that those two statements appear contradictory. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
On Thursday, September 8, 2022 Jaroslav Mracek wrote: > First of all we are not going to remove old DNF from the distribution. Isn't that what > The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`, > and DNF plugins (core and extras). python3-dnf and LIBDNF (`libdnf`, > `python3-hawkey`) will be obsoleted by `fedora-obsolete-packages`. says? -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
CVE Tracking Bugs
Hi Fedorians,
I think the security tracking bug filing process needs to be amended. The
current process is quite frustrating for me and other contributors. This
is especially bad for Go CVEs, which there are lot of.
Red Hat Product Security creates a single tracking bug for Fedora{, EPEL}
_and_ all Red Hat products and CCs a bunch of Fedora maintainers. They
then create separate bugs for each package that they deem affected. The
affected packages are oftened determined in a manner that appears
overzealous and arbitrary.
After the bugs are created, we get spammed with a bunch of notifications
about private bugs, RH product errata, and various other things that are
completely irrelevant to Fedora. These messages flood my Bugzilla mailbox
and obscure actual issues that I need to address. I do not really care
whether a Go CVE has been mitigated in Red Hat Advanced Cluster
Management for Kubernetes 2.4 for RHEL 8"
or "Red Hat Advanced Cluster Management for Kubernetes 2.5 for RHEL 8"
or "Red Hat Advanced Cluster Management for Kubernetes 2.6 for RHEL 8."
---
Some particularly egregious examples:
I maintain an Ansible kubernetes collection, and they reported it as
vulnerable to some CVE with a specific Openshift component. The
collection not vulnerable. They provided no actionable information, and
the description was unclear. When I asked why it was reported, they said
that the package "used OpenShift."
A couple Go CVEs ago[^1], they created bugs against hundreds of Go
libraries. They arbitrarily chose branches and packages. The bugs were
not actionable by packagers of individual go libraries. Only applications
that provide binaries need to be rebuilt. They were reported shortly
before the F34 EOL, so we got a huge amount of emails after the bugs were
automatically closed. In fact, a Go packager reported that these messages
from the _security_ team DOSed their mail server. To their credit, they
have fixed this issue after one of the other Go SIG people talked to
them. Now, these bugs are only filed against the golang component.
[^1]: Really, it was a couple Go releases ago. There are multiple CVEs
reported with each Go release these days.
Another time, their automation posted the exact same comment over 200
times.
---
First and foremost, there needs to be a clear way for packagers to report
problems with this process to prodsec.
I don't think Fedora packagers should be CCed on these global trackers.
We could create a separate "Security Response" component under the
"Fedora" Bugzilla product to create tracker bugs for CVEs that affect
multiple Fedora components, or we could ask prodsec to only CC Fedora
maintainers on the child, package-level bugs. I guess I could acomplish
what I'm proposing by filtering out mails with "X-Bugzilla-Product:
Security Response" headers and not have gone on this rant, but I still
think this needs to be addressed.
Does anyone know how to reach prodsec about this?
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
Aug 29, 2022 1:32:21 PM Ben Cotton : https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2 == Summary == Cryptographic policies will be tightened in Fedora ''38''-39, SHA-1 signatures will no longer be trusted by default. Fedora ''38'' will do a "jump scare", introducing the change but then reverting it in time for Beta. Test your setup with TEST-FEDORA39 today and file bugs in advance so you won't get bit by Fedora ''38''-39. I think this is a bad idea. It's quite hostile to packagers. It will break rawhide for months and make it very difficult to stabilize the distro before the beta freeze or do any type of rebuild. It very well may affect other Changes. It will still cause untold problems even if you revert it before the beta freeze. Please test this in COPR (as Miro already said) or somewhere else instead of destabilizing the distro. You can analyze the COPR failures and report bugs just like the Python SIG does for new Python major versions. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Tuesday, September 6, 2022 Vitaly Zaitsev via devel wrote: > > mobile device > > Requires proprietary Google services. As has already been said, that's not true. Google Authenticator is far from the only software that supports the TOTP standard. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Tuesday, September 6, 2022 Michael Catanzaro wrote: > Currently I do not have any 2FA enabled > on my Fedora account I have 2FA set up on my account and it works okay. You'd use `fkinit` instead of `kinit` that requires special setup[1] to work with 2FA. It doesn't work with the GOA kerberos integration. When authenticating with Fedora online services, there's a field for the token just like on any other site that supports 2FA. > because there's no way to disable it once enabled, > and I'm afraid something will break, so I'm not brave enough to opt in. > I highly doubt I'm alone here. I'd guess that Infrastructure could disable it for you if you enable it and then change your mind. [1]: https://fedoraproject.org/wiki/Infrastructure/ Kerberos#How_to_use_kerberos_auth_with_Fedora_Infrastructure -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Tuesday, September 6, 2022 Vitaly Zaitsev via devel wrote: > If > you want to enforce such a policy, find sponsors and buy devices for all > Fedora contributors. I kind of agree with this. See what PyPi is doing[1]. I don't think anyone who maintains one package should get one, but perhaps provenpackagers or those who maintain more than X packages should be required to have *some kind* of MFA enabled. [1]: https://pypi.org/security-key-giveaway/ -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [EPEL-devel] EPEL: packaging multiple versions and compat packages
On Monday, September 5, 2022 Mark E. Fuller wrote: > Can someone point me to a good resource on how (if permitted) I can make > appropriate compat(?) packages to allow for two major versions of the > same package to be available? > Is this allowed for EPEL? You can package compat packages as long as they don't conflict with anything in RHEL. EPEL packages may conflict with other EPEL packages, however. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Monday, September 5, 2022 Peter Robinson wrote: > it would probably be easier to join and become a packager by > packaging a random leaf package no one would use, then as a packager > pick up an random orphaned package that's in the core distro and then > just compromise the distro that way TBH. They wouldn't even need to pick up a core package. "Supplements: kernel" would get them far enough... -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Conditional Patch line
On Monday, September 5, 2022 Richard W.M. Jones wrote:
> I have a downstream patch[0] which -- I don't really understand why --
> breaks riscv64 builds but is necessary for primary Fedora arches. Is
> it correct to do:
>
> %ifnarch riscv64
> Patch123: downstream.patch
> %endif
>
> given that the package uses %autosetup and therefore doesn't have
> explicit %patch lines.
>
> I think this means that if I build the SRPM on riscv64 then the
> downstream patch wouldn't be included, meaning that SRPM would then
> fail to build on other arches. In this particular case that doesn't
> matter, but it feels wrong. Is there a recommended way to do this
> (apart from fixing the patch)?
Yes, conditionalizing Source or Patch lines is a bad idea. This exact case is
explicitly forbidden by the guidelines[1]. There is also a guidelines PR to
forbid any type of Source/Patch conditionaliztion[2].
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/
#_no_arch_specific_sources_or_patches
[2]: https://pagure.io/packaging-committee/pull-request/1163
If you don't want to add %patchX for every Patch, you can use regular `%setup
-q` together with %autopatch, which allows more granular control than
`%autosetup`.
>From /usr/lib/rpm/macros:
```
# Apply patches using %autosetup configured SCM.
# Typically used with no arguments to apply all patches in the order
# introduced in the spec, but alternatively can be used to apply indvidual
# patches in arbitrary order by passing them as arguments.
# -vVerbose
# -p Prefix strip (ie patch -p argument)
# -m Apply patches with number >= min only (if no arguments)
# -M Apply patches with number <= max only (if no arguments)
%autopatch(vp:m:M:) %{lua:
```
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: How to get a new gilab.com/fedora sub-project?
Sep 3, 2022 4:18:19 AM Miro Hrončok : We'd like to move https://gitlab.com/fberat/mass-prebuild/ into the Fedora namespace, ideally under something like: https://gitlab.com/fedora/packager-tools/ What do we need to do? Hi Miro, You have to file an infra ticket. See [1]. It would be nice if we could change the process to be more self-service (i.e. give Fedora contributors permissions to do this themselves). That could come along with guidelines of what may be put under the Fedora namespace and how subgroups should be organized. [1]: https://pagure.io/fedora-infrastructure/issues?search_pattern=Gitlab=all -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Non-responsive maintainer check for olem
On Friday, September 2, 2022 Dusty Mabe wrote: > > Side note: I have asked for co-maintainers for those packages a couple > > times, but so far, I have not found any. Perhaps one of the CoreOS people > > would be interested? It seems those packages are used a lot there based > > on the bug reports we've gotten. > > Interesting. I opened an issue for us to discuss: > https://github.com/coreos/fedora-coreos-tracker/issues/1291 Thank you! I left to a comment to add more context. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Non-responsive maintainer check for olem
Sep 2, 2022 5:36:41 AM Fabio Valentini : Does anybody know whether olem still wants to maintain their Fedora packages? I'm fairly sure that they no longer wish to maintain Fedora packages. I reached out to them about moby-engine and containerd at the end of May, and they said they no longer have time to maintain them. I have been maintaining those packages myself for a while. Side note: I have asked for co-maintainers for those packages a couple times, but so far, I have not found any. Perhaps one of the CoreOS people would be interested? It seems those packages are used a lot there based on the bug reports we've gotten. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Minizip renaming (Self-Contained Change proposal)
On 22/08/30 05:57PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Aug 15, 2022 at 05:04:27PM -0400, Ben Cotton wrote:
> > == Detailed Description ==
> > Upstream has changed the naming of the "minizip" package to
> > "minizip-ng" and we should follow their naming so there is no
> > confusion about which package is the right one. Upstream has also
> > requested to rename the "minizip-compat" zlib subpackage to "minizip"
> > which is the right naming for the package.
> >
> > The "minizip" and "minizip-compat" provides different shared libraries
> > which prevent us from conflicting sonames.
> >
> > The plan behind this change can be put into x steps which will be
> > completed separately and in the given order:
> >
> > ''NOTE: All of the Provides and Obsoletes will be added to the *-devel
> > subpackages as well.''
> >
> > 1) Create a new package "minizip-ng" which will `Provides: minizip =
> > %{sameevr}` and `Obsoletes: (minizip < 3.0.2-7 and minizip > 3.0.0-1)`
>
> Hi,
>
> it seems that Obsoletes does not work with boolean dependencies,
> so the proposed for would not work.
Correct. And even if it did work, you'd want to use the "with" operator
not "and."
> Instead, please use the standard form described by the Packaging
> Guidelines:
> Obsoletes: minizip < 3.0.3
That also won't work. If minizip-ng "Obsoletes: minizip < 3.0.3" and the
new minizip package (the current minizip-compat) is 1.2.12-5, it will
get Obsoleted by minizip-ng, which is unwanted. I would suggest adding
"Epoch: 1" to the new minizip package (current minizip-compat) so it
sorts above 3.0.3.
You also shouldn't add "Provides: minizip = %{sameevr}`" to minizip-ng.
It will break parallel installability with the new minizip package. Just
wait to retire the current minizip (the one that's becoming minizip-ng)
until step 2 has been completed.
> > 2) Rebuild all of the packages that BuildRequire/Require "minizip"
> > package to BuildRequire/Require new "minizip-ng" package
Who will be doing this? How will it be done?
> > 3) Retire the "minizip" package following the
> > [https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/
> > Package Retirement Process]
> >
> > 4) Wait for the Fedora 40 when it's ensured that every user has
> > updated at least to the Fedora 38. Remove the `Provides` and
> > `Obsoletes` from the "minizip-ng" package
>
> FWIW, I prefer to keep those for a while. We don't officially support
> this, but people do upgrades over more than two versions quite often,
> and it's nice not to break that.
I agree. If you use the approach I outlined above, removing the
the Obsoletes won't be necessary in order to rename minizip-compat to
minizip.
> > 5) Rename the "minizip-compat" to the "minizip" package and add
> > `Provides: minizip-compat = %{sameevr}` and `Obsoletes: minizip-compat
> > < 1.2.12`
>
> As already mentioned in the original discussion thread, this step is
> risky. We generally try to follow upstream naming on packages, but
> sometimes it's not possible for various technical reasons. This seems
> to be one of those cases, because limitiations of Obsoletes mean that
> we can't obsolete a subset of package versions.
If you use the Epoch approach, this wouldn't be an
issue. Also, what's the idea of waiting to do step 5 until Fedora 40?
> Minizip-compat is not intended to be used by anything in the
> distribution, so it's not a big deal if the package name is "wrong".
> Thus, I think it's better to skip this last step and tell minizip
> upstream that the we'll keep the "-compat" name for compatiblity
> reasons. Maybe add a sentence of explanation to the package name.
I agree. While it's possible to overcome the technical hurdles, this
whole Change seems like more headache than its worth. Kevin and I had to
deal with a similar situation of Obsoletes and Provides and boolean
Requires with the ansible -> ansible-core split, and it's been a huge
pain. This change is probably more complicated than that. It's likely
that I've confused something in this email given the complexity of a
renaming like this
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: problem creating a kernel module rpm package
On Sunday, August 28, 2022 Jerry Kiely wrote: > I did remove it and got the following result: > > rfpkg mockbuild -N --root fedora-36-x86_64-rpmfusion_free > sources file doesn't exist. Source files download skipped. > Failed to get repository name from Git url or pushurl > Failed to get ns from Git url or pushurl > Could not execute mockbuild: > /home/jerry/Workspace/Research/RPM/Modules/hid-ite8291r3-kmod is not a > valid repo > Try `spectool -g NAME_HERE.spec` and then rerun the rfpkg command. You have to download the sources to build the package. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
ansible-collection-community-mysql License Change
Hi Fedorians, The license of ansible-collection-community-mysql has been updated from "GPLv3+ and Python" to "GPL-3.0-or-later AND PSF-2.0 AND BSD-2-Clause". See https://src.fedoraproject.org/rpms/ansible-collection-community-mysql/c/242bcaa709334c0a5ec0d78d1a2da3daaae532ce?branch=rawhide. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: CPE Weekly Update - Week 34 2022
Aug 26, 2022 7:02:06 AM Michal Konecny : If you want to receive weekly reports by emails in the future, please subscribe to either https://communityblog.fedoraproject.org/ or https://discussion.fedoraproject.org/c/news/commblog/61. We will stop sending them in the future. Why is that? I appreciate getting the updates as a clean, plain text email that doesn't require clicking external links to read. Also, I'd venture that not every CentOS person is interested in the Fedora blog or forums. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
More Ansible license changes
Hi Fedorians, I'm back with more ansible license updates. Upstream, some of the community Ansible Collections have adopted the REUSE specification, which makes it much easier to determine the overall license. For collections that have adopted this, the license texts are all stored as files in one directory, instead of being spread out throughout the source tree as file headers. I would like to thank the upstream developers for working with me on this. The License tag of ansible-collection-community-general has changed from "GPLv3+ and BSD and Python" to "GPL-3.0-or-later AND BSD-2-Clause AND PSF-2.0 AND MIT". See https://src.fedoraproject.org/rpms/ansible-collection-community-general/pull-request/8. The License tag of ansible has changed from "GPLv3+" to "GPL-3.0-or-later AND Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND MIT AND MPL-2.0 AND PSF-2.0". I cannot claim this to be 100% accurate, but I have done my best to determine the overall license. Note that ansible is a curated bundle of 103 Ansible collections, so this task is a bit difficult. See https://src.fedoraproject.org/rpms/ansible/pull-request/32. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: sqlcipher soname change in rawhide
On Thursday, August 25, 2022 Carl George wrote:
> [root@f38-container:~]# repoquery --repo
> rawhide-source,rawhide-modular-source \
> > --quiet --queryformat '%{name}' --archlist src --whatrequires
> > sqlcipher-devel
> libgda
> python-peewee
> sqlitebrowser
> [root@f38-container:~]# repoquery --repo
> rawhide-source,rawhide-modular-source \
> > --quiet --queryformat '%{name}' --archlist src --whatrequires
> > 'pkgconfig(sqlcipher)'
> kmymoney
> rust-libsqlite3-sys
> skrooge
You do not need to separately query for the Provides like this. If you
keep the regular repository enabled and filter out the src packages
after, the Provides are queried, as well.
$ sudo dnf repoquery --repo=rawhide{,-source} -q --whatrequires sqlcipher-devel
| grep '\.src$' | pkgname | sort -u
kmymoney
libgda
python-peewee
rust-libsqlite3-sys
skrooge
sqlitebrowser
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: GNOME's Icon Development Kit icons potentially causing implicit conflicts
On Tuesday, August 23, 2022 Elliott Sales de Andrade wrote: > > The CC0 has been banned for new packages in Fedora. > > Banned for code, not content. Icons are not code. Good point! Thanks for the correction. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GNOME's Icon Development Kit icons potentially causing implicit conflicts
On Tuesday, August 23, 2022 Lyes Saadi wrote: > Fortunately, Icon Development Kit is under CC0, so we're kinda saved > from a Licensing apocalypse (although, I have to admit that this is not > ideal). The CC0 has been banned for new packages in Fedora. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 side tag after branching point
On Tuesday, August 23, 2022 1:16:00 PM CDT Iñaki Ucar wrote: > We have a new R version sitting on a side tag (f37-build-side-55653) > for a few weeks now, where packages are being rebuilt as time permits. Can this perhaps be handled differently next time? I admit that I'm not familiar with the R ecosystem, so the answer may be no. Side tags are not meant to be open for this long. So far, this R rebuild has caused a lot of problems (see "The R stack in Rawhide is on fire"). What are the issues that prevent the rebuild from happening all at once? Can it be staged in COPR to make sure nothing will break? Can the packages be built all at once with a script? > Unfortunately, F37 is not rawhide anymore, so the question is whether > this side tag could be safely merged both in F37 and rawhide when it > is ready. I'll defer to the releng folks, but I think you should be able to merge the sidetag normally through the Bodhi interface, though it will be for f37 and not rawhide. You'll have to rebuild everything in rawhide. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
python-ntlm-auth License Correction
I've corrected the license of python-ntlm-auth from LGPLv3+ to MIT. It was relicensed upstream 5 years ago, but the previous maintainer never updated the License field. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intent to retire: novacom-client, novacom-server
On Tuesday, August 16, 2022 Jonathan Dieter wrote: > So, unless I hear from someone who wants it within the next week and > has a plan on how to fix the current FTBFS bug[2], on August 23, I will > retire novacom-client[3] and novacom-server[4]. I would suggest just orphaning the packages. This way, anyone can pick up the packages themself through the src.fp.o web interface. The packages will get automatically retired in six weeks if nobody claims them. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Updating several packages to SPDX
Do Callway > SPDX license changes where there's a clear mapping and no other additions or removals still have to be announced? That wasn't my understanding. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Important changes to software license information in Fedora packages (SPDX and more!)
Kevin Kofler via devel wrote: > Now you have to compare every word of the MIT license > with the very similar templates such as MIT, MIT-CMU, MIT-feh, etc., and > then figure out which one it actually is. If it is even one of these and not > some random mix of several variants (one sentence from here, one sentence > from there, …). You're right. MIT/BSD License variants are a pain to deal with. In practice, they are mostly equivalent, so having to identify is a burden without a lot of benefit. Currently, there's MIT variants such as the HPND that aren't even part of the new license list, despite being explicitly listed on the old list and being used by packages like libX11[1]. As that license deprecated, it's not likely to cause issues when importing new packages, but it is still used by older packages. There are other examples of licenses missing from the new list that are already blocking new packages[2]. [1]: https://gitlab.com/fedora/legal/fedora-license-data/-/issues/1#note_969573331 [2]: https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/12#note_1045611169 > But that is how things work in practice. It is just impossible to read > through every source file and scan for copied snippets. They can even appear > in the middle of a file, with the license attached right there. So the > packager and the reviewer will both check the COPYING/LICENSE/LICENCE file > provided by upstream, then go exemplarily through a handful source files to > check that the copyright header and/or SPDX REUSE header matches that > license, and then declare that as the one License. This is onerous if you do it manually, but there are tools to make it a bit easier. You can use scancode-toolkit or licencecheck to scan the entire codebase. I believe the RH legal folks recommended the former at some point, but licensecheck is used by fedora-review and actually packaged in Fedora[^1]. The Legal docs recommend SPDX license-diff[3] and [4] to see if a certain license text exists in SPDX. [^1]: I wish luck to anyone who tries to package tries to package scancode. There are quite a few unpackaged dependencies... [3]: https://addons.mozilla.org/en-US/firefox/addon/spdx-license-diff/ [4]: https://tools.spdx.org/app/check_license/ -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedora-legal-list] Re: Important changes to software license information in Fedora packages (SPDX and more!)
On 22/07/31 12:57PM, Richard Fontana wrote: > I can go into why I don't think it's worthwhile, if there's interest. Feel free to go into more details if you'd like :). -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedora-legal-list] Important changes to software license information in Fedora packages (SPDX and more!)
On 22/07/29 11:19AM, Matthew Miller wrote: > New docs site for licensing and other legal topics > -- > > All documentation related to Fedora licensing has moved to a new > section in Fedora Docs, which you can find at: > > https://docs.fedoraproject.org/en-US/legal/ > Fedora license information in a structured format > - > > The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are > now stored in a repository, using a simple structured file format for > each license (it’s TOML). You can find this at: > > https://gitlab.com/fedora/legal/fedora-license-data > > This data is then presented in easy tabular format in the > documentation, at: As part of this change, the data on which licenses are GPL-compatible seems to have been removed. Other projects were relying on this (e.g. [1]). Are there any plans to add it back? [1]: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#id5 -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: HTTP 500 - https://admin.fedoraproject.org/accounts/
On 22/07/28 12:06PM, Andrew Bauer wrote: > The backend server that is hosting admin.fedoraproject.org/accounts/ is > throwing an HTTP 500 SSL handshake error. I would recommend filing an infra ticket: https://pagure.io/fedora-infrastructure/new_issue. devel@ is not the correct place to report issues like this. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Upstream Release Monitoring - bug report
On 22/07/26 09:54AM, Kevin Fenzi wrote: > If you want to watch activity on a package you want The little 'watch' > pulldown under The package description. You can set there if you want to > watch bugs, commits, both, etc. If you only wanted to watch koji builds, > you would need to set that in FMN (apps.fedoraproject.org/notifications) Neither FMN nor the "Watch commits" button on src.fp.o work for me. FMN just shows a page to set my contact information with no way to create filters; the "Watch commits" option doesn't work on src.fp.o (i.e. it doesn't send notifications for new commits) despite working on pagure.io. I believe the FMN brokenness has something to do with my account not existing in the old FAS2 instance, but I'm not sure about the src.fp.o issue. Is it some deliberate configuration difference or a bug? -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Heads-up: ODE soname bump
On 22/07/24 06:05PM, Kalev Lember wrote: > If ODE 0.16 was only built as part of the mass rebuild and wasn't > available in the buildroot during the mass rebuild (and I don't think > it was), then all the other packages that depend on it were still > built against the older ODE 0.14 version as part of the mass rebuild. > Once the mass rebuild is merged back into f37 then all other packages > that depend on ODE are going to have broken dependencies. That indeed appears to be the case. The f37-rebuild build target[1] builds against f37-build but tags completed builds into f37-rebuild. ode-0.16.2-2.fc37[2] is only tagged into f37-rebuild. [1]: https://koji.fedoraproject.org/koji/buildtargetinfo?targetID=24581 [2]: https://koji.fedoraproject.org/koji/buildinfo?buildID=2016899 Also, looking at ompl, one of ode's dependents, you can see that it was rebuilt against the old version of ode: > DEBUG util.py:445: ode-devel x86_64 > 0.14-15.fc36 build 66 k -- https://kojipkgs.fedoraproject.org//packages/ompl/1.5.0/11.fc37/data/logs/x86_64/root.log and https://koji.fedoraproject.org/koji/buildinfo?buildID=2016925https://koji.fedoraproject.org/koji/buildinfo?buildID=2016925 In order to fix this, a provenpackager will need to build all of the dependents in a sidetag like normal. Preferably, this could happen before the mass rebuild tag is merged back into f37. I am a bit busy today, but I suppose I could do this later if nobody beats me to it. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Retiring the pcre package from Fedora
(It seems my previous message didn't send properly...)
On 22/07/22 10:24PM, Fabio Valentini wrote:
> the script that determines leaf packages in the Rust SIG
Can you provide a link to this?
> $ (dnf repoquery --whatrequires pcre ; dnf repoquery --whatrequires
> pcre-cpp ; dnf repoquery --whatrequires pcre-devel ; dnf repoquery
> --whatrequires pcre-static ; dnf repoquery --whatrequires pcre-tools ;
> dnf repoquery --whatrequires pcre-utf16 ; dnf repoquery --whatrequires
> pcre-utf32) | sort | uniq | grep src
It's actually possible to pass --whatrequires mutliple times with all of
the dependencies, instead of running multiple queries. e.g.:
sudo dnf repoquery --whatrequires pcre --whatrequires pcre-cpp --whatrequires
pcre-devel --whatrequires pcre-static --whatrequires pcre-tools --whatrequires
pcre-utf16 --repo=rawhide{,-source} -q | grep '\.src$' | sort | uniq
This is quite a bit faster. I only just recently learned this, so I
thought I'd pass it on :).
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
repoquery-fu (was Re: Retiring the pcre package from Fedora)
On 22/07/22 10:24PM, Fabio Valentini wrote:
> the script that determines leaf packages in the Rust SIG
Can you provide a link to this?
> $ (dnf repoquery --whatrequires pcre ; dnf repoquery --whatrequires
> pcre-cpp ; dnf repoquery --whatrequires pcre-devel ; dnf repoquery
> --whatrequires pcre-static ; dnf repoquery --whatrequires pcre-tools ;
> dnf repoquery --whatrequires pcre-utf16 ; dnf repoquery --whatrequires
> pcre-utf32) | sort | uniq | grep src
It's actually possible to pass --whatrequires mutliple times with all of
the dependencies, instead of running multiple queries. e.g.:
sudo dnf repoquery --whatrequires pcre --whatrequires pcre-cpp --whatrequires
pcre-devel --whatrequires pcre-static --whatrequires pcre-tools --whatrequires
pcre-utf16 --repo=rawhide{,-source} -q | grep '\.src$' | sort | uniq
This is quite a bit faster. I only just recently learned this, so I
thought I'd pass it on :).
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora 37 mass rebuild started
On 22/07/22 09:08AM, Michael J Gruber wrote: > notmuch failed to build from source because of a strange test suite failure > on ppc64le: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=89837091 > > The only failing test is a pytest run on the bindings > > ``` > T391-python-cffi: Testing python bindings (pytest) > FATAL: /builddir/build/BUILD/notmuch-0.36/test/T391-python-cffi.sh: > interrupted by signal 15 > ``` > > whereas other tests of those bindings work. What makes it even more strange > is that for a scratch build all tests work on all architectures: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=89853627 > > Is there possibly a timing issue where tests on ppc64le happen to take "too > long" and pytest gets killed? It sounds like this might've been a transient issue, likely related to something on the builder, as it also worked fine when I scratch built it. The releng folks can probably tell you how to handle this and if you should rebuild it, just wait, or whatever. As Kevin said: > You can contact releng in #fedora-releng channel on Libera.Chat, the > #releng:fedoraproject.org room on Matrix, or by dropping an email to > our list[2] or filing an issue in pagure[3]. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: ANTLR packages and i686
(Sorry for the messed up line wrapping. I wanted to get this out.)
Hi Jerry,
On 22/07/06 08:13PM, Jerry James wrote:
> - golang-github-google-cel (eclipseo, @go-sig): needs the Go runtime
> from the antlr4-project package
> - golang-google-grpc (eclipseo, @go-sig): needs
> golang-github-google-cel. Is consumed by a TON of other Go packages,
> so many that I did not attempt to trace them.
I'm replying as a member of the go-sig, as the primary maintainer is pretty
busy lately.
At least 289 source packages (recursively) BuildRequire
golang-github-google-cel-devel[1]. Some of these packages only provide
`-devel` subpackages that should've been included in the above query, but
there are likely also some that provide binaries that could be used by other
packages (go or otherwise; runtime and/or buildtime). The dependents of those
packages aren't included in the count above. I am
working on querying for those packages and asking maintainers to remove the
leaves.
The go-sig is also considering entirely removing go stack from i686, but
we have not made a lot of progress yet. My preference would be to wait
to remove all go packages from there by removing %ix86 from
%golang_arches instead of adding `ExcludeArch: %ix86` to just the golang
packages that need golang-antlr4-runtime-devel. Non go packages can probably be
`ExcludeArch`ed first.
Please do not remove golang-antlr4-runtime-devel until we've dealt with
at least the packages affected by removing this one. I understand that this
probably
isn't the answer you want to hear. We are in a similar situation; we'd like to
remove the go stack from i686, as it adds extra maintenance burden, but
there are other packages that depend on go stuff that need to be dealt with
first (and some go packages that don't follow the packaging guidelines and are
missing ExclusiveArch: %{golang_arches}`).
[1]: sudo dnf repoquery --repo=rawhide{,-source} --recursive --whatrequires |
grep '\.src$' | pkgname | sort | uniq
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Golang Mass Rebuild
On 22/07/17 09:57PM, Maxwell G wrote: > golang 1.18.4 was released a couple days ago. This release has fixes for > 9 medium (rated by Red Hat Product Security) CVEs, so I will preform a > rebuild in `rawhide` and `f36` to mitigate them[^0]. See > https://groups.google.com/g/golang-dev/c/frczlF8OFQ0/m/4lrZh5BHDgAJ for > more information about the specific vulnerabilities. I am planning to handle the rebuild today, as I'd like to have it done before the F37 Mass Rebuild. As discussed, this will not affect rawhide, only f36. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Announcing fmt library soversion bump
On 22/07/19 02:22PM, Vitaly Zaitsev via devel wrote: > Now it can be easily mitigated by using fmt8-devel. > > Rawhide compose will be fixed automatically soon, as fmt8 provides missing > libfmt.so.8 shared library. Yes, the *compose*, but those packages will still need to be fixed to not FTBFS. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Golang Mass Rebuild
Hi Tomáš, Jul 18, 2022 1:42:30 AM Tomas Hrcka : > Fedora release engineering is running a mass rebuild of rawhide on 20.6., if > your changes are merged in rawhide/main branches by then, they will be > included. Indeed. The distro-wide mass rebuild has been in the back of my mind, but I'm not sure why I didn't think about it more when planning this. I will still do the "Rebuild for golang..." changelog bump on rawhide for the f36 mergable packages[^1], but I won't actually submit the builds to avoid duplicating work and disrupting the F37 Mass Rebuild. [^1]: If you all couldn't already tell, I really don't like dealing with changelog/release related merge conflicts, so I try to avoid them when making mass changes :). -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Golang Mass Rebuild
Hi Fedorians and Gophers, golang 1.18.4 was released a couple days ago. This release has fixes for 9 medium (rated by Red Hat Product Security) CVEs, so I will preform a rebuild in `rawhide` and `f36` to mitigate them[^0]. See https://groups.google.com/g/golang-dev/c/frczlF8OFQ0/m/4lrZh5BHDgAJ for more information about the specific vulnerabilities. [^0]: The golang version is Fedora 35 is EOL upstream, and the maintainers have not yet had a chance to backport the changes. Only packages that provide binaries need to be rebuilt, which will make this rebuild less disruptive. These packages were determined by querying for source packages that BuildRequire `golang` or `go-rpm-macros` and then checking if they provide any binary RPMS that install files in `/usr/bin`, `/usr/sbin`, or `/usr/libexec`. No action will be required from you, unless you'd like your package to receive special treatment regarding merging `rawhide` into `f36`. I plan to handle this rebuild later this week (the week of the 17th). In light of the recent discussion about large updates, I will most likely split this into 4 Bodhi updates per branch (a total of 8; each containing ~100 packages). ## rawhide Here[1] is a list of the affected packages on `rawhide`. [1]: https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/rebuilds/golang_1.18.4/rawhide/lists/all-packages.list ## f36 Here[2] is a list of all of the affected packages on `f36`. However, I have further split this list down into two subgroups. [2]: https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/rebuilds/golang_1.18.4/f36/lists/all-packages.list ### Mergable from Rawhide For these packages[3], `rawhide` was determined to be mergable back to `f36`, as `f36` is up to date with `rawhide`. [3]: https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/rebuilds/golang_1.18.4/f36/lists/mergable.list ### Not mergable These packages were determined to not be mergable[4], as `rawhide` is ahead of (or has otherwise diverged from) `f36`. Therefore, I will create a new rebuild commit and bump the release on `f36`. This will likely cause merge conflicts if you try to merge `rawhide` back into `f36` after this change. Assuming the update would be compatible and comply with the Updates Policy, I can move your package into the other list and merge `rawhide` into `f36`. Please leave a comment on https://pagure.io/GoSIG/go-sig/issue/44 if you would like me to do so. Conversely, if you believe your package is incorrectly in the mergable list, also let me know in the aforementioned ticket. [4]: https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/rebuilds/golang_1.18.4/f36/lists/unmergable.list -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Non-responsive maintainer-like policy for approved packages that aren't imported?
On 22/07/14 03:29PM, Mark E. Fuller wrote: > Can anyone advise as to what the policy should be when a package is reviewed > and approved but never imported? I already answered Mark's question on Matrix, but for the benefit of everyone else, there is a policy here: https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/#stalled -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Announcing fmt library soversion bump
On 22/07/14 07:32PM, Vitaly Zaitsev via devel wrote:
> On 11/07/2022 18:21, Ben Beasley wrote:
> > I don’t believe this list is nearly complete. Two packages I maintain
> > that would be affected (fmidi and giada) are absent from the list.
>
> It's very strange:
>
> $ dnf repoquery -q --releasever=rawhide --disablerepo="*" --qf="%{name}"
> --enablerepo=fedora-source --enablerepo=updates-source
> --enablerepo=updates-testing-source --archlist=src
> --whatrequires="fmt-devel"
Use the command from
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/X5MOIWN3TTUOOUKVV545SYNSOS7SJWQW/.
If you only enable the *-source repositories, it won't include
fmt-devel's virtual Provides.
```
$ diff -u <(echo "0ad
OpenImageIO
cantera
ceph
dolphin-emu
domoticz
folly
libsonata
mkvtoolnix
sdrpp
spdlog
vcpkg
zswap-cli" | sort) <(sudo dnf repoquery --repo=rawhide{,-source} -q
--whatrequires fmt-devel | grep '\.src' | pkgname | sort | uniq)
--- /proc/self/fd/122022-07-14 12:51:17.366920423 -0500
+++ /proc/self/fd/132022-07-14 12:51:17.366920423 -0500
@@ -1,13 +1,27 @@
0ad
+bear
cantera
ceph
dolphin-emu
domoticz
+easyeffects
+easyrpg-player
+fcitx5
+fcitx5-chinese-addons
+fcitx5-gtk
+fcitx5-m17n
+fcitx5-zhuyin
+fmidi
folly
+giada
+libsemigroups
libsonata
mkvtoolnix
+ntfs2btrfs
OpenImageIO
sdrpp
spdlog
vcpkg
+waybar
zswap-cli
+zxing-cpp
$ sudo dnf repoquery --repo=rawhide-source -q --requires bear | grep fmt
cmake(fmt)
```
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Shall we add a limit to number of packages in a Bodhi update?
Jul 13, 2022 1:13:38 PM Adam Williamson : > If they need to be rebuilt for an API/ABI change, then by policy they > should be grouped together. We do not want a situation where the > API/ABI change gets pushed stable but some of the rebuilds do not, or > vice versa. We're not talking about ABI/API changes. This about the recent rebuilds we've done to fix CVEs in golang/the surrounding libraries. golang/the libraries are only needed at buildtime and the binaries are statically linked, so it doesn't matter if everything is pushed at exactly the same time. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Shall we add a limit to number of packages in a Bodhi update?
On 22/07/13 07:49PM, Fabio Valentini wrote: > I wonder if it would have made sense to have submitted those 300+ > builds in separate bodhi updates (at least in several smaller batches, > if not individually)? > At least in this case, that would've been a little bit more work, but > would have caused less of a chance to break bodhi. > As far as I can tell, there's no reason the builds need to be handled > together, as the only thing that ties these builds together is the > *reason* why they were rebuilt, but they don't necessary need to be > pushed to testing or stable as a single unit. You're right. They don't have to be rebuilt together as long as the patched version of golang/the libraries with CVEs are in the buildroot. I decided to handle them as a single update to make it easier to manage/organize. I don't want to have to manage 300+ different updates and have my Fedora mailbox flooded with notifications from them. The RH prodsec team already does a good enough job at flooding my inbox :(. It probably wouldn't be too much effort to split them into multiple batches, though. --- Also, there was a new golang version released today that has fixes for 9 CVEs, so I will probably have to do another rebuild in F36 and Rawhide. It would be helpful if we could come to a conclusion about how to handle this properly sooner rather than later. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Script to get all deps of a package (for soname bumps etc.)
On 22/07/13 05:35PM, Ankur Sinha wrote:
> > This is what we (I) aren't sure of, and that's why I first obtain the
> capabilities manually and then query for them. If someone can confirm
> that this is indeed the case, that would certainly simplify things.
Here is confirmation:
```
sudo dnf repoquery --repo=rawhide{,-source} -q --whatrequires
python3-setuptools | grep '\.src' | grep yt-dlp
yt-dlp-0:2022.06.29-2.fc37.src
$ sudo dnf repoquery --repo=rawhide-source -q --requires yt-dlp | grep
setuptools
python3dist(setuptools) >= 40.8
```
yt-dlp depends on one of `python3-setuptool`'s virtual provides, and it is still
found when using the command I gave to find which packages BuildRequire
a certain other package. This also works when querying runtime
dependencies:
```
$ sudo dnf repoquery -q --repo=rawhide --requires reuse | grep setuptools
python3.11dist(setuptools)
$ sudo dnf repoquery -q --repo=rawhide --whatrequires python3-setuptools | grep
reuse
reuse-0:1.0.0-2.fc37.noarch
```
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
