Spec URL: http://peter.fedorapeople.org/asn1c.spec SRPM URL: http://peter.fedorapeople.org/asn1c-0.9.21-1.fc9.src.rpm Description: Free, open source compiler of ASN.1 specifications into C source code. It supports a range of ASN.1 syntaxes, including ISO/IEC/ITU ASN.1 1988, '94, '97, 2002 and later amendments. The supported sets of encoding rules are * BER: ITU-T Rec. X.690 | ISO/IEC 8825-1 (2002) (BER/DER/CER) * PER: X.691|8825-2 (2002) (PER). * XER: X.693|8825-3 (2001) (BASIC-XER/CXER). The compiler was written specifically to address security concerns while providing streaming decoding capabilities.
It would be nice if you at least commented on the large number of rpmlint complaints this package generates (107 warnings).
(In reply to comment #1) > It would be nice if you at least commented on the large number of rpmlint > complaints this package generates (107 warnings). These files contains necessary definitions for asn1c compiler. They shouldn't used by anyone else than asn1c itself, so they cannot be placed in %{_includedir}.
Ver. 0.9.21-2 %changelog * Wed Sep 3 2008 Peter Lemenkov <lemenkov> 0.9.21-2 - Cosmetic changes http://peter.fedorapeople.org/asn1c.spec http://peter.fedorapeople.org/asn1c-0.9.21-2.fc9.src.rpm Samples still cannot be built - I'll try to fix it.
I believe you have commented on the devel-file-in-non-devel-package complaints; how about the two file-not-utf8 issues which remain in the -2 package? asn1c.x86_64: W: file-not-utf8 /usr/share/doc/asn1c-0.9.21/samples/sample.source.LDAP3/sample-LDAPMessage-1.ber asn1c.x86_64: W: file-not-utf8 /usr/share/doc/asn1c-0.9.21/samples/sample.source.RRC/rrc.asn1 It would be really nice for the reviewers if you could run rpmlint and at least comment on the complaints, as we end up having to ask for those comments anyway.
It's been six months with no progress; I will close this ticket soon if there is no response.
> It's been six months with no progress The spec-file is almost finished, and the only missing part of job is my comments regarding the last two warnings, listed above. > asn1c.x86_64: W: file-not-utf8 > /usr/share/doc/asn1c-0.9.21/samples/sample.source.LDAP3/sample-LDAPMessage-1.ber This is a false positive message from rpmlint, since this is a binary file. > asn1c.x86_64: W: file-not-utf8 > /usr/share/doc/asn1c-0.9.21/samples/sample.source.RRC/rrc.asn1 Unfortunately, we cannot redistribute asn1-description of Radio Resource Control tech specs, so I removed it. http://peter.fedorapeople.org/asn1c.spec http://peter.fedorapeople.org/asn1c-0.9.21-3.fc10.src.rpm
Just going back over some of these older tickets. I wonder it is permissible for us to distribute the sources of those sample files that you have to explicitly not include in the package due to licensing restrictions. In other words, don't they need to be removed from the source tarball completely? http://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code Otherwise, we still ship them in the source package.
(In reply to comment #7) > Just going back over some of these older tickets. I wonder it is permissible > for us to distribute the sources of those sample files that you have to > explicitly not include in the package due to licensing restrictions. Actually, these messages are just a leftover from my experiments (I tried to download these files and plan to add them to the tarball before realizing that this is illegal). Yes, we able to distribute srpm, since it doesn't contain non-redistributive stuff. Ok, returning to this ticket: http://peter.fedorapeople.org/asn1c.spec http://peter.fedorapeople.org/asn1c-0.9.21-4.fc11.src.rpm I just removed confusing messages about asn1-files, which are not present in tarball and cannot be redistributed.
A wannabee-packager-review: rpmlint output: asn1c.i686: W: file-not-utf8 /usr/share/doc/asn1c-0.9.21/samples/sample.source.LDAP3/sample-LDAPMessage-1.ber (misunderstood binary file) asn1c.i686: W: devel-file-in-non-devel-package /usr/share/asn1c/... 103 times (NOT include files but input to asn1.c for generating c code) Package and spec name fine. This is a fine and simple spec, legible and in American English AFAICS. I think it is a bit odd to mangle source files in %install so a folder can be specified as %doc in %files. Perhaps it could be moved to %build ... or ask upstream to change it. License "BSD" is OK; COPYING and most source contains a slightly truncated "FreeBSD BSD Variant (2 clause BSD)" and some even more free snippets and rfc texts. Upstream seems to be aware of potential licensing issues with the samples - they are carefully avoided. Source URL is fine. There are no build requirements, and it mock builds and installs on rawhide/f12. The sample source/makefiles in docs fails, partly because they are meant to be run from the source tree, partly because of the packaging and moving things around. And there is a bug in asn1c-quick.pdf: TestModule.asn1 doesn't work - it should probably be SEQUENCE instead of SET. But finally I managed to run asn1c and it seemed to work and generate something which seemed OK. But I don't have any real-world use case. There are no locales and no libraries and thus also no system libraries. Not relocatable, and creates and owns files/directories in usual locations and they are only listed once and with proper permissions. %files is however very explicit and verbose about %{_datadir}/%{name}. %clean is fine, and macros are used consistently. The package contains fine permissible code with supporting files. The fine documentation - and especially the samples - takes up several times more space than the rest. But this is a development package, so I think it is fine to keep it all in one package. No header files (except the data), no static libs, no pkgconfig, no libraries and especially no libtool archives, and no GUI. %install is fine and installs files with pure ascii names. Conclusion: Try to get the samples working - or at least make sure that they not are broken by the packaging. Consider simplifying %{_datadir}/%{name} in %files
(In reply to comment #6) > > asn1c.x86_64: W: file-not-utf8 > > /usr/share/doc/asn1c-0.9.21/samples/sample.source.RRC/rrc.asn1 > > Unfortunately, we cannot redistribute asn1-description of Radio Resource > Control tech specs, so I removed it. I believe, I read, that, when you are not allowd to redistribute it, you are not allowed to put it in the source tar.gz for uploading and not just deleting in %install or %build. Furthermore, if just deleting %check make check fails. (You should add this into the spec file, too.)
(In reply to comment #10) > I believe, I read, that, when you are not allowd to redistribute it, you are > not allowed to put it in the source tar.gz for uploading and not just deleting > in %install or %build. rrc.asn1 isn't in upstreams tar.gz and apparently never was. (But it was in upstream svn trunk and Peter had included it as an extra source in early specs. He never deleted it in %install or %build; he just stopped adding it.) samples/sample.source.RRC/README is pretty clear. > Furthermore, if just deleting > > %check > make check > > fails. > > (You should add this into the spec file, too.) Are you saying that %check section is mandatory? That is new to me. AFAICS most specs don't have a %check section. Can you give a reference?
(In reply to comment #11) > (In reply to comment #10) > > I believe, I read, that, when you are not allowd to redistribute it, you are > > not allowed to put it in the source tar.gz for uploading and not just deleting > > in %install or %build. > > rrc.asn1 isn't in upstreams tar.gz and apparently never was. (But it was in > upstream svn trunk and Peter had included it as an extra source in early specs. > He never deleted it in %install or %build; he just stopped adding it.) > How do you call: %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT rm -rf $RPM_BUILD_ROOT%{_docdir}/%{name}/* rm -f samples/Makefile{,.am,.in} rm -f samples/clyx2asn1.pl rm -f samples/crfc2asn1.pl rm -f samples/sample.makefile.regen He removes some files, this breaks %check :( > samples/sample.source.RRC/README is pretty clear. > > > Furthermore, if just deleting > > > > %check > > make check > > > > fails. > > > > (You should add this into the spec file, too.) > > Are you saying that %check section is mandatory? That is new to me. AFAICS most > specs don't have a %check section. Can you give a reference? It's not mandatory, but a 'should'. Didn't found it in the main guidelines, but at least in https://fedoraproject.org/wiki/Packaging:R#Running_.25check It'll be better to run the testsuite anyway, to see, if there are regressions. Many specs have a %check section. e.g. https://bugzilla.redhat.com/show_bug.cgi?id=529466#c8 (In reply to comment #9) > Conclusion: > Try to get the samples working - or at least make sure that they not are broken > by the packaging. > Consider simplifying %{_datadir}/%{name} in %files 'Make sure, that they are not broken' is for me the same like running a test suite.
PING It's been almost ten months with no progress; This bug should be closed soon if there is no response, shouldn't it?
Due to the lack of response this review is now considered as stalled. I'm closing this bug just as described in Fedora's Policy for stalled package reviews http://fedoraproject.org/wiki/Policy_for_stalled_package_reviews