Re: [gentoo-dev] Not-Forking 0.3.1 with ebuild

2021-01-25 Thread Gordon Pettey
A bit off topic to whether or not there's an ebuild/maintainer for it, but
their homepage example is cringe-y. Instead of using the built-in features
of Git like submodules and rebasing, depend on an external tool to make
your repository even more messy?

Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init

2020-10-18 Thread Gordon Pettey
On Sun, Oct 18, 2020 at 6:02 AM Aisha Tammy  wrote:

> On 10/18/20 2:29 AM, Joonas Niilola wrote:
> > On 10/18/20 8:48 AM, Michał Górny wrote:
> >> Do you really think a rename for the sake of renaming justifies
> >> requiring all users to rewrite their configuration?  While we're
> >> requiring the users to do that, wouldn't it be better to stop using
> >> the awful layout of 'one script to run them all', and switch to separate
> >> scripts for every DM?
> >>
> > This is exactly what I proposed in the previous RFC, systemd already
> works this way and is IMHO a lot clearer to use.
> >
> > -- juippis
> >
> This would need some more tinkering as OpenRC doesn't have a dedicated
> mechanism to control vt's while systemd controls the vts.

Aside from that...

Additionally we would need to able to say that each of them is going to
> conflict
> with the other.

What conflict? Each package should have an init script with a matching
name. The only conflict might arise from
putting both in the same runlevel (assuming they don't just take the next
available VT). If a user wants to try out
a different DM, it is simpler IMHO to
/etc/init.d/old-dm stop && /etc/init.d/new-dm start
than editing xdm.conf. If new-dm crashes the system for whatever reason, no
need to remember to edit xdm.conf
to restore your old choice; just reboot and old-dm which was in the default
runlevel is still your DM.

Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-09 Thread Gordon Pettey
On Sat, Aug 8, 2020 at 6:57 PM William Hubbs  wrote:

> Hi Rich,
> > William - can you actually elaborate on WHY you want to change things?
> >  Is there some problem with eudev?  Is it actively maintained and
> > generally tracking upstream udev commits (minus whatever they
> > intentionally don't want to accept)?
>  It is maintained primarily by one person the last time I checked, and I
>  don't really know what he has included or not included from udev. What
>  I can say is that the last release of eudev hit the tree a year ago,
>  and I'm not sure about feature parity with udev.
> > I'd be curious as to a list of the practical differences between the
> > two at this point.  For the longest time the only ones I was aware of
> > were the de-bundled build system, and the change in the default
> > persistent ethernet device name rule which was made in udev but not
> > made (by default) in eudev.  Perhaps at this point there are other
> > differences.
> The only other one I know of is if you aren't using glibc udev will not
> compile, but I'm not even sure that is an issue still.
> The way I see it, we switched away from udev because of a fear that
> never materialized, and I'm not convinced that we have enough time to
> keep it in feature parity with udev which it needs to be to be the
> default provider.

Name the missing features in eudev.

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

2020-07-28 Thread Gordon Pettey
That dependency is only if USE="-gnuefi". sys-boot/gnu-efi has no Python
dependency. Instead of masking/removing refind, remove the USE flag and
force the gnu-efi dependency, or reverse the condition, add
IUSE="tianocore", and mask that USE flag.

On Tue, Jul 28, 2020 at 7:06 PM Aaron Bauman  wrote:

> On Tue, Jul 28, 2020 at 04:55:57PM -0700, Matt Turner wrote:
> > On Tue, Jul 28, 2020 at 4:17 PM Aaron Bauman  wrote:
> > > sys-boot/refind
> >
> > How did you conclude that this package depends on Python at all?
> >
> Hi, Matt. It has a dependency on sys-boot/udk which was masked due to
> using py2.7 only. Hope that helps.
> --
> Cheers,
> Aaron

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

2020-05-22 Thread Gordon Pettey
On Fri, May 22, 2020 at 1:18 AM waebbl  wrote:

> Am Do., 21. Mai 2020 um 22:14 Uhr schrieb Viktar Patotski <
>> I believe that we are all have forgotten about Donald Knuth: Premature
>> optimisation is the root of all evill.
> I won't consider spam protection to be a optimisation. Instead, the
> occurence of spam is IMO a proper use-case from a developers PoV. Therefore
> thinking about how to handle it, is a necessary task.
Abusing Knuth's words as an excuse to avoid any and all good practice is
the root of all evil.

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

2020-05-21 Thread Gordon Pettey
Require browser-based interaction to use the service. Do something funky
with AJAX so the page can't be properly used with curl or anything so that
manual effort is required to get the UUID to submit as. Only allow
registered UUIDs, and only allow one submission per day per UUID.
Sure, somebody can go to Mechanical Turk and pay a few cents to generate
fake submission IDs, but at least you have that tiny deterrent of "I've got
to pay 3 cents per spam account :(".

Maybe also add some minor tracking to the database if it isn't already
there to count submissions over time per UUID, and make the default cron
script weekly. If you see some UUID that is submitting at the maximum rate
of daily, you may lean towards accusations of spam.

On Thu, May 21, 2020 at 3:47 AM Michał Górny  wrote:

> Hi,
> TL;DR: I'm looking for opinions on how to protect goose from spam,
> i.e. mass fake submissions.
> Problem
> ===
> Goose currently lacks proper limiting of submitted data.  The only
> limiter currently in place is based on unique submitter id that is
> randomly generated at setup time and in full control of the submitter.
> This only protects against accidental duplicates but it can't protect
> against deliberate action.
> An attacker could easily submit thousands (millions?) of fake entries by
> issuing a lot of requests with different ids.  Creating them is
> as trivial as using successive numbers.  The potential damage includes:
> - distorting the metrics to the point of it being useless (even though
> some people consider it useless by design).
> - submitting lots of arbitrary data to cause DoS via growing
> the database until no disk space is left.
> - blocking large range of valid user ids, causing collisions with
> legitimate users more likely.
> I don't think it worthwhile to discuss the motivation for doing so:
> whether it would be someone wishing harm to Gentoo, disagreeing with
> the project or merely wanting to try and see if it would work.  The case
> of SKS keyservers teaches us a lesson that you can't leave holes like
> this open a long time because someone eventually will abuse them.
> Option 1: IP-based limiting
> ===
> The original idea was to set a hard limit of submissions per week based
> on IP address of the submitter.  This has (at least as far as IPv4 is
> concerned) the advantages that:
> - submitted has limited control of his IP address (i.e. he can't just
> submit stuff using arbitrary data)
> - IP address range is naturally limited
> - IP addresses have non-zero cost
> This method could strongly reduce the number of fake submissions one
> attacker could devise.  However, it has a few problems too:
> - a low limit would harm legitimate submitters sharing IP address
> (i.e. behind NAT)
> - it actively favors people with access to large number of IP addresses
> - it doesn't map cleanly to IPv6 (where some people may have just one IP
> address, and others may have whole /64 or /48 ranges)
> - it may cause problems for anonymizing network users (and we want to
> encourage Tor usage for privacy)
> All this considered, IP address limiting can't be used the primary
> method of preventing fake submissions.  However, I suppose it could work
> as an additional DoS prevention, limiting the number of submissions from
> a single address over short periods of time.
> Example: if we limit to 10 requests an hour, then a single IP can be
> used ot manufacture at most 240 submissions a day.  This might be
> sufficient to render them unusable but should keep the database
> reasonably safe.
> Option 2: proof-of-work
> ===
> An alternative of using a proof-of-work algorithm was suggested to me
> yesterday.  The idea is that every submission has to be accompanied with
> the result of some cumbersome calculation that can't be trivially run
> in parallel or optimized out to dedicated hardware.
> On the plus side, it would rely more on actual physical hardware than IP
> addresses provided by ISPs.  While it would be a waste of CPU time
> and memory, doing it just once a week wouldn't be that much harm.
> On the minus side, it would penalize people with weak hardware.
> For example, 'time hashcash -m -b 28 -r test' gives:
> - 34 s (-s estimated 38 s) on Ryzen 5 3600
> - 3 minutes (estimated 92 s) on some old 32-bit Celeron M
> At the same time, it would still permit a lot of fake submissions.  For
> example, randomx [1] claims to require 2G of memory in fast mode.  This
> would still allow me to use 7 threads.  If we adjusted the algorithm to
> take ~30 seconds, that means 7 submissions every 30 s, i.e. 20k
> submissions a day.
> So in the end, while this is interesting, it doesn't seem like
> a workable anti-spam measure.
> Option 3: explicit CAPTCHA
> ==
> A traditional way of dealing with spam -- require every new system
> identifier to be confirmed by solving a CAPTCHA (or a few 

Re: [gentoo-dev] Re: [gentoo-dev-announce] [RFC] New global USE flag 'speech'

2020-04-13 Thread Gordon Pettey
On Mon, Apr 13, 2020 at 1:13 PM Andreas Sturmlechner 

> On Monday, 13 April 2020 18:01:42 CEST Michał Górny wrote:
> > I see one package using 'tts'.
> These should switch to 'speech', imo:
> app-i18n/translate-shell[tts] - Enable text-to-speech support

I would strongly disagree. TTS has a very clear meaning. All of the listed
cases are explicitly enabling text to speech conversion. They are not
enabling speech input, and they are not enabling speech output without text

Re: [gentoo-dev] Re: News item: Deprecation and removal of legacy X11 input drivers.

2020-04-02 Thread Gordon Pettey
On Thu, Apr 2, 2020 at 10:27 AM Piotr Karbowski 

> while keeping the long sentence, that even it's long, is still beneficial
> to have

Split it for grammatical correctness and ease of human parsing.

The only use for those drivers remain in deployments which intentionally
> opt-out of using udev, as both evdev and libinput require udev during
> runtime, however given that upstream has already removed the Linux

Replace with "runtime. Given that upstream"

support from xf86-input-keyboard, future X11 releases will no longer
> support xf86-input-keyboard on Linux rendering those installation

installations should be plural

> infeasible to use without udev.

Re: [gentoo-dev] rfc: noarch keyword

2020-03-19 Thread Gordon Pettey
On Thu, Mar 19, 2020 at 9:47 AM Alec Warner  wrote:

> On Thu, Mar 19, 2020 at 6:52 AM Gerion Entrup 
> wrote:
>> Am Donnerstag, 19. März 2020, 02:59:56 CET schrieb Kent Fredric:
>> > 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, an ebuild with KEYWORDS="noarch"
>> > *cannot* depend on another ebuild with only KEYWORDS="amd64".
>> Maybe I misunderstand something but shouldn't that be the normal case?
>> Every single Python package (candidates for noarch) for example depends
>> on the Python interpreter, which must have non noarch keywords.
>> > Otherwise it breaks the entire stabilization graph.
>> The condition would be: If the interpreter is stable for an arch, all
>> it's interpreted code is also stable for this arch.
> Much of the concern is that this condition is not true for all interpreted
> code.
> -A
>> Best,
>> Gerion
If noarch is an alias that includes all keywords, KEYWORDS="noarch -sparc"
works (in Portage, not sure what PMS says about keyword additivity) and
doesn't break your keyword dependency graph for a Python package that for
whatever reason doesn't function on sparc.

Semantically, noarch says it hasn't been tested on any arch, so Kent's
evidence follows. Once you get a negative test result from an arch, you add
-arch to that package. It's not called "allarches".

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2019-09-05 Thread Gordon Pettey
On Thu, Sep 5, 2019 at 8:15 AM Thomas Deutschmann  wrote:

> On 2019-09-05 06:02, Michał Górny wrote:
> >> In my case I am working on a new mysql eclass to outsource pkg_config
> >> function which is shared at least between dev-db/mysql and
> >> dev-db/percona-server (and maybe dev-db/mariadb).
> >>
> >> For this new eclass I would say it's a "per-package" eclass and would
> >> probably have skipped mailing list review, too.
> >
> > Everyone can skip as many paragraphs as they want, and then apply what's
> > said later to something said way earlier.
> Could you please stop adding any bad interpretation?
> That was a serious question. For you, it's pretty clear. I am showing
> you, that for me, it isn't pretty clear. When you believe I skipped
> important lines in my quote please outline what I have missed and I will
> take the blame.

You'll note the bit you quoted in defense of skipping review says
"changes", and the bit about new eclasses says "do not skip this step".

Re: [gentoo-dev] rfc: [QA] Ban policy introduction

2018-07-29 Thread Gordon Pettey
On Sun, Jul 29, 2018 at 4:17 AM, Andrew Savchenko  wrote:
> On Sun, 29 Jul 2018 16:47:47 +0900 Alice Ferrazzi wrote:
>> Sent from my phone. Please excuse my brevity.
>> On Sun, 29 Jul 2018, 16:39 Fabian Groffen,  wrote:
>> > Completely agreeing with Sergei, with some additional suggestions:
>> >
>> > On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote:
>> > > On Sun, 29 Jul 2018 00:40:18 +0300
>> > > Mikle Kolyada  wrote:
>> > >
>> > > > Hello,
>> > > >
>> > > > The Gentoo QA team would like to introduce the following policy that
>> > > > would be applied to individuals breaking the state and quality of the
>> > > > main gentoo.git tree
>> > > >
>> > > > ( as we do not have this strictly documented yet):
>> > > >
>> > > > 
>> > > >
>> > > > If recommended
>> > >
>> > > It's not called "recommended" but "enforced".
>> >
>> > I agree.  If you put penalties on these, they become hard rules.  I
>> > think that change should be discussed by the council perhaps?
> +1. Also please provide some tool for developers to check for
> compliance to these rules, e.g. repoman full must perform all these
> checks.
> If developers have no way to verify correctness of the code, they
> can't be held responsible for accidental violation of the rules.
>> > > > the standard QA
>> > > > procedure is:
>> > > >
>> > > > 1.) Two warnings granted by QA team, after two independent breakages
>> > > > 2.) Revoking the commit access for 14 days
>> > > >
>> > > > These violations will be evaluated individually by all QA team members.
>> > > > Warnings can be revoked, if during 6 months period a developer makes at
>> > > > least 20 non trivial changes not producing more breakages.
> Why 6 months period? Why time frame at all? 20 good commits sounds
> OK. If you want time frame, then you should set autoexpire of
> warning as well.
> Best regards,
> Andrew Savchenko

That reads to me as "warnings become permanent after six months if not
remediated with 20 non-trivial good commits", not that they expire.

Re: [gentoo-dev] rfc: moving default location of portage tree

2018-07-11 Thread Gordon Pettey
On Wed, Jul 11, 2018 at 2:29 AM, Jory A. Pratt  wrote:
> This is a mess, many systems are setup with portage already on a
> seperate partition for reasons. What advantage does it provide to move
> the tree now after all these years? I have seen nothing more then lets
> do this cause I like the ideal lately and it is getting old, there is no
> benefit that would justify moving the tree or many other changes that
> are being made in Gentoo lately.

1. If you're able to mount /usr/portage from another filesystem, why
would you think it wouldn't work in with /var/cache/portage?
1a. If your system is already installed, why do you think this even
affects you? Did you read?
2. Pretty sure following FHS more closely is something most people
would see as a benefit.

Re: [gentoo-dev] multi-backend support for ssl/tls in curl

2018-04-23 Thread Gordon Pettey
On Mon, Apr 23, 2018 at 1:26 AM, Michał Górny  wrote:
> W dniu nie, 22.04.2018 o godzinie 09∶34 -0500, użytkownik Matthew Thode
> napisał:
>> The short of it is that curl supports having multiple backends.  I'd
>> like to have that feature enabled so libraries and userland can choose
>> the backend they wish to use.
>> has the specifics, but I cannot see a
>> reason why we are artifically limiting the backed to just one.
> How would you solve the problem of packages requiring specific SSL
> backend?  Currently they enforce it via USE dependency on cURL.

Perhaps with exactly the same USE dependencies that already exists,
just without the at-most-one limitation on curl itself?

Re: [gentoo-dev] [PATCH] use.desc: Correct/clarify SSL/TLS-related flags

2018-01-30 Thread Gordon Pettey
On Tue, Jan 30, 2018 at 5:22 PM, Ulrich Mueller  wrote:
>> On Tue, 30 Jan 2018, Michał Górny wrote:
> NACK. This seems to imply that USE="-ssl gnutls" is not a valid
> configuration? What if the user prefers gnutls and therefore has
> globally enabled the gnutls flag, but -ssl for a single package?

Because having gnutls enabled and ssl disabled, if a package has both
flags, is nonsense? What is "I want gnutls but I don't want support
for SSL/TLS" supposed to do?

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

2018-01-28 Thread Gordon Pettey
On Sun, Jan 28, 2018 at 4:00 PM, Andrew Barchuk  wrote:
> I don't see a reason to organize distfiles in a
> multi-level hierarchy: e.g. if the goal is to keep no more than 1000
> files in a folder than the limit of single level hierarchy is a million
> which is more than enough for foreseeable future. The list of 500
> directories takes 15kB when using full file names and will be couple of
> times smaller when using only unique prefixes.

Then don't. Using one level of first-4-characters-of-filename-hash is
still more efficient.

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

2018-01-28 Thread Gordon Pettey
On Sun, Jan 28, 2018 at 2:43 PM, Andrew Barchuk  wrote:
> There's another option to use character ranges for each directory
> computed in a way to have the files distributed evenly. One way to do
> that is to use filename prefix of dynamic length so that each range
> holds the same number of files. E.g. we would have Ab/, Ap/, Ar/ but
> texlive-module-te/, texlive-module-th/, texlive-module-ti/. A similar
> but simpler option is to use file names as range bounds (the same way
> dictionaries use words to demarcate page bounds): each directory will
> have a name of the first file located inside. This way files will be
> distributed evenly and it's still easy to pick a correct directory where
> a file will be located manually.
> ...snip...
> Using the approach above the files will distributed evenly among the
> directories keeping the possibility to determine the directory for a
> specific file by hand. It's possible if necessary to keep the directory
> structure unchanged for very long time and it will likely stay
> well-balanced. Picking a directory for a file is very cheap. The only
> obvious downside I see is that it's necessary to know list of
> directories to pick the correct one (can be mitigated by caching the
> list of directories if important). If it's desirable to make directory
> names shorter or to look less like file names it's fairly easy to
> achieve by keeping only unique prefixes of directories. For example:

To the contrary, that would not remain balanced, because your
boundaries are entirely dependent on exactly what is in the tree at
the moment you run your script. Now the package manager has to perform
directory listing, sort and find the file name that's closest, open
that directory, find the next closest filename (assuming multiple
levels of hierarchy), and so on, or you have to store yet another
index that duplicates information and takes additional space. Locating
by distfile name hash is effectively free.

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

2018-01-27 Thread Gordon Pettey
On Sat, Jan 27, 2018 at 10:48 AM, Michael Orlitzky <> wrote:
> On 01/27/2018 11:42 AM, Gordon Pettey wrote:
>> Why not use a hash of the file name instead of its contents? That
>> seems like it would be much simpler, and that's not going to reduce
>> the output space for balance...
> That's the proposal =P

I'm not following, then. What's all this about a temporary directory
because of not knowing the hash in advance? The ebuild must specify
the file name, or src_unpack wouldn't work. There is never a point
where the file name, and therefore its hash, is unknown.

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

2018-01-27 Thread Gordon Pettey
Why not use a hash of the file name instead of its contents? That
seems like it would be much simpler, and that's not going to reduce
the output space for balance...

On Sat, Jan 27, 2018 at 5:41 AM, Michał Górny  wrote:
> W dniu sob, 27.01.2018 o godzinie 11∶36 +, użytkownik Roy Bamford
> napisał:
>> On 2018.01.27 08:30, Michał Górny wrote:
>> > W dniu pią, 26.01.2018 o godzinie 20∶48 -0500, użytkownik Michael
>> > Orlitzky napisał:
>> > > On 01/26/2018 06:24 PM, Michał Górny wrote:
>> > > >
>> > > > The alternate option of using file hash has the advantage of
>> >
>> > having
>> > > > a more balanced split.  Furthermore, since hashes are stored
>> > > > in Manifests using them is zero-cost.  However, this solution has
>> >
>> > two
>> > > > significant disadvantages:
>> > > >
>> > > > 1. The hash values are unknown for newly-downloaded distfiles, so
>> > > >``repoman`` (or an equivalent tool) would have to use a
>> >
>> > temporary
>> > > >directory before locating the file in appropriate subdirectory.
>> > > >
>> > > > 2. User-provided distfiles (e.g. for fetch-restricted packages)
>> >
>> > with
>> > > >hash mismatches would be placed in the wrong subdirectory,
>> > > >potentially causing confusing errors.
>> > > >
>> > >
>> > > The filename proposal sounds fine, so this is only academic, but:
>> >
>> > are
>> > > these two points really disadvantages?
>> > >
>> > > What are we worried about in using a temporary directory? Copying
>> >
>> > across
>> > > filesystem boundaries? Except in rare cases, $DISTDIR itself will be
>> > > usable a temporary location (on the same filesystem), won't it?
>> >
>> > Why add the extra complexity when there's no need for one? Note that
>> > there's also the problem of resuming transfers, so in the end we're
>> > talking about permanent temporary directory where we keep unfinished
>> > transfers.
>> >
>> > > For the second point, portage is going to tell me where to put the
>> >
>> > file,
>> > > isn't it? Then no matter what garbage I download, won't portage look
>> >
>> > for
>> > > it in the right place, because where-to-put-it is determined using
>> >
>> > the
>> > > same manifest hash that determines where-to-find-it?
>> >
>> > No, it won't. Why would it? You're going to call something like:
>> >
>> >   edistadd foo.tar.gz bar.tar.gz
>> >
>> > ...and it will place the files in the right subdirectories.
>> >
>> > --
>> > Best regards,
>> > Michał Górny
>> >
>> >
>> >
>> >
>> Michał,
>> How does this work for fetch restricted files and finding other files
>> no longer on the mirrors?
>> Its no longer a download and move it to $DISTFILES, or is it?
>> Whatever it is, users will need to do it unless files in  $DISTFILES
>> are accepted by package managers if they are not found in the main
>> structure.
> I've just answered that, and it's in the GLEP also. There will be
> a helper tool to make this easy. Furthermore, I think we may even make
> Portage keep accepting both locations indefinitely.
> As for finding files in your distdir, there's no reason why plain:
>   find -name 'foo.tar.gz'
> wouldn't work.
> --
> Best regards,
> Michał Górny

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

2018-01-15 Thread Gordon Pettey
On Mon, Jan 15, 2018 at 9:09 AM, Rich Freeman  wrote:
> On Mon, Jan 15, 2018 at 8:26 AM, Tom H  wrote:
>> Gentoo's singling itself itself out as less receptive to its users
>> simply because some its developers are too Trumpian to resist arguing
>> with people who criticize their work or Gentoo.
> Wouldn't it be a bit exclusionary to require prospective developers to
> be qualified to be heads of state?
> I'd think that such a thing would discourage users from contributing.

Qualifications are subjective. For both groups of people.

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

2018-01-10 Thread Gordon Pettey
On Wed, Jan 10, 2018 at 10:22 PM, Duncan <> wrote:
> Andreas K. Huettel posted on Thu, 11 Jan 2018 02:12:47 +0100 as excerpted:
>> Am Mittwoch, 10. Januar 2018, 18:16:33 CET schrieb Vincent-Xavier JUMEL:
>>> Le 2018-01-10 10:53, Michał Górny a écrit :
>>> > Last I checked, Gentoo was a Linux distribution. However, some people
>>> > prefer to turn it into open discussion forum that has nothing to do
>>> > with making a distribution.
>>> No it has. Giving power to a subset of users, denying interaction with
>>> future contributors unless they enroll is the eaxct way to kill Gentoo
>>> as a community !
>> We wouldn't have needed to go this far if not for 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 they
>> plainly have no clue about (while whining when are told they sprout
>> bulls##t).
>> We do not have a problem with "future contributors". I wager those will
>> rather increase in numbers once the list spam is gone.
> This has been my biggest concern about the whole thing:
> Are we going to be nipping future devs in the bud because there's now too
> many hoops to jump thru too early, and it's simply not worth the trouble
> when they can (and will) go elsewhere where it's easier,
> OR
> Are we going to be lowering the unwelcoming noise, confusion and name-
> calling threshold and making the community more welcoming for those who
> have a serious interest, clearing out some of the stuff that could
> otherwise discourage them.
> It's pretty clear that council believes it's the latter, at least to the
> degree that they're willing to try it for a time, effectively a wager of
> sorts, but I don't believe anyone can honestly say what the real effect
> one way or the other will be until it /is/ tried.
> Personally, my viewpoint is that while over the last year or so there
> were some 1-2 level frustrating posters on a 5-point scale, it's nothing
> compared to the level-4 (direct name calling, just short of physical
> threats that justify getting the law involved) stuff that I've seen on
> this list in the some-years-distant past.  In my mind, unquestionably
> that level-4 stuff required action, and it was taken.
> The recent stuff seems so much milder in comparison that IMO it's hard to
> see what the hubbub is all about, but there's certainly an argument to be
> made that the previous experience simply desensitized our detection
> meters, and that were it not for that, the recent stuff would seem rather
> more shocking and horrible than it does, and that even if it's /less/
> horrible, it's horrible /enough/ that it remains unacceptable in a
> civilized society, and if we /do/ accept it, we're effectively pushing
> others that won't, out.

Given the quantity of relevant problem-mail that came from, maybe the glass house dwellers should be careful where
they aim their stones. I considered taking the dev quiz and everything
instead of just posting a few ebuilds on bugzilla years ago, but the
elitist, as Alex labelled it, voices from are what made me
decide not to, and my decision keeps getting reinforced. That
impression has been there for years, and it's not getting better by

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 Gordon Pettey
On Fri, Dec 8, 2017 at 2:30 PM, Peter Stuge  wrote:
> 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 be
> appropriate wording in this context? That is at a minimum tasteless.
> 2. substance: Why would William be blocked from Gentoo for a year?
> How and/or where will these two points be clarified?
> Thanks
> //Peter

Second that. Such a long thread about behavior on both sides, and then this from
somebody acting officially as comrel? No wonder you're getting abuse.

Re: [gentoo-dev] Manifest2 hashes, take n+1-th: 3 hashes for the tie-breaker case

2017-11-12 Thread Gordon Pettey
On Sun, Nov 12, 2017 at 8:22 PM, Joshua Kinard  wrote:

> Minor clarification, old single core //and// uni-processor.  Some older
> machines have multiple physical CPUs that are single-core.  Threading
> should be
> okay on these, as long as the thread count stays under NR_CPUS.
> I also have a really old single-CPU system, MIPS (obviously).  Not the
> fastest
> on the block compared to the other equipment I've got, but does anyone
> know of
> any simple timing scripts/programs available that can benchmark some of
> these
> proposed digest hashes?  If they turn out to be reasonably quick on my old
> machine, I doubt then that speed will be too much of an issue.

Even on your "old single-CPU MIPS" system, what percentage of time is
spent verifying manifest hashes compared to actually building/installing?
The whole "slow and/or multiple hashes will cause problems" argument
seems specious.

Re: [gentoo-dev] Manifest2 hashes, take n+1-th

2017-10-20 Thread Gordon Pettey
On Fri, Oct 20, 2017 at 5:42 PM, Anton Molyboha <anton.stay.connected@gmail.
com> wrote:

> On Thu, Oct 19, 2017 at 6:49 PM, Gordon Pettey <>
> wrote:
>> On Thu, Oct 19, 2017 at 5:32 PM, Hanno Böck <> wrote:
>>> On Thu, 19 Oct 2017 21:08:40 +0200
>>> Michał Górny <> wrote:
>>> >   manifest-hashes = SHA512 SHA3_512
>>> Counterproposal: Just use SHA512.
>>> There isn't any evidence that any SHA2-based hash algorithm is going to
>>> be broken any time soon. If that changes there will very likely be
>>> decades of warning before a break becomes practical.
>>> Having just one hash is simpler and using a well supported one like
>>> SHA512 may make things easier than using something that's still not
>>> very widely supported.
>> Yet having more than one lets you match make sure nobody hijacked your
>> manifest file when an attack vector is inevitably discovered for the old
>> new algorithm (whether SHA2, SHA3, or BLAKE2), because you'll be able to
>> confirm the file is the same one that matched the old checksum in addition
>> to the new one.
> Would it make sense then to support several hashes but let the user
> optionally turn off the verification of some of them, depending on the
> user's security vs performance requirements?
I would strongly question whether anybody is actually running emerge (or
whatever command that would be using the manifests) on systems that don't
have the CPU power to check a few hashes. If the CPU is really that weak,
there are likely much more important issues to deal with than what
combination of hashing algorithms manifests use. Things like "I should be
using pre-built system images because my CPU is orders of magnitude to even
do dependency tree calculation in less than a decade"...

Re: [gentoo-dev] Manifest2 hashes, take n+1-th

2017-10-19 Thread Gordon Pettey
On Thu, Oct 19, 2017 at 5:32 PM, Hanno Böck  wrote:

> On Thu, 19 Oct 2017 21:08:40 +0200
> Michał Górny  wrote:
> >   manifest-hashes = SHA512 SHA3_512
> Counterproposal: Just use SHA512.
> There isn't any evidence that any SHA2-based hash algorithm is going to
> be broken any time soon. If that changes there will very likely be
> decades of warning before a break becomes practical.
> Having just one hash is simpler and using a well supported one like
> SHA512 may make things easier than using something that's still not
> very widely supported.

Yet having more than one lets you match make sure nobody hijacked your
manifest file when an attack vector is inevitably discovered for the old
new algorithm (whether SHA2, SHA3, or BLAKE2), because you'll be able to
confirm the file is the same one that matched the old checksum in addition
to the new one.

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

2017-09-08 Thread Gordon Pettey
On Fri, Sep 8, 2017 at 11:15 AM, Ciaran McCreesh <> wrote:

> On Fri, 8 Sep 2017 11:10:54 -0500
> Gordon Pettey <> wrote:
> > And this is all irrelevant since the copyright applies to the
> > software, not the location you obtain it from. Nobody commits
> > copyright infringement by buying a used book from their neighbour
> > instead of buying it at Half Price Books.
> > Distribution licenses are another thing, but if the original SRC_URI
> > from the ebuild wasn't RESTICT="fetch", what makes anybody think that
> > would suddenly change with a new SRC_URI?
> Are you a lawyer, and does this constitute legal advice? I ask, because
> the lawyers I've spoken to about a similar issue seemed to think it
> wasn't that simple.

Since - just like you - I'm not lawyer, I have no obligation whatsoever to
say whether or not anything I say is legal advice. And so you can avoid
this the-sky-is-falling legal nonsense, here's yet another SRC_URI from the
author himself:!25302=!AEUh_81RXMobRbo=file%2cexe

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

2017-09-08 Thread Gordon Pettey
And this is all irrelevant since the copyright applies to the software, not
the location you obtain it from. Nobody commits copyright infringement by
buying a used book from their neighbour instead of buying it at Half Price
Distribution licenses are another thing, but if the original SRC_URI from
the ebuild wasn't RESTICT="fetch", what makes anybody think that would
suddenly change with a new SRC_URI?

On Fri, Sep 8, 2017 at 11:05 AM, Ciaran McCreesh <> wrote:

> On Sat, 9 Sep 2017 03:56:38 +1200
> Kent Fredric  wrote:
> > > >> Sir, please see my above comment about building ballistic
> > > >> missiles. It may be important for the Gentoo Foundation to add a
> > > >> disclaimer similar to the one I mentioned. I would hate for the
> > > >> Foundation or any of its administrators or contributors to be
> > > >> found guilty of aiding and abetting terrorists.
> > > >
> > > > Yeah. Stop trolling, please.
> > > >
> > >
> > > I am being completely serious. You can find such a clause in the
> > > iTunes license.
> > >
> > > If it seems ridiculous please reconsider the subject in question.
> >
> > I'm not sure how enforceable that clause is as a License.
> Until recently, there was a clause in the Nauty licence prohibiting use
> in "military applications". This was sufficient for the highly paid
> lawyers who looked at it to recommend not redistributing Nauty as part
> of the GAP computer algebra system, because computer algebra could
> conceivably be used for blowing stuff up.
> --
> Ciaran McCreesh

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

2017-09-05 Thread Gordon Pettey
Can these package.mask notes stop saying "no alternative found" when it's
obvious five seconds of Google searching was not even performed to find an
has live links, and the exe even matches the sha256sum.

On Tue, Sep 5, 2017 at 4:43 PM, Austin English 

> # Austin English  (05 Sep 2017)
> # Download has been broken for nearly a year, no alternative found
> # Bug:
> # Removal in 30 days
> games-rpg/nwn-shadowlordsdreamcatcherdemon
> --
> -Austin
> Austin English
> Gentoo Developer
> GPG: 00B3 2957 B94B F3E1

Re: [gentoo-dev] Re: Categories for GUI stuff x11 and wayland

2017-09-04 Thread Gordon Pettey
On Mon, Sep 4, 2017 at 4:57 PM, Duncan <> wrote:

> R0b0t1 posted on Mon, 04 Sep 2017 12:27:35 -0500 as excerpted:
> >> I actually really like the ux-* idea.  So much so I wish I'd thought of
> >> it. =:^)  It doesn't come across as nearly as "tired and worn out" as
> >> "gui-*" does, here (tho I already see a reply from someone else with
> >> the opposite reaction, favoring desktop-* over ux-*).

Pedants will note that UI (user interface) and UX (user experience) are
different things and for the described purpose of package categories,
neither one fits, at all.

ui-apps: Don't all "apps" have UIs, whether X11, Wayland, ncurses, slang,
plain text, or etc.?
ux-apps: What does this even mean? UX refers to the way a user interacts
with an application, not the application itself.

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

2017-08-14 Thread Gordon Pettey
On Mon, Aug 14, 2017 at 4:46 PM, William L. Thomson Jr. <>

> On Sat, 12 Aug 2017 09:55:02 -0500
> Gordon Pettey <> wrote:
> > On Sat, Aug 12, 2017 at 9:50 AM, 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.
> > >
> >
> > Also, how many Portages are there that need to be managed with a
> > "Portage Manager"?
> If your asking about alternative package managers, I am aware of 2

I'm not. I'm pointing out that just changing the meaning of P in PMS to
Portage makes the acronym nonsense unless you remove or change the M too.

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

2017-08-12 Thread Gordon Pettey
On Sat, Aug 12, 2017 at 9:50 AM, Alexander Berntsen 

> 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.

Also, how many Portages are there that need to be managed with a "Portage

Re: [gentoo-dev] Packages up for grabs: app-forensics/* and other forensics@g.o packages

2017-08-11 Thread Gordon Pettey
I have used chkrootkit and rkhunter in the past. Will copy them to my
overlay ( if they don't get a

On Fri, Aug 11, 2017 at 12:49 PM, RB  wrote:

> On Fri, Aug 11, 2017 at 11:40 AM, Michał Górny  wrote:
> > app-admin/integrit
> > app-forensics/afflib [o]
> > app-forensics/air
> > app-forensics/autopsy
> > app-forensics/chkrootkit [o]
> > app-forensics/cmospwd
> > app-forensics/examiner
> > app-forensics/galleta
> > app-forensics/libewf [o]
> > app-forensics/lynis
> > app-forensics/mac-robber
> > app-forensics/magicrescue
> > app-forensics/memdump
> > app-forensics/pasco
> > app-forensics/rifiuti [o]
> > app-forensics/rkhunter
> > app-forensics/scalpel [o]
> > app-forensics/sleuthkit [o]
> > net-mail/libpst [o]
> > sys-apps/dcfldd
> > sys-block/disktype
> The overlay has superseded and expanded on a lot of these. I
> gave up on trying to provide patches and updates for this category
> long ago, but they have picked up the flag and are doing a good job.

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

2017-07-12 Thread Gordon Pettey
On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. 

> On Thu, 13 Jul 2017 01:03:00 +1000
> Sam Jorna  wrote:
> > $ emerge -C apg
> >  * This action can remove important packages! In order to be safer,
> > use
> >  * `emerge -pv --depclean ` to check for reverse dependencies
> > before
> >  * removing packages.
> That is my point. That message is always there. The chance that it is
> ignored is very high.
Stop signs on the road are also always there. If you get arrested for
ignoring it, it is not because the stop signs are always there, it is
because you ignored it. Don't ignore the warning.

Re: [gentoo-dev] Sets vs Meta ebuilds

2017-07-10 Thread Gordon Pettey
On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny  wrote:

> On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
> > Stop getting lost in the weeds
> > You all are making this about -c vs -C. I am not talking about that!
> >
> >
> > When using -C, portage SHOULD warn for dependencies like it does for
> > profile and set packages, PERIOD. NOTHING to do with -c vs -C.
> >
> > When using -c the output should say in layman's terms,
> > "Not removing package A because it is a dependency"
> William, I'm not sure if you're aware of how package managers work but
> checking reverse dependencies of a package takes significant amount of
> time.

for x in $(eix -I --only-names); do time equery g $x > /dev/null; done

The only single package on my system that took more than 2 seconds total
time was gcc. The idea that that is too much time to add to emerge -c or
-C, which in my experience already takes multiple seconds to run anyway is
kind of silly.

Re: [gentoo-dev] Profile-enforced big-endian USE flag

2017-06-28 Thread Gordon Pettey
On Wed, Jun 28, 2017 at 5:29 PM, James Le Cuirot  wrote:

> On Wed, 28 Jun 2017 17:52:26 -0400
> Mike Gilbert  wrote:
> > On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot 
> wrote:
> > > I am therefore proposing a new global big-endian flag. This could be
> > > masked by default and unmasked + forced in the relevant profiles under
> > > arch. I will apply this according to the mapping defined in tc-endian
> of
> > > toolchain-funcs.eclass.
> I've just been putting the patch together. I made it slightly simpler
> by masking *and* forcing it by default so that it only needs to be
> unmasked were necessary.
> > A possible alternative would be to create a new USE_EXPAND variable
> > for this. That would allow for easier expansion in case we ever
> > support something other than big/little endian machines.
> That way madness lies? Wikipedia talks about middle-endian as being the
> catch all for other random orderings that have appeared over the years
> but I don't think any of them were used on a system-wide basis. I can't
> imagine Linux ever supporting such a thing. Unless you're talking about
> dealing with soft vs hard float here too?

So I can't ever expect support for littler-endian, giant-endian,
shrinking-endian, and chaos-endian?

Re: [gentoo-dev] Last rites: app-editors/vim-qt

2017-04-23 Thread Gordon Pettey

Upstream is working fine.

On Sun, Apr 23, 2017 at 5:53 AM, Michael Palimaka 

> # Michael Palimaka  (23 Apr 2017)
> # Doesn't work with any in-tree versions of vim. Inactive upstream.
> # Bug 607136. Masked for removal in 30 days.
> app-editors/vim-qt

Re: [gentoo-dev] Removal of CVS headers

2017-02-26 Thread Gordon Pettey
On Sun, Feb 26, 2017 at 1:59 PM, Robin H. Johnson 

> On Sat, Feb 25, 2017 at 03:05:09PM +0100, Ulrich Mueller wrote:
> > As the council has decided in its 2014-10-14 meeting (and confirmed
> > again in the 2016-11-13 meeting), CVS headers should be removed after
> > the migration to Git.
> The 2014-10-14 meeting did NOT specify what CVS headers were in
> question, and it was later decided that this was $Header$, not $Id$.
> > Until recently, this was blocked by repoman still checking for the
> > $Id$ line. The latter is now fixed in the stable repoman version.
> >
> > Therefore, I am going to remove the remaining CVS headers throughout
> > the tree (except for patches, of course) in two days from now.
> This was also discussed in August 2015:
> Subject: 'Infra plans regarding $Id$ - official answer...'
> d01ce943a9f9404c454c26bdb7efdf0e
> $Id$ is used by Git as well, and I was a strong advocate that expansion
> of $Id$ should be ENABLED in the rsync exports, because it allowed
> tracing what version of a file was actually in use.
> In the case of Git, $Id$ expands to the blob hash, which can be traced
> to a commit trivially, and several of the council members in the 2015
> thread did agree it was useful in that format (but I see no formal vote
> was ever taken).

Which can also be generated trivially (,
which kind of obviates the need for $Id$.

Re: [gentoo-dev] Printer drivers and net-print

2017-02-26 Thread Gordon Pettey
On Sun, Feb 26, 2017 at 4:54 AM, Andrew Savchenko 

> On Thu, 23 Feb 2017 21:16:15 + Ciaran McCreesh wrote:
> > On Thu, 23 Feb 2017 23:58:50 +0300
> > Andrew Savchenko  wrote:
> > > On Thu, 23 Feb 2017 18:50:45 +0100 Ulrich Mueller wrote:
> > > > > On Thu, 23 Feb 2017, Andrew Savchenko wrote:
> > > > >>
> > > > >> "Category Names"
> > > >
> > > > > I don't see a requirement here, only note on most common
> > > > > pattern:
> > > >
> > > > > ``Note: A hyphen is not required because of the virtual category.
> > > > > Usually, however, category names will contain a hyphen.''
> > > >
> > > > It is a note on what is the exclusive pattern, with the single
> > > > exception of the virtual category. I believe that we shouldn't break
> > > > that pattern.
> > >
> > > I'm fine with this approach, but could PMS be updated to contain
> > > more clear statement to avoid misunderstanding? E.g.:
> > > ``all category names must contain a single hyphen with a
> > > special exception for "virtual"''
> >
> > It's not a "must". Also, putting that rule in and having the package
> > mangler enforce it can have unintended consequences: for example,
> > there used to be the mild nuisance of dealing with overlays which
> > didn't contain a categories list, and which did contain directories
> > named CVS all over the place.
> OK, let's say "should", or ever better explain details, e.g.:
>   All newly created categories should follow "group-qualificator"
> pattern, a name without hyphen is allowed for a "virtual" category
> and for compatibility reasons in overlays.

If PMS is going to specify that, there ought to be better reasoning then
"that's how it's always been done." What concrete benefit is there to
_requiring_ hyphenated categories?

Re: [gentoo-dev] Printer drivers and net-print

2017-02-21 Thread Gordon Pettey
On Tue, Feb 21, 2017 at 7:05 PM, M. J. Everitt  wrote:

> On 21/02/17 08:53, Lars Wendler wrote:
> > On Mon, 20 Feb 2017 22:47:17 +0100 Andreas K. Huettel wrote:
> >
> >> Hey all,
> >>
> >> 1) Putting printer drivers into "net-print" is silly.
> >>
> >> Something that converts format a to device-specific format b has
> >> absolutely nothing to do with network.
> >> So, a new category "sys-print", emphasizing that it's hardware
> >> drivers, (or "cups-drv"?) (or maybe "media-print"?) might make sense.
> > Like I said in IRC, I'm all in favor of this. "media-print" seems
> > reasonable as I don't consider printing related packages being
> > system-relevant (and thus no sys-print).
> >
> >
> Maybe we can shoot for "app-print" .. its not really a system package
> any more than a networking one, nor a (multi-)media package per-se (cue
> bikeshed on what 'media' means) .. so perhaps just 'app-print' or
> 'app-printing' .. I dunno ..

There is no requirement for category names to be x-y. Instead of forcing a
prefix-suffix pattern that doesn't really fit, just call it "printing".

Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-02 Thread Gordon Pettey
On Thu, Feb 2, 2017 at 12:01 PM, Rich Freeman  wrote:

> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky  wrote:
> >
> > If (base == minimal), then all of the upstream defaults need to be added
> > to package.use for the upstream-defaults profile. That's bad,
> I'll go further and say that it is unacceptably bad.
> > but if
> > (base == upstream-defaults), then the important IUSE defaults need to be
> > copy/pasted from our ebuilds into the minimal profile. The latter is
> > more spiritually damning =)
> >
> So, I'll admit I've never been one that cared a great deal about
> minimalism so I appreciate that I may not be the best one to judge
> this, so let's go ahead and embrace your statement for the purpose of
> debate.
> Is there a better way we can have our cake and eat it too?  I'll admit
> that a huge package.use on the minimal profile isn't a whole lot
> better than a huge package.use on all the other profiles.
> Do we need another form of syntax in individual ebuilds to try to
> separate out the various cases you cite?  Does anybody care to
> actually suggest one?
> I still think that we shouldn't encourage users to lightly deviate
> from all the upstream defaults.  There are of course legitimate
> reasons for doing so, and you and I can probably appreciate when we
> should do this, but for somebody starting out we're giving them a lot
> of rope to hang themselves with.  It is like building a kernel
> answering no to the largest number of questions possible while still
> actually building something.  I'd actually be curious as to what that
> kernel would even be capable of doing (there are a lot of fairly
> essential things you can turn off in the kernel).
> In the same way, we shouldn't be too quick to deviate from upstream
> defaults ourselves (#4 in your example), beyond actual integration
> work.
> I'll admit the current state is a bit of a compromise, but I don't
> think we should change it unless we're changing it to something
> significantly better.  This is a pretty big-impact change.
> --
> Rich

If you want to keep this kind of thing in the ebuilds, IUSE="+blah" doesn't
allow any granularity. Another variable USE_PROFILE should be added
analogue to DEPENDS:
IUSE="gnome-keyring gtk-theme kwallet pulseuadio qt-theme
desktop? ( pulseaudio )
gtk? ( gtk-theme )
gnome? ( @gtk gnome-keyring)
kde? ( @qt kwallet )
qt? ( qt-theme )
upstream? ( annoyingUpstreamDefault )
@ is already used for sets, so "some other use_profile's set of defined
flags" seems reasonable. It should be additive only, so no +- prefixes
needed (or allowed). If a package is emerged without any USE_PROFILE set,
you might einfo "This package supports was emerged with no use profile. It
supports blah1, blah2, and blah3. Upstream recommends blah2." USE_PROFILE
should never have any default selected by an ebuild; if a flag is required
to build, is shouldn't be a flag. You get independent behavior per package
rather than listing every single package that ever existed in
profile/package.use, package behavior actually being with the package
instead of global profiles, and you get rid of the mess of uncustomizable
IUSE="+something" everywhere that makes people like me tend to start off
every new Gentoo install with echo "USE=\"-*\"" >> /etc/portage/make.conf.
Just need to come up with sane naming convention for common possibilities
like kde, gnome, and generic desktop.

If you want upstream, USE_PROFILE="upstream". If Gentoo as an organization
wants that to be the "friendly to new user" standard, put
USE_PROFILE="upstream" in the stage3 make.conf, where those of us who want
to can simply remove or change it instead of having to nuke everything with
USE="-*". You can still use e.g. RUBY_TARGETS="+ruby21" in an ebuild if you
want a default for things that really require an at-least-one-of choice.

Then instead of default/linux/amd64/13.0/desktop/kde listing any USE flags
itself, it just sets required USE_PROFILE and lets the packages do their

Re: [gentoo-dev] Requirements for UID/GID management

2017-01-28 Thread Gordon Pettey
On Sat, Jan 28, 2017 at 8:54 PM, Michael Orlitzky  wrote:

> On 01/28/2017 09:22 PM, Rich Freeman wrote:
> >
> > Honestly, I really will say "so what" here.  :)
> >
> I forgot to mention a few of the advantages of having really-fixed UIDs.
> First, it makes the code simpler. Yup, cool.
> It also lets us play a nice trick and use the UID as a subslot, so that
> if some sys-user/foo package ever changes its UID, everything depending
> on it can be rebuilt to use the new UID.

That's nonsense for reasons already mentioned by rich0. UIDs don't change
except in the case of an admin doing it manually.

Re: [gentoo-dev] Re: Please stay on-topic.

2016-12-09 Thread Gordon Pettey
On Fri, Dec 9, 2016 at 4:36 PM, William L. Thomson Jr. 

> Java on Gentoo is really not bad, if you are familiar with Java at all.

It's actually quite insane "if you're familiar with Java at all"...

Building C and C++ from source is great. 51% of dev-java category is doing
pointless work. 401 ebuilds only have IUSE="doc source" which can almost
always be fetched from Maven Central, and 44 ebuilds have no USE flags at
all. That's just from simple grep results. Given the ugly majority there, I
don't doubt there's some silliness going on in the remaining 49%. Building
Java from source to get the exact same jar file every time on a million
machines when you could just fetch the upstream jar instead is plain stupid.

Re: [gentoo-dev] Re: [RFC] New version constraints: variant one

2016-11-10 Thread Gordon Pettey
On Thu, Nov 10, 2016 at 5:19 PM, Ulrich Mueller  wrote:

> > On Thu, 10 Nov 2016, Michał Górny wrote:
> > The following revision-free version comparison operators are provided:
> >  ==   exact version match, or prefix match (with *)
> >  !=   exact version non-match, or prefix non-match (with *)
> >   >  <=   version less or equal to match
> >  >version greater than match
> >  >=   version greater or equal to match
> I think we should stick to the existing operators, and not introduce
> two slightly different sets for different contexts.
> Especially:
> - The operator for exact version match should be = not ==.
> - Omit the != operator because it can be confused with blockers. If an
>   operator for inequality is needed, we can add one but it should work
>   everywhere (we could e.g. use <> for that).
> - The ~ operator is missing.
> > All those operators compare on versions ignoring the revision part.
> I am strictly opposed to this. Again, it is confusing to have the same
> operators acting in a different way depending on context.
> > The following revision-oriented version comparison operators are
> > provided:
> >  ===  exact version+revision match
> >  !==  exact version+revision non-match
> >  <==  version+revision less or equal to match
> >  >==  version+revision greater or equal to match
> These are not necessary if the regular operators match revision.

Only if you're misusing revisions. A package depends on a another package,
not the ebuild revision of that package.

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

2016-10-26 Thread Gordon Pettey
On Wed, Oct 26, 2016 at 9:05 PM, Ian Stakenvicius  wrote:

> On 26/10/16 04:49 AM, Joshua Kinard wrote:
> > On 10/25/2016 13:15, William Hubbs wrote:
> >> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
> >>> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs 
> wrote:
>  If you are not using /dev/disk/by-* paths in fstab, you do not need to
> >>> take any action for this news item.
>  If you are, it is very critical that you update fstab AS SOON AS
> >>> POSSIBLE. Your system will become unbootable in the future if you do
> >>> not  do so.
> >>>
> >>> Err, what is changing that will make systems unbootable?
> >>>
> >>> I am fairly certain systems running systemd will continue to work
> >>> properly with either syntax.
> >>
> >>  They probably will.
> >>
> >>> If this is about the udev-settle issue for OpenRC, I would urge you to
> >>> reconsider that.
> >>
> >>  There isn't anything to reconsider afaik. The problem is that
> >>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
> >>  works regardless of which device manager  you use, so this is the safer
> >>  route.
> >>
> >>  William
> >>
> >
> > I take it us museum relics still using jurassic-era device names like
> > /dev/sd* or /dev/md* aren't affected by this?
> That's correct -- the kernel's 'devtmpfs' creates those ones, whereas
> the /dev/disk/by-* symlinks (pretty well all symlinks in /dev i think,
> actually) are generated by udev rules.
> Actually, I wonder if the /dev/[vgname]/[lvname] paths would be
> affected by this too -- those are symlinks to the actual nodes in
> /dev/mapper/ after all, and are created by 11-dm-lvm.rules

Those are already problematic; udev and/or lvm2 seem to randomly forget to
set those up sometimes. I use /dev/mapped/vg-lv in /etc/fstab because of

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

2016-10-24 Thread Gordon Pettey
On Mon, Oct 24, 2016 at 5:40 PM, Ciaran McCreesh <> wrote:

> On Mon, 24 Oct 2016 15:34:14 -0700
> Matt Turner  wrote:
> > In order to contribute to GNU projects, one must sign a copyright
> > assignment statement.
> >
> > Gentoo doesn't have anything similar as far as I'm aware, which makes
> > me question the legitimacy of "Gentoo Foundation" copyrights.

That style makes no sense to begin with. Something is copyrighted as of the
date it is created (whether originally or as an updated edited work), from
that date until X years in the future depending on what country you're in.
At worst, that range implies "This file was created in 1999 but in 20xx
we're making it public domain". Assuming Gentoo still exists in 200 years
and a certain mouse doesn't extend copyright durations again, a header that
says "1999-2216" would be quite invalid. Just use the single year as of the
date of editing. See

Re: [gentoo-dev] man pages: build or copy?

2016-07-09 Thread Gordon Pettey
On Sat, Jul 9, 2016 at 5:24 PM, Neil Bothwick  wrote:

> On Sat, 9 Jul 2016 10:13:13 -0400, Michael Orlitzky wrote:
> > On 07/09/2016 09:54 AM, Neil Bothwick wrote:
> > > I've created an ebuild for net-misc/zerotier [1]. This has a BDEP on
> > > app-text/ronn, the build system uses it to create the man pages. The
> > > trouble is that ronn is a Ruby program and pulls in a shedload of
> > > dependencies, just to install man pages.
> >
> > Ruby packages (besides dev-lang/ruby itself) install quickly, like perl
> > packages, so this isn't a *huge* deal. They can also be removed
> > afterwards with a depclean.
> That's when it really hurt, installing on a system without ruby itself.
> That's when I looked at alternatives.
> > > It seems to me to make more sense to put pre-built man pages in
> > > ${FILESDIR}/${PV} and copy them with doman. Is this considered the
> > > correct or acceptable way to deal with this?
> >
> > It's up to you. If they release a new version every day, it's going to
> > get real annoying to regenerate the man pages each time. Also keep an
> > eye on the size of the man pages. We have a soft limit of "a few
> > kilobytes" for things in FILESDIR,
> There's only three of them, totally 15kB uncompressed.

Having recently been annoyed by a package that for some reason depends on a
command-line web browser to build documentation, I'd really appreciate the
pre-built-without-oddball-dependencies variety :) (And ZeroTier looks like
something interesting I might find some use for)

Re: [gentoo-dev] Need design help/input for eclean-kernel

2016-07-01 Thread Gordon Pettey
On Fri, Jul 1, 2016 at 2:52 PM, William Hubbs <> wrote:

> On Thu, Jun 30, 2016 at 06:18:11PM -0500, Gordon Pettey wrote:
> > On Thu, Jun 30, 2016 at 5:22 PM, Daniel Campbell (zlg) <>
> > wrote:
> >
> > > Hash: SHA512
> > >
> > > 'boot' is a symlink to '.'. Not really sure why it's there but if I
> remove
> > > it, things break. Probably a minor misconfiguration.
> > >
> >
> > /boot/boot -> /boot allows you to prefix every reference to a kernel
> image
> > with /boot, regardless of whether you are running something in userspace
> on
> > a fully mounted system or in GRUB or syslinux or the kernel where "/boot"
> > is actually /dev/sda1 or some such and effectively /. Likely irrelevant
> to
> > eclean tools.
> I have to bring up a question for clarification. When we are talking
> about grub, are we talking about grub legasy or grub2?

Which bootloader doesn't matter. Instead of having to remember to delete
/boot from the beginning of the path, it just lets you reference everything
the same way you would from a shell on your running mounted system.

Re: [gentoo-dev] Need design help/input for eclean-kernel

2016-06-30 Thread Gordon Pettey
On Thu, Jun 30, 2016 at 5:22 PM, Daniel Campbell (zlg) 

> Hash: SHA512
> 'boot' is a symlink to '.'. Not really sure why it's there but if I remove
> it, things break. Probably a minor misconfiguration.

/boot/boot -> /boot allows you to prefix every reference to a kernel image
with /boot, regardless of whether you are running something in userspace on
a fully mounted system or in GRUB or syslinux or the kernel where "/boot"
is actually /dev/sda1 or some such and effectively /. Likely irrelevant to
eclean tools.

Re: [gentoo-dev] [RFC] Global USE=gui

2016-06-03 Thread Gordon Pettey
On Fri, Jun 3, 2016 at 8:06 AM, Damien Levac  wrote:

> On 2016-06-02 05:27 PM, Daniel Campbell wrote:
>> On 06/02/2016 12:57 PM, Damien Levac wrote:
>>> On 2016-06-02 03:42 PM, wrote:
 On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote

> IMHO, you see this in reverse. the 'gui' useflag would be useful for
> users who don't want to care about X/wayland/mir and do not want to
> care
> about gtk/qt, they just want windows to be drawn for the applications
> they install -- without, if possible, pulling useless dependencies.
 How, exactly, will the app draw windows without linking against one
 X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the

>>> It will be linked to one of those, but the users don't want to care so
>>> reasonable default would apply.
>>> For example, if I have setup my profile to be 'plasma', then having
>>> 'gui' in my global use flags would mean "build with qt5 support to
>>> provide my gui whenever possible, if not possible, fallback to whatever
>>> is available at the discretion of the package maintainer".
>>> 2 nice properties I foresee this feature will have:
>>> * If you do not like it, don't use it. It shouldn't affect any user
>>> unless they explicitly use the flag.
>>> * Negating the flag would mean to not build any GUI (i.e. headless
>>> server) which is cleaner than: '-qt3support -qt4 -qt5 -gtk -gtk3 -X
>>> -waylang...'
>>> I do not think the question is whether the flag would be useful: it
>>> will. The question is: can it be implemented efficiently...
>> To play devil's advocate, can we get a citation on "users don't want to
>> care"? Which users? Does Gentoo have a lot of users who don't care, or
>> does it attract a more passionate audience that enjoys the control that
>> comes with being source-based? I'm inclined to believe the latter, but
>> I'm ready to be wrong.
> Personal experience: I use to care a lot and tweak my system a lot... But
> I am not an eager undergraduate anymore, my interests have shift. I still
> use Gentoo as I know the system very well and like it. But I am in a point
> in my life where I want to focus on my work and not on whether or not I am
> making a 'gtk-only' or 'qt-only' system..
I'm a USE="-*" person, and I think USE="gui" to clean up a few lines in
package.use/* would be a nice idea... We do exist :)

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-05-14 Thread Gordon Pettey
On Sat, May 14, 2016 at 6:35 AM, Ciaran McCreesh <> wrote:

> Why? Gentoo is about the community. Requiring a basic standard of commit
> quality a) reduces the number of community members who are able to
> contribute, 2) leads to fewer forums posts discussing how to fix
> problems, iii) hurts Gentoo's DistroWatch statistics by reducing the
> volume of commits, and fourthly, discriminates unfairly against
> competency-challenged developers by imposing subjective interpretations
> of the value of source code from a position of unearned authority. This
> is against the code of conduct, and is bad for the community!
> So, it's perfectly okay to make direct commits of obviously broken code
that has no chance of working, because community something mumble...

Re: [gentoo-dev] CVS headers in ebuilds

2016-04-10 Thread Gordon Pettey
Or you could just use a branching workflow like Git has great support for,
and create your overlay as a branch of the main tree you're copying ebuilds
from. With recent versions, you can even have checkouts of different
branches from the same tree in different directories, so you're not
duplicating the the whole repository. Then you could just git diff from the
master branch, and no need for preserving CVS misbehavior.

On Sun, Apr 10, 2016 at 12:28 PM, Robin H. Johnson 

> On Sun, Apr 10, 2016 at 06:16:05PM +0200, Ulrich Mueller wrote:
> > Why would you need $Id$ feature for this? "git ls-files -s" gives you
> > the hash of the blob as well, is more efficient than grep, and even
> > works recursively on a directory tree.
> >
> >$ git ls-files -s -- www-client/seamonkey/seamonkey-2.40.ebuild
> >100644 5ecd7709c6c8a316d9f005b4e4a0a54da81eb048 0
> www-client/seamonkey/seamonkey-2.40.ebuild
> Your ls-files doesn't let you track what blob the modified ebuild came
> from, when it's copied out of the git repo where expansion was
> happening.
> If the $Id$ is expanded in rsync, or your local environment, then you
> copy the file with the expanded $Id$ to an overlay (or another Git
> environment without expansion enabled), you have preserved the $Id$.
> Now the user edits it in their overlay, and since the original $Id$ is
> preserved, when you ask on bugzilla, please submit it as a diff; they
> can simply do:
> # diff <(git show $IdHash) $OVERLAY/pn/pv.ebuild
> --
> Robin Hugh Johnson
> Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee
> E-Mail :
> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] usr merge

2016-04-09 Thread Gordon Pettey
On Sat, Apr 9, 2016 at 5:50 PM, Philip Webb  wrote:

> 160409 Canek Peláez Valdés wrote:
> > On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb 
> wrote:
> >> I've always used Lilo, which is simple + reliable :
> >> I never see questions re it here, but there are many re Grub.
> >> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
> >> When setting it up, I suppressed UEFI in the BIOS settings :
> >> isn't that what anyone not running M$ would do ?
> > I just disabled secure boot, although it's possible to use it with Linux.
> > However, it would require to manually sign everything from boot loader
> > to kernel modules, since Gentoo has no infrastructure to do that.
> > I don't "supress" UEFI, since it's *obviously* so much better than BIOS
> > and since bootctl (the program formerly known as gummiboot)
> > it's incredible easy to use. You don't even notice it's there.
> Sorry, I meant "suppress secure boot".  My mobo doesn't have UEFI.

If you have "secure boot", you have UEFI. You can't have it without.

Re: [gentoo-dev] Re: [gentoo-project] Portage repo usage survey and change evaluation

2016-03-03 Thread Gordon Pettey
On Thu, Mar 3, 2016 at 1:20 AM, Patrick Lauer  wrote:

> It is almost, but not completely unlike it. A simple ChangeLog is a lot
> easier ...
> (Why are people now trying to add middleware layers to indirect the
> problem to become invisible in a huge machinery? This is wonderfully
> insane ...)

Exactly... The SCM is a lot easier, and you avoid any middleware layers and
indirection :)

Regarding all the previous size arguments: my system doesn't agree. A
recent rsync sync gave me an 856 MB directory (of which 223 MB is those
precious ChangeLog and ChangeLog-2015 files). A checkout from git, plus
news, glsa, etc. (using hasufell's convenient portage-gentoo-git-config on
GitHub) is only 782M, and I can get more detailed change information than
those ChangeLog* files could ever give. Then there's the option of putting
it on btrfs with compression if I still want the working tree smaller. You
can argue about squashfs reducing the size, but you can do that with a tree
from git just like you could with a tree from rsync, so it's irrelevant.

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

2016-02-25 Thread Gordon Pettey
On Thu, Feb 25, 2016 at 1:12 AM, Martin Vaeth  wrote:

> Luis Ressel  wrote:
> >
> > That would require a local git clone. And that's exactly what those who
> > still want Changelogs are trying to avoid.
> You need even a deep git clone with full history.
> Already now this means that you need 2 (or already 3?) times the
> disk space as for an rysnc mirror; multiply all numbers by 4
> if you used squashfs to store the tree.
> In the course of the years the factor will continue to increase;
> I guess at least by 1 for every year (there is possibility of some
> compression of history, but OTOH, many packages are added and
> removed, eclasses keep changing, etc.)
> So in 2-3 years, it can be for some users 20 times the disk storage
> than what it needs now.

Or, in 2-3 years, maybe people will stop with the hyperbole. Hopefully
sooner. The tree is a bunch of text files, of which a whole lot of text is
repeated (esomewrapper, eclass-based builds which are identical but for a
single line, version updates to packages that make no changes at all to the
ebuild, etc.) which is great for compression, which git does.

Re: [gentoo-dev] Re: "Lazy" use flags?

2016-02-12 Thread Gordon Pettey
On Fri, Feb 12, 2016 at 5:26 AM, Rich Freeman  wrote:

> On Fri, Feb 12, 2016 at 1:36 AM, Kent Fredric 
> wrote:
> > On 12 February 2016 at 18:56, Duncan <> wrote:
> >> So my USE="-* ..." (without letting portage do autounmasking) would
> >> continue to work just like it does now, correct?
> >
> > I would hope so.
> That would be my proposal.
> I think it would make more sense in general for this to be the default
> and to have a flag to disable it, in part for this reason.  It
> wouldn't affect people running -* and such anyway, so this is targeted
> mostly at users who don't care a great deal about micromanaging their
> USE flags.

I use -* exactly because I /don't/ want to micromanage, and there are far
too many packages whose maintainers have decided to stick + in IUSE for
random crap. To wishlist a different feature, it'd be nice to have a
profile or something that made portage ignore
IUSE="+maintainers-favorite-flag" so we wouldn't have to use -*... I'll
happily let portage semi-manage USE for me by auto-enabling USE in
dependencies if I can set the base USE in the first place without having to
start off with global negation.

Re: [gentoo-dev] "Lazy" use flags?

2016-02-09 Thread Gordon Pettey
On Tue, Feb 9, 2016 at 7:19 AM, Kent Fredric  wrote:

> On 10 February 2016 at 02:14, Daniel Campbell  wrote:
> > Another concern, though, is it'd result in something similar. Instead
> > of "cat/foo bar baz" and later removing 'baz', you'd have "cat/foo bar
> > ~baz" (with '~baz' as 'enable this if you need to'). You'd still have
> > cruft left in your p.use file, and it would achieve the same result as
> > a well-commented file.
> Granted you'd still have the cruft in your config files, but it would
> become mostly-harmless cruft, not cruft that caused needless
> dependencies to get pulled into the dependency tree as a side-effect.
> And because it would be "only as needed", you could afford to use some
> of those "only if needed" useflags in a more global manner.
> For instance, I really don't want to globally define PYTHON_TARGETS to
> include python2_7, because it will simply install a lot of extra
> things I know I don't need.
> But if I could globally define something to the effect of "anything
> that wants python2.7 support can have it", then that's acceptable
> globally, because the effect would still turn things on automatically
> on a per-page level, not at a global level.
> So you could achieve the same results with much less syntax and much
> less effort.

A distinct behavior for +USE (as opposed to -USE and USE) would fit better
than "~USE" IMHO, where the plus means "add if (and only if) required" and
would cascade through dependencies, so if I merge e.g. app-portage/pfl with
USE="+PYTHON_TARGETS_PYTHON2_7" it would apply that to dependencies as
required. ~USE might fit for something like "~PYTHON_TARGETS_PYTHON3",
where it would select the greatest flag matching that prefix, and would
therefore automatically keep packages that have 3_2, 3_3, 3_4, 3_5 using
whatever is the latest unmasked flag. Could potentially combine the
prefixes, e.g. "~+PYTHON_TARGETS_PYTHON3" to both select the greatest
python version AND cascade to dependencies.

Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

2015-10-27 Thread Gordon Pettey
Is this not precisely what USE_EXPAND is supposed to be for? Take CURL_SSL
and make it generic...

On Tue, Oct 27, 2015 at 9:46 PM, Rich Freeman  wrote:

> On Tue, Oct 27, 2015 at 10:06 PM, hasufell  wrote:
> >
> > B) 1 feature flag, 3 strict provider flags
> > * ssl: enable any sort of SSL/TLS support
> > * gnutls: only to enable gnutls provided ssl support in case there
> >   is a choice
> > * openssl: only to enable openssl provided ssl support in case
> >there is a choice (should not be implemented as !gnutls?)
> > * libressl: only to enable libressl provided ssl support in case there
> > is a choice, must conflict with 'openssl' USE flag
> >
> > consequences:
> > * REQUIRED_USE="^^ ( openssl libressl )" is not only allowed, it is
> >   _mandatory_
> > * packages like media-video/ffmpeg _must_ switch the USE flag
> >   openssl->ssl to avoid breaking global USE flags
> > * !gnutls? ( dev-libs/openssl:0 ) will be bad form or even disallowed
> >
> > B will definitely be more work, but ofc is also a lot cleaner and
> > totally unambigous.
> >
> ++
> The pain is for a short time.  Then we have to live with this for a
> long time.  USE flags should have one meaning.  The fact that this
> isn't the case right now is already a bug.  We don't need to
> perpetuate it.
> Honestly, this just seems like "the right thing" so if there isn't
> opposition then I'd suggest to "just do it" and commit fixes to
> ebuilds that need the fix (ie if maintainer doesn't respond to bug
> quickly just take care of it).  If people object they should speak up
> now, and we can take it up at the next council meeting if necessary
> (which is right around the corner).
> --
> Rich

Re: [gentoo-dev] Re: Referencing bug reports in git

2015-08-10 Thread Gordon Pettey
On Mon, Aug 10, 2015 at 7:25 AM, Duncan wrote:

 ** summary bug number standardized to GB#xx or #xx or similar,
 short enough for summary, easily identified. GB# would be distinctly
 gentoo and could be expanded to KDEB#, GNB# (gnome), FDOB#, etc, for

If you're going to prepend the project, just spell it out. Don't invent new
acronyms and abbreviations. Don't add a B suffix to everything. If it's the
same everywhere, then it is meaningless, and just confuses things. I know
what KDE is, but I'd have to go Google for what KDEB is (Is that KDE B? K
Debian?), and hope Google indexed the above email from gmane or something.

Don't prefix bugs with #. 1. It doesn't apply to every system: Random
Project using Jira is going to have bugs like RP-123. You'd have to insert
it in the middle of the identifier like RP-#123. 2. It is a relatively
useless prefix at best: In the bug tracker UI, you search for 123, not
#123. At worst, it makes the identifier invalid (as in the Jira example).

Re: [gentoo-dev] Git workflow, commit messages

2015-08-09 Thread Gordon Pettey
On Sun, Aug 9, 2015 at 7:06 AM, Anthony G. Basile

 Particularly, we should prepend CATEGORY/PN:  to the first line so we
 can easily search git log for what happened to a package.

Good format to help reading unfiltered logs, but invalid reasoning. 'git
log portage/cat/pn' or 'git log portage/cat-old/pn-old
portage/cat-moved/pn-moved' gets every commit affecting files in said
package's directory.

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

2015-04-13 Thread Gordon Pettey
On Mon, Apr 13, 2015 at 7:59 AM, Erik Mackdanz wrote:

 William Hubbs writes:

git request-pull simply formats an email template to tell someone how

they may pull from you, but Github makes no attempt to process such a
 message or turn it into a Github pull request.

A pull is a pull is a pull. Please don't conflate Git and GitHub.

 Any Github presence of the tree will result in Github issues being
 submitted and Github pull requests coming across.  We'd have to be
 prepared to chain that into our existing processes or have someone
 dedicated to closing every issue/pull request with Use bugzie.

Then turn off the issue tracker. Joe Random can't submit GitHub
issues if the repository admin hasn't enabled them.

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

2015-04-11 Thread Gordon Pettey
On Sat, Apr 11, 2015 at 5:47 PM, Andrew Savchenko

 While I must admit that travis is a quite convenient tool (thought
 it has its limitations), I'd like to raise related software freedom

 Travis itself is a closed, proprietary and non-trivial-to-replace

Looks pretty open to me...
Replacement may be non-trivial purely due to the large number
of components involved, but closed and proprietary are a bit

Re: [gentoo-dev] shouldn't eselect be in app-eselect ?

2015-04-04 Thread Gordon Pettey
On Sat, Apr 4, 2015 at 1:49 PM, Michał Górny wrote:

 Dnia 2015-04-04, o godz. 13:47:47
 Alex Brandt napisał(a):
  I don't disagree but will simply point out that if this becomes true, we
  should also move dev-lang/python to dev-python, dev-lang/ruby to
 dev-ruby, and
  dev-lang/perl to dev-perl (not an exhaustive list).

 Portage to app-portage/, web browsers with plugins to www-plugins/...

That doesn't fit. Ruby is Ruby, Python is Python, vim is vim, and emacs is
emacs, but a web browser is not a plugin.

Re: [gentoo-dev] Policies for games dirs, new group gamestat for sgid binaries

2015-02-21 Thread Gordon Pettey
On 02/21/2015 01:35 AM, Ulrich Mueller wrote:

   Personally, I think that controlling who is allowed to run certain
   types of applications via group membership is a great idea. We
   should introduce that approach for other applications too. How
   about an editors group? Text editors are potentially dangerous
   because they allow users to modify files. Therefore, the system
   administrator should add only trusted users to the editors group
   so they can run programs like emacs, nano, or vim from the
  app-editors category.

Protect the permissions on the files, not the editors - there's always
another way to get content into a file if you have write permission to it.
If you try to do that with a g+xo-x, then you're going to have to do the
same for every single command that can put output in a file (sed, curl,
wget, heck, anything that can be piped, every shell), and then your system
doesn't even need users anymore, because no user can do anything at all for
fear they might write to a file!

Re: [gentoo-dev] missing opengl dependency header

2015-02-12 Thread Gordon Pettey
On Thu, Feb 12, 2015 at 7:46 AM, Nicolas Sebrecht

   In file included from modules/graphics/opengl/GLee.h:66:0,
from modules/graphics/opengl/OpenGL.h:24,
from modules/graphics/opengl/VertexBuffer.h:29,
from modules/graphics/opengl/VertexBuffer.cpp:21:
   /usr/include/GL/gl.h:2055:22: fatal error: GL/glext.h: No such file or
#include GL/glext.h
   compilation terminated.

 In fact, /usr/include/GL/glext.h is a relative symlink to

What ebuild creates the missing files in /usr/lib64/opengl/global ? I
 wasn't able to figure this out.

app-admin/eselect-opengl manages the symlinks to headers provided by
media-libs/mesa, I think. app-portage/pfl or
will help you with finding packages owning files that might not exist on
your system.

Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

2015-02-02 Thread Gordon Pettey
Having USE=ffmpeg at all is the source of any confusion in case somebody
is using libav. Either with an expand set (which seems wasted just for two
options) or two regular flags, just force one or none. There is absolutely
no sense in having USE=ffmpeg on for a system using libav.

On Mon, Feb 2, 2015 at 8:12 AM, Ulrich Mueller wrote:

  On Mon, 2 Feb 2015, Michał Górny wrote:

  FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg
  tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will
  exactly get used. Much less confusion.

  Thirdly, this opens space for having more than two different
  implementations in the future without having to reset the system. Maybe
  this isn't something worth considering but -- as I see it -- the first
  big fork starts a precedent, and both current versions suck :).

  Fourthly, there's the case of implicity. Right now USE=-libav implies
  ffmpeg. Therefore, USE=-* implies ffmpeg as well -- which is kinda
  weird since it's supposedly the non-default. With this solution, USE=-*
  will result in explicit error asking user to select an implementation.

  As for the downsides:

  1. there is a number of non-meaningful flag combinations.
  FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be
  blocked via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'.

  2. There is some more work to get ebuilds correct (REQUIRED_USE).
  However, this is a minor issue compared to the potential mistakes in
  interpretation of USE='ffmpeg' and USE='libav'.

  What are your thoughts?

 In a nutshell, you have a binary choice here, namely ffmpeg or libav
 as implementation, and instead of one USE flag you want to introduce
 two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible
 combinations only 2 are valid. So you need a REQUIRED_USE to forbid
 some combinations.

 Please spare us of this.


Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-01-25 23:59 UTC

2015-01-28 Thread Gordon Pettey
On Wed, Jan 28, 2015 at 2:25 PM, Rich Freeman wrote:

 On Wed, Jan 28, 2015 at 11:36 AM, Tobias Klausmann
  A while back, Daniel Quinn asked what the Gentoo devs that follow
  the G+ Gentoo Account what they think of making it possible to
  thank/donate to Gentoo developers for their work on the

 Wow!  Thanks!  :)

  Note that this a mockup only, no actual donation is possible.

 I'd suggest working with the trustees if you want to enable any kind
 of donations.  One area of ongoing discussion has been that right now
 it is hard to donate using anything but paypal.  An obvious
 alternative is bitcoin, but there have been legal concerns with this.

Dwolla is easier and free-er, and run by a credit union instead of eBay :)

Re: [gentoo-dev] Review: USE=libav news item

2015-01-26 Thread Gordon Pettey
On Mon, Jan 26, 2015 at 6:18 AM, Rich Freeman wrote:

 On Mon, Jan 26, 2015 at 7:00 AM, Alexis Ballier
  On Mon, 26 Jan 2015 12:37:09 +0100
  Alexis Ballier wrote:
   media-video/mplayer2 or media-video/mpv may be used as a more
   modern replacement.
  Don't recommend mplayer2, afaik it's dead.
  Also, I'd drop modern from there: I don't see much more modernity in
  those forks except maybe younger maintainers :)

 Is there an exhaustive list of packages that don't work with one or
 the other?  I don't think I've noticed anything I couldn't install for
 a lack of libav.

Chromaprint will work /differently/ depending on which is used. I added
libav support to it, but the fingerprints are not the same as fingerprints
generated when using ffmpeg. I've not gotten around to fixing that, so if
such a list is being compiled it should be noted on the don't arbitrarily
switch between ffmpeg and libav if this tool is important to you list.

Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86

2015-01-23 Thread Gordon Pettey
On Fri, Jan 23, 2015 at 3:16 PM, Michael Orlitzky wrote:

 On 01/23/2015 03:22 PM, Michał Górny wrote:
  Dnia 2015-01-23, o godz. 14:26:48
  Michael Orlitzky napisał(a):
  On 01/23/2015 02:13 PM, Michał Górny wrote:
  To help you enable the correct USE flags, we are providing a Python
  script which generates the correct value from your /proc/cpuinfo [1].
  The Python script can be downloaded and executed using the following
$ wget -O - | python
  Can we not encourage people to pipe stuff from a plain-http website into
  an interpreter?
  Find a better solution.

If you trust GitHub, put it on a Gist, and it'll be accessible via HTTPS
and SSH.
If the raw URL is too ugly, and you trust Google, use the HTTPS version
of to shorten it.

 Even `wget --no-check-certificate` would be a big improvement. Or since
 Firefox seems happy with the certificate, we could just
 ask them to download it with their browsers.

 Longer term: can we make wget like our SSL certificate?

DigiCert SHA2 High Assurance Server CA is not in ca-certificates.
Funnily, DigiCert's download link for it is via plain HTTP so reasonable
paranoia demands manually verifying the chain after downloading.

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

2015-01-20 Thread Gordon Pettey
On Tue, Jan 20, 2015 at 2:17 PM, Christopher Head wrote:

 On January 20, 2015 12:47:03 AM PST, Alexis Ballier
 So, you're telling me that if you have a list of 90 cpu extensions, you
 will from time to time open that list to see if there is a 91st one
 added ? I think most people won't even notice, at best they'll look for
 the changelog.

 No, actually, I’m advocating the exact opposite. I’m saying that, as long
 as the list file is kept up to date, then I will look at those 90 flags

Why do you keep insisting on 90 flags? Nothing is going to have alternate
code paths for whether you've got pse, pse36, pat, fpu, or ept. The vast
majority of the flags in cpuinfo aren't ever going to be in anything
userspace. The kernel might care about them, but even then, most of them
aren't going to be related to any options you can change.

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

2015-01-19 Thread Gordon Pettey
On Mon, Jan 19, 2015 at 4:40 PM, Michał Górny wrote:

 Dnia 2015-01-19, o godz. 23:09:55
 Rémi Cardona napisał(a):

  Why not :
  libav? ( media-libs/libav:= )
  ffmpeg? ( media-libs/ffmpeg:= )
  + REQUIRED_USE=^^ ( libav ffmpeg )
  I for one would never expect USE=-libav to enable ffmpeg (nor
  USE=-ffmpeg to enable libav FWIW).

 Two reasons:

 1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in
 a lot of packages. If we changed the meaning, libav users will end up
 switching '-ffmpeg libav' per-package. Ugly.

There are only 61 packages with USE=ffmpeg, and quite few of those might
reasonably have package.use different from make.conf.

 2. Feature-oriented flags. USE=ffmpeg represents the generic feature,
 USE=libav is auxiliary implementation-switch flag. Well, maybe we could
 use, say, USE=avcodec to avoid ambiguity but that's a larger change.

So, it is then expected to have both (USE=ffmpeg libav) to enable the
feature and then select the implementation? That's quite counter-intuitive,
and in some cases, there are some significant API differences - it is not
just a drop-in auxiliary implementation.

Re: [gentoo-dev] Review: desc/cpu_flags_x86.desc

2015-01-19 Thread Gordon Pettey
On Mon, Jan 19, 2015 at 4:41 AM, Alexis Ballier wrote:

 On Sun, 18 Jan 2015 15:15:22 -0800
 Matt Turner wrote:
   mmx - Use the MMX instruction set
   mmxext - Use the Extended MMX instruction set (intersection of
   Enhanced 3DNow! and SSE instruction sets) (3dnowext or sse in
   cpuinfo) padlock - Use VIA padlock instructions popcnt - Enable
   popcnt instruction support sse - Use the SSE instruction set
   sse2 - Use the SSE2 instruction set
   sse3 - Use the SSE3 instruction set (pni in cpuinfo)
   sse4 - Enable SSE4 instruction support
  We shouldn't have an sse4 USE flag. It's either one of the three
  below, but SSE4 by itself isn't a thing.

 wikipedia says it is sse4.1 + sse4.2

Some CPUs don't have 4.2, and some don't have 4a. You'd still need the
separate flags, so an extraneous combined flag is a bit silly.

Re: [gentoo-dev] Review: desc/cpu_flags_x86.desc

2015-01-18 Thread Gordon Pettey
On Sun, Jan 18, 2015 at 6:13 PM, Patrick Lauer wrote:

 On Sunday 18 January 2015 21:44:05 Michał Górny wrote:

  popcnt - Enable popcnt instruction support

Because Intel and AMD support it via different cpuinfo feature names. It is
popcnt on Intel, and abm on AMD. The description of the flag should also
mention that it is included in feature abm on AMD CPUs (and Intel CPUs,
but since they list popcnt separately, too, that might be confusing).

Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

2014-12-07 Thread Gordon Pettey
On Sun, Dec 7, 2014 at 3:21 PM, Kristian Fiskers

 By all means, thanks for informing about an alternative, but I
 personally believe that it is important for the overall distribution
 to keep a wider perspective than personal non-free use (even if this
 is a developers primary focus as reason for contribution), otherwise
 we'll hit a wall quickly enough.

 In this specific case I at least use pdftk for some batch jobs on
 business-related servers and a non-commercial license would not be

pdfTK is also GPLv2, (effectively GPLv3 since iText is /A/GPLv/3/?
Effectively AGPLv3 when in a public-facing service?) unless you're paying
for it. I doubt m-click would refuse to consider alternative paid licensing
if they were asked.

Re: [gentoo-dev] Re: Implicit system dependency

2014-11-23 Thread Gordon Pettey
On Sat, Nov 22, 2014 at 1:14 PM, William Hubbs wrote:

 On Tue, Nov 18, 2014 at 12:05:03AM +0100, Andreas K. Huettel wrote:
  That's at most an argument that USE=-* should be a theoretically valid
  configuration. It does not mean that the setting makes sense for anyone.
  USE=-* was maybe a reasonable idea before we had use defaults.
  Now, by setting USE=-*, you deviate from upstream defaults at random
  and pointlessly mess up the dependency calculations of python / ruby /
  multilib / ... packages.
  Message to users- if you want a minimum set of useflags, start from the
  default profile of your arch. That's what it is for. Everything else,
 and you
  sure get to keep the pieces.

 Agreed. If you want to turn things off, I would recommend starting your
 use with something like:

 USE=-foo -bar -bas ...

 so that you turn off the specific things you want to turn off.

That's quite infeasible given the number of package-level defaults. It is
far easier to parse conflicts when I know anything that has been enabled
was explicitly enabled by myself,and not through random-maintainer-X's
preference. 3743 package-level defaults of 1474 USEs is just a few too
many. Starting with USE=-* provides sanity. As has been said so many
times in this and related threads, if users wanted upstream's defaults, we
wouldn't be using a distro with USE.

Re: [gentoo-dev] Re: git security (SHA-1)

2014-09-20 Thread Gordon Pettey
You're following the wrong train down the wrong tracks. Git [0-9a-f]{40} is
to CVS 1[.][1-9][0-9]+. You're arguing that CVS is more secure because its
commits are sequential numbers.

On Sat, Sep 20, 2014 at 4:20 PM, Ulrich Mueller wrote:

  On Sat, 20 Sep 2014, hasufell  wrote:

  This is a bug in git. Do you want us to wait until it is resolved?
  Not a bug. There are VCSs (like Subversion or Bazaar) that use simple
  revision numbers to identify their commits. Git happens to use a hash,
  which is perfectly fine as long as accidental collisions are unlikely.
  Neither has to do anything with security, though.

  Because there are other VCSs it is not a bug??

 No, but with any other VCS we wouldn't have this discussion. Git using
 SHA-1 obscures the fact that an additional security layer is needed.
 This can be either a secure channel for accessing the repository
 (developers pushing their commits to it), or signed Manifests that
 ensure integrity of the tree distributed to users.

  Of course it is a bug since it is in the gpg-signing chain and to
  use it in a practical way is very unlikely.

  So you are suggesting to not migrate at all or severely break the
  workflow because someone might forge _working code_ with a specific
  SHA1? There is no efficient algorithm for that afaik, those are just
  about finding _any_ collision and even then it takes considerable
  resources that can be used to break gentoo in much easier ways.

 Weakness of SHA-1 is discussed since several years, and it is
 generally recommended that one should slowly move away from it.
 Therefore I would find it strange if we (in 2014!) deployed a system
 relying on it, while in our present Manifest files SHA-1 was already
 abandoned long time ago, in favour of more secure hashes. It looks
 like a move in the wrong direction.


Re: [gentoo-dev] Re: git security (SHA-1)

2014-09-20 Thread Gordon Pettey
On Sat, Sep 20, 2014 at 8:20 PM, Rich Freeman wrote:
On Sat, Sep 20, 2014 at 8:58 PM, Gordon Pettey wrote:
 You're following the wrong train down the wrong tracks. Git [0-9a-f]{40}
 to CVS 1[.][1-9][0-9]+. You're arguing that CVS is more secure because its
 commits are sequential numbers.

Ulrich is well-aware of that.  His argument is that with cvs there is
no security whatsoever in the scm, and so there is more interest in
layering security on-top.  With git there is more of a tendency to
rely on the less-than-robust commit signing system.

On Sat, Sep 20, 2014 at 9:17 PM, Peter Stuge wrote:

 Rich Freeman wrote:
   I've so far gotten zero feedback on my hosting offer, intended to
   help find some starting processes.
  hassufel's repository on github should be more than adequate:

 The very first email in this thread pointed out that it is difficult
 to do anything custom on github, so I offered to help because I'm
 willing and able to help arrange hooks and scripting and whatever foo
 may be needed to move on.

I can set up something in New York and/or Germany if additional hosts are

Re: [gentoo-dev] git security (SHA-1)

2014-09-15 Thread Gordon Pettey
On Mon, Sep 15, 2014 at 7:02 AM, hasufell wrote:

  * there is no known SHA-1 collision afais
  * calculating one isn't that hard. NSA might be able to do it in
  reasonable time
  * however, the algorithms to do that will come up with random garbage,
  so it's a completely different thing to hide a useful vulnerability
  behind a SHA-1 collision

 That said... an attacker who has that much resources to calculate a
 _random_ hash collision in reasonable time would certainly have a lot of
 easier attack vectors than forging a _non-random_ hash collision that
 contains actual working code (which, afaiu doesn't effectively work with
 the current attack algorithms on SHA-1).

 He could simply break into one of the ~200 developer computers. There's
 a pretty high chance at least one of them is running windows or known
 vulnerable versions of the kernel or other random packages.

 No need to waste millions of dollars on SHA-1.

Even if you wanted to burn the money to find that magical collision that
actually contains working code, you've still got to somehow propagate that
to other repositories, since they'll just ignore it for having the same
hash as an already-existing object.

Re: [gentoo-dev] Default HOMEPAGE for packages with unavailable website

2014-07-21 Thread Gordon Pettey
On Mon, Jul 21, 2014 at 5:06 PM, Alexander Berntsen

 On 21/07/14 19:41, Ciaran McCreesh wrote:
  What's wrong with HOMEPAGE=() ?
 It is not very informative.

The wiki page is equivalently informative. What's the point of metadata
that just says there's no metadata?

Re: [gentoo-dev] RFC: using .xz for doc/man/info compression

2014-05-12 Thread Gordon Pettey
On Mon, May 12, 2014 at 5:47 AM, Alexander Tsoy wrote:

 В Sun, 11 May 2014 18:26:32 -0500
 Gordon Pettey пишет:

  A lot of small files (e.g. AUTHORS, ChangeLog
  FWIW: On my system, I have 59M of bz2 files in /usr/share/man and
  /usr/share/doc. A short script to decompress those and recompress with xz
  -6e reduced that to 36M.

 Very strange o_O

 Here is my test results. xz options: --lzma2=preset=6e,dict=4MiB.
 Larger dictionary size does not improve compression ratio, I get
 even worse results with just -6e or -9e. man-bz2 is a full copy of
 my /usr/share/man, man-xz is a recompressed one.

 Size comparison:

 $ du -s man-bz2/ man-xz/
 82032   man-bz2/
 82308   man-xz

Did you skip all the files that weren't bz2 in the first place, and
decompress bz2 before compressing with xz? My comparison script does not
include uncompressed files. It copies all the bz2 files to a new folder,
pipes those through bzip -d to xz -6e to files in another new folder, then
compares the total size of those folders. Out of 8576 compressed files,
only 464 were larger in xz than in bz2. A very bad timing test I just did
showed the total decompression time of all the xz files to be half that of
decompressing all the bz2 files. Working on getting that data per-file and

Re: [gentoo-dev] RFC: using .xz for doc/man/info compression

2014-05-11 Thread Gordon Pettey
A lot of small files (e.g. AUTHORS, ChangeLog

FWIW: On my system, I have 59M of bz2 files in /usr/share/man and
/usr/share/doc. A short script to decompress those and recompress with xz
-6e reduced that to 36M. I don't have a comparison for individual file

I posted the short bash scripts at

On Sun, May 11, 2014 at 4:27 PM, Pacho Ramos wrote:

 El dom, 11-05-2014 a las 19:46 +0200, Michał Górny escribió:
  Hello, developers.
  I'd like to raise the following item for discussion: making .xz
  the default compressor used by portage for documentation, man pages
  and info files. That is, the equivalent of:
  in make.globals.
  Rationale: xz-utils is quite widespread nowadays and it is a part
  of @system set. It can achieve better compression ratio than bzip2,
  and faster decompression at the same time.
  I have confirmed that both sys-apps/man and sys-apps/man-db can
  handle .xz compressed man pages, and sys-apps/texinfo can handle .xz
  compressed info pages. Major text editors and pagers support .xz
  alike .bz2 (i.e. usually they support both or neither :)).
  The additional question is: what preset to use? To help discussing
  this, I'd like to quote the tables from 'man xz':
   Preset   DictSize   CompCPU   CompMem   DecMem
 -0 256 KiB   03 MiB1 MiB
 -1   1 MiB   19 MiB2 MiB
 -2   2 MiB   2   17 MiB3 MiB
 -3   4 MiB   3   32 MiB5 MiB
 -4   4 MiB   4   48 MiB5 MiB
 -5   8 MiB   5   94 MiB9 MiB
 -6   8 MiB   6   94 MiB9 MiB
 -7  16 MiB   6  186 MiB   17 MiB
 -8  32 MiB   6  370 MiB   33 MiB
 -9  64 MiB   6  674 MiB   65 MiB
   Preset   DictSize   CompCPU   CompMem   DecMem
-0e 256 KiB   84 MiB1 MiB
-1e   1 MiB   8   13 MiB2 MiB
-2e   2 MiB   8   25 MiB3 MiB
-3e   4 MiB   7   48 MiB5 MiB
-4e   4 MiB   8   48 MiB5 MiB
-5e   8 MiB   7   94 MiB9 MiB
-6e   8 MiB   8   94 MiB9 MiB
-7e  16 MiB   8  186 MiB   17 MiB
-8e  32 MiB   8  370 MiB   33 MiB
-9e  64 MiB   8  674 MiB   65 MiB
  I'd like to note here that increasing dictionary size over file size
  does not improve compression. However, the options involved in CompCPU
  Depending on the expected amount of complexity, I'd either go for:
  1) -6e (or -6, the default) -- max CompCPU, reasonable use of memory,
  and dictionary larger than most (or all?) documents that are going to
  be compressed,
  2) -Ne with minimal 'N' for CompCPU==8 and DictSize  filesize -- still
  max compression ratio while keeping lowest memory requirements possible.
  Your thoughts?


 Looks like bzip2 was still better for small files :/

Re: [gentoo-dev] RFC GLEP 1005: Package Tags

2014-03-28 Thread Gordon Pettey
And now you file a bug to get that incorrectly applied terminal tag
changed to cli, because they don't mean the same thing.

On Fri, Mar 28, 2014 at 4:06 PM, Kent Fredric wrote:

 On 29 March 2014 09:56, yac wrote:

 terminal ∩ jabber ∩ client

 And now you want *only* terminal terminals, do you have to search for

 terminal ∩ !( jabber ∪ client ∪ everything ∪ else ) ?


 terminal ∩ emulator

 ( Which may include terminals for emulators instead of terminal emulators )


Re: [gentoo-portage-dev] [PATCH v3] Test for read-only filesystems, bail out during preinst if there are any which will be written to and display a useful error message. Fixes bug 378869.

2014-01-20 Thread Gordon Pettey
If your going to make that argumint, ewe mite a's well right the
documentation in LOL-1337. Encouraging bad grammar in documentation just
make's thing's harder for everybody.

On Mon, Jan 20, 2014 at 9:28 PM, Mike Frysinger wrote:

 On Sunday 19 January 2014 05:39:25 Alexander Berntsen wrote:
  On 19/01/14 10:17, Mike Frysinger wrote:
   prefer OSes - OS's
  That's just not proper English.

 i don't think that phrase means what you think it means.  if you're wishing
 for English to be a standard, then you're in for a rude surprise.

  It makes no sense.

 of course it does.

  Please don't prefer
  that. If for nothing else, then to prevent me from sighing whenever I
  have to read it.

Re: [gentoo-dev] Portage Feature Request: making thirdpartymirrors easier to manage

2014-01-11 Thread Gordon Pettey
On Thu, Jan 9, 2014 at 9:26 AM, Ben Kohler wrote:

 On Mon, Jan 6, 2014 at 2:20 PM, Robin H. Johnson robb...@gentoo.orgwrote:

 I would like to make it a directory instead of a single file, and extend
 the internal syntax.

 I'm not sure I see much real value in allowing individual profiles to
 add/remove mirrors from each group, to be honest.  Maybe I'm just not
 thinking of the right scenarios.

Ignorant question: Can overlays modify profile easily (if at all?) If not,
then taking mirror lists out of profile seems rather sane, and would allow
overlays to add their own mirrors.

Spec thought:

1. make.conf should define MIRROR_REGIONS, which is a space separated list
of Region/Subregion/Locality strings (e.g.
north_america/united_states/texas europe/germany/düsseldorf).
2. Using the file layout as bkohler suggested (e.g.
mirrorname may be a file or a directory. If it is a directory, it may
contain a file named mirrorlist if there are global mirrors, and it may
contain any number of region-named files or directories.
3. If a region-named file is a directory, then it must contain either a
file mirrorlist if it has region-level mirrors, or files/directories for
4. When emerge fetches a file, if the most specific region (of the first
entry, if there are multiple entries) is not found, move up to the next
greater-sized region (one directory up). If that region exists, then
concatenate all of its subregions into the list to select a URL from. If it
doesn't exist, move up another level, and again, if it is found,
concatenate everything below it into the list of possible URLs. If the
final top-level region isn't found, move to the next MIRROR_REGIONS entry,
if it exists. Otherwise, concatenate every available region for that mirror
into the list.

This could all be done in a flat XML (or YAML, to avoid boilerplate) file,

Re: [gentoo-dev] OCSP was: friendly reminder wrt net virtual in init scripts

2013-11-06 Thread Gordon Pettey
On Wed, Nov 6, 2013 at 7:36 PM, Alex Xu wrote:
 On 06/11/13 08:00 PM, Michael Orlitzky wrote:
 On 11/06/2013 02:11 PM, Thomas D. wrote:

 This is going OT but I cannot leave this statement uncommented,
 because from my knowledge this is wrong/you are hiding important
 information everyone should know about:

 I figure everyone here is smart enough to google OCSP before
 unchecking the box. This isn't the place to argue that the CA system
 is broken, but I will respond to a few points.

 I figure everyone here is smart enough not to spread knowingly-incorrect

 Regarding your privacy concerns: No, your OCSP-enabled browser
 won't share the address (URL) with the OCSP responder. Your browser
 will use the site's certificate serial number to ask the OCSP
 responder if the certificate is still valid. Yes, the company who
 is running the OCSP responder is able to log You [IP, UA...]
 requested status for certificates with the serial number 0x1, 0x2,
 0x3 and because the OCSP responder needs some basic knowledge
 about the certificates it should provide answers for, the operator
 may know that the certificate with the serial number 0x1 has the
 Common Name (CN) www.mysecretsite.invalid and 0x2 was issued for
 www.mydarksecrets.invalid or 0x3 was for, but
 the operator doesn't know the URL you visited.

 This is a long way of saying it sends the address of every website
 you visit to a third party.

 Addresses, in the context of web browsing, are commonly understood to
 mean URLs, which include protocol, name, port, and path.

 OCSP only sends the name portion. Thus, the statement was a long way
 of saying you are wrong..

A bit of additional consideration:

Given the above statement and RFC 2560, OCSP sends the certificate serial,
not the name. With the availability of Wildcard certificates and the
subjectAltName parameter, with many certificates that serial will not let the
CA actually know which domain you are visiting.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/base: ChangeLog package.use.force

2013-07-19 Thread Gordon Pettey
On Fri, Jul 19, 2013 at 10:53 AM, Markos Chandras hwoar...@gentoo.orgwrote:

 On 19 July 2013 16:46, Michał Górny wrote:
  Dnia 2013-07-19, o godz. 16:11:52
  Markos Chandras napisał(a):
  On 19 July 2013 16:04, Ian Delaney (idella4)
   +# Ian Delaney (17 July 2013)
   +# Selection of IUSE flags for bin build.
   +dev-python/pypy-bin bzip2 ncurses sqlite ssl xml
  I don't understand that. Why not use +bzip2 +ncurses +sqlite +ssl +xml
  in the ebuild?
  I guess that's because they are not optional :).

 So why are these features behind use flags?

Wild guess: It's -bin. It's built with those flags. You can't choose to
install it with flags other than what it was built with.