I hope this email finds everyone well. We are currently packaging PyTorch for Fedora and we are actively packaging the dependencies. We’re reaching out to see if anyone is interested in joining the project. If you’re interested in more information, our meeting notes are in a GitHub repo and we have the AI/ML SIG discussion page where we’ve hosted all of our post meeting discussions. We have a WikiPage for our package assignment list if you would like to see what needs packaging or just to see the status of the project. Our next meeting is tomorrow, October 11th at 9AM EST and it’s on the FedoCal under the SIG calendar. All lists are found below. If you’re interested in joining, have any questions, or want to get a calendar invite for our reoccurring meeting, please feel free to email me at kabdo(a)redhat.com or Teng at tema(a)redhat.com.
AI/ML SIG Discussion Page: https://discussion.fedoraproject.org/tag/ai-ml-sig
Meeting Notes: https://github.com/kaitlynabdo/pytorch-fedora-meeting-notes
Packaging Assignment List: https://fedoraproject.org/wiki/SIGs/PyTorch/packagingStatus
This message is realted to:
The final patches for GCC 14 are currently under upstream review and
should land very soon. Earlier, I had received feedback that the larger
community desires just one transition, so we end up with the following
warnings which turn into errors by default:
-Wreturn-mismatch (new, previously part of -Wreturn-types)
-Wdeclaration-missing-parameter-type (new, previously unnamed)
Only the first two were covered in the initial Fedora conversion work.
I've done another round of test builds with an instrumented GCC for all
errors, and the numbers of problematic packages I have today are:
implicit-function-declaration 53 21
implicit-int 2 0
int-conversion 99 33
return-mismatch 13 2
declaration-missing-parameter-type 0 0
incompatible-pointer-types 374 50
(I've updated the change page to describe those diagnostics briefly.)
The numbers don't add up because one package can have multiple issues.
Some of the reported issues are false positives, although the GCC
instrumentation is a bit better than it used to be.
The autoconf column covers packages which are particularly at risk for
silent miscompilation because of incorrect detection of build system
features. This is based on file name heuristics and includes more than
just autoconf proper.
As you can see, the incompatible-pointer-types issues are a bit of a
problem. We fixed over 800 packages during the first round, and now it
looks like we are only two thirds done.
It is unlikely that I will be able to work on all these issues
myself or with help from the people around me. I just suggested to GCC
upstream that we may have to reconsider including this change in the GCC
Consequently, my priorities are as follows:
* Try to resolve the autoconf issues in packages, to reduce the risk of
* Integrate a backport of the GCC 14 changes into the rawhide GCC 13
version (rawhide only, not Fedora 39 or 38). This will allow us
to isolate these issues from GCC 14 issues that typically occur
during the upcoming mass rebuild.
* Produce the final redhat-rpm-config integration, using -fpermissive
for _build_type_safety_c 0, and -Wno-error= options for the higher
type safety levels. This obviously depends on -fpermissive and and
the new warning names becoming available in rawhide, which is another
reason for the GCC 13 backport.
* Come up with a way to resolve the Vala situation, likely by embedded
“#pragma GCC diagnostic” in the generated C source files. Vala is
currently not able to generate type-safe C, and is unlikely that this
going to change soon. (The numbers above do not include packages
which have failures in Vala code only.) In some cases, there is
nothing that can be done about this on the Vala source code side. Not
all of these type errors are harmless, of course, but I don't see a
way to deal with this except by telling GCC to be less picky.
I'm attaching package maintainer lists, generated using the
find-package-maintainers script from fthe
<https://pagure.io/fedora-misc-package-utilities/> repository, for both
the full package set, and the autoconf-impacted package set.
Build logs with results from the instrumentation are available here;
We delete logs from that repository as packages get fixed.
Again, some of these are false positives. The second link at the start
has instructions for a COPR repository if you want to verify things
locally (sadly the Koji build target is currently not in working order).
I'd like to start writing a script to synch users/groups from Fedora IPA
to pagure.io and src.fp.o: both pagure.io and src.fp.o logins are based
on Fedora accounts, but the Pagure user database is only updated when a
user login in Pagure.
That means that by searching for a user or looking group memberships in
Pagure we don't have an updated, real view of what we have in IPA. With
the old FAS system there used to be a synch script provided by
pagure-dist-git plugin, so I plan to use that as the base for a new
synch script from IPA.
However, before digging in how (and if) is possible to add new users
using pagure libraries, I'd like to ask if it would be acceptable to
"copy" user data from one database to another (except passwords, which
remain in IPA only). We will need to pass username, full name, email and
group memberships from IPA to pagure.io/src.fp.o, which is what is done
when a user logs in for the first time.
If that's not acceptable, I think I can just only update group
membership for users already in pagure database.
as the CVE (which was not even a problem with keepass in the first
place) leading to keepass retirement has been resolved in the meantime,
I would like to unretire the package. I have submitted a re-review already:
I'm looking for co-maintainers for nix.
We had a plan to add support for nix to mkosi, but it has been put on ice (*),
so my main motivation and use-case went away. But I prepared a package for nix,
i.e. the big binary that is used to build and manage NixOS systems (**). The
compilation and packaging of the program is one thing, but then some decisions
need to be made about how the package is integrated with the rest of the system:
nix has a whole-system mode and a per-user mode, and a bunch of different
service files… Since I'm not going to use it myself, and I don't know all the
details, I would love to have somebody who is interested in NixOS to help with
that part. There have been a few requests for nix packaging over the years, so I
hope that there might be some interest in this.
Right now the package is available from copr (**), but I'd like to submit it for
review with a comaintainer. I packaged lowdown (***), a required dependency.
Tests are disabled because "rapidtest" dependency is not available.
(*) Mkosi expects an FHS-adhereing system, and nixos is very much about not
doing that, so mkosi would need to have a lot of special-casing for nixos, and
it just doesn't seem worth it.