On Wed, May 31, 2023 at 08:30:58AM +0200, pascal.jaeger leimstift.de wrote:
>
> > Arthur Zamarin hat am 30.05.2023 18:35 CEST
> > geschrieben:
> >
> >
> > Currently the best solution *per package* is to speak with upstream, to
> > add a CI workflow which create a source tarball which includes
On Wed, 2023-05-31 at 11:43 +, Andrey Grozin wrote:
> Hello *,
>
> wxGTK:3.2-gtk3 is now stable. But there are 98 ebuilds depending on
> wxGTK:3.0-gtk3 and only 22 ebuilds depending on wxGTK:3.2-gtk3 in the
> tree. Probably, in a vast majority of cases 3.0 can be simply replaced by
> 3.2 wi
# Michał Górny (2023-05-31)
# Unmaintained. Last commit in 2020. Does not work with Python 3.12.
# No revdeps.
# Removal on 2023-06-30. Bug #907495.
dev-python/http-parser
--
Best regards,
Michał Górny
For less downloading client-side, as it is likely that only one package
in each covered group would work on a given system.
Closes: https://github.com/gentoo/gentoo/pull/31241
Signed-off-by: WANG Xuerui
---
dev-lang/rust-bin/rust-bin-1.65.0-r1.ebuild | 2 +-
dev-lang/rust-bin/rust-bin-1.66.1-r1
Right now mips64el systems are treated as mips64 (big-endian) in the
rust_abi helper, that prevents installation of rust. Fix by checking for
mips64el before mips64.
See: https://github.com/gentoo/gentoo/pull/31241
Signed-off-by: WANG Xuerui
---
dev-lang/rust-bin/Manifest | 12
de
Re-tab the file, and reorganize the rust_abi and rust_all_arch_uris
helpers so the keys are sorted alphabetically while preserving match
order. No functional change intended.
See: https://github.com/gentoo/gentoo/pull/31241
Signed-off-by: WANG Xuerui
---
eclass/rust-toolchain.eclass | 70 +++
Hi,
This is https://github.com/gentoo/gentoo/pull/31241 and specific to
packaging of Rust (the compiler itself), but I'm also sending here for
wider review (e.g. in case I messed up some ports but didn't realize).
WANG Xuerui (3):
rust-toolchain.eclass: cosmetic cleanups
rust-toolchain.eclass
Ühel kenal päeval, K, 31.05.2023 kell 11:43, kirjutas Andrey Grozin:
> Hello *,
>
> wxGTK:3.2-gtk3 is now stable. But there are 98 ebuilds depending on
> wxGTK:3.0-gtk3 and only 22 ebuilds depending on wxGTK:3.2-gtk3 in the
> tree. Probably, in a vast majority of cases 3.0 can be simply
> replace
On Wed, 31 May 2023, Piotr Karbowski wrote:
There's at least a few project that will not work with new wxGTK, out of what
I know that is in tree the SuperSlicer and the PrusaSlicer that in the
version currently in tree requires wxGTK 3.0. The newer version of
PrusaSlicer actually requires wxGTK
Hi,
On 31/05/2023 13.43, Andrey Grozin wrote:
Hello *,
wxGTK:3.2-gtk3 is now stable. But there are 98 ebuilds depending on
wxGTK:3.0-gtk3 and only 22 ebuilds depending on wxGTK:3.2-gtk3 in the
tree. Probably, in a vast majority of cases 3.0 can be simply replaced
by 3.2 without any negative
Hello *,
wxGTK:3.2-gtk3 is now stable. But there are 98 ebuilds depending on
wxGTK:3.0-gtk3 and only 22 ebuilds depending on wxGTK:3.2-gtk3 in the
tree. Probably, in a vast majority of cases 3.0 can be simply replaced by
3.2 without any negative consequences. What could be a reasonable way to
Andrew Ammerlaan writes:
> On 30/05/2023 18:35, Arthur Zamarin wrote:
>> My solution is as such:
>> 1. Undeprecate EGO_SUM in eclass
>> 2. Forbid it's usage in ::gentoo (done by pkgcheck, error level, will
>> fail CI and as such we can see the misuse). Overlays are allowed.
>> 3. Maintainer star
Just FYI, here is a working GitHub action for generating vendor tarballs in the
same repo but with different branches
https://github.com/bekcpear/gopkg-vendors/blob/main/.github/workflows/make-vendor.yaml
It has already worked for a long time.
Sincerely.
Ryan
> 在 2023年5月31日，14:20，Andrew Ammerla
13 matches
Mail list logo
