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

[Benjamin Beasley]

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
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: Golang 1.19 (System-Wide Change proposal)

[Benjamin Beasley]

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 Freeze is currently scheduled for 2022-08-23, and Go 1.19 final is 
scheduled for sometime in August, so getting the mass rebuild done with the 
final version before the beta freeze might be tight or it might be just fine.
___
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

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

[Benjamin Beasley]

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 wiki[1].

I’m not sure what that means in terms of how to handle these cases, but it does 
suggest that many of these lingering updates may reflect conscientious 
application of the guidelines at the time rather than maintainers simply losing 
track of updates.

[1] 
https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_little_bit_bigger_minor_version_updates
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Benjamin Beasley]

> * 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 section in libgcc_s,
> presumably caused by the unwinder changes.  The GCC change is fine by
> itself, it's a real GDB bug.
> 
> Thanks,
> Florian

Thanks for the pointer! I did a successful local mock-build of debugbreak with 
the patched RPMs from the scratch build linked in 
https://bugzilla.redhat.com/show_bug.cgi?id=2042664#c4, which confirms I really 
am seeing that particular GDB bug.
___
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

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

[Benjamin Beasley]

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

License of mpir package simplified to LGPLv3+

[Benjamin Beasley]

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.
 While not strictly required when there is a single effective license, a 
breakdown of the exact licenses for various source files is still included.
___
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

Orphaning mkdocs-markdownextradata-plugin

[Benjamin Beasley]

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 perfectly usable if someone rescues the rest of the mkdocs 
packages—and I may pick it up again if that happens—but for now I have thrown 
it onto the pile.
___
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: Building docs of compiled extensions with new macros

[Benjamin Beasley]

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 
https://src.fedoraproject.org/rpms/python-asyncpg/blob/ca0bedc42ddba790ffda74cbaa48a06daf7d141e/f/python-asyncpg.spec#_103
 for an example.
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Benjamin Beasley]

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 unrelated problems causing FTBFS are resolved.

Others (cairomm/cairomm1.16) presumably used only header-only parts of Boost, 
and were silently continuing to use the old Boost. I rebuilt these as well.

It’s probably worth looking into the process for finding and rebuilding 
dependent packages to see why these were not rebuilt, as there must be many 
other packages that also should have been rebuilt but were not.
___
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: Easy way to temporarily change smp_mflags in mock or fedpkg mockbuild?

[Benjamin Beasley]

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 -- 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: An unsuccessful case study: Using pyproject-rpm-macros with PyQt-builder and sip 5

[Benjamin Beasley]

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, then python-pendulum, which uses poetry, may 
be the only example right now.
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Benjamin Beasley]

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

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

[Benjamin Beasley]

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, which is still orphaned. (If 
you, the reader, do want to claim it, I’m happy to send you a PR to update the 
packaging as I did for the other packages, and to work around the 
currently-missing python-aiozmq in Rawhide. I just don’t want to maintain this 
package.)

In one week, I will update python-engineio to 4.2.0 
(https://src.fedoraproject.org/rpms/python-engineio/pull-request/1), 
python-socketio to 5.3.0 
(https://src.fedoraproject.org/rpms/python-socketio/pull-request/1), and 
python-flask-socketio to 5.1.0 
(https://src.fedoraproject.org/rpms/python-flask-socketio/pull-request/1), all 
in Rawhide only. These are all breaking major version updates that introduce 
EngineIO protocol version 4 and SocketIO protocol version 5. The updates 
shouldn’t directly affect anything in Fedora at the moment, except perhaps the 
orphaned python-jsonrpcserver package. Still, the new versions will be built in 
a side tag as a multi-build update.
___
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

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

[Benjamin Beasley]

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: “GPLv3 and LGPLv2+ and CC0” becomes “GPLv3”
- gaupol: “GPLv3+ and CC0” becomes “GPLv3+”
- harmonyseq: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
- libinstpatch: “LGPLv2 and Public Domain” becomes “LGPLv2”
- notejot: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
- sequeler: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
___
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: Need assistance to build Blender

[Benjamin Beasley]

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 the problem. The libraries may or may not be necessary—I didn’t take 
time to investigate.

--- blender-2.93.0-original/source/blender/io/usd/CMakeLists.txt
2021-04-21 10:23:41.0 -0400
+++ blender-2.93.0/source/blender/io/usd/CMakeLists.txt 2021-06-24 
13:02:05.568490263 -0400
@@ -53,6 +53,7 @@
   ${USD_INCLUDE_DIRS}
   ${BOOST_INCLUDE_DIR}
   ${TBB_INCLUDE_DIR}
+  ${PYTHON_INCLUDE_DIRS}
 )
 
 set(SRC
@@ -86,6 +87,8 @@
 
 list(APPEND LIB
   ${BOOST_LIBRARIES}
+  ${PYTHON_LINKFLAGS}
+  ${PYTHON_LIBRARIES}
 )
 
 list(APPEND LIB
___
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

License field change: dippi

[Benjamin Beasley]

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, the License 
field has been updated from “GPLv3+ and GPLv2+ and CC0” to "GPLv3+".
___
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: x86_64-v2 in Fedora

[Benjamin Beasley]

> 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 hardware is
> expensive in multiple ways (time, capex, and various legal aspects). That
> leaves listening to the maintainers.

At the risk of overextending an already well-elaborated thread, I would like to 
point out that my main workstation, for Fedora packaging and other purposes, 
has an Intel Q6600 (Core 2 Quad) that does NOT meet the requirements for 
x86_64-v2. I built it in 2007, and it has exceeded all expectations for how 
long it would remain useful. The desktop I maintain for my parents uses an AMD 
Phenom II X4 965 processor, circa 2009-2010, and it doesn’t support x86_64-v2 
either—but it just keeps on working.

Now, I can afford to replace my own workstation if I must—and I’m planning to 
do so in another year or two when the rolling component shortages settle out a 
little—but I suspect there are still many others like me, some of whom might 
not be in a position to just sigh and buy new hardware. Even for those who can, 
the pandemic and the crypto crazes have made it an exceptionally bad time to be 
forced into an upgrade.
___
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Benjamin Beasley]

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, let me point to pipx as an example where I recently gave up on 
maintaining an ever-shifting list of 50 tests that require interaction with 
PyPI 
(https://src.fedoraproject.org/rpms/pipx/c/55c6c9debf3039747327686a2f07dc31cd1e966b?branch=rawhide).
 It just wasn’t worth it to keep doing this in order to run the small minority 
of tests that can work offline. Even worse, upstream recently added an offline 
bundle of a huge number of PyPI wheels to make these tests reproducible 
offline, but this bundle is arch-specific with compiled binary wheels (a 
non-starter for including as a Source# file), and it would now require a 
nontrivial patch to run ANY of the tests without either the wheel bundle or a 
network connection.

Now, running these fussy tests in CI would be great! I would accept a 
reasonable PR to do so. But I’m not excited about learning Yet Another 
YAML-Based Programming-As-Configuration Language being an absolute requirement 
in order to maintain packages that have impractical upstream tests like these. 
There are an increasing number of upstreams with test suites that are really 
only designed to run in upstream’s own fickle CI, and reproducing these 
environments could be quite a burden. Realistically, I picked up pipx and 
cleaned it up after it was orphaned, and I’m likely just to file a Bugzilla and 
orphan it again if CI is mandated. Unfortunately, I suspect there are many 
packagers who would choose quiet noncompliance instead.

Another example is python-strictyaml. It builds its documentation using an 
idiosyncratic build system (see https://hitchdev.com/) that is hopelessly 
entangled with the idea of downloading dependencies from PyPI. An offline 
documentation build is therefore nearly impossible. Currently, it has no tests 
upstream, but if it ever adds them, they will be run via the same system and 
will also be effectively impossible to run offline.

A third example is python-pgspecial. Most of the tests require a postgresql 
database, which I cannot set up in %check because this requires root 
privileges. This package actually seems like it would be compliant today, 
because it has a few tests that work without the database connection, and 
automatically skips the rest—but I am sure there are others where every single 
test requires a privileged operation. That would be the case for 
python-databases if it did not support SQLite.

A fourth example is python-absl-py. There are a couple of “smoke tests” that I 
can and do run, but the core test suite requires Bazel—which, as has been 
discussed before, will probably never be successfully packaged for Fedora.

I’m still in favor of running every test that is even vaguely practical in 
%check, but upstream Python packaging practices are wildly diverse (arguably, a 
mess) and it seems like a strongly worded SHOULD with a fallback of “trust the 
packager” would be a better approach than forcing packagers to build 
complicated CI configurations and go to great lengths to implement and debug 
network-connected tests they cannot reproduce locally.

It’s also not clear to me why the Python guidelines should be so much stricter 
than the overall Fedora guidelines 
(https://docs.fedoraproject.org/en-US/packaging-guidelines/#_test_suites) in 
this area.
___
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:  Advice on packaging azure-cli

[Benjamin Beasley]

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 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: [cdparanoia] License field fix awaiting to be merged

[Benjamin Beasley]

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

The “effective license” approach you advocated is not mentioned in the 
packaging guidelines but has historical support in the wiki 
(https://fedoraproject.org/wiki/Licensing:FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F).
 It has also come up on the fedora-legal list recently 
(https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/W57JRNLWVOT55D7TDF7VYFMJT5QMBEGR/).

There is, I think, a valid question of how much mechanistic detail to apply to 
documenting the source files *that contribute to the binary RPM contents.* One 
approach, which I have favored in my packages, exhaustively lists licenses of 
such files. The other, which you have advocated, simplifies the license field 
into an “effective license” when clearly appropriate. Both philosophies seem to 
be well-established as acceptable. My view is therefore this patch seems to be 
correct but not absolutely required.

HOWEVER: I have to agree with you that the idea of documenting the licenses of 
SRPM contents seems to be a questionable justification, as current Guidelines 
are clear that the License field is for the binary package contents. If 
documenting SRPM contents became policy, it would require pervasive changes to 
existing packages. For example, sources that belong to the build system would 
need to be documented. Nearly all autotools-based packages would have to add 
several licenses, as install-sh is commonly MIT, aclocal.m4 and various 
generated files are commonly FSFULLR, configure scripts are commonly FSFUL, at 
least GNU configure.ac files are commonly FSFAP, and so on. If following this 
approach strictly, even the licenses of bundled libraries removed in %prep 
would need to be documented—after all, they are still in the source tarball, so 
they are in the SRPM. In addition to being tedious, I think that would make the 
License field less useful than it is now.
___
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

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

[Benjamin Beasley]

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 EPEL8.
___
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: Unannounced soname bump: libgta

[Benjamin Beasley]

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

License change: npm-name-cli adds 0BSD

[Benjamin Beasley]

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 
to the License field in Rawhide. The result is:

MIT and 0BSD and ASL 2.0 and BSD and (BSD or MIT or ASL 2.0) and CC0 and CC-BY 
and ISC and (MIT or CC0) and MPLv2.0
___
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

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

[Benjamin Beasley]

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
  • python3-grpcio-health-checking
  • python3-grpcio-reflection
  • python3-grpcio-status
  • python3-grpcio-testing

The C API/ABI so-version will be bumped to “15”, and the C++ API/ABI so-version
to “1”. Additionally, for compatibility with the system copy of abseil-cpp, the
C++ libraries are now built with C++17, which may affect their ABI.

I have built the new version into the side tag “f35-build-side-41105”.

Testing and contributions are welcome. I’ve improved the quality of this
package quite a bit over the last few months since I started maintaining it,
but it is still far from perfect (and will likely remain so, given the nature
of its upstream). Particularly, there are still a significant number of
unexplained test failures, many of which are architecture-specific, that I have
to skip. Any contributions to understanding these well enough to fix them or
usefully report them upstream (understanding that upstream runs the tests very
differently, with a dedicated test build using docker) are very welcome.

I have identified the following packages that will need to be rebuilt because
they depend on the C or C++ libraries. Each package has received a PR, or
a new Bugzilla issue in preparation for a PR.

  • bear
  • frr
  • perl-grpc-xs

The following packages use the Python bindings. Testing with the new version
would be a good idea, but a rebuild should not be required. For the first two,
I performed a successful scratch-build using the side tag to check for any
issues. The last two are FTBFS for unrelated reasons
(https://bugzilla.redhat.com/show_bug.cgi?id=1959534,
https://bugzilla.redhat.com/show_bug.cgi?id=1959540).

  • buildstream
  • python-google-api-core
  • python-opencensus
  • python-opentelemetry

Any contributions are welcome, from testing to auditing the spec file (PRs
welcome) to co-maintainers. The missing language bindings (Ruby, PHP, C#,
Objective-C) are much more likely to be packaged if I have input from someone
with experience packaging for those languages. I’m not a user of this package,
and now that I’ve brought it back to usable and current condition, I’d welcome
those interested in taking co-maintainer responsibility for any of the 
following:
  • the whole package (I would be happy for someone else to be the primary
maintainer in the long term)
  • EPEL 8 (https://bugzilla.redhat.com/show_bug.cgi?id=1757147); currently
this means getting a significant number of dependencies into EPEL 8 and
perhaps offering to co-maintain them there
  • particular language bindings (C++, Python, or the as-yet unpackaged Ruby,
PHP, C#, or Objective-C)
  • running down test failures and other warts and figuring out patches and/or
reporting them upstream usefully
Drive-by contributions are appreciated too, of course.
___
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

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

[Benjamin Beasley]

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

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

[Benjamin Beasley]

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 Public Domain”, and a so-version bump 
from 0 to 2. Also the directory containing the headers now ends in the 
so-version (%{_incdir}/libinstpatch-2), but dependent packages all use 
pkgconfig and do not care.

I have built the update in the side tag “f35-build-side-40054”. The following 
PR’s cover the dependent packages:

muse: https://src.fedoraproject.org/rpms/muse/pull-request/1
gsequencer: https://src.fedoraproject.org/rpms/gsequencer/pull-request/1
___
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

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

[Benjamin Beasley]

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 improvements, 
eventually reaching all current Fedora releases.
___
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

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

[Benjamin Beasley]

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 be providing the latest version, 2.8, with the corrected License field, 
as a compatible update to all current Fedora releases. This update will also 
resolve a variety of FTI and FTBFS bugs.
___
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

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

[Benjamin Beasley]

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.)
___
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

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

[Benjamin Beasley]

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 
https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/message/FMFIZU22AP36J3DOUVCXUPHQ3MNDN5P6/
 for details if you are interested.
___
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

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

[Benjamin Beasley]

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 “GPLv3+” to “GPLv3+ 
and MIT and CC0 and GPLv3 and ISC and ASL 2.0 and BSD and zlib and IJG”.

It is my hope that, over time, the number of bundled dependencies can be 
reduced by submitting them to Fedora, where they are not already present, and 
by patching the build system where necessary, ideally in a way that can be 
submitted upstream.
___
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

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

[Benjamin Beasley]

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

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

[Benjamin Beasley]

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: 
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: Fwd: Orphaning some packages (C++/Gtkmm)

[Benjamin Beasley]

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

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

[Benjamin Beasley]

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 harvey has been corrected from “GPLv3” to “GPLv3+ and GPLv2+ 
and CC0”.

The license for notejot has been corrected from “GPLv3” to “GPLv3+ and GPLv2+ 
and CC0”.

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

The license for gaupol (but not python3-aeidon) has been corrected from 
“GPLv3+” to “GPLv3+ and CC0”.
___
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

Re: Orphaned: all my elementary AppCenter application packages

[Benjamin Beasley]

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

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

[Benjamin Beasley]

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

License field change and future plans: grpc

[Benjamin Beasley]

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 reflect an upstream 
change.

Upstream does also provides certain source files under other licenses (ISC, 
MIT, MPLv2.0), but at this point these are all removed in %prep. Previous 
versions of the package *should* have been “ASL 2.0 and BSD and MPLv2.0”, but I 
have replaced the MPLv2.0-licensed certificate bundle with a symbolic link to 
the system shared certificates.

There are a number of subpackages, some pre-existing, and some new. Many 
(grpc-cpp, grpc-plugins, grpc-cli, grpc-devel, python3-grpcio, 
python3-grpcio-tools) now have the same “ASL 2.0 and BSD” license as the base 
package, while others (grpc-data, grpc-doc, python3-grpcio-channelz, 
python3-grpcio-health-checking, python3-grpcio-reflection, 
python3-grpcio-status, python3-grpcio-testing, python-grpcio-doc) are still 
just “ASL 2.0”. This generally falls along arch/noarch lines.

I already fixed quite a few defects in the package, and added several Python 
packages that were not being built. As I keep working on this package, I plan 
to:
  - Switch from building with make to building with CMake, which is 
better-supported upstream.
  - Try to build and run the test suite.
  - Update to the latest version; at this point, I will build into a side tag, 
coordinate with dependent packages, and issue a call for testing on this list. 
This package is a Byzantine warren of code, and I am not even a user of it—just 
someone with a lot of experience digging through Byzantine warrens of code—so 
there are a lot of things that could go wrong, or could have already gone wrong 
undetected a long time ago! I’d like to get to this point for Fedora 34.
  - Try to build for EPEL8.
  - Start trying to build the bindings for languages other than C, C++, and 
Python.

We’ll see how it goes!
___
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

Re: cmake FTBFS in rawhide

[Benjamin Beasley]

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 trying to 
allocate eight times as much memory, even though both machines have similar 
amounts of RAM. I think that explains it adequately. Presumably scratch builds 
just happen to be assigned to machines with more cores at the moment.

I think you will need to either skip the multi-threaded TXZ test, or bound its 
memory requirements by patching it to use some fixed value for 
CPACK_ARCHIVE_THREADS instead of 0. See 
https://cmake.org/cmake/help/latest/cpack_gen/archive.html#variables-used-by-cpack-archive-generator.
___
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

SONAME bump: cpp-hocon

[Benjamin Beasley]

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 rebuilt into the 
side tag (https://src.fedoraproject.org/rpms/facter/pull-request/6).
___
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

Help with compiling SASS to CSS in a Python package

[Benjamin Beasley]

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 package. 
However, the review is hung up on the web assets it includes.

Upstream uses gulp to compile/bundle and minify the JavaScript, and compile 
SASS to CSS, in order to produce the PyPI source tarball. Based on 
https://docs.fedoraproject.org/en-US/packaging-guidelines/JavaScript/#_compilationminification,
 https://docs.fedoraproject.org/en-US/packaging-guidelines/Web_Assets/#_css, 
and 
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_pregenerated_code,
 it will be necessary to use the GitHub source tarball instead and do all of 
the additional work in the RPM build.

For the Python part, in which the GitHub tarball is a PEP 517/518 format source 
tree without a “legacy” setup.py, python3-flit can do the job of building a 
wheel, and %py3_install_wheel can install it. No problem.

For the JavaScript part, bundling and minification can’t use uglify-js because 
ES6 “const” is used, and it can’t use esbuild (golang-github-evanw-esbuild) as 
intended because upstream does not use ES6 modules and imports. However, 
“bundling” by simple concatenation with cat, optionally followed by 
minification with esbuild, should work fine. It would break source maps, but at 
least the original sources would still be included in the RPM.

The problem is the SASS. Upstream uses gulp-sass with the JavaScript-transpiled 
version of dart-sass, which seems to be the only SASS compiler that is not 
deprecated today. Trying to compile with rubygem-sass or either frontend to 
libsass (sassc/rubygem-sassc) gives an error like:

sassc -a src/furo/assets/styles/furo.sass 
Error: Invalid CSS after "...ow-y: scroll; }": expected 1 selector or at-rule, 
was "not(html):not(body)"
on line 20:24 of src/furo/assets/styles/_scaffold.sass
from line 5:1 of src/furo/assets/styles/furo.sass
>>   overflow-y: scroll; }

   ---^

with various other errors following if the offending section is commented out. 
I don’t know SASS too well, but it doesn’t look too practical to patch our way 
out of this.

This is a call for help, then. Does anyone see a way forward for this package?

More details are in the review request Bugzilla issue, linked at the beginning 
of this email.

Thanks,
Ben Beasley
___
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

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

[Benjamin Beasley]

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 License 
field for the aeidon/python2-aeidon subpackage remains “GPLv3+”.

This change does not affect the newer release of gaupol currently in testing 
for EPEL8, nor the versions already available in supported Fedora releases.

– Ben
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Notice of recent License field change: mpir

[Benjamin Beasley]

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+ or GPLv2+) and BSD

and added a new PACKAGE-LICENSING file to explain the details. Note that the 
upstream license did not change; this is what should have been in the License 
field all along.

– Ben
___
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

Notice of upgrading xalan-c to 1.12.0 in Rawhide

[Benjamin Beasley]

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 
https://koji.fedoraproject.org/koji/taskinfo?taskID=56532547.

Because the ABI will change (so-version changes from 111 to 112), the following 
packages will need to be rebuilt. I will forward this notice directly to their 
maintainers.

libdigidocpp – maintained by germano
xml-security-c – maintained by kloczek

The new release brings the following significant changes to the Fedora package:

- Source code signature verification
- New CMake build system
- Enable new optional ICU dependency
- Build API documentation with Doxygen

It will also resolve the following outstanding bugs:

xalan-c: New upstream release 1.12
https://bugzilla.redhat.com/show_bug.cgi?id=1900893

xalan-c: FTBFS in Fedora rawhide/f33
https://bugzilla.redhat.com/show_bug.cgi?id=1865631

I am also happy to report that we no longer need to carry a 6000+ line patch!

Note that the -devel packages now include pkg-config and CMake module files.

The upstream changelog for the new release is available at:

https://github.com/apache/xalan-c/releases/tag/Xalan-C_1_12_0
___
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

Arpwatch updated to 3.1 – testing and auditing appreciated!

[Benjamin Beasley]

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 version, 3.1; the entire 
spec file has been modernized and de-crufted, and I have reviewed and dropped, 
rebased, or rewritten every patch or extra source file carried by the Fedora 
package. (I will send all remaining patches and extra sources upstream for 
consideration prior to the release of Fedora 34; I am waiting for further 
testing before doing so.)

I’ve made all these changes very carefully; still, given the scope of the 
necessary changes, I would especially appreciate testing and feedback from any 
arpwatch users, as well as from anyone who feels like auditing the current spec 
file and/or patches (https://src.fedoraproject.org/rpms/arpwatch/tree/master).

– Ben Beasley
___
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