ecl soname bump and license change
Version 24.5.10 of the ecl package has been released, and includes an soname bump. I intend to build it and rebuild its sole Fedora consumer, maxima, in a week, for Rawhide only. In addition, this release changes the base license of the package from LGPL-2.0-or-later to LGPL-2.1-or-later. -- Jerry James http://www.jamezone.org/ -- ___ 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: OCaml flambda optimizations causing a compilation slow down
On Fri, May 3, 2024 at 11:18 AM Richard W.M. Jones wrote: > I tested the tip of the 5.1 branch upstream and that still had the > issue. I didn't test 5.2. Here's a build with OCaml 5.2.0rc1: https://copr.fedorainfracloud.org/coprs/jjames/OCaml5.2/build/7416844/ As you can see, the build times are still terrible. I tried switching from menhir's default code backend to its table backend, and compilation of the emitted file was so fast it was below the level of (my) perception. The tradeoff between the code and table backends is described in Section 1, Foreword, here: http://cambium.inria.fr/~fpottier/menhir/manual.html I don't know what percentage of the total runtime coccinelle spends in the parser, but if it is a small percentage, then maybe the small slowdown from using the table backend is worth the massive decrease in build time. -- Jerry James http://www.jamezone.org/ -- ___ 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: OCaml flambda optimizations causing a compilation slow down
On Fri, May 3, 2024 at 6:22 AM Richard W.M. Jones wrote: > In Fedora we enable flambda in our OCaml package. Debian does not. As the person who pushed to get flambda enabled in Fedora, I feel kind of responsible for this. > We recently found that one package (coccinelle) takes much, much > longer to compile when this is enabled. As in one particular file > goes from seconds -> 30 minutes to compile. I investigated and the > difference is entirely explained by enabling flambda, and goes away > when disabled. Apart from this being annoying, it doesn't seem to be > a problem in any other way (for example, the final program doesn't > noticable run faster or slower). Upstream coccinelle seem to be using > Debian and therefore haven't seen the problem. > > Thread about all that: > https://lore.kernel.org/cocci/20240502085433.ga30...@redhat.com/ > > This email is mostly to notify that this is happening. I'm not sure > if a single package slowing down compilation means we need to do > anything here, but if anyone else sees similar symptoms, let us know. Wow, that's an amazing blow up in compile time. I note that the file in question is generated by menhir. I remember seeing reports that some menhir features generate code that cause compile times to explode. I can't seem to find a usable link to the menhir mailing list archives at the moment. I can experiment with the different code generation options from menhir and see if anything helps. Also, I was going to contact you about this today, but OCaml 5.2.0RC1 was tagged yesterday. I started doing test builds here: https://copr.fedorainfracloud.org/coprs/jjames/OCaml5.2/ I need to build a few more packages before coccinelle can be attempted, but it will be interesting to see if the build time improves. -- Jerry James http://www.jamezone.org/ -- ___ 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
python-networkx 3.3 + review swaps
Version 3.3 of NetworkX was released a few weeks ago. It needs pydot >= 2.0.0. I have opened https://src.fedoraproject.org/rpms/pydot/pull-request/4. Also, if we are going to continue generating documentation for python-networkx [1], then I need some package reviews. I am willing to swap reviews for these: - python-jupytext: https://bugzilla.redhat.com/show_bug.cgi?id=2278420 - python-jupyter-server-mathjax: https://bugzilla.redhat.com/show_bug.cgi?id=2278421 - python-nbdime: https://bugzilla.redhat.com/show_bug.cgi?id=2278422 - python-jupyter-cache: https://bugzilla.redhat.com/show_bug.cgi?id=2278423 - python-myst-nb: https://bugzilla.redhat.com/show_bug.cgi?id=2278424 Builds for all of these packages, plus pydot and python-networkx, are available from https://copr.fedorainfracloud.org/coprs/jjames/Jupyter/. Footnotes: [1] And I want to, if for no other reason than that the doctests have turned up problems in the past. I feel much better about doing a python-networkx upgrade if the doctests all pass. -- Jerry James http://www.jamezone.org/ -- ___ 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: PHP without 32-bit
On Wed, Apr 24, 2024 at 12:27 AM Remi Collet wrote: > - flamegraph waiting for PR #1 I merged this and it is building now. -- Jerry James http://www.jamezone.org/ -- ___ 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
[rpms/perl-Task-Catalyst] PR #1: Stop building for 32-bit x86
jjames commented on the pull-request: `Stop building for 32-bit x86` that you
are following:
``
I have updated the PR to include the comment above the License tag.
The php stack is [dropping its i386
builds](https://fedoraproject.org/wiki/Changes/php_no_32_bit). The flamegraph
package consumes php. There is a [pull
request](https://src.fedoraproject.org/rpms/flamegraph/pull-request/1) to stop
building the php bits on i386. I looked at the number of packages sitting on
top of flamegraph. Only 4 of them do not already exclude i386 builds. My
preference is to stop building flamegraph on i386 altogether, rather than
single out the php parts. Since flamegraph is not currently a leaf package for
i386, I need to sweet talk the maintainers of those 4 packages into dropping
i386 support.
My understanding is that noarch packages show up in the i386 repository unless
an ExcludeArch or ExclusiveArch tag prevents that. This is why all Java
packages in Fedora now have something like this:
```
BuildArch: noarch
ExclusiveArch: %{java_arches} noarch
```
I will happily accept correction if I have misunderstood the situation.
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Task-Catalyst/pull-request/1
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Task-Catalyst] PR #1: Stop building for 32-bit x86
jjames opened a new pull-request against the project: `perl-Task-Catalyst` that you are following: `` Stop building for 32-bit x86 `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Task-Catalyst/pull-request/1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: "fedpkg local" builds fail for rust packages
On Fri, Apr 5, 2024 at 7:35 AM Fabio Valentini wrote: > On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber > wrote: > > Is there any other set of packages which we package like that? > > Probably golang ... maybe Haskell, OCaml? Not OCaml, no. The OCaml packages can be installed and used for software development. -- Jerry James http://www.jamezone.org/ -- ___ 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: Reminder: F40 final freeze starts next week (2024-04-02)
On Tue, Apr 2, 2024 at 10:08 AM Sandro wrote: > We are one week down the road. I've submitted an update a week ago > shortly after Adam's reply was sent (March 26, 21:48 UTC). Final freeze > is now in effect and the update[1] has *not* made it to stable. It's > still in testing. > > Luckily, this update can wait until after freeze. I'm glad I decided to > ask for karma for another update submitted earlier the same day. > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-3ebd1e2c45 I've had this bite me in previous years. If you submit an update on Tuesday, then it will be pushed to testing Tuesday night. One week later, on Tuesday night again, it will be submitted for stable, and 24 hours later it will actually go stable. It takes 8 days to get an update from submission to stable, not 7, so when there are only 7 days between Beta release and Final Freeze, you're already too late when the Beta release happens. I personally wish we would keep the "3 days to stable" rule all the way up to Final Freeze. Switching to the 7 day time period right before that always slows me down just when I'm trying to hurry and fix things for the final freeze. Also: - We don't switch from 3 to 7 days at Beta Release, but rather when the Beta Release is announced, which is typically 4 to 5 days prior to the Beta Release. - We retroactively change the time to stable of all updates that have already been submitted. I might have an update that I think will go stable in 1 more day, and suddenly it isn't going to go stable for 5 more days. All of that combined means extra delays just when time is short. -- Jerry James http://www.jamezone.org/ -- ___ 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: xz backdoor
On Fri, Mar 29, 2024 at 12:08 PM Richard W.M. Jones wrote: > On Fri, Mar 29, 2024 at 07:00:37PM +0100, Kevin Kofler via devel wrote: > > Hi, > > > > wow: https://www.openwall.com/lists/oss-security/2024/ > > > > I think at this point we clearly cannot trust xz upstream anymore and should > > probably fork the project. > > I kind of agree here, though it saddens me to say it. Any commit or > release by "Jia Tan" or "Hans Jansen" [1] is suspect until proven > otherwise, and those go back 2 or more years. > > Rich. > > [1] Putting quotes here because those are almost certainly not real > peoples' names. That github user has also committed to libarchive, although not since November 2021. -- Jerry James http://www.jamezone.org/ -- ___ 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
Review swap: 2 GAP packages
With the arrival of GAP 4.13.0 in Rawhide, I find myself in need of 2 more GAP packages (which do some work in C rather than in the GAP language, for speed): - gap-pkg-anupq: https://bugzilla.redhat.com/show_bug.cgi?id=2270581 - gap-pkg-fplsa: https://bugzilla.redhat.com/show_bug.cgi?id=2270856 I am happy to swap reviews. Let me know what I can review for you. -- Jerry James http://www.jamezone.org/ -- ___ 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: ld: error: triggering the generation of an executable stack
On Tue, Mar 19, 2024 at 6:28 PM Orion Poplawski wrote: > With a recent update, plplot is failing to build with: > > cd > /builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/examples/fortran > && /usr/bin/cmake -E cmake_link_script CMakeFiles/x16af.dir/link.txt > --verbose=1 > /usr/bin/gfortran -Wl,-z,relro -Wl,--as-needed > -Wl,-z,pack-relative-relocs -Wl,-z,now > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -O2 > -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe > -Wall -Wno-complain-wrong-lang -Werror=format-security > -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 > -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection > -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer > -mno-omit-leaf-frame-pointer -frecursive > CMakeFiles/x16af.dir/x16af.f90.o -o x16af > -Wl,-rpath,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/bindings/fortran:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime > ../libplfortrandemolib.a > ../../bindings/fortran/libplplotfortran.so.0.2.0 > -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime > /usr/bin/ld: error: /tmp/cchkMGCX.ltrans0.ltrans.o: is triggering the > generation of an executable stack (because it has an executable > .note.GNU-stack section) > /usr/bin/ld: failed to set dynamic section sizes: No such file or directory > > I have no idea what is up here. > > Seems to have started with: > > gcc 14.0.1-0.7.fc41 > glibc 2.39.9000-3.fc41 > util-linux 2.40-0.9.rc1.fc41 > binutils 2.42.50-4.fc41 > > and lots of others, but that seems the most likely. At least one of the Fortran example programs (x09f) really does require an executable stack. This PR will work around the build issue for now, but the reason why it requires an executable stack should be investigated: https://src.fedoraproject.org/rpms/plplot/pull-request/6 -- Jerry James http://www.jamezone.org/ -- ___ 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
coin-or-HiGHS soname bump
Version 1.7.0 of coin-or-HiGHS has been released and comes with an soname bump. In a week, I will update it and rebuild its two consumers: coin-or-Cbc and mp. -- Jerry James http://www.jamezone.org/ -- ___ 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: perl segfault in F40
On Mon, Mar 11, 2024 at 8:38 AM Fabio Valentini wrote: > Yes, but the soname did not change. So it looks like this ABI change (if it > is an ABI change? it looks like it) was not intentional. Actually, it appears that we shot ourselves in the foot: https://github.com/pkgconf/pkgconf/issues/347 -- Jerry James http://www.jamezone.org/ -- ___ 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: perl segfault in F40
On Mon, Mar 11, 2024 at 8:12 AM Fabio Valentini wrote: > Does this mean that pkgconf had an undetected ABI change? And that possibly > more things would need to be rebuilt and / or pkgconf be fixed / bump its > soname? Argh, dang time change. I meant to remark on that and obviously forgot. Yes, libpkgconf 2.1.0 is not ABI compatible with libpgkconf 1.9.5, but the soname was not bumped. Besides pkgconf itself and perl-PkgConfig-LibPkgConf, the build2 and perl-Alien-pkgconf packages may also need rebuilds. -- Jerry James http://www.jamezone.org/ -- ___ 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: perl segfault in F40
run.c:41
#6 0x77c47899 in S_run_body (oldscope=,
my_perl=)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perl.c:2807
#7 perl_run (my_perl=0x92a0) at
/usr/src/debug/perl-5.38.2-506.fc40.x86_64/perl.c:2727
#8 0x5342 in main (argc=, argv=, env=)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perlmain.c:127
This declaration is at the top of LibPkgConf.xs:
struct my_client_t {
pkgconf_client_t client;
FILE *auditf;
int maxdepth;
SV *error_handler;
};
So an operation on the client field is being done, but the following
field is affected. Starting over with a breakpoint on
pkgconf_cache_add shows that this is happening on the very first call
to that function. It happens when client->cache_count is incremented
on line 135, just before the realloc:
++client->cache_count;
client->cache_table = pkgconf_reallocarray(client->cache_table,
client->cache_count, sizeof (void *));
which can only mean that different compilation units have seen
different definitions of the pkgconf_client_t type. And here we
notice that the latest build of pkgconf is version 2.1.0 from 12
February 2024, and the latest build of perl-PkgConfig-LibPkgConf is
perl-PkgConfig-LibPkgConf-0.11-18.fc40 from 29 February 2024 ... but
it hasn't gone stable yet. The version you are getting in F40 mock is
perl-PkgConfig-LibPkgConf-0.11-17.fc40 from 25 January 2024, built
against pkgconf 1.9.5, which had a different definition of
pkgconf_client_t.
Your choices are to wait for the F40 beta freeze to end, or lobby for
a freeze exception for the perl-PkgConfig-LibPkgConf update.
Regards,
--
Jerry James
http://www.jamezone.org/
--
___
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
z3 soname bump
In about a week, I will update the z3 package to version 4.13, which bumps the soname for the z3 library. No packages in Fedora consume z3-libs, other than some built from the z3 source RPM, so no other builds are necessary. -- Jerry James http://www.jamezone.org/ -- ___ 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
soplex and scip soname bumps
Next week I plan to update soplex to version 7.0.0 and scip to version 9.0.0. Both updates come with an soname bump. The following packages will be rebuilt: - coin-or-Couenne - coin-or-lemon - coin-or-OS - gfan - mp - polymake - TOPCOM Since that list overlaps with the list of packages that must be rebuilt for the flint 3.x update I announced yesterday, I am considering doing all of the builds in the same side tag so polymake, for example, only needs to be built once. -- Jerry James http://www.jamezone.org/ -- ___ 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
flint 3.x, soname bumps
Next week, I plan to update flint to version 3.1.0. The 3.x series has some backwards incompatible changes, but nearly all consuming upstreams have already adapted. The formerly independent antic and arb packages have been absorbed into flint, so those 2 packages will be retired after the builds are done. The following packages will bump sonames: - flint: from libflint.so.17 to libflint.so.19 - e-antic: from libeantic.so.1 to libeantic.so.3 This is the list of packages to be rebuilt (in approximately this order): - flint, updated to version 3.1.0 - ccluster - e-antic, updated to version 2.0.2 - eclib, updated to version 20231212 - msolve - pplite - apron - normaliz, updated to version 3.10.2 - Singular, updated to version 4.3.2p15 - polymake Test builds are ongoing in this COPR: https://copr.fedorainfracloud.org/coprs/jjames/FLINT3/ -- Jerry James http://www.jamezone.org/ -- ___ 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: SoPlex and SCIP builds
On Sat, Feb 24, 2024 at 7:21 PM Jerry James wrote: > The Rawhide side tag is being merged into Rawhide now. The F40 builds > have hit an unfortunate snag and have not progressed far. If anybody > from releng is reading this, I need > https://pagure.io/releng/issue/11977 processed before I can make > further progress. I appreciate any help. The F40 builds are done and the side tag has been merged. The affected packages can now be built directly for Rawhide and F40. Thanks again to everyone who helped. -- Jerry James http://www.jamezone.org/ -- ___ 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: SoPlex and SCIP builds
On Thu, Feb 22, 2024 at 10:00 AM Jerry James wrote: > Thanks to Benson Muite and Kai Hiller, the final package reviews > needed for the SoPlex and SCIP effort are done. The packages will be > built in these side tags: > > f41-build-side-84341 > f40-build-side-84343 > > There are several packages that take multiple hours to build, and must > be built serially due to dependencies between them, so the builds will > probably take 2-3 days. If you need to build any of the following > packages in the next 2-3 days, please coordinate with me. The > maintainers are BCCed on this message. > > - bliss > - coin-or-Alps > - coin-or-Bcp > - coin-or-Bcps > - coin-or-Blis > - coin-or-Bonmin > - coin-or-Cbc > - coin-or-Cgl > - coin-or-Clp > - coin-or-CoinMP > - coin-or-CoinUtils > - coin-or-Couenne > - coin-or-Dip > - coin-or-DyLP > - coin-or-FlopC++ > - coin-or-Ipopt > - coin-or-lemon > - coin-or-OS > - coin-or-Osi > - coin-or-SYMPHONY > - freefem++ > - gfan > - Macaulay2 > - mp > - opencv > - openms > - polymake > - python-cyipopt > - python-jupymake > - python-pysingular > - Singular > - TOPCOM > > I will reply to this message when the side tags are ready to merge. A > big thank you to everyone who helped along the way. The Rawhide side tag is being merged into Rawhide now. The F40 builds have hit an unfortunate snag and have not progressed far. If anybody from releng is reading this, I need https://pagure.io/releng/issue/11977 processed before I can make further progress. I appreciate any help. -- Jerry James http://www.jamezone.org/ -- ___ 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: pygsl tests fail on s390x
On Fri, Feb 23, 2024 at 3:53 PM Jerry James wrote: > I'll open a PR upstream for this issue. https://github.com/pygsl/pygsl/pull/49 -- Jerry James http://www.jamezone.org/ -- ___ 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: pygsl tests fail on s390x
On Fri, Feb 23, 2024 at 11:22 AM José Abílio Matos wrote: > https://koji.fedoraproject.org/koji/taskinfo?taskID=113947607 > > > Most of the errors are like this > > E numpy.core._exceptions._ArrayMemoryError: Unable to allocate 320. GiB > for an array with shape (42949672961,) and data type float64 > > > I am surprised with the fact that the s390x builders do not have at least 320 > GiB of RAM, they are clearly under-powered. ;-) > > > On a more serious, and boring, note does this warning rings a bell to anyone > who had a similar problem? Yes, many times. :-) This kind of thing happens when a pointer to a 64-bit integer gets passed to something that expects a pointer to a 32-bit integer. In this case, src/rng/rng_helpers.c has a number of variables named "dimension" that have type PyGSL_array_index_t. That type has the same size as a pointer; i.e., it is a 32-bit integer on 32-bit systems and a 64-bit integer on 64-bit systems. At various places in rng_helpers.c, a dimension variable is initialized to 1, then PyArg_ParseTuple is called to parse an integer into it. The type code "i" is given. Python thinks that means we passed it a pointer to a 32-bit integer. On little endian systems, that's okay as long as the integer to be parsed fits into a 32-bit integer; we overwrite the 1. On big endian systems, however, we write the parsed 32-bit integer into the most significant 32 bits of the 64 bit integer, leaving the 1 in the least significant bits. This leaves the dimension variable holding a value like 42949672961 == 0xa0001, when it should have held the value 10. The fix is to pass "l" into PyArg_ParseTuple instead of "i". I have added a patch for this to https://src.fedoraproject.org/rpms/pygsl/pull-request/2, which (gentle prod here) has now been open for 6 months. If you don't want all of it, we can eject unwanted commits from the PR. I'll open a PR upstream for this issue. Regards, -- Jerry James http://www.jamezone.org/ -- ___ 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
SoPlex and SCIP builds
Thanks to Benson Muite and Kai Hiller, the final package reviews needed for the SoPlex and SCIP effort are done. The packages will be built in these side tags: f41-build-side-84341 f40-build-side-84343 There are several packages that take multiple hours to build, and must be built serially due to dependencies between them, so the builds will probably take 2-3 days. If you need to build any of the following packages in the next 2-3 days, please coordinate with me. The maintainers are BCCed on this message. - bliss - coin-or-Alps - coin-or-Bcp - coin-or-Bcps - coin-or-Blis - coin-or-Bonmin - coin-or-Cbc - coin-or-Cgl - coin-or-Clp - coin-or-CoinMP - coin-or-CoinUtils - coin-or-Couenne - coin-or-Dip - coin-or-DyLP - coin-or-FlopC++ - coin-or-Ipopt - coin-or-lemon - coin-or-OS - coin-or-Osi - coin-or-SYMPHONY - freefem++ - gfan - Macaulay2 - mp - opencv - openms - polymake - python-cyipopt - python-jupymake - python-pysingular - Singular - TOPCOM I will reply to this message when the side tags are ready to merge. A big thank you to everyone who helped along the way. -- Jerry James http://www.jamezone.org/ -- ___ 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: SoPlex and SCIP review swaps
On Tue, Feb 20, 2024 at 10:05 AM Benson Muite wrote: > Will get mine done tomorrow. I'd just like to give a shout out to Benson, who has done the lion's share of the reviews for this effort. Thank you, Benson! You have been an enormous help. -- Jerry James http://www.jamezone.org/ -- ___ 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: SoPlex and SCIP review swaps
On Tue, Feb 20, 2024 at 9:09 AM Kai A. Hiller wrote: > I’ll take care of scip. I’d be glad if you could take a look at one or > more of these (not urgent, though): > > golang-gopkg-macaroon2: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2250314 > golang-github-matrix-org-util: > https://bugzilla.redhat.com/show_bug.cgi?id=2250311 > golang-github-matrix-org-gomatrix: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2250312 Will do. Thank you, Kai! -- Jerry James http://www.jamezone.org/ -- ___ 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: SoPlex and SCIP review swaps
On Fri, Feb 16, 2024 at 2:22 PM Jerry James wrote: > On Mon, Feb 12, 2024 at 11:11 AM Jerry James wrote: > > On Wed, Dec 6, 2023 at 3:10 PM Jerry James wrote: > > > I need reviews for the following new packages. I am willing to swap > > > reviews. > > > - asl: https://bugzilla.redhat.com/show_bug.cgi?id=2253354 > > > - ccluster: https://bugzilla.redhat.com/show_bug.cgi?id=2253355 > > > - lusol: https://bugzilla.redhat.com/show_bug.cgi?id=2253356 > > > - pdqsort: https://bugzilla.redhat.com/show_bug.cgi?id=2253357 > > > - zimpl: https://bugzilla.redhat.com/show_bug.cgi?id=2253358 > > > - zstr: https://bugzilla.redhat.com/show_bug.cgi?id=2253359 > > > - papilo: https://bugzilla.redhat.com/show_bug.cgi?id=2253360 > > > - soplex: https://bugzilla.redhat.com/show_bug.cgi?id=2253361 > > > - scip: https://bugzilla.redhat.com/show_bug.cgi?id=2253362 > > > - coin-or-HiGHS: https://bugzilla.redhat.com/show_bug.cgi?id=2253363 > > > - spasm: https://bugzilla.redhat.com/show_bug.cgi?id=2253364 > > > > Just a few package reviews to go! This is what remains to be done: > > > > - papilo: https://bugzilla.redhat.com/show_bug.cgi?id=2253360 > > - soplex: https://bugzilla.redhat.com/show_bug.cgi?id=2253361 > > - scip: https://bugzilla.redhat.com/show_bug.cgi?id=2253362 > > - coin-or-HiGHS: https://bugzilla.redhat.com/show_bug.cgi?id=2253363 > > > > These will need to be reviewed with respect to the [COPR mentioned > > above](https://copr.fedorainfracloud.org/coprs/jjames/SCIP/), since I > > can't build asl in Rawhide without breaking the existing mp package, > > so the rest all has to be done at once in a side tag. > > > > Let me know what I can review for you in exchange for the above reviews. > > Thanks to Benson Muite, papilo has been reviewed and soplex is under > review. I still need reviewers for scip and coin-or-HiGHS. If you > don't have a package that needs review right now, I can give you a > rain check, or I can do some other task for you. I still need a reviewer for scip. If we can get the last couple of reviews finished by tomorrow, I will still have time to get this all built before F40 beta freeze. Please help. -- Jerry James http://www.jamezone.org/ -- ___ 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: Question about error: inlining failed in call to ‘always_inline’
c/generic/stage2/tape_builder.h:105:39: > note: called from here >105 | return iter.walk_document(builder); >| ~^ > make[2]: *** [CMakeFiles/simdjson.dir/build.make:79: > CMakeFiles/simdjson.dir/src/simdjson.cpp.o] Error 1 > make[2]: Target 'CMakeFiles/simdjson.dir/build' not remade because of > errors. > > I really have no idea how to resolve this. Someone who understands more will have to answer why this happens, but a workaround is to change "simdjson_inline" to plain "inline" on line 119 of src/generic/stage2/json_iterator.h. -- Jerry James http://www.jamezone.org/ -- ___ 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: SoPlex and SCIP review swaps
On Mon, Feb 12, 2024 at 11:11 AM Jerry James wrote: > On Wed, Dec 6, 2023 at 3:10 PM Jerry James wrote: > > I need reviews for the following new packages. I am willing to swap > > reviews. > > - asl: https://bugzilla.redhat.com/show_bug.cgi?id=2253354 > > - ccluster: https://bugzilla.redhat.com/show_bug.cgi?id=2253355 > > - lusol: https://bugzilla.redhat.com/show_bug.cgi?id=2253356 > > - pdqsort: https://bugzilla.redhat.com/show_bug.cgi?id=2253357 > > - zimpl: https://bugzilla.redhat.com/show_bug.cgi?id=2253358 > > - zstr: https://bugzilla.redhat.com/show_bug.cgi?id=2253359 > > - papilo: https://bugzilla.redhat.com/show_bug.cgi?id=2253360 > > - soplex: https://bugzilla.redhat.com/show_bug.cgi?id=2253361 > > - scip: https://bugzilla.redhat.com/show_bug.cgi?id=2253362 > > - coin-or-HiGHS: https://bugzilla.redhat.com/show_bug.cgi?id=2253363 > > - spasm: https://bugzilla.redhat.com/show_bug.cgi?id=2253364 > > Just a few package reviews to go! This is what remains to be done: > > - papilo: https://bugzilla.redhat.com/show_bug.cgi?id=2253360 > - soplex: https://bugzilla.redhat.com/show_bug.cgi?id=2253361 > - scip: https://bugzilla.redhat.com/show_bug.cgi?id=2253362 > - coin-or-HiGHS: https://bugzilla.redhat.com/show_bug.cgi?id=2253363 > > These will need to be reviewed with respect to the [COPR mentioned > above](https://copr.fedorainfracloud.org/coprs/jjames/SCIP/), since I > can't build asl in Rawhide without breaking the existing mp package, > so the rest all has to be done at once in a side tag. > > Let me know what I can review for you in exchange for the above reviews. Thanks to Benson Muite, papilo has been reviewed and soplex is under review. I still need reviewers for scip and coin-or-HiGHS. If you don't have a package that needs review right now, I can give you a rain check, or I can do some other task for you. -- Jerry James http://www.jamezone.org/ -- ___ 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: Restore dmz-cursor-themes
Hi Fabrice, On Fri, Feb 16, 2024 at 4:43 AM Fabrice wrote: > Hi! > > I would like to become the maintainer of dmz-cursor-themes. > https://src.fedoraproject.org/rpms/dmz-cursor-themes > > I would like to push an update from Debian, v0.4.5.1. Thank you for your interest in this package. Since it has been retired for more than 8 weeks, it will need to be reviewed as described here: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming Are you currently a Fedora packager? If not, you will need to follow the procedure described here: https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ Feel free to ask questions or ask for help on this mailing list or on https://discussion.fedoraproject.org/. Regards, -- Jerry James http://www.jamezone.org/ -- ___ 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: CMake errors
On Tue, Feb 13, 2024 at 2:39 PM Josef Řídký wrote:
> Hi,
>
> I am trying to build a new version of the jasper package, but I am not able
> to successfully pass the %cmake command. [1]
>
> First issue was about using in-source build, which can be overridden by
> -ALLOW_IN_SOURCE_BUILD. But even though, CMake has problem with finding
> CMAKE_C_COMPILER location.
>
> Currently is used CMAKE_VERSION: 3.28.2
>
> Previous successful build of jasper [2] used CMAKE_VERSION: 3.27.7 and no
> in-source error nor CMAKE_C_COMPILER issue has occurred.
>
> Does anyone have a similar issue? What is a recommended way to deal with this?
>
> [1] https://kojipkgs.fedoraproject.org//work/tasks/9648/113459648/build.log
> [2]
> https://kojipkgs.fedoraproject.org//packages/jasper/4.1.0/3.fc40/data/logs/x86_64/build.log
>
> Best regards
>
> Josef
This works:
%build
%cmake \
-DALLOW_IN_SOURCE_BUILD:BOOL=ON \
-DJAS_ENABLE_DOC:BOOL=OFF
%cmake_build
%install
%cmake_install
# Unpackaged files
rm -f doc/README
rm -f %{buildroot}%{_libdir}/lib*.la
%check
%ctest
Regards,
--
Jerry James
http://www.jamezone.org/
--
___
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: do we need CONFIG_UPROBES=y in our kernels?
On Mon, Feb 12, 2024 at 11:16 AM Marius Schwarz wrote: > In a german developer blog article was the topic raised, that with > uprobes enabled, userland apps can i.e. circumvent tls security(and > other protections), > by telling the kernel to probe the function calls with the uprobes api. > As this enables i.e. the hosting system of a vm or container, to track > activity inside the container, trust is lost i.e. from customer to > hoster. To be fair, you need to be root on the host to do this, but as > it "wasn't possible before", and it is "now" ( out in a greater public > ), it tends to create trust issues, just for being there*. > > As this only works with uprobes enabled and has no use case besides a > developer debugging apps, the question is: > > Do we need this for all others out there enabled by default? Both systemtap and bpftrace can use uprobes. Those capabilities have been important from time to time in my job. That does not mean that my ability to do my job should outweigh security concerns, of course, but I think some effort should be made to find out if use of uprobes via systemtap and bpftrace is common amongst Fedora users. -- Jerry James http://www.jamezone.org/ -- ___ 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: SoPlex and SCIP review swaps
On Wed, Dec 6, 2023 at 3:10 PM Jerry James wrote: > I need reviews for the following new packages. I am willing to swap reviews. > - asl: https://bugzilla.redhat.com/show_bug.cgi?id=2253354 > - ccluster: https://bugzilla.redhat.com/show_bug.cgi?id=2253355 > - lusol: https://bugzilla.redhat.com/show_bug.cgi?id=2253356 > - pdqsort: https://bugzilla.redhat.com/show_bug.cgi?id=2253357 > - zimpl: https://bugzilla.redhat.com/show_bug.cgi?id=2253358 > - zstr: https://bugzilla.redhat.com/show_bug.cgi?id=2253359 > - papilo: https://bugzilla.redhat.com/show_bug.cgi?id=2253360 > - soplex: https://bugzilla.redhat.com/show_bug.cgi?id=2253361 > - scip: https://bugzilla.redhat.com/show_bug.cgi?id=2253362 > - coin-or-HiGHS: https://bugzilla.redhat.com/show_bug.cgi?id=2253363 > - spasm: https://bugzilla.redhat.com/show_bug.cgi?id=2253364 Just a few package reviews to go! This is what remains to be done: - papilo: https://bugzilla.redhat.com/show_bug.cgi?id=2253360 - soplex: https://bugzilla.redhat.com/show_bug.cgi?id=2253361 - scip: https://bugzilla.redhat.com/show_bug.cgi?id=2253362 - coin-or-HiGHS: https://bugzilla.redhat.com/show_bug.cgi?id=2253363 These will need to be reviewed with respect to the [COPR mentioned above](https://copr.fedorainfracloud.org/coprs/jjames/SCIP/), since I can't build asl in Rawhide without breaking the existing mp package, so the rest all has to be done at once in a side tag. Let me know what I can review for you in exchange for the above reviews. -- Jerry James http://www.jamezone.org/ -- ___ 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
runaway fork() in Lua script
For the second time in two days, running "fedpkg build" gave me a few dozen lines that say: warning: runaway fork() in Lua script before the usual build messages start appearing. Is this a known issue? It looks like I am not the only one to encounter this: https://github.com/QubesOS/qubes-issues/issues/8771 -- Jerry James http://www.jamezone.org/ -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in February
On Wed, Jan 24, 2024 at 2:28 PM Michel Lind wrote: > On Wed, Jan 24, 2024 at 10:35:09AM -0700, Jerry James wrote: > > I fixed cl-asdf in Rawhide. > Mind building it in F39 and F38 too? It fails to build there and there > is one bug open for each Sure, I can do that. What we really ought to do is remove all dependencies on this package and retire it. It is ASDF 2.x. AFAIK, both ecl and sbcl ship with ASDF 3.x. I'm not sure about gcl. Anyway, that will take more work than I have time for right now. I'll add it to my TODO list. -- Jerry James http://www.jamezone.org/ -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in February
On Wed, Jan 24, 2024 at 9:39 AM Miro Hrončok wrote: > Based on the current fail to build from source policy, the following packages > should be retired from Fedora 40 approximately one week before branching. [snip] > cl-asdf green I fixed cl-asdf in Rawhide. -- Jerry James http://www.jamezone.org/ -- ___ 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: HEADSUP boost and tbb rebuilds starting in a side tag
On Sat, Jan 20, 2024 at 8:32 AM Jonathan Wakely wrote: > Aha, thanks for figuring that out! The problem was also observed at > https://bugzilla.redhat.com/show_bug.cgi?id=2036372#c43 but I didn't > get the right explanation. > > I'm not sure why the i686 package does that, maybe Jerry knows (I used > his TBB COPR for the new tbb.spec). Upstream has this in src/tbb/CMakeLists.txt: if (CMAKE_SIZEOF_VOID_P EQUAL 8) set(TBB_PC_NAME tbb) else() set(TBB_PC_NAME tbb32) endif() That makes the pkgconfig file install as tbb32.pc. I don't know why upstream is doing that. Maybe so 64-bit and 32-bit installs can coexist on the same system? -- Jerry James http://www.jamezone.org/ -- ___ 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
cryptominisat soname bump
In about a week, I plan to update the cryptominisat package to version 5.11.15 in Rawhide, which comes with an soname bump. We have been stuck on version 5.8.0 for a long time because some consuming packages were not compatible with newer versions. At last all of them are ready for the update. In addition to the cryptominisat package, I will also rebuild: - cvc5 - stp - yices -- Jerry James http://www.jamezone.org/ -- ___ 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: Mass rebuild: git push --no-verify
On Thu, Jan 18, 2024 at 4:50 AM Tomas Hrcka wrote: > This is not a good idea. Because of a few packages that are not rebuilding we > would disable the hook for every push the script does. My thinking is that the hook is not useful for automated build scripts anyway, so disabling it doesn't hurt. See my previous replies in this thread. -- Jerry James http://www.jamezone.org/ -- ___ 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: Mass rebuild: git push --no-verify
On Wed, Jan 17, 2024 at 3:48 PM kevin wrote: > I suppose this might be a good idea... I'd be afraid of what it might > break, while fixing the fonts packages though. But of course if it was > completely broken it would fail after that anyhow... That's exactly my thinking. The package is either broken already or it is not. If it is, then allowing a mass rebuild push won't change the situation. If it is not, then skipping verification has no effect. -- Jerry James http://www.jamezone.org/ -- ___ 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: Mass rebuild: git push --no-verify
On Tue, Jan 16, 2024 at 3:32 PM Sérgio Basto wrote:
> You got mass rebuild script here [1] in massrebuildsinfo.py [2] you may
> define what packages you are going to rebuild , in line 93 of mass-
> rebuild.py [3] you got the list of packages that you go rebuild
> and since line 132 [4] you have the commands that will run .
> Is rpmdev-bumpspec that fails ?
Thank you for the pointer, Sérgio. I have opened
https://pagure.io/releng/pull-request/11897.
It is not rpmdev-bumpspec that fails. That works just fine. But any
package that uses the %{fontpkgname1}, %{fontpkgname2}, ... macros
requires --no-verify today when pushing to git, due to the referenced
bug. That's merely annoying for a human, but fatal to an automated
build script that doesn't pass --noverify.
--
Jerry James
http://www.jamezone.org/
--
___
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
Mass rebuild: git push --no-verify
Given the problems we had with font packages not being rebuilt in the last mass rebuild, can we ensure that the mass rebuild script uses "git push --no-verify" instead of plain "git push"? See: - https://bugzilla.redhat.com/show_bug.cgi?id=2233878 - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7IIZPEC6B4BEOOOV5YFEUGOONNOH5LZO/ -- Jerry James http://www.jamezone.org/ -- ___ 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
pl License updates
I did a reanalysis of the pl package License field. The main package is changing from: BSD-2-Clause AND BSD-3-Clause AND (BSD-3-Clause OR GPL-1.0-or-later) AND Beerware AND CC-BY-SA-3.0 AND (GPL-1.0-or-later OR Artistic-1.0-Perl) AND GPL-2.0-or-later AND GPL-2.0-or-later WITH SWI-Exception AND (GPL-2.0-or-later WITH SWI-Exception OR Artistic-2.0) AND LGPL-2.0-or-later AND LicenseRef-Fedora-Public-Domain AND LPPL-1.2 AND MIT AND Sleepycat AND Unicode-DFS-2015 AND Unicode-DFS-2016 AND Zlib to: BSD-2-Clause AND BSD-3-Clause AND (Brian-Gladman-3-Clause OR GPL-1.0-or-later) AND Beerware AND CC-BY-SA-3.0 AND (GPL-1.0-or-later OR Artistic-1.0-Perl) AND GPL-2.0-or-later AND GPL-2.0-or-later WITH SWI-Exception AND (GPL-2.0-or-later WITH SWI-Exception OR Artistic-2.0) AND LGPL-2.0-or-later AND LicenseRef-Fedora-Public-Domain AND LPPL-1.3a AND MIT AND Sleepycat AND Unicode-DFS-2015 AND Unicode-DFS-2016 AND Zlib AND dtoa i.e., the following changes: - Change (BSD-3-Clause OR GPL-1.0-or-later) to (Brian-Gladman-3-Clause OR GPL-1.0-or-later) - Change LPPL-1.2 to LPPL-1.3a - Add dtoa The License field of the compat-yap-devel subpackage is changing from: BSD-2-Clause AND AND GPL-2.0-or-later AND GPL-2.0-or-later WITH Bison-exception-2.2 AND LicenseRef-Fedora-Public-Domain AND Spencer-99 AND TCL to: BSD-2-Clause AND AND GPL-2.0-or-later AND GPL-2.0-or-later WITH Bison-exception-2.2 AND LicenseRef-Fedora-Public-Domain AND Spencer-99 AND TCL AND FBM i.e., FBM is added. I have pushed this change to git, and will let the mass rebuild do the package build. -- Jerry James http://www.jamezone.org/ -- ___ 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
polyml soname bump
In about a week, I plan to update polyml to version 5.9.1. This includes an soname bump in the polyml library. Nothing in Fedora depends on it, so there should be no breakage. -- Jerry James http://www.jamezone.org/ -- ___ 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: Two review swaps
On Tue, Dec 26, 2023 at 7:31 PM Lyes Saadi wrote: > I have two review requests I'd like to swap with anyone willing to ! I have taken both reviews. -- Jerry James http://www.jamezone.org/ -- ___ 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: unicorn on s390x
On Sun, Dec 17, 2023 at 12:18 PM Jerry James wrote: > With some architecture/gcc combinations, you have to link with > -latomic to get access to the 128-bit atomic functions. Upstream's > configure script assumes those functions are builtin or not present at > all. They need to check for a 3rd possibility: that they are present > in libatomic. It looks like you will need to add "atomic" to the target_link_libraries invocations at lines 1318 and 1323 of CMakeLists.txt. You will also need to change qemu/configure so that the compile_prog invocations at lines 1831, 1846, and 1876 read: if compile_prog "" "-latomic" ; then You should probably add "BuildRequires: libatomic" as well, just to be sure it is installed. -- Jerry James http://www.jamezone.org/ -- ___ 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: unicorn on s390x
On Sat, Dec 16, 2023 at 3:20 PM W. Michael Petullo wrote: > I maintain Fedora's unicorn package. This package will not presently > build on s390x, and I am not certain why. The problem seems to have to > do with 128-bit instructions. With some architecture/gcc combinations, you have to link with -latomic to get access to the 128-bit atomic functions. Upstream's configure script assumes those functions are builtin or not present at all. They need to check for a 3rd possibility: that they are present in libatomic. -- Jerry James http://www.jamezone.org/ -- ___ 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: rpmbuild sagemath 10.1 on Fedora 38
Please keep your replies on the public mailing list where the conversation started. On Fri, Dec 8, 2023 at 3:39 PM Rafel Amer Ramon wrote: > As a first attempt, I didn't use the patches beacuse a lot of them failed. > Today I have revised and modified some of the patches and I can apply 20 > of them. Right, this is always part of updating to a new sagemath version. You have to determine which of the patches are still needed, and whether they need to be revised. It's tedious work for sure. And of course, it's always a good idea to push as many patches upstream as possible so that someday they can be dropped from the Fedora build altogether. > I can't apply the patches sagemath-maxima.patch sagemath-python3.patch and > sagemath-intersphinx.patch beacause the original files have changed a lot > and I even don't know how to patch the files manually. The question is whether the problems those patches address have been fixed upstream. If not, the patches will have to be ported to the new sources. > Now the process of buiding the package runs, but at the end I get the errors Ignore the warnings. Those symlinks are needed and correct. This is the error: > RPM build errors: > File not found: > /root/rpmbuild/BUILDROOT/sagemath-10.1-1.fc38.x86_64/usr/share/doc/sagemath/index.html > Directory not found: > /root/rpmbuild/BUILDROOT/sagemath-10.1-1.fc38.x86_64/usr/share/doc/sagemath/html So either the documentation building step failed or the documentation is installed in a different location now. You will have to look in the build log to determine which of those is the case. > If I am able to buid the sagemath package, I'm interested in being the > mantainer of it. That would be great. Hopefully upstream makes good progress on supporting python 3.12. Regards, -- Jerry James http://www.jamezone.org/ -- ___ 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: rpmbuild sagemath 10.1 on Fedora 38
Hi Rafel, On Fri, Dec 8, 2023 at 1:35 PM Rafel Amer Ramon wrote: > I'm trying to rpmbild sagemath 10.1 on Fedora 38, but I gave an error. > See the attached files sagemath.spec and sagemath.log. > > Any help would be appreciated. I see you threw away all of the patches. I think you're going to find that you need most of them. In particular, you discarded the patch to use flexiblas. The error you are getting indicates that sagemath did not find a usable blas implementation. Updating the sagemath package to a new version is a pretty involved process. It would take me hours every time a new version came out to update it, one reason why I ultimately decided to stop doing it. -- Jerry James http://www.jamezone.org/ -- ___ 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
SoPlex and SCIP review swaps
Kevin Kofler noted about a year ago [1] that new versions of the solvers SoPlex [2] and SCIP [3] were released under free software licenses. Over the last year, I've been working little by little on building them in a COPR [4] and rebuilding various Fedora packages with SoPlex and SCIP support. I believe we have reached the point where we can start integrating this work into Fedora. References: [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GGGRTBI3ZQYXMNLTPAYCW5IT4FYNY6GX/ [2] https://soplex.zib.de/ [3] https://scipopt.org/ [4] https://copr.fedorainfracloud.org/coprs/jjames/SCIP/ I need reviews for the following new packages. I am willing to swap reviews. - asl: https://bugzilla.redhat.com/show_bug.cgi?id=2253354 - ccluster: https://bugzilla.redhat.com/show_bug.cgi?id=2253355 - lusol: https://bugzilla.redhat.com/show_bug.cgi?id=2253356 - pdqsort: https://bugzilla.redhat.com/show_bug.cgi?id=2253357 - zimpl: https://bugzilla.redhat.com/show_bug.cgi?id=2253358 - zstr: https://bugzilla.redhat.com/show_bug.cgi?id=2253359 - papilo: https://bugzilla.redhat.com/show_bug.cgi?id=2253360 - soplex: https://bugzilla.redhat.com/show_bug.cgi?id=2253361 - scip: https://bugzilla.redhat.com/show_bug.cgi?id=2253362 - coin-or-HiGHS: https://bugzilla.redhat.com/show_bug.cgi?id=2253363 - spasm: https://bugzilla.redhat.com/show_bug.cgi?id=2253364 I will shortly open pull requests for each of the following packages. I wanted to post this message first so that the PR text can include a reference to it. - bliss - coin-or-Alps - coin-or-Bcp - coin-or-Bcps - coin-or-Blis - coin-or-Bonmin - coin-or-Cbc - coin-or-Cgl - coin-or-Clp - coin-or-CoinMP - coin-or-CoinUtils - coin-or-Couenne - coin-or-Dip - coin-or-DyLP - coin-or-FlopC++ - coin-or-lemon - coin-or-Ipopt - coin-or-OS - coin-or-Osi - coin-or-SYMPHONY - freefem++ - gfan - latte-integrale - Macaulay2 - mp - opencv - openms - polymake - python-cyipopt - python-pysingular - qsopt-ex - seqan - seqan2 - seqan3 - Singular - sympol - TOPCOM ASL vs. mp -- Many of the coin-or packages currently BuildRequires mp-devel. They really only need the ASL part of mp. Upstream has split the two projects into separate git repositories; see the new asl package listed above. This will reduce the number of runtime dependencies for the coin-or packages. Since the new asl package conflicts with the current mp package, the introduction of asl, modification of mp, and rebuilding of affected coin-or packages all need to be done at once. Once all of the reviews are complete, they will be built in a side tag. i386 removal Some of the new packages need some work to build correctly on i386. Why bother? Let's not build for i386 in the first place. That means, however, that some of the packages that sit on top of them will need to be modified to stop building for i386 as well. That is the extent of the modifications to some of these packages (e.g., freefem++). Since opencv and openms are both still built for i386, the packages that they depend on (including the new asl package) must also be built for i386 for now. -- Jerry James http://www.jamezone.org/ -- ___ 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
Review swaps
Who would like to swap package reviews? I've got 4 packages that need to be reviewed: ocaml-ptime: https://bugzilla.redhat.com/show_bug.cgi?id=2242903 ocaml-crunch: https://bugzilla.redhat.com/show_bug.cgi?id=2242904 ocaml-stdlib-random: https://bugzilla.redhat.com/show_bug.cgi?id=2242905 JUnitParams: https://bugzilla.redhat.com/show_bug.cgi?id=2247877 Let me know what I can review for you. A note for those trying to get us to move from this mailing list to discussion.fedoraproject.org. I have been asking for these reviews there for 3 weeks now [1], and am getting nowhere. We don't seem to have a critical mass of packagers looking there for package reviews. [1] https://discussion.fedoraproject.org/t/1-c-1-java-and-3-ocaml-reviews/93946 -- Jerry James http://www.jamezone.org/ -- ___ 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: SPDX short name for "Redistributable, no modification permitted" (firmware)
On Sun, Oct 15, 2023 at 3:13 AM Robert-André Mauchin wrote: > I'm doing a MR on an old package that contains firmware data. > > I wanna convert to SPDX, what is the equivalent to "Redistributable, no > modification > permitted" in SPDX. [snip] > What can I use for SPDX? According to https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_redistributable_no_modification_permitted, you should submit this license for review. See https://docs.fedoraproject.org/en-US/legal/license-review-process/. -- Jerry James http://www.jamezone.org/ ___ 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
i386 leaf report
Figuring out whether a given package is a leaf for i386 is a pain in the neck when done manually. How about we have a computer figure it out for us? Those of you who run regular reports, what would it take to run a report every week or two that lists every package X such that: 1. X has no ExcludeArch field that expands to a value including "i386"; 2. X has no ExclusiveArch field that expands to a value not including "i386"; and 3. For every package Y that BuildRequires or Requires X or any of its subpackages: A. Y has an ExcludeArch field that expands to a value including "i386"; or B. Y has an ExclusiveArch field that expands to a value not including "i386". Bonus points if the report can take a list of packages to exclude. That way, over time we can figure out which packages we really want to build for i386 and drop them from the report. When the report lists 0 packages, we have reached nirvana. I'm willing to put in some work to write such a report, but have no clue how to get started. If someone can point me in the right direction, I can take a stab at it. -- Jerry James http://www.jamezone.org/ ___ 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: %prep leaving SPECPARTS directories lying around
On Thu, Sep 14, 2023 at 12:32 PM Adam Williamson wrote: > It seems like, as of fairly recently, the %prep stage for any Fedora > package build leaves an empty directory named the same as the package > source directory with with -SPECPARTS appended lying around. > > Do we know why this is happening, and can it be stopped? It already > caused problems for CI for a few packages, and it's just a bit messy... I think it is related to the dynamic spec file feature. See https://github.com/rpm-software-management/rpm/discussions/2032. Also see https://github.com/rpm-software-management/rpm/issues/2532 for some other cases where SPECPARTS caused issues. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Will noarch packages "inherit" ExcludeArch from another noarch package
On Tue, Sep 12, 2023 at 10:02 PM Jerry James wrote:
> I looked at blueprint-compiler tonight, and found 2 bugs with the
> handling of bitfields. Sadly, fixing those still doesn't make the
> test suite pass, so there is at least one more bug lurking somewhere.
> Still, I think the package is probably fixable. If you can wait just
> a little longer, I will try to find the next bug tomorrow.
Bug 3 was on the line right next to bug 2. :-) I have opened
https://gitlab.gnome.org/jwestman/blueprint-compiler/-/merge_requests/143.
That patch does not apply cleanly to version 0.6.0, but the attached
version does.
--
Jerry James
http://www.jamezone.org/
--- blueprint-compiler-v0.6.0/blueprintcompiler/gir.py.orig 2022-11-26 16:14:49.0 -0700
+++ blueprint-compiler-v0.6.0/blueprintcompiler/gir.py 2023-09-13 08:32:20.150427956 -0600
@@ -603,8 +603,8 @@ class Repository(GirNode):
return self.lookup_namespace(ns).get_type(dir_entry.DIR_ENTRY_NAME)
def _resolve_type_id(self, type_id: int):
-if type_id & 0xFF == 0:
-type_id = (type_id >> 27) & 0x1F
+if type_id & (0xFF if sys.byteorder == "little" else 0xFF00) == 0:
+type_id = ((type_id >> 27) if sys.byteorder == "little" else type_id) & 0x1F
# simple type
if type_id == typelib.TYPE_BOOLEAN:
return BoolType()
--- blueprint-compiler-v0.6.0/blueprintcompiler/typelib.py.orig 2022-11-26 16:14:49.0 -0700
+++ blueprint-compiler-v0.6.0/blueprintcompiler/typelib.py 2023-09-13 08:47:24.479850483 -0600
@@ -61,7 +61,14 @@ class Field:
def __init__(self, offset, type, shift=0, mask=None):
self._offset = offset
self._type = type
-self._shift = shift
+if not mask or sys.byteorder == "little":
+self._shift = shift
+elif self._type == "u8" or self._type == "i8":
+self._shift = 7 - shift
+elif self._type == "u16" or self._type == "i16":
+self._shift = 15 - shift
+else:
+self._shift = 31 - shift
self._mask = (1 << mask) - 1 if mask else None
self._name = f"{offset}__{type}__{shift}__{mask}"
@@ -160,7 +167,7 @@ class Typelib:
OBJ_FINAL = Field(0x02, "u16", 3, 1)
OBJ_GTYPE_NAME = Field(0x08, "string")
OBJ_PARENT = Field(0x10, "dir_entry")
-OBJ_GTYPE_STRUCT = Field(0x14, "string")
+OBJ_GTYPE_STRUCT = Field(0x12, "string")
OBJ_N_INTERFACES = Field(0x14, "u16")
OBJ_N_FIELDS = Field(0x16, "u16")
OBJ_N_PROPERTIES = Field(0x18, "u16")
@@ -241,7 +248,11 @@ class Typelib:
return self._typelib_file[loc:end].decode("utf-8")
def _int(self, size, signed):
-return int.from_bytes(self._typelib_file[self._offset:self._offset + size], sys.byteorder)
+return int.from_bytes(
+self._typelib_file[self._offset:self._offset + size],
+sys.byteorder,
+signed=signed,
+)
class TypelibHeader(Typelib):
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Will noarch packages "inherit" ExcludeArch from another noarch package
On Tue, Sep 12, 2023 at 11:11 AM Lyes Saadi wrote: > Oh woops, answered to Jerry James privately instead to the whole devel > mailing list. It's indeed about blueprint-compiler. I looked at blueprint-compiler tonight, and found 2 bugs with the handling of bitfields. Sadly, fixing those still doesn't make the test suite pass, so there is at least one more bug lurking somewhere. Still, I think the package is probably fixable. If you can wait just a little longer, I will try to find the next bug tomorrow. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Will noarch packages "inherit" ExcludeArch from another noarch package
On Tue, Sep 12, 2023 at 10:03 AM Lyes Saadi wrote: > I have a noarch package which faces an issue with one of its arches > (s390x), and which happens to have multiple noarch packages depending on > it, and they won't build either if they were built on that same arch > (but, they will still work normally when installed on that arch). And > so, I plan on adding an ExcludeArch, as per > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_arch_specific_runtime_and_build_time_dependencies. > > But, I don't know if I need to also ask maintainers of every dependency > to add ExcludeArch themselves. Indeed, the guideline says : > > You can limit both the architectures used to build a noarch package, > *and the repositories to which the built noarch package will be added* > > So, am I correct in assuming that if my noarch package uses ExcludeArch, > every other dependent package, when building, will not build on that > Arch as well ? You will indeed have to ask the maintainers of consuming packages to add that ExcludeArch too. What package is it and what is the nature of the problem on s390x? Maybe it can be fixed. -- Jerry James http://www.jamezone.org/ ___ 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: Fedora rawhide compose report: 20230911.n.1 changes
On Mon, Sep 11, 2023 at 3:16 PM Fedora Rawhide Report wrote: > = ADDED PACKAGES = [snip] > Package: python-sphinx_reredirects-0.1.2-2.fc40 > Summary: Handles redirects for moved pages in Sphinx documentation projects > RPMs:python3-sphinx_reredirects > Size:21.18 KiB This appears to be a duplicate of the existing python-sphinx-reredirects package. Please retire this one. -- Jerry James http://www.jamezone.org/ ___ 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: Orphaning scala, jline, and friends
Hi Christiano, On Wed, Aug 23, 2023 at 5:30 AM Christiano Anderson wrote: > I'm Scala developer and I'm willing to maintain (or co-maintain) Scala > package, maybe add Scala 3 as well. > > Since I have never maintained any Fedora package, if I find a sponsor, I'll > be glad to maintain (or co-maintain) Scala. It would be really great to have a Scala developer maintain the package. I will get in touch with you privately to discuss sponsoring you. Be aware that, since we don't have sbt in Fedora, the current scala package is a real Frankenstein monster. -- Jerry James http://www.jamezone.org/ ___ 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: Orphaning scala, jline, and friends
On Fri, Aug 11, 2023 at 10:30 AM Jerry James wrote: > java-diff-utils > jline > jol > juniversalchardet > material-icons-fonts > scala > scalacheck Also the test-interface package. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaning scala, jline, and friends
A couple of years ago, I picked up the scala package because a couple of packages I care about depended on it. In the past few months both packages have dropped their scala dependencies. I am orphaning the following packages: java-diff-utils jline jol juniversalchardet material-icons-fonts scala scalacheck They are all on their latest upstream versions and have no open bugs (but material-icons-fonts has an open PR). -- Jerry James http://www.jamezone.org/ ___ 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: [Cython3 need help] Re: mass rebuild for opencv 4.8.0 with soname bump on rawhide
On Mon, Aug 7, 2023 at 5:02 PM Sérgio Basto wrote: > Error compiling Cython file: > > ... > def set_depth_callback(DevPtr dev, cb): > global _depth_cb > if cb is not None: > _depth_cb = cb > freenect_set_depth_callback(dev._ptr, depth_cb) > ^ > > /builddir/build/BUILD/libfreenect- > 0.7.0/wrappers/python/freenect.pyx:351:46: Cannot assign type 'void > (freenect_device *, void *, uint32_t) except * nogil' to > 'freenect_depth_cb' You probably have to patch that declaration to add "noexcept". See https://src.fedoraproject.org/rpms/python-pari-jupyter/blob/rawhide/f/python-pari-jupyter-cython3.patch for an example. If that is the issue, see https://cython.readthedocs.io/en/latest/src/userguide/migrating_to_cy30.html#exception-values-and-noexcept for more information. -- Jerry James http://www.jamezone.org/ ___ 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: Fedora 39 Mass Rebuild
On Mon, Jul 24, 2023 at 1:15 PM Alexander Ploumistos
wrote:
> Is it up to the packagers to rebuild these? I have a package on this
> list, but there is no commit in dist-git concerning the F39 Mass
> Rebuild.
I just discovered that the fontawesome-fonts package had no commit or
build either. I wonder if it has something to do with this error I
just encountered while preparing an update for the package:
$ git push
Source file '60-%{fontpkgname1}.conf' was neither listed in the
'sources' file nor tracked in git. Push operation was cancelled
Hint: this check (.git/hooks/pre-push script) can be bypassed by
adding the argument '--no-verify' argument to the push command.
error: failed to push some refs to
'ssh://pkgs.fedoraproject.org/rpms/fontawesome-fonts'
The error is bogus. Something failed to expand the %{fontpkgname1}
macro. I wonder if the mass rebuilder actually made a commit, but the
push failed.
--
Jerry James
http://www.jamezone.org/
___
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: Say goodbye to polymake
On Thu, Jul 20, 2023 at 7:29 AM Richard W.M. Jones wrote: > On Thu, Jul 20, 2023 at 02:20:59AM +0200, Kevin Kofler via devel wrote: > > As I understand it, this function is included in the public (at least, it is > > declared EXT, so it should not be hidden) PL_check array (several times, the > > first time at index 2), so I believe something like: > > #define Perl_ck_fun (PL_check[2]) > > should work. > > That seems possible, although it's a bit of a hack to misuse the array > like this: > > https://github.com/Perl/perl5/blob/ccfa6b533228ad41e4dbc5576cd43081b8fd2a13/opcode.h#L1431 > > I suppose if polymake is going to fiddle with Perl internals anyway, > then why not. Thank you very much, Kevin and Rich, for the hints. I decided to see if polymake could be made to work with perl 5.38.0 after all. It turns out that polymake calls quite a few functions that are now hidden. However, the function prototypes are still included in public headers, so that did not become apparent until link time. I have been able to find pointers to most of them (mostly in PL_ppaddr). A few gave me some trouble: Perl_keyword Perl_list Perl_save_pushptrptr Perl_scalar Perl_yyerror For each of those, I included the upstream perl implementations (nearly) verbatim in the polymake code. Yuck. But it seems to "work". I am now encountering the kinds of problems upstream would have faced with perl 5.38.0 anyway, even without functions becoming hidden. For example, I just adapted the code to this change in Perl_anoncode: https://github.com/Perl/perl5/pull/20290. There are probably more issues. Whether all of them can be addressed remains to be seen. However, I will not orphan or retire any packages for now. -- Jerry James http://www.jamezone.org/ ___ 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: Review swaps
On Wed, Jul 19, 2023 at 2:35 PM Scott Talbert wrote: > I'm happy to take cvc5, since I just packaged it for Debian a little while > back. But yeah, it would be nice to have a working fedora-review. Thank you, Scott. Having someone familiar with cvc5 review it would be great. Like I just told Richard, there is a thread about fixing fedora-review in place: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/QMCHW3ZUTKLPIDARUFKPINA3VBSI3OT5/ I've used that to do ... what? Four reviews, I think? I haven't encountered any trouble so far. (Which doesn't mean you won't, of course!) -- Jerry James http://www.jamezone.org/ ___ 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: Review swaps
On Wed, Jul 19, 2023 at 2:26 PM Richard W.M. Jones wrote: > Just to let you know I'm still up for reviewing those ocaml-* packages > (without swaps), but I'm waiting on a final resolution of > fedora-review on Rawhide. Thank you. I can wait. :-) I started a thread about fixing fedora-review in place, although I won't claim that is a good idea: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/QMCHW3ZUTKLPIDARUFKPINA3VBSI3OT5/ -- Jerry James http://www.jamezone.org/ ___ 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
Review swaps
Hi all, Is anyone interested in swapping reviews? I've got some nontrivial packages awaiting review, and am willing to review nontrivial packages in exchange. Font packages needed to update MuseScore to 4.x: makemusic-finale-fonts: https://bugzilla.redhat.com/show_bug.cgi?id=2152347 edwin-fonts: https://bugzilla.redhat.com/show_bug.cgi?id=2180241 leland-fonts: https://bugzilla.redhat.com/show_bug.cgi?id=2180242 MuseScore 4.1.0, along with a package rename: musescore: https://bugzilla.redhat.com/show_bug.cgi?id=2180243 All of the above are available in a COPR: https://copr.fedorainfracloud.org/coprs/jjames/MuseScore4/ Finally, a replacement for the existing cvc4 package: cvc5: https://bugzilla.redhat.com/show_bug.cgi?id=2223012 Thank you! -- Jerry James http://www.jamezone.org/ ___ 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: fedora-review workarounds for dnf5
On Tue, Jul 18, 2023 at 7:28 AM Fabio Valentini wrote:
> On Tue, Jul 18, 2023, 15:22 Maxwell G wrote:
>> --requires --resolve resolves the entire dependency tree of a package.
>> --requires just prints the direct dependencies that are specified in the
>> RPM metadata.
>> I don't know what this code is used for,
>> but I don't think simply removing --resolve is the right solution.
>
>
> Is it though? I assume you're thinking of "--recursive". As far as I know,
> "--requires --resolve" force resolution of virtual provides instead. I don't
> think removing "--resolve" is the correct solution for this case.
>
> For example, the check if a package depends on something that's deprecated
> (i.e. "Provides: deprecated ()") would need to resolve and check the actual
> package dependencies, not only virtual provides.
That's the reason for the second change I proposed, namely changing
line 97 from:
name = line.rsplit(".", 2)[0]
to:
name = resolve_one(line)[0].rsplit(".", 2)[0]
The `resolve_one` function resolves the dependencies one at a time, to
compensate for unavailability of the --resolve option. On second
thought, though, perhaps that code should be:
for arg in resolve_one(line):
name = arg.rsplit(".", 2)[0]
deps.append(name.rsplit("-", 2)[0])
--
Jerry James
http://www.jamezone.org/
___
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: Say goodbye to polymake
On Tue, Jul 18, 2023 at 5:41 AM Richard W.M. Jones wrote: > The first error is: > > /home/rjones/d/fedora/polymake/rawhide/polymake-4.10/lib/core/src/perl/RefHash.xxs:737:11: > error: ‘Perl_ck_fun’ was not declared in this scope; did you mean > ‘Perl_cx_dup’? > 737 |return Perl_ck_fun(aTHX_ o); > | ^~~ > | Perl_cx_dup > ninja: build stopped: subcommand failed. > > As far as I can see that's the only missing / hidden Perl symbol. > > This symbol was hidden in: > https://github.com/Perl/perl5/commit/0351a629e71de127cbfd1b142e9eaa6069deabf5 > > As for what it does, that's more tricky. I believe what it's doing is > while Perl is parsing the input script, it is used to check that the > thing you are calling is a function. Unfortunately it's slightly more > complicated than that because it can convert some function-like things > to functions (returning the updated OP*). Also Perl_ck_fun is > complicated, to say the least: > > https://github.com/Perl/perl5/blob/a6d10131eee6ee336e4bd63f22a378e9d5ae40bd/op.c#L12522 > > For these reasons we can't just replace 'return Perl_ck_fun(aTHX_ o)' > with 'return aTHX_ o', nor can be copy the function into the polymake > source (since it calls other internal functions, but also for > licensing reasons). > > So I think this does require upstream attention. The code also calls save_pushptrptr (Pel_save_pushptrptr), another hidden symbol. Polymake has long had way too much knowledge of perl internals, which is why it has tended to break whenever a new perl version was released. It broke drastically this time. > Another note is this package requires ocaml-tplib which we orphaned. Right. I was going to remove that dependency, but the package broke from the perl update while we were still doing the OCaml 5 builds, so I never got the chance. At this point, I don't see how to keep it in Fedora until upstream does some major surgery on their code base. Thanks for looking at it! -- Jerry James http://www.jamezone.org/ ___ 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
Say goodbye to polymake
The introduction of perl 5.38.0 broke polymake beyond repair. Several symbols formerly used by polymake have been marked as internal APIs. They now have the ELF hidden attribute, so we can't even cheat by adding prototypes to the polymake code. Polymake upstream is aware of the issue. For the time being, they are advising their downstreams to stay on perl 5.36.0, which is not feasible for Fedora. In the long term, they plan to remove the mandatory perl bindings from polymake. However, they as yet have no timeline for that effort. It might be years. I don't see that I have any choice but to retire polymake from Rawhide. This will have some repercussions: - gap-pkg-polymaking, python-jupymake, and python-jupyter-polymake will also be retired - sagemath and Macaulay2 will be rebuilt without polymake support - packages that I have maintained solely for use by polymake will be orphaned: azove, permlib, plantri, sympol, vinci I could try begging the perl package maintainers to add a downstream patch making the affected symbols visible again. However, since those symbols are now internal only, the perl maintainers are free to alter or remove them at any time, so that would not be a good long term solution. -- Jerry James, who is currently channeling Billy Joel http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in August
On Mon, Jul 17, 2023 at 1:15 PM Miro Hrončok wrote: > xmvn-connector-ivymizdebsk Didik opened a PR to fix this: https://src.fedoraproject.org/rpms/xmvn-connector-ivy/pull-request/2. -- Jerry James https://www.jamezone.org/ ___ 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: fedora-review workarounds for dnf5
On Mon, Jul 17, 2023 at 10:54 AM Jerry James wrote:
> Like many of you, I have been quite inconvenienced because of
> dnf5-related breakage of fedora-review. I've been monkeying with it
> today and finally got a successful run of fedora-review after making
> the following changes [*].
>
> 1. Edit /etc/mock/templates/fedora-rawhide.tpl. Change:
>
> config_opts['package_manager'] = 'dnf'
>
> to:
>
> config_opts['package_manager'] = 'dnf5'
>
> 2. Run 'mock -r fedora-rawhide-x86_64 --scrub=bootstrap'
>
> 3. Edit /usr/lib/python3.11/site-packages/FedoraReview/deps.py. Change line
>83 from:
>
> "dnf repoquery -q -C --requires --resolve " + "
> ".join(list(set(pkgs))),
>
>to:
>
> "dnf repoquery -q -C --requires " + " ".join(list(set(pkgs))),
>
>Change line 97 from:
>
> name = line.rsplit(".", 2)[0]
>
>to:
>
> name = resolve_one(line)[0].rsplit(".", 2)[0]
>
> Change line 286 from:
>
> "dnf repoquery -C -l " + " ".join(list(set(pkgs))),
>
>to:
>
> "dnf repoquery --files " + " ".join(list(set(pkgs))),
>
> Other changes may be needed.
>
> [*] Altering rpm-controlled files is generally a bad idea, and I do not
> recommend it. I am only doing so in this case because fedora-review does
> not work at all without these changes. I understand that my changes will
> be overwritten the next time a mock-core-configs or fedora-review update
> is installed.
Skip steps 1 and 2. They are unnecessary. Step 3 is all you need.
--
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
fedora-review workarounds for dnf5
Like many of you, I have been quite inconvenienced because of
dnf5-related breakage of fedora-review. I've been monkeying with it
today and finally got a successful run of fedora-review after making
the following changes [*].
1. Edit /etc/mock/templates/fedora-rawhide.tpl. Change:
config_opts['package_manager'] = 'dnf'
to:
config_opts['package_manager'] = 'dnf5'
2. Run 'mock -r fedora-rawhide-x86_64 --scrub=bootstrap'
3. Edit /usr/lib/python3.11/site-packages/FedoraReview/deps.py. Change line
83 from:
"dnf repoquery -q -C --requires --resolve " + " ".join(list(set(pkgs))),
to:
"dnf repoquery -q -C --requires " + " ".join(list(set(pkgs))),
Change line 97 from:
name = line.rsplit(".", 2)[0]
to:
name = resolve_one(line)[0].rsplit(".", 2)[0]
Change line 286 from:
"dnf repoquery -C -l " + " ".join(list(set(pkgs))),
to:
"dnf repoquery --files " + " ".join(list(set(pkgs))),
Other changes may be needed.
[*] Altering rpm-controlled files is generally a bad idea, and I do not
recommend it. I am only doing so in this case because fedora-review does
not work at all without these changes. I understand that my changes will
be overwritten the next time a mock-core-configs or fedora-review update
is installed.
--
Jerry James
http://www.jamezone.org/
___
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: OCaml binary stripping (was: Re: OCaml 5 again)
On Wed, Jul 12, 2023 at 3:34 PM Richard W.M. Jones wrote: > I looked through the section names with objdump -h and none of them > looked unusual. However I think in the past when we analyzed this we > found it was doing something really crazy, like actually appending the > bytecode to the file (ie. not using the ELF format at all). That was the conclusion I had just come to. In the unstripped binary, the ELF structure accounts for about 700K, but the file size is over 3M. It looks like they really do just append the bytecode to the file. -- Jerry James http://www.jamezone.org/ ___ 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: FYI OCaml 5.0 rebuild is under way
On Wed, Jul 12, 2023 at 11:04 AM Jerry James wrote: > On Wed, Jul 12, 2023 at 11:00 AM Richard W.M. Jones wrote: > > > My test build of the swig package, which succeeded, was done with > > > python 3.11. I suspect that this is python 3.12 breakage. The OCaml > > > testsuite passed, so this failure is probably unrelated to the OCaml > > > 5.0.0 update. > > > > Not sure how to fix this. We could disable the SWIG tests entirely, > > but that's quite aggressive. > > I'll see if I can figure it out. This looks like a python 3.12 bug: https://bugzilla.redhat.com/show_bug.cgi?id=449 On an x86_64 Fedora 38 machine, with python 3.11: $ python3 Python 3.11.4 (main, Jun 7 2023, 00:00:00) [GCC 13.1.1 20230511 (Red Hat 13.1.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> x = "hello" >>> sys.getrefcount(x) 2 >>> y = x >>> sys.getrefcount(x) 3 On an x86_64 Rawhide machine, with python 3.12: $ python3 Python 3.12.0b3 (main, Jun 21 2023, 00:00:00) [GCC 13.1.1 20230614 (Red Hat 13.1.1-4)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> x = "hello" >>> sys.getrefcount(x) 4294967295 >>> y = x >>> sys.getrefcount(x) 4294967295 -- Jerry James http://www.jamezone.org/ ___ 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: FYI OCaml 5.0 rebuild is under way
On Wed, Jul 12, 2023 at 11:00 AM Richard W.M. Jones wrote: > > > - swig > > > > > >This also should work but does not. It has a very opaque failures > > >in the test suite. I'm going to try to reproduce this one locally. > > > > This is the failure: > > > > checking python testcase langobj (with run test) > > Traceback (most recent call last): > > File > > "/builddir/build/BUILD/swig-4.1.1/Examples/test-suite/python/./langobj_runme.py", > > line 13, in > > raise RuntimeError > > RuntimeError > > make[1]: *** [Makefile:123: langobj.cpptest] Error 1 > > Ah interesting, I couldn't find that. > > > My test build of the swig package, which succeeded, was done with > > python 3.11. I suspect that this is python 3.12 breakage. The OCaml > > testsuite passed, so this failure is probably unrelated to the OCaml > > 5.0.0 update. > > Not sure how to fix this. We could disable the SWIG tests entirely, > but that's quite aggressive. I'll see if I can figure it out. -- Jerry James http://www.jamezone.org/ ___ 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: FYI OCaml 5.0 rebuild is under way
On Wed, Jul 12, 2023 at 9:37 AM Richard W.M. Jones wrote:
> - ocaml-atd
>
>Fails to build because it requires Python3 flake8 which is
>uninstallable at the moment.
It is used for testing only, so we can disable the python tests for
now to get this to build.
> - ocaml-camlp5
>
>Waiting on two packages to be reviewed (see below).
Reviews much appreciated! I am happy to swap reviews.
> - coq
>
>Unclear what's going on here, I asked Jerry to take a look since
>his earlier build was successful. This also affects:
>
>- flocq
>- frama-c
>- gappalib-coq
>- why3
>- zenon
>
>I will submit builds for these once coq is sorted out.
Coq has a plugin architecture which appears to depend on the OCaml
native compiler, so the solution is to add "ExclusiveArch:
%{ocaml_native_compiler}" to these spec files.
> - swig
>
>This also should work but does not. It has a very opaque failures
>in the test suite. I'm going to try to reproduce this one locally.
This is the failure:
checking python testcase langobj (with run test)
Traceback (most recent call last):
File
"/builddir/build/BUILD/swig-4.1.1/Examples/test-suite/python/./langobj_runme.py",
line 13, in
raise RuntimeError
RuntimeError
make[1]: *** [Makefile:123: langobj.cpptest] Error 1
My test build of the swig package, which succeeded, was done with
python 3.11. I suspect that this is python 3.12 breakage. The OCaml
testsuite passed, so this failure is probably unrelated to the OCaml
5.0.0 update.
> - graphviz
>
>Requires a fix to swig, which cannot be built, see above.
>
> - haxe
>
>Requires camlp5, see above.
I believe Andy Li is looking at fixing haxe, which also uses
interfaces that were removed in OCaml 5.
--
Jerry James
http://www.jamezone.org/
___
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: OCaml binary stripping (was: Re: OCaml 5 again)
On Wed, Jul 12, 2023 at 4:38 AM Richard W.M. Jones wrote:
> During the OCaml 5 rebuild I found there's a generic problem on s390x
> & ppc64le (ie. the bytecode-only architectures) involving stripping of
> OCaml binaries. A good example is supermin on s390x:
>
> # uname -a
> Linux e132ed8a0a9b4411b210e43e253581f0 6.4.0-59.fc39.s390x #1 SMP Mon Jun
> 26 11:55:15 UTC 2023 s390x GNU/Linux
> # supermin --version
> unknown option --version
> # echo $?
> 127
>
> The binary is correct when built, but gets corrupted after one of
> these steps is applied (not sure which):
>
> + /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
> + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
>
> In the past we had this commit in supermin:
>
> commit 18ebd2cc631f119a10374a914d5c725288060349
> Author: Dan Horák
> Date: Thu Sep 15 12:09:34 2016 +0200
>
> - Do not break the binary on interpreted builds (#1375213)
>
> diff --git a/supermin.spec b/supermin.spec
> index 30af5fb..8d4f03b 100644
> --- a/supermin.spec
> +++ b/supermin.spec
> @@ -1,3 +1,8 @@
> +%ifnarch %{ocaml_native_compiler}
> +%global __strip /bin/true
> +%global debug_package %{nil}
> +%endif
> +
> [etc]
>
> which basically kills off stripping. However that may or may not
> still work. It was removed because it was no longer necessary (as we
> had an s390x native code backend), and because of this bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1915570
>
> So I'm going with this instead to see if it cures the problem:
>
> %ifnarch %{ocaml_native_compiler}
> %global __strip /bin/true
> %global _lto_cflags %nil
> %global debug_package %{nil}
> %endif
>
> (https://src.fedoraproject.org/rpms/supermin/c/61395e3f5a0fdbbea28ec03c6befcf482cb96792?branch=rawhide)
>
> Anyway this could potentially affect any s390x / ppc64le OCaml package
> that contains a binary so it's something to look out for ... For some
> reason dune doesn't seem to be affected.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> nbdkit - Flexible, fast NBD server with plugins
> https://gitlab.com/nbdkit/nbdkit
I encountered that with a couple of packages, ocaml-findlib and
coccinelle. Sorry I missed the others. Yes, stripping those binaries
removes the bytecode payload, leaving only the bytecode interpreter.
I also noticed that dune isn't affected, which is interesting. I
wonder if it is the difference between -output-complete-exe and
-custom. Dune now uses the former instead of the latter.
--
Jerry James
http://www.jamezone.org/
___
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: [rawhide] ICU upgrade to 73.2
On Tue, Jul 11, 2023 at 2:35 PM Frantisek Zatloukal wrote: > On Tue, Jul 11, 2023 at 9:47 PM Jerry James wrote: >> > brltty >> >> This package is also being built in a side tag for the OCaml 5.0.0 >> update, which is already ongoing. Can you wait until the OCaml builds >> are done to build this one? Otherwise, we're going to rebuild this >> poor package over and over to get all of its deps right. > > > Sure, task https://koji.fedoraproject.org/koji/taskinfo?taskID=103239771 > canceled, will wait for ocaml rebuild. Unfortunately, I'd already committed > the bump to the dist-git repo (just release inc), hope that doesn't mind! It looks like we haven't gotten to brltty yet in the OCaml builds. How long do you think it would be before you could merge your side tag? If it won't be long, maybe we should wait for you. CCing Richard Jones, who is actually running the OCaml builds. -- Jerry James http://www.jamezone.org/ ___ 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: [rawhide] ICU upgrade to 73.2
On Tue, Jul 11, 2023 at 3:10 AM Frantisek Zatloukal wrote: > Later today, I'll be starting with rebuilds of packages depending on icu. The > rebuilds will take place in f39-build-side-69764 for all packages returned by > repoquery --whatrequires 'libicu*.so.72()(64bit)' (list cleaned up, converted > to source package names, attached at the end of the message). > > Please, if you're going to make changes in affected packages before the side > tag gets merged, make the build in the said side tag. I expect to merge the > side tag asap with most of the affected packages built and then continue > building things that take longer to build (webkit/libreoffice) later. [snip] > brltty This package is also being built in a side tag for the OCaml 5.0.0 update, which is already ongoing. Can you wait until the OCaml builds are done to build this one? Otherwise, we're going to rebuild this poor package over and over to get all of its deps right. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in August
On Tue, Jul 11, 2023 at 7:07 AM Miro Hrončok wrote: > sbcl green, rdieter About a month ago, I opened a PR to fix this. It looks like the PR was merged, but no build was done. I am taking it upon myself to update sbcl to the next released version (the PR was for 2.3.5, but 2.3.6 has since been released) and do the build. I hope I am not stepping on any toes. > xmvn-connector-ivy mizdebsk The problem appears to be that apache-ivy does not have VFS support, which xmvn-connector-ivy needs. It doesn't have VFS support because apache-commons-vfs was retired. I need apache-commons-vfs back anyway for other reasons, so I have filed a review bug: https://bugzilla.redhat.com/show_bug.cgi?id=023 -- Jerry James https://www.jamezone.org/ ___ 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: Modernize Thread Building Blocks for Fedora 39
On Thu, Jul 6, 2023 at 4:12 AM Jonathan Wakely wrote: > This is a status update for > https://fedoraproject.org/wiki/Changes/F39ModernizeTBB > > The tbb2020.3 compat package has now been added to rawhide: > https://bodhi.fedoraproject.org/updates/FEDORA-2023-15ccd1cedb > > It doesn't include the docs or python modules (you can use the main > tbb package for those). > > The tbb2020.3-devel subpackage conflicts with tbb-devel, as a given > package only needs to build against one or the other, not both. > > Later today I will start submitting pull requests for the packages > which need to switch from BuildRequires: tbb-devel (or similar) to > using tbb2020.3-devel instead. The affected packages are: > > blender > gazebo > opencascade > opensubdiv > usd > > After those packages have been rebuilt against tbb2020.3 I'll create a > side tag and push a new spec file to the 'tbb' package to update it to > version 2021.9.0 (based on the > https://copr.fedorainfracloud.org/coprs/jjames/TBB2021/ package made > by Jerry James). Then the remaining packages that depend on tbb can be > rebuilt against the new tbb in the side tag. I'm very happy to see this happening at last. I know it has been tricky. Thank you for sticking with it. -- Jerry James http://www.jamezone.org/ ___ 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: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On Fri, Jun 30, 2023 at 9:02 AM Petr Viktorin wrote: > The use_tracing was fixed for most code, but still remained in > profiling/tracing support. > I filed a PR for Cython: > https://src.fedoraproject.org/rpms/Cython/pull-request/46 > > (Hoping for a Cython 3 release soon -- things are getting fixed properly > for 3.0, but the stable branch is pretty much on life support now...) Ah great, thank you. > Do you have an example of a package that fails on ob_digit? > Uses of that should be behind CYTHON_USE_PYLONG_INTERNALS which should > be off by default (and probably will stay off until Cython 3.0). I was trying to fix a couple of Paulo's packages, python-cypari2 and python-fpylll. They directly access ob_digit. My attempts to fix them seemed to be stymied by the Cython definition I mentioned, but maybe I just don't know what I'm doing. :-) If you have suggestions on how to approach the fixes for those two packages, I would be very grateful. Regards, -- Jerry James http://www.jamezone.org/ ___ 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
Retiring pvs-sbcl
I intend to retire the pvs-sbcl package soon. First, it depends on sbcl, which has failed to build for so long that it is on the list of packages to be retired in August. (See https://src.fedoraproject.org/rpms/sbcl/pull-request/1.) Second, the current version of pvs-sbcl (7.1) does not build successfully with the latest sbcl version. There has been a lot of git activity since 2020, when 7.1 was released, so I tried building with git HEAD. That is when I discovered that git HEAD now downloads a bunch of Lisp libraries during the build. I could download them in advance and include them as Sources, but ... Third, pvs-sbcl by itself is not useful for why3 (the only Fedora package that has ever required it). There are a bunch of NASA libraries that are necessary for it to be useful. We have never been able to package the NASA libraries due to license issues. (Some years ago, I spearheaded an effort to track down all of the contributors to the NASA libraries and get them to agree to a permissive license. I got quite a few people to sign on, but was never able to reach them all.) For that reason, the why3 package has not required pvs-sbcl for some years now. If any of you formal methods afficionados want to take over maintaining pvs-sbcl, let me know. Otherwise I will retire it next week. I'm starting to feel like my job as a Fedora packager is to kill off software that I once worked on. First XEmacs, now PVS. Sigh. Regards, -- Jerry James http://www.jamezone.org/ ___ 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: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On Tue, Jun 13, 2023 at 6:03 AM Tomas Hrnciar wrote:
> If you'd like to build a package after we already rebuilt it, you should be
> able to build it in the side tag via:
>
> on branch rawhide:
> $ fedpkg build --target=f39-python
> $ koji wait-repo f39-python --build
I'm trying to help by fixing packages I maintain that failed to build
on the first attempt. However, I'm having some issues with Cython
generating incorrect code. The most recent example is the
python-pytest-cython package, which fails because Cython generates
code that accesses the use_tracing field of _PyCFrame. That field was
removed in python 3.12.
There are a couple of other packages that have issues with the
representation of a long object. In python 3.11 and before, we had:
struct _longobject {
PyObject_VAR_HEAD
digit ob_digit[1];
};
In python 3.12, we have:
typedef struct _PyLongValue {
uintptr_t lv_tag; /* Number of digits, sign and flags */
digit ob_digit[1];
} _PyLongValue;
struct _longobject {
PyObject_HEAD
_PyLongValue long_value;
};
The Cython package in the side tag has this in Includes/cpython/longintrepr.pxd:
ctypedef class __builtin__.py_long [object PyLongObject]:
cdef digit* ob_digit
which is incorrect for python 3.12. I think I'm stuck until Cython
has been updated for python 3.12.
--
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: LLVM 17 (System-Wide)
On Tue, Jun 27, 2023 at 5:06 AM Vitaly Zaitsev via devel wrote: > Some package maintainers are too lazy. They won't do anything even if > you inform them in the ML. That's harsh. Package maintainers are mostly volunteers, who spend their free time on the project. If something happens to reduce that free time, their participation also decreases. I myself periodically get so much stuff to do piled on me that I temporarily drop out of Fedora activities, then play catch up when my free time bounces back. Don't assume laziness is the cause. -- Jerry James http://www.jamezone.org/ ___ 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
FontAwesome 6 change merged
It has been 8 days since the FontAwesome 6 Change side tag was created. Some of the packages built into that side tag have since been rebuilt for Rawhide, causing them to break. To fix that breakage, the side tag has been merged into Rawhide. The following PRs have still not been merged, so these packages are now broken in Rawhide. I am happy to merge and/or build the packages in question if the maintainers would like me to do so: https://src.fedoraproject.org/rpms/dogtag-pki/pull-request/5 https://src.fedoraproject.org/rpms/python-f5-sdk/pull-request/1 https://src.fedoraproject.org/rpms/python-QtAwesome/pull-request/2 https://src.fedoraproject.org/rpms/sympa/pull-request/2 https://src.fedoraproject.org/rpms/freeipa/pull-request/15 https://src.fedoraproject.org/rpms/python-streamlink/pull-request/4 If you see any breakage related to the FontAwesome update, let me know. Regards, -- Jerry James http://www.jamezone.org/ ___ 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: Schedule for Thursday's FPC Meeting (2023-04-06 16:00 UTC)
On Wed, Apr 5, 2023 at 7:39 PM James Antill wrote: > If you would like to add something to this agenda, you can: > * Reply to this e-mail > * File a new ticket at: https://pagure.io/packaging-committee > * E-mail me directly > * Bring it up at the end of the meeting, during the open floor topic. Note > that added topics may be deferred until the following meeting. Can you also look at https://pagure.io/packaging-committee/issue/1266 and its accompanying PR https://pagure.io/packaging-committee/pull-request/1265, please? -- Jerry James http://www.jamezone.org/ ___ 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: FontAwesome 6.x inches closer
On Thu, Mar 30, 2023 at 10:09 AM Jonathan Wright wrote: > I just retired python-acme this morning in F38/39. It's now built by the > certbot package. Great, thank you for letting me know. -- Jerry James http://www.jamezone.org/ ___ 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: FontAwesome 6.x inches closer
On Wed, Mar 1, 2023 at 3:28 PM Jerry James wrote: > The maintainers of the packages I am about to mention are BCCed on this email. And that is true of this email as well. > A couple of months ago, I talked about updating the fontawesome-fonts > package to version 6.x. I want to give an update on where things > stand. See https://copr.fedorainfracloud.org/coprs/jjames/FontAwesome6/ > for builds of affected packages. All changes have been checked into > my forks of the affected packages (username "jjames"). Here's a quick > rundown of the changes. The FontAwesome 6 Change proposal was accepted. I have created a side tag, have built both the new backwards compatibility fontawesome4-fonts package and the updated fontawesome-fonts package in it. I will start filing PRs momentarily for the other packages. Package maintainers, until the side tag is merged back into Rawhide, please use the following command to build the affected packages: fedpkg build --target=f39-build-side-65584 As a reminder, these are the packages that will need to be changed and built: - cantata - dogtag-pki - freeipa - ipsilon - python-acme - python-f5-sdk - python-nbclassic - python-networkx - python-pydata-sphinx-theme - python-QtAwesome - python-sphinx_ansible_theme - python-streamlink - python-XStatic-Font-Awesome - R-fontawesome - sympa - texlive Once all builds are complete and the side tag has been merged into Rawhide, the fontawesome5-fonts package will be retired. Let me know if you have any questions or concerns. -- Jerry James http://www.jamezone.org/ ___ 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
Review swaps
Hi all, I am in need of some package reviews, and am happy to swap. First, I think I have finally beaten MuseScore 4.x into good enough shape for Fedora. This has been a months-long process. I need some font reviews: makemusic-finale-fonts: https://bugzilla.redhat.com/show_bug.cgi?id=2152347 edwin-fonts: https://bugzilla.redhat.com/show_bug.cgi?id=2180241 leland-fonts: https://bugzilla.redhat.com/show_bug.cgi?id=2180242 We currently have MuseScore in the mscore package. I have been asked a couple of times to rename the package to musescore, to make it easier for users to discover. Here is a rename review, while simultaneously changing to version 4.0.2, just to make things more complicated: https://bugzilla.redhat.com/show_bug.cgi?id=2180243 I also have a couple of simple python packages that need reviews, but these are lower priority for me than the reviews above. python-accessible-pygments: https://bugzilla.redhat.com/show_bug.cgi?id=2176933 python-pytest-cython: https://bugzilla.redhat.com/show_bug.cgi?id=2173018 Regards, -- Jerry James http://www.jamezone.org/ ___ 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
bugz.fedoraproject.org links
URLs such as https://bugz.fedoraproject.org/ocaml-dune started returning an HTTP 403 Forbidden a few days ago. Is that permanent? I personally find those URLs very useful and have used them a lot in the past. -- Jerry James http://www.jamezone.org/ ___ 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: nodejs broken?
On Wed, Mar 15, 2023 at 11:09 AM Jerry James wrote: > I see the same with a couple of my packages. A look at > https://src.fedoraproject.org/rpms/nodejs suggests that we shouldn't > be using BuildRequires: nodejs-devel anymore, but rather > nodejsXX-devel for an appropriate value of XX. It looks like "20" is > the only currently appropriate value for XX. I am unsure how that is > supposed to work going forward. Unfortunately, that doesn't fix the 2 cases I am looking at, because they use yarnpkg, and installing yarnpkg pulls nodejs and nodejs-libs into the buildroot, not nodejs20 and nodejs20-libs. -- Jerry James http://www.jamezone.org/ ___ 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: nodejs broken?
I see the same with a couple of my packages. A look at https://src.fedoraproject.org/rpms/nodejs suggests that we shouldn't be using BuildRequires: nodejs-devel anymore, but rather nodejsXX-devel for an appropriate value of XX. It looks like "20" is the only currently appropriate value for XX. I am unsure how that is supposed to work going forward. On Wed, Mar 15, 2023 at 10:35 AM Iñaki Ucar wrote: > > Hi, > > RStudio (which depends on nodejs-devel) is FTBFS since the latest > nodejs update. I see this in F37 and F38: > > Error: Transaction test error: > file /usr/lib64/libv8.so.10 conflicts between attempted installs of > nodejs-libs-1:18.14.2-5.fc37.x86_64 and > nodejs20-libs-1:19.7.0-13.fc37.x86_64 > file /usr/lib64/libv8_libbase.so.10 conflicts between attempted > installs of nodejs-libs-1:18.14.2-5.fc37.x86_64 and > nodejs20-libs-1:19.7.0-13.fc37.x86_64 > file /usr/lib64/libv8_libplatform.so.10 conflicts between attempted > installs of nodejs-libs-1:18.14.2-5.fc37.x86_64 and > nodejs20-libs-1:19.7.0-13.fc37.x86_64 > > Best, > -- > Iñaki Úcar > ___ > 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 -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: FontAwesome6 (Self-Contained Change proposal)
On Fri, Mar 10, 2023 at 2:16 PM Matthew Miller wrote: > > Some user-facing applications will be able to display the latest > > versions of the FontAwesome icons, which have undergone a number of > > updates and cleanups to provide a more pleasing look. In addition, > > many new icons have been added in the 5.x and 6.x versions. For > > example, version 6.x contains a Fedora icon, while previous versions > > do not. > > Version 5.x contains an an unauthorized not-so-great single-color hackup of > the "classic" logo. Version 6.x contains an authorized rendition of the > legit current logo. > > Is 6.x backwards compatible with 5? Yes, 6.x is backwards compatible with 5.x. The plan includes retiring the fontawesome5-fonts package, so that unauthorized not-so-great single-color hackup will get the boot as part of this change. -- Jerry James http://www.jamezone.org/ ___ 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: SPDX Statistics - University of Constantinople edition
On Tue, Feb 28, 2023 at 4:33 PM Miro Hrončok wrote: > However, in both cases at least I notice the unrelated change in the diff. In > my worldview, both are chaotic (read: they violate my imaginary commit-purity > O.C.D. rules), but they are not evil (nothing is "hidden"). In the MIT SPDX > license case, the "mixed in" change is a no-change, so when looking at the > diff > we don't notice it, hence I called it "evil". > > Hope that makes sense. No judgement intended, I know people have different > expectations and habits when it comes to commits (and dist-git commits in > particular). I get your point. However, I think what I did is clearly chaotic good. Chaotic neutral would be releasing a new version of a software package that contains both security fixes and new features. Chaotic evil would be releasing a new version of a software package that claims to contain both security fixes and new features, but in fact contains changes that make security worse, and all of the new features are either broken or break old features. :-) Have a good week. Regards, -- Jerry James http://www.jamezone.org/ ___ 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
FontAwesome 6.x inches closer
The maintainers of the packages I am about to mention are BCCed on this email. A couple of months ago, I talked about updating the fontawesome-fonts package to version 6.x. I want to give an update on where things stand. See https://copr.fedorainfracloud.org/coprs/jjames/FontAwesome6/ for builds of affected packages. All changes have been checked into my forks of the affected packages (username "jjames"). Here's a quick rundown of the changes. New packages: - fontawesome4-fonts (a near-identical copy of the current fontawesome-fonts package) - python-accessible-pygments (needed for new python-pydata-sphinx-theme version) Packages with significant changes, including version updates to get upstream changes to the use of FontAwesome fonts: - fontawesome-fonts (update to version 6.3.0) - cantata (update to version 2.5.0) - dogtag-pki - python-f5-sdk - python-nbclassic - python-networkx - python-pydata-sphinx-theme (update to version 0.13.0) - python-QtAwesome (update to version 1.2.2) - python-sphinx_ansible_theme (update to version 0.10.1) - python-XStatic-Font-Awesome (update to version 6.2.1.1) - R-fontawesome - sympa Packages where the only change is to replace this: Requires: fontawesome-fonts with this: Requires: font(fontawesome) - freeipa - ipsilon - python-acme - python-streamlink I did not build these packages in the COPR because the change is so trivial. This makes the dependency get version 4.x both before and after the other changes. Packages that do not need any changes because they already require font(fontawesome): - coq - libgpuarray - libsemigroups - python-BTrees - python-primecountpy - python-sphinx_rtd_theme In addition, texlive is changed by removing these lines from the texlive-fontawesome subpackage: # This is a bit of a lie, but I don't want someone who installs texlive-fontawesome to wonder where their # system fonts are. Requires: fontawesome-fonts I don't see any reason why we should spare people from learning the difference between system and TeX fonts. And anyway, there are lots of other such system/TeX font pairs, and this wasn't done for them. It wasn't even done for the texlive-fontawesome5 subpackage. What remains to be done -- The way the FontAwesome 6.x subpackages are split up seems to be suboptimal. First, nothing in Fedora wants just one of fontawesome-6-brands-font, fontawesome-6-free-fonts, and fontawesome-6-free-solid-fonts. Every user wants all 3. I only split them up this way because I thought the Font Packaging Guidelines indicated that must be done. (See below.) Now that I'm looking back through them again, I'm not sure that is true. I would like to merge these 3 into a single package if the guidelines permit doing so. Second, nothing in Fedora wants just one of fontawesome-fonts and fontawesome-fonts-web. Every user wants both. I split them up this way thinking the split would be helpful. Now I don't think it is, so I will probably throw away the fontawesome-fonts package and move its contents into fontawesome-fonts-web. Comments welcome. Should we run this through the Change process? At first I didn't think so, because I was dealing with a small number of packages. However, the more I have looked, the more cases of bundling I have discovered, so this is turning into a bigger deal. I'm starting to lean towards making this a Change. Opinions? Finally, very few of the packages mentioned above comply with the Font Packaging Guidelines, or at least my reading of them. I have not attempted to fix them, as that would blow this project up by at least an order of magnitude. The current guidelines (https://docs.fedoraproject.org/en-US/packaging-guidelines/FontsPolicy/) are, I am sure, a big improvement over the previous iteration. However, in my opinion, they are not very accessible to people who are not font experts. They are long, complex, and (for me, at least) difficult to understand. It also doesn't appear that either packagers or reviewers are, in general, very familiar with them. We should do something to make them more widely understood, for some definition of "something". I will be away from my Fedora computer for the rest of this week, so I won't be able to actually do anything until next week. However, I should be able to read and respond to email on a mobile device with a depressingly small screen. It also tries to force me to top-post and send HTML email. Sorry about that in advance if it happens. Regards, -- Jerry James http://www.jamezone.org/ ___ 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 r
Re: SPDX Statistics - University of Constantinople edition
On Tue, Feb 28, 2023 at 11:37 AM Miro Hrončok wrote: > On one hand, I think the script should consider commits like this: > > """ > Modernize packaging > > Remove deprecated macros > Verify license is SPDX > Drop Fedora 28 conditionals > """ > > On the other hand, I consider putting "Verified that License tag is valid > SPDX." into a commit with "Use the %gap_arches macro." in the subject chaotic > evil. I don't see how the example above is qualitatively different from the example I posted. Mine was also changing an obsolete usage to a modern one and verifying the license is SPDX. Why do you think the two are different? In any case, as a precaution, I will refrain from playing paladin characters until this issue is resolved. -- Jerry "Insert evil cackle here" James http://www.jamezone.org/ ___ 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: SPDX Statistics - University of Constantinople edition
On Mon, Feb 27, 2023 at 4:23 PM Miroslav Suchý wrote: > https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt > > say: > > gap-pkg-ace warning: valid as old and new and no changelong entry, please > check > > When I check > > https://src.fedoraproject.org/rpms/gap-pkg-ace/blob/rawhide/f/gap-pkg-ace.spec > I see no mention in spec %changelog > and when I check the git-log > https://src.fedoraproject.org/rpms/gap-pkg-ace/commits/rawhide > I see no mention of spdx neither. > > Is it possible that you forgot to git-push? No, the commit is here: https://src.fedoraproject.org/rpms/gap-pkg-ace/c/298f6b5dce052408a6a82eac97bc843fceebc2a3?branch=rawhide So I guess the script only checks the first line of the git commit message, right? I guess I'll have to add a changelog entry, then. -- Jerry James http://www.jamezone.org/ ___ 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: SPDX Statistics - University of Constantinople edition
On Mon, Feb 27, 2023 at 3:35 PM Miroslav Suchý wrote: > List by package maintainers is here > > > https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt That shows some packages under my name, such as gap-pkg-ace, where I pushed git commits mentioning SPDX a couple of weeks ago. Did I do it incorrectly? -- Jerry James http://www.jamezone.org/ ___ 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
