gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] revno.h again and deb building


From: Rob Savoye
Subject: Re: [Gnash-dev] revno.h again and deb building
Date: Thu, 09 Dec 2010 10:30:43 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc13 Lightning/1.0b2 Thunderbird/3.1.6

On 12/09/10 01:48, strk wrote:

  Strk, would you please stop "fixing" revno.h without discussing your
intended changes. Minor tweaks to all config/build effect me greatly.
Your refusal to discuss anything is frustrating.

> One concern of rob about having revno.h in source repository was that
> source dir should be read-only. This is still the case as revno.h*
> will only be written if sources are not in a git repository (and I
> dubt you'll have a git working tree under read-only filesystem, right
> ?)

  Sigh... Putting any generated files in the source tree is bad style,
other than the read-only problem. This shows a lack of experience. Yes,
when NFS mounting a source tree, it is often read-only on the client
side. My source tree is NFS mounted everywhere in my subnet, and each
machine has a local build tree. I never edit files on the client, only
on the server side.

  This change will prevent Gnash from building in most of my build farm.
So I'm screwed again... If you would just think these things through
instead of making knee-jerk decisions we'd all be better off.

> About using `which git' vs. configure time checking I'm still
> wondering what's "better" about it. Please explain before reverting.

  The which git thing was gone, not sure how you missed it. I just
modified your configure code to use AC_SUBST() instead of
AM_CONDITIONAL(), as it was a cleaner solution. We *need* the default to
a date if git doesn't exist, and as long as you keep reverting this, you
break package building on several of my build slaves.

> Oh, I've tested make deb this time and it works, although I still
> think it's very fragile.

  Package building of snapshots ia always a bit fragile, that's why I'm
griping.

> Last note: 'make deb' you can't complete successfully unless you
> have rob's private GPG key to sign the packages, altought it leaves
> you with the .deb files built (think buildbots).

  Anyone can build a deb by changing the maintainer field, or editing
the same thing in the changelog. Building a deb can also be separated
from signing it. It only needs to be signed before duploading. I just do
it that way as I'm the only one building packages out of master. Also
for an automated setup, keychain is commonly used to keep the keys
resident for package building, without that user being logged in.

  Please discuss these changes before making them so I don't loose a 3rd
day trying to update the packages in our repository.

        - rob -



reply via email to

[Prev in Thread] Current Thread [Next in Thread]