8.0 packages to QA

[Jon Peatfield]

> 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!