https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #67 from Milan Bouchet-Valat <nalimilan@xxxxxxx> --- (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 _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review