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 shou
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 to
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 w
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. Nam
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 f
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 u
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 ex
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
curr
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 can
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 j
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
i
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`? Des
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 th
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 compat
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 un-versione
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 reti
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
d
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 n
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 de
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 rai
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 F
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 improv
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 we
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 rais
34 matches
Mail list logo
