Created attachment 292559 [details, diff] Diff of ebuilds There is a new version of the IBM Tivoli Storage Manager Backup-Archive Client, version 6.3.0.0. The atached patch changes the ebuild accordingly. Note that the new version appears to be 64bit only, so the old version should probably stay around a while longer. Client did install on my system, and at least basic functionality has been tested: the command line backups seem to work as they used to. No promises on anything more advanced, or anything at all, come to that, though. Note that the ebuild generates a lot of QA warnings. The package being closed source, I doubt there is much we can do about those, though.
Created attachment 299841 [details] tsm-6.3.0.0-r1 An upgraded version of the ebuild. All dependencies have been checked and QA problems flagged. The only annoyance left is that you need to run /sbin/ldconfig manually. (There is an "einfo" for it in the ebuild.) I have been using this in a new server for some time.
I am unfamiliar with this app, is this latest version? Is it still amd64 only? Thanks for the info
(In reply to comment #2) > I am unfamiliar with this app, is this latest version? ftp://ftp.software.ibm.com/storage/tivoli-storage-management/patches/client/v6r3/Linux/LinuxX86/BA/v630/ has a patch release, 6.3.0.5. Pages like http://www-01.ibm.com/support/docview.wss?uid=swg21239415 don't link to those files, but still refer to the 6.3.0.0 download path inside maintenance. ftp://ftp.software.ibm.com/storage/tivoli-storage-management/.message describes the content of the different trees as follows: maintenance - contains ptf code for Clients and Servers patches - contains fixtest code for Clients and Servers Sounds to me like we'd only ever want to roll ebuilds from the patches tree for ~ARCH, never for stable ARCH. It would be easy to have the ebuild decide the path based on the 4th version component: if that is 0, use maintenance, otherwise use patches. That way, a simple rename would be enough for users to grab such a fixtest. Do you think that approach would make sense? By the way, we probably should set HOMEPAGE=http://www.ibm.com/software/tivoli/products/storage-mgr/ as this appears to be the most suitable page describing this product. > Is it still amd64 only? The primary tarball contains only *.x86_64.rpm files, so there appears to be no support for 32bit x86. There are tarballs for PPC and zSeries in the Linux directory, though. Haven't looked at these so far. http://www.ibm.com/support/docview.wss?uid=swg21052223 also states that 6.3 only supports amd64; 32bit x86 users should probably be using 6.2 I guess. Latest tsm in portage is 6.2.2.0-r1; latest upstream 6.2.* is 6.2.4.1: ftp://ftp.software.ibm.com/storage/tivoli-storage-management/patches/client/v6r2/Linux/LinuxX86/v624/
(In reply to comment #3) > (In reply to comment #2) > > I am unfamiliar with this app, is this latest version? > > ftp://ftp.software.ibm.com/storage/tivoli-storage-management/patches/client/ > v6r3/Linux/LinuxX86/BA/v630/ has a patch release, 6.3.0.5. Pages like > http://www-01.ibm.com/support/docview.wss?uid=swg21239415 don't link to > those files, but still refer to the 6.3.0.0 download path inside > maintenance. > ftp://ftp.software.ibm.com/storage/tivoli-storage-management/.message > describes the content of the different trees as follows: > > maintenance - contains ptf code for Clients and Servers > patches - contains fixtest code for Clients and Servers > > Sounds to me like we'd only ever want to roll ebuilds from the patches tree > for ~ARCH, never for stable ARCH. It would be easy to have the ebuild decide > the path based on the 4th version component: if that is 0, use maintenance, > otherwise use patches. That way, a simple rename would be enough for users > to grab such a fixtest. Do you think that approach would make sense? > > By the way, we probably should set > HOMEPAGE=http://www.ibm.com/software/tivoli/products/storage-mgr/ > as this appears to be the most suitable page describing this product. > The idea would be to always use "patches" tree > > Is it still amd64 only? > > The primary tarball contains only *.x86_64.rpm files, so there appears to be > no support for 32bit x86. There are tarballs for PPC and zSeries in the > Linux directory, though. Haven't looked at these so far. > > http://www.ibm.com/support/docview.wss?uid=swg21052223 also states that 6.3 > only supports amd64; 32bit x86 users should probably be using 6.2 I guess. > Latest tsm in portage is 6.2.2.0-r1; latest upstream 6.2.* is 6.2.4.1: > ftp://ftp.software.ibm.com/storage/tivoli-storage-management/patches/client/ > v6r2/Linux/LinuxX86/v624/ Looks like 6.2 tree is still maintained, are you sure 6.2.x are not tagged as "stable" releases and 6.3.x as "testing" or "unstable"?
(In reply to comment #4) > The idea would be to always use "patches" tree I assume that when 6.3.1.0 arrives, it will appear in the maintenance tree only, and the patches tree will receive a newer update only when 6.3.1.1 comes along. So you should choose the tree based on the last version component, I believe. > Looks like 6.2 tree is still maintained, are you sure 6.2.x are not tagged > as "stable" releases and 6.3.x as "testing" or "unstable"? I'm not 100% sure about anything, but my local tsm server admins told me they had assigned storage on a 6.3 server for me, so they would advise I use a 6.3 client as well. As this is a pretty large setup, I'm confident they are not running versions not ready for production use. Users with access to a 6.2 server as well as users on a 32bit system might both be happy about a 6.2 client, though.
(In reply to comment #5) > (In reply to comment #4) > > The idea would be to always use "patches" tree > > I assume that when 6.3.1.0 arrives, it will appear in the maintenance tree > only, and the patches tree will receive a newer update only when 6.3.1.1 > comes along. So you should choose the tree based on the last version > component, I believe. If that is the case, of course :-) > > > Looks like 6.2 tree is still maintained, are you sure 6.2.x are not tagged > > as "stable" releases and 6.3.x as "testing" or "unstable"? > > I'm not 100% sure about anything, but my local tsm server admins told me > they had assigned storage on a 6.3 server for me, so they would advise I use > a 6.3 client as well. As this is a pretty large setup, I'm confident they > are not running versions not ready for production use. Users with access to > a 6.2 server as well as users on a 32bit system might both be happy about a > 6.2 client, though. Per http://en.wikipedia.org/wiki/IBM_Tivoli_Storage_Manager looks like 6.3 is "stable" also then, we would need to bump both versions This would be my plan: - As this package is orphan and no dev wants to maintain it I could be your proxy maintainer, that way, you could contribute to get it fixed and bumped and I would be your committer. This is explained a bit better at: http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml In this case, I think I could be your proxy maintainer directly instead of relying on proxy-maint but, if for some reason you prefer to be proxied by proxy-maint team, ok :) What do you think? I would start point would be to attach updated ebuilds for 6.2.x and 6.3.x to let me review them and commit if ok (or fix them, explain the changes and commit anyway)
Also, both bumps should include fix from bug 375041
(In reply to comment #6) > This would be my plan: > - As this package is orphan and no dev wants to maintain it I could be your > proxy maintainer, that way, you could contribute to get it fixed and bumped > and I would be your committer. This is explained a bit better at: > http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml Generally fine with me, although I'll need some time to work on those ebuilds. In particular, I'd like to understand this ldconfig stuff Tero has been writing about in comment #1. If you'll proxy my maintainership, I take it that either you or the bug wranglers would make sure to cc new tsm bug reports to me.
For this cases when I am the proxy maintainer I usually set metadata to get bugs assigned to maintainer (you) and proxy-maintainer CCed (me)
Were you able to look at this? ;)
(In reply to comment #10) > Were you able to look at this? ;) In part: I've got a merged version, hopefully containing the best from both my own ebuild and the one Tero attached in comment #1. The thing I'm least clear about, though, is this ldconfig thing he wrote about. The fact that there apparently isn't a single ebuild in all of the official portage tree that has to worry about the user calling ldconfig makes me believe that tsm shouldn't have to, either. I believe that both env-update and ldconfig are run automatically by emerge, so the user shouldn't have to act at all, but I'd like to verify that fact before completing the ebuild. Do you have any info on that?
But, have you seen any problem when not re-running ldconfig manually? If not, I think we could go without that ugly stuff
(In reply to comment #12) > But, have you seen any problem when not re-running ldconfig manually? If > not, I think we could go without that ugly stuff Any news here?
ping
Created attachment 311647 [details] Reworked ebuild Sorry it took me so long, but here are ebuilds for both tsm-6.3.0.0 and tsm-6.3.0.5. Modifications since my last attachments: * Merged my own ebuild and the one from Tero Pelander from comment #1 * Fixed broken symlinks for libgpfs.so libdmapi.so; it might be that these were the real reason why Taro had to use ldconfig but I didn't have to before * Addressed bug 375041 (and thus comment #7) in a very conservative way, making /var/log/tsm not group-writable but only the known files in that directory * Added new USE flags to metadata.xml * Implemented support for patchlevel versions as per comment #5 * Included full version number in messages files, to avoid name conflicts due to different paths as well as due to upstream changing files without renaming The attached file is a shell script which will generate the files. You can look at the plain text content of the contained files in your browser, and still unpack everything from a single downloaded file. The script will fail if there already is an app-backup directory, so nothing will be overwritten. Is this method of bundling files all right for you, or would you rather I attach several files or create a tarball or something like this? I haven't tackled 6.2.x yet, but I'll feel better to have 6.3.x on the way (i.e. attached here) before I start working on that one.
Well, I won't be able to check them today. For the next time, attaching files in a tarball or separately is enough (needs less work from you and makes checking easier ;))
+*tsm-6.3.0.5 (14 May 2012) +*tsm-6.3.0.0 (14 May 2012) + + 14 May 2012; Pacho Ramos <pacho@gentoo.org> +tsm-6.3.0.0.ebuild, + +tsm-6.3.0.5.ebuild, files/dsmc.conf.d, files/dsmc.init.d, + files/dsmcad.init.d, files/tsm.logrotate, metadata.xml, tsm-6.2.2.0-r1.ebuild: + Version bump (#390581) that also fixes logrotate config file (#375041), thanks + a lot to Martin von Gagern that also becomes maintainer with me as proxy. +
