m1027 wrote:
> Wow, wasn't aware of catalyst at all. What a beast in terms of control.
It's not so well-known maybe because it was created by and for
gentoo-releng but if you know what you want it's a fantastic tool.
> (FYI: I enjoyed the links on catalyst you sent me directly.
> Unfortunatelly
Peter Stuge wrote:
> Essentially you will be maintaining a private fork of gentoo.git,
If this seems too heavy handed then you can just as well do the reverse:
Maintain an overlay repo with the packages you care to control in the
state you care to have them, set that in the catalyst stage4.s
Hi,
m1027 wrote:
> So, what we've thought of so far is:
>
> (1) Keeping outdated developer boxes around and compile there. We
> would freeze portage against accidental emerge sync by creating a
> git branch in /var/db/repos/gentoo. This feels hacky and requires a
> increating number of develper
Hi Marco,
mscard...@icloud.com wrote:
> Looking at packages seems there’s not any package strictly related
> to net (tell me if You think some of these should remains to it).
..
> things more common-used like cups).
cups certainly has a network component both as server and as client.
It's one
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
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
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
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
John Helmert III wrote:
> # John Helmert III (2022-11-27)
> # Unmaintained upstream, several unresolved public vulnerabilities,
> # Removal in 30 days. Bug #882773.
> www-servers/boa
This is bogus, please revert.
Who are you to declare unmaintained? It's a simple program so maybe
it simply
John Helmert III wrote:
> > Searching for the repo name on GitHub finds this however:
> >
> > https://github.com/bdrewery/vchkuser
> >
> > ..which seems to be a 2010 version of the code. I did a test, it works
> > fine. Maybe just change the SRC_URI.
>
> Can you produce a guarantee that the
John Helmert III wrote:
> > Jonas Stein wrote:
> > > # Dead upstream
> > > # Removal after 2023-01-01. Bug #881249.
> > > net-mail/vchkuser
> >
> > Was there an actual issue with the package that prompted you to do
> > this - something that a package maintainer should have resolved?
> >
> > I
Jonas Stein wrote:
> # Dead upstream
> # Removal after 2023-01-01. Bug #881249.
> net-mail/vchkuser
Was there an actual issue with the package that prompted you to do
this - something that a package maintainer should have resolved?
I think it's a bad idea to remove a package if "Upstream
Mikhail Koliada wrote:
> This idea has been fluctuating in my head for quite a while given
> that the migration had happened a while ago [0] and some other
> major distributions have already adopted yescrypt as their default algo
> by now [1].
Please only do that based on proven merit and nothing
Matt Turner wrote:
> repoman is inferior to other tooling mentioned. The other tooling is
> actually run in CI.
The problem seems to be that CI is running something other than
developers run, not the other way around.
> Developers should get the same warnings locally as in CI.
I agree. And
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
>
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
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
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
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
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,
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
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
Marco Scardovi wrote:
> mail-filter/bogofilter
I'd like to proxy-maintain this.
//Peter
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.
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
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
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
> -#
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
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
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
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.
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 ...
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
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
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
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
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
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
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 no
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
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
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
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
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"
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
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
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
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
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
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
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
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.
>
>
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,
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
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
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
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
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
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
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
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..
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
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
Jimi Huotari wrote:
> # Jimi Huotari (2020-08-04)
> # No consumers since 2015, and no known stand-alone use.
> # Removal in 30 days.
> dev-libs/liboobs
Wut - isn't that a really poor reason to remove from the tree? :\
Why not just keep it unless there is an actual technical problem?
(Security,
Remco Rijnders wrote:
> I'd like to volunteer myself as proxy maintainer for this package. As
> this would be the first package in gentoo I'd be working on, I ask for
> advice on the following two points:
Note that I'm no developer but have been proxy-maint for some time.
> - Can the removal of
Benda Xu wrote:
> > I was wondering if the openbsd prefix support is something
> > that is still garnering any interest from gentoo?
>
> There is still interest in Gentoo. But no one seems to have energy to
> take care of it.
FWIW I have interest in this as well.
> Your contribution is
Kent Fredric wrote:
> > While services such as reCAPTCHA are (as said) massively intrusive, there
> > are other, much less intrusive and even terminal-compatible ways to
> > construct
> > a CAPTCHA. Hello game developers, you have 80x23 "pixels" to render a puzzle
> > for a human above the
Michał Górny wrote:
> Hence my question: do you find 'do not remove kernels listed
> in bootloader config' feature useful? Do you think it should remain
> the default? Do you think it is worthwhile to continue supporting it?
I continue to use LILO because simpler and more mature code is good,
Stop motivated attackers or keep low barrier to entry; pick any one. :)
Michał Górny wrote:
> CAPTCHA
> ==
> A traditional way of dealing with spam -- require every new system
> identifier to be confirmed by solving a CAPTCHA (or a few identifiers
> for one CAPTCHA).
>
>
Hi,
I'm trying something out over here and I'm surprised to find that
acct-group/* do not work with ROOT+SYSROOT != "/".
Should I file yet another bug about this?
I suppose the limitation is in user.eclass, but what about the 11 bugs
already filed about exactly this problem?
They are easy to
Kent Fredric wrote:
> Syntax above not expected verbatim, just food for thought,
I think this is a really good and useful idea. I would love to see it.
> the nature of this metadata is that it SHOULD NOT be in the ebuild
> itself, as it is inherently "repo based", the installed values of
>
James Le Cuirot wrote:
> Damn, I realised just as I hit send that there's a caveat here and
> that's sub-dependencies. If you're building a partially static binary
> then I think you're okay. A fully static binary obviously needs all its
> dependencies to be static and that includes any
Mike Gilbert wrote:
> Do the users actually need home directories?
Technically probably no, but ~qmail is easier to type than /var/qmail.
TBH I actually always type it out anyway.
Mike Gilbert wrote:
> If you don't want to maintain them, you'll need to find someone else
> to do it.
If noone
Rich Freeman wrote:
> Is there a large population that actually runs x86 on modern
> hardware, or is ancient hardware a significant use case?
There are current products with pre-686 instruction sets.
Companies such as DM still produce 586-class SoCs for embedded and
industrial. These[1][2] are
Hi Thomas, I suggest some improvements..
Thomas Deutschmann wrote:
> Title: OpenSSH LDAP support
Perhaps qualify this a bit, e.g. "Migration required for OpenSSH with LDAP"
> When your sshd authenticates against LDAP, you have to migrate your
s,When,If,
> current setup to a new one using
Mart Raudsepp wrote:
> > * USE=udev means different things for different packages. You think
> > it "makes udev work" or whatever, but nobody has any idea what it
> > does for half of the packages that use it. The meaning is package-
> > specific, so the default should be package-specific.
>
M. J. Everitt wrote:
> I'm thinking something along the lines of the following:
> - Line one is limited to / and some Key Word that defines the
> type of change made, similar to bugzilla perhaps eg. "REVBUMP, VERBUMP,
> EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get around the
> issue
Johannes Huber wrote:
> I will take it.
Thanks. I can help as proxy-maintainer if you like.
//Peter
William Hubbs wrote:
> The first change is that ROOTPATH is no longer set. This means all of
> the *sbin directories will be added to the default path for all users
> instead of just the root user.
Maybe add a sentence about why this is changing or even neccessary,
to avoid perception of weakened
Maybe this is a discussion for -project, then?
Andreas K. Huettel wrote:
> a few outside trolls who
> * keep pushing their personal agenda in endless threads,
> * confuse their own inability to contribute with being a mistreated underdog,
> * and keep commenting opinionated on technical things
Andreas K. Huettel wrote:
>
> Independent of whether William now unsubscribed or not, he's now enjoying a
> lengthy (1 year until review) vacation from all Gentoo communication channels.
>
I don't understand two things about Gentoo:
1. style: How can anyone consider "enjoying a vacation" to
Daniel Campbell wrote:
> On Sun, Dec 03, 2017 at 12:18:04AM +0100, Michał Górny wrote:
> > I'd like to establish the following changes to the mailing lists:
> >
> > 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be
> > initially restricted to active Gentoo developers.
>
> I
William L. Thomson Jr. wrote:
> No one questions why I stepped down.
I have wondered what happened, but haven't felt able to investigate.
Please know that I wouldn't take sides without investigating, and I
think that an overwhelming majority is also like that. A problem is
that you'll only ever
I'm quite unimpressed by how mgorny and jstein behave there.
I wouldn't accept that, were I leading the project.
//Peter
Hi Michał,
Michał Górny wrote:
> major problems with some of the posters for more than a year.
Please believe me when I say that I know what this feels like.
I want to applaud and thank everyone who has been tackling/discussing
this issue in private, and I especially want to applaud taking
William L. Thomson Jr. wrote:
> Or uber minimal, can't get much smaller still 5.20s
> https://travis-ci.org/Obsidian-StudiosInc/asspr#L165
> https://github.com/Obsidian-StudiosInc/asspr/blob/master/configure.ac
Consider
AM_INIT_AUTOMAKE([foreign no-define no-installinfo no-installman])
foreign
William L. Thomson Jr. wrote:
> Or uber minimal, can't get much smaller still 5.20s
> https://travis-ci.org/Obsidian-StudiosInc/asspr#L165
> https://github.com/Obsidian-StudiosInc/asspr/blob/master/configure.ac
That takes 2.0s here, on quite old hardware, though with primed cache.
>
William L. Thomson Jr. wrote:
> I cannot understand why systems get faster, yet configure seems to
> take the same amount of time and is super slow.
The generated configure scripts can be fork intensive, which is still
fairly expensive.
But I think the problem is more with poorly written
Martin Vaeth wrote:
> > 1. Doing a full clean build [..] the speed of make or ninja is hugely
> > offset by the compilation speed, and their overhead is negligible.
>
> It depends on the definition of negligible. For huge projects like
> boost or chromium it is several minutes
It's arguably a
William L. Thomson Jr. wrote:
> > If you have any suggestions as to what I should look at to better
> > understand the OpenJDK build system I would very much appreciate
> > them.
..
> Build OpenJDK stand alone. Get familiar with that.
It used to be that one could not build OpenJDK without already
Michał Górny wrote:
> W dniu nie, 23.07.2017 o godzinie 16∶13 +0200, użytkownik Manuel Rüger
> napisał:
> > dev-libs/libgit2
>
> I'm going to co-maintain this with the full set (-glib, pygit2). I've
> used it in the past, and I think it'll still come in handy
> in the future.
I too have some
Alexander Berntsen wrote:
> While the PMS perhaps hasn't been an unequivocal success, it's still a
> good effort with some success. I would be disappointed to see the
> proposed change, and view it as a bad sign for Gentoo.
As far as technical documentation about how ebuilds work (the core of
Michael Orlitzky wrote:
> All this is to say that "easy to read" is in the eye of the beholder.
> For ebuilds in the tree, the beholder is usually the maintainer, which
> is why I think the choice should be left up to him.
I think what mgorny says is that locality of ebuilds is an important
Michael Palimaka wrote:
> The 30 day waiting period is useful for smoking out major upstream bugs,
> but can't replace stabilisation integration testing. For example,
> package foobar may build fine in ~arch but fails in stable because it
> needs a newer libbaz.
So that's either because of an
Good work on the refactoring!
Alexis Ballier wrote:
> > > if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then
> >
> > It’s always been recommended to me that we should use the [[ … ]]
> > form.
>
> Doesn't make much difference here
Some; you need neither quote nor {} in expansions within [[
Thank you for working on this.
Sergei Trofimovich wrote:
> Can this proposal make a difference and make gentoo better and
> easier to work with?
>
> Does it try to attack the right thing?
>
> Does it completely miss the point?
I hold a perhaps radical view: I would like to simply remove
Hi,
I have some ebuilds which use enewuser to create groups and users in
pkg_setup(), and make use of those groups and users in src_install()
in exeopts, insopts etc.
Is there any reason that this would not always work reliably with
binpkgs?
Ie. regardless of whether I am using portage or
Luke A. Guest wrote:
> Thoughts?
I can't comment on your strategy, but I do agree with and support
your goals of being able to use more Ada in Gentoo.
Thanks to you and others for your work on this! :)
//Peter
Alexis Ballier wrote:
> > If elibtoolize results in different binaries being produced, then it's
> > done wrong in the first place. AFAIU the primary goal of elibtoolize
> > logic is to fix issues on recent systems with outdated build systems.
> > Which is certainly not something that needs to be
1 - 100 of 528 matches
Mail list logo
