re-alpine-bugs

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-04 21:05
Message generated for change (Tracker Item Submitted) made by chappa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832460 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832460, was opened at 2009-08-05 00:20
Message generated for change (Tracker Item Submitted) made by chappa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832460&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832460&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 04:05
Message generated for change (Comment added) made by ruskie3
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832460 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832460, was opened at 2009-08-05 07:20
Message generated for change (Comment added) made by ruskie3
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832460&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
>Resolution: Duplicate
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:31

Message:
Duplicate of 2832419

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832460&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832460 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832460, was opened at 2009-08-05 07:20
Message generated for change (Comment added) made by ruskie3
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832460&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Duplicate
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:31

Message:
And closing

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:31

Message:
Duplicate of 2832419

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832460&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832460 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832460, was opened at 2009-08-05 07:20
Message generated for change (Settings changed) made by ruskie3
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832460&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Deleted
Resolution: Duplicate
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:31

Message:
And closing

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:31

Message:
Duplicate of 2832419

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832460&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 04:05
Message generated for change (Comment added) made by schamane
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 13:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-04 21:05
Message generated for change (Comment added) made by chappa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 15:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 06:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 00:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 04:05
Message generated for change (Comment added) made by ruskie3
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 23:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 22:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 13:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 02:05
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 21:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 21:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 21:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 20:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 11:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 05:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-04 21:05
Message generated for change (Comment added) made by chappa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 17:00

Message:
Well, if that is the way it will be, then let it be that way. Just
remember, I can't build anything, nor for that matter test anything, or
cooperate with the project.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 16:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 16:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 16:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 15:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 06:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 00:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-04 21:05
Message generated for change (Comment added) made by chappa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 16:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 16:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 15:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 06:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 00:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 02:05
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 22:37

Message:
Eduardo,

your autogen problem can certainly be fixed. I have had some issues here
with similar products several times and it has always helped to upgrade the
involved components. 

Suggest you get the newest revisions of the following:
http://www.gnu.org/software/m4/m4.html
http://www.gnu.org/software/automake
http://www.gnu.org/software/autoconf

There are FTP servers available from those pages, choose the newest
version of the product you can find. The stuff installs the usual way with
'configure; make; make install'.

Once you've done that (typically installed to /usr/local), don'f forget to
add /usr/local to your path and try to run the autogen.sh of re-alpine
again. It should work.

What happens here is the following:
testuser@bianca:~> git clone
git://re-alpine.git.sourceforge.net/gitroot/re-alpine
Initialized empty Git repository in /home/testuser/re-alpine/.git/
remote: Counting objects: 5406, done.
remote: Compressing objects: 100% (2065/2065), done.
remote: Total 5406 (delta 3618), reused 5000 (delta 3283)
Receiving objects: 100% (5406/5406), 9.42 MiB | 347 KiB/s, done.
Resolving deltas: 100% (3618/3618), done.

testuser@bianca:~> cd re-alpine

testuser@bianca:~/re-alpine> ./autogen.sh 
Copying file ABOUT-NLS
Copying file config.rpath
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL'
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal

[The last warnings can be ignored]

Now we have a 'configure' that can be run as usual.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 22:00

Message:
Well, if that is the way it will be, then let it be that way. Just
remember, I can't build anything, nor for that matter test anything, or
cooperate with the project.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 21:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 21:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 21:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 20:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 11:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 05:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-04 21:05
Message generated for change (Comment added) made by chappa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 17:56

Message:
One more time, maybe this time I will get through.

* Alpine builds fine using "./configure && make"

Maybe you should know I do have root privileges in this machine, so
/usr/local/ is out of touch.
Ok, that was my last attempt.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 17:37

Message:
Eduardo,

your autogen problem can certainly be fixed. I have had some issues here
with similar products several times and it has always helped to upgrade the
involved components. 

Suggest you get the newest revisions of the following:
http://www.gnu.org/software/m4/m4.html
http://www.gnu.org/software/automake
http://www.gnu.org/software/autoconf

There are FTP servers available from those pages, choose the newest
version of the product you can find. The stuff installs the usual way with
'configure; make; make install'.

Once you've done that (typically installed to /usr/local), don'f forget to
add /usr/local to your path and try to run the autogen.sh of re-alpine
again. It should work.

What happens here is the following:
testuser@bianca:~> git clone
git://re-alpine.git.sourceforge.net/gitroot/re-alpine
Initialized empty Git repository in /home/testuser/re-alpine/.git/
remote: Counting objects: 5406, done.
remote: Compressing objects: 100% (2065/2065), done.
remote: Total 5406 (delta 3618), reused 5000 (delta 3283)
Receiving objects: 100% (5406/5406), 9.42 MiB | 347 KiB/s, done.
Resolving deltas: 100% (3618/3618), done.

testuser@bianca:~> cd re-alpine

testuser@bianca:~/re-alpine> ./autogen.sh 
Copying file ABOUT-NLS
Copying file config.rpath
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL'
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal

[The last warnings can be ignored]

Now we have a 'configure' that can be run as usual.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 17:00

Message:
Well, if that is the way it will be, then let it be that way. Just
remember, I can't build anything, nor for that matter test anything, or
cooperate with the project.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 16:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 16:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 16:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 15:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 06:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 00:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 02:05
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 23:20

Message:
Eduardo,

check the old SVN tree of Alpine. You will find an 'configure.ac' there.
Look into it and you should find a line like "Process this file with
autoconf to produce a configure script.".

There you can see that even the old 'configure' was produced this way
(using autoconf / autoconf etc.). Steve Hubert and his guys did just
additionally checkin the result to the SVN repo.

It is however uncommon to checkin production results to a repo (like you
would also not checkin fixed Makefiles, because they are created by running
'configure', or binaries as they are produced from object files, or object
files resulting from a compilation, because you've got the c-sources in the
repo, etc. you get the picture).

If you have no typo in your statements, then you do have 'root' privileges
on the box. So you have no problem to update your tools either in
/usr/local or /usr (though I would suggest using /usr/local to be on the
safe side).

In case I've understood you wrongly and you do not have root rights, then
you could add the tools to some local subdirectory of your homedir using
the --prefix option on running configure of the tools.

In case all of this fails, I can offer to send you a configure result once
from my box by email (drop me a mail in this case).

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 22:56

Message:
One more time, maybe this time I will get through.

* Alpine builds fine using "./configure && make"

Maybe you should know I do have root privileges in this machine, so
/usr/local/ is out of touch.
Ok, that was my last attempt.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 22:37

Message:
Eduardo,

your autogen problem can certainly be fixed. I have had some issues here
with similar products several times and it has always helped to upgrade the
involved components. 

Suggest you get the newest revisions of the following:
http://www.gnu.org/software/m4/m4.html
http://www.gnu.org/software/automake
http://www.gnu.org/software/autoconf

There are FTP servers available from those pages, choose the newest
version of the product you can find. The stuff installs the usual way with
'configure; make; make install'.

Once you've done that (typically installed to /usr/local), don'f forget to
add /usr/local to your path and try to run the autogen.sh of re-alpine
again. It should work.

What happens here is the following:
testuser@bianca:~> git clone
git://re-alpine.git.sourceforge.net/gitroot/re-alpine
Initialized empty Git repository in /home/testuser/re-alpine/.git/
remote: Counting objects: 5406, done.
remote: Compressing objects: 100% (2065/2065), done.
remote: Total 5406 (delta 3618), reused 5000 (delta 3283)
Receiving objects: 100% (5406/5406), 9.42 MiB | 347 KiB/s, done.
Resolving deltas: 100% (3618/3618), done.

testuser@bianca:~> cd re-alpine

testuser@bianca:~/re-alpine> ./autogen.sh 
Copying file ABOUT-NLS
Copying file config.rpath
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL'
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal

[The last warnings can be ignored]

Now we have a 'configure' that can be run as usual.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 22:00

Message:
Well, if that is the way it will be, then let it be that way. Just
remember, I can't build anything, nor for that matter test anything, or
cooperate with the project.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 21:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 21:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 21:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 20:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 11:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 05:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-04 21:05
Message generated for change (Comment added) made by chappa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 18:28

Message:
You were right. There was a typo. I do not have root access to this
machine.
Nevertheless. Do not worry about it. I will not anymore. You can safely
close the bug.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 18:20

Message:
Eduardo,

check the old SVN tree of Alpine. You will find an 'configure.ac' there.
Look into it and you should find a line like "Process this file with
autoconf to produce a configure script.".

There you can see that even the old 'configure' was produced this way
(using autoconf / autoconf etc.). Steve Hubert and his guys did just
additionally checkin the result to the SVN repo.

It is however uncommon to checkin production results to a repo (like you
would also not checkin fixed Makefiles, because they are created by running
'configure', or binaries as they are produced from object files, or object
files resulting from a compilation, because you've got the c-sources in the
repo, etc. you get the picture).

If you have no typo in your statements, then you do have 'root' privileges
on the box. So you have no problem to update your tools either in
/usr/local or /usr (though I would suggest using /usr/local to be on the
safe side).

In case I've understood you wrongly and you do not have root rights, then
you could add the tools to some local subdirectory of your homedir using
the --prefix option on running configure of the tools.

In case all of this fails, I can offer to send you a configure result once
from my box by email (drop me a mail in this case).

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 17:56

Message:
One more time, maybe this time I will get through.

* Alpine builds fine using "./configure && make"

Maybe you should know I do have root privileges in this machine, so
/usr/local/ is out of touch.
Ok, that was my last attempt.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 17:37

Message:
Eduardo,

your autogen problem can certainly be fixed. I have had some issues here
with similar products several times and it has always helped to upgrade the
involved components. 

Suggest you get the newest revisions of the following:
http://www.gnu.org/software/m4/m4.html
http://www.gnu.org/software/automake
http://www.gnu.org/software/autoconf

There are FTP servers available from those pages, choose the newest
version of the product you can find. The stuff installs the usual way with
'configure; make; make install'.

Once you've done that (typically installed to /usr/local), don'f forget to
add /usr/local to your path and try to run the autogen.sh of re-alpine
again. It should work.

What happens here is the following:
testuser@bianca:~> git clone
git://re-alpine.git.sourceforge.net/gitroot/re-alpine
Initialized empty Git repository in /home/testuser/re-alpine/.git/
remote: Counting objects: 5406, done.
remote: Compressing objects: 100% (2065/2065), done.
remote: Total 5406 (delta 3618), reused 5000 (delta 3283)
Receiving objects: 100% (5406/5406), 9.42 MiB | 347 KiB/s, done.
Resolving deltas: 100% (3618/3618), done.

testuser@bianca:~> cd re-alpine

testuser@bianca:~/re-alpine> ./autogen.sh 
Copying file ABOUT-NLS
Copying file config.rpath
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL'
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal

[The last warnings can be ignored]

Now we have a 'configure' that can be run as usual.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 17:00

Message:
Well, if that is the way it will be, then let it be that way. Just
remember, I can't build anything, nor for that matter test anything, or
cooperate with the project.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 16:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 16:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 16:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 15:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 06:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 00:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 04:05
Message generated for change (Comment added) made by ruskie3
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:11

Message:
I have made configure ungitignored and have commited the one I generated I
ask anyone that wishes to to test it out if it works for them. If so this
bug is closed.

The decision behind this:

I have checked multiple projects. Most do not include it. But some do:
gcc, glibc, emacs to name a few. As this is a minor thing I have decided to
include it back in. It will hopefully make it easier for those who cannot
update their systems to contribute.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 01:28

Message:
You were right. There was a typo. I do not have root access to this
machine.
Nevertheless. Do not worry about it. I will not anymore. You can safely
close the bug.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 01:20

Message:
Eduardo,

check the old SVN tree of Alpine. You will find an 'configure.ac' there.
Look into it and you should find a line like "Process this file with
autoconf to produce a configure script.".

There you can see that even the old 'configure' was produced this way
(using autoconf / autoconf etc.). Steve Hubert and his guys did just
additionally checkin the result to the SVN repo.

It is however uncommon to checkin production results to a repo (like you
would also not checkin fixed Makefiles, because they are created by running
'configure', or binaries as they are produced from object files, or object
files resulting from a compilation, because you've got the c-sources in the
repo, etc. you get the picture).

If you have no typo in your statements, then you do have 'root' privileges
on the box. So you have no problem to update your tools either in
/usr/local or /usr (though I would suggest using /usr/local to be on the
safe side).

In case I've understood you wrongly and you do not have root rights, then
you could add the tools to some local subdirectory of your homedir using
the --prefix option on running configure of the tools.

In case all of this fails, I can offer to send you a configure result once
from my box by email (drop me a mail in this case).

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:56

Message:
One more time, maybe this time I will get through.

* Alpine builds fine using "./configure && make"

Maybe you should know I do have root privileges in this machine, so
/usr/local/ is out of touch.
Ok, that was my last attempt.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 00:37

Message:
Eduardo,

your autogen problem can certainly be fixed. I have had some issues here
with similar products several times and it has always helped to upgrade the
involved components. 

Suggest you get the newest revisions of the following:
http://www.gnu.org/software/m4/m4.html
http://www.gnu.org/software/automake
http://www.gnu.org/software/autoconf

There are FTP servers available from those pages, choose the newest
version of the product you can find. The stuff installs the usual way with
'configure; make; make install'.

Once you've done that (typically installed to /usr/local), don'f forget to
add /usr/local to your path and try to run the autogen.sh of re-alpine
again. It should work.

What happens here is the following:
testuser@bianca:~> git clone
git://re-alpine.git.sourceforge.net/gitroot/re-alpine
Initialized empty Git repository in /home/testuser/re-alpine/.git/
remote: Counting objects: 5406, done.
remote: Compressing objects: 100% (2065/2065), done.
remote: Total 5406 (delta 3618), reused 5000 (delta 3283)
Receiving objects: 100% (5406/5406), 9.42 MiB | 347 KiB/s, done.
Resolving deltas: 100% (3618/3618), done.

testuser@bianca:~> cd re-alpine

testuser@bianca:~/re-alpine> ./autogen.sh 
Copying file ABOUT-NLS
Copying file config.rpath
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL'
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal

[The last warnings can be ignored]

Now we have a 'configure' that can be run as usual.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:00

Message:
Well, if that is the way it will be, then let it be that way. Just
remember, I can't build anything, nor for that matter test anything, or
cooperate with the project.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 23:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 23:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 23:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 22:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 13:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 04:05
Message generated for change (Comment added) made by schamane
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 19:18

Message:
My Debian boxes ask for ./config.sub and ./config.guess, too.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:11

Message:
I have made configure ungitignored and have commited the one I generated I
ask anyone that wishes to to test it out if it works for them. If so this
bug is closed.

The decision behind this:

I have checked multiple projects. Most do not include it. But some do:
gcc, glibc, emacs to name a few. As this is a minor thing I have decided to
include it back in. It will hopefully make it easier for those who cannot
update their systems to contribute.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 01:28

Message:
You were right. There was a typo. I do not have root access to this
machine.
Nevertheless. Do not worry about it. I will not anymore. You can safely
close the bug.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 01:20

Message:
Eduardo,

check the old SVN tree of Alpine. You will find an 'configure.ac' there.
Look into it and you should find a line like "Process this file with
autoconf to produce a configure script.".

There you can see that even the old 'configure' was produced this way
(using autoconf / autoconf etc.). Steve Hubert and his guys did just
additionally checkin the result to the SVN repo.

It is however uncommon to checkin production results to a repo (like you
would also not checkin fixed Makefiles, because they are created by running
'configure', or binaries as they are produced from object files, or object
files resulting from a compilation, because you've got the c-sources in the
repo, etc. you get the picture).

If you have no typo in your statements, then you do have 'root' privileges
on the box. So you have no problem to update your tools either in
/usr/local or /usr (though I would suggest using /usr/local to be on the
safe side).

In case I've understood you wrongly and you do not have root rights, then
you could add the tools to some local subdirectory of your homedir using
the --prefix option on running configure of the tools.

In case all of this fails, I can offer to send you a configure result once
from my box by email (drop me a mail in this case).

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:56

Message:
One more time, maybe this time I will get through.

* Alpine builds fine using "./configure && make"

Maybe you should know I do have root privileges in this machine, so
/usr/local/ is out of touch.
Ok, that was my last attempt.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 00:37

Message:
Eduardo,

your autogen problem can certainly be fixed. I have had some issues here
with similar products several times and it has always helped to upgrade the
involved components. 

Suggest you get the newest revisions of the following:
http://www.gnu.org/software/m4/m4.html
http://www.gnu.org/software/automake
http://www.gnu.org/software/autoconf

There are FTP servers available from those pages, choose the newest
version of the product you can find. The stuff installs the usual way with
'configure; make; make install'.

Once you've done that (typically installed to /usr/local), don'f forget to
add /usr/local to your path and try to run the autogen.sh of re-alpine
again. It should work.

What happens here is the following:
testuser@bianca:~> git clone
git://re-alpine.git.sourceforge.net/gitroot/re-alpine
Initialized empty Git repository in /home/testuser/re-alpine/.git/
remote: Counting objects: 5406, done.
remote: Compressing objects: 100% (2065/2065), done.
remote: Total 5406 (delta 3618), reused 5000 (delta 3283)
Receiving objects: 100% (5406/5406), 9.42 MiB | 347 KiB/s, done.
Resolving deltas: 100% (3618/3618), done.

testuser@bianca:~> cd re-alpine

testuser@bianca:~/re-alpine> ./autogen.sh 
Copying file ABOUT-NLS
Copying file config.rpath
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL'
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal

[The last warnings can be ignored]

Now we have a 'configure' that can be run as usual.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:00

Message:
Well, if that is the way it will be, then let it be that way. Just
remember, I can't build anything, nor for that matter test anything, or
cooperate with the project.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 23:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 23:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 23:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 22:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 13:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 04:05
Message generated for change (Comment added) made by ruskie3
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:26

Message:
Give it another try now. Added those two as well.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 19:18

Message:
My Debian boxes ask for ./config.sub and ./config.guess, too.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:11

Message:
I have made configure ungitignored and have commited the one I generated I
ask anyone that wishes to to test it out if it works for them. If so this
bug is closed.

The decision behind this:

I have checked multiple projects. Most do not include it. But some do:
gcc, glibc, emacs to name a few. As this is a minor thing I have decided to
include it back in. It will hopefully make it easier for those who cannot
update their systems to contribute.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 01:28

Message:
You were right. There was a typo. I do not have root access to this
machine.
Nevertheless. Do not worry about it. I will not anymore. You can safely
close the bug.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 01:20

Message:
Eduardo,

check the old SVN tree of Alpine. You will find an 'configure.ac' there.
Look into it and you should find a line like "Process this file with
autoconf to produce a configure script.".

There you can see that even the old 'configure' was produced this way
(using autoconf / autoconf etc.). Steve Hubert and his guys did just
additionally checkin the result to the SVN repo.

It is however uncommon to checkin production results to a repo (like you
would also not checkin fixed Makefiles, because they are created by running
'configure', or binaries as they are produced from object files, or object
files resulting from a compilation, because you've got the c-sources in the
repo, etc. you get the picture).

If you have no typo in your statements, then you do have 'root' privileges
on the box. So you have no problem to update your tools either in
/usr/local or /usr (though I would suggest using /usr/local to be on the
safe side).

In case I've understood you wrongly and you do not have root rights, then
you could add the tools to some local subdirectory of your homedir using
the --prefix option on running configure of the tools.

In case all of this fails, I can offer to send you a configure result once
from my box by email (drop me a mail in this case).

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:56

Message:
One more time, maybe this time I will get through.

* Alpine builds fine using "./configure && make"

Maybe you should know I do have root privileges in this machine, so
/usr/local/ is out of touch.
Ok, that was my last attempt.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 00:37

Message:
Eduardo,

your autogen problem can certainly be fixed. I have had some issues here
with similar products several times and it has always helped to upgrade the
involved components. 

Suggest you get the newest revisions of the following:
http://www.gnu.org/software/m4/m4.html
http://www.gnu.org/software/automake
http://www.gnu.org/software/autoconf

There are FTP servers available from those pages, choose the newest
version of the product you can find. The stuff installs the usual way with
'configure; make; make install'.

Once you've done that (typically installed to /usr/local), don'f forget to
add /usr/local to your path and try to run the autogen.sh of re-alpine
again. It should work.

What happens here is the following:
testuser@bianca:~> git clone
git://re-alpine.git.sourceforge.net/gitroot/re-alpine
Initialized empty Git repository in /home/testuser/re-alpine/.git/
remote: Counting objects: 5406, done.
remote: Compressing objects: 100% (2065/2065), done.
remote: Total 5406 (delta 3618), reused 5000 (delta 3283)
Receiving objects: 100% (5406/5406), 9.42 MiB | 347 KiB/s, done.
Resolving deltas: 100% (3618/3618), done.

testuser@bianca:~> cd re-alpine

testuser@bianca:~/re-alpine> ./autogen.sh 
Copying file ABOUT-NLS
Copying file config.rpath
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL'
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal

[The last warnings can be ignored]

Now we have a 'configure' that can be run as usual.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:00

Message:
Well, if that is the way it will be, then let it be that way. Just
remember, I can't build anything, nor for that matter test anything, or
cooperate with the project.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 23:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 23:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 23:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 22:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 13:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 04:05
Message generated for change (Comment added) made by schamane
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 19:33

Message:
I was too fast with my comment. Sorry. After adding ./config.sub and
./config.guess ./configure stops nevertheless:

...
checking for sigaddset... yes
checking for sigprocmask... yes
checking for library containing syslog... none required
configure: * * * SSL file "/etc/ssl/certs/factory.pem" is missing.
configure: * * *   This might indicate that CA certs did not get properly
configure: * * *   installed.  If you get certificate validation failures
configure: * * *   in Alpine, this might be the reason for them.
configure: * * * TCL libraries could not be found.
configure: * * * WEB ALPINE COMPONENT WILL NOT BE BUILT.
configure: creating ./config.status
config.status: error: cannot find input file: m4/Makefile.in

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:26

Message:
Give it another try now. Added those two as well.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 19:18

Message:
My Debian boxes ask for ./config.sub and ./config.guess, too.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:11

Message:
I have made configure ungitignored and have commited the one I generated I
ask anyone that wishes to to test it out if it works for them. If so this
bug is closed.

The decision behind this:

I have checked multiple projects. Most do not include it. But some do:
gcc, glibc, emacs to name a few. As this is a minor thing I have decided to
include it back in. It will hopefully make it easier for those who cannot
update their systems to contribute.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 01:28

Message:
You were right. There was a typo. I do not have root access to this
machine.
Nevertheless. Do not worry about it. I will not anymore. You can safely
close the bug.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 01:20

Message:
Eduardo,

check the old SVN tree of Alpine. You will find an 'configure.ac' there.
Look into it and you should find a line like "Process this file with
autoconf to produce a configure script.".

There you can see that even the old 'configure' was produced this way
(using autoconf / autoconf etc.). Steve Hubert and his guys did just
additionally checkin the result to the SVN repo.

It is however uncommon to checkin production results to a repo (like you
would also not checkin fixed Makefiles, because they are created by running
'configure', or binaries as they are produced from object files, or object
files resulting from a compilation, because you've got the c-sources in the
repo, etc. you get the picture).

If you have no typo in your statements, then you do have 'root' privileges
on the box. So you have no problem to update your tools either in
/usr/local or /usr (though I would suggest using /usr/local to be on the
safe side).

In case I've understood you wrongly and you do not have root rights, then
you could add the tools to some local subdirectory of your homedir using
the --prefix option on running configure of the tools.

In case all of this fails, I can offer to send you a configure result once
from my box by email (drop me a mail in this case).

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:56

Message:
One more time, maybe this time I will get through.

* Alpine builds fine using "./configure && make"

Maybe you should know I do have root privileges in this machine, so
/usr/local/ is out of touch.
Ok, that was my last attempt.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 00:37

Message:
Eduardo,

your autogen problem can certainly be fixed. I have had some issues here
with similar products several times and it has always helped to upgrade the
involved components. 

Suggest you get the newest revisions of the following:
http://www.gnu.org/software/m4/m4.html
http://www.gnu.org/software/automake
http://www.gnu.org/software/autoconf

There are FTP servers available from those pages, choose the newest
version of the product you can find. The stuff installs the usual way with
'configure; make; make install'.

Once you've done that (typically installed to /usr/local), don'f forget to
add /usr/local to your path and try to run the autogen.sh of re-alpine
again. It should work.

What happens here is the following:
testuser@bianca:~> git clone
git://re-alpine.git.sourceforge.net/gitroot/re-alpine
Initialized empty Git repository in /home/testuser/re-alpine/.git/
remote: Counting objects: 5406, done.
remote: Compressing objects: 100% (2065/2065), done.
remote: Total 5406 (delta 3618), reused 5000 (delta 3283)
Receiving objects: 100% (5406/5406), 9.42 MiB | 347 KiB/s, done.
Resolving deltas: 100% (3618/3618), done.

testuser@bianca:~> cd re-alpine

testuser@bianca:~/re-alpine> ./autogen.sh 
Copying file ABOUT-NLS
Copying file config.rpath
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL'
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal

[The last warnings can be ignored]

Now we have a 'configure' that can be run as usual.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:00

Message:
Well, if that is the way it will be, then let it be that way. Just
remember, I can't build anything, nor for that matter test anything, or
cooperate with the project.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 23:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 23:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 23:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 22:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 13:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 04:05
Message generated for change (Comment added) made by ruskie3
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:37

Message:
Seems like it will need more or less everything or near everything
included. I'll try doing that or someone else can. The .gitiignore file 
has comments so shouldn't be to hard.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 19:33

Message:
I was too fast with my comment. Sorry. After adding ./config.sub and
./config.guess ./configure stops nevertheless:

...
checking for sigaddset... yes
checking for sigprocmask... yes
checking for library containing syslog... none required
configure: * * * SSL file "/etc/ssl/certs/factory.pem" is missing.
configure: * * *   This might indicate that CA certs did not get properly
configure: * * *   installed.  If you get certificate validation failures
configure: * * *   in Alpine, this might be the reason for them.
configure: * * * TCL libraries could not be found.
configure: * * * WEB ALPINE COMPONENT WILL NOT BE BUILT.
configure: creating ./config.status
config.status: error: cannot find input file: m4/Makefile.in

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:26

Message:
Give it another try now. Added those two as well.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 19:18

Message:
My Debian boxes ask for ./config.sub and ./config.guess, too.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:11

Message:
I have made configure ungitignored and have commited the one I generated I
ask anyone that wishes to to test it out if it works for them. If so this
bug is closed.

The decision behind this:

I have checked multiple projects. Most do not include it. But some do:
gcc, glibc, emacs to name a few. As this is a minor thing I have decided to
include it back in. It will hopefully make it easier for those who cannot
update their systems to contribute.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 01:28

Message:
You were right. There was a typo. I do not have root access to this
machine.
Nevertheless. Do not worry about it. I will not anymore. You can safely
close the bug.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 01:20

Message:
Eduardo,

check the old SVN tree of Alpine. You will find an 'configure.ac' there.
Look into it and you should find a line like "Process this file with
autoconf to produce a configure script.".

There you can see that even the old 'configure' was produced this way
(using autoconf / autoconf etc.). Steve Hubert and his guys did just
additionally checkin the result to the SVN repo.

It is however uncommon to checkin production results to a repo (like you
would also not checkin fixed Makefiles, because they are created by running
'configure', or binaries as they are produced from object files, or object
files resulting from a compilation, because you've got the c-sources in the
repo, etc. you get the picture).

If you have no typo in your statements, then you do have 'root' privileges
on the box. So you have no problem to update your tools either in
/usr/local or /usr (though I would suggest using /usr/local to be on the
safe side).

In case I've understood you wrongly and you do not have root rights, then
you could add the tools to some local subdirectory of your homedir using
the --prefix option on running configure of the tools.

In case all of this fails, I can offer to send you a configure result once
from my box by email (drop me a mail in this case).

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:56

Message:
One more time, maybe this time I will get through.

* Alpine builds fine using "./configure && make"

Maybe you should know I do have root privileges in this machine, so
/usr/local/ is out of touch.
Ok, that was my last attempt.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 00:37

Message:
Eduardo,

your autogen problem can certainly be fixed. I have had some issues here
with similar products several times and it has always helped to upgrade the
involved components. 

Suggest you get the newest revisions of the following:
http://www.gnu.org/software/m4/m4.html
http://www.gnu.org/software/automake
http://www.gnu.org/software/autoconf

There are FTP servers available from those pages, choose the newest
version of the product you can find. The stuff installs the usual way with
'configure; make; make install'.

Once you've done that (typically installed to /usr/local), don'f forget to
add /usr/local to your path and try to run the autogen.sh of re-alpine
again. It should work.

What happens here is the following:
testuser@bianca:~> git clone
git://re-alpine.git.sourceforge.net/gitroot/re-alpine
Initialized empty Git repository in /home/testuser/re-alpine/.git/
remote: Counting objects: 5406, done.
remote: Compressing objects: 100% (2065/2065), done.
remote: Total 5406 (delta 3618), reused 5000 (delta 3283)
Receiving objects: 100% (5406/5406), 9.42 MiB | 347 KiB/s, done.
Resolving deltas: 100% (3618/3618), done.

testuser@bianca:~> cd re-alpine

testuser@bianca:~/re-alpine> ./autogen.sh 
Copying file ABOUT-NLS
Copying file config.rpath
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL'
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal

[The last warnings can be ignored]

Now we have a 'configure' that can be run as usual.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:00

Message:
Well, if that is the way it will be, then let it be that way. Just
remember, I can't build anything, nor for that matter test anything, or
cooperate with the project.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 23:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 23:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 23:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 22:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 13:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 04:05
Message generated for change (Comment added) made by ruskie3
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:41

Message:
Ok updated m4 dir. Give it another try.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:37

Message:
Seems like it will need more or less everything or near everything
included. I'll try doing that or someone else can. The .gitiignore file 
has comments so shouldn't be to hard.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 19:33

Message:
I was too fast with my comment. Sorry. After adding ./config.sub and
./config.guess ./configure stops nevertheless:

...
checking for sigaddset... yes
checking for sigprocmask... yes
checking for library containing syslog... none required
configure: * * * SSL file "/etc/ssl/certs/factory.pem" is missing.
configure: * * *   This might indicate that CA certs did not get properly
configure: * * *   installed.  If you get certificate validation failures
configure: * * *   in Alpine, this might be the reason for them.
configure: * * * TCL libraries could not be found.
configure: * * * WEB ALPINE COMPONENT WILL NOT BE BUILT.
configure: creating ./config.status
config.status: error: cannot find input file: m4/Makefile.in

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:26

Message:
Give it another try now. Added those two as well.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 19:18

Message:
My Debian boxes ask for ./config.sub and ./config.guess, too.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:11

Message:
I have made configure ungitignored and have commited the one I generated I
ask anyone that wishes to to test it out if it works for them. If so this
bug is closed.

The decision behind this:

I have checked multiple projects. Most do not include it. But some do:
gcc, glibc, emacs to name a few. As this is a minor thing I have decided to
include it back in. It will hopefully make it easier for those who cannot
update their systems to contribute.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 01:28

Message:
You were right. There was a typo. I do not have root access to this
machine.
Nevertheless. Do not worry about it. I will not anymore. You can safely
close the bug.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 01:20

Message:
Eduardo,

check the old SVN tree of Alpine. You will find an 'configure.ac' there.
Look into it and you should find a line like "Process this file with
autoconf to produce a configure script.".

There you can see that even the old 'configure' was produced this way
(using autoconf / autoconf etc.). Steve Hubert and his guys did just
additionally checkin the result to the SVN repo.

It is however uncommon to checkin production results to a repo (like you
would also not checkin fixed Makefiles, because they are created by running
'configure', or binaries as they are produced from object files, or object
files resulting from a compilation, because you've got the c-sources in the
repo, etc. you get the picture).

If you have no typo in your statements, then you do have 'root' privileges
on the box. So you have no problem to update your tools either in
/usr/local or /usr (though I would suggest using /usr/local to be on the
safe side).

In case I've understood you wrongly and you do not have root rights, then
you could add the tools to some local subdirectory of your homedir using
the --prefix option on running configure of the tools.

In case all of this fails, I can offer to send you a configure result once
from my box by email (drop me a mail in this case).

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:56

Message:
One more time, maybe this time I will get through.

* Alpine builds fine using "./configure && make"

Maybe you should know I do have root privileges in this machine, so
/usr/local/ is out of touch.
Ok, that was my last attempt.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 00:37

Message:
Eduardo,

your autogen problem can certainly be fixed. I have had some issues here
with similar products several times and it has always helped to upgrade the
involved components. 

Suggest you get the newest revisions of the following:
http://www.gnu.org/software/m4/m4.html
http://www.gnu.org/software/automake
http://www.gnu.org/software/autoconf

There are FTP servers available from those pages, choose the newest
version of the product you can find. The stuff installs the usual way with
'configure; make; make install'.

Once you've done that (typically installed to /usr/local), don'f forget to
add /usr/local to your path and try to run the autogen.sh of re-alpine
again. It should work.

What happens here is the following:
testuser@bianca:~> git clone
git://re-alpine.git.sourceforge.net/gitroot/re-alpine
Initialized empty Git repository in /home/testuser/re-alpine/.git/
remote: Counting objects: 5406, done.
remote: Compressing objects: 100% (2065/2065), done.
remote: Total 5406 (delta 3618), reused 5000 (delta 3283)
Receiving objects: 100% (5406/5406), 9.42 MiB | 347 KiB/s, done.
Resolving deltas: 100% (3618/3618), done.

testuser@bianca:~> cd re-alpine

testuser@bianca:~/re-alpine> ./autogen.sh 
Copying file ABOUT-NLS
Copying file config.rpath
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL'
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal

[The last warnings can be ignored]

Now we have a 'configure' that can be run as usual.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:00

Message:
Well, if that is the way it will be, then let it be that way. Just
remember, I can't build anything, nor for that matter test anything, or
cooperate with the project.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 23:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 23:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 23:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 22:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 13:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 04:05
Message generated for change (Comment added) made by ruskie3
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 21:41

Message:
OK added I think most of the other missing bits. I tested it and it seems
to have worked. Try it out and if it's all good we can close this.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:41

Message:
Ok updated m4 dir. Give it another try.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:37

Message:
Seems like it will need more or less everything or near everything
included. I'll try doing that or someone else can. The .gitiignore file 
has comments so shouldn't be to hard.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 19:33

Message:
I was too fast with my comment. Sorry. After adding ./config.sub and
./config.guess ./configure stops nevertheless:

...
checking for sigaddset... yes
checking for sigprocmask... yes
checking for library containing syslog... none required
configure: * * * SSL file "/etc/ssl/certs/factory.pem" is missing.
configure: * * *   This might indicate that CA certs did not get properly
configure: * * *   installed.  If you get certificate validation failures
configure: * * *   in Alpine, this might be the reason for them.
configure: * * * TCL libraries could not be found.
configure: * * * WEB ALPINE COMPONENT WILL NOT BE BUILT.
configure: creating ./config.status
config.status: error: cannot find input file: m4/Makefile.in

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:26

Message:
Give it another try now. Added those two as well.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 19:18

Message:
My Debian boxes ask for ./config.sub and ./config.guess, too.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:11

Message:
I have made configure ungitignored and have commited the one I generated I
ask anyone that wishes to to test it out if it works for them. If so this
bug is closed.

The decision behind this:

I have checked multiple projects. Most do not include it. But some do:
gcc, glibc, emacs to name a few. As this is a minor thing I have decided to
include it back in. It will hopefully make it easier for those who cannot
update their systems to contribute.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 01:28

Message:
You were right. There was a typo. I do not have root access to this
machine.
Nevertheless. Do not worry about it. I will not anymore. You can safely
close the bug.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 01:20

Message:
Eduardo,

check the old SVN tree of Alpine. You will find an 'configure.ac' there.
Look into it and you should find a line like "Process this file with
autoconf to produce a configure script.".

There you can see that even the old 'configure' was produced this way
(using autoconf / autoconf etc.). Steve Hubert and his guys did just
additionally checkin the result to the SVN repo.

It is however uncommon to checkin production results to a repo (like you
would also not checkin fixed Makefiles, because they are created by running
'configure', or binaries as they are produced from object files, or object
files resulting from a compilation, because you've got the c-sources in the
repo, etc. you get the picture).

If you have no typo in your statements, then you do have 'root' privileges
on the box. So you have no problem to update your tools either in
/usr/local or /usr (though I would suggest using /usr/local to be on the
safe side).

In case I've understood you wrongly and you do not have root rights, then
you could add the tools to some local subdirectory of your homedir using
the --prefix option on running configure of the tools.

In case all of this fails, I can offer to send you a configure result once
from my box by email (drop me a mail in this case).

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:56

Message:
One more time, maybe this time I will get through.

* Alpine builds fine using "./configure && make"

Maybe you should know I do have root privileges in this machine, so
/usr/local/ is out of touch.
Ok, that was my last attempt.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 00:37

Message:
Eduardo,

your autogen problem can certainly be fixed. I have had some issues here
with similar products several times and it has always helped to upgrade the
involved components. 

Suggest you get the newest revisions of the following:
http://www.gnu.org/software/m4/m4.html
http://www.gnu.org/software/automake
http://www.gnu.org/software/autoconf

There are FTP servers available from those pages, choose the newest
version of the product you can find. The stuff installs the usual way with
'configure; make; make install'.

Once you've done that (typically installed to /usr/local), don'f forget to
add /usr/local to your path and try to run the autogen.sh of re-alpine
again. It should work.

What happens here is the following:
testuser@bianca:~> git clone
git://re-alpine.git.sourceforge.net/gitroot/re-alpine
Initialized empty Git repository in /home/testuser/re-alpine/.git/
remote: Counting objects: 5406, done.
remote: Compressing objects: 100% (2065/2065), done.
remote: Total 5406 (delta 3618), reused 5000 (delta 3283)
Receiving objects: 100% (5406/5406), 9.42 MiB | 347 KiB/s, done.
Resolving deltas: 100% (3618/3618), done.

testuser@bianca:~> cd re-alpine

testuser@bianca:~/re-alpine> ./autogen.sh 
Copying file ABOUT-NLS
Copying file config.rpath
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL'
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal

[The last warnings can be ignored]

Now we have a 'configure' that can be run as usual.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:00

Message:
Well, if that is the way it will be, then let it be that way. Just
remember, I can't build anything, nor for that matter test anything, or
cooperate with the project.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 23:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 23:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 23:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 22:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 13:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 04:05
Message generated for change (Comment added) made by schamane
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 21:54

Message:
Ruskie, you were faster than I could ever be. It's time that I learn _git_
;)
I can confirm that "git clone ... ; ./configure ..." now works on Debian 5
(Lenny) and Debian Testing:

$ git pull && ./configure >/dev/null && echo yes
Already up-to-date.
/bin/rm: cannot remove `libtoolT': No such file or directory
yes

(The error with libtoolT can be safely ignored for now.)
Thanks ruskie!

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 21:41

Message:
OK added I think most of the other missing bits. I tested it and it seems
to have worked. Try it out and if it's all good we can close this.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:41

Message:
Ok updated m4 dir. Give it another try.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:37

Message:
Seems like it will need more or less everything or near everything
included. I'll try doing that or someone else can. The .gitiignore file 
has comments so shouldn't be to hard.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 19:33

Message:
I was too fast with my comment. Sorry. After adding ./config.sub and
./config.guess ./configure stops nevertheless:

...
checking for sigaddset... yes
checking for sigprocmask... yes
checking for library containing syslog... none required
configure: * * * SSL file "/etc/ssl/certs/factory.pem" is missing.
configure: * * *   This might indicate that CA certs did not get properly
configure: * * *   installed.  If you get certificate validation failures
configure: * * *   in Alpine, this might be the reason for them.
configure: * * * TCL libraries could not be found.
configure: * * * WEB ALPINE COMPONENT WILL NOT BE BUILT.
configure: creating ./config.status
config.status: error: cannot find input file: m4/Makefile.in

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:26

Message:
Give it another try now. Added those two as well.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 19:18

Message:
My Debian boxes ask for ./config.sub and ./config.guess, too.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:11

Message:
I have made configure ungitignored and have commited the one I generated I
ask anyone that wishes to to test it out if it works for them. If so this
bug is closed.

The decision behind this:

I have checked multiple projects. Most do not include it. But some do:
gcc, glibc, emacs to name a few. As this is a minor thing I have decided to
include it back in. It will hopefully make it easier for those who cannot
update their systems to contribute.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 01:28

Message:
You were right. There was a typo. I do not have root access to this
machine.
Nevertheless. Do not worry about it. I will not anymore. You can safely
close the bug.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 01:20

Message:
Eduardo,

check the old SVN tree of Alpine. You will find an 'configure.ac' there.
Look into it and you should find a line like "Process this file with
autoconf to produce a configure script.".

There you can see that even the old 'configure' was produced this way
(using autoconf / autoconf etc.). Steve Hubert and his guys did just
additionally checkin the result to the SVN repo.

It is however uncommon to checkin production results to a repo (like you
would also not checkin fixed Makefiles, because they are created by running
'configure', or binaries as they are produced from object files, or object
files resulting from a compilation, because you've got the c-sources in the
repo, etc. you get the picture).

If you have no typo in your statements, then you do have 'root' privileges
on the box. So you have no problem to update your tools either in
/usr/local or /usr (though I would suggest using /usr/local to be on the
safe side).

In case I've understood you wrongly and you do not have root rights, then
you could add the tools to some local subdirectory of your homedir using
the --prefix option on running configure of the tools.

In case all of this fails, I can offer to send you a configure result once
from my box by email (drop me a mail in this case).

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:56

Message:
One more time, maybe this time I will get through.

* Alpine builds fine using "./configure && make"

Maybe you should know I do have root privileges in this machine, so
/usr/local/ is out of touch.
Ok, that was my last attempt.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 00:37

Message:
Eduardo,

your autogen problem can certainly be fixed. I have had some issues here
with similar products several times and it has always helped to upgrade the
involved components. 

Suggest you get the newest revisions of the following:
http://www.gnu.org/software/m4/m4.html
http://www.gnu.org/software/automake
http://www.gnu.org/software/autoconf

There are FTP servers available from those pages, choose the newest
version of the product you can find. The stuff installs the usual way with
'configure; make; make install'.

Once you've done that (typically installed to /usr/local), don'f forget to
add /usr/local to your path and try to run the autogen.sh of re-alpine
again. It should work.

What happens here is the following:
testuser@bianca:~> git clone
git://re-alpine.git.sourceforge.net/gitroot/re-alpine
Initialized empty Git repository in /home/testuser/re-alpine/.git/
remote: Counting objects: 5406, done.
remote: Compressing objects: 100% (2065/2065), done.
remote: Total 5406 (delta 3618), reused 5000 (delta 3283)
Receiving objects: 100% (5406/5406), 9.42 MiB | 347 KiB/s, done.
Resolving deltas: 100% (3618/3618), done.

testuser@bianca:~> cd re-alpine

testuser@bianca:~/re-alpine> ./autogen.sh 
Copying file ABOUT-NLS
Copying file config.rpath
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL'
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal

[The last warnings can be ignored]

Now we have a 'configure' that can be run as usual.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:00

Message:
Well, if that is the way it will be, then let it be that way. Just
remember, I can't build anything, nor for that matter test anything, or
cooperate with the project.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 23:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 23:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 23:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 22:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 13:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

[Re-alpine-bugs] [ re-alpine-Bugs-2832419 ] Re-Alpine fails to build

[SourceForge.net <no...@so...>]

Bugs item #2832419, was opened at 2009-08-05 04:05
Message generated for change (Settings changed) made by ruskie3
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 9
Private: No
Submitted By: Eduardo Chappa (chappa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Re-Alpine fails to build

Initial Comment:
The new method to build re-alpine fails. If I execute autogen.sh, I get a failure. Here are a few lines of the failure.

String found where operator expected at /usr/bin/autoreconf line 219, near 
"error "cannot find `configure.ac'""
         (Do you need to predeclare error?)
String found where operator expected at /usr/bin/autoreconf line 240, near 
"verbose "$configure_ac: not using Autoconf""
         (Do you need to predeclare verbose?)
String found where operator expected at /usr/bin/autoreconf line 267, near 
"verbose "$configure_ac: not using Gettext""
         (Do you need to predeclare verbose?)

The old method to build (./configure...) used to work. I suspect the project should return to the old way, since this is not a reliable way to build re-alpine.

----------------------------------------------------------------------

>Comment By: Andraž Levstik (ruskie3)
Date: 2010-07-16 07:49

Message:
OK since nobody else had any issues I'm marking this as fixed, closed

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 21:54

Message:
Ruskie, you were faster than I could ever be. It's time that I learn _git_
;)
I can confirm that "git clone ... ; ./configure ..." now works on Debian 5
(Lenny) and Debian Testing:

$ git pull && ./configure >/dev/null && echo yes
Already up-to-date.
/bin/rm: cannot remove `libtoolT': No such file or directory
yes

(The error with libtoolT can be safely ignored for now.)
Thanks ruskie!

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 21:41

Message:
OK added I think most of the other missing bits. I tested it and it seems
to have worked. Try it out and if it's all good we can close this.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:41

Message:
Ok updated m4 dir. Give it another try.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:37

Message:
Seems like it will need more or less everything or near everything
included. I'll try doing that or someone else can. The .gitiignore file 
has comments so shouldn't be to hard.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 19:33

Message:
I was too fast with my comment. Sorry. After adding ./config.sub and
./config.guess ./configure stops nevertheless:

...
checking for sigaddset... yes
checking for sigprocmask... yes
checking for library containing syslog... none required
configure: * * * SSL file "/etc/ssl/certs/factory.pem" is missing.
configure: * * *   This might indicate that CA certs did not get properly
configure: * * *   installed.  If you get certificate validation failures
configure: * * *   in Alpine, this might be the reason for them.
configure: * * * TCL libraries could not be found.
configure: * * * WEB ALPINE COMPONENT WILL NOT BE BUILT.
configure: creating ./config.status
config.status: error: cannot find input file: m4/Makefile.in

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:26

Message:
Give it another try now. Added those two as well.

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-09 19:18

Message:
My Debian boxes ask for ./config.sub and ./config.guess, too.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-09 19:11

Message:
I have made configure ungitignored and have commited the one I generated I
ask anyone that wishes to to test it out if it works for them. If so this
bug is closed.

The decision behind this:

I have checked multiple projects. Most do not include it. But some do:
gcc, glibc, emacs to name a few. As this is a minor thing I have decided to
include it back in. It will hopefully make it easier for those who cannot
update their systems to contribute.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 01:28

Message:
You were right. There was a typo. I do not have root access to this
machine.
Nevertheless. Do not worry about it. I will not anymore. You can safely
close the bug.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 01:20

Message:
Eduardo,

check the old SVN tree of Alpine. You will find an 'configure.ac' there.
Look into it and you should find a line like "Process this file with
autoconf to produce a configure script.".

There you can see that even the old 'configure' was produced this way
(using autoconf / autoconf etc.). Steve Hubert and his guys did just
additionally checkin the result to the SVN repo.

It is however uncommon to checkin production results to a repo (like you
would also not checkin fixed Makefiles, because they are created by running
'configure', or binaries as they are produced from object files, or object
files resulting from a compilation, because you've got the c-sources in the
repo, etc. you get the picture).

If you have no typo in your statements, then you do have 'root' privileges
on the box. So you have no problem to update your tools either in
/usr/local or /usr (though I would suggest using /usr/local to be on the
safe side).

In case I've understood you wrongly and you do not have root rights, then
you could add the tools to some local subdirectory of your homedir using
the --prefix option on running configure of the tools.

In case all of this fails, I can offer to send you a configure result once
from my box by email (drop me a mail in this case).

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:56

Message:
One more time, maybe this time I will get through.

* Alpine builds fine using "./configure && make"

Maybe you should know I do have root privileges in this machine, so
/usr/local/ is out of touch.
Ok, that was my last attempt.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-08 00:37

Message:
Eduardo,

your autogen problem can certainly be fixed. I have had some issues here
with similar products several times and it has always helped to upgrade the
involved components. 

Suggest you get the newest revisions of the following:
http://www.gnu.org/software/m4/m4.html
http://www.gnu.org/software/automake
http://www.gnu.org/software/autoconf

There are FTP servers available from those pages, choose the newest
version of the product you can find. The stuff installs the usual way with
'configure; make; make install'.

Once you've done that (typically installed to /usr/local), don'f forget to
add /usr/local to your path and try to run the autogen.sh of re-alpine
again. It should work.

What happens here is the following:
testuser@bianca:~> git clone
git://re-alpine.git.sourceforge.net/gitroot/re-alpine
Initialized empty Git repository in /home/testuser/re-alpine/.git/
remote: Counting objects: 5406, done.
remote: Compressing objects: 100% (2065/2065), done.
remote: Total 5406 (delta 3618), reused 5000 (delta 3283)
Receiving objects: 100% (5406/5406), 9.42 MiB | 347 KiB/s, done.
Resolving deltas: 100% (3618/3618), done.

testuser@bianca:~> cd re-alpine

testuser@bianca:~/re-alpine> ./autogen.sh 
Copying file ABOUT-NLS
Copying file config.rpath
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL'
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13:   run info '(automake)Extending
aclocal'
/usr/local/share/aclocal/smpeg.m4:13:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal

[The last warnings can be ignored]

Now we have a 'configure' that can be run as usual.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-08 00:00

Message:
Well, if that is the way it will be, then let it be that way. Just
remember, I can't build anything, nor for that matter test anything, or
cooperate with the project.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-07 23:56

Message:
Hi Guys,

the usual way how this is handled is that the source repository does not
include a checked in fixed 'configure' script, but  the autogen.sh etc.
stuff and that the configure is generated by it.

However, when a release is produced and is made available as a compressed
tarball, then this tarball then contains a prebuild 'configure' script (and
the autogen.sh stuff is not present).

For the autogen.sh stuff to work, one usually needs a recent system,
especially the GNU autoconf and automake tools.

Regards

Guido

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 23:32

Message:
Ruskie,

  Thank you for your message. I see that you are making a few assumptions
about the way things should work. In real life things do not work that
way.

  I have experience building software, and the configure script is always
present in it. You think it is wrong to provide it, and by that token you
are saying that many developers are wrong. It is fine if you think that
way, but it is not fine that because you think that way, then I can not
build this software. You can try to push your philosophy, but when that
interferes with my work then we have a problem. The solution is simple.
Generate the files, as many projects do, distribute them and then let the
users regenerate them if the want to.

What do you suggest we do?  I suggest that we do what we all know that
works.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-07 23:23

Message:
Hmmm I guess I was under the impression that most people knew how autotools
based build systems work.

I'll try to give a brief overview.

a) you have configure.ac, Makefile.am and possibly other supporting files.
This is where you modify build options and other such things.

b) you run various autotools in the dir with those files example
autoreconf which is what autogen.sh calls

c) this then generates a usable and working ./configure script

d) you then run the generated ./configure script and it will produce a
Makefile

e) you run make which uses the generated Makefile and builds the final
product

The ONLY difference between the old method as you say is that someone at
UW had to run steps A through C and commit the generated configure script.
This for all intents and purposes is wrong as this is generated code and
should not be present in the repository. It should be generated before
releasing and added to the final tarball though.

Can you check after running autogen.sh if you get a configure script in
your directory if not can you please provide the following:

autoreconf --version

and try running in the source dir:
autoreconf -ifv

And provide the complete output. What distribution(or system) and it's
version might help as well.
And yes this was tested before commiting and it worked.

My version of autoreconf is:
autoreconf (GNU Autoconf) 2.63

I am trying to solve this in the correct way not the fastest. So bear with
me on this. If this entails a month of trial and error and discussing about
it so be it if we can then make a proper decision on this.

----------------------------------------------------------------------

Comment By: Eduardo Chappa (chappa)
Date: 2009-08-07 22:42

Message:
If re-alpine moves to another build system and it works, it is fine, but
the fact that there is a plan to move to another system is little to no
solution to this problem. Re-Alpine does not build and nothing I can do on
this side makes it work. Not running configure, nor trying to recreate the
files.

On the flip side, I can build Alpine in the same machine.

Bottom line: autogen.sh breaks the build of Re-Alpine. The current method
is not the best. I can not generate the makefiles. Things are broken.

Let me put it this way. I am allowed to write to the repository, and in
particular I am allowed to
make Re-Alpine build without having anyone generate files, but this is not
a Wiki. This is a "community effort", and not an imposition of one idea
over another idea, so could we have the system that builds for everyone,
instead of the system that does not work? Better yet, could we agree that
we are going to test changes and then write the repository with those
changes once we have an idea that those changes work?

Do I make sense?

-- 
Eduardo

----------------------------------------------------------------------

Comment By: Andreas Schamanek (schamane)
Date: 2009-08-07 13:22

Message:
Eduardo, you did not specifiy what system you used where autogen.sh failed.
And, can you tell us whether the ./configure provided in the 2.01 snapshot
works?
If it does I'd consider this a low priority issue. As ruskie said was
plans to migrate to another build system [cf.
https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LNX.2.01.0908031409590.2296%40freya
]
HTH.

----------------------------------------------------------------------

Comment By: Andraž Levstik (ruskie3)
Date: 2009-08-05 07:26

Message:
The autoreconf generates a configure. This is how it's supposed to work.
Usually autogen.sh uses a few more things.

You could test aclocal && libtoolize && automake -a && autoconf

Or any of the various permutations. The way I see it it probably needs
some fixups in the template files and ac files to work as it should as atm
it spews out a few errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1128048&aid=2832419&group_id=264924