> On 3 Dec 2022, at 07:09, Michał Górny wrote:
>
> Hi,
>
> I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug
> states with a simple NEW state. Why?
>
> 1. Only a handful of developers actually uses these two statuses
> in a meaningful way.
>
> 2. Some users are
# Hans de Graaff (2022-12-03)
# ruby27-only packages. No recent releases. No reverse dependencies
# anymore. Maksed for removal in 30 days.
dev-ruby/rspec-retry
signature.asc
Description: This is a digitally signed message part
Hi,
I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug
states with a simple NEW state. Why?
1. Only a handful of developers actually uses these two statuses
in a meaningful way.
2. Some users are confused and demotivated by having their bugs stay
UNCONFIRMED for a long
Signed-off-by: Michał Górny
---
eclass/app-alternatives.eclass | 84 ++
1 file changed, 84 insertions(+)
create mode 100644 eclass/app-alternatives.eclass
PR with examples: https://github.com/gentoo/gentoo/pull/28515
diff --git a/eclass/app-alternatives.eclass
On Sat, 3 Dec 2022, Haelwenn (lanodan) Monnier wrote:
Well Alpine is using the ecl route:
https://git.alpinelinux.org/aports/tree/community/sbcl/APKBUILD
And GNU GuixSD is using the clisp route but per the comments ecl would be
better:
On Sat, 2022-12-03 at 02:59 +0100, Haelwenn (lanodan) Monnier wrote:
> [2022-12-02 05:11:15+] Andrey Grozin:
> > In principle, one can try a workaround: use some other lisp (say, clisp or
> > ecl) as the bootstrap lisp. This way is at best brittle: there is no
> > guarantee that these external
[2022-12-02 05:11:15+] Andrey Grozin:
In principle, one can try a workaround: use some other lisp (say, clisp or
ecl) as the bootstrap lisp. This way is at best brittle: there is no
guarantee that these external lisps will compile the sbcl sources
successfully. People say that sometimes this
# Oz Tiram (2022-12-03)
# Mate-desktop no longer supports gtk+:2, so there is
# no need for this package. Removal on 2023-01-03.
x11-themes/mate-themes-meta
signature.asc
Description: Message signed with OpenPGP
Alec Warner wrote:
> Currently mgorny is the listed maintainer of boa. What if instead of a
> bunch of CVEs he just decided he had better things to do with his
> time.
> He last-rites the package, giving a 90d deadline for the package to
> find a new owner.
> No one cares to maintain boa, so no
On Fri, Dec 2, 2022 at 11:28 AM Peter Stuge wrote:
>
> Andrey Grozin wrote:
> > This means that no user of the musl profiles has ever been able to emerge
> > all these packages (because they did not have sbcl). And all these
> > packages should be pmasked in the musl profiles.
>
> Is the last
> On 2 Dec 2022, at 19:28, Peter Stuge wrote:
>
> Andrey Grozin wrote:
>> This means that no user of the musl profiles has ever been able to emerge
>> all these packages (because they did not have sbcl). And all these
>> packages should be pmasked in the musl profiles.
>
> Is the last
On Fri, Dec 02, 2022 at 08:30:03PM +, Peter Stuge wrote:
> John Helmert III wrote:
> > > > There are multiple CVEs for it, is it really on us to discriminate
> > > > between which CVEs are valid and which are not?
> > >
> > > Yes.
> ..
> > > > We can't possibly hope to do that accurately in
On Fri, Dec 2, 2022 at 12:30 PM Peter Stuge wrote:
>
> John Helmert III wrote:
> > > > There are multiple CVEs for it, is it really on us to discriminate
> > > > between which CVEs are valid and which are not?
> > >
> > > Yes.
> ..
> > > > We can't possibly hope to do that accurately in all
John Helmert III wrote:
> > > There are multiple CVEs for it, is it really on us to discriminate
> > > between which CVEs are valid and which are not?
> >
> > Yes.
..
> > > We can't possibly hope to do that accurately in all cases.
> >
> > Some times it will be easy, other times less easy.
..
>
Andrey Grozin wrote:
> This means that no user of the musl profiles has ever been able to emerge
> all these packages (because they did not have sbcl). And all these
> packages should be pmasked in the musl profiles.
Is the last sentence actually true?
Shouldn't only ebuilds with actual
On Fri, Dec 02, 2022 at 06:29:28PM +, Peter Stuge wrote:
> John Helmert III wrote:
> > So much yapping on the mailing lists, and no response in the bug which
> > triggered the last rites...
>
> Apologies if I responed in the wrong forum. I thought on list would
> be good, why are those mails
John Helmert III wrote:
> So much yapping on the mailing lists, and no response in the bug which
> triggered the last rites...
Apologies if I responed in the wrong forum. I thought on list would
be good, why are those mails on the list if not?
> So, Peter, do you use Boa?
Not right now, but I
So much yapping on the mailing lists, and no response in the bug which
triggered the last rites...
So, Peter, do you use Boa? If you do, what niche does it fill that
isn't filled by anything else? There are multiple CVEs for it, is it
really on us to discriminate between which CVEs are valid and
On Fri, Dec 2, 2022 at 12:20 PM Peter Stuge wrote:
> If you wanted to encourage me to become a Gentoo developer and (among
> other things) improve the lastriting process then you missed the mark,
> in fact your behavior consistently remains one strong reason for me
> to *not* become a Gentoo
Michał Górny wrote:
> > Shouldn't this process work a lot better?
>
> Processes tend to work better when people are contributing towards
> making the processes work better rather than complaining from their
> comfy armchairs that they tend to confuse with thrones.
LOL!
Are you honestly arguing
Thanks, I now understand what pathlib2 does, but more importantly found
out it is not really needed in that case making the fix even easier =)
On Fri, Dec 02, 2022 at 11:35:06AM +0100, Andrew Ammerlaan wrote:
Hi,
Pathlib2 is a backport, as such it doesn't really make sense to add 3.10 and
Hi,
Pathlib2 is a backport, as such it doesn't really make sense to add 3.10 and
3.11 to compat. The package from the overlay probably should adjust its
dependencies to only depend on pathlib2 when instaling for 3.9 or 3.8. This can
be accomplished with the python_gen_cond_dep function (see
> The sbcl ebuild from the Gentoo tree is useless on musl. And hence it
should be masked. Otherwise somebody would think that [s]he can simply
emerge sbcl on a musl profile, and will be disappointed.
Ah, I see. That makes sense, and I think I can just unmask it in my
custom musl profile.
Thanks!
On Fri, 2 Dec 2022, Tom Gillespie wrote:
For the record I've had sbcl building and running on musl for months
without issue (at one point I even had static linking working). You
have to cross compile a musl version and then side load the binary
instead of using one of the distributed binaries.
For the record I've had sbcl building and running on musl for months
without issue (at one point I even had static linking working). You
have to cross compile a musl version and then side load the binary
instead of using one of the distributed binaries. See
Hi all,
I noticed that a package from an overlay fails to install due to it
requiring pathlib2 with python_targets with 3.10 and/or 3.11. So I
checked pathlib2's setup.py [0] that it supports newer python versions
and wanted to update the ebuild, but noticed
My question is whether I should:
On Fri, 2 Dec 2022, Sam James wrote:
If the dependencies are optional (at least for some), we should indeed
(package.)use.mask sbcl on musl to reduce the damage,
then package.mask the remaining unconditional reverse dependencies.
But I cannot do these this myself. I use neither musl nor ros. I
27 matches
Mail list logo
