Bug 438543
Summary: | Review Request: Synopsis - Source-code introspection tool. | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Stefan Seefeld <stefan> | ||||
Component: | Package Review | Assignee: | Mamoru TASAKA <mtasaka> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | rawhide | CC: | 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
Stefan Seefeld
2008-03-21 17:19:32 UTC
*** Bug 220393 has been marked as a duplicate of this bug. *** 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 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 ! 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)? 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. 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 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 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 ! (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.) 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. (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... 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 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. 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'. 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 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 (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? 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. 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. 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 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. 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 ? 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 ------------------------------------------------------------ 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, (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). 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 ! ping? 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 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 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) ping? 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. ping again? 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. ping again? ping again? Again ping? I will close this bug as NOTABUG if no response is received from the reporter within ONE WEEK. 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 Don't you have any site where you can put the tarball and the srpm you are using now? 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...) 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. ping again? ping again? At least would you do at least one pre-review of other person's review request, which is needed for sponsoring process? 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 (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. ping again? ping again? ping again? I will close this bug again if no response is received from the reporter within ONE WEEk. 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 Okay. Then I will wait for your another review request. (By the way would you also update this package, too?) Yes, I'm going to release Synopsis 0.11 in a couple of days, and can submit a new package based on that. 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 Would you update this srpm again? Would you update the status of this bug? 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 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? 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, Okay. ------------------------------------------------------ This package (synopsis) is APPROVED by mtasaka ------------------------------------------------------ Please release new version when ready. New Package CVS Request ======================= Package Name: synopsis Short Description: source-code introspection tool Owners: stefan Branches: F-9 F-10 InitialCC: cvs done. 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. |