On Thu, 3 Jul 2025 at 19:01, kpcyrd wrote:
> On 7/3/25 12:09 PM, Campbell Jones wrote:
> > That may be something worth considering in the future. As much as I
> > dislike Fedora's package format, their decision to make architectures
> > opt-*out* instead of opt-in has apparently reduced the frict
On 7/3/25 12:09 PM, Campbell Jones wrote:
That may be something worth considering in the future. As much as I
dislike Fedora's package format, their decision to make architectures
opt-*out* instead of opt-in has apparently reduced the friction of
adding new architectures quite a bit. We should
On Thu, 03 Jul 2025 06:09:16 -0400 Campbell Jones said:
> On July 2, 2025 3:25:22 PM EDT, Levente Polyak wrote:
> >On 7/2/25 6:29 PM, Carsten Haitzler wrote:
> >> On Wed, 2 Jul 2025 12:20:49 +0200 Christian Hesse said:
> >>
> >>> Carsten Haitzler on Wed, 2025/07/02 11:00:
> Next releases
On July 2, 2025 3:25:22 PM EDT, Levente Polyak wrote:
>On 7/2/25 6:29 PM, Carsten Haitzler wrote:
>> On Wed, 2 Jul 2025 12:20:49 +0200 Christian Hesse said:
>>
>>> Carsten Haitzler on Wed, 2025/07/02 11:00:
Next releases of anything I maintain shall be going arch=(any) as
everything I
On Wed, 2 Jul 2025 21:25:22 +0200 Levente Polyak said:
> On 7/2/25 6:29 PM, Carsten Haitzler wrote:
> > On Wed, 2 Jul 2025 12:20:49 +0200 Christian Hesse said:
> >
> >> Carsten Haitzler on Wed, 2025/07/02 11:00:
> >>> Next releases of anything I maintain shall be going arch=(any) as
> >>> ever
On 7/2/25 6:29 PM, Carsten Haitzler wrote:
On Wed, 2 Jul 2025 12:20:49 +0200 Christian Hesse said:
Carsten Haitzler on Wed, 2025/07/02 11:00:
Next releases of anything I maintain shall be going arch=(any) as
everything I maintain is fully portable anyway and always has been. My AUR
pkgs alre
On Wed, 2 Jul 2025 12:20:49 +0200 Christian Hesse said:
> Carsten Haitzler on Wed, 2025/07/02 11:00:
> > Next releases of anything I maintain shall be going arch=(any) as
> > everything I maintain is fully portable anyway and always has been. My AUR
> > pkgs already have a host of arch's in them
On 7/1/25 5:57 PM, Levente Polyak wrote:
> # First step for non-x86_64 contributions
>
> Hey everyone,
>
> I'd like to share my view on the first step for targeting non-x86_64
> architectures in our packages. While our official infrastructure for
> non-x86 support isn&
Carsten Haitzler on Wed, 2025/07/02 11:00:
> Next releases of anything I maintain shall be going arch=(any) as
> everything I maintain is fully portable anyway and always has been. My AUR
> pkgs already have a host of arch's in them and i'll simplify to any. No
> other changes needed.
That's prob
On Tue, 1 Jul 2025 17:57:37 +0200 Levente Polyak said:
> # First step for non-x86_64 contributions
>
> Hey everyone,
>
> I'd like to share my view on the first step for targeting non-x86_64
> architectures in our packages. While our official infrastructure for
> n
On 2025-07-01 18:56:05 (+0200), Levente Polyak wrote:
> On 7/1/25 6:44 PM, David Runge wrote:
> > > ### Merge-request indicator
> > >
> > > All secondary architecture related merge-requests must be flagged with the
> > > new `pkg::ports` GitLab label. It'll help separate them from the usual
> > >
On 7/1/25 6:44 PM, David Runge wrote:
### Merge-request indicator
All secondary architecture related merge-requests must be flagged with the
new `pkg::ports` GitLab label. It'll help separate them from the usual
requests and allow interested packagers and contributors to filter on them
globally,
Hey Levente,
On 2025-07-01 17:57:37 (+0200), Levente Polyak wrote:
> There's already a ton of community interest and effort around non-x86_64.
> There's plenty of low hanging fruits and clean patches that are easy to
> review, well contained, and good groundwork. So instead of waiting for the
> pe
# First step for non-x86_64 contributions
Hey everyone,
I'd like to share my view on the first step for targeting non-x86_64
architectures in our packages. While our official infrastructure for
non-x86 support isn't ready yet and will still take some time to
materialize, I'd
14 matches
Mail list logo
