On Thu, 19 Mar 2020 03:07:21 +0100
Thomas Deutschmann wrote:
> Why can't we use "ALLARCHES" stabilization for that?
Because that experiment basically failed.
Bugs with that flag, basically were treated (repeatedly) like that flag
wasn't there.
And that approach still has the weakness of it bei
On Wed, 18 Mar 2020 09:54:42 -0500
William Hubbs wrote:
> So, my question is, why can't we add a noarch/~noarch keyword and see
> how things go? If it gets abused we can always nuke it later.
>
> Thanks,
I'm just gonna say I disagree with this proposal as stated.
Stability and arch support, fo
Hi,
please don't introduce another keyword.
Why can't we use "ALLARCHES" stabilization for that?
However, this will getting more complicated than it will help.
Any Python package which compiles something can fail. During my x86 work
I have seen a lot of problems when it comes to anything math re
On Wed, 18 Mar 2020 17:52:25 +
James Le Cuirot wrote:
> Not quite. Tools like repoman will need to be updated to understand
> that an ebuild with KEYWORDS="amd64" can depend on another ebuild with
> only KEYWORDS="noarch". I do think the idea has merit though.
But the inverse is _not_ true,
On Wed, 18 Mar 2020 11:59:25 -0500
William Hubbs wrote:
> Sure, but if you run into something like that you just don't use the
> noarch keyword for those packages.
But as soon as this happens, all dependent packages that are noarch
will need to also transition to not using no-arch.
So it turn
On Wed, Mar 18, 2020 at 4:16 PM Mart Raudsepp wrote:
>
> > @@ -1,6 +1,6 @@
> > -# Copyright 1999-2014 Gentoo Foundation
> > +# Copyright 1999-2020 Gentoo Foundation
> > # Distributed under the terms of the GNU General Public License v2
> >
> > -USE="systemd udev"
> > +USE="systemd udev user-sessi
> @@ -1,6 +1,6 @@
> -# Copyright 1999-2014 Gentoo Foundation
> +# Copyright 1999-2020 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
>
> -USE="systemd udev"
> +USE="systemd udev user-session"
>
> BOOTSTRAP_USE="${BOOTSTRAP_USE} systemd udev"
Seems good
Signed-off-by: Matt Turner
---
.../linux/amd64/17.0/desktop/plasma/systemd/package.use| 7 ---
.../linux/amd64/17.1/desktop/plasma/systemd/package.use| 7 ---
.../linux/arm/17.0/desktop/plasma/systemd/package.use | 7 ---
.../linux/arm64/17.0/desktop/plasma/systemd/packag
> So, my question is, why can't we add a noarch/~noarch keyword and see
> how things go? If it gets abused we can always nuke it later.
I'm pretty sure we already discussed this in very much detail in the past at
least once, and came to the conclusion that there are problems with that
approach.
Am Mittwoch, 18. März 2020, 19:40:57 CET schrieb William Hubbs:
> There would be no need to cc all arches on the bug, just make noarch@g.o
> an alias that emails to all arch teams.
We might as well just make an allarches@... alias.
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
# Michał Górny (2020-03-18)
# Unmaintained. Version bump pending. No Python 3 support upstream.
# Removal in 30 days. Bug #708268.
app-backup/buttersink
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
On Wed, Mar 18, 2020 at 07:12:08PM +0100, Michał Górny wrote:
> On Wed, 2020-03-18 at 12:47 -0500, William Hubbs wrote:
> > On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote:
> > > On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:
> > > > this came up again on the recent thread abo
On Wed, Mar 18, 2020 at 05:52:25PM +, James Le Cuirot wrote:
> On Wed, 18 Mar 2020 12:47:53 -0500
> William Hubbs wrote:
>
> > On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote:
> > > On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:
> > > > this came up again on the recent
On Wed, 2020-03-18 at 12:47 -0500, William Hubbs wrote:
> On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote:
> > On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:
> > > this came up again on the recent thread about dropping non x86/amd64
> > > support for python packages, and I wan
On Wed, 18 Mar 2020 12:47:53 -0500
William Hubbs wrote:
> On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote:
> > On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:
> > > this came up again on the recent thread about dropping non x86/amd64
> > > support for python packages, and I
On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote:
> On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:
> > this came up again on the recent thread about dropping non x86/amd64
> > support for python packages, and I want to bring it up again on its own
> > thread.
> >
> > How often
On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:
> this came up again on the recent thread about dropping non x86/amd64
> support for python packages, and I want to bring it up again on its own
> thread.
>
> How often do architecture specific bugs really exist in languages like
> perl, pyth
On Wed, Mar 18, 2020 at 05:11:17PM +0100, Rolf Eike Beer wrote:
> Am 2020-03-18 15:54, schrieb William Hubbs:
> > All,
> >
> > this came up again on the recent thread about dropping non x86/amd64
> > support for python packages, and I want to bring it up again on its own
> > thread.
> >
> > How o
Am 2020-03-18 16:10, schrieb Jaco Kroon:
Hi,
I'd be in support. Especially for "data only" kind of packages, like:
net-misc/asterisk-moh-opsound
net-misc/asterisk-extra-sounds
net-misc/asterisk-core-sounds
My immediate target was aspell dictionaries and fonts.
Am 2020-03-18 15:54, schrieb William Hubbs:
All,
this came up again on the recent thread about dropping non x86/amd64
support for python packages, and I want to bring it up again on its own
thread.
How often do architecture specific bugs really exist in languages like
perl, python etc? From wha
Hi,
I'd be in support. Especially for "data only" kind of packages, like:
net-misc/asterisk-moh-opsound
net-misc/asterisk-extra-sounds
net-misc/asterisk-core-sounds
For all three these I've already dropped the DEPEND on net-misc/asterisk
anyway, and upgraded the PDEPEND on net-misc/asterisk bac
All,
this came up again on the recent thread about dropping non x86/amd64
support for python packages, and I want to bring it up again on its own
thread.
How often do architecture specific bugs really exist in languages like
perl, python etc? From what I've seen they are pretty rare. Not to menti
22 matches
Mail list logo
