Patching or scratch build for llvm-3.8.0 failed.

Created attachment 1177862 [details]
Rebase-helper rebase-helper-debug.log log file.
See for details and report the eventual error to rebase-helper https://github.com/phracek/rebase-helper/issues.

Patches were not touched. All were applied properly

Latest upstream release: 3.9.0
Current version/release in rawhide: 3.8.0-1.fc25
URL: http://llvm.org

Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.

Based on the information from anitya:  https://release-monitoring.org/project/1830/

Rebase helper failed.
See logs and attachments in this bugzilla 

  RAN: '/usr/bin/git clone http://pkgs.fedoraproject.org/cgit/rpms/llvm.git /var/tmp/thn-rhIb_K9M'

  STDOUT:
Cloning into '/var/tmp/thn-rhIb_K9M'...


  STDERR:
error: garbage at end of loose object 'df6a37efae307388c6d0bbaab33fed5d1f6f3c8a'
fatal: loose object df6a37efae307388c6d0bbaab33fed5d1f6f3c8a (stored in /var/tmp/thn-rhIb_K9M/.git/objects/df/6a37efae307388c6d0bbaab33fed5d1f6f3c8a) is corrupt

Failed to kick off scratch build.

[Errno 2] No such file or directory: '/var/tmp/thn-t1rTrR'

As a request, can you please update llvm/clang to 3.9 prior to branching Fedora 26 :) (Feb 2017ish)

I noticed that there was a recent build of llvm 3.9.0 in rawhide by Dave Airlie (adding to CC).

It seems there are some warnings in sphinx, which are in turn treated as errors.

This can be worked around with by adding the cmake flag -DLLVM_ENABLE_SPHINX=ON

I'm not sure if this is a good idea though, as it probably should probably be patched and reported upstream.

Correction, I meant to say the cmake flag -DSPHINX_WARNINGS_AS_ERRORS=OFF

for the record both s390x and ppc64/ppc64le can build from today's master git

http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3728913
http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2353916

airlied's llvm-3.9.0-1.fc26 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=801221

jistone's llvm-3.9.0-2.fc26 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=810182

jistone's llvm-3.9.0-3.fc26 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=810678

airlied's llvm-3.9.0-4.fc26 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=812649

airlied's llvm-3.9.0-5.fc26 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=812657

airlied's llvm-3.9.0-6.fc26 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=814135

Seems to be fixed in rawhide :)

Yes, however can we back port this to f25 at least please.
As https://bugzilla.redhat.com/show_bug.cgi?id=1381109

Updating F25 means it will be an API and ABI change in a stable Fedora.
Do you have a strong justification for wanting this?

I guess it's not unheard of to update for mesa/gl needs, but it deserves caution.

(In reply to Josh Stone from comment #19)
> Updating F25 means it will be an API and ABI change in a stable Fedora.
> Do you have a strong justification for wanting this?

I would say opengl 4.3 and Vulkan support for AMD cards could be one justification. Would it be better to make a private llvm?

Personally, I only need LLVM for Rust, which would be perfectly happy with 3.9.  I'll defer to the graphics maintainers for whether it makes sense in a wider scope.

is llvm 3.8 shipped with F25 the reason I only get OpenGL 4.1 on my netbook?

OpenGL renderer string: Gallium 0.4 on AMD MULLINS (DRM 2.46.0 / 4.8.12-300.fc25.x86_64, LLVM 3.8.0)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 13.0.2
OpenGL core profile shading language version string: 4.10

(In reply to Clemens Eisserer from comment #23)
> is llvm 3.8 shipped with F25 the reason I only get OpenGL 4.1 on my netbook?
> 
> OpenGL renderer string: Gallium 0.4 on AMD MULLINS (DRM 2.46.0 /
> 4.8.12-300.fc25.x86_64, LLVM 3.8.0)
> OpenGL core profile version string: 4.1 (Core Profile) Mesa 13.0.2
> OpenGL core profile shading language version string: 4.10

Yes unfortunately, but LLVM 3.9 is already built in Rawhide, so it will be available for f26.

(In reply to Jeremy Newton from comment #24)
> Yes unfortunately, but LLVM 3.9 is already built in Rawhide, so it will be
> available for f26.

That's at least six months away. Not being six months behind other distros on vulkan support seems a compelling reason.

(In reply to Alex G. from comment #25)
> (In reply to Jeremy Newton from comment #24)
> > Yes unfortunately, but LLVM 3.9 is already built in Rawhide, so it will be
> > available for f26.
> 
> That's at least six months away. Not being six months behind other distros
> on vulkan support seems a compelling reason.

It's unfortunate, but both LLVM and Mesa are easy to compile yourself. I can provide the instructions if you are interested.

(In reply to Vedran Miletić from comment #26)
> (In reply to Alex G. from comment #25)
> > (In reply to Jeremy Newton from comment #24)
> > > Yes unfortunately, but LLVM 3.9 is already built in Rawhide, so it will be
> > > available for f26.
> > 
> > That's at least six months away. Not being six months behind other distros
> > on vulkan support seems a compelling reason.
> 
> It's unfortunate, but both LLVM and Mesa are easy to compile yourself. I can
> provide the instructions if you are interested.

People use binary distro's not to recompile critical path packages themselves. If they wanted that they would be using Gentoo. Nor do people want to rid on rawhide, else they would be using Arch.

LLVM 3.9.1 is now out, folks need a newer LLVM for many reasons including that of mesa. It's not like LLVM 3.9.0 is mere weeks old.. It's a little more than just unfortunate, it needs to be updated frankly.

(In reply to Edward O'Callaghan from comment #27)
> (In reply to Vedran Miletić from comment #26)
> > (In reply to Alex G. from comment #25)
> > > (In reply to Jeremy Newton from comment #24)
> > > > Yes unfortunately, but LLVM 3.9 is already built in Rawhide, so it will be
> > > > available for f26.
> > > 
> > > That's at least six months away. Not being six months behind other distros
> > > on vulkan support seems a compelling reason.
> > 
> > It's unfortunate, but both LLVM and Mesa are easy to compile yourself. I can
> > provide the instructions if you are interested.
> 
> People use binary distro's not to recompile critical path packages
> themselves. If they wanted that they would be using Gentoo. Nor do people
> want to rid on rawhide, else they would be using Arch.
> 
> LLVM 3.9.1 is now out, folks need a newer LLVM for many reasons including
> that of mesa. It's not like LLVM 3.9.0 is mere weeks old.. It's a little
> more than just unfortunate, it needs to be updated frankly.

Well LLVM 3.9.1 hasn't been released quite yet, but it's very close.

For anyone who wants the updated amd stack with vulkan, I have a copr:
https://copr.fedorainfracloud.org/coprs/mystro256/polaris-gfx/

But for the rest, I can't help you there. The maintainers of the LLVM and Clang packages need to organize this. It's really not hard to do, but requires a lot of testing and recompiling.

While I understand the hesitation to update to llvm 3.0, I would also like to express my disappointment. I updated to F25 in order to finally get all the new OpenGL work provided by mesa (after reading about it for months) - and now the conclusion is to wait for another 6-8 months again :/