Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Thu, 2014-03-27 at 16:02 -0400, Adam Jackson wrote:
If there are no serious objections I'll try to get this all into testing
early next week. If you _do_ happen to be using OpenGTL for something
in F20, now would be an excellent time for you to start working on
porting it to current LLVM.
Well it took a little longer, but:
https://admin.fedoraproject.org/updates/mesa-10.1-6.20140305.fc20,pure-0.58-3.fc20,python-llvmpy-0.12.4-1.fc20,pocl-0.9-4.fc20.1,OpenGTL-0.9.18-9.fc20,gedit-code-assistance-0.2.0-5.fc20,gambas3-3.5.3-1.fc20.1,dragonegg-3.4-0.3.rc0.fc20,llvm-3.4-6.fc20
I've also started a howto/checklist for future LLVM updates here:
https://fedoraproject.org/wiki/RebasingLLVM
I have yet to rebuild kate-plugin-cpphelper for new libclang, because it
fails to build for unrelated reasons:
/builddir/build/BUILD/KateCppHelperPlugin-0.9.6/src/cpp_helper_plugin_view.cpp:
In member function 'void kate::CppHelperPluginView::updateInclusionExplorer()':
/builddir/build/BUILD/KateCppHelperPlugin-0.9.6/src/cpp_helper_plugin_view.cpp:1069:100:
error: converting to 'std::stackQTreeWidgetItem*' from initializer list
would use explicit constructor 'std::stack_Tp, _Sequence::stack(_Sequence)
[with _Tp = QTreeWidgetItem*; _Sequence = std::dequeQTreeWidgetItem*,
std::allocatorQTreeWidgetItem* ]'
details::InclusionVisitorData data = {this,
m_plugin-getDocumentInfo(doc), {}, {}, nullptr, 0};
The affected code doesn't appear to exist anymore in upstream's git
repo, and I'm not familiar enough with the waking nightmare that is C++
to understand why this would even be an error (nor do I really wish to
learn, tbh). If someone wanted to chip in here that'd be great.
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On 03/29/2014 02:39 AM, Kevin Kofler wrote: By way of libGL linking LLVM, if some other library uses a private LLVM, and an application links both libGL and that library, it crashes due to symbol conflicts. Ah yes, that's an excellent point. Thanks Kevin! -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
Hi Adam, We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so long before F21 and (among other goodies) it enables OpenGL 3.3 on some newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets a little awkward: the OpenGTL package only works up to LLVM 3.3. One concern from me is that ghc on ARM uses llvm as its compiler backend. Thanks for letting me know! ghc doesn't show up as an llvm-libs consumer on amd64 so I hadn't caught this. Right - I think even on ARM only llvm would show up. Is it possible to build the llvm backend on other arches, even if only locally? That might at least allow me to shake out issues with the llvm code outside of actual codegen. It is built by default at least on intel archs - just not used by default. GHC ARM is kind of an anomaly using llvm by default - intel archs and ppc 32bit have (good) native code generators and so don't use the newer llvm backend in their compilation pipeline. You can test ghc with llvm on intel archs with the -fllvm. What you probably want to do is to change or patch ghc-rpm-macros locally to pass the -fllvm flag to ghc via Haskell Cabal buildsystem. I can send you a diff for that. Or you can tweak individual Haskell packages to use llvm by adding: %define cabal_configure_options --ghc-option=-fllvm at the beginning of their %build sections. (A more expensive way would be to rebuild all the current packages in Rawhide which would cause them to be rebuild with llvm-3.4 on ARM, but that is probably overkill and I hope we can move Rawhide ghc to 7.8 soon anyway) Thanks, Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
Hi 2014-03-27 21:02 GMT+01:00 Adam Jackson a...@redhat.com: We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so long before F21 and (among other goodies) it enables OpenGL 3.3 on some newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets a little awkward: the OpenGTL package only works up to LLVM 3.3. The following source packages will also be updated for the llvm rebase: dragonegg gambas3 pocl pure python-llvmpy I have patched python-llvmpy to work with llvm 3.4, so it should be a problem. The patched package (0.12.4-19 has been built in Rawhide but not in F20, to avoid re building the same thing twice. Regards, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Fri, Mar 28, 2014 at 1:54 AM, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com wrote: 2014-03-27 17:40 GMT-03:00 Adam Williamson awill...@redhat.com: On Thu, 2014-03-27 at 16:02 -0400, Adam Jackson wrote: We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so long before F21 and (among other goodies) it enables OpenGL 3.3 on some newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets a little awkward: the OpenGTL package only works up to LLVM 3.3. However, OpenGTL is dead upstream, and the only thing requiring it in F20 gold - calligra-krita, by way of libQtGTL - has already been updated to Obsolete OpenGTL. As far as I know OpenGTL is the only such package we have requiring LLVM 3.3, so the rest of the rebase should just be a matter of updating to match F21. The following source packages will also be updated for the llvm rebase: dragonegg gambas3 pocl pure python-llvmpy If there are no serious objections I'll try to get this all into testing early next week. If you _do_ happen to be using OpenGTL for something in F20, now would be an excellent time for you to start working on porting it to current LLVM. I can absolutely see the reasons for doing this, but...can it at least go through a fesco rubber stamp? Let's face it, entirely deprecating a library we shipped as part of the gold release seems to be a pretty flagrant violation of the update policy, and really ought to be granted a formal exception at the very least if it's going to go ahead. As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. ABI changes in general are very strongly discouraged https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases Fedora *is* a platform, not just a set of packages, however half-assedly we conform to that vision, so I guess I just feel a bit uncomfortable not at least putting up a few hoops for this to jump through. :) This patch may be useful: https://abf.rosalinux.ru/openmandriva/opengtl/blob/master/opengtl-0.9.18-llvm-3.4.patch If that works we should probably use it for F20 to avoid retiring a package mid release. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
While Heisenbereg isn't the newbie friendly distro that Mint or Ubuntu are but many new to Enterprise linux use this and that could seriously cause some bad blood type issues with end-users I'm also for at least getting the upstream approval for mid release modding if not FesCO Corey W Sheldon Owner, 1st Class Mobile Shine 310.909.7672 www.facebook.com/1stclassmobileshine On Fri, Mar 28, 2014 at 11:15 AM, Adam Jackson a...@redhat.com wrote: On Fri, 2014-03-28 at 07:39 -0400, Jaroslav Reznik wrote: +1 And yep, it should go to FESCo - this has much more bigger scope than 10.0.3 due to LLVM update. You know I'm more than ok with updates to Fn-1 but this one should be coordinated very well. Can you (or anyone else) elaborate on the issues you're concerned with here? If I'm going to have to play Simon Says about this I'd like some opportunity to address (or at least investigate) concerns ahead of time. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On 03/28/2014 04:37 PM, Adam Jackson wrote: RHEL's Mesa at this point links against a private build of llvm that is explicitly _not_ part of The Platform, for exactly this reason: it's not something we can commit to supporting for any use beyond Mesa itself, even in the extreme short term. This might be a good way forward for Fedora as well to avoid changing the system-wide llvm ABI mid release. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Fri, 2014-03-28 at 11:21 -0400, Corey Sheldon wrote: While Heisenbereg isn't the newbie friendly distro that Mint or Ubuntu are but many new to Enterprise linux use this and that could seriously cause some bad blood type issues with end-users I'm also for at least getting the upstream approval for mid release modding if not FesCO Upstream approval? Mesa doesn't care what we ship. If you mean will RHEL mind if we do this, hello, my name's Adam, I've been doing most of the packaging grunt work for graphics in RHEL for the last six-ish years, including mass rebases in RHEL6 for the last three. I'm pretty sure I'm okay with it. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Thu, 2014-03-27 at 13:40 -0700, Adam Williamson wrote: Fedora *is* a platform, not just a set of packages, however half-assedly we conform to that vision, so I guess I just feel a bit uncomfortable not at least putting up a few hoops for this to jump through. :) OpenGTL here is something of an implementation detail. RHEL's Mesa at this point links against a private build of llvm that is explicitly _not_ part of The Platform, for exactly this reason: it's not something we can commit to supporting for any use beyond Mesa itself, even in the extreme short term. It might be nice if Fedora adopted the common practice (among other OSes with interface assurances) of at least attempting to define stability levels. Whose action item would that be? - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
Adam Jackson (a...@redhat.com) said: On Fri, 2014-03-28 at 07:39 -0400, Jaroslav Reznik wrote: +1 And yep, it should go to FESCo - this has much more bigger scope than 10.0.3 due to LLVM update. You know I'm more than ok with updates to Fn-1 but this one should be coordinated very well. Can you (or anyone else) elaborate on the issues you're concerned with here? If I'm going to have to play Simon Says about this I'd like some opportunity to address (or at least investigate) concerns ahead of time. 1) the removal of OpenGTL mid-stream breaking user or other apps (and we can't truly remove it anyway - it stays in the F20 release repo) This may be solvable by use of the patch mentioned elsewhere in this thread. 2) as the policy is to not update ABI on libraries, it requires an exception. Concerns would be about the number of apps affected, coordinating the release of all dependent apps, how likely user/other apps might be broken by this ABI update. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Fri, 2014-03-28 at 07:39 -0400, Jaroslav Reznik wrote: +1 And yep, it should go to FESCo - this has much more bigger scope than 10.0.3 due to LLVM update. You know I'm more than ok with updates to Fn-1 but this one should be coordinated very well. Can you (or anyone else) elaborate on the issues you're concerned with here? If I'm going to have to play Simon Says about this I'd like some opportunity to address (or at least investigate) concerns ahead of time. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Fri, 2014-03-28 at 11:38 -0400, Bill Nottingham wrote:
Adam Jackson (a...@redhat.com) said:
Can you (or anyone else) elaborate on the issues you're concerned with
here? If I'm going to have to play Simon Says about this I'd like some
opportunity to address (or at least investigate) concerns ahead of time.
1) the removal of OpenGTL mid-stream breaking user or other apps
(and we can't truly remove it anyway - it stays in the F20 release repo)
This may be solvable by use of the patch mentioned elsewhere in this thread.
Yeah, I'm happy to apply that patch. I'm not sure I could do much
validation on it beyond running OpenGTL's own tests though (or, I guess,
pulling an old version of calligra and trying to exercise it that way).
2) as the policy is to not update ABI on libraries, it requires an
exception. Concerns would be about the number of apps affected, coordinating
the release of all dependent apps, how likely user/other apps might be
broken by this ABI update.
In terms of Fedora proper, it's a pretty short list:
- eclipse-cdt-llvm, syntastic-llvm, gedit-code-assistance, and
kate-plugin-cpphelper all use clang to do various levels of realtime
parsing for things like syntax highlighting and etc; depressingly
there's even a libclang.so (yep, not versioned!) whose abi has almost
certainly changed, which the latter two do use, so probably they should
be rebuilt even in f21
- xorg-x11-drv-vmware - mesa-libxatracker - llvm-libs; testable by
booting a kvm with a vmware gpu (I think, there's been multiple
generations and the one kvm emulates might not be one requiring the
xatracker bits) or, obviously, under vmware
- pocl is an opencl implementation with no consumers, but with a
testsuite
- pure is a programming language with a test suite; I don't know of any
other packages containing pure code though (rimshot)
- OpenGTL is covered above
- dragonegg is an llvm backend for gcc, with a test suite
- gambas3 is a visual basic clone; it does not appear to have a test
suite, but the IDE is at least self-hosting
- python{,3}-llvmpy are python wrappers around libLLVM, with a test
suite
- ghc apparently uses llvm as a backend on arm; I'm assuming it has a
test suite because Haskell
And, of course, mesa-{dri,vdpau}-drivers contain drivers using LLVM.
So, ~12 packages outside llvm and mesa, not all of which necessarily
need an update (depends how much clang's output changes between 3.3 and
3.4). Excluding mesa these are mostly leaf packages, well outside the
critical path, typically self-contained, and quite unlikely to break
booting to the desktop for anyone.
That most of them appear to have test suites is heartening, the irony is
that running them for the llvm rebase would almost certainly be more
verification than went into them for F20 gold. Still, we can at least
establish a baseline and compare for regressions.
That said, I haven't looked for other consumers in outside repositories,
and I can't possibly know every llvm-using app in the world even if I
did look.
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Fri, 2014-03-28 at 16:45 +0100, Kalev Lember wrote: On 03/28/2014 04:37 PM, Adam Jackson wrote: RHEL's Mesa at this point links against a private build of llvm that is explicitly _not_ part of The Platform, for exactly this reason: it's not something we can commit to supporting for any use beyond Mesa itself, even in the extreme short term. This might be a good way forward for Fedora as well to avoid changing the system-wide llvm ABI mid release. Eh. We've done an llvm rebase before: dmt:~% koji -q latest-pkg f18 llvm llvm-3.1-11.fc18 f18 salimma dmt:~% koji -q latest-pkg f18-updates llvm llvm-3.3-0.4.rc2.fc18 f18-updates ajax People were pretty eager for it then, too, and we even did it _because_ we wanted a Mesa rebase to go with it. llvm upstream doesn't do stable branches, so there's really not a good solution here. And tbf llvm really is a research project more than a compiler in a lot of ways, anyone building against it is going to discover they're building on sand eventually, regardless of when Fedora updates it. That said I'm not intrinsically opposed to doing, say, compat-llvm (in fact I suggested it in F18). Though if I had to choose between that and mesa-private-llvm in Fedora... I dunno, they're both kind of terrible. compat-llvm would let us stick to the rule about not shipping the same source in two packages, but m-p-l might have marginally better performance. Neither one seems as sane to me as just accepting llvm as not actually ABI. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Thu, 2014-03-27 at 22:25 -0400, Jens Petersen wrote: Hi, We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so long before F21 and (among other goodies) it enables OpenGL 3.3 on some newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets a little awkward: the OpenGTL package only works up to LLVM 3.3. One concern from me is that ghc on ARM uses llvm as its compiler backend. Thanks for letting me know! ghc doesn't show up as an llvm-libs consumer on amd64 so I hadn't caught this. Is it possible to build the llvm backend on other arches, even if only locally? That might at least allow me to shake out issues with the llvm code outside of actual codegen. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Fri, Mar 28, 2014 at 11:37:24AM -0400, Adam Jackson wrote: It might be nice if Fedora adopted the common practice (among other OSes with interface assurances) of at least attempting to define stability levels. Whose action item would that be? Agreed, and, FESCo. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
Matthew Miller (mat...@fedoraproject.org) said: On Fri, Mar 28, 2014 at 11:37:24AM -0400, Adam Jackson wrote: It might be nice if Fedora adopted the common practice (among other OSes with interface assurances) of at least attempting to define stability levels. Whose action item would that be? Agreed, and, FESCo. The fun part would be whether we start enforcing that *in* Fedora, or whether we keep the current policy that anything in the Fedora repository is an acceptable ABI to use for anything else in the Fedora repository. (To be clear, I don't think that scales in the long term.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
Kalev Lember wrote: This might be a good way forward for Fedora as well to avoid changing the system-wide llvm ABI mid release. No, most definitely not! Let me introduce you to our old friend, the symbol conflict. By way of libGL linking LLVM, if some other library uses a private LLVM, and an application links both libGL and that library, it crashes due to symbol conflicts. And this is EXACTLY what already happened with OpenGTL on several distributions, including Fedora: http://www.valdyas.org/fading/index.cgi/2011/10/08#llvm The only fix for that issue, and the one we implemented, was linking OpenGTL (and also Mesa, which had also been using a private LLVM before) against the system LLVM. The distros which didn't do that kept having that fatal crash. Now, it turns out that the current Krita no longer uses OpenGTL, and I'm not aware of any application using it, so I don't really care what you do to it anymore. (We already retired it in Rawhide.) But please DO NOT use a private LLVM in any other package (and especially not in Mesa – again, to avoid the symbol conflicts, BOTH Mesa AND the other LLVM-using package(s) MUST link to the shared LLVM library). You WILL hit this same issue. You have been warned. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so long before F21 and (among other goodies) it enables OpenGL 3.3 on some newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets a little awkward: the OpenGTL package only works up to LLVM 3.3. However, OpenGTL is dead upstream, and the only thing requiring it in F20 gold - calligra-krita, by way of libQtGTL - has already been updated to Obsolete OpenGTL. As far as I know OpenGTL is the only such package we have requiring LLVM 3.3, so the rest of the rebase should just be a matter of updating to match F21. The following source packages will also be updated for the llvm rebase: dragonegg gambas3 pocl pure python-llvmpy If there are no serious objections I'll try to get this all into testing early next week. If you _do_ happen to be using OpenGTL for something in F20, now would be an excellent time for you to start working on porting it to current LLVM. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Thu, 2014-03-27 at 16:02 -0400, Adam Jackson wrote: We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so long before F21 and (among other goodies) it enables OpenGL 3.3 on some newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets a little awkward: the OpenGTL package only works up to LLVM 3.3. However, OpenGTL is dead upstream, and the only thing requiring it in F20 gold - calligra-krita, by way of libQtGTL - has already been updated to Obsolete OpenGTL. As far as I know OpenGTL is the only such package we have requiring LLVM 3.3, so the rest of the rebase should just be a matter of updating to match F21. The following source packages will also be updated for the llvm rebase: dragonegg gambas3 pocl pure python-llvmpy If there are no serious objections I'll try to get this all into testing early next week. If you _do_ happen to be using OpenGTL for something in F20, now would be an excellent time for you to start working on porting it to current LLVM. I can absolutely see the reasons for doing this, but...can it at least go through a fesco rubber stamp? Let's face it, entirely deprecating a library we shipped as part of the gold release seems to be a pretty flagrant violation of the update policy, and really ought to be granted a formal exception at the very least if it's going to go ahead. As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. ABI changes in general are very strongly discouraged https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases Fedora *is* a platform, not just a set of packages, however half-assedly we conform to that vision, so I guess I just feel a bit uncomfortable not at least putting up a few hoops for this to jump through. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
2014-03-27 17:40 GMT-03:00 Adam Williamson awill...@redhat.com: On Thu, 2014-03-27 at 16:02 -0400, Adam Jackson wrote: We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so long before F21 and (among other goodies) it enables OpenGL 3.3 on some newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets a little awkward: the OpenGTL package only works up to LLVM 3.3. However, OpenGTL is dead upstream, and the only thing requiring it in F20 gold - calligra-krita, by way of libQtGTL - has already been updated to Obsolete OpenGTL. As far as I know OpenGTL is the only such package we have requiring LLVM 3.3, so the rest of the rebase should just be a matter of updating to match F21. The following source packages will also be updated for the llvm rebase: dragonegg gambas3 pocl pure python-llvmpy If there are no serious objections I'll try to get this all into testing early next week. If you _do_ happen to be using OpenGTL for something in F20, now would be an excellent time for you to start working on porting it to current LLVM. I can absolutely see the reasons for doing this, but...can it at least go through a fesco rubber stamp? Let's face it, entirely deprecating a library we shipped as part of the gold release seems to be a pretty flagrant violation of the update policy, and really ought to be granted a formal exception at the very least if it's going to go ahead. As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. ABI changes in general are very strongly discouraged https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases Fedora *is* a platform, not just a set of packages, however half-assedly we conform to that vision, so I guess I just feel a bit uncomfortable not at least putting up a few hoops for this to jump through. :) This patch may be useful: https://abf.rosalinux.ru/openmandriva/opengtl/blob/master/opengtl-0.9.18-llvm-3.4.patch -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net Paulo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
Hi, We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so long before F21 and (among other goodies) it enables OpenGL 3.3 on some newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets a little awkward: the OpenGTL package only works up to LLVM 3.3. One concern from me is that ghc on ARM uses llvm as its compiler backend. To be honest things are already bad enough for ghc with llvm-3.3 there that I am not sure if they could get much worse with 3.4... ;) though really need to test (3.2 was better). I haven't seen any Haskell build regressions yet though with llvm-3.4 in Rawhide relative to 3.3 at least. (ghc-7.6.3 officially supports only llvm = 3.1, but ghc-7.8, which will be released soon and I am planning to ship it in F21, will support 3.4. Maybe I should add Requires: llvm = 3.4 at that time to ghc.spec for ARM.;) Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
