[gentoo-dev] Packages up for grabs

2017-12-12 Thread Daniel Campbell
The following packages are in need of a maintainer:

dev-util/astyle
net-im/toxic
x11-misc/alock
x11-misc/ktsuss
x11-misc/spacefm
-- 
Daniel Campbell
OpenPGP Fingerprint: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
Found on hkp://keys.gnupg.net and other keyservers


signature.asc
Description: Digital signature


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

2017-12-09 Thread Daniel Campbell
On Sat, Dec 09, 2017 at 08:13:18PM -0500, Rich Freeman wrote:
> On Sat, Dec 9, 2017 at 7:29 PM, Daniel Campbell <z...@gentoo.org> wrote:
> >
> > Other developers are required to subscribe to -dev, and are
> > expected to follow it so they stay informed.
> 
> Developers are not required to subscribe to -dev.
> 
> > If they missed something covered on the list, they are directed to the
> > archives and (usually) laughed at.
> 
> Correct.  While nobody is required to follow the lists, acting out of
> ignorance usually doesn't impress others.  Devs are expected to be
> adults and figure out what they need to follow based on what they
> intend to contribute to.  -core and -dev-announce are the only
> required subscriptions.
> 
> >
> > Great things coming from Gentoo "leadership" here. What will you do when
> > mgorny starts targeting developers and pitching tantrums over them, too?
> 
> You act as if this was the only reason that comrel took action.  In
> the cases of appeals I've seen I've yet to see a case where there
> wasn't something else going on behind the scene that wasn't reasonably
> severe when they've taken action.  I can't vouch for their reasons in
> this case as I'm not privy to them, and I imagine they're not going to
> be made public.

Well, let's consider the order of events here:

1. wltjr and others appear on the ML
2. Drama
3. mgorny suggests some change in structure to avoid dealing with said
   people.
4. more drama
5. mgorny publicly insults comrel, accusing them of doing nothing
6. mgorny publishes formal plan to reform our mailing lists
7. more drama
8. comrel bans wltjr
9. mgorny's plan is put on Council agenda
10. comrel *mails to let everyone know wltjr was banned*, despite prior
claims of valuing privacy and secrecy
11. you are here

This looks awfully clear to me. I'm pointing out behavior that looks a
lot like one person twisting the social structure to suit their desires.
This concerns me because our community will be damaged by his plan, and
it is only the first step. In the second step, he will turn against
developers as well. But not you and his other buddies. Just the ones
*he* thinks are a problem.

> 
> > This is precisely why we have unmotivated developers
> > and a bevy of unmaintained packages; nobody wants to contribute to a
> > distro that treats its users (and developers) so poorly.
> 
> Go ahead and cite the list of people who have been banned in the last
> decade.  You won't run out of fingers on one hand.  Some might cry
> about it for months, but good luck finding another distro that hasn't
> banned twice as many in the same span of years.
> 
> And keep in mind that failing to take action isn't without
> consequences.  When somebody is harassing somebody else (and sometimes
> more than one other) you don't really get a choice about whether
> somebody is going to end up leaving, whether of their own accord or
> not.  That is a situation I've seen happen more than once around here
> behind the scenes.  Again, I have no specific knowledge about this
> particular comrel action - I'm talking about situations I've seen in
> the past.

I'm not focused on the ban, or whether it was deserved. That's a
separate subject. I'm pointing out behaviors that damage our image, our
credibility, and morale. I'm calling out unequal enforcement and
favoritism; these are things that you won't find in any records, because
the existence of such records would damn those culpable. The fact that
comrel has never acted against mgorny strongly indicates that they do
not care about the way he treats others. He is kept because of his
technical skill. Others do not get this convenience; we are accountable
for the code *and* the words that we write. You're blind if you don't
see this.

> 
> > A distro should never bend its entire social structure to protect the
> > feelings of one surly developer (or his/her entourage),
> 
> Certainly, and that works both ways.
> 
> > but naturally
> > since every council member is friends with mgorny and comrel is afraid
> > to take any action against him, they'll make exceptions to established
> > procedures and ignore any complaints about the way he treats others.
> 
> Considering that he won a significantly contested election to Council,
> I suspect that more people around here approve of mgorny than just the
> members of the council.  And I can certainly vouch that not all
> council members are necessarily fans of some of his actions, though I
> suspect that his technical contributions are praised by just about all
> (rightly, IMO).
> 
> I've yet to see a discussion between Council members where people were
> strongly playing favorites the way you imply.

I'm not criticizing any code he's written.

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

2017-12-09 Thread Daniel Campbell
On Fri, Dec 08, 2017 at 09:22:32PM +0100, Andreas K. Huettel wrote:
> Am Donnerstag, 7. Dezember 2017, 19:06:36 CET schrieb William L. Thomson Jr.:
> > 
> > The day everyone wanted has come, after this message. I will
> > unsubscribe not to return. You all won in 2008, and again in 2017.
> > Though this time I will not be back. I tried more than most anyone else
> > would for a very long time. Gentoo wins I lose, I am fine with that.
> > 
> > Please do not contact me off list in IRC or at all. I am done with the
> > Gentoo community!
> 
> 
> Independent of whether William now unsubscribed or not, he's now enjoying a 
> lengthy (1 year until review) vacation from all Gentoo communication channels.
> 
> 
> -- 
> Andreas K. Hüttel
> dilfri...@gentoo.org
> Gentoo Linux developer (council, perl, libreoffice)

So, mgorny threatened to leave if something wasn't done, right? I saw
the IRC conversation about unsubscribing from gentoo-dev, as well. IRC
is not private, for the record. Other developers are required to
subscribe to -dev, and are expected to follow it so they stay informed.
If they missed something covered on the list, they are directed to the
archives and (usually) laughed at. I see no reason for this expectation
to be waived for any single developer. Do I get a free pass if I don't
like what someone says?

It's not enough to let wltjr leave on his own; you had to create a ban
and add a smug, tongue-in-cheek mail to it to maintain the image of
doing something. Quite hypocritical of comrel's attitude of secrecy to
suddenly announce a ban. It seems to me that secrecy is only adopted
when it suits those who stand to benefit from it.

Great things coming from Gentoo "leadership" here. What will you do when
mgorny starts targeting developers and pitching tantrums over them, too?
Are we going to stratify developership further, too? It seems rather
clear to me that a few individuals see themselves as the owners of this
distro and bend it to suit their whims, using bureacracy to obscure
their actions and motivations, segment the community, and block those
less experienced. This is precisely why we have unmotivated developers
and a bevy of unmaintained packages; nobody wants to contribute to a
distro that treats its users (and developers) so poorly.

A distro should never bend its entire social structure to protect the
feelings of one surly developer (or his/her entourage), but naturally
since every council member is friends with mgorny and comrel is afraid
to take any action against him, they'll make exceptions to established
procedures and ignore any complaints about the way he treats others.

Software cannot fix wetware. Plenty of developers get to deal with
mgorny's aggressive and insulting tone, yet nothing happens. Gee... I
wonder why.  Maybe because the upper parts of Gentoo are riddled with
cronyism.

"Rules for thee, not for me."

It's clear to anyone with eyeballs that there is preferential treatment
and inconsistent enforcement of rules in this community, and the people
in a position to fix it, won't, because they in fact benefit from this.

Unfortunately, GLEP 39 does not have a section on recalling or
impeachment... This whole situation highlights why the Council has no
business sticking its head into non-technical matters. It's clearly not
up to the task. It's no surprise, since technical skill does not
guarantee or even imply social skill. (or vice-versa)

I'm tired of people beating around the bush and the facile attempts of
tact: why do you give special treatment to certain members of this
community? Would you have done anything different if it were me or some
other developer who was proposing this change?

It wouldn't have made it to the Council agenda if he didn't write it,
period. Everyone else would've been told to suck it up and deal with it.
And knowing how the Council is, in a few days we'll all get to deal with
the churn of mailing lists to protect one person's ego. Sad.

~zlg
-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


signature.asc
Description: Digital signature


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

2017-12-05 Thread Daniel Campbell
On Tue, Dec 05, 2017 at 08:59:40AM +, Peter Stuge wrote:
> Daniel Campbell wrote:
> > On Sun, Dec 03, 2017 at 12:18:04AM +0100, Michał Górny wrote:
> > > I'd like to establish the following changes to the mailing lists:
> > > 
> > > 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be
> > > initially restricted to active Gentoo developers.
> > 
> > I don't think this plan will have the effect you're going for,
> 
> I agree, and I'll double down on my previous comment on this proposal:
> 
> I consider the proposal to be the wrong solution.
> 
> 
> > but let's be honest here: the "RFC" is just a formality; the decision's
> > already been made.
> 
> I hope that a mere proposal doesn't automatically mean policy change.
> 

If proposals come from a select couple of people, there are high odds
that it's been discussed privately and the relevant people've been
convinced or otherwise pushed to implement the change. By the time it
hits the list, any cricitism is met with "too bad, we're doing it
anyway". I'm not sure how new you are to Gentoo, but it's been this way
since at least 2012.

> 
> > If the "real leaders" of Gentoo want to divide and fragment the
> > community, it's their prerogative.
> 
> When there is a request for comments, there should also be comments. :)
> 
> Far too many fall into the simple trap that is tribalism, and I'd like
> to encourage everyone on this list to not be that kind of person,
> because there really is no "us and them", there is only "us".
> 

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. It will likely be a silent rejection, so the
fallout is minimal. The plan itself is a manifestation of tribalism.
The "us" is a select group of people who've been blessed by mgorny and
friends.  Everyone else is deemed a "do nothing" or some other insult,
regardless of their history or efforts with the distribution. Yes,
talking about that is ugly, but it's the truth. I've been on the
receiving end of it multiple times and have been witness to it many
others. It shows up in just about every corner of Gentoo. Creating a
technical schism won't fix it.

> 
> > As we tell users who do something they're not supposed to: You get
> > to keep the pieces.
> 
> Well, let's see what happens, now that both developers and
> non-developers have clearly spoken out *against* this proposal.
> 

I'm not holding my breath on any positive change, but we'll see. It's
not like we have a choice in the matter. I guess we'll have to subscribe
to yet another mailing list if we want to stay informed. Maybe in a
year's time, we'll have gentoo-dev-expert as well, so the Chosen Ones
don't have to deal with developers they don't like.

This is my last mail in this thread. I've made my points and know they
will fall on deaf ears. You're not wrong in your approach; I don't share
that faith, is all. So I hope you don't interpret this as me yelling at
you.

> 
> Kind regards
> 
> //Peter
> 

-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


signature.asc
Description: Digital signature


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

2017-12-04 Thread Daniel Campbell
ion with the current mailing list software
> and I'm not aware of anyone willing to undergo all the necessary work to
> change that.
> 
> Even if we were able to overcome that and be able to find a good
> moderation team that can effectively and fairly moderate e-mails without
> causing huge delays, moderation has a number of own problems:
> 
> α) the delays will make discussions more cumbersome, and render posting
> confusing to users,
> 
> β) they will implicitly cause some overlap of replies (e.g. when N
> different people answer the same question because they 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?
> 
> 
> 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.
> 
> -- 
> Best regards,
> Michał Górny
> 
> 

I don't think this plan will have the effect you're going for, but let's
be honest here: the "RFC" is just a formality; the decision's already
been made.

If the "real leaders" of Gentoo want to divide and fragment the
community, it's their prerogative. As we tell users who do something
they're not supposed to: You get to keep the pieces.

~zlg

-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


signature.asc
Description: Digital signature


Re: [gentoo-dev] NEWS item for games destabling

2017-11-20 Thread Daniel Campbell
On Mon, Nov 20, 2017 at 11:36:33AM +0100, Róbert Čerňanský wrote:
> On Mon, 20 Nov 2017 10:26:29 +0100
> David Seifert <s...@gentoo.org> wrote:
> 
> > Round 2 (with correct whitespace this time):
> > 
> > Title: No stable KEYWORDS for Gentoo Games
> > Author: David Seifert <s...@gentoo.org>
> > Content-Type: text/plain
> > Posted: 2017-11-20
> > Revision: 1
> > News-Item-Format: 1.0
> > Display-If-Keyword: amd64 x86
> > 
> > As the Games team does not have enough manpower to keep tabs on all
> > games packages, we have dropped all ebuilds maintained by the games
> > project to unstable KEYWORDS (without those required by other stable
> > packages). If you have any of these stable games packages installed,
> > you will have to add them to /etc/portage/package.accept_keywords/
> > manually. Failures related to missing stable KEYWORDS will show up as
> > 
> >   The following keyword changes are necessary to proceed:
> >(see "package.accept_keywords" in the portage(5) man page for more
> > details)
> >   # required by @selected
> >   # required by @world (argument)
> >   =games-action/0verkill-0.16-r4 ~amd64
> > 
> > While we accept that this will cause some irritation for the
> > community, pretending we have a well supported games collection by
> > having a wealth of stable games packages is misleading at best. We
> > welcome contributions from outsiders willing to polish up the games
> > landscape in Gentoo via the Proxy Maintainers.
> 
> What does it mean for the future?  Should not users bother to test &
> write stabilization request bugs for games anymore?  Or stabi
> requests will still be accepted?
> 
> Robert
> 
> 
> -- 
> Róbert Čerňanský
> E-mail: ope...@tightmail.com
> Jabber: h...@jabber.sk
> 

If I may take a stab at this (correct me if I'm wrong, soap):

It only means games are being dropped to ~arch (testing) until other
maintainers (proxy or otherwise) step up to make sure the games really
are stable. Packages that rarely get attention but are still marked
"stable" dilutes the meaning of "stable", especially if you get
installation or runtime problems that a proper testing of the package
would have caught.

This results in bugs that should've been caught in the testing phase,
confuses users (and developers), and redundant or obvious bugs being
reported.

This reads like a "fresh slate" for games, allowing them to start from
~arch and ensure that stabilization procedures are correctly followed by
those who step up. While this will create more stabilization bugs, it
should, in theory, result in better ebuilds (which makes Gentoo
maintenance better/easier) and games that have *actually* been tested.

I hope this explanation is both accurate and helpful.

~zlg
-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH] fdo-mime.eclass: Mark the eclass as deprecated

2017-11-18 Thread Daniel Campbell
On Mon, Nov 13, 2017 at 03:30:11AM +0100, Jonas Stein wrote:
> On 19/06/17 15:20, Michał Górny wrote:
> > The GNOME team has committed the xdg-utils.eclass serving exactly
> > the same purpose as fdo-mime.eclass, supposedly with the goal of
> > replacing it. However, it seems that they have never bothered to
> > actually hint the deprecation in the fdo-mime.eclass in any way.
> > As a result, developers are still adding references to this eclass
> > instead of using xdg-utils or xdg, and/or not working towards replacing
> > them.
> > 
> > Add an explicit deprecation notice to the fdo-mime.eclass to make it
> > clear that the eclass should not be used in new packages, and what
> > the replacement eclasses are.
> 
> Packages and Ebuilds which are still using the fdo-mime are listed here:
> 
> Packages:
> https://qa-reports.gentoo.org/output/eclass-usage/fdo-mime.txt
> 
> Ebuilds sorted by Maintainer or Package
> http://gentoo.levelnine.at/simplechecks/fdo-mime-check/
> 
> If you see your name in the list, you find a list of your packages with
> inherit fdo-mime.
> 
> Thanks to Michael. For his script.
> 
> -- 
> Best,
> Jonas
> 

Great tool! Super easy for maintainers to check their packages. I have
fixes ready for x11-misc/spacefm, but I could not find a bug number to
reference. Are we tracking this on bugzy or just pushing everyone to go
ahead and update their ebuilds? I searched bugzy for 'fdo-mime' and the
only relevant bug is 621914 [1], which I assume was the original discussion
to get us onto xdg-utils since it's newer.

If there's no tracker bug I need to reference, that's fine. Just wanted
to be sure I'm not missing anything before pushing.

[1]: https://bugs.gentoo.org/621914

-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


signature.asc
Description: Digital signature


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

2017-11-17 Thread Daniel Campbell
gt; from a trusted source for comparison.

"a more complete protection"; should probably drop the "a".

> 
> Strictly speaking, this information is already provided by the various
> ``metadata/timestamp*`` files that are already present. However,
> including the value in the Manifest itself has a little cost
> and provides the ability to perform the verification stand-alone.
> 
> Furthermore, some of the timestamp files are added very late
> in the distribution process, past the Manifest generation phase. Those
> files will most likely receive ``IGNORE`` entries and therefore
> be not suitable to safe use.

Looks like a few extra words in the last sentence. Here's my attempt:

"These files will likely receive ``IGNORE`` entries and therefore be
unsafe to use."

("unsuitable" may replace "unsafe", up to you)

> 
> The specification permits additional timestamps in sub-Manifest files
> for local use. A generic testing tool should ignore them.
> 
> 
> New vs deprecated tags
> --
> 
> Out of the four types defined by Manifest2, only one is reused
> and the remaining three is replaced by a single, universal ``DATA``
> type.

"the remaining three is" -> "the remaining three are"

> [snip]
> Injecting ChangeLogs into the checkout
> --
> 
> One of the problems considered in the new Manifest format was that
> of injecting historical and autogenerated ChangeLog into the repository.
> Normally we are not including those files to reduce the checkout size.
> However, some users have shown interest in them and Infra is working
> on providing them via an additional rsync module.

"that of" is extraneous here.

The second sentence should read something like "We normally don't
include these files, to reduce checkout size."

> 
> [snip]
> Hash algorithms
> ---
> 
> While maintaining a consistent supported hash set is important
> for interoperability, it is no good fit for the generic layout of this
> GLEP. Furthermore, it would require updating the GLEP in the future
> every time the used algorithms change.

"it is no good fit" -> "it is not a good fit"

> 
> [snip]
> The compression of top-level Manifest file has been prohibited
> as the specification currently does not provide any means of verifying
> the file prior to decompression. This would make it possibly for
> a malicious third party to provide a compressed Manifest exposing
> decompressor vulnerabilities, or being a zip bomb, and the tooling
> would have to unpack it before being able to verify the contents.

The latter half of the paragraph is a little scattered. Here's my
attempt, after the first sentence:

"If the top-level Manifest is compressed, tooling will have to unpack
the file before being able to verify the contents. This makes it
possible for a malicious third party to attack a system by providing a
compressed Manifest that exposes decompressor vulnerabilities, or a zip
bomb."

(Maybe 'zip bomb' should be a link or a footnote, describing what it
is.)

> [snip]
> 
> The existence of additional entries for uncompressed Manifest checksums
> was debated. However, plain entries for the uncompressed file would
> be confusing if only compressed file existed, and conflicting if both

"only compressed" -> "only the compressed"

> uncompressed and compressed variants existed. Furthermore, it has been
> pointed out that ``DIST`` entries do not have uncompressed variant

"uncompressed variant" -> "an uncompressed variant"

> either.
> 
> 
> Performance considerations
> --
> 
> Performing a full-tree verification on every sync raises some
> performance concerns for end-user systems. The initial testing has shown
> that a cold-cache verification on a btrfs file system can take up around
> 4 minutes, with the process being mostly I/O bound. On the other hand,
> it can be expected that the verification will be performed directly
> after syncing, taking advantage of warm filesystem cache.

"warm" -> "a warm"

> 
> [snip]
> Thanks to all the people whose contributions were invaluable
> to the creation of this GLEP. This includes but is not limited to:
> 
> - Robin Hugh Johnson,
> - Ulrich Müller.
> 
> Additionally, thanks to Robin Hugh Johnson for the original
> MataManifest GLEP series which served both as inspiration and source

"MataManifest" -> "MetaManifest"

>
> [snip]
> 

Aside from the few nitpicks this looks good. Hope this helps.

-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


signature.asc
Description: Digital signature


Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd

2017-09-29 Thread Daniel Campbell
On 09/29/2017 04:53 AM, Rich Freeman wrote:
> On Thu, Sep 28, 2017 at 11:32 PM, Ulrich Mueller <u...@gentoo.org> wrote:
>>>>>>> On Thu, 28 Sep 2017, Austin English wrote:
>>
>>> Talking with Whubbs about it, I found that our service script only
>>> supports OpenRC, via rc-service. I looked around, and from what I
>>> can tell, most distros ship a service tool for all supported init
>>> systems. I.e., Debian/Ubuntu: supports sysvinit and systemd via
>>> init-system-helpers CentOS/Fedora: provides support for systemd via
>>> initscripts OpenSUSE: has a working service binary for systemd
>>> (according to #suse)
>>
>> There is "eselect rc" which could be easily extended to support
>> systemd. Patches are welcome. :)
>>
> 
> ++
> 
> Honestly, I could see the argument for having a generic "service"
> command because that is what everybody else does, but there is little
> point in arguing about the name of the file when nobody has bothered
> to write it yet.
> 
> If somebody writes such a tool and it proves useful, we can always
> have the discussion about refactoring.
> 
> To minimize list replies I'll tackle one of Duncan's points - he was
> debating whether you really need this vs just using systemctl.  The
> obvious use case is scripts that are intended to support multiple init
> systems - it makes far more sense to put the logic to figure out which
> one to run in one place than many.  If the runit users want to add
> their own logic they could.  IMO it would be potentially useful, even
> if you and I don't personally have much use for it.
> 
> That said, the sorts of people most likely to benefit probably don't
> use Gentoo in the first place.
> 
> In any case, arguing over whether it is useful is putting the cart
> before the horse.  It doesn't matter if it is useful if nobody bothers
> to build it.  If nobody has that much of an itch to scratch then how
> useful could it be?
> 

Great points. It'll be much easier to decide on something when/if there
is something concrete to work with. There isn't much stopping a package
from making it into Gentoo. If there is demand, it'll be written.

-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


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

2017-09-12 Thread Daniel Campbell
On 09/11/2017 01:56 PM, Michał Górny 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).
> 
> Rich already answered this in detail, so I'll skip it.
> 
>> Will it be possible to build the GLEP rst files locally, and view the
>> output exactly as it would appear on the website? I ask because, so long
>> as you don't want to be able to preview the result, you can already
>> write MediaWiki markup into a text file locally. The offline "live
>> preview" ability is the killer feature of RST as I see it.
> 
> Of course yes. However, the exactness of result depends on how much
> effort you put into it.
> 
> The 'easy way' is rst2html.py (dev-python/docutils). It will give you
> a rough rendering with a standard style, i.e. kinda ugly but enough to
> see if everything works as expected. You'll also see the preamble as big
> mumbo-jumbo on top.
> 
> Then, there's glep.py (dev-python/docutils-glep) which adds preamble
> parsing, table of contents and some styling. AFAICS it needs a bit
> handiwork (copying a stylesheet to a relative directory) but it gives
> nice old-school rendering.
> 
> 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.
> 
> As a side note, we may also rename GLEPs to .rst. Then, GitHub will also
> provide out-of-the-box rendering of them.
> 
To preface, I really like the idea to do this in Git. Much as I
appreciate what the wiki team has done, collaboration isn't quite as
smooth on it and as another person mentioned, it's hard to get reviews,
so you get to choose to leave something in your userspace (I liked your
Drafts namespace idea, fwiw) or edit a page anyway and hope for the best.

That said... Is it wise to rely on Ruby (via Jekyll) for critical
reference documents, given how often minor version bumps in Ruby disrupt
its ecosystem? Do we really need the entire www.gentoo.org repository in
order to view and hack on GLEPs? I see little reason for GLEPs to not be
in their own repository, depending on something more stable than Jekyll
and Ruby. Given that the doc tools themselves are written in Python, it
makes more sense (imo) to leverage Gentoo's existing technical
investment in Python and use something like app-text/pelican, which is
equally, if not more capable than Jekyll and will not require pulling in
Ruby just to hack on and preview some text. Every Gentoo system comes
with Python unless you go off the beaten path and know what you're
doing, so that's a bonus, too.

Of course, this changes if we need some extremely advanced behavior. I'm
not sure how easy it is to build a Pelican plugin, but there's an entire
repo full of them. [1] Pelican also uses a Makefile you can hack on
(even multiple publishing targets), and supports GNU gettext for
translations.

Or is Jekyll chosen purely because the current website is built with it?
In that case, it at least makes sense despite the heavyweight dependencies.

If anyone's interested in seeing a mockup of a few GLEPs in Pelican, I
can get that started.

Whether or not the structure works on GitHub is orthogonal to the
decision. Still, put me down in favor of switching to Git. Thanks for
putting together the proposal.

[1]: https://github.com/getpelican/pelican-plugins
-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

2017-09-10 Thread Daniel Campbell
On 09/10/2017 02:34 AM, Michał Górny wrote:
> W dniu nie, 10.09.2017 o godzinie 00∶39 -0700, użytkownik Daniel
> Campbell napisał:
>> On 09/09/2017 12:47 AM, Michał Górny wrote:
>>> W dniu pią, 08.09.2017 o godzinie 17∶19 -0400, użytkownik Rich Freeman
>>> napisał:
>>>> On Tue, Jul 25, 2017 at 4:05 AM, Michał Górny <mgo...@gentoo.org> wrote:
>>>>>
>>>>> What do you think about it? Is there anything else that needs being
>>>>> covered?
>>>>>
>>>>
>>>> FYI - if anybody does want to make any comments on the proposed
>>>> devmanual changes to implement the new tags please comment at:
>>>>
>>>> https://github.com/gentoo/devmanual.gentoo.org/pull/72
>>>>
>>>> For that matter, if you want to even know what the proposed changes
>>>> are you should also visit the link.
>>>>
>>>> List replies seem to be discouraged.
>>>>
>>>> I realize that some prefer to limit comments to media that are purely
>>>> open source.  I guess the FOSS Linux kernel provided /dev/null still
>>>> exists as an alternative.  Honestly, I'm not sure which of the options
>>>> are more likely to get read.
>>>>
>>>
>>> TL;DR: Rich, I would really appreciate if you stopped the flamebaits.
>>> I understand that you think you're doing Gentoo a favor but you're not.
>>>
>>> The footers were discussed to death in this very thread. I've heard your
>>> opinions. However, as far as I'm concerned (and as I've pointed out) you
>>> did literally *nothing* to push your ideas forward for 2+ years.
>>>
>>> Since I've done all the work, I've did it my way and for the reasons
>>> I've explained multiple times. If you disagree, them I'm sorry but
>>> in life you don't get to have everything your way. Especially if all you
>>> do is complain and expect others to do the work for you.
>>>
>>> I understand that you're unhappy and since you have no valid arguments,
>>> all you can do is try to get more people to support you and shout.
>>> Revive the bikeshed as many times as possible, try to make a lot of
>>> noise and block changes. Worst case, you've blocked something you didn't
>>> like. Best case, you're finally get others so discouraged that they'll
>>> do things your way just so that you stop.
>>>
>>> Rich, this is not a kindergarten. It's time you learn to lose,
>>> and accept the consequences. If you can't do that, the door out is open,
>>> and you're free to leave anytime you want.
>>>
>>
>> This behavior is not befitting Gentoo leadership. Limiting commentary to
>> a walled garden outside Gentoo control violates one of our goals
>> (independence), and the incendiary retorts are no more mature than the
>> behavior you're criticizing. Nothing will change in the way people
>> respond to you until you learn how to treat others.
>>
>> By all means, I'm glad we're seeing some action on which tags to settle
>> with. It's been a mess of confusion ("which tags do I use? Will this
>> tick someone off?", etc), and will be easier to build on once we figure
>> out the tags that'll work best. It'll be awesome to get automatic bug
>> closing from a commit, and I suspect it'll bring a lot of good. Settling
>> on tags allows us to automate more. However, as a Council member, the
>> Gentoo community looks to you and your behavior as an example. Is this
>> the example you want to set for our community?
>>
>> On the GitHub Issue, you called this mailing list "completely useless"
>> [1], and then you sent your message above a little later. Would you want
>> to work with someone who talks to you the way you treated Rich?
> 
> Yes, I did call it useless *multiple times*, and I've pointed out
> the problems. Considering they were ignored and the quality of
> the mailing list hasn't improved, this statement still stands.
> 
> Rich should have talked to me if he had problems with understanding my
> comment or missed the context to it. What he did instead is beginning
> a public stone throwing session. This is not a kind of behavior I am
> going to accept, or respond kindly to.
> 
> It's elementary. If you have a problem with me, talk to me first. Not go
> pointing fingers and shouting 'this person is bad'.

That's a good policy, one most of us can agree with I think. Sarcasm
isn't often understood (or appreciated) by all, but Rich's comment
really didn't do anything except highlight how discussion was being
mo

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

2017-09-10 Thread Daniel Campbell
On 09/09/2017 12:47 AM, Michał Górny wrote:
> W dniu pią, 08.09.2017 o godzinie 17∶19 -0400, użytkownik Rich Freeman
> napisał:
>> On Tue, Jul 25, 2017 at 4:05 AM, Michał Górny <mgo...@gentoo.org> wrote:
>>>
>>> What do you think about it? Is there anything else that needs being
>>> covered?
>>>
>>
>> FYI - if anybody does want to make any comments on the proposed
>> devmanual changes to implement the new tags please comment at:
>>
>> https://github.com/gentoo/devmanual.gentoo.org/pull/72
>>
>> For that matter, if you want to even know what the proposed changes
>> are you should also visit the link.
>>
>> List replies seem to be discouraged.
>>
>> I realize that some prefer to limit comments to media that are purely
>> open source.  I guess the FOSS Linux kernel provided /dev/null still
>> exists as an alternative.  Honestly, I'm not sure which of the options
>> are more likely to get read.
>>
> 
> TL;DR: Rich, I would really appreciate if you stopped the flamebaits.
> I understand that you think you're doing Gentoo a favor but you're not.
> 
> The footers were discussed to death in this very thread. I've heard your
> opinions. However, as far as I'm concerned (and as I've pointed out) you
> did literally *nothing* to push your ideas forward for 2+ years.
> 
> Since I've done all the work, I've did it my way and for the reasons
> I've explained multiple times. If you disagree, them I'm sorry but
> in life you don't get to have everything your way. Especially if all you
> do is complain and expect others to do the work for you.
> 
> I understand that you're unhappy and since you have no valid arguments,
> all you can do is try to get more people to support you and shout.
> Revive the bikeshed as many times as possible, try to make a lot of
> noise and block changes. Worst case, you've blocked something you didn't
> like. Best case, you're finally get others so discouraged that they'll
> do things your way just so that you stop.
> 
> Rich, this is not a kindergarten. It's time you learn to lose,
> and accept the consequences. If you can't do that, the door out is open,
> and you're free to leave anytime you want.
> 
This behavior is not befitting Gentoo leadership. Limiting commentary to
a walled garden outside Gentoo control violates one of our goals
(independence), and the incendiary retorts are no more mature than the
behavior you're criticizing. Nothing will change in the way people
respond to you until you learn how to treat others.

By all means, I'm glad we're seeing some action on which tags to settle
with. It's been a mess of confusion ("which tags do I use? Will this
tick someone off?", etc), and will be easier to build on once we figure
out the tags that'll work best. It'll be awesome to get automatic bug
closing from a commit, and I suspect it'll bring a lot of good. Settling
on tags allows us to automate more. However, as a Council member, the
Gentoo community looks to you and your behavior as an example. Is this
the example you want to set for our community?

On the GitHub Issue, you called this mailing list "completely useless"
[1], and then you sent your message above a little later. Would you want
to work with someone who talks to you the way you treated Rich?

None of this bickering is motivating or inspiring to those who read it,
and leadership should know better than to stoop to this level publicly.
You will not get more developer activity, agreement, cooperation, or
contribution by berating your fellow developers. In fact, Gentoo is
known for its bickering developer community. You are in a position to
change that. You asserted in #gentoo-trustees that the Council *is*
Gentoo's leadership.

Is this your brand of leadership?

~zlg

[1] https://dev.gentoo.org/~zlg/useless.png

(screenshotted since GitHub conversations can be curated.)
-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New package neomutt

2017-08-17 Thread Daniel Campbell
On 08/17/2017 12:48 AM, Michał Górny wrote:
> W dniu śro, 16.08.2017 o godzinie 22∶07 -0700, użytkownik Daniel
> Campbell napisał:
>> On 08/10/2017 01:10 AM, Michał Górny wrote:
>>> On czw, 2017-08-10 at 09:54 +0200, Fabian Groffen wrote:
>>>> On 10-08-2017 09:40:30 +0200, Michał Górny wrote:
>>>>> On czw, 2017-08-10 at 06:58 +0200, Nicolas Bock wrote:
>>>>>> On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I would like to add neomutt to the tree. This new package is meant as 
>>>>>>> an alternative and not a replacement of the existing mutt package.
>>>>>>
>>>>>> Thanks for all of the great suggestions and feedback!
>>>>>>
>>>>>> This is round two. I have update the ebuild with all your 
>>>>>> suggestions. I have also added support for eselecting between mutt 
>>>>>> and neomutt. Before the eselect ebuild can land though, we need to 
>>>>>> rename the mutt binary so that the managed link can be called 
>>>>>> mutt.
>>>>>
>>>>> What for? How many people are exactly in the dire need of having both
>>>>> installed simultaneously and switching between them? If you really can't
>>>>> learn to type the new command, add IUSE=symlink blocking original mutt
>>>>> and be done with it. Don't add more unowned files to /usr by another
>>>>> poorly written eselect module.
>>>>
>>>> Be nice!  No need to be bitchy here (and in the rest of your review).
>>>> Nicolas is just trying.
>>>>
>>>> Me, as maintainer of Mutt, thought it was a good idea, because it allows
>>>> people to easily have both installed at the same time, which in this
>>>> interesting time for both projects is not a weird thing to have.
>>>
>>> I don't see how eselect helps that. People can just run neomutt by
>>> typing... neomutt, right? It works without the symlink, right?
>>>
>>>> If there is a policy/move to get rid of eselect, then sorry, I am not
>>>> aware of that.  I can live with a symlink USE-flag.  It doesn't seem
>>>> very elegant to me, but it would work for this scenario.
>>>>
>>>
>>> The move is against orphaned files in /usr that are randomly changed by
>>> runtime tools rather than the package manager.
>>>
>>
>> Then how do we explain the reasoning for the other 50 or so eselect
>> modules? No doubt at least a handful of them modify symlinks in /usr,
>> and have similarly few options to choose from, such as eselect-vi.
>> Should we remove those as well?
>>
> 
> Mistakes of the past are no excuse to commit more mistakes. You should
> know that because I had to repeat this many times. Some of the eselect
> modules have been fixed since then giving major improvements (see:
> eselect-opengl).
> 

I can agree with that, but you seemed opposed to the entire idea of an
eselect module for upstreams that own the same file; e.g. neomutt being
a drop-in replacement for mutt. Are you instead opposing a
cobbled-together eselect module? What would it take to ensure the RO
/usr use-case could be supported while simultaneously allowing easy
switching? Does eselect-opengl support RO /usr? If not, then it's a
little unreasonable to expect other modules to do it since you pointed
to it as a good example.

What is your true opinion?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New package neomutt

2017-08-16 Thread Daniel Campbell
On 08/10/2017 01:10 AM, Michał Górny wrote:
> On czw, 2017-08-10 at 09:54 +0200, Fabian Groffen wrote:
>> On 10-08-2017 09:40:30 +0200, Michał Górny wrote:
>>> On czw, 2017-08-10 at 06:58 +0200, Nicolas Bock wrote:
>>>> On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote:
>>>>> Hi,
>>>>>
>>>>> I would like to add neomutt to the tree. This new package is meant as 
>>>>> an alternative and not a replacement of the existing mutt package.
>>>>
>>>> Thanks for all of the great suggestions and feedback!
>>>>
>>>> This is round two. I have update the ebuild with all your 
>>>> suggestions. I have also added support for eselecting between mutt 
>>>> and neomutt. Before the eselect ebuild can land though, we need to 
>>>> rename the mutt binary so that the managed link can be called 
>>>> mutt.
>>>
>>> What for? How many people are exactly in the dire need of having both
>>> installed simultaneously and switching between them? If you really can't
>>> learn to type the new command, add IUSE=symlink blocking original mutt
>>> and be done with it. Don't add more unowned files to /usr by another
>>> poorly written eselect module.
>>
>> Be nice!  No need to be bitchy here (and in the rest of your review).
>> Nicolas is just trying.
>>
>> Me, as maintainer of Mutt, thought it was a good idea, because it allows
>> people to easily have both installed at the same time, which in this
>> interesting time for both projects is not a weird thing to have.
> 
> I don't see how eselect helps that. People can just run neomutt by
> typing... neomutt, right? It works without the symlink, right?
> 
>> If there is a policy/move to get rid of eselect, then sorry, I am not
>> aware of that.  I can live with a symlink USE-flag.  It doesn't seem
>> very elegant to me, but it would work for this scenario.
>>
> 
> The move is against orphaned files in /usr that are randomly changed by
> runtime tools rather than the package manager.
> 

Then how do we explain the reasoning for the other 50 or so eselect
modules? No doubt at least a handful of them modify symlinks in /usr,
and have similarly few options to choose from, such as eselect-vi.
Should we remove those as well?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


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

2017-08-16 Thread Daniel Campbell
On 08/14/2017 03:39 PM, William L. Thomson Jr. wrote:
> On Mon, 14 Aug 2017 15:20:26 -0700
> Rich Freeman <ri...@gentoo.org> wrote:
> 
>> On Mon, Aug 14, 2017 at 5:26 PM, William L. Thomson Jr.
>> <wlt...@o-sinc.com> wrote:
>>>
>>> Portage supports sets, but the PMS has no mention. Then there is
>>> debate on what they are. Creating so much noise it drowns the bug
>>> request and makes it invalid. Despite the need still existing, and
>>> PMS lacking anything on  sets.
>>> https://bugs.gentoo.org/show_bug.cgi?id=624300
>>>
>>> Just the needs I have with portage are stalled, marked as invalid.
>>> No discussion for inclusion in PMS. Like documenting sets.  
>>
>> Ah, well, that's the main mystery of this thread solved.  Thanks.
> 
> That is the tip of the iceberg, not the main problem itself. I have
> never been a fan of EAPI, or the resulting PMS, etc. Having been around
> before such existed, I do not believe it has helped Gentoo and in fact
> maybe the opposite. Why EAPI 0 stuff is in tree, or very old EAPIs.
> 
> Now becoming more real issues rather than just a dislike of EAPI.
> 
I'm unaware of any other way to introduce progressive changes to an API
without literally rewriting every ebuild. Versioned APIs are good APIs,
and give developers (both inside and outside Gentoo) something they can
depend on and, most importantly, predict. If there was just one EAPI,
you'd need to consult git log or some other construct to figure out the
API version an ebuild was written against.

The fact we still have older EAPI ebuilds is one of manpower and
(dis)interest. I don't see anyone trying to prevent (or encourage) EAPI
upgrading across the tree. Generally, we wait until a package needs a
revbump/version bump and/or has serious breakage (and thus needing a
rewrite) before bumping EAPI. Some jumps in EAPI, for simple packages,
are painless. Others are a nightmare.

I see no other way to support the 1m+ ebuilds that have been written
since Gentoo's inception in an unambiguous, reference-able way. In fact,
I'd argue if you don't version your APIs, you're not designing them
correctly. APIs *will* change; building a version number into the API
ensures the consumers of said API are aware of changes.

That said, yes, it'd be nice if every ebuild was EAPI 6, but that is a
hge amount of work that nobody seems interested in, for questionable
gain. The work would just be repeated when the next EAPI is approved.
The way it works now is more organic and better representative of the
state of Gentoo development, for better or worse.

It's good to see you taking part in constructive discussions! That's not
intended as sarcasm. I mean it. Thanks for taking part.

~zlg

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Revisions for USE flag changes

2017-08-16 Thread Daniel Campbell
On 08/13/2017 03:11 AM, Michael Orlitzky wrote:
> On 08/12/2017 10:52 PM, Duncan wrote:
>>
>> How so?  Are you arguing that deciding to system-wide switch to/from 
>> pulseaudio, systemd, or gstreamer is nonsense?
>>
> 
> The meaning of any one USE flag varies widely across packages. I could
> never say "I want to enable USE=gstreamer" for every package in the
> tree, because I have no idea what it does for most of them. Setting
> USE=whatever globally essentially means "make random changes to my
> system" -- hence my wording.
> 
> The meaning of a USE flag is per-package, so per-package is the only
> meaningful way to set them.
> 
There are USE flag situations that are relevant at the global level.
systemd, pulseaudio, alsa, gstreamer, openssl/libressl, libav/ffmpeg,
vim-syntax, and so on. Then there's USE_EXPAND variables, which might
mean different things in different packages and yet I see nothing in
your argument covering them.

These flags make perfect sense at the global level, because users
generally want support for the choices they make, and they make choices
on that *general* level first, before diving into package-specific USE
flags. It's a monumental waste of developer and user time to manually
set major USE flags in every relevant package. Some people are picky and
will still do that, but global USE ensures that certain assumptions are
made about your system. If you don't want assumptions, don't use global
USE. There's no reason to deprive others of functionality you don't
personally agree with or use.

Granted, some flags don't belong in make.conf. But part of Gentoo's
beauty is that we *do* let users proverbially saw their leg off, if
that's what they really want. There are lots of use cases that would be
made ridiculous in scope if we got rid of global USE. Is your only
answer a megabyte-long p.use file?

That said, I like your idea of clearing up revbump decisions and the
angle of reducing development burden. This particular idea comes at too
high a cost for my taste, as we stand to lose functionality rather than
improve or gain it.

~zlg
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Package up for grabs

2017-08-07 Thread Daniel Campbell
On 08/06/2017 02:27 AM, tom...@gentoo.org wrote:
> Quoting Daniel Campbell (2017-07-31 04:16:30)
>> On 07/19/2017 02:33 AM, Amy Liffey wrote:
>>> The following package is up for grabs:
>>>
>>> dev-lang/gforth
>>>
>>> Best regards,
>>> Amy Liffey
>>>
>> I can take this one; I'd hate to see Forth support go missing on Gentoo.
>> I'm open to co-maintainers as well.
>>
> Ok, as I have done some quite Forth programming in the past, let me step in.
> 
> Thomas
> 
>> ~zlg
>>
>> -- 
>> Daniel Campbell - Gentoo Developer
>> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
>> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
>>
> 
> 
Sounds great. Would you like me to do the honors of updating
metadata.xml later tonight?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Package up for grabs

2017-07-30 Thread Daniel Campbell
On 07/19/2017 02:33 AM, Amy Liffey wrote:
> The following package is up for grabs:
> 
> dev-lang/gforth
> 
> Best regards,
> Amy Liffey
> 
I can take this one; I'd hate to see Forth support go missing on Gentoo.
I'm open to co-maintainers as well.

~zlg

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Package up for grabs

2017-07-30 Thread Daniel Campbell
On 07/23/2017 07:13 AM, Manuel Rüger wrote:
> The following packages are up for grabs:
> 
> app-admin/gixy
> app-admin/mei-amt-check
> app-admin/ngxtop
> app-admin/passwordsafe
> app-arch/lz5
> app-crypt/acme
> app-crypt/certbot
> app-crypt/certbot-apache
> app-crypt/certbot-nginx
> app-crypt/easy-rsa
> app-crypt/libmd
> app-crypt/manuale
> app-crypt/pgpdump
> app-emulation/docker-gc
> app-misc/jira-cli
> app-misc/pdfpc
> app-text/blahtexml
> app-text/itex2mml
> app-text/mathtex
> dev-go/cli
> dev-go/delve
> dev-go/go-gitlab-client
> dev-go/glide
> dev-go/toml
> dev-python/parsley
> dev-python/safety
> dev-python/txsocksx
> dev-python/vcversioner
> dev-libs/libgit2
> dev-lua/luadbi
> dev-lua/luasocket
> dev-lua/lua-zlib
> dev-util/bloaty
> dev-util/cookiecutter
> net-analyzer/linkchecker
> net-libs/libssh2
> net-misc/kafkacat
> x11-misc/flow-pomodoro
> x11-plugins/pidgin-opensteamworks
> x11-plugins/pidgin-xmpp-receipts
> 
> There is another set of packages, which have a backup project
> maintaining it. Please talk to the respective project if you're
> interested in maintaining those:
> 
> app-office/texstudio
> dev-python/cookies
> dev-python/freezegun
> dev-python/future
> dev-python/hiro
> dev-python/hvac
> dev-python/parsedatetime
> dev-python/parsley
> dev-python/pyhcl
> dev-python/pykka
> dev-python/pyrfc3339
> dev-python/pytest-capturelog
> dev-python/pytest-localserver
> dev-python/responses
> dev-python/vcrpy
> dev-python/zope-component
> dev-python/zope-event
> net-firewall/nftables
> net-libs/libnftnl
> 
> Best regards,
> Manuel Rüger
> 
> 
I have a machine using certbot (Rpi 3 Model B) now that I might be
switching to Gentoo in the future. I'd be willing to co-maintain
app-crypt/certbot with other interested developers. The catch is I don't
use Apache or nginx; others would need to maintain certbot-apache and
certbot-nginx.

Anyone interested?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


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

2017-07-28 Thread Daniel Campbell
On 07/28/2017 12:44 PM, Alec Warner wrote:
> 
> 
> On Fri, Jul 28, 2017 at 3:44 AM, Andreas K. Huettel
> <dilfri...@gentoo.org <mailto:dilfri...@gentoo.org>> wrote:
> 
> Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
> >
> > I hold a perhaps radical view: I would like to simply remove stable.
> >
> > I continue to feel that maintaining two worlds (stable+unstable)
> > carries with it an unneccessary cost.
> >
> 
> That's not feasible. It would kill off any semi-professional or
> professional
> Gentoo use, where a minimum of stability is required.
> 
> 
> So my argument (for years) has been that this is the right thing all along.
> 
> If people want a stable Gentoo, fork it and maintain it downstream of
> the rambunctious rolling distro. 
>  
> 
> 
> (Try keeping ~10 machines on stable running without automation.
> That's already
> quite some work. Now try the same with ~arch. Now imagine you're
> talking about
> 100 or 1000 machines.)
> 
> --
> Andreas K. Hüttel
> dilfri...@gentoo.org <mailto:dilfri...@gentoo.org>
> Gentoo Linux developer (council, perl, libreoffice)
> 
> 
Why would we replicate that when Arch has been in that cavalier role for
over a decade? Stability is important to all users; some simply have a
lower tolerance for faults. It also gives us a reliable "product" for
others to rely on or even dogfood. I personally run on ~arch, but if I
were to put a friend on Gentoo, I'd want something that will be pretty
easy-going until they learn the skills to take on ~arch, bug reports, etc.

For many -- especially developers -- stable is only a letter away from
"stale", and that's fine. Some run mixed keywords, or go full ~arch. One
of the core values of Gentoo is choice; why take away the stable choice?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow

2017-07-27 Thread Daniel Campbell
On 07/26/2017 10:05 AM, Kristian Fiskerstrand wrote:
> On 07/25/2017 02:28 PM, Michael Palimaka wrote:
>> Does a bug # really need to always be in the summary line? It can eat
>> valuable characters and tags which are pretty popular are equally valid IMO.
> 
> I would prefer the summary to be informative without having bug ID at
> all. Summary should describe the change  ,not only "fixes XXX", the bug
> reference belongs in body (tags)
> 
+1. I tend to add bug numbers in my summary, but it makes it very
challenging to put something meaningful into the remaining characters.
We already put 'category/pkg:' or 'dir/file:' for a prefix. Adding 6 or
7 characters to that already considerable deficit cuts ~15% of git's
recommended 50 characters, or 10% of our proposed 70.

Pushing this out to a tag -- and standardizing it -- will only improve
maintenance and speed up our onboarding process.


"Bug: xx" isn't my favorite since it requires tooling to actually
visit said bug (and doesn't clarify which bug platform to reference),
but a URL uses more bytes and infra may change. It's a tough choice, but
if we can find something that fits enough use cases, tooling shouldn't
be too difficult to write to make up for it. I already use a `bgo`
keyworded shortcut in Pale Moon to make bug searching faster; adding
another to navigate straight to a bug wouldn't be much trouble.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


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

2017-07-25 Thread Daniel Campbell
On 07/25/2017 06:22 AM, Rich Freeman wrote:
> On Tue, Jul 25, 2017 at 9:10 AM, Michael Palimaka <kensing...@gentoo.org> 
> wrote:
>>
>> The 30 day waiting period is useful for smoking out major upstream bugs,
>> but can't replace stabilisation integration testing. For example,
>> package foobar may build fine in ~arch but fails in stable because it
>> needs a newer libbaz.
>>
> 
> I think this is a good reason why everything should be at least
> build-tested on a stable tree before getting stabilized.  Now, that
> might not be on each arch if it is truly arch-independent (and if
> arches keep the dependencies reasonably in sync).
> 
> This might be a situation where a compromise could exist.  Have some
> kind of flag (in metadata, or maybe the ebuild) that indicates that
> the maintainer believes the package is low-risk to stabilize purely on
> a build test.  Then after 30 days in testing a tinderbox could
> build-test the package and stabilize it automatically.
> 
> If the package is considered at-risk then it goes through manual
> testing, either by the maintainer or an arch team.
> 
> This will also encourage the teams doing testing to actually do more
> testing on the packages that would benefit from it.
> 
> We wouldn't set hard criteria but leave it up to maintainer
> discretion, with a guideline being that past performance is probably a
> good predictor of future results.
> 
This reads like a practical use of both developer time and machine time.
Build testing at a minimum, imo, is necessary if the word "stable" is
going to mean anything for us. So +1.

Since there are bound to be fewer manually tested packages than
automatic "it builds, ship it" packages, I think it would make a bit
more sense to add a "manually test this please" tag to metadata.xml,
rather than expect auto-stabilizers to have additional tags, which will
outnumber the manual packages and inflate the size of the tree (albeit
slightly).

Since maintainers also manage their packages in various ways, could we
extend this to a general  element? Maintainers can specify how
they'd prefer bugs or commits to be done, and an additional element to
indicate hand-testing. This would solve two problems instead of just
one: indicate a package is ready for auto-stabilization, and give a
single, canonical location for a maintainer to put maintenance policy.

Just my 2¢,

~zlg
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] vim-syntax USE flag

2017-07-22 Thread Daniel Campbell
On 07/22/2017 01:27 PM, Mike Gilbert wrote:
> Packages currently handle installation of vim syntax support files
> inconsistently. Some builds install the files if the "vim-syntax" USE
> flag is enabled, while others install them unconditionally.
> 
> Do these files fall into the "small text files" category for
> unconditional installation? If so, we should probably phase out the
> vim-syntax USE flag.
> 
> If we want to keep the USE flag, I would suggest documenting a global
> policy regarding its use. Should that live in the devmanual? Or maybe
> the Vim project page?
> 

I agree, a global policy should be established; whether it's "install
unconditionally" like we do with systemd units, openrc daemons, etc, or
a global USE. I'm unaware of any way to misinterpret what "vim-syntax"
means, and Vim itself already has a place it expects such files to go.
Installing a package without this USE flag requires a rebuild to get the
syntax file(s), so that's another reason to go unconditional. I have the
USE flag set globally and it hasn't created any blockers, so maybe it's
safe.

As for where documentation goes, I would expect a brief paragraph in the
devmanual mentioning the USE flag and linking to the Vim project page
that better explains usage and expectations. That way, changes in the
Vim project's way of development wouldn't require big rewrites in the
devmanual.

If we're shipping syntax for other editors as well, perhaps it's
deserving of its own devmanual page. Do we have a problem with
developers not shipping syntax files? (vim or otherwise)

--semi-offtopic--

When I first began using Gentoo in 2012, I was annoyed that Vim
remembered my cursor position for every file I opened. It took some
hunting to locate where this was set (/etc/vim/vimrc, owned by
app-editors/vim-core for the curious) and correct it with

g:leave_my_cursor_position_alone = 1

in my vimrc.

If we could document Gentoo-added Vim features like that, it'd be less
trouble for our newer users to configure Vim to their tastes. I
understand we're not a newbie distro, but unexpected behavior can be a
PITA to track down without documentation or trawling through `:script`
output. Searching the Web, our wiki, and even our GitHub account turned
up zero helpful results for this particular thing.

If the Vim team needs the help, I'd be glad to lend a hand where needed.

(also cc'ing vim@ to get an official opinion)
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


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

2017-07-11 Thread Daniel Campbell
On 07/11/2017 01:57 PM, William L. Thomson Jr. wrote:
> On Tue, 11 Jul 2017 13:27:57 -0700
> Daniel Campbell <z...@gentoo.org> wrote:
> 
>> On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote:
>>> On Mon, 10 Jul 2017 19:22:47 -0400
>>
>>> A rule for portage could be;
>>>
>>>  - If the package is not in world and already installed. Do not add
>>> the package to world. If you are re-emerging a package already
>>>installed. You do not have to use the -1 option. 
>>>
>>> I have polluted so many world files with system packages and/or
>>> dependencies I re-emerged directly without -1. Those IMHO should
>>> never have been recorded to that file. They were brought in by
>>> other things. Only things in my world should be packages merged
>>> directly, not from profile, set, or a dep.
> 
>> Portage's fault. If you don't want a package added to a set or world,
>> you'll need to use the -1 (--oneshot) option.
> 
> Did you even read above? I clearly state WITHOUT -1 option
> 
>> I added it to my default
>> emerge options in make.conf for exactly that reason (clean world);
> 
> The point is people should not have to do such. Or remember to always
> use -1 when re-emerging a dep, system, world, or set package.
> 
>> though, I have to be careful and make sure packages I care about are
>> in a set somewhere or --depclean will wipe'em out. In short, Portage
>> won't stop you from shooting yourself in the foot.
> 
> If those package are in your world file portage will not remove on
> depclean.
> 
>> If you decide you want to add a package to world without re-merging
>> it, -n (--noreplace) will do the job.
> 
> Or you can add it to the world file, or your profile/packages
> in /etc/portage, etc. There are other places, one does not have to
> emerge every package then want in world. Just the same it should not
> add stuff just the same from system, world,  sets, or deps of any of
> those 3.
> 
>> That said, having helpful messages is a good addition, but needs to be
>> done in a way that is unambiguous and gives the user a clear solution.
> 
> So now it must be clear to the user? That is the entire point I am
> making. The output now is not clear... But in improving such now there
> is concern over something no one cares about now Funny stuff!!!
> 

I understand where you're coming from, I just thought to give a few tips
to make life a bit easier for you since it works out pretty well for
myself. I think your idea has merit, just unsure of where the
functionality goes, since I'm not a Portage developer.

I think the hard part of implementing this will be detecting whether a
command-line-given package is (a) in a set/profile/world and (b) part of
a dependency tree (i.e. shouldn't be removed).

-c already traverses the dependency tree. This one message may mean
iterating through the list of candidate packages and comparing them
against a set/profile/world *per package*, unless the vdb/cache makes
this lookup cheap in terms of cycles. The message would be helpful,
though again, eix-test-obsolete might be the right tool to build that
feature into. I'd be interested in following the bug discussion, if
you've already filed it.

If you're really interested in the message from -C, it could be done by
checking the argument list for packages in sets or profiles. But it's
going to incur similar overhead that -c has because it necessarily has
to check some sort of list before producing the message.

I do not think this message belongs in -C output, however; -C is
intentionally meant for operations where you don't care what happens to
the dependency tree. Sometimes that's good (resolving a blocker the hard
way), sometimes it's bad (removing gcc on a whim). Warnings won't stop a
user doing that, because --unmerge is already documented with the
caveat. There must be a certain point where we as developers have to say
"You're on your own," or there will be so many rails and training wheels
that it loses value for the more experienced users, or a bunch of bugs
filed over failing to heed documentation, i.e. PEBKAC. I think -C is a
great place to draw that line.

The best way to get the ball rolling is file a feature request against
Portage and see what 'upstream' has to say. In the meantime, maybe try
your hand at hacking it. I've found people are a lot more receptive to
suggestions when you've already attempted to provide it. Even if the
solution is crap, people seem willing to help those who have the
gumption to help themselves.

Please don't interpret this e-mail as aggressive or dismissive. I'm
simply trying to offer explanation and guidance to help you make this
happen. It's clear that you care about it, so I'm sure there's a way for
this to go forward.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


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

2017-07-11 Thread Daniel Campbell
On 07/11/2017 01:27 PM, Daniel Campbell wrote:
> On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote:
>> On Mon, 10 Jul 2017 19:22:47 -0400
>> "William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
>>>
>>> That part does not require it to resolve deps. Just check world file,
>>> assuming its correct. Though could be thrown off if say gcc, or
>>> another was in the world file. I think the profile or set would catch
>>> that as it does now and generate a warning, regardless.
>>
>> Speaking of gcc in the world file. I think portage should STOP adding
>> packages that are in the profile or a dep to world. If you merge a
>> package as part of a set, I am pretty sure it does not get recorded to
>> world, need to confirm, could be wrong.
>>
>> A rule for portage could be;
>>
>>  - If the package is not in world and already installed. Do not add the
>>package to world. If you are re-emerging a package already
>>installed. You do not have to use the -1 option. 
>>
>> I have polluted so many world files with system packages and/or
>> dependencies I re-emerged directly without -1. Those IMHO should never
>> have been recorded to that file. They were brought in by other things.
>> Only things in my world should be packages merged directly, not from
>> profile, set, or a dep.
>>
>> I will file a bug on that as well.
>>
> Whether Portage adds a package to a set or world file is dependent on
> how you invoke emerge. Some people (like me) include sets as part of
> their world, via /var/lib/portage/world_sets . At that point, sets added
> to that file are basically treated as the world package list.
> 
> If gcc or other @system packages end up in your world, it's not
> Portage's fault. If you don't want a package added to a set or world,
> you'll need to use the -1 (--oneshot) option. I added it to my default
> emerge options in make.conf for exactly that reason (clean world);
> though, I have to be careful and make sure packages I care about are in
> a set somewhere or --depclean will wipe'em out. In short, Portage won't
> stop you from shooting yourself in the foot.
> 
> If you decide you want to add a package to world without re-merging it,
> -n (--noreplace) will do the job.
> 
> I'm not sure if eix-test-obsolete (from app-portage/gentoolkit) will
> catch a @system atom inside a set/world file, but that's where I'd
> expect such a notification to come from. The tool can help clean up
> unneeded entries in /etc/portage files, and would be a good fit for this
> particular issue.
> 
> That said, having helpful messages is a good addition, but needs to be
> done in a way that is unambiguous and gives the user a clear solution.
> 
> Hope this helps,
> 
> zlg
> 
Whoops.

s/gentoolkit/eix/

Sorry for the spam.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


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

2017-07-11 Thread Daniel Campbell
On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote:
> On Mon, 10 Jul 2017 19:22:47 -0400
> "William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
>>
>> That part does not require it to resolve deps. Just check world file,
>> assuming its correct. Though could be thrown off if say gcc, or
>> another was in the world file. I think the profile or set would catch
>> that as it does now and generate a warning, regardless.
> 
> Speaking of gcc in the world file. I think portage should STOP adding
> packages that are in the profile or a dep to world. If you merge a
> package as part of a set, I am pretty sure it does not get recorded to
> world, need to confirm, could be wrong.
> 
> A rule for portage could be;
> 
>  - If the package is not in world and already installed. Do not add the
>package to world. If you are re-emerging a package already
>installed. You do not have to use the -1 option. 
> 
> I have polluted so many world files with system packages and/or
> dependencies I re-emerged directly without -1. Those IMHO should never
> have been recorded to that file. They were brought in by other things.
> Only things in my world should be packages merged directly, not from
> profile, set, or a dep.
> 
> I will file a bug on that as well.
> 
Whether Portage adds a package to a set or world file is dependent on
how you invoke emerge. Some people (like me) include sets as part of
their world, via /var/lib/portage/world_sets . At that point, sets added
to that file are basically treated as the world package list.

If gcc or other @system packages end up in your world, it's not
Portage's fault. If you don't want a package added to a set or world,
you'll need to use the -1 (--oneshot) option. I added it to my default
emerge options in make.conf for exactly that reason (clean world);
though, I have to be careful and make sure packages I care about are in
a set somewhere or --depclean will wipe'em out. In short, Portage won't
stop you from shooting yourself in the foot.

If you decide you want to add a package to world without re-merging it,
-n (--noreplace) will do the job.

I'm not sure if eix-test-obsolete (from app-portage/gentoolkit) will
catch a @system atom inside a set/world file, but that's where I'd
expect such a notification to come from. The tool can help clean up
unneeded entries in /etc/portage files, and would be a good fit for this
particular issue.

That said, having helpful messages is a good addition, but needs to be
done in a way that is unambiguous and gives the user a clear solution.

Hope this helps,

zlg
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] taking a break from arches stabilization

2017-07-11 Thread Daniel Campbell
On 07/10/2017 10:22 AM, Agostino Sarubbo wrote:
> Hi all.
> 
> every time that I attach my tmux session to see what happens on irc, I always 
> see the same discussion about the 'minor' arches status.
> Since I joined gentoo(2011) I worked on all arches except hppa, I put more 
> effort in amd64 and less where I saw other people work on it (arm,alpha)
> But every time the magic phrase is that those arches are unmaintained.
> 
> Now, since I work on these arches just to help, i.e. I don't have any 
> business 
> and I do non have any installation of those arches and the work I'm doing is 
> not appreciated at all I decided to stop for now.
> If your dream is to put sparc and ia64 to ~arch, go ahead, I have no 
> objections.
> I will take a break also from amd64 and x86...let's see how things will 
> change.
> 
Thanks for your efforts in stabilization. I try to make it a point to
thank people like you and Toralf since stabilization and arch testing
are both time-consuming, and probably frustrating to get the tooling
correct.

Take some time off! I'm sure Gentoo won't implode. :)

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Sets vs Meta ebuilds

2017-07-09 Thread Daniel Campbell
On 07/09/2017 06:53 AM, William L. Thomson Jr. wrote:
> On Sun, 9 Jul 2017 00:42:46 -0700
> Daniel Campbell <z...@gentoo.org> wrote:
> 
>>>  - Sets used in profiles cannot have use expansion, versions or
>>> anything beyond cat/pkg.  
>> This would break some set behavior, at least in Portage. Specifying a
>> single version (or better, a slot) in a set is less work than adding
>> lines to p.mask *and* the set file(s), and p.mask doesn't appear to
>> support "!=cat/pkg-1.0" syntax to mimic the same functionality
>> achieved by a versioned atom in a set. It also makes sense to put
>> packages you want in a set instead of a mask. ">=" or "<=" may be
>> adequate if you only want one slot or version installed, but the
>> entire point of slots is to allow multiple versions to be installed
>> simultaneously. Versioned package names in sets achieve this.
> 
> Valid point, and along those lines to make the rules for sets in
> profiles easier.
> 
> - Sets in profiles can contain anything that is valid in a
>   profile/packages file, less the * symbol.
> 
> I think that addresses both versions and slots. The rest, like use
> expansion I believe is handled via package.use in profiles and not in
> packages.
> 

Yeah, that could work. As convenient as it is to mix USE flags with
sets, there's a better place to put it and I'm unsure of any situation
that would require more than two lines (one in the set, one in p.use) to
achieve a given USE constraint.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Sets vs Meta ebuilds

2017-07-09 Thread Daniel Campbell
On 07/08/2017 06:23 PM, William L. Thomson Jr. wrote:
> On Sun, 9 Jul 2017 01:10:11 +0100
> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> 
>> On Sat, 8 Jul 2017 19:58:13 -0400
>> "William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
>>> On Sun, 9 Jul 2017 00:49:57 +0100
>>> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:  
>>>> On Sat, 8 Jul 2017 19:39:33 -0400
>>>> "William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
>>>>> The two ways are not the same, and there is a reason sets exist
>>>>> in the first place. People seem to be over looking that fact. I
>>>>> did not add sets. They are not new.  I am simply trying to
>>>>> expand their use.  
>>>>
>>>> Sets exist because people keep saying "let's have sets!" without
>>>> agreeing on what sets actually are or how they are to be used.
>>>
>>> Do they need to agree? Isn't Gentoo about choice? Maybe your use of
>>> sets is different from mine. Is that not acceptable to have
>>> choice?  
>>
>> Well yes, they do need to agree, because otherwise when two different
>> developers put sets in a profile expecting different effects, then at
>> least two developers are going to end up confused, disappointed, and
>> quite probably breaking user systems.
> 
> Valid points, so basically need a set of guidelines or rules for sets
> used in profiles. Which should not be that complex, as usage is minimal.
> Offhand, likely could be more;
> 
> - Sets used in profiles are "lists of packages" for users to
>   emerge/re-emerge, and as such should be minimal list only. Similar to
>   the contents of a profile/packages, less the * symbol.
> 
>  - Sets used in profiles cannot have use expansion, versions or anything
>beyond cat/pkg.
This would break some set behavior, at least in Portage. Specifying a
single version (or better, a slot) in a set is less work than adding
lines to p.mask *and* the set file(s), and p.mask doesn't appear to
support "!=cat/pkg-1.0" syntax to mimic the same functionality achieved
by a versioned atom in a set. It also makes sense to put packages you
want in a set instead of a mask. ">=" or "<=" may be adequate if you
only want one slot or version installed, but the entire point of slots
is to allow multiple versions to be installed simultaneously. Versioned
package names in sets achieve this.

> 
> - Sets should not have the same file listed, in that case inherit the
>   other set if using overlapping packages or split into smaller
> 


-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints

2017-07-08 Thread Daniel Campbell
On 07/08/2017 03:29 PM, Michał Górny wrote:
> On sob, 2017-07-08 at 15:21 -0700, Daniel Campbell wrote:
>> On 07/08/2017 02:43 AM, Michał Górny wrote:
>>> Hi, everyone.
>>>
>>> I think the affairs have settled enough and I've finished filling
>>> in the pre-GLEP for REQUIRED_USE auto-enforcing. It's got all
>>> the algorithms, rationale and separated reference implementation.
>>>
>>> If there are no major concerns raised, I will soon start working
>>> on writing an optimized implementation for pkgcore/pkgcheck
>>> and integrating the verification algos with the CI.
>>>
>>> The pre-GLEP for review is here:
>>>
>>> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse
>>>
>>> TIA.
>>>
>>
>> This has grown quite a bit since first recommended! Great job so far.
>> Forgive me if I missed something, but wouldn't it be helpful to the user
>> to let them know when automatically choosing for them? A single line in
>> a logfile, einfo output, whatever, would be useful for people wondering
>> how certain packages got pulled in. Users will continue to get errors if
>> the constraints aren't met (or are wrong), but where will information go
>> that indicates the automatic solver's choice? You and I can read an
>> ebuild and guess from the dep spec, but what will a user look at?
>>
>> I searched the GLEP page for "log", "einfo", and "output" with no
>> results. If I've missed something please let me know.
>>
>> Thanks for the work that's been put into this so far.
>>
> 
> Indeed I have entirely skipped the user output problem, and left it
> purely for package manager's design choice. Do you really feel like we
> need to explicitly specify it? I think it's best if package manager
> authors decide how to best fit it into whatever output the PMs already
> have.
> 
> 
I just considered it helpful, that's all. I hadn't considered the PMS
vs. PM devs perspective. Do we plan to support some way for users to get
such output from Portage?

Thanks for clarifying. It does make more sense to leave it to PM devs.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints

2017-07-08 Thread Daniel Campbell
On 07/08/2017 02:43 AM, Michał Górny wrote:
> Hi, everyone.
> 
> I think the affairs have settled enough and I've finished filling
> in the pre-GLEP for REQUIRED_USE auto-enforcing. It's got all
> the algorithms, rationale and separated reference implementation.
> 
> If there are no major concerns raised, I will soon start working
> on writing an optimized implementation for pkgcore/pkgcheck
> and integrating the verification algos with the CI.
> 
> The pre-GLEP for review is here:
> 
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse
> 
> TIA.
> 
This has grown quite a bit since first recommended! Great job so far.
Forgive me if I missed something, but wouldn't it be helpful to the user
to let them know when automatically choosing for them? A single line in
a logfile, einfo output, whatever, would be useful for people wondering
how certain packages got pulled in. Users will continue to get errors if
the constraints aren't met (or are wrong), but where will information go
that indicates the automatic solver's choice? You and I can read an
ebuild and guess from the dep spec, but what will a user look at?

I searched the GLEP page for "log", "einfo", and "output" with no
results. If I've missed something please let me know.

Thanks for the work that's been put into this so far.

~zlg

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] The status of grsecurity upstream and hardened-sources downstream

2017-06-23 Thread Daniel Campbell
On 06/23/2017 09:28 AM, Anthony G. Basile wrote:
> Hi everyone,
> 
> Since late April, grsecurity upstream has stop making their patches
> available publicly.  Without going into details, the reason for their
> decision revolves around disputes about how their patches were being
> (ab)used.
> 
> Since the grsecurity patch formed the main core of our hardened-sources
> kernel, their decision has serious repercussions for the Hardened Gentoo
> project.  I will no longer be able to support hardened-sources and will
> have to eventually mask and remove it from the tree.
> 
> Hardened Gentoo has two sides to it, kernel hardening (done via
> hardened-sources) and toolchain/executable hardening.  The two are
> interrelated but independent enough that toolchain hardening can
> continue on its own.  The hardened kernel, however, provided PaX
> protection for executables and this will be lost.  We did a lot of work
> to properly maintain PaX markings in our package management system and
> there was no part of Gentoo that wasn't touched by issues stemming from
> PaX support.
> 
> I waited two months before saying anything because the reasons were more
> of a political nature than some technical issue.  At this point, I think
> its time to let the community know about the state of affairs with
> hardened-sources.
> 
> I can no longer get into the #grsecurity/OFTC channel (nothing personal,
> they kicked everyone), and so I have not spoken to spengler or pipacs.
> I don't know if they will ever release grsecurity patches again.
> 
> My plan then is as follows.  I'll wait one more month and then send out
> a news item and later mask hardened-sources for removal.  I don't
> recommend we remove any of the machinery from Gentoo that deals with PaX
> markings.
> 
> I welcome feedback.
> 
Thanks for taking the time to let the greater Gentoo community know.
It's a shame things took this turn... Is there any hope of a fork
emerging from the drama? Why would a security-conscious group take their
toys and go home? Regardless, this is a loss for Linux as a whole. I
hope something springs up in its place.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs

2017-06-20 Thread Daniel Campbell
On 06/20/2017 05:53 AM, Pacho Ramos wrote:
> This packages are now up for grabs:
> dev-ml/fort
> media-libs/embree
> x11-wm/i3
> 
> 
I use i3-gaps these days, but if no-one else is willing, I'll take up i3
since it's close enough to i3-gaps to be considered mostly the same.
Dual maintainership is preferred.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] fdo-mime.eclass: Mark the eclass as deprecated

2017-06-19 Thread Daniel Campbell
On 06/19/2017 06:20 AM, Michał Górny wrote:
> The GNOME team has committed the xdg-utils.eclass serving exactly
> the same purpose as fdo-mime.eclass, supposedly with the goal of
> replacing it. However, it seems that they have never bothered to
> actually hint the deprecation in the fdo-mime.eclass in any way.
> As a result, developers are still adding references to this eclass
> instead of using xdg-utils or xdg, and/or not working towards replacing
> them.
> 
> Add an explicit deprecation notice to the fdo-mime.eclass to make it
> clear that the eclass should not be used in new packages, and what
> the replacement eclasses are.
> ---
>  eclass/fdo-mime.eclass | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/fdo-mime.eclass b/eclass/fdo-mime.eclass
> index b3b096d154e7..8e51d8a69df1 100644
> --- a/eclass/fdo-mime.eclass
> +++ b/eclass/fdo-mime.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2011 Gentoo Foundation
> +# Copyright 1999-2017 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: fdo-mime.eclass
> @@ -7,6 +7,8 @@
>  # @AUTHOR:
>  # Original author: foser <fo...@gentoo.org>
>  # @BLURB: Utility eclass to update the desktop mime info as laid out in the 
> freedesktop specs & implementations
> +# @DESCRIPTION:
> +# This eclass is DEPRECATED. Please use xdg-utils or xdg instead.
>  
>  # @FUNCTION: fdo-mime_desktop_database_update
>  # @DESCRIPTION:
> 
Looks good to me. Thanks for looking out for stuff like this.

That aside, isn't this supposed to be standard operating procedure if a
developer is deprecating an eclass? And similarly with the removal of an
eclass, all ebuilds getting updated by the developer or team that
prompted the removal of the eclass?

My apologies if this is answered elsewhere. I want to be sure what's
expected, just in case I need to touch an eclass.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Addition of a new field to metadata.xml

2017-06-03 Thread Daniel Campbell
On 06/01/2017 11:59 PM, Kent Fredric wrote:
> On Thu, 1 Jun 2017 18:36:24 -0700
> Daniel Campbell <z...@gentoo.org> wrote:
> 
>> +1. Otherwise sounds good. But if we do this for Debian, will there be
>> movement to add in package names for rpm-based distros? Arch? BSD?
>> Slackware? Where do we draw the line?
> 
> I'd say "as need be". Here we have a few extra benefits from using a
> debian identifier that aren't strictly related to "package mapping".
> 
> Its also easier for third party services to use our use of debian
> identifiers to produce the other mappings for us where known ( that is,
> non-gentoo entities can maintain a mapping of debian-to-foo, and we can
> trivially hook into that by using the debian-id as the identifer )
> 
>> Will developers be expected to treat this like a mandated element?
> 
> I'd imagine not, given not everything in debian exists in gentoo, or
> vice versa.
> 
> Similarly, I don't think there are any mandates that the other values
> of remote-id be populated, only that its *encouraged* because that data
> provides utility to an end user.
> 
>> If
>> not, which team will have authority to touch package metadata to make
>> this change?
> 
> I'd suggest it should stay within the controls of the package
> maintainer for starters, where individual maintainers can provision it
> as they feel fit, and we can review our stance on this later if we want
> to make it a tree wide consistent thing.
> 
> Partly because individual maintainers are more likely to understand
> correctly how equivalent their dists are to the referenced debian one,
> and be more equipped to decide whether to include/exclude a given ref.
> 

That sounds very reasonable to me. Thanks for clarifying.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Addition of a new field to metadata.xml

2017-06-01 Thread Daniel Campbell
On 06/01/2017 06:09 PM, Kent Fredric wrote:
> On Thu, 1 Jun 2017 23:18:22 +0200
> Jonas Stein <jst...@gentoo.org> wrote:
> 
>> A space separated list of the corresponding debian packages should be
>> written in the field
>>  
> 
> Why space separated?
> 
> Its already legal to specify the field multiple times, and it should
> work better that way for consistency with things that can already parse
> XML.
> 
> That way there's no need to put an additional parser inside our XML
> extraction.
> 
> libfoo
> libfoo-debug
> 
> No?
> 
> It also means general purpose XML formatting tools can keep it tidy,
> _and_ sorted, without having to reinvent new tools.
> 
+1. Otherwise sounds good. But if we do this for Debian, will there be
movement to add in package names for rpm-based distros? Arch? BSD?
Slackware? Where do we draw the line?

Will developers be expected to treat this like a mandated element? If
not, which team will have authority to touch package metadata to make
this change?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

2017-05-31 Thread Daniel Campbell
On 05/31/2017 03:54 PM, Ciaran McCreesh wrote:
> On Thu, 01 Jun 2017 02:32:24 +0700
> "Vadim A. Misbakh-Soloviov" <gen...@mva.name> wrote:
>> - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all
>> the installed files
>>
>> - patching NeoVim source to include Vim's runtimedirs (incl. "after"
>> dir), // NeoVim upstream highly disagree with such way, if any
>>
>> - patching VIMRUNTIME environment variable,
>>
>> - making a wrapper,
>>
>> - rewrite all the existing ebuilds to take nvim into account and
>> force all newcomers to also take it,
>>
>> - symlinking a directory,
>> // mostly bad way, since opposite plugin compatibility is not
>> garanteed and users can install nvim-only plugins in the future
>>
>> - making postinst hook to regenerate content of NeoVim's
>> site-directory (maybe, by symlinking installed vim modules there)
>>
>> or even:
>>
>> - making eselect module for user to rule that.
> 
> - Have a separate anyvimishthing directory, and make both vim and
> neovim look there, and only make plugins that have been tested to work
> with both install to that directory.
> 

+1, though it's still important to keep nvim- and vim-specific dirs.

A third, common dir cuts down on the work that other solutions would
need. It would also give users a way to check which plugins will work
with 'the other one' too and can use that to decide whether they want to
make the switch. This information can probably be gleaned on their own
with some detective work on the Web, but choosing this path gives the
accidental feature for free.

~zlg

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCHES] python-r1.eclass: any-of dep API support

2017-05-27 Thread Daniel Campbell
On 05/20/2017 06:30 AM, Michał Górny wrote:
> 
> 
> Please review.
> 
> --
> Best regards,
> Michał Górny
> 
> 

It looks much as you mentioned it'd be: moving code around and cutting
down duplication. Looks good to me. I really appreciate the example in
patch 7, which makes it a little more clear how to use it. Thanks for
putting all of this together.

I'm not sure how to express this because I don't know which question to
ask. Is there anything I can help with once this gets committed?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Restricted version of gentoo-dev mailing list

2017-05-27 Thread Daniel Campbell
On 05/23/2017 12:31 PM, Michał Górny wrote:
> [snip]
> Your comments?
> 

Since it's adding a list instead of warping an existing one, I say go
ahead on the condition that everything important finds its way to a more
open list. I'm subscribed to enough as it is.

I am skeptical that it will lead to an improved social experience among
Gentoo developers, but also willing to be proven wrong.

Personally, there's nothing that attracts me to the idea. I don't really
like the concept of curating a mailing list. But seeing as the point of
the list is to lessen the volume of messages, it will likely succeed.

~zlg
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

2017-05-18 Thread Daniel Campbell
On Fri, May 12, 2017 at 08:32:53PM +0200, Michał Górny wrote:
> On czw, 2017-05-11 at 11:47 +0700, Alex Turbov wrote:
> > DEPEND=( doc?
> > || (
> > (
> > dev-python/sphinx[python_targets_python2_7]
> > # NOTE This packages provide extensions for Sphinx
> > dev-python/rst-linker[python_targets_python2_7]
> > dev-python/jaraco-packaging[python_targets_python2_7]
> > )
> > (
> > dev-python/sphinx[python_targets_python3_5]
> > dev-python/rst-linker[python_targets_python3_5]
> > dev-python/jaraco-packaging[python_targets_python3_5]
> > )
> > (
> > dev-python/sphinx[python_targets_python3_6]
> > dev-python/rst-linker[python_targets_python3_6]
> > dev-python/jaraco-packaging[python_targets_python3_6]
> > )
> > )
> >   )
> > 
> 
> One more thing I've missed in my initial mail. The other problem with
> this solution (alone) is that it doesn't enforce the implementation that
> satisfied the dependency.
> 
> Let's take a simple example. You've built sphinx for 2.7+3.5 but rst-
> linker and jaraco-packaging for 3.5 only. The dependency is satisfied
> because the 3.5 branch matches. However, you have no rule to enforce
> 3.5, so sphinx could be actually called with 2.7 and fail.
> 
> This is a generic problem that was pretty much solved by python-any-r1.
> I think we should be able to copy the most important pieces of the API
> to python-r1 to achieve something similar, i.e. add python_gen_any_dep
> to generate the depstrings and make python_setup aware of
> python_check_deps(). Then the above would be written alike:
> 
>   DEPEND="doc? ( $(python_gen_any_dep '
>   dev-python/sphinx[${PYTHON_USEDEP}]
>   dev-python/rst-linker[${PYTHON_USEDEP}]
>   dev-python/jaraco-packaging[${PYTHON_USEDEP}]
> ') )"
> 
>   python_check_deps() {
> has_version "dev-python/sphinx[${PYTHON_USEDEP}]" &&
> has_version "dev-python/rst-linker[${PYTHON_USEDEP}]" &&
> has_version "dev-python/jaraco-packaging[${PYTHON_USEDEP}]"
>   }
> 
> python_setup would verify which implementation has the dependencies
> satisfied, and set it for the common code building docs.
> 
> However:
> 
> 1. I think it would work. However, I can't be sure until I implement it,
> and even then I might miss something.
> 
> 2. It's a significant extension to the API, and kinda goes against
> the goal of making the eclass simpler. However, it mostly fits what is
> in python-any-r1 already, so at least it doesn't introduce a new API.
> 
> So I'd like others to chime in and let me know whether they consider
> this a worthwhile addition before I start working on it.
> 
> -- 
> Best regards,
> Michał Górny

Would this bloat python-r1 too much? I understand the need to keep
eclasses small and efficient. This looks like it might work, and I'm
willing to test it, though I'd need some time to learn how to properly
test Python packages. Is #gentoo-python a good place to seek guidance,
after looking through docs?

Is this a unique-enough case to justify a python-doc eclass? It looks
like it would depend on python-any* or python-r* anyway, so maybe it's a
bit redundant. It's an option, though.

I hadn't considered the dependency <-> implementation relationship; nice
catch! If what you wrote above is as clean as we can get it, I'm
willing to help you on it. I'm just not sure how I'd be most helpful
since I've never written an eclass.


signature.asc
Description: Digital signature


Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

2017-05-17 Thread Daniel Campbell
On Sat, May 13, 2017 at 09:32:46AM +0200, Michał Górny wrote:
> On pią, 2017-05-12 at 17:42 -0700, Daniel Campbell wrote:
> > On 05/11/2017 12:51 AM, Michał Górny wrote:
> > > In fact, I'm personally leaning towards not building docs at all
> > > in ebuilds. It's practically a wasted effort since most of the time
> > > users read docs online anyway.
> > 
> > I believe that's a little myopic; a user (or even developer) may not
> > have Internet access all the time, or may not have it in their primary
> > development environment. Having a copy of the docs locally (the entire
> > point of USE="doc") is super valuable to have when you're away from the
> > network. I'm sure I'm not alone as one of the people who uses the flag
> > and appreciates the work that goes into making sure said flag works.
> > 
> > Sure, we could yank out every single USE="doc", but then we lose a nice
> > feature of the tree and users are back to either (a) trawling the Web to
> > find the project site, then hope they have docs in a separate download,
> > or (b) we end up with foo+1 packages, one extra for any package that has
> > documentation. Neither are particularly good solutions; Debian has done
> > the latter and it results in a huge number of packages for little gain.
> 
> The Python team mostly focuses on providing packages for dependencies of
> other Gentoo packages, not direct Python development. We do not have
> the manpower to go above that.
> 
> -- 
> Best regards,
> Michał Górny

Ah, well that at least explains why you're not interested in it.
Dependency management alone can be tough; I've not noticed any Python
issues, so it seems like you guys do well. :) If you don't mind me
asking, what would it take to solve the USE="doc" issue to the Python
team's standard? I have some personal interest in Python and wouldn't
mind adding 'doc' support for Python packages that users request docs
for.

Maybe others are willing to join me on this. Is that something we can
make happen without getting in anyone's hair?

~zlg


signature.asc
Description: Digital signature


Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

2017-05-12 Thread Daniel Campbell
On 05/11/2017 12:51 AM, Michał Górny wrote:
> In fact, I'm personally leaning towards not building docs at all
> in ebuilds. It's practically a wasted effort since most of the time
> users read docs online anyway.

I believe that's a little myopic; a user (or even developer) may not
have Internet access all the time, or may not have it in their primary
development environment. Having a copy of the docs locally (the entire
point of USE="doc") is super valuable to have when you're away from the
network. I'm sure I'm not alone as one of the people who uses the flag
and appreciates the work that goes into making sure said flag works.

Sure, we could yank out every single USE="doc", but then we lose a nice
feature of the tree and users are back to either (a) trawling the Web to
find the project site, then hope they have docs in a separate download,
or (b) we end up with foo+1 packages, one extra for any package that has
documentation. Neither are particularly good solutions; Debian has done
the latter and it results in a huge number of packages for little gain.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Removal of rxvt

2017-05-11 Thread Daniel Campbell
On 05/11/2017 08:57 AM, Jason A. Donenfeld wrote:
> Hi folks,
> 
> Rxvt is ancient. It's been replace by rxvt-unicode. Rxvt hasn't seen
> updates in years. Recently it's been the subject of a security
> vulnerability, and I suspect it's filled with other potential
> vulnerabilities. Rxvt has no upstream. I tried reaching out to the
> former upstream, and it's evident everybody has moved on and has no
> interest in further maintenance. It doesn't even have a Gentoo
> maintainer!
> 
> Given this, I'd like to remove rxvt from Gentoo, with the usual
> mask-for-30-days process.
> 
> Does anybody have any objections to me doing this? (I'll wait a week
> from now before taking any actions.)
> 
> Regards,
> Jason
> 

Sounds sane to me. It might be helpful to ask if anyone in gentoo-user
is interested in proxying, but as far as I know anyone who used rxvt
migrated to rxvt-unicode once it was stable.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/2] app-portage/eclass-manpages: Add @SUPPORTED_EAPIS tag for eclass

2017-05-03 Thread Daniel Campbell
On 04/28/2017 07:06 AM, Michał Górny wrote:
> Add a @SUPPORTED_EAPIS tag that can be used to explicitly provide a list
> of EAPIs that are supported by the eclass. The main goal is to make it
> possible to extract this list with relative ease, for scripting
> purposes. It is not included explicitly in the manpages at the moment.
> 
> The first use case is to make it possible to explicitly distinguish
> eclasses that do not support a specific EAPI from eclasses that are not
> used by any ebuilds using a specific EAPI. Therefore, it will make it
> possible to easily detect when we can deprecate old EAPIs from eclasses.
> ---
>  app-portage/eclass-manpages/files/eclass-to-manpage.awk | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/app-portage/eclass-manpages/files/eclass-to-manpage.awk 
> b/app-portage/eclass-manpages/files/eclass-to-manpage.awk
> index 0b65162c04ec..fe7e9c12d8f5 100644
> --- a/app-portage/eclass-manpages/files/eclass-to-manpage.awk
> +++ b/app-portage/eclass-manpages/files/eclass-to-manpage.awk
> @@ -18,6 +18,7 @@
>  # <optional; description of how to report bugs;
>  #  default: tell people to use bugs.gentoo.org>
>  # @VCSURL: <optional; url to vcs for this eclass; default: 
> https://gitweb.gentoo.org/repo/gentoo.git/log/eclass/@ECLASS@>
> +# @SUPPORTED_EAPIS: <optional; space-separated list of EAPIs>
>  # @BLURB: <required; short description>
>  # @DESCRIPTION:
>  # <optional; long description>
> @@ -147,6 +148,7 @@ function handle_eclass() {
>   eclass = $3
>   eclass_maintainer = ""
>   eclass_author = ""
> + supported_eapis = ""
>   blurb = ""
>   desc = ""
>   example = ""
> @@ -176,6 +178,8 @@ function handle_eclass() {
>   reporting_bugs = eat_paragraph()
>   if ($2 == "@VCSURL:")
>   vcs_url = eat_line()
> + if ($2 == "@SUPPORTED_EAPIS:")
> + supported_eapis = eat_line()
>   if ($2 == "@BLURB:")
>   blurb = eat_line()
>   if ($2 == "@DESCRIPTION:")
> 

Looks like something eclass developers could really use. I say go for
it! I'm not sure what you're talking about regarding _ vs. -; do you
mean the variable name? I think _ makes a bit more sense there since we
use INSTALL_MASK, PYTHON_SINGLE_TARGET, or other variable names with
underscores. Using a hyphen would make it stick out from other similarly
structured variable names.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Suggested sync method/Portage config for devs on ~arch?

2017-02-27 Thread Daniel Campbell
Ever since we switched to Git, I've tried to use gentoo.git (or a
mirror) to sync from. I later found a configuration that hasufell used
at the time. [1] It works well so far, but I wanted to ask the greater
developer community what method(s) they employ to sync from our
repositories and why it's a good fit for them. I'm hoping that this
discussion may lead to suggestions we can put in the devmanual or other
documentation to make the "transition" to a developer smoother for new
staff, or simply make it easier for our users to be close to the
bleeding edge, if that's what they desire.

So, for a developer/user using ~arch, what do you use and/or recommend
for Portage configuration?

Thanks for reading.

[1]: https://github.com/hasufell/portage-gentoo-git-config
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] ABI Navigator — a project to search for binary symbols

2017-02-23 Thread Daniel Campbell
On 02/23/2017 06:36 PM, Andrey Ponomarenko wrote:
> Hello,
> 
> I'd like to present a new project called "ABI Navigator" for searching binary 
> symbols (functions, methods, global data, etc.) in open-source libraries: 
> https://abi-laboratory.pro/index.php?view=navigator
> 
> The project allows to find out in which versions of libraries some symbol is 
> defined, added, removed or changed. The data is taken from the ABI Tracker 
> project (238 libraries and 0.9 million symbols currently): 
> https://abi-laboratory.pro/tracker/
> 
> Example for symbol dwelf_strtab_add from libdw.so (elfutils): 
> https://abi-laboratory.pro/index.php?view=navigator=dwelf_strtab_add%40%40ELFUTILS_0.167#result
> 
> The project aims to help Linux developers and maintainers to resolve issues 
> with missed symbols and navigate through the reports in the ABI Tracker.
> 
> Have you ever encountered the "undefined reference" error or want to know 
> whether the symbol is _stable_ enough to use in your code? Try to find it in 
> the ABI Navigator!
> 
> Enjoy!
> 
This tool didn't return anything on a quick test (TOX_CONFERENCE_TYPE,
part of net-libs/tox, TokTok/toxcore on GitHub), but it did it quickly
and it has a clean interface. I'll definitely try using this when I find
myself stumped on something.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Package up for grabs: x11-misc/ktsuss

2017-02-15 Thread Daniel Campbell
On 01/25/2017 01:17 PM, Gokturk Yuksek wrote:
> The following package is up for grabs:
> 
>   x11-misc/ktsuss
> 

I can take this; I use it with SpaceFM to do things as root.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-09 Thread Daniel Campbell
On 02/09/2017 12:59 PM, Michael Orlitzky wrote:
> On 02/09/2017 03:41 PM, Daniel Campbell wrote:
>> That's a great question. Based on a cursory look at make.conf's manpage,
>> USE_ORDER without 'pkginternal' will ignore IUSE defaults as intended.
>>
> 
> This has already been suggested like five times =P
> 
> So long as people insist on using IUSE defaults for flags that are
> critical to the package and to satisfy REQUIRED_USE (sprinkled liberally
> throughout the tree), this won't work. You'll turn off the defaults that
> are critical, too, and throw a wrench into dependency resolution.
> 
> 

(Just noticed that after I finished reading the thread; d'oh)

Hm, good point. A good number of us are against REQUIRED_USE (I don't
feel strongly either way), and I'm really not sure why we have packages
that won't work at all without specific USE flags. Now that I've read
the entire thread I see someone mentioned different arches may need
different USE flags, but that seems like something that belongs in the
profile, *if* it's a profile problem.

I'd be happy if REQUIRED_USE conflicts were handled in one of two ways:

1. emerge throws it up in your face and suggests a change (defaulting to
whichever IUSE has a +), which can then be handled with etc-update

or

2. emerge prompts you to choose a flag from the ones listed in
REQUIRED_USE, obeys it, then does #1 so you can etc-update after merging.

The downside to this is it's yet another function to add to emerge. I'm
not sure how else we can make use of REQUIRED_USE while simultaneously
allowing people the choice to not care. Could an eclass do this reliably?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-09 Thread Daniel Campbell
On 02/09/2017 12:25 PM, Ben Kohler wrote:
> 
> 
> On Thu, Feb 9, 2017 at 2:18 PM, Daniel Campbell <z...@gentoo.org
> <mailto:z...@gentoo.org>> wrote:
> 
> I support the idea of a profile-set variable that determines whether or
> not IUSE is respected. Minimalists get their systems faster, we get
> something that adds to Gentoo's versatility and an additional profile.
> Of course, we should be asking the anti-IUSE people if that would be
> good enough to make the profiles/systems they want possible.
> 
> --
> Daniel Campbell - Gentoo Developer
> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net <http://keys.gnupg.net>
> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
> 
> Can't this already be accomplished by modifying the USE_ORDER variable?
> 
> -Ben
That's a great question. Based on a cursory look at make.conf's manpage,
USE_ORDER without 'pkginternal' will ignore IUSE defaults as intended.

So if we change that from what I assume to be the default (found in the
manpage), a minimalist profile (or system) should be using:

USE_ORDER = "env:pkg:conf:defaults:repo:env.d"

If that gets combined with a profile meant explicitly for this
bare-bones use case, then I don't see why we can't make that happen. It
just requires someone who knows the use case to build the profile.

Thanks for pointing this out!

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-09 Thread Daniel Campbell
On 02/03/2017 02:09 PM, William L. Thomson Jr. wrote:
> On Friday, February 3, 2017 2:53:59 PM EST Michael Orlitzky wrote:
>> On 02/03/2017 01:33 PM, Patrick McLean wrote:
>>> We might as well go back to before IUSE defaults then. Part of the
>>> advantage of IUSE defaults is maintainers don't all have to fiddle with
>>> the profiles, everything can be self-contained in the ebuild. This
>>> drastically complicates maintenance, having two locations to track and
>>> change rather than just one.
>>
>> You still retain the benefit for IUSE defaults that actually belong in
>> the base profile, just not for upstream defaults or the ones that you
>> personally prefer.
> 
> That is a side effect, as it is more about the package maintainer choosing 
> the 
> defaults. They are not messing with profiles. That base ends up with it is 
> indirect. Otherwise IUSE default flags would have to be per profile rather 
> than 
> in the package. Which would create more work for package maintainers.
> 
>>> I suspect that there is a small subset
>>> of people interested in this, and perhaps those people could maintain a
>>> "minimal" profile that unsets IUSE defaults.
>>
>> Then every IUSE default gets recorded twice: once when the maintainer
>> puts it in the ebuild, and once when I add it (negated) to the minimal
>> profile. That's a bad design even if we pretend that I can solve the
>> problem of tracking every IUSE change in the tree.
> 
> Sorry if its been suggested, I haven't followed every comment. What about 
> some 
> global env variable that could override all default IUSE. That can set in 
> base, and set what ever minimal IUSE flags that are needed.
> 
I support the idea of a profile-set variable that determines whether or
not IUSE is respected. Minimalists get their systems faster, we get
something that adds to Gentoo's versatility and an additional profile.
Of course, we should be asking the anti-IUSE people if that would be
good enough to make the profiles/systems they want possible.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-02 Thread Daniel Campbell
proposed profile organization?

afaik building the kernel is completely outside of Portage's reach. It
merely installs the source files needed to build it. Everything else is
up to you and/or genkernel.

A special kernel fork designed for embedded sounds good, though. I'm
sure we've got something like that in the tree (or an overlay) somewhere.
> 
> 
>> In the same way, we shouldn't be too quick to deviate from upstream
>> defaults ourselves (#4 in your example), beyond actual integration
>> work.
> 
>> I'll admit the current state is a bit of a compromise, but I don't
>> think we should change it unless we're changing it to something
>> significantly better.  This is a pretty big-impact change.
> 
> 
> Just formalize some new parts of the profile tree to not be required to
> be upstream compliant. Isn't that part of being a 'meta-distribution'?

Don't we already do that? KDE, GNOME, and XFCE aren't "upstream"
compliant because there *isn't* a single, default upstream DE, so we
have profiles for that. If you or others would like to create or improve
existing profiles, then that's awesome and you should try to put
together some patches or a pull request so we can take a look.

> 
> In my future (and the future of many others) there will be minimalistic
> builds on clusters where any number to constructs including
> compatibility  which will all be solved, at the framework level, not the
> base distro level, to the extent possible. Folks are now running a
> myriad of windows OS versions on linux (), so I have just read
> about a few days ago. So I'm proposing and working on gentoo
> heterogeneous cluster where one can partition part to be for systemd
> stuffage, part to be HPC, part to be extraordinarily secure, part to be
> aligned with a particularly commercial linux distro, and many other
> differing needs based frameworks.
> 
> 
> The minimal (lowest level) should be clear of all of those distro
> encumbrances. CoreOS is taking this approach, as their bare metal
> bootstrapping occurs completely and well before systemd or any other
> PID1 schema is invoked or becomes a defacto requirement.  Gentoo is all
> about freedom, right?

If we need a new profile, then certainly those who are going to use it
should be best equipped to know what needs to be in it, right? This is a
great case for building what you need and then sharing it so everyone
can benefit. I don't do embedded (though I might tinker with it some
day), so I'm definitely not able to know what needs to be in such a
profile. We need people who actually work in that sort of stuff to do
the work, because if someone like me does it, then it may have too many
packages in it, or it won't account for X or Y use case that's super
common in embedded, etc.

Embedded is an itch, and non-embedded Gentoo people can't scratch it for
you because we aren't qualified. If you or others ever manage to make
that profile, please share it so others can benefit too. :)
> 
> 
> hth,
> James
> 

Thanks for reading,
zlg
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Last rites: leechcraft

2017-02-02 Thread Daniel Campbell
On 01/31/2017 09:08 AM, David Seifert wrote:
> On Tue, 2017-01-31 at 17:34 +0100, Kristian Fiskerstrand wrote:
>> On 01/31/2017 03:50 PM, Georg Rudoy wrote:
>>> I'll make a new release of leechcraft itself and bump the version
>>> to
>>> that new one, so they'll naturally be dropped to unstable, 0.6.70
>>> and
>>> earlier (if any) indeed could be removed. Most of the bugs, as I
>>> saw
>>> them, are due to the current last released version being 2.5 years
>>> old
>>> and obviously bitrotten somewhat since then.
>>
>> I'd still recommend spending a bit of time to consider whether this
>> doesn't fit better in an overlay, which would also make it easier to
>> maintain without overburdening proxy maint given the number of
>> packages
>> involved.
>>
> 
> I really second this - we can ask infra to get you an overlay. Should
> it turn out that you are truly maintaining stuff, we can then merge it
> into the tree.
> 
I'd like to third it. Overlays are a great way for people (users and
devs alike) to try their hand maintaining their own Portage tree. It's
great practice and it gives you a single place to reference for people
who are using your ebuilds.

If it gets formally into layman, I believe our bugzy will cover you,
too, in case you don't want to use github. I'd ask infra just to be sure.

Overlays for Gentoo are comparable to Debian's and Ubuntu's PPAs and are
similarly simple to install/use/delete.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] REQUIRED_USE, global USE flags, user-friendliness...

2017-01-30 Thread Daniel Campbell
and listen to choices, and c) a way to default to one of the
given choices in "automatic" or unattended merges.

A good portion of the information is already in the ebuilds. We have
IUSE for default flag state and REQUIRED_USE to show us which flags are
conflicting. The description for the USE flags can be gleaned from
metadata.xml or the profile's package.use.desc.

So the hard part is: how do we glue this together?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Unused profiles

2017-01-19 Thread Daniel Campbell
On 01/19/2017 05:25 PM, Anthony G. Basile wrote:
> [snip]
> 
> Also, we should just drop a deprecated file into these profiles for now
> and wait a year before removing them from the tree.
> 

Agreed. Some sort of deprecation notice would make sense and give people
time to figure out a way forward with their machines.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Last-rites: www-plugins/pipelight

2017-01-17 Thread Daniel Campbell
On 01/10/2017 11:29 AM, NP-Hardass wrote:
> # NP-Hardass <np-hard...@gentoo.org> (19 Jan 2017)
> # Upstream has discontinued Pipelight and Firefox is in the process
> # of removing NPAPI support (which Pipelight relies upon), making
> # this obsolete.
> # Masked for removal in 30 days.
> www-plugins/pipelight
> 
> 
Would this work for Pale Moon by any chance?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

2017-01-17 Thread Daniel Campbell
On 01/06/2017 12:46 PM, William L. Thomson Jr. wrote:
> On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote:
>>
>> The nice thing about ::graveyard or similar is that its a clear demarcation
>> between maintained (in tree) and unmaintained (graveyard.) It also means
>> that people doing actual maintenance work can basically ignore the
>> graveyard as a matter of policy. The ebuilds are archived there (for users)
>> but since they are unmaintained they may not work correctly.
> 
> This is what the Java team used to do. There was a java-graveyard-overlay. I 
> do not believe any package ever moved there came back into the tree. It did 
> result in a pretty messed up overlay, but makes it a user problem.
> 
> At the same time, something could always be restored from VC. Not like 
> removal 
> is removing all history and traces. Thus not sure such overlay is really even 
> beneficial. Using it could cause lots of problems if they just care about 1 
> package or a few.
> 

There's a nice trick around that, actually: let's assume the overlay is
called "foo-overlay".

In package.mask:

*/*::foo-overlay

will mask all packages in the overlay. You can then add packages to
package.unmask:

pkg-cat/foobar::foo-overlay

That should alleviate most issues, though it can make dependencies a
PITA if those deps are also in the overlay. In that case, emerge should
yell at you and suggest adding lines to package.unmask.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] bzipped manpages

2017-01-16 Thread Daniel Campbell
On 01/10/2017 05:16 AM, Fabian Groffen wrote:
> On 09-01-2017 09:08:22 +0100, Jan Stary wrote:
>> The particular problem I am having is that http://mdocml.bsd.lv/ ,
>> my manpage formatter of choice, does deliberately not support bzip
>> (or any other outside decompressors for that matter).
> 
> Attached patch works for me.  XZ should be a similar exercise, a little
> cleanup would be nice then though.
> 
> Fabian
> 
This is awesome; has upstream been sent this yet, by any chance?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] bzipped manpages

2017-01-16 Thread Daniel Campbell
by the designer, not the underlying hardware from a vendor.
> Robust embedded system design, regardless of VHDL or C or ? codes
> are more of an art-form than a technical expose on software development.
> I know embedded designers that have created thousands of products  some
> in a matter of weeks, and other teams that fail to produce a single
> robust product, in their entire lifetime.  The most prolific designer of
> them all, is simple referred to as 'doctor bitch' by her subordinates
> and friends. Some, more respectfully refer to her as the queen of
> assembler, as she has fixed thousands of compiler bugs from a myriad of
> compiler vendors, not for compensation, but because the bugs got in her
> way...
> 
> 
> 
> hth,
> James
> 
Whoa, quite a post there! It was a good read. Is this coworker looking
for any volunteer distro work by any chance? *wink wink* :P

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New Project: Gentoostats

2017-01-06 Thread Daniel Campbell
On 01/06/2017 08:08 AM, Gokturk Yuksek wrote:
> Hi,
> 
> Daniel Campbell:
>> On 01/02/2017 09:27 AM, Gokturk Yuksek wrote:
>>> Alexander Shorin:
>>>> Hi!
>>>>
>>>> Thanks for sharing. Would be nice see updated README file (it contains
>>>> outdated links to Not Found pages) and add few notes about comparison
>>>> of your solution with collectd, ussd and the rest modern stats
>>>> collecting tools.
>>>> How better it  suites Gentoo machines and why to use it today instead
>>>> of any existed and mature tool?
>>>
>>> We are interested in different kinds of stats with gentoostats. The main
>>> purpose of gentoostats is to collect package statistics, and currently
>>> it does so by utilizing the Portage API. Here's a sample output from the
>>> gentoostats-cli tool that may give you a better idea:
>>>
>>> $ gentoostats-cli search --c sys-apps --p portage --v 2.3.0 --r gentoo
>>> --min_hosts 4
>>> Search results
>>> [{'CAT': 'sys-apps',
>>>   'HOSTS': 5,
>>>   'PKG': 'portage',
>>>   'REPO': 'gentoo',
>>>   'VER': '2.3.0'}]
>>>
>>> There is also other Gentoo-specific information it collects such as this:
>>>
>>> $ gentoostats-cli list arch
>>> Arch
>>> {'amd64': {'HOSTS': 4}, 'x86': {'HOSTS': 1}}
>>>
>>>> --
>>>> ,,,^..^,,,
>>>>
>>>>
>>>
>>> --
>>> gokturk
>>>
>>>
>> Is it too late to suggest more standard flags? `--c` for example doesn't
>> make sense to me since '--' is used more for GNU long options. So it
>> should be '--category' and '-c' instead. Of course that's just my
>> opinion, so take it with salt as usual. :)
>>
> 
> That's a typo on my part, thanks for pointing it out :) It's
> '-c/--category', '-p/--package', '-v/--version' and '-r/--repo'. I used
> the long options, then decided to go with the short ones to increase
> readability, forgot to remove extra '-'.
> 
>> Still, interesting project and I might run it on a machine if it can
>> help us out.
>>
> 
> 
I guess we can ignore that little nitpick then. :P

I'll check it out when I get some time to spare.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New Project: Gentoostats

2017-01-05 Thread Daniel Campbell
On 01/02/2017 09:27 AM, Gokturk Yuksek wrote:
> Alexander Shorin:
>> Hi!
>>
>> Thanks for sharing. Would be nice see updated README file (it contains
>> outdated links to Not Found pages) and add few notes about comparison
>> of your solution with collectd, ussd and the rest modern stats
>> collecting tools.
>> How better it  suites Gentoo machines and why to use it today instead
>> of any existed and mature tool?
> 
> We are interested in different kinds of stats with gentoostats. The main
> purpose of gentoostats is to collect package statistics, and currently
> it does so by utilizing the Portage API. Here's a sample output from the
> gentoostats-cli tool that may give you a better idea:
> 
> $ gentoostats-cli search --c sys-apps --p portage --v 2.3.0 --r gentoo
> --min_hosts 4
> Search results
> [{'CAT': 'sys-apps',
>   'HOSTS': 5,
>   'PKG': 'portage',
>   'REPO': 'gentoo',
>   'VER': '2.3.0'}]
> 
> There is also other Gentoo-specific information it collects such as this:
> 
> $ gentoostats-cli list arch
> Arch
> {'amd64': {'HOSTS': 4}, 'x86': {'HOSTS': 1}}
> 
>> --
>> ,,,^..^,,,
>>
>>
> 
> --
> gokturk
> 
> 
Is it too late to suggest more standard flags? `--c` for example doesn't
make sense to me since '--' is used more for GNU long options. So it
should be '--category' and '-c' instead. Of course that's just my
opinion, so take it with salt as usual. :)

Still, interesting project and I might run it on a machine if it can
help us out.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: Global USE cuda

2017-01-05 Thread Daniel Campbell
On 01/03/2017 06:18 PM, Mart Raudsepp wrote:
> Ühel kenal päeval, T, 03.01.2017 kell 11:02, kirjutas Andrew Savchenko:
>> Hi,
>>
>> On Mon, 2 Jan 2017 21:37:43 + Justin  wrote:
>>>
>>> Hi all
>>>
>>> How about making USE=cuda a global USE?
>>>
>>> Description: Enable support for nVidia CUDA
>>
>> Sounds reasonable.
> 
> If this gets implemented, just please make sure to not wipe too much fo
> the local descriptions. I see many of them specifying things in detail,
> which is very useful to keep around as a description "override" and I
> very much appreciate and encourage that.
> 
> 
>>>
>>> Current Situation:
>>> dev-lang/pgi: Install PGI's CUDA components (e.g. for OpenACC)
>>> dev-libs/libflatarray: Enables plugins for NVIDIA GPUs (e.g.
>>> dev-util/VampirTrace: Enable tracing of CUDA calls and GPU
>>> kernels.
>>> sci-chemistry/ball: Include cuda support
>>> sci-chemistry/nwchem: Enable CUDA GPU support for the Tensor
>>> sci-libs/arrayfire: Build CUDA backend.
>>> sci-libs/bigdft-abi: Enable support for nVidia CUDA
>>> sci-libs/libgeodecomp: Enables plugins for NVIDIA GPUs (e.g.
>>> sci-libs/trilinos: Add support for cuda (dev-util/nvidia-cuda-
>>> toolkit)
>>> sci-misc/kaldi: Build with CUDA support.
>>> sci-physics/abinit: Enable support for nVidia CUDA
>>> sci-physics/bigdft: Enable support for nVidia CUDA GPU
>>> acceleration
>>> sys-cluster/openmpi: Add GPU direct support
>>> app-crypt/johntheripper: Use nvidia cuda toolkit for speeding
>>> up
>>> dev-libs/libdynd: Enable NVIDIA CUDA toolkit support
>>> dev-libs/libflatarray: Enables plugins for NVIDIA GPUs (e.g.
>>> dev-libs/starpu: Enable NVIDIA CUDA toolkit support
>>> dev-util/nvidia-cuda-sdk: Build CUDA binaries.
>>> media-gfx/blender: Build cycles renderer with nVidia CUDA
>>> support.
>>> media-gfx/k3d: Use nvidia cuda toolkit for speeding up
>>> computations
>>> media-gfx/nvidia-texture-tools: Enable NVIDIA CUDA toolkit
>>> support
>>> media-libs/opencv: Enable NVIDIA Cuda computations support
>>> media-libs/opensubdiv: Enable NVIDIA CUDA Toolkit support
>>> through
>>> net-analyzer/suricata: Enable NVIDIA Cuda computations support
>>> net-wireless/pyrit: Enable CUDA support via net-
>>> wireless/cpyrit-cuda
>>> sci-chemistry/ball: Include cuda support
>>> sci-chemistry/gromacs: Enable cuda non-bonded kernels
>>> sci-chemistry/vmd: Use nvidia cuda toolkit for speeding up
>>> sci-libs/cholmod: Use nvidia cuda toolkit for speeding up
>>> computations
>>> sci-libs/flann: Enable support for nVidia CUDA
>>> sci-libs/pcl: Adds support for NVIDIA CUDA.
>>> sci-libs/suitesparse: Enable nvidia cuda toolkit for speeding
>>> up
>>> sci-misc/boinc: Use nvidia cuda toolkit for speeding up
>>> computations.
>>> sci-physics/espresso: Enable cuda support
>>> sci-physics/hoomd-blue: Enable cuda non-bonded kernels
>>> sys-apps/hwloc: Enable CUDA device discovery
>>> sys-cluster/openmpi: Add GPU direct support
>>>
>>> More or less consistent in enabling CUDA support.
>>>
>>> Best,
>>> Justin
>>>
>>
>>
>> Best regards,
>> Andrew Savchenko
> 
+1

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs due to retirement

2017-01-05 Thread Daniel Campbell
On 01/03/2017 06:31 AM, M. J. Everitt wrote:
> On 03/01/17 11:05, Michał Górny wrote:
>> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
>> gro...@gentoo.org wrote:
>>
>>> On Mon, 2 Jan 2017, Brian Evans wrote:
>>>> IMO, this one should be given last-rites as upstream is dead and it
>>>> heavily depends on wireless-tools and WEXT.  
>>> I use it on 2 notebooks. It works fine, and is (from my point of view) the 
>>> most convenient tool to control ethernet and wifi connections on a 
>>> notebook. Why lastrite it when it works?
>> This is the Gentoo Way™. Having a working software is not a goal.
>> Gentoo focuses on the best bleeding edge experience and therefore
>> highly relies on software packages that are under active development
>> and require active maintenance. The packages in early stages of
>> development are especially interesting since they can supply users
>> and developers with variety of interesting bugs and unpredictable
>> issues.
>>
> From your response I infer the following, please discuss:
> 1) "working software is not a goal" .. so we can have a tree full of
> broken and/or unstable packages. What is the point of any QA/CI system
> if this is applicable?
> 2) "require active maintainance" .. by whom exactly? Where are the flood
> of keen developers bringing their bleeding edge code (with their
> ludicrous packaging requirements and language demands) to Gentoo?
> 3) "interesting bugs and unpredictable isssue" .. WTF?
> 
> Michal .. are you (once again...) High .. or is your email (once again)
> so soaked in sarcasm we can't tell any useful content from the complete
> drivel ...
> 
Maybe I'm weird but I thought it was funny...

I'm in favor of keeping software around until it breaks. When there's a
non-existent upstream and nobody's willing to take up the helm
themselves, it's a clear indication that it's in danger of being
treecleaned. In some cases that's good; some packages get left behind
and never updated, CVEs get released, nobody cares about the package and
it sits masked for a while. Those are the packages we should consider
for treecleaning, not just "oh it's been 2 years since a release" or
"upstream website troubles".

On the latter count, does anyone attempt to reach upstream before
suggesting we get rid of the package(s)? Is there not some forum we can
use to reach users who may be interested in proxy-maintaining it? This
discussion makes me wonder if we need (more) formal guidelines for
treecleaning. I think we've got a few people who are eager to clean the
tree -- and their goal is admirable -- but until we can get metrics on
who's using what, it's hard to say how much damage removing a package
will do for users. A thread on gentoo-user re: lastrites might not be a
bad idea.

Thanks for the laugh Michał. :)

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Point user to additional kernel removal, instructions. See bug #581522.

2016-12-27 Thread Daniel Campbell
On 12/27/2016 04:52 PM, Mike Pagano wrote:
> This addresses concerns that users might not realize that after an
> unmerge of kernel sources some files will need to be removed manually.
> The particular concern was specific to the files in /lib/modules/. I
> liked this solution, since it does not require a wordy explanation to be
> written in the eclass.
> 
> ---
>  eclass/kernel-2.eclass | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index 520a4c1..29b2987 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -1619,4 +1619,7 @@ kernel-2_pkg_postrm() {
>   ewarn "with modified files will remain behind. By design, package
> managers"
>   ewarn "will not remove these modified files and the directories they
> reside in."
>   echo
> + ewarn "For more detailed kernel removal instructions, please see: "
> + ewarn "https://wiki.gentoo.org/wiki/Kernel/Removal;
> + echo
>  }
> 
+1

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls

2016-12-27 Thread Daniel Campbell
On 12/26/2016 12:22 PM, Mike Gilbert wrote:
> Bug: https://bugs.gentoo.org/603776
> ---
>  eclass/toolchain.eclass | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index 55249b00249b..97511ee12440 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -2119,13 +2119,13 @@
>  
>  do_gcc_config() {
>   if ! should_we_gcc_config ; then
> - env -i ROOT="${ROOT}" gcc-config --use-old --force
> + env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config --use-old 
> --force
>   return 0
>   fi
>  
>   local current_gcc_config target
>  
> - current_gcc_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET} 
> 2>/dev/null)
> + current_gcc_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config 
> -c ${CTARGET} 2>/dev/null)
>   if [[ -n ${current_gcc_config} ]] ; then
>   local current_specs use_specs
>   # figure out which specs-specific config is active
> @@ -2159,12 +2159,12 @@ should_we_gcc_config() {
>   # if the current config is invalid, we definitely want a new one
>   # Note: due to bash quirkiness, the following must not be 1 line
>   local curr_config
> - curr_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET} 2>&1) || 
> return 0
> + curr_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config -c 
> ${CTARGET} 2>&1) || return 0
>  
>   # if the previously selected config has the same major.minor (branch) as
>   # the version we are installing, then it will probably be uninstalled
>   # for being in the same SLOT, make sure we run gcc-config.
> - local curr_config_ver=$(env -i ROOT="${ROOT}" gcc-config -S 
> ${curr_config} | awk '{print $2}')
> + local curr_config_ver=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" 
> gcc-config -S ${curr_config} | awk '{print $2}')
>  
>   local curr_branch_ver=$(get_version_component_range 1-2 
> ${curr_config_ver})
>  
> 

Seems like an obvious bug and fix; is there any reason passing CHOST
around might be a bad idea? It seems to me that it enforces the behavior
it's meant to have to begin with and makes it more obvious that CHOST is
used.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [rfc] New global USE flag: rbd

2016-12-26 Thread Daniel Campbell
On 12/25/2016 11:45 PM, Andrew Savchenko wrote:
> Hi all,
> 
> 8 packages are using either rbd or rados USE flag for Rados
> Block Device support:
> 
> use.local.desc:app-backup/bareos:rados - Enable rados storage backend
> use.local.desc:app-emulation/ganeti:rbd - Enable rados block device support 
> via sys-cluster/ceph
> use.local.desc:app-emulation/libvirt:rbd - Enable rados block device support 
> via sys-cluster/ceph
> use.local.desc:app-emulation/qemu:rbd - Enable rados block device backend 
> support, see http://ceph.newdream.net/wiki/QEMU-RBD
> use.local.desc:net-analyzer/rrdtool:rados - Enable support for librados from 
> sys-cluster/ceph
> use.local.desc:net-libs/xrootd:rbd - Enable rados block device support via 
> sys-cluster/ceph
> use.local.desc:sys-block/fio:rbd - Enable Rados block device support via 
> sys-cluster/ceph
> use.local.desc:sys-block/tgt:rbd - Add support for ceph block devices
> 
> Suggested description:
> rbd - Enable rados block device support via sys-cluster/ceph
> 
> Best regards,
> Andrew Savchenko
> 

Do we expect the list of packages using RBD to grow? If so then sure, if
for no other reason than to give a consistent description.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

2016-12-24 Thread Daniel Campbell
On 12/24/2016 05:13 PM, Gokturk Yuksek wrote:
> On 11/04/2016 09:36 PM, Jonas Stein wrote:
>>>> If you maintain one of these packages, please fix the SRC_URI
>>>> and HOMEPAGE variables.
>>
>>> It would probably be better if the output included the
>>> maintainer.
>>
>> Yes, that is a good idea.
>>
>> cat googlecode-shutdown.txt | cut -f1 -d":" | xargs equery meta -mH
>> | grep "\@" | sort | uniq | sed "s/@/__/g"
>>
>> I prefer to protect the list at least by substitution. It will not
>> help much, but makes me happier ;-)
>>
> 
> I've hacked up a portageq-like script [0] to list
> ebuilds/packages/maintainers for anyone who is interested.
> 
> [0] https://github.com/gktrk/gentoo-scripts/blob/master/googlecode-uri.py
> 
> --
> gokturk
> 
> 
Hey, thanks for that script; it helped me find the one package I needed
to sort out my gcode stuff. I had a feeling there was at least one I
needed to take care of.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-12-18 23:59 UTC

2016-12-19 Thread Daniel Campbell
On 12/18/2016 11:02 PM, Kent Fredric wrote:
> On Sun, 18 Dec 2016 21:08:09 -0500
> Michael Orlitzky <m...@gentoo.org> wrote:
> 
>>   dev-php/ca-bundle20161124-07:43 mjo[1] 7597666
>>   dev-php/cli-prompt   20161124-07:21 mjo[1] d3bd351
>>   dev-php/composer 20161124-08:09 mjo[1] d273046
>>   ...
>>
>>   [1] Author: Guillaume Seren
> 
> +1 
> 
Agreed. Easy to read and credits the appropriate people.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish

2016-12-13 Thread Daniel Campbell
On 12/13/2016 10:47 AM, Christopher Head wrote:
> On December 9, 2016 10:12:54 PM PST, "A. Wilcox" <awil...@adelielinux.org> 
> wrote:
>> I think James has perhaps spoken ambiguously, or at least I hope that
>> you have misunderstood his proposal.  (If you haven't, then he's
>> misunderstood mine.)
>>
>> The point of making it easier to fork is not only for the benefit of
>> developers.  As James says:
>>
>>> And then folks running gentoo-proper now can pick and choose which 
>>> innovations they want to include in the master tree.
>>
>> The idea being the people who "run" Gentoo, that being the developers
>> of Gentoo, can pick what they want from the forks and derivatives, and
>> include those improvements in the master tree.  Then all Gentoo users,
>> and all derivatives of Gentoo, can benefit from those improvements.
> 
> You’re right, I took the word “run” in the sense of “execute” (the OS), not 
> in the sense of “manage” (the organization). If forks are a way to develop 
> work destined for upstream, they’re great. It’s when they become a tool for 
> fragmenting the community (of both users and developers) without any hope of 
> work being recombined that they become a problem.
> 

Sometimes people don't get along or play politics to fight within an
organization. At that point, one is forced to route around the social
damage and branch off. It's at the "host"'s discretion whether they want
to pull from the fork, and I don't think pressuring or forcing either of
those groups to work together would be a good idea.

I'm applying this in a general sense, to clarify.

It's true that it can create a maintenance burden and sometimes even
confusion, but what else can you do about volunteers that can't agree on
a way forward for a given project?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] tinfo flag

2016-12-11 Thread Daniel Campbell
  Additionally, we can set
> SLOT="0/6tinfo" which will trigger subslot rebuilds to ensure anything
> that may need to be rebuilt to link to both libncurses and libtinfo
> will be rebuilt when the tinfo-IUSE-less version gets installed.
> 
> We not only have a solution that'll address the
> ABI-break-on-USE-change issue, but also a migration path that will be
> transparent to users via a -uDN @world.  I call that a win-win.  The
> only thing we lose is the easy ability to build an all-in-one
> libncurses.  So if there is an actual need for that which we have yet
> to find, this is an official request for comments to let us know.
> 
> 
Thanks for adding some clarity to the conversation. Your idea seems
solid to me; if libtinfo and libncurses are built from the same repo, we
can ship ncurses with the included libtinfo build and, if it's needed in
the future, write an ebuild for just libtinfo (similar to how udev can
be built separate from systemd). Based on what I've seen in this thread,
there isn't a need (yet) for tinfo to be standalone, so I support
bundling them for the interim.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rdp vs rdesktop vs freerdp USE flags

2016-12-11 Thread Daniel Campbell
On 12/08/2016 06:10 AM, Doug Freed wrote:
> On Thu, Dec 8, 2016 at 7:38 AM, Andrew Savchenko <birc...@gentoo.org> wrote:
>> Hi,
>>
>> On Thu, 08 Dec 2016 11:29:51 +0100 Pacho Ramos wrote:
>>> When looking at freerdp reverse deps I noticed we are using three different
>>> names for USE flags enabling freerdp support: rdp, rdesktop and freerdp
>>>
>>> rdesktop is the only one that is a global USE flag, even if it's used only 
>>> by
>>> two packages, the others are local USE flags that are enabling similar
>>> supports.
>>>
>>> What should we do? Move all to rdesktop?
>>
>> Move everything to rdp, since this one is most common; add it to
>> global flags and remove rdesktop from the list.
> 
> +1; RDP is the protocol, whereas freerdp/rdesktop is the
> implementation.  This allows one to later replace the dependency with
> an any-of or virtual, without needing to change the useflag.
> 
> -Doug
> dwfreed
> 
+1 here.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish

2016-12-11 Thread Daniel Campbell
On 12/11/2016 02:00 AM, Markos Chandras wrote:
> On 12/11/2016 08:05 AM, Daniel Campbell wrote:
>> On 12/07/2016 07:36 AM, Jorge Manuel B. S. Vicetto wrote:
>>> On Wed, 7 Dec 2016, Jorge Manuel B. S. Vicetto wrote:
>>>
>>> 
>>>
>>>> I'm asking recuiters directly, but unless someone changed the rules
>>>> and I was distracted, irc is not mandatory.
>>>
>>> I've got confirmation that nothing has changed, so irc is not mandatory.
>>> I hope this clears any misunderstandings and puts an end to any
>>> speculation.
>>>
>>> Best regards,
>>> Jorge Manuel B. S. Vicetto
>>> Gentoo Developer
>>>
>> Would you mind telling us who told you that? I don't disagree or
>> anything, but if others have further questions, we should route them to
>> the person you spoke with.
>>
> 
> I did. No, do not redirect them to me. If the wiki does not clarify
> that, then fix the wiki.
> 
> But seriously, are we arguing here about connecting to IRC for a few
> hours in your entire dev-hood? Is this really *that* hard? Or is it just
> another excuse to complain about the whole process?
> 
> Anyway, nobody (to my knowledge) ever got rejected because he/she did
> not have IRC access so please stop speculating and throwing flamebaits
> here and there. We have more than enough already.
> 
I think maybe you're mixing me up with someone else. That said, editing
the wiki sounds good since it'll save developer time.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish

2016-12-11 Thread Daniel Campbell
On 12/09/2016 09:46 PM, Christopher Head wrote:
> On Wed, 7 Dec 2016 12:15:06 -0500
> james <gar...@verizon.net> wrote:
> 
>> Being able to use stage-4 or stage-5 (G. forums) installs to rapidly 
>> provision a collection of bare-metal systems [BGO-593218] into a wide 
>> variety of hardened clusters is my passion. Unikernels as stage 4 
>> packages can then very easily be targeted for very specific needs: VM
>> or container or bare-metal.  Gentoo-proper is has too much political 
>> baggage to encourage folks to innovate, imho. So, I really hope the 
>> gentoo dev community gets behind the Anna Wilcox idea of streamlining 
>> Gentoo into the most fork-able distro on the planet. WE could all be
>> one happy family and yet be very competitive with our ideas, trials
>> and published results?  Surely a few eggheads (academcis/pedantics)
>> see the wisdom of competing micro_distros? Not unlike competing
>> micro_breweries, it make the entire craft much stronger and better
>> for all.
>>
>>
>> Then there can be peace and harmony as everybody can do exactly as
>> they please with their little cluster of gentoo and their very own 
>> portage-tree. And then folks running gentoo-proper now can pick and 
>> choose which innovations they want to include in the master tree.
>> Isn't that pretty much what Google and CoreOS do now, as well as the
>> gentoo derivative OS? Why not accelerate what has worked, for the
>> few, to emancipate those of us still chained into user-land servitude.
> 
> As an ordinary user, this sounds pretty bad. Forking is great for
> developers, but bad for users. I don’t *want* 27 different
> Gentoo-derived fork distributions, each of which is great at one thing.
> I don’t want to have to reinstall a different OS just because I switch
> from writing embedded code to running Octave. Honestly, I don’t even
> want to go out and find other OS’s repos, add them as overlays, and
> hope the inter-OS dependencies work.
> 
> As an ordinary user, what I *want*, is to install one OS and not think
> about it again. Ideally, Gentoo. When I want to do embedded
> development, I just emerge dev-embedded/thingy. When I want to do some
> math, I just emerge sci-mathematics/octave. Most things that most
> people care about in the main tree. Breaking things up into overlays or
> different OSs or whatever just means adding more hoops that I have to
> jump through before I can start working on a new topic.
> 

Unfortunately even with a rich technical foundation (like Gentoo's)
can't ensure that happens. Forks are patches around social problems or
(sometimes, but rarely) technical disagreements. As much as some would
insist that libre software is purely technical, there's an important and
prevalent social component that influences the technical side. At some
point or another, people can't work together and as a result the ebuilds
scatter. Adding overlays via layman is dead-simple, and iirc you can use
bugzie to file bugs against any official layman overlay. There *are*
ways to deal with overlays in a mostly centralized manner. The layman
list and bugzilla support goes a long way to making that possible, and
the guys behind it did a great job.

One Size Fits All is a dream. It sounds great on paper, but when it
comes time to Just Do It™, you get all the messiness that comes with
wetware and the disagreements on software.

I see where you're coming from and yes, it'd be nice if we could all
just use Gentoo. But reality (read: volunteering) doesn't work that way.

If you have any issues with overlays, please, use the ML or #gentoo so
somebody can help you out.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish

2016-12-11 Thread Daniel Campbell
On 12/07/2016 07:36 AM, Jorge Manuel B. S. Vicetto wrote:
> On Wed, 7 Dec 2016, Jorge Manuel B. S. Vicetto wrote:
> 
> 
> 
>> I'm asking recuiters directly, but unless someone changed the rules
>> and I was distracted, irc is not mandatory.
> 
> I've got confirmation that nothing has changed, so irc is not mandatory.
> I hope this clears any misunderstandings and puts an end to any
> speculation.
> 
> Best regards,
> Jorge Manuel B. S. Vicetto
> Gentoo Developer
> 
Would you mind telling us who told you that? I don't disagree or
anything, but if others have further questions, we should route them to
the person you spoke with.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] tinfo flag

2016-12-06 Thread Daniel Campbell
On 12/06/2016 06:44 PM, Mike Gilbert wrote:
> On Tue, Dec 6, 2016 at 9:11 PM, William Hubbs <willi...@gentoo.org> wrote:
>> On Tue, Dec 06, 2016 at 05:26:19PM -0500, Mike Gilbert wrote:
>>> On Tue, Dec 6, 2016 at 4:15 PM, Michał Górny <mgo...@gentoo.org> wrote:
>>>> On Tue, 6 Dec 2016 12:54:26 -0500
>>>> Mike Gilbert <flop...@gentoo.org> wrote:
>>>>
>>>>> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox <konsole...@gmail.com> wrote:
>>>>>> Please consider promoting the use of tinfo flag in packages that
>>>>>> depend on sys-libs/ncurses so that they would synchronize properly
>>>>>> with sys-libs/ncurses[tinfo].
>>>>>
>>>>> I would rather see the tinfo USE flag removed from ncurses.
>>>>
>>>> vapier doesn't consider this QA violation a QA violation.
>>>>
>>>> https://bugs.gentoo.org/487844
>>>
>>> Perhaps QA could take some action then?
>>>
>>> Updating ~1500 ebuilds with a [tinfo=] use-dep seems like a poor solution.
>>
>> 
>> Our policies are in the dev manual, so please cite the violation there.
>> If you can't, this is not a qa violation, so please don't call it one.
>> 
>>
>> I don't see a problem with the use flag and suggest updating the other 
>> ebuilds.
> 
> The USE flag introduces needless complexity for zero benefit. Please
> explain to me why this is a good idea.
> 
As an onlooker, I don't see anything in favor of getting rid of it, and
otherwise it seems like a normal USE flag. All that's been said in favor
of removing it is just statements that tell me it's more complex or that
it's a QA violation.

Could you explain so other people (and myself) understand what you're
talking about?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

2016-12-05 Thread Daniel Campbell
On 12/05/2016 03:49 AM, Rich Freeman wrote:
> Here is a separate thought.  Would it make sense in any way to try to
> have a more established way to communicate with our downstream distros
> about stuff like this, like a gentoo-derivatives mailing list or such?
>  I wouldn't restrict access or anything like that, but participants
> would be expected to stay on-topic (it isn't another gentoo-dev or
> gentoo-user/project).  Changes could still make their way onto the
> main lists.  I was just thinking that we don't really have any
> official way to notify downstream distros of changes like these.

Sounds like a good idea to me. We could even allow technical support
there ala -user, but with a focus on 'remixing' or otherwise
forking/copying Gentoo. It makes sense for a meta distro to assist in
the 'meta' part, if only for informational reasons.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

2016-12-04 Thread Daniel Campbell
On 12/04/2016 07:20 PM, Sam Jorna wrote:
> On Sun, Dec 04, 2016 at 09:13:23PM -0600, A. Wilcox wrote:
>> to read over it.  (Would it be more desirable to have all changes in a
>> single large commit, or one commit per package?)
> 
> I'd think this is one of those cases best suited to a branch and merge 
> commit - best of both worlds.
> 
> But that's just my two cents. :)
> 
Yeah. Small, but numerous changes in many different locations aren't
really suited to our usual one-commit-per-logical change bit. It might
be better to branch off, run the sed call or whatever will be used to
update the entire tree, then submit a PR.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

2016-12-04 Thread Daniel Campbell
On 12/04/2016 06:58 PM, Mike Gilbert wrote:
> On Sun, Dec 4, 2016 at 6:31 PM, A. Wilcox <awil...@adelielinux.org> wrote:
>> Roadmap
>> - ---
>>
>> Since the shell environment is flexible, this change can be
>> implemented almost immediately; the defaults specified in the Gentoo
>> base profile ensure that at worst nothing will immediately change.  As
>> forks, derivatives, and other organisations change the environment
>> variables in their profiles or ``make.conf`` files, all updated
>> ebuilds will immediately reflect the changes.
>>
>> During this, the variables can be added to the EAPI=7 specification,
>> and may eventually be added to PMS §11.1.
> 
> It's not clear to me why this should be defined in PMS, especially if
> this is going to be a profile variable in make.defaults.
> 
> I think we would only need to add it to PMS if you need to package
> manager to compute the value based on the running system. Is that what
> you had in mind here? If so, you will need to include that algorithm
> in your patch.
> 
How would we ensure (or encourage) that other distros based on Gentoo
would follow this practice? Adding things to PMS isn't a panacea, sure,
but from what I can tell it seems the goal here is to allow distros
based on us to correctly *show* that without changing hundreds of lines
in the package tree. Maybe that's outside of PMS; if so, where does this
belong?

Of course, this solution requires action/patching on our behalf as well,
but it seems like a long-term goal that, when completed, may be suitable
for addition in some sort of standard document, even if it's a wiki page
on how to roll your own distro based on us.

It didn't seem to me that there was any intention to automatically guess
which distro it is; the people in charge of each distro's package tree
should be setting those variables to the correct value, and it should be
accessible throughout the tree(s).

As OP mentioned, at worst it does nothing until it 'spreads' throughout
the tree. The end result is anyone could fork us, change DISTRO and
DISTRO_BUG_URL, and instantly have a starting point for their new
distro. I'm not aware of any other distro that would make forking or
spinning off _this_ easy. That could turn into renewed interest in
Gentoo or possibly even better inter-distro relations, since bugs would
be going to the correct places.

To OP: This idea looks good to me; do you have any proofs of concept for
use in common places like ebuilds, metadata.xml (if you intend for it to
be used there), etc? If we had a more visual idea of how it worked,
maybe more people would understand and have an idea of where to put it
if it doesn't fit in with PMS's scope.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] (OT) Accounting systems: Ledger-CLI vs GNUcash

2016-12-04 Thread Daniel Campbell
On 12/04/2016 04:03 PM, M. J. Everitt wrote:
> On 04/12/16 23:49, Robin H. Johnson wrote:
>> On Sun, Dec 04, 2016 at 11:07:59PM +, M. J. Everitt wrote:
>>> I gather both Quickbooks and Sage have a more modular approach to
>>> "proper" accounting software applicable to small and large businesses. I
>>> know my mother used Quickbooks in the past with good success and the
>>> support of her accountant, but Sage is known to be equally accessible. I
>>> would imagine there is an appropriate version for not-for-profit or
>>> charities, perhaps you can seek advice with the person(s) already
>>> contacted for accounting/finance purposes?!
>> Our CPA (Yes, we do have one) only recommends QuickBooks, but has used a
>> variety of other proprietary systems (none of which he recommends at
>> all!).
>>
>> The catch is that either Quickbooks or Sage would be a violation of the
>> social contract's libre-licence dependence clause.
>>
>> Ledger HAS filled most of our needs thus far, but lacks in reporting and
>> some automation:
>> - I'd love to automatically generate lots of depreciation
>>   entries, but can't yet.
>> - Something to anonymize private information in some entries, so that
>>   the actual Ledgers can be published for transparency.
>>
> Thanks for the clarification, Robin. It may be worth reviewing that
> social contract to allow us better compliance if deemed worthwhile!
> 
> :]
> 
Compliance with what? If others desire Quickbook support, they can make
a tool to convert from ledger. There's no good reason for a non-profit,
libre software organization to use and depend on proprietary software.
Did nobody learn a lesson from BitKeeper?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass

2016-12-04 Thread Daniel Campbell
On 12/04/2016 10:10 AM, james wrote:
> On 12/04/2016 02:22 AM, Robin H. Johnson wrote:
>> On Sat, Dec 03, 2016 at 06:30:29PM -0500, William L. Thomson Jr. wrote:
>>>> 
>>>> Net Total: $50,924.19
>>>> 
>>> So from 09-16 avg of ~$4.6k per year over 11 years.
>> 10 years of participation, 9 of which we got paid for. So ~$5.7k/year.
>> If we got paid for 2013: ~$5.4k/year over 10 years.
>>
>>> With that really being earned by people doing GSoC. Not the same as if
>>> Google donated a lump sum of money to further development per say the
>>> Councils plans. Only 1 hardware donation.
>> That's the payment to the organization for mentoring and managing the
>> students, separate from what the students doing GSoC earned.
>>
>> If the student's work was of use to Gentoo, then it's ALSO $5000-$5500
>> per student that we've had in man-hours. I do use that disclaimer,
>> because I know the integration rate for Gentoo students much lower than
>> it should be.
>>
>> 2006: 10 students
>> 2007: 8 students
>> 2008: 5 students
>> 2009: 6 students
>> 2010: 16 students
>> 2011: 14 students
>> 2012: 8 students
>> 2013: 6 students
>> 2014: 3 students
>> 2016: 5 students
>>
>> Total: 81 students.
>> Assuming $5k/student: $405,000 in student payments, over 11 years.
>>
>> I don't know how many students we've failed: I do know it's been at
>> least one (I failed them. Their original mentor had medical issues, I
>> took over, and they provided a mocked video of their work and no code by
>> midterm).
>>
>>> I believe past sponsors such as GNi incurred costs in the ~$5k range
>>> monthly.
>>> I would assume some hosting sponsors to be averaging a few thousand
>>> at minimum
>>> per year.
>> The cost to GNi was much closer to $1k/month, mostly in potential lost
>> revenue if the hardware COULD be used for income (it was already a sunk
>> cost, and didn't have other users). For our present major hosting
>> sponsors, I believe we're more in line with $250-$400/month, but again
>> mostly older hardware that isn't of much other salable use.
>>
>>> Just as an example. FreeBSD is seeking $1.25 Million in a fundraiser
>>> with
>>> $882k thus far.
>>> https://www.freebsdfoundation.org/
>> $1.25M is their annual fund-raising target for this year and last. Not a
>> specific fund-raiser, but their annual target.
>> For 2016 Q1-Q3, on the $1.25M, they report $293k in contributions.
>> For 2015, on a $1.25M target, they reported $657k in contributions.
>> For 2014, on a $1M target, they reported $2.4M in contributions.
>>
>>> They seem to average in the hundreds of thousands every year in
>>> contributions
>>> https://www.freebsdfoundation.org/about/financials/
>> They're also got a good few years on us (as do Apache).
>>
>>> Always looked at FreeBSD when I was a Gentoo Trustee. Great
>>> foundation! Passed
>>> the 5 year probation period with IRS, and other stuff.
>> The Apache Foundation was very beneficial to look at I found, because
>> they kept superb public records, but also were not hampered by some of
>> our restrictions about depending on non-open software (they & the perl
>> foundation BOTH use QuickBooks on Windows for their accounting).
> 
> 
> GNUcash is superior to Quickbooks, as it is a 'double entry' accounting
> system. Last time I check Quickbooks was not 'double entry' and that is
> a big deal in accounting.  There is a module that allows entries via
> Android now with GNUcash, but is not an official part of GNUcash.org. I
> use GNUcash with my company, but not the Android smartphone module.
> 
> 
> http://gnucash.org
> 
> http://www.techrepublic.com/article/gnucash-a-powerful-mobile-financial-tool-for-android/
> 
> 
> 
> Serious inquires could be directed to 'gnucash-u...@gnucash.org' as this
> accounting software is robust, under active development and even the
> devs 'chime in' on  routine basis.  All in all, gnucash is an
> outstanding piece of FOSS software; much better than Quickbooks as many
> on the discussion lists attest to on a routine basis. It is in portage
> and it runs on windows and other platforms.
> 
> 
> hth,
> James
> 
> 
>> https://www.apache.org/foundation/records/
>>
>> I draw your attention to their last 990 filing:
>> https://www.apache.org/foundation/records/990-2014.pdf
>> - $1.2M in annual income
>> - $858k spend on infrastructure,
>>   of which >$400k was marked directly as IT spending.
>> - $1.8M in net assets
>>
> 
> 
iirc, we're using Ledger (http://ledger-cli.org), which is also
double-entry accounting. It uses a text file for its information, and
has a ton of reporting features that make it trivial to produce reports.
I use it to manage my personal finances, as well.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Review request: Ruby 2.0 removal news item

2016-12-04 Thread Daniel Campbell
On 12/03/2016 11:51 PM, Hans de Graaff wrote:
> Title: Ruby 2.0 removal; Ruby 2.1 default
> Author: Hans de Graaff <gra...@gentoo.org>
> Content-Type: text/plain
> Posted: 2016-12-04
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed:  
> Ruby MRI 2.0 has been retired by upstream in February 2016.[1]
> We remove Ruby MRI 2.0 support from the tree now. Ruby MRI 2.1 remains
> activated in base profile's RUBY_TARGETS variable by default.
> 
> If your currently eselected Ruby interpreter is ruby20, our
> recommendation is to change it to ruby21. At the moment Ruby MRI 2.1
> delivers the best possible support of all Ruby interpreters in tree.
> 
> Check the current setting via:
> 
>   eselect ruby show
> 
> Change the current setting to Ruby MRI 2.1 via:
> 
>   eselect ruby set ruby21
> 
> [1] https://www.ruby-lang.org/en/news/2016/02/24/support-plan-of-ruby-2
> -0-0-and-2-1/
> 

1. Do users need to know about MRI? I had to search the Web to figure
out that it's referring to Matz's Ruby Interpreter (or CRuby), which is
the reference implementation. This information (if important) may be
useful to include, like "Ruby MRI (Matz's Ruby Interpreter) 2.1 ...".

2. Grammar and tone seems a little off. Here's my attempt at a rewrite,
if you don't mind:

~~~

Ruby MRI (Matz's Ruby Interpreter) 2.0 was retired by upstream in
February 2016. [1] Following this, Ruby MRI 2.0 support will be removed
from Gentoo in favor of Ruby MRI 2.1. We recommend updating to the
'ruby21' target as soon as possible.

[insert eselect guide here]

~~~

I wrote my edit trying to stay close to the original writing style. I
hope it's satisfactory.

The eselect part reads well. We could remove the "MRI" part, but as a
non-Rubyist I don't feel qualified to determine whether it's important
or not.

I felt that the base profile variable mention and the bit about MRI
being the best interpreter were better left out, but it also doesn't
actively hurt it.

Someone more experienced in news-writing should clarify that. Overall I
thought it was a good initial draft.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Uppercase characters in package names

2016-12-03 Thread Daniel Campbell
On 12/03/2016 07:00 AM, William L. Thomson Jr. wrote:
> On Saturday, December 3, 2016 8:59:09 AM EST Michał Górny wrote:
>> On Fri, 2 Dec 2016 23:26:53 -0800
>>
>> Daniel Campbell <z...@gentoo.org> wrote:
>>> On 12/02/2016 10:47 AM, Michał Górny wrote:
>>>>
>>>> I'd say keeping things lowercase makes sense for end user packages. For
>>>> pure dependencies with consistent conventions (e.g. perl), it makes
>>>> sense to keep upstream's naming.
>>>
>>> What is a pure dependency? Do we handle those differently than the
>>> garden-variety dependencies in other packages?
>>
>> It is a package that is rarely installed directly, and rather commonly
>> taken as a dependency of another package. For example, packages that
>> install no programs and just Perl/Python/... modules.
> 
> Keep in mind some will emerge libraries dependencies for their own projects 
> and development. They do not always have to be merged as a dependency of 
> another package.
> 
> It might be confusing to know when it is acceptable to use mixed case and not.
> 
I think Michał was talking strictly in the case of a library being
pulled in as a dependency, e.g. program A is depending on library B, but
library B is so specialized that it doesn't really get pulled in
manually. When emerging program A, library B is pure. When emerging
library B deliberately, it becomes the target package.

(If I have this wrong please correct me, Michał. Also forgive me if the
glyph for the last letter in your name is wrong.)

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass

2016-12-03 Thread Daniel Campbell
On 12/03/2016 03:01 PM, Robin H. Johnson wrote:
> On Sat, Dec 03, 2016 at 04:49:19PM -0500, William L. Thomson Jr. wrote:
>> No matter what terms you use, Google uses Gentoo to build products it makes 
>> money off. In that sense I think it could give back allot. If not in 
>> donations, resources (tinderbox), etc.
> Here's the financial parts of what Google has given us, that I can
> quantify. It DOESN'T include anything of the 20% time that might have
> been used in Gentoo's favour [some past Google-employed developers have
> specifically said they were spending Friday afternoons doing Gentoo
> dev], or paid Gentoo stuff that overlapped their actual job needs
> (ChromeOS-related).
> 
> Non-GSOC:
> -
> 2011: Google donated brand-new Dell servers, that with their volume
> discount, had an invoice price of $4331.60, and a Dell list price over
> $6k. Those servers are hosted at OSUOSL, and are still in active use
> (dipper, blackcap). 
> Net Subtotal: $4,331.60
> 
> GSOC:
> -
> Gross Payments
> (including reimbursement for mentor summit travel expenses)
> 2009:  $5,151.59
> 2006:  $7,000.00
> 2007:  $4,500.00
> 2008:  $3,000.00
> 2010: $11,001.25
> 2011:  $9,891.77
> 2012:  $7,000.00
> 2013:  $0.00 [1]
> 2014:  $4,200.00
> 2015:  $0.00 - did not participate
> 2016:  $4,700.00 [2] 
> Gross Subtotal: $56,444.61
> Less reimbursed travel expenses: $9,852.02
> Net Subtotal: $46,592.59
> 
> 
> Net Total: $50,924.19
> 
> 
> [1] 
> - Details in bug 488142. Not locked, no personal information in it
>   (other year GSOC bugs are locked due to containing mentor personal
>   information).
> - No record could be found for a 2013 invoice, in our bank records OR
>   Google's invoice archive [MANY thanks to Antarus and the Google
>   accounting department who did pull all historical invoices submitted
>   by Gentoo].
> - presumed we did not submit before the deadline and thus forfeited the
>   payment & reimbursement.
> - Net Amount if we had filed: $2591.55
> -- 6 students * $500/student: $3000
> -- Less $2608.45 in actual travel expenses (max $2200 reimbursement)
> - Net for non-filing: $-2608.45
> - NOT included in reimbursement subtotal above.
> 
> [2] Invoice submitted 2012/11/29, payment NET30 period ends 2016/12/29
> 
I just wanted to point this e-mail out and thank you for the effort
spent to share information like this. This is a great step, and once we
get the books in order, sharing this information using automated means
could get us part of the way to 501(c)3 status.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: Userkit.eclass

2016-12-03 Thread Daniel Campbell
On 11/28/2016 03:26 PM, M. J. Everitt wrote:
> On 28/11/16 19:39, William L. Thomson Jr. wrote:
>> For now who cares about other OS or distros. If Gentoo gets its house in 
>> order 
>> others may follow.
>>
> At the risk of a huge flame, remind me, who uses Gentoo again?!
> 
Unless something's changed in the past year or two, iirc Sony uses
Gentoo as part of the backend of Gaikai, Google's used it for the base
of ChromeOS... I can't speak for other 'big names', but Gentoo's not
quite as niche as the small, active userbase has most of us believing.

There's also our downstream neighbors: Funtoo, Pentoo, Sabayon,
Calculate, Exherbo, etc

As for communities, lots of places from 4chan to lainchan, various mesh
network users, security-conscious communities, OCD support groups
(kidding), etc.

I'm sure I'm missing some mentions here; this is just off the top of my
head.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Uppercase characters in package names

2016-12-03 Thread Daniel Campbell
On 12/02/2016 11:55 PM, Michał Górny wrote:
> On Fri, 2 Dec 2016 23:21:34 -0800
> Daniel Campbell <z...@gentoo.org> wrote:
> 
>> On 12/02/2016 10:45 AM, Ian Stakenvicius wrote:
>>> On 02/12/16 01:31 PM, Ciaran McCreesh wrote:  
>>>> On Fri, 2 Dec 2016 13:24:29 -0500
>>>> Mike Gilbert <flop...@gentoo.org> wrote:  
>>>>> On Fri, Dec 2, 2016 at 1:10 PM, Ciaran McCreesh
>>>>> <ciaran.mccre...@googlemail.com> wrote:  
>>>>>> On Fri, 2 Dec 2016 13:02:48 -0500
>>>>>> Mike Gilbert <flop...@gentoo.org> wrote:
>>>>>>> The devmanual states:
>>>>>>>
>>>>>>> The name section should contain only lowercase non-accented
>>>>>>> letters, the digits 0-9, hyphens, underscores and plus characters.
>>>>>>> Uppercase characters are strongly discouraged, but technically
>>>>>>> valid.
>>>>>>>
>>>>>>> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
>>>>>>>
>>>>>>>
>>>>>>> Why are uppercase characters strongly discouraged?
>>>>>>>
>>>>>>> Wouldn't it make sense to follow upstream's naming convention?
>>>>>>
>>>>>> What's upstream's naming convention for Firefox?  
>>>>>
>>>>> I have no idea. What's your point?  
>>>>
>>>> That naming conventions are generally complicated and a mess, and that
>>>> no-one wants to have to remember whether it's firefox, Firefox, or
>>>> FireFox.
>>>>  
>>>
>>> It's also more convenient at the consone to just type everything
>>> lowercase.  I expect that's the primary reason it's discouraged.
>>>
>>>
>>>
>>>   
>> That seems the most likely to me as well.
>>
>> We could make a more "user friendly" feature by setting up bash
>> completion for package names, but that sounds a) daunting, b)
>> error-prone, and c) probably not worth the time spent writing the
>> script(s) necessary.
> 
> There is a bash completion script for that for a long time now.
> However, it no longer works correctly with new bash-completion versions
> and it seems that nobody cares enough to fix it.
> 
Oh, that's good to know. I didn't find anything relevant with
'bash-completion' in its name in the tree. Where should I look for this
script?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Uppercase characters in package names

2016-12-03 Thread Daniel Campbell
On 12/02/2016 11:59 PM, Michał Górny wrote:
> On Fri, 2 Dec 2016 23:26:53 -0800
> Daniel Campbell <z...@gentoo.org> wrote:
> 
>> On 12/02/2016 10:47 AM, Michał Górny wrote:
>>> On Fri, 2 Dec 2016 13:02:48 -0500
>>> Mike Gilbert <flop...@gentoo.org> wrote:
>>>   
>>>> The devmanual states:
>>>>
>>>> The name section should contain only lowercase non-accented letters,
>>>> the digits 0-9, hyphens, underscores and plus characters. Uppercase
>>>> characters are strongly discouraged, but technically valid.
>>>>
>>>> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
>>>>
>>>>
>>>> Why are uppercase characters strongly discouraged?
>>>>
>>>> Wouldn't it make sense to follow upstream's naming convention?  
>>>
>>> I'd say keeping things lowercase makes sense for end user packages. For
>>> pure dependencies with consistent conventions (e.g. perl), it makes
>>> sense to keep upstream's naming.
>>>   
>> What is a pure dependency? Do we handle those differently than the
>> garden-variety dependencies in other packages?
> 
> It is a package that is rarely installed directly, and rather commonly
> taken as a dependency of another package. For example, packages that
> install no programs and just Perl/Python/... modules.
> 
Ah, thanks for explaining that. Makes a lot more sense.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Revision bumps vs git commits atomicity

2016-12-02 Thread Daniel Campbell
On 12/02/2016 07:14 AM, Andrew Savchenko wrote:
> Hi all!
> 
> Right now we have two somewhat conflicting policies (at least up to
> my understanding of them):
> 
> 1) git atomic commits [1]:
> each logical change should be a separate commit.
> 
> 2) revision bump policy [2]:
> each change sufficiently affecting application run-time or
> installed files should have a revision bump.
> 
> Let's consider the following quite common scenario: package foo-1.0
> should be updated to foo-1.1, but aside from version bump there is
> a set of accumulated issues which maintainer is willing to handle,
> e.g.:
> - bump to EAPI 6;
> - fix several runtime bugs (still present in the new version);
> - install missing documentation;
> - add previously omitted USE flags for some tools of controllable
> functionalities;
> - etc...
> 
> If both policies are to be followed, users will see something like:
> foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as
> a separate commit with a revision bump).
> 
> While such versioning change is technically correct, it is
> confusing for our users and makes future maintainance harder,
> because of multiple file renames (yeah, I know about git diff
> --find-renames, but this kludge is not perfect).
> 
> What about the following forkflow:
> - version bump first with minimal changes required, but without
> pushing commit to the tree;
> - make each logical change as a separate commit without revision
> bumps and without pushing stuff to the tree (of course repoman
> scan/full is required as usual for each commit);
> - well test package after the last commit (that it builds with
> various USE flag combinations, old and new functionality works fine
> and so on);
> - fix any problems found and only afterwards push changes to the
> tree.
> 
> This way users will see only foo-1.0 -> foo-1.1 change in the tree,
> while git will still retain each logical change as a separate
> commit, which will make future maintenance and debugging much
> easier.
> 
> Of course a separate git branch may be used as well, but using
> branches for each half-a-dozen set of commits looks like an
> overkill to me.
> 
> Thoughts, comments?
> 
> [1] https://devmanual.gentoo.org/ebuild-maintenance/index.html
> [2] https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
> 
> Best regards,
> Andrew Savchenko
> 
I've always worked as if each commit needed to be working for Gentoo
users. So if I need to version bump, that's a separate commit. However,
let's say I found a bug in the ebuild itself for foo-1.0. The way I see
it is I should bump to foo-1.0-r1 to fix the bug in that ebuild, _then_
version bump so that foo-1.1 already has the fixes that foo-1.0-r1 has.
If I version bump first, then I have to revbump both and that just
increases my odds of forgetting to put the fixes into all the correct
ebuilds.

It results in the appropriate fixes in the older package, and the new
version comes with the old one's fixes (plus any changes the new ebuild
might need due to upstream changes).

Does that make any sense?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Tinderboxing efforts in Gentoo

2016-12-02 Thread Daniel Campbell
On 12/02/2016 06:09 AM, Michael Mol wrote:
> On Friday, December 02, 2016 02:10:27 PM Michał Górny wrote:
>> Hi, everyone.
>>
>> I've heard multiple times about various tinderbox projects being
>> started by individuals in Gentoo. In fact, so many different projects
>> that I've forgotten who was working on most of them.
>>
>> I know that Toralf is doing tinderboxing for most of the stuff.
>> What other projects do we have there? What is their status?
>>
>> Is there anything we could try to integrate with pull requests to get
>> a better testing?
> 
> If there's a mostly-turnkey VM I can run to contribute to Tinderboxing, I 
> have 
> one or two systems I could benefit from some heat from over the winter. It's 
> that or bring out the electric space heater. Was talking with my wife about 
> mining Doge on one of them last night...
> 
I second that. I have a hexcore CPU and 16 GB of RAM, most of which I
don't use unless I'm compiling. If there's a guide that can get me up
and running with a VM within an hour or so, I'd be more than willing to
pitch in some cycles.

mgorny mentioned PRs, however... are such efforts moot if I don't have a
GitHub account?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Uppercase characters in package names

2016-12-02 Thread Daniel Campbell
On 12/02/2016 10:47 AM, Michał Górny wrote:
> On Fri, 2 Dec 2016 13:02:48 -0500
> Mike Gilbert <flop...@gentoo.org> wrote:
> 
>> The devmanual states:
>>
>> The name section should contain only lowercase non-accented letters,
>> the digits 0-9, hyphens, underscores and plus characters. Uppercase
>> characters are strongly discouraged, but technically valid.
>>
>> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
>>
>>
>> Why are uppercase characters strongly discouraged?
>>
>> Wouldn't it make sense to follow upstream's naming convention?
> 
> I'd say keeping things lowercase makes sense for end user packages. For
> pure dependencies with consistent conventions (e.g. perl), it makes
> sense to keep upstream's naming.
> 
What is a pure dependency? Do we handle those differently than the
garden-variety dependencies in other packages?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Uppercase characters in package names

2016-12-02 Thread Daniel Campbell
On 12/02/2016 08:09 PM, Nick Vinson wrote:
> 
> [snip]
> Personally, I've disliked that differentiation. Most people don't pay
> close enough attention to such things.  For example, how many people
> think iOS and IOS are the same thing?
> 
> -Nicholas Vinson

Anyone familiar with Wii homebrew knows they're different, but I see
your point. :)
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Uppercase characters in package names

2016-12-02 Thread Daniel Campbell
On 12/02/2016 10:45 AM, Ian Stakenvicius wrote:
> On 02/12/16 01:31 PM, Ciaran McCreesh wrote:
>> On Fri, 2 Dec 2016 13:24:29 -0500
>> Mike Gilbert <flop...@gentoo.org> wrote:
>>> On Fri, Dec 2, 2016 at 1:10 PM, Ciaran McCreesh
>>> <ciaran.mccre...@googlemail.com> wrote:
>>>> On Fri, 2 Dec 2016 13:02:48 -0500
>>>> Mike Gilbert <flop...@gentoo.org> wrote:  
>>>>> The devmanual states:
>>>>>
>>>>> The name section should contain only lowercase non-accented
>>>>> letters, the digits 0-9, hyphens, underscores and plus characters.
>>>>> Uppercase characters are strongly discouraged, but technically
>>>>> valid.
>>>>>
>>>>> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
>>>>>
>>>>>
>>>>> Why are uppercase characters strongly discouraged?
>>>>>
>>>>> Wouldn't it make sense to follow upstream's naming convention?  
>>>>
>>>> What's upstream's naming convention for Firefox?
>>>
>>> I have no idea. What's your point?
>>
>> That naming conventions are generally complicated and a mess, and that
>> no-one wants to have to remember whether it's firefox, Firefox, or
>> FireFox.
>>
> 
> It's also more convenient at the consone to just type everything
> lowercase.  I expect that's the primary reason it's discouraged.
> 
> 
> 
> 
That seems the most likely to me as well.

We could make a more "user friendly" feature by setting up bash
completion for package names, but that sounds a) daunting, b)
error-prone, and c) probably not worth the time spent writing the
script(s) necessary.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Please retain authorship of contributed patches

2016-12-01 Thread Daniel Campbell
On 12/01/2016 02:13 PM, Andrey Utkin wrote:
> On Thu, Dec 01, 2016 at 12:50:42PM -0800, Daniel Campbell wrote:
>> I completely agree that we should credit (and thank) contributors. I'm
>> not sure if I'm doing things correctly, but when I'm dealing with a bug
>> and users contribute patches or edits to ebuilds, I try to credit them
>> in my commit message, often asking them which nickname they'd prefer so
>> I can give credit to the "right" name. Is this a practice you find adequate?
> 
> As turned out, the problem was lack of communication rather than
> misprocessing of original contribution.
> 
> In Git, t's harder to erase the original authorship than to retain it,
> so I don't see the need to discuss subtleties here. Common practice I
> see in such projects as FFmpeg and Kernel is to pick the original patch
> if possible, or, if credit must be given just for mere concept, the
> contributor is mentioned in "Suggested-by:" line or just informally.
> 
>> Thanks for bringing this to attention. It's somewhat related to another
>> discussion we've been having about copyright, and it may be worth
>> considering protocol for situations like the one you've outlined.
> 
> Could you  please give a link to archives of that discussion?
> 
I'm a little busy this afternoon, but I have the subject titles for a
few of the relevant posts:

[gentoo-dev] Contributed ebuilds and copyright questions
(Oct 24th)

[gentoo-dev] GLEP RFC: Third-party contributions
(Oct 27th)

I remember one more, I believe started by rich0? But it's not in my mail
client anymore as I routinely purge older discussions. I can look for it
tonight if you'd like.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Please retain authorship of contributed patches

2016-12-01 Thread Daniel Campbell
On 11/30/2016 01:23 PM, Andrey Utkin wrote:
> I'm quite sure this angry rant won't be pleasant to read for anybody,
> but still I believe this post serves the good of Gentoo and this issue
> is technical enough to be discussed on gentoo-dev. Also gentoo-pr list
> seems retired anyway.
> 
> This is a second time I've got into a situation when a new ebuild
> submitted by me gets to mainline with minimal changes but not retaining
> my authorship at all.
> 
> First time it was here: https://github.com/gentoo/gentoo/pull/361 and my
> rant was endorsed by monsieurp and the committer made excuses.
> 
> This time the discussion between me and the committer has never
> happened.
> 
> My PR: https://github.com/gentoo/gentoo/pull/2765
> 
> My bugzilla ticket linked to it:
> https://bugs.gentoo.org/show_bug.cgi?id=599088
> 
> After my pull request from Nov 6, the following commit gets into mainline:
> 
> commit e19f46dfca967f4195eedf3f37a7882fbb37b796
> Author: Matthew Thode <prometheanf...@gentoo.org>
> Date:   Tue Nov 15 13:55:17 2016 -0600
> 
> dev-python/secretstorage: adding for keyring
> 
> Package-Manager: portage-2.3.0
> 
> 
> The difference between my submission and final variant by Matthew is big
> in number of lines, but is trivial in content as you can see below, so I
> don't believe that Matthew has written his variant from scratch on his
> own (he hasn't given any note on tickets on bugs.g.o or github), it
> seems more like intentional swapping and amending original lines
> retaining identical outcome.
> 
> Not that authorship of one or two commits is so crucial for me, or that
> I'm the most ambitious wannabe-contributor. Hell, there's not much of
> code at all in the ebuild - it's trivial; but also not much is needed
> here to give credit. I have contributed to quite some FOSS projects, and
> have run into theft of my patches a couple of times, and it never was by
> pure accident.
> 
> I beg affiliated Gentoo developers to stay sane and be thinking not just
> about numbers of your commits, but also about community spirit and
> relationships. Of course inexperienced contributor gets things not right
> first. In such cases, great maintainers fix that and retain original
> authorship; good maintainers request for changes and resubmission.
> 
> In no way I'm going to drift away from Gentoo because of this issue, no
> alternatives around. (I even have a gradually maturing idea to become
> Gentoo contributor on regular basis.)
> 
> Just for record, a list of projects I've contributed to: FFmpeg, Linux
> kernel, VLC, GStreamer, Kamailio, Mcabber, Gajim, v4l-utils.
> 
> 
> [snip]
> 

I completely agree that we should credit (and thank) contributors. I'm
not sure if I'm doing things correctly, but when I'm dealing with a bug
and users contribute patches or edits to ebuilds, I try to credit them
in my commit message, often asking them which nickname they'd prefer so
I can give credit to the "right" name. Is this a practice you find adequate?

Thanks for bringing this to attention. It's somewhat related to another
discussion we've been having about copyright, and it may be worth
considering protocol for situations like the one you've outlined.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Developer GitHub usernames

2016-12-01 Thread Daniel Campbell
On 11/30/2016 01:19 PM, Michał Górny wrote:
> On Wed, 30 Nov 2016 01:33:24 -0800
> Daniel Campbell <z...@gentoo.org> wrote:
> 
>> On 11/26/2016 01:08 AM, Michał Górny wrote:
>>> On Sat, 26 Nov 2016 00:03:59 -0800
>>> Daniel Campbell <z...@gentoo.org> wrote:
>>>   
>>>> 
>>>> A funny deficiency of GitHub is it doesn't allow for open conversations.
>>>> You're always forced to talk about something directly related to the
>>>> code, like an Issue or a Commit. Gists can be somewhat analogous to an
>>>> open discussion, but that strikes me as abuse of the medium.
>>>> Additionally, it's not a threaded format so it's hard to guess which
>>>> branch of conversation you're on.
>>>>
>>>> Of course sometimes you *want* to focus strictly on the code, but that's
>>>> not how real-world organizations work. They're made of people, and most
>>>> people end up talking about things *around* the code that are still
>>>> important, like the various RFCs that we post here on the ML. None of
>>>> what GitHub offers is suitable for that imo.
>>>>   
>>>
>>> GitHub is a code hosting and review tool, not a forum. It's not
>>> a replacement for everything ever invented.
>>>   
>> The GitHub guys seem to disagree with you; unless you consider custom
>> emoji support (and reactions, thumbs-up counts, etc) integral to the
>> code review process.
> 
> Excuse me but how are your visual feelings even remotely related to
> the topic at hand? If you want to troll GitHub, please find
> an appropriate forum to do so, and don't spam the mailing list.

It was a simple observation that indicates they care about a little bit
more than _just_ code review. I'm not sure how a counter argument is
considered spam.
> 
>> Since you didn't address it, what tone was intended by the quip about
>> others "pretending" to not use GitHub?
> 
> I'm not going to reply to your provocation.
> 

Again, not meant to be provocative. The best way to figure out what
someone meant by something is to ask them. Rather than assume, I figured
asking would be the normal thing to do. My apologies if you find that
offensive.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Developer GitHub usernames

2016-11-30 Thread Daniel Campbell
On 11/26/2016 01:08 AM, Michał Górny wrote:
> On Sat, 26 Nov 2016 00:03:59 -0800
> Daniel Campbell <z...@gentoo.org> wrote:
> 
>> 
>> A funny deficiency of GitHub is it doesn't allow for open conversations.
>> You're always forced to talk about something directly related to the
>> code, like an Issue or a Commit. Gists can be somewhat analogous to an
>> open discussion, but that strikes me as abuse of the medium.
>> Additionally, it's not a threaded format so it's hard to guess which
>> branch of conversation you're on.
>>
>> Of course sometimes you *want* to focus strictly on the code, but that's
>> not how real-world organizations work. They're made of people, and most
>> people end up talking about things *around* the code that are still
>> important, like the various RFCs that we post here on the ML. None of
>> what GitHub offers is suitable for that imo.
>> 
> 
> GitHub is a code hosting and review tool, not a forum. It's not
> a replacement for everything ever invented.
> 
The GitHub guys seem to disagree with you; unless you consider custom
emoji support (and reactions, thumbs-up counts, etc) integral to the
code review process.

Since you didn't address it, what tone was intended by the quip about
others "pretending" to not use GitHub?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Developer GitHub usernames

2016-11-26 Thread Daniel Campbell
On 11/21/2016 12:46 PM, Mike Gilbert wrote:
> On Mon, Nov 21, 2016 at 3:28 PM, Jeroen Roovers <j...@gentoo.org> wrote:
>> On Mon, 21 Nov 2016 10:01:47 +0100
>> Michał Górny <mgo...@gentoo.org> wrote:
>>
>>> Since some of our people don't want to admit they're using GitHub or
>>> otherwise want to pretend they're not
>>
>> Interesting how you simply can't understand that some people hate
>> mixing work and pleasure[1] and how you then need to ridicule what you
>> don't understand, Ciaran.
>>
>>
>>  jer
>>
>>
>>
>> [1] Or indeed hate using some third party's proprietary website
>> that has the barest possible support for managing multiple user
>> profiles in a single account and seems to be geared toward the Web
>> 2.0 or "social media" inclined.
>>
> 
> I don't see what you find offensive about mgorny's message. You're
> overreacting to "ridicule" that simply isn't there.
> 
I can understand taking issue with the tone. Maybe it was meant to be a
joke, since almost everyone and their brother is on GitHub. I closed my
account there a while ago due to personal issues with their behavior and
terms. I also found that despite having access to Gentoo repositories,
policies regarding the treatment of the repos (at the time) wasn't
clear, so I never did anything in Gentoo space on GitHub to begin with
for fear of breaking something or pissing someone off.

I'm not sure if I'm alone on that, but yeah; without any context the
quote could be interpreted as a jab at people who don't use GitHub.
*shrug* Rather than guess about it why not ask Michał what he meant by it?


A funny deficiency of GitHub is it doesn't allow for open conversations.
You're always forced to talk about something directly related to the
code, like an Issue or a Commit. Gists can be somewhat analogous to an
open discussion, but that strikes me as abuse of the medium.
Additionally, it's not a threaded format so it's hard to guess which
branch of conversation you're on.

Of course sometimes you *want* to focus strictly on the code, but that's
not how real-world organizations work. They're made of people, and most
people end up talking about things *around* the code that are still
important, like the various RFCs that we post here on the ML. None of
what GitHub offers is suitable for that imo.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Stabilisation procedure

2016-11-25 Thread Daniel Campbell
On 11/22/2016 12:06 AM, Alice Ferrazzi wrote:
> On Sat, Nov 19, 2016 at 12:55:09AM -0800, Daniel Campbell wrote:
>> On 11/17/2016 01:07 PM, Robin H. Johnson wrote:
>>> On Thu, Nov 17, 2016 at 03:05:41PM +0100, Kristian Fiskerstrand wrote:
>>>>> Isn't it implied that any stabilisation is approved by the maintainer?
>>>>> Has it ever been acceptable to go around stabilising random packages?
>>>>>
>>>>
>>>> Explicit > Implicit when we're updating things anyways.
>>>>
>>>> There are scenarios where e.g Security is calling for stabilization ,
>>>> I'll add some info to the draft security GLEP with some requirements for
>>>> when this can happen without maintainer involvement as well..
>>>>
>>>> Ultimately maintainer is responsible for the state of the stable tree
>>>> for the packages they maintain and should be taking proactive steps for
>>>> this also for security bugs, it doesn't "always" happen like that.
>>>
>>> The interaction of this proposal and the prior discussion of allow
>>> maintainers to document the maintenance policy of given packages is
>>> where it would really come into play.
>>>
>>> Using two packages for examples:
>>> app-admin/diradm: I am the upstream author as well as the package
>>> maintainer. I care about it being marked stable. I'd prefer the normal
>>> policy of other people asking me (with timeout) before touching it.
>>>
>>> app-admin/cancd: It's a very obscure package that I put in the tree
>>> because I needed it, but I haven't personally used it in many years. 
>>> I fix the packaging if it's broken only.
>>> I'm inclined to mark it with 'anybody-may-bump/fix/stabilize'.
>>>
>> Agreed. For most of my packages, I really don't mind since we're all
>> working on Gentoo together, but it'd be super helpful if I was simply
>> notified in the event that a package I maintain has gotten a security
>> bump, patch, or stabilization. Sure, 'git log' and 'git blame' can
>> explain a few things, but if I was going to edit a package, I have the
>> maintainer's e-mail available right there in metadata.xml. To me it's a
>> courtesy that should be a requirement by default, while devs that don't
>> care can use whatever means we agree upon to indicate that they don't care.
>>
>> This creates a "contact first" practice, which it seems we want to
>> encourage. If someone isn't responsive and/or away, that complicates
>> things, but if it's a security concern or the last blocker in a big
>> stabilization effort (looking at you, tcl 8.6...), then it makes sense
>> to just go ahead and make the bumps necessary.
> 
> What about maintainers that are away without writing it in their
> maintainer bug ?
> After how many days of no replay can be fair to touch their package ?
> 
>>
>> -- 
>> Daniel Campbell - Gentoo Developer
>> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
>> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
>>
> 
> 
> 
We have a formal dev-away practice, requiring little more than literally:

ssh m...@dev.gentoo.org; echo "Away for vacation. Back in a week" >
~/.away; exit

A dev can add more details to the file if they want to. If they're gone
and can't be reached at all, then I think a week is enough time for a
developer to check their mail and get (or make) enough time to either
update their dev-away status or otherwise indicate how they feel about a
change that needs their feedback.

Maybe the maintainer-bug case is different if we're talking
proxy-maintainers, but that's a good question; one that maybe p-m should
make on its own before we aim for a global, concrete policy.

I think the requirement for contact is all we should really settle on
formally; the rest being handled in wetware where it belongs. :)
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: Userkit.eclass

2016-11-25 Thread Daniel Campbell
On 11/23/2016 01:08 AM, Michał Górny wrote:
> On Wed, 23 Nov 2016 09:44:33 +0100
> Manuel Rüger <mr...@gentoo.org> wrote:
> 
>> I have not started to write it, but I am considering it and rather want
>> to gather feedback on my idea first.
>> I am aware that https://wiki.gentoo.org/wiki/GLEP:27 exists, but as of
>> right now I haven't seen anyone working on it. The goal of this eclass
>> is to improve user/group handling without touching the PMS.
>>
>> tl;dr: Userkit eclass will improve the user handling by externalizing
>> the configuration to variables that can be set from outside of the ebuild.
>>
>> Userkit.eclass will inherit user.eclass and require bash arrays
>> USERKIT_USER and USERKIT_GROUP for configuration.
>> I will export a pkg_setup with the corresponding setup (basically
>> calling enewuser and enewgroup). It will provide get_user, get_uid,
>> get_group, get_gid and get_home functions.
>> This would allow to do something like "fowners $(get_user):$(get_group)
>> foo".
>>
>> If ${CATEGORY}-${PN}_user and ${CATEGORY}-${PN}_group are set, these
>> will replace the contents of USERKIT_USER and USERKIT_GROUP, allowing
>> the user to fully define everything user/group related.
> 
> How does that all map to multiple users/groups? How does that map to
> USE-conditional users/groups? How does that map to users/groups shared
> between multiple packages?
> 
> Besides, this sounds a lot like games.eclass... will developers be
> required to patch upstream software now to force support for using
> custom users/groups?
> 
>> What happens if the ebuild wants to create multiple users/group?
>> Currently, I want to ignore that case and focus on the 80% ebuilds that
>> can profit from such an eclass.
> 
> Do you have specific numbers? I don't see 80% of ebuilds caring about
> users/groups. I don't see the problem you are trying to fix.
> 
> Is it one of those problems that someone thinks it's awesome to make
> everything declaratory, and add tons of middleware to make the
> declaratory work somehow for the most common use cases?
> 
I think the use-case here is ebuilds that need to create a user and/or
group (www-servers/lighttpd is a good example; alongside pretty much
anything else that needs to run as a separate user and serves
something). In lighttpd's case we don't currently support the ability to
declare which user and group lightty uses; the lighttpd user and
lighttpd group will always be created. Later configuration of users and
groups can be worked with, and iirc we recently patched the initscript
so it handles that use case.

I could see a use-case for someone wanting to install a given daemon or
server with a specific user and/or group. I'm not sure this is the right
approach (nor do I know what is), but I think we have room to think
about a solution; ideally one that is dead-simple to implement and
doesn't have a ton of edge-cases.

What is QA's current policy on user/group creation, btw?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Stabilisation procedure

2016-11-19 Thread Daniel Campbell
On 11/17/2016 01:07 PM, Robin H. Johnson wrote:
> On Thu, Nov 17, 2016 at 03:05:41PM +0100, Kristian Fiskerstrand wrote:
>>> Isn't it implied that any stabilisation is approved by the maintainer?
>>> Has it ever been acceptable to go around stabilising random packages?
>>>
>>
>> Explicit > Implicit when we're updating things anyways.
>>
>> There are scenarios where e.g Security is calling for stabilization ,
>> I'll add some info to the draft security GLEP with some requirements for
>> when this can happen without maintainer involvement as well..
>>
>> Ultimately maintainer is responsible for the state of the stable tree
>> for the packages they maintain and should be taking proactive steps for
>> this also for security bugs, it doesn't "always" happen like that.
> 
> The interaction of this proposal and the prior discussion of allow
> maintainers to document the maintenance policy of given packages is
> where it would really come into play.
> 
> Using two packages for examples:
> app-admin/diradm: I am the upstream author as well as the package
> maintainer. I care about it being marked stable. I'd prefer the normal
> policy of other people asking me (with timeout) before touching it.
> 
> app-admin/cancd: It's a very obscure package that I put in the tree
> because I needed it, but I haven't personally used it in many years. 
> I fix the packaging if it's broken only.
> I'm inclined to mark it with 'anybody-may-bump/fix/stabilize'.
> 
Agreed. For most of my packages, I really don't mind since we're all
working on Gentoo together, but it'd be super helpful if I was simply
notified in the event that a package I maintain has gotten a security
bump, patch, or stabilization. Sure, 'git log' and 'git blame' can
explain a few things, but if I was going to edit a package, I have the
maintainer's e-mail available right there in metadata.xml. To me it's a
courtesy that should be a requirement by default, while devs that don't
care can use whatever means we agree upon to indicate that they don't care.

This creates a "contact first" practice, which it seems we want to
encourage. If someone isn't responsive and/or away, that complicates
things, but if it's a security concern or the last blocker in a big
stabilization effort (looking at you, tcl 8.6...), then it makes sense
to just go ahead and make the bumps necessary.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: Future EAPI version operator changes

2016-11-09 Thread Daniel Campbell
On 11/06/2016 02:52 AM, Michał Górny wrote:
> Hi, everyone.
> 
> Following my previous RFC wrt version operator problems, I'd like to
> start the second part of the discussion: how to improve version
> operators in a Future EAPI?
> 
> I've collected various ideas on operator changes on a wiki page [1].
> I've tried to stay open-minded and cover every possibility, even though
> I doubt some of them would be even considered.
> 
> I should warn you that some of the solutions are interlinked to each
> other, and you probably need to look through the whole page first
> before starting to construct an opinion. For example, specific
> solutions to most of the problems depend on whether we enable version
> ranges and in which form.
> 
> I think we should start by loosely discussing the various ideas
> on the wiki page. Feel free to also point out any missing ideas
> or remarks that would be useful there.
> 
> So, what are your comments?
> 
> [1]:https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes
> 
I think it complicates version matching. Of course, matching the correct
version is a difficult task in itself. Anything that requires the least
necessary change and improves readability and utility the most should
get in. I like the idea of version ranges and slot ranges, but it's
tough to figure out which form is best for that.

Then we have the pesky * that, when used in a version spec, doesn't
follow intuition. Unless a package is slotted for each major or
major.minor version, there isn't a way currently (that I know of) to
express "pull in any version 1.2.x of app-misc/foobar" in a single
declaration/line.

In an attempt at a solution: we already use [] for USE, and () are for
groupings. If bash doesn't yell at us much, maybe {} would be good for
version restrictions. Maybe something like:

>=app-misc/foobar-{1.2..1.4}:=[baz]

To mean "any version of 1.2 or greater, up to version 1.4, inclusive".
We could add in asterisk support to match any sub versions, e.g.
{1.2*..1.4}, but it could get really messy.

While the initial proposal to put the operator in a better place seems
nice on paper, I can only think of the massive amount of work that'd
need to be done to get that change pushed through and re-educate fellow
devs on how to do things going forward. Maybe we should go through some
particularly tricky ebuilds and "try out" the new ideas, to see what the
final product looks like.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] tmpfiles: call for testers

2016-11-08 Thread Daniel Campbell
On 11/08/2016 05:02 PM, Rich Freeman wrote:
> On Tue, Nov 8, 2016 at 7:54 PM, Patrick McLean <chutz...@gentoo.org> wrote:
>> On Tue, 8 Nov 2016 17:41:02 -0600
>> William Hubbs <willi...@gentoo.org> wrote:
>>>
>>> The plan, once the first release is out, is to rewrite this utility
>>> in a better language. I'm considering C, but if I am comfortable by
>>> that time in Go or Rust, I may use one of them.
>>>
>>
>> For a low-level utility that is likely going to be in the default
>> @system set, please use C. Adding dependencies on the go or rust
>> compilers for this is not very nice.
>>
> 
> Assuming I'm looking at the right sources, the actual systemd
> implementation is only 2342 lines of C.  Glancing at the includes, I'm
> not convinced it even requires systemd to run.
> 
> You might want to take a look at either just creating a split ebuild,
> or tweaking it to work standalone if necessary.
> 
Is that including any headers and/or libraries shared by the systemd
umbrella?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


  1   2   3   4   >