Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
Summary: Review Request: librep - An embeddable LISP environment Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: Package Review AssignedTo: nobody@fedoraproject.org ReportedBy: rkhadgar@redhat.com QAContact: extras-qa@fedoraproject.org CC: fedora-package-review@redhat.com,notting@redhat.com
Spec URL: http://people.redhat.com/rkhadgar/personal/fedora/librep.spec SRPM URL: http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17-2.svn20071102.... Description: This is a lightweight Lisp environment for UNIX. It contains a Lisp interpreter, byte-code compiler and virtual machine. Applications may use the Lisp interpreter as an extension language, or it may be used for standalone scripts.
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
rkhadgar@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |431249 nThis| |
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
------- Additional Comments From tibbs@math.uh.edu 2008-02-02 10:24 EST ------- This fails to build for me:
/bin/sh ../libtool --mode=link gcc -o repdoc repdoc.o -lgdbm /bin/sh: ../libtool: No such file or directory make[1]: *** [repdoc] Error 127 make[1]: Leaving directory `/builddir/build/BUILD/librep-0.17/src' make: *** [src/repdoc] Error 2
Adding BuildRequires: libtool gets things to progress further, until:
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/librep-0.17-2.svn20071102.fc9-root-mockbuild error: Installed (but unpackaged) file(s) found: /usr/share/info/dir
You need to explicitly delete this file, which is generated as part of the texinfo compilation but should never be part of any package. At the end of %install: rm -f $RPM_BUILD_ROOT/%{_infodir}/dir
Things build after that. rpmlint then says: librep.x86_64: W: incoherent-version-in-changelog 0.17-2 0.17-2.svn20071102.fc9 Your changelog entries should match the version.
librep-devel.x86_64: W: no-documentation This is OK, but you should consider whether any of the documentation you package is more appropriate for the -devel package.
I notice a bunch of .la files packaged. Generally these should not be packaged; do you have some specific reason for doing so?
Are the .jl and .jlc files arch-neutral? Otherwise they will conflict when both i386 and x86_64 packages are installed together.
There'a a bunch of stuff installed into /usr/libexec/rep that seems better suited to %{_libdir}/rep instead. Generally I'd expect to see only executables in /usr/libexec. (See what gcc does, for example.) I do not know if this opinion is widely held, however.
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
------- Additional Comments From michal@harddata.com 2008-02-02 20:41 EST ------- Created an attachment (id=293814) --> (https://bugzilla.redhat.com/attachment.cgi?id=293814&action=view) modified librep spec file
Some further remarks about this package:
.svn .cvsignore are superflous in a tar file. Every file and directory in a tar file has the same timestamp (possibly an svn deficiency). /sbin/install-info is 'Prereq:' to install documentation gmp should be in 'Requires:'
In %files section it should be just
%{_datadir}/rep %{_libexecdir}/rep %{_datadir}/emacs/site-lisp/*
or you will get "leftovers" after deinstalling the package
%{_datadir}/emacs/site-lisp/* %{_infodir}/*.info*
possibly in 'devel'
Options for %configure are taken from old librep specs. I cannot tell how necessary they are now but they definitely work. Missing '--with-readline' is not good.
Modified spec file is attached.
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
------- Additional Comments From tibbs@math.uh.edu 2008-02-02 21:33 EST ------- Please note that use of Prereq: is not allowed and is a blocker. Requires(pre): is probably what is intended, although it seems that other dependencies are a bit off in the specfile from comment #2 (Requires(post): /sbin/ldconfig, /sbin/install-info is missing, for example.)
For things like this you should just consult http://fedoraproject.org/wiki/Packaging/ScriptletSnippets and use the scriptlets and dependencies provided there.
Also, I noticed that the name of the package violates the naming guidelines. "svnYYYYMMDD" is incorrect; the date goes first, followed by whatever you like (probably "svn" in this case).
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
------- Additional Comments From rkhadgar@redhat.com 2008-02-03 10:35 EST ------- Updates posted based on feedback from Jason and Michal
http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17-3.20071102svn....
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
------- Additional Comments From michal@harddata.com 2008-02-03 17:08 EST ------- Thanks for corrections in comment #3. I just looked at some "historical" packages and not on wiki. :-)
BTW, after
find . -name .svn | xargs rm -rf find . -name .cvsignore | xargs rm rm -rf autom4te.cache
in librep-0.17 directory a size of the original source archive drops down by roughly 2/3rd without, of course, affecting a compilation in any way and size differences in a resulting src.rpm are of a similar order.
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
------- Additional Comments From rkhadgar@redhat.com 2008-02-27 09:42 EST ------- Kool. Thanks, updated
http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17-4.20071102svn....
Hitting one issue though. How do i build "librep-common" for noarch ? Using "BuildArch: noarch" with librep-common yields lots of error :(
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
------- Additional Comments From michal@harddata.com 2008-02-27 18:34 EST -------
How do i build "librep-common" for noarch ?
You are putting in "librep-common" a lot of byte-compiled .jlc files. Are you really sure that they are the same for all possible architectures?
In any case it does not seem possible to specify "BuildArch" for a subpackage _on the same build_. The same source with two different spec files and building twice could do it.
If I am mistaken somebody will tell me, I presume. :-) You would need "BuildArch: %{_arch}" for other subpackages - would be my guess (but that seems to override BuildArch settings for "common").
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
------- Additional Comments From rkhadgar@redhat.com 2008-02-28 04:29 EST -------
You are putting in "librep-common" a lot of byte-compiled .jlc files. Are you really sure that they are the same for all possible architectures?
" As for .jlc's, I've been shipping them in an arch-neutral package in Debian for over a year now, and nothing has broken since, so I guess they are ;) "
http://mail.gnome.org/archives/sawfish-list/2008-February/msg00013.html
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
------- Additional Comments From michal@harddata.com 2008-02-28 11:17 EST -------
"... and nothing has broken since ..."
That is a good hint but a pretty weak argument, appearences to the contrary. If those files were used mostly for i386 and x86_64 then there are many similarities here, including endianess. Checking in sources that a byte compiler is indeed arch-independent would be a different matter.
I looked through installed "noarch" packages on one system and peeked at such few which could be a subpackage; like 'gimp-help', for example. They all appear to build separately; so this seems to support what I said in comment #7. OTOH is there really any good reason for somebody to try to install sawfish.i386 and sawfish.x86_64 at the same time which would require two variants of librep and would cause conflicts on files from "common"? I do not see any but possibly I miss something.
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
akahl@iconmobile.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |431251 nThis| |
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
------- Additional Comments From rkhadgar@redhat.com 2008-04-10 02:21 EST ------- the jlc file are the same, atleast across i386,ia64, and ppc64.
update spec file to include libtool in build dependency.
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
------- Additional Comments From rkhadgar@redhat.com 2008-04-17 01:51 EST ------- based on my understanding, i dont see any reason for a person to install both i386 and x86_64 version, in my box. will merge back librep-common into librep.
librep is a scripted language, and relevant bindings to run all know application (to me) can be installed natively on x86_64.
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
------- Additional Comments From rkhadgar@redhat.com 2008-05-19 05:09 EST ------- downgraded the spec & srpm file
http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17-3.20071102svn....
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tibbs@math.uh.edu OtherBugsDependingO| |177841 nThis| |
------- Additional Comments From tibbs@math.uh.edu 2008-06-18 20:24 EST ------- Doesn't look like Ritesh is in cvsextras yet.
This package builds fine and rpmlint only complains about the lack of docs in librep-devel.
/usr/share/aclocal seems to be unowned. I think the -devel package needs a dependency on automake.
If you're going to package a subversion checkout, please see http://fedoraproject.org/wiki/Packaging/SourceURL for info on including instructions for duplicating the checkout. I need to be able to check out my own copy of the upstream source by following information in the specfile.
Honestly I'd say this package is pretty close now, but I haven't done a complete review.
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
------- Additional Comments From rkhadgar@redhat.com 2008-07-02 11:52 EST ------- this is a svn pull of the stack, updated
http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17-3.20071102svn....
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: librep - An embeddable LISP environment
https://bugzilla.redhat.com/show_bug.cgi?id=431250
pertusus@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pertusus@free.fr
------- Additional Comments From pertusus@free.fr 2008-07-12 05:56 EST ------- The checkout instructions should include a date or a -r switch such that the same tarble is constructed even if there has been some later changes in the svn.
The release is not right, it should be Release: 0.3.%{snapshot}%{?dist}
You should not use gzip on the info files, it is done automatically.
A dot is missing at the end of the -devel %description.
The --with-malloc-alignment=8 for specific arches is very scary and doesn't scale well. Isn't it possible to achieve portability?
I suggest not having -f for the 2 first rm, such that you notice when the files are not installed anymore. It should stay for $RPM_BUILD_ROOT%{_infodir}/dir since it may or may not be created depending on the situation. This would lead to
rm $RPM_BUILD_ROOT%{_libdir}/*.la rm $RPM_BUILD_ROOT%{_libdir}/rep/%{version}/%{_host}/*.la rm -f $RPM_BUILD_ROOT%{_infodir}/dir
There is a missing Requires(post): /sbin/ldconfig
Also a missing Requires: automake for the devel package, or, alternatively owning %{_datadir}/aclocal/.
A suggestion, I think it is nice to have a trailing / for directories in %files to see that they are directories. It is just a personal preference, though. This would lead to
%{_datadir}/rep/
and
%{_libdir}/rep/
Since there are emacs files, you should certainly follow http://fedoraproject.org/wiki/Packaging/Emacs and also shouldn't the file also be byte-compiled?
There are these rpmbuild warnings: warning: File listed twice: /usr/lib/librep.so.9 warning: File listed twice: /usr/lib/librep.so.9.4.0
There are still some .la files in -devel, like /usr/lib/rep/0.17/i686-pc-linux-gnu/rep/data/tables.la
Aren't the files in /usr/lib/rep/0.17/i686-pc-linux-gnu/ needed for rep at runtime?
It seems to me that %{_libdir}/rep/ is unowned.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #16 from ritz rkhadgar@redhat.com 2008-08-13 12:48:45 EDT --- updated
http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17.1-rc1.src.rpm
is the emacs subpackage really required ? where do i find examples for these, i looked up subversion, libidn from what i could see on my system.
and how do i remove the message below librep.x86_64: W: unstripped-binary-or-object <some-libs> librep.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/rep ['/usr/lib64']
-- ritz
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #17 from Patrice Dumas pertusus@free.fr 2008-09-03 07:25:57 EDT --- There is an example of emacs subpackages in gnuplot.
For the rpath look at the guidelines, unless I am wrong it is more or less explained there.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #18 from ritz rkhadgar@redhat.com 2008-09-08 07:20:30 EDT --- updated. thanks for the inputs.
http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17.1-1.src.rpm
-- ritz
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
Itamar Reis Peixoto itamar@ispbrasil.com.br changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |itamar@ispbrasil.com.br Alias| |librep
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #19 from Patrice Dumas pertusus@free.fr 2008-09-28 16:35:42 EDT --- I think it is better to keep changelog, to track not only changes but also their pace, but it is not a big deal.
For the emacs package this is a bit strange. Indeed -el subupackages are, unless I am wrong, like -devel subpackages. It seems to me that the 'compiled' emacs module is missing. That being said, I know next to nothing about emacs.
pkgconfig dependency is missing for -devel.
rpmlint warnings are harmless in my opinion librep-devel.i386: W: no-documentation librep-devel.i386: E: only-non-binary-in-usr-lib emacs-librep-el.i386: W: no-documentation
The files in devel in /usr/lib/rep/%{_host} seem dubious. Are they really of use?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #20 from Patrice Dumas pertusus@free.fr 2008-09-28 16:50:10 EDT --- Also in librep.pc there is no Libs: entry???
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #21 from ritz rkhadgar@redhat.com 2008-10-03 17:59:30 EDT ---
I notice a bunch of .la files packaged. Generally these should not be packaged; do you have some specific reason for doing so?
need them to build rep-gtk, or anything for that matter with rep. this is needed. added these to devel package.
Indeed -el subupackages are, unless I am wrong, like -devel subpackages. It seems to me that the 'compiled' emacs module is missing. That being said, I know next to nothing about emacs.
I do not see any reason to build them. is this really required ?
The files in devel in /usr/lib/rep/%{_host} seem dubious. Are they really of use?
Yes, to build any apps againt rep.
updated package
http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17.2-1.20081003sv...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #22 from Patrice Dumas pertusus@free.fr 2008-10-03 18:35:26 EDT --- The release is not right for svn snapshots. Should be like 0.1.20081003svn
Since you use autogen now, I guess that autoconf/automake are needed.
devel should require pkgconfig.
Looks like the %{_libdir}/rep/ directory is unowned.
Using rep in /usr/share, and in bindir is bad, in my opinion. See http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_com...
Using librep instead would be right for the directory, and something else for the binary. But this has to be done with upstream.
Regarding the emacs subpackages, my intuition is that with only the el package, it just doeosn't work. But i may well be wrong. I think that even if the emacs packaging is not perfect, this shouldn't block the review, this is not vital and i am not knowlegable enough.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #23 from Michal Jaegermann michal@harddata.com 2008-10-03 18:59:18 EDT ---
Regarding the emacs subpackages, my intuition is that with only the el package, it just doeosn't work.
You really do not need .elc packages with emacs at all. This is only an "optimization" to load things faster and with nowadays CPUs negligible one (this was not the case at emacs beginnings). There was also "undumping" which ceased to be feasible.
Moreover I know of cases when a presence of .elc packages really break things, causing some functions to bail out with complaints about wrong parameters, while removal of those and leaving only .el files provides a fix.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #24 from ritz rkhadgar@redhat.com 2008-10-03 19:11:58 EDT ---
Since you use autogen now, I guess that autoconf/automake are needed.
devel should require pkgconfig. Looks like the %{_libdir}/rep/ directory is unowned.
Updated spec and srpm
Using rep in /usr/share, and in bindir is bad, in my opinion. See http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_com...
Using librep instead would be right for the directory, and something else for the binary. But this has to be done with upstream.
I really doubt, if this will happen anytime soon. Will check this up with upstream maintainer. Additionally, I was unable to locate any other projects, which used rep for name on google search.
You really do not need .elc packages with emacs at all.
Thanks for the info.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #25 from Patrice Dumas pertusus@free.fr 2008-10-03 20:20:49 EDT --- Where is the updated srpm?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #26 from ritz rkhadgar@redhat.com 2008-10-03 20:30:01 EDT --- here - http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17.2-1.20081003sv...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #27 from ritz rkhadgar@redhat.com 2008-10-04 04:04:59 EDT ---
Using rep in /usr/share, and in bindir is bad, in my opinion. See http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_com...
debain is using rep itsel, and upstream[1] does not see much value in this change
[1] http://mail.gnome.org/archives/sawfish-list/2008-October/msg00004.html
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #28 from ritz rkhadgar@redhat.com 2008-10-04 04:16:19 EDT --- updated package
http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17.2-2.20081003sv...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #29 from Patrice Dumas pertusus@free.fr 2008-10-04 05:58:40 EDT --- The %{_libdir}/rep/%{version}/ dir seems unowned.
The %version is still wrong, should be 0.X.20081003svn....
I understand why the .la could be needed at runtime for the dlopened modules, but is really %{_libdir}/librep.la needed at build time?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #30 from ritz rkhadgar@redhat.com 2008-10-04 07:30:14 EDT ---
I understand why the .la could be needed at runtime for the dlopened modules, but is really %{_libdir}/librep.la needed at build time?
fixed.
The %version is still wrong, should be 0.X.20081003svn....
fixed
http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17.2-0.2.20081003...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #31 from Patrice Dumas pertusus@free.fr 2008-10-04 12:56:25 EDT --- * rpmlint output ignorable: librep-devel.i386: W: no-documentation librep-devel.i386: E: only-non-binary-in-usr-lib emacs-librep-el.i386: W: no-documentation X free software, but license should be included * follow guidelines * match upstream (checked manually) * usual .so unuseful provides X directory %{_libdir}/rep/%{version}/ unowned.
# rpm -qf /usr/lib/rep/0.17.2/ file /usr/lib/rep/0.17.2 is not owned by any package
I would suggest putting AUTHORS MAINTAINERS in %doc. And maybe doc/*.
2 issues marked with X to be fixed before approval.
And also before approval there are multilib issues remaining:
In librep.pc there is no Libs: entry???
The file /usr/bin/rep-config will conflict in multilib settings, on fedora it would be better to patch it such that it is a wrapper around pkgconfig, and you can submit to upstream the resulting rep-config script such that they also ship it, and packagers can choose what to install.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #32 from ritz rkhadgar@redhat.com 2008-10-05 13:03:09 EDT ---
The file /usr/bin/rep-config will conflict in multilib settings,
is multilib support really required ? As i see this to be of little value - comment#11 .
In librep.pc there is no Libs: entry???
As of now, i am thinking of excluding this from package. Will talk to upstream about this using this as a wrapper around pkgconfig.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #33 from Patrice Dumas pertusus@free.fr 2008-10-05 15:47:43 EDT --- (In reply to comment #32)
The file /usr/bin/rep-config will conflict in multilib settings,
is multilib support really required ? As i see this to be of little value - comment#11 .
One may want to link against a specific arch. But even though this is not a very usefull setting, one should not have get error when installing both, and currently this is the case, since there is a conflict.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #34 from Michal Jaegermann michal@harddata.com 2008-10-09 00:48:20 EDT --- Files in rep/%{version}/%{_host}/ were moved from %{_libexecdir}/rep/... to %{_libdir}/rep/... Not sure when, how and what for? This makes sawfish specs, ahem, "interesting" as they work or not depending only on with which version of librep you are trying to compile without any real interface changes in this library. Sawfish will compile but %files section will change depending on circumstances. It is possible to check in specs where librep in use puts 'rep' and define %{librepwhere} accordingly to be used in %files; it looks like an extra bother.
Was this an attempt to make librep and sawfish "multilib"? I miss a purpose of such exercise although maybe there is one?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #35 from Patrice Dumas pertusus@free.fr 2008-10-09 05:18:23 EDT --- (In reply to comment #34)
Was this an attempt to make librep and sawfish "multilib"? I miss a purpose of such exercise although maybe there is one?
If there is %{_host} it shouldn't be problematic with respect with multilib (at least regarding file conflicts).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #36 from Michal Jaegermann michal@harddata.com 2008-10-09 10:53:18 EDT ---
If there is %{_host} ...
You mean that architecture shows up as a part of %{_host}? In that case was the move in question dictated by other considerations?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #37 from Patrice Dumas pertusus@free.fr 2008-10-09 11:32:02 EDT --- (In reply to comment #36)
If there is %{_host} ...
You mean that architecture shows up as a part of %{_host}? In that case was the move in question dictated by other considerations?
$ rpm --eval %_host i386-redhat-linux-gnu
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #38 from ritz rkhadgar@redhat.com 2008-10-14 08:55:09 EDT --- I had tried building a multi-lib package before, and ended up with conflict between i386 and x86_64 package. Few of the files are listed below
/usr/share/rep/0.17.2/lisp/cgi-get.jl /usr/share/rep/0.17.2/lisp/cgi-get.jlc /usr/share/rep/0.17.2/lisp/compiler.jl /usr/share/rep/0.17.2/lisp/compiler.jlc /usr/share/rep/0.17.2/lisp/date.jl /usr/share/rep/0.17.2/lisp/date.jlc /usr/share/rep/0.17.2/lisp/disassembler.jl /usr/share/rep/0.17.2/lisp/disassembler.jlc /usr/share/rep/0.17.2/lisp/gaol.jl /usr/share/rep/0.17.2/lisp/gaol.jlc /usr/share/rep/0.17.2/lisp/lisp-doc.jl ...
as pointed out by comment#9, i do not see any reason for a person to install both x86_64 , and i386 version on a system.
-------------------------
If otherwise required, i will go ahead and package /usr/share/rep/%{version}/lisp/ under librep-common package. the only question being, how do i build a noarch package ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #39 from Patrice Dumas pertusus@free.fr 2008-10-19 07:25:30 EDT --- I you have rpms, I'd like to look at the files to see where differences are. I tried a scratch build, but it failed: https://koji.fedoraproject.org/koji/taskinfo?taskID=888335
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #40 from ritz rkhadgar@redhat.com 2008-10-20 00:18:51 EDT --- sorry, i was unable to access the page.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #41 from Patrice Dumas pertusus@free.fr 2008-10-20 16:07:53 EDT --- I can access that page...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #42 from ritz rkhadgar@redhat.com 2008-10-20 16:43:53 EDT --- my bad, i had not installed the cert.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
Jonathan Underwood jonathan.underwood@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.underwood@gmail.co | |m
--- Comment #43 from Jonathan Underwood jonathan.underwood@gmail.com 2008-10-22 13:08:22 EDT --- Michal, you need a emacs-%{name} sub-package which contains the byte compiled emacs files (this is distinct from the emacs-%{name}-el subpackage which contains the elsip source files).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #44 from Michal Jaegermann michal@harddata.com 2008-10-22 13:20:39 EDT ---
Michal, you need a emacs-%{name} sub-package ...
Eh? What do you mean by "you need"? It may be useful for some, although in various cases this is really debatable, but is surely not "needed" if you have .el files.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #45 from Jonathan Underwood jonathan.underwood@gmail.com 2008-10-22 13:24:22 EDT --- (In reply to comment #44)
Michal, you need a emacs-%{name} sub-package ...
Eh? What do you mean by "you need"? It may be useful for some, although in various cases this is really debatable, but is surely not "needed" if you have .el files.
Please see:
https://fedoraproject.org/wiki/Packaging/Emacs
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #46 from Jonathan Underwood jonathan.underwood@gmail.com 2008-10-22 13:31:26 EDT --- Actually comment #43 was aimed at the package submitter ("ritz") rather than Michal, apologies for that.
But the point stands - byte compilation is necessary, as it provides a speedup when parsing many elisp files (particularly on older machines. Also, if a file doesn't do what it should when byte compiled, then that's a bug.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #47 from Michal Jaegermann michal@harddata.com 2008-11-03 12:01:35 EDT --- Re comment #6 about building a "noarch subpackages". A changelog for rpm-4.6.0-0.rc1.7 in the current rawhide includes the following comment:
* Sat Oct 25 2008 Panu Matilainen pmatilai@redhat.com - Make noarch sub-packages actually work
I guess that this leaves you in a cold with earlier rpm versions. Maybe Panu would have some additional comments; in particular about mechanics of this option.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #48 from Jason Tibbitts tibbs@math.uh.edu 2008-11-04 14:28:00 EDT --- rpm may now support noarch subpackages, but the buildsys doesn't. Honestly there are some interesting issues that crop up, such as which of the noarch packages gets used? The one from the i386 build, the x86_64 build, one of the PPC builds, or something else? There's no guarantee that they're the same; unless significant care is taken they will almost always differ in the timestamps of the included files and may differ in more significant ways.
Bottom line: noarch subpackages do not work and aren't going to work even in F10, regardless of what support has been checked into rpm.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #49 from Jason Tibbitts tibbs@math.uh.edu 2008-12-22 15:37:10 EDT --- So what's up with this ticket? The last comment from the submitter was a comple of months ago. As for the emacs stuff, I would suggest that you follow the emacs packaging guidleines if you intend to package the emacs stuff, but other packages have simply taken the step of packaging a lone .el file as documentation and leaving it to the end user to set that up if they want it.
Also, the package in comment #30, which seems to be the most recent one, fails to build for me in rawhide:
Running aclocal Running autoconf configure: WARNING: unrecognized options: --disable-rpath configure: error: cannot run /bin/sh ./config.sub
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
--- Comment #50 from Michal Jaegermann michal@harddata.com 2008-12-22 20:35:15 EDT ---
Also, the package in comment #30, which seems to be the most recent one,
The package may be the most recent one but the current _releases_ are librep 0.17.2: http://sourceforge.net/project/showfiles.php?group_id=580 rep-gtk 0.18.3: http://sourceforge.net/project/showfiles.php?group_id=581 and sawfish 1.3.5: http://sourceforge.net/project/showfiles.php?group_id=32
The first two were released 2008-10-22 and sawfish on 2008-12-20.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
Jason Tibbitts tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(rkhadgar@redhat.c | |om)
--- Comment #51 from Jason Tibbitts tibbs@math.uh.edu 2009-02-11 14:19:05 EDT --- It's been many months since the last comment from the submitter of this ticket; I will close this out in a week if progress isn't made.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
Jason Tibbitts tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Blocks|177841(FE-NEEDSPONSOR) | Resolution| |NOTABUG Flag|needinfo?(rkhadgar@redhat.c | |om) |
--- Comment #52 from Jason Tibbitts tibbs@math.uh.edu 2009-03-09 20:07:36 EDT --- Well, I waited a month. Closing.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
Jason Tibbitts tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |201449(FE-DEADREVIEW)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
Peter Lemenkov lemenkov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |496433(RussianFedora)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=431250
Jason Tibbitts tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|NOTABUG |DUPLICATE
--- Comment #53 from Jason Tibbitts tibbs@math.uh.edu 2011-03-31 15:33:29 EDT ---
*** This bug has been marked as a duplicate of bug 692537 ***
package-review@lists.fedoraproject.org
-
Red Hat Bugzilla