[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Susi Lehtola  changed:

   What|Removed |Added

 Blocks|505154 (FE-SCITECH) |




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=505154
[Bug 505154] Tracker: Review Requests for Science and Technology related
packages
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list -- package-review@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517
Bug 1040517 depends on bug 1109390, which changed state.

Bug 1109390 Summary: Review Request: llvm33 - Versioned LLVM
https://bugzilla.redhat.com/show_bug.cgi?id=1109390

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA



-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517
Bug 1040517 depends on bug 1109390, which changed state.

Bug 1109390 Summary: Review Request: llvm3.3 - Versioned LLVM
https://bugzilla.redhat.com/show_bug.cgi?id=1109390

   What|Removed |Added

 Status|CLOSED  |NEW
 Resolution|NOTABUG |---



-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Fedora Update System upda...@fedoraproject.org changed:

   What|Removed |Added

   Fixed In Version|julia-0.3.1-2.fc21  |julia-0.3.1-2.fc20



--- Comment #87 from Fedora Update System upda...@fedoraproject.org ---
julia-0.3.1-2.fc20 has been pushed to the Fedora 20 stable repository.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Fedora Update System upda...@fedoraproject.org changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||julia-0.3.1-2.fc21
 Resolution|--- |ERRATA
Last Closed||2014-10-03 00:04:23



--- Comment #86 from Fedora Update System upda...@fedoraproject.org ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #85 from Fedora Update System upda...@fedoraproject.org ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #84 from Fedora Update System upda...@fedoraproject.org ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #82 from Fedora Update System upda...@fedoraproject.org ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517
Bug 1040517 depends on bug 1108765, which changed state.

Bug 1108765 Summary: Review Request: dSFMT - Double precision SIMD-oriented 
Fast Mersenne Twister
https://bugzilla.redhat.com/show_bug.cgi?id=1108765

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA



-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Milan Bouchet-Valat nalimi...@club.fr changed:

   What|Removed |Added

  Flags||fedora-cvs?



--- Comment #78 from Milan Bouchet-Valat nalimi...@club.fr ---
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:

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Jon Ciesla limburg...@gmail.com changed:

   What|Removed |Added

  Flags|fedora-cvs? |fedora-cvs+



-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #79 from Jon Ciesla limburg...@gmail.com ---
Git done (by process-git-requests).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #80 from Paulo Andrade paulo.cesar.pereira.de.andr...@gmail.com 
---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #81 from Milan Bouchet-Valat nalimi...@club.fr ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #73 from Milan Bouchet-Valat nalimi...@club.fr ---
(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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #74 from Paulo Andrade paulo.cesar.pereira.de.andr...@gmail.com 
---
(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.spec2014-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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Paulo Andrade paulo.cesar.pereira.de.andr...@gmail.com changed:

   What|Removed |Added

  Flags||fedora-review?



--- Comment #76 from Paulo Andrade paulo.cesar.pereira.de.andr...@gmail.com 
---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #69 from Milan Bouchet-Valat nalimi...@club.fr ---
(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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #70 from Paulo Andrade paulo.cesar.pereira.de.andr...@gmail.com 
---
(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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #71 from Milan Bouchet-Valat nalimi...@club.fr ---
(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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #72 from Paulo Andrade paulo.cesar.pereira.de.andr...@gmail.com 
---
(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 :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #66 from Michael Schwendt bugs.mich...@gmx.net ---
 %files doc
 %doc %{_docdir}/julia/

Even shorter:

  %files doc
  %{_docdir}/julia/

That's because %_docdir is in default %__docdir_path list.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #67 from Milan Bouchet-Valat nalimi...@club.fr ---
(In reply to Paulo Andrade from comment #65)
   1) I believe none of the installed Makefile files are required
   (or functional):
   $ find /usr/share/julia/ -name Makefile
   /usr/share/julia/test/perf/micro/Makefile
   /usr/share/julia/test/perf/shootout/Makefile
   /usr/share/julia/test/perf/Makefile
   /usr/share/julia/test/Makefile
   /usr/share/julia/examples/Makefile
  Right, these only work from inside the source tree anyway. I've even removed
  the perf suite, which does not work when installed, and contains a few files
  with non-MIT licenses.
 
 %check now fails like this:
 exception on 1: ERROR: opening file perf/kernel/imdb-1.tsv: No such file or
 directory
  in open at ./iostream.jl:117
  in open at ./iostream.jl:135
 while loading readdlm.jl, in expression starting on line 4
 ERROR: opening file perf/kernel/imdb-1.tsv: No such file or directory
  in open at ./iostream.jl:117
  in open at ./iostream.jl:135
 while loading readdlm.jl, in expression starting on line 4
 while loading /home/pcpa/rpmbuild/BUILD/julia-0.3.0/test/runtests.jl, in
 expression starting on line 35
 
 Makefile:16: recipe for target 'readdlm' failed
 make: *** [readdlm] Error 1
Woops! I got tired of running the checks again and again so I disable them. I
guess I should have run them at least once...

So let's keep installing the perf suite for now, only removing Makefiles.

   2) Is it really required to install /usr/share/julia/test ?
   I checked it, and apparently must call the runtests.jl, I
   did not change the environment, but apparently not everything
   was fine:
  [...]
  Yeah, currently the backtrace test is failing with LLVM 3.4
  (https://github.com/JuliaLang/julia/issues/8099). I think it's still better
  to ship this file, hopefully this will get fixed soon enough. (FWIW, this
  file can be called by Base.runtests().)
  
   3) Can it be changed to install documentation in %_docdir?
   All documentation is under /usr/share/julia
  Yes, I've filed a bug upstream, and for now I move the files manually:
  https://github.com/JuliaLang/julia/issues/8367
 
 Looks almost good :) Just that now there are two packages
 owning LICENSE.md and other UPPERCASE files.
Ah, I've added a series of %exclude for -doc.

 BTW, you could change:
 %files doc
 %dir %{_docdir}/julia/
 %doc %{_docdir}/julia/*
 
 to
 %files doc
 %doc %{_docdir}/julia/
Fixed. Michael: I prefer keeping the explicit %doc because I won't remember it
happens automatically. :-)

   4) I believe there is something wrong with the documentation. It
   should install processed documentation. I try to build it
   manually, by switching to the doc subdir I see this:
  [...]
   So, I believe just the hack to create juliadoc/juliadoc/__init__.py is not
   enough.
  Yes, I've filed this in the same upstream issue. I'd say for now let's
  install the .rst files, which are readable if not pretty, and wait for
  upstream to make it possible to install HTML files properly.
 
 I believe it can be fixed in the current rpm, probably a patch actually
 creating an usable juliadoc/juliadoc/__init__.py or whatever is
 missing from the tarball.
Yes, copying these files from Julia git seems to work, but then I need to carry
the patch and move files around by hand. Is it really worth it? I'd prefer
fixing this upstream directly, I've filed an issue:
https://github.com/JuliaLang/julia/issues/8378

   5) It has been commented before, but it really would be better to
   have a versioned .so under %_libdir; subdirectories usually are
   modules, and, usually are ok.
  The problem is, Julia has not yet committed to API stability, so there's no
  versioning upstream, and if I invented one I would need to change the
  SOVERSION for every new release. I'm not sure it's worth it. What do you
  think?
 
 It would be better to not make the libjulia.so symlink to start with.
I don't think so, as GUIs embedding Julia, like iJulia, may need to link to it.
I realize this may be an argument in favor of adding a SOVERSION. I guess I
should ask upstream about that.

 Then, remove the rpath from binary(ies) and add to the package
 an /etc/ld.so.conf/julia-%{_arch}.conf that on x86_64 would have
 /usr/lib64/julia
 as contents.
 Not the most beautiful way (better to patch build), but using
 chrpath -d after build should be ok to remove the rpath.
Actually the RPATH points to /usr/bin/../lib64/julia/, so I could remove the
symlink without problems for Julia itself.

 I believe, to remove another rpmlint E: you could instead of
 Requires: dSFMT-devel
 have a dangling link, e.g.:
 /usr/lib64/julia/lib.dSFMT.so - /usr/lib64/libdSFMT.so.2
 or create it in %post (and remove in %postun) to avoid rpmlint
 warnings. This way it wold also break on purpose if there is
 a major bump of dSFMT.
Probably, but it sounds a bit hack (and I have to do the same for openlibm and
openspecfun). Isn't there 

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #68 from Paulo Andrade paulo.cesar.pereira.de.andr...@gmail.com 
---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Paulo Andrade paulo.cesar.pereira.de.andr...@gmail.com changed:

   What|Removed |Added

 CC||paulo.cesar.pereira.de.andr
   ||a...@gmail.com
   Assignee|nob...@fedoraproject.org|paulo.cesar.pereira.de.andr
   ||a...@gmail.com



--- Comment #61 from Paulo Andrade paulo.cesar.pereira.de.andr...@gmail.com 
---
This pseudo-patch appears to be required at least for rawhide.

+sed -i 's/-xnolibs//' deps/libuv/Makefile.in
+
 %build

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #62 from Milan Bouchet-Valat nalimi...@club.fr ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Paulo Andrade paulo.cesar.pereira.de.andr...@gmail.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #63 from Paulo Andrade paulo.cesar.pereira.de.andr...@gmail.com 
---
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 onFrom 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
  dirhtmlto 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
  devhelpto make HTML files and a Devhelp project
  epub   to make an epub
  latex  to make LaTeX files, you can set PAPER=a4 or 

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #64 from Milan Bouchet-Valat nalimi...@club.fr ---
(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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #65 from Paulo Andrade paulo.cesar.pereira.de.andr...@gmail.com 
---
  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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #60 from Milan Bouchet-Valat nalimi...@club.fr ---
Would anybody finish the review? :-p

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #55 from Milan Bouchet-Valat nalimi...@club.fr ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #56 from Michael Schwendt bugs.mich...@gmx.net ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #57 from Milan Bouchet-Valat nalimi...@club.fr ---
(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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #58 from Milan Bouchet-Valat nalimi...@club.fr ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #59 from Milan Bouchet-Valat nalimi...@club.fr ---
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

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Milan Bouchet-Valat nalimi...@club.fr changed:

   What|Removed |Added

 Blocks||505154 (FE-SCITECH)




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=505154
[Bug 505154] Tracker: Review Requests for Science and Technology related
packages
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517
Bug 1040517 depends on bug 1109390, which changed state.

Bug 1109390 Summary: Review Request: llvm3.3 - Versioned LLVM
https://bugzilla.redhat.com/show_bug.cgi?id=1109390

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NOTABUG



-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #54 from Milan Bouchet-Valat nalimi...@club.fr ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #53 from Milan Bouchet-Valat nalimi...@club.fr ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Robert Knight kni...@princeton.edu changed:

   What|Removed |Added

 CC||kni...@princeton.edu



--- Comment #51 from Robert Knight kni...@princeton.edu ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Christopher Meng i...@cicku.me changed:

   What|Removed |Added

 CC||i...@cicku.me



--- Comment #52 from Christopher Meng i...@cicku.me ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #50 from Milan Bouchet-Valat nalimi...@club.fr ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #49 from Milan Bouchet-Valat nalimi...@club.fr ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #45 from Milan Bouchet-Valat nalimi...@club.fr ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #46 from Baurzhan Muftakhidinov baurthefi...@gmail.com ---
(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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #47 from Baurzhan Muftakhidinov baurthefi...@gmail.com ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #48 from Milan Bouchet-Valat nalimi...@club.fr ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #44 from Baurzhan Muftakhidinov baurthefi...@gmail.com ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #43 from Milan Bouchet-Valat nalimi...@club.fr ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Milan Bouchet-Valat nalimi...@club.fr changed:

   What|Removed |Added

 Depends On||1109390




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1109390
[Bug 1109390] Review Request: llvm3.3 - Versioned LLVM
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517
Bug 1040517 depends on bug 1098534, which changed state.

Bug 1098534 Summary: Package relying on a specific LLVM version
https://bugzilla.redhat.com/show_bug.cgi?id=1098534

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NOTABUG



-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #40 from Baurzhan Muftakhidinov baurthefi...@gmail.com ---
(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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Milan Bouchet-Valat nalimi...@club.fr changed:

   What|Removed |Added

 Depends On||1108765




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1108765
[Bug 1108765] Review Request: dSFMT - Double precision SIMD-oriented Fast
Mersenne Twister
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #41 from Milan Bouchet-Valat nalimi...@club.fr ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #42 from Baurzhan Muftakhidinov baurthefi...@gmail.com ---
(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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #39 from Baurzhan Muftakhidinov baurthefi...@gmail.com ---
(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,

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517
Bug 1040517 depends on bug 1058019, which changed state.

Bug 1058019 Summary: Review Request: utf8proc - Library for processing UTF-8 
encoded Unicode strings
https://bugzilla.redhat.com/show_bug.cgi?id=1058019

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA



-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #38 from Milan Bouchet-Valat nalimi...@club.fr ---
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/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517
Bug 1040517 depends on bug 1089500, which changed state.

Bug 1089500 Summary: Review Request: openlibm - High quality system 
independent, open source libm
https://bugzilla.redhat.com/show_bug.cgi?id=1089500

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA



-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #37 from Milan Bouchet-Valat nalimi...@club.fr ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #35 from Neal Becker ndbeck...@gmail.com ---
(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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Milan Bouchet-Valat nalimi...@club.fr changed:

   What|Removed |Added

 Depends On||1098534




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1098534
[Bug 1098534] Package relying on a specific LLVM version
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #36 from Milan Bouchet-Valat nalimi...@club.fr ---
Neal: Yeah, this works on build VMs, but is less practical on your own machine.
See bug 1098534.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Neal Becker ndbeck...@gmail.com changed:

   What|Removed |Added

 CC|ndbeck...@gmail.com |
 CC||ndbeck...@gmail.com



--- Comment #32 from Neal Becker ndbeck...@gmail.com ---
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)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #33 from Rex Dieter rdie...@math.unl.edu ---
Needs rebuild after llvm-3.4 landed in updates:
https://admin.fedoraproject.org/updates/FEDORA-2014-5319

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #34 from Milan Bouchet-Valat nalimi...@club.fr ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517
Bug 1040517 depends on bug 1062901, which changed state.

Bug 1062901 Summary: Review Request: openspecfun - Library providing a 
collection of special mathematical functions
https://bugzilla.redhat.com/show_bug.cgi?id=1062901

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA



-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #29 from Neal Becker ndbeck...@gmail.com ---
Is julia-release-basic not packaged?

This is needed to run julia under emacs

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #30 from Neal Becker ndbeck...@gmail.com ---
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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #31 from Milan Bouchet-Valat nalimi...@club.fr ---
julia-release-basic/julia-basic existed until recently, when the Julia-based
readline implementation was merged. Now only the julia executable exists.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #27 from Milan Bouchet-Valat nalimi...@club.fr ---
Filed https://github.com/JuliaLang/julia/issues/6742 about the unexpected
dependency on openspecfun-devel (also applies to openlibm).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #28 from Milan Bouchet-Valat nalimi...@club.fr ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #26 from Milan Bouchet-Valat nalimi...@club.fr ---
Thanks, filed here: https://github.com/JuliaLang/julia/issues/6722

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Orion Poplawski or...@cora.nwra.com changed:

   What|Removed |Added

 Depends On||1089500




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1089500
[Bug 1089500] Review Request: openlibm - High quality system independent,
open source libm
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

baurthefi...@gmail.com changed:

   What|Removed |Added

 CC||baurthefi...@gmail.com



--- Comment #16 from baurthefi...@gmail.com ---
Hello,

I tried to build on Fedora Copr and it requried to add

BuildRequires:  openspecfun-devel

to spec file. Consider adding it, please.

Thanks,

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #17 from baurthefi...@gmail.com ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #18 from Milan Bouchet-Valat nalimi...@club.fr ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #19 from baurthefi...@gmail.com ---
(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}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #20 from baurthefi...@gmail.com ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #21 from Orion Poplawski or...@cora.nwra.com ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #22 from Orion Poplawski or...@cora.nwra.com ---
(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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #23 from Milan Bouchet-Valat nalimi...@club.fr ---
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?...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #24 from Milan Bouchet-Valat nalimi...@club.fr ---
Orion: How do you reproduce the ENETUNREACH tests failure? Do you need to
disable the loopback interface?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #25 from Orion Poplawski or...@cora.nwra.com ---
linux-user-chroot --unshare-net / rpmbuild 

copr builds should reproduce as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #13 from Orion Poplawski or...@cora.nwra.com ---
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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #14 from Milan Bouchet-Valat nalimi...@club.fr ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #15 from Orion Poplawski or...@cora.nwra.com ---
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)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #12 from Milan Bouchet-Valat nalimi...@club.fr ---
Are you OK with the new version? (FWIW, ARM support in Julia might well be
ready for the next 0.3 version.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #11 from Milan Bouchet-Valat nalimi...@club.fr ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Milan Bouchet-Valat nalimi...@club.fr changed:

   What|Removed |Added

 Depends On||1062901




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1062901
[Bug 1062901] Review Request: openspecfun - Library providing a collection
of special mathematical functions
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #9 from Milan Bouchet-Valat nalimi...@club.fr ---
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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #10 from Orion Poplawski or...@cora.nwra.com ---
I believe meta-packages are frowned upon and comps groups preferred for this
sort of thing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Orion Poplawski or...@cora.nwra.com changed:

   What|Removed |Added

 CC||or...@cora.nwra.com



--- Comment #8 from Orion Poplawski or...@cora.nwra.com ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #6 from Milan Bouchet-Valat nalimi...@club.fr ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #7 from Neal Becker ndbeck...@gmail.com ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Neal Becker ndbeck...@gmail.com changed:

   What|Removed |Added

 CC||ndbeck...@gmail.com



--- Comment #5 from Neal Becker ndbeck...@gmail.com ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Bug 1040517 depends on bug 1040027, which changed state.

Bug 1040027 Summary: Review Request: double-conversion - Library providing 
binary-decimal and decimal-binary routines for IEEE doubles
https://bugzilla.redhat.com/show_bug.cgi?id=1040027

   What|Removed |Added

 Status|VERIFIED|CLOSED
 Resolution|--- |ERRATA



-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Milan Bouchet-Valat nalimi...@club.fr changed:

   What|Removed |Added

 Depends On||1058019




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1058019
[Bug 1058019] Review Request: utf8proc - Library for processing UTF-8
encoded Unicode strings
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517

Milan Bouchet-Valat nalimi...@club.fr changed:

   What|Removed |Added

 Blocks|177841 (FE-NEEDSPONSOR) |




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=177841
[Bug 177841] Tracker: Review requests from new Fedora packagers who need a
sponsor
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #4 from Milan Bouchet-Valat nalimi...@club.fr ---
With double-conversion now in the repos, the new package builds fine on Koji:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6305726

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
___
package-review mailing list
package-review@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review