https://bugzilla.redhat.com/show_bug.cgi?id=1109390
Bug ID: 1109390 Summary: Review Request: llvm3.3 - Versioned LLVM Product: Fedora Version: rawhide Component: Package Review Severity: medium Priority: medium Assignee: nobody@fedoraproject.org Reporter: nalimilan@club.fr QA Contact: extras-qa@fedoraproject.org CC: package-review@lists.fedoraproject.org
Spec URL: https://bugzilla.redhat.com/attachment.cgi?id=903308 SRPM URL: http://nalimilan.perso.neuf.fr/transfert/llvm3.3-3.3-1.fc20.src.rpm Description: Versioned LLVM 3.3, parallel-installable with 3.4. Fedora Account System Username: nalimilan
In order to package the Julia language (Bug 1040517), I need to be able to use LLVM 3.3 in Fedora 20 and 21, instead of 3.4 which is currently included there. The reason is, Julia uses the LLVM API which is not stable across releases. Cf. Bug 1098534 for more details.
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.
There's the question of the best name to use. Jens Petersen thinks the package should be called llvm33. I prefer llvm3.3 since it's clearer, but then if using a dot in the name is discouraged... I don't really care actually. :-)
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
Milan Bouchet-Valat nalimilan@club.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1040517
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1040517 [Bug 1040517] Review Request: julia - High-level, high-performance dynamic language for technical computing
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #1 from Christopher Meng i@cicku.me --- Per your strategy, will there come llvm3.4, llvm3.5 in the future? Because LLVM API is never stable.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #2 from Jens Petersen petersen@redhat.com --- Does Julia upstream have any plans to move to llvm-3.4 btw?
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #3 from Milan Bouchet-Valat nalimilan@club.fr --- (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.)
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #4 from Milan Bouchet-Valat nalimilan@club.fr --- Bump!
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #5 from Christopher Meng i@cicku.me --- (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.?
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #6 from Milan Bouchet-Valat nalimilan@club.fr --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
Neal Becker ndbecker2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ndbecker2@gmail.com
--- Comment #7 from Neal Becker ndbecker2@gmail.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
Orion Poplawski orion@cora.nwra.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |orion@cora.nwra.com
--- Comment #8 from Orion Poplawski orion@cora.nwra.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #9 from Neal Becker ndbecker2@gmail.com --- Makes it hard to build julia. Is there a julia build f20 x86_64 available for me to try?
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #10 from Milan Bouchet-Valat nalimilan@club.fr --- 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)
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
Milan Bouchet-Valat nalimilan@club.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |NOTABUG Last Closed| |2014-08-28 03:27:33
--- Comment #11 from Milan Bouchet-Valat nalimilan@club.fr --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
Milan Bouchet-Valat nalimilan@club.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |NEW CC| |nonamedotc@gmail.com Resolution|NOTABUG |--- Keywords| |Reopened
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #12 from Milan Bouchet-Valat nalimilan@club.fr --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #13 from Jens Petersen petersen@redhat.com --- (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 '-')?
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #14 from Jens Petersen petersen@redhat.com ---
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #15 from Milan Bouchet-Valat nalimilan@club.fr --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #16 from Jens Petersen petersen@redhat.com --- (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. :)
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #17 from Milan Bouchet-Valat nalimilan@club.fr --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
Milan Bouchet-Valat nalimilan@club.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: llvm3.3 - |Review Request: llvm33 - |Versioned LLVM |Versioned LLVM
--- Comment #18 from Milan Bouchet-Valat nalimilan@club.fr --- 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/%%7B?prerel:pre-%7Dreleases/%%7Bversion%7D%%7B?prerel:/%%7Bp... +%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@club.fr 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@lists.fedoraproject.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.)
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
Milan Bouchet-Valat nalimilan@club.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1231163
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1231163 [Bug 1231163] FTBFS: julia with LLVM 3.6
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|nobody@fedoraproject.org |petersen@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #19 from Jens Petersen petersen@redhat.com --- (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@club.fr 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #20 from Jens Petersen petersen@redhat.com --- http://pkgs.fedoraproject.org/cgit/llvm34.git/commit/?id=3c25e4ba6538f2f804a...
(I think it is good to try to keep the spec files for llvm33 <-> llvm34 <-> llvm35 <-> llvm36 in sync.)
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #21 from Jens Petersen petersen@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #22 from Jens Petersen petersen@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #23 from Milan Bouchet-Valat nalimilan@club.fr --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #24 from Milan Bouchet-Valat nalimilan@club.fr --- Bump! :-)
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #25 from Jens Petersen petersen@redhat.com --- Thanks - will try to find time tomorrow to look at this again.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #26 from Jens Petersen petersen@redhat.com --- I note in passing that my llvm35 review is still open too (bug 1223673).
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #27 from Milan Bouchet-Valat nalimilan@club.fr --- Ah, I didn't know that. I can review it if you want. Sounds like a logical exchange.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #28 from Jens Petersen petersen@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #29 from Jens Petersen petersen@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #30 from Jens Petersen petersen@redhat.com --- (In reply to Jens Petersen from comment #28)
some way to add a prefix.
Sorry suffix.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #31 from Milan Bouchet-Valat nalimilan@club.fr --- Jens, would you finish your review? We should try to get both llvm3.3 and llvm3.5 in.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |fedora-review+
--- Comment #32 from Jens Petersen petersen@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #33 from Fedora Update System updates@fedoraproject.org --- llvm33-3.3-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-c39b0b2f3b
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |ON_QA
--- Comment #34 from Fedora Update System updates@fedoraproject.org --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #35 from Jens Petersen petersen@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #36 from Milan Bouchet-Valat nalimilan@club.fr --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #37 from Jens Petersen petersen@redhat.com --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #38 from Milan Bouchet-Valat nalimilan@club.fr --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
--- Comment #39 from Fedora Update System updates@fedoraproject.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1109390
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed|2014-08-28 03:27:33 |2015-10-31 22:34:53
package-review@lists.fedoraproject.org
-
Red Hat Bugzilla