Spec URL: http://nalimilan.perso.neuf.fr/transfert/julia.spec SRPM URL: http://nalimilan.perso.neuf.fr/transfert/julia-0.2.0-1.fc19.src.rpm Description: Julia is a high-level, high-performance dynamic programming language for technical computing, with syntax that is familiar to users of other technical computing environments. It provides a sophisticated compiler, distributed parallel execution, numerical accuracy, and an extensive mathematical function library. The library, largely written in Julia itself, also integrates mature, best-of-breed C and Fortran libraries for linear algebra, random number generation, signal processing, and string processing. Fedora Account System Username: nalimilan This package needs the double-conversion library to build: https://bugzilla.redhat.com/show_bug.cgi?id=1040027 rpmlint shows a few errors, but these are in part spurious: - E: binary-or-shlib-defines-rpath: Julia links against private libraries /usr/lib/julia/. I think it is correct to set the rpath for that. - E: missing-call-to-setgroups: This is triggered because the Julia standard library offers issetuid() and issetgid() functions, and the rpmlint check is very rough. Julia does not run as setuid in any way. - W: dangling-relative-symlink: Here I'm probably doing something wrong because rpmlint does not detect that the file the symlink points to (/usr/share/man/man1/julia.1.gz) is provided by the julia package, which is a dependency of julia-devel. I've tried adding Requires: exists(/usr/share/man/man1/julia.1.gz), but that does not fix the problem. - E: non-standard-dir-perm: I don't understand what creates this %{buildroot}/usr/src/debug/tmp directory. I've tried removing it at the end of the %install phase, but it doesn't exist at that point, so I guess it's created when generating the debuginfo package. Is this a bug? $ rpmlint SPECS/julia.spec RPMS/x86_64/julia-0.2.0-1.fc19.x86_64.rpm julia.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/julia-readline ['$ORIGIN/../lib64/julia', '$ORIGIN/../lib64'] julia.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/julia-basic ['$ORIGIN/../lib64/julia', '$ORIGIN/../lib64'] julia.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/julia/libjulia.so ['$ORIGIN'] julia.x86_64: E: missing-call-to-setgroups /usr/lib64/julia/libjulia.so 1 packages and 1 specfiles checked; 4 errors, 0 warnings. $ rpmlint SPECS/julia.spec RPMS/x86_64/julia-devel-0.2.0-1.fc19.x86_64.rpm julia-devel.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/julia-debug-readline ['$ORIGIN/../lib64/julia', '$ORIGIN/../lib64'] julia-devel.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/julia/libjulia-debug.so ['$ORIGIN'] julia-devel.x86_64: E: missing-call-to-setgroups /usr/lib64/julia/libjulia-debug.so julia-devel.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/julia-debug-basic ['$ORIGIN/../lib64/julia', '$ORIGIN/../lib64'] julia-devel.x86_64: W: dangling-relative-symlink /usr/share/man/man1/julia-debug-basic.1.gz julia.1.gz julia-devel.x86_64: W: dangling-relative-symlink /usr/share/man/man1/julia-debug-readline.1.gz julia.1.gz 1 packages and 1 specfiles checked; 4 errors, 2 warnings. $ rpmlint SPECS/julia.spec RPMS/x86_64/julia-doc-0.2.0-1.fc19.x86_64.rpm 1 packages and 1 specfiles checked; 0 errors, 0 warnings. $ rpmlint SPECS/julia.spec RPMS/x86_64/julia-debuginfo-0.2.0-1.fc19.x86_64.rpm julia-debuginfo.x86_64: E: non-standard-dir-perm /usr/src/debug/tmp 01777L 1 packages and 1 specfiles checked; 1 errors, 0 warnings. These are my two first packages so I need sponsoring. Thanks for your help! :-)
Drop-by: 1. ExclusiveArch has i386 only? Please do this from command line: rpm -E %{ix86} 2. Group: Applications/Engineering Fedora now doesn't need it as a MUST, you can drop it if you want. 3. # .gitignore files make rpmlint complain find . -name ".git*" -exec rm {} \; Please tell upstream don't include such files in the tarball 4. %{buildroot}/usr Please use %{_prefix} for /usr. And I've sent a patch to upstream. 5. %SYSCONFDIR=/etc Please use macro %{_sysconfdir} And did you consider seriously why you still have to run "mv %{buildroot}/usr/etc/ %{buildroot}/etc"? I think %SYSCONFDIR=/etc doesn't work, please try to fix the errors from your part, and try again. 6. /usr/%{_lib} --> %{_libdir} 7. Is it a MUST? ln -s julia.1.gz julia-basic.1.gz ln -s julia.1.gz julia-readline.1.gz ln -s julia.1.gz julia-debug-basic.1.gz ln -s julia.1.gz julia-debug-readline.1.gz 8. It's better to add soname to these libraries. 9. %files section: %{_datadir}/man/man1/julia.1.gz Please use macro, and also a glob to let RPM determine if the manpages are compressed already or not: %{_mandir}/man1/julia.1* 10. %post devel -p /sbin/ldconfig %postun devel -p /sbin/ldconfig Please put above lines before %files. 11. Please leave a blank line between each changelog, this will help some people not keen-eyed.
Thanks for the reply. I've updated the files linked above with a revised .spec and .src.rpm. I have renamed julia to julia-base and made julia a metapackage depending on julia-base and julia-doc, to follow what R currently does. I figured in the future it could become more important when some essential packages could be installed by default for most users. Please tell me whether you think it's right. (In reply to Christopher Meng from comment #1) > Drop-by: > > 1. ExclusiveArch has i386 only? > > Please do this from command line: > > rpm -E %{ix86} Woops, obviously I meant that. I couldn't find a list of architectures until you gave me this macro. > 2. Group: Applications/Engineering > > Fedora now doesn't need it as a MUST, you can drop it if you want. Yeah, but I figured it couldn't hurt. As you prefer. > 3. # .gitignore files make rpmlint complain > find . -name ".git*" -exec rm {} \; > > Please tell upstream don't include such files in the tarball Yeah, another issue I'm going to file. This is because upstream does not really make tarballs at the moment, they merely mark git commits as the release. > 4. %{buildroot}/usr > > Please use %{_prefix} for /usr. > > And I've sent a patch to upstream. So you mean use %{buildroot}/%{_prefix}? Indeed, I've done that now. > 5. %SYSCONFDIR=/etc > > Please use macro %{_sysconfdir} Done. > And did you consider seriously why you still have to run "mv > %{buildroot}/usr/etc/ %{buildroot}/etc"? I think %SYSCONFDIR=/etc doesn't > work, please try to fix the errors from your part, and try again. Yeah, I said upstream that their Makefile is currently broken. It always installs to $PREFIX/etc, as Makefile explains: # Note that we don't install to SYSCONFDIR: we always install to PREFIX/etc. # If you want to make a distribution with a hardcoded path, you take care of installation My goal is to get rid of this kind of ugly hacks for the next release. > 6. /usr/%{_lib} > > --> > > %{_libdir} Done. > 7. Is it a MUST? > > ln -s julia.1.gz julia-basic.1.gz > ln -s julia.1.gz julia-readline.1.gz > ln -s julia.1.gz julia-debug-basic.1.gz > ln -s julia.1.gz julia-debug-readline.1.gz Not sure, rpmlint complains when manpages are missing, and this may still be useful. I've got a change accepted upstream to ship those files in the future. > 8. It's better to add soname to these libraries. You mean, to libjulia.so? (Others are only for internal use.) Indeed it would make sense, but I'd rather wait for upstream to do that -- I think they do not consider the API/ABI stable at this point. Do you think I should call the file libjulia.so.0 anyway? > 9. %files section: > > %{_datadir}/man/man1/julia.1.gz > > Please use macro, and also a glob to let RPM determine if the manpages are > compressed already or not: > > %{_mandir}/man1/julia.1* Nice trick! > 10. %post devel -p /sbin/ldconfig > %postun devel -p /sbin/ldconfig > > Please put above lines before %files. Done. > 11. Please leave a blank line between each changelog, this will help some > people not keen-eyed. Done.
I've raised Release and put the new files here: http://nalimilan.perso.neuf.fr/transfert/julia.spec http://nalimilan.perso.neuf.fr/transfert/julia-0.2.0-2.fc19.src.rpm
With double-conversion now in the repos, the new package builds fine on Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=6305726
I built http://nalimilan.perso.neuf.fr/transfert/julia-0.2.0-2.fc19.src.rpm on f20 x86_64 OK, but: sudo yum install rpmbuild/RPMS/x86_64/julia* [sudo] password for nbecker: Loaded plugins: fastestmirror, langpacks, merge-conf, refresh-packagekit Repository google-chrome is listed more than once in the configuration Examining rpmbuild/RPMS/x86_64/julia-base-0.2.0-2.fc20.x86_64.rpm: julia-base-0.2.0-2.fc20.x86_64 Marking rpmbuild/RPMS/x86_64/julia-base-0.2.0-2.fc20.x86_64.rpm to be installed Examining rpmbuild/RPMS/x86_64/julia-debuginfo-0.2.0-2.fc20.x86_64.rpm: julia-debuginfo-0.2.0-2.fc20.x86_64 Marking rpmbuild/RPMS/x86_64/julia-debuginfo-0.2.0-2.fc20.x86_64.rpm to be installed Examining rpmbuild/RPMS/x86_64/julia-devel-0.2.0-2.fc20.x86_64.rpm: julia-devel-0.2.0-2.fc20.x86_64 Marking rpmbuild/RPMS/x86_64/julia-devel-0.2.0-2.fc20.x86_64.rpm to be installed Examining rpmbuild/RPMS/x86_64/julia-doc-0.2.0-2.fc20.x86_64.rpm: julia-doc-0.2.0-2.fc20.x86_64 Marking rpmbuild/RPMS/x86_64/julia-doc-0.2.0-2.fc20.x86_64.rpm to be installed Resolving Dependencies --> Running transaction check ---> Package julia-base.x86_64 0:0.2.0-2.fc20 will be installed ---> Package julia-debuginfo.x86_64 0:0.2.0-2.fc20 will be installed ---> Package julia-devel.x86_64 0:0.2.0-2.fc20 will be installed --> Processing Dependency: julia(x86-64) = 0.2.0-2.fc20 for package: julia-devel-0.2.0-2.fc20.x86_64 Loading mirror speeds from cached hostfile * fedora: fedora.mirrors.tds.net * rpmfusion-free: mirror.us.leaseweb.net * rpmfusion-free-updates: mirror.us.leaseweb.net * rpmfusion-nonfree: mirror.us.leaseweb.net * rpmfusion-nonfree-updates: mirror.us.leaseweb.net * updates: fedora.mirrors.tds.net ---> Package julia-doc.x86_64 0:0.2.0-2.fc20 will be installed --> Finished Dependency Resolution Error: Package: julia-devel-0.2.0-2.fc20.x86_64 (/julia-devel-0.2.0-2.fc20.x86_64) Requires: julia(x86-64) = 0.2.0-2.fc20 You could try using --skip-broken to work around the problem
Thanks. I guess julia-devel should depend on julia-base, not on julia. I'll change that, but you can easily fix the .spec file if you want.
I'm not certain, but I believe the explicit dependency should just be deleted. I believe rpm is supposed to add the correct dep here automatically.
Well, one needs a "Requires: %{name}=%{version}-%{release}" generally in a devel package, but in this case the base package is %{name}-base as Milan noted. However, I do not agree with the change of julia being a meta-package to bring in julia-base and julia-doc. Perhaps if there were more sub-packages to bring in, but not just for those two.
The meta-package thing was done with the idea that in the future more packages could be installed by default. What comes to mind, similar to what happens with R, is a host of recommended packages for plotting, data frames, data import (in short, JuliaStats). There was a debate about whether these should be handled via system packages or using Julia's package management system. Not sure what's the best solution (with the former, you don't need duplicate copies for each user).
I believe meta-packages are frowned upon and comps groups preferred for this sort of thing.
OK, I've removed the julia meta-package. I'll request a new comp group when everything is packaged. So when utf8proc and openlibm will have been reviewed, everything will be ready.
Are you OK with the new version? (FWIW, ARM support in Julia might well be ready for the next 0.3 version.)
ARM support would be nice to see. Misc: %exclude %{_libdir}/julia/libuv.a %exclude %{_libdir}/julia/libjulia-debug.so should not be necessary Blank lines between %changelog entries please. Have you filed for bundling exceptions yet for dSMRT, libuv, and Rmath?
The second exclude is not needed, but the first is because the libuv static library is not needed for Julia to run. I could include it in the -devel package, but I'm not sure which program would need it. Anyway in the long term we should use the system shared library. I'm going to file bundling exceptions requests for the libraries.
Hmm, I would have thought rpm would complain about unpackaged files in the libuv.a case. I tend to prefer simply using rm in %install, but whatever you like best. The llvm version appears to be hardcoded into deps/Versions.make so it fails with llvm 3.4. You'll need a way to changed this automatically as needed. You're going to need to work around lack of network access for the julia tests: + cd test + make all Warning: git information unavailable; versioning information limited JULIA test/all ERROR: connect: network is unreachable (ENETUNREACH) while loading /export/home/orion/redhat/julia-0.3.0/julia-master/test/runtests.jl, in expression starting on line 29 make: *** [all] Error 1 error: Bad exit status from /tmp/rpm/rpm-tmp.BrEF5I (%check)
Hello, I tried to build on Fedora Copr and it requried to add BuildRequires: openspecfun-devel to spec file. Consider adding it, please. Thanks,
1. Builds on copr fail sometime due to failing test in file arpack.jl 2. After installing from copr, I got the following error message: Target architecture mismatch. Please delete or regenerate sys.{so,dll,dylib} So I deleted /usr/lib64/julia/sys.so as suggested. After that I got the following message on julia's start: Warning: error initializing module LinAlg: ErrorException("error compiling __init__: error compiling check_blas: error compiling blas_vendor: could not load module libopenblas.so: libopenblas.so: cannot open shared object file: No such file or directory") So I installed openblas-devel to resolve it.
Orion: Yes, LLVM is going to be a problem. I've updated it manually to 3.4, but I don't know how to make it automatic, and more profoundly there's no guarantee that Julia will work with any newer versions without changes. So it may be better to retain the manual update solution. I'll also have a look at the network access issue. baurthefirst: Thanks, I didn't know about copr, and I wasn't able to use Koji since utf8proc and openlibm are not present there. I'll have a look. Since Julia opens libraries at run time, it may indeed try to acces libopenblas.so rather than libopenblas-r0.2.8.so or the equivalent, and therefore require opneblas-devel. This should probably be fixed uptsream. Meanwhile, I've filed a bundling exception request at https://fedorahosted.org/fpc/ticket/427
(In reply to Milan Bouchet-Valat from comment #18) > Orion: Yes, LLVM is going to be a problem. I've updated it manually to 3.4, > but I don't know how to make it automatic, and more profoundly there's no > guarantee that Julia will work with any newer versions without changes. So > it may be better to retain the manual update solution. > > I'll also have a look at the network access issue. > > baurthefirst: Thanks, I didn't know about copr, and I wasn't able to use > Koji since utf8proc and openlibm are not present there. I'll have a look. > Since Julia opens libraries at run time, it may indeed try to acces > libopenblas.so rather than libopenblas-r0.2.8.so or the equivalent, and > therefore require opneblas-devel. This should probably be fixed uptsream. > > > Meanwhile, I've filed a bundling exception request at > https://fedorahosted.org/fpc/ticket/427 Have you considered setting JULIA_CPU_TARGET to core2? By default it is set to native, thus causing the issue as I wrote earlier: Target architecture mismatch. Please delete or regenerate sys.{so,dll,dylib}
I meant, when you compile julia on a newer CPU, its library file /usr/lib64/julia/sys.so may not work on older CPUs. See https://groups.google.com/forum/#!topic/julia-dev/Eqp0GhZWxME
(In reply to Milan Bouchet-Valat from comment #18) > Orion: Yes, LLVM is going to be a problem. I've updated it manually to 3.4, > but I don't know how to make it automatic, and more profoundly there's no > guarantee that Julia will work with any newer versions without changes. So > it may be better to retain the manual update solution. Well, you're just to going to have to address whatever issues might come up with new LLVM version, so you might as just set it by adding: LLVM_VER=$(llvm-config --version) to commonopts. I wish they would just use cmake or some other build system rather than trying to hack up their own.
(In reply to baurthefirst from comment #19) > Have you considered setting JULIA_CPU_TARGET to core2? By default it is set > to native, thus causing the issue as I wrote earlier: > > Target architecture mismatch. Please delete or regenerate sys.{so,dll,dylib} Hmm, how does this play with other architectures? 32-bit?
baurthefirst: Right, I'll fix that too. Orion: Thanks for the LLVM hint. I just have to hope that the situation where Julia does not support a new version of LLVM which is pushed to the current release happens... Regarding the CPU target, indeed core2 is a relatively high requirement. I've filed and issue: https://github.com/JuliaLang/julia/issues/6715 Do you think it would be reasonable to still require some recent instruction sets, like SSE (I guess this one is OK), SSE2, SSE3, SSSE3?...
Orion: How do you reproduce the ENETUNREACH tests failure? Do you need to disable the loopback interface?
linux-user-chroot --unshare-net / rpmbuild .... copr builds should reproduce as well.
Thanks, filed here: https://github.com/JuliaLang/julia/issues/6722
Filed https://github.com/JuliaLang/julia/issues/6742 about the unexpected dependency on openspecfun-devel (also applies to openlibm).
I've created a copr project here: http://copr.fedoraproject.org/coprs/nalimilan/julia/ It unveiled two more failures in the tests: https://github.com/JuliaLang/julia/issues/6743 https://github.com/JuliaLang/julia/issues/6744
Is julia-release-basic not packaged? This is needed to run julia under emacs
I tried using julia (0.3.0-prerelease) using emacs in ess. It appears to work without using julia-release-basic, so maybe this is no longer required?
julia-release-basic/julia-basic existed until recently, when the Julia-based readline implementation was merged. Now only the julia executable exists.
Broken deps? ---> Package julia.x86_64 0:0.3.0-2.fc20 will be installed --> Processing Dependency: libLLVM-3.3.so()(64bit) for package: julia-0.3.0-2.fc20.x86_64 --> Finished Dependency Resolution Error: Package: julia-0.3.0-2.fc20.x86_64 (nalimilan-julia) Requires: libLLVM-3.3.so()(64bit) Available: llvm-libs-3.3-0.10.rc3.fc20.x86_64 (fedora) libLLVM-3.3.so()(64bit) Installed: llvm-libs-3.4-6.fc20.x86_64 (@updates) ~libLLVM-3.4.so()(64bit)
Needs rebuild after llvm-3.4 landed in updates: https://admin.fedoraproject.org/updates/FEDORA-2014-5319
Yeah, but LLVM 3.4 triggers problems when running the tests (cf. comments above). In the meantime, you can replace llvm-libs-3.4 with the old 3.3 version from the "fedora" repo.
(In reply to Milan Bouchet-Valat from comment #34) > Yeah, but LLVM 3.4 triggers problems when running the tests (cf. comments > above). In the meantime, you can replace llvm-libs-3.4 with the old 3.3 > version from the "fedora" repo. No, in most cases you can't. Many other packages will drag in llvm-libs-3.4 and you can't install the old version without removing them. In general, I think mesa will trip up users: repoquery --whatrequires llvm-libs-3.4 OpenGTL-0:0.9.18-9.fc20.x86_64 OpenGTL-devel-0:0.9.18-9.fc20.i686 OpenGTL-devel-0:0.9.18-9.fc20.x86_64 OpenGTL-libs-0:0.9.18-9.fc20.i686 OpenGTL-libs-0:0.9.18-9.fc20.x86_64 clang-0:3.4-6.fc20.i686 clang-0:3.4-6.fc20.x86_64 dragonegg-0:3.4-0.3.rc0.fc20.x86_64 gambas3-gb-jit-0:3.5.3-1.fc20.1.x86_64 lightspark-0:0.7.2-8.20140219git.fc20.x86_64 lldb-0:3.4-6.fc20.i686 lldb-0:3.4-6.fc20.x86_64 llvm-0:3.4-6.fc20.i686 llvm-0:3.4-6.fc20.x86_64 llvm-ocaml-0:3.4-6.fc20.i686 llvm-ocaml-0:3.4-6.fc20.x86_64 mesa-dri-drivers-0:10.1.3-1.20140509.fc20.i686 mesa-dri-drivers-0:10.1.3-1.20140509.fc20.x86_64 mesa-libOpenCL-0:10.1.3-1.20140509.fc20.i686 mesa-libOpenCL-0:10.1.3-1.20140509.fc20.x86_64 mesa-libxatracker-0:10.1.3-1.20140509.fc20.i686 mesa-libxatracker-0:10.1.3-1.20140509.fc20.x86_64 mesa-vdpau-drivers-0:10.1.3-1.20140509.fc20.i686 mesa-vdpau-drivers-0:10.1.3-1.20140509.fc20.x86_64 pocl-0:0.9-4.fc20.1.i686 pocl-0:0.9-4.fc20.1.x86_64 pure-0:0.58-3.fc20.i686 pure-0:0.58-3.fc20.x86_64 python-llvmpy-0:0.12.4-1.fc20.x86_64 python3-llvmpy-0:0.12.4-1.fc20.x86_64
Neal: Yeah, this works on build VMs, but is less practical on your own machine. See bug 1098534.
Temporary bundling exceptions granted for libuv and Rmath. dSFMT is going to be packaged and Julia will use that instead (which may need changes upstream since currently dSFMT does not produce a library). https://fedorahosted.org/fpc/ticket/427#comment:3
Could anybody on 32-bit check whether Julia starts correctly with the following package on F20? What's changed is that it should now run on all i386 CPUs, not only on recent ones (but checking that it works somewhere is a good start ;-). Thanks! http://copr-be.cloud.fedoraproject.org/results/nalimilan/julia/fedora-20-i386/julia-0.3.0-2.fc20/
(In reply to Milan Bouchet-Valat from comment #38) > Could anybody on 32-bit check whether Julia starts correctly with the > following package on F20? What's changed is that it should now run on all > i386 CPUs, not only on recent ones (but checking that it works somewhere is > a good start ;-). Thanks! > > http://copr-be.cloud.fedoraproject.org/results/nalimilan/julia/fedora-20- > i386/julia-0.3.0-2.fc20/ Hi, have you considered building julia for EPEL7 as well? I think it will also require llvm3 package (There is llvm-3.4 in epel6 already). Thanks,
(In reply to Milan Bouchet-Valat from comment #38) > Could anybody on 32-bit check whether Julia starts correctly with the > following package on F20? What's changed is that it should now run on all > i386 CPUs, not only on recent ones (but checking that it works somewhere is > a good start ;-). Thanks! > > http://copr-be.cloud.fedoraproject.org/results/nalimilan/julia/fedora-20- > i386/julia-0.3.0-2.fc20/ 1) In your spec file of julia, line 41, you have %if 0%{fedora} < 20 which gives error when building on epel7, I changed it to %if 0%{?fedora} < 20 2) Due to LLVM being shipped as llvm3.3 package, I changed that line again, to %if 0%{?fedora} < 20 && 0%{?rhel} < 6 3) Line 33 BuildRequires: double-conversion-devel >= 1.1.1 gave build error, changed to BuildRequires: double-conversion-devel >= 2.0.0 4) Required packages built for epel7. What is the policy of adding new packages to epel? Having openlibm, utf8proc, openspecfun, openblas, patchelf there will be very useful. Finally, julia built successfully, you may want to see the results at https://copr.fedoraproject.org/coprs/baurzhanm/julia-epel7/builds/ IMHO, because of RHEL7 (Centos 7) having a long-term support, it serves as a good candidate to have julia too (educational purposes, etc).
Yes, I've considered EPEL, but as a first step I wanted to get the package working for Fedora. But thanks for looking at it, I can make sure the package is clean for EPEL. (In reply to Baurzhan Muftakhidinov from comment #40) > (In reply to Milan Bouchet-Valat from comment #38) > > Could anybody on 32-bit check whether Julia starts correctly with the > > following package on F20? What's changed is that it should now run on all > > i386 CPUs, not only on recent ones (but checking that it works somewhere is > > a good start ;-). Thanks! > > > > http://copr-be.cloud.fedoraproject.org/results/nalimilan/julia/fedora-20- > > i386/julia-0.3.0-2.fc20/ > > 1) In your spec file of julia, line 41, you have > > %if 0%{fedora} < 20 > > which gives error when building on epel7, I changed it to > > %if 0%{?fedora} < 20 Thanks, I fixed that. > 2) Due to LLVM being shipped as llvm3.3 package, I changed that line again, > to > > %if 0%{?fedora} < 20 && 0%{?rhel} < 6 Done. > 3) Line 33 > BuildRequires: double-conversion-devel >= 1.1.1 > > gave build error, changed to > > BuildRequires: double-conversion-devel >= 2.0.0 I don't get this. We only need 1.1.1, and 2.0.0 is clearly greater than 1.1.1, so it should work. > 4) Required packages built for epel7. What is the policy of adding new > packages to epel? Having openlibm, utf8proc, openspecfun, openblas, patchelf > there will be very useful. > > Finally, julia built successfully, you may want to see the results at > https://copr.fedoraproject.org/coprs/baurzhanm/julia-epel7/builds/ Good to know, I've also added these targets to my Copr, waiting for LLVM to finish the build. > IMHO, because of RHEL7 (Centos 7) having a long-term support, it serves as a > good candidate to have julia too (educational purposes, etc). Sure. New package is at: http://nalimilan.perso.neuf.fr/transfert/julia.spec http://nalimilan.perso.neuf.fr/transfert/julia-0.3.0-3.fc20.src.rpm
(In reply to Milan Bouchet-Valat from comment #41) > Yes, I've considered EPEL, but as a first step I wanted to get the package > working for Fedora. But thanks for looking at it, I can make sure the > package is clean for EPEL. > > (In reply to Baurzhan Muftakhidinov from comment #40) > > (In reply to Milan Bouchet-Valat from comment #38) > > > Could anybody on 32-bit check whether Julia starts correctly with the > > > following package on F20? What's changed is that it should now run on all > > > i386 CPUs, not only on recent ones (but checking that it works somewhere is > > > a good start ;-). Thanks! > > > > > > http://copr-be.cloud.fedoraproject.org/results/nalimilan/julia/fedora-20- > > > i386/julia-0.3.0-2.fc20/ > > > > 1) In your spec file of julia, line 41, you have > > > > %if 0%{fedora} < 20 > > > > which gives error when building on epel7, I changed it to > > > > %if 0%{?fedora} < 20 > Thanks, I fixed that. > > > 2) Due to LLVM being shipped as llvm3.3 package, I changed that line again, > > to > > > > %if 0%{?fedora} < 20 && 0%{?rhel} < 6 > Done. Hi, I put rhel version there to ensure that build passes. Otherwise, without second check, %if 0%{?fedora} < 20 was true for rhel7 and build searched for llvm-3.3 and not for llvm33. Correct check should be like %if 0%{?fedora} < 20 AND NOT 0%{?rhel} but I don't know how to write it correctly. Regards, > > 3) Line 33 > > BuildRequires: double-conversion-devel >= 1.1.1 > > > > gave build error, changed to > > > > BuildRequires: double-conversion-devel >= 2.0.0 > I don't get this. We only need 1.1.1, and 2.0.0 is clearly greater than > 1.1.1, so it should work. > > > 4) Required packages built for epel7. What is the policy of adding new > > packages to epel? Having openlibm, utf8proc, openspecfun, openblas, patchelf > > there will be very useful. > > > > Finally, julia built successfully, you may want to see the results at > > https://copr.fedoraproject.org/coprs/baurzhanm/julia-epel7/builds/ > Good to know, I've also added these targets to my Copr, waiting for LLVM to > finish the build. > > > IMHO, because of RHEL7 (Centos 7) having a long-term support, it serves as a > > good candidate to have julia too (educational purposes, etc). > Sure. > > New package is at: > http://nalimilan.perso.neuf.fr/transfert/julia.spec > http://nalimilan.perso.neuf.fr/transfert/julia-0.3.0-3.fc20.src.rpm
(In reply to Baurzhan Muftakhidinov from comment #42) > Hi, > I put rhel version there to ensure that build passes. Otherwise, without > second check, %if 0%{?fedora} < 20 was true for rhel7 and build searched for > llvm-3.3 and not for llvm33. > Correct check should be like > %if 0%{?fedora} < 20 AND NOT 0%{?rhel} but I don't know how to write it > correctly. Yeah, I found it a little weird at first, but actually I think it's OK and the build works for all versions. I think we could get the same result by depending on llvm == 3.3 || llvm3.3. Now it would be good to understand why it doesn't work for EPEL6.
(In reply to Milan Bouchet-Valat from comment #43) > (In reply to Baurzhan Muftakhidinov from comment #42) > > Hi, > > I put rhel version there to ensure that build passes. Otherwise, without > > second check, %if 0%{?fedora} < 20 was true for rhel7 and build searched for > > llvm-3.3 and not for llvm33. > > Correct check should be like > > %if 0%{?fedora} < 20 AND NOT 0%{?rhel} but I don't know how to write it > > correctly. > Yeah, I found it a little weird at first, but actually I think it's OK and > the build works for all versions. I think we could get the same result by > depending on llvm == 3.3 || llvm3.3. > > Now it would be good to understand why it doesn't work for EPEL6. julia depends on fftw > 3.4 which requires gcc > 4.6 to get built. Also pcre is too old in el6, same goes for suitesparse. For epel6 the only way I can think of is to distribute archive with pre-built Julia, like for Windows.
(In reply to Baurzhan Muftakhidinov from comment #44) > (In reply to Milan Bouchet-Valat from comment #43) > > > > Now it would be good to understand why it doesn't work for EPEL6. > > julia depends on fftw > 3.4 which requires gcc > 4.6 to get built. Also pcre > is too old in el6, same goes for suitesparse. Right, I just figured this problem. > For epel6 the only way I can think of is to distribute archive with > pre-built Julia, like for Windows. Maybe it would be easier to build a newer gcc, then fftw, suitesparse and pcre on Copr. Users wouldn't have to install gcc to get the binaries.
(In reply to Milan Bouchet-Valat from comment #45) > (In reply to Baurzhan Muftakhidinov from comment #44) > > (In reply to Milan Bouchet-Valat from comment #43) > > > > > > Now it would be good to understand why it doesn't work for EPEL6. > > > > julia depends on fftw > 3.4 which requires gcc > 4.6 to get built. Also pcre > > is too old in el6, same goes for suitesparse. > Right, I just figured this problem. > > > For epel6 the only way I can think of is to distribute archive with > > pre-built Julia, like for Windows. > Maybe it would be easier to build a newer gcc, then fftw, suitesparse and > pcre on Copr. Users wouldn't have to install gcc to get the binaries. I have tried already, took a gcc from software collections https://copr.fedoraproject.org/coprs/baurzhanm/julia-epel6/monitor/ You can check the logs to see why build of julia failed
(In reply to Milan Bouchet-Valat from comment #45) > (In reply to Baurzhan Muftakhidinov from comment #44) > > (In reply to Milan Bouchet-Valat from comment #43) > > > > > > Now it would be good to understand why it doesn't work for EPEL6. > > > > julia depends on fftw > 3.4 which requires gcc > 4.6 to get built. Also pcre > > is too old in el6, same goes for suitesparse. > Right, I just figured this problem. > > > For epel6 the only way I can think of is to distribute archive with > > pre-built Julia, like for Windows. > Maybe it would be easier to build a newer gcc, then fftw, suitesparse and > pcre on Copr. Users wouldn't have to install gcc to get the binaries. Updating pcre is too painful, for test build I used bundled pcre.
(In reply to Baurzhan Muftakhidinov from comment #46) > I have tried already, took a gcc from software collections > > https://copr.fedoraproject.org/coprs/baurzhanm/julia-epel6/monitor/ > > You can check the logs to see why build of julia failed Looks like an lapack issue. Have you tried building a more recent lapack too? :-) (In reply to Baurzhan Muftakhidinov from comment #47) > Updating pcre is too painful, for test build I used bundled pcre. Out of curiosity, why is it so painful? But you're right that if we need to replace so many packages, we may as well bundle them with Julia -- and do not try to get the package included into EPEL6, but keep it in Copr instead.
OK, I think the package is now ready for the final review. The new version works, though it needs dSFMT (bug 1108765) and llvm3.3 (bug 1109390) to be included. The only bundled libraries are Rmath and libuv, for which exceptions were granted ( https://fedorahosted.org/fpc/ticket/427#comment:3). http://nalimilan.perso.neuf.fr/transfert/julia.spec http://nalimilan.perso.neuf.fr/transfert/julia-0.3.0-4.fc20.src.rpm
Orion, what's your opinion on bug 1109390? Packaging Julia is stuck on this issue and I'd like to know if I need to find something else.
Packages all build in mock and install on a current F20 x86_64 system. The installed version complains: Warning: error initializing module Random: ErrorException("could not load module libdSFMT: libdSFMT: cannot open shared object file: No such file or directory") so you probably need a Requires: dSFMT for the julia package.
(In reply to Robert Knight from comment #51) > Packages all build in mock and install on a current F20 x86_64 system. The > installed version complains: > > Warning: error initializing module Random: > ErrorException("could not load module libdSFMT: libdSFMT: cannot open shared > object file: No such file or directory") > > so you probably need a Requires: dSFMT for the julia package. No. If it's linked correctly, RPM will pick it up during the dependency check. So please check if it's built against dsfmt and linked with it.
dSFMT is not linked to, it's dlopened at runtime by Julia, this is why it's not picked by RPM. Will add it to Requires.
I'm eventually going to use LLVM 3.4 instead of requiring a new llvm3.3 package. Julia developers are willing to support several versions of LLVM, including 3.4 and 3.5. So the package is ready for the final review (at last! ;-). Anyone willing to take it? http://nalimilan.perso.neuf.fr/transfert/julia.spec http://nalimilan.perso.neuf.fr/transfert/julia-0.3.0-1.fc20.src.rpm (Will require dSFMT from Bug 1108765) > rpmlint SPECS/julia.spec > 0 packages and 1 specfiles checked; 0 errors, 0 warnings. > rpmlint RPMS/x86_64/julia-* > julia.x86_64: E: devel-dependency dSFMT-devel As explained above, currently needed, but should be fixed in the future. > julia.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/julia/libjulia-debug.so ['$ORIGIN'] > julia.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/julia/libjulia.so ['$ORIGIN'] This is required because Julia loads its own private library, and it works fine. > julia-debuginfo.x86_64: E: non-standard-dir-perm /usr/src/debug/tmp 01777L No idea about this one, as it's automatically done by debugging symbols extraction... > julia-devel.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/julia/libjulia-debug.so ['$ORIGIN'] Same as above. > julia-devel.x86_64: W: dangling-relative-symlink /usr/share/man/man1/julia-debug.1.gz julia.1.gz The link is not dangling, it points at a file in the julia package. > 4 packages and 0 specfiles checked; 5 errors, 1 warnings.
Anybody willing to do the final review? It's been 10 months since I first opened this request! :-) Now I think it's OK at last.
Have you pointed the fedora-review tool at this ticket yet? -> "fedora-review -b 1040517" After a brief look at the spec file, I think there are a couple of places that would benefit from trying to perform a self-review of your own spec file. It will help you understanding the package more deeply. > %files > %{_libdir}/julia/*.so https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership https://fedoraproject.org/wiki/Packaging:UnownedDirectories > %{_datadir}/julia/base/ Same here. > %config(noreplace) %{_sysconfdir}/julia/juliarc.jl Same here. > %post devel -p /sbin/ldconfig > %postun devel -p /sbin/ldconfig Very doubtful. Typically, ldconfig is only run for _runtime_ library packages, whereas -devel packages only contain symlinks needed at build-time, and that's not ldconfig's area. https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages > %files doc > %docdir %{_datadir}/julia/doc > %{_datadir}/julia/doc Unowned directories here, too. Using %docdir here is not convenient, since you add the contents of a single directory only. %dir %{_datadir}/julia/doc %doc %{_datadir}/julia/doc/* > %files devel > %{_bindir}/julia-debug > %{_libdir}/libjulia.so Please double-check whether this is a runtime library that belongs into the base %name package instead: https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages > %package doc > Summary: Julia documentation and code examples > Group: Development/Languages "Group: Documentation" if you really want to set the Group tag. https://fedoraproject.org/wiki/Packaging:Guidelines#Group_tag > Requires: fftw >= 3.3.2 > Requires: gmp > Requires: lapack > Requires: mpfr > Requires: openblas > Requires: openlibm >= 0.4 > Requires: openspecfun >= 0.4 https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires
(In reply to Michael Schwendt from comment #56) > Have you pointed the fedora-review tool at this ticket yet? -> > "fedora-review -b 1040517" I wish I was able to do it myself, but I'm hitting a bug in fedora-review. I'm only able to run it on prebuilt packages from Koji, and Julia does not build there yet because of dSFMT. Sigh. If you can paste the raw output of fedora-review somewhere, I can fix the warnings. Thanks for doing the manual review! > After a brief look at the spec file, I think there are a couple of places > that would benefit from trying to perform a self-review of your own spec > file. It will help you understanding the package more deeply. > > > > %files > > %{_libdir}/julia/*.so > > https://fedoraproject.org/wiki/Packaging: > Guidelines#File_and_Directory_Ownership > https://fedoraproject.org/wiki/Packaging:UnownedDirectories > > > %{_datadir}/julia/base/ > > Same here. > > > > %config(noreplace) %{_sysconfdir}/julia/juliarc.jl > > Same here. Indeed. Fixed using %dir. > > %post devel -p /sbin/ldconfig > > %postun devel -p /sbin/ldconfig > > Very doubtful. Typically, ldconfig is only run for _runtime_ library > packages, whereas -devel packages only contain symlinks needed at > build-time, and that's not ldconfig's area. > > https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries > https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages This was because there's only /usr/lib/libjulia.so, and no /usr/lib/libjulia.so.X.Y, since this library is currently unstable: therefore I included it in -devel. But it makes more sense to move it to the julia package itself (until it gets versioned). > > %files doc > > %docdir %{_datadir}/julia/doc > > %{_datadir}/julia/doc > > Unowned directories here, too. Using %docdir here is not convenient, since > you add the contents of a single directory only. > > %dir %{_datadir}/julia/doc > %doc %{_datadir}/julia/doc/* Fixed. > > %files devel > > %{_bindir}/julia-debug > > %{_libdir}/libjulia.so > > Please double-check whether this is a runtime library that belongs into the > base %name package instead: > https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages As I said above, moved to the base julia package. > > %package doc > > Summary: Julia documentation and code examples > > Group: Development/Languages > > "Group: Documentation" if you really want to set the Group tag. > https://fedoraproject.org/wiki/Packaging:Guidelines#Group_tag Done. > > Requires: fftw >= 3.3.2 > > Requires: gmp > > Requires: lapack > > Requires: mpfr > > Requires: openblas > > Requires: openlibm >= 0.4 > > Requires: openspecfun >= 0.4 > > https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires There's a comment about this slightly above: # Dependencies loaded at run time by Julia code # and thus not detected by find-requires I've put the new package online: Spec URL: http://nalimilan.perso.neuf.fr/transfert/julia.spec SRPM URL: http://nalimilan.perso.neuf.fr/transfert/julia-0.3.0-2.src.rpm
Hold on, I've found the problem with fedora-review: it was not finding dSFMT-devel, but the error message was really obscure. I'll post the review in a moment.
OK, here's the review, which looks mostly OK to me. A few remarks: - the only Fail is about a dist tag which must be due to my box's setup. - I can fix the Issue about unversioned .so files, but that would mean putting runtime libraries back into -devel (see end of Comment #57). - rpmlint warnings are addressed in Comment #54. - "Note: Directories without known owners: /usr/share/julia" I cannot explain why this appears since I have explicitly added "%dir %{_datadir}/julia/". Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - Development (unversioned) .so files in -devel subpackage, if present. Note: Unversioned so-files directly in %_libdir. See: http://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages ===== MUST items ===== C/C++: [ ]: Package does not contain kernel modules. [ ]: Package contains no static executables. [ ]: Rpath absent or only used for internal libs. Note: See rpmlint output [x]: Header files in -devel subpackage, if present. [x]: Package does not contain any libtool archives (.la) Generic: [ ]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [ ]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "GPL (v2 or later)", "Unknown or generated", "MIT/X11 (BSD like)", "BSD (3 clause)", "GPL (v2 or later) (with incorrect FSF address)", "ISC", "BSD (2 clause)", "LGPL (v2.1 or later)". 134 files have unknown license. Detailed output of licensecheck in /home/milan/Dev/rpmbuild/1040517-julia/licensecheck.txt [ ]: License file installed when any subpackage combination is installed. [ ]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [ ]: Package must own all directories that it creates. Note: Directories without known owners: /usr/share/julia [ ]: %build honors applicable compiler flags or justifies otherwise. [ ]: Package contains no bundled libraries without FPC exception. [ ]: Changelog in prescribed format. [ ]: Sources contain only permissible code or content. [ ]: Package contains desktop file if it is a GUI application. [ ]: Development files must be in a -devel package [ ]: Package uses nothing in %doc for runtime. [ ]: Package consistently uses macros (instead of hard-coded directory names). [ ]: Package is named according to the Package Naming Guidelines. [ ]: Package does not generate any conflict. [ ]: Package obeys FHS, except libexecdir and /usr/target. [ ]: If the package is a rename of another package, proper Obsoletes and Provides are present. [ ]: Requires correct, justified where necessary. [ ]: Spec file is legible and written in American English. [ ]: Package contains systemd file(s) if in need. [ ]: Useful -debuginfo package or justification otherwise. [ ]: Package is not known to require an ExcludeArch tag. [ ]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 81920 bytes in 4 files. [ ]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. [x]: Package requires other packages for directories it uses. [x]: Package does not own files or directories owned by other packages. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package do not use a name that already exist [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local Perl: [ ]: Package contains the mandatory BuildRequires and Requires:. Note: Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) missing? ===== SHOULD items ===== Generic: [!]: Dist tag is present (not strictly required in GL). [ ]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [ ]: Final provides and requires are sane (see attachments). [ ]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in julia-doc [ ]: Package functions as described. [ ]: Latest version is packaged. [ ]: Package does not include license text files separate from upstream. [ ]: Scriptlets must be sane, if used. [ ]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [ ]: %check is present and all tests pass. [ ]: Packages should try to preserve timestamps of original installed files. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Uses parallel make %{?_smp_mflags} macro. [x]: SourceX is a working URL. [x]: Package should compile and build into binary rpms on all supported architectures. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [ ]: Large data in /usr/share should live in a noarch subpackage if package is arched. Note: Arch-ed rpms have a total of 6195200 bytes in /usr/share [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: julia-0.3.0-2.x86_64.rpm julia-doc-0.3.0-2.x86_64.rpm julia-devel-0.3.0-2.x86_64.rpm julia-0.3.0-2.src.rpm julia.x86_64: E: devel-dependency dSFMT-devel julia.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/julia/libjulia.so ['$ORIGIN'] julia-doc.x86_64: W: devel-file-in-non-devel-package /usr/share/julia/examples/embedding.c julia-devel.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/julia/libjulia-debug.so ['$ORIGIN'] julia-devel.x86_64: W: dangling-relative-symlink /usr/share/man/man1/julia-debug.1.gz julia.1.gz 4 packages and 0 specfiles checked; 3 errors, 2 warnings. Rpmlint (installed packages) ---------------------------- # rpmlint julia-devel julia julia-doc julia-devel.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/julia/libjulia-debug.so ['$ORIGIN'] julia-devel.x86_64: W: dangling-relative-symlink /usr/share/man/man1/julia-debug.1.gz julia.1.gz julia.x86_64: E: devel-dependency dSFMT-devel julia.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/julia/libjulia.so ['$ORIGIN'] julia-doc.x86_64: W: devel-file-in-non-devel-package /usr/share/julia/examples/embedding.c 3 packages and 0 specfiles checked; 3 errors, 2 warnings. # echo 'rpmlint-done:' Requires -------- julia-devel (rpmlib, GLIBC filtered): /bin/bash /usr/bin/env julia(x86-64) libLLVM-3.4.so()(64bit) libc.so.6()(64bit) libdl.so.2()(64bit) libffi.so.6()(64bit) libgcc_s.so.1()(64bit) libjulia-debug.so()(64bit) libm.so.6()(64bit) libpthread.so.0()(64bit) librt.so.1()(64bit) libstdc++.so.6()(64bit) libtinfo.so.5()(64bit) libunwind-x86_64.so.8()(64bit) libunwind.so.8()(64bit) libutf8proc.so.0.1()(64bit) libz.so.1()(64bit) perl(strict) perl(warnings) rtld(GNU_HASH) julia (rpmlib, GLIBC filtered): /sbin/ldconfig arpack config(julia) dSFMT dSFMT-devel fftw gmp lapack libLLVM-3.4.so()(64bit) libamd.so.2()(64bit) libc.so.6()(64bit) libcamd.so.2()(64bit) libcholmod.so.2()(64bit) libcolamd.so.2()(64bit) libdl.so.2()(64bit) libdouble-conversion.so.1()(64bit) libffi.so.6()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libjulia.so()(64bit) libm.so.6()(64bit) libpthread.so.0()(64bit) librt.so.1()(64bit) libspqr.so.1()(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libtinfo.so.5()(64bit) libumfpack.so.5()(64bit) libunwind-x86_64.so.8()(64bit) libunwind.so.8()(64bit) libutf8proc.so.0.1()(64bit) libz.so.1()(64bit) mpfr openblas openlibm openlibm-devel openspecfun openspecfun-devel pcre rtld(GNU_HASH) julia-doc (rpmlib, GLIBC filtered): Provides -------- julia-devel: julia-devel julia-devel(x86-64) libjulia-debug.so()(64bit) julia: bundled(Rmath) bundled(libuv) config(julia) julia julia(x86-64) libRmath-julia.so()(64bit) libgrisu.so()(64bit) libjulia.so()(64bit) libsuitesparse_wrapper.so()(64bit) julia-doc: julia-doc julia-doc(x86-64) Unversioned so-files -------------------- julia: /usr/lib64/julia/libRmath-julia.so julia: /usr/lib64/julia/libgrisu.so julia: /usr/lib64/julia/libjulia.so julia: /usr/lib64/julia/libsuitesparse_wrapper.so julia: /usr/lib64/julia/sys.so julia: /usr/lib64/libjulia.so Source checksums ---------------- https://github.com/JuliaLang/Rmath/archive/e432b0c4b01c560353412b3f097d179eef5c0ba2/archive/Rmath.tar.gz#/Rmath-e432b0c4b01c560353412b3f097d179eef5c0ba2.tar.gz : CHECKSUM(SHA256) this package : d06d9b8a532c77280ec7d89ee63f42b98565659bc34ec0250d6d3dedfdcf58ba CHECKSUM(SHA256) upstream package : d06d9b8a532c77280ec7d89ee63f42b98565659bc34ec0250d6d3dedfdcf58ba https://github.com/JuliaLang/julia/archive/v0.3.0.tar.gz#/julia-0.3.0.tar.gz : CHECKSUM(SHA256) this package : 1e9778129231aeff4e5f6100b0b71d2dbc4306cfc92cf533e527907d4a7a9aa1 CHECKSUM(SHA256) upstream package : 1e9778129231aeff4e5f6100b0b71d2dbc4306cfc92cf533e527907d4a7a9aa1 https://github.com/JuliaLang/libuv/archive/5d608abc3c2e9dc37da04030a0e07ba0af5ae57d/archive/libuv.tar.gz#/libuv-5d608abc3c2e9dc37da04030a0e07ba0af5ae57d.tar.gz : CHECKSUM(SHA256) this package : 7ffc341ccaf95199305d3d4deb14b42a311dde53aa3257877f5613a9f332ec51 CHECKSUM(SHA256) upstream package : 7ffc341ccaf95199305d3d4deb14b42a311dde53aa3257877f5613a9f332ec51 Generated by fedora-review 0.5.2 (63c24cb) last change: 2014-07-14 Command line :/usr/bin/fedora-review -b 1040517 -L mock-rpms/ Buildroot used: fedora-20-x86_64 Active plugins: Generic, Shell-api, C/C++, Perl Disabled plugins: Java, Python, fonts, SugarActivity, Ocaml, Haskell, R, PHP, Ruby Disabled flags: EXARCH, EPEL5, BATCH, DISTTAG Built with local dependencies: /home/milan/Dev/rpmbuild/mock-rpms/dSFMT-2.2.3-4.fc20.x86_64.rpm /home/milan/Dev/rpmbuild/mock-rpms/dSFMT-debuginfo-2.2.3-4.fc20.x86_64.rpm /home/milan/Dev/rpmbuild/mock-rpms/dSFMT-devel-2.2.3-4.fc20.x86_64.rpm /home/milan/Dev/rpmbuild/mock-rpms/dSFMT-devel-doc-2.2.3-4.fc20.x86_64.rpm /home/milan/Dev/rpmbuild/mock-rpms/openlibm-0.3-5.fc20.x86_64.rpm /home/milan/Dev/rpmbuild/mock-rpms/openlibm-debuginfo-0.3-5.fc20.x86_64.rpm /home/milan/Dev/rpmbuild/mock-rpms/openlibm-devel-0.3-5.fc20.x86_64.rpm /home/milan/Dev/rpmbuild/mock-rpms/openspecfun-0.4-1.fc20.x86_64.rpm /home/milan/Dev/rpmbuild/mock-rpms/openspecfun-devel-0.4-1.fc20.x86_64.rpm
Would anybody finish the review? :-p
This pseudo-patch appears to be required at least for rawhide. +sed -i 's/-xnolibs//' deps/libuv/Makefile.in + %build
Thanks! I think I did not see the failure because I've not run the updates for a few weeks on my F20 box. IIUC this option was removed in systemtap 2.5. I've filed a bug against libuv, and added the line you suggested in the meantime. New package is here: Spec URL: http://nalimilan.perso.neuf.fr/transfert/julia.spec SRPM URL: http://nalimilan.perso.neuf.fr/transfert/julia-0.3.0-3.src.rpm
I did a normal rpmbuild and installed it, and a fedora-review from generated srpm with my initial proposed patch, to ensure it was building. Some considerations: 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 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: $ (cd /usr/share/julia/test/; julia runtests.jl) From worker 4: * linalg3 From worker 3: * linalg2 From worker 5: * linalg4 From worker 2: * linalg1 From worker 4: * core From worker 4: * keywordargs From worker 4: * numbers From worker 5: * strings From worker 5: * collections From worker 5: * hashing From worker 5: * remote From worker 5: * iobuffer From worker 4: * arrayops From worker 5: * reduce From worker 5: * reducedim From worker 2: * simdloop From worker 5: * blas From worker 2: * fft From worker 2: * dsp From worker 4: * sparse From worker 5: * bitarray From worker 2: * random From worker 3: * math From worker 2: * functional From worker 2: * bigint From worker 2: * sorting From worker 3: * statistics From worker 2: * spawn From worker 4: * backtrace exception on From worker 2: [stdio passthrough ok] 4: ERROR: test failed: have_backtrace while loading backtrace.jl, in expression starting on line 12 ERROR: test failed: have_backtrace while loading backtrace.jl, in expression starting on line 12 while loading /usr/share/julia/test/runtests.jl, in expression starting on line 35 WARNING: Forcibly interrupting busy workers error in running finalizer: InterruptException() WARNING: Unable to terminate all workers exception on 4: signal (11): Segmentation fault signal (11): Segmentation fault run_finalizer at /home/pcpa/rpmbuild/BUILD/julia-0.3.0/src/gc.c:288 run_finalizers at /home/pcpa/rpmbuild/BUILD/julia-0.3.0/src/gc.c:318 uv_atexit_hook at /home/pcpa/rpmbuild/BUILD/julia-0.3.0/src/init.c:447 jl_exit at /home/pcpa/rpmbuild/BUILD/julia-0.3.0/src/jl_uv.c:687 unknown function (ip: 88535058) uv_write2 at /home/pcpa/rpmbuild/BUILD/julia-0.3.0/deps/libuv/src/unix/stream.c:1282 jl_write_no_copy at /home/pcpa/rpmbuild/BUILD/julia-0.3.0/src/jl_uv.c:577 write at ./stream.jl:732 print at ./ascii.jl:93 print at /usr/bin/../lib64/julia/sys.so (unknown line) jl_apply at /home/pcpa/rpmbuild/BUILD/julia-0.3.0/src/gf.c:1431 unknown function (ip: -968871807) jl_apply at /home/pcpa/rpmbuild/BUILD/julia-0.3.0/src/gf.c:1429 unknown function (ip: -745434435) unknown function (ip: -745435035) unknown function (ip: -745434873) jl_apply at /home/pcpa/rpmbuild/BUILD/julia-0.3.0/src/gf.c:1431 unknown function (ip: -968961883) start_task at /home/pcpa/rpmbuild/BUILD/julia-0.3.0/src/task.c:427 switch_stack at /home/pcpa/rpmbuild/BUILD/julia-0.3.0/src/task.c:207 switch_stack at /home/pcpa/rpmbuild/BUILD/julia-0.3.0/src/task.c:207 julia_trampoline at /home/pcpa/rpmbuild/BUILD/julia-0.3.0/src/init.c:1006 unknown function (ip: 4199757) __libc_start_main at /usr/bin/../lib64/libc.so.6 (unknown line) unknown function (ip: 4199811) unknown function (ip: 0) 3) Can it be changed to install documentation in %_docdir? All documentation is under /usr/share/julia 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: doc$ make Please use 'make <target>' where <target> is one of helpdb.jl to make the REPL help db html to make standalone HTML files dirhtml to make HTML files named index.html in directories singlehtml to make a single large HTML file pickle to make pickle files json to make JSON files htmlhelp to make HTML files and a HTML help project qthelp to make HTML files and a qthelp project devhelp to make HTML files and a Devhelp project epub to make an epub latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter latexpdf to make LaTeX files and run them through pdflatex text to make text files man to make manual pages texinfo to make Texinfo files info to make Texinfo files and run them through makeinfo gettext to make PO message catalogs changes to make an overview of all changed/added/deprecated items linkcheck to check all external links for integrity doctest to run all doctests embedded in the documentation (if enabled) doc$ make html make: *** No rule to make target 'juliadoc/juliadoc/__init__.py', needed by 'juliadoc-pkg'. Stop. If I try to "hack" it, I see this: doc$ mkdir juliadoc/juliadoc/ doc$ touch juliadoc/juliadoc/__init__.py doc$ make html fatal: Not a git repository (or any parent up to mount point /home) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). Makefile:52: recipe for target 'juliadoc-pkg' failed make: [juliadoc-pkg] Error 128 (ignored) PYTHONPATH=:juliadoc sphinx-build -b html -d _build/doctrees . _build/html Making output directory... Running Sphinx v1.2.2 Exception occurred: File "conf.py", line 24, in <module> import sphinx_rtd_theme ImportError: No module named sphinx_rtd_theme The full traceback has been saved in /tmp/sphinx-err-7Yhijm.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at <https://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks! Makefile:55: recipe for target 'html' failed make: *** [html] Error 1 doc$ sudo dnf install python-sphinx_rtd_theme [[[[[ install it ]]]]] doc$ make html fatal: Not a git repository (or any parent up to mount point /home) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). Makefile:52: recipe for target 'juliadoc-pkg' failed make: [juliadoc-pkg] Error 128 (ignored) PYTHONPATH=:juliadoc sphinx-build -b html -d _build/doctrees . _build/html Running Sphinx v1.2.2 Exception occurred: File "conf.py", line 119, in <module> html_theme_path = [juliadoc.get_theme_dir(), AttributeError: 'module' object has no attribute 'get_theme_dir' The full traceback has been saved in /tmp/sphinx-err-0WJmJs.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at <https://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks! Makefile:55: recipe for target 'html' failed make: *** [html] Error 1 So, I believe just the hack to create juliadoc/juliadoc/__init__.py is not enough. 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.
(In reply to Paulo Andrade from comment #63) > I did a normal rpmbuild and installed it, and a fedora-review > from generated srpm with my initial proposed patch, to ensure > it was building. > Some considerations: > > 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. > 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 > 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. > 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? New version: Spec URL: http://nalimilan.perso.neuf.fr/transfert/julia.spec SRPM URL: http://nalimilan.perso.neuf.fr/transfert/julia-0.3.0-4.src.rpm
> > 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 > > 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. BTW, you could change: %files doc %dir %{_docdir}/julia/ %doc %{_docdir}/julia/* to %files doc %doc %{_docdir}/julia/ > > 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. > > 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. 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. 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. 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.
> %files doc > %doc %{_docdir}/julia/ Even shorter: %files doc %{_docdir}/julia/ That's because %_docdir is in default %__docdir_path list.
(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 probably saw I posted to devel@ earlier today about issues with rpath/runpath. I was waiting for some comment on that before replying, but none so far... > > > > 1) I believe none of the installed Makefile files are required > > > > (or functional): [...] > So let's keep installing the perf suite for now, only removing Makefiles. > > > > 2) Is it really required to install /usr/share/julia/test ? [...] > Ah, I've added a series of %exclude for -doc. > > > > 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 I asked it because I know it should be easy, and would greatly increase the quality of the package, and/or, it could detect problems in the documentation itself. While waiting for upstream, please make a simple patch to get html documentation built. You will make the reviewer a lot happier :) > > > > 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)? AFAIK what should work is to check what "rpm -q --requires dSFMT-devel" outputs and add that, but it would change from arch to arch, and is an ugly and fragile hack, e.g. on x86_64: Requires: libdSFMT.so.2.2()(64bit) Anyway, in case it may be helpful, this is how I avoid rpmlint warnings on dangling symlinks in sagemath: http://pkgs.fedoraproject.org/cgit/sagemath.git/tree/sagemath.spec#n1102 you could write something like this in %post: ln -sf /usr/lib64/libdSFMT.so.2 /usr/lib64/julia/libdSFMT.so > > 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.
(In reply to Paulo Andrade from comment #68) > You probably saw I posted to devel@ earlier today about issues > with rpath/runpath. I was waiting for some comment on that > before replying, but none so far... You're probably aware of this, but there are two points in the rpmlint wiki page: http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath The second one, "Rpath for Internal Libraries", seems to apply to us. [...] > > 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 > > I asked it because I know it should be easy, and would greatly increase > the quality of the package, and/or, it could detect problems in the > documentation itself. While waiting for upstream, please make a > simple patch to get html documentation built. You will make the > reviewer a lot happier :) OK, done. :-) [..] > > > 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. Actually, I'm starting to think I should stop installing libjulia.so to /usr/lib64, as this is not done by default by Julia, and there's the SOVERSION issue. So for now I've removed it, and we'll see if something like iJulia needs it later. [...] > AFAIK what should work is to check what "rpm -q --requires dSFMT-devel" > outputs and add that, but it would change from arch to arch, and is an > ugly and fragile hack, e.g. on x86_64: > > Requires: libdSFMT.so.2.2()(64bit) Ah, it's unfortunate. That would have been the best solution to handle dlopen()ed dependencies in the long term. > Anyway, in case it may be helpful, this is how I avoid rpmlint > warnings on dangling symlinks in sagemath: > http://pkgs.fedoraproject.org/cgit/sagemath.git/tree/sagemath.spec#n1102 > you could write something like this in %post: > ln -sf /usr/lib64/libdSFMT.so.2 /usr/lib64/julia/libdSFMT.so OK, done. But now rpmlint grants me with a julia.x86_64: W: dangerous-command-in-%post ln julia.x86_64: W: dangerous-command-in-%postun rm New version: Spec URL: http://nalimilan.perso.neuf.fr/transfert/julia.spec SRPM URL: http://nalimilan.perso.neuf.fr/transfert/julia-0.3.0-5.src.rpm
(In reply to Milan Bouchet-Valat from comment #69) > (In reply to Paulo Andrade from comment #68) > > You probably saw I posted to devel@ earlier today about issues > > with rpath/runpath. I was waiting for some comment on that > > before replying, but none so far... > You're probably aware of this, but there are two points in the rpmlint wiki > page: > http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath > > The second one, "Rpath for Internal Libraries", seems to apply to us. In the (recent) past rpmbuild would fail in these cases. I have packages were I added a wrapper setting LD_LIBRARY_PATH, or if the library is not "truly" private, install /etc/ld.so.conf.d/$name-$arch.conf Currently it is apparently only causing a rpmlint error. But unless with more feedback, I will *not* consider it mandatory to remove rpath to get the package approved, because it pass build and there are a lot of binaries in rawhide, several with a bogus one, rpath/runpath. > [...] > > > 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 > > > > I asked it because I know it should be easy, and would greatly increase > > the quality of the package, and/or, it could detect problems in the > > documentation itself. While waiting for upstream, please make a > > simple patch to get html documentation built. You will make the > > reviewer a lot happier :) > OK, done. :-) At first I only suggest this pseudo patch to the spec: -rm -R %{buildroot}%{_docdir}/julia/html/_sources Because there is that "big" "View page source" on every documentation page, that just leads to a page like this: " File not found Firefox can't find the file at /usr/share/doc/julia/html/_sources/index.txt. Check the file name for capitalization or other typing errors. Check to see if the file was moved, renamed or deleted. " > [..] > > > > 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. > Actually, I'm starting to think I should stop installing libjulia.so to > /usr/lib64, as this is not done by default by Julia, and there's the > SOVERSION issue. So for now I've removed it, and we'll see if something like > iJulia needs it later. > > [...] > > AFAIK what should work is to check what "rpm -q --requires dSFMT-devel" > > outputs and add that, but it would change from arch to arch, and is an > > ugly and fragile hack, e.g. on x86_64: > > > > Requires: libdSFMT.so.2.2()(64bit) > Ah, it's unfortunate. That would have been the best solution to handle > dlopen()ed dependencies in the long term. > > > Anyway, in case it may be helpful, this is how I avoid rpmlint > > warnings on dangling symlinks in sagemath: > > http://pkgs.fedoraproject.org/cgit/sagemath.git/tree/sagemath.spec#n1102 > > you could write something like this in %post: > > ln -sf /usr/lib64/libdSFMT.so.2 /usr/lib64/julia/libdSFMT.so > OK, done. But now rpmlint grants me with a > julia.x86_64: W: dangerous-command-in-%post ln > julia.x86_64: W: dangerous-command-in-%postun rm I believe these can be ignored, as the end effect of not needing to install -devel packages should be better. But, can you provide a simple test case to exercise the julia interface to dlopen those? Just to make sure it works with only /usr/lib64/julia/libdSFMT.so that is, will not fail if /usr/lib64/libdSFMT.so is not available (as well as the other links). > New version: > Spec URL: http://nalimilan.perso.neuf.fr/transfert/julia.spec > SRPM URL: http://nalimilan.perso.neuf.fr/transfert/julia-0.3.0-5.src.rpm
(In reply to Paulo Andrade from comment #70) > At first I only suggest this pseudo patch to the spec: > > -rm -R %{buildroot}%{_docdir}/julia/html/_sources > > Because there is that "big" "View page source" on every documentation > page, that just leads to a page like this: > " > File not found > > Firefox can't find the file at /usr/share/doc/julia/html/_sources/index.txt. > > Check the file name for capitalization or other typing errors. > Check to see if the file was moved, renamed or deleted. > " Good catch. I'll fix that. > > OK, done. But now rpmlint grants me with a > > julia.x86_64: W: dangerous-command-in-%post ln > > julia.x86_64: W: dangerous-command-in-%postun rm > > I believe these can be ignored, as the end effect of not needing > to install -devel packages should be better. But, can you provide a > simple test case to exercise the julia interface to dlopen those? > Just to make sure it works with only > /usr/lib64/julia/libdSFMT.so that is, will not fail if > /usr/lib64/libdSFMT.so is not available (as well as the other > links). The test suite already checks that AFAIK. But then I guess it's run when dSFMT-devel is still installed, as it's the build environment. What exactly do you have in mind?
(In reply to Milan Bouchet-Valat from comment #71) > (In reply to Paulo Andrade from comment #70) > > At first I only suggest this pseudo patch to the spec: > > > > -rm -R %{buildroot}%{_docdir}/julia/html/_sources > > > > Because there is that "big" "View page source" on every documentation > > page, that just leads to a page like this: > > " > > File not found > > > > Firefox can't find the file at /usr/share/doc/julia/html/_sources/index.txt. > > > > Check the file name for capitalization or other typing errors. > > Check to see if the file was moved, renamed or deleted. > > " > Good catch. I'll fix that. > > > > OK, done. But now rpmlint grants me with a > > > julia.x86_64: W: dangerous-command-in-%post ln > > > julia.x86_64: W: dangerous-command-in-%postun rm > > > > I believe these can be ignored, as the end effect of not needing > > to install -devel packages should be better. But, can you provide a > > simple test case to exercise the julia interface to dlopen those? > > Just to make sure it works with only > > /usr/lib64/julia/libdSFMT.so that is, will not fail if > > /usr/lib64/libdSFMT.so is not available (as well as the other > > links). > The test suite already checks that AFAIK. But then I guess it's run when > dSFMT-devel is still installed, as it's the build environment. What exactly > do you have in mind? I was thinking about some script to test it, after install, and only be used during package review. But I tested it the "hard" way anyway; I checked that the only one julia does not output some error/warning message at startup is if there is a missing %_libdir/julia/libopenspecfun.so so, it apparently always dlopen libdSFMT.so and libopenlibm.so and either does not dlopen or does not print anything if libopenspecfun.so is missing at startup. Another minor cosmetic issue is that you are using %_datarootdir but has one use of %_datadir; for consistency could change the later to %_datarootdir in %files. Otherwise, I believe it is almost done now :)
(In reply to Paulo Andrade from comment #72) > (In reply to Milan Bouchet-Valat from comment #71) > > The test suite already checks that AFAIK. But then I guess it's run when > > dSFMT-devel is still installed, as it's the build environment. What exactly > > do you have in mind? > > I was thinking about some script to test it, after install, and only > be used during package review. But I tested it the "hard" way anyway; > I checked that the only one julia does not output some error/warning > message at startup is if there is a missing > %_libdir/julia/libopenspecfun.so so, it apparently always dlopen > libdSFMT.so and libopenlibm.so and either does not dlopen or does not > print anything if libopenspecfun.so is missing at startup. Yeah, openspecfun is only loaded when calling specific functions, for example: airy(1, 1+1im). > Another minor cosmetic issue is that you are using %_datarootdir but > has one use of %_datadir; for consistency could change the later > to %_datarootdir in %files. Ah, yes, I've changed a few occurrences yesterday but there was one left. > Otherwise, I believe it is almost done now :) Cool! New version: Spec URL: http://nalimilan.perso.neuf.fr/transfert/julia.spec SRPM URL: http://nalimilan.perso.neuf.fr/transfert/julia-0.3.0-6.src.rpm Something really weird is going on with the new package: /usr/share/doc/julia/ files are included twice, once in julia and once in julia-doc. How is it possible?
(In reply to Milan Bouchet-Valat from comment #73) > (In reply to Paulo Andrade from comment #72) > > (In reply to Milan Bouchet-Valat from comment #71) > > > The test suite already checks that AFAIK. But then I guess it's run when > > > dSFMT-devel is still installed, as it's the build environment. What exactly > > > do you have in mind? > > > > I was thinking about some script to test it, after install, and only > > be used during package review. But I tested it the "hard" way anyway; > > I checked that the only one julia does not output some error/warning > > message at startup is if there is a missing > > %_libdir/julia/libopenspecfun.so so, it apparently always dlopen > > libdSFMT.so and libopenlibm.so and either does not dlopen or does not > > print anything if libopenspecfun.so is missing at startup. > Yeah, openspecfun is only loaded when calling specific functions, for > example: airy(1, 1+1im). > > > Another minor cosmetic issue is that you are using %_datarootdir but > > has one use of %_datadir; for consistency could change the later > > to %_datarootdir in %files. > Ah, yes, I've changed a few occurrences yesterday but there was one left. > > > Otherwise, I believe it is almost done now :) > Cool! > > > New version: > Spec URL: http://nalimilan.perso.neuf.fr/transfert/julia.spec > SRPM URL: http://nalimilan.perso.neuf.fr/transfert/julia-0.3.0-6.src.rpm > > Something really weird is going on with the new package: > /usr/share/doc/julia/ files are included twice, once in julia and once in > julia-doc. How is it possible? Good observation, now on my todo list whenever checking a package :) Try this: ---%<--- $ diff -u SPECS/julia.spec{.orig,} --- SPECS/julia.spec.orig 2014-09-18 11:42:14.503828453 -0300 +++ SPECS/julia.spec 2014-09-18 11:41:31.790826817 -0300 @@ -175,6 +175,8 @@ mv %{buildroot}%{_datarootdir}/julia/doc %{buildroot}%{_docdir}/julia/ mv %{buildroot}%{_datarootdir}/julia/examples %{buildroot}%{_docdir}/julia/ +cp -p CONTRIBUTING.md LICENSE.md NEWS.md README.md %{buildroot}%{_docdir}/julia + # Install HTML manual and remove unwanted files # https://github.com/JuliaLang/julia/issues/8378 mv %{_builddir}/%{name}-%{version}/doc/_build/html/ %{buildroot}%{_docdir}/julia/html/ @@ -183,17 +185,20 @@ cd %{buildroot}%{_docdir}/julia rm -R devdocs/ images/ juliadoc/ man/ manual/ stdlib/ _build/ _templates/ # helpdb.jl is duplicated at %{_datarootdir}/julia/helpdb.jl -rm conf.py DocCheck.jl helpdb.jl index.rst latex.rst NEWS-update.jl requirements.txt README.md +rm conf.py DocCheck.jl helpdb.jl index.rst latex.rst NEWS-update.jl requirements.txt cd %{buildroot}%{_prefix}/share/man/man1/ ln -s julia.1.gz julia-debug.1.gz %files -%doc CONTRIBUTING.md LICENSE.md NEWS.md README.md +%dir %{_docdir}/julia/ +%{_docdir}/julia/LICENSE.md +%doc %{_docdir}/julia/CONTRIBUTING.md +%doc %{_docdir}/julia/NEWS.md +%doc %{_docdir}/julia/README.md %{_bindir}/julia %{_libdir}/julia/ %exclude %{_libdir}/julia/libjulia-debug.so - %{_mandir}/man1/julia.1* %files common @@ -207,11 +212,8 @@ %config(noreplace) %{_sysconfdir}/julia/juliarc.jl %files doc -%doc %{_docdir}/julia/ -%exclude %{_docdir}/julia/CONTRIBUTING.md -%exclude %{_docdir}/julia/LICENSE.md -%exclude %{_docdir}/julia/NEWS.md -%exclude %{_docdir}/julia/README.md +%doc %{_docdir}/julia/examples +%doc %{_docdir}/julia/html %files devel %{_bindir}/julia-debug ---%<--- I personally rarely, if ever use "%doc NAME", to avoid surprises with whatever rpm does behind the curtains, and also to make it easier to make experimental partial builds. BTW, the install logic is really hard to follow, I strongly suggest ensuring that "rpmbuild --short-circuit -bi" works. It is better for you (the packager), but others may benefit if looking at your package. I mean, use (cd dir; commands) or pushd dir commands popd to make it easier to know what is the current directory, if necessary to add extra commands; usually one expects current directory to be the builddir. Avoid mv from builddir to buildroot, it just completely breaks --short-circuit -bi
(In reply to Paulo Andrade from comment #74) > Good observation, now on my todo list whenever checking a package :) > Try this: [...] > > I personally rarely, if ever use "%doc NAME", to avoid surprises > with whatever rpm does behind the curtains, and also to make it > easier to make experimental partial builds. Thanks. Indeed the %doc directive feels pretty broken, it doesn't make any sense to include some files twice, especially since I only asked to include a few files, not any directory... > BTW, the install logic is really hard to follow, I strongly suggest > ensuring that "rpmbuild --short-circuit -bi" works. It is better for > you (the packager), but others may benefit if looking at your package. > I mean, use > (cd dir; commands) > or > pushd dir > commands > popd > to make it easier to know what is the current directory, if > necessary to add extra commands; usually one expects current > directory to be the builddir. > Avoid mv from builddir to buildroot, it just completely breaks > --short-circuit -bi Good idea. Looks like short-circuit works now. New version: Spec URL: http://nalimilan.perso.neuf.fr/transfert/julia.spec SRPM URL: http://nalimilan.perso.neuf.fr/transfert/julia-0.3.0-7.src.rpm
Please remove the installed /usr/share/doc/julia/html/objects.inv file. This would also removed some rpmlint warnings: julia-doc.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/julia/html/objects.inv julia-doc.noarch: W: file-not-utf8 /usr/share/doc/julia/html/objects.inv I also suggest adding these build requires: BuildRequires: desktop-file-utils BuildRequires: ImageMagick This to somewhere, as appropriate in %install: mkdir -p %{buildroot}%{_datadir}/pixmaps convert -scale 32x32 doc/juliadoc/juliadoc/theme/julia/static/julia-logo.svg \ julia-logo.png %{buildroot}%{_datadir}/pixmaps/%{name}.png mkdir -p %{buildroot}%{_datadir}/applications cat > %{buildroot}%{_datadir}/applications/%{name}.desktop << EOF [Desktop Entry] Name=Julia Comment=High-level, high-performance dynamic language for technical computing Exec=julia Icon=%{name} Terminal=true Type=Application Categories=Science;Math; EOF desktop-file-validate %{buildroot}%{_datadir}/applications/%{name}.desktop and append this to the main %files: %{_datadir}/pixmaps/%{name}.png %{_datadir}/applications/%{name}.desktop You obviously may customize it, and also, the suggestion for the .desktop file is untested.
I consider the package approved. Just remember to remove the /usr/share/doc/julia/html/objects.inv files. The suggestion about the .desktop file is optional, but could help in making your package "more visible".
Great! Thank you Paulo, and all the people who helped me finish this Julia package, and by the way learn RPM packaging. :-) I've now removed objects.inv and added the .desktop file (I needed to install icons to /usr/share/icons/ and to ship the SVG too to get a good-looking icon in GNOME Shell). A final question: would it be a good idea to make -common and -doc depend on the base package, so that you remove all of them at the same time and don't get version discrepancies? That would prevent installing the docs without the program. New Package SCM Request ======================= Package Name: julia Short Description: High-level, high-performance dynamic language for technical computing Upstream URL: http://julialang.org/ Owners: nalimilan Branches: f19 f20 f21 epel7 InitialCC:
Git done (by process-git-requests).
(In reply to Milan Bouchet-Valat from comment #78) > Great! Thank you Paulo, and all the people who helped me finish this Julia > package, and by the way learn RPM packaging. :-) You're welcome :) > I've now removed objects.inv and added the .desktop file (I needed to > install icons to /usr/share/icons/ and to ship the SVG too to get a > good-looking icon in GNOME Shell). Ok. You can actually suggest upstream to provide a .desktop and icons for menus, but the scalable SVG should be better for most modern desktops. > A final question: would it be a good idea to make -common and -doc depend on > the base package, so that you remove all of them at the same time and don't > get version discrepancies? That would prevent installing the docs without Yes it should. Actually I did check that, but only verified that the -doc package was requiring the base one and did not fool proof check the others, so I did not notice that the -common was missing the requires.
(In reply to Paulo Andrade from comment #80) > (In reply to Milan Bouchet-Valat from comment #78) > > Great! Thank you Paulo, and all the people who helped me finish this Julia > > package, and by the way learn RPM packaging. :-) > > You're welcome :) > > > I've now removed objects.inv and added the .desktop file (I needed to > > install icons to /usr/share/icons/ and to ship the SVG too to get a > > good-looking icon in GNOME Shell). > > Ok. You can actually suggest upstream to provide a .desktop > and icons for menus, but the scalable SVG should be better for > most modern desktops. Sure, will do. > > A final question: would it be a good idea to make -common and -doc depend on > > the base package, so that you remove all of them at the same time and don't > > get version discrepancies? That would prevent installing the docs without > > Yes it should. Actually I did check that, but only verified > that the -doc package was requiring the base one and did not > fool proof check the others, so I did not notice that the > -common was missing the requires. OK, I'll fix that. Looks like Julia 0.3.1 is planned for tomorrow, so I may as well wait for it before sending the package to updates.
julia-0.3.1-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/julia-0.3.1-1.fc21
julia-0.3.1-1.fc21 has been pushed to the Fedora 21 testing repository.
julia-0.3.1-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/julia-0.3.1-2.fc21
julia-0.3.1-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/julia-0.3.1-2.fc20
julia-0.3.1-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
julia-0.3.1-2.fc20 has been pushed to the Fedora 20 stable repository.