I copied in to a directory every single rpm it was asking for and when I run: current directory == /usr/src/dovecot/ build --clean --verify --rpms /usr/src/dovecot/ I get and error that it cannot find aaa_base.rpm Well, I'm looking at it and it's there. What went wrong? What needs to be fixed?
* Tom Allison
I copied in to a directory every single rpm it was asking for and when I run:
current directory == /usr/src/dovecot/ build --clean --verify --rpms /usr/src/dovecot/
I get and error that it cannot find aaa_base.rpm Well, I'm looking at it and it's there.
What went wrong? What needs to be fixed?
Did you read the man-page to build before starting? First off you don't want to be in /usr/src/dovecot when calling build. You want to be in the directory with the package you want to build. Also you might try $ export BUILD_RPMS=/usr/src/dovecot/ and then $ build --clean --verify No need for the --rpms swich. -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort?" -- A. P. J.
Mads Martin Joergensen wrote:
* Tom Allison
[Nov 09. 2003 00:50]: I copied in to a directory every single rpm it was asking for and when I run:
current directory == /usr/src/dovecot/ build --clean --verify --rpms /usr/src/dovecot/
I get and error that it cannot find aaa_base.rpm Well, I'm looking at it and it's there.
What went wrong? What needs to be fixed?
Did you read the man-page to build before starting? First off you don't want to be in /usr/src/dovecot when calling build. You want to be in the directory with the package you want to build.
Also you might try
$ export BUILD_RPMS=/usr/src/dovecot/
and then
$ build --clean --verify
No need for the --rpms swich.
According to the man page export BUILD_RPMS=/usr/src/dovecot/ --rpms /usr/src/dovecot/ are synonymous. I am using 8.2 Professional fully updated from Suse websites. I selected 'build' over RPM because it seemed a better approach if I intended to build an rpm specifically for SuSE 8.2 that might be suitable for distribution to others. However, reading your continued threads about how 'build' is essentially farked in 8.2 and 9.0 (with some contention as to the exact farkiness therein/thereof/whatever) I'm just a wee bit disappointed. I am very favorably impressed with how well SuSE can get up and running as a desktop workstation. As far as the various comments people have about Linux != workstation environment they need to spend a few days with SuSE. However... My experience has led me to the conclusion that SuSE comes with a huge caveat. "Don't leave the path". For whatever it's worth, everything that I have done which is outside of the DEFAULT installation has been met with some level of limited success. I've been very careful to determine the exact area of shortcoming and to provide feedback as accurate as possible to SuSE. A specific example that really caught my by surprise was this: squirrelmail -- documentation (README.Suse) states that squirrelmail is intended for use with the imap (Univ. Wash) package. imap is compiled without imap support. It will only support imap-ssl protocol. squirrelmail, as shipped from Suse is version 1.2 and is incapable of imap-ssl support. This functionality was not available until 1.4 according the the squirrelmail mailing list. This, combined with the issues identified with 'build' lead me to conclude that SuSE, while having an excellent desktop environment, has limited capabilities for doing much on the Server side and even less when you attempt to do anything that is even more deviated from "The Path". Don't get me wrong, I'm not down on Suse. In fact I intend on keeping it as my desktop. But it's been a devil of a time getting the server working. There's been additional problems with cyrus-imap, cyrus-sasl, several other build packages (courier-imap is one), sieveshell authentication, ldap-anything (but that's likely my fault). But, I did get KDE's CD-burner working the first time I tried to use it. That was "cool".
* Tom Allison
I am using 8.2 Professional fully updated from Suse websites.
I selected 'build' over RPM because it seemed a better approach if I intended to build an rpm specifically for SuSE 8.2 that might be suitable for distribution to others.
However, reading your continued threads about how 'build' is essentially farked in 8.2 and 9.0 (with some contention as to the exact farkiness therein/thereof/whatever) I'm just a wee bit disappointed.
It's only broken if you don't use # usedforbuild line. -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort?" -- A. P. J.
Op zondag 9 november 2003 00:50, schreef Tom Allison:
I copied in to a directory every single rpm it was asking for and when I run:
current directory == /usr/src/dovecot/ build --clean --verify --rpms /usr/src/dovecot/
I get and error that it cannot find aaa_base.rpm Well, I'm looking at it and it's there.
What went wrong? What needs to be fixed?
What do you actually want to achieve? Do you want to build an rpm? If yes just use the rpm build command which is rpm -ba <specfile> on 9.0 it is rpmbuild -ba -- Richard Bos Without a home the journey is endless
* Richard Bos
current directory == /usr/src/dovecot/ build --clean --verify --rpms /usr/src/dovecot/
I get and error that it cannot find aaa_base.rpm Well, I'm looking at it and it's there.
What went wrong? What needs to be fixed?
What do you actually want to achieve? Do you want to build an rpm? If yes just use the rpm build command which is rpm -ba <specfile> on 9.0 it is rpmbuild -ba
But building with 'build' will set up a chroot environment, which have it's advantages. -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort?" -- A. P. J.
Op zondag 9 november 2003 21:17, schreef Mads Martin Joergensen:
What do you actually want to achieve? Do you want to build an rpm? If yes just use the rpm build command which is rpm -ba <specfile> on 9.0 it is rpmbuild -ba
But building with 'build' will set up a chroot environment, which have it's advantages.
I know. But it is a bit more complicated/confusing is you just start building. Built does no make it easier to built rpms and last time I looked at it the to be installed rpm list is does not match the suse version..... -- Richard Bos Without a home the journey is endless
* Richard Bos
What do you actually want to achieve? Do you want to build an rpm? If yes just use the rpm build command which is rpm -ba <specfile> on 9.0 it is rpmbuild -ba
But building with 'build' will set up a chroot environment, which have it's advantages.
I know. But it is a bit more complicated/confusing is you just start building. Built does no make it easier to built rpms and last time I looked at it the to be installed rpm list is does not match the suse version.....
I think you looking wrong, can you show me an example of such? -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort?" -- A. P. J.
Op zondag 9 november 2003 22:16, schreef Mads Martin Joergensen:
* Richard Bos
[Nov 09. 2003 21:57]: What do you actually want to achieve? Do you want to build an rpm? If yes just use the rpm build command which is rpm -ba <specfile> on 9.0 it is rpmbuild -ba
But building with 'build' will set up a chroot environment, which have it's advantages.
I know. But it is a bit more complicated/confusing is you just start building. Built does no make it easier to built rpms and last time I looked at it the to be installed rpm list is does not match the suse version.....
I think you looking wrong, can you show me an example of such?
ls $i*rpm done /bin/ls: aaa_version*rpm: No such file or directory /bin/ls: bind9-utils*rpm: No such file or directory bison-1.75-109.i586.rpm /bin/ls: fileutils*rpm: No such file or directory flex-2.5.4a-195.i586.rpm gdbm-devel-1.8.3-119.i586.rpm
yes. eval $(grep USEDFORBUILD=\" /usr/bin/build) for i in $USEDFORBUILD; do rpm -q $i >/dev/null ; [ $? -ne 0 ] && echo $i; done aaa_version bind9-utils bison fileutils flex gdbm-devel pam-devel rcs sendmail sh-utils texinfo textutils Some are not installed, check the dvd: richard@pilchard:/media/dvd/suse/i586> for i in $ERRORED; do pam-devel-0.77-124.i586.rpm rcs-5.7-764.i586.rpm sendmail-8.12.10-7.i586.rpm sendmail-devel-8.12.10-7.i586.rpm /bin/ls: sh-utils*rpm: No such file or directory texinfo-4.5-88.i586.rpm /bin/ls: textutils*rpm: No such file or directory aaa_version is now suse-release *utils are now coreutils -- Richard Bos Without a home the journey is endless
* Richard Bos
eval $(grep USEDFORBUILD=\" /usr/bin/build) for i in $USEDFORBUILD; do rpm -q $i >/dev/null ; [ $? -ne 0 ] && echo $i; done aaa_version bind9-utils bison fileutils flex gdbm-devel pam-devel rcs sendmail sh-utils texinfo textutils
Some are not installed, check the dvd: richard@pilchard:/media/dvd/suse/i586> for i in $ERRORED; do
ls $i*rpm done
Well, you might want to go one dir back, and do ls */$i*rpm since there might be some in noarch too.
/bin/ls: aaa_version*rpm: No such file or directory /bin/ls: bind9-utils*rpm: No such file or directory bison-1.75-109.i586.rpm /bin/ls: fileutils*rpm: No such file or directory flex-2.5.4a-195.i586.rpm gdbm-devel-1.8.3-119.i586.rpm pam-devel-0.77-124.i586.rpm rcs-5.7-764.i586.rpm sendmail-8.12.10-7.i586.rpm sendmail-devel-8.12.10-7.i586.rpm /bin/ls: sh-utils*rpm: No such file or directory texinfo-4.5-88.i586.rpm /bin/ls: textutils*rpm: No such file or directory
aaa_version is now suse-release *utils are now coreutils
And this source rpm is from what version? -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort?" -- A. P. J.
* Richard Bos
And this source rpm is from what version?
The result has been found on 8.2 and verified on 9.0.
You cannot use 'build' to build an 8.2 package without adjusting # usedforbuild accordingly of course! Any 9.0 src.rpm will not show such error. -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort?" -- A. P. J.
Op zondag 9 november 2003 23:49, schreef Mads Martin Joergensen:
* Richard Bos
[Nov 09. 2003 22:59]: And this source rpm is from what version?
The result has been found on 8.2 and verified on 9.0.
You cannot use 'build' to build an 8.2 package without adjusting # usedforbuild accordingly of course!
Any 9.0 src.rpm will not show such error.
Mads, let me clearer. 9.0 _and_ 8.2 have the problem. I used the same procedure for checking their native build script on 8.2 and 9.0. I have to disagree with
Any 9.0 src.rpm will not show such error.
As that is the one I actually used in during our email exchange. -- Richard Bos Without a home the journey is endless
* Richard Bos
let me clearer. 9.0 _and_ 8.2 have the problem. I used the same procedure for checking their native build script on 8.2 and 9.0.
I have to disagree with
Any 9.0 src.rpm will not show such error.
As that is the one I actually used in during our email exchange.
Please tell me the name of that src.rpm, you did not mention that in your previous mail. -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort?" -- A. P. J.
* Mads Martin Joergensen
I have to disagree with
Any 9.0 src.rpm will not show such error.
As that is the one I actually used in during our email exchange.
Please tell me the name of that src.rpm, you did not mention that in your previous mail.
The problem here only shows it's face when one builds an rpm without a correct # usedforbuild. Here's the patch to apply to /usr/bin/build: --- old/build/build 2003-09-05 16:00:56.000000000 +0200 +++ new/build/build 2003-11-10 13:47:44.000000000 +0100 @@ -264,7 +264,7 @@ USEDFORBUILD=`grep "^#.*usedforbuild" $SPECFILE` if [ -z "$USEDFORBUILD" ] ; then - USEDFORBUILD="fillup attr acl aaa_base filesystem aaa_version autoconf au tomake bash bind9-utils binutils bison bzip2 cpio cpp cracklib cyrus-sasl db dev s diffutils e2fsprogs file fileutils findutils flex gawk gcc gdbm gdbm-devel get text glibc glibc-devel glibc-locale gpm grep groff gzip kbd less libgcc libstdc+ + libtool libxcrypt zlib m4 make man mktemp modutils ncurses ncurses-devel net-t ools netcfg pam pam-devel pam-modules patch perl permissions ps rcs readline rpm sed sendmail sh-utils shadow strace syslogd sysvinit tar texinfo textutils time zone unzip util-linux vim zlib-devel" + USEDFORBUILD="aaa_base acl attr autoconf automake binutils bash bind-util s bison bzip2 coreutils cpio cpp cracklib cvs cyrus-sasl db devs diffutils e2fsp rogs file filesystem fillup findutils flex gawk gcc gdbm gdbm-devel gettext glib c glibc-devel glibc-locale gpm grep groff gzip info insserv kbd less libacl liba ttr libgcc libstdc++ libtool libxcrypt m4 make man mktemp modutils ncurses ncurs es-devel net-tools netcfg openldap2-client openssl pam pam-devel pam-modules pat ch permissions perl popt ps rcs rpm readline sed sendmail shadow strace syslogd sysvinit tar texinfo timezone unzip util-linux vim zlib zlib-devel" fi for i in $USEDFORBUILD ; do case "$i" in -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort?" -- A. P. J.
participants (3)
-
Mads Martin Joergensen
-
Richard Bos
-
Tom Allison