Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

2021-09-27 Thread Peter Stuge
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

Re: [gentoo-dev] moving kernel config checks forward: potential config checking tool

2021-09-27 Thread Peter Stuge
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

Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

2021-09-27 Thread Peter Stuge
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

Re: [gentoo-dev] Guidance on distributed patented software

2021-09-26 Thread Peter Stuge
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

Re: [gentoo-dev] Guidance on distributed patented software

2021-09-23 Thread Peter Stuge
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,

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

2021-07-25 Thread Peter Stuge
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

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

2021-07-25 Thread Peter Stuge
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

Re: [gentoo-dev] Packages up for grab

2021-07-22 Thread Peter Stuge
Marco Scardovi wrote: > mail-filter/bogofilter I'd like to proxy-maintain this. //Peter

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

2021-07-12 Thread Peter Stuge
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.

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

2021-07-12 Thread Peter Stuge
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

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

2021-07-08 Thread Peter Stuge
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

Re: [gentoo-dev] [PATCH] qmail.eclass: simplify is_prime()

2021-06-17 Thread Peter Stuge
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 > -#

Re: [gentoo-dev] EAPI 8 is here!

2021-06-16 Thread Peter Stuge
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

Re: [gentoo-dev] Packages up for grabs

2021-06-15 Thread Peter Stuge
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

Re: [gentoo-dev] Package up for grabs: sys-boot/lilo

2021-06-07 Thread Peter Stuge
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

Re: [gentoo-dev] Package up for grabs: sys-boot/lilo

2021-06-01 Thread Peter Stuge
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.

Re: [gentoo-dev] Gentoo 18th Anniversary Edition - Help Needed

2021-04-20 Thread Peter Stuge
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 ...

Re: [gentoo-dev] Idea: User centric kernel configuration

2021-03-11 Thread Peter Stuge
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

Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-10 Thread Peter Stuge
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

Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-10 Thread Peter Stuge
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

Re: [gentoo-dev] A script to pick next free UID/GID for your acct-* packages

2021-02-09 Thread Peter Stuge
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

Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

2021-02-08 Thread Peter Stuge
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

Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

2021-02-08 Thread Peter Stuge
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

Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

2021-02-08 Thread Peter Stuge
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

Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

2021-02-08 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc.

2021-01-11 Thread Peter Stuge
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

Re: [gentoo-dev] Static libraries

2020-12-31 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

2020-12-31 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

2020-12-31 Thread Peter Stuge
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"

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

2020-12-30 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

2020-12-30 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
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. > >

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
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,

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-28 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-28 Thread Peter Stuge
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

Re: [gentoo-dev] libressl / libtls

2020-12-11 Thread Peter Stuge
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

Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread Peter Stuge
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

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

2020-11-09 Thread Peter Stuge
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..

Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Peter Stuge
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

Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Peter Stuge
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

Re: [gentoo-dev] Last-rites: dev-libs/liboobs

2020-08-03 Thread Peter Stuge
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,

Re: [gentoo-dev] Last rites: */* More Py2 only items

2020-07-21 Thread Peter Stuge
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

Re: [gentoo-dev] Gentoo/OpenBSD current status

2020-06-01 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Anti-spam for goose

2020-05-24 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Bootloader use in eclean-kernel

2020-05-24 Thread Peter Stuge
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,

Re: [gentoo-dev] [RFC] Anti-spam for goose

2020-05-22 Thread Peter Stuge
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). > >

[gentoo-dev] user.eclass ignores ROOT/SYSROOT

2020-05-05 Thread Peter Stuge
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

Re: [gentoo-dev] zoom concerns

2020-04-08 Thread Peter Stuge
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 >

Re: [gentoo-dev] ceph's static-libs

2020-04-05 Thread Peter Stuge
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

Re: [gentoo-dev] Use acct-* for qmail users

2019-09-15 Thread Peter Stuge
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

Re: [gentoo-dev] Gentoo i486 support

2018-08-22 Thread Peter Stuge
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

Re: [gentoo-dev] News item review: OpenSSH LDAP support

2018-08-06 Thread Peter Stuge
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

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-20 Thread Peter Stuge
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. >

Re: [RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?

2018-07-18 Thread Peter Stuge
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

Re: [gentoo-dev] x11-terms/xterm up for grabs

2018-06-25 Thread Peter Stuge
Johannes Huber wrote: > I will take it. Thanks. I can help as proxy-maintainer if you like. //Peter

Re: [gentoo-dev] newsitem: baselayout 2.5 changes (round 2)

2018-02-13 Thread Peter Stuge
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

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

2018-01-11 Thread Peter Stuge
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

Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)

2017-12-08 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

2017-12-05 Thread Peter Stuge
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

Re: [gentoo-dev] We Are All wltjr On This Blessed Day

2017-12-05 Thread Peter Stuge
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

Re: [gentoo-dev] We Are All wltjr On This Blessed Day

2017-12-04 Thread Peter Stuge
I'm quite unimpressed by how mgorny and jstein behave there. I wouldn't accept that, were I leading the project. //Peter

Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

2017-12-03 Thread Peter Stuge
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

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-24 Thread Peter Stuge
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

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-24 Thread Peter Stuge
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. >

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-24 Thread Peter Stuge
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

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-23 Thread Peter Stuge
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

Re: [gentoo-dev] Java 9 on Gentoo

2017-11-17 Thread Peter Stuge
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

Re: [gentoo-dev] Package up for grabs

2017-08-23 Thread Peter Stuge
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

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

2017-08-14 Thread Peter Stuge
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

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

2017-08-04 Thread Peter Stuge
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

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

2017-07-25 Thread Peter Stuge
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

Re: [gentoo-dev] New eclass: opam.eclass

2017-07-25 Thread Peter Stuge
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 [[

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

2017-07-24 Thread Peter Stuge
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

[gentoo-dev] Sanity check: enewuser in binpkg with portage-utils

2017-07-20 Thread Peter Stuge
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

Re: [gentoo-dev] Integrating Ada into toolchain.eclass, again

2017-05-20 Thread Peter Stuge
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

Re: [gentoo-dev] [RFC] Master plan for fixing elibtoolize

2017-03-18 Thread Peter Stuge
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

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

2017-03-11 Thread Peter Stuge
Anthony G. Basile wrote: > >> I proxy maintain bitcoins for luke-jr. He wants to propose a patch > >> against the bitcoin eclass. The following is his proposed change. > >> I'll commit it after review. > > > > Please do not do that, Anthony. > > I don't have time nor the familiarity to

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

2017-03-07 Thread Peter Stuge
Anthony G. Basile wrote: > I proxy maintain bitcoins for luke-jr. He wants to propose a patch > against the bitcoin eclass. The following is his proposed change. > I'll commit it after review. Please do not do that, Anthony. > Bitcoin Knots includes a number of enhancements users may find

Re: [gentoo-dev] newsitem: important fstab update

2016-10-29 Thread Peter Stuge
Peter Stuge wrote: > --8<-- mount(8) .. > portable. The mount(8) command internally uses udev symlinks > -->8-- That's of course only the mount in util-linux. //Peter

Re: [gentoo-dev] newsitem: important fstab update

2016-10-29 Thread Peter Stuge
Ian Stakenvicius wrote: > > WilliamH wants everyone using /dev/disk/by-label/ > > paths in fstab to instead use LABEL= , to avoid issues if udev > > doesn't create the symlinks before localmount tries to use them. .. > UUID is the same situation in this case -- in fstab you can do it by > UUID= or

Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Peter Stuge
Rich Freeman wrote: > We give you the tools when you install your system, and we give you > the tools when it is time for renovations... On that note - thank you very much to everyone who contributes to Gentoo! <3 //Peter

Re: [gentoo-dev] Commented packages in the @system set

2016-10-26 Thread Peter Stuge
waltd...@waltdnes.org wrote: > For a build-from-source distro like Gentoo, gcc and associated > tools are a vital part of the distro. A stage4 created (and updated) on a catalyst build farm doesn't need to have gcc, but may still need libstdc++. //Peter

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

2016-10-26 Thread Peter Stuge
Rich Freeman wrote: > I think you could make an argument that voluntarily placing that > header on your work is an assignment of copyright. > You could also argue otherwise. Especially in jurisdictions where copyright can not be assigned. //Peter

Re: [gentoo-dev] newsitem: important fstab update

2016-10-26 Thread Peter Stuge
Ian Stakenvicius wrote: > by mount and works regardless of device manager, therefore removing > the the dependency of having udev-settle before mounting these paths. the the Looks good. Thanks. //Peter

Re: [gentoo-dev] Commented packages in the @system set

2016-10-26 Thread Peter Stuge
Raymond Jennings wrote: > Why exactly isn't libstdc++ a separate package anyway? I guess because it has no separate upstream. I think a separate package would be a fantastic improvement though. //Peter

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

2016-10-18 Thread Peter Stuge
Patrice Clement wrote: > We should strive for keeping a clean and linear history. I agree with you. > Cherry-picking is not my go-to solution as far as I'm concerned. > It requires a bit of setup and is clearly tedious: you must know > in advance the full SHA-1 of commit(s) you want to

Re: [gentoo-dev] Re: Packages up for grabs

2016-08-06 Thread Peter Stuge
Peter Stuge wrote: > How can I help improve ..? Michał Górny wrote: > people focused on preaching and/or implementing random crap-based > solutions without even stopping for a few minutes to consider what > we exactly need. You could interpret my question as "what e

Re: [gentoo-dev] Re: Packages up for grabs

2016-08-06 Thread Peter Stuge
Michał Górny wrote: > Or file a pull request @ https://github.com/gentoo/gentoo/pulls. > That's the most convenient solution for most of proxy-maint team members. How can I help improve that problematic situation? It's not cool to gravitate the project towards GitHub Inc. //Peter

Re: [gentoo-dev] Re: Packages up for grabs

2016-08-06 Thread Peter Stuge
Felix Janda wrote: > I'd like become a proxy-maintainer for app-editors/nvi. Sweet! If there are some open bugs then please upload patched ebuilds and other neccessary files to the bugtracker, ideally as output by git format-patch, and then talk e.g. to #gentoo-proxy-maint on freenode to get

Re: [gentoo-dev] Packages up for grabs

2016-08-06 Thread Peter Stuge
Andrew Savchenko wrote: > On Sat, 6 Aug 2016 13:37:19 +0000 Peter Stuge wrote: > > Hi Pacho, many thanks for your work, but.. .. > > ..do you think you can arrange to post everything in one mail, > > instead of 14 different ones in a single day? > > I suppose these po

Re: [gentoo-dev] Packages up for grabs

2016-08-06 Thread Peter Stuge
Hi Pacho, many thanks for your work, but.. Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho

Re: [gentoo-dev] Package up for grab

2016-08-03 Thread Peter Stuge
Daniel Campbell wrote: > Tox .. > All it needs is feature parity with video, voice, and file sharing. And a new name. :) //Peter

  1   2   3   4   5   6   >