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

[james]

On 11/30/2016 05:17 PM, Rich Freeman wrote:

On Wed, Nov 30, 2016 at 4:23 PM, Andrey Utkin  wrote:


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.



++

I'd have to hunt for where it is written down, but it can't be said
enough.  We should definitely be trying to acknowledge the
contributions of others whenever possible.  It is really the only
recognition a lot of "external" contributors get, and it is the least
we can do.  This isn't about copyright or policy or anything like
that, but just a nice thing to do, and there is no "threshold" that
external contributors need to make.

I wouldn't ascribe to malice what is probably just the result of
oversight, but it is a good reminder whatever the case may be...


+

As an old 'C' hack, 99.999% of what I've written is hardware centric and 
not publically published. A good 95% of it is covered by NDAs and
ownership/rights as transferred codes. Often I can only speak to 
potential negotiators of opportunity, in a generic way about a variety 
of codes and technologies.



Many of today's potential employers want to see the open source 
contributions of potential employees/contractors; I get that. So it is 
quintessentially important that these sorts of contributors have a list 
of easy to review works and contributions to show potential employers. 
Perhaps their own overlay where their works and contributions are 
duplicated for easy viewing by a potential employer? (I'm certainly not
a git-architect) but there is a valid need and this documentation trail 
would only serve to attract more potential to gentoo's projects.



Me, I have a lab full of home-made prototypes and who's who list of 
EE/CS developers and leaders that I can tap, if I feel the need. I can 
talk deeply about chipsets and the sorry codes developed by the OEMs 
(sorry_moto) which were directly embedded into compromise-able routers 
(like cisco) and such juicy tidbits. Or, I have deeply secretive stories 
(antidotes) of stories behind the story, than can curl the ear-hairs of 
most CIO/CT0. But for the youthful devs, it would be very cool if a 
mechanism/system was deployed at Gentoo for those aspiring devs to 
enhance their resumes, kinda like a personally attributable changelog or 
such.



Story telling comes with age and wisdom. knowing when to give the 
credit to another..



hth,
James

[gentoo-dev] Simple crude tool to bump packages ebuild-bumper.sh

[William L. Thomson Jr.]

Do you find yourself with lots of related packages with the same version to 
bump?
Do those package have a special order in which they need to be bumped?

If those sound like problems you run into, then I have a simple crude tool for 
you called ebuild-bumper.sh[1]. A simple crude bash script that using an 
external file that can bump many packages in a given order. This can save a 
good deal of time on routine version bumps across many related packages of the 
same version/slot.

This script uses external files[2] to specify the area of the tree, base name, 
and packages in order to be revision bumped. At the same time it can clean 
while it bumps, not recommended as it will break depgraph and cause it to 
fail. However once you have bumped a set of packages. You can turn around and 
re-run it to clean out older versions.

It is pretty nifty and can save time. If any bump fails, the script stops. So 
you can manually intervene. Then you can resume bumping the rest of the 
packages.

I chose bash to keep it simple, and I hate python, so not sure what other I 
might have used. I do not believe it need be complex requiring use of other 
languages but possibly. The package sort aspect for cleaning and what not 
could be improved upon and done easier by other languages. Though sort is 
pretty powerful if given proper arguments.

Anyway look it over, duplicate and make better if you like, or send me 
patches, etc. Maybe eventually this can be adopted as an official Gentoo tool 
and added to a developer toolkit. None of that matters to me really. I made it 
to save myself time and address a problem I was facing. If it others find it 
useful great :)

1. https://github.com/Obsidian-StudiosInc/ebuild-bumper
2. https://github.com/Obsidian-StudiosInc/ebuild-bumper/tree/master/bump_pkgs

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Simple crude tool to bump packages ebuild-bumper.sh

[William L. Thomson Jr.]

On Thursday, December 1, 2016 12:12:27 PM EST William L. Thomson Jr. wrote:
> Do you find yourself with lots of related packages with the same version to
> bump?
> Do those package have a special order in which they need to be bumped?
> 
> If those sound like problems you run into, then I have a simple crude tool
> for you called ebuild-bumper.sh[1]. A simple crude bash script that using
> an external file that can bump many packages in a given order. This can
> save a good deal of time on routine version bumps across many related
> packages of the same version/slot.

Further thoughts on this, if integrated with something like libraries.io or 
other that can alert to new versions. It may be possible to fully automate 
routine version bumps. Only requiring a human to bump if/when things fail.

Routine version bumps suck, seem a waste of any humans time if it can be 
automated. This tool is a step in such direction, but can be further expanded 
upon and integrated into other things for more automation :)

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[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

[Andrey Utkin]

Hi Matthew,

Please take my deepest excuses for unjustly blaming you, now I see that
my perception was plain wrong in being so blindly emotional.

On Wed, Nov 30, 2016 at 05:43:36PM -0600, Matthew Thode wrote:
> While I did see your PR and bug if I remember correctly I didn't
> actually use your commit or your ebuild to source it.  I added it based
> on the bug iirc (which is still waiting on the link it seems).

Indeed, the link to PR was never added to bugzilla ticket, which is odd
on my side. I guess I could have connectivity issues back then.

> I should
> have mentioned that bug at the very least though and/or worked with you
> on the ebuild.

> Again, sorry about not updating the bug or waiting to work with you on
> the PR.  If there's something else I can do for this let me know.

Again sorry for false accusation and not getting in touch with you
before starting public discussion.

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

[Andrey Utkin]

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?

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

[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 
> 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] [RESEND PATCH 1/1] kernel-2.eclass: Fix eapply_user as per PMS spec and execute in, src_prepare. Support older EAPIs with epatch_user.

[Mike Pagano]

On 11/30/2016 07:32 PM, Mike Pagano wrote:
> Round 3. As per mgorny's additional advice, fix eapply_user as per PMS
> spec and execute in src_prepare. Support older EAPIs with epatch_user.
> export src_prepare only for supported EAPI versions.



mgorny, thanks for the feedback. Committed with peace and love. Peace.
And. Love.

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead
E-Mail : mpag...@gentoo.org
GnuPG FP   : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137
Public Key :
http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 1/1] kernel-2.eclass: Cleanup. Remove die from global, scope per EAPI 6 rules

[Mike Pagano]

EAPI 6 prohibits dying in global scope.  Move that check to pkg_setup.

---
 eclass/kernel-2.eclass | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 547153c..91a24e9 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -544,9 +544,6 @@ elif [[ ${ETYPE} == headers ]]; then
unset KBUILD_OUTPUT

SLOT="0"
-else
-   eerror "Unknown ETYPE=\"${ETYPE}\", must be \"sources\" or \"headers\""
-   die "Unknown ETYPE=\"${ETYPE}\", must be \"sources\" or \"headers\""
 fi

 # Cross-compile support functions
@@ -1371,6 +1368,11 @@ kernel-2_pkg_setup() {
fi

ABI="${KERNEL_ABI}"
+   if [[ ${ETYPE} != sources ]] && [[ ${ETYPE} != headers ]]; then
+   eerror "Unknown ETYPE=\"${ETYPE}\", must be \"sources\" or 
\"headers\""
+   die "Unknown ETYPE=\"${ETYPE}\", must be \"sources\" or 
\"headers\""
+   fi
+
[[ ${ETYPE} == headers ]] && setup_headers
[[ ${ETYPE} == sources ]] && echo ">>> Preparing to unpack ..."
 }
-- 
2.7.3




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Simple crude tool to make massive changes ebuild-batcher.sh

[William L. Thomson Jr.]

Do you find yourself having to make a change to a lot of ebuilds?

If that is something you face or have run into, then I have a simple crude 
tool for you called ebuild-batcher.sh[1]. A simple crude bash script that 
using an external file[2] that can modify ebuilds, files, etc across the entire 
tree or list of packages.

This is a pretty simple crude tool that can save tremendous amounts of time. 
The external file specifies what ever change needs to be made. This can be 
minor 
or major, and can have lots of complex logic. This could be potentially used 
for any new EAPI, to make such changes to the tree automatically.

I might even go so far as to propose if you are suggesting something in EAPI. 
That you write a file that can modify all ebuilds. That is not practical for 
all things but might be for some things.

None the less this tool allows you to make the same change to a batch of 
ebuilds. The tool is 100% safe, as if anything fails at any time for a given 
package. It is reverted to its previous state and it moves on to the next.

I chose bash to keep it simple, and I hate python, so not sure what other I 
might have used. I do not believe it need be complex requiring use of other 
languages but possibly. 

Anyway look it over, duplicate and make better if you like, or send me 
patches, etc. Maybe eventually this can be adopted as an official Gentoo tool 
and added to a developer toolkit. None of that matters to me really. I made it 
to save myself time and address a problem I was facing. If it others find it 
useful great. :)

1. https://github.com/Obsidian-StudiosInc/ebuild-batcher
2. https://github.com/Obsidian-StudiosInc/ebuild-batcher/tree/master/scripts

--
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[Michael Palimaka]

On 01/12/16 10:27, Andrew Savchenko wrote:
> On Wed, 30 Nov 2016 17:17:16 -0500 Rich Freeman wrote:
>> On Wed, Nov 30, 2016 at 4:23 PM, Andrey Utkin  
>> wrote:
>>>
>>> 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.
>>>
>>
>> ++
>>
>> I'd have to hunt for where it is written down, but it can't be said
>> enough.  We should definitely be trying to acknowledge the
>> contributions of others whenever possible.  It is really the only
>> recognition a lot of "external" contributors get, and it is the least
>> we can do.  This isn't about copyright or policy or anything like
>> that, but just a nice thing to do, and there is no "threshold" that
>> external contributors need to make.
>>
>> I wouldn't ascribe to malice what is probably just the result of
>> oversight, but it is a good reminder whatever the case may be...
>  
> One more reason to use merge commits for pull requests: original
> author commits with proper authorship will be retained.
> 
> Yes, I know that some people are unhappy with non-linear history,
> but this is how git works, so there is nothing wrong with merge
> commits for user-contributed changes.

Git has distinct 'author' and 'committer' fields for a reason, there's
no reason to not use them. This has nothing to do with merge commits.

In fact, non-merge commits provide a much clearer picture of who did
what. Compare
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6485aff0129ae4c8df5a211af1a51d03ecb6de4
and
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a06f6c599f999a9ae9b1e7ca448712ebfb31ad5f.

The former commit was rebased and clearly shows that Andreas authored
the commit and that I pushed it. The latter was part of a merge commit,
and although it retains authorship information provides no *easy* way to
figure out who the responsible dev is.

Re: [gentoo-dev] Developer GitHub usernames

[Daniel Campbell]

On 11/30/2016 01:19 PM, Michał Górny wrote:
> On Wed, 30 Nov 2016 01:33:24 -0800
> Daniel Campbell  wrote:
> 
>> On 11/26/2016 01:08 AM, Michał Górny wrote:
>>> On Sat, 26 Nov 2016 00:03:59 -0800
>>> Daniel Campbell  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

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

[Michael Palimaka]

On 01/12/16 09:33, Sam Jorna wrote:
> On Wed, Nov 30, 2016 at 09:23:56PM +, Andrey Utkin wrote:
>> 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.
> 
> Though I wasn't involved in these commits, I have seen how easy and
> accidental it is to lose authorship information on a commit. That being
> said, finding where to draw the line on authorship can be difficult.
> 
> I'm not sure how many others are aware of this, but I'll mention it just
> in case: provided it's done before pushing commits, the commit metadata
> and message can be amended locally with
> 
>   git commit --amend --author="Joe Smith "
> 
> This will update the Author tag but leave the Committer tag untouched
> (and will allow fixing any problems with the commit message itself).
> Amending commits that are not the tip of your local clone will probably
> need an interactive rebase though (but I could be wrong about that).
> 

I've added a new section on the wiki page about this:
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Retaining_commit_author_information

Improvements welcome.

Re: [gentoo-dev] Lastrites: app-text/stardict and app-dicts/stardict*

[Andrew Savchenko]

On Mon, 28 Nov 2016 22:36:09 +0100 Pacho Ramos wrote:
> # Pacho Ramos  (27 Nov 2016)
> # All stardict stuff and dicts are completely unmaintained and orphan
> for
> # years (#471350, #533632, #568472, #600718). Removal in a month.
> app-dicts/stardict-cdict-en-zh-big5
> app-dicts/stardict-cdict-en-zh-gb
> app-dicts/stardict-cedict-zh-en-big5
> app-dicts/stardict-cedict-zh-en-gb
> app-dicts/stardict-dictd-devils
> app-dicts/stardict-freedict-eng-deu
> app-dicts/stardict-freedict-eng-fra
> app-dicts/stardict-freedict-eng-ita
> app-dicts/stardict-freedict-eng-lat
> app-dicts/stardict-freedict-eng-rus
> app-dicts/stardict-freedict-eng-spa
> app-dicts/stardict-freedict-eng-swe
> app-dicts/stardict-freedict-eng-tur
> app-dicts/stardict-freedict-tur-deu
> app-dicts/stardict-freedict-tur-eng
> app-dicts/stardict-hnd-de-vi
> app-dicts/stardict-hnd-en-vi
> app-dicts/stardict-hnd-fr-vi
> app-dicts/stardict-hnd-ru-vi
> app-dicts/stardict-hnd-vi-de
> app-dicts/stardict-hnd-vi-en
> app-dicts/stardict-hnd-vi-fr
> app-dicts/stardict-hnd-vi-vi
> app-dicts/stardict-jmdict-en-ja
> app-dicts/stardict-jmdict-ja-en
> app-dicts/stardict-langdao-en-zh-gb
> app-dicts/stardict-langdao-zh-en-gb
> app-dicts/stardict-mova-smiley
> app-dicts/stardict-oxford-en-zh-gb
> app-dicts/stardict-quick-eng-fra
> app-dicts/stardict-quick-eng-jpn
> app-dicts/stardict-quick-jpn-eng
> app-dicts/stardict-quick-ru-en
> app-dicts/stardict-xdict-en-zh-big5
> app-dicts/stardict-xdict-en-zh-gb
> app-dicts/stardict-xdict-zh-en-big5
> app-dicts/stardict-xdict-zh-en-gb
> app-text/stardict
 
I'll take care of stardict and all dictionaries except for
stardict-hnd-* family. Stardict is used by many people and works
fine except for minor issues.

I'm not sure I'll fix bug 568472, since this may require a lot of
coding and result will be non-stable in the long run: google often
changes API of their services.

As for dictionaries:
- I'm interested in dicts only from download.huzheng.org, since
other sorces are not reliable and legal status of many (most?)
dictionaries is unclear.
- Many users (including myself) install dictionaries
themselves, outside of portage control.
- Please note for the future: app-dicts/stardict-* packages can be
used not only by stardict, but by sdcv and goldendict as well, so
not be hasty to remove them :)

Best regards,
Andrew Savchenko


pgpgsHv5RSub0.pgp
Description: PGP signature