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> and i did only packaging part for qcwebcam package.
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??
(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.
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??
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.
paul, Did what u suggest changes. Can you check again those URL's and check is there something remaining to be done?
(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.
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
(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.
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
(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).
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
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??
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??
(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.
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.
thanks for your comment will do full package review
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
(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
Andy Burns, Thanks for brief review. I updated following Changes in SPEC file * Wed Jul 12 2006 Parag Nemade <panemade>- 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
(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
(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.
(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 ...
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?
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.
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??
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.
(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.
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.
(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 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.
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.