Thank you everyone for testing!!

@besser82... It is always good to get your testing in!!

Thanks everyone for the quick testing!!!

Correct me if I'm wrong... Your task is to make sure packages that are in Fedora are stable. In the past you've done an excellent job! Recently and over the years you have found issues with a number my packages and I have come to depend on your testing to make sure my testing is valid (thank you).

But I don't think it in your task to criticize packages because they don't look like the packages you maintain. If you have a problem with how a package is being maintained... open up a bz. That is the path that should be used.

Stopping a stable package from fixing bugs just because you don't like the way it look... Is not right... IMHO.

But, because this is an RC of the next version, it is actually 6.13-rc5. I've been using this type of versioning on all my packages for many years and it was never a problem. With Fedora or Upstream. I would prefer to continue the versioning I have established over the years. Fantastic! You should be able to version your packages as you see appropriate.... But that does not mean it is appropriate all packages.

Take a look at the changelog for the initial commit for libtirpc (Fri Aug 4 2006) and I've never had a problem with versioning until now.... That has got to say something

Again... lets move on.

The way I'm versioning the package is not locked in 1.3.6-rc1 if the next package release adds a new interface or feature The versioning can to from 1.3.5-rc5 to 1.4.1... which has happen in the passed.

At the end of the day this is a nit... IMHO The stability of the package is much more important than what it the package is called.

Also note the word "Guidelines" in the link you pointed out. Package maintainers have been able to version their packages as they see appropriate. So lets move on so libtirpc will be able to compile with the new gcc-15 compiler.

This is an RC for 1.3.7, not for 1.3.6, right? I think this was discussed before. Yes.

It would be like Linus calling current kernel RC 6.12-RC5. But, because this is an RC of the next version, it is actually 6.13-rc5. I've been using this type of versioning on all my packages for many years and it was never a problem. With Fedora or Upstream. I would prefer to continue the versioning I have established over the years.

Is how to version rc releases documented anywhere?

Package version does not match the version propagated in this update. The package version is libtirpc-1.3.6-1.rc3 which is the version of this update.

What am I missing?

40$ cat /etc/exports

/home *.home.dicksonnet.net(rw,s2sc)

/home *.home.dicksonnet.net(rw)

/home (rw,sec=sys:krb5:krb5i:krb5p) /tmp (rw,fsid=666,all_squash) /home/foo 127.0.0.0/24(rw) /home/bar 127.0.0.0/24(rw) f40$ fg su (wd: ~) f40# systemctl restart nfs-server f40# systemctl status nfs-server * nfs-server.service - NFS server and services Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; preset: disabled) Drop-In: /usr/lib/systemd/system/service.d -10-timeout-abort.conf /run/systemd/generator/nfs-server.service.d-order-with-mounts.conf Active: active (exited) since Mon 2024-11-25 05:33:32 EST; 20s ago Docs: man:rpc.nfsd(8) man:exportfs(8) Process: 48961 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS) Process: 48962 ExecStart=/bin/sh -c /usr/sbin/nfsdctl autostart || /usr/sbin/rpc.nfsd (co> Process: 48983 ExecStart=/bin/sh -c if systemctl -q is-active gssproxy; then systemctl re> Main PID: 48983 (code=exited, status=0/SUCCESS) CPU: 20ms

Nov 25 05:33:32 f40.home.dicksonnet.net systemd[1]: Starting nfs-server.service - NFS server > Nov 25 05:33:32 f40.home.dicksonnet.net systemd[1]: Finished nfs-server.service - NFS server >

What do I need to do to reproduce this?

I can not reproduce this regression in either rawhide, f41, or f40. Can you please explain the tests you are running?

This update has been unpushed.

It appears the problem is with libtirpc-1.3.6-0.rc1...

If you downgrade to libtirpc-1.3.6-0 the problem should go away... That's what I'm seeing can anybody else verify?

Here is a libtirpc scratch build that fixes the NVR and removes the rc1 patch.

https://koji.fedoraproject.org/koji/taskinfo?taskID=125816548

Could please give this build a try, since I'm not able to reproduce the crash... tia!!

I am not 100% sure whether it's just nfs-utils package that is broken or both it and libtirpc. In any event, reverting both to > the previous version made NFS server work again. New packages are dumping core.

What is dumping core and when is it happening... Can you supply the core so it can be examined?

UNIT LOAD ACTIVE SUB DESCRIPTION > ● nfs-mountd.service loaded failed failed NFS Mount Daemon ● rpc-statd.service > loaded failed failed NFS status monitor for NFSv2/3 lockin> ● rpcbind.service loaded failed failed RPC Bind > ● rpcbind.socket loaded failed failed RPCbind Server Activation Socket

Were are these failures coming from and I do I reproduce them?

The rpm version disagrees with the libtirpc version that is supposed to be in this update (1.3.6-0.rc1.fc41 versus libtirpc-1-3-7-rc1, respectively), and predates the rpm version that it is supposed to supersede, 1.3.6-0.fc41.

The latest upstream tag is libtirpc-1-3-7-rc1 and the latest version is 1.3.6-0.rc1... My apologies but I don't see the problem.

what failed?

To make it a 1.3.4 I would have to make a new release... 1.3.4.rc3 means 1.3.4 is not released... aka the rc2...

@besser82 are good with this??

Updated to the latest upstream RC release: libtirpc-1-3-4-rc2 mean I update to latest upstream RC (aka upstream tag)

The NVR is 1.3.3-1.rc2 increased from 1.3.3-1.rc1 which is fine