Joonas Niilola wrote:
> some of you may already have seen the new packages.gentoo.org page,
> https://packages.gentoo.org/
I had not seen that - that's wonderful!
I would just request that /packages/ is removed from the start of
package URLs. I understand how this makes request routing more
com
Michał Górny wrote:
> Read: it's important to slap users to satisfy developer's wannabes.
LOL! Michał, you managed to squeeze both misrepresentation and ad hominem
into so few words. Please take care. Anyway, you missed my point:
It's important that (the project) developers set accurate expectati
Andreas K. Hüttel wrote:
> it's probably time to deprecate the amd64 17.0 profiles!
I for one am not so excited about the amd64 17.1 profiles. On the surface
it appeared to me that one developer has "taken over" just about everything,
which (regardless of the individual) can't be a good thing..
Georgy Yakovlev wrote:
> I'll be switching default tmpfiles provider to sys-apps/systemd-tmpfiles
> by the end of the week by updating virtual/tmpfiles ebuild.
Michael Orlitzky wrote:
> Corollary: the tmpfiles.d specification can only be implemented (safely)
> on Linux after all.
So should virtua
Paul B. Henson wrote:
> Would it be possible to have a use flag such as 'libtlsonly' or whatever
> for the ebuild which only installs libtls,
Sure.
> Or have a separate ebuild just for libtls (which couldn't
> be installed with the full libressl ebuild or vice versa)
That's also technically p
Michał Górny wrote:
> I would like to discuss the possibility of discontinuing LibreSSL
> support in Gentoo in favor of sticking with OpenSSL.
I think that's a horrible idea, since Gentoo is about choice and this
particular component is one of the most important in a system.
But "support" can mea
Michał Górny wrote:
> > A. It is a distinct implementation with probably /quite some/ stable
> > compatibility, meaning that it will work perfectly fine as an
> > alternative in many cases.
>
> Except that it doesn't, as has been proven numerous times.
I'm sure that there are numerous cases where
Michał Górny wrote:
> > I'm sure that there are numerous cases where libressl doesn't work,
> > but that's no reason to dismiss cases where it *does*.
>
> Are you asking people to put an effort into maintaining something that
> can't be practically installed?
No, I'm rather asking to change the l
Michał Górny wrote:
> 1. Stuff that does not build against LibreSSL.
> 2. Stuff that builds just fine but fails at runtime in unpredictable
> ways (e.g. Tor mentioned today).
> 3. Stuff that builds and works 'fine' but ends up being crippled (e.g.
> doesn't support new algorithms).
>
> The first o
Michał Górny wrote:
> > net-misc/openntpd
>
> I've just tested it and it builds fine against dev-libs/libretls.
I hope you're not planning to suggest that dev-libs/libretls should
be the only libtls on Gentoo, since that would be an arbitrary and
artificial limitation - the very opposite of choic
Michał Górny wrote:
> > 2. Install them into different prefixes (eg /usr/lib/openssl +
> > /usr/lib/libressl and have the linker link to a specific version,
> > /usr/include/{openssl,libressl} too).
>
> For the record, this is something I've been wondering about for a long
> time. However, there
David Seifert wrote:
> > > I mean, you have to explicitly support the choice in ebuilds,
> > > and this means making things even harder for newcomers.
> >
> > pkg-config/pkgconf and .pc files can help with this part, taking care
> > of all abstraction if/when downstream uses a libressl.pc.
>
> As
Andreas K. Huettel wrote:
> > I agree completely that it's unreasonable for Gentoo (worse, 1 person!)
> > to continuosly patch the entire world for libressel.
> >
> > I'm asking to stop doing that, yet still enable the choice between
> > openssl and libressl where that is possible without patches,
Matt Turner wrote:
> > I think many mails in this thread suffer from some tunnel vision, expecting
> > that a libressl ebuild in the tree must continue to work exactly like the
> > openssl ebuild - I'm saying to stop that but do keep a libressl ebuild.
To clarify, by "stop that" I mean "stop effor
Michał Górny wrote:
> > I would be happier if some other developers were able and willing to
> > participate actively in the LibreSSL project.
>
> But why would they do that? What I'm really missing in all the replies
> is a single reason why LibreSSL would be better for anyone.
Maybe because it
David Seifert wrote:
> > Maybe because it is so well-known that monoculture is harmful per se,
> > which is why the commitment to choice in Gentoo is very valuable.
> >
> > Further, LibreSSL comes out of the OpenBSD project, which has a good
> > reputation on code quality.
>
> Like strong-arming
We could clearly discuss forever, but since you refuse to engage with
my constructive proposition and my ask for feedback there's no point,
is there? It's super sad that you behave like that in Gentoo.
Michał Górny wrote:
> Choice for the sake of choice is meaningless.
Far from it.
> So far no
Michał Górny wrote:
> let's summarize what was said so far.
Thanks for the good summary!
> I think the three main ways forward from here would be to either:
>
> 1. Keep LibreSSL for indefinite time (possibly masked)
> 2. Eventually move LibreSSL to libressl overlay.
> 3. Eventually remove Libre
Michał Górny wrote:
> > > I think the three main ways forward from here would be to either:
> > >
> > > 1. Keep LibreSSL for indefinite time (possibly masked)
> > > 2. Eventually move LibreSSL to libressl overlay.
> > > 3. Eventually remove LibreSSL.
> >
> > 4. A libressl or libressl-libtls ebuil
Mike Gilbert wrote:
> > It is important to me that you can choose dev-libs/libretls instead of
> > having any libretls code on your systems, but I reject you forcing that
> > choice of yours on everyone else.
>
> I'm having trouble making sense of this sentence. Did you mean to
> write "libressl"
Hi Jaco,
Jaco Kroon wrote:
> So a few points that I picked up during this discussion.
>
> 1. Nobody is AGAINST libressl per sé,
Michał gives me a distinctly different impression.
> 2. A number of people are AGAINTS the effort involved to make
> libressl work for various packages.
Yes, and I
Alessandro Barbieri wrote:
> > Obviously this will only be useful for packages wanting to statically link
> > with libressl lib{crypto,ssl}
>
> There is an ongoing effort to remove static libraries from packages.
I know, and I couldn't disagree more with that effort.
> > but I think that's far
Jaco Kroon wrote:
> > I can think of two ways of solving it:
> >
> > 1. We could patch system-installed libtool to respect environment
> >
> > 2. We could regenerate libtool and force local instance of libtool
> > in the packages needing it.
>
> 3. Have it always use some fixed compiler somewhere
Aisha Tammy wrote:
> We are now in the process of cleaning up GTK:2 ebuilds and moving the
> packages to use GTK:3 and drop GTK:2 support.
Quoting the blog post you linked to: (thanks for including the link!)
"It does mean, however, that GTK 2 has reached the end of its life.
We will do one fina
Peter Stuge wrote:
> We will do one final 2.x release in the coming days, and we encourage
> everybody to port their GTK 2 applications to GTK 3 or 4."
>
>
> The recommendation in the blog post is for application developers to
> port to 3 or 4, nothing more and nothin
Hanno Böck wrote:
> > "It does mean, however, that GTK 2 has reached the end of its life.
> > We will do one final 2.x release in the coming days, and we encourage
> > everybody to port their GTK 2 applications to GTK 3 or 4."
>
> I read that as there will be one more gtk2 release and none after
John Helmert III wrote:
> > Until there's a relevant flaw that will remain unfixed or there is
> > significant incompatibility with infrastructure (recurse my argument)
> > no signs actually exist.
>
> Waiting until such a problem pops up and bites everyone before doing
> anything about it doesn't
Joonas Niilola wrote:
> There's a script by jkroon in data/api.git
> (https://gitweb.gentoo.org/data/api.git/) that prints the next available
> UID/GID pair for new acct-* packages.
This is super nice! Thanks a lot jkroon!
> It is not forbidden to mix and mash UID/GID between different packages,
Michał Górny wrote:
> I'm seriously wondering why I'm wasting so much effort on open source.
Open source only ever works when taking responsibility for one's problems.
> I don't see a good way out of it.
I see a couple. Of course all require some effort.
One was already mentioned; move Gentoo
Mike Gilbert wrote:
> > > The first big blocker we're going to hit is trustme [3] package that
> > > relies on cryptography API pretty heavily to generate TLS certs for
> > > testing.
> >
> > For which testing? Could it be changed to generate certs differently?
>
> He is probably referring to the
Hi,
Gerion Entrup wrote:
> the Linux kernel has _a lot of_ configuration options, way too many to
> configure them by hand.
I actually disagree strongly with that; I think it's important to
actively decide what kernels include, and I routinely do, but of
course not everyone will. I've made sure
Great idea and happy anniversary! :)
Roy Bamford wrote:
> Here's where I reed your help.
I can't help with that.
Roy Bamford wrote:
> I have a similar media problem with a pile of 5 1/4" floppies. A have a
> drive that reads all the 5 1/4" formats and a motherboard to connect it
> to ... unti
Mike Gilbert wrote:
> The base system project is dropping LILO: it really needs to be
> maintained by someone who actually uses it.
I also use it.
Hank Leininger wrote:
> I still use/prefer LILO; I'll take a look at the open bugs and
> consider submitting PRs for them & taking on p-m of it.
Hank
Hi Joshua,
Joshua Kinard wrote:
> > The base system project is dropping LILO: it really needs to be
> > maintained by someone who actually uses it.
>
> I'll claim it.
Awesome, thanks a lot.
> Never took a liking to GRUB. Simpler is better
+1
> However, I am very time-limited, so I will def
David Seifert wrote:
> mail-filter/bogofilter
In principle I'm interested in proxy-maintaining this but do not have
cycles immediately.
The current ebuild has little special stuff so probably also works for
the #763024 bump without much change - though I'd like to rework the
rather messy databa
Sam James wrote:
> * Brings IDEPEND, usev enhancements, --disable-static by default, and more!
How to undo that --disable-static ?
I'm asking both for my own ebuilds and as a regular portage user.
//Peter
Rolf Eike Beer wrote:
> The previous algorithm would scan for all primes for a given number,
> which takes needlessly long.
Please also mention how this caused a problem for you in the commit
message, to help us understand why you're proposing to change this.
> +++ b/eclass/qmail.eclass
> -# @FU
Matt Turner wrote:
> If you can find a case where you wouldn't want to enable one of these
> USE flags, please let me know and I'll reconsider my position.
My catalyst spec files all have use: -* foo bar x y z
specifically because the defaults are never what I want for any given
system. I build d
Matt Turner wrote:
> > > If you can find a case where you wouldn't want to enable one of these
> > > USE flags, please let me know and I'll reconsider my position.
> >
> > My catalyst spec files all have use: -* foo bar x y z
> > specifically because the defaults are never what I want for any give
Ben Kohler wrote:
> Nobody is "disabling choice" here,
Fair! Sorry about the hyperbole.
> a change in defaults doesn't remove your ability to choose something else.
True. My argument is more specificically that setting USE flags by
default in a "low-level" profile goes in the wrong direction.
Marco Scardovi wrote:
> mail-filter/bogofilter
I'd like to proxy-maintain this.
//Peter
Alice wrote:
> +++ b/eclass/kernel-2.eclass
..
> - PYTHON_COMPAT=( python2_7 )
> + PYTHON_COMPAT=( python3_{7..10} )
From
https://www.fsfla.org/pipermail/linux-libre/2020-August/003404.html
it seems that it may be possible to need only very simple tool
Sam James wrote:
> > https://www.fsfla.org/pipermail/linux-libre/2020-August/003404.html
> >
> > it seems that it may be possible to need only very simple tools for the
> > deblob program(s).
>
> Instead of linking to a huge release announcement, could you summarise it?
Fair enough - though the
Joshua Kinard wrote:
> Hmm, it looks like dropbear is relying heavily on the ecc/ecdsa functions
> provided in libtomcrypt, and that library's homepage states all its code is
> public domain. Our ebuild has no bindist restrictions on that library.
> Perhaps that is how dropbear, and thus Red Hat,
Joshua Kinard wrote:
> > I'm not entirely sure what you'd like to ask the libtomcrypt authors.
> > "We think there may be patents, but we don't know. Did you consider
> > that?"
>
> No, actually, I was thinking something more along the lines of "Hey, are you
> aware of these supposed patent claims
Mike Gilbert wrote:
> It's a waste of time and effort to pepper random ebuilds with checks
> for options that everyone should have enabled in the first place.
It's not for you to say what everyone should have enabled in their kernel.
There's significant value in ebuilds documenting required kerne
Robin H. Johnson wrote:
> We have some set of packages (A) which collectively depend on one or
> more kernel options being set in specific ways, and the options need to
> REMAIN set if you want the packages to continue work.
..
> Can we consider moving the checks for set A somewhere else, such that
Mike Gilbert wrote:
> > > It's a waste of time and effort to pepper random ebuilds with checks
> > > for options that everyone should have enabled in the first place.
> >
> > It's not for you to say what everyone should have enabled in their kernel.
>
> Do you not agree that there are some options
Mike Gilbert wrote:
> The current (proxied) maintainer is somewhat difficult to work with
Why is Arfrever being treated so bad here? To me, it looks like
you're the one who is difficult to work with. :\
Jakov Smolić wrote:
> From what I've investigated, other major distributions don't apply
> an
501 - 549 of 549 matches
Mail list logo
