Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 188168
Summary: | Review Request: gauche - Scheme script interpreter with multibyte character handling | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Gérard Milmeister <gemi> | ||||
Component: | Package Review | Assignee: | Jason Tibbitts <j> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | ||||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2006-04-29 17:44:41 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: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 163779, 188176, 188178 | ||||||
Attachments: |
|
Description
Gérard Milmeister
2006-04-06 16:57:19 UTC
Package fails to build in mock (development, both i386 and x86_64): RPM build errors: File not found by glob: /var/tmp/gauche-0.8.7-1-root-mockbuild/usr/share/info/* I added a BR: for texinfo and all is well. rpmlint complains: W: gauche file-not-utf8 /usr/share/info/gauche-refe.info-3.gz Normally we fix these up with a call to iconv, but I'm not sure how to handle this problem in a multilingual texinfo file (Japanese and English are included in the same source file; these are postprocessed to produce the proper texi output.) Looking deeper, I see that in this particular file some Japanese has leaked into the English text; I think the cause is on line 8051 of modgauche.texi; the "@c COMMON" should be "@c JP", and the following "@c JP" should be "@c COMMON". E: gauche-debuginfo non-readable /usr/src/debug/Gauche-0.8.7/ext/sxml/sxml-sxpath.c 0600 (and many similar lines) The build process is creating these intermediate files: /tmp/Gauche-0.8.7> find . -name sxml-sxpath.c -ls 197853 708 -rw------- 1 tibbs users 719935 Apr 26 22:39 ./ext/sxml/sxml-sxpath.c which should probably be mode 644. I see some makefiles setting umask, but it's happening in a subshell so it shouldn't be leaking out. I don't understand why they're making it into the debuginfo package, but if the permissions were correct rpmlint would at least be quiet. E: gauche-devel only-non-binary-in-usr-lib Technically since there's nothing system-dependent in there, it could live in /usr/share. Not knowing Gauche, I don't know what these files are used for; gcc for example stores plenty of development files in /usr/lib that are used by the compiler (and has no -devel package as well). I don't think this is a blocker. W: gauche-devel doc-file-dependency /usr/share/doc/gauche-devel-0.8.7/template.DIST /bin/sh This file should not be executable. (In reply to comment #2) > I added a BR: for texinfo and all is well. Ok. > rpmlint complains: > > W: gauche file-not-utf8 /usr/share/info/gauche-refe.info-3.gz > > E: gauche-debuginfo non-readable > /usr/src/debug/Gauche-0.8.7/ext/sxml/sxml-sxpath.c 0600 > (and many similar lines) I created a patch for this. I will try to push this upstream. > The build process is creating these intermediate files: > > /tmp/Gauche-0.8.7> find . -name sxml-sxpath.c -ls > 197853 708 -rw------- 1 tibbs users 719935 Apr 26 22:39 > ./ext/sxml/sxml-sxpath.c Ok, I changed all *.c files to 0644 > E: gauche-devel only-non-binary-in-usr-lib I am somewhat annoyed that rpmlint reports this as an error, not as a warning. Of course the include files should be in /usr/include/gauche/%{version} or something similar, however "gauche-config" reports the /usr/lib directory, and I don't think it is wise to make major restructuring. However, I will suggest this upstream. > W: gauche-devel doc-file-dependency > /usr/share/doc/gauche-devel-0.8.7/template.DIST /bin/sh > This file should not be executable. Ok. Update at: http://math.ifi.unizh.ch/fedora/5/i386/SRPMS.gemi/gauche-0.8.7-2.fc5.src.rpm Something seems to have busted; now I can't build any of the packages you've submitted on the development branch. Things start to go off here: os_dep.c:20:30: error: linux/version.h: No such file or directory In file included from /usr/include/asm/signal.h:5, from os_dep.c:27: /usr/include/asm-x86_64/signal.h:6:27: error: linux/linkage.h: No such file or directory In file included from /usr/include/asm-x86_64/signal.h:7, from /usr/include/asm/signal.h:5, from os_dep.c:27: /usr/include/linux/time.h:9: error: redefinition of 'struct timespec' /usr/include/linux/time.h:15: error: redefinition of 'struct timeval' /usr/include/linux/time.h:42: error: redefinition of 'struct itimerspec' In file included from /usr/include/asm/signal.h:5, from os_dep.c:27: /usr/include/asm-x86_64/signal.h:15: error: conflicting types for 'sigset_t' /usr/include/signal.h:50: error: previous declaration of 'sigset_t' was here In file included from /usr/include/asm/signal.h:5, from os_dep.c:27: /usr/include/asm-x86_64/signal.h:102: error: redefinition of 'struct sigaction' /usr/include/asm-x86_64/signal.h:103: error: expected ':', ',', ';', '}' or '__attribute__' before '.' token /usr/include/asm-x86_64/signal.h:113: error: redefinition of 'struct sigaltstack' I'll attach a build log, but fortunately things still build on the FC5 release branch, and that's all that's required, so I'll proceed with the review on that basis. I think something must have busted since I last pulled from rawhide a couple of days ago. The first file it can't find, /usr/include/linux/version.h, is in FC5 part of glibc-kernheaders but it's not there in current rawhide. Issues: You should package the COPYING file as %doc. I'm inclined to ignore the remaining rpmlint complaint. In reality fixing gauche-config should be a simple matter of patching src/genconfig.in, but I have no way of knowing what that might break. And anyway, compilers tend to be something of a special case (c.f. gcc). There's a test suite that you don't call; I added %check cd src; LD_LIBRARY_PATH=$RPM_BUILD_ROOT%{_libdir} make test and it runs and, most importantly, passes. Review: * package meets naming and packaging guidelines. * specfile is properly named, is cleanly written and uses macros consistently. * license field matches the actual license. X license is open source-compatible and is included upstream but is not included in the package. * source files match upstream: 5c7cb6eba7455c9877aec884b0088a25 Gauche-0.8.7.tgz 5c7cb6eba7455c9877aec884b0088a25 Gauche-0.8.7.tgz-srpm * BuildRequires are proper. * package builds in mock (fc5, i386 and x86_64). O rpmlint is silent. * final provides and requires are sane. * shared libraries are present; ldconfig is called as necessary. * package is not relocatable. * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * %clean is present. X %check is not present, but upstream includes one that can easily be run. * code, not content. * documentation is small, so no -docs subpackage is necessary. * %docs are not necessary for the proper functioning of the package. * headers present and in a -devel package. * no pkgconfig files. * no libtool .la droppings. * not a GUI app. Created attachment 128340 [details]
Logg for failing build in rawhide
The build failure seems to be fixed with last night's glibc-kernheaders package update. I added the %check and the COPYING file: http://math.ifi.unizh.ch/fedora/5/i386/SRPMS.gemi/gauche-0.8.7-3.fc5.src.rpm Looks great and builds fine. APPROVED Built successfully on FC-4, FC-5 and FC-6. However, I had to remove _smp_flags. Thanks for the review. |