https://bugzilla.redhat.com/show_bug.cgi?id=1040517
--- Comment #67 from Milan Bouchet-Valat <nalimilan(a)club.fr> ---
(In reply to Paulo Andrade from comment #65)
> > 1) I believe none of the installed Makefile files are
required
> > (or functional):
> > $ find /usr/share/julia/ -name Makefile
> > /usr/share/julia/test/perf/micro/Makefile
> > /usr/share/julia/test/perf/shootout/Makefile
> > /usr/share/julia/test/perf/Makefile
> > /usr/share/julia/test/Makefile
> > /usr/share/julia/examples/Makefile
> Right, these only work from inside the source tree anyway. I've even removed
> the perf suite, which does not work when installed, and contains a few files
> with non-MIT licenses.
%check now fails like this:
exception on 1: ERROR: opening file perf/kernel/imdb-1.tsv: No such file or
directory
in open at ./iostream.jl:117
in open at ./iostream.jl:135
while loading readdlm.jl, in expression starting on line 4
ERROR: opening file perf/kernel/imdb-1.tsv: No such file or directory
in open at ./iostream.jl:117
in open at ./iostream.jl:135
while loading readdlm.jl, in expression starting on line 4
while loading /home/pcpa/rpmbuild/BUILD/julia-0.3.0/test/runtests.jl, in
expression starting on line 35
Makefile:16: recipe for target 'readdlm' failed
make: *** [readdlm] Error 1
Woops! I got tired of running the checks again and
again so I disable them. I
guess I should have run them at least once...
So let's keep installing the perf suite for now, only removing Makefiles.
> > 2) Is it really required to install /usr/share/julia/test
?
> > I checked it, and apparently must call the runtests.jl, I
> > did not change the environment, but apparently not everything
> > was fine:
> [...]
> Yeah, currently the backtrace test is failing with LLVM 3.4
> (
https://github.com/JuliaLang/julia/issues/8099). I think it's still better
> to ship this file, hopefully this will get fixed soon enough. (FWIW, this
> file can be called by Base.runtests().)
>
> > 3) Can it be changed to install documentation in %_docdir?
> > All documentation is under /usr/share/julia
> Yes, I've filed a bug upstream, and for now I move the files manually:
>
https://github.com/JuliaLang/julia/issues/8367
Looks almost good :) Just that now there are two packages
owning LICENSE.md and other UPPERCASE files.
Ah, I've added a series of
%exclude for -doc.
BTW, you could change:
%files doc
%dir %{_docdir}/julia/
%doc %{_docdir}/julia/*
to
%files doc
%doc %{_docdir}/julia/
Fixed. Michael: I prefer keeping the explicit %doc because I
won't remember it
happens automatically. :-)
> > 4) I believe there is something wrong with the
documentation. It
> > should install processed documentation. I try to build it
> > manually, by switching to the doc subdir I see this:
> [...]
> > So, I believe just the hack to create juliadoc/juliadoc/__init__.py is not
> > enough.
> Yes, I've filed this in the same upstream issue. I'd say for now let's
> install the .rst files, which are readable if not pretty, and wait for
> upstream to make it possible to install HTML files properly.
I believe it can be fixed in the current rpm, probably a patch actually
creating an usable juliadoc/juliadoc/__init__.py or whatever is
missing from the tarball.
Yes, copying these files from Julia git seems to work,
but then I need to carry
the patch and move files around by hand. Is it really worth it? I'd prefer
fixing this upstream directly, I've filed an issue:
https://github.com/JuliaLang/julia/issues/8378
> > 5) It has been commented before, but it really would be
better to
> > have a versioned .so under %_libdir; subdirectories usually are
> > modules, and, usually are ok.
> The problem is, Julia has not yet committed to API stability, so there's no
> versioning upstream, and if I invented one I would need to change the
> SOVERSION for every new release. I'm not sure it's worth it. What do you
> think?
It would be better to not make the libjulia.so symlink to start with.
I don't
think so, as GUIs embedding Julia, like iJulia, may need to link to it.
I realize this may be an argument in favor of adding a SOVERSION. I guess I
should ask upstream about that.
Then, remove the rpath from binary(ies) and add to the package
an /etc/ld.so.conf/julia-%{_arch}.conf that on x86_64 would have
/usr/lib64/julia
as contents.
Not the most "beautiful" way (better to patch build), but using
"chrpath -d" after build should be ok to remove the rpath.
Actually the
RPATH points to /usr/bin/../lib64/julia/, so I could remove the
symlink without problems for Julia itself.
I believe, to remove another "rpmlint E:" you could instead
of
Requires: dSFMT-devel
have a dangling link, e.g.:
/usr/lib64/julia/lib.dSFMT.so -> /usr/lib64/libdSFMT.so.2
or create it in %post (and remove in %postun) to avoid rpmlint
warnings. This way it wold also break "on purpose" if there is
a major bump of dSFMT.
Probably, but it sounds a bit hack (and I have to do the
same for openlibm and
openspecfun). Isn't there any way of setting Requires(libdSMFT.so.2)?
Another issue is that you could split the files installed under
/usr/share/julia in a noarch package, unless they are not noarch,
but then they are in the wrong place :) Say, a new julia-data
package or package similar name.
Done.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component