Per your strategy, will there come llvm3.4, llvm3.5 in the future? Because LLVM API is never stable.

Does Julia upstream have any plans to move to llvm-3.4 btw?

(In reply to Christopher Meng from comment #1)
> Per your strategy, will there come llvm3.4, llvm3.5 in the future? Because
> LLVM API is never stable.
Well, it really depends on how Fedora's and Julia's schedules interact in the future. With some luck, when a new Fedora release goes out, Julia will happen to use the latest LLVM version, and we won't need a versioned llvm package. But OTOH when backporting a new LLVM version to a published Fedora release, it's likely that Julia will break as there will likely be some lag between LLVM's and Julia's releases. With an unstable API like LLVM's, versioned parallel-installable packages are kind of inevitable.


(In reply to Jens Petersen from comment #2)
> Does Julia upstream have any plans to move to llvm-3.4 btw?
Yes, the next version will use LLVM 3.5. (Support for 3.4 is almost present already, but there are a few bugs and it has not been tested thoroughly enough that the developers feel confident to use it now.)

Bump!

(In reply to Milan Bouchet-Valat from comment #3)
> (In reply to Christopher Meng from comment #1)
> > Per your strategy, will there come llvm3.4, llvm3.5 in the future? Because
> > LLVM API is never stable.
> Well, it really depends on how Fedora's and Julia's schedules interact in
> the future.

It depends on Julia itself, actually.

> But OTOH when backporting a new LLVM version to a published Fedora
> release, it's likely that Julia will break as there will likely be some lag
> between LLVM's and Julia's releases. 

I don't think you need to update julia for each Fedora release, we need to keep something stable.

> With an unstable API like LLVM's,
> versioned parallel-installable packages are kind of inevitable.

Still not a good reason. If something can't be considered stable, you'd better package it in copr first.

> (In reply to Jens Petersen from comment #2)
> > Does Julia upstream have any plans to move to llvm-3.4 btw?
> Yes, the next version will use LLVM 3.5. (Support for 3.4 is almost present
> already, but there are a few bugs and it has not been tested thoroughly
> enough that the developers feel confident to use it now.)

Oh, so llvm3.5 will appear in review queue again? What about 3.6, 3.7, 3.8 etc.?

(In reply to Christopher Meng from comment #5)
> (In reply to Milan Bouchet-Valat from comment #3)
> > (In reply to Christopher Meng from comment #1)
> > > Per your strategy, will there come llvm3.4, llvm3.5 in the future? Because
> > > LLVM API is never stable.
> > Well, it really depends on how Fedora's and Julia's schedules interact in
> > the future.
> 
> It depends on Julia itself, actually.
Well, it depends on what version of Julia we want in each Fedora release, and on whether the LLVM maintainers in Fedora want to upgrade it in stable releases or not.

> > But OTOH when backporting a new LLVM version to a published Fedora
> > release, it's likely that Julia will break as there will likely be some lag
> > between LLVM's and Julia's releases. 
> 
> I don't think you need to update julia for each Fedora release, we need to
> keep something stable.
Sure. But for example in F20 LLVM was updated from 3.3 to 3.4, which would have been a problem if Julia had been included in that release. So even if I keep Julia stable, which is perfectly possible, LLVM maintainers need to be OK with keeping it stable too (and they may have good reasons not to want this).

> > With an unstable API like LLVM's,
> > versioned parallel-installable packages are kind of inevitable.
> 
> Still not a good reason. If something can't be considered stable, you'd
> better package it in copr first.
What, move LLVM out of Fedora? :-)

It's not Julia which is unstable, it's LLVM. And I guess it's fine. In such cases it is frequent to allow several versions to be parallel-installable, just like GTK2 and GTK3 live together for years in Fedora.

> > (In reply to Jens Petersen from comment #2)
> > > Does Julia upstream have any plans to move to llvm-3.4 btw?
> > Yes, the next version will use LLVM 3.5. (Support for 3.4 is almost present
> > already, but there are a few bugs and it has not been tested thoroughly
> > enough that the developers feel confident to use it now.)
> 
> Oh, so llvm3.5 will appear in review queue again? What about 3.6, 3.7, 3.8
> etc.?
I can't tell for sure. I can ask Julia developers to try to remain very close to upstream LLVM. They already do that, but they decided to skip 3.4 since it didn't bring much benefit while 3.5 was more interesting. They can probably avoid doing that in the future if distributions need it. But again, if LLVM maintainers want to update it right after the release in a stable Fedora release, the same situation is going to happen.


But what's the problem with including llvm3.X in parallel with llvm? The packaging work has already been done, the code is tested, and it adds additional stability for packages and users who may need it. Julia is not the only package which would have found it useful; for example, it seems that ghc only supports 3.3 too (cf. bug 1049057).

The other strategy is to use Software Collections:
https://bugzilla.redhat.com/show_bug.cgi?id=1049057#c6

I tried building, but install conflicts: 

rpmbuild --rebuild ~/llvm3.3-3.3-1.fc20.src.rpm
...

sudo yum install ~/rpmbuild/RPMS/x86_64/llvm3.3-devel-3.3-1.fc20.x86_64.rpm 
[sudo] password for nbecker: 
Loaded plugins: fastestmirror, langpacks, merge-conf, refresh-packagekit
Repository google-chrome is listed more than once in the configuration
Examining /home/nbecker/rpmbuild/RPMS/x86_64/llvm3.3-devel-3.3-1.fc20.x86_64.rpm: llvm3.3-devel-3.3-1.fc20.x86_64
Marking /home/nbecker/rpmbuild/RPMS/x86_64/llvm3.3-devel-3.3-1.fc20.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package llvm3.3-devel.x86_64 0:3.3-1.fc20 will be installed
--> Processing Dependency: llvm3.3(x86-64) = 3.3-1.fc20 for package: llvm3.3-devel-3.3-1.fc20.x86_64
Loading mirror speeds from cached hostfile
 * fedora: mirror.metrocast.net
 * rpmfusion-free: mirror.us.leaseweb.net
 * rpmfusion-free-updates: mirror.us.leaseweb.net
 * rpmfusion-nonfree: mirror.us.leaseweb.net
 * rpmfusion-nonfree-updates: mirror.espoch.edu.ec
 * updates: mirror.metrocast.net
--> Running transaction check
---> Package llvm3.3.x86_64 0:3.3-1.fc20 will be installed
--> Processing Dependency: llvm3.3-libs(x86-64) = 3.3-1.fc20 for package: llvm3.3-3.3-1.fc20.x86_64
--> Processing Dependency: libLLVM-3.3.so()(64bit) for package: llvm3.3-3.3-1.fc20.x86_64
--> Running transaction check
---> Package llvm3.3-libs.x86_64 0:3.3-1.fc20 will be installed
--> Processing Conflict: llvm3.3-devel-3.3-1.fc20.x86_64 conflicts llvm-devel
--> Finished Dependency Resolution
Error: llvm3.3-devel conflicts with llvm-devel-3.4-6.fc20.x86_64

It's not uncommon for -devel packages of this sort to conflict with the main package.  Nice to avoid if possible (haven't looked), but shouldn't be considered a blocker I think.

Makes it hard to build julia.  Is there a julia build f20 x86_64 available for me to try?

As I said in the description:
> This package is just a modification of the llvm package version 3.3 which was > included in F20. All paths have been changed to include the version, so that
> they do not conflict with other LLVM packages. The only exceptions are the
> -devel packages, which need to conflict since they determine with LLVM
> compilers will use.

-devel packages need to conflict since usually programs call llvm-config to determine which version of LLVM should be used when building. If they did not conflict, they would have to be adapted to call a special versioned llvm-config.

I don't think this is a problem since you can easily remove llvm-devel without removing many dependencies.

For a Julia package, see
http://copr.fedoraproject.org/coprs/nalimilan/julia/
(details on Bug 1040517)

I'm going to use LLVM 3.4, Julia developers are willing to backport fixes to support it, and LLVM 3.5. Let's hope it will work for future releases.

I'd like to raise this issue again. Julia has been FTBFS for several weeks in Rawhide because of the update to LLVM 3.6. Clearly the current strategy isn't viable if we want a working Julia in Fedora in the future. I'd like to include llvm3.3 in Rawhide/F23 in order to be able to get Julia working again.

The Haskell compiler has done the same recently with LLVM 3.4, for the very same reason:
https://bugzilla.redhat.com/show_bug.cgi?id=1161014

Jens, Mukundan: could you comment on your experience with packaging llvm3.4?

(In reply to Milan Bouchet-Valat from comment #12)
> The Haskell compiler has done the same recently with LLVM 3.4, for the very
> same reason:

Yeah I we probably need llvm35 too for ghc-7.10

> Jens, Mukundan: could you comment on your experience with packaging llvm3.4?

Once you have llvm34.spec it should be pretty trivial to tweak it to llvm33.
You can give it a try locally first. :)

You can't see llvm34?  (comment 11)

(I still vote for calling this llvm33;)
Are there any other packages with '.' in their name (without a '-')?

> Once you have llvm34.spec it should be pretty trivial to tweak it to llvm33.
> You can give it a try locally first. :)

Assuming you don't need clang?

> (I still vote for calling this llvm33;)
> Are there any other packages with '.' in their name (without a '-')?

Anyway since we already have llvm34 it seems more consistent use to llvm33.

Actually, I already have an llvm3.3 package ready for a long time, which I can rename to llvm33. I was more asking for your opinion about having another versioned-LLVM package in Fedora, since anyway I'd need support to get this review request accepted.

I don't need clang, and indeed I realized the build fails if I enable it in 64-bit Rawhide (but not in other versions). Is that expected?

(In reply to Jens Petersen from comment #13)
> You can't see llvm34?  (comment 11)

Ugh, that should have read "You can't *use* llvm34?"
(Since you mentioned that version in version 11.)

(In reply to Milan Bouchet-Valat from comment #15)
> Actually, I already have an llvm3.3 package ready for a long time, which I
> can rename to llvm33. I was more asking for your opinion about having
> another versioned-LLVM package in Fedora, since anyway I'd need support to
> get this review request accepted.

I don't see any problem with having llvm33 in Fedora if it is needed.
(llvm34 seems to be working just fine and I haven't had to update it.)

> I don't need clang, and indeed I realized the build fails if I enable it in
> 64-bit Rawhide (but not in other versions). Is that expected?

I removed all the clang and other misc subpackaging from llvm34.spec
which simplifies the packaging a lot.  I think it is a lot more work
to package the whole of llvm+clang etc as llvmXY.

Does your current package actually build then?

My personal recommendation would be to just "rebase" llvm33.spec
off llvm34.spec - if you do that I am happy to help review it.
I think that should just work (ie more or less just changing
the version number etc should be enough.:)

I appreciate this submission pre-dates llvm34, but nevertheless
llvm34 is a newer version of llvm than llvm33 and I think it is better
to keep the packaging of these two packages as close as possible
to ease maintainence and avoid potential problems and extra work. :)

Unfortunately, the upcoming 0.4 version of Julia does not work with 3.4, in which MCJIT was introduced and wasn't very stable IIUC. Upstream is not very keen on continuing to support five different LLVM APIs, and since it's not tested during continuous integration is breaks frequently.

Thanks for your offer to review. I'll rebase my llvm33 package on llvm34 and post the result here soon. The current package already builds in Rawhide when disabling everything except the libraries, which is what I need.

OK, I've started from your llvm34 package, and with very few changes it works.

Spec URL: https://nalimilan.fedorapeople.org/llvm33.spec
SRPM URL: 
https://nalimilan.fedorapeople.org/llvm33-3.3-1.fc22.src.rpm
Description: Versioned LLVM 3.3
Fedora Account System Username: nalimilan

A Koji build is here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=10287200


The diff is:
--- ../llvm34/llvm34.spec	2015-07-04 09:21:38.400208716 +0200
+++ ../llvm33/llvm33.spec	2015-07-04 13:09:52.844414464 +0200
@@ -11,13 +11,11 @@
   %global llvmdocdir() %{_docdir}/%1
 %endif
 
-%global downloadurl http://llvm.org/%{?prerel:pre-}releases/%{version}%{?prerel:/%{prerel}}
+%global major_version 3.3
 
-%global major_version 3.4
-
-Name:           llvm34
-Version:        3.4.2
-Release:        7%{?dist}
+Name:           llvm33
+Version:        3.3
+Release:        1%{?dist}
 Summary:        The Low Level Virtual Machine
 
 Group:          Development/Languages
@@ -34,9 +32,7 @@
 # patches
 Patch11:        0001-data-install-preserve-timestamps.patch
 Patch12:        0002-linker-flags-speedup-memory.patch
-
-# temporary measure to get ppc64le building, if perhaps not working
-Patch21:        0001-PPC64LE-ELFv2-ABI-updates-for-the-.opd-section.patch
+Patch13:        0003-fix-clear-cache-declaration.patch
 
 BuildRequires:  bison
 BuildRequires:  chrpath
@@ -112,7 +108,7 @@
 
 %patch11 -p1
 %patch12 -p1
-%patch21 -p1
+%patch13 -p1
 
 # fix library paths
 sed -i.orig 's|/lib /usr/lib $lt_ld_extra|%{_libdir} $lt_ld_extra|' configure
@@ -169,7 +165,7 @@
 %if %{with gold}
   --with-binutils-include=%{_includedir} \
 %endif
-  --with-c-include-dirs=%{_includedir}:$(echo %{_prefix}/lib/gcc/%{_target_cpu}*/*/include)
+  --with-c-include-dirs=%{_includedir}:$(ls -d1 %{_prefix}/lib/gcc/%{_target_cpu}*/*/include | tr "\\n" ":")
 
 make %{_smp_mflags} REQUIRES_RTTI=1 VERBOSE=1 \
 %ifarch ppc
@@ -275,7 +271,6 @@
 %{_bindir}/bugpoint-%{major_version}
 %{_bindir}/llc-%{major_version}
 %{_bindir}/lli-%{major_version}
-%{_bindir}/lli-child-target-%{major_version}
 %exclude %{_bindir}/llvm-config-%{__isa_bits}-%{major_version}
 %{_bindir}/llvm*-%{major_version}
 %{_bindir}/macho-dump-%{major_version}
@@ -300,6 +295,11 @@
 %doc %{llvmdocdir %{name}-doc}/
 
 %changelog
+* Sat Jul 04 2015 Milan Bouchet-Valat <nalimilan> 3.3-1
+- Create llvm33 package based on llvm34.
+- Fix configure option --with-c-include-dirs when several gcc versions are installed.
+- Remove unused global downloadurl.
+
 * Wed Jun 17 2015 Fedora Release Engineering <rel-eng.org> - 3.4.2-7
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
(Note that the --with-c-include-dirs is something unrelated I've found out when building the package on RHEL. I can remove it for now if you like.)

(In reply to Milan Bouchet-Valat from comment #18)
> OK, I've started from your llvm34 package, and with very few changes it
> works.

Thanks

>  %changelog
> +* Sat Jul 04 2015 Milan Bouchet-Valat <nalimilan> 3.3-1
> +- Create llvm33 package based on llvm34.
> +- Fix configure option --with-c-include-dirs when several gcc versions are
> installed.
> +- Remove unused global downloadurl.

Looks good to me.

http://pkgs.fedoraproject.org/cgit/llvm34.git/commit/?id=3c25e4ba6538f2f804a5b1f0ed67ea39e95f8c68

(I think it is good to try to keep the spec files for
llvm33 <-> llvm34 <-> llvm35 <-> llvm36 in sync.)

One thing, it also be good to compare with the old llvm.spec for 3.3
and also rebase the changelog off that.

http://pkgs.fedoraproject.org/cgit/llvm.git/tree/llvm.spec?h=f19

Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated

Issues:
=======
- Header files in -devel subpackage, if present.
  Note: llvm33-doc : /usr/share/doc/llvm33-doc/examples/BrainF/BrainF.h
  See: http://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages

===== MUST items =====
C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[!]: Development (unversioned) .so files in -devel subpackage, if present.
     Note: Unversioned so-files in private %_libdir subdirectory (see
     attachment). Verify they are not in ld path.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "BSD (3 clause)", "ISC", "Unknown or generated". 2304 files
     have unknown license. Detailed output of licensecheck in
     /home/petersen/pkgreview/1109390-llvm33/licensecheck.txt
[x]: License file installed when any subpackage combination is installed.
[x]: Package must own all directories that it creates.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[!]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[x]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[x]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[x]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 665600 bytes in 3 files.
[x]: 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 %license.
[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]: %config files are marked noreplace or the reason is justified.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[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]: No %config files under /usr.
[x]: Package does not use a name that already exists.
[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]: Static libraries in -static or -devel subpackage, providing -devel if
     present.
     Note: Package has .a files: llvm33-static.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====
Generic:
[x]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[x]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in
     llvm33-doc , llvm33-libs , llvm33-static
[x]: Package functions as described.
[-]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Patches link to upstream bugs/comments/lists or are otherwise
     justified.
[x]: Scriptlets must be sane, if used.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[x]: %check is present and all tests pass.
[?]: Packages should try to preserve timestamps of original installed
     files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Uses parallel make %{?_smp_mflags} macro.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====
Generic:
[x]: Rpmlint is run on debuginfo package(s).
     Note: No rpmlint messages.
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: llvm33-3.3-1.fc23.x86_64.rpm
          llvm33-devel-3.3-1.fc23.x86_64.rpm
          llvm33-doc-3.3-1.fc23.noarch.rpm
          llvm33-libs-3.3-1.fc23.x86_64.rpm
          llvm33-static-3.3-1.fc23.x86_64.rpm
          llvm33-3.3-1.fc23.src.rpm
llvm33.x86_64: W: spelling-error %description -l en_US runtime -> run time, run-time, rudiment
llvm33.x86_64: W: no-manual-page-for-binary llc-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-nm-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-stress-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-prof-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-bcanalyzer-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-tblgen-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-diff-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-symbolizer-3.3
llvm33.x86_64: W: no-manual-page-for-binary bugpoint-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-rtdyld-3.3
llvm33.x86_64: W: no-manual-page-for-binary lli-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-cov-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-objdump-3.3
llvm33.x86_64: W: no-manual-page-for-binary opt-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-mc-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-ar-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-mcmarkup-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-link-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-dwarfdump-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-readobj-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-as-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-extract-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-dis-3.3
llvm33.x86_64: W: no-manual-page-for-binary macho-dump-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-size-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-ranlib-3.3
llvm33-devel.x86_64: W: no-manual-page-for-binary llvm-config-64-3.3
llvm33-libs.x86_64: W: no-documentation
llvm33-static.x86_64: W: no-documentation
llvm33.src: W: spelling-error %description -l en_US runtime -> run time, run-time, rudiment
llvm33.src:114: E: hardcoded-library-path in /usr/lib
llvm33.src:168: E: hardcoded-library-path in %{_prefix}/lib/gcc/%{_target_cpu}*/*/include
6 packages and 0 specfiles checked; 2 errors, 31 warnings.

Rpmlint (debuginfo)
-------------------
Checking: llvm33-debuginfo-3.3-1.fc23.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

Rpmlint (installed packages)
----------------------------
sh: /usr/bin/python: そのようなファイルやディレクトリはありません
llvm33-libs.x86_64: W: private-shared-object-provides /usr/lib64/llvm33/libprofile_rt.so libprofile_rt.so()(64bit)
llvm33-libs.x86_64: W: private-shared-object-provides /usr/lib64/llvm33/libLLVM-3.3.so libLLVM-3.3.so()(64bit)
llvm33-libs.x86_64: W: private-shared-object-provides /usr/lib64/llvm33/libLTO.so libLTO.so()(64bit)
llvm33-libs.x86_64: W: no-documentation
llvm33.x86_64: W: no-manual-page-for-binary bugpoint-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-readobj-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-symbolizer-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-ar-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-rtdyld-3.3
llvm33.x86_64: W: no-manual-page-for-binary lli-3.3
llvm33.x86_64: W: no-manual-page-for-binary llc-3.3
llvm33.x86_64: W: no-manual-page-for-binary opt-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-cov-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-mc-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-nm-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-size-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-mcmarkup-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-dwarfdump-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-dis-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-tblgen-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-objdump-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-bcanalyzer-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-ranlib-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-stress-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-extract-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-link-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-as-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-prof-3.3
llvm33.x86_64: W: no-manual-page-for-binary macho-dump-3.3
llvm33.x86_64: W: no-manual-page-for-binary llvm-diff-3.3
llvm33-static.x86_64: W: no-documentation
llvm33-devel.x86_64: W: no-manual-page-for-binary llvm-config-64-3.3
6 packages and 0 specfiles checked; 0 errors, 32 warnings.

Requires
--------
llvm33-libs (rpmlib, GLIBC filtered):
    /sbin/ldconfig
    config(llvm33-libs)
    libLLVM-3.3.so()(64bit)
    libLTO.so()(64bit)
    libc.so.6()(64bit)
    libdl.so.2()(64bit)
    libffi.so.6()(64bit)
    libgcc_s.so.1()(64bit)
    libgcc_s.so.1(GCC_3.0)(64bit)
    libgcc_s.so.1(GCC_3.4)(64bit)
    libm.so.6()(64bit)
    libpthread.so.0()(64bit)
    libstdc++.so.6()(64bit)
    libstdc++.so.6(CXXABI_1.3)(64bit)
    libstdc++.so.6(CXXABI_1.3.8)(64bit)
    libz.so.1()(64bit)
    libz.so.1(ZLIB_1.2.0)(64bit)
    rtld(GNU_HASH)

llvm33-devel (rpmlib, GLIBC filtered):
    /bin/sh
    /usr/sbin/alternatives
    libc.so.6()(64bit)
    libdl.so.2()(64bit)
    libffi-devel
    libffi.so.6()(64bit)
    libgcc_s.so.1()(64bit)
    libgcc_s.so.1(GCC_3.0)(64bit)
    libgcc_s.so.1(GCC_3.4)(64bit)
    libm.so.6()(64bit)
    libpthread.so.0()(64bit)
    libstdc++-devel
    libstdc++.so.6()(64bit)
    libstdc++.so.6(CXXABI_1.3)(64bit)
    libstdc++.so.6(CXXABI_1.3.8)(64bit)
    libz.so.1()(64bit)
    llvm33(x86-64)
    ncurses-devel
    rtld(GNU_HASH)

llvm33-static (rpmlib, GLIBC filtered):
    llvm33-devel(x86-64)

llvm33-doc (rpmlib, GLIBC filtered):
    llvm33

llvm33 (rpmlib, GLIBC filtered):
    libLLVM-3.3.so()(64bit)
    libc.so.6()(64bit)
    libdl.so.2()(64bit)
    libffi.so.6()(64bit)
    libgcc_s.so.1()(64bit)
    libgcc_s.so.1(GCC_3.0)(64bit)
    libgcc_s.so.1(GCC_3.4)(64bit)
    libm.so.6()(64bit)
    libpthread.so.0()(64bit)
    libstdc++.so.6()(64bit)
    libstdc++.so.6(CXXABI_1.3)(64bit)
    libstdc++.so.6(CXXABI_1.3.8)(64bit)
    libz.so.1()(64bit)
    llvm33-libs(x86-64)
    rtld(GNU_HASH)

Provides
--------
llvm33-libs:
    config(llvm33-libs)
    libLLVM-3.3.so()(64bit)
    libLTO.so()(64bit)
    libprofile_rt.so()(64bit)
    llvm33-libs
    llvm33-libs(x86-64)

llvm33-devel:
    llvm33-devel
    llvm33-devel(x86-64)

llvm33-static:
    llvm33-static
    llvm33-static(x86-64)

llvm33-doc:
    llvm33-doc

llvm33:
    llvm33
    llvm33(x86-64)

Unversioned so-files
--------------------
llvm33-libs: /usr/lib64/llvm33/BugpointPasses.so
llvm33-libs: /usr/lib64/llvm33/LLVMgold.so
llvm33-libs: /usr/lib64/llvm33/libLLVM-3.3.so
llvm33-libs: /usr/lib64/llvm33/libLTO.so
llvm33-libs: /usr/lib64/llvm33/libprofile_rt.so

Source checksums
----------------
http://llvm.org/releases/3.3/llvm-3.3.src.tar.gz :
  CHECKSUM(SHA256) this package     : 68766b1e70d05a25e2f502e997a3cb3937187a3296595cf6e0977d5cd6727578
  CHECKSUM(SHA256) upstream package : 68766b1e70d05a25e2f502e997a3cb3937187a3296595cf6e0977d5cd6727578


Generated by fedora-review 0.6.0 (3c5c9d7) last change: 2015-05-20
Command line :/usr/bin/fedora-review -m fedora-rawhide-x86_64 -b 1109390
Buildroot used: fedora-rawhide-x86_64
Active plugins: Generic, Shell-api, C/C++
Disabled plugins: Java, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP, Ruby
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6

Sorry for the delay. I've synchronized llvm33.spec with your changes to llvm34.spec, and rebased the changelog and a few details on llvm.spec version 3.3. This one should be good to go -- and will allow me to finally stop these warnings a Julia FTBS on F23!


Spec URL: https://nalimilan.fedorapeople.org/llvm33.spec
SRPM URL: 
https://nalimilan.fedorapeople.org/llvm33-3.3-2.fc22.src.rpm
Description: Versioned LLVM 3.3
Fedora Account System Username: nalimilan

Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=10614986

Bump! :-)

Thanks - will try to find time tomorrow to look at this again.

I note in passing that my llvm35 review is still open too (bug 1223673).

Ah, I didn't know that. I can review it if you want. Sounds like a logical exchange.

Thanks for all your work on this.

I am not sure which binary package should really correctly own the datadir
but overall the package looks fine to me now.

The only outstanding/embarrassing remaining issue is:

[!]: Development (unversioned) .so files in -devel subpackage, if present.
     Note: Unversioned so-files in private %_libdir subdirectory (see
     attachment). Verify they are not in ld path.

But this is also true for llvm and llvm34!
The only solution I see is to get rid of
/etc/ld.so.conf.d/%{name}-%{_arch}.conf
and then add some RPATH to the binaries.
But that is a bit of work to sort out... :-(
Or maybe the llvm buildsystem (cmake) allows
some way to add a prefix.

(In reply to Milan Bouchet-Valat from comment #27)
> Ah, I didn't know that. I can review it if you want. Sounds like a logical
> exchange.

Okay if you have time that would be appreciated.

(In reply to Jens Petersen from comment #28)
> some way to add a prefix.

Sorry suffix.

Jens, would you finish your review? We should try to get both llvm3.3 and llvm3.5 in.

Sorry this drifted off my radar again... been too busy,
but had been meaning to get back to this.

I don't see any real issues with this package relative to
the llvm and llvm34 packages.  From the llvm35 review I filed
several bugs against llvm to improve its packaging.
I think it is good that the llvmXY packages stay close
and compatible to the original llvm version packagings.

So I am going ahead finally and approving this - looks good enough to me.

APPROVED

llvm33-3.3-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-c39b0b2f3b

llvm33-3.3-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update llvm33'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-c39b0b2f3b

BTW minor thing - still not sure if llvm33 needs to own
'%dir %{_datadir}/%{name}'? Keeping it in llvm33-devel looks okay to me.

And I noticed that I dropped -O3 from llvm34 - maybe you want to too?
I will probably drop it from llvm35 also.

Ah, good catch, owning an empty dir doesn't make much sense. For -O3, I agree to drop it, but since it has worked for so long it doesn't sound like a serious issue. I'll fix that in the .spec file, but not worth doing an update if we don't find other issues.

(In reply to Milan Bouchet-Valat from comment #36)
> For -O3, I agree to drop it, but since it has worked for so long it doesn't sound like
> a serious issue. I'll fix that in the .spec file, but not worth doing an
> update if we don't find other issues.

Right that sounds fine - just wanted to let you know.
There is no need to keep lockstep but probably good
to try to back/forward port fixes over time between
llvm33/llvm34/llvm35/llvmXY to keep them roughly in sync.
(Down the road probably need to consider their lifetime
too - we shouldn't need to carry these older versions
forever in Fedora but for some releases it makes sense.)
Thanks again

I wouldn't worry too much about keeping them in sync: given the current upstream plans, F24 will be released with the next version of Julia, which will probably rely on LLVM 3.8. So llvm33 would only live for one release cycle.

llvm33-3.3-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.