Hello, everyone—my name is Ben Beasley. I’m an electrical engineer in
the USA with training and experience in communications systems and
digital signal processing. I’ve been writing domain-specific and
general-purpose software in many languages (Python, C, C++,
JavaScript/ECMAScript, bash/sh
uildrequires -r or “better”) would catch most such issues at build
time. I did this in pipx for exactly that reason.
– Ben Beasley
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
In one week, I will update python-sure to 2.0.0 in Rawhide
(https://bugzilla.redhat.com/show_bug.cgi?id=1974521). This includes the
following breaking API change:
> No longer patch the builtin `dir()` function, which fixes pytest in
some cases such as projects using gevent.
I do not think
In one week, I will update python-starlette to 0.15.0 in Rawhide
(https://bugzilla.redhat.com/show_bug.cgi?id=1975613). This includes
some minor API changes; please see the release notes at
https://github.com/encode/starlette/releases/tag/0.15.0.
The following packages depend on this package,
In one week, or slightly later, I will update python-pyrsistent to
0.18.0 in Rawhide (https://bugzilla.redhat.com/show_bug.cgi?id=1977038).
This includes one minor API change; please see the release notes at
it is and isn’t
reasonable to expect packagers to derive effective licenses. Suffice it
to say that, in these specific simple cases, I think the changes are
clearly consistent with the community consensus, such as it is, and with
guidance from fedora-legal.
Regards,
Ben Beasley
On 7/9/21 10
Relevant history:
https://bugzilla.redhat.com/show_bug.cgi?id=1953340
https://github.com/grosjo/fts-xapian/issues/82
In short, a package was submitted and approved, but the submitter (who
is also the upstream author) is discouraged by the need to seek
sponsorship into the packager group.
, and building with upstream’s
default C++ standard version should generally be the right thing to do.
On 8/23/21 11:35 AM, Ian McInerney via devel wrote:
On Mon, Aug 23, 2021 at 4:13 PM Ben Beasley <mailto:c...@musicinmybrain.net>> wrote:
The same specialization of ProcessorCache:
The same specialization of ProcessorCache:
template class ProcessorCache;
is explicitly instantiated in two different translation units:
src/OpenColorIO/Processor.cpp
src/OpenColorIO/Config.cpp
which violates the C++ standard (an explicit instantiation definition
shall appear at most
!
- Ben
On 8/30/21 6:22 AM, Chandan Kumar wrote:
Hello Ben,
On Sat, Aug 21, 2021 at 12:36 AM Ben Beasley wrote:
Unless someone convinces me of another plan, I intend to retire
python-typer and python-typer-cli in F35 and Rawhide in one week
(2021-08-27).
I myself introduced these two packages
Unless someone convinces me of another plan, I intend to retire
python-typer and python-typer-cli in F35 and Rawhide in one week
(2021-08-27).
I myself introduced these two packages to Fedora quite recently
(https://bugzilla.redhat.com/show_bug.cgi?id=1964742,
It looks like the project changed version schemes at some point. The 4.02.3
release was in 2015, before 0.9.0; a long list of 4.x and 3.x releases preceded
it.
I don’t see where it got 0.10.0 as the currently-packaged version; the actual
bug
=608029
https://github.com/OpenKinect/libfreenect2/issues/157
https://bugs.launchpad.net/ubuntu/+source/freecad/+bug/503188
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683021
On 8/23/21 1:11 PM, Richard Shaw wrote:
On Mon, Aug 23, 2021 at 10:13 AM Ben Beasley <mailto:c...@musicinmybrain.
The errors are not the same across releases.
The complete error on F34 is:
~~~
Error:
Problem: package OpenColorIO-devel-2.0.1-1.fc34.x86_64 requires
libOpenColorIO.so.2.0()(64bit), but none of the providers can be installed
- package OpenColorIO-devel-2.0.1-1.fc34.x86_64 requires
In one week (September 16), or slightly later, I will build grpc 1.40.0
for Rawhide (F36).
As is traditional for minor releases of grpc, the C++ ABI was broken
(soversion bumped from 1.39 to 1.40). This time, the C (core) ABI
remained stable (soversion 18).
I will coordinate builds of
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.
The update was unpushed on everything but Rawhide.
Many (but not quite all) of these packages will use gtest-devel only to
build test executables and have no runtime/install-time dependency on
it. In my opinion, those can probably get by without rebuilding if desired.
- Ben Beasley
On 9/6
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
?id=1968167 for details.
– Ben Beasley
On 8/5/21 1:01 PM, Richard Shaw wrote:
Current status:
aqsis - Move to openexr2
bcd - Moved to openexr2
blender - seems to be failing for Python related issue
calligra - Moved to openexr2, FTBFS for FontConfig reasons
CTL - Moved to openexr2
darktable -done
In general, if you want to rebuild an rpmautospec package with no spec file
changes, you can do an empty git commit like this:
git commit —allow-empty -m 'Rebuild for foolib 3.14'
Then “fedpkg build” as usual.
The case of usd is not quite so simple. I tried to rebuild it as a
co-maintainer
In one week (2021-08-03), I will merge
https://src.fedoraproject.org/rpms/grpc/pull-request/5 (which will build
on all architectures by then) and build it into a side tag. This will
bring grpc 1.39.0 to Rawhide, bumping the C so-version to 18 and the C++
so-version to 1.39, prior to F35
I think becoming a packager is not as complicated as you’ve written. To
become a packager, you must convince a packager sponsor to sponsor you.
That’s all; there is no rule about how to do the convincing.
Sponsors want to be confident that you understand and are likely to
follow the packaging
I managed to build usd in Rawhide
(https://koji.fedoraproject.org/koji/buildinfo?buildID=1817418). Expect
a build for F35, and updates to the relevant bug reports, in the next
couple of hours.
– Ben
On 8/11/21 3:40 PM, Ben Beasley wrote:
Your build did end up failing due to the glibc 2.34
Your build did end up failing due to the glibc 2.34 incompatibility
(https://koji.fedoraproject.org/koji/taskinfo?taskID=73678362).
See https://github.com/PixarAnimationStudios/USD/issues/1592 for details
on what’s happening. It’s likely that a significant patch to USD will be
required to fix
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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:
<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
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
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
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:
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
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.
___
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
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
/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
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
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
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
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
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
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
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 get python-xds-protos
(https://bugzilla.redhat.com/show_bug.cgi?id=1980041) reviewed so I can
update grpc to version 1.39.0 in Rawhide in time for Fedora 35.
This is a new dependency for grpc—a weirdly circular one that’s
ultimately generated from sources inside grpc, but is
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]
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
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 (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
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
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
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
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,
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]
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 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
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
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 --
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
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]
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
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’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
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
>
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
, 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
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
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
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
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 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`
-
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
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
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
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.
1 - 100 of 326 matches
Mail list logo
