-----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(a)redhat.com | +---------------------------------------------------------------------+

On Mon, 19 May 2008 09:40:02 +0800, Gregory Hosler wrote: You can just edit the spec file directly in your cvs working copy and then "cvs commit" it. Yeah, it isn't directly clear in the howto, although step 2 does mention "cvs add"ing files. If you mean that the changes happen automatically and flow from devel->EL, they don't... It's up to you to make changes in each of the different branches and then commit them separately. Use your best judgment as to when and where to update for the different versions (there is a guideline page about this somewhere, but i can't seem to find it in the wiki). EPEL is optional by the way, although I'm sure they'd love the help. there are some helpful make targets in your cvs checkout. type "make help": ... scratch-build Request scratch build of "xxx" for dist-f10 scratch-build-<archs> Request scratch build of "xxx" for dist-f10 and archs <archs> examples: make scratch-build-i386,ppc64 make scratch-build-x86_64 mockbuild Local test build using mock ... those make targets aren't really a step by step guide but they should "just work", (note: I actually haven't ever tried them :P). I have a local mock install that i setup manually some time ago that i use by hand and scratch-builds are a relatively recent thing. welcome aboard.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrice Dumas wrote: | 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 the beginning 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. So you're saying that anything committed to devel will eventually find it's way to the other branches (F-*) ? | 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 Thanks for that. | 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. | -- | Pat | | -- | Fedora-packaging mailing list | Fedora-packaging(a)redhat.com | https://www.redhat.com/mailman/listinfo/fedora-packaging - -- +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler ghosler(a)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(a)redhat.com | +---------------------------------------------------------------------+

On Mon, May 19, 2008 at 06:53:16PM +0800, Gregory Hosler wrote: Yes. In some cases (namely security bugs), you should also push to other branches as fast as possible. -- Pat