Feedback from making a RPM package

[Milan Bouchet-Valat]

Hi!

I've started making a RPM package of Julia 0.2.0 for Fedora (and
possibly others). I took great inspiration and patches from the Debian
package. Overall, it looks like I'm getting closer to the goal, but the
process was not very easy (contrary to the build from git using
downloaded libraries, which works very well). ;-)

So I figured I should report on the issues I faced to help improve
things.

* At the moment, it's not very easy to build Julia without using git at
all. Debian carries a patch [1] against the Makefiles to work around
this, which is not very clean. It would be nice to ensure that when
using a tarball, everything works fine. Two places in particular require
git:
- Showing the version, which could easily be disabled if not in a git
repository (i.e. for official releases, store the information in a file
somewhere and that's it - see the Debian patch).
- Handling dependencies as submodules. I think it would greatly help if
the Makefiles allowed providing these dependencies as tarballs or
uncompressed directories: if the tarball is already present, git and
downloads would not be used. This is much nicer for integrating with
package build systems.


* I've not been able to understand what is the version of libuv used in
the submodule. It apparently follows the 0.10 branch, but from a look at
the history these branches do not match. The 0.10.19 version I have on
Fedora 19 does not have the same API as the one used by Julia
(specifically, uv_cwd() does not have the same return type). Of coure
that's OK if Julia needs the unstable version, but I'd like to be sure I
understand the situation. I don't think distributions would be OK with
including a private copy of libuv in Julia packages.


* I think 'make install' should accept a DESTDIR argument [2] so that
files can be installed temporarily to any directory, disregarding
PREFIX. This is the preferred solution used by package build systems,
since they need files to be copied to a place which is different from
the ultimate destination of the files. For example, libuv already does
this.

Likewise, files going to SYSCONFDIR should be copied to DESTDIR if
specified, while currently Debian has a patch to Makefiles because
specifying SYSCONFDIR=/etc means the files are installed there directly.


* 'make' and 'make install' create a 'lib' directory even with 64-bit
builds. This means we have to rename it by hand to lib64 in that case.


* I would be interested in knowing what UNTRUSTED_SYSTEM_LIBM=1 and
USE_LLVM_SHLIB=1 imply, or when they should be used. A few words of
explanation somewhere (in DISTRIBUTIONS.jl?) could help. Also, the fact
that USE_SYSTEM_OPENLIBM=1 does not mean that openlibm source is not
needed, since openlibm-extras is still required, would deserve a word --
or maybe I haven't understood the problem correctly.


* Now the bikeshedding: should I call the package 'julia' or
'julia-base'? The latter would mean that in the future, a 'julia'
package would also install recommended Julia packages like DataArrays,
Winston, etc. Does that sound like a good idea?


I think that's all for now. Thanks for your attention! I'm not saying
everything should be fixed immediately, nor that all of these are real
bugs, but at least here's my feedback before I forget about it.


Regards


1: http://ftp.de.debian.org/debian/pool/main/j/julia/julia_0.2.0
+dfsg-5.debian.tar.gz, see debian/patches/no-git.patch
2: http://www.gnu.org/prep/standards/html_node/DESTDIR.html

[John Myles White]

+1 for DESTDIR.

FWIW, I’d call this package julia and a package with Julia libraries julia-extras.

— John

[Patrick O'Leary]

On Saturday, December 7, 2013 10:28:38 AM UTC-6, Milan Bouchet-Valat wrote:

* I've not been able to understand what is the version of libuv used in
the submodule. It apparently follows the 0.10 branch, but from a look at
the history these branches do not match. The 0.10.19 version I have on
Fedora 19 does not have the same API as the one used by Julia
(specifically, uv_cwd() does not have the same return type). Of coure
that's OK if Julia needs the unstable version, but I'd like to be sure I
understand the situation. I don't think distributions would be OK with
including a private copy of libuv in Julia packages.

Julia uses a patched libuv which contains things not in Joyent's upstream. The end goal is for upstream libuv to support everything we need, but that's not where things stand now.

[Viral Shah]

We do want to make it easy for distro package maintainers to easily build debs/rpms. Could you file an issue? We went through one round of simplifications when we did the debian package, and it sure is time for a second round now. Ideally, we would love for distro maintainers not neededing to maintain patches at all.

DESTDIR is a good idea, and I have been wanting to do it for a while, but there hasn't been a good reason so far.

USE_LLVM_SHLIB is to link against LLVM dynamically. This did not work well in the past, but seems to work well with the current LLVM releases. We probably want to make this the default in the next julia release.

I would advise to go with openlibm, as it receives a stream of bugfixes. openlibm-extras has nothing to do with openlibm, nor has a dependency on it. This includes amos and a few routines from the Faddeeva library. These could all be separate, and perhaps that is the way to go forward.

Like Patrick already said, we use a patched libuv, and those patches are not part of the upstream libuv. Thus, the julia libuv needs to be included in the package.

-viral

[Elliot Saba]

Hello Milan, I'm glad you're taking this up!  More packages would be awesome.

1. Building without `git` is supported (our Ubuntu binaries are built on canonical's buildd servers, which don't have `git` installed, or even the `.git` directory available) but you have to do a little bit extra work.  The way our ubuntu nightly packaging scripts get around this is to save the submodules into our source package.  The git submodules are mostly julia-specific codes; openlibm, libuv, and Rmath.  All three of these projects are either maintained by the Julia team (openlibm) or modified so heavily that standard distributions won't work at all with Julia (libuv, Rmath).  Here is a relevant excerpt from my "packaging scripts" repository.  That repository also contains a patch to get versioning information into Julia without git, which might work a little differently from the one in the official debian package.  You can see where it is applied here.

Note that I perform all this patching and such BEFORE uploading the source to canonical's servers for building.  If you don't want to deal with all this patching and workarounds and such, and just want a "git-free snapshot" of the latest source, you can use bazaar to [pull from canonical's servers](https://code.launchpad.net/~staticfloat/julianightlies/trunk), or I could push it to github nightly where you can pull it from git/download a tarball.  I suppose we could also embed this information into tagged git releases, if that would help.  (So official versions wouldn't need `git` either).  If that is desirable, please open an issue and tag me.

2. Git submodules don't follow branches, they just point to a specific commit (which could be included in multiple branches in any given repository) which you can see via `git submodule status`:

$ git submodule status

 004e056e4562a8e8459b3d283f7de2f655f99a8b deps/Rmath (remotes/origin/HEAD)
 0bae1555437bcb1af2df9d3f320837a2a79f6e6d deps/libuv (node-v0.7.6-1113-g0bae155)
 ec41733ce80d52f0ca2a2d9c6bd6b41690a418a8 deps/openlibm (remotes/origin/HEAD)
 9bfbd7684be14936091e7d2f0a92fcc51996cef7 doc/juliadoc (remotes/origin/HEAD)

Of course, that doesn't help you much in what you want to know.  The libuv branch we do development on is the julia-uv0.10.13 branch, although that is subject to change as we develop libuv more.  It's better to pull down the specific commit pointed to in the julia.git repository, then rely on branch names.

3. I don't believe we use the value of PREFIX anywhere at runtime on Linux, so no matter the value of PREFIX we should be completely relocatable, as long as relative path structure is maintained.  In that case, I'm not sure why you would need DESTDIR instead of PREFIX.  The only exception I can think of is that SYSCONFDIR is an absolute path, but even then we have relative-path based defaults that will kick in if the absolute path doesn't pan out.

If I'm wrong, again, please open an issue and ping me.

4. In the same way that we support multiarch library paths, you can override JL_LIBDIR and JL_PRIVATE_LIBDIR to whatever you want.  You should be able to move them around to anything you desire.

5. UNTRUSTED_SYSTEM_LIBM is only used on windows, because we don't trust the windows math libraries. This flag gets set so the build system knows to link against openlibm instead.  Here's the motivating issue, and the fix that was instated. I found this using github's blame feature; sometimes you have to go back a few steps, but you can see who committed what lines in a file, which is fantastic.

USE_LLVM_SHLIB is our attempt to link against LLVM as a shared library instead of statically linking it into `libjulia`.  This is a rather fine distinction, but the reason we've typically done it statically is because you cannot mix and match versions of LLVM, even "minor" versions.  (E.g. Julia built against LLVM 3.3 will not work with a LLVM 3.2 shared library)

6. I'm not sure what your issues with openlibm-extras is.  Could you try explaining it again?

7. I think John Myles White's suggestion of `julia` and `julia-extras` is a good idea, but it is ultimately your choice as porter!

If you have any further questions, please ask!  I'd love to have more people packaging Julia, and it's in all of our best interests to make it as easy as possible.

-E

[Milan Bouchet-Valat]

Le dimanche 08 décembre 2013 à 12:57 +0800, Elliot Saba a écrit :
> Hello Milan, I'm glad you're taking this up! More packages would be
> awesome.

Thank you all for the replies. There's much to say about many different
points, so I'm going to reply to a few things and file separate issues
for further debate.

> 1. Building without `git` is supported (our Ubuntu binaries are built
> on canonical's buildd servers, which don't have `git` installed, or
> even the `.git` directory available) but you have to do a little bit
> extra work. The way our ubuntu nightly packaging scripts get around
> this is to save the submodules into our source package. The git
> submodules are mostly julia-specific codes; openlibm, libuv, and
> Rmath. All three of these projects are either maintained by the Julia
> team (openlibm) or modified so heavily that standard distributions
> won't work at all with Julia (libuv, Rmath). Here is a relevant
> excerpt from my "packaging scripts" repository. That repository also
> contains a patch to get versioning information into Julia without git,
> which might work a little differently from the one in the official
> debian package. You can see where it is applied here.
>
>
> Note that I perform all this patching and such BEFORE uploading the
> source to canonical's servers for building. If you don't want to deal
> with all this patching and workarounds and such, and just want a
> "git-free snapshot" of the latest source, you can use bazaar to [pull
> from canonical's
> servers](https://code.launchpad.net/~staticfloat/julianightlies/trunk), or I could push it to github nightly where you can pull it from git/download a tarball. I suppose we could also embed this information into tagged git releases, if that would help. (So official versions wouldn't need `git` either). If that is desirable, please open an issue and tag me.

Sure, with patches adapted from Debian (which are the same as yours
IIUC) I got everything working, but as Viral said it would be great to
have this working without patches. They make packaging more much painful
an error-prone when new releases come out.

> 2. Git submodules don't follow branches, they just point to a specific
> commit (which could be included in multiple branches in any given
> repository) which you can see via `git submodule status`:
>
>
> $ git submodule status
> 004e056e4562a8e8459b3d283f7de2f655f99a8b deps/Rmath
> (remotes/origin/HEAD)
> 0bae1555437bcb1af2df9d3f320837a2a79f6e6d deps/libuv
> (node-v0.7.6-1113-g0bae155)
> ec41733ce80d52f0ca2a2d9c6bd6b41690a418a8 deps/openlibm
> (remotes/origin/HEAD)
> 9bfbd7684be14936091e7d2f0a92fcc51996cef7 doc/juliadoc
> (remotes/origin/HEAD)
>
>
> Of course, that doesn't help you much in what you want to know. The
> libuv branch we do development on is the julia-uv0.10.13 branch,
> although that is subject to change as we develop libuv more. It's
> better to pull down the specific commit pointed to in the julia.git
> repository, then rely on branch names.

Yeah, that's what I do. I was misled by Github which said when you click
on the submodule that it's 0 commits behind/ahead of the official 0.10
branch. So no I understand how it works.

> 3. I don't believe we use the value of PREFIX anywhere at runtime on
> Linux, so no matter the value of PREFIX we should be completely
> relocatable, as long as relative path structure is maintained. In
> that case, I'm not sure why you would need DESTDIR instead of PREFIX.
> The only exception I can think of is that SYSCONFDIR is an absolute
> path, but even then we have relative-path based defaults that will
> kick in if the absolute path doesn't pan out.
>
> If I'm wrong, again, please open an issue and ping me.

Nice to hear. But see the Debian patch for why it is needed for
SYSCONFDIR. I've filed this issue:
https://github.com/JuliaLang/julia/issues/5063

> 4. In the same way that we support multiarch library paths, you can
> override JL_LIBDIR and JL_PRIVATE_LIBDIR to whatever you want. You
> should be able to move them around to anything you desire.

I'd like to avoid messing with details: PREFIX and DESTDIR should be
enough to keep things simple.

> 5. UNTRUSTED_SYSTEM_LIBM is only used on windows, because we don't
> trust the windows math libraries. This flag gets set so the build
> system knows to link against openlibm instead. Here's the motivating
> issue, and the fix that was instated. I found this using github's
> blame feature; sometimes you have to go back a few steps, but you can
> see who committed what lines in a file, which is fantastic.
>
>
> USE_LLVM_SHLIB is our attempt to link against LLVM as a shared library
> instead of statically linking it into `libjulia`. This is a rather
> fine distinction, but the reason we've typically done it statically is
> because you cannot mix and match versions of LLVM, even "minor"
> versions. (E.g. Julia built against LLVM 3.3 will not work with a
> LLVM 3.2 shared library)

Thanks, I see. Copying this in the docs could be useful.

> 6. I'm not sure what your issues with openlibm-extras is. Could you
> try explaining it again?

It's just that the distinction between openlibm and openlibm-extras is
not that clear (even after Viral's explanations ;-). The tarball in
deps/ is called openlibm, does it provide openlibm, openlibm-extras, or
both? When setting USE_SYSTEM_OPENLIBM=1, can I use the system version
for both (at the moment openlibm is not packaged for Fedora anyway).

I had a similar confusion with grisu/double-conversion. One has to read
the Makefiles to understand they double-conversion provides grisu.

> 7. I think John Myles White's suggestion of `julia` and `julia-extras`
> is a good idea, but it is ultimately your choice as porter!

I'd better keep naming consistent between distributions, and I have no
strong feelings about it. I just need to check whether in Fedora (as in
Debian IIRC) one can easily get soft dependencies (Recommends/Suggests)
be installed by default, so that if I call the package julia,
julia-extras is installed too. Else it might be confusing for users, and
most of the time you also want the recommended packages.

> If you have any further questions, please ask! I'd love to have more
> people packaging Julia, and it's in all of our best interests to make
> it as easy as possible.

Be sure I will!


Regards

[Iain Dunning]

so that if I call the package julia, 
julia-extras is installed too. Else it might be confusing for users, and 
most of the time you also want the recommended packages. 

Surely its the opposite: you would want to manually install julia-extras, that is, installing julia by default comes with no packages.

In general, given we have an in-built package manager, it doesn't seem wise to use the OS package manager - this isn't really encouraged anymore for other languages, is it?

[John Myles White]

This is actually a hornet’s nest of a topic. Some of us think using the OS package manager to manage per-language packages is uniformly bad; some of us think _not_ using the OS package manager is uniformly bad.

— John

[Stefan Karpinski]

If I recall correctly, that was Steven Johnson making the argument to support the system package manager, which I was resistant to but conceded. I don't think that he was actually for using the system package manager for installing Julia packages, but rather for supporting it.

[Viral Shah]

The OS provided packages often lag and have many issues. Sometimes they are really convenient, once packages are a bit mature and the latest stuff is not required.

This could work if we incorporate a package stabilization period as part of the julia release process.

-viral

[John Myles White]

Ok. I misremembered that debate.

— John

[Milan Bouchet-Valat]

Le dimanche 08 décembre 2013 à 16:53 -0800, Iain Dunning a écrit :

so that if I call the package julia, 
julia-extras is installed too. Else it might be confusing for users, and 
most of the time you also want the recommended packages. 

Surely its the opposite: you would want to manually install julia-extras, that is, installing julia by default comes with no packages.

Then people would install julia-base rather. A few more kilobytes of Julia packages can't really hurt, and if you're using Julia you're very likely to need a few standard packages. But there's the second argument:

In general, given we have an in-built package manager, it doesn't seem wise to use the OS package manager - this isn't really encouraged anymore for other languages, is it?

Indeed, this has to be considered carefully. One advantage of using system packages is that dependencies would be handled correctly. But if  BinDeps.jl integrates with the system package manager, maybe that's not needed. There can still be a problem if you remove system dependencies of a Julia package after installing it (this could happen because of a conflict) - but of course you can reinstall the package and it will install its dependencies again.
So probably I'll call the package julia and wait for the dust to settle.

Regards

[Ivar Nesje]

I like the idea of a clean "julia-base" package, and a default "julia" package that include some of the most used Julia packages with dependencies. 

Ivar

[Milan Bouchet-Valat]

Le dimanche 08 décembre 2013 à 15:58 +0100, Milan Bouchet-Valat a
écrit :

> > 6. I'm not sure what your issues with openlibm-extras is. Could you
> > try explaining it again?
> It's just that the distinction between openlibm and openlibm-extras is
> not that clear (even after Viral's explanations ;-). The tarball in
> deps/ is called openlibm, does it provide openlibm, openlibm-extras, or
> both? When setting USE_SYSTEM_OPENLIBM=1, can I use the system version
> for both (at the moment openlibm is not packaged for Fedora anyway).

Raising this issue again: I think I now understand that openlibm
provides a replacement for libm, plus more functions, which are included
in openlibm-extras. Passing USE_SYSTEM_LIBM=1 means that only the
openlibm-extras part is used. But what's the advantage of using openlibm
rather than the system-provided libm? Performance? Rounding precision?

Related to that, is it planned to make a release of openlibm? This was
requested by Eliot some time ago [1]. If I am to propose a Fedora
package for it, it would be more credible if it was a true release.


Regards


1: https://github.com/JuliaLang/openlibm/issues/21

[Stefan Karpinski]

Consistency. Different platform libms have radically different behaviors. Some return values that are fully correct, some are correct to within an ulp, and some just give it a solid effort and then call it a day, and of course it various from function to function and version to version of the system. Openlibm is consistent across platforms while being quite fast. I fully agree that we should make an official release.

[Milan Bouchet-Valat]

Le mardi 10 décembre 2013 à 17:35 -0500, Stefan Karpinski a écrit :
> Consistency. Different platform libms have radically different
> behaviors. Some return values that are fully correct, some are correct
> to within an ulp, and some just give it a solid effort and then call
> it a day, and of course it various from function to function and
> version to version of the system. Openlibm is consistent across
> platforms while being quite fast. I fully agree that we should make an
> official release.

Thanks for the details. I'm going to package it too then. But I've seen
openlibm does not build on non-x86, and Debian sets USE_SYSTEM_LIBM=1 on
other platforms because of this: I'm perfectly OK with doing the same
(and using the reference BLAS instead of openblas), except that I don't
understand what will provide openlibm-extras in that case.

Regards

[Viral Shah]

We should just split the openlibm-extras out into separate repos - amos and Faddeeva.

On most 64-bit linux distros nowadays, the system provided libm tends to be ok. It is usually the older libm on 32-bit linux distros where I have seen the issues that Stefan mentions. OS X seems to have a high quality libm, whereas we have seen issues on Windows.

-viral

[Elliot Saba]

That line disabling openlibm on non-x86 architectures is just because Sebastien was trying to compile Julia on ARM.  We actually cannot (yet) compile Julia on anything other than x86 architectures.  (Note that the actual test is for 32 OR 64-bit x86 architectures, we're not making a distinction between 32 and 64 bit here).

-E

[Milan Bouchet-Valat]

Le mercredi 11 décembre 2013 à 14:19 +0800, Elliot Saba a écrit :
> That line disabling openlibm on non-x86 architectures is just because
> Sebastien was trying to compile Julia on ARM. We actually cannot
> (yet) compile Julia on anything other than x86 architectures. (Note
> that the actual test is for 32 OR 64-bit x86 architectures, we're not
> making a distinction between 32 and 64 bit here).

OK, that's what I suspected. So no need to worry about this currently.


Regards

[Milan Bouchet-Valat]

Le mercredi 11 décembre 2013 à 08:30 +0530, Viral Shah a écrit :
> We should just split the openlibm-extras out into separate repos -
> amos and Faddeeva.

If that's the plan, then I'll wait before packaging it.

> On most 64-bit linux distros nowadays, the system provided libm tends
> to be ok. It is usually the older libm on 32-bit linux distros where I
> have seen the issues that Stefan mentions. OS X seems to have a high
> quality libm, whereas we have seen issues on Windows.

So, for Fedora, would you advise setting USE_SYSTEM_OPENLIBM=1 or not?
Should I special-case the 32-bit version?


Regards

[Viral Shah]

On 11-Dec-2013, at 3:16 pm, Milan Bouchet-Valat <nali...@club.fr> wrote:

> Le mercredi 11 décembre 2013 à 08:30 +0530, Viral Shah a écrit :
>> We should just split the openlibm-extras out into separate repos -
>> amos and Faddeeva.
> If that's the plan, then I'll wait before packaging it.

Yes, we will do this soon. Would be great if you can open an issue.

>> On most 64-bit linux distros nowadays, the system provided libm tends
>> to be ok. It is usually the older libm on 32-bit linux distros where I
>> have seen the issues that Stefan mentions. OS X seems to have a high
>> quality libm, whereas we have seen issues on Windows.
> So, for Fedora, would you advise setting USE_SYSTEM_OPENLIBM=1 or not?
> Should I special-case the 32-bit version?

For now, my suggestion would be to bundle the openlibm library as part of the julia installation, rather than have a separate package.

-viral

[Milan Bouchet-Valat]

Le mercredi 11 décembre 2013 à 15:57 +0530, Viral Shah a écrit :
> On 11-Dec-2013, at 3:16 pm, Milan Bouchet-Valat <nali...@club.fr> wrote:
>
> > Le mercredi 11 décembre 2013 à 08:30 +0530, Viral Shah a écrit :
> >> We should just split the openlibm-extras out into separate repos -
> >> amos and Faddeeva.
> > If that's the plan, then I'll wait before packaging it.
>
> Yes, we will do this soon. Would be great if you can open an issue.

Done at https://github.com/JuliaLang/openlibm/issues/32

> >> On most 64-bit linux distros nowadays, the system provided libm tends
> >> to be ok. It is usually the older libm on 32-bit linux distros where I
> >> have seen the issues that Stefan mentions. OS X seems to have a high
> >> quality libm, whereas we have seen issues on Windows.
> > So, for Fedora, would you advise setting USE_SYSTEM_OPENLIBM=1 or not?
> > Should I special-case the 32-bit version?
>
> For now, my suggestion would be to bundle the openlibm library as part
> of the julia installation, rather than have a separate package.

Yeah, that's how it works at the moment.


Regards

[Steven G. Johnson]

On Tuesday, December 10, 2013 10:00:54 PM UTC-5, Viral Shah wrote:

We should just split the openlibm-extras out into separate repos - amos and Faddeeva.

As a user, I'd prefer just an openspecfun library (or some other name, but "openlibm-extras" is a ugly) with lots of special functions, rather than installing a separate library for each type of special function.    This will also be easier for Julia packaging.

[Viral Shah]

That’s a good idea. I’ll call it openspecfun.

-viral

[Stefan Karpinski]

openlibspecfun?

[Milan Bouchet-Valat]

For those who are interested in testing or using it, the RPM package of
Julia 0.2.0 for Fedora 19 and 20 can be found here:
http://nalimilan.perso.neuf.fr/transfert/

julia is only a meta-package depending on the three others; the most
interesting parts are in julia-base. You will need to enable the
updates-testing repository or to install the double-conversion package
manually.

The package seems to work fine, but any feedback is appreciated. It is
under review here:
https://bugzilla.redhat.com/show_bug.cgi?id=1040517

We will need to wait for openlibm to be split and packaged before Julia
is accepted in Fedora.


Regards

[Viral Shah]

I have now created openspecfun, and as some of you may have already seen it - it is part of the build process. openlibm now only has the libm functions, and that is nice too.

We'll wait for this to settle over the next couple of days, and then I will tag 0.1 releases for both openlibm and openspecfun.

-viral

[Viral Shah]

I was looking through this. It is really great to have package for Fedora. I am intimately familiar with debian, but not as much with the fedora packaging system. Looking through the spec file, I had a few comments:

1. openlibm has multiple licenses - MIT license is just for some of the new code. I have updated the license file accordingly.

2. Are you using libRmath-static that is provided by Fedora? We use a patched Rmath, so that it uses the same RNG underneath as the rest of julia, and a better normal random number generator. It would be best to use the julia libRmath. Perhaps we need to change the name of our library to avoid conflicts with the libRmath that ships with R.

3. Would 32-bit versions of julia also get built as part of this?

-viral

On Sunday, December 22, 2013 1:28:42 AM UTC+5:30, Milan Bouchet-Valat wrote:

[Milan Bouchet-Valat]

Le mardi 24 décembre 2013 à 19:31 -0800, Viral Shah a écrit :
> I was looking through this. It is really great to have package for
> Fedora. I am intimately familiar with debian, but not as much with the
> fedora packaging system. Looking through the spec file, I had a few
> comments:
>
> 1. openlibm has multiple licenses - MIT license is just for some of
> the new code. I have updated the license file accordingly.

Thanks, I'll have a look. I see you have updated LICENSE.md, which will
greatly help.

> 2. Are you using libRmath-static that is provided by Fedora? We use a
> patched Rmath, so that it uses the same RNG underneath as the rest of
> julia, and a better normal random number generator. It would be best
> to use the julia libRmath. Perhaps we need to change the name of our
> library to avoid conflicts with the libRmath that ships with R.

Oh, since there was a USE_SYSTEM_RMATH variable I thought it was safe to
use the standard Rmath library. If you plan to diverge from it in the
long term, it would be better to rename it, and either release it
separately or consider it as a fully internal part of Julia. If you
think nobody is going to use it from another program soon, so maybe an
internal library is fine; another separate package could be a little
overkill.

A word in README and DISTRIBUTING would be nice, many people will likely
get it wrong (or make the library fully internal and remove the
environment variable).

> 3. Would 32-bit versions of julia also get built as part of this?

Yes, it builds fine on i686 right now. I didn't provide the link to the
binaries because I don't have a 32-but machine off-hand, and until
double-conversion enters Fedora updates, I cannot build Julia on Fedora
build servers (Koji).


Regards