Spec URL: Attached SRPM URL: TBD Description: The gfs2-utils package contains a number of utilities for creating, mounting, checking, modifying, and correcting any inconsistencies in GFS2 filesystems. Important Note: This is complicated.... so I'm going to be adding to this bug over the next few days. Feel free to comment in the mean time, but not everything is ready for a full review right away. The plan is this: 1. To bring back gfs2-utils as a package in its own right 2. To add a new subpackage to gfs2-utils, gfs2-cluster which will contain the cluster parts of the gfs2 userland infrastructure 3. To drop those items from the pre-existing cluster package (which means dropping the gfs2-utils binary package in its entirety, and the parts of the cman binary package which will move into gfs2-cluster) 4. The new gfs2-utils package will then be built in all versions of Fedora and work alongside the newly adjusted cluster packages The main reason for doing this is that the releases of the GFS2 packages will then be independent from those of the rest of the cluster infrastructure. That means that the GFS2 team can deal with those releases directly, taking some of the load from the cluster team. The only missing item at the moment, is an init script for gfs2-cluster which I'll add to the upstream source shortly. In the mean time, the gfs2-utils spec file will, I hope, not change very much so that is available for review now. The upstream source can be found here: http://git.fedorahosted.org/git/?p=gfs2-utils.git
Created attachment 451033 [details] Draft spec file Hopefully this isn't too far from the final spec file.
Note that the initscript that was mentioned as missing in the opening comment has now been added upstream. So we are getting closer now.
Also a reminder to myself, we'll need to add a conflicts line for cman prior to when gfs_controld is removed from cman, but I need to wait to do that, until I know exactly which version of cman that will be.
Created attachment 454152 [details] Updated spec file Now I know what the versions will be, updated the version info for the package and for the cman dependency. So only a fairly minor change. Once we are sure that we are ready to release, I'll drop a version tag into the git tree which will allow the script to create tar balls of the correct name. Plan is to call this 3.1.0 in order that we are in sync with the rest of the cluster packages. What happens after that doesn't matter so long as we move upwards.
Created attachment 454154 [details] Source RPM Added the source rpm.
spec file needs BuildRequires: libtool
Is that the only issue? Normal practise is to paste the checklist into the bz and check them off as you go through them I think. Let me know about comment #6 and I'll update the spec file.
No. That was just the first issue I spotted. Here is the important rpmlint results: gfs2-utils.src: W: no-version-in-last-changelog Needs a version in the last changelog entry gfs2-utils.src: W: invalid-url Source0: gfs2-utils-3.1.0.tar.gz It wants a URL to go to for the source. I'm not sure if we can ignore this warning, since we are upstream. However the cluster package currently has one.
The source url thing we can ignore according to the instructions. The alternative is to add a comment to describe where the source comes from, which is what I did in this case. My long term plan is to use the script in the gfs2-utils tree to create tar balls and then we can stick them somewhere (kernel.org might be easiest) and that will allow us to replace that with a real url. I don't want to do that until I drop the release tag into the git tree though, which I'll do shortly. I'll try and figure out what the other warning means and sort that out when I next update the spec file.
The only other rmplint warning that wasn't a false positive when I checked was gfs2-utils.src: W: no-version-in-last-changelog which just means you need to add the version to your changelog message. change * Tue Sep 30 2010 Steven Whitehouse <swhiteho> to * Tue Sep 30 2010 Steven Whitehouse <swhiteho> 3.1.0-1 Looking at the scriptlets, I assume you mean to remove the gfs2-cluster service, not cman. %preun -n gfs2-cluster if [ "$1" = 0 ]; then /sbin/service stop gfs2-cluster >/dev/null 2>&1 /sbin/chkconfig --del cman fi
Or you can simply use the fedorahosted release area. The URL is already known for you and even if you haven't actually uploaded a tarball there, you can still update the spec file to point to it. To release there, you simply need to scp the tarball. See how we do it for cluster STABLE3 in make/releases.mk publish target. Your releases would be in https://fedorahosted.org/releases/g/f/gfs2-utils/.... I remember at somepoint, but I might be mistaken, that some of the fedora automatic tool checks, does a URL sanity check to verify that the tarball referenced by the spec file is actually the same as the one in the fedora build cache. I'd recommend to allow that check to run smoothly (aka add the URL as it costs nothing) as a mismatch is source of questions and BZs. Fabio
That's all the issues I found with this package.
Created attachment 455941 [details] Spec file (updated) Three changes: 1. Added version to most recent comment 2. Added BuildRequired: libtool 3. Fixed script to refer to gfs-cluster rather than cman
Created attachment 455943 [details] Source rpm Updated source rpm
Now fixed: http://git.fedorahosted.org/git/?p=gfs2-utils.git;a=commitdiff;h=97368b361627c1a89f7e241297541118018504c9
Oops. Wrong bug. Please ignore comment #15
Note that I've dropped a 3.1.0 tag into the gfs2-utils git tree now. That means that the make-tarball.sh script which I wrote a little while back will now create the release tar ball directly from the git tree. Any further patches checked into the git tree will have to wait for 3.1.1 now. Assuming that Ben is happy with everything now, we are pretty much ready to go I think.
Looks good to me.
Package Change Request ====================== Package Name: gfs2-utils New Branches: f13 f14 Owners: swhiteho, bmarzins, adas, rpeterso, fabbione InitialCC: This is complicated, so let me explain what we want to do here: - There is an already existing (but obsolete) gfs2-utils package which we'd like to revive with the (new) source package to which this bugzilla relates. - There is an already existing package called cluster which builds a number of binary packages including (currently) gfs2-utils and cman We want to: - Use this package to replace the pre-existing gfs2-utils binary package - Use this package to build a new gfs2-cluster binary package which replaces part of the existing cman binary package - Adjust the spec file for the cluster package so that it does not build gfs2-utils at all, and so that the cman package will no longer contain gfs_control, gfs_controld and the respective man page, which will now be part of gfs2-cluster The plan is based upon the first version after the split being version 3.1.0 (that will be the same across both SRPMs in order to avoid confusion). So we need to coordinate with the actions being carried out in the cluster package, in order that both happen at the same time. The reason for the rather complicated split is to allow the gfs2 developers to look after their own packages independent of the remainder of the cluster packages once the split has taken place. To try and sum it up simply, the idea is this: cluster SRPM: gfs2-utils binary package -> removed cman binary package -> gfs_control, gfs_controld & man page removed other binary packages -> continue as before gfs2-utils SRPM: (this bugzilla) gfs2-utils binary package (identical content to cluster SRPMs gfs2-utils binary package) gfs2-cluster binary package (some of the content from old cman package, plus new init script) The cluster maintainer (Fabio) is not quite ready yet to make the change, so this is a heads up on what we want to do so that you can flag up any issues which may arise. Also if there are things which can be set up in the mean time, then I'd like to get them set up sooner rather than later to avoid having too much to do when we do the switch. This package is however ready, and so I want to be certain that we've not got anything else which needs to be done, bar the final switch over from our PoV.
> The cluster maintainer (Fabio) is not quite ready yet to make the change, so > this is a heads up on what we want to do so that you can flag up any issues > which may arise. Also if there are things which can be set up in the mean time, > then I'd like to get them set up sooner rather than later to avoid having too > much to do when we do the switch. > > This package is however ready, and so I want to be certain that we've not got > anything else which needs to be done, bar the final switch over from our PoV. cluster upstream and packages will be ready in approx 2 weeks. I´d strongly recommend to get gfs2-utils srpm/rpm ready and tested in the meantime.
RE: comment #20 It is ready now.
adas appears not to be a Fedora Packager. Could you please fix the Change Request?
Package Change Request ====================== Package Name: gfs2-utils New Branches: f13 f14 Owners: swhiteho, bmarzins, rpeterso, fabbione InitialCC: See comment #19 for additional details. RE: comment #22. I've removed Abhi from the list for now. Once the package is created I'll arrange for him to have access to it. Let me know if there are any other issues.
This package already exists. I have 'unretired' it in devel/rawhide. Please reset the fedora-cvs flag if you need anything further.
Package Change Request ====================== Package Name: gfs2-utils New Branches: f13 f14 Owners: swhiteho, bmarzins, rpeterso, fabbione InitialCC: RE: comment #24. The branches for f-13 and f-14 don't appear to exist. I assume that you still need to create them.... or do I do that? Also I want to confirm exactly what the final step needs to be in order to get gfs2-utils building again in all branches. I want to do as much as possible to get things ready without actually releasing anything at this stage. So if I add back in the spec file and upload the sources to the lockaside cache, etc., can I be 100% sure that nothing will get released until we are ready to synchronize with the cluster team? Sorry its a long question, but we need to be certain. Can I assume that nothing will get released until the dead.package file is removed for example?
Ah, the branches existed in pkgdb, but were not on the git server. I have fixed that. Nothing will be released until you remove the dead.package, import a package and build it (and push it as an update for stable releases).
To keep everybody uptodate, Fabio is currently building all the cluster packages (including this one) to test, and if successful, we'll be "going live" with the new package very shortly.
Hi Kevin, I am having problems to build this package. It appears that not all the work in the backend has been done. 2638831 build (dist-rawhide, /gfs2-utils:c4f049f791f862220b28e1baff35a9f7446539fe): open (x86-19.phx2.fedoraproject.org) -> FAILED: BuildError: package gfs2-utils is blocked for tag dist-f15 Can you please fix it and make sure to unlock it for all stable releases too? f13/f14. No plans to backport to f12 before EOL. Thanks Fabio
Please try again now?
It appears Steven did build rawhide and f13. I am unable to test f14 myself as I am getting some other errors. Steven will figure that out. Thanks Fabio
I'm not sure why the fedora-cvs flag is still set, but I don't see unprocessed request, so I'll clear the flag. If there is something left to be done, please explain.
This seems to be all ok now and the updates have all been pushed to f13/f14, so I think we can close this now unless anybody has any objections.