4#issuecomment-2498148533
Just to clarify, you mean the that this warning will be added to the
'tensorflow' package, which only includes the base libraries, but the
'python-tensorflow' package will still be dropped, right?
Cheers,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
n the list. You might want to pick up those too.
[1] https://ffy00.github.io/blog/03-state-of-things-2024-04/
Cheers,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
On Tue, 2023-02-28 at 03:06 +, Filipe Laíns wrote:
> Hi,
>
> It has recently come to my attention that Cython uses CPython's private API,
> which is unstable, see [1].
>
> From https://docs.python.org/3/c-api/stable.html:
> > Names prefixed by an underscore, s
ch releases.
Meaning that packages that ship Cython modules are dependent on the interpreter
version, and need to be rebuilt on all python release updates, including patch
releases.
[1] https://github.com/cython/cython/issues/5275
Cheers,
Filipe Laíns
signature.asc
Description: This is a digit
On Sat, 2022-09-03 at 23:10 +0300, Felix Yan wrote:
> On 9/3/22 23:00, Filipe Laíns wrote:
> > python-libcst
>
> This one is still in the reverse dependency tree of hypothesis. I'll
> take a look if no one else wanted to take it.
Oh I missed that, I'll keep it then.
-pythondata-cpu-lm32
python-pythondata-cpu-mor1kx
python-pythondata-cpu-picorv32
python-pythondata-cpu-vexriscv
python-pythondata-software-compiler_rt
python-swagger-ui-bundle
Cheers,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
;
> Best,
> David
>
> [1]
> https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/138
> [2]
> https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/tree/wkd_sync_service
> [3] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/184
>
on-build.readthedocs.io/en/latest/
[14]
https://wiki.archlinux.org/title/Python_package_guidelines#Standards_based_(PEP_517)
Cheers,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
ith
the current one? Because not doing so seems a little bit problematic, and I
don't see a way for this to work otherwise.
Anyway, I thank you for your time working on this, it is certainly valuable, I
am just unsure, and, admittedly, perhaps a little bit pessimistic, about how
this implementation impacts my commitment as an Arch packager.
My two cents are that adding a x86_64_v3 would be amazing if had already reached
the, still far, goal of having automated package builders. But we are not there
yet, so this introduces a lot of manual labor :/
Cheers,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
chnical side of changes, but if someone can
commit to co-maintaining with me focusing more on that side, it would be
optimal.
Similarly, I am also have a bottleneck on time commitments, but that mostly
affects development or reviewing large changes. I work remotely, so I basically
spend all day
A new RFC (request for comment) has been opened here:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/5
Please visit the above link for discussion.
Summary: Put distribution guidlelines in a Git repository and enforce a review
process.
signature.asc
Description: This is a digital
I
was wondering if perhaps we could maybe join them together in one single
PKGBUILD? Anatol, Eli, NicoHood and Felix maintain the rest of the cross
toolchains, so if they agree maybe we could join all architectures into a single
PKGBUILD for each component?
Cheers,
Filipe Laíns
signatur
t this
would very likely not have any significant effect whatsoever in performance, and
that it fails to solve the ISA extensions issue we have. While there was some
feedback based on personal circumstances, I provided objective argumentation
about how the proposal as is is probably not a good idea and not the best path
forward.
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
On Wed, 2021-03-03 at 21:11 +1000, Allan McRae via arch-dev-public wrote:
> On 3/3/21 9:00 pm, Filipe Laíns wrote:
> > On Wed, 2021-03-03 at 20:52 +1000, Allan McRae via arch-dev-public wrote:
> > > I'd hate to be the dbscripts maintainer who implements that! Also,
>
On Wed, 2021-03-03 at 20:52 +1000, Allan McRae via arch-dev-public wrote:
> On 3/3/21 8:32 pm, Filipe Laíns wrote:
> > On Wed, 2021-03-03 at 19:44 +1000, Allan McRae via arch-dev-public wrote:
> > > On 3/3/21 7:31 pm, Filipe Laíns wrote:
> > > > On Wed, 2021-03-03 a
On Wed, 2021-03-03 at 19:44 +1000, Allan McRae via arch-dev-public wrote:
> On 3/3/21 7:31 pm, Filipe Laíns wrote:
> > On Wed, 2021-03-03 at 12:12 +1000, Allan McRae via arch-dev-public wrote:
> > > On 3/3/21 11:56 am, Filipe Laíns wrote:
> > > > On Wed, 2021-03-03 a
On Wed, 2021-03-03 at 12:12 +1000, Allan McRae via arch-dev-public wrote:
> On 3/3/21 11:56 am, Filipe Laíns wrote:
> > On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public wrote:
> > > On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
> > > &
ld just do x86_64 and the
maintainer could opt-in into x86_64-* if it makes sense for the package.
This would not introduce new effort to maintainers and would solve the issue
quite nicely IMO.
Cheers,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
ply. I am CCing
maintainers of some of our projects, that could be possibly interested in
participating.
Please try to get back to us soon!
Cheers,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
19 matches
Mail list logo
