Re: Self Introduction: Štěpán Horáček

I have sponsored Štěpán (shoracek) under the co-maintainer section of the packager sponsor policy. Welcome, and happy packaging! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F37 proposal: Golang 1.19 (System-Wide Change proposal)

I imagine I could answer this myself by looking carefully at the history of the golang package, but what happens if you end up doing the mass rebuild with a pre-release version? Would you need to do a second mass rebuild with the final version between the beta and final freezes? The Beta

[EPEL-devel] Re: EPEL7 packages still in epel-testing

For context, until very recently, the EPEL guidelines explicitly asked packagers to disable time-based push on fully-compatible “minor release” type updates and let them sit indefinitely in testing until/unless they accrued +3 karma. The historical guidelines are mostly preserved on the

Re: gcc-12.0.0-0.4.fc36 in rawhide

> * Jakub Jelinek: > > > I think Kevin has posted a GDB patch for the crash: > > [PATCH] Fix GDB internal error by using text (instead of data) section > offset > > > The bug was exposed by the loss of the .data

License correction: python-pdfminer is “MIT and Public Domain and APAFML and BSD”

The License field for python-pdfminer has been corrected from “MIT” to “MIT and Public Domain and APAFML and BSD”. Its -doc subpackage remains “MIT”. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

License of mpir package simplified to LGPLv3+

The license for the mpir package has been simplified from “LGPLv3+ and LGPLv2+ and (LGPLv3+ or GPLv2+) and BSD” back to the effective license of “LGPLv3+”. See also https://fedoraproject.org/wiki/Licensing:FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F.

Orphaning mkdocs-markdownextradata-plugin

Since the entire stack of packages related to mkdocs was orphaned recently, and I do not wish to take them all myself, I have disabled mkdocs-generated HTML documentation in my packages, and I have orphaned mkdocs-markdownextradata-plugin, which is useless without mkdocs. This package is

Re: Building docs of compiled extensions with new macros

I have also resorted to manually installing the wheel to a temporary directory in %build, then setting PYTHONPATH to include the temporary directory to build the documentation. I don’t like this solution very well either, but it is a third alternative that seems to work well. See

Re: [HEADS UP] Fedora 35 Boost 1.76 rebuilds starting in a side tag

It looks like none of the packages I maintain or co-maintain that depend on boost-devel were rebuilt before the side tag was merged. Some (luminance-hdr, cpp-hocon) had automated FTI bugs filed; these were fixed by a manual rebuild on my part. Another (usd) should be in the same boat once some

Re: Easy way to temporarily change smp_mflags in mock or fedpkg mockbuild?

These should work: fedpkg mockbuild -- --define='_smp_mflags -j1' fedpkg mockbuild -- -D '_smp_mflags -j1' mock -r foo --rebuild bar.src..rpm --define='_smp_mflags -j1' mock -r foo --rebuild bar.src..rpm -D '_smp_mflags -j1' ___ devel mailing list --

Re: An unsuccessful case study: Using pyproject-rpm-macros with PyQt-builder and sip 5

If by “are using PEP-517 build systems” you just mean those that use pyproject-rpm-macros in their spec files, I can also offer python-asyncpg and python-pyrsistent as examples. If you mean that upstream does not use setuptools in setup.py, but instead uses flit or poetry via pyproject.toml,

Coming to Rawhide with small breaking API changes: python-starlette 0.16.0

In one week, I will build python-starlette 0.16.0 for Rawhide (https://src.fedoraproject.org/rpms/python-starlette/pull-request/2). It contains some small breaking API changes. I don’t think this will affect any other packages. ___ devel mailing list

Heads-up: python-engineio v4 / python-socketio v5

I claimed python-engineio, python-socketio, and python-flask-socketio after they were orphaned. I also claimed python-aiozmq. It does not currently work with Python 3.10, but it’s likely that upstream will get it fixed in time for Fedora 35. I probably will not claim python-jsonrpcserver,

License field is now “effective license” in agenda, appeditor, gaupol, harmonyseq, libinstpatch, notejot, sequeler

I’ve updated several of my packages to use only the “effective license” in their License fields, in cases where it was very clear that a single effective license was correct. The following packages are affected: - agenda: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+” - appeditor:

Re: Need assistance to build Blender

The “pyconfig.h” header lives in a python-version-specific subdirectory. Some of the compiler invocations earlier in the build log contain “-I/usr/include/python3.10”, but the one that is failing does not. I haven’t tried it, but I would guess that something like the following would resolve

License field change: dippi

The dippi package has been updated to 3.1.0 for ElementaryOS 6 in Rawhide. Upstream clarified the licensing, and the entire program is now GPLv3+ with CC0 AppStream metadata. Based on this, and on recent discussion suggesting a community preference for using effective licenses where feasible,

Re: x86_64-v2 in Fedora

> In this case it doesn't 'matter' it is a small segment of users. It is > a > segment of our maintainers who are. We either have to listen to them, 'fire > them', or buy them replacement hardware. Since we are already overloaded, > firing them has not been on the table. Buying replacement

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

I agree that running the tests wherever practical is the best practice. I do put my time where my mouth is—I maintain 17 packages that now use the pyproject-rpm-macros, and you’ll find that in general I’ve added a lot of %check sections to packages that were previously lacking them. However,

Re:  Advice on packaging azure-cli

I personally think the individual packages approach will be easier to maintain in the long run. (If you do go down that road, I’m planning to help review them.) – Ben Beasley ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send

Re: [cdparanoia] License field fix awaiting to be merged

> So, it doesn't really matter if two source files are distributed under the > GPLv2+ license. > The resulting binary (i.e. /usr/bin/cdparanoia) will always be GPLv2. > […] > But Licensing Guidelines make clear that the License: field refers to the > binary packages not source ones. > > BR, > >

License change: python-aiomqtt (“EPL-1.0” to “EPL-1.0 or BSD”)

I just started maintaining the previously-orphaned python-aiomqtt package. I corrected the License field from “EPL-1.0” to “EPL-1.0 or BSD” and added files with the actual license text, resolving https://bugzilla.redhat.com/show_bug.cgi?id=1962393. Please expect updates for all releases and

Re: Unannounced soname bump: libgta

Please consider updating the spec files as you go to help avoid the problem in the future, e.g., https://src.fedoraproject.org/rpms/libgta/pull-request/1. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

License change: npm-name-cli adds 0BSD

As a NodeJS package under the new guidelines with bundled dependencies, npm-name-cli has a long and complicated License field (https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/#_bundled_licenses). The 0BSD license now appears in its bundled dependencies, so it has been added

Preparing grpc 1.37.1 in Rawhide (with so-version bumps)

I am preparing to update grpc in Fedora Rawhide (35) to version 1.37.1. This includes the following subpackages: • grpc • grpc-data • grpc-doc • grpc-cpp • grpc-plugins • grpc-cli • grpc-devel • python3-grpcio • python3-grpcio-tools • python3-grpcio-channelz •

License change: harmonyseq (changed from “GPLv3+” to “GPLv3+ and CC0”)

The harmonyseq package changed from “GPLv3+” to “GPLv3+ and CC0” due to the downstream addition of an AppData XML file under the latter license (https://github.com/rafalcieslak/harmonySEQ/issues/5). ___ devel mailing list --

License change and so-version bump in side tag: libinstpatch

The License field for the libinstpatch 1.0.0 (a pre-release version from SVN) packaged in Fedora 32–34 has been corrected from “LGPLv2+” to “LGPLv2 and GPLv2 and Public Domain”. In Fedora 35, libinstpatch has been updated to version 1.1.6, which brings another license change, to “LGPLv2 and

License field correction: luminance-hdr changed from “GPLv2+” to “GPLv2+ and […]”

After taking over maintenance of the luminance-hdr package, I audited the upstream sources and found that the License field needed to be changed from “GPLv2+” to “GPLv2+ and GPLv2 and GPLv3+ and LGPLv2+ and BSD and MIT and Boost”. New builds will be available soon with this and other

License change: jrnl (changed from MIT to GPLv3 upstream)

I just picked up this package after it was orphaned. The upstream license changed to MIT to GPLv3 in release 2.4; the previous maintainer missed the change, so the RPMs in all current Fedora releases have the incorrect License field. (The version in EPEL8 is old enough to be correct.) I will

License change: giada (now “GPLv3+ and MIT and BSD”)

The license of giada has changed from “GPLv3+ and MIT and CC0 and BSD” to “GPLv3+ and MIT and BSD” since json/nlohmann_json/“JSON for Modern C++” was unbundled. (It in turn bundled Hedley, which is where the CC0 part of the license field came from.)

License change: giada (now “GPLv3+ and MIT and CC0 and BSD”)

The license of giada has changed from “GPLv3+ and MIT and CC0 and GPLv3 and ISC and ASL 2.0 and BSD and zlib and IJG” to “GPLv3+ and MIT and CC0 and BSD” after the bundled VST 3 SDK and JUCE sources were excluded from the source tarball due to legal considerations. See

License field correction: giada changed from “GPLv3+” to “GPLv3+ and […]”

I rescued the giada package after it was orphaned and have updated it to the latest upstream release, using the new CMake build system. The package now properly documents its pre-existing bundled dependencies (four direct and many indirect). Accordingly, the License field has changed from

License field correction: python-pyrsistent is now “MIT and BSD” instead of “MIT”

The License field for python-pyrsistent is now “MIT and BSD” instead of “MIT”; this is a correction rather than an upstream change. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

License change: pipx (MIT and BSD to just MIT)

The pipx package has changed upstream from MIT and BSD to just MIT. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

Re: Fwd: Orphaning some packages (C++/Gtkmm)

I have picked up cairomm. I might pick up more later, if others do not. Many thanks for your efforts thus far, and best wishes for your health. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

License field corrections: agenda, appeditor, dippi, harvey, notejot, sequeler, gaupol

The license for agenda has been corrected from “GPLv3” to “GPLv3+ and GPLv2+ and LGPLv2+ and CC0”. The license for appeditor has been corrected from “LGPLv2+” to “GPLv3 and LGPLv2+ and CC0”. The license for dippi has been corrected from “GPLv3” to “GPLv3+ and GPLv2+ and CC0”. The license for

Re: Orphaned: all my elementary AppCenter application packages

They are indeed in good shape—so I have picked them all up. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

License field change: wdiff (“GPLv3+” to “GPLv3+ and Latex2e”)

The License field for wdiff has been corrected from “GPLv3+” to “GPLv3+ and Latex2e”; the latter applies to the texinfo documentation. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

License field change and future plans: grpc

I took over maintainership of the grpc package after it was orphaned for one month, and I just built the first package in the process of rehabilitating it. A careful audit of the sources required a License field change for the main package from “ASL 2.0” to “ASL 2.0 and BSD”. This does not

Re: cmake FTBFS in rawhide

The failing test is multi-threaded compression with xz (LZMA), which is notoriously memory-hungry, and it is failing because it cannot allocate enough memory. In the success example, the i686 VM has six cores (see hw_info.log), while in the failure example, the i686 VM has 48 cores, so it is

SONAME bump: cpp-hocon

I just took over the orphaned cpp-hocon package and updated it. Version 0.3.0 is built in side tag f34-build-side-35661. Upstream has no ABI stability; SONAME changes even on patch releases. A multi-build update will be created for Rawhide after the only known dependent package, facter, is

Help with compiling SASS to CSS in a Python package

I am the reviewer for “python-furo - A clean customizable documentation theme for Sphinx” (https://bugzilla.redhat.com/show_bug.cgi?id=1910798). The Python part of the package is clean and simple, and the submitter is responsive, competent, and helpful. I’d really like to be able to approve the

[EPEL-devel] License field change in EPEL7: gaupol

While fixing up the packaging of gaupol to meet modern standards (for EPEL7 values of modern), I found that it includes one file copied from anjuta, distributed under GPLv2+, as described in the CREDITS file. Accordingly, the License field has changed from “GPLv3+” to “GPLv3+ and GPLv2+”. The

Notice of recent License field change: mpir

After I recently took over maintainership of the orphaned mpir package, I found that the License field was based on the overall license rather than on a complete audit of source file license headers. Accordingly, I updated the License field from: LGPLv3+ to: LGPLv3+ and LGPLv2+ and (LGPLv3+

Notice of upgrading xalan-c to 1.12.0 in Rawhide

I am the new volunteer maintainer of the orphaned xalan-c package (Xalan XSLT processor for C/C++). On 2020-12-08, I plan to submit a build of the new upstream version, 1.12.0, to Rawhide. Those interested may already inspect the new spec file in Pagure, and a Koji scratch build is available at

Arpwatch updated to 3.1 – testing and auditing appreciated!

I recently took maintainership of arpwatch after it was orphaned by the previous maintainer. This package has a particularly long history in Fedora, carries quite a few patches, and had seen no upstream releases in many years until late 2019. I just updated Rawhide to ship the latest upstream