Hide Forgot
Spec URL: http://www.grid.tsl.uu.se/review/lfc.spec SRPM URL: http://www.grid.tsl.uu.se/review/lfc-1.7.3.1-1.fc11.src.rpm Description: The LCG File Catalog (LFC) keeps track of the locations of the physical replicas of the logical files in a distributed storage system
Hi, Question: There is this lfc building mysql variant and Bug #531252 building a postgres variant. Both look to be build from the same source file? Is it possible not to merge these two packages?
rpmlint errors. lfc-mysql.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/lfcdaemon I've not looked at the file at the logrotate file at all. Also it seems not to like "backend" as not being a en_US word. Hyphenate I guess: lfc-mysql.x86_64: W: spelling-error-in-summary en_US backend Steve
1) # rpm -Uvh lfc-1.7.3.1-1.fc13.x86_64.rpm error: Failed dependencies: liblcgdm.so.1()(64bit) is needed by lfc-1.7.3.1-1.fc13.x86_64 which is course provided by lcgdm-1.7.3.1-1.fc13.x86_64.rpm it seems to be normal in these case to explicitly require lcgdb = %{version}-%{release} where the provides comes from one of the sub packages so as not to end up with mixed versions of package. similar for lfc-mysql as well. 2) # /etc/init.d/lfc-mysql start Starting lfcdaemon: FAILED : config file /etc/NSCONFIG empty So this file should probably be there as an example or something? I guess they come from these files which are apparently duplicated. # cat /usr/lib64/lfc-mysql/NSCONFIG.templ <username>/<password>@<host> [root@rawhide x86_64]# cat /usr/share/lfc/NSCONFIG.templ <username>/<password>@<host> 3) The INSTALL-server-mysql is rather misleading to this RPM installation. 4) A quick read of the init.d script has /etc/grid-security/$LFCUSER/lfccert.pem so that directory should probably exist. 5) The same LICENSE file looks to be duplicated in both lfc and lfc-mysql 6) I'm guessing a schema or at least a database has to be created? Maybe a README.Fedora?
Update: Spec URL: http://www.grid.tsl.uu.se/review/lfc.spec SRPM URL: http://www.grid.tsl.uu.se/review/lfc-1.7.3.1-4.fc12.src.rpm (In reply to comment #1) > Hi, > > Question: There is this lfc building mysql variant and Bug #531252 > building a postgres variant. > > Both look to be build from the same source file? > > Is it possible not to merge these two packages? Actually there are 4 packages building from the same tarfile: - lfc (bug #531252 - this one) - lfc-postgres (bug #531254) - dpm (bug #531256) - dpm-postgres (bug #531258) Unfortunately there is no sane way to build all this at the same time in the same source tree. The configure options for building LFC and DPM are mutually exclusive. The same is true for building the servers with mysql, postgres (or oracle) support. The oracle support we can't build for Fedora anyway since the oracle client libraries are not free - which is kind of fortunate since otherwise there would be 6 package. If all the software were to be built in the same source RPM this source RPM would have to untar the source tarfile 4 times so that the build directory had 4 copies of the source tree, then apply the patches 4 times (once in each of the source trees), run configure 4 times with different options in each of the source trees, run make and make install 4 times. It would be a mess. Splitting it into 4 separate source RPMs seemed to be a much better way to do it to me. Each of these is more or less standard with setup, configure, make, make install. (In reply to comment #2) > rpmlint errors. > lfc-mysql.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/lfcdaemon > > I've not looked at the file at the logrotate file at all. The logrotate files are handled by alternatives so that there are not two copies of them installed in /etc/logrotate.d if you install both the mysql and postgres version of the services. The name of the symlink installed by the alternatives is the same for both packages and both packages own this symlink as a %ghost, as they should. However, since the name of this symlink must be the same for both packages it can not have the same name as the package, which is why rpmlint finds it "incoherent". > Also it seems not to like "backend" as not being a en_US word. Hyphenate > I guess: > > lfc-mysql.x86_64: W: spelling-error-in-summary en_US backend I don't get this complaint with my version of rpmlint. (In reply to comment #3) > 1) # rpm -Uvh lfc-1.7.3.1-1.fc13.x86_64.rpm > error: Failed dependencies: > liblcgdm.so.1()(64bit) is needed by lfc-1.7.3.1-1.fc13.x86_64 > > which is course provided by lcgdm-1.7.3.1-1.fc13.x86_64.rpm > it seems to be normal in these case to explicitly require lcgdb = > %{version}-%{release} where the provides comes from one of the sub packages so > as not to end up with mixed versions of package. > > similar for lfc-mysql as well. Since the choice of building liblcgdm together with the LFC or the DPM is arbitrary, the Requires should not depend on this choice, and since having %{version}-%{release} Requires across source RPMs is a bad idea ... The same arbitrariness is true for building liblfc together with lfc-mysql or lfc-postgres. > 2) # /etc/init.d/lfc-mysql start > Starting lfcdaemon: FAILED : config file /etc/NSCONFIG empty > > So this file should probably be there as an example or something? > > I guess they come from these files which are apparently duplicated. > > # cat /usr/lib64/lfc-mysql/NSCONFIG.templ > <username>/<password>@<host> > [root@rawhide x86_64]# cat /usr/share/lfc/NSCONFIG.templ > <username>/<password>@<host> The duplication is due to the alternatives handling. The installed file is /usr/lib64/lfc-mysql/NSCONFIG.templ, and the symlink created by alternatives is /usr/share/lfc/NSCONFIG.templ. The instructions for creating the /etc/NSCONFIG file is now in the README.Fedora file (see below). > 3) The INSTALL-server-mysql is rather misleading to this RPM installation. Removed - replaced with a README.Fedora (see below). > 4) A quick read of the init.d script has > /etc/grid-security/$LFCUSER/lfccert.pem > so that directory should probably exist. Directory added. > 5) The same LICENSE file looks to be duplicated in both lfc and lfc-mysql Yes, this is again due to making the package content not depend on arbitrary choices about what parts to build in which source RPM. Since the mysql-postgres package should have the license file since it is built from a separate rpm it doesn't make sense for lfc-mysql not to have it since the choice about which flavour of the server to build in the main package is arbitrary. > 6) I'm guessing a schema or at least a database has to be created? > Maybe a README.Fedora? README.Fedora added.
Concerning the 1 or 4 my feeling is that your method you describe of 4 * (unpacks, patch, .... build, installs) is probably better in the long run. With the exception of the configure stage it is a series of loops(?). More of a pain now but better for future when you are updating the package. >Since the choice of building liblcgdm together with the LFC or the DPM is >arbitrary, the Requires should not depend on this choice, and since having >%{version}-%{release} Requires across source RPMs is a bad idea ... It's a bad idea normally but in this case its the same .tgz and so all the binary packages are essentially sub-packages to the binary end user. Certainly the two .src.rpms should/would be released together if they contain the same upstream update anyway. Obviously doing the loop avoids the situation. Also the lib you are building against is not the same instance as the one that this is then ran against. Its a private lib in the build. I was looking for precedents of two packages starting life with the same source. There are 66 tar.gz, .tgz or .bz2s in more than one rawhide package so they do exist but inspecting the list only these mostly probably for other reasons, e.g including private libs for some reason, but there are some that look similar to this one. e.g. //Python-2.6.4.tar.bz2 in python-0:2.6.4-3.fc13.src and //Python-2.6.4.tar.bz2 in python-docs-0:2.6.4-2.fc13.src There are certainly precedents for the multi build option, e.g one of mine ndoutils. Writing this really convinces me one package is the way to go. Lastly on a separate note rather than say /etc/init.d/lfc-mysql should/could it be /etc/init.d/lfc and an ghost and alternative to lfc-mysql , -postgres instances. Would be consistent with the other files managed under alternatives. Is it possible to make the init.d script db independent and avoid the situation completely?
Created attachment 377341 [details] Multiple sources in .src.rpms For academic purposes the list of duplicate source files in .src.rpms.
(In reply to comment #5) > Also the lib you are building against is not the same instance as the > one that this is then ran against. Its a private lib in the build. No, I do not build libraries multiple times. E.g. liblcgdm is only built by the lfc SRPM, the other three has the lcgdm-devel as a build dependency. > Lastly on a separate note rather than say > /etc/init.d/lfc-mysql > should/could it be > /etc/init.d/lfc > > and an ghost and alternative to lfc-mysql , -postgres instances. Would > be consistent with the other files managed under alternatives. > Is it possible to make the init.d script db independent and avoid the > situation completely? No, the alternatives in Fedora has a --initscript option for this purpose. These initscripts should however not themselves be handled by alternatives, and must have different names for different altenatives. The alternatives system makes sure that only one of the alternative's initscript is active at the same time.
(In reply to comment #5) > Concerning the 1 or 4 my feeling is that your method you describe of > 4 * (unpacks, patch, .... build, installs) is probably better > in the long run. > > With the exception of the configure stage it is a series of loops(?). > More of a pain now but better for future when you are updating the > package. OK, here is an attempt to build everything in the same SRPM: Spec URL: http://www.grid.tsl.uu.se/review/lcgdm.spec SRPM URL: http://www.grid.tsl.uu.se/review/lcgdm-1.7.3.1-5.fc12.src.rpm It is quite a long specfile, and it creates 28 binary packages. It is not as messy as I feared. One advantage of this approach would be that there is only need for one review and not four.
Won't be able to look at this for nearly a month to un-assigning. Steve
Updated to new upstream version: Spec URL: http://www.grid.tsl.uu.se/review/lcgdm.spec SRPM URL: http://www.grid.tsl.uu.se/review/lcgdm-1.7.4.1-1.fc12.src.rpm
Looking at this now again. Having some problems using the lfc commands: e.g. $ lfc-ls prod-lfc-shared-central.cern.ch:/grid/dteam send2nsd: NS002 - send error : client_establish_context: The server had a problem while authenticating our connection prod-lfc-shared-central.cern.ch:/grid/dteam: Could not secure the connection There are some env variables to add debugging output to this but I forget what they are. I've a correct proxy and also the openssl 1.0 version of the CAs installed. will continue to look at things anyway.
Given diff /etc/lfc-postgres/lfcdaemon.logrotate /etc/lfc-mysql/lfcdaemon.logrotate shows they are the same having an alternative between them seems a bit pointless but then of course I realise there is the problem of where you put it. Perhaps a -common package or something. Also it would remove the, all be it false positive, rpmlint ERROR. lfc-mysql.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/lfcdaemon Steve
In the README change: mysql> grant all on cns_db.* to <user>@localhost identified by <password>; to mysql> grant all on cns_db.* to <user>@localhost identified by '<password>';
Related to comment #12 I think the /etc/NSCONFIG should really be present and owned especially given it is in /etc/ It could go in lfc-common package.
Hi Mattias, 1) Can you submit a bug for # rpmlint dpm dpm.x86_64: W: shared-lib-calls-exit /usr/lib64/libdpm.so.1.7.4 exit.5 1 packages and 0 specfiles checked; 0 errors, 1 warnings. 2) Request only: Given there are two different versions of rf* commands out there any chance these ones could become of managed by alternatives key of rfio so as to exist with. > rpm -ql castor-rfio-client /usr/bin/rfcat /usr/bin/rfchmod /usr/bin/rfcp /usr/bin/rfdir /usr/bin/rfmkdir /usr/bin/rfrename /usr/bin/rfrm /usr/bin/rfstat and man pages. Obviously castor-rfio does not exist in Fedora but it might one day. It certainly does here of course. 3) I realise this is an upstream thing but both lfc and dpm-nameserver use a database called cns_db by default. If possible/easy could one be changed. 4) Finally same comments for dpm and lfc about the use of a -common package for each with configuration files to avoid things like. # rpm -qf /etc/DPMCONFIG file /etc/DPMCONFIG is not owned by any package Other than these I've run out of things to look for at the moment. Steve
(In reply to comment #11) > Looking at this now again. > > Having some problems using the lfc commands: e.g. > > $ lfc-ls prod-lfc-shared-central.cern.ch:/grid/dteam > send2nsd: NS002 - send error : client_establish_context: The server had a > problem while authenticating our connection > prod-lfc-shared-central.cern.ch:/grid/dteam: Could not secure the connection > > There are some env variables to add debugging output to this but > I forget what they are. > > I've a correct proxy and also the openssl 1.0 version of the CAs installed. > > will continue to look at things anyway. The authentication problem is a known issue. It is due to the current globus-gssapi-gsi package not working correctly with openssl 1.0.0. These issues have been fixed in today's build of globus-gssapi-gsi in koji (globus-gssapi-gsi-7.0-2). So please use this version if you are on a Fedora release that uses openssl 1.0.0. [ellert@ellert ~]$ rpm -q lfc-client lfc-client-1.7.3.1-4.fc12.x86_64 [ellert@ellert ~]$ rpm -q globus-gssapi-gsi globus-gssapi-gsi-7.0-2.fc12.x86_64 [ellert@ellert ~]$ lfc-ls lfc1.ndgf.org:/grid atlas ops.ndgf.org The globus-gssapi-gsi-7.0-2 is part of the big update to Globus Toolkit 5. This transition has been completed for the existing Globus packages in F13, with the exception of globus-gridftp-server-control where the new version depends on the new globus-xio-pipe-driver package submitted for review. For F11, F12 and EPEL the GT5 update has been imported to CVS and most of the packages have been built, but some of the builds involves requesting and waiting for buildroot overrides. The builds are almost done - the buildroot override I am currently waiting for is the second to last one. But of course the new dependency on globus-xio-pipe-driver applies here too, if the update should be really complete.
(In reply to comment #12) > Given > > diff /etc/lfc-postgres/lfcdaemon.logrotate /etc/lfc-mysql/lfcdaemon.logrotate > > shows they are the same having an alternative between them seems > a bit pointless but then of course I realise there is the problem > of where you put it. Perhaps a -common package or something. There are in total 7 logrotate files. If each of these should be put in a separate subpackage this would mean 7 new subpackages each containing a single file. I don't find this to be a good idea. (In reply to comment #13) > In the README change: > > mysql> grant all on cns_db.* to <user>@localhost identified by <password>; > > to > mysql> grant all on cns_db.* to <user>@localhost identified by '<password>'; Accepted. (In reply to comment #14) > Related to comment #12 I think the /etc/NSCONFIG should really be present > and owned especially given it is in /etc/ > > It could go in lfc-common package. The /etc/NSCONFIG file contains the username and password of the lfc database that the sysadmin creates when the service is deployed. This file should not exist before the database has been created. Its presence is an indication that the sysadmin has initialized the necessary database tables. It can therefore not be installed or created at the time of package installation. (In reply to comment #15) > 1) Can you submit a bug for > # rpmlint dpm > dpm.x86_64: W: shared-lib-calls-exit /usr/lib64/libdpm.so.1.7.4 > exit.5 > 1 packages and 0 specfiles checked; 0 errors, 1 warnings. I sent an e-mail to the upstream developers about this issue and it has been fixed in the latest version. > 2) Request only: Given there are two different versions of rf* commands out > there any chance these ones could become of managed by alternatives key of > rfio so as to exist with. > > > rpm -ql castor-rfio-client > /usr/bin/rfcat > /usr/bin/rfchmod > /usr/bin/rfcp > /usr/bin/rfdir > /usr/bin/rfmkdir > /usr/bin/rfrename > /usr/bin/rfrm > /usr/bin/rfstat > > and man pages. Obviously castor-rfio does not exist in Fedora but it might > one day. It certainly does here of course. I sent the following question to the upstream developers: "The dpm-clients bundles the set of rfio-clients. These are also present in another software package you provide (castor-rfio). This package is not in Debian or Fedora yet, so it is not a packaging conflict in the distributions at this time, but it is a potential one. Do you have any plans w.r.t. this so that you only provide one set of the rfio client tools. Looking at the sources the two versions seems to be different versions of the same software a bit out of sync with each other, not two different implementations that both should be packaged, but please enlighten me." And got the following reply: "There was 3 years ago a project to have a common RFIO between CASTOR and DPM. But not much has been done and the 2 RFIO codes have even more diverged. However in the medium term CASTOR wants to drop RFIO. So I'm not sure we should spend time on this, but the RFIO code cleanup I've done for DPM 1.7.4-2 would certainly help." I suggest keeping the current structure of the package until we know more about whether upstream will merge the two implementations, or drop one of them, or not. > 3) I realise this is an upstream thing but both lfc and dpm-nameserver use a > database called cns_db by default. If possible/easy could one be changed. Upstream's reply: "cns_db is the default but as you can specify the DB name in the NSCONFIG and DPMCONFIG files, I do not see really a problem. We have also a plan to be able to use the DPM Name Server as local LFC (DPM 1.7.6)." Given this reply, I suggest upstream's defaults are kept. It is tricky to run both an lfc and a dpm-nameserver on the same host anyway since they both by default listen to the same port (5010). > 4) Finally same comments for dpm and lfc about the use of a -common package > for each with configuration files to avoid things like. > > # rpm -qf /etc/DPMCONFIG > file /etc/DPMCONFIG is not owned by any package The /etc/DPMCONFIG file contains the username and password of the dpm database that the sysadmin creates when the service is deployed. This file should not exist before the database has been created. Its presence is an indication that the sysadmin has initialized the necessary database tables. It can therefore not be installed or created at the time of package installation. New version: Spec URL: http://www.grid.tsl.uu.se/review/lcgdm.spec SRPM URL: http://www.grid.tsl.uu.se/review/lcgdm-1.7.4.4-1.fc12.src.rpm
*** Bug 531254 has been marked as a duplicate of this bug. ***
*** Bug 531256 has been marked as a duplicate of this bug. ***
*** Bug 531258 has been marked as a duplicate of this bug. ***
Review: lcgdm Date: 6th April Mock Build: F14 http://koji.fedoraproject.org/koji/taskinfo?taskID=2098329 * PASS: rpmlint output 30 packages and 1 specfiles checked; 14 errors, 71 warnings. I've sorted, grouped and removed duplicates here to make it easier to read. invalid-url Source0: lcgdm-1.7.4.4.tar.gz -> expected since built from cvs. dpm.x86_64: W: spelling-error %description -l en_US runtime -> run time, run-time, runtier dpm-mysql.x86_64: W: spelling-error Summary(en_US) backend -> back end, back-end, backed -> correct runtime and backend if you like but they are clearly in common usage in this context. If you do it's obviously for all the descriptions but odmitted here. dpm-mysql.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/dpm dpm-mysql-copyd.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/dpmcopyd dpm-mysql-srmv1.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/dpm-srmv1 dpm-mysql-srmv2.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/dpm-srmv2 dpm-mysql-srmv22.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/dpm-srmv2.2 dpm-postgres-nameserver.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/dpnsdaemon lfc-mysql.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/lfcdaemon lfc-postgres.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/lfcdaemon -> These are symlinks to real ones managed via "alternatives". dpm-mysql.x86_64: W: non-standard-uid /var/log/dpm dpmmgr dpm-mysql-copyd.x86_64: W: non-standard-uid /var/log/dpmcopy dpmmgr dpm-mysql-nameserver.x86_64: W: non-standard-uid /var/log/dpns dpmmgr dpm-mysql-srmv1.x86_64: W: non-standard-uid /var/log/dpm-srmv1 dpmmgr dpm-mysql-srmv2.x86_64: W: non-standard-uid /var/log/dpm-srmv2 dpmmgr dpm-mysql-srmv22.x86_64: W: non-standard-uid /var/log/dpm-srmv2.2 dpmmgr lfc-dli.x86_64: W: non-standard-uid /var/log/lfc-dli lfcmgr lfc-mysql.x86_64: W: non-standard-uid /var/lib/lfc lfcmgr -> All expected since these users write the log files writes the log files. dpm-postgres-nameserver.x86_64: W: non-standard-uid /var/log/dpns dpmmgr dpm-postgres-nameserver.x86_64: W: non-standard-gid /var/log/dpns dpmmgr * PASS: Named according to the Package Naming Guidelines. Same as SVN module. * PASS: spec file name same as base package %{name}. Yes. * PASS: Packaging Guidelines. Its clearly a hugh package but yes. There are * PASS: Approved license in .spec file. ASL 2.0 * NOTE: License on Source code. Clear LICENSE file, most code is with out its own license header but lcgdm-1.7.4.4/test/python/lfc/*.py looks to be GPL but as far as I can see this is not used nor end ups in the binary RPMS. i.e it is fine. socket/goputils/gop_synfo.c contains some GPL declarations but again it does not looked to be used in anyway. * PASS: Include LICENSE file or similar if it exist. Included * PASS: Written in American English. Only if you want to change runtime and backend. * COMMENT: Spec file legible. Some of the seds especially could do with a few more comments. * PASS: Included source must match upstream source. After checking out and removing the .svn directories. $ diff -r --brief lcgdm-1.7.4.4 ../SPECS/lcgdm-1.7.4.4 produces nothing. * PASS: Build on one architecture. koji build * PASS: Not building on an architecture must highlighted. koji build * PASS: Build dependencies must be listed in BuildRequires. koji build * PASS: Handle locales properly. no locales * PASS: ldconfig must be called on shared libs. * PASS: No bundled copies of system libraries. * PASS: Package must state why relocatable if relocatable. Not relocatable. * PASS: A package must own all directories that it creates * PASS: No duplicate files in %files listings. None * PASS: Permissions on files must be set properly. %defattr %defattr is there. * PASS: %clean section contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). * PASS: Each package must consistently use macros. * PASS: The package must contain code, or permissable content. * PASS: Large documentation files must go in a -doc subpackage. No large docs. * PASS: %doc must not affect the runtime of the application. * PASS: Header files must be in a -devel package. Yes. * PASS: Static libraries must be in a -static package. No statics. * PASS: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' No pkgconfig * PASS: devel packages must require the exact base package They do * PASS: No .la libtool archives None present * PASS: GUI apps should have %{name}.desktop file No gui * PASS: No files or directories already owned by other packages. None * PASS: %install must run rm -rf %{buildroot} (or $RPM_BUILD_ROOT). It does * PASS: All filenames in rpm packages must be valid UTF-8. Summary: 1. There are quite a few "install"s that could benefit from a "-p". 2. There are a few pretty complicated seds in there that have little or no comments with them. Might make it easier for someone else (me) to understand what is going on if more comment could be added. 3. You may want to take out the words backend and runtime which are apparently not words.
Above can all be done post review. A really good package. APPROVED.
Thank you for the review - it took some time, but I think the end result is very good. New Package CVS Request ======================= Package Name: lcgdm Short Description: LHC Computing Grid Data Management Owners: ellert Branches: F-11 F-12 F-13 EL-4 EL-5 InitialCC:
Hi had one more comment I meant to mention yesterday. The postgres and mysql flavors are both priority 20. Is that on purpose, I admit I don't know what alternatives chooses in this case? The mysql version is certainly better maintained. Steve.
(In reply to comment #24) > The postgres and mysql flavors are both priority 20. > Is that on purpose, I admit I don't know what alternatives chooses > in this case? The postgres version was supposed to have lower priority (10) - it was correct for the LFC, but not for the DPM services. I bit too much cut and paste I guess. Thank you for pointing this out - I will fix it.
CVS done (by process-cvs-requests.py).
lcgdm-1.7.4.4-2.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.el5
lcgdm-1.7.4.4-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.fc13
lcgdm-1.7.4.4-2.el4 has been submitted as an update for Fedora EPEL 4. http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.el4
lcgdm-1.7.4.4-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.fc11
lcgdm-1.7.4.4-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.fc12
lcgdm-1.7.4.4-2.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update lcgdm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.el5
lcgdm-1.7.4.4-2.el4 has been pushed to the Fedora EPEL 4 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update lcgdm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.el4
lcgdm-1.7.4.4-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update lcgdm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.fc13
lcgdm-1.7.4.4-2.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update lcgdm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.fc12
lcgdm-1.7.4.4-2.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update lcgdm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.fc11
lcgdm-1.7.4.4-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
lcgdm-1.7.4.4-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
lcgdm-1.7.4.4-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
lcgdm-1.7.4.4-2.el4 has been pushed to the Fedora EPEL 4 stable repository. If problems still persist, please make note of it in this bug report.
lcgdm-1.7.4.4-2.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.