devel

devel@lists.centos.org

3 participants
4662 discussions

5.3´s anaconda src.rpm missing
by Farkas Levente 10 Apr '09

10 Apr '09

hi, it seems that the anaconda src.rpm missing from the mirror sites SRPMS dir. is there any reason for this or it´s just a bug? thanks in advance. -- Levente "Si vis pacem para bellum!"

16 22

Re: [CentOS-devel] [CentOS-qa] RPM issue
by Phil Schaffner 10 Apr '09

10 Apr '09

On Mon, 2009-04-06 at 16:47 -0400, R P Herrold wrote: > My first thought was: The only other list it might move to is > not a centos list -- we don't ship the package 'expressing' > this behaviour, as I read the ticket ["EPEL rhnlib package"]. I think the EPEL package provides an example of the symptom, but is not directly relevant. > But if it is to a centos list, I would put this thread on > centos-devel, and not the main list, which would trigger an > endless quantity of side noise. Agree that -devel would be a better venue if the discussion continues. I put it here because it seemed to be a QA issue when reported on the forums. Cross-posting to -devel, so this thread should presumably be considered closed. ... > > I do not see mention that a bug was filed, and to the extent > that forum answers by 'authoritative answerers' there do not > feed the bug tracker, we hide knowledge of possible errors > from ourselves by leaving it only in the forum I didn't file one, nor encourage the OP on the forum to do so, because I was unsure where to file it. Brandon has opened: http://bugs.centos.org/view.php?id=3517 Phil

1 0

forums + portal for {lang}.centos.org sites
by Graeme Spence 09 Apr '09

09 Apr '09

Hi, My name is Graeme, I'm a member of the Simple Machines team and I do apologize if I'm posting this to the wrong spot, however if the main issue against our software SMF is the licensing issue regarding re- distribution were quite up for negotiating an agreement as we have done with others. If SMF was being redistributed would it be modified in any way or just a standard SMF package? Its very nice to be considered and we would happily help in any way we can. Thanks, Graeme

2 2

Re: [CentOS-devel] RPM issue
by Brandon Davidson 08 Apr '09

08 Apr '09

I'm moving this here from from the QA list. For those who missed the original thread, it's linked from the bug report. http://bugs.centos.org/view.php?id=3517 -Brandon Brandon Davidson wrote: > If you look at the spec file for specspo, the string replacement is done > with a patch, so it's not just an overeager sed script... but it does seem like > some of the replacements are unnecessary. > > Other inappropriate translations are present for rhn-client-tools, rhnsd, and > rhn-setup-gnome. The mysqlclient10 package also refers to "CentOS 9" instead of > "Red Hat Linux 9". I'm sure there are others I'm overlooking. > > For the next release, perhaps someone could update the patch to remove > translations for upstream packages that have been removed from CentOS, as well > as going over the remainder to make sure they all make sense? -- Brandon Davidson Systems Administrator University of Oregon Neuroinformatics Center (541) 346-2417 brandond(a)uoregon.edu Key Fingerprint 1F08 A331 78DF 1EFE F645 8AE5 8FBE 4147 E351 E139

5 7

Re: [CentOS-devel] Welcome to the "CentOS-devel" mailing list (Digest mode)
by V Srikanth 06 Apr '09

06 Apr '09

Hello. Does CentOS have plans to release a build of Redhat MRG? If not, please, please consider doing it. _________________________________________________________________ Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. http://www.microsoft.com/windows/windowslive/products/photos.aspx

3 4

Centos 5.3 dependency check?
by Hugo van der Kooij 06 Apr '09

06 Apr '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, It seems that a package is now added to perl in Centos 5.3 that was not there before. So a dependency on perl-MIME-Base64 will fail because that package now seems to colide with perl itself. (SIGHHHH) How can I change my spec file to list the requirement only for Centos/RHEL 5.x where x < 3? Hugo. - -- hvdkooij(a)vanderkooij.org http://hugo.vanderkooij.org/ PGP/GPG? Use: http://hugo.vanderkooij.org/0x58F19981.asc A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting frowned upon? Bored? Click on http://spamornot.org/ and rate those images. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAknX4vQACgkQBvzDRVjxmYHvJACfYDKTKpF07O0ooJDujUmyRNkv BK8AnRKSums3kn0aJL3M1pn6xy9AuHNz =XBeU -----END PGP SIGNATURE-----

3 5

Broken mirror: ftp.nluug.nl
by Hugo van der Kooij 05 Apr '09

05 Apr '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yum is slow because it returns ftp.nluug.nl as the fastest mirror but that mirror is not in sync. In fact I belive it is in a state of temporal flux as there seem to be some major reorganisation going on. Hugo. - -- hvdkooij(a)vanderkooij.org http://hugo.vanderkooij.org/ PGP/GPG? Use: http://hugo.vanderkooij.org/0x58F19981.asc A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting frowned upon? Bored? Click on http://spamornot.org/ and rate those images. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAknX46wACgkQBvzDRVjxmYE2pACeKTBpMP/PycqFDSzRn2kCbRPG oL8An26nVKlJs/ABEkaqVcOvoj7mJi/H =wnjO -----END PGP SIGNATURE-----

2 1

ldconfig issue?
by Hugo van der Kooij 01 Apr '09

01 Apr '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Did others notic there seems to be a problem with ldconfig on Centos 5? It got apparant with the latest clamav update of rpmforge but it seems that ldconfig does not bild all the information that is required. Or as the report read on the MailScanner mailinglist: > And some more fun: > > [root@liquidity lib]# rm libclamunrar.so.6 libclamunrar_iface.so.6 > rm: remove symbolic link `libclamunrar.so.6'? y > rm: remove symbolic link `libclamunrar_iface.so.6'? y > [root@liquidity lib]# ls -lra libclamunrar* > -rwxr-xr-x 1 root root 142039 Mar 27 17:45 libclamunrar.so.6.0.2 > -rwxr-xr-x 1 root root 24434 Mar 27 17:45 libclamunrar_iface.so.6.0.2 > [root@liquidity lib]# ldconfig -v | grep unrar > libclamunrar.so.6 -> libclamunrar.so.6.0.2 (changed) > libclamunrar_iface.so.6 -> libclamunrar_iface.so.6.0.2 (changed) > [root@liquidity lib]# ls -lra libclamunrar* > -rwxr-xr-x 1 root root 142039 Mar 27 17:45 libclamunrar.so.6.0.2 > lrwxrwxrwx 1 root root 21 Apr 1 17:24 libclamunrar.so.6 -> > libclamunrar.so.6.0.2 > -rwxr-xr-x 1 root root 24434 Mar 27 17:45 libclamunrar_iface.so.6.0.2 > lrwxrwxrwx 1 root root 27 Apr 1 17:24 libclamunrar_iface.so.6 -> > libclamunrar_iface.so.6.0.2 > > > The issue doesn't appear to be isolated to just ClamAV, though. Look in > your libs and delete any linked .so file and re-run ldconfig. The .so > isn't recreated. > > [root@liquidity lib]# rm libbeecrypt.so libbeecrypt.so.6 > rm: remove symbolic link `libbeecrypt.so'? y > rm: remove symbolic link `libbeecrypt.so.6'? y > [root@liquidity lib]# ldconfig -v | grep libbeecr > libbeecrypt.so.6 -> libbeecrypt.so.6.4.0 (changed) > [root@liquidity lib]# ls -lra libbeecrypt* > -rwxr-xr-x 1 root root 251704 Jan 6 2007 libbeecrypt.so.6.4.0 > lrwxrwxrwx 1 root root 20 Apr 1 17:25 libbeecrypt.so.6 -> > libbeecrypt.so.6.4.0 > -rwxr-xr-x 1 root root 833 Jan 6 2007 libbeecrypt.la > -rw-r--r-- 1 root root 340262 Jan 6 2007 libbeecrypt.a Is this something that needs to be reported upstream? Or is it Centos 5 specific? Hugo. - -- hvdkooij(a)vanderkooij.org http://hugo.vanderkooij.org/ PGP/GPG? Use: http://hugo.vanderkooij.org/0x58F19981.asc A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting frowned upon? Bored? Click on http://spamornot.org/ and rate those images. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAknT4AgACgkQBvzDRVjxmYEA5QCgrGnY/e5/0bWXRi6jEJI6ByPf LvoAn23lt58ucrqSv9WcUpu/e0qZGblg =Mms2 -----END PGP SIGNATURE-----

2 1

CentOS-Sparc - New 'Fedora Secondary' Discovery
by Worsham, Michael 01 Apr '09

01 Apr '09

This report/issue is geared to those attempting to find a CentOS/RH for Sparc. Currently, there is a slowdown to the development of CentOS for the Sparc platform. The current tftp64.img build for CentOS on Sparc does not have support for the low-cost Netra and Sunfire 1U servers, thus hinders any chance of this distro release being used for cheap hardware re-provisioning needs (i.e. basic web servers, database servers, etc). In the past, there was a project called Aurora Sparc Linux, which was based on the Fedora platform. There are older builds still available, but these are rather ancient in comparison to today's kernel and driver updates. Upon doing a bit of in-depth research, I did discover that Ubuntu did release a Sparc build under their v7.10 distro, which supports many older as well as new Sparc-based platforms including the low-cost Netra and Sunfire 1U servers. These special servers require the 'eri' driver commonly called the SunGEM driver. I did, however, stumble upon a 'Fedora Secondary' project which does have actual images and CD/DVD/NetBoot ISO builds available and is based on the Fedora 9 distro. http://archives.fedoraproject.org/pub/fedora-secondary/releases/test/9-B eta/Fedora/sparc/iso/ Upon initial testing, I found that the test ISO and the TFTP images do support the low-cost Netra and Sunfire 1U servers as well as other platform, but there seems to be an issue when it comes down to creating the actual disk environment. Out of five tries, three of them tried to create an 'ext2' disk build-out even when ext3 was specified. The remaining two would place the disks in a read-only status -- and even using a rescue boot CD -- failed to restore these to a read-write capability. I recommend to those looking at trying out a RedHat-based distro for Sparc, to look at this build. It might provide some guidance for the CentOS development team going forward for future platform releases. -- Michael

4 3

Fwd: Using probe dependencies for ordering
by Jeff Johnson 31 Mar '09

31 Mar '09

Niels: I've been assembling the necessary implementations to __REALLY__ solve the useradd ordering issue for the last few years. Thanks for the impetus to finally attempt to deploy a solution. Flaps down, headed on final approach pattern to the release runway ... Gonna take a few months still ... 73 de Jeff Begin forwarded message: > From: Jeff Johnson <n3npq(a)mac.com> > Date: March 30, 2009 12:47:57 PM EDT > To: rpm-devel(a)rpm5.org > Subject: Using probe dependencies for ordering > > This thread (I chimed in late solely because using PreReq: > never solves any problem in reliable packaging imho) > > http://lists.centos.org/pipermail/centos-devel/2009-March/004250.html > > leads me to attempting to ensure that RPM orders packages > so that dynamic events (in this case adding a user) occur > before they are needed. > > There's a whole class of these run-time ordering issues, from > daemon restart to cache rebuilds, that are often not ordered > correctly, leading to endless discussions of the best way > to solve rather mundane issues. > > The problem is intrinsically run-time because an event > (like a cache rebuild or adding a user or ...) needs > to precede the installation/erasure of some other package. > > There's all sorts of solutions that have been proposed, > some solutions work better than others ;-) The typical > approach is to overload dependencies like > Provides: user(foo) > and then attach some semantic to the existence of a > value in rpm dependencies. That approach can take you > only so far because the string represents an > intrinsically run-time condition without actually > testing that the run-time condition is satisfied. > > E.g. adding a user through a %pre script represented by > Provides: user(add) > is only as good (or bad) as the execution of the > script itself. One never knows whether the user > was actually added, only that the user was *supposed* > to have been added, tying the success of an end-luser > upgrade to the quality of the packagers scripting > abilities. > > However, the fundamental problem of representing a dependency > on a dynamic event (think: adding a user) that usually occurs in the > middle of > rather large upgrade transactions using static dependency > assertions is rather confusing. > > I'm gonna call the (solution to the) problem a "Dynamically Ordered > Event" > (or DOE for short) because I gotta call it something. > > There are already several DOE relations that are used for > (partially) ordering packages installs and erases already. > > The most important DOE event (now handled in @rpm5.org code) is > Install before erasing a package on upgrade. > RPM does not compute file dispositions correctly > unless install occurs before erase. The ordering > relation is a DOE because (obviously) the installation > of the new instance before the old instance is removed > is dynamic and solely within the scope of running a transaction. > > Other DOE events (that were added to RPM5 in February) include > ensuring that a package that contains a directory is installed > before any file is installed in that directory. > > Similarly, the end-point of a symlink is used as a DOE relation > when ordering packages to ensure that the end-point of a symlink is > installed before the symlink itself. > > (aside) > There's another _HUGELY_ important DOE condition in RPM that > should be instantly obvious: > Never erase a package instance if the new instance > was not installed successfully. > But that DOE condition is handled through other means (i.e. > doubly linked package upgrade chains) than by permuting the > order of package installation and erasure. > > (another aside) > Whether DOE relations (like parentdir/linkto dependencies) > are _NECESSARY_ or _USEFUL_ for installing *.rpm packages is quite > controversial years after implementation. Adding DOE relations is > demonstrably not _NECESSARY_, RPM has survived (and @rpm.org ;-) > without using that information for more than a decade, there > are other means to constrain ordering with existing dependency > relations. > I do claim that the the added DOE relations are _USEFUL_ because > of the increased determinism in transactions, with less "partial" in > the > package ordering. Additionally, the data in the added DOE > relations is *guaranteed* to be accurate because hierarchical > file paths and symlink end-points always exist, no fuss, no muss, > no packaging policies or reviews are ever needed. > > So I believe its time to start using DOE events (like adding > users, restarting daemons, rebuilding caches, etc) to > package ordering much like parentdir/linkto and install-before-erase > are currently being used. > > The major problem with treating useradd like parentdir dependencies > is how to detect the condition while installing. Unlike parentdir > dependencies, useradd is run by a script that can/will fail. > > Which brings me to run-time probe dependencies. As implemented, > run-time probe dependencies are strings that map to a dynamic run-time > test. E.g. (as implemented @rpm5.org, ymmv) this dependency > Requires: user(foo) > tests that getpwnam("foo") has a return code of 0 rather than whether > some package some where contains a matching string > Provides: user(foo) > (Note: I'm deliberately ignoring details that both the strcmp(3) and > the getpwnam(3) probe will be done if necessary, and also that > probes are not currently > run against added packages but only against the "system" whatever > that means). > > The important point is that (as implemented @rpm5.org) the user(foo) > probe tests the condition that indeed, "foo" can be looked up rather > than that some package happens to contain a matching Provides: of a > string. > > The remaining pieces of the puzzle have to do with establishing > the points in time where DOE relations are evaluated. At the > point where packages are ordered, the script containing the > useradd has not yet been run (and may fail when it actually is > run). So there's a need to attach a post-condition to the > running of %pre (where useradd is typically done) to verify > that indeed a user was added. There's also a need to test > the precondition when installing a package that needs to do > chown(2) on some file path with the uid returned by getpwnam(3) > (i.e. exactly what the Requires: user(foo) dependency tests). > > The above pins down the exact points in time, using pre-/post- > conditions > where the probe is meaningful. > > What remains is to attempt to use the DOE relation while ordering > packages. As currently implemented, that basically means that > %pre scripts need to be parsed to detect that useradd is being > attempted, with whatever user, and a DOE relation needs to be > added before the user is actually added so that the package > that is attempting to add the user is installed before other > packages that need to do getpwnam(3) in order to do chown(2). > > I think I've covered all the necessary details to attempt a > DOE relation for adding users. Adding groups is not significantly > different. > > I also claim that other probes, like /sbin/ldconfig cache rebuilds, > can be mapped into DOE relations. Note that the code base @rpm5.org > already has the run-time probe > Requires: soname(libfoo.so) > and there are further run-time probes that can be evaluated as > pre-/post-conditions during package installation/erasure as well > as being used as DOE relations for ordering. > > Opinions? > > 73 de Jeff > > > >

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel