FEDORA-2026-9127454743

Yes.. %ghost did work! A new updates for rawhide and Fedora 44 are on the way... Thanks!!!

< Maybe the right solution is to define those 10-nfsv3.conf and 10-nfsv4.conf files as %config(missingok) ? What do you think?

Than does not seem to work....

-%attr(0644,root,root) %config(noreplace) %{_datadir}/nfs-utils/nfsmount.conf.d/10-nfsv3.conf +%attr(0644,root,root) %config(missingok) %{_datadir}/nfs-utils/nfsmount.conf.d/10-nfsv3.conf %config(noreplace) %{_sysconfdir}/nfsmount.conf.d/10-nfsv3.conf %{_sbindir}/rpc.statd %{_sbindir}/sm-notify @@ -455,7 +455,7 @@ rm -f %{_sysconfdir}/nfsmount.conf.d/10-nfsv4.conf %files -n nfsv4-client-utils %dir %attr(555, root, root) %{_sharedstatedir}/nfs/rpc_pipefs %config(noreplace) %{_sysconfdir}/request-key.d/id_resolver.conf -%attr(0644,root,root) %config(noreplace) %{_datadir}/nfs-utils/nfsmount.conf.d/10-nfsv4.conf +%attr(0644,root,root) %config(missingok) %{_datadir}/nfs-utils/nfsmount.conf.d/10-nfsv4.conf %config(noreplace) %{_sysconfdir}/nfsmount.conf.d/10-nfsv4.conf

$ sudo rpm -Va

missing c /etc/nfsmount.conf.d/10-nfsv4.conf missing c /etc/nfsmount.conf.d/10-nfsv3.conf

If the nfs-client-utils package supports both v3 and v4 why those nfsv3-client-utils and nfsv4-client-utils are also installed? Yes.... nfs-client-utils is dependent on both nfsv3-client-utils and nfsv4-client-utils

It sounds like they should not be installed all together but only one of them, i.e. when both v3 and v4 are needed only nfs-client-utils should be installed, when only v3 is needed only nfsv3-client-utils should be installed and when only v4 is needed only nfsv4-client-utils should be installed. This should resolve issues reported by sudo rpm -Va True... nfs-client-utils is just a wrapper for both v3 and v4 rpms... We thought that was the cleanest way to do the break up...

It appears I'm not seeing the problem you are seeing: $ sudo rpm -Va /etc/nfsmount.conf.d $

Why those two config files are missing? Those files are used when only a nfsv3-client-utils or nfsv4-client-utils rpms are installed to make the default version either v3 or v4.

They are removed when nfs-client-utils (supporting both v3 and v4) and when nfs-utils (supporting both the client and server) is installed.

If there is a better way to handle things like this please let me know.

Also, I don't remember such an issue in the previously used Fedora 43. You are correct... Fedora 44 is the first release where the clients and server were split up.

Thank you for your time and effort!

@plumlis ^^^

Can someone test this scratch build [1] to see if the problem is fixed?

We (upstream and I) were not able to reproduce this problem

tia!

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=143290490

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?