3:02 p.m.
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
3:40 p.m.
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
7:54 p.m.
2014-03-27 17:40 GMT-03:00 Adam Williamson <awilliam(a)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-...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
Paulo
6:23 a.m.
On Fri, Mar 28, 2014 at 1:54 AM, Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com> wrote:
2014-03-27 17:40 GMT-03:00 Adam Williamson
<awilliam(a)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-...
If that works we should probably use it for F20 to avoid retiring a
package mid release.
6:39 a.m.
----- Original Message -----
On Fri, Mar 28, 2014 at 1:54 AM, Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com> wrote:
> 2014-03-27 17:40 GMT-03:00 Adam Williamson <awilliam(a)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-...
If that works we should probably use it for F20 to avoid retiring a
package mid release.
+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.
Jaroslav
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
10:15 a.m.
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
10:21 a.m.
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 <ajax(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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
10:29 a.m.
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
10:38 a.m.
Adam Jackson (ajax(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
12:47 p.m.
On Fri, 2014-03-28 at 11:38 -0400, Bill Nottingham wrote:
Adam Jackson (ajax(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
10:37 a.m.
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
10:39 a.m.
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 -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
10:56 a.m.
Matthew Miller (mattdm(a)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
10:45 a.m.
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
11:44 a.m.
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
8:39 p.m.
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
9:25 p.m.
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
10:43 a.m.
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
11:46 p.m.
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
5:01 a.m.
Hi
2014-03-27 21:02 GMT+01:00 Adam Jackson <ajax(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
12:16 p.m.
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....
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::stack<QTreeWidgetItem*>' from initializer list
would use explicit constructor 'std::stack<_Tp,
_Sequence>::stack(_Sequence&&) [with _Tp = QTreeWidgetItem*; _Sequence =
std::deque<QTreeWidgetItem*, std::allocator<QTreeWidgetItem*> >]'
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
3662
days inactive
3682
days old
21 comments
12 participants
participants (12)
-
Adam Jackson -
Adam Williamson -
Bill Nottingham -
Corey Sheldon -
drago01 -
Jaroslav Reznik -
Jens-Ulrik Petersen -
Kalev Lember -
Kevin Kofler -
Matthew Miller -
Paulo César Pereira de Andrade -
Sergio Pascual