Bug 193224 - Review Request: streamer
Review Request: streamer
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
5
i386 Linux
medium Severity urgent
: ---
: ---
Assigned To: Thorsten Leemhuis (ignored mailbox)
Fedora Package Reviews List
: Reopened
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2006-05-26 05:41 EDT by Parag AN(पराग)
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-01 08:52:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Parag AN(पराग) 2006-05-26 05:41:55 EDT
Spec URL: http://people.redhat.com/pnemade/Qcwebcam/streamer.spec
SRPM URL: http://people.redhat.com/pnemade/Qcwebcam/streamer-1.1-2.fc5.src.rpm
Description: This is the coammnd line tool to record streaming video from qcwebcam package. This is extracted from XawTv package. All the original work is done by Gerd Knorr <kraxel@bytesex.org> and i did only packaging part for qcwebcam package.
Comment 1 Parag AN(पराग) 2006-05-29 05:32:31 EDT
can any one check whether this package is according to Fedora Extras Guidlines??
Is there anything remaining or its ready to go in Fedora Extras??
Comment 2 Paul Howarth 2006-05-29 06:05:30 EDT
(In reply to comment #1)
> can any one check whether this package is according to Fedora Extras Guidlines??
> Is there anything remaining or its ready to go in Fedora Extras??

It can go into Fedora Extras when someone has reviewed it, approved it, and
changed the blocker bug to FE-ACCEPT. So far none of these things have happened.

Do you currently have any other packages already in Fedora Extras? If not,
you'll also need a sponsor for cvs access, and should add the blocker bug of
FE-NEEDSPONSOR to this review request.
Comment 3 Parag AN(पराग) 2006-05-29 06:44:21 EDT
i am already waiting for package
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193216 approval and
streamer is required to be installed first before using qcwebcam package. I need
sponsor for cvs access. What steps shoul i follow?
how can i add he blocker bug of FE-NEEDSPONSOR to this review request??
Comment 4 Paul Howarth 2006-05-29 08:07:40 EDT
I had a quick look at this package, and spotted these things:

1. Lose the "Provides: streamer-1.1-2" header. RPM will generate an appropriate
Provides: entry itself.

2. Wrap the %description at 80 columns.

3. Try to wrap lomg lines in %install by using backslashes and continuation
lines to make the spec file more readable.

4. The package does not honor %{optflags}. You can fix this by adding the
following command to the end of %prep:

sed -i -e 's/^\(CFLAGS *:= \).*/\1%{optflags}/' Makefile

5. Include some documentation. README and ChangeLog seem appropriate.

6. If you are this package's upstream, bundle a copy of the GPL with the tarball
and include it as %doc in the RPM package. If you're not upstream yourself, ask
whoever is to include a copy of the GPL.

7. Add missing buildreqs ncurses-devel libXt-devel libjpeg-devel libpng-devel
(test-build your packages in mock to find missing buildreqs)

8. Lose the "-s" from the install commands. Stripping binaries is done
automatically by rpmbuild and if you do it yourself you'll get useless debuginfo
packages.

9. Your package needs to own directory %{_libdir}/streamer/; otherwise, it will
left on the system when the package is removed.

(In reply to comment #3)
> i am already waiting for package
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193216 approval and
> streamer is required to be installed first before using qcwebcam package.

This is why I added bug 193216 to the list of bugs that this one blocks. You
need to get this package into Extras before qcwebcam because that package
depends on this one.

> I need sponsor for cvs access. What steps shoul i follow?

See http://www.fedoraproject.org/wiki/Extras/Contributors

> how can i add he blocker bug of FE-NEEDSPONSOR to this review request??

It appears you have figured that out for yourself. I have reponed this bug
though, which you appear to have closed by mistake.
Comment 5 Parag AN(पराग) 2006-05-29 08:45:29 EDT
paul,
     Did what u suggest changes. Can you check again those URL's and check is
there something remaining to be done?
Comment 6 Paul Howarth 2006-05-29 08:53:12 EDT
(In reply to comment #5)
> paul,
>      Did what u suggest changes. Can you check again those URL's and check is
> there something remaining to be done?

Can you please increment the release number of the package, make an appropriate
changelog entry, and post updated URLs whenever you make a change to the
package? This helps people reading the review request to identify which comments
are associated with which revision of the package.
Comment 7 Parag AN(पराग) 2006-05-29 09:08:14 EDT
I updated Release number and added a ChangeLog entry in it. Updated files are at
Spec URL: http://people.redhat.com/pnemade/Qcwebcam/streamer.spec
SRPM URL: http://people.redhat.com/pnemade/Qcwebcam/streamer-1.1-3.fc5.src.rpm
Comment 8 Paul Howarth 2006-05-29 11:48:45 EDT
(In reply to comment #7)
> I updated Release number and added a ChangeLog entry in it. Updated files are at
> Spec URL: http://people.redhat.com/pnemade/Qcwebcam/streamer.spec
> SRPM URL: http://people.redhat.com/pnemade/Qcwebcam/streamer-1.1-3.fc5.src.rpm

Thanks. What appears to have happened now is that upstream (you) have released a
new tarball at version 1.1 that contains the GPL file, which was not the case
with the version 1.1 tarball I last looked at. *Please* don't release new
tarballs with the same version numbers as previous releases - that's a really
bad habit to get into.

You've fixed the unowned directory by adding the following line to %files:
%{_libdir}/streamer/

This tells RPM to include that directory and everything underneath it, which
results in lots of "file included twice" warnings when the package is built. To
avoid this, do either:

%{_libdir}/streamer/
(which will include everything from that directory downwards), or

%dir %{_libdir}/streamer/
plus all the individual files that you currently list in the %files section. The
%dir tag tells RPM to include the directory but not its contents.

The build process produces quite a lot of compiler warnings. Most of these can
be ignored, but these warrant investigation I think:

console/capture.c: In function 'movie_writer_stop':
console/capture.c:528: warning: integer constant is too large for 'long' type
console/capture.c:533: warning: integer constant is too large for 'long' type
console/capture.c: In function 'movie_print_timestamps':
console/capture.c:588: warning: integer constant is too large for 'long' type
console/capture.c:588: warning: integer constant is too large for 'long' type
console/capture.c: In function 'movie_grab_put_video':
console/capture.c:624: warning: integer constant is too large for 'long' type

In order to get sponsored, you will need to demonstrate to a potential sponsor
that you are familiar with the Fedora Extras processes and standards. The best
way of doing this is to review other people's packages. Doing this can also be a
useful learning experience for yourself, as you're likely to pick up tips from
other packages and review comments.
Comment 9 Parag AN(पराग) 2006-05-30 00:40:35 EDT
paul,
     I didnt get what u mean by 
>Thanks. What appears to have happened now is that upstream (you) have released a
>new tarball at version 1.1 that contains the GPL file, which was not the case
>with the version 1.1 tarball I last looked at. *Please* don't release new
>tarballs with the same version numbers as previous releases - that's a really
>bad habit to get into.
  Also i solved rpmbuild "file included twice" warnings and some other warnings.
Other signedness warnings are ok as they are compiler specific. Same warnings
are not coming on FC4 and RHEL systems.
   Do i need to update to new release number. if yes why?? i only solved
warnings not added any feature.

I updated SPEC file and rebuild RPM. Updated files are at
Spec URL: http://people.redhat.com/pnemade/Qcwebcam/streamer.spec
SRPM URL: http://people.redhat.com/pnemade/Qcwebcam/streamer-1.1-3.fc5.src.rpm
Comment 10 Paul Howarth 2006-05-30 09:11:13 EDT
(In reply to comment #9)
>      I didnt get what u mean by 
> >Thanks. What appears to have happened now is that upstream (you) have released a
> >new tarball at version 1.1 that contains the GPL file, which was not the case
> >with the version 1.1 tarball I last looked at. *Please* don't release new
> >tarballs with the same version numbers as previous releases - that's a really
> >bad habit to get into.

OK, I'll give examples. In your original bugzilla submission for this package
you posted a URL for streamer-1.1-2.fc5.src.rpm. This SRPM contains a tarball
streamer-1.1.tar.bz2. In Comment #7 you posted a URL for
streamer-1.1-3.fc5.src.rpm, another SRPM, which also contains a tarball
streamer-1.1.tar.bz2. However, this was different from the previous tarball of
the same name because it contained an additional file, "GPL". In Comment #9 you
reposted the same URL as in Comment #7, but now the SRPM at that URL contains
yet another version of streamer-1.1.tar.bz2 that is different from the previous
two releases. So if I refer in my review to a problem with the streamer version
1.1 release, what am I actually referring to? There are to my knowledge at least
three different things that could be described as streamer version 1.1. This is
terribly confusing. 

To avoid this confusion, follow these rules of thumb:
1. If you change the contents of a tarball, no matter how minor the change, the
version number of that tarball (and hence the package containing it as well)
should be increased.
2. If you change any other aspect of the package, such as a spec file, adding or
changing a patch etc., the release number of the package should be increased.
This ensures that there is never a case where there are two different packages
with the same name but different contents.

>   Also i solved rpmbuild "file included twice" warnings and some other warnings.

Yes, that's good.

> Other signedness warnings are ok as they are compiler specific. Same warnings
> are not coming on FC4 and RHEL systems.

You'll need to build on FC5 or later to see some of these warnings. The ones I
was most concerned about are still there:

  CC      console/capture.o
console/capture.c: In function 'ng_grabber_setformat':
console/capture.c:183: warning: pointer targets in passing argument 1 of
'ng_ratio_fixup' differ in signedness
console/capture.c:183: warning: pointer targets in passing argument 2 of
'ng_ratio_fixup' differ in signedness
console/capture.c: In function 'movie_writer_stop':
console/capture.c:528: warning: integer constant is too large for 'long' type
console/capture.c:533: warning: integer constant is too large for 'long' type
console/capture.c: In function 'movie_print_timestamps':
console/capture.c:588: warning: integer constant is too large for 'long' type
console/capture.c:588: warning: integer constant is too large for 'long' type
console/capture.c: In function 'movie_grab_put_video':
console/capture.c:624: warning: integer constant is too large for 'long' type

>    Do i need to update to new release number. if yes why?? i only solved
> warnings not added any feature.

The package has changed. It's a new release, different from the previous one.
The release number should be increased and there should be a changelog entry
describing the changes (note: the changelog in the RPM spec describes the
changes to the packaging rather than the changes to the application itself -
changes to the application are normally described in a changelog file in the
application's tarball).
Comment 11 Parag AN(पराग) 2006-05-31 08:17:41 EDT
paul,
  I solved all problems now by reversioning all my Source as well as SPEC
Changes. I have placed all my SRPMS right from the first i posted to review to
latest one.
Latest SPEC URL: http://people.redhat.com/pnemade/Qcwebcam/streamer.spec

First Version(1.1.1-1) posted for review is at=>
SRPM URL: http://people.redhat.com/pnemade/Qcwebcam/streamer-1.1.1-1.fc5.src.rpm

Then I added Following Changes to next version(1.1.2-1)
- Solved Package dependency problem by adding BuildRequires in SPEC file.
- Added GPL ChangeLog README in SPEC file and added GPL in tarball.
- Remove Provides header
- Wrap Description at 80 columns 
- Remove stripping binaries by removing -s from install
SRPM URL: http://people.redhat.com/pnemade/Qcwebcam/streamer-1.1.2-1.fc5.src.rpm

Then in Next version(1.1.3-1) I added
- Added dir macro to avoid file inclusion twice
- Change some code to remove warnings coming at compilation
SRPM URL: http://people.redhat.com/pnemade/Qcwebcam/streamer-1.1.3-1.fc5.src.rpm
 
Comment 12 Parag AN(पराग) 2006-05-31 09:41:50 EDT
paul,
    How can this package will come to Fedora-Extras as i cannot see any new
Review Request bugzilla ID that you said me to check it? Does that mean i need
to wait until i review any package??
Comment 13 Parag AN(पराग) 2006-05-31 09:51:18 EDT
paul,
  sorry i was searching at wrong place. Got new requests for Review Package. So
i can directly interfere Review Request for others even if Bugzilla is going to
assing it to somebody??
Comment 14 Paul Howarth 2006-05-31 09:59:08 EDT
(In reply to comment #13)
>   sorry i was searching at wrong place. Got new requests for Review Package. So
> i can directly interfere Review Request for others even if Bugzilla is going to
> assing it to somebody??

Yes, just add your comments as you would in a normal bug report, without
changing any of the assignment/status etc. fields.
Comment 15 Paul Howarth 2006-06-05 06:27:42 EDT
I see you've made a few comments on other package reviews, but unless I've
missed something these appear to be limited to posting the output of rpmlint.
This is just domonstrating that you can can use bugzilla and rpmlint. What I'd
really like to see is a detailed review of a package (use the package review
guidelines from http://fedoraproject.org/wiki/Packaging/ReviewGuidelines). If
you find problems with a package, don't just point them out, make a suggestion
for how to fix the problem (if you know how - otherwise, try asking on
fedora-extras-list - it will be a useful learning experience). Remember, what a
sponsor is looking for is that you know how to make good packages and are aware
of the Fedora Extras processes and packaging standards. Doing a detailed,
point-by-point review will go a long way towards demonstrating that.
Comment 16 Parag AN(पराग) 2006-06-05 07:00:21 EDT
thanks for your comment will do full package review
Comment 17 Andy Burns 2006-07-11 19:54:49 EDT
Review of http://people.redhat.com/pnemade/Qcwebcam/streamer-1.1.3-1.fc5.src.rpm

* rpmlint must be run on every package.

  $rpmlint -v /home/andy/Desktop/streamer-1.1.3-1.fc5.src.rpm
  I: streamer checking

  $ rpmlint -v /usr/src/redhat/RPMS/i386/streamer-1.1.3-1.i386.rpm
  I: streamer checking
  W: streamer incoherent-version-in-changelog 1.1-3-1 1.1.3-1

  $ rpmlint -v /usr/src/redhat/RPMS/i386/streamer-debuginfo-1.1.3-1.i386.rpm
  I: streamer-debuginfo checking

  suggest correcting version 1.1-3-1 to 1.1.3-1 likewise 1.1-2-1 to 1.1.2-1
  otherwise ok

* package must be named according to the guidelines.

  ok

* spec file name must match the base package name

  ok

* package must meet the Packaging Guidelines.

  It amuses me that meeting the packaging guidlines is an item within the
packaging guidelines checklist

* package must be licensed with an open-source compatible license 

  spec file = GPL
  tarball contains licence file = GPL v2  

* The License field in the package spec file must match the actual license.

  most source files themselves do contain copyright, but not licencing info,
  of those that do, only one or two clearly state GPL, 
  others in contrib-plugin directory seem to make a weaker GPL claim.

* If package includes the text of the license(s) in its own file, then that file
must be included in %doc.

  ok

* The spec file must be written in American English.

  ok

* The spec file for the package MUST be legible.

  ok, to be ultrapicky, add a space between "Name:" and "streamer"?
  suggestion, make Description: slightly more, err, descriptive 
  e.g. use "Command line tool for streaming capture, including audio." from the
README file.
 
* The sources used to build the package must match the upstream source

  cannot test because source
  http://people.redhat.com/pnemade/Qcwebcam/streamer-1.1.3.tar.bz2
  does not exist

* The package must successfully compile and build into binary rpms on at least
one supported architecture.

  compiled and build on i386 (FC6T1/rawhide)

* If the package does not successfully compile, build or work on an
architecture, then those architectures should be listed in the spec in
ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed
in bugzilla, describing the reason that the package does not compile/build/work
on that architecture. The bug number should then be placed in a comment, next to
the corresponding ExcludeArch line. New packages will not have bugzilla entries
during the review process, so they should put this description in the comment
until the package is approved, then file the bugzilla entry, and replace the
long explanation with the bug number. (Extras Only) The bug should be marked as
blocking one (or more) of the following bugs to simplify tracking such issues:
[WWW] FE-ExcludeArch-x86, [WWW] FE-ExcludeArch-x64, [WWW] FE-ExcludeArch-ppc

  nothing excluded, I can test on FC5/x86_64 later, does the packager know how
it performs on other architectures?

* All build dependencies must be listed in BuildRequires, except for any that
are listed in the exceptions section of Packaging Guidelines; inclusion of those
as BuildRequires is optional. Apply common sense.

  Some BRs are specified, I have not checked the list is exhaustive

* The spec file MUST handle locales properly

  No locales in package

* If the package contains shared library files located in the dynamic linker's
default paths, that package must call ldconfig 

  ok, .so files in own directory only, not added to linker path

* If the package is designed to be relocatable, the packager must state this
fact in the request for review, along with the rationalization for relocation of
that specific package. Without this, use of Prefix: /usr is considered a blocker.

  no such statement, assume this is correct.

* A package must own all directories that it creates. If it does not create a
directory that it uses, then it should require a package which does create that
directory. The exception to this are directories listed explicitly in the
Filesystem Hierarchy Standard ([WWW]
http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that
those directories exist.

  ok (/usr/lib/streamer and /usr/share/doc/streamer-version)

* A package must not contain any duplicate files in the %files listing.

  ok, all files explicitly listed, no wildcards used at all
  would it be considered neater to use %{_libdir}/streamer/*.so instead?

* Permissions on files must be set properly. Executables should be set with
executable permissions, for example. Every %files section must include a
%defattr(...) line.

  ok, permissions on files set within rpm, not modified by %defattr or %attr

* package must have a %clean section, which contains rm -rf %{buildroot} (or
$RPM_BUILD_ROOT).

  ok

* package must consistently use macros, as described in the macros section of
Packaging Guidelines.
 
  does use both $ and % macros, but never mixes usage for the same macro, so
meets guidelines

* The package must contain code, or permissable content. This is described in
detail in the code vs. content section of Packaging Guidelines.

  ok, executable + supporting libraries

* Large documentation files should go in a -doc subpackage. (The definition of
large is left up to the packager's best judgement, but is not restricted to
size. Large can refer to either size or quantity)
 
  separate -doc not justified!

* If a package includes something as %doc, it must not affect the runtime of the
application. To summarize: If it is in %doc, the program must run properly if it
is not present.

  ok

* Header files or static libraries must be in a -devel package.

  none

* Files used by pkgconfig (.pc files) must be in a -devel package.

  none

* If a package contains library files with a suffix (e.g. libfoo.so.1.1), then
library files that end in .so (without suffix) must go in a -devel package.

  ok, no suffixes used

* In the vast majority of cases, devel packages must require the base package
using a fully versioned dependency: Requires: %{name} = %{version}-%{release} 

  ok, no devel package

* Packages must NOT contain any .la libtool archives, these should be removed in
the spec.

  ok

* Packages containing GUI applications must include a %{name}.desktop file, and
that file must be properly installed with desktop-file-install in the %install
section. This is described in detail in the desktop files section of Packaging
Guidelines. If you feel that your packaged GUI application does not need a
.desktop file, you must put a comment in the spec file with your explanation.

  ok, not a GUI app

* must not own files or directories already owned by other packages. The rule of
thumb here is that the first package to be installed should own the files or
directories that other packages may rely upon. This means, for example, that no
package in Fedora should ever share ownership with any of the files or
directories owned by the filesystem or man package. If you feel that you have a
good reason to own a file or directory that another package owns, then please
present that at package review time.

  ok

* If the source package does not include license text(s) as a separate file from
upstream, the packager SHOULD query upstream to include it.

  ok, GPL file included

* The description and summary sections in the package spec file should contain
translations for supported Non-English languages, if available.

  none included

* The reviewer should test that the package builds in mock.

  not tested

* The package should compile and build into binary rpms on all supported
architectures.

  only tested on i386/FC6T1(rawhide)

* The reviewer should test that the package functions as described. A package
should not segfault instead of running, for example.

  I do not have appropriate video capture hardware on this machine

* If scriptlets are used, those scriptlets must be sane. This is vague, and left
up to the reviewers judgement to determine sanity.

  Ok, none used.

* Usually, subpackages other than devel should require the base package using a
fully versioned dependency. 
 
  ok, no sub-packages

Comment 18 Andy Burns 2006-07-11 19:59:46 EDT
(In reply to comment #17)

> The sources used to build the package must match the upstream source
> 
>   cannot test because source
>   http://people.redhat.com/pnemade/Qcwebcam/streamer-1.1.3.tar.bz2
>   does not exist

However previous versions of streamer source tarballs appear to be in 
http://people.redhat.com/pnemade/streamer/ 
directory, rather than http://people.redhat.com/pnemade/Qcwebcam

Comment 19 Parag AN(पराग) 2006-07-12 00:01:34 EDT
Andy Burns,
   Thanks for brief review. I updated following Changes in SPEC file
 * Wed Jul 12 2006 Parag Nemade <panemade@gmail.com>- 1.1.3-2
- Corrected Changelog entry
- Added wildcard in files section
- Changed Source Package Path
- Clean the SPEC file look

I have changed Source URL now. I will be happy if you please do review for
x86_64 architecture.

I updated SPEC file and rebuild RPM. Updated files are at
Spec URL: http://people.redhat.com/pnemade/streamer/streamer.spec
SRPM URL: http://people.redhat.com/pnemade/streamer/streamer-1.1.3-2.fc5.src.rpm

Comment 20 Andy Burns 2006-07-12 03:55:20 EDT
(In reply to comment #19)

> - Added wildcard in files section

I was genuinely asking if it would be better to use the wildcard, or have the
multiple single files, I'd be interested to see an answer from an experienced
reviewer on this ...

> I have changed Source URL now. I will be happy if you please do review for
> x86_64 architecture.

ok, will do so this evening, would appreciate a review in return
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758

Comment 21 Paul Howarth 2006-07-12 10:39:15 EDT
(In reply to comment #17)
> * package must meet the Packaging Guidelines.
> 
>   It amuses me that meeting the packaging guidlines is an item within the
> packaging guidelines checklist

The package review guidelines is not actually a checklist of things in the
packaging guidelines. The packaging guidelines as a whole encompasses a bunch of
pages on the wiki (see http://fedoraproject.org/wiki/Packaging), which include
the main packaging guidelines, the package naming guidelines, plus a number of
pages on language-specific guidelines. Extras contributors are expected to have
read the main packaging and naming guidelines and be familar with them
(committing them all to memory isn't expected but it's worth re-reading them
from time to time as a refresher and to catch up with changes). The review
guidelines page just includes a checklist of things that apply to most packages.

> * All build dependencies must be listed in BuildRequires, except for any that
> are listed in the exceptions section of Packaging Guidelines; inclusion of those
> as BuildRequires is optional. Apply common sense.
> 
>   Some BRs are specified, I have not checked the list is exhaustive

Building the package in mock is a good way to test this.

> * If the package is designed to be relocatable, the packager must state this
> fact in the request for review, along with the rationalization for relocation of
> that specific package. Without this, use of Prefix: /usr is considered a blocker.
> 
>   no such statement, assume this is correct.

This relates to the use of the "Prefix:" rpm tag. If present, the package is
telling rpm that it's supposed to be relocatable (whether it actually is or not
depends on how the rest of the package is built). Some packagers tend to include
the "Prefix:" tag because they've copied the spec from some template that
included it. This check is there to catch that mistake.

> * A package must not contain any duplicate files in the %files listing.
> 
>   ok, all files explicitly listed, no wildcards used at all
>   would it be considered neater to use %{_libdir}/streamer/*.so instead?

This check is looking for instances of the same file being installed in multiple
different places (e.g. a README installed in %{_docdir}/%{name}-%{version} and
also %{datadir}/%{name}) rather than being included more than once in the %files
list (which rpmbuild will warn about actually).

(In reply to comment #20)
> (In reply to comment #19)
> 
> > - Added wildcard in files section
> 
> I was genuinely asking if it would be better to use the wildcard, or have the
> multiple single files, I'd be interested to see an answer from an experienced
> reviewer on this ...

This is really a matter of personal preference and may vary from package to
package. In general I like to enumerate all of the files individually,
particularly for binaries, as this results in unpackaged file errors if you
build a later version of the package that contains additional files, something
that you really should know about as the new files might clash with some other
package. An alternative approach here would be to use rpmdiff to compare old and
new packages. For some packages though, the list of files would simply be
unmanagable if done individually, so using a wildcard is the only sane option.
Comment 22 Andy Burns 2006-07-12 18:46:55 EDT
(In reply to comment #19)

> - Corrected Changelog entry
> - Added wildcard in files section
> - Changed Source Package Path
> - Clean the SPEC file look
> 
> I have changed Source URL now. I will be happy if you please do review for
> x86_64 architecture.

changelog version tidy-up has silenced rpmlint

Source0: now points to correct location

$ md5sum /usr/src/redhat/SOURCES/streamer-1.1.3.tar.bz2 
ce10341fb74870e4b69fe2c778cd17b1  /usr/src/redhat/SOURCES/streamer-1.1.3.tar.bz2

$ wget  http://people.redhat.com/pnemade/streamer/streamer-1.1.3.tar.bz2
$ md5sum /tmp/streamer-1.1.3.tar.bz2 
ce10341fb74870e4b69fe2c778cd17b1  /tmp/streamer-1.1.3.tar.bz2

srpm is built from the specified source file

installed http://people.redhat.com/pnemade/streamer/streamer-1.1.3-2.fc5.src.rpm
on x86_64 FC5+updates

compiler spits out a few 64bit related warnings (mainly %llx format strings in
printf expecting, but not receiving long long arguments)

libng/plugins/read-avi.c: In function 'avi_add_movi':
libng/plugins/read-avi.c:66: warning: format '%llx' expects type 'long long
unsigned int', but argument 6 has type 'off_t'
libng/plugins/read-avi.c:66: warning: format '%llx' expects type 'long long
unsigned int', but argument 7 has type 'off_t'
libng/plugins/read-avi.c: In function 'avi_find_chunk':
libng/plugins/read-avi.c:216: warning: format '%llx' expects type 'long long
unsigned int', but argument 5 has type 'off_t'
libng/plugins/drv0-v4l2-old.c: In function 'xioctl':
libng/plugins/drv0-v4l2-old.c:234: warning: format '%Ld' expects type 'long long
int', but argument 11 has type 'stamp_t'

however these will probably get type promoted ok, and don't stop the build,
could be cleaned up with a patch though, at minimum casting arguments to long
long to silence the warnings.

spec file now cleaner to my eye

I've got a creative webcam pro somewhere, which has V4L1 drivers, but not V4L2
drivers from what I remember, I'll dig it out and check if the program can
actuall do any streaming ...

Comment 23 Parag AN(पराग) 2006-07-13 04:52:49 EDT
Ok i have updated Source tarball. I don't have 64 bit machine but from warning
messages i changed code and now updated files are at
Spec URL: http://people.redhat.com/pnemade/streamer/streamer.spec
SRPM URL: http://people.redhat.com/pnemade/streamer/streamer-1.1.4-1.fc5.src.rpm

can you again review this new package for x86_64 arch?
Comment 24 Paul Howarth 2006-08-31 05:38:24 EDT
The only remaining warning is:

libng/plugins/read-avi.c: In function 'avi_find_chunk':
libng/plugins/read-avi.c:217: warning: format '%llx' expects type 'long long 
unsigned int', but argument 5 has type 'off_t'

rpmlint complains:
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/flt-disor.so: File
format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/conv-mjpeg.so:
File format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/conv-audio.so:
File format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/flt-gamma.so: File
format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/read-avi.so: File
format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/linedoubler.so:
File format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/flt-invert.so:
File format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/bilinear.so: File
format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/linear-blend.so:
File format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/drv0-v4l2.so: File
format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/cubic.so: File
format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/drv1-v4l.so: File
format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/write-avi.so: File
format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/snd-oss.so: File
format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/drv0-v4l2-old.so:
File format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/lib64/streamer/flt-smooth.so:
File format not recognized
W: streamer objdump-failed objdump:
/tmp/streamer-1.1.4-1.fc6.x86_64.rpm.21567/usr/bin/streamer: File format not
recognized

I don't know why that's happening.
Comment 25 Parag AN(पराग) 2006-08-31 07:20:06 EDT
But on my i386 machine i didn't get any warning in compilation or error in
rpmlint  output.
sorry i don't have x86_64 machine. How can i solve this problem now??
Comment 26 Parag AN(पराग) 2006-09-01 08:52:13 EDT
Ok After seeing peoples getting sponserships within 2 days who claim to be
newbies for this procedure, I think i did not deserved then to be Sponserer so i
think its time to make Official reviewers burden less by closing this bug.
Comment 27 Paul Howarth 2006-09-01 10:22:34 EDT
(In reply to comment #26)
> Ok After seeing peoples getting sponserships within 2 days who claim to be
> newbies for this procedure, I think i did not deserved then to be Sponserer so i
> think its time to make Official reviewers burden less by closing this bug.

I understand yur frustration at not being sponsored yet, despite being very
active and doing everything asked of you, especially when you see other new
contributors getting sponsored very quickly. Having already sponsored a few
people, I've become very careful to make sure that I think any new contributor I
sponsor now is fully aware of how how to work within Fedora Extras and not make
too many mistakes (since I as their sponsor would end up having to fix them,
which I've had to do in the past). As a result, it may be that the bar for being
sponsored by me is higher than it would be for some other sponsors. Other issues
for me include the fact that I've recently changed jobs and have less time to
review submissions than I used to have (I've only done one review in the past
couple of months I think). There's also the problem that I haven't got any means
of testing either this or the qcwebcam submission.

On the plus side, it looks like someone else may also be willing to sponsor you
(Kevin in Bug #199254). You might refer Kevin to this ticket and the qcwebcam
one as other examples of your work. Once you're sponsored, any contributor will
then be able to review these submissions and it's more likely that someone with
the right hardware will appear and be able to do that for you. So if I was you
I'd reopen these tickets. They'll get in eventually, but that won't happen if
the tickets are closed.
Comment 28 Parag AN(पराग) 2006-09-01 23:53:02 EDT
Paul,
 I am not blaming here anyone at all as i already said may be i did not deserved
to get sponsorship. I already said is one of my bugs that i am ready to wait.
But what made me to write my previous comment is that after seeing toher newbies
getting sponsorships within 2 days. So anyway i am not leaving to review/add
comments here as it became a part of my hobbies as well my hunger to review
other peoples packages. But i decided to stop submitting packages. I have
already 2 packages ready to submit but i was waiting for my sponsorship. But due
to some other work i failed to prove myself.
 
 And i don't understand why you are taking resposibility to comment here. I
thinks its THL's responsibility to answer here.

I request Thorsten Leemhuis to comment here as it looks its assigned to him.
 
Comment 29 Paul Howarth 2006-09-02 01:53:46 EDT
(In reply to comment #28)
>  And i don't understand why you are taking resposibility to comment here. I
> thinks its THL's responsibility to answer here.
> 
> I request Thorsten Leemhuis to comment here as it looks its assigned to him.

Thorsten's address was the default one assigned to new review requests
(nobody@fedoraproject.org is now used for this purpose). Having a buig assigned
to that address means that nobody has yet decided to formally review a package,
that's all.
Comment 30 Parag AN(पराग) 2006-09-02 02:03:05 EDT
yes i discussed that on #fedora-extras with kevin. I thought the new procedure
is followed to all older review request bugs also and i only check current state
of bug before sending any comments. So thought maybe while creating this bug it
got assigned to thl but blocker bug clearly indicated that its not under FE-REVIEW.

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