Fedora rawhide compose report: 20230202.n.1 changes
OLD: Fedora-Rawhide-20230202.n.0 NEW: Fedora-Rawhide-20230202.n.1 = SUMMARY = Added images:3 Dropped images: 3 Added packages: 1 Dropped packages:0 Upgraded packages: 82 Downgraded packages: 1 Size of added packages: 54.41 KiB Size of dropped packages:0 B Size of upgraded packages: 3.50 GiB Size of downgraded packages: 198.81 MiB Size change of upgraded packages: 19.93 MiB Size change of downgraded packages: -10.67 MiB = ADDED IMAGES = Image: LXQt live aarch64 Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-Rawhide-20230202.n.1.iso Image: LXQt live x86_64 Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-Rawhide-20230202.n.1.iso Image: LXQt raw-xz aarch64 Path: Spins/aarch64/images/Fedora-LXQt-Rawhide-20230202.n.1.aarch64.raw.xz = DROPPED IMAGES = Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20230202.n.0.ppc64le.raw.xz Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20230202.n.0.ppc64le.qcow2 Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20230202.n.0.ppc64le.tar.xz = ADDED PACKAGES = Package: python-ebranch-0.0.3-1.fc38 Summary: Tool for branching Fedora packages for EPEL RPMs:ebranch Size:54.41 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: R-mockr-0.2.1-1.fc38 Old package: R-mockr-0.2.0-2.fc38 Summary: Mocking in R RPMs: R-mockr Size: 60.51 KiB Size change: 113 B Changelog: * Thu Feb 02 2023 Tom Callaway - 0.2.1-1 - update to 0.2.1 Package: aardvark-dns-1.5.0-1.fc38 Old package: aardvark-dns-1.4.0-2.fc38 Summary: Authoritative DNS server for A/ container records RPMs: aardvark-dns Size: 4.23 MiB Size change: 59.81 KiB Changelog: * Thu Feb 02 2023 Lokesh Mandvekar - 1.5.0-1 - bump to v1.5.0 Package: annobin-11.09-1.fc38 Old package: annobin-11.07-2.fc38 Summary: Annotate and examine compiled binary files RPMs: annobin-annocheck annobin-docs annobin-libannocheck annobin-plugin-clang annobin-plugin-gcc annobin-plugin-llvm Size: 4.96 MiB Size change: 9.44 KiB Changelog: * Tue Jan 31 2023 Nick Clifton - 11.08-1 - Annocheck: Fix atexit test. Fix recording of version numbers. (#2165528) * Thu Feb 02 2023 Nick Clifton - 11.09-1 - Libannocheck: Fix thinko in debugging code. - Annocheck: Fix LTO test. - Notes: Display notes held in separate dbeuginfo files. Package: awscli-1.27.63-1.fc38 Old package: awscli-1.27.62-1.fc38 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 3.28 MiB Size change: 51 B Changelog: * Thu Feb 02 2023 Gwyn Ciesla - 1.27.63-1 - 1.27.63 Package: biosig4c++-1.9.5-10.gita2aae2b.fc38 Old package: biosig4c++-1.9.5-9.gita2aae2b.fc38 Summary: A software library for processing of biomedical signals RPMs: biosig4c++ biosig4c++-devel Size: 3.25 MiB Size change: 1.38 KiB Changelog: * Thu Jan 26 2023 Florian Weimer - 1.9.5-10.gita2aae2b - Apply upstream patches to fix C99 compatibility issues Package: cgnslib-4.3.0-7.fc38 Old package: cgnslib-4.3.0-6.fc38 Summary: Computational Fluid Dynamics General Notation System RPMs: cgnslib cgnslib-common cgnslib-devel cgnslib-libs cgnslib-mpich cgnslib-mpich-devel cgnslib-mpich-libs cgnslib-openmpi cgnslib-openmpi-devel cgnslib-openmpi-libs Size: 12.23 MiB Size change: -1.07 KiB Changelog: * Thu Feb 02 2023 Florian Weimer - 4.3.0-7 - Fix C99 compatibility issue around TkWmAddToColormapWindows Package: chessx-1.5.8-1.fc38 Old package: chessx-1.5.6-9.fc38 Summary: Chess Database and PGN viewer RPMs: chessx Size: 15.27 MiB Size change: 2.03 MiB Changelog: * Wed Feb 01 2023 Ondrej Mosnek - 1.5.6-14 - Switch to rpmautospec * Wed Feb 01 2023 Ondrej Mosnek - 1.5.6-15 - Convert License field to SPDX * Thu Feb 02 2023 Ondrej Mosnek - 1.5.8-1 - Update to version 1.5.8 Package: compat-guichan05-0.5.0-36.fc38 Old package: compat-guichan05-0.5.0-35.fc38 Summary: Compatibility libraries for older guichan versions RPMs: compat-guichan05 compat-guichan05-devel Size: 2.53 MiB Size change: -603 B Changelog: * Thu Feb 02 2023 Florian Weimer - 0.5.0-36 - Port configure script to C99 Package: cronolog-1.6.2-36.fc38 Old package: cronolog-1.6.2-35.fc38 Summary: Web log rotation program for Apache RPMs: cronolog Size: 157.39 KiB Size change: -219 B Changelog: * Thu Feb 02 2023 Florian Weimer - 1.6.2-36 - Fix C99 compatibility issues (#2166555) Package: crun-1.8-1.fc38 Old package: crun-1.7.2-4.fc38 Summary: OCI runtime written in C RPMs: crun crun-krun crun-wasm Size: 890.00 KiB Size change: 8.25 KiB Changelog: * Thu Feb 02 2023
openmpi 5.0.0 drops 32-bit support
As a heads up - openmpi 5.0.0 drops support for 32-bit builds [1]. I'm not sure how far away it is from release - we're on rc10 at the moment. Affected packages seem to be: amg4psblas-1.1.0-4.fc38.src.rpm arbor-0.7-4.fc38.src.rpm auryn-0.8.2-15.fc38.src.rpm boost-1.78.0-11.fc38.src.rpm bout++-4.4.2-5.fc37.src.rpm cgnslib-4.3.0-6.fc38.src.rpm cgnslib-4.3.0-7.fc38.src.rpm coin-or-Ipopt-3.14.9-2.fc38.src.rpm combblas-1.6.2-0.15.beta2.fc37.src.rpm cp2k-2023.1-2.fc38.src.rpm dolfin-2019.1.0.post0-36.fc38.src.rpm elpa-2022.05.001-2.fc38.src.rpm fftw-3.3.10-3.fc37.src.rpm freefem++-4.12-2.fc38.src.rpm ga-5.7.2-13.fc38.src.rpm gmsh-4.11.1-3.fc38.src.rpm gpaw-22.8.0-5.fc38.src.rpm gretl-2022c-2.fc38.src.rpm h5py-3.7.0-4.fc38.src.rpm hdf5-1.12.1-11.fc38.src.rpm hpx-1.8.1-1.fc37.src.rpm hypre-2.24.0-3.fc37.src.rpm intel-mpi-benchmarks-2021.3-3.fc38.src.rpm lammps-20220623-3.fc38.src.rpm libcircle-0.3-12.fc38.src.rpm libneurosim-1.2.0-6.20210110.gitafc003f.fc38.src.rpm mathgl-8.0.1-2.fc38.src.rpm mpi4py-3.1.4-2.fc38.src.rpm MUMPS-5.5.1-1.fc38.src.rpm MUSIC-1.1.16-10.20201002git8c6b77a.fc38.src.rpm nest-3.3-1.fc38.src.rpm netcdf-4.9.0-5.fc38.src.rpm netcdf-cxx4-4.3.1-8.fc38.src.rpm netcdf-fortran-4.5.4-3.fc38.src.rpm netgen-mesher-6.2.2202-5.fc38.src.rpm neuron-8.0.2-6.fc38.src.rpm nwchem-7.0.2-12.fc38.src.rpm openmpi-4.1.4-8.fc38.src.rpm paraview-5.11.0-3.fc38.src.rpm petsc-3.17.4-7.fc38.src.rpm psblas3-3.8.0-3.fc37.src.rpm python-dijitso-2019.1.0-12.fc38.src.rpm python-ffc-2019.1.0.post0-11.fc38.src.rpm python-lfpy-2.2.6-6.fc38.src.rpm python-steps-3.6.0-27.fc38.src.rpm quantum-espresso-7.0-5.fc38.src.rpm scalapack-2.2.0-3.fc38.src.rpm scotch-6.1.2-3.fc37.src.rpm sundials2-2.7.0-12.fc38.src.rpm sundials-5.8.0-11.fc38.src.rpm superlu_dist-8.1.1-1.fc38.src.rpm vtk-9.2.5-2.fc38.src.rpm Personally I've been planning on dropping 32-bit support in a buch of packages I maintain in this stack like vtk, paraview, etc. This seems like as good a driver for it as any. That said, packages that build serial and parallel versions don't need to drop 32-bit support completely, just for the openmpi builds. 1 - https://github.com/open-mpi/ompi/pull/11282 -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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: 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: F39 proposal: Mass Retire Golang Leaves (Self-Contained Change proposal)
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? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired next week
On Tue, 2023-01-31 at 13:44 +0100, Miro Hrončok wrote: > If you see a package that was built, please let me know. > If you see a package that should be exempted from the process, > please let me know and we can work together to get a FESCo approval for > that. > > If you see a package that can be rebuilt, please do so. > free42 brouhaha I'll save this if no response, fix is ready: https://src.fedoraproject.org/rpms/free42/pull-request/1 > frogr teuf Fix under discussion: https://src.fedoraproject.org/rpms/frogr/pull-request/1 > gtkhash nonamedotc This is built now. > kguitar davidcornette Fix available: https://src.fedoraproject.org/rpms/kguitar/pull-request/1 > kjots kde-sig, thunderbirdtr This is built now. > libmobi avsej Fix available: https://src.fedoraproject.org/rpms/libmobi/pull-request/2 > mimic pbrobinson Fix available: https://src.fedoraproject.org/rpms/mimic/pull-request/1 > xml-security-c bruno, kloczek Fix available: https://src.fedoraproject.org/rpms/xml-security-c/pull-request/3 HTH, -- Yaakov Selkowitz Principal Software Engineer - Platform Enablement Red Hat, Inc. ___ 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
Rawhide and debug kernel changes
As the MR is now merged, it is a good time to make sure that everyone is aware. As of 6.2-rc5, Rawhide is no longer forcing a debug build with any kernels. All rawhide kernels are now built just like stable Fedora kernels, with both non-debug and debug variations. This change was necessary because performance has degraded with debug kernels to the point that there were very few people using them, meaning fewer people testing daily upstream development builds. Changing the config to make the performance acceptable to more would take away much of the usefulness of the debug builds to begin with. We do still appreciate those who have the patience and ability to run rawhide debug kernels when possible just because they do still find the occasional lockdep issue, or other problems that would be hidden by a non-debug kernel. In addition to this change, I have added debug builds for aarch64 kernels. Previously, debug kernels were only available on x86. Thanks, Justin ___ 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: Quick thanks for -fno-omit-frame-pointer
A neat thing you can play around with is the color profiles, you can have kernel stack frames in one color, C / C++ userspace stack frames in another color, Java / Node / Python stack frames in another color, etc. https://www.brendangregg.com/blog/2017-07-30/coloring-flamegraphs-code-type.html It would be a nice visual addition to the demo. ___ 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: Quick thanks for -fno-omit-frame-pointer
On Thu, Feb 02, 2023 at 06:05:44PM -, Daniel Alley wrote: > Perhaps this would be amenable to a blog post demonstrating the benefits? > e.g. > > * What does the system performance analysis process look like, how to get > started > * What impacts does the lack of frame pointer information have on the outputs > (incoherent / invisible / inaccurate data), and how much work is required to > work around it that (recompiling packages) > * Compared to Fedora-with-frame-pointers > > I think it would be quite useful both as a "starter guide" of sorts and as a > call to action to get developers to start taking advantage of it. Maybe even > to switch to Fedora. I made a start here: https://rwmj.wordpress.com/2023/02/02/fedora-now-has-frame-pointers/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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: Proposal: explicitly require full process to resubmit rejected proposals to FESCo
On Tue, Jan 31, 2023 at 5:21 PM Tom Stellard wrote: > > On 1/31/23 14:00, Ben Cotton wrote: > >> Proposals that are rejected may be submitted by reconsideration, but they > >> must go through whatever process was originally required before FESCo > >> begins voting. For example, this means a rejected Change proposal must be > >> resubmitted to the Change Wrangler as outlined in the Changes process. > > > Will the Change Proposal Deadlines still apply (i.e. proposals can't > be resubmitted after the deadline)? I would think so, if for no other reason than to give the owners time to implement it after approval. That said, FESCo can accept late proposals at its discretion, so it may depend on the exact circumstances. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Quick thanks for -fno-omit-frame-pointer
Perhaps this would be amenable to a blog post demonstrating the benefits? e.g. * What does the system performance analysis process look like, how to get started * What impacts does the lack of frame pointer information have on the outputs (incoherent / invisible / inaccurate data), and how much work is required to work around it that (recompiling packages) * Compared to Fedora-with-frame-pointers I think it would be quite useful both as a "starter guide" of sorts and as a call to action to get developers to start taking advantage of it. Maybe even to switch to Fedora. ___ 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 next week
I’m sorry for not answering sooner! I’ll be glad to receive help with the current state of the package. Thanks in advance On Thu, Feb 2, 2023 at 14:41 Sérgio Basto wrote: > On Thu, 2023-02-02 at 12:14 +0100, Miro Hrončok wrote: > > On 02. 02. 23 0:46, Georg Sauthoff wrote: > > > Hello, > > > > > > On Tue, Jan 31, 2023 at 01:44:26PM +0100, Miro Hrončok wrote: > > > > > > > datamashjhladky > > > > > > I have a build fix ready and volunteer to maintain it such that I > > > can > > > apply it. > > > > > > My FAS handle is: gsauthof > > > > > > Can you add me as a maintainer for the datamash package and exclude > > > it > > > from next weeks retirement run? > > > > Could you open a pull request with the fix, to have a track record > > for this? > > Once the time for retirement happens, I will assign you to the > > package instead > > and let you merge and ship it. > > I added the fix on bugzilla and built it for F36 and F37 and rawhide > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-1fa3c954ca > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-ed734e6bba > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-1dfdac0cb5 > > > > -- > > Miro Hrončok > > -- > > Phone: +420777974800 > > IRC: mhroncok > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > > -- > Sérgio M. B. > ___ > 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 > ___ 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 next week
On Thu, 2023-02-02 at 12:14 +0100, Miro Hrončok wrote: > On 02. 02. 23 0:46, Georg Sauthoff wrote: > > Hello, > > > > On Tue, Jan 31, 2023 at 01:44:26PM +0100, Miro Hrončok wrote: > > > > > datamash jhladky > > > > I have a build fix ready and volunteer to maintain it such that I > > can > > apply it. > > > > My FAS handle is: gsauthof > > > > Can you add me as a maintainer for the datamash package and exclude > > it > > from next weeks retirement run? > > Could you open a pull request with the fix, to have a track record > for this? > Once the time for retirement happens, I will assign you to the > package instead > and let you merge and ship it. I added the fix on bugzilla and built it for F36 and F37 and rawhide https://bodhi.fedoraproject.org/updates/FEDORA-2023-1fa3c954ca https://bodhi.fedoraproject.org/updates/FEDORA-2023-ed734e6bba https://bodhi.fedoraproject.org/updates/FEDORA-2023-1dfdac0cb5 > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Sérgio M. B. ___ 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: Will dnf5 be ready by F39?
On Wed, Feb 1 2023 at 08:41:55 PM -0800, Gordon Messmer wrote: Is the current plan to support the PackageKit API in the dnf daemon, or to port packagekit's dnf backend to the dnf5 API? Red Hat is currently planning to port everything we care about that uses PackageKit to use dnfdaemon's D-Bus API. Currently that's gnome-software, gnome-shell, and gnome-initial-setup. (I think that's all we have in Fedora Workstation that depends on PackageKit?) I'm not sure this is actually a good plan! If feasible, I'd say the best plan would be for dnfdaemon to implement the same D-Bus API as PackageKit does. Then we no longer need PackageKit to serve as a glue layer, but the PackageKit D-Bus API still lives on as the one true standard for software centers and system updates. A PackageKit backend for dnf5 would also work and I have no doubt it will happen regardless. Surely that'd be the best option for Fedora if dnfdaemon does not have the same D-Bus API that PackageKit does, because pushing dnf-specific code into upstream projects when PackageKit exists is not very friendly. But Red Hat has a conflicting goal: we don't want to maintain PackageKit anymore! Michael ___ 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
Orphaning rubygem-jquery-rails + *js-jquery*
Hi, I have spend some quality time bringing rubygem-railties test suite up2date and this resulted in dropping the dependency on rubygem-jquery-rails. Nothing else in Fedora depends on that package and therefore I orphaned it and I suggest to let it go. Since I don't maintain rubygem-jquery-rails, I have also released ownership of js-jquery package. I have saved the package a while ago from being retired, but I was never good maintainer. Because it is used by other packages, I hope it will find new maintainers quickly. The package was updated while ago by Stephen and recently by Orion, therefore adding them on CC. Vít OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: x86_64-v2 in Fedora
Dne 02. 02. 23 v 17:20 Miroslav Suchý napsal(a): Dne 01. 02. 23 v 23:25 Reon Beon via devel napsal(a): There seems to be support now in rpm:https://github.com/rpm-software-management/rpm/discussions/2022 Where? When following the link, it leads to the hole of anothers issues, and refences. But I see no merged PR. Probably this: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1375300128 Vít OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to migrate database format during package update?
Dne 01. 02. 23 v 13:56 Milan Crha napsal(a): Hi, this is a query for an opinion and a best-practice experience for a case when a package needs to change its internal database format between versions, in an environment, which does not allow real That being said, any such change surely deserves release notes, with the commands what to do to export and then back import the wordlist. There should be filled a corresponding Change too, I guess. Yes. Likely both. If you will go the release notes only way then open the issue here https://pagure.io/fedora-docs/release-notes But I strongly encourage you to create Change proposal as it gives you a lot of advertisment and therefore awareness for free. Still, how does other packages migrate their data, or at least help the users with the migration? Is there any way? Put aside all your expectation. The reality will always surprise you no matter how big is your imagination. I worked in past on project where the DB was sometimes huge. And upgrades of the schema took 20+ hours even on beefy machines. The stories... The best practice is to document it. Announce in advance. And when package is upgraded flip some variable in config (/etc/sysconfig/$package or ~/.config/$package) and until user flip the variable back, do not start the service/application and if user attempts to start it, exit with message like: The DB schema of $package changed. Please migrate to new format using a tool `$migration-tool`. And then change variable FOO in /etc/sysconfig/$package For more information see $URL Miroslav ___ 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: x86_64-v2 in Fedora
Dne 01. 02. 23 v 23:25 Reon Beon via devel napsal(a): There seems to be support now in rpm:https://github.com/rpm-software-management/rpm/discussions/2022 Where? When following the link, it leads to the hole of anothers issues, and refences. But I see no merged PR. Miroslav ___ 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: Will dnf5 be ready by F39?
Dne 02. 02. 23 v 5:41 Gordon Messmer napsal(a): The change proposal calls for dnf5 to be ready by the time that F39 is branched, on Aug 8 of this year. Right now, I don't see any documentation for plugins, the general API docs are (subjectively) terse, and the DNF5 git repo has a banner with warning signs that says "The API/ABI is currently unstable." (...which seems very odd, since 5.0.1 was released in November, so one would expect that the API has been stable since at least that time.) Right. When Change is proposed it does not need to be done or close to be finished. It is fine. When the owners submit it, then they indicate that they think it is doable. Fesco agreed that it is doable. But for the worst case scenario we have https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Acceptance_Criteria https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Contingency_Plan And if things will not work out, we can push back and rollback the change. It is hard, but IIRC it happened in past. The change proposal doesn't seem to consider gnome-software at all (only the gnome-software-rpm-ostree plugin is mentioned). It's not part of the acceptance criteria, but it seems like it should be. Is the current plan to support the PackageKit API in the dnf daemon, or to port packagekit's dnf backend to the dnf5 API? This is actually one of the reason the change is happening - rewrite from Python to C. PackageKit is written in C and it was way behind libdnf. And the differences grow over time. The migration of PackageKit will happen in future for sure. I hope in near future. But if we push on having it in acceptance criteria now then it will be huge step. And it is much easier to do two steps than doing one long step. Miroslav ___ 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
F39 proposal: Mass Retire Golang Leaves (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Mass_Retire_Golang_Leaves
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 ==
As of Jan 2023, 275/1660 (17%) library only Go source packages are
leaves.
Overall, these packages are maintained by 35 different maintainers along with
the Go SIG.
[https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves These leaves]
([https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves-by-maintainer
by maintainer])
will be mass retired in Fedora 39.
== Owner ==
* Name: [[User:gotmax23| Maxwell G]]; [[User:alexsaezm | Alejandro
Sáez Morollón]]; [https://pagure.io/GoSIG/go-sig the Go SIG]
* Email: gotmax@e.email; a...@redhat.com; gol...@lists.fedoraproject.org
== Definitions ==
* ''library only source package'' -- a component/source package that
only contains noarch golang ''*-devel'' subpackages.
* ''binary subpackage'' -- an arched subpackage that contains go binaries.
* ''source package with binaries'' - a component/source package that
contains at least one ''binary subpackage''; may also contain library
subpackages.
* ''leaf'' -- a library only source package whose subpackages don't
have any dependents
== Detailed Description ==
The Go SIG maintains over 2000 source packages. 275 of these packages are
''leaves''. Overall, these packages are assigned to 35 different maintainers.
We'd like to clean up these unneeded packages to allow us to better direct our
time and unclutter the distribution. Handling this large number of leaves one
by one and maintainer by maintainer proved ineffective, so we're taking a more
heavy handed approach and mass retiring these leaf packages prior to the
release of Fedora 39.
''Source packages with binaries'' will be excluded even if the ''binary
subpackage''(s) and/or the -devel subpackage(s) are leaves.
See the next section for more information on how we plan to implement this.
In short:
* We wrote a script to identify the ''leaf'' packages.
* The current list of ''leaf'' packages is available at
https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves. A by maintainer
breakdown is available at
https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves-by-maintainer.
* We will contact the maintainers of these packages and allow them to opt-out.
* We will use Copr to verify our work before proceeding with the mass removal.
=== Implementation ===
Finding the leaves:
([https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/go-sig/go_leaves.py
go_leaves.py])
# Find the source packages that BuildRequire go-rpm-macros or any
golang.src subpackage
# Iterate over the source packages list and find the subpackages for each one
# If all of a source package's subpackages are noarch and contain
"-devel", it is considered a leaf.
# Remove packages from the leaves list if they've opted out.
# Store the output in
https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves. Update it
periodically.
Confirmation:
# 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.
# Rebuild all of the non leaf packages.
# Investigate new failures and rebuild in a control Copr.
Opt outs:
# A list of opt outs will be kept in
https://pagure.io/GoSIG/go-leaves. Go SIG members will have `commit`.
# As explained in the aforementioned repo's README, packagers can
simply push an `opt-out/{component}` text file with a short
justification to opt out.
Mass Retirement:
# Shallow clone the ''leaves''' distgit repositories and run `fedpkg
retire` on each.
# Double check that the packages are properly blocked/retired in Koji and PDC.
== Feedback ==
This was briefly discussed in a Go SIG meeting
([https://meetbot.fedoraproject.org/fedora-golang/2023-01-16/go_sig_meeting.2023-01-16-19.00.html
minutes]).
Feedback was generally positive.
== Benefit to Fedora ==
This change will allow the Go SIG to focus its limited people power on
maintaining packages that are actually needed.
Fedora won't waste resources uselessly rebuilding these packages.
Hopefully, the other packages will be better maintained.
== Scope ==
* Proposal owners:
** ✅ Write a script to determine leaves.
([https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/go-sig/go_leaves.py
go_leaves.py])
** ✅ Store an updated list of leaves in https://pagure.io/GoSIG/go-leaves
** Directly contact affected maintainers and devel-announce. Ensure
opt outs are properly accounted for.
** Simulate the removal of these packages and rebuild the Golang stack
in Copr. Investigate any new failures.
** Mass retire packages after waiting a few weeks for maintainers to
opt out. Aim to have this completed before the mass rebuild.
* Release engineering: [https://pagure.io/releng/issue/11253 #11253
Non-responsive maintainer check for andymenderunix
This is a non-responsive maintainer check for andymenderunix (Andy Mender). Does anyone know how to contact Andy? https://bugzilla.redhat.com/show_bug.cgi?id=2166645 Thanks, Scott ___ 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
Quick thanks for -fno-omit-frame-pointer
I was doing some perf analysis for the first time in a few weeks, and it is so much clearer now that I can use Rawhide packages compiled with frame pointers. Makes it much easier to analyse Flame Graphs when I can just update libraries to Rawhide instead of having to recompile them all myself (or more usually, suffer with incoherent / invisible / inaccurate bits of the chart). Thanks everyone who helped with this feature. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ 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
Fedora rawhide compose report: 20230202.n.0 changes
OLD: Fedora-Rawhide-20230201.n.0 NEW: Fedora-Rawhide-20230202.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 3 Dropped packages:1 Upgraded packages: 350 Downgraded packages: 0 Size of added packages: 5.79 GiB Size of dropped packages:2.78 MiB Size of upgraded packages: 7.64 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 419.35 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Sway live x86_64 Path: Spins/x86_64/iso/Fedora-Sway-Live-x86_64-Rawhide-20230202.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: java-11-openjdk-portable-1:11.0.18.0.9-0.1.ea.fc38.1 Summary: OpenJDK 11 Runtime Environment portable edition RPMs:java-11-openjdk-portable java-11-openjdk-portable-devel java-11-openjdk-portable-devel-fastdebug java-11-openjdk-portable-devel-slowdebug java-11-openjdk-portable-fastdebug java-11-openjdk-portable-slowdebug java-11-openjdk-portable-static-libs java-11-openjdk-portable-static-libs-fastdebug java-11-openjdk-portable-static-libs-slowdebug Size:5.79 GiB Package: libcamera-apps-1.1.1-2.fc38 Summary: A small suite of libcamera-based apps RPMs:libcamera-apps Size:1.12 MiB Package: qt6-qtwebview-6.4.2-1.fc38 Summary: Qt6 - WebView component RPMs:qt6-qtwebview qt6-qtwebview-devel qt6-qtwebview-examples Size:303.74 KiB = DROPPED PACKAGES = Package: Catch2-3.3.1-1.fc38 Summary: A modern, C++-native, test framework RPMs:Catch2 Catch2-devel Size:2.78 MiB = UPGRADED PACKAGES = Package: OpenImageIO-2.4.8.0-1.fc38 Old package: OpenImageIO-2.4.7.1-4.fc38 Summary: Library for reading and writing images RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils python3-openimageio Size: 21.49 MiB Size change: 15.04 KiB Changelog: * Thu Feb 02 2023 Richard Shaw - 2.4.8.0-1 - Update to 2.4.8.0. Package: akonadi-calendar-tools-22.12.2-1.fc38 Old package: akonadi-calendar-tools-22.12.1-2.fc38 Summary: Akonadi Calendar Tools RPMs: akonadi-calendar-tools Size: 925.35 KiB Size change: 4 B Changelog: * Tue Jan 31 2023 Marc Deop - 22.12.2-1 - 22.12.2 Package: akonadi-import-wizard-22.12.2-1.fc38 Old package: akonadi-import-wizard-22.12.1-2.fc38 Summary: Akonadi Import Wizard RPMs: akonadi-import-wizard akonadi-import-wizard-devel Size: 2.33 MiB Size change: -939 B Changelog: * Tue Jan 31 2023 Marc Deop - 22.12.2-1 - 22.12.2 Package: akonadiconsole-22.12.2-1.fc38 Old package: akonadiconsole-22.12.1-2.fc38 Summary: Akonadi developer tool RPMs: akonadiconsole Size: 1.25 MiB Size change: -126 B Changelog: * Tue Jan 31 2023 Marc Deop - 22.12.2-1 - 22.12.2 Package: akregator-22.12.2-1.fc38 Old package: akregator-22.12.1-2.fc38 Summary: Feed Reader RPMs: akregator akregator-libs Size: 5.83 MiB Size change: -1.58 KiB Changelog: * Tue Jan 31 2023 Marc Deop - 22.12.2-1 - 22.12.2 Package: anaconda-38.19-1.fc38 Old package: anaconda-38.18-1.fc38 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui anaconda-webui anaconda-widgets anaconda-widgets-devel Size: 19.46 MiB Size change: 28.34 KiB Changelog: * Tue Jan 31 2023 Packit - 38.19-1 - Remove mocking of modules for sphinx docs builds (vslavik) - docs: Update branching instructions (vslavik) - docs: Fix release badge URL (vslavik) - Remove leftovers after the isys module removal (vslavik) - Templatize kickstart version (vslavik) - Ignore jinja templates in RPM tests (vslavik) - Show only usable devices in custom partitioning (jstodola) - Add base for integration testing and default installation test (zveleba) - Add storage helper function for listing disks (zveleba) - Add helper for back button to WebUI tests (zveleba) - Fix missing tests in release archive (marmarek) - Update translations from Weblate Package: analitza-22.12.2-1.fc38 Old package: analitza-22.12.1-2.fc38 Summary: Library of mathematical features RPMs: analitza analitza-devel Size: 3.02 MiB Size change: 105 B Changelog: * Tue Jan 31 2023 Marc Deop - 22.12.2-1 - 22.12.2 Package: ansible-7.2.0-1.fc38 Old package: ansible-7.1.0-2.fc38 Summary: Curated set of Ansible collections included in addition to ansible-core RPMs: ansible Size: 44.38 MiB Size change: 716.72 KiB Changelog: * Tue Jan 31 2023 David Moreau-Simard - 7.2.0-1 - Update to 7.2.0. Package: ansible-core-2.14.2-1.fc38 Old package: ansible-core-2.14.1-2.fc38 Summary: A radically simple IT automation system RPMs: ansible-core ansible-core-doc Size: 5.32 MiB Size change: 48.77 KiB Changelog: * Tue Jan 31
Re: List of long term FTBFS packages to be retired next week
On 02. 02. 23 0:46, Georg Sauthoff wrote: Hello, On Tue, Jan 31, 2023 at 01:44:26PM +0100, Miro Hrončok wrote: datamashjhladky I have a build fix ready and volunteer to maintain it such that I can apply it. My FAS handle is: gsauthof Can you add me as a maintainer for the datamash package and exclude it from next weeks retirement run? Could you open a pull request with the fix, to have a track record for this? Once the time for retirement happens, I will assign you to the package instead and let you merge and ship it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired next week
- all 31.01.2023, 12:44, "Miro Hrončok" :howl atim, pwalterI took over howl that was orphaned a few weeks ago and now rescued it and fixed it to build from source. I also created a fedora flatpak for it as it was missing. Pete___ 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
[Test-Announce] Fedora 38 Rawhide 20230202.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 38 Rawhide 20230202.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20230126.n.0: anaconda-38.18-1.fc38.src, 20230202.n.0: anaconda-38.19-1.fc38.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/38 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20230202.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20230202.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20230202.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20230202.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20230202.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20230202.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20230202.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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: Will dnf5 be ready by F39?
On Thu, Feb 2, 2023 at 5:42 AM Gordon Messmer wrote: > > On 2023-02-01 13:38, Zbigniew Jędrzejewski-Szmek wrote: > > #2870 Change proposal: Replace DNF with DNF5 > > https://pagure.io/fesco/issue/2870 > > APPROVED (+6,0,-0) > > > (Fixed the link above) > > The change proposal calls for dnf5 to be ready by the time that F39 is > branched, on Aug 8 of this year. > > Right now, I don't see any documentation for plugins, the general API > docs are (subjectively) terse, and the DNF5 git repo has a banner with > warning signs that says "The API/ABI is currently unstable." (...which > seems very odd, since 5.0.1 was released in November, so one would > expect that the API has been stable since at least that time.) > > The change proposal doesn't seem to consider gnome-software at all (only > the gnome-software-rpm-ostree plugin is mentioned). It's not part of the > acceptance criteria, but it seems like it should be. > > Is the current plan to support the PackageKit API in the dnf daemon, or > to port packagekit's dnf backend to the dnf5 API? > > https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5 Well, having it supported in PackageKit is certainly part of the plan once it becomes possible. When that is, I don't know yet... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Developer Portal content update for January 2023
Hi all, we have new year, new merged PRs, therefore I made a new build and pushed new release. Give it a moment to propagate. You can preview the changes using this URL before the prod release propagates: https://developer.stg.fedoraproject.org/ Notable changes: * Update .NET docs for .NET 7 release, #471 * https://developer.fedoraproject.org/tech/languages/csharp/dotnet-installation.html * https://developer.fedoraproject.org/tech/languages/dotnet/dotnet-ide.html * https://developer.fedoraproject.org/tech/languages/dotnet/dotnetcore.html * Replace RLS with rust-analyzer as prefered language server for rust, #466 * https://developer.fedoraproject.org/tech/languages/rust/further-reading.html * Update vagrant-libvirt.md, #467 * https://developer.fedoraproject.org/tools/vagrant/vagrant-libvirt.html Minor changes: * Minor spelling correction, #462 * https://developer.fedoraproject.org/start/sw/web-app/about.html * Gtk C -- remove packages absent in recent Fedoras in the install step, #464 * https://developer.fedoraproject.org/tech/languages/c/gtk.html Contributions are always welcome: https://github.com/developer-portal/content Following pages contain deprecated instructions and will be removed soon unless they are updated to work with modern Fedora: https://developer.fedoraproject.org/tech/database/mongodb/about.html https://developer.fedoraproject.org/tech/database/cassandra/about.html https://developer.fedoraproject.org/tech/languages/groovy/groovy-installation.html Thanks, Jarek Prokop ___ 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 next week
Dne 02. 02. 23 v 0:46 Georg Sauthoff napsal(a): Hello, On Tue, Jan 31, 2023 at 01:44:26PM +0100, Miro Hrončok wrote: datamashjhladky I have a build fix ready and volunteer to maintain it such that I can apply it. My FAS handle is: gsauthof Can you add me as a maintainer for the datamash package and exclude it from next weeks retirement run? I think it would make sense to make this request in the BZ you reference bellow. And also, providing PR fixing the issue might help to convince the maintainer. But other than that, retiring would not be that bad thing in your case, because after retirement, there is 8 weeks window to unretire the package without re-review, that way you could pick it up ... Vít See also: - discussion of the fix: https://bugzilla.redhat.com/show_bug.cgi?id=2056736#c10 - my previous message to this list regarding preventing datamash getting retired: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/TADIVWB3QXO3ASJ246WF4X5D2F2GL4SM/ Best regards, Georg OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired next week
On Thursday, 02 February 2023 at 03:53, Gary Buhrmaster wrote: > On Tue, Jan 31, 2023 at 12:45 PM Miro Hrončok wrote: > > > If you see a package that can be rebuilt, please do so. > > > tpm2-tss-engine mzavalavz > > I can fix this (up-lift to the current release), but I don't see a way > to do so before retirement as the current maintainer seems mostly MIA. > Am I missing something in the process (as a non-PP). If the package > is orphaned, I would just take it, up-lift, and rebuild, but I do not > see that as a viable option with the current maintainer is > (apparently) non-responsive (yes, I could open the entire > non-responsive process, but at this point that would take longer than > the date of retirement). Open a PR and ask a proven packager to merge it for you. Then you can submit the build yourself. In parallel, start the non-responsive maintainer process. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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
