For desktop-class hardware, the parts that are most likely to fail
around the decade mark are storage drives, power supplies, and perhaps
fans. All of these are fully standardized and in plentiful supply; there
is no reason that first-party hardware vendor support should be required
to keep
While the autoreconf command is “external,” it does implicitly execute
m4 scripts, often including some that are included in the package source
distribution, in order to generate the configure script. Note also that
autogen.sh is rarely more than a trivial one-to-five-line wrapper around
The libcerf package was updated to version 2.1 in Rawhide yesterday[1],
which included an unannounced .so version bump from “1” to “2”.
The following packages will need to be rebuilt:
- LabPlot
- gnuplot
- libecpint
[1]
Correction: of course, 2022-04-08 is today, and 2022-04-15 is one week
from today.
On 4/8/22 17:07, Ben Beasley wrote:
In one week (2022-04-08), or slightly later, I plan to build
python-versioningit 1.1.1 in Rawhide[1]. There are breaking API
changes[2] in the 1.x series, but python
In one week (2022-04-08), or slightly later, I plan to build
python-versioningit 1.1.1 in Rawhide[1]. There are breaking API
changes[2] in the 1.x series, but python-versioningit appears to be a
leaf package at the moment, so this should not affect any other packages
in the distribution.
[1]
Indeed, HP (now HPE) first introduced UEFI support to their ProLiant
servers in the Gen8 series, which I believe was around 2013. While I
think the previous G7 servers have reached the end of their support
lifecycle (but are probably still happily running in some places), UEFI
has indeed been
Thanks for updating these pages.
I noticed that the Flask and Django pages have language like:
Fedora includes a |python3-flask| package that you can install and
import. However, unless you are developing or packaging an
application for Fedora, it is more useful to install Flask as a
I have no idea whether or not this Change would add significantly to
package build times in practice. It’s a good question. I think answering
it would require benchmarks rather than asymptotic reasoning, though.
There are plenty of things in an RPM build that already inherently take
O(N) time
This is just a heads-up that I am retiring python-typer-cli in
F37/Rawhide due to an ongoing lack of upstream support. It is a leaf
package.
Important functionality has been patched out downstream[1] for about six
months due to incompatibility with click version 8.x and typer version
0.4.0
This is a “stub file” for type checking. It looks like upstream is
trying to follow https://peps.python.org/pep-0484 rather than the later
https://peps.python.org/pep-0561/. However, the way they are installing
the stub file with data_files in setup.py is resulting in it getting
dumped in
I encountered the same problem in luminance-hdr. It does not seem to
affect all packages that link qt5-qtwebengine. I would like to know the
root cause, but never figured it out. Instead, I was able to work around
it by disabling LTO in my own package. More details in the bugs below.
I will build python-probeinterface 0.2.8[1] for Rawhide in one week
(2022-03-30), or slightly later.
This breaks the API by renaming:
- `probeinterface.probe.select_dimensions` to
`probeinterface.probe.select_axes`
- the `plane` keyword argument of `probeinterface.probe.to_3d` to `axes`
-
Also, specifically:
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
On 3/22/22 21:30, Scott Talbert wrote:
On Tue, 22 Mar 2022, Paul DeStefano wrote:
Greetings. I just joined devel, following directions I found on how
to become maintainer of an
I interpreted this to mean that, while this Java proposal and
Changes/EncourageI686LeafRemoval both have to do with i686 removals:
- the Java change should not be seen as part of Changes/EncourageI686LeafRemoval
- the Java change was written without knowledge of
Changes/EncourageI686LeafRemoval
Since icedtea-web was orphaned for 6+ weeks, it was retired. You must
therefore follow [1]. Note that:
Retired Fedora packages (rawhide branch retired) require a
re-review if they are retired for more than eight weeks or if there is
no previous review of the package.
This package has a
The packaging effort is real; it’s just unevenly distributed across different
types of packages, so some packagers might not have noticed it.
Packaging work that, with the demise of 32-bit ARM, can now be ascribed purely
to these generally-unused i686 packages includes:
- As Fabio noted,
Petr said pretty much the same thing I was about to say.
As others have noted, the “indirect sub-type change” seems to be an
awkward way of saying the function prototype has changed, which is
certainly an ABI change for the mbest_search function. The only question
is, is mbest_search really
Assuming you are already a packager, please follow this process:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/
On Wed, Mar 2, 2022, at 5:31 PM, Linus Walleij wrote:
> Hi,
>
> it seems the maintainer of gnome-shell-extension-freon is not responsive
>
I’m not very familiar with mold’s pros and cons other than its speed,
but I think that architecture limitations[1] will limit widespread
adoption for the time being:
||
# mold can currently produce native binaries for x86, aarch64 and
riscv64 only
ExclusiveArch: x86_64
In one week (2022-03-08), or slightly later, we plan to update
abseil-cpp[1] to version 20211102.0 in Rawhide by merging this PR[2] and
coordinating rebuilds of dependent packages into a side tag. This
includes a new .so version, “2111.0.0”.
The following packages will therefore need to be
I’d like to find some reviewers to clear out my backlog of mostly-Python
packages. These vary from near-trivial to moderately complicated.
I’m happy to review packages in exchange. I’m particularly comfortable
with C, C++, and Python, but reviewing other kinds of packages is a
possibility. It
Ok, this is simple enough, and you’ve been looking for someone to help
for quite a while, so I’ll bite.
Someone will need to do the review:
https://bugzilla.redhat.com/show_bug.cgi?id=2059247
– Ben
On 2/23/22 19:44, Kelly Brazil wrote:
Hi team,
I am the developer of JC and Jello. JC is
Jędrzejewski-Szmek wrote:
> On Sat, Feb 26, 2022 at 02:00:08PM -0500, Ben Beasley wrote:
>> The c4core package will be updated to 0.1.9 in Rawhide in one week
>> (2022-03-05), or slightly later, with an accompanying .so version bump. This
>> shouldn’t affect any packages
The c4core package will be updated to 0.1.9 in Rawhide in one week
(2022-03-05), or slightly later, with an accompanying .so version bump.
This shouldn’t affect any packages, as c4core is a leaf package. (It
will be a dependency for rapidyaml once that is packaged.)
– Ben
I have stopped using the “forge” macros in most cases where I am packaging a
release/tag, since the URLs are simple enough without them, usually something
like
URL: https://github.com/foo/bar
Source0: %{url}/archive/v%{version}/bar-%{version}.tar.gz
However, when I need to package an untagged
With version 1.8.0, upstream for python-userpath has dropped the Apache
license option. The License field has therefore changed from “MIT OR ASL
2.0” to simply “MIT”. This version will appear in F37/Rawhide and (after
the beta freeze) F36/branched.
– Ben
Yes, the devtoolsets work nicely if you supply the appropriate incantations. I
haven’t tried in COPR specifically, but I assume the situation is the same as
in EPEL proper. Please see the very clean example in the epel7 branch for
sleef[1], which was kindly contributed by Dave Love.
– Ben
[1]
This idiom is known as “flexible array member,” and it is standardized since
C99. The “bar[0]” syntax you mention is a GCC extension predating C99.
I’m not that familiar with the nuances of SWIG, but it looks like SWIG doesn’t
understand this at all, and is treating “bar” as a pointer member
All current versions of *Fedora* have CMake 3.20 or later, so you
shouldn’t have any problems there.
When packaging for EPEL, you rely on the package versions that were
released with the corresponding version of Red Hat Enterprise Linux.
RHEL aims to provide long-term stability, so these
This is covered by the Updates Policy[1]. There is quite a bit written
there about why an incompatible update might or might not be allowed in
a stable release. It also specifically addresses security updates[2],
and describes how you can petition FESCo for an exception, either for a
Thank you for contributing to Fedora. At the request[1] of Christopher
King (FAS bunnyapocalypse), I have sponsored you to the packager group
as a co-maintainer[2] for the lutris package.
Welcome, and happy packaging!
[1] https://pagure.io/packager-sponsors/issue/522
[2]
This is the obligatory announcement that the license of the
gi-docgen-doc subpackage of gi-docgen has been corrected from:
(ASL 2.0 or GPLv3+) and CC0 and CC-BY
to:
(ASL 2.0 or GPLv3+) and CC0 and CC-BY-SA
___
devel mailing list --
Your points about why touching dist-git for rebuilds can be problematic are
correct, I think. However, I don’t see an easy way around the fact that a
release bump is required to produce a new build that obsoletes the previous
build, and that interaction with dist-git is required to make this
, and sometimes life just doesn’t permit that work.
I extend my deepest sympathies for your recent hardships, and wish you a
smoother and happier future.
– Ben
On 2/14/22 00:09, Kushal Das wrote:
On 13/02/22, Ben Beasley wrote:
Does anybody know how to contact Kushal Das (FAS kushal), or whether
Does anybody know how to contact Kushal Das (FAS kushal), or whether he
wants to remain active in Fedora?
I have initiated a non-reponsive maintainer check for by filing the
required bug on python-ujson[1]. This is the required email for the
non-responsive maintainer process[2].
The
There was an missed/unannounced .so version bump in glew[1] which affected a
lot of packages, including vtk.
It looks like vtk builds for F36-F37 are currently in progress.
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DLZLYNVJOMAACLAKW4OF63ZHFVFQ3GV5/
At the request[1] of Serge Guelton, who is a package maintainer for
llvm, I have just sponsored Nikita Popov (FAS nikic) into the packager
group a co-maintainer.
Welcome, and thank you for your contributions to Fedora!
– Ben Beasley
[1] https://pagure.io/packager-sponsors/issue/521
It looks like the recent update to glew 2.2.0[1] in F36 and F37
contained an undetected/unannounced .so version change.
This is breaking vtk[2] and presumably a lot of other things.
I suggest updating the globs in the %files list[3] to keep this from
happening in the future.
[1]
This is indeed a can of worms.
A previous discussion on the packaging list[1] concluded that, despite the
common practice of packaging Sphinx-generated HTML documentation, there is
probably no practical way to do so without running afoul of guidelines about
bundled or precompiled JavaScript,
I agree with Petr’s response, and I would like to add that most of the
motivations for creating an EPEL-only package are in fact covered by one
of the review exceptions[1], e.g:
*
The package is being created so that multiple versions of the same
package can coexist in the distribution
Note also that gstreamer1, gstreamer1-plugins-base, and
gstreamer1-plugins-good are currently orphaned.
– Ben
On 2/4/22 07:54, Mamoru TASAKA wrote:
Richard W.M. Jones wrote on 2022/02/04 21:21:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82370784
DEBUG util.py:444: Problem:
Check https://src.fedoraproject.org/lookaside/, specifically
https://src.fedoraproject.org/lookaside/rpm-specs-latest.tar.xz. This covers
Rawhide only, of course.
On Mon, Jan 31, 2022, at 7:03 PM, Germano Massullo wrote:
> Good day. I have to search gcc-toolset among all Fedora packages specs
That looks like it’s due to fmt not having been rebuilt with the ABI change
yet, presumably due to https://bugzilla.redhat.com/show_bug.cgi?id=2045391.
On Wed, Jan 26, 2022, at 7:30 PM, Adam Williamson wrote:
> On Wed, 2022-01-26 at 23:57 +0100, Jakub Jelinek wrote:
>> Hi!
>>
>> A new gcc with
Your original reviewer (or any Fedora packager) can still approve the package
even though they are not a packager sponsor. You just won’t be able to import
it until you have found a sponsor. It’s normal to have one or more packages
approved before finding a
Skimming through Koschei, here are a sampling of regressions that seem
to be associated with GCC 12. Some of these are in packages I maintain
directly; others are via @neuro-sig.
With a few exceptions, I have triaged these only to the extent of
confirming the problem appeared at the same time
To clarify, this is affecting the
https://src.fedoraproject.org/rpms/json package and (since it is a
header-only library) some or all of the many packages that use it.
Here’s the upstream issue: https://github.com/nlohmann/json/issues/3138
It looks like they’re not sure what to do about it
I (and others) encountered this too. It’s reported here[1], with a fix promised
today.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2040825
On Sat, Jan 15, 2022, at 7:06 AM, Vitaly Zaitsev via devel wrote:
> On 14/01/2022 15:31, Jakub Jelinek wrote:
>> gcc 12 snapshot has landed as the
As I understand it, the --with-long-double-format=ieee change should
stop Boost.Math from exploding with a preprocessor error “Sorry, but
this platform does not have sufficient long double support for the
special functions to be reliably implemented” on ppc64le[1].
This will likely allow
At the request of tboot maintainer Sun Yunying (yunyings)[1], I have
sponsored Jun Miao as a co-maintainer[2]. Welcome to Fedora!
[1] https://pagure.io/packager-sponsors/issue/513#comment-774848
[2]
with tools, processes,
packaging guidelines, debugging, or anything else that you might need to
know [1].
Welcome to Fedora! Thanks for your contributions, and happy packaging.
Regards,
Ben Beasley
[1]
https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_responsibilities/
On 1/3/22 12
I think this makes perfect sense. It would be generally helpful for the
reasons stated, and it’s hard to imagine any cases in which it could be
harmful.
– Ben
On 1/10/22 07:55, Miro Hrončok wrote:
Hello Pythonistas.
When we invented the %pyproject_buildrequires BuildRequires generator,
it
At the request of the current qatzip package maintainer, Zheng Ma, I
have sponsored Xinghong as a co-maintainer.
Welcome to Fedora!
Regards,
Ben Beasley
On 1/6/22 21:12, Chen, Xinghong wrote:
Hello all:
I’m Xinghong from the Intel NPG-QAT team. I'm very interested in
becoming a Fedora
On 2022-01-12, or slightly later, I plan to update c4core to version
0.1.8 [1] in Rawhide, which will bump the SONAME version. There are
currently no dependent packages; c4core will be a dependency for
rapidyaml, which is not yet packaged.
[1]
Is the backtrace not helpful in figuring out where to set up
breakpoints? As in, “gdb foo”, then “run”, wait for the crash, and type
“bt”?
The darktable development documentation suggests[1] the following to log
useful backtraces:
|$ gdb darktable ... crash dt here ... (gdb) set
On 12/24/21 16:13, Neal Gompa wrote:
On Fri, Dec 24, 2021 at 3:56 PM Ben Beasley wrote:
[…] I plan to stop building
the static library, drop the iml-static subpackage, and Obsolete the
iml-static subpackage via the iml package […]
I'd recommend obsoleting it with the -devel package instead
nobody speaks up to tell me that I’ve missed a reason to keep it around.
– Ben Beasley
[1] https://src.fedoraproject.org/rpms/iml
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le
I will review these.
– Ben
On 12/23/21 05:54, Sandro Mani wrote:
Hi
I have the following packages pending review:
python-flask-gravatar - https://bugzilla.redhat.com/show_bug.cgi?id=2033804
python-flask-paranoid -
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2033803
I have taken freexl.
I am willing to take pyshp, python-OWSLib, and readosm, but they have
not been orphaned.
Co-maintainers are (always) welcome.
- Ben Beasley (FAS music)
On 12/12/21 17:18, Emmanuel Seyman wrote:
* Volker Fröhlich [12/12/2021 23:03] :
All of my packages are up
I am orphaning the following packages that contain a NodeJS “production”
dependency bundle:
- fkill-cli
- fx (along with fx-completion, which depends on it)
- nodejs-svgo
- npm-name-cli
- topojson-client
- topojson-server
- topojson-simplify
Considering recent and ongoing discussion over the
I’m happy, in principle, to help co-maintain ROCm packages.
However, before becoming a co-maintainer, I always like to take a look
over packages and make sure I’m comfortable with them, i.e.:
- I can reconcile them with packaging guidelines
- I think I can fix most things that are likely to
It turns out that while a couple of packages I care about were actually
broken by the bump to 3.0, most of them were instead broken by the
update failing to install on F34[1].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=201
On 12/16/21 14:09, Ben Beasley wrote:
It looks like python
It turns out that while a couple of packages I care about were actually
broken by the bump to 3.0, most of them were instead broken by the
update failing to install on F34[1].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=201
On 12/16/21 14:09, Ben Beasley wrote:
It looks like python
It looks like python-pytest-cov was recently updated to 3.0.0 in F35[1]
and F34[2]. I noticed this because, between my own packages and those
maintained through @neuro-sig, I saw a wave of FTBFS notifications from
Koschei.
Unfortunately, because packages commonly pin a particular major
or
unpackaged software. I think a lot of people would be *very* excited
about that, if it is possible.
– Ben Beasley (FAS music)
[1] https://github.com/RadeonOpenCompute/rocm_smi_lib/
[2] https://github.com/RadeonOpenCompute/rocm_smi_lib/issues/84
[3] https://github.com/RadeonOpenCompute
Tom,
Per Omair Majid’s request[1], I have sponsored you to the packager group
via the co-maintainer path. Welcome to Fedora, and happy packaging!
– Ben Beasley
https://pagure.io/packager-sponsors/issue/504
On 12/14/21 10:42, Tom Deseyn wrote:
Hi everyone!
My name is Tom. I work on .NET
as necessary by appropriate choice of algorithm and parameters.
– Ben Beasley
On 12/14/21 11:25, Carlos O'Donell wrote:
On 12/14/21 10:16, Robbie Harwood wrote:
Carlos O'Donell writes:
- Life-cycle management (delete attachments).
Please don't delete attachments. It severely reduces
I’m happy to co-maintain polyclipping. It’s an indirect dependency for
my low-priority project of packaging https://github.com/googlefonts/gftools.
– Ben Beasley (FAS music)
On 12/13/21 05:11, Miro Hrončok wrote:
On 12. 12. 21 23:03, Volker Fröhlich wrote:
> I don't want to be a pack
/browser.js”, and the dev bundle contains 28
directories named “dist”. (The prod bundle is ~2k files and the dev
bundle is ~12k files including ~800 package.json’s.)
Surely the example spec file is meant to be compliant with the
guidelines it illustrates?
– Ben Beasley
[1]
https
Interestingly, I’m able to do local EPEL9 builds on F35 by using “fedpkg
--release epel9 mockbuild”, which seems to use an environment called
“epel9-candidate-${ARCH}”. I haven’t looked into where that comes from.
It doesn’t correspond to anything in /etc/mock.
– Ben
On 12/6/21 12:36,
I’d like to point to
https://src.fedoraproject.org/rpms/sleef/blob/epel7/f/sleef.spec as a
working example of a package that is built with a devtoolset in EPEL7.
While I maintain the sleef package, the EPEL7 backport was contributed
by Dave Love.
– Ben Beasley
On 11/25/21 08:56, David
Sandro: Thanks! I have added Thomas to the packager group.
Thomas: Welcome, and happy packaging!
– Ben
On 11/24/21 10:12, Sandro Mani wrote:
On 24.11.21 14:54, Ben Beasley wrote:
Welcome, Thomas!
There’s a straightforward process for a packager to request
sponsorship for a prospective
Welcome, Thomas!
There’s a straightforward process for a packager to request sponsorship
for a prospective packager as a co-maintainer:
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/#become_a_co_maintainer
Sandro, if you read through
For reference, the process for a stalled review in which the reviewer is
not responding can be found at
https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/#reviewer_not_responding.
– Ben
On 11/23/21 11:14, Mwesigwa Guma wrote:
Hello,
I hope you had a good week. I am sending
Please compare with
https://src.fedoraproject.org/rpms/xfontsel/blob/rawhide/f/xfontsel.spec,
paying close attention to the comments in the spec file. SKS keyservers have
gone offline since that package obtained its keyring, so try using
hkps://keys.openpgp.org instead.
That package also uses
I am guessing that the public_html/ directory in your home directory
does not exist or does not have the read and/or execute bits set for all
users. Try:
$ ssh aa...@fedorapeople.org 'mkdir -p public_html; chmod 0755 public_html'
to make sure the directory exists with the correct permissions.
Previously, the License field was “GPLv2+ and GPLv2 and GPLv3+ and
LGPLv2+ and BSD and MIT and Boost”.
This is corrected and simplified as follows:
The GPLv2-only sources were removed downstream some time ago, and the
functionality they provide patched out, since their license is
I know this pattern works in general, because I maintain several Python
packages in which it is used.
I tried modifying python-fixit to patch requirements.txt as you
described. I confirmed the line appeared in the “prepped” source as you
have written. Then I built it with mock and installed
In one week (2021-11-18), or slightly later, I will merge and build
https://src.fedoraproject.org/rpms/python-absl-py/pull-request/1,
updating python-absl-py to 1.0.0 in Rawhide.
In this release, upstream drops support for obsolete Python versions
(<3.6). This means the
I have simplified the License for the “jo” package from “GPLv2+ and MIT
and Public Domain” to the effective license “GPLv2+”. A spec file
comment explains:
# The entire source is GPLv2+, except json.c and json.h, which are MIT,
# and base64.c and base64.h, which are Public Domain. Since these
In one week (2021-11-13), or slightly later, I will build
python-starlette 0.17.0 in F36/Rawhide[1]. This release removes
deprecated GraphQL support, which is formally a breaking change.
I’ve tested rebuilding each of the following dependent packages using
starlette 0.17.0 and confirmed they
I don’t know where to find documentation for operator precedence in RPM
conditional expressions, but it looks like “!” binds more tightly than
“>=”, so
> %if ! 0%{?rhel} >= 8
is grouped as
> %if (! 0%{?rhel}) >= 8
which becomes, on Fedora:
> %if (! 00) >= 8
> %if 1 >= 8
and therefore
On 2021-11-10, or slightly later, I will build c4core 0.1.7 in Rawhide.
This includes an soname bump.
This notice is just a formality since c4core was introduced in order to
package rapidyaml in the future, and no packages yet depend on it.
___
<mailto:to...@pipebreaker.pl>> wrote:
On Tue, Nov 02, 2021 at 03:26:52PM -0400, Ben Beasley wrote:
> The License field of wlcs has been corrected from “GPLv2 or GPLv3” to
> “GPLv3”.
https://github.com/MirServer/wlcs
<https://github.com/MirServer/wlcs> (i
The License field of wlcs has been corrected from “GPLv2 or GPLv3” to
“GPLv3”.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
I think Björn Persson’s concerns are reasonable. Hopefully they can be
easily addressed, since I would be happy to see this change implemented.
At least six packages I maintain or regularly contribute to could be
simplified.
I spot-checked a libtool .la file to see what typical contents
Almost all of the Python packages I maintain have something useful in the
GitHub archive that isn’t in the PyPI archive. I find that PyPI source
distributions commonly lack test suites and usually lack documentation. I
choose PyPI sources where all else is equal, but in a lot of cases using
In one week (2021-11-03), or slightly later, I will build
python-engineio 4.3.0 in Rawhide
(https://src.fedoraproject.org/rpms/python-engineio/pull-request/2).
This release technically contains a breaking change (“Reject websocket
messages larger than max_http_buffer_size”), although it
Bear just needed a rebuild, which I took care of. It depends on grpc,
but was built before it in the side tag.
On 10/27/21 07:25, Miro Hrončok wrote:
On 26. 10. 21 13:53, Adrian Reber wrote:
All packages have been rebuild and the side tag has been merged. I was
not able to rebuild the
In one week (Nov. 2), or slightly later, I will merge [1] and build
python-pytest-bdd 5.0.0 in Rawhide.
There are minor API changes that require changes to some tests that use
it; see [2].
This notice is a formality, since I maintain the only dependent
package[3] and I already applied the
With the upcoming update to version 20211012
(https://src.fedoraproject.org/rpms/python-pdfminer/pull-request/5), the
python-pdfminer License field gains yet another term due to some new
SASL code based on pyHanko and ultimately derived from python-pymongo
(mongo-python-driver).
Instead of
The License field of the python-fastavro package has been corrected from
“ASL 2.0” to “MIT and ASL 2.0”.
The primary upstream license is MIT
(https://github.com/fastavro/fastavro/blob/1.4.6/LICENSE), but the
project is derived from Apache Avro, which is under the ASL 2.0 license
The License field for python-trimesh has been corrected from “MIT” to
“MIT and BSD and zlib”.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
I just built python-shapely 1.8~rc2 for Rawhide/F36, which fixes
compatibility with geos 3.10.0.
This should be a compatible update from 1.7.x, and I used a COPR to
confirm that there are no new problems in its dependent packages as a
result of the update.
On 10/21/21 11:33, Sandro Mani
I looked at a few of the failures.
> 4. opencv
> 6. gazebo
> 7. fawkes
The root cause is of course a bad python-flake8 update, as described here:
https://bugzilla.redhat.com/show_bug.cgi?id=2014589
A lot of other packages are affected as well. The python-flake8 package
should
The section you linked says “See the following section to learn about
%py_provides.”
That following section,
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Automatic-unversioned-provides,
describes when and how to use %py_provides. It explains how the vast
majority of
I claimed libfakekey. I’ll modernize the spec file a bit and update it
to 0.3 from https://git.yoctoproject.org/cgit/cgit.cgi/libfakekey/.
On 10/4/21 18:20, Peter Robinson wrote:
Looking through the packages I own there's a bunch I no longer use.
I've tried to group these, from memory, where I
In one week (October 6), or slightly later, I will build grpc 1.41.0 for
Rawhide (F36). Fedora 35 will remain on 1.39.1.
As is traditional for minor releases of grpc, the C++ ABI was broken
(soversion bumped from 1.40 to 1.41). This time, the C (core) ABI was
also broken (soversion bumped
It was maimed by the 10-bug default limit in the recent Bugzilla upgrade. It
looks like people are working on it:
https://pagure.io/fedora-infra/review_stats/pull-request/13
https://pagure.io/fedora-infra/review_stats/pull-request/14
On Fri, Sep 17, 2021, at 6:12 PM, Jerry James wrote:
> What
is automatically filed whenever there is a new upstream
release.
Please let me know if I can provide any help or advice. I’ve been an
inotify-tools user for many years, and I appreciate your contributions.
- Ben Beasley (FAS music)
On 9/17/21 10:51, Ankur Sinha wrote:
On Fri, Sep 17, 2021 15:28:59 +0100
I have checked the remaining packages (cctz, geometry-hpp, python-pypet,
seqan3, and snappy). Based on source grepping and on a successful
“fedpkg mockbuild --enablerepo=local”, none of them uses the part of the
API that was changed.
On 9/15/21 08:24, Vitaly Zaitsev via devel wrote:
Hello.
201 - 300 of 326 matches
Mail list logo
