On Fri, Dec 11, 2009 at 11:33 AM, Zarko Pintar <zarko.pintar(a)gmail.com&gt; wrote: Zarko, this happened because you didn't update your CVS checkout and worked on a local non-synced spec file. Regards, Andrea.

On Fri, Dec 11, 2009 at 11:47 AM, Zarko Pintar <zarko.pintar(a)gmail.com&gt; wrote: I was probably misunderstood. You did a cvs up but you then copyed a local non-synced spec file. Bye, Andrea.

When I'm using this procedure for updates then I have some tagging issues. But, OK next time I'll use make new-sources bye Zarko

On Fri, 11 Dec 2009 12:07:57 +0100, Dominik wrote: All "tagging issues" after plain cvs commit based updates are _user errors_. For example, working with an out-of-date "common" checkout (which contains an old "branches" file). The only issue cvs-import.sh works around is that because it creates a fresh temporary check-out, it always checks out a fresh "branches" file. But that's only a corner-case after "devel" was branched to its own directory. cvs-import.sh does not and cannot work around other ordinary "tagging issues", which are based on user's mistakes. Really, do avoid using cvs-import.sh for updates. Prefer plain cvs.

BTW, Could someone make a review for my OpenShot package? OpenShot is another video editor based on MLT Framework, written in Python and GTK. review request is here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=993 thx, Zarko On Fri, Dec 11, 2009 at 12:19 PM, Zarko Pintar <zarko.pintar(a)gmail.com&gt;wrote:

On Fri, 11 Dec 2009 12:18:23 +0100, Zarko wrote: The end-result is the same. You end up with modified files in your cvs working-copy, which you need to commit to the cvs server. And that's easy: cvs diff -u | less for a final look at what you've changed compared with what is found in the cvs repository. make clog to extract the latest .spec %changelog comment into a file "clog", which can be used as the cvs commit log message: cvs commit -F clog or cvs commit -m "some alternative log message" to commit the modifications found in all local files (with a proper log message), and if that worked without errors, make tag to apply a cvs tag to all [comitted] files of the package. If none of these steps caused an error, the new tag is ready to be used by make build Room for mistakes is given when trying to shorten this sequence with the help of macros/aliases and when not paying attention to cvs error messages. For example, "make tag" will not tag all files as appropriate, if some of the local changes have not been committed before. [...] For updates that require a new source tarball, there are two commands which upload such source archives to the lookaside cache (a server that doesn't store them in cvs) prior to modifying other files in cvs: make new-sources FILES="fu-1.0.tar.gz bar-1.0.tar.gz" to upload one or multiple files and store their file names in new local "sources" and ".cvsignore" files. Or: make upload FILES="fu-1.0.tar.gz bar-1.0.tar.gz" to upload one or multiple files and append their file names to the local "sources" and ".cvsignore" files. In either case, the changes in the "sources" and ".cvsignore" files need to be committed to cvs just like ordinary changes made in the .spec file. The "cvs commit -F clog" above also commits the changes found in those files.