Bug 1084813 - Review Request: gnubatch - Provides enhanced job control
Summary: Review Request: gnubatch - Provides enhanced job control
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Christopher Meng
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-06 19:44 UTC by Jon Kent
Modified: 2014-06-27 22:09 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-27 22:09:43 UTC
Type: ---
Embargoed:
i: fedora-review?


Attachments (Terms of Use)

Description Jon Kent 2014-04-06 19:44:56 UTC
Spec URL: https://github.com/jondkent/gnubatch/blob/master/gnubatch.spec
SRPM URL: https://github.com/jondkent/gnubatch/blob/master/gnubatch-1.10-1.fc20.src.rpm
Patch URL: https://github.com/jondkent/gnubatch/blob/master/gnubatch-systemd.tar.gz
Description: gnubatch provides a comprehensive batch scheduling system
for UNIX systems and GNU/Linux with transparently shared jobs and
job control variables across the network. Provide jobs dependancy cross server/jobs functionality.

Fedora Account System Username: jondkent

Comment 1 Jon Kent 2014-04-06 19:50:52 UTC
Hi,

I'm slightly nervous about this package as I was surprised to find that it did not exist already, therefore I'm half expecting that this has been put forward before and refused.  If this is so I can find any history of that.

When you look at the spec file you'll see some embedded awk to modify /etc/services in the %post section.  I've checked on ask.fedoraproject.org and the feedback looks positive, nevertheless not done that on a Fedora spec before.

Before anyone asks, I maintain a Fedora package at the moment (ptpd).

Fingers crossed that there aren't too many problems with this.

Thanks,
Jon

Comment 2 Christopher Meng 2014-04-07 02:21:24 UTC
Uh...Surprise?

Only gentoo has it so far.

Comment 3 Jon Kent 2014-04-07 21:10:39 UTC
Hi,

For something that's been around since the 90s that's surprising isn't it?

Are you doing the review of this package?

Cheers,
Jon

Comment 4 Jon Kent 2014-04-12 16:53:19 UTC
Hi,

Found a build bug with the original source rpm when testing it on copr and on a new Fedora build.  I've now fixed this and its built successfully for FC20/21(rawhide).

New source rpm is here:

https://github.com/jondkent/gnubatch/blob/master/gnubatch-1.10-2.fc20.src.rpm

and here just in case:
https://spideroak.com/share/MZSWI33SMEWXG4TDOJYG24Y/fedora-gnubatch-110/home/jon/src-rpms/gnubatch-1.10-2.fc20.src.rpm

Regards,
Jon

Comment 5 Christopher Meng 2014-04-16 06:20:22 UTC
1. Summary: gnubatch provides enhanced job control

Not good, uncapitalized.

2. Drop grop tag.

3. Drop BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)

4. Use %configure, currently the strip can't work properly and get these to users:

ERROR: Command failed: 
 # ['/usr/bin/yum', '--installroot', '/var/lib/mock/fedora-rawhide-i386/root/', '--releasever', '21', 'install', '/home/rpmaker/Desktop/gnubatch/results/gnubatch-1.10-2.fc21.i686.rpm', '--setopt=tsflags=nocontexts']
Error: Package: gnubatch-1.10-2.fc21.i686 (/gnubatch-1.10-2.fc21.i686)
           Requires: libgnubatch_int.so.1.debug
Error: Package: gnubatch-1.10-2.fc21.i686 (/gnubatch-1.10-2.fc21.i686)
           Requires: libgnubatch_curs.so.1.debug
Error: Package: gnubatch-1.10-2.fc21.i686 (/gnubatch-1.10-2.fc21.i686)
           Requires: libgnubatch_client.so.1.debug
 You could try using --skip-broken to work around the problem
Error: Package: gnubatch-1.10-2.fc21.i686 (/gnubatch-1.10-2.fc21.i686)
           Requires: libgnubatch_curs.so.debug
Error: Package: gnubatch-1.10-2.fc21.i686 (/gnubatch-1.10-2.fc21.i686)
           Requires: libgnubatch_client.so.debug
Error: Package: gnubatch-1.10-2.fc21.i686 (/gnubatch-1.10-2.fc21.i686)
           Requires: libgnubatch_int.so.debug
 You could try running: rpm -Va --nofiles --nodigest

5. rm -rf %{buildroot}

6. Executables should be set 755, others are 644, special files are custom.

Therefore no 554/664/666 please.

In order to not do this, please use install -pm$(PERMISSION) to install the relevant files to the correct dir in %install instead of cp.

7. /usr/share --> %{_datadir}

8. No need to %attr(664,root,root) in

%config(noreplace) %attr(664,root,root) /etc/sysconfig/gnubatch.conf

Remove that.

9. Scriptlet invalid, please don't use them.

10. Check and add missing syntax of systemd:

https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd

11. Source0: http://ftp.gnu.org/gnu/gnubatch/gnubatch-1.10.tar.gz

Please use a macro at least for easier life:

Source0: http://ftp.gnu.org/gnu/gnubatch/gnubatch-%{version}.tar.gz

12. Do we really need to gzip the systemd files? Why not provide them directly as SOURCE1, SOURCE2?

13. %{buildroot}/%{_unitdir}

No slash after buildroot macro.

14. /etc --> %{_sysconfdir}

15. Why not use standard %make_install? If you find problem, patch them.

16. cp -p LICENSE %{buildroot}%{_defaultdocdir}/%{name}/
cp -p README %{buildroot}%{_defaultdocdir}/%{name}/

Dont do that! Use %doc macro in %files!

17. Please remove %clean section forever.

18. Leave a blank line between each changelog entry.

19. Please put %post and such sections before %files.

20. Drop %defattr(-,root,root,-)

Hint, by using rpm -E $(MACROS), you can get the details of them.

Comment 6 Jon Kent 2014-04-18 15:57:12 UTC
Hi,

Thanks for the feedback.  I've applied most of those changed now.

The only one I haven't applied (afaik) is the use of %make_install as the multiple Makefiles make use of 2 perl scripts that verify that the user gnubatch exists and that the additional services are applied to /etc/services.  To patch this out looks like  it would be quite a brittle patch and doesn't gain much that I can see.

All changes and source rpms are in github, and the new tag is 1.10-3.  As before the source rpm in also in SpiderOak just in case.

Hopefully this is a cleaner spec this time :)

Thanks again,

Jon

Comment 7 Michael Schwendt 2014-04-18 16:40:33 UTC
Please keep the "SRPM URL:" and "Spec URL:" lines in this ticket up-to-date, so the fedora-review tool may be pointed at this ticket. The links to the src.rpm give 404 Not Found. The results from "fedora-review -b 1084813" would be interesting.


You've missed a few issues from the earlier comment(s). So, some of these may be redundant:


> Summary: Gnubatch provides enhanced job control

In many many cases it is just bad form to repeat the program name in the %summary, especially when the package name is the same. Better and more concise would be to immediately start summing up what the package provides. For example:

  Summary: Enhanced job control system

  Summary: Comprehensive batch scheduling system

The latter is from the first sentence of the %description. I'm not a fan of the "Enhanced" in the summary when the description doesn't expand on _what_ has been enhanced, and how.

https://fedoraproject.org/wiki/Examples_of_good_package_summaries


> #%setup -a 1

Be very careful with commenting out macros like that. Some macros are expanded and evaluated even then and may cause side-effects. Better replace the '%' with a '#' or '%%'.


> %configure --sysconfdir=/etc/gnubatch --sharedstatedir=/var --localstatedir=/var --exec-prefix=/usr --prefix=/usr

Why do you redefine several of the options?
See output of "rpm -E %configure".


> install -m 755

Prefer adding option "-p" to preserve timestamps when installing prebuilt files.

https://fedoraproject.org/wiki/Packaging:Guidelines#Timestamps


> %post
> 
> echo "checking /etc/services setup for gnubatch"

Scriptlets must not print anything deliberately. There's not even any guarantee that package install tools would show the output to the user. Only the scriptlet exit return code matters.


> %attr(755,root,root) %{_bindir}/*
> %attr(755,root,root) %{_libdir}/*
> %attr(644,root,root) %{_unitdir}/*
> %attr(755,root,root) /var/gnubatch

Consider adjusting the file permissions in the buildroot with chmod (or via the supplied Makefiles, which you avoid because they seem unsuitable for installing into an empty buildroot). Overuse of %attr leads to problems occasionally and also raises the question whether/why you need to override default permissions.
Prefer using %attr only for very special permissions you want to stick out in the spec file, e.g. setuid, setgid. The default for dirs is 0755,root,root and for files 0644,root,root already.


> %attr(644,root,root) /usr/share/%{name}/help/*

Either use %{_datadir} for /usr/share in all places, or hardcode /usr/share everywhere. Don't mix both forms:

  https://fedoraproject.org/wiki/Packaging:Guidelines#Macros


> %attr(644,root,root) /usr/share/%{name}/help/*

Directory /usr/share/gnubatch is not included.

https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership
https://fedoraproject.org/wiki/Packaging:UnownedDirectories

Comment 9 Jon Kent 2014-04-18 18:15:26 UTC
Below added for fedora-review

Spec URL: https://spideroak.com/share/MZSWI33SMEWXG4TDOJYG24Y/fedora-gnubatch-110/home/jon/src-rpms/gnubatch.spec

Comment 11 Jon Kent 2014-04-18 18:41:55 UTC
Hi,

Again, thanks for the quick feedback.  As you've probably gathered from the previous 3 entries here I've been checking this against fedora-review (must admit I'd forgotten about that tool).

I've done as you've suggested, does look cleaner and I think the summary is more descriptive now.  Not idea why I added those flags to configure, just paranoid I think.  I also updated the description to put more detail around what gnubatch does, which I think is better than before.

The only bit I wasn't sure what you meant was the "Directory /usr/share/gnubatch is not included." comment.  If this refers to the perms, then I'm happy with them as they now are.  If not can you please let me know.

The only error I'm seeing from Fedora Reviewer is :

/sbin/ldconfig: /lib64/libgnubatch_curs.so.1 is not a symbolic link

/sbin/ldconfig: /lib64/libgnubatch_client.so.1 is not a symbolic link

/sbin/ldconfig: /lib64/libgnubatch_int.so.1 is not a symbolic link

/sbin/ldconfig: /lib64/libgnubatch_curs.so.1 is not a symbolic link

/sbin/ldconfig: /lib64/libgnubatch_client.so.1 is not a symbolic link

/sbin/ldconfig: /lib64/libgnubatch_int.so.1 is not a symbolic link

These really should be sym links but I can see a preserve flag to install (aside from selinux context).  Am I missing something here, or is this expected and OK?

Spec file and src rpms updated.  I had to relocate the spec file to my SpiderOak share as 'fedora reviewer' had problems downloading from github.

Thanks,

Jon

Comment 12 Michael Schwendt 2014-04-18 20:00:03 UTC
fedora-review reports a couple of errors and warnings about gnubatch-1.10-4.fc20.src.rpm.

Also notice the long list of W/E from rpmlint, which are included in the fedora-review report, too.


> License: GPLv3

The fedora-review license check does not agree. See:

https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#.22or_later_version.22_licenses


> The only bit I wasn't sure what you meant was the
> "Directory /usr/share/gnubatch is not included." comment.

The two links I added explain it well. Your spec file %files section does not include the directories

  /usr/share/gnubatch
  /usr/share/gnubatch/help

but only the contents of /usr/share/gnubatch/help:

  $ rpmls -p gnubatch-1.10-4.fc20.x86_64.rpm |grep ^d
  drwxr-xr-x  /usr/share/doc/gnubatch
  drwxr-xr-x  /usr/share/man/man1
  drwxr-xr-x  /usr/share/man/man3
  drwxr-xr-x  /usr/share/man/man5
  drwxr-xr-x  /usr/share/man/man8
  drwxr-xr-x  /var/gnubatch


* The build.log reveals that Fedora's global compiler flags are not used:
https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags


* A simple "rpmbuild --rebuild …" on Fedora 20 ends with a built failure, which could mean that possibly something is installed that's not installed the cleaner Mock buildroot:

  ! LaTeX Error: File `xifthen.sty' not found.

  Type X to quit or <RETURN> to proceed,
  or enter new name. (Default extension: sty)

  Enter file name: 



> /sbin/ldconfig: /lib64/libgnubatch_int.so.1 is not a symbolic link
> 
> These really should be sym links but I can see a preserve flag to
> install (aside from selinux context).  Am I missing something here,
> or is this expected and OK?

There are multiple packaging bugs related to it:

$ rpmls -p gnubatch-1.10-4.fc20.x86_64.rpm |grep lib64
-rwxr-xr-x  /usr/lib64/libgnubatch_client.a
-rwxr-xr-x  /usr/lib64/libgnubatch_client.la
-rwxr-xr-x  /usr/lib64/libgnubatch_client.lai
-rwxr-xr-x  /usr/lib64/libgnubatch_client.so
-rwxr-xr-x  /usr/lib64/libgnubatch_client.so.1
-rwxr-xr-x  /usr/lib64/libgnubatch_client.so.1.0.0
-rwxr-xr-x  /usr/lib64/libgnubatch_curs.a
-rwxr-xr-x  /usr/lib64/libgnubatch_curs.la
-rwxr-xr-x  /usr/lib64/libgnubatch_curs.lai
-rwxr-xr-x  /usr/lib64/libgnubatch_curs.so
-rwxr-xr-x  /usr/lib64/libgnubatch_curs.so.1
-rwxr-xr-x  /usr/lib64/libgnubatch_curs.so.1.0.0
-rwxr-xr-x  /usr/lib64/libgnubatch_int.a
-rwxr-xr-x  /usr/lib64/libgnubatch_int.la
-rwxr-xr-x  /usr/lib64/libgnubatch_int.lai
-rwxr-xr-x  /usr/lib64/libgnubatch_int.so
-rwxr-xr-x  /usr/lib64/libgnubatch_int.so.1
-rwxr-xr-x  /usr/lib64/libgnubatch_int.so.1.0.0

About the .a files (static libs) and the .la files (libtool archives):
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries

About the .so files, they should be a chain of symlinks:

  .so -> .so.1 -> .so.1.0.0

The executable is linked with the versioned libs:

  $ rpm -qpR gnubatch-1.10-4.fc20.x86_64.rpm |grep gnubat
  config(gnubatch) = 1.10-4.fc20
  libgnubatch_client.so.1()(64bit)
  libgnubatch_curs.so.1()(64bit)
  libgnubatch_int.so.1()(64bit)

That means the ldconfig scriptlets are missing:
https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries

The non-versioned .so files/symlinks need not be included in the package.
https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages


> install -pm 644 doc/poddoc/man/*.3 %{buildroot}/%{_mandir}/man3/

Those are about an API. Hence its manual section 3. But where is the API? No headers in the package. Did you forget to install headers into the buildroot? If so, you will also need to create a -devel subpackage.

Comment 13 Michael Schwendt 2014-04-18 20:03:00 UTC
Oh, and while I visit the bugzilla comment I submitted, I notice the package includes directory it must not include directories included in -filesystem packages, such as these which are provided by the "filesystem" package:

  drwxr-xr-x  /usr/share/man/man1
  drwxr-xr-x  /usr/share/man/man3
  drwxr-xr-x  /usr/share/man/man5
  drwxr-xr-x  /usr/share/man/man8

https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership

Comment 14 Jon Kent 2014-04-29 21:13:53 UTC
Hi,

OK, I feel like I'm going round in circles here.  When I use

make %{?_smp_mflags} CFLAGS="%{optflags}" BINDIR=%{_bindir}

The make completely fails, basically complaining about not being about to find header files, but I cannot figure out why.  Initially I thought the include statements where not correct and patch quite a few sources to point to the correct location and indeed this worked, initially.

But there is also dynamically generated code which also needs this and it confuses me that make works fine with no complaints about missing header files.

Not being a dev I'm at a stage where I'm stuck for ideas on how to proceed here.  I've got a feeling that I'm missing something obvious, but can't see it for the fog.

Cheers,
Jon

Comment 15 Michael Schwendt 2014-05-04 10:51:57 UTC
> Initially I thought the include statements where not correct 

That sounds correct.

Indeed, it's overriding a CFLAGS definition (and any -I… options in there) instead of _adding_ to existing CFLAGS (as defined in either Makefiles or the configure script):

| gcc -O -g -Wall -fno-stack-protector  -I.. -I../src/hdrs   -c
| -o helpparse.o helpparse.c

Compare with the build using modified CFLAGS:

| gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
| -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
| -m64 -mtune=generic   -c -o helpparse.o helpparse.c

Here's how it sets the variables:

$ grep CFLAGS util/Makefile.in 
CCFLAGS		=	-O @gcc_useful_options@ @funny_compiler_options@
CFLAGS		=	$(CCFLAGS) -I$(BASE) -I$(HDRS)
	-$(CC) -c -o $@ $(CFLAGS) $(GTKINCL) xhostedit.c


Multiple options:

 * Contact upstream and request a Makefile variable that could be used to append to CFLAGS at either configure-time or make-time.

 * Patch every file to achieve the same using either += or a new variable. That could get tedious.

 * An old-school hack to change and reapply configure script settings. I've noticed the script substitutes the @gcc_useful_options@ variable, so currently that one can be changed to add something:

  %configure
  sed -i 's!\(.*gcc_useful_options.*\)"$!\1 \${RPM_OPT_FLAGS}"!' config.status ; ./config.status
  make RPM_OPT_FLAGS="%{optflags}"

Usually it's a good idea to add a grep-based guard before or after the sed substitution.

As I'm not familiar with past gnubatch releases it could be that this hack will not work anymore for future releases.

Comment 16 Jon Kent 2014-05-10 15:46:55 UTC
Hi,

Many thanks for the feedback.  The sed hack, to me, seems the neatest of your suggestions so I've added this and test it.  It all works now!!!!

I've run a rpmbuild --rebuild as well.  The only error I see is it warning:

warning: File listed twice: /usr/share/gnubatch/help
warning: File listed twice: /usr/share/gnubatch/help/btint-config
warning: File listed twice: /usr/share/gnubatch/help/btq.help
warning: File listed twice: /usr/share/gnubatch/help/btrest.help
warning: File listed twice: /usr/share/gnubatch/help/btuser.help
warning: File listed twice: /usr/share/gnubatch/help/filemon.help
warning: File listed twice: /usr/share/gnubatch/help/xmbtq.help
warning: File listed twice: /usr/share/gnubatch/help/xmbtr.help
warning: File listed twice: /usr/share/gnubatch/help/xmbtuser.help

which I assume is because of this in the spec file:

%dir %{_datadir}/%{name}/help
%{_datadir}/%{name}/help/

Is the %dir required here?

I've updated the src rpm and spec file: 

SRPMS : https://spideroak.com/share/MZSWI33SMEWXG4TDOJYG24Y/fedora-gnubatch-110/home/jon/src-rpms/gnubatch-1.10-5.fc20.src.rpm

Spec URL: https://spideroak.com/share/MZSWI33SMEWXG4TDOJYG24Y/fedora-gnubatch-110/home/jon/src-rpms/gnubatch.spec


Many thanks,

Jon

Comment 17 Michael Schwendt 2014-05-10 19:21:01 UTC
> %dir %{_datadir}/%{name}/help
> %{_datadir}/%{name}/help/
> 
> Is the %dir required here?

It isn't. The second line includes the directory *and* everything in it. The %dir line includes only an entry for the directory, not for any of its contents.

The real mistake, however, is two lines before that:

  %dir %{_datadir}/%{name}
  %{_datadir}/%{name}/*
  %dir %{_datadir}/%{name}/help
  %{_datadir}/%{name}/help/*

The wildcard line

  %{_datadir}/%{name}/*

also matches

  %{_datadir}/%{name}/help

which includes that directory and its files the first time.

You could replace the four lines with just

  %{_datadir}/%{name}/
or
  %{_datadir}/%{name}

to include that dir and anything below it. The trailing slash is just for readability (to be explicit that the file entry is about a directory tree and not a single data file or such).

https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership
 -> https://fedoraproject.org/wiki/Packaging:UnownedDirectories

Comment 18 Jon Kent 2014-05-13 18:13:05 UTC
Hi,

OK, I've removed the offending line and rpmbuild --rebuild is certainly not longer complaining.

As usual I've updated the src rpm and spec file: 

SRPMS : https://spideroak.com/share/MZSWI33SMEWXG4TDOJYG24Y/fedora-gnubatch-110/home/jon/src-rpms/gnubatch-1.10-6.fc20.src.rpm

Spec URL: https://spideroak.com/share/MZSWI33SMEWXG4TDOJYG24Y/fedora-gnubatch-110/home/jon/src-rpms/gnubatch.spec

Could this be close to the end ;)

Thanks for the feedback,

Jon

Comment 19 Jon Kent 2014-05-22 08:35:35 UTC
Hi,

Just a bump to get the status of this package.

Thanks,
Jon

Comment 20 Christopher Meng 2014-05-22 11:58:03 UTC
1. /etc --> %{_sysconfdir}

2. http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd

3. BuildRequires: flex flex-devel, redundant "flex" if you BR flex-devel.

4. %description too long

5. /var --> %{_localstatedir}

Comment 22 Jon Kent 2014-06-08 15:22:29 UTC
Hi,

Just a bump to see how you think things are looking here.

Thanks,
Jon

Comment 23 Jon Kent 2014-06-18 17:49:45 UTC
Hi,

Just another bump.  Any news?


Thanks,
Jon

Comment 24 Christopher Meng 2014-06-19 06:48:10 UTC
I'm not an idiot but your package failed to build again:

+ make 'RPM_OPT_FLAGS=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables'
cd util;make all
make[1]: Entering directory '/builddir/build/BUILD/gnubatch-1.10/util'
gcc -O -g -Wall -fno-stack-protector -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables  -I.. -I../src/hdrs   -c -o helpparse.o helpparse.c
bison -y -d msgparse.y 
mv -f y.tab.c msgparse.c
gcc -O -g -Wall -fno-stack-protector -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables  -I.. -I../src/hdrs   -c -o msgparse.o msgparse.c
:  -t msglex.l > msglex.c
gcc -O -g -Wall -fno-stack-protector -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables  -I.. -I../src/hdrs   -c -o msglex.o msglex.c
gcc -O -g -Wall -fno-stack-protector -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables  -I.. -I../src/hdrs   -c -o alloc.o alloc.c
gcc  -o helpparse helpparse.o msgparse.o msglex.o alloc.o 
helpparse.o: In function `fprintf':
/usr/include/bits/stdio2.h:97: undefined reference to `line_count'
helpparse.o: In function `main':
/builddir/build/BUILD/gnubatch-1.10/util/helpparse.c:710: undefined reference to `line_count'
/builddir/build/BUILD/gnubatch-1.10/util/helpparse.c:711: undefined reference to `resetlex'
msgparse.o: In function `fprintf':
/usr/include/bits/stdio2.h:97: undefined reference to `line_count'
msgparse.o: In function `yyparse':
/builddir/build/BUILD/gnubatch-1.10/util/y.tab.c:1274: undefined reference to `yylex'
msgparse.o: In function `fprintf':
/usr/include/bits/stdio2.h:97: undefined reference to `line_count'
msgparse.o: In function `yyparse':
/builddir/build/BUILD/gnubatch-1.10/util/msgparse.y:208: undefined reference to `line_count'
/builddir/build/BUILD/gnubatch-1.10/util/msgparse.y:209: undefined reference to `yylex'
/builddir/build/BUILD/gnubatch-1.10/util/msgparse.y:210: undefined reference to `line_count'
alloc.o: In function `fprintf':
/usr/include/bits/stdio2.h:97: undefined reference to `line_count'
/usr/include/bits/stdio2.h:97: undefined reference to `line_count'
collect2: error: ld returned 1 exit status
Makefile:50: recipe for target 'helpparse' failed
make[1]: *** [helpparse] Error 1
rm msglex.c msgparse.c
make[1]: Leaving directory '/builddir/build/BUILD/gnubatch-1.10/util'
Makefile:61: recipe for target 'utild' failed
make: *** [utild] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.oxj6zH (%build)
    Bad exit status from /var/tmp/rpm-tmp.oxj6zH (%build)
RPM build errors:
Child return code was: 1
EXCEPTION: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target i686 --nodeps  builddir/build/SPECS/gnubatch.spec']
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py", line 70, in trace
    result = func(*args, **kw)
  File "/usr/lib/python2.7/site-packages/mockbuild/util.py", line 376, in do
    raise mockbuild.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode)
Error: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target i686 --nodeps  builddir/build/SPECS/gnubatch.spec']
LEAVE do --> EXCEPTION RAISED

Also, for linking the ldflags are not set yet.

Comment 25 Jon Kent 2014-06-19 19:40:39 UTC
Hi,

Thanks for the feedback.  Yup, you are right that doesn't build under mock (didn't think about checking that), though build OK directly on my PC so obviously missing something here.  I'll dig into it a bit more.

Thanks,
Jon

Comment 26 Jon Kent 2014-06-27 22:09:43 UTC
Hi,

I'm going to have to close this for the moment as I'm not getting the time to resolve the outstanding issues with it.  If time frees itself up I might revisit.

Thanks for your help,


Regards,

Jon


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