- These two lines can probably be removed from %build
#acc. README.txt
#gcc -Wall -D_LARGEFILE64_SOURCE -o nettee nettee.c

- The find commandline looks too complex to me, "chmod 644 *.sh" does afaics the same job

- The spec is not honouring the %optflags[0], e.g. use this in %build:

%{__cc} %{optflags}  -D_LARGEFILE64_SOURCE -o nettee nettee.c

- With the %opflags set, it does not compile:
In line 868 open is used with O_CREAT, but without default permissions of the file to be created. I will attach a patch that will fix this. If you add the patch to the package, please mention that this is already fixed in the development version (0.2.0 beta)[1]


[0] https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags
[1] https://fedoraproject.org/wiki/Packaging/PatchUpstreamStatus

Created attachment 322863 [details]
open with O_CREAT needs a mode

Thanks Till for your help with this package.

Updated:
Spec URL: http://fab.fedorapeople.org/packages/SRPMS/nettee.spec
SRPM URL: http://fab.fedorapeople.org/packages/SRPMS/nettee-0.1.9-2.fc9.src.rpm

Koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=922713

[OK] rpmlint output:
silent
[OK] Spec in %{name}.spec format

[OK] license allowed: GPLv2
[OK] license matches shortname in License: tag
[OK] license in tarball and included in %doc: LICENSE

[OK] package is code or permissive content:
{OK} patches sent to upstream and commented
[OK] Source0 is a working URL
{N/A} Sourceforge URL is Source0: http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
<OK> SourceX / PatchY prefixed with %{name}

[OK] Source0 matches Upstream:
35546f5f651a607365f94e115eb2ecd8  nettee-0.1.9.tar.gz

[OK] Package builds on all platforms:
http://koji.fedoraproject.org/koji/taskinfo?taskID=922713
[N/A] ExcludeArch bugs are filed and commented:
[OK] BuildRequires are complete (mock builds)
(OK) No file dependencies outside of /etc /bin /sbin /usr/bin /usr/sbin 

[N/A] %find_lang used for locales

[N/A] Every (sub)package containing libraries runs ldconfig
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
[N/A] .h (header) files are in -devel subpackage
[N/A] .a (static libraries) are in -static subpackage
[N/A] contains .pc (pkgconfig) files and has Requires: pkgconfig
(N/A) .pc files are in -devel subpackage
[N/A] contains .so.X(.Y) files and .so is in -devel
[N/A] -devel subpackage has Requires: %{name} = %{version}-%{release}
[N/A] .la files (libtool) are not included

[N/A] Has GUI and includes %{name}.desktop
[N/A] .desktop file installed with desktop-file-install in %install

[OK] Prefix: /usr not used (not relocatable)

[OK] Owns all created directories
[OK] no duplicates in %files
[OK] %defattr(-,root,root,-) is in every %files section
[OK] Does not own files or dirs from other packages
[OK] included filenames are in UTF-8

[OK] %clean is rm -rf %{buildroot} or $RPM_BUILD_ROOT 
[OK] %install starts with rm -rf %{buildroot} or $RPM_BUILD_ROOT 

[OK] Consistent macro usage

[N/A] large documentation is -doc subpackage
[OK] %doc does not affect runtime

{OK} no pre-built binaries (.a, .so*, executable)

{OK} well known BuildRoot
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
{OK} PreReq not used

{OK} RPM_OPT_FLAGS honoured
{OK} Useful debuginfo generated
{OK} no duplication of system libraries
{OK} no rpath
{OK} Timestamps preserved with cp and install
{N/A} Uses parallel make (%{?_smp_mflags})
{OK} Requires(pre,post) style notation not used
{OK} only writes to tmp /var/tmp $TMPDIR %{_tmppath} %{_builddir} (and %{buildroot} on %install and %clean)
{OK} no Conflicts
{OK} nothing installed in /srv
{OK} Changelog in allowed format
{OK} does not use Scriptlets
<N/A> Architecture independent packages have: BuildArch: noarch
<OK> Sane Provides: and Requires:
{OK} Follows Naming Guidelines

The package is APPROVED.

Nevertheless I would think about using "chmod 644 *.sh" instead of "find *.sh -type f -name \* -exec chmod 644 {} \;", to make the spec easier to read.

theoretically speaking, there is a slight difference between the two commands. find does the change recursively, unlike the direct chmod which only affects the top level folder

(In reply to comment #5)
> theoretically speaking, there is a slight difference between the two commands.
> find does the change recursively, unlike the direct chmod which only affects
> the top level folder

I know, also chmod would also remove the executable flag of directories, but in this case there are no such directories, so for this package/spec a plain chmod would do exactly the same and be easier to read.

(In reply to comment #6)
> (In reply to comment #5)
> > theoretically speaking, there is a slight difference between the two commands.
> > find does the change recursively, unlike the direct chmod which only affects
> > the top level folder
> 
> I know, also chmod would also remove the executable flag of directories, but in
> this case there are no such directories, so for this package/spec a plain chmod
> would do exactly the same and be easier to read.

I agree with Till that the spec file should be as easy to read as possible.

New Package CVS Request
=======================
Package Name: nettee
Short Description: Network "tee" program
Owners: fab
Branches: F-9 F-10 EL-5
InitialCC:

cvs done.

nettee-0.1.9-3.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/nettee-0.1.9-3.fc9

nettee-0.1.9-3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/nettee-0.1.9-3.fc10

nettee-0.1.9-3.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nettee'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-9559

nettee-0.1.9-3.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

nettee-0.1.9-3.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.