Bug 133928 - sendmail has multiple build problems
Summary: sendmail has multiple build problems
Alias: None
Product: Fedora
Classification: Fedora
Component: sendmail   
(Show other bugs)
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact:
Keywords: Patch
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-28 15:14 UTC by Steve Grubb
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-04 15:35:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch that addresses all 5 issues against the spec file. (2.47 KB, patch)
2004-09-28 15:18 UTC, Steve Grubb
no flags Details | Diff

Description Steve Grubb 2004-09-28 15:14:06 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4.2)

Description of problem:
There are several build problems with sendmail's spec file. I am using
the latest in rawhide and compiling with the latest packages in rawhide.

1) %if "%{old_setup}" == "yes"
 Source3: aliases

Using %if in Source tags is bad. This means rpmbuild will not complain
if aliases is ever missing. And looking around, aliases is now
missing. When old_setup yes is given, it fails to build because the
aliases file is no longer in the srpm.

2) BuildRequires: util-linux  is needed. If util-linux is not
installed, the build fails with:

/home/build/working/tmp/rpm-tmp.4227: line 1: arch: command not found
+ OBJDIR=obj.Linux.2.4.20-31.9smp.

3) During the install phase around line 269, there are some missing
Make installs. mailstats, rmail, praliases, smrsh, and makemap all
need to do a Make install-docs. Without using this target, it fails
with this error messages:

+ /usr/lib/rpm/brp-strip-comment-note
error: File not found by glob:
error: File not found by glob:
error: File not found by glob:
error: File not found by glob:
error: File not found by glob:
    File not found by glob:
    File not found by glob:
    File not found by glob:
    File not found by glob:
    File not found by glob:

4) Around line 379, is a series of mv statements. The files they are
trying to mv is in a different directory. You get these errors:

+ mv /home/build/working/tmp/sendmail-root/usr/sbin/sendmail
+ mv /home/build/working/tmp/sendmail-root/usr/bin/mailq
+ mv /home/build/working/tmp/sendmail-root/usr/bin/newaliases
+ mv /home/build/working/tmp/sendmail-root/usr/bin/rmail
+ mv /home/build/working/tmp/sendmail-root/usr/share/man/man1/mailq.1
mv: cannot stat
`/home/build/working/tmp/sendmail-root/usr/share/man/man1/mailq.1': No
such file or directory

5) On older systems (RH9) there are some left over files that must be

Checking for unpackaged file(s): /usr/lib/rpm/check-files
/var/tmp/sendmail-rootwarning: Installed (but unpackaged) file(s) found:

This does not show up under FC3T2.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. rpmbuild -bb sendmail.spec

Actual Results:  Various failure messages.

Expected Results:  A message saying where the rpm was written.

Additional info:

I will attach a patch that addresses all these issues.

Comment 1 Steve Grubb 2004-09-28 15:18:15 UTC
Created attachment 104439 [details]
Patch that addresses all 5 issues against the spec file.

Comment 2 Thomas Woerner 2004-10-04 15:35:42 UTC
1) This switch is as is.
2) This is a rpm bug.
3) Not reproducible.
4) Not reproducible.
5) RHL9 is not supported.

Closing as "NOT A BUG".

Comment 3 Steve Grubb 2004-10-04 15:50:58 UTC
>1) This switch is as is.

So if people want to build with the old setup, you want it to fail
because the file is not there? I can understand maybe branching around
something in the install or %files phase, but not at the Source line.
Why not just delete the old_setup define if its not supported?

>3) Not reproducible.
>4) Not reproducible.

Are you testing with all the latest packages in FC3T2? I think
coreutils made a subtle change in the semantics of following symlinks
a month ago. This may be the source of the difference.

Comment 4 Thomas Woerner 2004-10-04 15:58:14 UTC
I will remove the switch in the near future.

Yes, I have tested this with the latest packages but there were no
problems in the original build process, too.

Note You need to log in before you can comment on or make changes to this bug.