[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Can't build gcc



On Thu, 30 Sep 1999, Matthias Klose wrote:

> Dale Scheetz writes:
>  > The request that I install dejagnu from project/experimental can not be
>  > satisfied, as there is no version of dejagnu in project/experimental (at
>  > least not last time I looked). In any case, the test suites that it would
>  > be used to execute have been disabled "by hand", so this should not be
>  > needed.
> 
> The version from experimental has been moved to unstable; thanks for
> the hint.

When I built the latest version from potato on the sparc-ultra, the
message remained the same whether I had dejagnu installed or not.

Looking at the logic in debian/rules2 is a bit confusing. with_check is
only set yes if the test_summary file is found, and there is the correct
version of dejagnu installed.

However, dispite all this, with_check is "forced" to have the value
"disabled by hand", and the check for "proper" version is avoided.

When we get down to the report, only the value "yes" is checked, hense the
message when yes is not the value, must suite two different states of
affairs.

For clarity could the message be re-worded to say:

If you wish to run the tests, install dejagnu.

but should probably say nothing when "disable by hand" is the value.

> 
>  > The second complaint, that mailx is not installed, and a report can't be
>  > mailed, seems to be the reason for generating the "false". How come? If
>  > you are going to require an e-mail report whenever gcc gets built, at the
>  > very least you are violating the DFSG and this turky should go into
>  > non-free. I don't do mail from the box building the packages. It isn't
>  > even connected to the net during builds. Is this step really needed?
> 
> The rational for sending the mail is to provide gcc-testresults with
> the build summaries you find at the mailing list at gcc.gnu.org. It
> should be disabled, if with_check isn't set to yes (which is the case
> for the gcc package). However I think it's very useful to provide the
> upstream maintainers with build reports (at least for the
> non-mainstream architectures). Is there a way to send or submit the
> build report without violating the DFSG? On the other hand, if I build
> gcc, I normally forget to send the report by hand ;-)
> 
The problem here is that if I don't want to, or just don't have the
ability, the build fails! This _forces_ the builder to comply with your
wishes to send said mail, which to me is a clear violation of the DFSG.

Can't you do the same thing here that you do with dejagnu, and just keep
going anyway? (i.e. comment out the "false" just like you did for dejagnu)


>  > I am willing to be convinced that it has nothing to do with either of
>  > these issues, and is something else entirely, however there isn't a clue
>  > to be had in the log of the build. It says that it will build a lot of
>  > things, but never does.
> 
> I thought an explicit message would be a clue ... (or at least a well
> documented debian/rules2 file ;-)

I assume you mean the explicit message about mailx?

After seeing the message about installing dejagnu and restarting, with no
failure, I had no reason to assume that such a minor issue as being unable
to send mail would defeat the build.

> 
>  > Can you tell me what I am missing/doing wrong?
> 
> Look at debian/rules2 and set with_mail to no after it's set by the
> debian/rules2 file. I'll find a solution for the next upload.
> 
I'm trying to run an autobuild process here, both for the Intel and Sparc.
As it stands now, it looks like the only way to get this to build in any
"automatic" fashion is to install mailx! Well, I guess I could just leave
gcc out of the autobuild, and build it "by hand". I hope you can see that
from my point of view this is less than optimal, specially considering
that this is a crucial package to the rest of the build process.

I had to uninstall exim, because I leave any installed mailer
unconfigured. The problem is the exim package insists on using a cron job
to wake it up for possible mail transfers, and this results in a scribbled
message at the console about not being able to open exim's config file,
since I never got one built.

Is mailx likely to give me the same grief?

Thanks,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- See www.linuxpress.com for more details  _-_-_-_-_-_-_-


Reply to: