Re: [expert] X 4.0.2 and the RPM database
On Tuesday 26 December 2000 12:33, you wrote: > I have been highly curious about that I saw something about updates for the > Xserver and updates for KDE and updated Sendmail and BIND but it was not > listed in the Regular mandrake update folders but if you dared to venture > into the Developer area you would see the updates but only after you saw a > nice scary box telling you that you might burn your box down using it . SO > what is the accpeted way to get the updates are those updates in the > developer area true beta of almost final releases? > Exactly right, everything is free, including the segfaults. Furthermore, if using these polymorphs you into a kobold, we never even knew you! /unsupported directory is for the current release, and will contain mostly _untested_ stuff (KDE2.01 is an exception). /cooker is for the release-to-be, and it will be thoroughly tested by those using it and by a corps of recruits once features are frozen. Of course, to follow good testing practice, the testing begins at the time the concept is designed, but we are not quite there yet. Civileme
Re: [expert] X 4.0.2 and the RPM database
civileme wrote: > > On Monday 25 December 2000 13:02, you wrote: > > Civileme wrote: > > > If it were that simple you would see it in /Mandrake-devel/unsupported > > > where we put updates that do not qualify as critical or security. > > > > Is unsupported a response to reported bugs (same version but a higher > > mdk patch level) or is it just a mandrake release of a a new > > developer's version (version upgraded, mdk level set to 1, plus > > still-relevant mdk patches) and compiled with and for the 7.2 gcc and > > glibc? > > > > These must be specific to 7.2? If so it is very strange that there > > is no /7.2/ in the path. What will happen when the incompatible 7.3 > > (if not onward compatible it should be 8.0, of course) has been > > released? Answer: then you will need unsupported/7.2/i586/ and > > unsupported/7.3/i586/. > > > > Or am I missing something? Civileme, > Yep you are. It wasn't clear to me how, but thanks for the elucidation. The same problem also must apply to /contrib. If a contrib binary RPM is release sensitive then don't we need a path qualifier to separate those contribs intended for 7.1 and 7.2 from those intended for Cooker and what it will become later, 7.3? -- Regards, Ron. [AU]
RE: [expert] X 4.0.2 and the RPM database
I have been highly curious about that I saw something about updates for the Xserver and updates for KDE and updated Sendmail and BIND but it was not listed in the Regular mandrake update folders but if you dared to venture into the Developer area you would see the updates but only after you saw a nice scary box telling you that you might burn your box down using it . SO what is the accpeted way to get the updates are those updates in the developer area true beta of almost final releases? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of civileme Sent: Tuesday, December 26, 2000 4:45 AM To: [EMAIL PROTECTED] Subject: Re: [expert] X 4.0.2 and the RPM database On Monday 25 December 2000 13:02, you wrote: > Civileme wrote: > > If it were that simple you would see it in /Mandrake-devel/unsupported > > where we put updates that do not qualify as critical or security. > > Is unsupported a response to reported bugs (same version but a higher > mdk patch level) or is it just a mandrake release of a a new > developer's version (version upgraded, mdk level set to 1, plus > still-relevant mdk patches) and compiled with and for the 7.2 gcc and > glibc? > > These must be specific to 7.2? If so it is very strange that there > is no /7.2/ in the path. What will happen when the incompatible 7.3 > (if not onward compatible it should be 8.0, of course) has been > released? Answer: then you will need unsupported/7.2/i586/ and > unsupported/7.3/i586/. > > Or am I missing something? Yep you are. Normally cooker has been an unofficial source of updates for users of the current release. Technology changes prohibited that this time (glibc, rpm4, etc) so /Mandrake-devel/unsupported was born for those things which did not belong in updates (neither critical nor security related). It is seldom that the newer packages will be so totally incompatible with the current release, at least for those who know how to use ln -s, so the /unsupported will be there as a _courtesy_ for updates at developers' discretion. Most of the packages will only see a smoke test, but of course KDE2.01 was an exception. Even so, it was so rushed that a new version of kdelibs (2mdk) had to be made later because the originals would fail on a conflict if kdelibs-devel wasn't included in the rpm -F *.rpm. So /unsupported will be for the current release. When the current release changes, /unsupported will be created anew and perhaps the old one moved to the archives for the previous release, depending on space availability. Anyway, ftp://mandragon.org/pub/mandrake has the efforts of a user for XFree-4.0.2, and it does accept anonymous logins, though it has had a couple of episodes where permissions needed work. Early results on 4.0.2 is that 3D accel is broken for all cards. That's one of the reasons it isn't appearing in /unsupported Civileme
Re: [expert] X 4.0.2 and the RPM database
On Monday 25 December 2000 13:02, you wrote: > Civileme wrote: > > If it were that simple you would see it in /Mandrake-devel/unsupported > > where we put updates that do not qualify as critical or security. > > Is unsupported a response to reported bugs (same version but a higher > mdk patch level) or is it just a mandrake release of a a new > developer's version (version upgraded, mdk level set to 1, plus > still-relevant mdk patches) and compiled with and for the 7.2 gcc and > glibc? > > These must be specific to 7.2? If so it is very strange that there > is no /7.2/ in the path. What will happen when the incompatible 7.3 > (if not onward compatible it should be 8.0, of course) has been > released? Answer: then you will need unsupported/7.2/i586/ and > unsupported/7.3/i586/. > > Or am I missing something? Yep you are. Normally cooker has been an unofficial source of updates for users of the current release. Technology changes prohibited that this time (glibc, rpm4, etc) so /Mandrake-devel/unsupported was born for those things which did not belong in updates (neither critical nor security related). It is seldom that the newer packages will be so totally incompatible with the current release, at least for those who know how to use ln -s, so the /unsupported will be there as a _courtesy_ for updates at developers' discretion. Most of the packages will only see a smoke test, but of course KDE2.01 was an exception. Even so, it was so rushed that a new version of kdelibs (2mdk) had to be made later because the originals would fail on a conflict if kdelibs-devel wasn't included in the rpm -F *.rpm. So /unsupported will be for the current release. When the current release changes, /unsupported will be created anew and perhaps the old one moved to the archives for the previous release, depending on space availability. Anyway, ftp://mandragon.org/pub/mandrake has the efforts of a user for XFree-4.0.2, and it does accept anonymous logins, though it has had a couple of episodes where permissions needed work. Early results on 4.0.2 is that 3D accel is broken for all cards. That's one of the reasons it isn't appearing in /unsupported Civileme
Re: [expert] X 4.0.2 and the RPM database
Civileme wrote: > If it were that simple you would see it in /Mandrake-devel/unsupported where > we put updates that do not qualify as critical or security. Is unsupported a response to reported bugs (same version but a higher mdk patch level) or is it just a mandrake release of a a new developer's version (version upgraded, mdk level set to 1, plus still-relevant mdk patches) and compiled with and for the 7.2 gcc and glibc? These must be specific to 7.2? If so it is very strange that there is no /7.2/ in the path. What will happen when the incompatible 7.3 (if not onward compatible it should be 8.0, of course) has been released? Answer: then you will need unsupported/7.2/i586/ and unsupported/7.3/i586/. Or am I missing something? -- Regards, Ron. [AU]
Re: [expert] X 4.0.2 and the RPM database
On Friday 22 December 2000 19:03, you wrote: > This...problem...does it occur if you install the Mandrake rpm? > Unfortunately, it is presently on rufus.rpmfind in the Cooker directory, SO > IT REQUIRES THAT DAMN GLIBC2.2. I have downloaded the src rpm and hope to > build it on my 7.2 system but wonder about this rpm database "problem". > > It IS corrected by doing the rpm --rebuilddb? > If it were that simple you would see it in /Mandrake-devel/unsupported where we put updates that do not qualify as critical or security. However, do not lose your faith in GNU/Linux and the free software community so easily. Look in ftp://mandragon.org/pub/mandrake LM user Eric Guntermann took the trouble to share his work for XFree-4.0.2 for version 7.2. Civileme
Re: [expert] X 4.0.2 and the RPM database
This...problem...does it occur if you install the Mandrake rpm? Unfortunately, it is presently on rufus.rpmfind in the Cooker directory, SO IT REQUIRES THAT DAMN GLIBC2.2. I have downloaded the src rpm and hope to build it on my 7.2 system but wonder about this rpm database "problem". It IS corrected by doing the rpm --rebuilddb? On Thursday 21 December 2000 23:38, you wrote: > Not sure what you mean by "...what looks like ..". Rebuilding the database > restores/updates the dependancy issues, *tries* to resolve duplicate > entries, and so forth. Are you having problems installing or "-e" ing [...] > On 22-Dec-2000 MichaelM wrote: > > b5dave wrote: > >> # rpm --rebuilddb > >> Don't worry, it takes a while. > > > > Nope. Still getting what looks like an old RedHat database =( [...] -- Praedor Against stupidity, the gods themselves contend in vain. ---
Re: [expert] X 4.0.2 and the RPM database
Not sure what you mean by "...what looks like ..". Rebuilding the database restores/updates the dependancy issues, *tries* to resolve duplicate entries, and so forth. Are you having problems installing or "-e" ing some rpms? When you say "looks" are you being literal? Please don't think I'm being facetious here; I'm *not*. I'm just trying to cover the bases. If you want it to look ordered is some way, and right after an install an 'rpm -qa' is indeed pretty well ordered, then there are tools for that. I would certainly agree that an un-ordered "rpm -qa" is next to useless. Personally I don't find uppercase files being sorted before lowercase ones usefull at all. Plus, why call it 'Eterm' when 'eterm' does the same work? Hell, I still don't know why they called it .Xdefaults instead of .xdefaults. There, that feels better. :-/ I pretty well have a *term constantly displaying all my installed rpm's. I've used the same command since RH 4.2 $ rpm -qa | sort -fd | less It's probably too late for me to put an alias in ~/.bashrc (like alias rpms='rpm -qa | sort -fd | less') because I can type the longer version as fast as the the alias!! Anyway, if I've completely misunderstood you, I apologize: it wouldn't be the first time I've missed the mark. Yet surely it could be useful given the peculiarities of Drakupdate or whatever that dangerous contraption is called. Dave. On 22-Dec-2000 MichaelM wrote: > b5dave wrote: > >> # rpm --rebuilddb >> Don't worry, it takes a while. > > Nope. Still getting what looks like an old RedHat database =( - 22-Dec-2000 01:38:09 -
Re: [expert] X 4.0.2 and the RPM database
b5dave wrote: > # rpm --rebuilddb > Don't worry, it takes a while. Nope. Still getting what looks like an old RedHat database =(
RE: [expert] X 4.0.2 and the RPM database
# rpm --rebuilddb Don't worry, it takes a while. Dave. On 22-Dec-2000 MichaelM wrote: > I'm sure I'm not the only one to be bitten by this, but for those out of > the loop, the binaries for XFree86 4.0.2 over-write the RPM database, > making RPM related stuff nigh on impossible. > > The question is, is a fix available, or even possible?
[expert] X 4.0.2 and the RPM database
I'm sure I'm not the only one to be bitten by this, but for those out of the loop, the binaries for XFree86 4.0.2 over-write the RPM database, making RPM related stuff nigh on impossible. The question is, is a fix available, or even possible?
