Vitaly Zaitsev via devel writes:
> On 22/05/2024 01:45, Tom Stellard wrote:
>> I looked in the iwyu source, and it's not using ${LLVM_LIBRARY_DIR}
>> correctly.
>> That variable points to where the libraries are installed, but iwyu is
>> using it to look
>> up the resource directory. iwyu
On 22/05/2024 01:45, Tom Stellard wrote:
I looked in the iwyu source, and it's not using ${LLVM_LIBRARY_DIR}
correctly.
That variable points to where the libraries are installed, but iwyu is
using it to look
up the resource directory. iwyu should be using `clang
-print-resource-dir`
instead.
On 5/21/24 09:33, Vitaly Zaitsev via devel wrote:
On 27/04/2024 06:34, Tom Stellard wrote:
If anyone has any feedback on these ideas we'd like to hear it and are happy to
discuss
these more.
Can you fix the ${LLVM_LIBRARY_DIR} variable in LLVM's CMake config?
It broke after switching LLVM
On 27/04/2024 06:34, Tom Stellard wrote:
If anyone has any feedback on these ideas we'd like to hear it and are
happy to discuss
these more.
Can you fix the ${LLVM_LIBRARY_DIR} variable in LLVM's CMake config?
It broke after switching LLVM to use /usr/lib. It still points to
/usr/lib64 and
On Wed, May 15, 2024 at 2:02 PM Miro Hrončok wrote:
>
> On 15. 05. 24 13:31, Vít Ondruch wrote:
> > I am saying that Python is bad example and nobody should follow it.
>
> I respectfully disagree. The LLVM maintainers think it is a good example worth
> following. So did the NodeJS maintainers.
On 15. 05. 24 13:31, Vít Ondruch wrote:
I am saying that Python is bad example and nobody should follow it.
I respectfully disagree. The LLVM maintainers think it is a good example worth
following. So did the NodeJS maintainers. Name-versioning all the components
makes things so much easier
Dne 15. 05. 24 v 12:10 Miro Hrončok napsal(a):
On 15. 05. 24 10:08, Vít Ondruch wrote:
Dne 14. 05. 24 v 18:35 Miro Hrončok napsal(a):
On 14. 05. 24 16:02, Vít Ondruch wrote:
Dne 13. 05. 24 v 20:23 Miro Hrončok napsal(a):
On 13. 05. 24 15:38, Vít Ondruch wrote:
And TBH, for me as a Fedora
On Wed, 15 May 2024 at 04:09, Vít Ondruch wrote:
>
>
> Every time I bring up such discussion, I am told "the reason it is
> called python3 and not python is well know" and yes, it is know to some,
> including me. But advocating for less experienced users. I advocating
> for users which are not
On 15. 05. 24 10:08, Vít Ondruch wrote:
Dne 14. 05. 24 v 18:35 Miro Hrončok napsal(a):
On 14. 05. 24 16:02, Vít Ondruch wrote:
Dne 13. 05. 24 v 20:23 Miro Hrončok napsal(a):
On 13. 05. 24 15:38, Vít Ondruch wrote:
And TBH, for me as a Fedora used with no special interest in Python, the
Dne 14. 05. 24 v 18:35 Miro Hrončok napsal(a):
On 14. 05. 24 16:02, Vít Ondruch wrote:
Dne 13. 05. 24 v 20:23 Miro Hrončok napsal(a):
On 13. 05. 24 15:38, Vít Ondruch wrote:
And TBH, for me as a Fedora used with no special interest in
Python, the current Python versioning sucks hard. How am
Similarly, python-llvmlite requires llvm14, and the upcoming upstream
release will require llvm15 (with a medium-term plan to get to llvm17).
For complex projects that are tightly coupled to the LLVM implementation
like this, there is generally *absolutely nothing* that downstream
packagers
On 14. 05. 24 16:02, Vít Ondruch wrote:
Dne 13. 05. 24 v 20:23 Miro Hrončok napsal(a):
On 13. 05. 24 15:38, Vít Ondruch wrote:
And TBH, for me as a Fedora used with no special interest in Python, the
current Python versioning sucks hard. How am I supposed to tell what is the
current version
Dne 13. 05. 24 v 20:23 Miro Hrončok napsal(a):
On 13. 05. 24 15:38, Vít Ondruch wrote:
And TBH, for me as a Fedora used with no special interest in Python,
the current Python versioning sucks hard. How am I supposed to tell
what is the current version just looking at e.g. the repository? Is
On Mon, May 13, 2024 at 3:42 PM Vít Ondruch wrote:
>
> My point is that we can spent time maintaining llvm00 - llvm99 packages
> or we can spent time adjusting upstream projects to be compatible with
> the latest llvm.
>
There are many projects that require a fair amount of work to be ported to
On 13/05/2024 15:41, Vít Ondruch wrote:
we can spent time adjusting upstream projects to be compatible with the
latest llvm
Feel free to start with pocl. It still doesn't support LLVM 18.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
--
___
On 13. 05. 24 15:38, Vít Ondruch wrote:
And TBH, for me as a Fedora used with no special interest in Python, the
current Python versioning sucks hard. How am I supposed to tell what is the
current version just looking at e.g. the repository? Is it `python3.12` or is
it already `python3.13`?
On 5/13/24 07:16, Simon Farnsworth via devel wrote:
On Saturday 27 April 2024 05:34:29 BST Tom Stellard wrote:
Hi,
* Build compat packages (e.g. llvm18) as early as possible. When we package
a new major release of llvm, we create a compat package so that packages
that aren't compatible with
On Saturday 27 April 2024 05:34:29 BST Tom Stellard wrote:
> Hi,
>
> * Build compat packages (e.g. llvm18) as early as possible. When we package
> a new major release of llvm, we create a compat package so that packages
> that aren't compatible with the new version can still use the old version.
Dne 13. 05. 24 v 15:28 Fabio Valentini napsal(a):
On Mon, May 13, 2024 at 3:23 PM Vít Ondruch wrote:
Dne 27. 04. 24 v 6:58 Neal Gompa napsal(a):
* Switch to python-style compat/main packages. In order to make the packaging
more
consistent between the main package (e.g. llvm) and the
Dne 13. 05. 24 v 15:23 Vít Ondruch napsal(a):
Dne 27. 04. 24 v 6:58 Neal Gompa napsal(a):
* Switch to python-style compat/main packages. In order to make the packaging
more
consistent between the main package (e.g. llvm) and the compat package (e.g.
llvm18),
we would retire the
On Mon, May 13, 2024 at 3:23 PM Vít Ondruch wrote:
>
>
> Dne 27. 04. 24 v 6:58 Neal Gompa napsal(a):
>
> * Switch to python-style compat/main packages. In order to make the
> packaging more
> consistent between the main package (e.g. llvm) and the compat package (e.g.
> llvm18),
> we would
Dne 27. 04. 24 v 6:58 Neal Gompa napsal(a):
* Switch to python-style compat/main packages. In order to make the packaging
more
consistent between the main package (e.g. llvm) and the compat package (e.g.
llvm18),
we would retire the un-versioned dist-git for llvm, and create a new versioned
On 27. 04. 24 6:34, Tom Stellard wrote:
...
* Switch to python-style compat/main packages. In order to make the packaging
more
consistent between the main package (e.g. llvm) and the compat package (e.g.
llvm18),
we would retire the un-versioned dist-git for llvm, and create a new versioned
On Mon, Apr 29, 2024 at 4:38 PM Vitaly Zaitsev via devel
wrote:
> Both of my LLVM dependent packages: iwyu and pocl. On every LLVM major
> release they break and I have to wait for the upstream to release a new
> version.
I would hope that there are more examples than O(1),
as processes should
Neal Gompa writes:
> You also have to do new package
> reviews for each new version instead of using the compatibility
> package exception to branch older releases into compatibility
> packages.
I don't think this will be needed because it is one of the exceptions [1]:
The package is being
On 29/04/2024 16:41, Gary Buhrmaster wrote:
Do we have any idea how many code bases are
actually sensitive to the specific llvm version?
Both of my LLVM dependent packages: iwyu and pocl. On every LLVM major
release they break and I have to wait for the upstream to release a new
version.
On Mon, Apr 29, 2024 at 2:25 PM Tulio Magno Quites Machado Filho
wrote:
> Considering that LLVM releases usually happen very late in Fedora's
> development cycle, if the default LLVM version is changed, packages may
> start to FTBFS very late in the development cycle if they buildrequire
> the
Nico Kadel-Garcia writes:
> On Sat, Apr 27, 2024 at 12:35 AM Tom Stellard wrote:
>> * Invert the order of compat/main packages. Instead of having the compat
>> package be
>> the old version, and the main package be the new version, we would have the
>> compat package
>> be newer and the main
On Sat, Apr 27, 2024 at 12:35 AM Tom Stellard wrote:
>
> Hi,
>
> After each Fedora release we do a retrospective with the LLVM package
> maintainers
> and talk about how we can improve the LLVM packages[1] in Fedora. We've come
> up
> with some ideas for Fedora 41 that we'd like to share to
On Sat, Apr 27, 2024 at 5:59 AM Tom Stellard wrote:
>
> On 4/27/24 05:57, Neal Gompa wrote:
> > On Sat, Apr 27, 2024 at 5:53 AM Tom Stellard wrote:
> >>
> >> On 4/26/24 21:58, Neal Gompa wrote:
> >>> On Fri, Apr 26, 2024 at 9:35 PM Tom Stellard wrote:
>
> Hi,
>
> After each
On 4/27/24 05:57, Neal Gompa wrote:
On Sat, Apr 27, 2024 at 5:53 AM Tom Stellard wrote:
On 4/26/24 21:58, Neal Gompa wrote:
On Fri, Apr 26, 2024 at 9:35 PM Tom Stellard wrote:
Hi,
After each Fedora release we do a retrospective with the LLVM package
maintainers
and talk about how we can
On Sat, Apr 27, 2024 at 5:53 AM Tom Stellard wrote:
>
> On 4/26/24 21:58, Neal Gompa wrote:
> > On Fri, Apr 26, 2024 at 9:35 PM Tom Stellard wrote:
> >>
> >> Hi,
> >>
> >> After each Fedora release we do a retrospective with the LLVM package
> >> maintainers
> >> and talk about how we can
On 4/26/24 21:58, Neal Gompa wrote:
On Fri, Apr 26, 2024 at 9:35 PM Tom Stellard wrote:
Hi,
After each Fedora release we do a retrospective with the LLVM package
maintainers
and talk about how we can improve the LLVM packages[1] in Fedora. We've come up
with some ideas for Fedora 41 that
On Fri, Apr 26, 2024 at 9:35 PM Tom Stellard wrote:
>
> Hi,
>
> After each Fedora release we do a retrospective with the LLVM package
> maintainers
> and talk about how we can improve the LLVM packages[1] in Fedora. We've come
> up
> with some ideas for Fedora 41 that we'd like to share to
Hi,
After each Fedora release we do a retrospective with the LLVM package
maintainers
and talk about how we can improve the LLVM packages[1] in Fedora. We've come up
with some ideas for Fedora 41 that we'd like to share to raise awareness and
get feedback. Right now these are just ideas, and
35 matches
Mail list logo
