[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing
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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Fedora Update System 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 --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Fedora Update System 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 --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #85 from Fedora Update System --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #84 from Fedora Update System --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #83 from Fedora Update System --- julia-0.3.1-1.fc21 has been pushed to the Fedora 21 testing 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #82 from Fedora Update System --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED -- 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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #81 from Milan Bouchet-Valat --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #80 from Paulo Andrade --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #79 from Jon Ciesla --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Jon Ciesla 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Milan Bouchet-Valat changed: What|Removed |Added Flags||fedora-cvs? --- Comment #78 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Paulo Andrade changed: What|Removed |Added Flags|fedora-review? |fedora-review+ --- Comment #77 from Paulo Andrade --- I consider the package approved. Just remember to remove the /usr/share/doc/julia/html/objects.inv files. The suggestion about the .desktop file is optional, but could help in making your package "more visible". -- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Paulo Andrade changed: What|Removed |Added Flags||fedora-review? --- Comment #76 from Paulo Andrade --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #75 from Milan Bouchet-Valat --- (In reply to Paulo Andrade from comment #74) > Good observation, now on my todo list whenever checking a package :) > Try this: [...] > > I personally rarely, if ever use "%doc NAME", to avoid surprises > with whatever rpm does behind the curtains, and also to make it > easier to make experimental partial builds. Thanks. Indeed the %doc directive feels pretty broken, it doesn't make any sense to include some files twice, especially since I only asked to include a few files, not any directory... > BTW, the install logic is really hard to follow, I strongly suggest > ensuring that "rpmbuild --short-circuit -bi" works. It is better for > you (the packager), but others may benefit if looking at your package. > I mean, use > (cd dir; commands) > or > pushd dir >commands > popd > to make it easier to know what is the current directory, if > necessary to add extra commands; usually one expects current > directory to be the builddir. > Avoid mv from builddir to buildroot, it just completely breaks > --short-circuit -bi Good idea. Looks like short-circuit works now. New version: Spec URL: http://nalimilan.perso.neuf.fr/transfert/julia.spec SRPM URL: http://nalimilan.perso.neuf.fr/transfert/julia-0.3.0-7.src.rpm -- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #74 from Paulo Andrade --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #73 from Milan Bouchet-Valat --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #72 from Paulo Andrade --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #71 from Milan Bouchet-Valat --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #70 from Paulo Andrade --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #69 from Milan Bouchet-Valat --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #68 from Paulo Andrade --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #67 from Milan Bouchet-Valat --- (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" i
[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #66 from Michael Schwendt --- > %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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #65 from Paulo Andrade --- > > 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #64 from Milan Bouchet-Valat --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Paulo Andrade changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #63 from Paulo Andrade --- 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 ' where 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 PAPER=letter latexpdf to make LaTeX files and run them through pdflatex text to m
[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #62 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Paulo Andrade 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 --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #60 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #59 from Milan Bouchet-Valat --- 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 Pe
[Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #58 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #57 from Milan Bouchet-Valat --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #56 from Michael Schwendt --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #55 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Milan Bouchet-Valat 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #54 from Milan Bouchet-Valat --- 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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #53 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Christopher Meng changed: What|Removed |Added CC||i...@cicku.me --- Comment #52 from Christopher Meng --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Robert Knight changed: What|Removed |Added CC||kni...@princeton.edu --- Comment #51 from Robert Knight --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #50 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #49 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #48 from Milan Bouchet-Valat --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #47 from Baurzhan Muftakhidinov --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #46 from Baurzhan Muftakhidinov --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #45 from Milan Bouchet-Valat --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #44 from Baurzhan Muftakhidinov --- (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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Milan Bouchet-Valat 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #43 from Milan Bouchet-Valat --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #42 from Baurzhan Muftakhidinov --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #41 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Milan Bouchet-Valat 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #40 from Baurzhan Muftakhidinov --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #39 from Baurzhan Muftakhidinov --- (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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #38 from Milan Bouchet-Valat --- 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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #37 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #36 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Milan Bouchet-Valat 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #35 from Neal Becker --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #34 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #33 from Rex Dieter --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Neal Becker changed: What|Removed |Added CC|ndbeck...@gmail.com | CC||ndbeck...@gmail.com --- Comment #32 from Neal Becker --- 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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #31 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #30 from Neal Becker --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #29 from Neal Becker --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #28 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #27 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Orion Poplawski 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #26 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #25 from Orion Poplawski --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #24 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #23 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #22 from Orion Poplawski --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #21 from Orion Poplawski --- (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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #18 from Milan Bouchet-Valat --- 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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #15 from Orion Poplawski --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #14 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #13 from Orion Poplawski --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #12 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #11 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Milan Bouchet-Valat 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #10 from Orion Poplawski --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #9 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Orion Poplawski changed: What|Removed |Added CC||or...@cora.nwra.com --- Comment #8 from Orion Poplawski --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #7 from Neal Becker --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #6 from Milan Bouchet-Valat --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 Neal Becker changed: What|Removed |Added CC||ndbeck...@gmail.com --- Comment #5 from Neal Becker --- 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