Re: [gentoo-dev] Gentoo i486 support

[R0b0t1]

On Wed, Aug 22, 2018 at 8:08 AM, Rich Freeman  wrote:
> 1.  Museum hardware.  People have systems that are running simply
> BECAUSE they are old, not because they are cost-effective/etc.  I'm
> not sure I'd even lump used hardware into this category any longer, as
> I'm sure there are plenty of i686+ used PCs at rock-bottom prices
> already out there, and maintaining pre-Y2K hardware is going to be
> fairly painful.  For this use case i386 as the baseline makes a LOT of
> sense.
>
> 2.  Non-museum hardware.  People have x86 hardware because it is the
> most cost-effective solution for a task, and not merely because it is
> old.  IMO for this use case i686 makes a lot more sense as a baseline.
> However, I'm honestly not sure in this day and age what these use
> cases even are, unless it is something you can buy for $10 at a flea
> market.  Even if you're talking about a container running one
> application that only needs 500kB of RAM, is there really that much
> benefit to not building it for amd64?
>

I don't want to get very offtopic, but:

Even newer embedded i586 and i686 hardware isn't cost effective
considering power consumption. When considering power it often does
not even make sense to run donated hardware ~5 years old.

I don't think this should be used to completely drop support for older
platforms but it is probably the best argument to use to convince
people to get rid of their old hardware.


> The other argument for i386 would be that in Gentoo nobody is stuck
> with the defaults.  So, a default that works more widely as an entry
> point makes a lot of sense, since anybody can set CFLAGs and do an
> emerge -e world to get the benefits.  Then again, if we're talking
> about older but not ancient hardware that is still quite a bit of
> build time.
>

This is definitely in the spirit of Gentoo, but I think the most
concrete reason to support older platforms is they are demonstrably
more secure and people may be using them for that reason.

Cheers,
R0b0t1

Re: [gentoo-dev] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys

[R0b0t1]

On Wed, Jul 4, 2018 at 7:18 PM, Joshua Kinard  wrote:
> On 7/4/2018 7:22 PM, Kristian Fiskerstrand wrote:
>> On 07/05/2018 01:07 AM, Joshua Kinard wrote:
>>>> @@ -64,6 +66,8 @@ not be used to commit.
>>>>
>>>> b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
>>>>
>>>> +   c. ECC, curve 25519
>>>> +
>>>>  3. Key expiry: 5 years maximum
>>>>
>>>>  4. Upload your key to the SKS keyserver rotation before usage!
>>>>
>>> Add a minimum key size here for ECC.  They have different bit sizes than
>>> classic DSA/RSA keys.  A quick read indicates that a 224-bit ECC key is 
>>> roughly
>>> equivalent to a 112-bit symmetric key, which is what a 2048-bit RSA key is
>>> equivalent to, so the logical minimum for ECC looks like 'nistp256'.  The
>>> maximum is 521-bits on ECC (nistp521).
>>>
>>> Also move the mention of Ed25519 keys to their own bullet and clarify that 
>>> they
>>> don't allow for a key length, as I think that's hardcoded in some capacity.
>>
>> following the comma-style of the rest of the document, the ECC part
>> should likely be read as curve25519 being the only acceptable curve,
>> which is 256 bits (roughtly 128 bit shannon entropy equivalent)
>>
>> that said, I'm not aware of any curves defined with a lower security
>> margin than this for OpenPGP in general. The known curves in the
>> ecosystem are
>>
>> let oid_to_psize oid =
>>let psize = match oid with
>>  | "\x2b\x81\x04\x00\x23" -> 521  (* nistp521 *)
>>  | "\x2b\x81\x04\x00\x22" -> 384  (* nistp384 *)
>>  | "\x2a\x86\x48\xce\x3d\x03\x01\x07" -> 256  (* nistp256 *)
>>  | "\x2b\x24\x03\x03\x02\x08\x01\x01\x07" -> 256  (* brainpoolP256r1 *)
>>  | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0b" -> 384  (* brainpoolP384r1 *)
>>  | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0d" -> 512  (* brainpoolP512r1 *)
>>  | "\x2b\x81\x04\x00\x0a" -> 256  (* secp256k1 *)
>>  | "\x2b\x06\x01\x04\x01\xda\x47\x0f\x01" -> 256  (* Ed25519 *)
>>  | _ -> failwith "Unknown OID"
>>
>
> By "only acceptable curve", do you mean we shouldn't allow the nistp* key
> types, only Ed25519?
>

Yes, the NIST curves are extremely suspect. I even have my doubts
about Ed25519; I personally only use it where a device has throughput
problems with RSA.

Cheers,
 R0b0t1

Re: [gentoo-dev] Trustless Infrastructure

[R0b0t1]

On Mon, Jul 2, 2018 at 11:47 AM, Jason A. Donenfeld  wrote:
> On Mon, Jul 2, 2018 at 6:02 PM R0b0t1  wrote:
>> Signed hashes should be faster, no? Each directory with files could
>> have a manifest.
>
> Signatures work over hashes of data, anyway. I think what you're
> wondering, though, is the granularity of each signature? I'd recommend
> this be done on the per-file level, since we wouldn't want gentoo devs
> signing files in a directory they haven't actually inspected. For
> example, eclasses.
>

Ah, okay then - I think at one time in the past GPG did something
strange with file contents directly, or perhaps the implementation was
just inefficient. It was maybe related to Debian where I first read
about this? They were signing an .iso directly and found it was faster
to hash it and then sign the hash.

>>
>> > - Ensure the naming scheme of portage files is sufficiently strict, so
>> > that renaming or re-parenting signed files doesn't result in RCE. [*]
>> > - Distribute said .asc files with rsync per usual.
>>
>> Rsync would work with this setup, but there is also webrsync-gpg in
>> Portage right now. This covers the vast majority of usecases right
>> now.
>
> Not sure whether you've missed the point or if you're responding to
> something slightly different, but it's worth noting that both rsync
> and webrsync-gpg right now check against infra signatures, rather than
> developer signatures, and this is a big problem.

Right, I lost track of that. The infrastructure or release developers
are implicitly trusting all developers, so I suppose cutting out the
middleman will reduce work.

Re: [gentoo-dev] Trustless Infrastructure

[R0b0t1]

On Mon, Jul 2, 2018 at 10:36 AM, Jason A. Donenfeld  wrote:
> Hey guys,
>
> While our infrastructure team has some nice technical competence, the
> recent disaster and ongoing embarrassing aftermath has made ever more
> urgent the need to have end-to-end signatures between developers and
> users. While the infrastructure team seems fairly impressive at
> deploying services and keeping the house running smoothly, I'd rather
> we don't place additional burden on them to do everything they're
> doing securely. Specifically, I'd like to ensure that 100% of Gentoo's
> infrastructure can be hacked, yet not backdoor a single witting user
> of the portage tree. Right now, as it stands, rsync distributes
> signatures to users that are derived from some
> infrastructure-controlled keys, not from the developers themselves.
>
> Proposal:
> - Sign every file in the portage tree so that it has a corresponding
> .asc. Repoman will need support for this.

Signed hashes should be faster, no? Each directory with files could
have a manifest.

> - Ensure the naming scheme of portage files is sufficiently strict, so
> that renaming or re-parenting signed files doesn't result in RCE. [*]
> - Distribute said .asc files with rsync per usual.

Rsync would work with this setup, but there is also webrsync-gpg in
Portage right now. This covers the vast majority of usecases right
now. There is often no need to sync more than once per day.

Speaking of, the keys for that have lapsed. Will they be updated?

Cheers,
 R0b0t1

Re: [gentoo-dev] Re: Mailing list moderation and community openness

[R0b0t1]

here people can argue. And the impression is correct, because
>> this actually *is* the intention if you are honest.
>
> Certainly this is the intention, at least for my part.  There is no
> benefit in arguing about this for more than a year, especially if
> those who made the decisions get re-elected to their posts.
>
>> Of course, it will not close said debate. The debate will just happen
>> on another channel. (Which in this example might be appropriate, but
>> pointing to the proper channel is what should have happened and not
>> closing a mailing list and thus excluding random people from posting
>> things about clompletely different topics which *are* on-topic on dev-ml).
>
> People have repeatedly pointed out the correct places for such
> debates, though honestly if it were my call I'd not allow this debate
> to go on further anywhere that Gentoo operates.
>
> People post this stuff on the -dev list for the same reason that
> protesters block public streets.  They want to make it hard to ignore
> them.
>
>>
>>> Sure, but we can at least force the negative advertising of Gentoo to
>>> go elsewhere, rather than basically paying to run a negative PR
>>> campaign against ourselves.
>>
>> Closing dev-ml will not help here. If people have a strong
>> disagreement with a decision, this will happen on gentoo channels.
>> If you want to prevent it technically, you have to close all channels.
>
> Agree.  But, I don't make the decisions.  If it were up to me this
> topic would be closed everywhere.
>
>> BTW, I do not think that contributors are that blue-eyed that they
>> will stop contributing only because one person does not know how to
>> behave.
>
> The problem comes when the person is booted out and a half dozen
> people keep arguing that they were innocent, that Gentoo is run by a
> cabal in an ivory tower, and that decisions like this should be made
> more openly.  IMO this is the sort of thing that is more likely to
> drive contributors away, because it has a veneer of legitimacy.  The
> arguments in favor of that position are simple, and the arguments
> against it are nuanced and often rely on access to non-public
> information.
>

It has a veneer of legitimacy? Perhaps the complaints are legitimate?

Imagine the outcry if a court made decisions in private and did not
release names of the accusers and the accused.

> You can ignore their posts but then people assume they're right.  So
> either we get endless argument (more than a year), or we need to
> exercise prior restraint.  Neither is desirable, but I've yet to see
> another option presented.
>

Don't present a false dichotomy - you could begin releasing
information. Every argument as to whether or not that is a valid
decision has been ignored.

Cheers,
 R0b0t1

Re: [gentoo-dev] Fw: "Please let's talk if spamming everyone pointlessly is really needed."

[R0b0t1]

On Sat, Jun 9, 2018 at 6:28 AM, Michał Górny  wrote:
> W dniu sob, 09.06.2018 o godzinie 13∶14 +0200, użytkownik Jeroen Roovers
> napisał:
>> Behold the magic of emergency announcements.
>>
>
> For the record, I would like to point out that his mail to you was sent
> *earlier* than your 'emergency announcement'.  And before you start
> claiming it's clock drift: I've verified that in SMTP logs.
>
> In other words, I see both your mails as nothing but an attempt to
> incite hostility towards fellow developers through attempting to provide
> false connections between events which have clearly occurred
> independently.
>

>From here it looks like:
1) A lot of bugs were modified.
2) Someone decided this was not good.
3) After thinking about it some more, no one actually cares.

Unless Mr. Roovers has admitted to some sort of conspiracy I don't
think it wise to accuse him of participating in one.

Re: [gentoo-dev] [RFC] multiversion ebuilds

[R0b0t1]

On Wed, May 16, 2018 at 2:38 AM, Michał Górny <mgo...@gentoo.org> wrote:
> W dniu sob, 12.05.2018 o godzinie 14∶20 +0200, użytkownik Gerion Entrup
> napisał:
>> Hi,
>>
>> just an idea for now. But what you think about multiversion ebuilds?
>> Technically this could be realized with the following line in the ebuild 
>> itself:
>> ```
>> VERSIONS=( 3.0.11 3.0.12 3.1 )
>> ```
>>
>> and the filename without version:
>> //.ebuild
>>
>> together with this set of rules:
>> 1. If there is an ebuild with had a version in its name, this ebuild is 
>> preferred.
>>  e.g. is a tree consists of "foobar/foobar-1.1.ebuild" and 
>> "foobar/foobar.ebuild" for version 1.1 the specific ebuild is taken.
>> 2. If the ebuild has the variable VERSIONS specified but also a version in 
>> its name, the version in its name is taken.
>> 3. There can be only one multiversioned ebuild per package.
>>
>> Different version keywording can be done as before:
>> ```
>> if [[ ${PV} == "3.1" ]] ; then
>>   KEYWORDS="~amd64 ~x86"
>> else
>>   KEYWORDS="amd64 x86"
>> fi
>> ```
>>
>> The resolution of versions can be done as before, with the difference that 
>> one ebuild can represent multiple versions.
>>
>> The "ebuild" tool needs some adjustments. Maybe it tries to download and 
>> build all version per default and has an additional flag to specify a single 
>> version.
>>
>> The advantages of this idea I see are:
>> - Ebuilds are written in a multiversion manner anyway, and then get copied 
>> (or linked?), so it can be made explicit.
>> - The diffs between different versions of ebuilds and the commit history are 
>> way more readable.
>> - The size of the tree reduces.
>>
>
> In my opinion, this puts more effort into inventing a problem than
> solving one.  In order to consider a particular idea thouroughly, you
> should also consider potential disadvantages, rather than focusing
> purely on advantages as you see them.
>
> While one might think that this will help developers, it is going to be
> a maintenance nightmare.  Just compare the workflow.
>
> Currently, adding a patch affecting runtime involves copying the ebuild,
> and applying the patch.  Later on, the old revision is just removed.
> With your solution, you need to adjust VERSIONS, add conditional; later
> on, you need to adjust VERSIONS, find all conditionals, remove them.
> Not only it involves more work but also increases the risk of accidental
> breakage.
>
> The arch team work is going to become a nightmare.  Currently, they just
> use 'ekeyword' tool to mass-edit ebuilds.  With your solution, they're
> now have to find the correct conditional (or add one), and update
> keywords there.  I can already imagine monsters like:
>
>   if pv1; then
> KEYWORDS="~amd64"
>   elif pv2; then
> KEYWORDS="amd64 ~arm64 x86"
>   elif pv3; then
> KEYWORDS="~amd64 ~arm64 ~x86"
>   elif pv4; then
> KEYWORDS="amd64 ~arm64 ~x86"
>   fi
>

Instead of VERSIONS=( 3.0.11 3.0.12 3.1 ) use KEYWORD_AMD64=( 3.0.11
3.0.12 ~3.1 ).

This would require a variable per arch. It would be possible to create
another structure to contain *these* in some way if having multiple
variables is something that should be avoided at all costs.

Cheers,
 R0b0t1

Re: [gentoo-dev] Re: [RFC] multiversion ebuilds

[R0b0t1]

On Tue, May 15, 2018 at 11:15 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Mathy Vanvoorden posted on Tue, 15 May 2018 11:32:30 +0200 as excerpted:
>
>> 2018-05-12 14:20 GMT+02:00 Gerion Entrup <gerion.ent...@flump.de>:
>>
>> just an idea for now. But what you think about multiversion ebuilds?
>>> Technically this could be realized with the following line in the ebuild
>>> itself:
>>> ```
>>> VERSIONS=( 3.0.11 3.0.12 3.1 )
>>> ```
>>>
>>
>> I like the idea of multiversion ebuilds but why would you complicate the
>> process by putting it in a variable? Why not just use symlinks and have the
>> following:
>>
>> foobar/foobar-1.x
>> foobar/foobar-1.1.ebuild -> foobar-1.x
>> foobar/foobar-1.2.ebuild -> foobar-1.x
>> foobar/foobar-2.x
>> foobar/foobar-2.1.ebuild -> foobar-2.x
>
> AFAIK symlinks aren't allowed in the gentoo tree, with the given reason
> being that some users, particularly those with limited net access and
> thus "sneakernetting" from where they /do/ have net access, may place
> the tree on or transfer it via no-symlink-support FAT32 or similar,
> perhaps downloading it from an MS machine or the like.
>
> Of course users may use symlinks on their own copies, but they're not
> allowed in the official tree.
>
> Tho perhaps that can be reevaluated.  But while there's more connectivity
> now than over a decade ago when that policy was created, I expect there's
> still those paying by the meg or gig for net access locally, that won't
> enjoy having their sneakernet sync routine disrupted.
>

Cygwin and MSYS(2) are currently mostly supported by Prefix, so using
symlinks might kill them as well. There is some kind of symlinking
support for NTFS now but it is very primitive.

Cheers,
 R0b0t1

Re: [gentoo-dev] [RFC] multiversion ebuilds

[R0b0t1]

On Sat, May 12, 2018 at 7:20 AM, Gerion Entrup <gerion.ent...@flump.de> wrote:
> - The size of the tree reduces.
>

If this is a big concern you may be able to mount the portage tree
under a compressed loopback filesystem. It may even be worth
considering that as a recommended-by-handbook default as the benefit
for compressing the ebuilds is likely huge anyway.

Cheers,
 R0b0t1

Re: [gentoo-dev] Regarding the State of PaX in the tree

[R0b0t1]

On Sun, Apr 15, 2018 at 7:04 PM, Anthony G. Basile <bluen...@gentoo.org> wrote:
> Hi everyone,
>
> Magnus (aka Zorry) and I have been talking about what to do with PaX in
> the Gentoo tree.  A year ago, grsecurity.net upstream stopped providing
> open versions of their patches to the community and this basically
> brought an end to sys-kernel/hardened-sources.  I waited a while before
> masking the package in the hope that upstream might reconsider.  There
> were also some forks but I didn't have much confidence in them.  I'm not
> sure that any of these forks have been able to keep up past
> meltdown/specter.
>
> It may be time to remove sys-kernel/hardened-sources completely from the
> tree.  Removing the package is easy, but the issue is there is a lot of
> machinery in the tree that revolves around supporting a PaX kernel.
> This involves things like setting PaX flags on some executables either
> by touching the ELF program headers or the file's extended attributes,
> or applying custom patches.
>
> The question then is, do we remove all this code?  As thing stands, its
> just lint that serves no current purpose, so removing it would clean
> things up.  The disadvantage is it would be a pita to ever restore it if
> we ever wanted it back.  While upstream doesn't provide their patch for
> free, some users/companies can purchase the grsecurity patches and still
> use a custom hardened-sources kernel with Gentoo.  But since we haven't
> been able to test the pax markings/custom patches in about a year, its
> hard to say how useful that code might still be.
>
> I'm just emailing everyone to get advice.
>

I retain hope that compatible features will be added to the kernel.
Consequently, I would appreciate if the machinery can be left. If it
becomes a maintenance burden in the future I suspect that would be a
good time to remove it.

Cheers,
 R0b0t1

Re: [gentoo-dev] Re: Mailing list moderation and community openness

[R0b0t1]

I really do hate discussing this. I will pray for Gentoo, friends, as
I hope the distribution continues to receive useful contributions.


On Tue, Mar 27, 2018 at 11:39 AM, Rich Freeman <ri...@gentoo.org> wrote:
> Now a bunch of community members get upset about Fred being booted out
> without reason.  Fred claims it is because he disagrees with the
> leadership on something.  People start arguing endlessly about
> openness.
>

Explain why the user was removed.

> Ultimately the leaders just want Fred gone so that new contributors
> aren't getting driven away.  They can't explain that because then they
> create potential civil liability for the project.  The problem is that
> the debate goes on for over a year despite intervening elections and
> now this becomes the issue that is driving new contributors away.
>

This is insane. If they sue produce the emails. At least in the US,
the suit will be thrown out, as truth is a defense to defamation.

If I am not a lawyer and as such can not understand the law and my
opinion should not be trusted, then, as I assume you are not a lawyer,
your opinion should not be trusted either. Even if you have consulted
with a lawyer you are not a lawyer and there is no reason to believe
you could have understood what the lawyer told you.

I do not present this as sophistry: for any progress to be made in the
discussion of your hypothetical situation I sincerely think you need
to consider the above. At what point is one's knowledge of the law
enough to act within society?

> What solution would you propose for this problem?  It isn't
> hypothetical at all - I can think of one case in Gentoo's past where
> this happened that I'm aware of, and I'd be shocked if it were the
> only one.
>

Stop using the law as a boogeyman.

Be transparent in why decisions were made. There are no legal concerns
save fair use (the copyright of any published emails) and the
publication of private facts.[1] For a tort involving the disclosure
of public facts, you would need to have no reason to publish those
facts save for the damage they could cause. You may also need to
publish them in a manner far more public than a Linux distribution
mailing list.


To continue the example I doubt anyone would care if it was just a
single Fred, though they may be slightly put off. Multiple Fred (or
related) incidents later it would seem rather strange.

As I have tried to explain my issue with the closure of the mailing
list is not the removal of a user, but the lack of openness with which
decisions are made. Points are brought up in good faith and then
ignored. Requests for clarification may not be greeted amicably.
Overall, this makes it seem like the closure of the development list
is to keep decisions from being questioned. If there were hecklers
asking stupid questions that would be one thing, but that is not what
it looks like to me.


I will note most developers go quietly about maintaining their charges
and make reasonable decisions.

Cheers,
 R0b0t1


[1]: http://www.dmlp.org/legal-guide/publication-private-facts

Re: [gentoo-dev] Mailing list moderation and community openness

[R0b0t1]

On Wed, Mar 21, 2018 at 9:44 AM, Alec Warner <anta...@gentoo.org> wrote:
> The community has a 'toxic people problem'

Maybe certain people who feel they are being attacked are idiots and
don't like hearing it? I can't tell, and I suspect other people can't
either.

Respectfully,
     R0b0t1

Re: [gentoo-dev] Integrating Portage with other package managers

[R0b0t1]

On Fri, Mar 9, 2018 at 10:17 AM, Alec Warner <anta...@gentoo.org> wrote:
> The containers are nominally stateless, so there is less chance of 'gunk'
> building up and surprising me later. It also makes the lifecycle simpler.
>
> Obviously its somewhat harder for stateful services (databases, etc.) but I
> suspect things like SANs (or Ceph) can really provide the storage backing
> for the database.
> (database "schema" cleanliness is perhaps a separate issue that I'll defer
> for another time ;p)
>

Restated:

Containers are stateless, which prevents programs from munging state,
because there is none. This is okay except when one needs state, which
one does for most desktop activities.

This implies it doesn't solve the problem. Working around it may be
valid, but only if state can be preserved.

Cheers,
 R0b0t1

Re: [gentoo-dev] Functional portage with namespace (Was: Integrating Portage with other package managers)

[R0b0t1]

On Thu, Mar 8, 2018 at 7:06 PM, Rich Freeman  wrote:
> On Thu, Mar 8, 2018 at 7:46 PM, Benda Xu  wrote:
>> Rich Freeman  writes:
>>
>>> If you have util-linux installed then try running (as any user - you
>>> don't have to be root): unshare -i -m -n -p -u -C -f --mount-proc -U
>>> -r /bin/bash
>>>
>>> Congrats.  You are now root in a container.  You're in the same root
>>> filesystem as always.  You'll note that you can't actually see
>>> anything that you couldn't see before.  If you run ps -ea you'll see
>>> that you're the only process running on the system.  Devices like
>>> /dev/sda aren't actually accessible.  A lot of container managers
>>> would mount a new /dev and just hide most of that stuff.  You can
>>> probably imagine how something like this could be useful for isolating
>>> processes.
>>
>> Just a side node, this seems to be the ultimate sandbox we (Gentoo and
>> portage) are after.  With this, we might even be able to have portage
>> full functional: a build is completely determined and only determined by
>> the dependencies and USE flags.
>>
>
> I'm not sure how well this would perform, but I had given this a bit
> of thought a few years ago.  There are two obvious ways to go about
> this: the sandbox or containers.
>

It may be possible to use fanotify(7) (but this would only catch disk
access). There is an extension to fanotify created as someone's thesis
(http://lkml.iu.edu/hypermail/linux/kernel/1703.1/05249.html) that
allows recursive watches. One of the features of fanotify is that it
is possible to deny the events generated. The fanotify API may
simplify the application of the generated rules. It was designed to be
fast, and most processing is done in the kernel when calls are made.

Sadly interest in the patches seems to have waned. The functionality
is not exactly duplicated in containers, but they do make it easier to
find changes.

Re: [gentoo-dev] Integrating Portage with other package managers

[R0b0t1]

On Thu, Mar 8, 2018 at 11:50 AM, Rich Freeman  wrote:
> If you have util-linux installed then try running (as any user - you
> don't have to be root):
> unshare -i -m -n -p -u -C -f --mount-proc -U -r  /bin/bash
>

Interesting. I hadn't found a good interface to containers and
clone(2) besides Docker. Of course, I didn't look very hard. I half
expect a "new" process model to develop around the kernel namespaces,
as people realize GID separation only is too coarse.

I still see some odd claims about container security, though: claiming
containers are more secure than user accounts still seems odd to me,
as if you don't trust the kernel to enforce user accounts, why trust
it to enforce namespace separation?

Re: [gentoo-dev] Integrating Portage with other package managers

[R0b0t1]

On Wed, Mar 7, 2018 at 3:06 PM, Rich Freeman <ri...@gentoo.org> wrote:
> On Wed, Mar 7, 2018 at 3:55 PM, R0b0t1 <r03...@gmail.com> wrote:
>> On Wed, Mar 7, 2018 at 1:15 PM, Alec Warner <anta...@gentoo.org> wrote:
>>>
>>> Because containers are awesome and are way easier to use.
>>>
>>
>> I think you missed my point: Why are they easier to use?
>>
>
> I suspect that he was equating "containers" with "Docker," which both
> runs containers and also is an image management solution (one that I
> don't particularly like, but probably because I don't have heavy needs
> so I find myself fighting it more than anything else - it doesn't hurt
> that for the life of me I can't get it to connect containers to my
> bridge, and it seems like it is completely opposed to just using DHCP
> to obtain IPs).
>
> But, if you're using Docker, sure, you can run whatever the command is
> to download an image of a container with some software pre-installed
> and run it.
>
> If you're using something other than Docker to manage your containers
> then you still have to get the software you want to use installed in
> your container image.
>

I think I was equating containers to Docker as well. My point was
instead of trying to manage dependencies, containers allow people to
shove everything into an empty root with no conflicts. The
enthusiastic blog post seems to restate this.

Re: [gentoo-dev] Integrating Portage with other package managers

[R0b0t1]

On Wed, Mar 7, 2018 at 1:15 PM, Alec Warner <anta...@gentoo.org> wrote:
>
>
> On Wed, Mar 7, 2018 at 1:22 PM, R0b0t1 <r03...@gmail.com> wrote:
>>
>> On Wed, Mar 7, 2018 at 11:52 AM, Alec Warner <anta...@gentoo.org> wrote:
>> > On Wed, Mar 7, 2018 at 11:51 AM, Michael Orlitzky <m...@gentoo.org>
>> > wrote:
>> >>
>> >> On 03/07/2018 11:06 AM, anote...@teknik.io wrote:
>> >> > Why should portage download some outdated second copy of the
>> >> > sources for 'bar', rebuild it, and scatter it around the file system
>> >> > where it cannot be used by other programs installed by cabal?
>> >>
>> >
>> > I'm really not happy with the tone of this email, so I'm going to
>> > comment on
>> > it a bit.
>> >
>>
>> I can't help but agree with Mr. Orlitzky's sentiment. All language
>> package managers suffer from the same sophomoric problems:
>>
>>
>> 1) I usually don't know where things are downloaded from.
>> 2) I can't integrate these changes with my distrbution (Gentoo,
>> Ubuntu, Debian, Fedora, CentOS) safely without serious work.
>> 3) I can't figure out easily what dependencies a package has. Usually
>> I see if there are compile or runtime errors. Sometimes the
>> dependencies are listed somewhere. If the dependency is not what is
>> currently in e.g. Ubuntu's repository, I may have to maintain separate
>> versions to be compatible.
>> 4) Sometimes they aren't set up to be built at all. Let the magic
>> package manager do everything for you. This works, except when your
>> shared objects are not in the right places. (But it makes me feel
>> dirty.)
>>
>> >>
>> >> These other package managers don't solve any hard problems -- they're
>> >> basically a fancy interface around wget and "git clone." Portage on the
>> >> other hand has ~20 years of good ideas and hard work on the hard
>> >> problems in package management. For example...
>> >
>> >
>> > Portage is also full of not-good ideas; many of these we papered over
>> > with
>> > PMS and EAPI to make
>> > the actual API people use less horrific. Lets not preach from our ivory
>> > tower here.
>> >
>>
>> The magnitude of "not good" is, I would suggest, very different.
>>
>> Cabal is a pretty hilarious example. Have you ever tried to build it
>> without using the release binaries? I suppose this is a second problem
>> though, where people want to be "self-reliant" and instead just end up
>> making things impossible to verify or make reproducible.
>>
>> For the longest time Cabal did not authenticate or verify the code it
>> would run (as root). Very recently this was fixed, but I still feel
>> bad any time I let it run, even if it's on a separate development
>> system.
>
>
> Gentoo just got signature checking enabled by default...in ~arch? I'm not
> sure if that version of portage is stable yet.
> Like I said, be careful how one preaches from the ivory tower.
>

webrsync-gpg has been an option for a long time.

Package maintenance for Gentoo is not the ivory tower. If anything,
the ivory tower is language development, in that tower the language
developers are isolated from the wider reaching consequences of their
actions.

>>
>>
>> >>
>> >> > It seems reasonable to me to 'hook' portage into these other package
>> >> > managers, so that running 'emerge bar' would actually run 'cabal
>> >> > install
>> >> > bar'
>> >>
>> >> Can "cabal install" build or even identify the C libraries that your
>> >> Haskell package needs? No, because nobody ever thought of that, and it
>> >> seems kind of hard now that the cabal build system has no ability to
>> >> build non-Haskell packages, so no one is ever going to work on it.
>> >>
>> >> Can "cabal install" rebuild your Haskell packages when the ABI of some
>> >> library changes? No, because "cabal install" doesn't have any idea
>> >> what's installed on your system.
>> >>
>> >> Can "cabal install" uninstall a package? Nope, it has no idea what was
>> >> done during the installation, and thus no idea what to undo.
>> >>
>> >> Can "cabal install" verify the integrity of your downloaded source
>> >> code?
>> >> No, because by design it fetches and runs code from complete

Re: [gentoo-dev] Integrating Portage with other package managers

[R0b0t1]

up with it I will find something more
stable.
4) True, but prefix would be a lot better at fixing that problem. If
not that, something like virtualenv.

In the case of either #3 or #4, the distribution developers prefer you
use their package manager to install packages. You are only safe doing
anything else in an environment like virtualenv, which does not exist
for the vast majority of languages. This is why developers will pass
around VM images, or devote an entire VM to development on a project.
Languages and their packages are not designed to be compartmentalized
and will trash your installation.

There is also (going along with #4):
5) The software may need to work on Windows. They could have used
Cygwin or MSYS2. Anything else is an exercise in futility. People have
come before you and done it better.

Taken together these issues boil down to "the people rewriting package
managers don't realize the problems they actually have" which agrees
with what was said. As above, the typical workflows of these people
involve lots of VMs or containers. Ask yourself "why?"

>
>>
>> If you want to eliminate the duplication of effort, tell these people to
>> use Gentoo Prefix instead of writing the N+1st crippled PM. Doing it the
>> other way around won't work because we'd be replacing one good thing
>> with 75 shitty things.
>
>
> I agree that in theory they could have published ebuilds for Gentoo prefix
> and it would have 'worked everywhere' but I think that boat sailed about 10
> years ago.
>
> https://wiki.gentoo.org/wiki/Project:Perl/g-cpan is a project is in a
> similar space and basically reads perl CPAN metadata to generate stub
> ebuilds.
> Portage tracks these stub ebuilds (and so for example, it tracks what these
> cpan packages install and can remove them afterwards.)
>
> I think this is the most pragmatic approach I've seen used as its mostly an
> adapter (to cpan) that just generates ebuilds.
> Its plausible that with some careful eclass magic you might be able to make
> the installed packages compatible with pip, cargo, etc.
>
> I think its more of a struggle to make it compatible with things like
> virtualenv or pip --user though.
>

This might be a good way to relieve the amount of intervention
required when repackaging code for an actual package manager. The
information should be there. The other option is convincing people to
package for multiple systems at once, which diffuses the effort to the
point people tend to not mind.

1) Language package manager (usually used by Windows consumers).
2) .debs for Ubuntu/Debian.
3) .rpms for Fedora/CentOS.
4) Sometimes there's a Gentoo or Arch release.

If you could sell #4 as a way to generate 1-3 it would likely be
possible to reduce the proliferation of language specific package
managers over time. Prefix would likely play an important role.

Cheers,
 R0b0t1

Re: [gentoo-dev] rfc: handling the "uucp" group

[R0b0t1]

On Thu, Feb 8, 2018 at 2:32 PM, Ulrich Mueller <u...@gentoo.org> wrote:
>>>>>> On Thu, 8 Feb 2018, William Hubbs wrote:
>
>> First, baselayout has had the "dialout" group since 2015, so the
>> longterm fix imo is to possibly use that instead of the uucp group.
>> What would it take to make that happen, or are we stuck with the
>> uucp group forever?
>
> There was an old discussion on this in bug 108249 [1]. The decision
> back in 2005 was to use the "uucp" group (because apparently that was
> what both Debian and Fedora did at the time), but IIRC it was pretty
> much arbitrary.
>
> So I don't see a reason why we couldn't use "dialout" instead.
>

UUCP doesn't have any intrinsic relationship with modems, though it
probably finds (found) most use over modems. Was "dialout" or "tty"
changed to "uucp" for some reason?

If possible please use dialout, as very few modems are teletypes.

It makes the most sense to me to give a uucp user dialout or tty
permission, instead of adding myself to the uucp group, a name which
references programs most people won't have installed and won't know
about.

Cheers,
 R0b0t1

Re: [gentoo-portage-dev] Fix all misc. bash errors.

[R0b0t1]

On Wed, Feb 7, 2018 at 1:41 AM, Michał Górny <mgo...@gentoo.org> wrote:
> W dniu pon, 05.02.2018 o godzinie 20∶33 -0600, użytkownik R0b0t1
> napisał:
>> On Sun, Feb 4, 2018 at 10:45 PM, Zac Medico <zmed...@gentoo.org> wrote:
>> > On 02/04/2018 07:22 PM, R0b0t1 wrote:
>> > > This is everything that shellcheck reported as an error. They are not
>> > > as serious as the globbing issue, but it would be a good idea to
>> > > change them. They are generally "type" issues (e.g. ">" instead of
>> > > "-gt").
>> > >
>> > > Some changes are shellcheck annotations. Very interesting was:
>> > >
>> > > eval "$x=(\"\${$x[@]}\" ${QA_PREBUILT//\*/.*})"
>> > >
>> > > Which looks like a bad array expansion ("$x[@]").
>> >
>> > I don't see a shellcheck error for that, using shellcheck-0.4.7. Maybe a
>> > false positive with an older version?
>> >
>>
>> 0.4.6, I will see if I can check.
>>
>> > > diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
>> > > index b28e44f18..377b32d90 100644
>> > > --- a/bin/isolated-functions.sh
>> > > +++ b/bin/isolated-functions.sh
>> > > @@ -82,7 +82,7 @@ __dump_trace() {
>> > >  lineno=${BASH_LINENO[${n} - 1]}
>> > >  # Display function arguments
>> > >  args=
>> > > -if [[ -n "${BASH_ARGV[@]}" ]]; then
>> > > +if [[ -n "${BASH_ARGV[*]}" ]]; then
>> >
>> > I feel like the shellcheck authors might be willing to accept [[ -n
>> > ${BASH_ARGV[@]} ]] or [[ ${BASH_ARGV[@]} ]] as correct, since the
>> > "Problematic code" that they cite involves an incorrect comparison:
>> >
>> > https://github.com/koalaman/shellcheck/wiki/SC2199#problematic-code
>> >
>>
>> This example might be more illustrative:
>>
>> argc () {
>> echo $#
>> }
>>
>> argc "${BASH_ARGV[*]}"
>> argc "${BASH_ARGV[@]}"
>>
>>
>> Output (./test.sh a b):
>>
>> 1
>> 2
>>
>>
>> Which changes the semantics of the tests in which it is present. It is
>> hard to know what [[ is doing; if the same is attempted with [ it
>> would be an error for the same reason that globbing produces errors.
>> See:
>>
>> [  "${BASH_ARGV[*]}"  ]
>> [  "${BASH_ARGV[@]}"  ] # Fails; [: b: unary operator expected
>> [[ "${BASH_ARGV[*]}" ]]
>> [[ "${BASH_ARGV[@]}" ]]
>>
>>
>> It is possible [[ ignores the extra elements. I can't think of a
>> reason where this would make the results of the test different. At the
>> same time, it might give people the wrong impression of the operation
>> of [.
>>
>> In the sense that [ and [[ represent test(1), anything but the "[*]"
>> expansion is incorrect, as the error message indicates. That [[ treats
>> its arguments specially because it is a feature of the syntax just
>> makes the situation more confusing.
>>
>
> They don't. '[' works as a external command whose arguments are subject
> to word splitting. '[[' works as a builtin that does word splitting
> before expanding variables.
>

I'm aware of the differing implementations, but trying to claim [[ is
not modelled after [ is disingenuous. Needing to keep track of what
precisely each thing is doing and why adds to the difficulty of
maintaining the scripts. It'd be like trying to make use of all of the
features of C++.

Shellcheck reports an error because what was asked doesn't make sense
in context, even though it does happen to work.

Cheers,
 R0b0t1

Re: [gentoo-portage-dev] Fix all misc. bash errors.

[R0b0t1]

On Mon, Feb 5, 2018 at 8:33 PM, R0b0t1 <r03...@gmail.com> wrote:
> On Sun, Feb 4, 2018 at 10:45 PM, Zac Medico <zmed...@gentoo.org> wrote:
>> On 02/04/2018 07:22 PM, R0b0t1 wrote:
>>> This is everything that shellcheck reported as an error. They are not
>>> as serious as the globbing issue, but it would be a good idea to
>>> change them. They are generally "type" issues (e.g. ">" instead of
>>> "-gt").
>>>
>>> Some changes are shellcheck annotations. Very interesting was:
>>>
>>> eval "$x=(\"\${$x[@]}\" ${QA_PREBUILT//\*/.*})"
>>>
>>> Which looks like a bad array expansion ("$x[@]").
>>
>> I don't see a shellcheck error for that, using shellcheck-0.4.7. Maybe a
>> false positive with an older version?
>>
>
> 0.4.6, I will see if I can check.

Still in 0.4.7.

>
>>> diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
>>> index b28e44f18..377b32d90 100644
>>> --- a/bin/isolated-functions.sh
>>> +++ b/bin/isolated-functions.sh
>>> @@ -82,7 +82,7 @@ __dump_trace() {
>>>  lineno=${BASH_LINENO[${n} - 1]}
>>>  # Display function arguments
>>>  args=
>>> -if [[ -n "${BASH_ARGV[@]}" ]]; then
>>> +if [[ -n "${BASH_ARGV[*]}" ]]; then
>>
>> I feel like the shellcheck authors might be willing to accept [[ -n
>> ${BASH_ARGV[@]} ]] or [[ ${BASH_ARGV[@]} ]] as correct, since the
>> "Problematic code" that they cite involves an incorrect comparison:
>>
>> https://github.com/koalaman/shellcheck/wiki/SC2199#problematic-code
>>
>
> This example might be more illustrative:
>
> argc () {
> echo $#
> }
>
> argc "${BASH_ARGV[*]}"
> argc "${BASH_ARGV[@]}"
>
>
> Output (./test.sh a b):
>
> 1
> 2
>
>
> Which changes the semantics of the tests in which it is present. It is
> hard to know what [[ is doing; if the same is attempted with [ it
> would be an error for the same reason that globbing produces errors.
> See:
>
> [  "${BASH_ARGV[*]}"  ]
> [  "${BASH_ARGV[@]}"  ] # Fails; [: b: unary operator expected
> [[ "${BASH_ARGV[*]}" ]]
> [[ "${BASH_ARGV[@]}" ]]
>
>
> It is possible [[ ignores the extra elements. I can't think of a
> reason where this would make the results of the test different. At the
> same time, it might give people the wrong impression of the operation
> of [.
>
> In the sense that [ and [[ represent test(1), anything but the "[*]"
> expansion is incorrect, as the error message indicates. That [[ treats
> its arguments specially because it is a feature of the syntax just
> makes the situation more confusing.
>
> Cheers,
>  R0b0t1

Re: [gentoo-portage-dev] Fix all misc. bash errors.

[R0b0t1]

On Sun, Feb 4, 2018 at 10:45 PM, Zac Medico <zmed...@gentoo.org> wrote:
> On 02/04/2018 07:22 PM, R0b0t1 wrote:
>> This is everything that shellcheck reported as an error. They are not
>> as serious as the globbing issue, but it would be a good idea to
>> change them. They are generally "type" issues (e.g. ">" instead of
>> "-gt").
>>
>> Some changes are shellcheck annotations. Very interesting was:
>>
>> eval "$x=(\"\${$x[@]}\" ${QA_PREBUILT//\*/.*})"
>>
>> Which looks like a bad array expansion ("$x[@]").
>
> I don't see a shellcheck error for that, using shellcheck-0.4.7. Maybe a
> false positive with an older version?
>

0.4.6, I will see if I can check.

>> diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
>> index b28e44f18..377b32d90 100644
>> --- a/bin/isolated-functions.sh
>> +++ b/bin/isolated-functions.sh
>> @@ -82,7 +82,7 @@ __dump_trace() {
>>  lineno=${BASH_LINENO[${n} - 1]}
>>  # Display function arguments
>>  args=
>> -if [[ -n "${BASH_ARGV[@]}" ]]; then
>> +if [[ -n "${BASH_ARGV[*]}" ]]; then
>
> I feel like the shellcheck authors might be willing to accept [[ -n
> ${BASH_ARGV[@]} ]] or [[ ${BASH_ARGV[@]} ]] as correct, since the
> "Problematic code" that they cite involves an incorrect comparison:
>
> https://github.com/koalaman/shellcheck/wiki/SC2199#problematic-code
>

This example might be more illustrative:

argc () {
echo $#
}

argc "${BASH_ARGV[*]}"
argc "${BASH_ARGV[@]}"


Output (./test.sh a b):

1
2


Which changes the semantics of the tests in which it is present. It is
hard to know what [[ is doing; if the same is attempted with [ it
would be an error for the same reason that globbing produces errors.
See:

[  "${BASH_ARGV[*]}"  ]
[  "${BASH_ARGV[@]}"  ] # Fails; [: b: unary operator expected
[[ "${BASH_ARGV[*]}" ]]
[[ "${BASH_ARGV[@]}" ]]


It is possible [[ ignores the extra elements. I can't think of a
reason where this would make the results of the test different. At the
same time, it might give people the wrong impression of the operation
of [.

In the sense that [ and [[ represent test(1), anything but the "[*]"
expansion is incorrect, as the error message indicates. That [[ treats
its arguments specially because it is a feature of the syntax just
makes the situation more confusing.

Cheers,
 R0b0t1

[gentoo-portage-dev] Fix all misc. bash errors.

[R0b0t1]

This is everything that shellcheck reported as an error. They are not
as serious as the globbing issue, but it would be a good idea to
change them. They are generally "type" issues (e.g. ">" instead of
"-gt").

Some changes are shellcheck annotations. Very interesting was:

eval "$x=(\"\${$x[@]}\" ${QA_PREBUILT//\*/.*})"

Which looks like a bad array expansion ("$x[@]").

Cheers,
 R0b0t1


---
 bin/ebuild-helpers/newins | 2 +-
 bin/ebuild.sh | 2 +-
 bin/etc-update| 6 +++---
 bin/isolated-functions.sh | 6 +++---
 bin/phase-functions.sh| 1 +
 5 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/bin/ebuild-helpers/newins b/bin/ebuild-helpers/newins
index 8032a8f2f..30e54b7e5 100755
--- a/bin/ebuild-helpers/newins
+++ b/bin/ebuild-helpers/newins
@@ -12,7 +12,7 @@ if [[ -z ${T} ]] || [[ -z ${2} ]] ; then
 fi

 (($#>2)) && \
-eqawarn "QA Notice: ${helper} called with more than 2 arguments: ${@:3}"
+eqawarn "QA Notice: ${helper} called with more than 2 arguments: ${*:3}"

 stdin=
 if ___eapi_newins_supports_reading_from_standard_input && [[ $1 == "-" ]]; then
diff --git a/bin/ebuild.sh b/bin/ebuild.sh
index 94a44d534..4a80fdd06 100755
--- a/bin/ebuild.sh
+++ b/bin/ebuild.sh
@@ -232,7 +232,7 @@ debug-print-section() {
 declare -ix ECLASS_DEPTH=0
 inherit() {
 ECLASS_DEPTH=$(($ECLASS_DEPTH + 1))
-if [[ ${ECLASS_DEPTH} > 1 ]]; then
+if [[ ${ECLASS_DEPTH} -gt 1 ]]; then
 debug-print "*** Multiple Inheritence (Level: ${ECLASS_DEPTH})"
 fi

diff --git a/bin/etc-update b/bin/etc-update
index ea69f1478..cbca8217e 100755
--- a/bin/etc-update
+++ b/bin/etc-update
@@ -767,7 +767,7 @@ portage_vars=(
 )

 if type -P portageq > /dev/null; then
-eval $(${PORTAGE_PYTHON:+"${PORTAGE_PYTHON}"} "$(type -P
portageq)" envvar -v ${portage_vars[@]})
+eval $(${PORTAGE_PYTHON:+"${PORTAGE_PYTHON}"} "$(type -P
portageq)" envvar -v "${portage_vars[@]}")
 else
 [[ $OS_FAMILY == 'gentoo' ]] && die "missing portageq"
 fi
@@ -801,7 +801,7 @@ cfg_vars=(
 mode
 )
 # default them all to ""
-eval ${cfg_vars[@]/%/=}
+eval "${cfg_vars[@]/%/=}"
 # then extract them all from the conf in one shot
 # (ugly var at end is due to printf appending a '|' to last item)
 get_config "($(printf '%s|' "${cfg_vars[@]}")NOVARFOROLDMEN)"
@@ -846,7 +846,7 @@ if ${NONINTERACTIVE_MV} ; then
 fi

 if ${VERBOSE} ; then
-for v in ${portage_vars[@]} ${cfg_vars[@]} TMP SCAN_PATHS ; do
+for v in "${portage_vars[@]} ${cfg_vars[@]} TMP SCAN_PATHS" ; do
 echo "${v}=${!v}"
 done
 fi
diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
index b28e44f18..377b32d90 100644
--- a/bin/isolated-functions.sh
+++ b/bin/isolated-functions.sh
@@ -82,7 +82,7 @@ __dump_trace() {
 lineno=${BASH_LINENO[${n} - 1]}
 # Display function arguments
 args=
-if [[ -n "${BASH_ARGV[@]}" ]]; then
+if [[ -n "${BASH_ARGV[*]}" ]]; then
 for (( j = 1 ; j <= ${BASH_ARGC[${n} - 1]} ; ++j )); do
 newarg=${BASH_ARGV[$(( p - j - 1 ))]}
 args="${args:+${args} }'${newarg}'"
@@ -550,13 +550,13 @@ __eqatag() {

 (
 echo "- tag: ${tag}"
-if [[ ${data[@]} ]]; then
+if [[ ${data[*]} ]]; then
 echo "  data:"
 for i in "${data[@]}"; do
 echo "${i%%=*}: \"$(__eqaquote "${i#*=}")\""
 done
 fi
-if [[ ${filenames[@]} ]]; then
+if [[ ${filenames[*]} ]]; then
 echo "  files:"
 for i in "${filenames[@]}"; do
 echo "- \"$(__eqaquote "${i}")\""
diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index 10d54ca74..469715f7f 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -541,6 +541,7 @@ __dyn_install() {
 # fnmatch patterns to regular expressions
 for x in QA_DT_NEEDED QA_FLAGS_IGNORED QA_PRESTRIPPED QA_SONAME ; do
 if [[ $(declare -p $x 2>/dev/null) = declare\ -a* ]] ; then
+# shellcheck disable=1087
 eval "$x=(\"\${$x[@]}\" ${QA_PREBUILT//\*/.*})"
 else
 eval "$x+=\" ${QA_PREBUILT//\*/.*}\""
-- 
2.14.1
From 2111073648d3e33f49ceaaca971f8cff9e5e6b0e Mon Sep 17 00:00:00 2001
From: Sid Spry <r03...@gmail.com>
Date: Sun, 4 Feb 2018 19:11:32 -0800
Subject: [PATCH] Fix all misc. bash errors.

---
 bin/ebuild-helpers/newins | 2 +-
 bin/ebuild.sh | 2 +-
 bin/etc-update| 6 +++---
 bin/isolated-functions.

[gentoo-portage-dev] Fix Misc. Bash Errors in phase-helpers.sh.

[R0b0t1]

On line 699, I suspect the test may erroneously expand into:

if [ -f ./Makefile ./makefile -o -f ./GNUmakefile ] ; then

If both files are present. The test was changed to include both names
explicitly. It could also be rewritten with [[, but it seems like it
would still either need a loop or multiple tests.


The other changes are almost stylistic. I made a PR
(https://github.com/gentoo/portage/pull/251) before I remembered that
that repo was a mirror.

Cheers,
 R0b0t1
From f93e8e1b1e8df555fe90d2efdb68afa314d0719e Mon Sep 17 00:00:00 2001
From: Sid Spry <r03...@gmail.com>
Date: Sat, 3 Feb 2018 23:44:56 -0800
Subject: [PATCH] Fix misc. bash errors.

---
 bin/phase-helpers.sh | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index 9b1f6adbe..282eb5665 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -696,7 +696,7 @@ einstall() {
 		unset EI_DESTLIBDIR
 	fi
 
-	if [ -f ./[mM]akefile -o -f ./GNUmakefile ] ; then
+	if [ -f ./Makefile -o -f ./makefile -o -f ./GNUmakefile ] ; then
 		if [ "${PORTAGE_DEBUG}" == "1" ]; then
 			${MAKE:-make} -n prefix="${ED}usr" \
 datadir="${ED}usr/share" \
@@ -810,7 +810,7 @@ __eapi4_src_install() {
 
 __eapi6_src_prepare() {
 	if [[ $(declare -p PATCHES 2>/dev/null) == "declare -a"* ]]; then
-		[[ -n ${PATCHES[@]} ]] && eapply "${PATCHES[@]}"
+		[[ -n ${PATCHES[*]} ]] && eapply "${PATCHES[@]}"
 	elif [[ -n ${PATCHES} ]]; then
 		eapply ${PATCHES}
 	fi
@@ -965,7 +965,7 @@ if ___eapi_has_einstalldocs; then
 	[[ -f ${d} && -s ${d} ]] && docinto / && dodoc "${d}"
 done
 			elif [[ $(declare -p DOCS) == "declare -a"* ]] ; then
-[[ ${DOCS[@]} ]] && docinto / && dodoc -r "${DOCS[@]}"
+[[ ${DOCS[*]} ]] && docinto / && dodoc -r "${DOCS[@]}"
 			else
 [[ ${DOCS} ]] && docinto / && dodoc -r ${DOCS}
 			fi
@@ -973,7 +973,7 @@ if ___eapi_has_einstalldocs; then
 
 		(
 			if [[ $(declare -p HTML_DOCS 2>/dev/null) == "declare -a"* ]] ; then
-[[ ${HTML_DOCS[@]} ]] && \
+[[ ${HTML_DOCS[*]} ]] && \
 	docinto html && dodoc -r "${HTML_DOCS[@]}"
 			else
 [[ ${HTML_DOCS} ]] && \
@@ -1014,6 +1014,7 @@ if ___eapi_has_eapply; then
 		local i found_doublehyphen
 		# first, try to split on --
 		for (( i = 1; i <= ${#@}; ++i )); do
+			# shellcheck disable=SC2199
 			if [[ ${@:i:1} == -- ]]; then
 patch_options=( "${@:1:i-1}" )
 files=( "${@:i+1}" )
@@ -1025,6 +1026,7 @@ if ___eapi_has_eapply; then
 		# then, try to split on first non-option
 		if [[ -z ${found_doublehyphen} ]]; then
 			for (( i = 1; i <= ${#@}; ++i )); do
+# shellcheck disable=SC2199
 if [[ ${@:i:1} != -* ]]; then
 	patch_options=( "${@:1:i-1}" )
 	files=( "${@:i}" )
@@ -1040,7 +1042,7 @@ if ___eapi_has_eapply; then
 			done
 		fi
 
-		if [[ -z ${files[@]} ]]; then
+		if [[ -z ${files[*]} ]]; then
 			die "eapply: no files specified"
 		fi
 
@@ -1062,7 +1064,7 @@ if ___eapi_has_eapply; then
 
 local files=()
 _eapply_get_files "${f}"
-[[ -z ${files[@]} ]] && die "No *.{patch,diff} files in directory ${f}"
+[[ -z ${files[*]} ]] && die "No *.{patch,diff} files in directory ${f}"
 
 einfo "Applying patches from ${f} ..."
 local f2
-- 
2.14.1

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure (draft v2)

[R0b0t1]

nd speed does not justify
> the resulting code duplication.
>
> It has also been pointed out that e.g. the BLAKE2 hash family provides
> the ability of creating arbitrary length hashes instead of truncating
> the standard-length hash.  However, not all implementations of BLAKE2
> support that and relying on it could reduce portability for no apparent
> gain.
>
>
> Backwards Compatibility
> ===
> Mirror compatibility
> 
> The mirrored files are propagated to other mirrors as opaque directory
> structure.  Therefore, there are no backwards compatibility concerns
> on the mirroring side.
>
> Backwards compatibility with existing clients is detailed
> in `migrating mirrors to the hashed structure`_ section.  Backwards
> compatibility with the old clients will be provided by preserving
> the flat structure during the transitional period.
>
> The new clients will fetch the ``layout.conf`` file to avoid backwards
> compatibility concerns in the future.  In case of hitting an old mirror,
> the package manager will default to the ``flat`` structure.
>
>
> Package manager storage compatibility
> -
> The exact means of preserving backwards compatibility in package manager
> storage are left to the package manager authors.  However, it is
> recommended that package managers continue to support the flat layout
> even if it is no longer the default.  The package manager may either
> continue to read files from this location or automatically move them
> to an appropriate subdirectory.
>
>
> Reference Implementation
> 
> TODO.
>
>
> References
> ==
> .. [#DESKTOP_FORMAT] Desktop Entry Specification: Basic format of the file
>(
https://standards.freedesktop.org/desktop-entry-spec/latest/ar01s03.html)
>
> .. [#GLEP74] GLEP 74: Full-tree verification using Manifest files:
>Checksum algorithms (informational)
>(
https://www.gentoo.org/glep/glep-0074.html#checksum-algorithms-informational
)
>
> .. [#GLEP59] GLEP 59: Manifest2 hash policies and security implications
>(https://www.gentoo.org/glep/glep-0059.html)
>
> .. [#BUG534528] Bug 534528 - distfiles should be sorted into
subdirectories
>of DISTDIR
>(https://bugs.gentoo.org/534528)
>
> .. [#ML1] [gentoo-dev] [pre-GLEP] Split distfile mirror directory
structure
>(
https://archives.gentoo.org/gentoo-dev/message/cfc4f8595df2edf9a25ba9ecae2463ba
)
>
> .. [#ADAPTIVE_FILENAME] Andrew Barchuk's reply on 'using character ranges
>for each directory computed in a way to have the files distributed
evenly'
>(
https://archives.gentoo.org/gentoo-dev/message/611bdaa76be049c1d650e8995748e7b8
)
>
> .. [#PKGNAME] Jason Zamal's reply including 'using the same dir layout
>as the packages themselves)
>(
https://archives.gentoo.org/gentoo-dev/message/f26ed870c3a6d4ecf69a821723642975
)
>
>
> Copyright
> =
> This work is licensed under the Creative Commons Attribution-ShareAlike
3.0
> Unported License. To view a copy of this license, visit
> http://creativecommons.org/licenses/by-sa/3.0/.
>
> --
> Best regards,
> Michał Górny
>

It's going to be hash based? Why? I tried to follow the conversation but
there's now close to 5 of these posts in the mailing list with different
conversations in each.

Using filename prefixes is boring and not uniform, but I feel I should
point out that most distfile hosts are still doing fine. Microoptimizing
this seems like wasted effort.

Cheers,
R0b0t1

Re: [gentoo-dev] [News item review] Portage rsync tree verification (v2)

[R0b0t1]

On Sat, Jan 27, 2018 at 8:27 AM, Michał Górny <mgo...@gentoo.org> wrote:
> W dniu czw, 25.01.2018 o godzinie 15∶55 -0600, użytkownik R0b0t1
> napisał:
>> On Thu, Jan 25, 2018 at 3:45 PM, Michał Górny <mgo...@gentoo.org> wrote:
>> > W dniu czw, 25.01.2018 o godzinie 21∶37 +, użytkownik Robin H.
>> > Johnson napisał:
>> > > On Thu, Jan 25, 2018 at 01:35:17PM +0100, Michał Górny wrote:
>> > > > Title: Portage rsync tree verification
>> > > > Author: Michał Górny <mgo...@gentoo.org>
>> > > > Posted: 2018-01-xx
>> > > > Revision: 1
>> > > > News-Item-Format: 2.0
>> > > > Display-If-Installed: > > >
>> > > Drop Display-If-Installed, they need to always see this until they know
>> > > it was bootstrapped.
>> >
>> > Well, the idea was that if someone starts with stage that has >2.3.21,
>> > then he has bootstrapped via verifying the stage signature.
>> >
>> > > > Starting with sys-apps/portage-2.3.22, Portage enables cryptographic
>> > > > verification of the Gentoo rsync repository distributed over rsync
>> > > > by default.
>> > >
>> > > Seems very wordy, suggested cleanup:
>> > > > > Starting with sys-apps/portage-2.3.22, Portage will verify the Gentoo
>> > > > > repository after rsync by default.
>> > > >
>> > > > This aims to prevent malicious third parties from altering
>> > > > the contents of the ebuild repository received by our users.
>> > > >
>> > > > This does not affect users syncing using git and other methods.
>> > > > Appropriate verification mechanisms for them will be provided
>> > > > in the future.
>> > >
>> > > Note that emerge-webrsync has verification via FEATURES=webrsync-gpg?
>> >
>> > I'm sorry, I have never used that. Does it cover full key maintenance
>> > or rely on user to do the gpg work?
>> >
>>
>> It used to be necessary to set up a GnuPG home for portage and pull
>> the keys in, but now users can emerge app-crypt/gentoo-keys and set
>> PORTAGE_GPG_DIR="/var/lib/gentoo/gkeys/keyrings/gentoo/release".
>>
>
> In that case I'd rather not announce it until it is integrated properly.
>

What is "properly?" It's referenced in the handbook.

Cheers,
 R0b0t1

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

[R0b0t1]

On Fri, Jan 26, 2018 at 7:48 PM, Michael Orlitzky <m...@gentoo.org> wrote:
> 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,

I've had to interact with the distfile server by hand, and would
appreciate it if the files can be maintained in some way that finding
them is obvious without tools.

Every once and a while I navigate to the distfile root and need to
forcefully exit Firefox.

Cheers,
 R0b0t1

Re: [gentoo-dev] [News item review] Portage rsync tree verification (v2)

[R0b0t1]

On Thu, Jan 25, 2018 at 3:45 PM, Michał Górny  wrote:
> W dniu czw, 25.01.2018 o godzinie 21∶37 +, użytkownik Robin H.
> Johnson napisał:
>> On Thu, Jan 25, 2018 at 01:35:17PM +0100, Michał Górny wrote:
>> > Title: Portage rsync tree verification
>> > Author: Michał Górny 
>> > Posted: 2018-01-xx
>> > Revision: 1
>> > News-Item-Format: 2.0
>> > Display-If-Installed: >
>> Drop Display-If-Installed, they need to always see this until they know
>> it was bootstrapped.
>
> Well, the idea was that if someone starts with stage that has >2.3.21,
> then he has bootstrapped via verifying the stage signature.
>
>> > Starting with sys-apps/portage-2.3.22, Portage enables cryptographic
>> > verification of the Gentoo rsync repository distributed over rsync
>> > by default.
>>
>> Seems very wordy, suggested cleanup:
>> > > Starting with sys-apps/portage-2.3.22, Portage will verify the Gentoo
>> > > repository after rsync by default.
>> > This aims to prevent malicious third parties from altering
>> > the contents of the ebuild repository received by our users.
>> >
>> > This does not affect users syncing using git and other methods.
>> > Appropriate verification mechanisms for them will be provided
>> > in the future.
>>
>> Note that emerge-webrsync has verification via FEATURES=webrsync-gpg?
>
> I'm sorry, I have never used that. Does it cover full key maintenance
> or rely on user to do the gpg work?
>

It used to be necessary to set up a GnuPG home for portage and pull
the keys in, but now users can emerge app-crypt/gentoo-keys and set
PORTAGE_GPG_DIR="/var/lib/gentoo/gkeys/keyrings/gentoo/release".

>>
>> Rewrite:
>> > > The new verification is intended for users who syncing via rsync.
>> > > Users who sync by emerge-webrsync should see [linkref].
>> > > Verification mechanisms for other methods of sync will be provided in
>> > > future.
>>
>>
>> > On Gentoo installations created using installation media that included
>> > portage-2.3.22, the keys will already be covered by the installation
>> > media signatures. On existing installations, you need to manually
>> > compare the primary key fingerprint (reported by gemato on every sync)
>> > against the official Gentoo keys [1]. An example gemato output is:
>> >   INFO:root:Valid OpenPGP signature found:
>> >   INFO:root:- primary key: 1234567890ABCDEF1234567890ABCDEF12345678
>> >   INFO:root:- subkey: FEDCBA0987654321FEDCBA0987654321FEDCBA09
>>
>> Either we should use real key here, or specifically note this is a fake
>> key output on purpose.
>
> Well, I've assumed most people would be able to figure out that it would
> be quite a coincidence to see such a key id. I wanted to avoid putting
> the real id so that people would actually check that HTTPS site instead
> of relying on the security of news item delivery.
>
> Will send an updated version tomorrow.
>
> --
> Best regards,
> Michał Górny
>
>

Re: [gentoo-dev] Managing updates on many identical Gentoo systems

[R0b0t1]

Hello,

There's been a lot of relevant points but I'm not sure how to stitch
together all of the posts so I will reply to the OP.

On Thu, Jan 18, 2018 at 5:46 AM, Anthony G. Basile <bluen...@gentoo.org> wrote:
> Hi everyone,
>
> I'm trying to design an update system for many identical Gentoo systems.
>  Using a binhost is obvious, but there are still problems with this
> approach.
>

How are the hosts administered now? Which problems are you referring to?

It's my understanding that Debian/Fedora/etc. based datacenters have
all of their machines crunching dependencies individually. There may
be local mirrors, but it looks like people have not seen fit to
centralize dependency information.

> Unless there's some magic I don't know about (and this is why I'm
> sending this email) each machine still needs to have the portage tree
> installed locally (1.5 GB) or somehow mounted by a network filesystem
> (which is not practical if the machines are not on a local network).
> Furthermore, each machine would have to run emerge locally to do the
> calculation of what packages need updating.
>
> This procedure is redundant because each machine is housing the same
> data and doing the same dependence-tree calculation.  It should be
> possible to do this calculation on a centralized binhost and simply
> communicate the update information to the remote machines.  They would
> then only have to download the .tbz2's and install them, keeping a tidy
> /var/db/pkg.  Thus they avoid having to house the portage tree and
> burning cpu cycles that just calculate redundant information.
>

Is it necessary to retain information that would be used to administer
the machines on the machines? You could treat your servers as embedded
appliances. The typical method used in that case is to push an entire
root to them at once. For safety's sake a separate system partition
can receive the system image; system data is kept elsewhere.

This would require some small customization by way of update code to
unpack the new system and modify bootloader entries. All configuration
of the system apart from that would have to be handled upstream when
the release was prepared, or stored on the data partition.

This is done for lots of devices (phones?) and works well even when
bandwidth is fairly limited.

Cheers,
 R0b0t1

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

[R0b0t1]

Erm.

On Mon, Jan 15, 2018 at 11:23 PM, R0b0t1 <r03...@gmail.com> wrote:
> Hello, and my apologies for missing your message.
>
> On Fri, Jan 12, 2018 at 1:59 AM, Benda Xu <hero...@gentoo.org> wrote:
>> Hi R0b0t1,
>>
>> R0b0t1 <r03...@gmail.com> writes:
>>
>>> I don't want to just comment on naming, but:
>>>
>>> It might be more natural to go the other way. Split profiles off based
>>> on version when breakage occurs, and otherwise do not reference a
>>> specific version.
>>>
>>> Then, the name indicates the most recent kernel supported by the
>>> profile. So remove the plus and (I think) shift all of the names
>>> "forward."
>>
>>> So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name.
>>>
>>> This seems more natural but does change the semantics of the
>>> name. Would that be a problem?
>>
>> Let's call this 'breakage-indicating scheme'.  I have considered it, but
>> finally I chose the original proposal:
>>
>> Consider one running kernel 3.8 with the newest profile, called
>> 'prefix/kernel-3.2+' in the original proposal and 'prefix' in the
>> breakage-indicating scheme.  When glibc decides to break <kernel-3.10,
>> in the breakage-indicating scheme, you will have to change the profile
>> to 'prefix/kernel-3.10-older'.
>>
>> Consider otherwise one running kernel 4.9, you will not not need to
>> switch profile 'prefix/kernel-3.2+' in the original proposal, although
>> 'prefix/kernel-3.10+' will be a better profile.
>>
>> In either case, the original proposal does not force a profile switch
>> when glibc breaks old kernel.  Therefore I prefer it.
>>
>
> This makes sense. While I agree that minimizing breakage is a good
> idea, I am not sure it should be favored over all alternatives.
>
>>> Is it expected people would want to use the profiles with
>>> compatibility features on newer kernels?
>>
>> One use case is that: I want to bootstrap on my new and powerful server
>> a 'prefix/kernel-2.6.16+' on kernel 4.9, and then transfer the resulting
>> Prefix to an aging RHEL 5.  Bootstrapping a 'prefix/kernel-2.6.32-older'
>> on kernel 4.9 feels awkward.
>>
>> But it is not about use cases, it is about logical consistancy: if we
>> are not forbidden to run an old glibc on a new kernel, we should not
>> indicate so in profile names.
>>
>
> I have seen similar choices made before, but this is the first time I
> have seen a good case for the choice you selected. E.g.:
>

(Lines up in a monospaced font.)

>>> This setup would prevent having to verify that old code works on new
>>> systems, which is implied to be supported.by the + naming (again, not
>>> sure if it matters).
>>
>> It is always supported to run an old glibc version on a new kernel, the
>> linux kernel is ABI-backwords compatible.  There is no need to verify
>> that.  Besides, by always using the most recent
>> sys-kernel/linux-headers, we are guaranteed with the newest kernel API.
>>
>
> It might be for the foreseeable future, but that might change. The
> comment was more about the features exposed to glibc and the programs
> installed via portage. It seems to me as the kernel and userland
> progress, the older profile. Perhaps I am not explaining it well, my
> apologies.
>

The older profile would require constant adjustment.

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

[R0b0t1]

Hello, and my apologies for missing your message.

On Fri, Jan 12, 2018 at 1:59 AM, Benda Xu <hero...@gentoo.org> wrote:
> Hi R0b0t1,
>
> R0b0t1 <r03...@gmail.com> writes:
>
>> I don't want to just comment on naming, but:
>>
>> It might be more natural to go the other way. Split profiles off based
>> on version when breakage occurs, and otherwise do not reference a
>> specific version.
>>
>> Then, the name indicates the most recent kernel supported by the
>> profile. So remove the plus and (I think) shift all of the names
>> "forward."
>
>> So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name.
>>
>> This seems more natural but does change the semantics of the
>> name. Would that be a problem?
>
> Let's call this 'breakage-indicating scheme'.  I have considered it, but
> finally I chose the original proposal:
>
> Consider one running kernel 3.8 with the newest profile, called
> 'prefix/kernel-3.2+' in the original proposal and 'prefix' in the
> breakage-indicating scheme.  When glibc decides to break <kernel-3.10,
> in the breakage-indicating scheme, you will have to change the profile
> to 'prefix/kernel-3.10-older'.
>
> Consider otherwise one running kernel 4.9, you will not not need to
> switch profile 'prefix/kernel-3.2+' in the original proposal, although
> 'prefix/kernel-3.10+' will be a better profile.
>
> In either case, the original proposal does not force a profile switch
> when glibc breaks old kernel.  Therefore I prefer it.
>

This makes sense. While I agree that minimizing breakage is a good
idea, I am not sure it should be favored over all alternatives.

>> Is it expected people would want to use the profiles with
>> compatibility features on newer kernels?
>
> One use case is that: I want to bootstrap on my new and powerful server
> a 'prefix/kernel-2.6.16+' on kernel 4.9, and then transfer the resulting
> Prefix to an aging RHEL 5.  Bootstrapping a 'prefix/kernel-2.6.32-older'
> on kernel 4.9 feels awkward.
>
> But it is not about use cases, it is about logical consistancy: if we
> are not forbidden to run an old glibc on a new kernel, we should not
> indicate so in profile names.
>

I have seen similar choices made before, but this is the first time I
have seen a good case for the choice you selected. E.g.:

(Current.)
*>
   *=>
  *==>
 *===>

vs.

(Usually seen.)
*==*
   *==*
  *==*
 *===>

vs.

(What it would actually mean for prefix.)
*==*->
   *==*-->
  *==*--->
 *===>

>> This setup would prevent having to verify that old code works on new
>> systems, which is implied to be supported.by the + naming (again, not
>> sure if it matters).
>
> It is always supported to run an old glibc version on a new kernel, the
> linux kernel is ABI-backwords compatible.  There is no need to verify
> that.  Besides, by always using the most recent
> sys-kernel/linux-headers, we are guaranteed with the newest kernel API.
>

It might be for the foreseeable future, but that might change. The
comment was more about the features exposed to glibc and the programs
installed via portage. It seems to me as the kernel and userland
progress, the older profile. Perhaps I am not explaining it well, my
apologies.

Cheers,
 R0b0t1

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

[R0b0t1]

On Wed, Jan 10, 2018 at 3:53 AM, Michał Górny <mgo...@gentoo.org> wrote:
> I guess you should have voiced your opinion back when discussion was
> taking place instead of being hostile *now* because the Council listened
> to what the developers requested.
>
> And if you are curious, then I've been asked by multiple developers
> (and a few users) requesting the restriction, and I haven't been
> contacted by a single one who asked otherwise.
>

My initial concern was related to what you are seeing now. Mailing
list participation is very relaxed. What is likely to happen is some
day a user will have cause to send a message and won't be able to,
because they don't know what is going on or why the list does not work
like most lists they interact with.

I am not sure it is wise to speak for those that are not present,
because whether someone responds or not does not tell you anything
about their opinion.

Respectfully,
 R0b0t1

[gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

[R0b0t1]

On Wednesday, January 10, 2018, Benda Xu <hero...@gentoo.org> wrote:
> Hi MJ,
>
> "M. J. Everitt" <m.j.ever...@iee.org> writes:
>
>> Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the
>> different between 2.6.16+ and 2.6.32+ .. should this potentially be
>> 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me,
>> and more confusing to others
>
> 2.6.16+ means that it can be used in any cases when the kernel is newer
> than 2.6.16.  For example, you can use it on linux-4.14, just with
> unnecessary backward compatibility code.
>
> Besides, with the newest profile, kernel-3.2+, the ending kernel version
> is not known.  We will have to rename it when glibc jumps if the profile
> is named with a version range.
>

I don't want to just comment on naming, but:

It might be more natural to go the other way. Split profiles off based on
version when breakage occurs, and otherwise do not reference a specific
version.

Then, the name indicates the most recent kernel supported by the profile.
So remove the plus and (I think) shift all of the names "forward."

So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name.

This seems more natural but does change the semantics of the name. Would
that be a problem? Is it expected people would want to use the profiles
with compatibility features on newer kernels?

This setup would prevent having to verify that old code works on new
systems, which is implied to be supported.by the + naming (again, not sure
if it matters).

Cheers,
R0b0t1

Re: OT: Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[R0b0t1]

On Wed, Dec 27, 2017 at 4:16 PM, Nils Freydank <holgers...@posteo.de> wrote:
> Am Mittwoch, 27. Dezember 2017, 22:33:03 CET schrieb R0b0t1:
>> On Wed, Dec 27, 2017 at 10:32 AM, William Hubbs <willi...@gentoo.org> wrote:
>> > As he said, he contactedd the maintainers in ample time, so I would say
>> > that since they didn't respond he went ahead in good faith. I'll get the
>> > link later, but as I recall, the dev manual recommends a 2-4 week wait
>> > for maintainers not responding then we can assume that what we are doing
>> > is ok.
>>
>> This assumes there is some pressing need for the change to take place,
>> which I am not sure there is. I can understand wanting to make the
>> change for consistency's sake, but the feature is important enough
>> that I think a suitable replacement should explicitly be found before
>> continuing. E.g. affirmative feedback from all affected packages.
>
> Often a fix timeline is the only way to achieve any responses - or at least
> get stuff done, even if the matter itself is not urgent at all. In this
> specific case the points Michael had were quite clear, and the timespan of
> two month was long enough to react somehow (at least in the context of typical
> periods in Gentoo, e.g. last rite/removal period of 30 days).
>

Yes, but as per past comments it seems some people think the action
taken was slightly inappropriate. It feels like you didn't read what I
said: in some cases, a fix timeline may not be appropriate. I don't
know when that is.

> On topic: There are some users including myself that find cracklib mostly
> annoying. I use strong passwords (or ssh keys only) where I can, and cracklib
> annoys me with the request to set "secure passwords" for a container
> playground, where I want root:test as login credentials.
> Beside that the point that profiles in general should contain as least USE as
> possible (see the bug report for that).
>

I must be confused, because this is the only part of your message that
is offtopic.

>> Enforcement of rules or Gentoo development guidelines does not happen
>> consistently, and the times when rules are enforced "for consistency's
>> sake" seem completely arbitrary. There seems to be no extant problems
>> caused by the flag as set, so why focus on this specifically?
>
> To me these times look as they're based upon agreement between the involved
> parties, and in itself consistently, e.g. at least 30 days masking before
> removal out of the tree, or in this case at least two to four weeks to let
> others respond.
>

But why male models^H^H^H^H^H^H^H^H^H^H^Hfocus on this issue in
particular? If I understand the situation, nothing is actually
*broken.* That is why I was questioning consistency.

>> There is a lot of discussion of not burdening developers with
>> pointless talk or changes. If that is a goal, then why is this posting
>> receiving so many replies?
>
> With all due respect, your posting didn't bring any new relevant aspects into
> this thread on this mailing list with the explicit focus and topic of Gentoo
> development, and might be exactly part of the "pointless talk" you mention.
>
> My one isn't better; I just want to point that out to you, because you tend to
> write messages with this kind of meta questions about the cause of things.
>
> If you want to discuss this, I'd prefer another place than this list.
>

As someone watching from the outside I see this type of discussion
crop up from time to time. All I am suggesting is thinking about
actions before they are acted out. This isn't to say what was
undertaken was not thought out - but the patterns of behavior I see
that that decision exists within are what I am suggesting needs more
careful consideration.

If you can not see the utility in thinking about thinking, I am not
sure we would have much to talk about.

Respectfully,
 R0b0t1

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[R0b0t1]

On Wed, Dec 27, 2017 at 10:32 AM, William Hubbs <willi...@gentoo.org> wrote:
> As he said, he contactedd the maintainers in ample time, so I would say
> that since they didn't respond he went ahead in good faith. I'll get the
> link later, but as I recall, the dev manual recommends a 2-4 week wait
> for maintainers not responding then we can assume that what we are doing
> is ok.

This assumes there is some pressing need for the change to take place,
which I am not sure there is. I can understand wanting to make the
change for consistency's sake, but the feature is important enough
that I think a suitable replacement should explicitly be found before
continuing. E.g. affirmative feedback from all affected packages.

Enforcement of rules or Gentoo development guidelines does not happen
consistently, and the times when rules are enforced "for consistency's
sake" seem completely arbitrary. There seems to be no extant problems
caused by the flag as set, so why focus on this specifically?

There is a lot of discussion of not burdening developers with
pointless talk or changes. If that is a goal, then why is this posting
receiving so many replies?

Respectfully,
 R0b0t1

Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

[R0b0t1]

On Sat, Dec 16, 2017 at 9:42 AM, Aaron W. Swenson <titanof...@gentoo.org> wrote:
> According to Merriam-Webster:
>
> self-evident
>  adjective | self-ev·i·dent | ˌself-ˈe-və-dənt , -ˌdent
>  evident without proof or reasoning
>

The version I used is taken from http://dd.pangyre.org/s/self-evident.html.

> You have been a part of the conversations that devolved into the
> non-technical, and even started your own decidedly non-technical
> discussion on this list[1] where you’ve seen that rules for moderation,
> or at least defining the expectations of moderators and participants,
> would have been beneficial.
>

Yes, it was non-technical, but it was related to Gentoo and most
importantly the stability of my operating system, which is why I
bothered to comment. I want to stress I am not opposed to moderation,
but so far the reason why things are happening and the specific things
being proposed do not seem to be well justified.

If, like in the past, decisions will be enforced more or less
arbitrarily and opaquely, I can only see this causing more problems. I
suppose the problems may be quieter.

Cheers,
 R0b0t1

Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

[R0b0t1]

On Sun, Dec 17, 2017 at 10:53 AM, Nils Freydank <holgers...@posteo.de> wrote:
> There is a specific RFC about splitting the mailing list because of a
> problematic style of conversation.
>

Well, yes - but what is problematic? Certain parties keep vaguely
alluding to past actions, which is what I am inquiring about.

> Even if that split won’t happen -- I don’t know if mgorny has the "right" or
> support to do that and I personally want to stay out of these discussions -- I
> really *do* think that a moderation of a frequented mailing list like gentoo-
> dev is a generally good idea. Therefore we need properly documented rules
> (beside moderators).
>

I don't like being here either, but after using Gentoo for a while
arbitrary actions taken by developers have broken my system, and poor
commit discipline has in cases made it very hard to figure out what
was changed and why.

This is an outgrowth of those things. If arbitrary choices are made
here and now arbitrary choices will keep being made elsewhere in the
future.

For some reason a lot of people seem to think my questions are
annoying. They're not supposed to be annoying. If a decision is
happening with purpose, then spending 30s to type out that purpose
should not be annoying.

> To answer you question: I think the RFC introduces either a "time pressure" or
> should be seen as sign that this list needs an improvement.
>

See reply to first paragraph; I mean specific events that make the OP
feel this is necessary.

Cheers,
 R0b0t1

Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB

[R0b0t1]

On Tue, Dec 19, 2017 at 2:33 PM, Patrick Lauer  wrote:
> On 12/17/17 19:39, Mike Gilbert wrote:
>> On Sun, Dec 17, 2017 at 8:21 AM, Michał Górny  wrote:
>>> Hello, everyone.
>>>
>>> It's my pleasure to announce that with a majority vote the QA team has
>>> accepted a new policy. The accepted wording is:
>>>
>>>   Total size of 'files' subdirectory of a package should not be larger
>>>   than 32 KiB. If the package needs more auxiliary files, they should
>>>   be put into SRC_URI e.g. via tarballs.
>>>
>>> (the total size being computed as a sum of apparent file sizes)
>>>
>>> The relevant policy vote is finishing at bug #633758 [1]. The CI reports
>>>  [2] were updated to report packages whose 'files' directories exceed
>>> 64 KiB, to avoid adding many new warnings at once. The limit will
>>> be lowered down to 32 KiB as packages are fixed to comply with the new
>>> policy.
>>>
>>> At the same time, I would like to explicitly remind developers that
>>> the spirit of the policy is 'do not let "files" grow large', not 'make
>>> sure you're one byte less than 32769.' Do not argue that your package
>>> exceeds the limit only by few bytes -- even if it gets close to the
>>> limit, then it means it's way too large.
>>
>> I just want to voice my opinion on this: as a developer, this policy
>> is a royal pain in the ass.
>>
>> I would ask the council to please increase this limit to at least 100
>> KiB, preferably more.
>>
> As a user I would like to ask everyone involved to stick to the 32kB
> limit so that we (as in everyone) don't have to fetch megabytes of
> patches we'll never use, just because someone was lazy.
>

How easy is it to move patches to Gentoo infrastructure if the patches
are not provided by upstream? I am slightly uncomfortable with
everything being pushed to websites like GitHub by default.

Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

[R0b0t1]

Hello,

On Tue, Dec 5, 2017 at 4:18 PM, Nils Freydank <holgers...@posteo.de> wrote:
> Hello everyone,
>
> with regards to the current mailing list (ML) split discussion, and one
> specific message deep down there by mgorny asked for someone providing
> moderator rules, I would like to propose the following ruleset for gentoo-dev
>
> Right now the situation escalated in a way that forces to actually do
> something and I hope we can recreate an atmosphere where technical
> improvements can happen.
>

To me, at least, this isn't self-evident. What specific actions make
you think an immediate response is necessary?

self-evident
  adj. Evident to one’s self and to nobody else.

Cheers,
 R0b0t1

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[R0b0t1]

On Thu, Dec 14, 2017 at 7:25 PM, M. J. Everitt <m.j.ever...@iee.org> wrote:
> On 15/12/17 01:17, R0b0t1 wrote (excerpted):
>> I'm not trying to be confrontational, but asserting an opinion is
>> correct without explaining why that it is so isn't really conducive to
>> arriving at the truth. I understand not wanting to answer if I am
>> completely clueless, and would like to apologize in advance for
>> bothering the developers.
>>
>> I am not very smart, sir.
>>
>> Cheers,
>>  R0b0t1
>>
> With all due respect, Gentoo is not renowned for spoon-feeding ...
>

That is exactly right, sir! I am trying my best to not impose on the
goodwill of the mailing list participants. At the same time, I feel
like I could understand an explanation if one was offered. If any
person's judgement suggests otherwise, however, surely they are
correct and no time should be wasted on such a person as myself.

> Returning to the topic in hand, two key points strike out at me:-
>
> 1) Gentoo isn't really interested in having a 'stable' tree or it would
> already be happening. As such, why not cut the Gordian knot, declare
> that this is not something that will happen [soon] and let users make
> their own choices. The [majority of] developers already seem to have ...
>

This is one of the valid conclusions, especially if the criteria for
stable packages are not changed.

> 2) Whilst there has yet another fine bike-shed emerged on the subject, I
> have only seen one volunteer willing or capable to actually take on
> implementation of anything that has been discussed on this thread. As
> such, you can talk all you like .. nothing will happen until somebody
> actually *does* something .. For all the hating, I will duly credit
> mgorny for producing a consistent quantity of commits across the board
> in Gentoo, and whilst you may not agree with all his bitching (for want
> of a better term) at least he can stand and say "well at least I did
> *something* about it, whether You like it or not ...".
>
> Damnit, there's another $2 from me .. my apologies.
>

I did some initial work trying to fix issues with erlang and rebar,
but I was unable to duplicate the errors due to how tinderboxes work.
A buildbot may not be any more repeatable depending on how it is set
up. Before any work is done I think the problem could be better
characterized, but then you have another long mailing list discussion
that people may or may not be willing to read. People want to do
something, not think about doing something.

In a lot of times that is the better option, even. But not always.

Cheers,
 R0b0t1

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[R0b0t1]

On Thu, Dec 14, 2017 at 4:04 PM, R0b0t1 <r03...@gmail.com> wrote:
> On Thu, Dec 14, 2017 at 2:32 PM, Kristian Fiskerstrand <k...@gentoo.org> 
> wrote:
>> On 12/14/2017 09:21 PM, R0b0t1 wrote:
>>> It seems like lagging stability is due to a lack of resources. I do
>>> not know a single person who would be able to run only stable
>>> packages.
>>
>> I run stable only on most of my systems.
>>
>
> That is fine, but this thread exists because at least the OP thinks
> stabilization is not happening quickly enough, likely because there
> are not enough people working on it. Allowing stabilization work from
> mixed systems might allow more people to help.
>
>>> They seem to move too slowly, and people switch to unstable
>>> packages because they contain bugfixes and sometimes new features.
>>
>> slow isn't necessarily a problem, as long as security fixes are handled.
>> There is some balancing for large performance gains, but most existing
>> systems are scaled based on the current estimates so it would only be
>> relevant for the up sizing of the server park for growth needs etc.
>>
>>>
>>> Could the criteria for stability be reconsidered? Mixed systems might
>>
>> why would it?
>>
>
> Per the question posed by OP the current state of affairs does not
> seem to be working, and I have tried to point out one likely cause. If
> it's hard to justify the criteria for stability then maybe the
> criteria don't make sense.
>
>>> not be supported, but save for cases of ABI/API breakage (which can
>>> happen when transitioning from stable->stable) I do not know why the
>>> packages would not play well with each other. I am sure there are
>>> examples where things have blown up, but it seems like expecting that
>>> to be the case isn't helping.
>>
>> There are plenty of cases where this fails in miserable ways, so thats
>> not a good idea (not to mention the dependency hell from it). That said,
>> you can have a stable chroot, or just use a VM for testing etc.
>>
>
> Can you be specific? Human memory is biased towards negative
> experiences. If it's hard to actually describe the multitude of issues
> that mixed systems cause then it is very likely mixed systems do not
> cause many issues.
>
> Personally, I have very few problems due to my mixed system, and less
> than I would have on a stable system.
>
> Cheers,
>  R0b0t1

I'm not trying to be confrontational, but asserting an opinion is
correct without explaining why that it is so isn't really conducive to
arriving at the truth. I understand not wanting to answer if I am
completely clueless, and would like to apologize in advance for
bothering the developers.

I am not very smart, sir.

Cheers,
 R0b0t1

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[R0b0t1]

On Thu, Dec 14, 2017 at 2:32 PM, Kristian Fiskerstrand <k...@gentoo.org> wrote:
> On 12/14/2017 09:21 PM, R0b0t1 wrote:
>> It seems like lagging stability is due to a lack of resources. I do
>> not know a single person who would be able to run only stable
>> packages.
>
> I run stable only on most of my systems.
>

That is fine, but this thread exists because at least the OP thinks
stabilization is not happening quickly enough, likely because there
are not enough people working on it. Allowing stabilization work from
mixed systems might allow more people to help.

>> They seem to move too slowly, and people switch to unstable
>> packages because they contain bugfixes and sometimes new features.
>
> slow isn't necessarily a problem, as long as security fixes are handled.
> There is some balancing for large performance gains, but most existing
> systems are scaled based on the current estimates so it would only be
> relevant for the up sizing of the server park for growth needs etc.
>
>>
>> Could the criteria for stability be reconsidered? Mixed systems might
>
> why would it?
>

Per the question posed by OP the current state of affairs does not
seem to be working, and I have tried to point out one likely cause. If
it's hard to justify the criteria for stability then maybe the
criteria don't make sense.

>> not be supported, but save for cases of ABI/API breakage (which can
>> happen when transitioning from stable->stable) I do not know why the
>> packages would not play well with each other. I am sure there are
>> examples where things have blown up, but it seems like expecting that
>> to be the case isn't helping.
>
> There are plenty of cases where this fails in miserable ways, so thats
> not a good idea (not to mention the dependency hell from it). That said,
> you can have a stable chroot, or just use a VM for testing etc.
>

Can you be specific? Human memory is biased towards negative
experiences. If it's hard to actually describe the multitude of issues
that mixed systems cause then it is very likely mixed systems do not
cause many issues.

Personally, I have very few problems due to my mixed system, and less
than I would have on a stable system.

Cheers,
 R0b0t1

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[R0b0t1]

On Thu, Dec 14, 2017 at 2:13 PM, Thomas Deutschmann <whi...@gentoo.org> wrote:
> On 2017-12-14 21:06, R0b0t1 wrote:
>> In response to the concerns about stability: If I run a lot of unstable
>> packages, would that preclude my system from being able to help?
>
> Yes. Only clean stable systems are eligible for arch testing. That's the
> whole idea of arch testing... ;)
>
> Remember that mixed systems aren't officially supported.
>

It seems like lagging stability is due to a lack of resources. I do
not know a single person who would be able to run only stable
packages. They seem to move too slowly, and people switch to unstable
packages because they contain bugfixes and sometimes new features.

Could the criteria for stability be reconsidered? Mixed systems might
not be supported, but save for cases of ABI/API breakage (which can
happen when transitioning from stable->stable) I do not know why the
packages would not play well with each other. I am sure there are
examples where things have blown up, but it seems like expecting that
to be the case isn't helping.

Cheers,
 R0b0t1

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[R0b0t1]

On Wed, Dec 13, 2017 at 2:55 PM, Lucas Ramage <ramage.luca...@gmail.com>
wrote:

> I see, well I can setup buildbot to do that. Is there some place in
> particular that I should send my test results?
>

Is this part of the point of a Tinderbox? The only problem I can see is
that the configurations being tested can be extremely hard to replicate and
lead to sporadic errors.

In response to the concerns about stability: If I run a lot of unstable
packages, would that preclude my system from being able to help?

Cheers,
 R0b0t1

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[R0b0t1]

On Tue, Dec 12, 2017 at 12:24 PM, Rich Freeman <ri...@gentoo.org> wrote:
> On Tue, Dec 12, 2017 at 1:15 PM, Michał Górny <mgo...@gentoo.org> wrote:
>>
>> It seems that we've started lacking arch testers for AMD64 architecture.
>> At this moment, there are already 159 bugs in amd64 backlog, and there
>> is no noticeable progress. New stabilization requests are usually
>> handled much faster by x86, sparc and hppa teams!
>>
>> If you have a stable AMD64 system and would like to help arch testing,
>> please do! I don't know what exact rules for that are but I think [1]
>> could be helpful. If someone knows better, then please share.
>>
>
> As far as I'm aware the standing policy already exists that
> maintainers can stabilize their own packages on amd64.
>
> That said, if somebody wants to organize an AT program for amd64 they
> should feel free to do so.  I could explain how things used to work at
> least if that is helpful.
>
> The old way it used to work is that ATs had to pass the ebuild quiz
> and they would get editbugs privs to tag bugs as tested.  I won't
> elaborate here unless there is interest...
>

I would like to know. But on the other hand, anyone interested in
contributing to packages they work with is likely already doing so. On
the third (and final?) hand, it may also be that there are people
looking for direction.

Cheers,
R0b0t1

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

[R0b0t1]

is fully unfounded and completely inappropriate. FYI,
> just let me correct a few facts here:
>
> 1. ComRel made its decision long before the discussion was even started
> (and I was unaware of it as well), and -- unless you presume they have
> time travellers there -- had nothing to do with it.
>
> 2. I disagree with the way of announcing the ban as well. I had nothing
> to do with that.
>
> 3. The agenda item wasn't expressing 'feelings of one developer', as you
> know it. It was written by me because I found the time to prepare
> a rationale of *facts* to support it. Don't shoot the messenger.
>

Most of what you provided were baseless assertions. I gave you ample
opportunity to explain why the actions would be taking place, but you
refused to provide any facts.

> 4. Finally, if you really hate me so much, you could at least bother to
> check the facts instead of publicly insulting me based purely on lies.
>

What facts?

Respectfully,
 R0b0t1

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

[R0b0t1]

On Fri, Dec 8, 2017 at 7:57 PM, R0b0t1 <r03...@gmail.com> wrote:
> On Fri, Dec 8, 2017 at 7:20 PM, Georg Rudoy <0xd34df...@gmail.com> wrote:
>> 2017-12-08 2:43 GMT-05:00 R0b0t1 <r03...@gmail.com>:
>>>
>>> On Mon, Dec 4, 2017 at 3:39 PM, Kristian Fiskerstrand <k...@gentoo.org> 
>>> wrote:
>>> > On 12/04/2017 10:36 PM, William L. Thomson Jr. wrote:
>>> >> Sorry last one, directed to Alec, but all should read.
>>> >
>>> > I hope you really mean that, we've all heard you complaining about this
>>> > too many times already.
>>> >
>>>
>>> Inasmuch as a random person is likely to care, glancing at the
>>> messages shows wltjr is the more convincing of the parties involved.
>>> Having actually wasted time trying to figure out what is going on
>>> there is no mention of what ever happened from Gentoo that indicates
>>> anything improper took place.
>>
>> Single-point samples are not really representative.
>>
>> The messages wltjr sent and the bugs/PRs/etc he linked convinced me in
>> quite the contrary, at least, about the legitimacy of the current
>> actions.
>>
>
> I am having trouble understanding you, unfortunately. It seems like
> you agree with his removal from the list. I suppose that is okay,
> originally I just tuned the conversations out because they were noisy.
>
> The summary I have tried to provide is: despite the fact wltjr does
> not seem to have a filter, he has so far not actually been incorrect.
> The developers involved, on the other hand, have been contradicting
> themselves since I first saw this around 2013. At some point they
> appear to have provided him an "out" and would have let him apologize,
> but he wants an apology from them.
>

Buried in his messages there are apologies, but the sticking point
seems to be that he fails to recognize the original actions as
reasonable.

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

[R0b0t1]

On Fri, Dec 8, 2017 at 7:20 PM, Georg Rudoy <0xd34df...@gmail.com> wrote:
> 2017-12-08 2:43 GMT-05:00 R0b0t1 <r03...@gmail.com>:
>>
>> On Mon, Dec 4, 2017 at 3:39 PM, Kristian Fiskerstrand <k...@gentoo.org> 
>> wrote:
>> > On 12/04/2017 10:36 PM, William L. Thomson Jr. wrote:
>> >> Sorry last one, directed to Alec, but all should read.
>> >
>> > I hope you really mean that, we've all heard you complaining about this
>> > too many times already.
>> >
>>
>> Inasmuch as a random person is likely to care, glancing at the
>> messages shows wltjr is the more convincing of the parties involved.
>> Having actually wasted time trying to figure out what is going on
>> there is no mention of what ever happened from Gentoo that indicates
>> anything improper took place.
>
> Single-point samples are not really representative.
>
> The messages wltjr sent and the bugs/PRs/etc he linked convinced me in
> quite the contrary, at least, about the legitimacy of the current
> actions.
>

I am having trouble understanding you, unfortunately. It seems like
you agree with his removal from the list. I suppose that is okay,
originally I just tuned the conversations out because they were noisy.

The summary I have tried to provide is: despite the fact wltjr does
not seem to have a filter, he has so far not actually been incorrect.
The developers involved, on the other hand, have been contradicting
themselves since I first saw this around 2013. At some point they
appear to have provided him an "out" and would have let him apologize,
but he wants an apology from them.

Cheers,
 R0b0t1

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

[R0b0t1]

On Mon, Dec 4, 2017 at 3:39 PM, Kristian Fiskerstrand <k...@gentoo.org> wrote:
> On 12/04/2017 10:36 PM, William L. Thomson Jr. wrote:
>> Sorry last one, directed to Alec, but all should read.
>
> I hope you really mean that, we've all heard you complaining about this
> too many times already.
>

Inasmuch as a random person is likely to care, glancing at the
messages shows wltjr is the more convincing of the parties involved.
Having actually wasted time trying to figure out what is going on
there is no mention of what ever happened from Gentoo that indicates
anything improper took place.

Not So Respectfully,
 R0b0t1

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

[R0b0t1]

On Wed, Dec 6, 2017 at 11:44 AM, William L. Thomson Jr.
<wlt...@o-sinc.com> wrote:
> On Wed, 06 Dec 2017 09:51:23 +0100
> "Andreas K. Huettel" <dilfri...@gentoo.org> wrote:
>
>> Am Mittwoch, 6. Dezember 2017, 00:40:11 CET schrieb William L.
>> Thomson Jr.: [...]
>>  [...]
>>  [...]
>>
>> Well, it's like listening to a broken record, which keeps repeating
>> the same snippet. At some point you stop listening, and at some point
>> you realize you should maybe remove it from the player.
>>
>

wltjr, I really do not think you are helping your case. If I were in
your position I think I would not back down either, but at some point
it is best to let history acknowledge that you are right. I started
reading your messages because I noticed Gentoo developers being
inconsistent, but not everyone will keep an open enough mind to do
that.

> Maybe you should go take more of my Firebird changes and put them in
> tree. Since you took over that package I mtainained and then merged in
> my changes from Linux UnderGround overlay that came from mine...
>
> Who do you think made the Firebird 3.x ebuild? I DID
> https://github.com/Obsidian-StudiosInc/os-xtoo/commits/master/dev-db/firebird
>
> See linux underground reporting issues with mine before adding it to
> their repository
> https://github.com/Obsidian-StudiosInc/os-xtoo/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+firebird
>
> See the date after they got it from mine :)
> https://github.com/linuxunderground/gentoo.overlay/blob/master/dev-db/firebird/firebird-3.0.2.32703.0.ebuild
>
> Then Andreas adding it to tree... HILARIOUS
> https://github.com/gentoo/gentoo/commit/e246873f43db77850c172263be72bc5153b23adb#diff-7dc5e9ed8a228dd8f564e17d66c5559e
>
> Also seems it took a few tries why? Not familiar with package?
> https://github.com/gentoo/gentoo/commits/master/dev-db/firebird
>
> Same package, mgorny 51 comment QA leading to more issues because he
> does not use, have a clue about it, or bothered to actually test... Due
> to his approach and stance I assumed his changes  were correct. HUGE
> mistake on my behalf. Why in part mgorny does not like me
>

Though this thread might not be the best place, the character of
Gentoo developers seems to be relevant to the topic at hand. I agree
that there appear to be developers who have editorial control of
packages they do not understand. It also seems like they have ample
opportunity to confer with people who do understand the packages but
choose not to do so.

Respectfully,
 R0b0t1

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

[R0b0t1]

On Wed, Dec 6, 2017 at 7:04 AM, Rich Freeman <ri...@gentoo.org> wrote:
> On Wed, Dec 6, 2017 at 2:22 AM, R0b0t1 <r03...@gmail.com> wrote:
>> On Tue, Dec 5, 2017 at 4:12 PM, Rich Freeman <ri...@gentoo.org> wrote:
>>>
>>> And what would you do when somebody repeatedly sexually harasses other
>>> members of the community in private after being told to stop, and then
>>> acts as if they're the victim on the public mailing lists?
>>>
>>
>> If you are going to allege misconduct you need to be prepared to prove it.
>>
>
> And this is done - in private.  Nobody is alleging misconduct in
> public, so I don't see why it needs to be proven in public.  Those
> being kicked out are generally told why and are given an opportunity
> to explain themselves, and often they're given an opportunity to
> improve.  Some have later posted publicly saying they don't know why
> they were booted.  With unmoderated lists we can't keep them from
> making false statements like this.  With our current policies we can't
> really contradict them specifically either.
>

You're mincing words: people are publicly alleging (we're talking
about it right now) private misconduct. Actions are now being proposed
(and have already begun to be acted out) based on this private
behavior. It is reasonable that if you expect anyone to believe you,
that you should prove the misconduct actually took place.

> I actually saw Debian take a slightly different tact in a recent
> situation.  It looks like they gave the accused the opportunity to
> decide whether the reasons for the action would be made public or not.
> In that case they chose to make it public, so there was a public
> statement by the project as to what was being done and why.  It
> probably wouldn't hurt to talk to a lawyer but such an approach has
> the advantage that it both preserves the privacy of the accused, while
> also defeating false statements.  If somebody alleges that they're
> innocent but did not give permission for the project to explain what
> actually happened, they can hardly be considered a voice for
> transparency and it would diminish their credibility.  On the other
> hand, if somebody chooses to quietly leave the community there would
> be no publicity around the event.  I'd think it would also help to
> defeat liability for defamation/etc since the statement could be
> presented to the accused for them to accept or reject, and if they
> accepted it for publication that would probably make it hard to argue
> in a court.
>

What really makes this hard to argue in court is the fact that in all
but one circuit libel, slander, and by extension defamation are all
impossible to claim if the statements were truthful. The first circuit
decision is very unpopular, and it seems like people do not expect it
to stand further testing as it was due to exceptional circumstances.

But really, the bigger issue is that lawyers are not magic sages that
can solve all of your problems. Most statements by lawyers are
opinions about how a justice might decide, and they do not know for
sure. In fact, much of practicing law is avoiding confrontation at all
cost, and many issues in the popular eye are almost entirely legal
speculation that has never seen a courtroom!

Consequently, the justification for the actions as has been given is
pathetic: if you actually had people's best interest in mind you would
be forthcoming with the evidence, because you truly believed the
problem is worth solving and believed you should convince other people
that it is worth solving. If you made someone's private actions public
(with consent of one party involved) it would be very hard to prove
that anything was done out of malice, which would be necessary, in the
US, to prove defamation.

Do not give up your freedom to act unless you are forced to.

The one legitimate complaint I could see being entertained is similar
to the ones that are now cropping up against universities and their
Title IX compliance courts: you have no legal training and are not
authorized to punish anyone, so the only thing you should do once you
are notified of misconduct is contact the police. In this sense the
policies you have now are "illegal" (in the vague, nebulous way that
your behavior makes it more likely for another party to have
standing).

> Aside from defamation as a potential issue, there is another reason to
> keep this stuff private.  Somebody might not be a good fit for a big
> community project, but that doesn't mean that there aren't other areas
> of their life where they can be successful.  Publicity over a bad
> event can harm their reputation in ways that go beyond the immediate
> needs of our community.  And there always is the chance that an error
> is being made in kicking them out.  Sure, that isn't 

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

[R0b0t1]

On Mon, Dec 4, 2017 at 11:28 AM, Michał Górny <mgo...@gentoo.org> wrote:
> W dniu nie, 03.12.2017 o godzinie 23∶59 -0600, użytkownik R0b0t1
> napisał:
>> As noted, there is one: analyzing the actions of those who are being
>> "attacked" to see why people are bothering to do it in the first
>> place. I sincerely doubt the offensive parties are doing what they are
>> doing without cause.
>
> Most of the affected developers are perfectly aware of the purpose of
> those attacks. If there was anything to be done to resolve the situation
> peacefully, we'd have done it long time ago. However, we can't and are
> not going to yield to people's unfounded demands based purely
> on the pressure inflicted by their misbehavior.
>

You are presupposing they are attacks. If they are public, and on
gentoo-dev, then why would you consider them attacks? Are you the only
person who acts with reason or purpose? How do you determine someone
else is not acting with those things?

> I believe this is as far as I can answer you. Going beyond that goes
> into public judgment of private issues which is unacceptable on this
> mailing list.
>

You have now made the issue public by asking that the information be
acted on. If you can not present it publicly, then do not ask anyone
to act on it, and do not hold people to decisions or outcomes made
using the information.

>> But no, the Gentoo developers are always above reproach.
>
> This remark is highly inappropriate.
>

Multiple times I have had polite requests for some explanation of
actions be ignored. In a few of them I can cite behavior that
contradicts itself. What conclusion is left to me save that certain
developers revel in being petty tyrants?

>> > I'm sorry but the purpose of this thread is not to convince you that
>> > the problems exist. If you haven't experienced them already, then it
>> > would be polite of you to either accept them as a fact, or do some
>> > research yourself.
>> >
>>
>> Your job is not to convince me, personally, but the future reader of
>> this list. If you have given up on doing so then you have admitted
>> that you do not want to be held accountable for your actions because
>> you do not feel you need to explain why you are doing what you are
>> doing.
>
> It is quite ironic that you worry about a 'future reader' needing to be
> convinced in this past post (presuming you have some infinite knowledge
> of what kind of details would a 'future reader' consider satisfying)
> and at the same time you clearly reject to search for any past posts
> on the topic.
>

Most people consider evidence and fact-based reasoning satisfying. You
can dispute this if you wish, but I'm not sure how far you will be
able to take it.

> Also, I should point out that you don't get to tell me what my job is.
> If you believe this thread should contain such data, please collect it
> yourself in your own time and include it in a reply. However, I should
> point out that you should respect all the rules we're talking about.
> I'd rather spend the time doing something that is of much greater
> importance of Gentoo users than some potential decision that will
> probably no longer be remembered in 12 months, except in snarky
> comments.
>

If you do not want to convince people you are right, eventually you
will have to accept a complete lack of credibility.

I do not have such information and now I have learned you are actively
keeping it from me and from everyone else who may be trying to form an
opinion on this matter.

>> > I understand that you might want to know things. However, it is
>> > generally impolite if someone 'comes late to the party' and starts
>> > shouting questions that the existing participants know answers to
>> > already. This is distorting to the conversation at hand.
>> >
>>
>> I am not shouting. I am politely, but pointedly, asking questions that
>> you ostensibly should already have the answer to. If you do not have
>> the answer, then I feel it is clear to future readers of the list that
>> you are making decisions for nonsensical reasons.
>
> I should point out that your personal attacks are also unacceptable.
> If you disagree with the proposal, then please focus on discussing facts
> and not trying to prove your opponent's incompetence.
>

I regret that you see it as a personal attack, but I am simply trying
to tell you how I expect most people will view the situation. You are
asserting you are right with no evidence. No one has any reason to
believe you.

>> > People's private issues are not topic of this mailing list. It is
>> > generally impolite and unprofessional to discuss them publicly. Please
>> > don't

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

[R0b0t1]

On Tue, Dec 5, 2017 at 4:12 PM, Rich Freeman <ri...@gentoo.org> wrote:
> On Tue, Dec 5, 2017 at 4:16 PM, Daniel Campbell <z...@gentoo.org> wrote:
>>
>> I think the plan to split mailing lists serves as a way to insulate
>> developers from the effects of their decisions. Anyone with an
>> incongenial tone will have their voice bit revoked and their mail will
>> be dropped or rejected.
>
> And what would you do when somebody repeatedly sexually harasses other
> members of the community in private after being told to stop, and then
> acts as if they're the victim on the public mailing lists?
>

If you are going to allege misconduct you need to be prepared to prove it.

> Pretty much every organization I've ever been in would quietly show
> such a person the door unless the victim went public with the
> allegations.  Most normal people wouldn't want to be a part of an
> organization that didn't do such a thing.
>
> Apparently though in Gentoo some prefer that the victims of harassment
> have no recourse if the harassment doesn't happen on the gentoo-dev
> mailing list in public.
>
> If you think some cabal is running the show just run for Council.  If
> you win then you get the lucky job of trying to explain all this
> without disclosing the horrible things that some people do in private.
> Of course, lots of people won't believe you, since they profess to be
> innocent and the evidence can't be disclosed without bringing harm to
> a victim or creating the possibility of a defamation lawsuit.
>

Like in the thread about potential piracy issues with ebuilds, people
are being too cautious. For a defamation suit it would be necessary to
prove malicious intent, and then, only in the first circuit.

I'm still waiting for the notice that I can't use Gentoo to
manufacture weapons of mass destruction.

Respectfully,
 R0b0t1

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

[R0b0t1]

I apologize for replying to only this message, but #1 stood out and I
am still catching up.

On Mon, Dec 4, 2017 at 12:57 PM, kuzetsa <kuze...@gmail.com> wrote:
> On 12/04/2017 01:51 PM, William L. Thomson Jr. wrote:
>> On Mon, 4 Dec 2017 13:15:32 +
>> "M. J. Everitt" <m.j.ever...@iee.org> wrote:
>>
>>> On 04/12/17 00:37, Matt Turner wrote:
>>>> A user requested I forward this information to the mailing list:
>>>>
>>>> http://www.hbs.edu/faculty/Publication%20Files/16-057_d45c0b4f-fa19-49de-8f1b-4b12fe054fea.pdf
>>>> https://goo.gl/42A8v7 (short URL of the same)
>>>>
>>>> ... and was itself cited a dozen or times:
>>>>
>>>> https://scholar.google.com/scholar?cites=5443947091657980238
>>>> https://goo.gl/obvdzh (short URL of the same)
>> Anyone paying any attention to current events?  Quite many business and
>> governments have gone out of their way to protect and hide the actions
>> of abusers. In most causes because they were money makers. I think that
>> may contradict the article entirely.
>>
> 1) harvard business school research publication, not an "article"

I have read doctoral theses from Harvard, Yale, and others that were
complete trash (they were all copies of an original presentation of a
paper about finger trees; one included code which didn't compile).
Those involved with academia on Freenode have repeatedly warned me not
to trust people based on the institution they work for, nor even to
trust PhD holders about their field of study. This advice has served
me well.

Unfortunately, being politely asked to explain oneself seems to be
grating to a great many people.

> 2) if things don't change, I'll be one of the people to quit.
> 3) gentoo already has documented instances of people leaving.
>

Yes, and from the other end, I see lots of people who hate red tape
and a fear of confrontation that gets in the way of technical
discussion. As far as I can tell, most of the people who feel slighted
feel that way because they choose to interpret someone asking about
the validity of their actions as a personal insult.

Respectfully,
 R0b0t1

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

[R0b0t1]

On Sun, Dec 3, 2017 at 8:56 PM, kuzetsa  wrote:
>
> Yes please. I don't want to see gentoo end because of ... rudeness.
>

Be careful, it is easy to disguise rudeness as tact.

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

[R0b0t1]

On Sun, Dec 3, 2017 at 4:03 PM, Michał Górny <mgo...@gentoo.org> wrote:
> W dniu sob, 02.12.2017 o godzinie 19∶33 -0600, użytkownik R0b0t1
> napisał:
>> Hello,
>>
>> In every mailing list conversation, there are at least three people:
>> the two conversing, and the future reader. I point this out as I think
>> it important that everyone realize that not all posts are written for
>> those immediately participating in the conversation.
>>
>> Some time ago I was offered some equipment due to my history of
>> open-source contributions to a variety of projects. I asked the donor
>> to forward it (or money) to the Gentoo foundation, but they declined,
>> citing a general distaste for the management of software projects in
>> general and specific issues they believed existed within Gentoo.
>
> I'm not sure if this is relevant to the topic at hand. There are many
> issues within Gentoo. I'm trying to address one of them.
>

The point is that actions of [some of] the developers are affecting
the public perception of Gentoo to the point at least one person
hasn't wanted to donate.

>> On Sat, Dec 2, 2017 at 5:18 PM, Michał Górny <mgo...@gentoo.org> wrote:
>> > Hello, everyone.
>> >
>> > This is something that's been talked about privately a lot lately but it
>> > seems that nobody went forward to put things into motion. SO here's
>> > a proposal that aims to improve the condition of our mailing lists
>> > and solve some of the problems they are facing today.
>> >
>>
>> If you have in fact discussed this off list with people who agree, I
>> think it is important that you invite them to comment. Not only will
>> it show support for what you have detailed, it will allow them to
>> explain the problems they have in greater detail, so that perhaps a
>> solution that does not involve restricting list access could be found.
>
> This sentence merely focuses on 'don't shoot the messenger' part which
> will happen anyway. Those people won't come here to '+1' the proposal
> because this mailing list is not supposed to be about mail popularity
> contests.
>

No, but policy changes are. They should be critically analyzed. I'm
not going to pretend like I can vote, but I can try to make you feel
bad about not answering my questions.

> Also because they don't want to be targeted by people misbehaving here.
> In fact, a number of them already pinged me today privately showing
> support, and some of them told me exactly that -- that they don't want
> to become a target of aggression. A few participants of this mailing
> list have shown harassment towards people that stood up to them --
> including constant insults on various public and private channels.
>

Again, no one has any right to not be offended. For something of this
nature I feel public support should be necessary.

>>
>> It may be that I am misunderstanding your language, but what you have
>> presented does not leave many things open for discussion. It seems
>> like what you have presented is to be either accepted or rejected as
>> is. Seeing as my opinion does not matter, it further seems like it
>> will simply be accepted as is.
>
> I simply don't believe that after so many iterations there's any more
> option that hasn't been tried or rejected already.
>

As noted, there is one: analyzing the actions of those who are being
"attacked" to see why people are bothering to do it in the first
place. I sincerely doubt the offensive parties are doing what they are
doing without cause.

But no, the Gentoo developers are always above reproach.

>> >
>> > Problems
>> > 
>> >
>> > Currently the developer-oriented mailing lists gentoo-dev and gentoo-
>> > project are open to posting by everyone. While this has been generally
>> > beneficial, we seem to be having major problems with some
>> > of the posters for more than a year. Off hand, I can think of three:
>> >
>> > 1. Repeating attacks against Gentoo and/or Gentoo developers (including
>> > pure personal attacks). While it is understandable that some people may
>> > be frustrated and need to vent off, repeating attacks from the same
>> > person are seriously demotivating to everyone.
>> >
>>
>> No one has any right to not be offended. If Gentoo developers are
>> receiving criticism for their behavior, then perhaps it would be best
>> that they critically analyze their actions and the effect that they
>> have on other people.
>>
>> As far as I am aware most developers never get harassed and go quietly
>> on about their business. I have even asked 

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

[R0b0t1]

19:09   @floppym | wltjr really seems to make shit up when he
doen't know what he's talking about.
19:20@mgorny | lol
19:20@mgorny | we're talking about the real wltjr or the
r0b0t1 fake identity?
19:21   @floppym | mgorny: There's a fake?
19:22@mgorny | didn't you notice r0b0t1 on the mailing lists?
19:22   @floppym | Nope.
19:22   @floppym | I'm talking about the person filing bugs about
Portage failures on NFS, as well as bug
 | 637160
19:22@mgorny | he appeared out of the blue a few weeks ago
19:22  willikins | floppym: https://bugs.gentoo.org/637160
"dev-python/pbr-3.1.1 access violation with pypy3";
 | Gentoo Linux, Current packages; UNCO;
wlt-ml:prometheanfire
19:25@mgorny |
https://archives.gentoo.org/gentoo-dev/message/7f2b9a05baf062acc8bf7b539949f5b9
19:25@mgorny | this guy
19:25   @floppym | Oh, yes. He seems to conherent to be wltjr.
19:26@mgorny | 'i know nothing but i'm going to pretend i'm
the smartest guy around, and try to prove
 | everyone who disagrees with me is stupid'
19:27   @floppym | I see posts from him dating back to 2016; I
think it's a different person.
19:28 jstein | But this robot seems to need some kind of
repair or recalibration in my eyes
19:29@mgorny | floppym: maybe. but he behaves quite similar
19:31  * | floppym shrugs
19:32 jstein | the members on our mailinglist handle this
troll very well and do not get triggered by his
 | statements.
19:32   @floppym | If only the same could be said for wltjr...
19:34--> | fekepp
(~Thunderbi@2a02:8071:31ac:c00:221:ccff:fed4:6de7) has joined
#gentoo-python
19:34 jstein | where do I remember this nick from? Bugs?
19:36 jstein | the robot did not write any mail after 9th. I
expected he was set to "moderated".

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

[R0b0t1]

ey don't see earlier
> replies until they're past moderation),
>
> γ) the problem will be solved only partially -- what if a reply contains
> both valuable info and personal attack?
>

I agree with this logic, but please be careful - it states a problem,
presupposes a single solution, and then concludes that there is only
one course of action based on the critique applied to that one
solution. This is partly why I see the proposal as something which
does not seem to be accommodating to alternate viewpoints. It makes
addressing this section with an alternate viewpoint difficult, and if
I ignore it then it looks like I ignored part of your argument.

>
> Seeing that no other effort so far has succeeded in solving the problem,
> splitting the mailing lists seems the best solution so far. Most
> notably:
>
> а. Developer mailing lists are restored to their original purpose.
>
> б. It is 'fair'. Unlike with disciplinary actions, there is no judgment
> problem, just a clear split between 'developers' and 'non-developers'.
>
> в. 'Expert users' are still provided with a mailing list where they can
> discuss Gentoo without being pushed down into 'user support' channels.
>
> г. Active contributors (in particular recruits) can still obtain posting
> access to the mailing lists, much like they do obtain it to #gentoo-dev
> right now. However, if they start misbehaving we can just remove that
> without the risk of evasion.
>

I feel this is still a fairly large barrier to involvement. Getting
people to the point they want to contribute or have the knowledge to
contribute is the hard part, and what this will make harder to do.


Respectfully,
 R0b0t1

Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v2]

[R0b0t1]

On Wed, Nov 22, 2017 at 2:02 AM, Michał Górny <mgo...@gentoo.org> wrote:
> W dniu wto, 21.11.2017 o godzinie 20∶59 -0600, użytkownik R0b0t1
> napisał:
>> On Mon, Nov 20, 2017 at 12:42 PM, Michał Górny <mgo...@gentoo.org> wrote:
>> > W dniu czw, 16.11.2017 o godzinie 11∶19 +0100, użytkownik Michał Górny
>> > napisał:
>> > > Hi, everyone.
>> > >
>> > > Here's the updated version of GLEP 74 taking into consideration
>> > > the points made during the Council pre-review.
>> > >
>> > > ReST: https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst
>> > > HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html
>> > >
>> >
>> > New changes:
>> >
>> > 9d819c9 glep-0074: Disallow filenames containing whitespace
>>
>> This seems like a bad idea. I apologize if this is covered in more
>> detail somewhere, but the only justification I can see is that the
>> current grammar does not permit quoting or some other method of
>> specifying whitespace as part of a field value.
>>
>> Is there any way to assure that this won't break things in a
>> non-obvious way? I'm having a hard time imagining how it would be an
>> inflexible requirement to use a space in a filename, but it could come
>> up if it was necessary to use Portage on a non-Gentoo distribution.
>
> Having a whitespace there *will* break the parser. Until a better parser
> is provided, we need to reject it to prevent tools from accidentally
> generating broken files. It's better to tell straight away 'sorry, you
> can't use Manifest here' than cause completely unexpected behavior
> in the parser.
>
> Using whitespace in filenames is going to break Portage in horrible
> ways. Half of shell script in it is based on whitespace-separated lists.
> PMS doesn't provide any means to replace some of them. It's not going to
> happen.
>

Yes, I was talking about providing a better parser. I understand it is
as it is now because whitespace is a delimiter.

If it's not possible to know where all code that has this as a
requirement is, that's fairly bad.

http://langsec.org/occupy/

>> It seems very arbitrary. I think the better solution is to use a better 
>> parser.
>>
>
> The parser is already there for 15 years or more. We can't just replace
> it without breaking all old Portage versions.
>

It sounds like portage is already broken.

Cheers,
 R0b0t1

Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v2]

[R0b0t1]

On Mon, Nov 20, 2017 at 12:42 PM, Michał Górny <mgo...@gentoo.org> wrote:
> W dniu czw, 16.11.2017 o godzinie 11∶19 +0100, użytkownik Michał Górny
> napisał:
>> Hi, everyone.
>>
>> Here's the updated version of GLEP 74 taking into consideration
>> the points made during the Council pre-review.
>>
>> ReST: https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst
>> HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html
>>
>
> New changes:
>
> 9d819c9 glep-0074: Disallow filenames containing whitespace

This seems like a bad idea. I apologize if this is covered in more
detail somewhere, but the only justification I can see is that the
current grammar does not permit quoting or some other method of
specifying whitespace as part of a field value.

Is there any way to assure that this won't break things in a
non-obvious way? I'm having a hard time imagining how it would be an
inflexible requirement to use a space in a filename, but it could come
up if it was necessary to use Portage on a non-Gentoo distribution.

It seems very arbitrary. I think the better solution is to use a better parser.

Cheers,
  R0b0t1

Re: [gentoo-dev] Manifest2 hashes: validation of single hash per MANIFESTx_REQUIRED_HASH

[R0b0t1]

On Mon, Nov 20, 2017 at 9:00 PM, R0b0t1 <r03...@gmail.com> wrote:
> Hello friends!
>
> On Wed, Nov 15, 2017 at 3:02 PM, Robin H. Johnson <robb...@gentoo.org> wrote:
>> Replying to your original question here, to repeat the answer I emphasised
>> before, along with significantly more detail in the history of Portage hashes
>> (pulled from my notes back to GLEP57 and some minor updates).
>>
>> On Wed, Nov 08, 2017 at 12:57:49PM -0600, R0b0t1 wrote:
>>> These posts are concerning because it looks like someone became stir
>>> crazy and invented a problem to solve. The changes proposed to date
>>> have remained poorly justified, and no one has addressed the concern
>>> that multiple hashes *is* actually more secure.
>>>
>>> If it was deemed necessary at one point, what justification was used?
>>> I.e. https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence.
>> On Wed, Nov 15, 2017 at 11:47:41AM -0600, R0b0t1 wrote:
>>> Does the existence of a decision mean I would need to contact the trustees
>>> if I feel the changes have not been adequately justified?
>>
>> In GLEP59, I referenced a paper by Joux [J04], in which it was shown that a
>> concatenation of multiple hashes is NOT much more secure against collisions
>> than the strongest of the individual hashes.
>>
>> That was cited as original logic in GLEP59 for the removal of SHA256 (that
>> removal was never implemented). WHIRLPOOL & SHA512 were kept out of an
>> abundance of caution at the time, mostly to implementation bugs in hashes 
>> (as I
>> have referenced in the related threads since).
>>
>> Your logic regarding removing something you think I don't understand is wrong
>> (Chesterton's Fence):
>>
>> If you dig in the history of Portage, you will see that it's always been 
>> valid,
>> to have just a SINGLE hash for each file in a Manifest.  Required hashes has
>> NEVER contained more than one hash.
>>
>> If multiple hashes are present, then Portage will validate all of them, but a
>> potential attacker can still modify the Manifest and have only a single hash
>> listed.  Exactly which hash MUST be present has changed over time.
>>
>> Manifest1 is very old, and was stored in $CAT/$PN/files/digest-$P
>> Manifest2 is the current $CAT/$PN/Manifest (and soon in more locations per 
>> MetaManifest).
>>
>> 1999/xx/xx: Portage starts with Manifest1 format, MD5-only (CVS)
>> 2004/08/25: Portage gets SHA1 support in Manifest1, but is problematic, SHA1 
>> generation manual only.
>> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/pym/portage_checksum.py?revision=1.1=markup
>> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/pym/portage.py?r1=1.485=1.486
>> 2005/12/19: Portage Manifest1 supports MD5,SHA1,SHA256,RMD160, but still 
>> requires only a single hash present. Generates MD5+SHA256+RMD160.
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=cd3e3775966a9f58aebb91f58cbdb5903faad3de
>> 2006/03/24: Manifest2 introduced.
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=f993747ca501e8a70d6f6174711149a172cfc3c2
>> 2007/01/20: MANIFEST2_REQUIRED_HASH introduced, SHA1, it must be present & 
>> pass
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=e768571187d1655fbb558c23d61fa2983e48e411
>> 2007/12/18: MANIFEST1_REQUIRED_HASH introduced, MD5, it must be present & 
>> pass
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=d9b10deaa03ce174d5ccc3b59c477549ad87e884
>> 2008/02/28: Manifest1 support dropped.
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=66940e1f2f0549ee8f01dad59016e168105e193d
>> 2011/10/02: GLEP59 implemented, MANIFEST2_REQUIRED_HASH changes to SHA256
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=c8cd3a985cc529299411d7343a11004b7d1330ef
>> 2017/06/15: MANIFEST2_REQUIRED_HASH changes to SHA512
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=e6abcc0b7cbdca481862a5c7cca946c01c471ffb
>>
>> [J04] Joux, Antoie. (2004). "Multicollisions in Iterated Hash Functions - 
>> Application to Cascaded Constructions;"
>> Proceedings of CRYPTO 2004, Franklin, M. (Ed); Lecture Notes in Computer 
>> Science 3152, pp. 306-316.
>> Available online from: 
>> http://web.cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf
>>
>
> This is the information I was looking for, thank you. I feel that the
> matter has been adequately explained. I apologize for missing your
> response.
>
> The paper gives a counter intuitive result, so I suspect I will have
> to

Re: [gentoo-dev] Manifest2 hashes: validation of single hash per MANIFESTx_REQUIRED_HASH

[R0b0t1]

Hello friends!

On Wed, Nov 15, 2017 at 3:02 PM, Robin H. Johnson <robb...@gentoo.org> wrote:
> Replying to your original question here, to repeat the answer I emphasised
> before, along with significantly more detail in the history of Portage hashes
> (pulled from my notes back to GLEP57 and some minor updates).
>
> On Wed, Nov 08, 2017 at 12:57:49PM -0600, R0b0t1 wrote:
>> These posts are concerning because it looks like someone became stir
>> crazy and invented a problem to solve. The changes proposed to date
>> have remained poorly justified, and no one has addressed the concern
>> that multiple hashes *is* actually more secure.
>>
>> If it was deemed necessary at one point, what justification was used?
>> I.e. https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence.
> On Wed, Nov 15, 2017 at 11:47:41AM -0600, R0b0t1 wrote:
>> Does the existence of a decision mean I would need to contact the trustees
>> if I feel the changes have not been adequately justified?
>
> In GLEP59, I referenced a paper by Joux [J04], in which it was shown that a
> concatenation of multiple hashes is NOT much more secure against collisions
> than the strongest of the individual hashes.
>
> That was cited as original logic in GLEP59 for the removal of SHA256 (that
> removal was never implemented). WHIRLPOOL & SHA512 were kept out of an
> abundance of caution at the time, mostly to implementation bugs in hashes (as 
> I
> have referenced in the related threads since).
>
> Your logic regarding removing something you think I don't understand is wrong
> (Chesterton's Fence):
>
> If you dig in the history of Portage, you will see that it's always been 
> valid,
> to have just a SINGLE hash for each file in a Manifest.  Required hashes has
> NEVER contained more than one hash.
>
> If multiple hashes are present, then Portage will validate all of them, but a
> potential attacker can still modify the Manifest and have only a single hash
> listed.  Exactly which hash MUST be present has changed over time.
>
> Manifest1 is very old, and was stored in $CAT/$PN/files/digest-$P
> Manifest2 is the current $CAT/$PN/Manifest (and soon in more locations per 
> MetaManifest).
>
> 1999/xx/xx: Portage starts with Manifest1 format, MD5-only (CVS)
> 2004/08/25: Portage gets SHA1 support in Manifest1, but is problematic, SHA1 
> generation manual only.
> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/pym/portage_checksum.py?revision=1.1=markup
> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/pym/portage.py?r1=1.485=1.486
> 2005/12/19: Portage Manifest1 supports MD5,SHA1,SHA256,RMD160, but still 
> requires only a single hash present. Generates MD5+SHA256+RMD160.
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=cd3e3775966a9f58aebb91f58cbdb5903faad3de
> 2006/03/24: Manifest2 introduced.
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=f993747ca501e8a70d6f6174711149a172cfc3c2
> 2007/01/20: MANIFEST2_REQUIRED_HASH introduced, SHA1, it must be present & 
> pass
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=e768571187d1655fbb558c23d61fa2983e48e411
> 2007/12/18: MANIFEST1_REQUIRED_HASH introduced, MD5, it must be present & pass
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=d9b10deaa03ce174d5ccc3b59c477549ad87e884
> 2008/02/28: Manifest1 support dropped.
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=66940e1f2f0549ee8f01dad59016e168105e193d
> 2011/10/02: GLEP59 implemented, MANIFEST2_REQUIRED_HASH changes to SHA256
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=c8cd3a985cc529299411d7343a11004b7d1330ef
> 2017/06/15: MANIFEST2_REQUIRED_HASH changes to SHA512
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=e6abcc0b7cbdca481862a5c7cca946c01c471ffb
>
> [J04] Joux, Antoie. (2004). "Multicollisions in Iterated Hash Functions - 
> Application to Cascaded Constructions;"
> Proceedings of CRYPTO 2004, Franklin, M. (Ed); Lecture Notes in Computer 
> Science 3152, pp. 306-316.
> Available online from: 
> http://web.cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf
>

This is the information I was looking for, thank you. I feel that the
matter has been adequately explained. I apologize for missing your
response.

The paper gives a counter intuitive result, so I suspect I will have
to spend more time with it.

Cheers,
 R0b0t1

Re: [gentoo-dev] Packages up for grabs

[R0b0t1]

On Monday, November 20, 2017, Amy Liffey <amy...@gentoo.org> wrote:
> dev-lang/clojure

I have some interest in helping with clojure. I have interacted with the
proxy maintainers before - do I need to wait for it to break?

Cheers,
    R0b0t1

[gentoo-dev] Re: Prefix bootstrap script maintainability (Was: No more stable keywords for Games)

[R0b0t1]

Hello friends!

On Monday, November 20, 2017, Sergei Trofimovich <sly...@gentoo.org> wrote:
> On Sun, 19 Nov 2017 22:47:35 -0600
> R0b0t1 <r03...@gmail.com> wrote:
>
>> Understanding an existing codebase should not be a technical
>> challenge. I had to resort to reimplementing all of the steps myself,
>> in part to understand if they were done properly in the first place.
>
> Looks like you are an expert in this area now and are perfectly capable
> of submitting the patches. I can review them at least for crossdev.
>

In my goal to understand bootstrap-rap I am still in the process of
creating something crossdev-like that can be used to generate a toolchain.

A recurring problem I have had is that this set of related tasks -
generating cross compilers and packages, generating an initramfs, or
generating a prefixed pseudoinstallation - all start by reimplementing some
subset of portage.

For prefix/RAP it makes sense, for the others possibly not.

>> Unfortunately these are things that the original authors should
>> produce. Experience has shown me that documentation written by
>> ancillary contributors that do not have deep experience with the code
>> base is poor.
>
> If you have invested some time to understand the code you and understood
> at least something you should be perfectly capable of submitting a patch
> to document a thing or two that took you time to grasp.
>

Yes, that is what I am doing with my own code as I have the time to write
it. I mostly still have no idea what is going on in the already written
code.

> Nobody knows what is hard for you to understand except yourself.
>

People will often find tasks similarly difficult. This is why I am
surprised documentation is lacking for specific projects, or, I suppose,
any software package that has ever been created.

Cheers,
R0b0t1

[gentoo-dev] Re: Prefix bootstrap script maintainability (Was: No more stable keywords for Games)

[R0b0t1]

Hello friends!

On Sun, Nov 19, 2017 at 6:54 PM, Benda Xu <hero...@gentoo.org> wrote:
> Greetings R0b0t1,
>
> R0b0t1 <r03...@gmail.com> writes:
>
>> It is one thing to say that contributions to the main Portage tree
>> require some standards to be upheld, but these standards do not seem
>> to be applied consistently. For example, crossdev, genkernel, and the
>> bootstrap-prefix and bootstrap-rap scripts are more or less
>> unmaintainable disasters.
>> [...]
>> and the bootstrap scripts are poorly explained with no extant
>> documentation and a workflow that does not clearly fit into Gentoo (or
>> more properly Portage) development at large.
>
> As one of the maintainers of the bootstrap-prefix (and bootstrap-rap), I
> acknowledge that the script is a result of accumulated contributions
> from multiple people, with rounds of refactorizations in the past
> several years. But it is well understood and maintainable.
>
> I would like to remind you that, the script is a reflection of the
> instrinsic complexity to compile a workable Gentoo from zero, in a wild
> variety of environments from handhold embedded devices to top 10
> supercomputers, from GNU/Linux, MacOS to Solaris/OpenIndiana and Cygwin.
>

That is fine, but I am more talking about the burden of trying to
understand what is going on. Nowhere is there a simple list of steps
that the bootstrap scripts take. The code is sparsely commented and
intent is not readily inferred from context. Some of this is related
to the packages in question, and I can not expect the scripts to e.g.
summarize the autotools options passed to the respective software, but
justification for why what is taking place is taking place should have
been a priority.

The typical response of "read the code" (which I have read more than a
few places) indicates to me that someone does not value my time and
has not bothered to remember what they have done, or why. Besides the
insult to future contributors this train of thought reflects poorly on
the quality of the author's work and the esteem with which they hold
the fruits of their labor.

I feel this manifests as the original developers being unlikely to
contribute because they have lost track of the various interacting
components and would need to invest a substantial amount of time in
re-understanding their own work. There are other projects where I have
observed the main authors undertake what appear to be, at first
glance, very technical changes due to an offhand comment by a mailing
list user.

These projects all seem to have been well documented.

> Don't be pissed off if it couldn't be hacked in several hours to be
> ported to ppc64.  That's life: anything worth doing will not be easy.
>

Understanding an existing codebase should not be a technical
challenge. I had to resort to reimplementing all of the steps myself,
in part to understand if they were done properly in the first place.

In the case of the bootstrap scripts, minor problems are very hard to
diagnose because of limited feedback given, and the difficulty of
integrating what feedback is available into the overall setup process.

> For the standards and documentation, yes, the recommended workflow had
> better be carved into stone.  That's where things should be improved.
>

Unfortunately these are things that the original authors should
produce. Experience has shown me that documentation written by
ancillary contributors that do not have deep experience with the code
base is poor.

Respectfully,
 R0b0t1

Re: [gentoo-dev] Re: No more stable keywords for Games

[R0b0t1]

Hello friends!

On Sun, Nov 19, 2017 at 12:45 PM, Philip Webb <purs...@ca.inter.net> wrote:
> 171119 James Le Cuirot wrote:
>> On Sun, 19 Nov 2017 08:50:20 -0500
>> Philip Webb <purs...@ca.inter.net> wrote:
>>> 171118 David Seifert wrote:
>>>> As the Games team does not have enough manpower to keep tabs on all
>>>> games packages, we have dropped all games-* ebuilds to unstable
>>>> keywords (modulo those required by stable non-games packages).
>>> Isn't this overkill in the absence of widespread bug reports for games ?
>>> 'Stable' doesn't mean well-maintained,
>>> but in the tree for some time & no serious bug reports.
>> There are plenty of bug reports for games.
>
> What percentage of games pkgs have bugs ?

I too would like some clarification on the standards being used.

> Marking all games 'unstable' still seems to be overkill.
>

To add to this, it is unlikely the situation will improve until it is
made easier for people to contribute. If one is not aware there is a
tendency for Gentoo-related issues to receive blog posts addressing
them, or to be passed down via word of mouth on IRC, or to be hidden
in a hard-to-find (and/or index) page of the Wiki.

The most likely explanation for this state of affairs is that getting
contributions accepted into the main tree is too hard.

It is one thing to say that contributions to the main Portage tree
require some standards to be upheld, but these standards do not seem
to be applied consistently. For example, crossdev, genkernel, and the
bootstrap-prefix and bootstrap-rap scripts are more or less
unmaintainable disasters. Crossdev in particular oscillates between
periods of relative stability and extreme brokenness, and the
bootstrap scripts are poorly explained with no extant documentation
and a workflow that does not clearly fit into Gentoo (or more properly
Portage) development at large. Other ebuilds may simply install low
quality software, or install software that is hard to manage with
Portage.

Respectfully,
 R0b0t1

Re: [gentoo-dev] Java 9 on Gentoo

[R0b0t1]

Hello again friends,

On Fri, Nov 17, 2017 at 11:30 AM, William L. Thomson Jr.
<wlt...@o-sinc.com> wrote:
> Every bit contains useful technical information. Maybe make some effort
> to package or help JDK on Gentoo vs a pointless comment.
>

Thank you for the information. I hope it didn't seem like I was asking
you to hurry up and package OpenJDK or IcedTea. I apologize for not
being able to address some of the information you gave immediately, as
it is a lot of information.

If anyone is at fault, it is myself, for asking questions that
necessitated many answers. For this I apologize to the list. Please do
not ban me, friends. I am not very smart, and using my computer is
hard without help.

Respectfully,
 R0b0t1

Re: [gentoo-dev] Java 9 on Gentoo

[R0b0t1]

On Fri, Nov 17, 2017 at 12:30 AM, William L. Thomson Jr.
<wlt...@o-sinc.com> wrote:
> On Thu, 16 Nov 2017 23:38:09 -0600
> R0b0t1 <r03...@gmail.com> wrote:
>>
>> Hopefully this is not a tangent, but the OpenJDK release is available
>> on Ubuntu. I have tried to understand the IcedTea build process and
>> failed, as I was hoping that it could be packaged for Gentoo before
>> the official IcedTea release. I was not able to find a timeline from
>> the OpenJDK project.
>
> Gentoo is a from source distro not binary. It will be some time before
> icedtea, some version support slot 9 will be available. There is no eta
> for icedtea. That comes from directly from RedHat. The person who
> makes it for the world does so on Gentoo, for RedHat their employer.
>

I am confused. I was aware that IcedTea was a build system, but I am
not aware as to how Ubuntu packaged OpenJDK 9.

In the context of Gentoo I meant "packaged" as in "created an ebuild
for," which is not proper language.

> I tried for years to get others to make a path for them to be able to
> become a dev and work in tree. Rather that work goes into java-overlay
> and is proxied to tree by Chewi/James.
> https://github.com/gentoo/java-overlay/tree/master/dev-java/icedtea
>

Though I am not a developer, this concerns me in other areas too. Many
developers do not produce extremely high quality code, but this
concern is cited as exactly the reason for keeping developership
exclusive. Projects I feel I should mention include genkernel and
crossdev. I had to temporarily give up my personal interests that
relied on them and have since begun rewriting them. In the small bit I
have done understanding crossdev, it has become apparent to me that
the authors did not reference the GCC build system documentation very
well. Of course, it may be the case that no one refers to it.

>> You focus on Oracle's Java?
>
> Yes, in brief, as the other will always lag. I would be some what
> interested in a actual OpenJDK package. That could build with either
> oracle or icedtea. Usually for production and business purposes people
> want to run Oracle. I do not know many who run icedtea/openjdk. Though
> I am sure they are out there. Definitely RedHat customers.
>

I expect the releases to lag, which is why I had been using Oracle's
JDK. Can you explain why there is an IcedTea ebuild but not an OpenJDK
ebuild?

> Also icedtea on Gentoo does not have OpenJavaFX. I am not
> sure any distro has OpenJavaFX packaged. I am not aware of any ebuilds
> ever for that. Probably be me someday if I ever have interest. Which
> can bind many to oracle for JavaFX. Which includes myself.
>

OpenJDK now contains an implementation of JavaFX. Debian and Ubuntu
have it packaged. For general instructions, see the following:

http://openjdk.java.net/projects/openjfx/
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX

Packages:

https://tracker.debian.org/pkg/openjfx
https://packages.ubuntu.com/xenial/openjfx

I have recently been interested in JavaFX. It is far more user
friendly. Many open source applications still target Swing however, to
be compatible with old OpenJDK releases.

> Icedtea really is not a jdk but a build system. On Gentoo only it
> becomes the name of the JDK/JRE. It really is just OpenJDK built
> without Oracle. Ideally there is oracle, openjdk, and icedtea ebuilds.
> You then build openjdk with oracle or icedtea via USE flag.
>
> Icedtea will always lag from Oracle. There will always be oracle
> binaries before others. Yes you can build the source against it, but no
> one is working on that. Again Gentoo has what it does because of
> RedHat. Really for RedHats own interest, not Gentoo. Gentoo just
> benefits.
>
> It would likely be a considerable effort to have a openjdk that can
> build via oracle or icedtea/openjdk binaries. I think exherbo managed
> that, I am not sure.
>

My response to this is the same as above: Can you explain why the
Gentoo build system is the way it is? If you have any suggestions as
to what I should look at to better understand the OpenJDK build system
I would very much appreciate them.

> The lagging may get worse as JDK release is scheduled to speed up
> considerably come March. Say hello to Java 18.3
> https://mreinhold.org/blog/forward-faster
>
>> The Oracle binaries seem to work well for me and I have experienced no
>> issues. Notably, Scala works transparently on the Oracle JDK 9. What
>> kind of issues are you seeing? The biggest issue I have had is that
>> some version tests do not parse "9" the same way as "1.8.0_152".
>
> There are tons of build issues for Java packages in tree. From not
> supporting < 1.6 source/target, The whole modules system. Changes with
> c

Re: [gentoo-dev] Java 9 on Gentoo

[R0b0t1]

Hello friends!

I am excited about Java 9. However, I am a very excitable person.

Hopefully this is not a tangent, but the OpenJDK release is available
on Ubuntu. I have tried to understand the IcedTea build process and
failed, as I was hoping that it could be packaged for Gentoo before
the official IcedTea release. I was not able to find a timeline from
the OpenJDK project.

On Thu, Nov 16, 2017 at 10:41 PM, William L. Thomson Jr.
<wlt...@o-sinc.com> wrote:
> On Thu, 16 Nov 2017 21:42:59 -0600
> Matthew Thode <prometheanf...@gentoo.org> wrote:
>>
>> You seem to know a bit about this, has there been a bug made outlining
>> the troubles we will encounter as you know them?
>
> No, I feel I am already doing more than I should to help given my past
> treatment. I have been making most issues with potential resolutions
> know in #gentoo-java for the past ~48 hours. I have been spending
> most time fixing stuff in my overlay. As I have been for over a year.
> https://github.com/Obsidian-StudiosInc/os-xtoo
>

You focus on Oracle's Java?

>>  It's nice to have a warning, but sounding alarmist without concrete
>> help doesn't actually help all that much.
>
> People have been asking in #gentoo-java about Java 9. I was simply
> letting everyone know it would be some time before that is likely to be
> the case. That alone was a courtesy to others.
>
> It does not take much to find out there are considerable issues with
> Java 9 from most any web search. For anyone who cares, most do not.
> Thus the present state of Java on Gentoo. Which I have brought up many
> times over the past years. A new major version taking some time should
> not be of surprise to anyone given that fact.
>

The Oracle binaries seem to work well for me and I have experienced no
issues. Notably, Scala works transparently on the Oracle JDK 9. What
kind of issues are you seeing? The biggest issue I have had is that
some version tests do not parse "9" the same way as "1.8.0_152".

Adding Java 9 to the tree would help users who are interested
experiment with the language. As part of the first work on Python 3.5
(very minor) I installed it on my system but did not add it to
PYTHON_TARGETS. Is there an equivalent for Java?

> If you recall I got banned from Github over commenting on Java 9 early
> access PR. I have also commented on another since.
> https://github.com/gentoo/gentoo/pull/1721
> https://github.com/gentoo/gentoo/pull/6033
>
> You can see the history of jdk 9 I put in my overlay almost a year ago.
> That could have been in Gentoo. I maintained EA builds till release...
> Dec 5, 2016
> https://github.com/Obsidian-StudiosInc/os-xtoo/commit/f90d8b21c39dbe8684e0951b845c43fae2ba6cfc#diff-0ecef02a46ed32d29b482614d71d229f
> https://github.com/Obsidian-StudiosInc/os-xtoo/commits/master/dev-java/oracle-jdk-bin
>

That looks promising, thank you.

> I have done all I can. This is the visible result of blocking people,
> with no one else wiling to do the work. I am playing catch up now.
>

I have read the bug discussing your retirement. It is not possible for
me to ascertain what led to disciplinary action. The lack of concrete
discussion on behavior to be addressed reflects poorly on those who
sought disciplinary action.

However, I am not a very smart man. I am usually wrong. Hopefully
someone who is much more intelligent than I can explain how I have
erred in my opinion.

Respectfully,
 R0b0t1.

Re: [gentoo-dev] manifest-hashes changing to 'BLAKE2B SHA512' on 2017-11-21

[R0b0t1]

On Wednesday, November 15, 2017, Michał Górny <mgo...@gentoo.org> wrote:
> Hi, everyone.
>
> The Council has approved the manifest-hashes switch on 2017-11-12
> meeting [1]. The transition will occur to the initial plan, with small
> changes. The updated plan is included at the end of this mail.
>
> According to this plan, BLAKE2B will be enabled on 2017-11-21. This
> means that starting at this time, all new and updated DIST entries will
> use BLAKE2B+SHA512. Old DIST entries will still use the current hash set
> until updated.
>
> The developers are required to upgrade to a package manager supporting
> this hash. That is:
>
> a. Portage 2.3.5 when using py3.6+,
>
> b. Portage 2.3.13 + pyblake2 installed manually,
>
> c. Portage 2.3.13-r1 that includes the pyblake2 dep.
>
> Modern (and old) Portage will refuse to update Manifests if it does not
> support the necessary hashes. However, Portage versions between 2.3.5
> and 2.3.13 inclusively will create Manifests missing BLAKE2B hash rather
> than failing when no hash provider is present. Those Manifests will be
> rejected by the git hook.
>
> Users will not be affected noticeably as the SHA512 hash continues being
> used for compatibility.
>
>
> That said, I'd like to request developers not to start proactively
> converting all old Manifest entries to the new set immediately,
> and instead give some time for things to settle down.
>
>
>
> The updated plan
> 
>
> Already done:
>
> - revbumped Portage with pyblake2 dep and started stabilizing it,
>
> - added git update hook to reject invalid Manifest entries.
>
> 2017-11-21 (T+7d):
>
> - manifest-hashes = BLAKE2B SHA512
>
> 2018-02-14 (T+3m):
>
> - manifest-required-hashes = BLAKE2B
>
> 2018-05-14 (T+6m):
>
> - last rite fetch-restricted packages that do not use BLAKE2B.
>
> The final removal of SHA512 will be decided by the Council separately.
>

Does the existence of a decision mean I would need to contact the trustees
if I feel the changes have not been adequately justified?

Respectfully,
R0b0t1

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

[R0b0t1]

Hello,

On Wednesday, November 8, 2017, Jonas Stein <jst...@gentoo.org> wrote:
> Hi "R0b0t1",
>
>>>> For the record, I'd claim I am.
>
> The question
>> On what basis?
> is ok, but
>
>> I performed a search on your name, and found at least
>> one person who was belligerently calling you a liar [..]
>
> does not fit here. Please keep this dirt away from our mailinglist and
> stay professional.
>

Actions have consequences. I may not have found the same Mr. Bock, in which
case he can certainly say something to that effect. Otherwise I see no
reason why his actions off-list related to security are not precisely what
should be discussed.

He is the one who failed to provide any support for his statement. I
researched him myself and that is the first thing I found. I did not
immediately link it as I felt it may be unsuitable for the list.

Respectfully,
R0b0t1

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

[R0b0t1]

My apologies, I forgot to address something:

On Sat, Oct 21, 2017 at 12:50 PM, Hanno Böck <ha...@gentoo.org> wrote:
> On Sat, 21 Oct 2017 12:12:44 -0500
> R0b0t1 <r03...@gmail.com> wrote:
>
>> That is precisely why I didn't suggest it be used on its own (see note
>> about extant use of MD5), and why I gave alternatives. If it is
>> desired that the hashes be computed quickly then weaker hashes will
>> need to be used. One usually can't have both security and speed.
>
> You can have that. Blake2 is faster than any broken legacy hash.
> And ripemd isn't particularly fast
>

Fair enough, but it is new and may have security problems related to
its operation that have not been found. This is hard to reason about,
but I would note that many cryptographic standards are fairly
conservative for similar reasons.

Ease of computation reduces security.

Respectfully,
 R0b0t1

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

[R0b0t1]

On Sat, Oct 21, 2017 at 3:11 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Hanno Böck posted on Sat, 21 Oct 2017 19:50:11 +0200 as excerpted:
>
>> On Sat, 21 Oct 2017 12:12:44 -0500 R0b0t1 <r03...@gmail.com> wrote:
>>
>>> People are discussing collision resistance, but no one here appears to
>>> be trained in cryptography.
>>
>> For the record, I'd claim I am.

On what basis? I performed a search on your name, and found at least
one person who was belligerently calling you a liar who wastes
people's time. The others results seemed to have no relation to
cryptography and were about technology journalism.

>
> ... And with a number of vuln discoveries to your credit, it's safe to
> say it's not just paper certs for you, too. =:^)
>

Of what nature are these vulnerabilities? There is a vast gulf between
discussing cryptography with a mathematical basis and finding code
which improperly implements cryptography. Or, as it seems based on my
searches, simply finding bugs or logical errors in programs.

> (And FWIW I'd point to Robin H Johnson/robbat2 as someone I know has
> authority in this area as well.  There may be others.  FTR I'm not one of
> them, tho as any good admin I try to follow the security news especially
> where it touches machines I administer, so I'm following this thread with
> particular interest.)
>

On what basis? As above, programming and cryptography have very little
in common, besides the fact computers can be programmed to perform
cryptography operations.


These posts are concerning because it looks like someone became stir
crazy and invented a problem to solve. The changes proposed to date
have remained poorly justified, and no one has addressed the concern
that multiple hashes *is* actually more secure.

If it was deemed necessary at one point, what justification was used?
I.e. https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence.

Respectfully,
 R0b0t1

Re: [gentoo-dev] Manifest2 hashes, take n+1-th: one hash to decide them all

[R0b0t1]

On Tue, Oct 24, 2017 at 9:40 PM, Robin H. Johnson <robb...@gentoo.org> wrote:
> On Tue, Oct 24, 2017 at 11:33:39PM +0200, Allan Wegan wrote:
>> >> That is currently the case with portage, but not an inevitable
>> >> consequence of having 3 hash functions in the Manifest. Portage could
>> >> be made to check only one or two of them (even by default), giving
>> >> the tie-breaking ability to those who need it, and speeding up things
>> >> for those who don't.
>> > No, it can't. The specification (GLEP 59) requires it to check all
>> > hashes.
>>
>> Of course it can: The code of the specification just has to be changed
>> before changing the code of portage. The question is not whether it is
>> possible to make portage skip hash verification - but whether it is a
>> good idea to make it do that...
>>
>> I would not mind as long as the default is to always check all the
>> hashes and the option to disable it is properly named (like
>> "--disable-hash-verification" or something similar) and documented.
> At that point, and this is a serious proposal:
> The package manager shall decide which hashes to check, but is required
> to check at least one hash. The choice may be 'fastest', 'most secure',
> or any local factor.
>
> For local values of 'most secure' or 'fastest'.
>
> I wrote GLEP59, and specified at the time that all hashes should be
> checked, based on prior experience with hash implementation problems.
>
> Skipping them entirely is a bad idea, but only checking one of them is a
> reasonable suggestion.
>

The talk on gentoo-dev related to the security of hash functions still
has me confused as to why anyone would want to remove the
alternatives. Arguably this gives the setup most of its security.

I acknowledge Mr. Böck's observation that most programs only use one
hash. When I first encountered portage, I thought the use of multiple
hashes was a very novel and security conscious design choice. The cost
is negligible compared to the difficulty it adds to generating a
collision.

Of course, the difficulty of generating a collision that results in
usable code is still very high, but there was an interesting paper
that described how it could be easier than most people think. I am not
sure how to find it again. It was based on the principle that the
solution space for collisions that were valid was actually far denser
than the solution space of all collisions. One of the results of this
is that finding usefully malicious collisions is probably easier than
finding a collision in general, although there may be more non-useful
collisions overall.

> I retract my prior suggestion that there should be 3 hashes, as I
> realize a key statements in GLEP59 that were NEVER implemented:
>>> - Removal of depreciated checksums shall happen after no less than 18
>>>   months or one major Portage version cycle, whichever is greater.
>>> ...
>>> After the majority of Portage installations include SHA512 support:
>>> - Remove SHA256.
>
> This GLEP to update the GLEP59 specification should state the following:
> - The package manager or verification tool is required to verify at
>   least one hash, preferably the strongest supported hash.
> - Multiple hashes may be present for transitional periods.
> - SHA3 or BLAKE2B shall be added to the official Manifest2 hashes.
>


I'm still kind of confused as to why these changes are being made. Can
they be justified?

> For implementation:
> - Generation of WHIRLPOOL and SHA256 shall be disabled in the next
>   Portage minor release (as soon as possible)
> - Generation of the next choice of hash, SHA3 or BLAKE2B shall be
>   enabled in an upcoming minor Portage release (soon)
> - 18 months after the next GLEP is approved, SHA512 shall be dropped
>   (put the date into the Portage code so it happens automatically this
>   time, unlike SHA256 that should have been removed in 2010!).
>

This makes sense, but I would hope deprecation can be justified in a useful way.

Cheers,
 R0b0t1

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

[R0b0t1]

On Sat, Oct 21, 2017 at 12:12 PM, R0b0t1 <r03...@gmail.com> wrote:
> On Sat, Oct 21, 2017 at 11:26 AM, Robin H. Johnson <robb...@gentoo.org> wrote:
>> On Fri, Oct 20, 2017 at 05:21:47PM -0500, R0b0t1 wrote:
>>> I would like to present my suggestions:
>>>
>>> SHA512, (RIPEMD160 | WHIRLPOOL | BLAKE2B), (SHA3_512 | BLAKE2B);
>>>
>>> or more definitively:
>>>
>>> SHA512, RIPEMD160, BLAKE2B.
>> Please do NOT reintroduce RIPEMD160. It was one of the older Portage
>> hashes prior to implementation of GLEP059, and was removed because it
>> was shown to fall to parts of the same attacks at MD4/MD5 by Wang's
>> paper in 2004.
>>
>> Wang, X. et al. (2004). "Collisions for Hash Functions MD4, MD5,
>> HAVAL-128 and RIPEMD", rump session, CRYPTO 2004, Cryptology ePrint
>> Archive, Report 2004/199, first version (August 16, 2004), second
>> version (August 17, 2004). Available online from:
>> http://eprint.iacr.org/2004/199.pdf
>>
>

Also important is that the existence of a constructed collision is not
necessarily an indication that the function is weak for real data.


> Can anyone defend the transition to two hashes, or is it just based on
> speculation?
>

This thread in particular is the worst case of bikeshedding I have
seen on gentoo-dev. No one here is well equipped to evaluate the
cryptographic primitives being discussed[1] but there are still many
strong opinions and unwarranted suggestions.

Respectfully,
 R0b0t1


[1]: In fairness perhaps no one is, as the cryptography of one
particular function takes very intensive study. Most published
algorithms are never studied intently until they are adopted. Still,
people should be justifying any suggestion by referencing real data or
tested deficiencies. Not guessing.

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

[R0b0t1]

On Sat, Oct 21, 2017 at 11:26 AM, Robin H. Johnson <robb...@gentoo.org> wrote:
> On Fri, Oct 20, 2017 at 05:21:47PM -0500, R0b0t1 wrote:
>> I would like to present my suggestions:
>>
>> SHA512, (RIPEMD160 | WHIRLPOOL | BLAKE2B), (SHA3_512 | BLAKE2B);
>>
>> or more definitively:
>>
>> SHA512, RIPEMD160, BLAKE2B.
> Please do NOT reintroduce RIPEMD160. It was one of the older Portage
> hashes prior to implementation of GLEP059, and was removed because it
> was shown to fall to parts of the same attacks at MD4/MD5 by Wang's
> paper in 2004.
>
> Wang, X. et al. (2004). "Collisions for Hash Functions MD4, MD5,
> HAVAL-128 and RIPEMD", rump session, CRYPTO 2004, Cryptology ePrint
> Archive, Report 2004/199, first version (August 16, 2004), second
> version (August 17, 2004). Available online from:
> http://eprint.iacr.org/2004/199.pdf
>

That is precisely why I didn't suggest it be used on its own (see note
about extant use of MD5), and why I gave alternatives. If it is
desired that the hashes be computed quickly then weaker hashes will
need to be used. One usually can't have both security and speed.

Can anyone defend the transition to two hashes, or is it just based on
speculation?

People are discussing collision resistance, but no one here appears to
be trained in cryptography. The only reasonable solution in that case
is not to rely on the particular mostly unknowable merits of an
algorithm, but the hardness of a successful collision of multiple
functions at the same time.

*If* collision resistance is important, and *if* no one here can
evaluate any of the algorithms intensively by themselves, then *why*
are two hashes going to be used instead of three? That is making the
system much weaker than it was.

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

[R0b0t1]

On Fri, Oct 20, 2017 at 8:04 AM, Kristian Fiskerstrand <k...@gentoo.org> wrote:
> On 10/20/2017 11:10 AM, Dirkjan Ochtman wrote:
>>
>> I support Hanno's suggestion of doing just SHA512, but would be
>> interested in hearing opinions from others who have apparent
>> security/crypto experience. Maybe the Security project can weigh the
>> suggestions as well?
>>
>
> The whole discussion is moot so long as we don't have OpenPGP signed
> gentoo repository in rsync.
>
> SHA2-512 is generally quicker than sha256 on 64 bit architectures, but
> considerably slower for some architectures. Introducing a non-optimized
> keccak on top of it will have a significant negative performance impact
> for these arches without much security gain.
>
> if we still want two separate hashes, the choice of sha2 and sha3
> compination is a good one given they are based on separate constructs.
>
> But IMHO we should start where things matter and complete an
> implementation for OpenPGP signatures of MetaManifests in Portage.
>

This is why I use webrsync-gpg. Git commits are supposed to be
GPG-signed, so that may be suitable for your purposes.

Cheers,
 R0b0t1.

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

[R0b0t1]

Hello,

I missed some messages in the time I wrote my reply. This also touches
on some of the points in Mr. Górny's other message about time.

On Fri, Oct 20, 2017 at 6:38 PM, Michał Górny <mgo...@gentoo.org> wrote:
> W dniu pią, 20.10.2017 o godzinie 00∶20 +0200, użytkownik Francesco
> Riosa napisał:
>> 2017-10-19 23:00 GMT+02:00 Michał Górny <mgo...@gentoo.org>:
>>
>> > W dniu czw, 19.10.2017 o godzinie 21∶08 +0200, użytkownik Michał Górny
>> > napisał:
>> > >
>> > > 4. The new hashes that are stronger and commonly available are
>> > > SHA3/Keccak (using sponges) and BLAKE2 (HAIFA). Both are diverse from
>> > > our current algorithms, so either is a good candidate. The choice of
>> > > Keccak is purely arbitrary (because it's the winner?).
>> > >
>> >
>> > Actually, a small correction here: we support more implementations
>> > of SHA3 than BLAKE2, so the first one is less problematic for us.
>> >
>>
>> Not researched in depth but:
>> B2sum provided by coreutils is quite satisfacting*, it's pretty fast, while
>> sha-3 is deemed to be slower than sha-2, maybe this could be weighted while
>> choosing the algorithm wanted.
>>
>> Both seem to take advantage of modern multicore CPUs but sha-3 does 11.7
>> [cpb]#0 (see #1) while an email seen on the internet say blake2 can reach 1
>> [cpb] (see #2)
>>
>> #0 cpb = cpu cycles per byte
>> #1 https://en.wikipedia.org/wiki/SHA-3#Speed
>> #2 http://www.metzdowd.com/pipermail/cryptography/2016-May/029297.html
>> * (in my limited experience)
>
> I've taken a closer look at BLAKE2 possibilities, and it seems that it's
> going to be our choice after all. I'm adding dev-python/pyblake2
> as a fallback implementation now.
>
> Curious enough, after disabling the 'optimized' SSE2 assembly, the plain
> register implementation is 2.5 times faster than the SSE2 implementation
> that is used by default, and two times faster than the built-in SHA2
> implementation in Python.
>

It is likely that the register implementation makes better use of the
data and instruction cache and processor instruction pipeline. For a
similar reason, functions with larger block sizes tend to run more
slowly over the same amount of data than their counterparts with
smaller block sizes.

If speed truly is crucial then it may be a better idea to use one very
strong hash function and two weaker but faster hash functions. This is
why I recommended RIPEMD160. If BLAKE2B is used, it may be possible to
switch SHA512 for SHA256.

It seems important to me to use three hash functions.

Again, though, I think it needs to be pointed out that on slower
machines the hash time is on the order of tens of seconds. This should
be negligible compared to the build time.

Cheers,
 R0b0t1

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

[R0b0t1]

Hello,

On Thu, Oct 19, 2017 at 2:08 PM, Michał Górny <mgo...@gentoo.org> wrote:
> Hi, everyone.
>
> The previous discussion on Manifest2 hashes pretty much died away
> pending fixes to Portage. Since Portage was fixed a while ago, and we
> can now safely switch, I'd like to reboot the discussion before
> submitting the item for the next Council meeting.
>
> Considering all arguments made so far, I'd like to propose changing:
>
>   manifest-hashes = SHA256 SHA512 WHIRLPOOL
>
> to:
>
>   manifest-hashes = SHA512 SHA3_512
>
> In other words, removing SHA256 and WHIRLPOOL, and adding SHA3_512.
>

In general I do not mind updating the algorithms used, but I do feel
it is important to keep at least three present. Without at least three
(or a larger odd number) it is not possible to break a tie.

That may ultimately be beside the point, as any invalid hashes should
result in the user contacting the developers or doing something else,
but it is hard to know.

>
> Rationale
> -
>
> 1. The main argument for using multiple hashes is to prevent the (very
> unlikely) possibility that if a weakness is discovered in one of
> the hashes, the other would still hold. This is given by using two
> algorithms; more than two do not increase security significantly, while
> they do increase performance cost.
>
> 2. For the above to hold, the hashes should be diverse. SHA256
> and SHA512 are the same algorithm, so a weakness discovered in either
> would probably apply to both -- keeping both does not make sense at all.
> Furthermore, both SHA2 and WHIRLPOOL use the same construct (MD), so
> a weakness in the construct would apply to both.
>

Algorithms of different block sizes can easily have different
cryptographic properties.

Notable is https://en.wikipedia.org/wiki/Advanced_Encryption_Standard,
see box. More relevant is https://en.wikipedia.org/wiki/SHA-2.

In general only the computational complexity is affected, but in the
case of AES some attacks work for the larger key lengths that do not
work for smaller ones. There is one other case I am having problems
remembering where a longer keylength led to a massively easier to
attack function.

For SHA3_512, I am worried that some of the novel properties of the
function that do not currently lead to attacks may in the future lead
to attacks.

> 3. Keeping one of the three old hashes is necessary for compatibility
> reasons. Furthermore, the current versions of Portage consider SHA512
> obligatory, so we can't remove it without redesigning Portage first
> (though I think this applies only to developer installs, i.e. those
> creating Manifests).
>
> 4. The new hashes that are stronger and commonly available are
> SHA3/Keccak (using sponges) and BLAKE2 (HAIFA). Both are diverse from
> our current algorithms, so either is a good candidate. The choice of
> Keccak is purely arbitrary (because it's the winner?).
>
> All the above considered, I think it's most reasonable to use two hashes
> with diverse constructs. SHA512 needs to be one of them, for
> compatibility reasons. The other could be either SHA3_512 or BLAKE2B,
> as a strong, future-proof hash. SHA3 is probably a better choice because
> it's going to have more support as the official recommendation.
>

I would like to present my suggestions:

SHA512, (RIPEMD160 | WHIRLPOOL | BLAKE2B), (SHA3_512 | BLAKE2B);

or more definitively:

SHA512, RIPEMD160, BLAKE2B.

My understanding is that whirlpool is the least secure of the 512 bit
hashes, but it would still be a serious undertaking to generate a
collision. If there is any cause to replace it RIPEMD160 is likely a
good candidate. It is similar in operation to the SHA1/2 functions but
was produced by the academic community and is quite dissimilar from
the SHA1/2 family. The "definitive" suggestions provide a wide sample
of time, size, and implementation.

SHA3_512 is novel and may be resistant to attack in ways the others
are not, but it is my opinion that BLAKE2B's author is better known
and respected.

I could also see the combination SHA512, BLAKE2B, SHA3_512 being
desirable, as that selection represents 3 very diverse algorithms.

If the suggestion of RIPEMD160 seems odd, realize that some
distribution platforms still use MD5 along with other functions. It is
fast to compute and with another hash function quite credible. If the
time taken to generate the hashes is a legitimate concern then using a
older, simpler, and heavily optimized function may be better for one
of the choices.

Respectfully,
 R0b0t1

Re: [gentoo-dev] Reviving the Sandbox project

[R0b0t1]

On Fri, Sep 22, 2017 at 5:01 PM, Michael Orlitzky <m...@gentoo.org> wrote:
> On 09/22/2017 05:51 PM, R0b0t1 wrote:
>> On Thu, Sep 21, 2017 at 2:56 PM, Michał Górny <mgo...@gentoo.org> wrote:
>>> [1]:https://wiki.gentoo.org/wiki/Project:Sandbox
>>>
>>
>> I think I understand, in principle, why a sandbox could be useful, but
>> would it not be more productive to follow up with projects which do
>> unexpected things to ask that they not do those things?
>>
>
> The sandbox isn't a security feature, it's more of a QA tool. How do you
> *know* when the upstream project does something wrong? See, for example,
>

I was aware of this part. I suggested sandboxing mechanisms which were
security related not for security purposes, but due to the fact that
their original design goals makes them more comprehensive. As a bonus,
they already exist.


On Fri, Sep 22, 2017 at 5:05 PM, Alec Warner <anta...@gentoo.org> wrote:
>
>
> On Fri, Sep 22, 2017 at 5:51 PM, R0b0t1 <r03...@gmail.com> wrote:
>>
>> On Thu, Sep 21, 2017 at 2:56 PM, Michał Górny <mgo...@gentoo.org> wrote:
>> > [1]:https://wiki.gentoo.org/wiki/Project:Sandbox
>> >
>>
>> I think I understand, in principle, why a sandbox could be useful, but
>> would it not be more productive to follow up with projects which do
>> unexpected things to ask that they not do those things?
>
>
> So step one is figuring out what those things are. So the LD_PRELOAD sandbox
> isn't designed to be a "security boundary" (its trivially defeat-able[1]).
> Instead its designed to be a fairly straightforward detector of 'anomalous'
> behavior. It works by intercepting file-operations and comparing them
> against a whitelist.
>
> You can't tell people do stop doing unexpected things if you don't know
> their software is doing unexpected things.
>

Right, I suppose a sandboxing mechanism is the best way to detect
those changes. Is it necessary for it to be implemented with something
like ptrace or ld tricks? Like above, I ask because other mechanisms
are more comprehensive.

The mechanism used to implement containers, in particular, is
extremely interesting because it does (more or less) exactly what is
wanted. Look for the CLONE_NEW* options in `man 2 clone`. It is
possible containers are the best interface to this syscall, but I am
not sure how to evaluate them in the context they would be used.

Respectfully,
 R0b0t1

Re: [gentoo-dev] Reviving the Sandbox project

[R0b0t1]

On Thu, Sep 21, 2017 at 2:56 PM, Michał Górny <mgo...@gentoo.org> wrote:
> [1]:https://wiki.gentoo.org/wiki/Project:Sandbox
>

I think I understand, in principle, why a sandbox could be useful, but
would it not be more productive to follow up with projects which do
unexpected things to ask that they not do those things?

In the sense that Portage can in its entirely be isolated in various
ways (user groups, containers, virtual machines, etc) I am not sure
adding another layer is the most expedient option, especially if it is
hard to maintain.

I once saw Java developers talking about introducing changes to an
enterprise program by not modifying the source, but keeping the source
as is, and then maintaining a set of reflection-based patches that
would modify the program after it was loaded but before it was run.
This did not make sense to me, and it seems a lot like what is being
done with the sandbox.

In some cases that can make sense, I suppose. I am not a very smart
man, so I would not know the necessary burden of proof.

Respectfully,
 R0b0t1

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

[R0b0t1]

Hello,

On Tue, Sep 12, 2017 at 9:04 AM, Michał Górny <mgo...@gentoo.org> wrote:
> W dniu pon, 11.09.2017 o godzinie 21∶59 -0500, użytkownik R0b0t1
> napisał:
>> Hello friends,
>>
>> On Mon, Sep 11, 2017 at 3:56 PM, Michał Górny <mgo...@gentoo.org> wrote:
>> > W dniu pon, 11.09.2017 o godzinie 13∶29 -0400, użytkownik Michael
>> > Orlitzky napisał:
>> > > On 09/11/2017 01:08 PM, Michał Górny wrote:
>> > > > Hi,
>> > > >
>> > > > TL;DR: I'd like to reinstate the old-school GLEPs in .rst files rather
>> > > > than Wiki, put in a nice git repo.
>> > > >
>> > >
>> > > I generally agree with you that wiki markup is terrible and that a text
>> > > editor and a git repo is The Right Way to do things (with Jekyll or
>> > > whatever to push it to the web). But in my experience, crappy and easy
>> > > is a better way to get people to contribute. When I've taken wiki
>> > > documents and moved them into git repos, more often than not I become
>> > > the sole contributor, and otherwise-technical people just start emailing
>> > > me their contributions (which decrease greatly in frequency).
>> >
>> > [...]
>> >
>> > Then, you can just take www.gentoo.org and run it locally. It takes
>> > a little more effort but jekyll is really trivial to set up and run
>> > locally. Then you see it exactly how it's gonna look on g.o.
>> >
>
> I'm going to reply to the Gollum topic here since it's the first mail
> according to date.
>

There is a thread in gentoo-dev where I proposed the Handbook be
maintained with Gollum. I apologize if it was not visible, but I was
trying to not make a nuisance of myself.

>> I previously suggested Gollum and think I should suggest it again.
>> Gollum provides features relevant to a Wiki setting including web
>> editing.
>
> Firstly, a generic request to everyone. If you want to suggest that we
> are supposed to use your-favorite-tool instead of the one we have
> deployed for a few years now, then please include:
>

I believe I addressed all of these. Please make suggestions on my
writing so I can make it more readable if you have the time.

If I suggest a project I think it reasonable to expect you to refer to
that project's README. Here is a link:
https://github.com/gollum/gollum/blob/master/README.md.

> 1. A short summary including:
>
> 1a. How it fits into the desired workflow. Topics such as access control
> and caching are of particular interest to me.
>

It manages a Wiki using a Git repository. Access control is managed
through the Git repository and has Git's limitations. When using
Gollum it seems like access control is best done by creating
repositories. The web editor seems to lack authentication.

Gollum may have issues with caching[1]. Gollum is deployed by GitHub,
but most GitHub project Wikis may be small.

> 1b. What possible future use it could have.
>

It could maintain all public facing documents.

> 1c. How much effort will the future maintenance take.
>

I do not see how it would take more maintenance time than Jekyll. It
may take less as it offers Wiki specific features.

> 2. A publicly available working instance that resembles the workflow
> we're aiming for, or an easy way of setting one up. Easy = ~5 simple
> shell commands, not 'set a webserver up'.
>

The README offers concise instructions for setting up a demonstration
instance and scaling up. Should that be hard to read, a video is
available (https://www.youtube.com/watch?v=EauxgxsLDC4).

> 3. A statement from an Infra member that is willing to set the instance
> up and maintain it.
>

It seems like it is your burden to interpret the suggestion and refer
it to the people who would be maintaining it. If you don't want to
then that is fine.

> Because otherwise we're only going to lose time on theoretical debates
> over software without even knowing if it will work at all, do what it's
> supposed to do, and most importantly, if someone will actually set
> a production instance up and maintain it afterwards.
>

It is not possible for me to know everything you would like addressed
in advance.

Most of the problems Gentoo faces are unique enough that I do not
think it is reasonable to expect a useful solution to exist. There
will always be problems.

> Infra already maintains enough diverse platforms/services/frameworks
> that serve only a single tool selected by one person who used to like
> it, and not maintained anymore. SMW belongs to that group.
>
>>  It would not require pages be rewritten and can render
>> MediaWiki that is maintained in a Git repository.
>
> Secondly, even if Goll

Re: [gentoo-dev] PowerPC Resources at OSU

[R0b0t1]

Hello,

There are multiple replies below.

On Tue, Sep 12, 2017 at 11:43 AM, Matthew Thode
<prometheanf...@gentoo.org> wrote:
> I have access to it (can spin up servers and whatnot), but it doesn't
> sound like that's what you are looking for (needing a non-virtualized
> system).  What specific features are you looking for?
>
> Are you looking for rack space to put a donated IBM system in or what?
> I'm not certian what you are looking for.
>

My apologies, I tried to be comprehensive in my original post but it
may have come out confused. I felt as if I did something bad and was
trying to make sure I told someone right away, like my parents taught
me.

I am looking to verify that my request for shipping reimbursement
could not be made superfluous. It looks like physical access to a
system is necessary to continue doing most of the novel things I am
interested in.

Firstly I want to interact with the system firmware. This may only be
possible with POWER8 systems. With the failure of the TALOS
workstation crowdfunding effort it looks like I will not be able to do
this soon. I intend to see what I can do to reverse engineer the
motherboard firmware on a donated Power6+ system if/when I receive it.
Secondly I wish to instrument PowerKVM and the newer PowerPC
hypervisor functions, specifically related to processor power
management, processor configuration, and memory model. The user mode
SIMD/decimal128 instructions are also extremely interesting. Lastly I
would like to run a Tinderbox targeting ppc64(le) to try to follow up
on some build failures I've been having.

On the systems I have access to at the moment I have been caught up in
prefix/RAP failures while trying to set up a development environment
otherwise I would have started following up on my latter interests.

A shell account on a ppc64le machine running Gentoo would likely be
enough. It would save me a lot of time. Otherwise I can wait until I
receive a donated Power6+ machine, some way or another.

> I'm on irc (as prometheanfire) if you want to talk.
>

I will try to remember that, but unfortunately I have less time to be
on IRC now. Setting up a bouncer is on my list and I will get to it.


On Tue, Sep 12, 2017 at 1:37 PM, Robin H. Johnson <robb...@gentoo.org> wrote:
> Have you seen this page on this wiki?
> https://wiki.gentoo.org/wiki/Project:Infrastructure/Developer_Machines
>
> Did you reach out to anybody there for access?
>

No sir, my apologies for my confusion. I am not very smart and it has
been hard to find information that might aid me in contributing to
Gentoo. Much to my dismay useful information is usually available. I
genuinely do not mean to ask useless questions.


On Tue, Sep 12, 2017 at 3:30 PM, James Le Cuirot <ch...@gentoo.org> wrote:
> As of a few months ago, we have two POWER8 guests, one big endian
> (timberdoodle) and one little endian (bogsucker). We would just have
> one but you can't mix big and little endian on the same system.
>
> After the old POWER7 timberdoodle died, I was responsible for creating
> these new instances with some help from prometheanfire. Replacing
> CentOS systems that had tied up all the storage from the other side of
> the world with no direct raw access was an interesting challenge!
>
> I didn't intend to manage the systems long term though as I only use
> them for building and testing Java stuff. I consider prometheanfire,
> blueness, and vapier to be in charge though you may struggle getting
> hold of the latter two.
>
> We generally only give access to devs but I am aware of one exception
> we made for gnu_andrew, who works for Red Hat and provides our icedtea
> ebuilds. Unfortunately I've only seen you on this list but hopefully
> someone can vouch for you. I don't know whether these guests will be
> suitable for your needs though.
>

I understand. Requesting resources on behalf of Gentoo was a line I
was not willing to cross myself. It seems I misunderstood what
desultory told me to do.

The best I can offer is an explanation for what I wish to do and how
it may end up impacting Gentoo in a positive way. Already my "work"
(attempting to run bootstrap-rap.sh) on GCC112, GCC's ppc64le Linux
system, has led to a number of bugs for the prefix and RAP projects.
If I had use of a Gentoo ppc64le system I would likely be able to
increase the stability of those architectures as I attempt to do
normal things. This is the basis I used to request shipping
reimbursement for a donated POWER6+ server.

The tracker has some bugs I have submitted and others I have commented
on (I would link to them but I haven't figured out how to find all
bugs by me, or all bugs that I have commented on). There are people
who would recognize my name but as I said before, now a line has been
crossed. I do not want to make anyone feel like I am cornering them.


Respectfully,
 R0b0t1

[gentoo-dev] Re: PowerPC Resources at OSU

[R0b0t1]

On Mon, Sep 11, 2017 at 11:29 PM, R0b0t1 <r03...@gmail.com> wrote:
> Hello,
>
> (This will be almost a duplicate on the PPC list, but now having more
> information I am sending it to the BSD list as well.)
>
> I apologize in advance if I did anything improper. I misunderstood
> desultory when I asked him what to do earlier. Originally I was
> unwilling to try to associate myself with Gentoo for the purpose of
> this request but I wasn't referred to anyone who could fill out the
> form "for" me.
>
> Having requested OpenPOWER hosting from OSUOSL on Gentoo's behalf, I
> was informed that hosting is already provided to the project.
> Consequently I have two questions:
>
> 1) May I have access to a/the POWER server, or some other suitable
> POWER resource? If not,
> 2) is anyone available to verify that I am associated with the project
> or that I will use the resources for project related work?
>
>
> For any comment to OSU, such as to request closure of the ticket or
> that they go ahead with allocating the VM, please comment and I will
> forward the support ticket to you.
>
>
> My intent is to experiment with the PowerPC architecture, specifically
> features found on newer POWER processors and servers. It is unlikely I
> will ever get to do this on my own as the machines run $10k-$30k. I
> requested services from OSU because GCC was not able to accommodate my
> request for hypervisor access on their system.
>
> However, having finally found the resources I've been looking for this
> whole time, it looks like OSU's nodes are virtualized and won't be
> able to do exactly what I want anyway (i.e. the GCC sysadmin was
> misinformed), so I may have accidentally wasted people's time and
> potentially tarnished Gentoo's reputation. I will make amends as best
> I can.
>
> IBM is willing to fund a node for my use and OSU is willing to deploy
> it pending contact from Gentoo leadership. If there is a machine that
> already exists that I would not disrupt, I would have no problems
> working on existing resources instead if that seems reasonable. The
> GCC server(s) are probably adequate, however I am having lots of
> problems setting up a prefix on those systems because they use CentOS.
> I am trying to fix bugs as best as I am able but it is starting to
> look hopeless.
>
> Excess resources on the donated OSU OpenPOWER machine could be offered
> to other developers or used to run a Tinderbox. It may be a good idea
> to do those things on the already existing machine(s).
>
> Respectfully,
>  R0b0t1

I am in no great hurry to get things moving and don't mind being told
"no," but at a certain point I feel like I will have to tell OSU that
I couldn't figure out who controls their current donation.

Respectfully,
 R0b0t1

[gentoo-dev] PowerPC Resources at OSU

[R0b0t1]

Hello,

(This will be almost a duplicate on the PPC list, but now having more
information I am sending it to the BSD list as well.)

I apologize in advance if I did anything improper. I misunderstood
desultory when I asked him what to do earlier. Originally I was
unwilling to try to associate myself with Gentoo for the purpose of
this request but I wasn't referred to anyone who could fill out the
form "for" me.

Having requested OpenPOWER hosting from OSUOSL on Gentoo's behalf, I
was informed that hosting is already provided to the project.
Consequently I have two questions:

1) May I have access to a/the POWER server, or some other suitable
POWER resource? If not,
2) is anyone available to verify that I am associated with the project
or that I will use the resources for project related work?


For any comment to OSU, such as to request closure of the ticket or
that they go ahead with allocating the VM, please comment and I will
forward the support ticket to you.


My intent is to experiment with the PowerPC architecture, specifically
features found on newer POWER processors and servers. It is unlikely I
will ever get to do this on my own as the machines run $10k-$30k. I
requested services from OSU because GCC was not able to accommodate my
request for hypervisor access on their system.

However, having finally found the resources I've been looking for this
whole time, it looks like OSU's nodes are virtualized and won't be
able to do exactly what I want anyway (i.e. the GCC sysadmin was
misinformed), so I may have accidentally wasted people's time and
potentially tarnished Gentoo's reputation. I will make amends as best
I can.

IBM is willing to fund a node for my use and OSU is willing to deploy
it pending contact from Gentoo leadership. If there is a machine that
already exists that I would not disrupt, I would have no problems
working on existing resources instead if that seems reasonable. The
GCC server(s) are probably adequate, however I am having lots of
problems setting up a prefix on those systems because they use CentOS.
I am trying to fix bugs as best as I am able but it is starting to
look hopeless.

Excess resources on the donated OSU OpenPOWER machine could be offered
to other developers or used to run a Tinderbox. It may be a good idea
to do those things on the already existing machine(s).

Respectfully,
 R0b0t1

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

[R0b0t1]

Hello friends,

On Mon, Sep 11, 2017 at 3:56 PM, Michał Górny <mgo...@gentoo.org> wrote:
> W dniu pon, 11.09.2017 o godzinie 13∶29 -0400, użytkownik Michael
> Orlitzky napisał:
>> On 09/11/2017 01:08 PM, Michał Górny wrote:
>> > Hi,
>> >
>> > TL;DR: I'd like to reinstate the old-school GLEPs in .rst files rather
>> > than Wiki, put in a nice git repo.
>> >
>>
>> I generally agree with you that wiki markup is terrible and that a text
>> editor and a git repo is The Right Way to do things (with Jekyll or
>> whatever to push it to the web). But in my experience, crappy and easy
>> is a better way to get people to contribute. When I've taken wiki
>> documents and moved them into git repos, more often than not I become
>> the sole contributor, and otherwise-technical people just start emailing
>> me their contributions (which decrease greatly in frequency).
>
> [...]
>
> Then, you can just take www.gentoo.org and run it locally. It takes
> a little more effort but jekyll is really trivial to set up and run
> locally. Then you see it exactly how it's gonna look on g.o.
>

I previously suggested Gollum and think I should suggest it again.
Gollum provides features relevant to a Wiki setting including web
editing. It would not require pages be rewritten and can render
MediaWiki that is maintained in a Git repository. It should be all of
the positives with no negatives.

Please refer to a statement by a project contributor and the original
author: https://github.com/gollum/gollum/issues/712.

Respectfully,
 R0b0t1

Re: [gentoo-dev] Appropriate location to publish experimental stages for Alt

[R0b0t1]

Hello!

On Sun, Sep 10, 2017 at 9:58 PM, Dean Stephens <desult...@gentoo.org> wrote:
> On 09/09/17 12:23, R0b0t1 wrote:
>> On Saturday, September 9, 2017, Johnson Steward <i...@jsteward.moe> wrote:
>>> Hello,
>>> I've been messing with Gentoo FreeBSD these days and, finally, got to the
>> current latest version available. As upgrading is really a tiring process
>> (lots and lots and lots of bootstrapping the tool chain and bunches of
>> blocks in the current stages), I'm thinking of sharing my currently working
>> system as a staged for further testing for those who are interested.
>>> Yet I can't come up with an appropriate location for the stage4 to be
>> hosted. 1.4GB is obviously too large for a pastebin even if
>> bzip2-compressed, and consumer-level cloud storage providers like Google
>> Drive or OneDrive will create unnecessary chaos when trying to actually
>> install the system (virtually impossible to interact with that
>> JavaScript-based system within the FreeBSD livecd), and I don't have an
>> account for Google Cloud Storage or AWS either.
>>> Is there a suitable location to host such a stage? I'm currently not a
>> Gentoo developer, yet I really want my work to benefit the Gentoo FreeBSD
>> community.
>>> Thanks,
>>>
>>> Johnson Steward
>>
>> Contact desult...@gentoo.org.
>>
> While I am willing to help people find suitable avenues for
> contributions to Gentoo; that reply, especially unqualified and coming
> barely half an hour after the initial post was made, rather strongly
> implies that I would be the right point of contact to actually get the
> stages hosted. That is simply not the case.
>

I realize there may be more suitable points of contact. I suppose I
can see now how that might be the case now.

> I would, at best, have directed them similarly to how robbat2 did,
> probably while lacking some of the details which he posted. Further,
> they were already posting on gentoo-dev, so they were inquiring
> somewhere that is virtually assured of reaching suitable persons.
>

I am not really certain as to the purpose of gentoo-dev, so my
apologies. Sometimes developers use it and sometimes they do not.
There have been technical posts which have languished before. I may
have been too quick to reply, as you have said.

> So, please, if you are going to suggest to others that they contact me
> to help them find a suitable point of contact, do not do so on
> gentoo-dev (as they have almost certainly reached suitable persons
> already), and make it explicitly clear that I would only be helping them
> find a suitable point of contact with which to proceed.
>

I did not think to clarify. At worst you would have gotten all of the
information up front and had to refer him to someone else. I can't
imagine he would have minded, but I apologize for taking liberties
with both of your time. I am only trying to help, sir. I apologize for
not being very smart. Some day I hope do accomplish something useful
but it seems a long way off. I pray for that day every day, but I may
have to wait until I go to Heaven.

Respectfully,
 R0b0t1

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

[R0b0t1]

On Sat, Sep 9, 2017 at 3:58 AM, Kent Fredric <ken...@gentoo.org> wrote:
> On Fri, 8 Sep 2017 20:33:49 -0500
> R0b0t1 <r03...@gmail.com> wrote:
>
>> In any case it is my understanding that the issue is that simple. It's
>> the reason torrents and magnet links exist, and why there are no legal
>> claims possible against websites which host magnet links.
>
> The entire court case against PirateBay was based on that.
>
> And the court case was won against PirateBay
>
> https://en.wikipedia.org/wiki/The_Pirate_Bay_trial#Trial_and_courtroom_charges
>
>> The court found that the defendants were all guilty of accessory to
>> crime against copyright law, strengthened by the commercial and
>> organized nature of the activity.
>

This was normal torrents, not magnet links? Was the complaint retried
against someone else who was hosting a magnet link website?

I suspect the links in ebuilds are more like torrent files, in which
case I think it makes sense to wait to be contacted to remove the
links. Otherwise, lots of other precautions should be taken, such as
disclaiming liability for acts of terrorism perpetrated using Gentoo.

Re: [gentoo-dev] Appropriate location to publish experimental stages for Alt

[R0b0t1]

On Saturday, September 9, 2017, Johnson Steward <i...@jsteward.moe> wrote:
> Hello,
> I've been messing with Gentoo FreeBSD these days and, finally, got to the
current latest version available. As upgrading is really a tiring process
(lots and lots and lots of bootstrapping the tool chain and bunches of
blocks in the current stages), I'm thinking of sharing my currently working
system as a staged for further testing for those who are interested.
> Yet I can't come up with an appropriate location for the stage4 to be
hosted. 1.4GB is obviously too large for a pastebin even if
bzip2-compressed, and consumer-level cloud storage providers like Google
Drive or OneDrive will create unnecessary chaos when trying to actually
install the system (virtually impossible to interact with that
JavaScript-based system within the FreeBSD livecd), and I don't have an
account for Google Cloud Storage or AWS either.
> Is there a suitable location to host such a stage? I'm currently not a
Gentoo developer, yet I really want my work to benefit the Gentoo FreeBSD
community.
> Thanks,
>
> Johnson Steward

Contact desult...@gentoo.org.

Thank you for your work. There's still lots of things that are harder than
they should be.

Cheers,
R0b0t1

Re: [gentoo-dev] dev-libs/cryptlib masked for removal in 30 days

[R0b0t1]

On Fri, Sep 8, 2017 at 2:57 PM, Alon Bar-Lev <alo...@gentoo.org> wrote:
> On 8 September 2017 at 22:44, R0b0t1 <r03...@gmail.com> wrote:
>>
>> On Fri, Sep 8, 2017 at 2:40 PM, Alon Bar-Lev <alo...@gentoo.org> wrote:
>> > Complex build system, hard to maintain, no dependencies in tree, upstream
>> > does not cooperate (Bug#630420).
>> > Removal in 30 days.
>> >
>>
>> I don't have any reason to disagree with this but I expected a
>> citation for those things to be in the bug you referenced. They're
>> not, and I don't see any bugs on the tracker.
>
> The effort of upgrade per each version is becoming greater.
> Previous and next versions required significant work, issues reported
> to upstream with the hope of a change, but most is rejected.
> The build system is so complex that is specific to gcc/ld and
> hard-coded dependencies locations and cflags/ldflags magic.
> Unless we have a very good reason (important dependency), my
> suggestion is to drop it.
> Do we have such a reason?
>

I don't think so. That is a very good description of a valid reason.

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

[R0b0t1]

On Fri, Sep 8, 2017 at 8:33 PM, R0b0t1 <r03...@gmail.com> wrote:
> On Fri, Sep 8, 2017 at 10:56 AM, Kent Fredric <ken...@gentoo.org> wrote:
>> On Fri, 8 Sep 2017 10:11:51 -0500
>> R0b0t1 <r03...@gmail.com> wrote:
>>
>>> Then I'm quite confused as to why people seem to be extremely attentive to
>>> copyright infringement (besides an immediate payout). In the US they cite
>>> the reasoning I gave, from memory.
>>>
>>> Maybe that was for trademarks?
>>
>> This is one of those problems where the nebulous term "IP" has infected
>> our thinking.
>>
>> Yes, US is very *copyright* infringement zealous.
>>
>> But Trademark and Copyright are very different beasts.
>>
>> Trademarks (read: brands, company names, company symbols, etc)  do
>> expire much shorter, but that's due to other reasons. Namely, that if
>> your company ceases to be doing business for 10 years, nobody is harmed
>> by people using a name of a company that doesn't exist, because
>> "Trademark protection" is largely a device to prevent competitors
>> claiming they're you, and to prevent competitors selling products
>> claiming you made them.
>>
>> Copyright (read: the right to publish, distribute, and sell) has a much
>> longer life as the results of that can be inheritable, eg: profits from
>> sale copyrighted works can go towards the estate of the author of those
>> works after the death of that author.
>>
>> There are documented *exceptions* to this, but they don't apply to us
>> as they apply to public institutions such as archives and libraries.
>>
>> And there are exceptions in cases of "fair use", which Gentoo does not
>> fall under.
>>
>> So, even though it is true that copyright expires, copy right expiry
>> dates are currently such that most juristictions don't have any
>> software that could conceivably exist that expires.
>>
>> If the expiry period is 50 years, and there's no software in
>> circulation older than 30, its kindof a moot point to argue software
>> that is less than 10 years old might have expired.
>>
>
> There's nothing in this though that says a copyright couldn't be
> weakened by failure to enforce claims against infringers. However, it
> happens that copyright law allows selective enforcement.
>
>>> >> 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.
>>
>> As a Warranty, sure.
>>
>
> The point isn't to be practically enforceable. If someone put their
> mind to using iTunes to make an ICBM I'm sure no one could stop them.
> The point is that Apple has now disclaimed liability for terrorist
> acts associated with iTunes in a very legally important way, which I
> believe is related to export restrictions (the item of interest likely
> being the cryptography portions of the digital restrictions management
> code).
>
>> "if you use it for this, don't blame us if bad things happen, we told
>> you not to"
>>
>
> There's a myriad of laws that duplicate the intent of the basic laws
> against property damage and taking life.
>

My apologies. In my dimwittedness I forgot to finish this section.

There's a lot of overlapping laws that duplicate things already in
existence. Likewise, people keep attempting to disclaim whatever
liability the law tells them they have in shrinkwrap contracts.

A good example is Li-Ion batteries. Did you know you're supposed to
watch them and not let them out of your sight while charging? If you
leave them out of your sight or do not take additional precautions
that no reasonable person I know would take, then the manufacturer
claims they are not responsible for property damage (read: fires) due
to their product's defects.

However, in fairly recent memory, the fires cause by Samsung phones
were being blamed on Samsung, and other smaller suits have been won
against battery manufacturers.

>> Also, those are typically things that fall under "National Laws" and

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

[R0b0t1]

On Fri, Sep 8, 2017 at 10:56 AM, Kent Fredric <ken...@gentoo.org> wrote:
> On Fri, 8 Sep 2017 10:11:51 -0500
> R0b0t1 <r03...@gmail.com> wrote:
>
>> Then I'm quite confused as to why people seem to be extremely attentive to
>> copyright infringement (besides an immediate payout). In the US they cite
>> the reasoning I gave, from memory.
>>
>> Maybe that was for trademarks?
>
> This is one of those problems where the nebulous term "IP" has infected
> our thinking.
>
> Yes, US is very *copyright* infringement zealous.
>
> But Trademark and Copyright are very different beasts.
>
> Trademarks (read: brands, company names, company symbols, etc)  do
> expire much shorter, but that's due to other reasons. Namely, that if
> your company ceases to be doing business for 10 years, nobody is harmed
> by people using a name of a company that doesn't exist, because
> "Trademark protection" is largely a device to prevent competitors
> claiming they're you, and to prevent competitors selling products
> claiming you made them.
>
> Copyright (read: the right to publish, distribute, and sell) has a much
> longer life as the results of that can be inheritable, eg: profits from
> sale copyrighted works can go towards the estate of the author of those
> works after the death of that author.
>
> There are documented *exceptions* to this, but they don't apply to us
> as they apply to public institutions such as archives and libraries.
>
> And there are exceptions in cases of "fair use", which Gentoo does not
> fall under.
>
> So, even though it is true that copyright expires, copy right expiry
> dates are currently such that most juristictions don't have any
> software that could conceivably exist that expires.
>
> If the expiry period is 50 years, and there's no software in
> circulation older than 30, its kindof a moot point to argue software
> that is less than 10 years old might have expired.
>

There's nothing in this though that says a copyright couldn't be
weakened by failure to enforce claims against infringers. However, it
happens that copyright law allows selective enforcement.

>> >> 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.
>
> As a Warranty, sure.
>

The point isn't to be practically enforceable. If someone put their
mind to using iTunes to make an ICBM I'm sure no one could stop them.
The point is that Apple has now disclaimed liability for terrorist
acts associated with iTunes in a very legally important way, which I
believe is related to export restrictions (the item of interest likely
being the cryptography portions of the digital restrictions management
code).

> "if you use it for this, don't blame us if bad things happen, we told
> you not to"
>

There's a myriad of laws that duplicate the intent of the basic laws
against property damage and taking life.

> Also, those are typically things that fall under "National Laws" and it
> doesn't really make sense to have to explicitly articulate in a
> software license that its intended use is to be done within the scope
> of your local governing laws.
>
> You're bound to follow local law regardless of whether you accept or
> reject a given license. So, its kinda moot.
>

It is my understanding that this realization supports the view that
the link should be left in. It's up to the user of the software, radio
broadcasting kit, car, etc, to use the item in a responsible manner.

I am worried about ceding rights where it is not necessary to do so. A
good analogue to the situation at hand is crowdfunded electronics
projects that try to be FCC compliant, or delay shipping to obtain FCC
compliance. They don't need to. They're almost always a product not
intended for end users or an incomplete product. This makes me afraid,
sir, because it may be the case in the future I can not produce any
electronic equipment on my own.

Likewise, being unable to tell someone where to download something is
another situation that makes me afraid.

> If your government goes and uses your software for military
> applications despite your license saying "don't", I'm not re

Re: [gentoo-dev] dev-libs/cryptlib masked for removal in 30 days

[R0b0t1]

On Fri, Sep 8, 2017 at 2:40 PM, Alon Bar-Lev  wrote:
> Complex build system, hard to maintain, no dependencies in tree, upstream
> does not cooperate (Bug#630420).
> Removal in 30 days.
>

I don't have any reason to disagree with this but I expected a
citation for those things to be in the bug you referenced. They're
not, and I don't see any bugs on the tracker.

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

[R0b0t1]

On Friday, September 8, 2017, Ulrich Mueller <u...@gentoo.org> wrote:
>>>>>> On Thu, 7 Sep 2017, R0b0t1  wrote:
>
>> Downloading does not imply committing a felony. As far as anyone can
>> tell it is impossible to prosecute someone for downloading something
>> they already own (regardless of what any EULA has claimed).
>
> Sure, if the user already has rightfully obtained the software then
> nothing can stop him from downloading it again.
>
>> Further, copyrights lapse if not enforced. Depending on how long
>> that download has been up the original rightsholder has forfeited
>> their claim to their work.
>
> Copyright expires no sooner than 50 years after the author's death:
> https://en.wikipedia.org/wiki/Berne_Convention
> In most countries that term is even longer, e.g. 70 years in the
> European Union.
>
> Also contrary to popular belief, there is no such concept as
> "abandonware". In some legislations, there are some provisions to
> allow archiving of orphan works, but only for public institutions
> (e.g. in the EU, museums and digital archives).
>

Then I'm quite confused as to why people seem to be extremely attentive to
copyright infringement (besides an immediate payout). In the US they cite
the reasoning I gave, from memory.

Maybe that was for trademarks?

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

R0b0t1.

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

[R0b0t1]

Hello,

On Thu, Sep 7, 2017 at 8:04 AM, Ulrich Mueller <u...@gentoo.org> wrote:
>>>>>> On Thu, 7 Sep 2017, Rich Freeman wrote:
>
>>>> Do we routinely confirm that any site we list in SRC_URI has
>>>> permission to redistribute files? That seems like a slippery
>>>> slope.
>>>
>>> We don't, and for a package that comes with a license (as the vast
>>> majority of packages does) it normally isn't necessary.
>
>> Why isn't this necessary?  How do you know the person issuing the
>> license actually has the right to issue it?
>
> Don't you think there is a difference between downloading a package
> that has a known upstream and that is also carried by other distros,
> and downloading a license-less package from a random location on the
> internet?
>
>>> The package in question doesn't come with any license though, which
>>> means that only the copyright holder has the right to distribute
>>> it. So I believe that some extra care is justified, especially when
>>> the upstream location of the distfile has changed.
>
>> Why?  We don't redistribute anything that is copyrighted.
>
> Users download the file, and I think that we are responsible to have
> only such SRC_URIs in our ebuilds from where they can obtain the
> package without being exposed to potential legal issues.
>

Downloading does not imply committing a felony. As far as anyone can
tell it is impossible to prosecute someone for downloading something
they already own (regardless of what any EULA has claimed). Further,
copyrights lapse if not enforced. Depending on how long that download
has been up the original rightsholder has forfeited their claim to
their work.

It's also really hard to convince a judge or jury that I am to blame
if someone follows my instructions (save for specific cases where I
could be considered a subject matter expert). E.g. it's possible to
sell radio kits that are illegal to put together and operate.

>> Are you arguing that merely linking to the file is illegal?  If so,
>> then you better get the list archives purged.
>
> Arguably, items in SRC_URI aren't even hyperlinks. And no, I don't
> think that such linking is illegal. IANAL, though.
>

It is at this point I would suggest that you have defeated your own argument.

>>> We don't know this for sure unless we ask the author. So whoever is
>>> interested in keeping the package in the tree should sort these
>>> issues out.
>
>> Perhaps if we want to enforce a policy like this we should take the
>> time to actually write the policy down.  As far as I can tell Gentoo
>> has no such policy currently.
>
> The old Games Ebuild Howto [1] has this:
>
> | LICENSE
> |
> | The license is an important point in your ebuild. It is also a
> | common place for making mistakes. Try to check the license on any
> | ebuild that you submit. Often times, the license will be in a
> | COPYING file, distributed in the package's tarball. If the license
> | is not readily apparent, try contacting the authors of the package
> | for clarification. [...]
>
> I propose to add the paragraph above to the devmanual's licenses
> section.
>

Should the Gentoo foundation include a disclaimer that the software
distributed by it is not to be used to build ballistic missiles or run
nuclear arms programs? Users might do those things, and Gentoo might
be liable for the consequences if they do.


On Thu, Sep 7, 2017 at 4:56 PM, Rich Freeman <ri...@gentoo.org> wrote:
> Do you really need me to put it on the Council agenda?

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.

Respectfully,
 R0b0t1

Re: [gentoo-dev] Server hardaware give away (misc archs)

[R0b0t1]

On Wednesday, September 6, 2017, R0b0t1 <r03...@gmail.com> wrote:
> On Wednesday, September 6, 2017, Brendan Horan <bren...@horan.hk> wrote:
>> Hi R0b0t1,
>>
>> Sounds good to me.
>> Shipping a 30kg+ system by it self will not be cheep.
>> This is originally why I had the idea to ship all the systems together.
>>
>
> I thought so. Shipping will still be cheaper than a used unit from
someone else, so thank you.
>

Sorry, still a tad excited and I forgot to finish again.

If you want to ship all the servers at once I might be able to find homes
for them stateside, but it looks like other people are already interested.
Also my budget isn't gigantic and that much weight that far is likely to be
expensive.

>> Specs are :
>>
http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_sm/1/872/ENUS8203-_h01/index.html=en_locale=en
>>
>> Sorry its a single 4-core CPU.
>>
>
> That is fine. I did not expect to come into a 40+ core POWER server any
time soon. The cheaper servers are about as rare as the expensive ones.
>
>> Lets talk about shipping options, I am open to suggestions and ideas.
>>
>
> If you do not mind I am moving to a private message to discuss this. In
short, time is not too important so the cheapest of the carriers available
to you would work.
>
> I should be able to buy postage and transmit it to you if you have a box
and scale ready.
>
>> Thanks
>> Brendan (irc : undersys)
>>
>>
>> - On 6 Sep, 2017, at 2:04 PM, R0b0t1 r03...@gmail.com wrote:
>>>>
>>>> I would very much appreciate it if I could claim the IBM Power server.
>>>> I have been interested in IBM's Power architecture and its supporting
>>>> hardware for quite a while now. There are not many machines sold on
>>>> the secondhand market and I do not have the funds to purchase one in
>>>> that way.
>>>
>>> Sorry for the follow-up. To clarify, I expect to be able to cover the
>>> cost of shipping.
>>>
>>>> The specs are mostly irrelevant as long as it has a Power
>>>> CPU, but they would be nice to know.
>>>>
>>>> The use for the machine would be to experiment with the novel
>>>> architecture while maintaining it with Gentoo, which would likely
>>>> spill over into providing support for Gentoo on IBM Power.
>>>>
>>>> I will try to catch you on IRC, but hopefully you receive this message
as well.
>>>>
>>>> Respectfully,
>>> >  R0b0t1
>>
>>

[gentoo-dev] Server hardaware give away (misc archs)

[R0b0t1]

On Wednesday, September 6, 2017, Brendan Horan <bren...@horan.hk> wrote:
> Hi R0b0t1,
>
> Sounds good to me.
> Shipping a 30kg+ system by it self will not be cheep.
> This is originally why I had the idea to ship all the systems together.
>

I thought so. Shipping will still be cheaper than a used unit from someone
else, so thank you.

> Specs are :
>
http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_sm/1/872/ENUS8203-_h01/index.html=en_locale=en
>
> Sorry its a single 4-core CPU.
>

That is fine. I did not expect to come into a 40+ core POWER server any
time soon. The cheaper servers are about as rare as the expensive ones.

> Lets talk about shipping options, I am open to suggestions and ideas.
>

If you do not mind I am moving to a private message to discuss this. In
short, time is not too important so the cheapest of the carriers available
to you would work.

I should be able to buy postage and transmit it to you if you have a box
and scale ready.

> Thanks
> Brendan (irc : undersys)
>
>
> - On 6 Sep, 2017, at 2:04 PM, R0b0t1 r03...@gmail.com wrote:
>>>
>>> I would very much appreciate it if I could claim the IBM Power server.
>>> I have been interested in IBM's Power architecture and its supporting
>>> hardware for quite a while now. There are not many machines sold on
>>> the secondhand market and I do not have the funds to purchase one in
>>> that way.
>>
>> Sorry for the follow-up. To clarify, I expect to be able to cover the
>> cost of shipping.
>>
>>> The specs are mostly irrelevant as long as it has a Power
>>> CPU, but they would be nice to know.
>>>
>>> The use for the machine would be to experiment with the novel
>>> architecture while maintaining it with Gentoo, which would likely
>>> spill over into providing support for Gentoo on IBM Power.
>>>
>>> I will try to catch you on IRC, but hopefully you receive this message
as well.
>>>
>>> Respectfully,
>> >  R0b0t1
>
>

Re: [gentoo-dev] Server hardaware give away (misc archs)

[R0b0t1]

On Tue, Sep 5, 2017 at 10:18 PM, R0b0t1 <r03...@gmail.com> wrote:
> On Tue, Sep 5, 2017 at 7:20 PM, Brendan Horan <bren...@horan.hk> wrote:
>> Hi everyone,
>>
>> I have some hardware I would like to see go to a good home.
>> I would prefer it to be someone working with Gentoo.
>> That was my goal, but life changes :)
>>
>>
>> I have the following :
>> * HP j6750 (2x cpu PA-RSIC)
>> * HP Zx2000 Itanium2 (single cpu) (custom 4ru unit)
>> * IBM Power 6+ p560 (dual cpu)
>> * Sun SPARC T5120 (single cpu)
>>
>> The systems are all in working order. With decent specs.
>> All have 8gb of memory or more
>> All have at least 2 disks (ranging from 32gb to 300gb)
>> I have some misc spares for all of the above.
>> If you want more details on any of the systems please ask.
>> You can also catch me on IRC @ #gentoo-proxy-maint
>>
>>
>> Ideally I would want to ship it to one location.
>> If you then wanted to ship interstate/country from that point I don't care.
>> I live in Hong Kong, no one hear but scrap metal places what this kit.
>> I don't mind helping pay some of the shipping costs.
>> I do not want payment for the systems, just a good home vs the scrap heap.
>>
>> Thanks
>> Brendan
>>
>
> Hello,
>
> I would very much appreciate it if I could claim the IBM Power server.
> I have been interested in IBM's Power architecture and its supporting
> hardware for quite a while now. There are not many machines sold on
> the secondhand market and I do not have the funds to purchase one in
> that way.

Sorry for the follow-up. To clarify, I expect to be able to cover the
cost of shipping.

> The specs are mostly irrelevant as long as it has a Power
> CPU, but they would be nice to know.
>
> The use for the machine would be to experiment with the novel
> architecture while maintaining it with Gentoo, which would likely
> spill over into providing support for Gentoo on IBM Power.
>
> I will try to catch you on IRC, but hopefully you receive this message as 
> well.
>
> Respectfully,
>  R0b0t1

Re: [gentoo-dev] Server hardaware give away (misc archs)

[R0b0t1]

On Tue, Sep 5, 2017 at 7:20 PM, Brendan Horan <bren...@horan.hk> wrote:
> Hi everyone,
>
> I have some hardware I would like to see go to a good home.
> I would prefer it to be someone working with Gentoo.
> That was my goal, but life changes :)
>
>
> I have the following :
> * HP j6750 (2x cpu PA-RSIC)
> * HP Zx2000 Itanium2 (single cpu) (custom 4ru unit)
> * IBM Power 6+ p560 (dual cpu)
> * Sun SPARC T5120 (single cpu)
>
> The systems are all in working order. With decent specs.
> All have 8gb of memory or more
> All have at least 2 disks (ranging from 32gb to 300gb)
> I have some misc spares for all of the above.
> If you want more details on any of the systems please ask.
> You can also catch me on IRC @ #gentoo-proxy-maint
>
>
> Ideally I would want to ship it to one location.
> If you then wanted to ship interstate/country from that point I don't care.
> I live in Hong Kong, no one hear but scrap metal places what this kit.
> I don't mind helping pay some of the shipping costs.
> I do not want payment for the systems, just a good home vs the scrap heap.
>
> Thanks
> Brendan
>

Hello,

I would very much appreciate it if I could claim the IBM Power server.
I have been interested in IBM's Power architecture and its supporting
hardware for quite a while now. There are not many machines sold on
the secondhand market and I do not have the funds to purchase one in
that way. The specs are mostly irrelevant as long as it has a Power
CPU, but they would be nice to know.

The use for the machine would be to experiment with the novel
architecture while maintaining it with Gentoo, which would likely
spill over into providing support for Gentoo on IBM Power.

I will try to catch you on IRC, but hopefully you receive this message as well.

Respectfully,
 R0b0t1

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

[R0b0t1]

On Mon, Sep 4, 2017 at 6:12 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Indeed.  Even after the general gui-provider can be assumed to be wayland
> in much the same was as it has been X for decades now, rootless/nested X
> will be around for many years/decades, for much the same reason that I'm
> still using dosbox to effectively provide "nested DOS" for that single
> legacy/proprietary game[1] I still play somewhat frequently.  Some
> things, in particular X-based proprietary apps such as but not limited to
> games, are unlikely to ever be ported, so those continuing to find a use
> for them will continue to have a use for X, almost certainly eventually
> in nested and ultimately emulated form, much as I do with that game and
> dosbox.
>

You are likely right. There are contractors with stories of the US
Government running mission critical infrastructure on servers which
emulate an older computer, which in turn is emulating an even older
computer.

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

My apologies, sir, for making myself known; please understand it was
never my intention to be a nuisance. I simply send things to this list
so that I can feel like I am doing something. Up until now I had not
been sure my messages were readable.

us·er ex·pe·ri·ence
noun: user experience; plural noun: user experiences
the overall experience of a person using a product such as a
website or computer application, especially in terms of how easy or
pleasing it is to use.

>From this definition, I see no connection to anything graphical. To
the extent that words have meaning I think the selection of "ux-*"
would be a mistake.

Respectfully,
 R0b0t1