Re: Can't build gcc
Dale Scheetz writes:
> 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.
the checks are disabled, because the testsuite has been removed from
the release.
> 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)
yes, for the non-snapshot packages.
> > > 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?
yes.
> > 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?
mailx is an MUA, not an MTA. AFAIK the most simple found in
Debian. Perhaps I should try to talk to port 25 directly? Or use mutt?
Reply to: