> I'm new to this issues about compiling. Where are the patch you use for > the rebuild? Assuming you want to know where they came from; In my case I got some from debian, others from RedHat, fedora-core etc. I've even looked as a few Suse advisories. My list of places to regularly check for new security issues includes: http://www.debian.org/security/ # usually quite fast https://rhn.redhat.com/errata/rhel3as-errata.html # often quiet slow https://rhn.redhat.com/errata/rh9-errata.html # was fast but no longer http://www.fedoralegacy.org/updates/RH9/ # none so far http://download.fedora.redhat.com/pub/fedora/linux/core/updates/ # painful http://www.suse.com/de/security/announcements/ Suse arn't very fast at making releases (their QA may take a long time), but section 2 of every advisory lists the outstanding security problems they are working on. e.g. http://www.suse.com/de/security/2004_14_kdelibs.html lists rsync, flim and mod_ssl. These usually contain enough info to find the original report and find a suitable upstream-patch or > Is it necessary to edit the spec from the rpm file to > include the pacht? Usually yes, if the patch replaces one of the same name you *could* avoid editing the specfile, but usually you at least want to change the release version! The specfile contains a list of patches to apply to the source, if the same (exact) patch applies as can be takes from another source (Debian or RHEL fro example), then you just need to add the PatchN lines to the specfile, change the package release and rebuild. If the package is the same version (or "close enough") as in RH9 or RHEA-AS3 (etc) then rebuilding from the update SRPM will usually give you a package which works on RH73, RH8 or 9. To avoid later confusion it is probably best practice to add something to the "release" version to indicate that it is a rebuild for a different version by you (as fedora-legacy does). I've been a bit varied in my numbering scheme(s), but currently try to change anything that looks like a redhat linux version-number to "80" or "RHL80" and add a JSP in there to show they are my rebuilds. For most such rebuilds (from the SRPM) just the release-version change is all that is needed, but a few need other tweaks. e.g. the NPTL change for kernel-... (NPTL problems was why we didn't switch to RH9 last year), and XFree86 was a bit of a pain (since it requires getting the environment right to build the final rpms). The biggest pain is when the BuildRequires lines arn't complete; e.g. you meet them only to find that the rpmbuild fails 'cos a needed dependency is missing. I live in fear of it just producing a "slightly broken" version which I won't spot 'til I've deployed it. I normally test on 3-4 machines for 2-3 days before pushing to the rest, but that isn't proper QA since the packages may nto get stress tested... > As I can see in the bugzilla errors getting the packages for QA, the > patch can be from the different sources: debian, redhat, etc. so I fear > myself thinking that you have to be a very good developer to do that > kind of things and I'm not a developer at all. I only know to rebuild a > package from sources. But I'm happy because there a lot of people who > share his effors to us. Thanks a lot for your help. I'd be happy to make all the packages that I have for download (I have to build them anyway), but they are *only* for RH80 and apparently few people (on this list at least) use that. I've still got no idea how to offer them up for fdl to look at/test though. Of course you might not trust me or my packages (why should anyone). > I'm testing in QA all the psyche packages that are released, and I have > a question... Where I can write that I'm testing that packages? For > example, xchat and OpenOffice from Marc, kernel 2.4.20-32-7, libxml2, > libxml2-python, lha, etc? If I'd designed the QA system you would report that via the bug-tracking system (once to say you started and later if there are problems or if you are happy). If there isn't a track kept of testing use then unless you "know" all the testers you can't tell if they started (downloaded packages etc), but never actually did anything. Not reporting problems doesn't mean that there arn't any... > > Best Regards, > P.C. I finally got a reply to a message on the list! -- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
