[Bug 186919] Review Request: eric: Python IDE
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: eric: Python IDE
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186919
bugzilla(a)redhat.com changed:
What |Removed |Added
----------------------------------------------------------------------------
QAContact|fedora-extras- |fedora-package-
|list(a)redhat.com |review(a)redhat.com
------- Additional Comments From rdieter(a)math.unl.edu 2006-05-01 13:29 EST -------
Those are all(most?) harmless rpmlint warnings. python scripts (*.py files)
don't have to be executable.
It appears fc5+ (auto)generates .pyo files... I wonder if there's anything
special that needs to be done packaging-wise?
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
16 years, 10 months
[Bug 181831] Review Request: bitbake - Build Tool
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: bitbake - Build Tool
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181831
bugzilla(a)redhat.com changed:
What |Removed |Added
----------------------------------------------------------------------------
QAContact|fedora-extras- |fedora-package-
|list(a)redhat.com |review(a)redhat.com
jpmahowald(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO|163778 |163779
nThis| |
------- Additional Comments From jpmahowald(a)gmail.com 2006-05-01 12:22 EST -------
- rpmlint checks return:
E: bitbake non-executable-script /usr/lib/python2.4/site-packages/bb/build.py 0644
E: bitbake non-executable-script
/usr/lib/python2.4/site-packages/bb/parse/parse_py/BBHandler.py 0644
E: bitbake non-executable-script
/usr/lib/python2.4/site-packages/bb/fetch/local.py 0644
E: bitbake non-executable-script /usr/lib/python2.4/site-packages/bb/data.py 0644
E: bitbake non-executable-script
/usr/lib/python2.4/site-packages/bb/fetch/cvs.py 0644
E: bitbake non-executable-script
/usr/lib/python2.4/site-packages/bb/fetch/svn.py 0644
E: bitbake non-executable-script /usr/lib/python2.4/site-packages/bb/event.py 0644
E: bitbake non-executable-script
/usr/lib/python2.4/site-packages/bb/fetch/wget.py 0644
E: bitbake non-executable-script
/usr/lib/python2.4/site-packages/bb/parse/parse_py/ConfHandler.py 0644
E: bitbake non-executable-script
/usr/lib/python2.4/site-packages/bb/fetch/__init__.py 0644
E: bitbake non-executable-script /usr/lib/python2.4/site-packages/bb/cache.py 0644
E: bitbake non-executable-script
/usr/lib/python2.4/site-packages/bb/parse/parse_py/__init__.py 0644
E: bitbake non-executable-script /usr/lib/python2.4/site-packages/bb/__init__.py
0644
E: bitbake non-executable-script
/usr/lib/python2.4/site-packages/bb/fetch/git.py 0644
E: bitbake non-executable-script /usr/lib/python2.4/site-packages/bb/shell.py 0644
E: bitbake non-executable-script
/usr/lib/python2.4/site-packages/bb/fetch/svk.py 0644
Which are ignorable.
- package meets naming guidelines
- package meets packaging guidelines
- license (GPL) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream
- package compiles on devel (x86_64)
- no missing BR
- no locales
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime
Building html, xhtml, text, and pdf docs seems a bit redundant. You can drop
html if you like.
- no need for .desktop file
APPROVED
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
16 years, 10 months
[Bug 188435] Review Request: glibrary-1.0.1
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: glibrary-1.0.1
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188435
------- Additional Comments From ville.skytta(a)iki.fi 2006-05-01 12:22 EST -------
(In reply to comment #3)
> Much better! The one point (not a blocker) is that you can use:
> %{_datadir}/%{name}/
>
> instead of
>
> %{_datadir}/%{name}/*
>
> Gives you the same end result.
Nope, the former results in ownership of the directory in the package (which is
desirable in this case), the latter does not. Properly owning dirs is a MUST
per the review guidelines.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
16 years, 10 months
[Bug 188435] Review Request: glibrary-1.0.1
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: glibrary-1.0.1
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188435
tcallawa(a)redhat.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|bugzilla-sink(a)leemhuis.info |tcallawa(a)redhat.com
OtherBugsDependingO|163776 |163779
nThis| |
------- Additional Comments From tcallawa(a)redhat.com 2006-05-01 12:07 EST -------
Much better! The one point (not a blocker) is that you can use:
%{_datadir}/%{name}/
instead of
%{_datadir}/%{name}/*
Gives you the same end result. I try to avoid * wherever possible.
Good:
- rpmlint checks return:
W: glibrary incoherent-version-in-changelog 1.0.1-2 1.0.1-1
E: glibrary script-without-shellbang /usr/share/doc/glibrary-1.0.1/README
E: glibrary script-without-shellbang /usr/share/doc/glibrary-1.0.1/AUTHORS
E: glibrary script-without-shellbang /usr/share/doc/glibrary-1.0.1/COPYING
E: glibrary script-without-shellbang /usr/share/doc/glibrary-1.0.1/ChangeLog
Make sure you bump your release number when you make a change. :)
Also, you should chmod -x those doc files, so that rpmlint doesn't think that
they are scripts.
- package meets naming guidelines
- package meets packaging guidelines
- license (GPL) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream
- package compiles on devel (x86)
- no missing BR
- no unnecessary BR
- locales handled properly
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime
- .desktop file ok (might consider adding an icon)
All in all, this is much better. Just some minor changes to make before you
build, but I'm convinced that you have a better grasp on things.
APPROVED.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
16 years, 10 months
[Bug 188482] Review Request: scipy-0.4.8
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: scipy-0.4.8
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188482
------- Additional Comments From ed(a)eh3.com 2006-05-01 11:16 EST -------
Hi Neal, this isn't a full review, just a few quick observations:
- Is this your first package? If so, we'll add FE-NEEDSPONSOR per:
http://fedoraproject.org/wiki/Extras/Contributors
- incorrect BuildRoot:
http://fedoraproject.org/wiki/Packaging/Guidelines
- please either make Source0 a full URL or indicate (with some
comments in the spec file) how one can generate the tar-ball
from, for instance, the upstream CVS [this is so we can more
easily verify that source matches upstream]
- please remove Prefix and Vendor
- please add a changelog
- please consider changing %defattr(-,root,root) to
%defattr(-,root,root,-)
You might want to take a look at the review guidelines:
http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
and build your rpm in mock ("yum install mock") and run your generated
RPM through rpmlint ("yum install rpmlint") to see if you might find any
other items -- it could make the job easier easier for reviewers!
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
16 years, 10 months
[Bug 188369] Review Request: ctapi-cyberjack
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: ctapi-cyberjack
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188369
------- Additional Comments From frank-buettner(a)gmx.net 2006-05-01 08:17 EST -------
The standart says noting about the the place of the libs.
But /usr/lib/ctapi will be an solution. Normaly the ctapi libs will live under
/usr/lib. The apps will normale only call dlopen(XX). XX=name of the lib.
When put the files to /usr/lib/ctapi then there we have the next problem.
Here the part of the doc about the dload function of the C lib about the search
path:
- (ELF only) If the executable file for the calling program contains a DT_RPATH
tag, and does not contain a DT_RUNPATH tag, then the directories listed in the
DT_RPATH tag are searched.
- If the environment variable LD_LIBRARY_PATH is defined to contain a
colon-separated list of directories, then these are searched. (As a security
measure this variable is ignored for set-UID and set-GID programs.)
- (ELF only) If the executable file for the calling program contains a
DT_RUNPATH tag, then the directories listed in that tag are searched.
- The cache file /etc/ld.so.cache (maintained by ldconfig(8)) is checked to
see whether it contains an entry for filename.
- The directories /lib and /usr/lib are searched (in that order).
When the files are in /usr/lib/ctapi the the apps will not find it without set
an global LD_LIBRARY_PATH. Or we simple add the files to /usr/lib/ctapi and put
an extra config file to /etc/ld.so.conf.d But this have the problem the each
ctapi driver muste create an extra dir.
example:
/usr/lib/ctapi/ReinerSCT/libctapi-cyberjack.so
/usr/lib/ctapi/Kobil/libctapi-XXXX.so
/usr/lib/ctapi/ZZ/libctapi-XXX.so
ZZ= maufacture of the device
XXX= produce name
I think before I can work forwart we must found an global solution for CT-API in
Fedora.
Here the link to the offical CT-API doc:
In german:
http://www.teletrust.de/index.php?id=303
In english:
http://www.teletrust.de/index.php?id=548
In my package the are 2 sample apps that use this API.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
16 years, 10 months