On Mon, 2008-05-19 at 09:40 +0800, Gregory Hosler wrote:

Hi all,

new packager here.

Apologies in advance for any ignorant questions.

The only ignorant questions are the ones unasked.

First question: What is the procedure when there are changes to the spec file ?

cvs update ; $EDITOR foo.spec ; cvs commit

I am gathering that changes are done in devel first, and then after they build correctly, those changes/updates are then applied to the respective branch from {EL-4, EL-5, F-7, F-8, F-9}, one at a time. Is this correct ?

It's best to keep newer releases with newer ENVRs, but there's no requirement to wait until a build is complete in devel before applying it to the stable Fedora releases. You can use the mockbuild target to give a "quick" shakedown of your package under a specific branch.

EPEL has it's own set of rules; you'll want advice from someone that's more familiar with them before touching the EL branches.

now, the pc I'm using for development is presently F-8, i386; How do I verify a package for other platforms, other hardware ? I have heard of mock, koji, and have been to the relevant wiki pages. I'm more needing some step-by-step guidance, as to what needs to be done, and the order of things :)

You can pass --scratch to koji in order to test build a SRPM for a single release across all archs; I'm not sure if you can do a scratch build of the contents of a branch.

On Mon, May 19, 2008 at 09:40:02AM +0800, Gregory Hosler wrote:

Next, as I study PackageMaintainers/UpdatingPackageHowTo and my cvs area, in my cvs area I see {common, CVS, devel, EL-4, EL-5, F-7, F-8, F-9} CVS I understand. and I understand that the {EL-4, EL-5, F-7, F-8, F-9} sub dirs are for the different fedora/epel repos. I'm lacking some clarity as to the migration of files from devel to {EL-4, EL-5, F-7, F-8, F-9}, and/or {common}

F-7 is end of life so you shouldn't change it.

Otherwise it is up to the packager. However you should think about what is best for your users depending on the target of the package (are these users who like the latest package, or do they prefer to stick to a version in old releases?). If you want to have maximal testing of your package, and since we are at th ebeginning of a new release cycle for F-10, you can wait for the devel version to be tested to push it to F-9 and F-8 and wait for testing in bodhi in these branches. However, if the user base is restricted, and the users don't know bodhi, having the release hit F-8 and F-9 as soon as possible may also be an option.

For EPEL you should be very cautious, and read: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies

I personally think that it is bad to break ABI in releases, or do updates that have incompatible configuration files, but there are differing opinions on that matter. Which package is it?

-- Pat

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Ignacio Vazquez-Abrams wrote: | On Mon, 2008-05-19 at 09:40 +0800, Gregory Hosler wrote: |> Hi all, |> |> new packager here. |> |> Apologies in advance for any ignorant questions. | | The only ignorant questions are the ones unasked. | |> First question: What is the procedure when there are changes to the spec file ? | | cvs update ; $EDITOR foo.spec ; cvs commit | |> I am gathering that changes are done in devel first, and then after they build correctly, |> those changes/updates are then applied to the respective branch from {EL-4, EL-5, F-7, |> F-8, F-9}, one at a time. Is this correct ? | | It's best to keep newer releases with newer ENVRs, but there's no | requirement to wait until a build is complete in devel before applying | it to the stable Fedora releases. You can use the mockbuild target to | give a "quick" shakedown of your package under a specific branch.

ok, so if I understand properly...

cvs update

go to the devel, directory, update the spec file, then

cvs commit

(And to clarify, the above commit should be delayed until several steps below, where I have done a build on my system, yes?)

and then

make new-sources FILES="yournewtarball.tar.gz"

Q: Do I have the tarball in the current (devel, or whatever) directory, or do I just specify the path to it, and "it doesn't matter" ?

Q: does the above line push the new tarball into cvs ? or do i need a commit ?

and then (if I understand correctly):

make i386

will make an i386 package on my current i386 system yes ? Once I have a successful build

cvs commit make tag make build

(all above 3 lines from the devel directory).

I'm terribly paranoid about submitting a package that will break while building, even though I've built it many times in my own environment...

Devel builds goes where ? F-10 ? F-9 ? rawhide ?

Thanks, and best rgds,

- -Greg

- -- +---------------------------------------------------------------------+

Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log)

| Greg Hosler ghosler@redhat.com | +---------------------------------------------------------------------+

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Patrice Dumas wrote: | On Mon, May 19, 2008 at 06:30:02PM +0800, Gregory Hosler wrote: |> So you're saying that anything committed to devel will eventually find it's way to the |> other branches (F-*) ? | | No, it will find its way to F-10 only. You should make the changes you | want to the other branches yourself.

Ok. makes sense. So once I feel comfortable with the devel build, I then re-do my changes for the other F-* branches.

Q: How do I monitor/track/follow whether there were any issues for a devel commit, for any other platform. e.g. x32_64 -- i.e. how frequently are builds done, and when are teh results known ?

Q: ditto on the other branches (F-9, F-8, etc.)

|> | I personally think that it is bad to break ABI in releases, or do |> | updates that have incompatible configuration files, but there |> | are differing opinions on that matter. Which package is it ? |> |> gyachi -- it's an instant messaging package, lots of eye candy. does yahoo protocol. | | Looks like there is no library, but a plugin system, so there are issues of | ABI compatibility, though you should know if they broke the plugins API | for plugins that are not shipped with the main program. If no, my advice | would be to push it to all the branches unless the new release is not | compatible with previous user config, but I hope they didn't do | something like that.

I'm the principle maintainer, so I have "inside knowledge" of the ABI issues...

The version I will be pushing will create a library that is a collection of common routines that are shared between the different package components. It's really a "private" library, and doesn't really have any practical use outside of the package. That being the case, I'll none-the-less keep an eye on the ABI aspect of the library.

At the moment, adding external plugin's is not feasible (yet). True plugin support, requires that the plug in add a "hook" into the menu sub-system, so that the plugin can be called (or effects to that nature, for non-menu related plugins). At the moment, that layer (allowing a plugin to add a menu item, so as to invoke it's callbacks) is not there. Obviously this has been thought about, and it is planned. At THAt point ABI compatibility will be a much bigger issue. :)

So, for now, there aren't ABI issues...

Many thanks for your responses,

- -Greg

- -- +---------------------------------------------------------------------+

Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log)

| Greg Hosler ghosler@redhat.com | +---------------------------------------------------------------------+

On Mon, May 19, 2008 at 06:53:16PM +0800, Gregory Hosler wrote:

Ok. makes sense. So once I feel comfortable with the devel build, I then re-do my changes for the other F-* branches.

Yes. In some cases (namely security bugs), you should also push to other branches as fast as possible.

-- Pat