Bug 1040517

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.