Re: Trying to install Bugs-Everywhere

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel

Re: Trying to install Bugs-Everywhere

On Sat, Oct 09, 2010 at 03:29:06PM -0700, Michael Diamond wrote:
> The dependancies list was very helpful, however an additional dependancy,
> docbook-to-man, is also required.

Not since
  commit 8c9f876ae69f7bf92686edea320931d875b5c681
  Author: W. Trevor King <wking <at> drexel.edu>
  Date:   Tue Sep 28 21:25:43 2010 -0400
  Converted man page source to DocBook V5.0.
which I hope will get merged into the trunk at some point.  My
documentation is for my branch.

> On Tue, Sep 28, 2010 at 6:36 PM, W. Trevor King <wking <at> drexel.edu> wrote:
> > On Mon, Sep 27, 2010 at 12:53:24AM -0700, Michael Diamond wrote:
> > > So I next tried to install the Ubuntu bugs-everywhere package,
> > > which worked
> >
> > This is a very old package.  Don't use it ;).
> 
> Should it be mentioned at all in the BE docs then?  That'll just
> confuse people like me.

We should really just _make_a_new_release_!  And package it!  As a
short term solution, it would be good to point out that the old
package is ancient.  I have just done this for my branch.

--

-- 
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel

be-1.0.0 test candidate

Hi all,

I've merged Trevor's repo and prepared a release tarball.  Would
anyone be up for testing and reporting back?  Here's the link:

http://download.bugseverywhere.org/test/be-1.0.0.tar.gz

If all looks good, I'll write up some release notes, push a git tag,
and move the tarball into the releases/ directory.

It's not clear to me what to do about libbe/_version.py -- it's
created with a git command when "make" runs, but I was intending
to avoid including .git/ in the tarball.

Cheers!

- Chris.
--

-- 
Chris Ball   <cjb <at> laptop.org>
One Laptop Per Child

Re: be-1.0.0 test candidate

Chris Ball <cjb <at> laptop.org> writes:

> It's not clear to me what to do about libbe/_version.py -- it's
> created with a git command when "make" runs, but I was intending to
> avoid including .git/ in the tarball.

Why can you not do both?

That is, have the release tarball exclude the ‘.git/’ directory and
include the ‘libbe/_version.py’ auto-generated file.

--

-- 
 \         “Religious faith is the one species of human ignorance that |
  `\     will not admit of even the *possibility* of correction.” —Sam |
_o__)                                 Harris, _The End of Faith_, 2004 |
Ben Finney

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel

Re: be-1.0.0 test candidate

Hi,

   > Why can you not do both?
   > 
   > That is, have the release tarball exclude the ‘.git/’ directory
   > and include the ‘libbe/_version.py’ auto-generated file.

I think the "python setup.py build/install" path will end up calling
make, which will end up calling git, which will fail.  Other than
that, I agree with the idea -- this is how the candidate tarball works.

Thanks,

- Chris.
--

-- 
Chris Ball   <cjb <at> laptop.org>
One Laptop Per Child

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel

Re: be-1.0.0 test candidate

Chris Ball <cjb <at> laptop.org> writes:

>    > That is, have the release tarball exclude the ‘.git/’ directory
>    > and include the ‘libbe/_version.py’ auto-generated file.
>
> I think the "python setup.py build/install" path will end up calling
> make, which will end up calling git, which will fail.

To make that work, the Makefile rules should be such that when the
‘libbe/_version.py’ file is already up to date, then no ‘git’ command is
necessary.

--

-- 
 \      “I find the whole business of religion profoundly interesting. |
  `\     But it does mystify me that otherwise intelligent people take |
_o__)                                    it seriously.” —Douglas Adams |
Ben Finney

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel

Re: be-1.0.0 test candidate

On Tue, 19 Oct 2010 13:28:26 +1100
>>>>>> "Ben" == Ben Finney <bignose+hates-spam <at> benfinney.id.au> wrote:

Ben> To make that work, the Makefile rules should be such that when the
Ben> ‘libbe/_version.py’ file is already up to date, then no ‘git’
Ben> command is necessary.

If you have problems with Makefiles, may I suggest pure python build
system - Waf (http://code.google.com/p/waf/). It's very nice and
actively developed (1.6 was released yesterday).

Samba is one of bigger players using it...

Sincerely,
Gour

--

-- 

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA
----------------------------------------------------------------

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel

Re: be-1.0.0 test candidate

On 2010-10-18 at 19:40:02 -0400, Chris Ball wrote:
> Hi all,
> 
> I've merged Trevor's repo and prepared a release tarball.  Would
> anyone be up for testing and reporting back?  Here's the link:
> 
> http://download.bugseverywhere.org/test/be-1.0.0.tar.gz
> 
> If all looks good, I'll write up some release notes, push a git tag,
> and move the tarball into the releases/ directory.

Would it be possible to pregenerate the documentation and include 
it in the relase tarball?
Generating the documentation under e.g. Arch Linux is problematic 
because of issues with the sphinx version and the lack of 
legacy prerequisites for docbook-to-man

> It's not clear to me what to do about libbe/_version.py -- it's
> created with a git command when "make" runs, but I was intending
> to avoid including .git/ in the tarball.

If the documentation is already generated there should be no need 
to run make, plain distutils will be enough and git won't be needed.

--

-- 
Elena ``of Valhalla''

homepage: http://www.trueelena.org

Re: be-1.0.0 test candidate

On Tuesday 19 October 2010 01:40:02 Chris Ball wrote:
> Hi all,
> 
> I've merged Trevor's repo and prepared a release tarball.  Would
> anyone be up for testing and reporting back?  Here's the link:
> 
> http://download.bugseverywhere.org/test/be-1.0.0.tar.gz
> 
> If all looks good, I'll write up some release notes, push a git tag,
> and move the tarball into the releases/ directory.
> 

Works for me, except that a simple

python setup.py install

does not install the manpages, since they are not builded

A workaround is to build the documentation (make doc) and after install be

As Elena suggest, if the documentation is already builded in the tarball, the 
problem of the libbe/_version.py file is solved, and if the process is 
automated, it is also possible to modify the file to have some more usefull 
information as output of the be --version command

bye
Gianluca

Re: be-1.0.0 test candidate

On Tue, Oct 19, 2010 at 01:28:26PM +1100, Ben Finney wrote:
> Chris Ball <cjb <at> laptop.org> writes:
> 
> >    > That is, have the release tarball exclude the ‘.git/’ directory
> >    > and include the ‘libbe/_version.py’ auto-generated file.
> >
> > I think the "python setup.py build/install" path will end up calling
> > make, which will end up calling git, which will fail.
> 
> To make that work, the Makefile rules should be such that when the
> ‘libbe/_version.py’ file is already up to date, then no ‘git’ command is
> necessary.

Except libbe/_version.py is marked .PHONY in the Makefile, since the
Makefile can't tell if it's up to date unless it knows Git.  The solution
is

  1) Generate libbe._version while you're still in Git.
  2) In the Makefile, change  'build: libbe/_version.py'  ->  'build:'
  3) Set libbe.version._VERSION

I've altered release.py in my branch to also do (2) (+ some bzr->git
migrations).  It already did (1) and (3).

On Tue, Oct 19, 2010 at 12:54:04PM +0200, Elena ``of Valhalla'' wrote:
> Generating the documentation under e.g. Arch Linux is problematic
> because of issues with the sphinx version and the lack of
> legacy prerequisites for docbook-to-man

My commit:

  commit 8c9f876ae69f7bf92686edea320931d875b5c681
  Author: W. Trevor King <wking <at> drexel.edu>
  Date:   Tue Sep 28 21:25:43 2010 -0400

  Converted man page source to DocBook V5.0.

Does not seem to have been merged into the trunk yet, but it replaces
the docbook-to-man dependency with xsltproc and the NS-enabled DocBook
stylesheets.  See
  http://www.physics.drexel.edu/~wking/code/be/doc/install.html
  http://www.physics.drexel.edu/~wking/code/be/doc/doc.html#man-page

I'm not sure if I posted anything about that to the list or not
though, sorry ;).

On Tue, Oct 19, 2010 at 07:45:37PM +0200, Gianluca Montecchi wrote:
> python setup.py install
>
> does not install the manpages, since they are not builded

You should install it with `make install` which generates the manpages
if they are missing.

--

-- 
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel