Re: [gentoo-dev] [PATCH 2/3] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs

[Nathan Zachary]

On 14/12/16 12:29, Fabian Groffen wrote:
> On 14-12-2016 13:01:16 -0500, Doug Freed wrote:
>> On Wed, Dec 14, 2016 at 12:48 PM, Nathan Zachary
>> <nathanzach...@gentoo.org> wrote:
>>> On 14/12/16 10:11, Doug Freed wrote:
>>>>> I somehow doubt that would give me the expected number only, and I lack
>>>>> a BSD install handy to test it.
>>>> $(sysctl -n hw.ncpu)
>>>>
>>> I don't know that the sysctl command works universally:
>>>
>>> # sysctl -n hw.ncpu
>>> sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory
>>>
>> It's BSD-specific (Darwin may have it too, but I'm not in OS X at the
>> moment, so I can't check), which pretty much describes this branch in
>> the codepath as well.  Linux users will have the nproc command from
>> coreutils.
> Yes, Darwin has it too, but the tool lives in /usr/sbin instead:
>
> https://gitweb.gentoo.org/repo/proj/prefix.git/tree/scripts/bootstrap-prefix.sh#n1987
>
> Fabian
>
>
Ah, yes, I missed the part about it being BSD-specific.

This one-liner certainly isn't as graceful or elegant, but it works:

# cat /proc/cpuinfo | grep 'processor' | wc -l



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 2/3] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs

[Nathan Zachary]

On 14/12/16 10:11, Doug Freed wrote:
> On Wed, Dec 14, 2016 at 11:04 AM, Michał Górny  wrote:
>> On Wed, 14 Dec 2016 15:27:25 +0300
>> Andrew Savchenko  wrote:
>>
>>> On Tue, 13 Dec 2016 10:36:15 +0100 Michał Górny wrote:
 +   nproc=$(python -c 'import multiprocessing; 
 print(multiprocessing.cpu_count());' 2>/dev/null)
>>> This is not portable. E.g. paludis users can have python-less
>>> system. Adding dev-lang/python to DEPEND will be also a bad idea,
>>> since this is quite heavy dependency.
>> You can bikeshed potential circumstances where it wouldn't work for
>> the next year. Which doesn't change that it would work quite reliably
>> for the most of Gentoo users.
>>
>>> Since on Linux boxes nproc is from coreutils, which is in @system,
>>> so looks like only *bsd setups are the problem. On FreeBSD
>> ...and all other operating systems (see: Prefix).
>>
>>>   sysctl -a | egrep -i 'hw.ncpu'
>> I somehow doubt that would give me the expected number only, and I lack
>> a BSD install handy to test it.
> $(sysctl -n hw.ncpu)
>
I don't know that the sysctl command works universally:

# sysctl -n hw.ncpu
sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Empty project: LXDE

[Nathan Zachary]

On 10/08/16 07:12, james wrote:
> On 08/10/2016 12:46 AM, Raymond Jennings wrote:
>> Hey, just a heads up as a user.  I'm currently using LXDE.
>>
>> On Sun, Aug 7, 2016 at 1:22 AM, Pacho Ramos <pa...@gentoo.org
>> <mailto:pa...@gentoo.org>> wrote:
>>
>> Now https://wiki.gentoo.org/wiki/Project:LXDE
>> <https://wiki.gentoo.org/wiki/Project:LXDE> is empty
>>
>> Feel free to join, anyway, if I don't misremember, LXDE is dead
>> for a
>> long time in favor of LXQT... in that case treecleaning the packages
>> would also be an option
>>
>> Thanks
>>
>>
>
> +1::
>
> me too. I have it on several (older) systems. Hopefully there will be
> a news item, when the time comes, with instructions on migration to
> lxqt or a listing of other light weight replacement options, with a
> wee bit of migration detail
>
>
> hth,
> James
>
I was under the impression that both LXDE and LXQT would continue
development, but that LXQT would be favoured.  Is there an official
statement that LXDE is dead?

Cheers,
Nathan Zachary





signature.asc
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[Nathan Zachary]

> GitHub Inc. is successful because they host a central location with
> "all the code on the Internet"; convenient for consumers and
> producers alike. Of course it is a fallacy, but it's convenient
> when it works.
>
> Ensure that Gentoo accomplishes the same for Gentoo.
>
> Do NOT - I repeat NOT - tie "user repos" to GitHub Inc., please do
> not even bother working on a prototype there (looking at you James),
> because if it is good enough it will stick, and as the social
> contract rightfully states, it's important to remain independent,
> so that Gentoo and Gentoo only can decide what it will offer.
>
>
> This is a wonderful idea which would benefit the community
> tremendously. I wish I had time to implement all of it immediately.
>
>
> Kind regards
>
> //Peter
>
I agree with the idea of NOT using GitHub.  Though it is a great
resource, I second the idea that Gentoo should offer the repository
space in order to stay separate.

Cheers,
Nathan Zachary



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] amd64 and x32 systemd stages should be ready

[Nathan Zachary]

On 09/05/16 19:12, M. J. Everitt wrote:
> On 10/05/16 00:08, Rich Freeman wrote:
>> On Mon, May 9, 2016 at 6:34 PM, Anthony G. Basile
>> <bas...@opensource.dyc.edu> wrote:
>>> oh okay.  sorry if i misunderstood.  nonetheless, doesn't the fedora
>>> installation cd double as a rescue cd?  i think that uses systemd.
>>>
>> It might - no idea.  I'm not sure if it is as loaded with useful
>> utilities, X11, a package manager, and so on.  Ugh - and it would use
>> rpm I guess...
>>
>>
> Did a quick google .. https://wiki.archlinux.org/index.php/Archboot ..
> looks like a potentially safer bet ?
>
+1.  Arch would probably be the best choice for a systemd-based rescue disc.

Cheers,
Nathan Zachary

Re: [gentoo-dev] glibc-2.16 moving to ~arch

[Nathan Zachary]

On Sat, 18 Aug 2012 12:00:17 -0400
Mike Frysinger vap...@gentoo.org wrote:

 *yawn* such a drama queen.
 
 i never said i am going to do this everyone else be damned.  i did
 say i will probably do this soon.  but that is why i posted to
 gentoo-dev in the first place -- to get feedback from others.
 
 gnutls breakage: not relevant.  you're causing that breakage by not
 adding a simple patch that most every other package has merged.
 conflating the issue to a major ABI bump is also irrelevant.
 
 boost breakage: if 1.50 is going to be unmasked soon, i can wait for
 that.
 
 general breakage: we can't sit around waiting for all packages to get
 fixed. if people aren't going to fix packages after being given
 notice, then they get tree cleaned.  not a big deal.
 -mike

You both (Mike and Diego) make good and valid points regarding the
unmasking of glibc-2.16 and its impact on other packages (and,
subsequently, users).  However, the personal attacks against one another
add nothing to the discussion. Resorting to ad hominem relegates the
discourse to a less-than-helpful state for everyone involved.  Please
try to focus on the points raised by other developers and users, so
that the end result is something that benefits the community and
distribution as a whole.

Cheers,
Nathan Zachary

Re: [gentoo-dev] news item: upgrading to postfix-2.9

[Nathan Zachary]

On Tue, 17 Jul 2012 14:21:07 +0300
Eray Aslan e...@gentoo.org wrote:

 On 07/17/2012 02:00 PM, Dirkjan Ochtman wrote:
  It may be a small issue, but since the potential pain is quite
  large,
 
 Yes, that's the idea.
 

Considering Postfix is an MTA that is commonly used in production
environments, it is likely better to provide users with ample warning
than to risk the application failing and troubleshooting thereafter.

Cheers,
Nathan Zachary

Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

[Nathan Zachary]

 On 24/08/10 22:21, Joshua Saddler wrote:

On Tue, 24 Aug 2010 19:18:56 +0200
Christian Faulhammerfa...@gentoo.org  wrote:


Hi,

Joshua Saddlernightmo...@gentoo.org:

The big issue with the docs is that IF OpenRC/baselayout-2 are marked
stable, it will require massive changes to hundreds of our other doc
files.

  Is there a list of the needed changes?

Read the OpenRC guide, then read all our other guides. That's the list. It will 
require a line-by-line code scan to figure all this stuff out. Creating such a 
list would probably take almost as long as actually fixing the docs.
I don't think that the documentation changes should be a determining 
factor in switching to OpenRC.  If we are going to endorse using OpenRC, 
the more relevant issues are the ones regarding its future development.  
The documentation can be updated in due time.  Of course, that's just my 
opinion.

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Nathan Zachary]

On 05/04/10 11:07, Jon Portnoy wrote:
 On Mon, Apr 05, 2010 at 08:50:49AM +0300, Eray Aslan wrote:
   
 Just replying randomly.

 On 05.04.2010 04:33, Tobias Heinlein wrote:
 
 I think this is a good starting point to get rid of the some important
 questions are too hard to answer dilemma that can be implemented
 relatively fast. On top of that I like Sebastian's idea to order the
 quizzes by difficulty -- this means just ordering by the categories I
 just mentioned would be sufficient: 1 first, then 2, then 3.
   
 I am not against this idea but frankly, I do not understand what is so
 demotivating about the ebuild quiz.  If you get demotivated because of a
 single exam, perhaps the problem is with the motivation and not with the
 exam itself.  I took the published quiz just for the fun of it and to
 see where I missed.  It is not that long.

 
 Agreed...

 I've been following this discussion with mixed feelings. When we 
 originally began using the quiz system the idea was simply to try
 to force new developers to RTFM -- and I was not such a fan of the 
 entire concept (as I recall, the quizzes were a suggestion from Daniel).

 As it turns out, the quiz system has repeatedly proven itself useful
 in another way: developers who whine/bitch/moan and are hesitant to 
 even attempt to complete the quizzes often turn out to be bitchy,
 unmotivated, or unpleasant developers. I don't want to name any names,
 but I've seen this often.

 IMO, those boring too much like high school quizzes serve one
 extremely valuable function: finding out up front who's a team player
 (or at least willing to do something mildly unpleasant for the
 Greater Good)

 If that's causing potential devs to drop out... perhaps the system is 
 working as it should? :)

   
My problem with the quizzes is not that they have to be done, but rather
the way they are structured.  I have read through the dev manual (which
is excellent in explaining some things, and a little rough in others),
but it would be much more enlightening to me to work on creating ebuilds
while working one-on-one with a mentor.  For instance, in a recent
ebuild I wrote, the application installed successfully but yielded
sandbox errors.  By jumping on IRC and chatting with a few people, I
readily found a solution to that problem.  Later, it was brought to my
attention that there were other problems with the ebuild.  I would have
never known about these issues solely from the information presented in
the devmanual.  Therefore, I think the most valuable aspect of the
recruitment process is hands-on time with ebuilds, commits, et cetera
WHILE working with a mentor.

--Zach

Re: [gentoo-dev] [RFC] Gentoo Wiki Project

[Nathan Zachary]

On 05/04/10 13:12, Ben de Groot wrote:
 After the mostly positive feedback on the recent wiki discussion, we
 have now gone ahead, formed a preliminary team consisting of both
 users and developers, and put up a project page [1]. All constructive
 feedback on this new project is welcome.

 We'd also like to invite any users and developers, who are willing to
 help to make this a success, to join us. At this point we are
 especially looking for people who can help with:
 - the initial setup and configuration of a MediaWiki instance
 - the design of a custom Gentoo theme for MediaWiki (including graphics and 
 CSS)
 - the internal organization of the wiki
 - moderation

 1: http://www.gentoo.org/proj/en/wiki/

 Cheers,
   
As I posted on the fora, I would be willing to work on the initial
installation of MediaWiki, organisation, and moderation.  Let me know
what needs to be done and I will start.

Thanks Ben.
--Zach

Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

[Nathan Zachary]

On 03/04/10 08:40, Dror Levin wrote:
 On Sat, Apr 3, 2010 at 16:19, Ben de Groot yng...@gentoo.org wrote:
   
 1 - requirements
 

 In order to choose the best possible wiki implementation, we need to
 know our requirements. So what features do you think are essential or
 good to have? What syntax would we prefer to use?

 I myself am a big fan of reStructuredText, which is quite simple,
 easy to pick up, highly readable, and has a good featureset. Plus, it
 is also reusable in other contexts (it is for example widely used in
 documentation of Python libraries). MediaWiki, MoinMoin and Trac have
 support for rst.

 Some others:

 - active upstream (bug fixes, security updates)
 - free open source software
 - ACLs
 - spam prevention measures
 - attachments (to upload screenshots for example)
 - feeds
 
 There is currently a wiki for gentoo at gentoo-wiki.com, which is
 running MediaWiki, so it would be easiest to transfer the content if
 we were to run the same software. Now, this doesn't mean we should be
 limited by their actions, but it seems to me like the best choice for
 other reasons as well. Its syntax is probably the most well known,
 thanks to Wikipedia. Its upstream is active, it apparently scales and
 performs pretty well, it's GPL, supports translations/localization,
 feeds, attachments, etc.
 I'm sure many other alternatives are as qualified, so this is most
 likely a personal preference issue. As such, lets just agree on
 something that works and is widespread and go with that and avoid all
 the bikeshedding.

   
 2 - maintainers
 ===

 Who is volunteering for maintaining the wiki? We need editors and
 moderators, people who look out for quality control and take care of
 spam removal. So let's get together a team. I'm sure if we ask on the
 forums we'll get some users interested as well.
 
 I volunteer. Spam shouldn't be that much of an issue if editing is
 restricted to registered users, but it is a good idea to have a team
 of moderators similar to the one that exists for the forums (of course
 users can take part of it as well as developers).

   
 3 - edit access
 ===

 Do we keep to the original free for all model, with all the spam
 that includes, or do we go with registered users only? I think the
 latter is the smarter option. I also think we will want to mark
 certain pages official and lock down editing rights.
 
 IMO it's best if only registered users can edit (but registering
 should be easy, no bugs to file or anything, just sign up and use
 immediately). This will probably prevent most kinds of spam and allow
 for much better tracking of editing and history, allow for banning,
 etc. without closing the wiki up too much.
 Also, from what I could tell, this is how others are managing their
 wiki as well (Arch and Amarok, for example).

 Dror Levin

   
I would enjoy working on a wiki as well as the fora, so I'm volunteering
as well.

--Nathan Zachary

Re: [gentoo-dev] How about a monthly bumpday?

[Nathan Zachary]

On 09/03/10 22:08, Sebastian Pipping wrote:
 Hello!


 We have about 500 bump request open at the moment:
 https://bugs.gentoo.org/buglist.cgi?quicksearch=bump

 I assume that quite a few of them would be no big deal to their
 maintainers in Gentoo.


 Bugday is occupying the first Saturday of the month: how about bumpday
 on the third Saturday of the month?  First bumpday could be March 20th,
 10 days from now.

 What do you think?



 Sebastian

   
Not sure that my opinion matters all that much as I'm not currently
doing ebuild work, but I think this idea could really help out the
status of the tree.  Attached to it could be a stabilisation day as well.

--Nathan Zachary

Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

[Nathan Zachary]

On 03/03/10 15:51, Ben de Groot wrote:
 On 3 March 2010 19:45, Mart Raudsepp l...@gentoo.org wrote:
   
 I don't believe we should selectively cripple one GUI toolkit with not
 having proper printing support out of the box on a desktop profile,
 while others do, just because maintainers are lazy.
 
 I'm not talking about selectively disabling cups. My proposal is
 to no longer enable the cups useflag in the base profile. I don't
 think cups should be part of the base profile, and as a result
 cascading to the desktop profile. And a lot of people seem to
 agree. Users can always enable that functionality when they
 need it. It is not something that is necessary for running a
 desktop system.

 Cheers,
   
I agree that CUPS is not really necessary in the desktop profile, and
especially in the base profile.  Many systems run desktop environments
without needing printing support.  As we advance further toward a
paperless computing experience, the need for printing support becomes
even less.  And, as it is incredibly simple to add print capabilities by
placing the cups USE flag in /etc/make.conf, that choice should be left
to the user.

Regards,
Nathan Zachary

Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

[Nathan Zachary]

I'm not talking about selectively disabling cups. My proposal is
 to no longer enable the cups useflag in the base profile. I don't
 think cups should be part of the base profile, and as a result
 cascading to the desktop profile. And a lot of people seem to
 agree. Users can always enable that functionality when they
 need it. It is not something that is necessary for running a
 desktop system.

 Cheers,

 I agree that CUPS is not really necessary in the desktop profile, and
 especially in the base profile.  Many systems run desktop
 environments without needing printing support.  As we advance further
 toward a paperless computing experience, the need for printing
 support becomes even less.  And, as it is incredibly simple to add
 print capabilities by placing the cups USE flag in /etc/make.conf,
 that choice should be left to the user.

 Regards,
 Nathan Zachary

 One could argue the opposite as well.  Adding -cups to make.conf is
 just as easy.

 I'm one of those lowly users.

 Dale

 :-)  :-)

I think that the point is that it is better to have it disabled by
default so that new users do not run into these circular dependencies
upon their first installation.  They can then add cups to their
make.conf and emerge -avuDN world to get full printing support. 

Just as a sidebar, there is not a lowly user.  Your input is greatly
important in all matters regarding Gentoo as you are a member of the
userbase.  It's your operating system too! :)

Regards,
Nathan Zachary

Re: [gentoo-dev] Re: Marking bugs for bugday?

[Nathan Zachary]

On 02/03/10 13:17, Ulrich Mueller wrote:
 On Tue, 02 Mar 2010, Sebastian Pipping wrote:
 
   
 To make naming a bit more consistent, how about:
 - BUGDAY-CANDIDATE
 - BUGDAY-ACCEPTED
 - BUGDAY-REFUSED
 
   
 They're a bit long but I think it's worth to not have them crippled
 down to stuff like BDYES, BDNO and BDMAYBE.
 
 This looks like overkill to me. One keyword should be enough, and for
 supplementary information Status Whiteboard could be used.

 Ulrich

   
I agree.  Simply having the BUGDAY keyword should be sufficient, and
more information can be provided elsewhere in the report.

--Zach

Re: [gentoo-dev] Re: Marking bugs for bugday?

[Nathan Zachary]

On 02/03/10 13:39, Sebastian Pipping wrote:
 On 03/02/10 20:28, Nathan Zachary wrote:
   
 This looks like overkill to me. One keyword should be enough, and for
 supplementary information Status Whiteboard could be used.
   
   
 I agree.  Simply having the BUGDAY keyword should be sufficient, and
 more information can be provided elsewhere in the report.
 
 If more than one keyword is commonly considered overkill I would at
 least request the whiteboard for it: somewhere in the report involves
 more than zero searching for it.



 Sebastian

   
Point taken, and I agree.

--Zach

Re: [gentoo-dev] about a new app

[Nathan Zachary]

hiperon wrote:
 Hi you all,

 I am sorry for posting this question but I saw no other way (got
 really confused).  I am developping an application (a text editor) and
 I would like to see it into Gentoo distro, but I can't really
 understand the way that thing goes. I read the documentation about how
 to make an ebuild file, but could not figured out how to submit it.
 Could you point me some directions, please, even if it is another
 maillist.

 sorry for the inconvenience.

 for whom might be interested:
 http://cafe.sourceforge.net

 -- 
   //  // o  ___   ___
  //=// // //_ / //_  //_ / //  // //\  /
 //  // // // //_  //  \  //_// //  \/
Hi there,

The best thing to do is to file a bug at http://bugs.gentoo.org
requesting that the application be added to the Portage tree.  A Gentoo
developer can then make the ebuild file for you.  If I get a little time
today to look at the source, I might be able to throw one together.  The
best thing for you to do now though is to file the bug.

Hope that helps,
Nathan Zachary

Re: [gentoo-dev] PR Project Activity Issues

[Nathan Zachary]

Man Shankar wrote:
 On 23:51 Mon 26 Jan , Alec Warner wrote:
  [snipped] 
  
   
 A long time ago I suggested some sort of pr-onduty role where
 basically for a set period you are the prime pr contact and if someone
 has news it is your job to review and post it or reject it.  This was
 never implemented; but may be a good idea if we are limited by commit
 access.  One of the main problems with posting to an alias is that you
 can always not reply and it will become someone else's problem(TM)
 until no one replies and the message is ignored.
 
 +1
 Recently, i had started a thread here on -dev regarding the newsletter.
 I was asked to post to gmn-feedback. Sorry, haven't heard from them as
 yet. I wonder a pr-onduty may have worked!

   
 I for one almost never read pr@ because it is mostly spam and it is
 difficult to locate useful requests from crap.  It may be useful to
 tag important items with NEWS ITEM or UPDATE or something.

 If GuideXML makes it hard to post we can perhaps develop a technical 
 solution.

 If there is not enough content I'm sure we can brainstorm ideas on
 what we could do (index2 covers this area pretty well IMHO).
 

 I doubt lack of content to be the real issue. As the OP mentions, if such a
 problem exists why not ask for help from the community in a more direct way.
 Maybe, something like the monthly reminders we get for the council-meeting.
 To back up the fact that lack of content should be a non-issue is the
 following excerpt from the thread i mentioned:

 Nathan Zachary ka...@gentoo.org wrote:
 I would be happy to help out with the newsletter, especially 
 with the one article.

 So, see, people are willing to help with the content. Their prowess needs
 to be utilized and channeled, i guess.
   
 But mostly I want to address concrete problems.

 -Alec

 

   
The more I look at the discussion lists, the less I want to contribute.
I understand that correcting someone for posting to the wrong list is
expected, but the way that it is done is equally as important. For
instance, saying Firstly, it's wonderful that you'd like to help with
project X. You might get a better response if you offer a submission to
such and such list instead. is radically more beneficial than Wrong
list; check the website before cluttering the discussion lists.

I joined the forum staff because I had not witnessed that type of
superiority there. Rather, I had seen a willingness for users and
developers to help each other out with questions, comments, or concerns.
I'm hoping that this trend doesn't continue.

Regarding the original topic, I think a reminder on the forum and on the
mailing lists would be great for the newsletter. At my place of
employment, there is an email sent out to everyone saying something
along the lines of don't forget to submit your ideas for the January
newsletter, and so on. If such a reminder is sent out a few days
beforehand, there might be a better response to submission requests.

--Zach

Re: [gentoo-dev] Proposal: disable python and perl USE flags in profile

[Nathan Zachary]

If one has built a system with the default python and perl USE flags,
what steps would be necessary to remove all packages and dependencies
after removing them from the USE declarations?

Jorge Manuel B. S. Vicetto wrote:
 Dawid WgliDski wrote:
  On Monday 08 of December 2008 11:34:21 Maciej Mrozowski wrote:
  Following advise from
 https://bugs.gentoo.org/show_bug.cgi?id=250179, I'm
  bringing it here.
  Hm, i totally don't agree with the original comment from the bug.
 Many people
  get use of those two flags without even noticing it. There is bunch
 of good
  soft, that take advantages of perl modules or python
 bindings/wrappers. For
  servers it may be nagios-plugins with bunch of perl scripts for hosts
  monitoring or at least nice DBD::mysql.

  So, maybe it's better to disable such flags on your system if you
 don't like
  them - that's why you are using Gentoo, aren't you?

 David,

 in the cases you mention, there's also the option to enable those use
 flags through IUSE defaults or if we're talking exclusively about server
 packages, thorough the server profiles.
 As explained in the bug, at least the python use flag means very heavy
 and *problematic* deps for KDE. As the current USE_ORDER prevents -use
 flags from working on ebuilds, any flag set by the profile requires
 users to manually disable it in /etc/portage/package.use[/*].

Re: [gentoo-dev] Proposal: disable python and perl USE flags in profile

[Nathan Zachary]

H, that's what I assumed, but I run into problems with the depclean:

Dependencies could not be completely resolved due to
the following required packages not being installed:

=virtual/perl-Compress-Zlib-1.14 required by dev-perl/Archive-Zip-1.23
=virtual/perl-ExtUtils-ParseXS-1.02 required by
perl-core/Module-Build-0.28.08
=virtual/perl-ExtUtils-CBuilder-0.15 required by
perl-core/Module-Build-0.28.08
=virtual/perl-Archive-Tar-1.09 required by perl-core/Module-Build-0.28.08

Have you forgotten to run `emerge --update --newuse --deep world` prior to
depclean?  It may be necessary to manually uninstall packages that no longer
exist in the portage tree since it may not be possible to satisfy their
dependencies.  Also, be aware of the --with-bdeps option that is documented
in `man emerge`.

Thanks for the information Josh.

Josh Saddler wrote:
 Nathan Zachary wrote:
   
 If one has built a system with the default python and perl USE flags,
 what steps would be necessary to remove all packages and dependencies
 after removing them from the USE declarations?
 

 After kicking 'em out of make.conf, run emerge -pvtuDN world (the N is
 important; it tells emerge to look for USE flag changes). Once you've
 rebuilt your packages, then you can run emerge -p --depclean.