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: strk
Subject: Re: [Gnash-dev] revno.h again and deb building
Date: Thu, 9 Dec 2010 23:32:28 +0100

On Thu, Dec 09, 2010 at 10:30:43AM -0700, Rob Savoye wrote:
> 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.

There might be a problem with mail delay, or I haven't received
feedback on my first report about revno.h changes (except from
pere). Happy to discuss below.

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

I see. So you have both git and sources in a git repo, but no write access.
Do you get an error blocking 'make' when writing is attempted or is it just
a matter of a missing revno.h file ?
If it's just the missing case we might have autogen.sh generate the initial
revno.h 

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

I disagree about "-a x$(GIT) != x" being clearer than "if HAVE_GIT" but
that's a matter of taste really. Anyway, I wouldn't hang on that.

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

If git doesn't exist we need revno.h to be there !
W/out git you got a package from somewhere, and that package needs to
have revno.h in. This is why I removed revno.h from the list of files
cleaned by 'make clean'. You don't want that cleaned. Ever. It's part
of the sources. Just re-generated if you're clearly in conditions to
regenerate it (you have git and sources are in a git repository).

Do you agree on this ?

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

Let's improve it. I'm here to help.

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

Splitting the rules would be a good idea for buildbot.
keep 'deb' for unsigned, 'deb-signed' for signed or something
along those lines (build slaves are runing 'make deb' now as part
of their builds)

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

Please do the same. Let's focus on making package building work.

As I said, they worked for me except the signing phase.
Also 'make deb' is now run by build slaves so we can check if anything
goes wrong there and what.
I'm ready to set my source tree read-only to see what happens in that case.

If you can split the signing part it'll be easier to get a green-or-red light.

--strk; 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html



reply via email to

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