Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

2014-02-20 Thread Donnie Berkholz
On 00:13 Wed 12 Feb , Gilles Dartiguelongue wrote:
 Right now, I don't really get the point of this discussion given all the
 precedent threads about this, be it 2 years ago and 8-10 years ago.

I spent a while tonight digging up this post from 2005, which nicely 
describes where we were with gtk1 vs gtk2 back then.

http://marc.info/?l=gentoo-devm=111212920310822w=2

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpiDAYuRO_lp.pgp
Description: PGP signature


Re: [gentoo-dev] Add support for rsync patches

2014-02-04 Thread Donnie Berkholz
On 12:48 Tue 28 Jan , Michał Górny wrote:
 Dnia 2014-01-28, o godz. 11:59:33
 Jauhien Piatlicki jpiatli...@gmail.com napisał(a):
 
  net-misc/rsync upstream provides a tarball with additional patches that
  can be useful for some users. I think it would be nice to have them
  handled automatically by portage using e.g. USE_EXPAND.
  
  Of course these patches can be just picked by user an applied using
  epatch_user, but I think it would be much easier and convenient to do
  this with just setting a use flag.
 
 ...and what do you want from gentoo-dev@? You need someone to file
 the bug for ya?

This is not the level of friendliness that is going to welcome potential 
new contributors into our community.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgp1ny54yNMQ0.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [OT] pkgcore bikeshed

2014-01-13 Thread Donnie Berkholz
On 11:02 Mon 13 Jan , Steven J. Long wrote:
 On Mon, Jan 13, 2014 at 04:15:37PM +0700, C. Bergström wrote:
   Realistically, we have to keep updating them both in parallel. 
   pkgcore needs to be brought up to portage-level functionality,
 
 Yeah but it already outshines under the hood: all you're talking about 
 is EAPI and radhermit is working on it; I'm sure he and dol-sen would 
 be happy for more help as well, so long as it's supportive. ISTR 
 TomWij is involved too.

Working on the UX of the emerge frontend is also of extreme importance 
if you want people actually using it. Speed is absolutely a usability 
feature but it's not the only one that matters. Maintaining EAPI parity 
is table stakes.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpQJ5K5w1XJT.pgp
Description: PGP signature


Re: [gentoo-dev] Default USE changes for fortran and mudflap?

2014-01-13 Thread Donnie Berkholz
On 01:53 Sun 12 Jan , Ryan Hill wrote:
 fortran:
 Do we want to keep enabling fortran by default?  The majority of users 
 will never get the urge to install a fortran package, and the fortran 
 eclass handles those that do.  I think it should be treated as all the 
 other optional languages and disabled by default, but I'd like to know 
 if there are other opinions.

It's essentially only used by the small minority of people installing 
sci-* packages so I'd be fine with that. Reasonable defaults FTW.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpKSLofMizut.pgp
Description: PGP signature


Re: [gentoo-dev] Re: RFC: storing predefined INSTALL_MASK directory lists in repos

2014-01-13 Thread Donnie Berkholz
On 19:59 Sat 11 Jan , Peter Stuge wrote:
 Duncan wrote:
   Michał Górny wrote:
 INSTALL_MASK=systemd bash-completion
   
   What are your thoughts?
   
   It seems like this will generally duplicate all -USE flags.
   
   Would it make sense to instead have a single setting which changes 
   the meaning of USE to be that everything not USEd is 
   install-masked?
  
  No, this would not be a duplicate.
 
 I did generalize, but think more about this - certainly for both 
 Michał's examples I have already either set or unset systemd and 
 bash-completion in USE.

It would largely be a duplicate, since we've already made a decision 
about whether the ability to build without a feature is important enough 
to merit a USE flag. This is essentially rethinking the same decision 
and adding complexity to it. I think having this as an additional 
feature in the core PM would be confusing to users.

It would probably be a better fit in gentoolkit or a similar tool.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpcJ3C4i8c3x.pgp
Description: PGP signature


Re: [gentoo-dev] Doing and then undoing slotmoves

2013-12-25 Thread Donnie Berkholz
On 12:31 Mon 23 Dec , Jeroen Roovers wrote:
 On Sun, 22 Dec 2013 20:07:21 -0600
 Donnie Berkholz dberkh...@gentoo.org wrote:
 
  Seems we should add repoman support to check profiles/. Spec mandates 
  that are not implemented in any tool are unlikely to be adhered to.
 
 repoman does not work in profiles, to my knowledge. It expects ebuild
 in package directories in categorie directories.

I'm confused. Isn't that exactly what I just said? add repoman support

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpK6B9Oku7YA.pgp
Description: PGP signature


Re: [gentoo-dev] Doing and then undoing slotmoves

2013-12-22 Thread Donnie Berkholz
On 10:19 Wed 18 Dec , Ulrich Mueller wrote:
  On Wed, 18 Dec 2013, Fabio Erculiani wrote:
 
  I have never seen something like that and this generated an
  interesting bug in entropy (well, I fixed it...). What I am asking
  is quite simple though. Is this allowed?
 
 The PMS does not allow it:
 http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-390004.4.4

Seems we should add repoman support to check profiles/. Spec mandates 
that are not implemented in any tool are unlikely to be adhered to.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpl051gaF9bu.pgp
Description: PGP signature


Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr

2013-09-26 Thread Donnie Berkholz
On 11:03 Thu 26 Sep , JD Horelick wrote:
 My only issue here is that I feel like we should give users a bit longer
 than one month (34 days, close enough) to make this change. In some cases,
 it may require a large, architectural change which may take a while to be
 engineered and organized. I'd suggest making the cutoff for this January 1,
 2014. I know that impedes our progress, but I feel it provides significant
 benefit to our users who may use seperate /usr.

In reality it should be more like 60 days before any of those users are 
affected. We stop support in 30 days (which can't be done directly in 
stable), then we test that in ~arch for the usual 30 days before 
stabilizing.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgp_W_sG3SI4M.pgp
Description: PGP signature


Re: [gentoo-dev] Changes in libreoffice ebuild

2013-08-13 Thread Donnie Berkholz
On 14:37 Tue 13 Aug , Rich Freeman wrote:
 If a maintainer is holding something up for months by all means
 escalate it if you think it is justified, but if a maintainer just
 wants a few days to look into things, that isn't asking too much.  If
 this were a security patch I might feel differently, or a stable
 regression (though as has been pointed out that shouldn't happen with
 reverse dep testing).

Turns out we already wrote this down. See Touching other developers 
ebuilds: 
http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html

Otherwise a soft limit of 2 to 4 weeks depending on the severity of the 
bug is an acceptable time frame before you go ahead and fix it 
yourself.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpFgfbAJDv3x.pgp
Description: PGP signature


Re: [gentoo-dev] status of security improvments (GLEPs 57-61)

2013-08-12 Thread Donnie Berkholz
On 08:00 Thu 08 Aug , Patrick Lauer wrote:
 On 08/08/2013 04:47 AM, hasufell wrote:
  I'd say let's push for it. I am willing to do a lot of testing.
  
 Good plan. I hope I find some time to figure out a roadmap so we have 
 an idea what needs to be done - or someone else might just want to 
 read through some old threads and do the same.

There's https://bugs.gentoo.org/show_bug.cgi?id=333531

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpL7_AlSQmu9.pgp
Description: PGP signature


[gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon

2013-08-03 Thread Donnie Berkholz
On 15:36 Fri 02 Aug , William Hubbs wrote:
 All,
 
 This message is an announcement and a reminder.
 
 OpenRc-0.12 will be introduced to the portage tree in the next few days.
 
 If you are using ~arch OpenRc, the standard disclaimer applies: remember
 that you might be subject to breakage.
 
 I do not know of any breakage personally. It does work on my system, and
 I know of others who are using OpenRc from git successfully. Some are
 OpenRc team members, and at least one is a Gentoo user.
 
 If you are not comfortable with the possibility of breakage, I recommend
 that you make sure you do not upgrade right away.
 
 If, on the other hand, you are comfortable with that possibility and you
 are willing to help us test and get rid of bugs before we go stable,
 feel free to run ~arch.
 
 In other words, this is the standard Gentoo disclaimer, so consider
 yourself warned.

Man, in terms of how to phrase things, this is way wrong.

If you're comfortable with your stuff breaking really? No. If you want 
to help improve Gentoo.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpR7xYCntyTZ.pgp
Description: PGP signature


Re: [gentoo-dev] Re: RFC: toolchain-r1.eclass

2013-08-01 Thread Donnie Berkholz
On 22:30 Thu 25 Jul , Ryan Hill wrote:
 I don't think we will be moving to 5 very soon.  I have nothing 
 against it but Mike might be a harder sell.  I want USE deps so I'm 
 going to do 2 at least, then get the prefix guys on board for 3.

The council deprecated 1/2 in April so I'd avoid those.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpk8YyXSSTTY.pgp
Description: PGP signature


Re: [gentoo-dev] Re: RFC: fortran-2.eclass - Support for bin package system without compiler

2013-07-18 Thread Donnie Berkholz
On 10:44 Thu 18 Jul , Justin wrote:
 +fortran-2_pkg_setup() {
 + case ${EAPI:-0} in
 + 0|1|2|3)
 + eqawarn Support for EAPI  4 will be removed from the
 + eqawarn fortran-2.eclass in near future.
 + eqawarn Please migrate your package to a higher EAPI
 + eqawarn or file a bug at https://bugs.gentoo.org;
 + _fortran-2_pkg_setup ;;

It's more useful if you provide a date here (30+ days from the commit) 
after which things are no longer guaranteed to work, versus near 
future.

I didn't catch it in your original email — have you run a scan to see 
how many ebuilds are affected?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgp6OhBSU0BAC.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Hangouts

2013-07-17 Thread Donnie Berkholz
On 18:52 Mon 08 Jul , Pavlos Ratis wrote:
 As far as I can see, opinions about VCs are 50-50. However, I don't
 see any disadvantages adding video hangouts to the project. VCs _are
 not_ mandatory and doesn't replace any of our current communication
 methods. You are not forced to participate. It's all about choice. If
 there are no objections and if the PR team gives an ack. I'd like to
 add video hangouts under the PR project (I'll create a simple faq page
 in wiki about VCs).

Go ahead. Experiments are always welcome.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpSNOnrgt6NR.pgp
Description: PGP signature


Re: [gentoo-dev] Proper distribution integration of kernel *-sources, patches and configuration.

2013-07-17 Thread Donnie Berkholz
On 20:19 Thu 04 Jul , Mike Pagano wrote:
 I have 'relaxed' a tad about what I think should be in g-s, but maybe it has 
 gone a bit farther than I wanted it too.
 
 I would like to see a -experimental use flag and base,extras,geek 
 (whatever) 
 so that g-s goes back to what it's original goal was with nothing 
 non-upstream 
 unless the user does a configuration change themselves.
 
 This will actually help us solve both issues.
 
 1) it will allow us to pull g-s back to it's original goal as  a minimal 
 kernel sources with upstream only patches.

Original? Not true. gentoo-sources has, for ages, carried feature 
patches that were considered useful to Gentoo as a whole or to releng in 
particular.

It's carried whole filesystems like XFS, it's carried EVMS, it's carried 
pretty much the whole ck- patchset (Con Kolivas), grsec, FreeS/WAN and 
OpenS/WAN, the bootsplash stuff, etc.

 2) we can carry some patches from upstreams trees that possibly aren't yet in 
 -next, or not yet accepted to mainline but do provide some benefit to a 
 smaller 
 group of our users. (Thinking about our thinkpad patches)

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpGcbFM00xhl.pgp
Description: PGP signature


Re: [gentoo-dev] new category: games-adventure/

2013-07-15 Thread Donnie Berkholz
On 17:26 Sun 14 Jul , Diego Elio Pettenò wrote:
 I would object... 10 games are wa too few for a new category and 
 especially pkg moves..

I wrote a script years ago to make recommendations for this. I just 
updated it to do things a little smarter. It bases its suggestions on 
percentiles of existing category sizes.

http://dev.gentoo.org/~dberkholz/scripts/category-size

$ category-size

Statistics for /usr/portage:
Median packages per category = 51
Suggested category size (25%–75%): 18 to 91
Split categories with more than 91 packages, and do not create categories with 
fewer than 18 packages.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpOocMKQ8ulN.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Gentoo Hangouts

2013-07-02 Thread Donnie Berkholz
On 09:21 Mon 24 Jun , Mike Pagano wrote:
 Sometimes it helps to realize that the people on the other end of the
 wire are just that: people.
 
 I've seen behaviors change among team members for the better.

^^ This.

Seeing people as close to in person as we can get without a conference 
really does help to improve the quality of our interactions. It's a lot 
harder to be a jerk when you can picture the person you're writing to as 
a living, breathing person.

Given recent, and more distant, actions by some of our community with 
DevRel consequences, it should be clear that treating our fellow 
developers decently is a problem. And seriously, hopping on a video chat 
once or twice a year should be doable for most of us.

I don't necessarily care a lot about the PR value of any replays, I see 
it as much more important to strengthening Gentoo than to do outreach. 

That said, I've gotten over 10,000 views of an intro talk on Gentoo 
that's posted on YouTube despite its pretty bad audio quality, and 
nearly 2,000 views of a Gentoo talk targeted at developers, so there's 
clearly people looking for this stuff.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgphu4DSZRfgK.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean

2013-04-09 Thread Donnie Berkholz
On 23:41 Sat 06 Apr , Michał Górny wrote:
 Optionally, after the last paragraph you can add a few lines with tags
 in form of 'Tag: value'. AFAICS git itself uses only
 'Signed-off-by' but you can find more tags in various 'submitting
 patches' docs.
 
 'Signed-off-by' lists the one responsible for the patch. Some upstreams
 require that line, some take over authorship of patches if you don't
 add it (like X.org), some just hate it :).
 
 The X.org wiki lists also 'Fixes' for bugtracker URL [2] and a few tags
 for reviewing patches [3] (those are probably not useful for us).

This is the part that would be most useful to document more. Suggesting 
which tags would be valuable to include. Fixes, Reviewed-by, 
Signed-off-by, etc.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpMghgyMMro7.pgp
Description: PGP signature


Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

2013-01-05 Thread Donnie Berkholz
On 18:03 Sat 05 Jan , Andreas K. Huettel wrote:
 Am Samstag, 5. Januar 2013, 16:46:07 schrieb Roy Bamford:
  I agree its not 'core business' but Gentoo isn't a business.
 
 Even if you're not a business you should care about maintainable solutions.

More importantly, even if you aren't a business (although we are, 
technically, albeit a not-for-profit one), you should still have a 
mission that you're focused on accomplishing. Otherwise you can justify 
anything in the context of Gentoo, when in reality we need to limit our 
scope to increase our impact.

I actually suspect this is a byproduct of Gentoo being many 
contributors' first OSS development experiences. They're nervous to 
branch out on their own w/ e.g. a GitHub repo so they initiate 
*everything* under the Gentoo umbrella.

I would argue that defining a clear vision and audience for Gentoo would 
significantly increase our ability to get useful things done.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpzBhWAtbiqb.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Wordiness

2013-01-04 Thread Donnie Berkholz
On 05:31 Fri 21 Dec , Matt Turner wrote:
 My point is that you consistently write long essays that I, and 
 apparently most others, don't bother to read. I'm not sure if you're 
 aware of this.
 
 Someone said on IRC this morning in response to this thread
 
  the tragic thing is that guy would be able to make valuable 
  contributions if it weren't for the excessive length of his mails
 
 So, your emails are way too long. A huge percentage of recipients 
 don't bother to read them. I don't know whether you just enjoy writing 
 (you must!) or if you hope to actually be heard, but as it stands now 
 you're not being heard by most.

Just coming back from Christmas vacation, but ...

Yeah.

Duncan, you need to learn how to be pithy. Invest the effort to cut your 
writing down to its essence; consider the time of the 100s/1000s who 
read it. Your value and impact will increase exponentially.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpR4IRW1xeQ_.pgp
Description: PGP signature


Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

2013-01-04 Thread Donnie Berkholz
On 10:26 Sat 22 Dec , Pacho Ramos wrote:
 Hello
 
 After seeing:
 https://bugs.gentoo.org/show_bug.cgi?id=440214
 
 Looking to a lot of its blockers shows that we are using elog messages
 for informing people about configuration (like pointing people to
 external links to get proper way of configuring things, tell them to add
 to some system groups...). I thought that maybe this kind of information
 could be simply included in a canonical file under /usr/share/doc/
 package dir called, for example, CONFIGURATION or SETUP. We would them
 point people (now with a news item, for the long term provably a note to
 handbook to newcomers would be nice) to that file to configure their
 setups. The main advantages I see:
 - We will flood less summary.log ;)
 - The information to configure the package is always present while
 package is installed, now, if we remove merge produced logs, people will
 need to reemerge the package or read directly the ebuild
 
 What do you think?

Bikeshedding ... would go with README.gentoo, because people are already 
used to looking for README files. Every time we can eliminate 
Gentoo-specific weirdness, we should.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgp3sbsAFBIVY.pgp
Description: PGP signature


Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

2013-01-04 Thread Donnie Berkholz
On 10:43 Mon 17 Dec , Markos Chandras wrote:
 On 16 December 2012 18:53, Andreas K. Huettel dilfri...@gentoo.org wrote:
  How to do this, however, and what software to target should probably 
  be decided by people who know more than me... and in the end it all 
  boils down to who has the time and motivation.
 
 Outsource it to someone who has the knowledge and interest in doing 
 this. The foundation has the funds to support it, and none of us 
 actually have the time to invest in a complete webpage redesign.

I did much of the design work nearly 2 years ago:

http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_black.png
http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_install.png
http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_handbook.png
http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_handbook2.png

Some early work on it using Bootstrap:

http://a3li.li/~alex/g.o/

That said, why the hell are we wasting time implementing our own website 
backend when we should be using a CMS? We're here to make a distro, not 
a website framework. No reason we should care, day to day, about 
anything but frontend theming and content.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpSKkhPZZeQ4.pgp
Description: PGP signature


Re: [gentoo-dev] Reminder: open season on robbat2's packages

2012-11-26 Thread Donnie Berkholz
On 04:22 Fri 23 Nov , Robin H. Johnson wrote:
 On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz wrote:
  On 11:11 Sun 18 Nov , Robin H. Johnson wrote:
   Here's a list of every package where I'm a maintainer and there is no
   herd listed (but their might be other maintainers):
 I didn't say I was dropping any of the packages, merely making an
 explicit list of packages I maintain, that other developers are welcome
 to touch - if they want to take them over explicitly, that would be
 great too.

Gah, my bad, trying to run through email too fast.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpZBv5vUx4gN.pgp
Description: PGP signature


Re: [gentoo-dev] Ohloh Organizations - Gentoo Linux

2012-11-22 Thread Donnie Berkholz
On 10:24 Fri 16 Nov , Dirkjan Ochtman wrote:
 On Thu, Nov 15, 2012 at 8:42 PM, Justin j...@gentoo.org wrote:
  does anybody like to setup an Organization[1] profile @ ohloh for Gentoo?
 
 I've shot them a message, let's see what happens.

Lemme know if you need any help pushing this through, I know the guy 
running it pretty well.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpeD65iNmfgq.pgp
Description: PGP signature


Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

2012-11-22 Thread Donnie Berkholz
On 23:57 Sat 17 Nov , Greg KH wrote:
 On Sat, Nov 17, 2012 at 11:02:19PM -0800, Alec Warner wrote:
  I'm unsure on what grounds you disapprove. People start (and abandon)
  projects often in Gentoo. Suddenly you dislike one such project and
  object to this practice? Certainly if we had to get some sort of
  Foundation consensus (for anything) nothing would happen. We can't
  even get more than 40% of foundation members to vote.
 
 I object if this is seen as a Gentoo blessed fork of a community
 project that is worked on by all other major Linux distros.  That is the
 type of decision that can be made by the Gentoo Council, which is fine,
 but it sure would be nice if it were publicly stated, instead of having
 to see it on the Gentoo github site instead.
 
 And if that is the decision of the council, I would expect the ability
 to have some type of discussion about it, wouldn't you?

Sorry to follow up late but I feel like the critical point never made it 
clearly into this discussion.

The key misunderstanding here seems to be that initiation of a Gentoo 
project means that the council explicitly supports it, because in most 
distributions there is no choice available to end users at this level of 
detail.

Instead, in Gentoo, the council-level decision typically happens when 
the *default* changes. Non-default or non-mandatory things are handled 
in a nearly anarchic, ad hoc manner, where anyone can do pretty much 
whatever they want as an official Gentoo project.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpFP4Q0Esq9W.pgp
Description: PGP signature


Re: [gentoo-dev] Reminder: open season on robbat2's packages

2012-11-22 Thread Donnie Berkholz
On 11:11 Sun 18 Nov , Robin H. Johnson wrote:
 Here's a list of every package where I'm a maintainer and there is no
 herd listed (but their might be other maintainers):
 dev-util/wiggle
 dev-vcs/cvs2svn

Suppose I could take these.

 dev-vcs/git

I'm hoping somebody is taking this?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgplPH1rn4ntA.pgp
Description: PGP signature


Re: [gentoo-dev] Adding PYTHON_TARGETS=python2_7 to base profile

2012-05-21 Thread Donnie Berkholz
On 16:27 Sun 13 May , Mike Gilbert wrote:
 To make ebuilds utilizing python-distutils-ng.eclass usable

I didn't read any farther because I couldn't stop laughing. What will 
the next version of this eclass be called, -ng-ng? -really-ng? =)

--
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpIBXHy7OxqK.pgp
Description: PGP signature


Re: [gentoo-dev] Keeping older versions around

2012-01-29 Thread Donnie Berkholz
On 21:33 Sat 28 Jan , Ryan Hill wrote:
 I've run into this three times today, so I'm a little grumpy.  When you bump
 to a new ~arch version, please consider keeping at least one previous ~arch
 version around, so if people run into major issues they can at lease try the
 previously installed version to determine if it's your package at fault.
 Recent version bumps to two libraries have completely trashed a package I
 maintain, and the only option for my users is downgrading them to stable,
 which requires downgrading several other libraries.  In both cases, the
 previous ~arch version, which worked fine, was removed.
 
 Personally I always try to keep two versions in ~arch and one stable,
 excepting security or other major bugs that render an older version useless.

Agreed with a slight modification — once you've kept the old 
{stable,~arch} version around for a reasonable amount of time (say 30 
days), you should be safe pulling it.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpSKypfDxmlZ.pgp
Description: PGP signature


Re: [gentoo-dev] Free Gentoo

2012-01-22 Thread Donnie Berkholz
On 21:01 Sat 21 Jan , . wrote:
 Hello there!
 
 Is there a chance that Gentoo may become a free distro?
 
 I'm so unhappy with the fact that there are some non-free packages in
 the main tree.
 The main goal of the GNU project was to replace the proprietary Unix system.
 You are actually ruining this goal.
 
 I'm also dissatisfied with the name of the distro. Linux is the kernel
 not the whole system.

Hi,

You should be using the Gentoo derivative Utoto GNU/Linux [1], which 
consists entirely of FSF-approved free software.

1. http://en.wikipedia.org/wiki/Ututo

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgpwhwggqOB6o.pgp
Description: PGP signature


Re: [gentoo-dev] How help in arch testing work

2012-01-18 Thread Donnie Berkholz
On 10:05 Wed 18 Jan , Mike Frysinger wrote:
 On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote:
  3) Check your rdepend, where is possible with scanelf[3] and if you 
  declare it, please, as you said, exclude gcc/glibc and all package 
  from @system
 
 portage generates a NEEDED file in the vdb

Awesome, never seen that before!

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/


pgp3cdeT1u02G.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: news item for sys-apps/systemd - /usr migration

2012-01-10 Thread Donnie Berkholz
On 10:25 Fri 06 Jan , Michał Górny wrote:
 On Thu, 05 Jan 2012 20:29:53 -0500
 Alexandre Rostovtsev tetrom...@gentoo.org wrote:
  I would suggest not removing the symlink unless there is a technical 
  reason why its presence is undesirable.
 
 The symlink is distro-specific. Honestly, I'd get rid of it sooner -- 
 but almost four months seem to be a safe period considering that we 
 are still in 'testing' stage mostly.

So other systemd-using distros have it in /usr? I'd follow their 
convention.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpz8wIaHHzi3.pgp
Description: PGP signature


Re: [gentoo-dev] Six month major project on Gentoo

2011-12-21 Thread Donnie Berkholz
On 10:29 Wed 14 Dec , Alec Warner wrote:
 On Wed, Dec 14, 2011 at 3:06 AM, Gaurav Saxena grvsaxena...@gmail.com wrote:
  Hello all,
  I am interested in doing my final year computer scence project on gentoo. I
  would be having a duration of six months to work on the project. Could you
  please suggest me some good project ideas that would be helpful to me as
  well as gentoo. I am interested in parallel computing, data structures ,
  operating system. I am well versed in C/C++. I think  there might be
  projects which need to be done, I would like to work on them.
 
 The only idea I can think of for parallel computing / distributed
 systems would be at the build level.
 
 distcc-ng, a farm of user-controlled machines that compile your code
 in a p2p fashion.

I looked into this 6 or 7 years ago. It wasn't feasible unless you were 
on an extremely high-speed, low-latency network, beyond what was 
typically accessible at the time outside of universities and LANs. Could 
be worth exploring again now that 25-100 mbps connections are becoming 
more common.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpbIWA2YfXR3.pgp
Description: PGP signature


Re: [gentoo-dev] News Item - MythTV

2011-12-21 Thread Donnie Berkholz
On 21:03 Mon 12 Dec , Peter Volkov wrote:
 В Птн, 09/12/2011 в 20:38 -0500, Rich Freeman пишет:
  I'm considering sending out this news item in a few days - comments
  are welcome.  It is a bit different in tone from a typical news item
  but MythTV has been in not-so-great shape for a while and my goal is
  to reel things in a bit and commit to something we can continue to
  maintain, while soliciting help from the community.
 
 This does not look like a news item, but more like a project status
 update or blog post. Probably it's much better to create webpage (or
 news item) on www.gentoo.org and add elog/ewarn to point there. Once
 mythtv team changes this information may change, but all users will see
 it anyway.

I like it fine as a GLEP42 news item, I hate it as a news item on the 
homepage for sure. Seems to me that pointing to the website for 
plaintext docs like this is kinda defeating the point of these news 
items. It's certainly more news rather than a long-term useful document, 
because at some point the change will happen, and then things are just 
the way they are.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgp89aeKXo0TJ.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Bleeding edge hardened-sources: move PaX markings from ELF to Extended Attributes

2011-12-07 Thread Donnie Berkholz
On 05:16 Fri 02 Dec , Duncan wrote:
 TL;DR: reiserfs (v3), for both caps and XT_PAX ??

A bit OT, but I find it incredibly ironic that perhaps the shortest 
email you've ever written contained a TL;DR segment.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpHC27Ef40KM.pgp
Description: PGP signature


Re: [gentoo-dev] rewritten epatch

2011-11-27 Thread Donnie Berkholz
On 18:45 Wed 23 Nov , Mike Frysinger wrote:
 personally, i've never found .rej useful.

It's nice if you use dev-util/wiggle.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgptppoeNYKdB.pgp
Description: PGP signature


Re: [gentoo-dev] huse: new helper for low level eclass writers

2011-10-20 Thread Donnie Berkholz
On 01:26 Thu 20 Oct , Mike Frysinger wrote:
 On Wednesday 19 October 2011 15:40:50 Brian Harring wrote:
  Name's a bit off though considering if the host was amd64, `huse amd64`
  would return 1 since it's not in IUSE.
 
 good point.  how about iuse_use ?  or use_iuse ?
 -mike

use_in_iuse ?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpZNI8F46o3g.pgp
Description: PGP signature


Re: [gentoo-dev] huse: new helper for low level eclass writers

2011-10-20 Thread Donnie Berkholz
On 12:22 Thu 20 Oct , Mike Frysinger wrote:
 On Thursday 20 October 2011 11:58:44 Donnie Berkholz wrote:
  On 01:26 Thu 20 Oct , Mike Frysinger wrote:
   On Wednesday 19 October 2011 15:40:50 Brian Harring wrote:
Name's a bit off though considering if the host was amd64, `huse amd64`
would return 1 since it's not in IUSE.
   
   good point.  how about iuse_use ?  or use_iuse ?
  
  use_in_iuse ?
 
 to me, that sounds like is the use flag in iuse.  but maybe i'm over 
 thinking 
 things.

alright, use_if_iuse. That's my last bikeshed for today.


-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpdYd1xNOUgU.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH autotools-utils] Use elibtoolize from libtool.eclass to fix libtool magic.

2011-10-10 Thread Donnie Berkholz
On 09:55 Mon 10 Oct , Michał Górny wrote:
 On Sun, 9 Oct 2011 21:08:43 -0500
 Donnie Berkholz dberkh...@gentoo.org wrote:
  On 10:21 Sun 09 Oct , Michał Górny wrote:
   We're calling it with '--patch-only' to avoid heavy changes to 
   ebuilds. This should handle gracefully eautoreconfed packages and 
   those not using libtool as well (in worst case, it should try to 
   apply patches twice).
  
  What kind of testing have you done?
 
 Simple testing on a few packages of mine. If you have something
 specific in mind, please be more accurate.

It's probably better to test on other people's code, since your own will 
always use eclass code in the way you imagine it being used. For changes 
to popular eclasses like this, I'd go find a cross-section of 25+ 
packages written by a variety of people besides yourself (or just test 
all 87 in the tree). Bonus points for those written by the most and 
least experienced devs, who I'd expect to use things in more 
unexpected/unlikely ways.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpZSatUY3Hl9.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH autotools-utils] Use elibtoolize from libtool.eclass to fix libtool magic.

2011-10-09 Thread Donnie Berkholz
On 10:21 Sun 09 Oct , Michał Górny wrote:
 We're calling it with '--patch-only' to avoid heavy changes to ebuilds.
 This should handle gracefully eautoreconfed packages and those not using
 libtool as well (in worst case, it should try to apply patches twice).

What kind of testing have you done?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpqkkgxxy6L7.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

2011-10-02 Thread Donnie Berkholz
On 00:31 Mon 03 Oct , Chí-Thanh Christopher Nguyễn wrote:
 It may be obvious to you, but it certainly is not obvious to me why
 linux-headers downgrade is so bad. If vapier's unsupported out-of-tree
 software fails to build against old linux-headers, then he has to make
 sure to have the correct version installed before proceeding. Blaming
 that on qutecom is far-fetched IMO.

There's like a million packages that use features in linux-headers, so 
it's not a isolated effect as with xorg-server.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpJmQC6XLYVa.pgp
Description: PGP signature


Re: [gentoo-dev] git-2: a bunch of patches to review

2011-09-22 Thread Donnie Berkholz
On 16:41 Thu 22 Sep , Andreas K. Huettel wrote:
 Am Donnerstag 22 September 2011, 13:27:47 schrieb Michał Górny:

The style change was approved by Donnie already.
   
   You mean that Donnie agreed with the style change. It's not up to any
   individual developer to approve such a change for the entire tree.
  
  What kind of 'entire tree'? It is just a single eclass, and its
  maintainer approves coding style change. Where do you see a problem
  with that?
  
 
 As Scarabeus wrote 99% of the eclass it's probably not obvious to 
 everyone that Donnie is listed as its maintainer.

And as Michał is making many of the changes recently because scarabeus 
got busy and the eclass works fine for me already, I figure it's his 
prerogative.

--
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpu61cwgFUSG.pgp
Description: PGP signature


Re: [gentoo-dev] new `usex` helper

2011-09-22 Thread Donnie Berkholz
On 09:37 Wed 21 Sep , Alec Warner wrote:
 On Wed, Sep 21, 2011 at 6:11 AM, Donnie Berkholz dberkh...@gentoo.org wrote:
  Not really, because when you update a bundled lib you actually make 
  your whole app compile with it. People change the APIs of eclasses 
  and then just let every internal consumer (ebuilds in gentoo-x86) 
  break. Maybe if we put the burden on the one who changed the API, 
  like the Linux kernel model, it would bother me less.
 
 I think people do this for three reasons.
 
 1) There are no refactoring tools that I know of for bash.
 2) There exist some package maintainers that will yell at you if you
 touch their packages for any reason.

To refer to the Linux model again, you send patches to the maintainers, 
and they just commit them. This is much less effort than figuring out to 
handle some incomprehensible change to an already weird eclass and then 
sorting out how to deal with it across 20 or 30 packages.

 3) Breaking things means they get fixed.
 
 We have this notify - deprecate - break workflow; I actually don't
 mind it (but only because I've seen it used elsewhere.)

I do, because I don't have time to deal with other people breaking my 
packages, whether they're in gentoo-x86, the science overlay, or my 
personal one. I've got more important things to deal with, within Gentoo 
and in the rest of my life.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpSPCiSQYwz8.pgp
Description: PGP signature


Re: [gentoo-dev] new `usex` helper

2011-09-22 Thread Donnie Berkholz
On 18:04 Thu 22 Sep , Alec Warner wrote:
 On Thu, Sep 22, 2011 at 5:41 PM, Donnie Berkholz dberkh...@gentoo.org wrote:
  I do, because I don't have time to deal with other people breaking 
  my packages, whether they're in gentoo-x86, the science overlay, or 
  my personal one. I've got more important things to deal with, within 
  Gentoo and in the rest of my life.
 
 You don't have time to fix breakages but you have time to do code 
 reviews?

If someone else I trust makes the changes and tells me they work, I can 
review code in an email on my cell phone in 15 seconds. I have to be on 
my single dev laptop with Gentoo repos and have a good 15 *minutes* to 
spare to figure out all the changes required, make them, test them, and 
do the commit.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpwzQq4wvFJa.pgp
Description: PGP signature


Re: [gentoo-dev] new `usex` helper

2011-09-21 Thread Donnie Berkholz
On 14:20 Tue 20 Sep , Brian Harring wrote:
 On Sun, Sep 18, 2011 at 10:16:46PM -0500, Donnie Berkholz wrote:
  OK, so the implication of what you're saying is that everything in 
  eutils.eclass, base.eclass, toolchain-funcs.eclass, 
  flag-o-matic.eclass, versionator.eclass, multilib.eclass, 
  prefix.eclass, savedconfig.eclass, and maybe even linux-info.eclass 
  and autotools{,-utils}.eclass should go into EAPI. All that stuff is 
  pretty generally useful features.
 
 Approximately... yes.  Some of that (base.eclass for example) is EAPI 
 compatibility that can't be folded in (would require retroactively 
 addding to an EAPI), others aren't yet stabilized (true multilib for 
 example, seems to still be under discussion), etc.
 
 You get the jist.

Yep, and I'm completely on the opposite end of the spectrum. =)

   They should, but api compatibility of an eclass *can* be fluid- in 
   the past it was a locked API purely because of portage environment 
   saving issues.  That's been resolved, there isn't any strict 
   requirement that the eclass maintain API compat now.  You're 
   trying to rely on people doing best practices- for format building 
   blocks (use_with/usex/unpack/etc), that's not sane.
  
  Which still pisses me off. It's like a shared library changing its 
  API without bumping SONAME.
 
 I think you're viewing this wrong; if we're talking about openssl 
 breaking API/ABI w/out bumping soname, sure.  It's one component that 
 is distributed alone, but consumed by others.  There is no way to 
 atomically deploy the new API at the same time as all of the consumers 
 being updated for it.
 
 That is /not/ the case of gentoo-x86; eclasses for us are equivalent 
 to bundled libs.  Overlay stacking just makes it possible for a third 
 party component to reach in and use what is effectively an internal 
 lib.

Not really, because when you update a bundled lib you actually make your 
whole app compile with it. People change the APIs of eclasses and then 
just let every internal consumer (ebuilds in gentoo-x86) break. Maybe if 
we put the burden on the one who changed the API, like the Linux kernel 
model, it would bother me less.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgp6JYY1kT8uQ.pgp
Description: PGP signature


Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)

2011-09-20 Thread Donnie Berkholz
On 10:00 Tue 20 Sep , Corentin Chary wrote:
 Could someone write ebuilds for euscan and euscanwww ? It should not 
 take a lot of time, but my ebuilds skills are probably not good 
 enought to do that.

Sounds like good practice for when you become a Gentoo dev. =)

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgp3w1etPQaXu.pgp
Description: PGP signature


Re: [gentoo-dev] new `usex` helper

2011-09-18 Thread Donnie Berkholz
On 04:22 Sun 18 Sep , Brian Harring wrote:
 On Sat, Sep 17, 2011 at 10:59:08PM -0500, Donnie Berkholz wrote:
  On 13:43 Fri 16 Sep , Brian Harring wrote:
   What I said from the getgo and you're missing is that pushing EAPI 
   implementation into the tree and ignoring EAPI, or having this notion 
   that every repository must automatically use gentoo-x86 (pushing the 
   format into the tree) is /wrong/;
  
  I'm not necessarily requiring that every repository must automatically 
  use gentoo-x86 ??? just the ones that want to use features in an eclass 
  distributed with gentoo-x86. It sounds to me like the logical 
  consequence of what you're saying is that every useful function that's 
  now or could eventually be in an eclass must instead be incorporated 
  into EAPI. I guess I just don't see where you're drawing the line.
 
 Drawing it back to what spawned it; usex.  This isn't git.eclass, this 
 isn't svn.eclass, nor is it any of the other complex eclass 
 functionality.  It's a core function that benefits the rest and should 
 be in EAPI.

OK, so the implication of what you're saying is that everything in 
eutils.eclass, base.eclass, toolchain-funcs.eclass, flag-o-matic.eclass, 
versionator.eclass, multilib.eclass, prefix.eclass, savedconfig.eclass, 
and maybe even linux-info.eclass and autotools{,-utils}.eclass should go 
into EAPI. All that stuff is pretty generally useful features.

  What I'm suggesting is that we should add useful stuff to eclasses 
  by default. If people want to use that stuff, they can stack on the 
  gentoo-x86 repo and inherit the eclass. I don't know why EAPI needs 
  to come into it at all.
 
 Stacking on gentoo-x86 means you get *everything* for that repository.  
 If all you want is a random function out of eutils, that's a *lot* of 
 uncontrolled change to have intermixed with your overlays eclasses 
 (even worse, if the eclasses truly overlay into gentoo-x86, that 
 introduces compatibility issues there too).

Yeah, it seems like the ability to do partial stacking would be nice. 
Perhaps to do so, one wouldn't stack by default but would have a way to 
specify cross-repo dependencies (including eclasses) or file-specific 
UUIDs of some sort.

   aside from meaning that the format definition can now *vary*, 
   which is great for wasting dev time and screwing up compatibility, 
   it opens up tweaking/customizing that functionality- aka, 
   fragmentation/divergence.
  
  People doing that outside gentoo-x86 should do it the same way as 
  ones within it, by bumping the eclass to a new unique name. Ideally 
  one that's not just a numeric value so it won't conflict with ours, 
  in the same way as EAPI naming.
 
 They should, but api compatibility of an eclass *can* be fluid- in the 
 past it was a locked API purely because of portage environment saving 
 issues.  That's been resolved, there isn't any strict requirement that 
 the eclass maintain API compat now.  You're trying to rely on people 
 doing best practices- for format building blocks 
 (use_with/usex/unpack/etc), that's not sane.

Which still pisses me off. It's like a shared library changing its API 
without bumping SONAME. That makes me wonder whether there's some way we 
could enforce it, at least on the level of repoman or test suites to 
examine whether the public interface changed, perhaps by generating a 
cache of the interfaces and comparing to them.

 I suspect an easier way to wrap this thread up is if you just state 
 what you want for backwards compatibility- in a seperate thread you 
 already proposed basically locking out systems older than 6 months, 
 and this discussion (moreso the eapi slows our development subtext) 
 is along the same lines.

Actually Zac said that, and I was trying to clarify if that's really 
what he was saying. 9-12 months is more my feeling, as it gets extremely 
difficult to maintain Gentoo systems without guru-level knowledge around 
there. (Spoken as someone who still gets support emails from a couple of 
previous positions.)

While I would like there to be a proper way to express repo-level 
dependencies, properly announce deprecation and updates (e.g. to bash 4) 
in advance as a feature integrated with the PM, and so on, I don't think 
we should block our ability to move forward on these things. The 
situation is essentially the same as it's always been, but our old 
solution is no longer considered good enough and we don't have a new one 
in place, so we're just sitting here.

 Layout what you think it should be,

Layout of what, exactly?

 how you think EAPI should be managed (what goes in, what doesn't, 
 etc),

If it can go in an eclass without strange contortions, put it there.

 how derivatives should be handled,

With white gloves. More seriously, people making derivatives should have 
maximal freedom to experiment, and I'm guessing most of them don't want 
to deal with modifying 3 different PMs written at least partially in 3 
different languages

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

2011-09-17 Thread Donnie Berkholz
On 14:06 Fri 16 Sep , Zac Medico wrote:
 Bumping the EAPI of the root profiles/eapi file would be a different 
 matter, since it applies to the whole repository. If you want to 
 version bump that repository-level EAPI, then you need to wait until 
 at least 6 months after supporting package managers have been 
 available in stable.

So in your opinion, it would be fine to bump profiles/eapi to EAPI=4 
now?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpT74nMsKtpS.pgp
Description: PGP signature


Re: [gentoo-dev] new `usex` helper

2011-09-17 Thread Donnie Berkholz
On 13:43 Fri 16 Sep , Brian Harring wrote:
 What I said from the getgo and you're missing is that pushing EAPI 
 implementation into the tree and ignoring EAPI, or having this notion 
 that every repository must automatically use gentoo-x86 (pushing the 
 format into the tree) is /wrong/;

I'm not necessarily requiring that every repository must automatically 
use gentoo-x86 — just the ones that want to use features in an eclass 
distributed with gentoo-x86. It sounds to me like the logical 
consequence of what you're saying is that every useful function that's 
now or could eventually be in an eclass must instead be incorporated 
into EAPI. I guess I just don't see where you're drawing the line.

What I'm suggesting is that we should add useful stuff to eclasses by 
default. If people want to use that stuff, they can stack on the 
gentoo-x86 repo and inherit the eclass. I don't know why EAPI needs to 
come into it at all.

 aside from meaning that the format definition can now *vary*, which is 
 great for wasting dev time and screwing up compatibility, it opens up 
 tweaking/customizing that functionality- aka, 
 fragmentation/divergence.

People doing that outside gentoo-x86 should do it the same way as ones 
within it, by bumping the eclass to a new unique name. Ideally one 
that's not just a numeric value so it won't conflict with ours, in the 
same way as EAPI naming.

 If we did the sort of thing you're basically pushing for, how long do 
 you think it would be till funtoo added support for a new archive 
 format to unpack?  That's a *simple*, and *likely* example of how this 
 can diverge.

So, what I'm getting out of this is that we should make it harder for 
derivative distributions to innovate? Why should I care if they want to 
do stuff with new archive formats?

 Further, doing as you propose means we're flat out, shit out of luck 
 /ever/ distributing a usable cache for standalone repositories.  If 
 they're bound to the changes of another repository, distributing a 
 cache in parallel is pointless (and not doable in current form since 
 metadata/cache lacks necessary eclass validation data for overlay 
 inheritance).

Not much different from other cross-repository dependencies; you have to 
keep everything in lockstep because who knows what other people will do 
with their repos. Maybe people would want to distribute their own copies 
of forked dependent repositories too, I haven't thought much about it.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgptazUS3EHSs.pgp
Description: PGP signature


Re: [gentoo-dev] new `usex` helper

2011-09-16 Thread Donnie Berkholz
On 02:06 Fri 16 Sep , Brian Harring wrote:
 Specious argument; the point of controllable stacking was to avoid the 
 issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds 
 (which may not support those modified eclasses) via the old 
 PORTDIR_OVERLAY behaviour.  This is why multiple repositories have 
 layout.conf master definitions- to explicitly mark that they 
 require/consume a seperate repo.

So let me get this straight — instead, you want overlay users to 
maintain a copy of every eclass they use, which will almost 
automatically become outdated and stale because it won't track the 
gentoo-x86 version?

 What you're basically proposing is a variation of the push format 
 definitions into a central tree, and require everyone to use that 
 central tree.  This discussion has come and gone; I say that being 
 one of the folks who was *pushing for the repository solution*.  The 
 problem there is it fundamentally enables (more forces) fragmentation.

I think Gentoo will always provide one or a set of official central 
repositories, that's pretty much the definition of a distribution. So 
yes, I'm saying that generally useful stuff could go into one of these 
repositories, which (in the multi-repo case) could be like the eclass 
metaphor for repos; others would depend on it implicitly or explicitly.

 Realistically I assume you're taking the stance EAPI gets in the way, 
 lets do away with it- if so, well, out with it, and I'll dredge up 
 the old logs/complaints that lead to EAPI.

I see EAPI as a nice thing for standardizing features that are 
implemented in the PM so they work identically across portage, pkgcore, 
and paludis. But I don't think that implementing things in the PM when 
they could go in an eclass is automatically the best choice. It 
dramatically slows down the speed of iteration, prototyping, and bug 
fixing.

 rephrase please; either you're saying everyone uses gentoo-x86 which 
 is sort of true (funtoo/chrome aren't necessarily riding HEAD/trunk 
 however which means things can get ugly for derivative repository 
 usage), but still ignores the situations where people have overlays w/ 
 developmental eclasses that they need to selectively control where it 
 overrides (which is where the notion of repo stacking comes into 
 play).

I think I explained above, but let me know if that's not the case.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpQi7rzibDrE.pgp
Description: PGP signature


Re: [gentoo-dev] x32 fun pants

2011-09-16 Thread Donnie Berkholz
On 15:34 Thu 15 Sep , Mike Frysinger wrote:
 ive converted my system over to x86/amd64/x32 multilib for funs.  but i can 
 see how some people wont want all three all the time.  so the question is how 
 we want to make this available to users at the release/profile level.
 
 background: x32 is a new ABI that runs on 64bit x86_64 processors.  see [1].  
 you'll need gcc-4.7+, binutils-2.21.50+, glibc-2.15+, and linux-3.2+.

For anyone interested how the performance compares to amd64 in more 
comprehensive tests, check out the slides from the Linux Plumbers 
Conference (particularly 14-21):

http://linuxplumbersconf.org/2011/ocw/proposals/531

In summary, on those benchmarks it looks like a small global win (maybe 
5%) on integer calculations with a few huge wins of ≥25%, but a net loss 
around 5% pretty much globally for floating-point calculations.

Most people probably do a lot more integer calculations unless they're 
science geeks like me, plus it should have lower memory use, so my 
understanding is that it probably makes sense to switch to x32 no matter 
what you're using now (x86 or amd64).

Mike, would you agree?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgp9K9W7gd3d2.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Adding a tiny install-mask directory list to gx86

2011-09-16 Thread Donnie Berkholz
On 11:36 Fri 16 Sep , Michał Górny wrote:
 The question is: where to store such a directory list?
 
 Keeping it inside project sources doesn't seem right as it would 
 require me to bump and re-release project every time a directory is 
 added. Keeping it in separate package which would need to be kept in 
 sync doesn't seem too good either.
 
 That's why I'm considering including a tiny file in gx86 (and possibly 
 other repositories) itself. Such a file could have a simple format and 
 specify mappings of 'install-mask names' (similar to USE flag names) 
 to lists of directories and possibly descriptions.

Do something like layman or repoman where it auto-fetches periodically. 
Layman has the advantage of also supporting add-on files in addition to 
the main one. I don't want this in my repo.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgp9tWKbxQw2E.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH autotools-utils 1/9] Fix handling whitespace in filenames when looking for .la files.

2011-09-16 Thread Donnie Berkholz
On 21:53 Tue 13 Sep , Nirbheek Chauhan wrote:
 On Tue, Sep 13, 2011 at 8:43 PM, Dirkjan Ochtman d...@gentoo.org wrote:
  2011/9/13 Michał Górny mgo...@gentoo.org:
  ---
   eclass/autotools-utils.eclass |    2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
 
  I don't think sending 9 patches is very useful for this mailing list.
  Next time just sent a link to a git repo or something?
 
 
 On the contrary, I like that mgorny sent separate completely
 independent patches for review to the list instead of either sending
 on huge chunk, or not sending patches at all.

+1, except parts of them were dependent. =) Maybe use some `git rebase 
--interactive` next time..

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgp3Hnb8ts55I.pgp
Description: PGP signature


Re: [gentoo-dev] new `usex` helper

2011-09-15 Thread Donnie Berkholz
On 17:29 Wed 14 Sep , Brian Harring wrote:
 On Wed, Sep 14, 2011 at 02:16:41PM -0500, Donnie Berkholz wrote:
  On 19:14 Tue 13 Sep , Brian Harring wrote:
   On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote:
On 17:56 Tue 13 Sep , Mike Frysinger wrote:
 useful enough for EAPI ?  or should i just stick it into 
 eutils.eclass 
 ?  OR BOTH !?

I prefer to avoid EAPI whenever possible, as it just makes things 
slower 
and more complex.
   
   Exactly the wrong approach; it winds up with master 
   repositories/overlays cloning the functionality all over the damn 
   place.
  
  Why are people cloning anything if it's in eutils.eclass in gentoo-x86?
 
 There are more repositories than just gentoo-x86, and overlay is *not* 
 the only configuration in use.

Who else besides you is using any other configuration? Should we really 
give a crap about the 0.001% population with some weird setup when we're 
trying to improve things for the 99.999% one?

 In the old days of the PM only handling a single overlay stack, what 
 you're suggesting would be less heinous- heinous in detail, but 
 pragmatic in reality.  These days it's a regressive approach- 
 requiring everyone to slave gentoo-x86 isn't sane, nor is avoiding 
 eapi (resulting in people having to duplicate code into each 
 repository stack).

I don't know many people who aren't using gentoo-x86 or a repo that 
pulls in changes directly from it.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgp6FhfQzVVid.pgp
Description: PGP signature


Re: [gentoo-dev] new `usex` helper

2011-09-14 Thread Donnie Berkholz
On 19:14 Tue 13 Sep , Brian Harring wrote:
 On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote:
  On 17:56 Tue 13 Sep , Mike Frysinger wrote:
   useful enough for EAPI ?  or should i just stick it into eutils.eclass 
   ?  OR BOTH !?
  
  I prefer to avoid EAPI whenever possible, as it just makes things slower 
  and more complex.
 
 Exactly the wrong approach; it winds up with master 
 repositories/overlays cloning the functionality all over the damn 
 place.

Why are people cloning anything if it's in eutils.eclass in gentoo-x86?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpLbZB1u1CsQ.pgp
Description: PGP signature


Re: [gentoo-dev] new `usex` helper

2011-09-14 Thread Donnie Berkholz
On 06:34 Wed 14 Sep , Ciaran McCreesh wrote:
 On Tue, 13 Sep 2011 21:02:28 -0500
 Donnie Berkholz dberkh...@gentoo.org wrote:
  On 17:56 Tue 13 Sep , Mike Frysinger wrote:
   useful enough for EAPI ?  or should i just stick it into
   eutils.eclass ?  OR BOTH !?
  
  I prefer to avoid EAPI whenever possible, as it just makes things
  slower and more complex.
 
 Sticking it in an EAPI *shouldn't* be slow and more complex. There are
 three reasons why it is, and they should all be within Gentoo's
 ability to solve.

[..reasons..]

I'm glad we agree about its current state, whatever the reasons. 

While I wish I could do something about them, I can't at all in some 
cases or quickly in others. No matter what, it's going to be a slow 
process to change them, and I'd like to keep things like this from 
blocking on that. I'm hoping to fix some of the council-related issues 
with an updated GLEP 39 (WIP), but even being on the council doesn't 
help much in making others focus on productive issues.


-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpRPCNKacCwa.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.

2011-09-13 Thread Donnie Berkholz
On 06:39 Tue 13 Sep , Joshua Kinard wrote:
 On 09/13/2011 06:29, Michał Górny wrote:
 
  On Tue, 13 Sep 2011 12:21:31 +0200
  Michał Górny mgo...@gentoo.org wrote:
  
  +# @FUNCTION: has_iuse
  
  Ideas for a better name will be appreciated.
 
 
 'in_iuse' or 'iuse_contains'?

I'd prefer to keep consistency with the parent function has(), so it's 
obvious exactly how it will work.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpA9WTwC02k1.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] obs eclasses

2011-09-13 Thread Donnie Berkholz
On 15:02 Tue 13 Sep , Amadeusz Żołnowski wrote:
 Excerpts from Joshua Kinard's message of 2011-09-13 14:26:02 +0200:
   You don't need -n/-z with [[.
   
 [[ $var ]] == [[ -n $var ]]
 [[ ! $var ]] == [[ -z $var ]]
  
  What about other comparisons, like -f, -e, or -d?
 
 Same as inside [, but no need of quotes inside [[.
 
  Also, is this a bash4-only thing, or bash3 and/or bash2 as well?
 
 I'm not sure.
 
 OT: When I was going through recruitment process, dberkholz pointed to
 me that I use things bash4-only. And again: why we need to stick to
 ancient 3 version? I would understand pseudo POSIX compatibility, but
 what is the benefit of bash3 compatibility while bash4 is stable
 already?

It's because people want to pretend that it's possible for incredibly 
outdated systems (those with bash-3 only) to be updated.

We're stuck in this limbo because we have apparently decided that just 
waiting a year, as we used to do, isn't good enough anymore; but at the 
same time, we don't have a better mechanism in place yet. So we're 
waffling around, doing nothing.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgp6rUsNsnKPn.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] obs eclasses

2011-09-13 Thread Donnie Berkholz
On 13:11 Tue 13 Sep , Michal Hrusecky wrote:
 # Copyright 1999-2011 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: $
 
 # @ECLASS: obs-download.eclass

Are there going to be lots of packages using this and not the other 
eclass? I wonder whether there really need to be two of them.

 # @MAINTAINER:
 # mi...@gentoo.org
 # @BLURB: Reduces code duplication in the downloading from obs.

Could you tell us what obs is in the blurb too? I had no clue what 
this email was about (obs, osc, etc are meaningless to me) until I got 
down to the eclass description.

 # @ECLASS: obs-service.eclass
 # @MAINTAINER:
 # mi...@gentoo.org
 # @BLURB: Reduces code duplication in the obs services.
 # @DESCRIPTION:
 # This eclass makes it easier to package obs services. Based on provided
 # information it will all neede variables and takes care of installation.

Lots of typos here.

 HOMEPAGE=http://en.opensuse.org/openSUSE:OSC;
 LICENSE=GPL-2
 SLOT=0
 IUSE=
 RDEPEND+=dev-util/osc

You probably want a space here.

RDEPEND+= dev-util/osc

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpkPf2od7LwK.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] obs eclasses

2011-09-13 Thread Donnie Berkholz
On 17:58 Tue 13 Sep , Patrick Lauer wrote:
 On 09/13/11 16:44, Donnie Berkholz wrote:
  It's because people want to pretend that it's possible for 
  incredibly outdated systems (those with bash-3 only) to be updated.
 
 Actually it's worse - PMS enforces this, and the only clean way out is 
 to patch/fix/extend PMS to allow bash4 - but that breaks compatibility 
 in silly ways.
 
 The proper way to handle that? I'm not sure, since we had a long fight 
 to get PMS to acknowledge bash 3.2 instead of 3.0 I'm mostly ignoring 
 PMS as it doesn't care about reality.

Thanks for the reminder; I looked, and it turns out that we now have a 
great precedent. Quoting PMS:

The required bash version was retroactively updated from 3.0 to 3.2 in 
November 2009 (see http://www.gentoo. 
org/proj/en/council/meeting-logs/20091109.txt).

So we could just retroactively update it again and let people scream if 
they're actually affected by this.

  We're stuck in this limbo because we have apparently decided that 
  just waiting a year, as we used to do, isn't good enough anymore; 
  but at the same time, we don't have a better mechanism in place yet. 
  So we're waffling around, doing nothing.
 
 That's not quite correct for this case, but it shows that we need to 
 discuss destructive changes (in the sense that they are not 
 backwards-compatible etc.) to have any decent progress

Maybe a way to set tree-level dependencies/EAPIs/features is something 
we seriously need to get going on.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpdqwj5WnNHA.pgp
Description: PGP signature


Re: [gentoo-dev] new `usex` helper

2011-09-13 Thread Donnie Berkholz
On 17:56 Tue 13 Sep , Mike Frysinger wrote:
 useful enough for EAPI ?  or should i just stick it into eutils.eclass 
 ?  OR BOTH !?

I prefer to avoid EAPI whenever possible, as it just makes things slower 
and more complex.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpi0BtNsnWIk.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH] autotools-utils.eclass: punt unnecessary .la files even w/ USE=static-libs.

2011-09-12 Thread Donnie Berkholz
On 21:57 Mon 12 Sep , Michał Górny wrote:
 Right now, autotools-utils.eclass punts .la files only with
 USE=-static-libs. We'd like to broaden the range of it and strip .la
 files when they are not necessary for static linkage as well.
 
 The following patch introduces an initial support for that. It assumes
 that the .la file can be removed if the library is mentioned in any of
 pkg-config files installed by the package, or if doesn't specify any
 dependency libs nor linker flags.

If I understand correctly, this will break for any packages that don't 
use pkg-config to link. The maintainers will manually need to add 
pkg-config calls to the ebuilds of anything that could statically link 
against a library using only libtool and not pkg-config. Is that 
accurate?

It might be worthwhile to add an easy way to force this argument on for 
every package for the purposes of testing, e.g. an environment variable.

  # @FUNCTION: remove_libtool_files
 -# @USAGE: [all|none]
 +# @USAGE: [all|only-not-required|none]

Is there a way to document the arguments of eclass functions? You added 
the name of the arg but didn't describe its purpose or why anyone would 
want to use it.

On a semantic note, that argument name (only-not-required) doesn't make 
sense to me. I might do something more helpful like pkgconfig-duplicates 
instead.

 + if [[ $1 == 'only-not-required' ]]; then

This is way more quoting than you need within double brackets.

   local f
   for f in $(find ${D} -type f -name '*.la'); do
   # Keep only .la files with shouldnotlink=yes - likely plugins
   local shouldnotlink=$(sed -ne '/^shouldnotlink=yes$/p' ${f})
   if [[  $1 == 'all' || -z ${shouldnotlink} ]]; then
 + if [[ $1 == 'only-not-required' ]]; then

Is there a case where one of those arguments might be $2 but you'd still 
want to run this?

I feel like that shouldnotlink thing is really confusing the logic, 
because there's multiple nested tests for different values of $1 in here 
instead of just testing the args once at the top and setting variables.

 + # remove .la files only when .pc files provide 
 the libs
 + # already or they don't give any information
 + ! has $(basename ${f}) ${pc_libs} \
 +  [[ -n $(sed -n \

The comment says or but I see an and here.

 + -e 
 s/^dependency_libs='\(.*\)'$/\1/p \
 + -e 
 s/^inherited_linker_flags='\(.*\)'$/\1/p \
 + ${f}) ]] \
 +  continue
 + fi
 +

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpMghPH2v6CX.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH] autotools-utils.eclass: punt unnecessary .la files even w/ USE=static-libs.

2011-09-12 Thread Donnie Berkholz
On 00:46 Tue 13 Sep , Samuli Suominen wrote:
  If I understand correctly, this will break for any packages that 
  don't use pkg-config to link. The maintainers will manually need to 
  add pkg-config calls to the ebuilds of anything that could 
  statically link against a library using only libtool and not 
  pkg-config. Is that accurate?
 
 Yes, seems accurate.
 
 I can think of 'export PKG_CONFIG=$($(tc-getPKG_CONFIG) --static)' or 
 something like 'export FOO_LIBS=$($(tc-getPKG_CONFIG) --libs --static 
 foo)' to accomplish getting static flags from an ebuild using 
 toolchain-funcs.eclass if required.
 
 Or they do it like lvm2 and cryptsetup at upstream level and add 
 support for statically linking the tools in the build-system.
 
 The .la files are not helping packages not using libtool in any case, 
 for example, those using cmake as build-system.
 
 And I've yet to see a real, in portage residing, example of where this 
 would really break anything and when I will, I'll gladly help 
 migrating it to the example mentioned above... Overall, corner cases 
 that can be easily worked around, yet punting the *harmful* .la files.

That's rather shocking. All it would take is trying to statically build 
a package not using pkg-config that links against anything X11-related 
(since all of them have .pc files).

It's probably more that nobody cares about static building than that 
there aren't packages that would break.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgphwBqOBZT6Q.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH] autotools-utils.eclass: punt unnecessary .la files even w/ USE=static-libs.

2011-09-12 Thread Donnie Berkholz
On 23:58 Mon 12 Sep , Michał Górny wrote:
 On Mon, 12 Sep 2011 16:00:20 -0500
 Donnie Berkholz dberkh...@gentoo.org wrote:
 local f
 for f in $(find ${D} -type f -name '*.la'); do
 # Keep only .la files with shouldnotlink=yes -
   likely plugins local shouldnotlink=$(sed -ne
   '/^shouldnotlink=yes$/p' ${f}) if [[  $1 == 'all' || -z
   ${shouldnotlink} ]]; then
   + if [[ $1 == 'only-not-required' ]]; then
  
  Is there a case where one of those arguments might be $2 but you'd
  still want to run this?
 
 Er? What are you referring to?

Two things.

1. This is only reached if shouldnotlink is false. That means it's only 
the things that you are already assuming are plugins, right? If so, why 
is this even done?

2. What happens if I call it with `remove_libtool_files all 
only-not-required`? Nobody ever does any checking of the # of args.

  I feel like that shouldnotlink thing is really confusing the logic, 
  because there's multiple nested tests for different values of $1 in 
  here instead of just testing the args once at the top and setting 
  variables.
 
 As mentioned earlier, the code needs to be refactored. First things 
 first, then we'll rewrite it to be nice and clean. I don't really want 
 to waste time doing this if we would need to rewrite it for more logic 
 in the future.

I'd rewrite it once as soon as you get all the reviews and before 
committing. Rewrites tend to never happen, since it turns out that 
people have other things to do with their time.

   + # remove .la files only when .pc
   files provide the libs
   + # already or they don't give any
   information
   + ! has $(basename ${f})
   ${pc_libs} \
   +  [[ -n $(sed -n
   \
  
  The comment says or but I see an and here.
 
 Because everything's negated here. Boolean magic :D.

OK, got it. Stop writing confusing logic. =P

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgprcOSPCGwcn.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: devqawarn()?

2011-09-01 Thread Donnie Berkholz
On 14:44 Thu 01 Sep , Petteri Räty wrote:
 One thing to note is that we should get eqawarn into the next EAPI.

Why?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpC80OrHx438.pgp
Description: PGP signature


Re: [gentoo-dev] Rewriting bash-completion.eclass

2011-09-01 Thread Donnie Berkholz
On 15:20 Thu 01 Sep , Tomáš Chvátal wrote:
 Dne 1.9.2011 15:15, Michał Górny napsal(a):
  We can either go with a new func and retroactively replace the 
  eclass, or retroactively fix all uses and fix the old funcs.
 
 As even if you fix main tree you can't ensure that you won't mess with 
 some overlay (silently as it would not be seen by default).
 
 I would then go proactively and fix the packages inheriting the bashcomp 
 eclass and when done just mark the eclass as dead.

Yes, please stop breaking backwards compat without version bumps to a 
new eclass. It's just as annoying in an eclass as in a shared library.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpe4A1WUfHEv.pgp
Description: PGP signature


Re: [gentoo-dev] mesa r600 gallium news item

2011-08-31 Thread Donnie Berkholz
On 23:12 Thu 25 Aug , Chí-Thanh Christopher Nguyễn wrote:
 Existing users will not be switched automatically.

Why not? If it's considered the supported route going forward, we should 
just do it automatically.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgphL8deYJFG4.pgp
Description: PGP signature


Re: [gentoo-dev] mesa r600 gallium news item

2011-08-31 Thread Donnie Berkholz
On 17:51 Wed 31 Aug , Chí-Thanh Christopher Nguyễn wrote:
 Donnie Berkholz schrieb:
  On 23:12 Thu 25 Aug , Chí-Thanh Christopher Nguyễn wrote:
  Existing users will not be switched automatically.
  
  Why not? If it's considered the supported route going forward, we should 
  just do it automatically.
 
 Some users might be using UMS instead of KMS still, which would break 3D
 acceleration once they are switched to gallium.

So migrate them. =)

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpyZdTbs8Ifi.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoostats, SoC 2011

2011-08-29 Thread Donnie Berkholz
On 03:18 Fri 26 Aug , Jorge Manuel B. S. Vicetto wrote:
 I've picked this message as I want to address one point in this thread 
 that was focused on this sub-thread. I disagree with the idea that 
 adding an application to the Gentoo tree that collects data from users 
 and sends it to a central (or distributed) system is the same as 
 adding any other application to the tree. Having the ability to add 
 ebuilds to the tree is part of what you gain by getting gentoo-x86 
 access. Issues with significant users privacy concerns and substantial 
 changes like adding packages to the tree that collect data from users 
 and compile it,

Like, oh, any package with a built-in bug reporting system?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgplaqzIBXO04.pgp
Description: PGP signature


Re: [gentoo-dev] Implicit system dependencies

2011-08-23 Thread Donnie Berkholz
On 19:08 Tue 23 Aug , Maciej Mrozowski wrote:
 On Tuesday 23 of August 2011 18:54:04 Paweł Hajdan, Jr. wrote:
  On 8/22/11 12:21 PM, Michael wrote:
   I wrote a script to search for discrepancies between linked libraries and
   what's defined in (R)DEPEND, with the intention of improving QA for
   minimal package installs.
  
  It would be great to integrate this into portage and make it a part of
  the developer profile. This would just help prevent future breakages.
 
 It seems there are a couple of such home-grown solutions already.
 dberkholz used to have on in his dev webspace[1], we have one[2] in kde 
 overlay...
 
 1.  http://dev.gentoo.org/~dberkholz/scripts/ (linking_libs, included_headers)
 2. 
 http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=Documentation/maintainers;hb=master
  
 (dynlink_scanner + try_dlopen.c)


Also we've got a couple of really cool GSoC projects along these lines.

One is called autodep [1, 2], and it integrates into portage to let you 
know if you're missing deps or specified too many deps.

The other one is an ebuild generator [3, 4] that works for autotools but not a 
lot else at this point.

1. 
http://archives.gentoo.org/gentoo-soc/msg_7491f6b5bffdccaedc939beb6e1c4f0d.xml 
2. http://dev.gentoo.org/~neurogeek/guidexml/ (temporary homepage)
3. 
http://archives.gentoo.org/gentoo-soc/msg_e29529cb6f3dfc762f4f7e313b106deb.xml
4. http://soc.dev.gentoo.org/~darkdefender/ebuildgenerator

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgp441wcSLJ6h.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

2011-08-20 Thread Donnie Berkholz
On 17:41 Thu 18 Aug , Roy Bamford wrote:
 Just as long as we can provide the patch sets for a period of at least 
 three years, in case someone asks.  Thats a GPL requirement.

Just to be clear, it's only a requirement if you're going with the 
written offer to provide source clause rather than the providing 
source at the same time as binary clause (i.e., 3b rather than 3a in 
GPL-2).

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpKNPzYQVAdA.pgp
Description: PGP signature


Re: [gentoo-dev] USE=introspection has been unmasked in the tree

2011-08-16 Thread Donnie Berkholz
On 21:23 Tue 16 Aug , Nirbheek Chauhan wrote:
 A side-note that we've wanted to get out to all devs is that everyone
 should *always* use IUSE=+introspection.

Then why is it a flag?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpuI4oupoiUE.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package

2011-08-09 Thread Donnie Berkholz
On 20:55 Sat 06 Aug , Robin H. Johnson wrote:
 Everything you have mentioned here was previously covered in the 
 discussions about Git conversion models. Please consult the history of 
 this list, as well as the -scm list. Additionally, a large discussion 
 about the pros and cons of all 3 models (package per repo, category 
 per repo, single repo) was had at the GSoC mentor summit last year, 
 and a number of the core Git developers were involved in the 
 discussion.

While noting the above [1 and its thread], I'd also like to point out 
that git submodules are conceptually a good fit but the implementation 
is lacking. Two examples:

- Creating new submodules requires administrative rights on the server. 
You can't just add one and push it up. This could conceivably be fixed 
by a hook that ran a specific privileged command to add a submodule, but 
I'm not really sure how or whether it's currently possible given the 
times available to run hooks.

- What we'd really want with submodules is to have the primary object 
storage shared in the master repo rather than in the submodule. That way 
we'd benefit from compression across packages, and furthmore, package 
moves wouldn't duplicate history.

If you're interested in fixing the above problems as well as the ones 
that exist regardless of repo format (linked on the main tracker bug 
[2]), then submodules could become a better option.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com

1. 
http://archives.gentoo.org/gentoo-scm/msg_98932c55ec10fcc5445ab950e62b12dc.xml
2. https://bugs.gentoo.org/show_bug.cgi?id=333531


pgp7n15SHaMHz.pgp
Description: PGP signature


Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)

2011-07-27 Thread Donnie Berkholz
On 09:39 Wed 27 Jul , Michał Górny wrote:
 As many of us already raged, the Python eclasses are delaying half a 
 year with support of EAPI=4. The reason for that is not actually the 
 lack of time or complexity of needed changes but willingness to use 
 the new EAPI as an excuse to turn the eclass API upside down.
 
 The question I'm raising here: should eclasses be actually allowed to 
 do *heavy* changes in their APIs in such cases? Or should the eclass 
 maintainers create a new eclass instead (python-r1.eclass or so)?

Eclasses still shouldn't break backwards compatibility — that hasn't 
changed in the past 5 years, despite what a very small minority of devs 
appears to think. This has been a huge PITA for python.eclass in 
particular, which has broken tons of my ebuilds for no particular 
reason. (And no, a 30-day warning is not an excuse for breaking 
anything.)

If you need to edit an eclass for EAPI/API changes anyway, updating the 
inherit line to python-2 instead of python isn't a big deal.

In the general sense, I think changing the API in arbitrary ways based 
on the EAPI in use is just plain confusing, and it should go into a new 
version-bumped eclass instead.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpgLBfaNeoHa.pgp
Description: PGP signature


Re: [gentoo-dev] net-misc/pimd RFC for new ebuild

2011-07-19 Thread Donnie Berkholz
On 11:43 Sun 17 Jul , Kacper Kowalik wrote:
 W dniu 17.07.2011 10:45, Kfir Lavi pisze:
  src_compile() {
  emake CC=$(tc-getCC) || die
  }
 Some systems export CC as gcc -m64.

I guess I'm a little confused here. What exactly is the problem and fix 
you're proposing? You stopped halfway through, there should've been a 
part at the end that said:

, so you need to do XX to avoid YY from happening.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpJjW4Wm54GR.pgp
Description: PGP signature


Re: [gentoo-dev] net-misc/pimd RFC for new ebuild

2011-07-19 Thread Donnie Berkholz
On 14:40 Tue 19 Jul , Mike Frysinger wrote:
 On Tue, Jul 19, 2011 at 14:32, Kacper Kowalik wrote:
  W dniu 19.07.2011 19:31, Donnie Berkholz pisze:
  On 11:43 Sun 17 Jul     , Kacper Kowalik wrote:
  W dniu 17.07.2011 10:45, Kfir Lavi pisze:
  src_compile() {
      emake CC=$(tc-getCC) || die
  }
 
  Some systems export CC as gcc -m64.
 
  I guess I'm a little confused here. What exactly is the problem and fix
  you're proposing? You stopped halfway through, there should've been a
  part at the end that said:
 
  , so you need to do XX to avoid YY from happening.
 
  Use quotes: CC=$(tc-getCC). Without it you could get emake CC=gcc -m64
  and that would of course fail.
 
 CC=gcc -m64 is a fairly questionable setting in the first place
 (you're most likely doing something wrong/stupid already), but quoting
 the CC arg on the cmdline as suggested is the right thing.

Ah, yeah, I was forgetting that an extra level of quoting is required 
for that use. Weren't we just saying that `VAR=foo emake` would be 
better than `emake VAR=foo`, though, to avoid screwing up packages that 
mangle those variables? And in that case I don't think it would need 
quotes.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpiK3wMnJHFS.pgp
Description: PGP signature


Re: [gentoo-dev] rfc: deprecation of baselayout-1.x

2011-07-01 Thread Donnie Berkholz
On 11:26 Fri 01 Jul , Nirbheek Chauhan wrote:
 Except for the fact that while you upgrade, you still have a usable 
 system. Reinstallation means a massive time-sink during which your 
 machine is completely unusable. This is not an option for a lot of 
 people.
 
 If -user is regularly giving that kind of advice, I think you guys are 
 making a huge mistake.
 
 I'm not going to support this kind of max-6-month-upgrade life cycle 
 for Gentoo. We're effectively driving our users away to distros like 
 Ubuntu that allow you to upgrade every LTS release instead of 
 constantly or every 6 months.

In my experience, updates become massively difficult after about 6 
months unless you have deep expertise in Gentoo. You run into blocker 
after blocker after USE-flag problem after resolution failure and an 
ongoing series of confusing messages with no apparent end in sight. We 
may call it supported (and technically, we're right) but it isn't 
realistically possible for most users.

After handing over administration of about 10 systems to someone else 
with less experience in Gentoo, I still get called in about once every 
couple of months to help every time one of these weird problems comes 
up. I recommended upgrades to the new admin every 3 months, which is a 
point where nearly everything still works cleanly.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpbxhlF9Fgwu.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: optinal run time dependencies

2011-06-28 Thread Donnie Berkholz
On 14:38 Tue 28 Jun , Peter Volkov wrote:
 1. add a use flag to control runtime dependency
 2. add elog message into pkg_postinst to notify users that some 
 features depend on installing package A, B, etc.

I've got a suggestion that builds a little bit on what both you and 
Ciaran have said.

The UI could probably be clearer if we added a new dependency type like 
SDEPEND (suggested deps) with USE flags for different features. That 
would enable portage to show things in a special way if it knew about 
SDEPEND. Yet it wouldn't do anything weird that broke backwards 
compatibility or produced strange output from noncompliant PMs (like USE 
flag modifications).

Then PMs would be free to implement their own logic for how to handle 
it. For Portage, I'd like to see a few cases:

1) If a package is installed, assume it's desired, as Ciaran proposed.

2) Add a way to determine whether to install all/none/groups of them, 
   w/ configuration in /etc/portage/package.suggestions/. Probably CPV 
   followed by the setting (all, none, specific groups, or specific 
   CPVs). Add an option similar to --autounmask that would let Portage 
   write to this file.

3) Something like the --take argument and friends that Ciaran mentioned 
   seems reasonable (perhaps --accept-suggestion, w/ a short option to 
   save typing).

Problems? Other thoughts?

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpEUroOHMuW9.pgp
Description: PGP signature


Re: [gentoo-dev] Don't use / when applying sed with CFLAGS

2011-06-27 Thread Donnie Berkholz
On 17:23 Mon 27 Jun , Lars Wendler wrote:
 Am Montag 27 Juni 2011, 17:01:01 schrieb Fabian Groffen:
  On 27-06-2011 14:08:52 +, Justin Lecher wrote:
   Please do not use / as seperater when using sed with CFLAGS. I came
   across a bug today where it failed for crossdev. Here the toolchain
   header paths in the cflags and consowuently the seds fail.
  
  Please also don't use ':' as separator, as some platforms have options
  for their toolchain that includes colons.
 
 Rather than telling us what to _not_ use as separator how about suggesting a 
 list of konwn to be good separators for such cases. How about the @ character?

One of my favorites for weird cases is ~.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpaaKjqoCZiQ.pgp
Description: PGP signature


Re: [gentoo-dev] Packages that explicitly DEPEND on sys-apps/sed

2011-06-22 Thread Donnie Berkholz
On 16:27 Tue 14 Jun , Brian Harring wrote:
 On Tue, Jun 14, 2011 at 10:08:54AM -0400, Rich Freeman wrote:
  And no, I don't think that Gentoo should fully support reduced-@system
  builds, but there is no harm in making them more of a viable option.
 
 Personally... I think gentoo should aim for it actually.  Question is 
 how close we can get to it w/out overly burdening developers.

Where this has been most useful for me is when I'm building out a 
minimal system (e.g., a diskless terminal or cluster node) using 
ROOT=/somewhere/else. It's nice to just start emerging stuff there 
instead of having to unpack a stage1 or something first.

I wonder if we need another set that's really @base (truly minimal, like 
what Mike posted elsewhere), so @system would then serve as what we 
think is necessary for a running Gentoo installation.

On a related note that would accomplish similar purposes, it would also 
be nice if we could somehow discriminate between DEPEND and RDEPEND for 
@system packages so build-only deps could be removed.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpPUQh7quVSd.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011

2011-06-08 Thread Donnie Berkholz
On 17:19 Wed 08 Jun , Paweł Hajdan, Jr. wrote:
 On 6/8/11 4:36 PM, Vikraman wrote:
  I'm working on the `Package statistics` project this year. Till now, I
  have managed to write a client and server[0] to collect the following
  information from hosts:
 
 Excellent, good luck with the idea! I think that better information
 about how Gentoo is actually used will greatly help improving it.
 
  Is there a need to collect files installed by a package ? Doesn't PFL[1]
  already provide that ?
 
 Well, PFL is not an official Gentoo project. It might be useful, but I
 wouldn't say it's a priority.

I would love to see it happen, but it's more important to roll out a 
minimal working solution now and add on later.

By combining installed files with USE flag settings, this project could 
actually attempt to factor out which USE flags result in which files in 
an automatic fashion. That would address one of the biggest objections 
many people have had to such a package-to-file search engine.

It would also be pretty useful for some other GSoC projects, like the 
ebuild generator and the auto dependency scanner.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgp99ZuhwbiGQ.pgp
Description: PGP signature


Re: [gentoo-dev] Re: RFC: an eclass for github snapshots?

2011-06-07 Thread Donnie Berkholz
On 13:21 Mon 30 May , Ulrich Mueller wrote:
  On Mon, 30 May 2011, Diego Elio Pettenò wrote:
  Il giorno lun, 30/05/2011 alle 08.27 +0200, Michał Górny ha scritto:
  S=${WORKDIR}/solutious-${PN}-*
  
  I'm surprised if that actually works. I'd say that seems not
  PMS-compliant but in fact PMS seems to almost not mention S. 
 
  Because you didn't follow the whole eclass tree ;)
 
  ruby-ng handles the star as a special case, given how many of those
  we had to use over time, [...]
 
 But it is not compliant with PMS:
 If S is assigned in the global scope of an ebuild, then the
 restrictions of section 12.2 for global variables apply. (section 12.1)
 Global variables must only contain invariant values. (section 12.2)

It seems compliant to me, as S is assigned an invariant value that 
happens to contain the character '*', which is overwritten with a new 
value as a local variable in ebuild functions. Sample code in listing 
12.1 in my copy of the PMS seems to suggest this is perfectly fine 
behavior as long as the global invariant is restored after each 
function.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpm4QVAvdoo9.pgp
Description: PGP signature


[gentoo-dev] Web-design help request

2011-05-03 Thread Donnie Berkholz
Hi all,

If anyone with web-design skills could help out on some improvements to 
our website, please get in touch with me off-list or on IRC in
#gentoo-pr.

One of this year's GSoC students (tampakrap) will be rewriting a bunch 
of the backend website code, which is a great opportunity for us to also 
fix some of the frontend usability issues.

-- 
Thanks,
Donnie

Donnie Berkholz
Team lead, public relations
Gentoo Linux
Blog: http://dberkholz.com


pgpfcuG38Min8.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: 24 hour review for = dev-libs/glib-2.28 stable news item

2011-04-27 Thread Donnie Berkholz
On 15:05 Wed 27 Apr , Samuli Suominen wrote:
 The way of setting default URI handlers has changed since 
 dev-libs/glib-2.28 and above. If you used the GConf registry to set 
 them before, they will now be ignored.

Do you think all our users will even understand what this means? Can you 
provide a more plain-English explanation, and give specific examples? 
For example:

The method for setting default applications for specific URI types 
(https://, mailto://, etc.) changed in dev-libs/glib-2.28 and newer. If 
you previously set them in GConf using the Configuration Editor, they 
will now be ignored.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpLMYrMOIz33.pgp
Description: PGP signature


Re: [gentoo-dev] openrc portage news item

2011-04-20 Thread Donnie Berkholz
On 13:32 Thu 14 Apr , Kfir Lavi wrote:
 When i run world update, I usually don't really check all the written 
 stuff.
 
 If I do this, I'm sure a lot more Gentoo users do the same. So do 
 expect people rebooting the machine without checking what your have 
 wrote. This can be a major headache if you have few systems that are 
 doing auto updates. I would solve this issue by stopping the emerge 
 and getting the attention of the user. If I don't get the attention of 
 the user, no openrc will be installed. It should be something like 
 emerge -C ... 1 .2 3 4 5...
 
 To conclude, you can't issue such a change without proper confirmation from
 the user.

I know this is the case. You're going to get literally thousands of 
people (or more) who break their Gentoo systems if that indeed is the 
consequence of not reading the migration guide and doing some action. 

From a glance over the guide, it wasn't immediately obvious what in 
there would result in a broken system. Perhaps it's the run 
dispatch-conf that's buried in the middle of a paragraph without enough 
emphasis? That's particularly confusing for people who use etc-update 
instead, and it *needs* to move somewhere more obvious like a separate 
code listing with big important tags and bold text. The line of red 
text just isn't enough, it needs to stand out even more.

It seems like nobody's really clear on what exactly happens though, 
since I've seen people talking about this *maybe* resulting in an 
unbootable system. Has anyone tested it?

One potential cleaner approach to the same idea Kfir suggested is to 
make it an interactive emerge with an ACCEPT_LICENSE-like feature that 
pops up something you must read and agree to.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpNuizXUZtxY.pgp
Description: PGP signature


Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)

2011-04-18 Thread Donnie Berkholz
On 06:29 Sat 16 Apr , Corentin Chary wrote:
 New website is up and running at
 
 http://euscan.iksaif.net/
 
 The git tree is still at http://git.iksaif.net/?p=euscan.git;a=summary
 
 TODO:
 - Make some charts to see how it's going
 - Finish the scan my world feature
 - Add a way to subsribe to herds/maintainer/packages in order to
 receive weekly/monthly reports
 
 I'll gladly accept any patch ! :)

This is cool! I just looked through the x11-team packages and it seems 
very useful already. I have a few suggestions if you have time. =)

- Some teams have official overlays. Supporting those as an additional 
  source of ebuilds would be pretty nice.

- Another useful thing would be a way to supply CPV tokens for any 
  unstable upstream series that we'll never add to the tree.

- This looks like a problem (a versioned tarball named cairo-5c):
  http://euscan.iksaif.net/package/x11-libs/cairo/


-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpKu9VoK0Qtd.pgp
Description: PGP signature


Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)

2011-04-18 Thread Donnie Berkholz
On 15:48 Mon 18 Apr , Corentin Chary wrote:
 On Mon, Apr 18, 2011 at 3:32 PM, Donnie Berkholz dberkh...@gentoo.org wrote:
  - Some teams have official overlays. Supporting those as an additional
   source of ebuilds would be pretty nice.
 
 I'll just checkout these trees on my machine (and only enable them for 
 euscan).
 euscan use portage, gentoolkit and eix internaly, so overlays are not
 a problem :).
 
 Where could I get a list of official overlays that should be added ?

It will be a little tricky to get this perfect automatically. I would 
start with anything in the layman repository file [1] that has repo ... 
status=official and owner type=project.


1. 
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/overlays/repositories.xml?view=log

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgp6LKmU7A8XS.pgp
Description: PGP signature


Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)

2011-04-18 Thread Donnie Berkholz
On 15:48 Mon 18 Apr , Corentin Chary wrote:
 On Mon, Apr 18, 2011 at 3:32 PM, Donnie Berkholz dberkh...@gentoo.org wrote:
  - Another useful thing would be a way to supply CPV tokens for any
   unstable upstream series that we'll never add to the tree.
 
 There is already some kind of blacklist in euscan. Could you provide
 examples so I can implement that ?

Sorry, forgot about this bit. I'm just talking about standard package 
tokens, the same kind used in package.mask or wherever:

=x11-drivers/xf86-video-intel-2.14.90*
=x11-base/xorg-server-1.10.900

etc.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgplh0Kf14xcm.pgp
Description: PGP signature


Re: [gentoo-dev] openrc-0.8.1 stable candidate

2011-04-13 Thread Donnie Berkholz
On 13:44 Wed 13 Apr , Marijn wrote:
 I would be very interested in seeing some kind of list/review of all 
 the advantages of the new system. Idea for the Newsletter?

We should certainly get a news item together, since this is a huge deal 
for Gentoo. Although no doubt non-Gentoo people will start laughing at 
yet another new init system. =)

If there's a guide around already, or a blog post, or you want to draft 
something, let me know and I'd be happy to polish it up.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpWOkaWzEnHI.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

2011-03-27 Thread Donnie Berkholz
On 02:39 Mon 28 Mar , Nirbheek Chauhan wrote:
 Where did this come from? My entire argument was based around the fact
 that unmaintained packages that may or may not be broken fundamentally
 constitute a *bad* experience for the user. If we cannot guarantee
 that bugs for a package will be fixed, we should not take up the
 responsibility of the package!
 
 Which is worse? Suddenly pulling a package from underneath the feet of
 users when it inevitably breaks or telling them upfront that it's
 *completely not* supported by us so they can do something about it
 before it breaks?

Here's the key point: may or may not. Arbitrary criteria with no 
relevance to whether a package works for users are not helpful.

The mere existence of a maintainer-needed package doesn't mean it should 
be removed. The existence of the same thing with numerous serious, 
unfixed bugs or tinderbox errors means something much different.

We have the ability to do these kinds of intersections today, since our 
wonderful bug wranglers normally insert the $CAT/$PN into summaries and 
Diego has tinderbox bugs filed.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpjZzeJgz4hc.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

2011-03-27 Thread Donnie Berkholz
On 17:34 Sun 27 Mar , Ryan Hill wrote:
 On Mon, 28 Mar 2011 02:55:14 +0530
 Nirbheek Chauhan nirbh...@gentoo.org wrote:
  If we launch gstats *today*, it'll take us at least a long time before
  we get decent numbers, and even after that, those numbers will be
  biased towards those people who are really active in following Gentoo
  news and developments. Unlike Firefox's usage stats, we have no way of
  prompting pre-existing gentoo installations with a Do want to take
  part in gstats? question.
 
 Last I checked we had a nifty news system for making announcements.  And I
 thought we were supposed to have Smolt support like two years ago.  What
 happened to it?

I wonder the same question too, since it seems statistics is an 
eternally returning GSoC project.

Sebastian, you worked on this in 2009. What needs to happen to get it 
deployed?

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpxww8cShQhy.pgp
Description: PGP signature


Re: [gentoo-dev] mono.eclass EAPI3(/4)

2011-03-25 Thread Donnie Berkholz
On 23:48 Thu 24 Mar , Christoph Mende wrote:
 Index: mono.eclass
 ===
 RCS file: /var/cvsroot/gentoo-x86/eclass/mono.eclass,v
 retrieving revision 1.13
 diff -u -b -B -r1.13 mono.eclass
 --- mono.eclass   8 Mar 2009 15:46:54 -   1.13
 +++ mono.eclass   24 Mar 2011 22:47:08 -
 @@ -35,24 +35,26 @@
  unset MONO_AOT_CACHE
  
  egacinstall() {
 + [[ -z ${ED+set} ]]  local ED=${D%/}${EPREFIX}/
   gacutil -i ${1} \
 - -root ${D}/usr/$(get_libdir) \
 + -root ${ED}/usr/$(get_libdir) \
   -gacdir /usr/$(get_libdir) \
   -package ${2:-${GACPN:-${PN}}} \
   || die installing ${1} into the Global Assembly Cache failed
  }
  
  mono_multilib_comply() {
 + [[ -z ${ED+set} ]]  local ED=${D%/}${EPREFIX}/
   local dir finddirs=() mv_command=${mv_command:-mv}
 - if [[ -d ${D}/usr/lib  $(get_libdir) != lib ]]
 + if [[ -d ${ED}/usr/lib  $(get_libdir) != lib ]]

No need for quotes when expanding variables or functions inside [[ ]]. 
That holds true for the rest of the diff, too. I'd also split this (and 
a later find call) into two separate conditionals, with just one test 
per [[ ]].

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgp15BGErOV6U.pgp
Description: PGP signature


Re: [gentoo-dev] Re: git-2.eclass final review

2011-03-24 Thread Donnie Berkholz
On 10:44 Wed 23 Mar , James Cloos wrote:
 TC So live with it.
 
 I cannot.  It makes the eclass useless.
 
 I have almost 2 gigs of bare repo in distdirs/git-src.  
 
 A forced re-download of all of that is just not possible!
 
 The existing distdir clones *MUST* continue to work.
 
 My applogies for not having looked for this kind of breakage in the new
 eclass before now.  The current git eclass finally got the submodules-
 vs-normal stuff worked out some time ago; the possibility of going
 backwards never occurred to me ☹
 
 As someone who makes heavy use of live ebuilds, someone who will be
 directly and severely affected by such a change, I have to beg you
 to keep the current logic for submodule-less repos.

I was discussing a couple of ideas on IRC with scarabeus yesterday but 
haven't had a chance to look into them in more detail yet:

- Providing automatic migration from the old system to the new. This is 
the simplest approach to deal with your specific problem but still 
leaves separate codepaths for submodule and non-submodule repos.

- Handling submodules in bare checkouts. Perhaps we could detect whether 
submodules are in use (need to find the right place/way in git), then 
grab them as separate bare checkouts that would eventually be cloned 
into TMPDIR by changing the repo location git looks for (again, need to 
sort out how in git).

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpQLdlUg2rXh.pgp
Description: PGP signature


Re: [gentoo-dev] virtual/ffmpeg and media-video/libav

2011-03-23 Thread Donnie Berkholz
On 11:10 Wed 23 Mar , Mike Frysinger wrote:
 On Wed, Mar 23, 2011 at 11:01 AM, Jeremy Olexa wrote:
  When reading about the fork awhile back, I assumed that ffmpeg would die
  and libav would continue in its place. Do we really need a virtual for
  this??
 
 might as well hedge our bets.  it'd really suck if we threw all our
 eggs into libav just to have to crash, or for it to move back to
 ffmpeg.

Indeed, this is the same thing we did back in the XFree86/X.Org split. I 
think x11-base/xfree stuck around for another year or so before we 
decided it was definitely a zombie and burned it to a crisp.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpKRB5nyAlw6.pgp
Description: PGP signature


Re: [gentoo-dev] Re: git-2.eclass final review

2011-03-23 Thread Donnie Berkholz
On 08:28 Wed 23 Mar , James Cloos wrote:
  MF == Mike Frysinger vap...@gentoo.org writes:
 
 MF ideally, the git eclass should be creating bare checkouts only in its
 MF store dir, in which case it could use `git archive | tar` to move
 MF things over ...
 
 Or better yet, git clone.

This could work well with --shared; even worked for me on separate 
partitions.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpXPp3orTeuv.pgp
Description: PGP signature


Re: [gentoo-dev] Eclass review: xorg-2 virtualx

2011-03-23 Thread Donnie Berkholz
On 00:18 Tue 22 Feb , Tomáš Chvátal wrote:
 + if grep -q -s disable-all-encodings 
 ${ECONF_SOURCE:-.}/configure; then
 + FONT_OPTIONS+=
 + --disable-all-encodings
 + else
 + FONT_OPTIONS+=
 + --disable-iso8859-2
 + --disable-iso8859-3
 + --disable-iso8859-4
 + --disable-iso8859-5
 + --disable-iso8859-6
 + --disable-iso8859-7
 + --disable-iso8859-8
 + --disable-iso8859-9
 + --disable-iso8859-10
 + --disable-iso8859-11
 + --disable-iso8859-12
 + --disable-iso8859-13
 + --disable-iso8859-14
 + --disable-iso8859-15
 + --disable-iso8859-16
 + --disable-jisx0201
 + --disable-koi8-r
 + fi

Any chance we can just clean out the fonts that still use the old way 
and delete most of this?

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpV233MzoVf4.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Quantity of open bugs

2011-03-12 Thread Donnie Berkholz
On 15:45 Sat 12 Mar , Diego Elio Pettenò wrote:
 I actually use the fact that these are still open to judge whether a
 package has to be removed from the tree, closing them would definitely
 be a bad idea for two reasons:

I'm assuming you're talking only about broken builds here and not 
QA-only bugs. My opinion is that if a tinderbox QA script is the only 
thing finding a nonfatal bug, and it's never reported or CC'd by a user, 
then it's about as low priority as you can get.

So this might serve as a pointer to potentially unmaintained packages, 
but clearly more investigation is required before removal.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpXlUAj6ZLsw.pgp
Description: PGP signature


Re: [gentoo-dev] Bugzilla 4 migration

2011-03-08 Thread Donnie Berkholz
On 07:50 Tue 08 Mar , Hans de Graaff wrote:
 On Mon, 2011-03-07 at 08:13 -0600, Donnie Berkholz wrote:
 
  Thanks! One thing I've been very interested about in 3.x and 4.x is API 
  access that's better than screen-scraping. I tried using the 
  python-bugzilla client that accesses Bugzilla via XML-RPC but it didn't 
  seem to work. Do we have anything available?
 
 I've tried an ipad application that uses xmlrpc and that seemed to work
 fine.

Confirmed with my iphone one. Guess the Python one's broken with BZ 4. 
Fiddling around manually with xmlrpclib works alright, too.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpN0Hq8SDQ9s.pgp
Description: PGP signature


Re: [gentoo-dev] Bugzilla 4 migration

2011-03-07 Thread Donnie Berkholz
On 09:51 Mon 07 Mar , Robin H. Johnson wrote:
 The Gentoo for the Bugzilla service went perfectly, a huge thanks to
 idl0r for the years of work he has put into them.

Thanks! One thing I've been very interested about in 3.x and 4.x is API 
access that's better than screen-scraping. I tried using the 
python-bugzilla client that accesses Bugzilla via XML-RPC but it didn't 
seem to work. Do we have anything available?

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpThu2dFRGyd.pgp
Description: PGP signature


Re: [gentoo-dev] Bugzilla 4 migration

2011-03-07 Thread Donnie Berkholz
On 16:35 Mon 07 Mar , Dirkjan Ochtman wrote:
 On Mon, Mar 7, 2011 at 15:13, Donnie Berkholz dberkh...@gentoo.org wrote:
  Thanks! One thing I've been very interested about in 3.x and 4.x is API
  access that's better than screen-scraping. I tried using the
  python-bugzilla client that accesses Bugzilla via XML-RPC but it didn't
  seem to work. Do we have anything available?
 
 Is that the one you get if you emerge pybugz?

No, pybugz is a screen-scraper. We previously had Bugzilla 2 so we 
couldn't do anything else.

 The Mozilla guys made a pretty nice REST API that can be installed as a
 plugin, I think. Maybe we could run that?

I've been somewhat following that too, but I don't know if anyone's 
written a CLI client for it yet, whereas python-bugzilla already exists 
(and has an ebuild in the sabayon overlay).

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpXcCnIenCNR.pgp
Description: PGP signature


Re: [gentoo-dev] Rewrite java-config in C++ or python

2011-02-27 Thread Donnie Berkholz
On 20:40 Sat 26 Feb , Petteri Räty wrote:
 On 02/26/2011 07:08 PM, Daniel Pielmeier wrote:
  2011/2/21 Uditha Galgamuwa nandun8...@gmail.com:
  Hi dev,
 I am Uditha Galgamuwa from university of moratuwa,Sri Lanka.I am
  interested in the project idea Rewrite java-config in C++ or python which
  was in last year Gsoc.As I saw this project has not been implemented in 
  Gsoc
  2010.Will this be available for this year's idea list from Gentoo
  foundation? I have good knowledge on programming with java and some
  knowledge on C++  and a basic understanding about XSLT as well.
  
  It is on the list for 2011 (1), so I guess you can apply for it.
  
  (1) http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2011_ideas
  
 
 The list started out with a copy of ideas from last year that were not
 finished successfully.

That is partially correct but incomplete. Many of them were never even 
started — just a few were started but not finished. (We had 3 out of 19 
students fail, which is about the same level as the broader GSoC 
program).

 This means no-one might be interested in mentoring for the projects 
 listed there this year. It should also be remembered that you don't 
 need to restrict yourself to the ideas presented there. For any 
 further discussion I suggest reading the Read this first section and 
 noticing that there is a gentoo-soc mailing list.

Indeed, please do join the mailing list!

We strongly encourage novel ideas beyond what's on the ideas list, but 
make sure to discuss them in advance of applying so you find a mentor.

--
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgphB5rIWJQox.pgp
Description: PGP signature


  1   2   3   4   5   6   7   8   9   10   >