Bug 438543

Summary: Review Request: Synopsis - Source-code introspection tool.
Product: [Fedora] Fedora Reporter: Stefan Seefeld <stefan>
Component: Package ReviewAssignee: Mamoru TASAKA <mtasaka>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: fedora-package-review, mtasaka, notting, pahan
Target Milestone: ---Flags: mtasaka: fedora-review+
kevin: fedora-cvs+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-01 09:35:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Workaround patch for lib64 issue none

Description Stefan Seefeld 2008-03-21 17:19:32 UTC
Spec URL: http://synopsis.fresco.org/download/srpm/synopsis.spec
SRPM URL: http://synopsis.fresco.org/download/srpm/synopsis-0.10-1.fc8.src.rpm
Description: 

Hi,

I released Synopsis version 0.10 yesterday, and I would appreciate a review to be able to integrate it into Fedora. I have validated all generated packages via rpmlint.

Description of the package:

Synopsis is a multi-language source code introspection tool that provides a variety of representations for the parsed code to enable further processing such as documentation extraction, reverse engineering, and source-to-source translation.

Thanks,
           Stefan

Comment 1 Mamoru TASAKA 2008-04-14 18:39:14 UTC
*** Bug 220393 has been marked as a duplicate of this bug. ***

Comment 2 Mamoru TASAKA 2008-04-17 13:23:48 UTC
Rebuild failed on dist-f9:
http://koji.fedoraproject.org/koji/taskinfo?taskID=570545

Even after "BuildRequires: byacc" is added, build still fails:
http://koji.fedoraproject.org/koji/taskinfo?taskID=570565

Comment 3 Stefan Seefeld 2008-04-19 20:57:26 UTC
Thanks for the feedback ! It seems this is an incompatibility with yacc (it
works fine with bison). I have fixed this problem, and will submit a new source
package soon.

I'v been trying to package this on a x86_64 box myself, and run into another
issue. May be you know how to address this:

In my spec file I list files, using the %{_libdir} variable, as per your earlier
suggestion. This expands to /usr/lib64. However, the buildsystem itself uses
autoconf, which provides a 'libdir' variable, but which expands to /usr/lib.
Thus, my library files end up in /usr/lib, and then rpmbuild tries to find them
in /usr/lib64, and obviously fails.
What can I do about that ? autoconf and rpmbuild seem to disagree about the file
system layout. Is there a way around this ? Is this a known issue ?

Thanks !

Comment 4 Mamoru TASAKA 2008-04-20 05:52:24 UTC
I must say I cannot investigate what is happening to your source
unless your source is given to me. So would you upload your srpm
anyway (with fixes as much as possible)?

Comment 5 Stefan Seefeld 2008-04-22 13:13:14 UTC
I uploaded an updated the srpm package to the above location at

http://synopsis.fresco.org/download/srpm/synopsis-0.10-1.fc8.src.rpm

rpmbuild runs fine on i386, but I get errors on x86_64, due to _libdir and
py_sitedir variables in synopsis.spec being expanded to 'unexpected' values (see
my previous message). Any help is highly appreciated.

Comment 6 Stefan Seefeld 2008-04-25 15:56:58 UTC
I just uploaded what I hope may become synopsis 0.11, as srpm:

http://synopsis.fresco.org/download/srpm/synopsis-0.11-1.fc8.src.rpm

Please note that this is not an official release yet, as I'd rather like to
incorporate any changes you may suggest in order to make this acceptable for
inclusion into Fedora.
Thanks

Comment 7 Mamoru TASAKA 2008-04-26 05:55:57 UTC
Does not build even on i386
- At least "flex byacc" are missing from BuildRequires
- Even if "flex byacc" are added to BuildRequires, build
  still fails
  http://koji.fedoraproject.org/koji/taskinfo?taskID=584014

Comment 8 Stefan Seefeld 2008-04-26 18:00:11 UTC
Thanks for the feedback. Is there any particular reason to prefer byacc over bison ?

As to the build failure, unfortunately I'm unable to reproduce it. I'm now
trying to build via 'mock', so may be things will look different there.

One thing I noticed is an error in your build.log is this:

ln: 
creating symbolic link
`/builddir/build/BUILD/synopsis-0.11/src/Synopsis/gc/atomic_ops.c'
: File exists

The appropriate line in configure.ac is:

 test -e ${srcdir}/atomic_ops.c \
    	|| ln -s ${srcdir}/libatomic_ops/src/atomic_ops.c \
		 ${srcdir}/atomic_ops.c

which means the link command should only be executed if the link target doesn't
exist yet. I wonder why this doesn't work for you. Is your version of the shell
buggy ? (This may be unrelated to the final error, I'm merely trying to find any
hints in the build.log that could explain why I can't reproduce the problem.)

Thanks !

Comment 9 Stefan Seefeld 2008-04-26 21:17:17 UTC
(Just a little note to let you know that I can reproduce the error when building
via mock. I'll thus be  able to track the problem down on my own, thanks.)

Comment 10 Stefan Seefeld 2008-04-27 00:55:57 UTC
I have updated the srpm at
http://synopsis.fresco.org/download/srpm/synopsis-0.11-1.fc8.src.rpm to
circumvent the compilation error, by using a pre-installed libgc / libgc-devel
package.
Compilation now succeeds with i368 as well as x86_64, and I see the packaging
error I mentioned earlier:

%{_libdir} is set to /usr/lib64, but Synopsis installed its library into /usr/lib. 
Where does rpmbuild get its _libdir value from ? I can't find any way to
establish on what platforms to install in /usr/lib64, and where to install into
/usr/lib.


Comment 11 Neal Becker 2008-04-27 11:44:10 UTC
(In reply to comment #3)
> Thanks for the feedback ! It seems this is an incompatibility with yacc (it
> works fine with bison). I have fixed this problem, and will submit a new 
source
> package soon.
> 
> I'v been trying to package this on a x86_64 box myself, and run into another
> issue. May be you know how to address this:
> 
> In my spec file I list files, using the %{_libdir} variable, as per your 
earlier
> suggestion. This expands to /usr/lib64. However, the buildsystem itself uses
> autoconf, which provides a 'libdir' variable, but which expands to /usr/lib.
> Thus, my library files end up in /usr/lib, and then rpmbuild tries to find 
them
> in /usr/lib64, and obviously fails.
> What can I do about that ? autoconf and rpmbuild seem to disagree about the 
file
> system layout. Is there a way around this ? Is this a known issue ?
> 
> Thanks !

Fedora/redhat have a patched autoconf that handles the multi-arch lib issue.  
Most times, you just need to do:

autoreconf -f -i

and then do configure, build...

Comment 12 Stefan Seefeld 2008-04-28 01:01:05 UTC
Ah, interesting. It isn't the autoconf version that ships with Fedora 8, as that
is what I use for development, or is it ?
Where can I get that version of autoconf ?

Thanks

Comment 13 Neal Becker 2008-04-28 01:16:22 UTC
The autoconf version that ships with F8 has that modification.  Just try 
running autoreconf -f -i as the first build step - I'm pretty sure that fixed 
a bunch of instances of the problem you are describing in my experience.

Comment 14 Stefan Seefeld 2008-04-28 02:00:49 UTC
Well, I ran 'autoconf' (et al.) on a Fedora 8 x86_64 box, and it replaces
@libdir@ by $(exec_prefix)/lib. I even ran 'autoreconf -f -i' just to be sure
(even though that shouldn't make a difference, as that only invokes the same
autoconf again, IIUC), and indeed, the result remains the same.

rpm -qf /usr/bin/autoconf reports 'autoconf-2.61-9.fc8'.


Comment 15 Mamoru TASAKA 2008-04-28 02:53:09 UTC
Created attachment 303932 [details]
Workaround patch for lib64 issue

lib64 issue is not coming from autotool generated files.
I don't know who wrote install_clib.py first, however
the culprit is this file ($ grep -r libSynopsis . gives
us a great hint :) )

A workaround patch is attached. The build result is
http://koji.fedoraproject.org/koji/taskinfo?taskID=585227

Comment 16 Stefan Seefeld 2008-04-28 03:12:55 UTC
Yes, install_clib.py is mine, and yes, it hardcodes 'lib' into the installation
path. However, the version I'm experimenting with delegates installation to the
Makefile (as I expected /hoped that at least there autoconf would generate the
correct $(libdir) variable. It doesn't. (See my previous mail.)

While I understand your patch works for the platforms you tested on, I don't
think this is a solution. There are platforms that support both, 32-bit as well
as 64-bit version to be installed side-by-side. Doing a 32-bit build on that
platform will still find /usr/lib64, and thus wrongly attempt to install the
32-bit libSynopsis.so there.

So once again, where can I find an autoconf version that replaces @libdir@ by
$(exec_prefix)/lib64 on the appropriate platforms ?

(If everything else fails, I have been contemplating a work-around that would
involve passing a --libdir variable down to the install command from within the
synopsis.spec file, so no matter whether autoconf gets it right, I use whatever
rpmbuild wants me to use.)

Thanks

Comment 17 Mamoru TASAKA 2008-04-28 03:50:31 UTC
(In reply to comment #16)
> Yes, install_clib.py is mine, and yes, it hardcodes 'lib' into the installation
> path. 
So anyway this file must be fixed, mustn't it?

> However, the version I'm experimenting with delegates installation to the
> Makefile 
What do you mean by this?

> While I understand your patch works for the platforms you tested on, I don't
> think this is a solution. 
So I said "workaround"

> So once again, where can I find an autoconf version that replaces @libdir@ by
> $(exec_prefix)/lib64 on the appropriate platforms ?
Umm.. it maybe that I don't understand what you say here, however
on usual "configure -> make -> make install" way,  we always
pass "--libdir=%{_libdir}" to configure, so in the sence
@libdir@ is not automatically replaced by %_libdir. Would you
explain what you say here?



Comment 18 Stefan Seefeld 2008-04-28 04:33:00 UTC
Heureka ! :-)

I updated the preview srpm on synopsis.fresco.org/download/srpm. I now pass
--libdir=%{_libdir} to configure, and I changed the install_clib command to run
'make install' in src/ (which thus uses the %{_libdir} variable obtained from
rpmbuild). And indeed, with this change mock building synopsis rpms works for
both i386 as well as x86_64. (Yay !)
I still don't understand where a patched autoconf comes into play, but that may
have become irrelevant with this new version.


Comment 19 Mamoru TASAKA 2008-04-28 14:31:12 UTC
Please at lease change the release number every time you change your
spec/srpm because
- reviewers and some other people watching a review request
  usually saves old srpms and check diffs
- changing srpm withour EVR (epoch-version-release) simply causes
  confusion

And please write the URLs of spec/srpm here from which we can
directly download them by "wget -N", for example.

Comment 20 Stefan Seefeld 2008-04-28 15:24:00 UTC
The current snapshot srpm is
http://synopsis.fresco.org/download/srpm/synopsis-2008-28-04-1.src.rpm.

If all goes well this may turn into the Synopsis 0.11 release. Otherwise I'll
start incrementing $release for subsequent srpm submissions.

Thanks

Comment 21 Mamoru TASAKA 2008-04-29 16:52:57 UTC
For 0.11-1: (please change EVR from next time)

* Redundant BuildRequires
  - gc-devel Requires gc so "BuildRequires: libgc" is redundant

* Requires
  - Please check all required packages are specified by Requires
    (except for library dependencies which are automatically added
     to binary rpms by rpmbuild).

    For example, %{py_sitearch}/Synopsis/Formatters/DocBook/Markup/RST.py
    contains the lines:
-------------------------------------------------------------
    10  from docutils import writers, nodes, languages
    11  from docutils.nodes import *
    12  from docutils.core import *
    13  from docutils.parsers.rst import roles
-------------------------------------------------------------
    This means synopsis should have "Requires: python-docutils".

* Macros
--------------------------------------------------------------
--with-gc-prefix=%{prefix}
--------------------------------------------------------------
  - This must be %{_prefix}

* %doc attribute
  - Files under %_docdir or %_mandir are automatically marked 
    as %doc.

* %defattr
  - We now recommend %defattr(-.root,root,-)

* Directory ownership issue
--------------------------------------------------------------
[tasaka1@localhost ~]$ rpm -qf /usr/share/doc/synopsis-0.11/COPYING 
synopsis-0.11-1.fc9.i386
synopsis-devel-0.11-1.fc9.i386
synopsis-idl-0.11-1.fc9.i386
[tasaka1@localhost ~]$ rpm -qf /usr/share/doc/synopsis-0.11/        
file /usr/share/doc/synopsis-0.11 is not owned by any package
[tasaka1@localhost ~]$ 
--------------------------------------------------------------
   - The directory %_docdir/%name-%version is not owned by any package.

* Other rpmlint issue:
--------------------------------------------------------------
synopsis.i386: W: one-line-command-in-%post /sbin/ldconfig
synopsis.i386: W: one-line-command-in-%postun /sbin/ldconfig
synopsis.i386: W: unstripped-binary-or-object /usr/lib/libSynopsis.so.0.11
--------------------------------------------------------------
  Summary
  - When only calling /sbin/ldconfig is needed for %post(%postun),
    write them in one line and avoid unneeded shell execution as
--------------------------------------------------------------
%post -p /sbin/ldconfig
%posun -p /sbin/ldconfig
--------------------------------------------------------------
   - %_libdir/libSynopsis.so.XXX.YYY is not stripped. 
     /usr/lib/rpm/find-debuginfo.sh checks and strips binaries
     with execution permission only, and on Fedora generally all
     libraries in %_libdir should have 0755 permission.

Comment 22 Stefan Seefeld 2008-04-29 20:17:40 UTC
Thanks for the feedback ! I have adressed most of the above in this new
snapshot:

http://synopsis.fresco.org/download/srpm/synopsis-2008-04-29-1.src.rpm

I was wrongly installing libSynopsis.so.0.11 with INSTALL_DATA, not INSTALL_PROGRAM.

In my local tests (using mock) I still see errors for all the extension modules,
as they end up with 0775 permissions, instead of 0755. Are you not seeing those ? 

Is that a local problem with my mock installation ? umask defaults to 0002,
which results in libs with 0775 permissions. When I set 'umask 0022' I get the
correct permissions in a normal build / install. 
rpmbuild appears to invoke 'umask 0022', too, but those files still appear to be
group-writable, i.e. have 0775 permission. If all looks good on your side I'll
just declare this to be some local corruption, though.

Thanks

PS: If I make an official release in the coming days, will that be able to ship
as part of the upcoming Fedora 9 ?


Comment 23 Mamoru TASAKA 2008-05-02 18:30:33 UTC
Okay, almost clean.

For 0.11-2:
* License issue:
--------------------------------------------------------------
Synopsis/Parsers/Cxx/occ/HashTable.cc	Xerox
Synopsis/Parsers/Cxx/occ/HashTable.hh	Xerox
Synopsis/Parsers/Cxx/occ/MetaClass.cc	Xerox
Synopsis/Parsers/Cxx/occ/MetaClass.hh	Xerox
Synopsis/Parsers/Cxx/occ/QuoteClass.cc	Xerox
Synopsis/Parsers/Cxx/occ/QuoteClass.hh	Xerox
Synopsis/Parsers/IDL/			GPLv2+
Synopsis/Parsers/Python/__init__.py	GPLv2+
src/Synopsis/PTree/generation.cc	Xerox
src/Synopsis/gc/libatomic_ops-1.2/tests/	GPLv2
src/Synopsis/gc/libatomic_ops/test/	GPLv2
--------------------------------------------------------------
  ! The license tag "Xerox" is tagged by spot:
    https://www.redhat.com/archives/fedora-legal-list/2008-April/msg00035.html
  - Well, I don't know why Synopsis/Parsers/Python/__init__.py is
    licensed under GPLv2+. I guess you want to release this as LGPLv2+
    (the license holder seems you).

    Currently, the license tag of synopsis (main) package should be
    "LGPLv2+ and Xerox and GPLv2+". note that Xerox and GPLv2+ 
    are incompatible, however on current situation no legal conflict
    is happening.

   The license tags of other subpackages (except for -idl) can be okay
   with LGPLv2+.

(In reply to comment #22)
> I was wrongly installing libSynopsis.so.0.11 with INSTALL_DATA, 
> not INSTALL_PROGRAM.
Now it seems good

> In my local tests (using mock) I still see errors for all the extension modules,
> as they end up with 0775 permissions, instead of 0755. 
> Are you not seeing those  ? 
Actually no.
 
> rpmbuild appears to invoke 'umask 0022', too, 
Actually.

> but those files still appear to be
> group-writable, i.e. have 0775 permission. 
Ummm....

> PS: If I make an official release in the coming days, will that be able to ship
> as part of the upcoming Fedora 9 ?
No problem :)

Anyway as this is NEEDSPONSOR ticket:

-------------------------------------------------------------
NOTE: Before being sponsored:

This package will be accepted with another few work. 
But before I accept this package, someone (I am a candidate) 
must sponsor you.

Once you are sponsored, you have the right to review other 
submitters' review requests and approve the packages formally. 
For this reason, the person who want to be sponsored (like you) 
are required to "show that you have an understanding 
of the process and of the packaging guidelines" as is described
on :
http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored

Usually there are two ways to show this.
A. submit other review requests with enough quality.
B. Do a "pre-review" of other person's review request
   (at the time you are not sponsored, you cannot do
   a formal review)

When you have submitted a new review request or have pre-reviewed other 
person's review request, please write the bug number on this bug report 
so that I can check your comments or review request.

Fedora package collection review requests which are waiting for someone to
review can be checked on:
http://fedoraproject.org/PackageReviewStatus/NEW.html
(NOTE: please don't choose "Merge Review")


Review guidelines are described mainly on:
http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
http://fedoraproject.org/wiki/Packaging/Guidelines
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets
------------------------------------------------------------



Comment 24 Stefan Seefeld 2008-05-02 18:43:15 UTC
OK, thanks for the feedback again. I'm glad to see I'm making progress. :-)
Just a little note on the license issue:

The XEROX files aren't actually used my my code (I originally forked OpenC++,
but have been moving away as I continue development), so I believe I can just
strip them off the repository entirely.

The IDL parser is indeed licensed under GPL, which is the reason why I split
this into a separate binary package (synopsis-idl), so it can be distributed
under GPL without any impact on the rest being released as LGPL.

the libatomic code is an import, too, and for the fedora binary packages not
used (I link to an external libgc). Do you think this conflict between LGPLv2
and LGPLv2+ is a problem ? Should I release as LGPLv2, too ?

Thanks,

Comment 25 Mamoru TASAKA 2008-05-02 19:12:28 UTC
(Umm... currently I don't receive any mails.. Perhaps the mail server
 of my university is down...??)

(In reply to comment #24)
> The XEROX files aren't actually used my my code 
Umm? Currently they are used as:
-------------------------------------------------------------
  1201  ar rcs opencxx.a  occ/HashTable.o  occ/Environment.o  occ/TypeInfo.o   
occ/TypeInfoVisitor.o  occ/Walker.o  occ/Class.o  occ/ClassWalker.o 
occ/MetaClass.o  occ/QuoteClass.o  occ/Member.o  occ/ClassBodyWalker.o
  1202  g++ -shared  -o ParserImpl.so syn/swalker.o syn/ast.o syn/builder.o
syn/type.o syn/dict.o syn/TypeIdFormatter.o syn/decoder.o syn/lookup.o
syn/filter.o syn/Translator.o syn/SXRGenerator.o syn/ParserImpl.o opencxx.a
-L/builddir/build/BUILD/synopsis-0.11/build/ctemp.linux-i686/src/lib -lSupport
-lSynopsis   
--------------------------------------------------------------

> The IDL parser is indeed licensed under GPL, which is the reason why I split
> this into a separate binary package (synopsis-idl), so it can be distributed
> under GPL without any impact on the rest being released as LGPL.
No problem.

> the libatomic code is an import, too, and for the fedora binary packages not
> used (I link to an external libgc).
Okay.

Well, then is this part okay?
    Well, I don't know why Synopsis/Parsers/Python/__init__.py is
    licensed under GPLv2+. I guess you want to release this as LGPLv2+
    (the license holder seems you).

Comment 26 Stefan Seefeld 2008-05-02 19:21:56 UTC
Indeed, the XEROX files are all linked in, but the code is never executed.
The Python/__init__.py header looks like a typo. I meant to license all my own
work under LGPLv2+. I'll submit an appropriate fix. Thanks !

Comment 27 Mamoru TASAKA 2008-05-12 15:45:28 UTC
ping?

Comment 28 Stefan Seefeld 2008-05-12 15:48:52 UTC
Sorry for the silence. I have made all planned changes and am doing some testing
now. I expect to upload a new snapshot later today.

Thanks

Comment 29 Stefan Seefeld 2008-05-13 04:39:15 UTC
Here is a new snapshot. The most important changes are code cleanup to remove
old XEROX code, and fix the Python parser license header:

http://synopsis.fresco.org/download/srpm/synopsis-2008-05-13-1.src.rpm

Comment 30 Mamoru TASAKA 2008-05-14 16:49:50 UTC
Seems good. So I will wait for your another review request
or a pre-review of other packages as this is a NEEDSPONSOR ticket
(please check my comment 23)

Comment 31 Mamoru TASAKA 2008-05-26 15:07:54 UTC
ping?

Comment 32 Stefan Seefeld 2008-05-26 15:54:54 UTC
Sorry for the delay. I have some trouble with my host (and the repository in
particular), and so didn't manage to check in the last set of changes.
This should be resolved shortly.

Comment 33 Mamoru TASAKA 2008-06-12 06:01:22 UTC
ping again?

Comment 34 Stefan Seefeld 2008-06-19 17:22:14 UTC
Sorry for being late again. I'm presently being stuck, waiting for my sys admin
to resolve an issue on the machine hosting the Synopsis project.

Comment 35 Mamoru TASAKA 2008-07-09 06:07:50 UTC
ping again?

Comment 36 Mamoru TASAKA 2008-07-16 17:09:33 UTC
ping again?

Comment 37 Mamoru TASAKA 2008-07-24 17:06:09 UTC
Again ping?

Comment 38 Mamoru TASAKA 2008-08-06 13:56:56 UTC
I will close this bug as NOTABUG if no response is received from the reporter
within ONE WEEK.

Comment 39 Stefan Seefeld 2008-08-07 22:19:00 UTC
Pong (sorry for the latency, now back from vacation).

Unfortunately, I'm still struggling with issues with my host. I have some outstanding patches that I want to check in prior to doing the 0.11 release.

Please do whatever you feel is most appropriate. I'm definitely interested into getting a new Synopsis release out and getting a fedora package accepted.

Thanks for your patience.

                   Stefan

Comment 40 Mamoru TASAKA 2008-08-08 15:27:19 UTC
Don't you have any site where you can put the tarball and the srpm you are
using now?

Comment 41 Stefan Seefeld 2008-08-08 15:36:54 UTC
Sure, but that's not an official release. I'd like to base the rpm packages on the 0.11 release that I haven't been able to get out yet. (I guess I only need to commit my local changes and run some final tests once they are in, the usual release procedure...)

Comment 42 Mamoru TASAKA 2008-08-08 16:05:39 UTC
By the way, to make it sure, 
what I am waiting for you first is that you submit another review request or
you do  a pre-review of other person's review request as I wrote as
comment 23. This is not related to your site problem.

Comment 43 Mamoru TASAKA 2008-08-25 16:03:39 UTC
ping again?

Comment 44 Mamoru TASAKA 2008-09-01 06:33:52 UTC
ping again?
At least would you do at least one pre-review of other person's review request,
which is needed for sponsoring process?

Comment 45 Stefan Seefeld 2008-09-05 19:20:13 UTC
OK, I'll try to do a pre-review sometime soon. What do I need to do for that ? Just reply to a review request as if I would do a review ? Or is there some checkbox (say) to indicate this is a pre-review ?

Thanks,
 Stefan

Comment 46 Mamoru TASAKA 2008-09-06 14:17:34 UTC
(In reply to comment #45)
> OK, I'll try to do a pre-review sometime soon. What do I need to do for that ?
> Just reply to a review request as if I would do a review ? Or is there some
> checkbox (say) to indicate this is a pre-review ?

Write your pre-review comment on the bug you pre-reviewed with noticing (adding a comment)
that it is a pre-review, what write on this bug the bug number you pre-reviewed.

Comment 47 Mamoru TASAKA 2008-09-17 15:19:03 UTC
ping again?

Comment 48 Mamoru TASAKA 2008-09-24 16:52:07 UTC
ping again?

Comment 49 Mamoru TASAKA 2008-10-03 06:00:28 UTC
ping again?

Comment 50 Mamoru TASAKA 2008-10-12 07:06:52 UTC
I will close this bug again if no response is received from the
reporter within ONE WEEk.

Comment 51 Stefan Seefeld 2008-10-19 14:59:00 UTC
Sorry for my silence. In addition to general business, I have been debating whether or not to submit another package of mine for inclusion into Fedora (which, as I understand, is one way to become sponsored).
I'm going to submit a qmtest package (http://www.codesourcery.com/qmtest) within the coming days. Are you the one to review that, then ?

Thanks,
          Stefan

Comment 52 Mamoru TASAKA 2008-10-19 16:15:59 UTC
Okay. Then I will wait for your another review request.

(By the way would you also update this package, too?)

Comment 53 Stefan Seefeld 2008-10-19 16:33:32 UTC
Yes, I'm going to release Synopsis 0.11 in a couple of days, and can submit a new package based on that.

Comment 54 Stefan Seefeld 2008-10-22 10:39:12 UTC
I just submitted QMTest (https://bugzilla.redhat.com/show_bug.cgi?id=468003).
I will release Synopsis 0.11 within the next week, and submit an updated source package here at the same time.

Thanks,
          Stefan

Comment 55 Mamoru TASAKA 2008-11-19 06:33:00 UTC
Would you update this srpm again?

Comment 56 Mamoru TASAKA 2008-12-12 13:18:42 UTC
Would you update the status of this bug?

Comment 57 Stefan Seefeld 2008-12-23 19:13:21 UTC
Please find a new srpm here:
http://stefan.fedorapeople.org/synopsis-0.11-3.fc9.src.rpm
and the associated spec file:
http://stefan.fedorapeople.org/synopsis.spec

Thanks,
             Stefan

Comment 58 Mamoru TASAKA 2008-12-26 07:49:13 UTC
Almost godd, however the newest rpms shows one rpmlint:
synopsis.i386: W: shared-lib-calls-exit /usr/lib/libSynopsis.so.0.11 exit

Usually a shared library should not call exit() in the library
($ rpmlint -I shared-lib-calls-exit for details). Would you check this?

Comment 59 Stefan Seefeld 2008-12-26 14:43:20 UTC
I'm not sure why this only shows up now, but you are certainly right. I removed some long obsolete code and those exit() calls are now gone.
Please find the latest spec / srpm at:

http://stefan.fedorapeople.org/synopsis-0.11-4.fc9.src.rpm
http://stefan.fedorapeople.org/synopsis.spec


Thanks,

Comment 60 Mamoru TASAKA 2008-12-26 15:43:57 UTC
Okay.

------------------------------------------------------
    This package (synopsis) is APPROVED by mtasaka
------------------------------------------------------

Please release new version when ready.

Comment 61 Stefan Seefeld 2008-12-26 16:06:35 UTC
New Package CVS Request
=======================
Package Name: synopsis
Short Description: source-code introspection tool
Owners: stefan
Branches: F-9 F-10
InitialCC:

Comment 62 Kevin Fenzi 2008-12-28 19:20:41 UTC
cvs done.

Comment 63 Mamoru TASAKA 2009-01-01 09:35:46 UTC
Thanks. When you think the requested packages can be moved from
testing to stable, please revisit the bodhi interface and edit
your requests.

Closing as NEXTRELEASE.