Hi, I'm trying to add a cvs variant to the slrn-devel portfile. As now i can fetch the sources with this: variant cvs { fetch.type cvs cvs.root :pserver:anonymous@slrn.cvs.sourceforge.net:/cvsroot/slrn cvs.module slrn cvs.password cvs.date 20070717 version ${version}-${cvs.date} worksrcdir slrn pre-configure { autopoint -f; aclocal -I autoconf; autoheader; automake --foreign --add-missing; autoconf; } depends_build-append port:autoconf port:automake } I can't pass the org.macports.configure phase because I should execute the autogen.sh script instead of ./configure. Autogen.sh checks if automake autoconf and autopoint exist and than executes: ------------------------------- autopoint -f; aclocal -I autoconf; autoheader; automake --foreign --add-missing; autoconf; ./configure $@ ------------------------------- I'd like to run the first 5 commands before running configure, but the pre-configure hook seems to be ignored. What I get is always: [...] ---> Verifying checksum(s) for slrn-devel ---> Extracting slrn-devel ---> Configuring slrn-devel Error: Target org.macports.configure returned: no such file or directory Warning: the following items did not execute (for slrn-devel): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.archive org.macports.install Error: Status 1 encountered during processing. Which is the right way to address this problem? Thanks, Gufo
On Aug 10, 2007, at 12:34, Sbranzo wrote:
I'm trying to add a cvs variant to the slrn-devel portfile. As now i can fetch the sources with this:
variant cvs { fetch.type cvs
cvs.root :pserver:anonymous@slrn.cvs.sourceforge.net:/ cvsroot/slrn cvs.module slrn cvs.password cvs.date 20070717 version ${version}-${cvs.date} worksrcdir slrn pre-configure { autopoint -f; aclocal -I autoconf; autoheader; automake --foreign --add-missing; autoconf; } depends_build-append port:autoconf port:automake }
I can't pass the org.macports.configure phase because I should execute the autogen.sh script instead of ./configure.
Autogen.sh checks if automake autoconf and autopoint exist and than executes: ------------------------------- autopoint -f; aclocal -I autoconf; autoheader; automake --foreign --add-missing; autoconf;
./configure $@ -------------------------------
I'd like to run the first 5 commands before running configure, but the pre-configure hook seems to be ignored.
What I get is always:
[...] ---> Verifying checksum(s) for slrn-devel ---> Extracting slrn-devel ---> Configuring slrn-devel Error: Target org.macports.configure returned: no such file or directory Warning: the following items did not execute (for slrn-devel): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.archive org.macports.install Error: Status 1 encountered during processing.
Which is the right way to address this problem?
Why are you adding such a variant? Under which circumstances might a user want, or not want, to select it? I'm trying to figure out why you don't just fetch from CVS all the time, as that would seem to simplify things, wouldn't it? Variants are not supposed to change the version of the installed software, so if it's the same version, why would anyone care whether it's fetched from CVS or somewhere else, so long as it's fetched? The immediate answer to your question, I think, is that the commands you are issuing are not valid TCL commands, and are therefore are not getting executed, and therefore the ./configure script, which the configure phase it trying to run, does not exist, hence the error message about no such file or directory. Hopefully if you would run the install in debug mode ("sudo port -dv install"), error messages to this effect would be printed. I think you would need something like this: pre-configure { system "cd ${worksrcdir} && autopoint -f" system "cd ${worksrcdir} && aclocal -I autoconf" system "cd ${worksrcdir} && autoheader" system "cd ${worksrcdir} && automake --foreign --add- missing" system "cd ${worksrcdir} && autoconf" }
Le 11 août 07 à 03:17, Ryan Schmidt a écrit :
On Aug 10, 2007, at 12:34, Sbranzo wrote:
I'm trying to add a cvs variant to the slrn-devel portfile. As now i can fetch the sources with this:
variant cvs { fetch.type cvs
cvs.root :pserver:anonymous@slrn.cvs.sourceforge.net:/ cvsroot/slrn cvs.module slrn cvs.password cvs.date 20070717 version ${version}-${cvs.date} worksrcdir slrn pre-configure { autopoint -f; aclocal -I autoconf; autoheader; automake --foreign --add-missing; autoconf; } depends_build-append port:autoconf port:automake }
I can't pass the org.macports.configure phase because I should execute the autogen.sh script instead of ./configure.
Autogen.sh checks if automake autoconf and autopoint exist and than executes: ------------------------------- autopoint -f; aclocal -I autoconf; autoheader; automake --foreign --add-missing; autoconf;
./configure $@ -------------------------------
I'd like to run the first 5 commands before running configure, but the pre-configure hook seems to be ignored.
What I get is always:
[...] ---> Verifying checksum(s) for slrn-devel ---> Extracting slrn-devel ---> Configuring slrn-devel Error: Target org.macports.configure returned: no such file or directory Warning: the following items did not execute (for slrn-devel): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.archive org.macports.install Error: Status 1 encountered during processing.
Which is the right way to address this problem?
Why are you adding such a variant? Under which circumstances might a user want, or not want, to select it? I'm trying to figure out why you don't just fetch from CVS all the time, as that would seem to simplify things, wouldn't it? Variants are not supposed to change the version of the installed software, so if it's the same version, why would anyone care whether it's fetched from CVS or somewhere else, so long as it's fetched?
The immediate answer to your question, I think, is that the commands you are issuing are not valid TCL commands, and are therefore are not getting executed, and therefore the ./configure script, which the configure phase it trying to run, does not exist, hence the error message about no such file or directory. Hopefully if you would run the install in debug mode ("sudo port -dv install"), error messages to this effect would be printed. I think you would need something like this:
pre-configure { system "cd ${worksrcdir} && autopoint -f" system "cd ${worksrcdir} && aclocal -I autoconf" system "cd ${worksrcdir} && autoheader" system "cd ${worksrcdir} && automake --foreign -- add-missing" system "cd ${worksrcdir} && autoconf" }
Or, I think, just: configure.cmd Autogen.sh -- Anthony Ramine, a lazy french student. nox@macports.org
On 10/08/07 20:17, Ryan Schmidt wrote:
Why are you adding such a variant? Under which circumstances might a user want, or not want, to select it? I'm trying to figure out why you don't just fetch from CVS all the time, as that would seem to simplify things, wouldn't it? Variants are not supposed to change the version of the installed software, so if it's the same version, why would anyone care whether it's fetched from CVS or somewhere else, so long as it's fetched?
Yes, I could fetch the source once in a while, create an archive and place it somewhere. By now cvs it's the only way of following slrn development, because the debian unstable source used before are outdated and the last stable release is from 2005. Using an external snapshot of cvs solved the problem of hosting the tarball, and updating it every time I want to test a new version. I'm fetching from cvs because for me it's easier to update, it's just a matter of changing the date of the snapshot, see if compiles and run and ask someone here on macports-dev to update my port (I don't have the commit bit).
The immediate answer to your question, I think, is that the commands you are issuing are not valid TCL commands, and are therefore are not getting executed, and therefore the ./configure script, which the configure phase it trying to run, does not exist, hence the error message about no such file or directory. Hopefully if you would run the install in debug mode ("sudo port -dv install"), error messages to this effect would be printed. I think you would need something like this:
pre-configure { system "cd ${worksrcdir} && autopoint -f" system "cd ${worksrcdir} && aclocal -I autoconf" system "cd ${worksrcdir} && autoheader" system "cd ${worksrcdir} && automake --foreign --add-missing" system "cd ${worksrcdir} && autoconf" }
Not using "system" was wrong, but there's another problem: [....] ---> Verifying checksum(s) for slrn-devel DEBUG: Executing org.macports.checksum (slrn-devel) ---> Extracting slrn-devel DEBUG: Executing org.macports.extract (slrn-devel) DEBUG: Executing org.macports.patch (slrn-devel) ---> Configuring slrn-devel DEBUG: Executing proc-pre-org.macports.configure-configure-0 DEBUG: delete: config.guess Error: Target org.macports.configure returned: no such file or directory Warning: the following items did not execute (for slrn-devel): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.archive org.macports.install Error: Status 1 encountered during processing. Using configure.cmd as kindly suggested on the other email doesn't work either and leads to the same output. macport version is 1.5.0 on tiger powerpc 10.4.10 Thanks, Gufo
Le 11 août 07 à 11:38, Sbranzo a écrit :
On 10/08/07 20:17, Ryan Schmidt wrote:
Why are you adding such a variant? Under which circumstances might a user want, or not want, to select it? I'm trying to figure out why you don't just fetch from CVS all the time, as that would seem to simplify things, wouldn't it? Variants are not supposed to change the version of the installed software, so if it's the same version, why would anyone care whether it's fetched from CVS or somewhere else, so long as it's fetched?
Yes, I could fetch the source once in a while, create an archive and place it somewhere. By now cvs it's the only way of following slrn development, because the debian unstable source used before are outdated and the last stable release is from 2005. Using an external snapshot of cvs solved the problem of hosting the tarball, and updating it every time I want to test a new version.
I'm fetching from cvs because for me it's easier to update, it's just a matter of changing the date of the snapshot, see if compiles and run and ask someone here on macports-dev to update my port (I don't have the commit bit).
The immediate answer to your question, I think, is that the commands you are issuing are not valid TCL commands, and are therefore are not getting executed, and therefore the ./configure script, which the configure phase it trying to run, does not exist, hence the error message about no such file or directory. Hopefully if you would run the install in debug mode ("sudo port -dv install"), error messages to this effect would be printed. I think you would need something like this:
pre-configure { system "cd ${worksrcdir} && autopoint -f" system "cd ${worksrcdir} && aclocal -I autoconf" system "cd ${worksrcdir} && autoheader" system "cd ${worksrcdir} && automake --foreign --add-missing" system "cd ${worksrcdir} && autoconf" }
Not using "system" was wrong, but there's another problem:
[....] ---> Verifying checksum(s) for slrn-devel DEBUG: Executing org.macports.checksum (slrn-devel) ---> Extracting slrn-devel DEBUG: Executing org.macports.extract (slrn-devel) DEBUG: Executing org.macports.patch (slrn-devel) ---> Configuring slrn-devel DEBUG: Executing proc-pre-org.macports.configure-configure-0 DEBUG: delete: config.guess Error: Target org.macports.configure returned: no such file or directory Warning: the following items did not execute (for slrn-devel): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.archive org.macports.install Error: Status 1 encountered during processing.
Using configure.cmd as kindly suggested on the other email doesn't work either and leads to the same output.
macport version is 1.5.0 on tiger powerpc 10.4.10
Thanks, Gufo
Please turn on debug mode to produce more useful output: port -d install slrn-devel +cvs -- Anthony Ramine, a lazy french student. nox@macports.org
On 11/08/07 16:58, N_Ox wrote:
[....] ---> Verifying checksum(s) for slrn-devel DEBUG: Executing org.macports.checksum (slrn-devel) ---> Extracting slrn-devel DEBUG: Executing org.macports.extract (slrn-devel) DEBUG: Executing org.macports.patch (slrn-devel) ---> Configuring slrn-devel DEBUG: Executing proc-pre-org.macports.configure-configure-0 DEBUG: delete: config.guess Error: Target org.macports.configure returned: no such file or directory Warning: the following items did not execute (for slrn-devel): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.archive org.macports.install Error: Status 1 encountered during processing. [...]
Please turn on debug mode to produce more useful output: port -d install slrn-devel +cvs
That's the output with debug turned on :-D Thanks for your help, Gufo
On Aug 11, 2007, at 04:38, Sbranzo wrote:
I think you would need something like this:
pre-configure { system "cd ${worksrcdir} && autopoint -f" system "cd ${worksrcdir} && aclocal -I autoconf" system "cd ${worksrcdir} && autoheader" system "cd ${worksrcdir} && automake --foreign --add-missing" system "cd ${worksrcdir} && autoconf" }
Not using "system" was wrong, but there's another problem:
[....] ---> Verifying checksum(s) for slrn-devel DEBUG: Executing org.macports.checksum (slrn-devel) ---> Extracting slrn-devel DEBUG: Executing org.macports.extract (slrn-devel) DEBUG: Executing org.macports.patch (slrn-devel) ---> Configuring slrn-devel DEBUG: Executing proc-pre-org.macports.configure-configure-0 DEBUG: delete: config.guess Error: Target org.macports.configure returned: no such file or directory Warning: the following items did not execute (for slrn-devel): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.archive org.macports.install Error: Status 1 encountered during processing.
Using configure.cmd as kindly suggested on the other email doesn't work either and leads to the same output.
I'm afraid I don't know what file or directory it's looking for. :-/
On Aug 10, 2007, at 18:17, Ryan Schmidt wrote:
I'm trying to figure out why you don't just fetch from CVS all the time
Why do we allow fetching from CVS in the standard ports tree? There's no way to validate the downloaded files (ie, checksums), and it's completely non-deterministic. -landonf
Le 14 août 07 à 01:49, Landon Fuller a écrit :
On Aug 10, 2007, at 18:17, Ryan Schmidt wrote:
I'm trying to figure out why you don't just fetch from CVS all the time
Why do we allow fetching from CVS in the standard ports tree? There's no way to validate the downloaded files (ie, checksums), and it's completely non-deterministic.
You're quite right about the checksums, but the policy is to never export trunk but use specific revision numbers, so we are pretty sure we always fetch the same thing. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
On Aug 13, 2007, at 17:05, N_Ox wrote:
Le 14 août 07 à 01:49, Landon Fuller a écrit :
On Aug 10, 2007, at 18:17, Ryan Schmidt wrote:
I'm trying to figure out why you don't just fetch from CVS all the time
Why do we allow fetching from CVS in the standard ports tree? There's no way to validate the downloaded files (ie, checksums), and it's completely non-deterministic.
You're quite right about the checksums, but the policy is to never export trunk but use specific revision numbers, so we are pretty sure we always fetch the same thing.
Given that, the export should just be tar'd up and placed somewhere for download -- then checksums can be checked. -landonf
Le 14 août 07 à 02:19, Landon Fuller a écrit :
On Aug 13, 2007, at 17:05, N_Ox wrote:
Le 14 août 07 à 01:49, Landon Fuller a écrit :
On Aug 10, 2007, at 18:17, Ryan Schmidt wrote:
I'm trying to figure out why you don't just fetch from CVS all the time
Why do we allow fetching from CVS in the standard ports tree? There's no way to validate the downloaded files (ie, checksums), and it's completely non-deterministic.
You're quite right about the checksums, but the policy is to never export trunk but use specific revision numbers, so we are pretty sure we always fetch the same thing.
Given that, the export should just be tar'd up and placed somewhere for download -- then checksums can be checked.
-landonf
By the way, am I blind or is there no "fetch.type" in portfile manpage? -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
Le 14 août 07 à 03:26, N_Ox a écrit :
Le 14 août 07 à 02:19, Landon Fuller a écrit :
On Aug 13, 2007, at 17:05, N_Ox wrote:
Le 14 août 07 à 01:49, Landon Fuller a écrit :
On Aug 10, 2007, at 18:17, Ryan Schmidt wrote:
I'm trying to figure out why you don't just fetch from CVS all the time
Why do we allow fetching from CVS in the standard ports tree? There's no way to validate the downloaded files (ie, checksums), and it's completely non-deterministic.
You're quite right about the checksums, but the policy is to never export trunk but use specific revision numbers, so we are pretty sure we always fetch the same thing.
Given that, the export should just be tar'd up and placed somewhere for download -- then checksums can be checked.
-landonf
By the way, am I blind or is there no "fetch.type" in portfile manpage?
-- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
By the way, it should be noted in the new guide that export tarballs are preferred over checkout ones. I don't need all of those .svn and CVS, I just want the sources. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
N_Ox <n.oxyde@gmail.com> writes:
By the way, it should be noted in the new guide that export tarballs are preferred over checkout ones. I don't need all of those .svn and CVS, I just want the sources.
You mean to state that it is preferred that port authors checkout from CVS, tar up only the source directories, and put it on macports.org? As opposed to using fetch.type cvs? Mark
On Aug 15, 2007, at 18:09, markd@macports.org wrote:
N_Ox writes:
By the way, it should be noted in the new guide that export tarballs are preferred over checkout ones. I don't need all of those .svn and CVS, I just want the sources.
You mean to state that it is preferred that port authors checkout from CVS, tar up only the source directories, and put it on macports.org? As opposed to using fetch.type cvs?
I think he means it is preferable to tar up the output of "svn export" (or whatever the equivalent CVS command is) and put it on macports.org rather than tar up the output of "svn checkout" (or equivalent CVS command) and put it on macports.org.
Ryan Schmidt <ryandesign@macports.org> writes:
By the way, it should be noted in the new guide that export tarballs are preferred over checkout ones. I don't need all of those .svn and CVS, I just want the sources.
You mean to state that it is preferred that port authors checkout from CVS, tar up only the source directories, and put it on macports.org? As opposed to using fetch.type cvs?
I think he means it is preferable to tar up the output of "svn export" (or whatever the equivalent CVS command is) and put it on macports.org rather than tar up the output of "svn checkout" (or equivalent CVS command) and put it on macports.org.
I see. I didn't know that. But if that is true, I would think it is safe to assume that fetch types "svn" and "cvs" do an "export" or export equivalent. Is that true? Mark
On Aug 15, 2007, at 18:51, markd@macports.org wrote:
Ryan Schmidt writes:
By the way, it should be noted in the new guide that export tarballs are preferred over checkout ones. I don't need all of those .svn and CVS, I just want the sources.
You mean to state that it is preferred that port authors checkout from CVS, tar up only the source directories, and put it on macports.org? As opposed to using fetch.type cvs?
I think he means it is preferable to tar up the output of "svn export" (or whatever the equivalent CVS command is) and put it on macports.org rather than tar up the output of "svn checkout" (or equivalent CVS command) and put it on macports.org.
I see. I didn't know that. But if that is true, I would think it is safe to assume that fetch types "svn" and "cvs" do an "export" or export equivalent. Is that true?
I have no idea what kind of thing the svn and cvs fetch types fetch, and I don't think it matters much. We're talking about when someone manually grabs something out of a svn or cvs repository, tars it up and uploads it. A CVS working copy contains a "CVS" directory in every directory which contains extra administrative stuff that we would have no use for. A Subversion working copy contains a ".svn" directory in every directory with administrative stuff, plus a complete copy of every file in the directory, meaning that if someone tars up a Subversion working copy it'll be more than twice as large as taring up an svn export would be, for absolutely no benefit in our case. That's the point.
participants (5)
-
Landon Fuller
-
markd＠macports.org
-
N_Ox
-
Ryan Schmidt
-
Sbranzo