Jef Spaleta wrote:
> On Fri, 2003-03-07 at 18:01, Audioslave - 7M3 - Live wrote:
>
> > I opted to get the program from Psyche, since it was newer.
>
> I wouldn't have done that. Bound to really break things on yer beta box
> rolling back to a redhat 8 release package....and you know what happens
> if it breaks...you get to keep all the pieces...and i doubt any bugs due
> to collateral damage you file at this point will get processed...yer
> outside of an established reference for bug reporting as far as i can
> tell....too bad rawhide is down huh. Atleast with a rawhide package...if
> it broke...you could probably file a bug against the package under the
> rawhide category and felt somewhat better that someone might look at the
> report (and I can safely bring up rawhide now because chabotc should
> have me procmail filtered now..he promised he would ignore me from now
> on, no more educational emails about how rawhide ain't a fix) rawhide is
> unwise if you have an expectation that things will work(otoh, no one
> should expect betas to work to begin with)...but at least you can file
> bugs against rawhide. Rolling back to a rh8 package has got to be worse
> from a bugreporting point of view, I'm not even sure where you'd think
> about filing a related bug now. If you do start filing related bugs make
> sure you detail what you have done here with the bugreport.
I haven't had any problems with going back to RH8 for the updates. The updated versions
were available on RH8, they weren't available for phoebe.
You are right though, when it comes to downgrading to lower versions with a forced rpm
condition. I broke all the programs that were dependent upon openssl. That is why I had
the question about security updates and applying the patch to the current phoebe
release. If it is less involved than building a kernel through xconfig, I might resort
to patching openssl current for phoebe and patching, compiling, then packaging it. Then
installing it via rpm.
>
> You have to ask yourself...is the point of the beta system to have a
> working system...or is the point to beta test packages. I don't think
> the point is to have a working system...or even a secure system during
> the beta process. I think the point is test packages, and complain to
> redhat about the bugs you find. There are no garuntees for bug fixes
> before a next release..its nice to have them...its nice to test
> them...but there is no garuntee that any will ever be forth coming.
i'm at a different thought process for this concern. A broken or compromised package is
a bug. It should be complained about, just as much as an extra ICON, lesser quality
graphics, funnies with displaying true-type fonts in differen tlanguages and so forth.
>
> Redhat could just issue one beta iso...and accept bugreports from that,
> and never release another package to public beta testers again...and do
> the rest of the testing in a closed beta. The expectation that there
> will be ANY subsequent packages..is an expectation for support. The beta
> is WHOLLY unsupported...the beta release as an end of life of about 1
> minute after its released (if that). When they say its not supported, it
> means its not supported.
>
For testing, quality and security. I feel that these few steps for keeping up2date
filled with better performing programs would aid in narrowing down the bugs for
newcomers, free up engineering time and ensure a better overall next release.
I tried Null and Limbo betas. I loaded one, then it stopped getting updates. Theefore I
loaded the next beta. It stopped getting updates. Therefore, I went back to just using
RH7.3. I didn't realize that there was a mailing list for betas. I just figured that it
would be active and ever improving.
My thoughts. Cute little bug background. It looks decent. but it seems no more
functional.
I believe that the prompt for the beta release should prompt one to also join the beta
list for the release. The CDR problem wouldn't have gotten so far with more user input.
In short, I appreciate the open-beta cycles. i know the risks involved. But I feel that
the product would be ever so better with utilization of up2date.
I've learned a lot by being involved in at least expressing my ideas on the list. I
learned a lot more that solitary use within my closed past Red Hat experiences. I hope
they keep the beta process open, but improve it a bit.
Jim
>
> > I wasn't successful when trying the openssl program version from RH8. It was older,
> > but included the bug fix.
> > I thought, what the heck, I'll try the older version through a force, nodeps
> > situation.
> omg...force, nodeps...not wise.
>
nope, not wise at all. But a concern for security and realizing that there will be no
proactive initiative introduced through up2date. I'm back to the original. Thank
goodness it wasn't a massive security update, like for kde. one program was easy enough
to recover from.
>
> > Anyway, up2date, lynx and a host of other programs failed to work with the older
> > program version.
> thats not really all that shocking...there is a reason dependence
> checking is there and a reason why you shouldn't bypass rpm's logic with
> force and nodeps.
>
The dependacies are legitimate for this type of program. The dependacies for mozilla,
an
ever changing program and evolution were a bother for me. It is one reason that I was
distracted from it's usage, when trying ximian out.
Speaking of ximian. I have to repair my RH7.3 distribution. It somehow went premium,
after update. I have to either uninstall ximian or find out why it went premium. If it
did, they will soon fade from my high opinion of their previous efforts.
xcdroast, the reason I installed RH7.3 again was broken during the ximian installation.
gtk related, I believe.
>
> > fortunately, I had the disc burned on the better working burner action for RH7.3 to
> > pull the phoebe3 version off of and was able to upgrade to the proper and probably
> > vulnerable version from the disc.
>
> such is life...again...betas are broken,insecure,unsupported pieces
> of...cough...software. I keep meaning to do a nother burn on this beta
> box and test the disc out for data corruption....maybe i'll do this now.
there was a proposed solution to my readr for my laptop earlier, CDR's were downgraded
with 8.0 also. The problem was only slightly more subtle with 8.0. It was blown off as
the fault of the reader. The last good discs that i burned were for 8.0 on RH 7.3. With
the current problems that people mentioned with versions after phoebe3 kernel and
cdrecord and related programs. I decided to try out 7.3 to see if it solved my
previously written off CDR problem. It did, therefore, post 7.3 is broken for CDR
usage.
The amount of breakage is dependent upon the error correction that the reader is
capable
of.
If you put an 8.0 or later into a previously written off cdreader and observe screen 4
output, you will see that there are errors with timeouts and illegal boundaries. I
think
that the newer versions are even getting past the later CDRW error correction
abilities.
>
>
> > I don't totally suspect the programs compiled from outsiders, but I am more wary of
> > them ,than I would be for programs versions released by redhat.
>
> I think you missed the point of my post...watch as i give the dead horse
> one more swift kick to the head...
> the point was to point out chabotc was being hypocritical. chabotc wants
> to remind us that a "beta platform" is a complicated collection of 1400+
> packages, and its an engineering miracle to get them all working
> together, and beta testers should really stick to the script and not go
> installing wacko random version of the packages because is some value in
> making people test a "specific collection" of 1400+ packages and figure
> out how they interact badly. Now thats all well and good...nice and
> consistant...but chabotc offered up his own compiled packages to fix
> this unwelcomed (but should have been expected) security problem in the
> beta. Thats were he went wrong, he offered his own compiled packages
> which are totally outside the redhat QA process (even though they are
> based on redhat code..you have to trust him specifically that his binary
> packages are the same...you have to trust his developement system to not
> be hacked...so on and so on). If you chose to use his packages...and it
> didnt work...where would you file bugs...certaintly not with
> bugzilla...they aren't redhat compiled packages anymore...that are
> chabotc.com packages....and like in mission impossible, redhat will
> disavow any knowledge of them if things go horrible wrong. And for
> that, i called cabotc the strongest derogatory term I know...hypocrite.
>
I don't have any opinion on policies, but changing an RH8 version package to a speced
RH phoebe file is a litle bit confusing to me.
Why not just use the newer version regardless of the spec info?
This sounds like registry chaos hangover to me. I think that auditing would only be
enhanced by changing the spec files.
Since I upgraded from 8.0 directly to 8.094 on one system. I am sure that programs were
not upgraded because there was the same or older spec information.
>
> > I haven't patched any programs before. But how difficult is it to patch the source
> > with the security update, then compile and package the rpm for use?
> Depends
> > Are the patches pretty much program version independent?
> Depends...but most probably very dependant
>
> I think i can sum up whats going wrong here...you are thinking that the
> beta is a product...it isnt a product...its a big old collection of
> unsupported packages that are in a proto-product stage that is pretty
> much garunteed to break in some crucial way....and you get to help
> discover how it breaks...but no one is actually beholden to give you a
> fix for the things that break before this gross little beta caterpillar
> crawls up in its rawhide frozen cacoon and emerges as a beautifully
> crafted release product. It sucks...but thats the risks of running a
> beta....its a waste of breath to try to twist redhat's arm about
> supporting the beta...the beta is not supported and will not be, in the
> sense that you can every expect an update package to show up for the
> beta. You maybe have grown accustomed to the idea that Redhat has in the
> past offered X number of beta isos during a beta cycle, or Y many sets
> of packages to up2date...but that expectation based on past performance
> is misguided.
>
I realize that it is not a product, in the sense that it is not refined. I realize that
is a sort of approved collection of programs that have met some levl of sanity. A
prototype is still a product, though it is plastic enough to mold into different
directions.
i do agree that it seems to be more of a rigid environment. Bugging Red Hat to become
more molding with the unique tool of up2date would be barren. I am thankful that it did
allow me to upgrade to the beta without having to go through a full blown installation.
that in itself is a great and welcome progression.
>
> -jef"wouldn't be horribly surprised if this kind of unwelcome security
> problem had happen in a previous beta..with the same sort of
> result"spaleta
>
I wasn't here for it. I was tthinkng that the beta was dead, since there was no new
activity. NULL, Limbo.
Jim
>
> ------------------------------------------------------------------------
> Name: signature.asc
> signature.asc Type: application/pgp-signature
> Description: This is a digitally signed message part
--
Air Force Inertia Axiom:
Consistency is always easier to defend than correctness.
--
Phoebe-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/phoebe-list
