Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog

2012-05-10 Thread Jim Ramsay
On Wed, May 02, 2012 at 11:23:48AM -0400, Matt Turner wrote:
 Jim?

Sorry, I am behind on my gentoo-dev reading, thanks Matt for bringing
this thread to my attention.  Here are the two main concerns I've
gathered from the rest of the thread:

On Wed, Apr 25, 2012 at 11:04:08PM -0600, Ryan Hill wrote:
 Arg, no.  Please just print the warning if the host doesn't do SSE2.
 There's no reason to have a USE flag here (and _really_ no reason to
 make it fatal), especially for an instruction set that every system
 has supported for over a decade.

It's true that probably most people have sse2.  And this change won't
affect all those people that have sse2.  It only affects people that
don't have sse2.

The run-time failure case (flash just doesn't work) is tricky to
diagnose, so I want the user to be aware of this at install time.  Thus
I feel the check should (1) be fatal and (2) provide instructions that
10.3 can still be used.

The reason there's a USE flag is so that binary packagers can forcibly
skip the 'die' if they know they're building for an sse2 SYSTEM.  This
is only needed if you're running on a machine without sse2, packaging for
a machine with sse2.

On Thu, Apr 26, 2012 at 05:06:45PM -0300, Alexis Ballier wrote:
 wouldnt adding a sse2 useflag and putting it in REQUIRED_USE solve the
 problem ?
 
 afaik portage wont even try to upgrade if people have -sse2

This is an interesting idea, as it could automatically downgrade users to
10.3 without requiring any masking.  I like that.

However, the problem I have with this approach is that it doesn't
address people who do have sse2 instructions available but have not set
the USE flag.  I noticed that our amd64 profile does set USE=sse2
automatically.  That's good.  But x86 users would still have to set this
manually.  And people without the flag will be forcibly downgraded to
10.3 for no good reason.  And as Ryan accurately points out, most people
*do* have sse2 instructions available.

I prefer checking /proc/cpuinfo because that way I'm *sure* that the
user's system has the required instruction set.

The only way I think that this decision can really be made would be to
have some sort of usage statistics on how many x86 setups there are
where the CPU has sse2 available but the user has not set USE=sse2.  Any
idea how we can know how many this is?

Hmmm... I suppose the other thing I could do is put the /proc/cpuinfo
check into the 10.3 ebuild, and warn users if they're installing 10.3
and *should* be setting USE=sse2 to get 11.2 instead Maybe that's the
best solution!

Thanks for the suggestions, I'll try to get at this change soon.

-- 
Jim Ramsay



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog

2012-05-10 Thread Jim Ramsay
On Thu, May 10, 2012 at 01:10:48PM -0400, Jim Ramsay wrote:
 On Thu, Apr 26, 2012 at 05:06:45PM -0300, Alexis Ballier wrote:
  wouldnt adding a sse2 useflag and putting it in REQUIRED_USE solve the
  problem ?
  
  afaik portage wont even try to upgrade if people have -sse2
 
 This is an interesting idea, as it could automatically downgrade users to
 10.3 without requiring any masking.  I like that.

Hmmm... After some testing, I don't think this is how it works.

It looks to me like if I try to do an upgrade on a system that has
USE=-sse2, it doesn't downgrade automatically.  Nor does it simply skip
the upgrade.  At least with portage 2.1.10.57, I get the following fatal
output:

---
# USE=-sse2 emerge -uDN world -p
...

!!! Problem resolving dependencies for www-plugins/adobe-flash from
@selected ... done!

!!! The ebuild selected to satisfy www-plugins/adobe-flash has unmet
requirements.
- www-plugins/adobe-flash-11.2.202.235::local USE=64bit (multilib)
  -32bit -kde -sse2 -vdpau

The following REQUIRED_USE flag constraints are unsatisfied:
sse2

(dependency required by @selected [set])
(dependency required by @world [argument])
---

So in light of this, I think I'm going to keep the fatal pkg_pretend
with /proc/cpuinfo check in the 11.2 ebuild, since that's the only way I
can do the check in a way that meets my 3 requirements:
 - No annoyance for users who have sse2 instructions present
 - runs at install time in a non-ignorable (fatal) way
 - provides useful downgrade instructions to the user

Too bad pkg_pretend doesn't fire during 'emerge -p' - That would be
even better.

Any other suggestions on how I can make this work better?

-- 
Jim Ramsay



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: vim.eclass

2011-11-28 Thread Jim Ramsay
Samuli Suominen wrote:
 eclass has ChangeLog file now.   any particular reason why you skipped it?

Completely oblivious to its existence, that's all :)  I'll
(hopefully) remember it next time.

 or is it not meant to be used yet / not mandatory to use yet? since most
 people seem to skip it.

In my case it was entirely ignorance, and with no statistical
evidence to base my assertion I'll say that most other omissions
come from the same cause.

Though on the other hand you could argue that a Changelog for all
eclasses may be a bit overkill.  Most eclasses are not related to
one another, so reading the CVS history of the changes to a
single file is much more useful than having a big list of
unrelated changes.  A changelog becomes much more useful when
you need to make related commits to multiple files with a
non-atomic-commit system like CVS.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox/fluxbox/gkrellm)



Re: [gentoo-dev] Re: rejecting unsigned commits

2011-05-10 Thread Jim Ramsay
On Tue, May 10, 2011 at 08:19:27AM +0200, Paweł Hajdan, Jr. wrote:
 On 5/10/11 4:08 AM, Jim Ramsay wrote:
  - Does this tree signing key have to be DSA?  Or is RSA okay too?
 
 No idea, I'd probably just try and see if signing works.

/me plugs his ears and presses GO...

Looks like it works fine!

  - If I have a key already, should I generate a new subkey just
for manifest signing, make a whole new primary key, or just use
the same key I use to sign my emails?
 
 See
 http://archives.gentoo.org/gentoo-dev/msg_bdc24ba33036ef413e620dc94532e080.xml,
 I think no separate key should be needed.

You know, I even remember reading this email, but focused more on
the SSL Cert recommendation part than immediate answer.  Thanks :)

-- 
Jim Ramsay



Re: [gentoo-dev] Re: rejecting unsigned commits

2011-05-09 Thread Jim Ramsay
On Fri, Mar 25, 2011 at 02:30:20PM -0400, Mike Frysinger wrote:
 for people who dont have a key yet:
 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=6

I'm pretty new to advanced gpg usage and management, and so had a
couple questions not answered by that page:

- Does this tree signing key have to be DSA?  Or is RSA okay too?

- If I have a key already, should I generate a new subkey just
  for manifest signing, make a whole new primary key, or just use
  the same key I use to sign my emails?

-- 
Jim Ramsay



[gentoo-dev] Lastrite: x11-plugins/gkrellm-hddtemp

2010-07-27 Thread Jim Ramsay
No longer works (Bug #284182), and no longer needed since
app-admin/gkrellm with USE=hddtemp supports reading drive
temperatures natively.

Removal in 30 days.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


[gentoo-dev] Lastrite: net-misc/amazonmp3

2010-07-26 Thread Jim Ramsay
# Jim Ramsay l...@gentoo.org (26 Jul 2010)
# Deprecated in favour of opensource alternatives:
#   net-misc/pymazon
#   net-misc/clamz
#
# net-misc/amazonmp3 has been masked since 2008
# Removal 30 Jul 2010
net-misc/amazonmp3
net-misc/amazonmp3-libcompat

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Over using preserve_old_lib, don't do that

2010-07-19 Thread Jim Ramsay
On Thu, Jul 15, 2010 at 07:28:40PM +0200, Markus Hauschild wrote:
 On Thu, Jul 15, 2010 at 10:49 AM, Mike Auty ike...@gentoo.org wrote:
  Ideally, these calls should either adhere to FEATURES=-preserve-libs,
  or there should be a tool that can identify which files portage has
  preserved, and allow easy rebuilding of dependent packages, and removal.
   At the moment, I'm having to manually grep ebuilds, ls the libraries
  and run revdep-rebuild over them one at a time...
 
 Such a tool which can at least identify files that remain on the
 system from preserved-libs or similar would be really useful in my
 opinion!

What if preserve_old_libs did the following:

  mv ${oldlib} ${oldlib}.preserved
  ln -s ${oldlib}.preserved ${oldlib}

Cons: 2 files to delete once you're done revdep-rebuilding

Pros: Easy to tell at a glance which libs are the preserved libs.

-- 
Jim Ramsay



Re: [gentoo-dev] Adding AdobeFlash-10{,.1} licenses to EULA group

2010-06-16 Thread Jim Ramsay
Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote:
 I propose that this license be added to the EULA group. The previous 
 AdobeFlash-10 license is similar in this regard, and could possibly
 also be added to that group.

Agreed, on both points, and done.  Thanks for finding and airing this
issue!

 One notable section is 7.6 in which Adobe reserves the right to
 download and install additional Content Protection software on the
 user's PC.

Not like anyone will actually *read* the license before adding it to
their accept group, but if they did this would indeed be an important
thing of which users should be aware.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


Re: [gentoo-dev] app-editors/vim and USE=vim-with-x - Rename to USE=X?

2010-06-09 Thread Jim Ramsay
Mike Frysinger vap...@gentoo.org wrote:
 people want it and i havent seen any compelling reason to avoid it
 anymore, so let's rock

For the record: It is now rocked.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


[gentoo-dev] app-editors/vim and USE=vim-with-x - Rename to USE=X?

2010-06-07 Thread Jim Ramsay
There is an ancient bug[1] dealing with the vim-with-x USE flag.

I think it makes sense to rename this flag from 'vim-with-x' to just
'X', but thought I'd raise the issue here since this USE flag has been
around since before time began.

Does anyone care?

References:
[1] http://bugs.gentoo.org/94171

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


Re: [gentoo-dev] app-editors/vim and USE=vim-with-x - Rename to USE=X?

2010-06-07 Thread Jim Ramsay
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
 On Mon, 7 Jun 2010 23:05:27 +0400
 dev-ran...@mail.ru wrote:
  On Mon, Jun 07, 2010 at 07:53:22PM +0100, Ciaran McCreesh wrote:
   It's there because if you break your X you probably want a usable
   editor to help you fix it.
  
  vim, compiled with vim-with-x works correctly when X is broken. It
  doesn't enable X11-based UI, like flag X suggests. It just enables
  optional connection to x-server to use its clipboard, and vim still
  works if that connection fails.
 
 It does not, however, work if your X libraries are broken.

I certainly agree with you that removing the linkage to a handful of X
libraries makes vim more robust if those particular libraries fail.

However even with USE=-vim-with-x, there are a number of other
libraries that, if broken, will still render vim useless, such as
ncurses, perl, python, and ruby.

I suspect if one really wants a fail-proof editor, one would either
be building vim with USE=minimal which will ignore the 'vim-with-x'
or 'X' USE flag (regardless of what we call it) and also ignore any
perl/python/ruby libraries, or one would want something more
trim, like busybox vi. Or even better yet, busybox vi with USE=static.

Of course changing the USE flag name to 'X' would still let users
decide to *not* link their app-editors/vim against any X libraries via
per-package USE flags.  The main difference in changing the name from
'vim-with-x' to 'X' is that instead of enforcing a default behaviour of
Vim will not link against X unless explicitly told to do so, we will
be enforcing a policy of Vim will link against X when USE='X'.

I suppose this is a bit like a transition from an opt-in policy to an
opt-out policy, with the caveat that by enabling USE=X globally, a user
has already declared their intent: opt-in to linking against X
in all packages where there is a choice to do so.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

2010-05-02 Thread Jim Ramsay
Peter Volkov wrote:
 ?? ??, 13/04/2010 ?? 17:18 +0530, Nirbheek Chauhan ??:
  The traditional ChangeLog that is currently employed in gentoo-x86
  (and in other projects) is simply an ugly hack 
 
 The difference between gentoo-x86 ebuild ChangeLogs and ChangeLogs used
 in other projects is

I think another very important distinction (that you imply below,
but I want to specifically point out here) is that we have *many*
per-project ChangeLogs whereas most other projects have a
*single* monolithic ChangeLog.

  Think of it like this: if you make a typo in a commit message, or
  forget to add something; you can't change it after you've published
  the commit (cvs/svn commit or git push) to the world.
 
 And then it's better to keep ChangeLogs. For developers it was never a
 problem to script `echangelog log  repoman commit -m log` and
 conflict resolution is really not that hard with git. In spirit of
 Gentoo, it's better to write some tool to update Manifests after
 conflict resolution instead of making ChangeLogs less useful for those
 who uses them.

This is a very good point regarding ease of conflict resolution.

Further to my other point above, the traditional ChangeLog
ugliness really only hits you with a centralized setup+git if
*everyone* is editing the *same* ChangeLog: If every commit
touches the same file in the same place (ie, prepending to a
ChangeLog file in the same location), you are guaranteed to have
collisions every time you pull a new version of the file.  This
is why most projects with a single monolithic changelog
auto-generate them, or perhaps just craft them at release time.

Our case, though it is a centralized repository model, is quite
different.  The chance of collisions in a package-specific
ChangeLog is, as it is today with CVS, pretty unlikely.  In fact,
I think the only time it usually happens to me is when an arch
stabilizes my package while I'm making a change, and these are
very easy to fix.

(In fact, it may be possible to help git out with this specific
ChangeLog situation by using a custom merge driver, see
GITATTRIBUTES(5) for details, though deployment of a custom merge
driver can be tricky)

 BTW as for profiles ChangeLogs... May be it's better to generate them.

That's another important distinction and probably a good idea.  I
think those profile ChangeLogs are also not as user-facing as the
per-package ones, so an autogenerated one makes a lot of sense.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox/fluxbox/gkrellm)


pgpnnsBkS27K2.pgp
Description: PGP signature


Re: [gentoo-dev] 2009 Council Elections

2009-06-26 Thread Jim Ramsay
Richard Freeman ri...@gentoo.org wrote:

 I suspect most devs just avoid the drama.

++

Less worrying, more working

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


Re: [gentoo-dev] net-www category

2009-04-03 Thread Jim Ramsay
Ulrich Mueller u...@gentoo.org wrote:
 Another question is if the existing ones should still be moved to
 some www-* category?

Should?  I have no idea.  Where exactly would we move these packages?
The quasi-more-usefully-named www-misc?

Though I seriously have no objection to either keeping things where
they are or moving them around.  My only request is that if someone does
this I'd like to take the opportunity to rename 'netscape-flash' to
'adobe-flash' at the same time.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: RFC: EAPI cheat sheet for your desktop

2009-04-02 Thread Jim Ramsay
Christian Faulhammer fa...@gentoo.org wrote:
 Ulrich Mueller u...@gentoo.org:
   On Tue, 31 Mar 2009, Christian Faulhammer wrote:
   Have a look at URL:http://v-li.de/temp/eapi_cheatsheet.pdf,
   print it, fold it and tell me if you like or not (and especially
   what exactly).
  
  The Gentoo store should have a coffee mug with this. ;-)
 
  That way my business plan to finally benefit financially from Gentoo.
 Millions of copies sold for sure. :)

Especially if I have to buy a new mug every time a new EAPI comes out!

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-25 Thread Jim Ramsay
Petteri Räty betelge...@gentoo.org wrote:
 2) EAPI in file extension
   - Allows changing global scope and the internal format of the ebuild
   a) .ebuild-eapi
 - ignored by current Portage
   c) .eapi.new extension
 - ignored by current Portage

Any of the above are fine with me, there is a demonstrated need for
this to introduce changes that current portage could not handle.

 3) EAPI in locked down place in the ebuild
   - Allows changing global scope
   - EAPI can't be changed in an existing ebuild so the PM can trust
 the value in the cache
   - Does not allow changing versioning rules unless version becomes a
 normal metadata variable
 * Needs more accesses to cache as now you don't have to load older
   versions if the latest is not masked
   a) new extension

3.a is just like glep-55, except that the filename extension doesn't
change all the time.  I like that this will have the benefits of
glep-55 plus the benefits of making happy the people who don't want the
EAPI in the filename or the extension to change very often.

This will effectively change a single EAPI number into a major/minor
pair.  The major part (the extension name) would only ever change when
a major feature is introduced that breaks the current portage rules.
The internal EAPI, specified however we like in the major format
specification, could be in a fixed location or otherwise easily
parseable.  Then small changes would alter this minor/internal EAPI
value.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)



Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Jim Ramsay
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
 On Tue, 24 Feb 2009 12:25:27 -0500
 Jim Ramsay l...@gentoo.org wrote:
   ...and it means we can't change name or version rules.
   
   ...and it means over doubling the best possible time to work out a
   dependency tree in the common case where the metadata cache is
   valid.
   
   ...and it means we can't make arbitrary format changes.
  
  Those would all land in the category of backwards compatibility
  mentioned below, as they would all break current sourcing rules.
 
 No, they're also future issues. Without glep 55, every time they come
 up we have to go through the whole mess again.

This minor/major EAPI scheme is exactly equivalent to glep 55 in
the ways that it addresses the non-implementation-specific
details - It could even be added as a caveat to glep-55 that says
something like:

You should not change filename extension (ie, major-EAPI version, or
EPARSE version, or whatever we want to call it...) except when you *have
to* because of changes such as name or version rules, arbitrary format
changes, or anything else that breaks the sourcing rules of the
existing filename extensions. Simpler feature improvements can be done
using whatever internal minor-EAPI version is defined by the major-EAPI
version.

This doesn't prevent you from changing the filename extension when you
have to do so, it just suggests that maybe you don't have to do it for
every single feature-set you may want to implement.

   Developers already have to stop and think and consult the
   conveniently available table of features for EAPIs. By splitting
   the EAPI concept in two you're doubling the amount of data to be
   learnt.
   
  I would think that this is a very small cost, and the benefit would
  be (I hope) that more people would agree on the solution and then
  we can go forward. Is that not a valid consideration?
 
 I'd expect to see changes that would warrant a major bump in every
 other EAPI or so anyway, so it's not really worth the complexity.

If that is indeed the case, then adding this caveat to glep-55 is
basically a nop.  If every EAPI includes a non-backwards-compatible
change that breaks existing PMs, the filename extension will be changed
every time.

But when you say worth the complexity, I'm not exactly sure what
your standards of worthiness are.

I don't think the human cognition of a 2-level versioning scheme is
that tricky, so I assume you must mean complexity in the internals of
package managers - but this should just be a Simple Matter Of
Programming.

I'll further qualify this response by mentioning that I am not a package
manager maintainer.  I don't know beans about metadata and cacheing and
what the tradeoffs may be between a two-level EAPI and a single-level
EAPI stored in the filename.  I understand that parsing two-level EAPI
is more expensive than a single-level stored in the filename.  I don't
however know how to figure out if it is too expensive, or whose
subjective scale we should use to measure this.

I personally feel the complexity that you say is too costly is a fair
tradeoff for a proposal that people will accept.

(Of course I have no idea if people actually would accept a two-level
EAPI any more than glep-55 as-is... I just think it addresses the
concerns I've heard in this thread in a way that does not break
the valid solutions to real problems presented in glep-55)

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Jim Ramsay
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
 People are struggling with the one level scheme we have now. We're
 already having to produce fancy tables and summaries for new EAPIs
 because people can't keep track of when features came along. Two
 levels just means no-one will remember any of it.

I disagree with your assertion that people are struggling - I think
things are very nicely documented in PMS and the devmanual, which are
where all EAPI changes should be documented in the future, regardless
if you specify the EAPI in the file, the extension, or both.

Two levels really just means that any fancy tables will have to have
one extra row (or perhaps a series of fancy tables) and any summaries
will have to have an extra section added whenever a new filename
extension becomes necessary.

 For the package manager, it's just a bit of added mess, not any major
 difficulty.

This is good to know, thank you for the clarification.

 People are opposed to 55 because of a knee-jerk reaction against
 changing file extensions and against doing anything that comes from
 the great Satan and all his little minions... If you're going to throw
 an equivalent but supposedly compromising solution at people, go for
 '.eapi3.eb' instead.

I can't speak to anyone's motivations or religious beliefs other than my
own here, but the opposition I have heard most often in this thread
is something like: I don't like it when the file extension changes so
often. Some people site historical president or the way other software
does things, or whatever - doesn't really matter.

What does matter is that some people don't like it when the file
extension changes very often. I think my solution is a valid compromise
because it balances, in my opinion, the two camps, whose arguments I
summarize as:

glep-55'ers: I don't care if the file extension changes all the time, I
just want a solution that works and is reasonably future-proof

Anti-55'ers: I don't want the file extension to change ever, but I
would agree that for major-enough changes it may be required
sometimes

If I understand the '.eapi3.eb' to which you make passing reference,
this is just a fancy hand-wavy way to say Look, the true .eb
extension won't ever change, just the .eapi3 part which isn't
technically the extension... which isn't a compromise at all - It's an
attempt to (cleverly?) obfuscate where in the filename the EAPI is
stored.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Jim Ramsay
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
 On Tue, 24 Feb 2009 15:07:29 -0500
 Jim Ramsay l...@gentoo.org wrote:
  I think
  things are very nicely documented in PMS and the devmanual, which
  are where all EAPI changes should be documented in the future,
  regardless if you specify the EAPI in the file, the extension, or
  both.
 
 They only ended up nicely documented after people moaned a lot that
 they were having a hard time keeping track of EAPIs...

You can't possibly be suggesting that everyone will be able to keep an
ever-increasing number of feature sets in his or her mind, or that
changing from a two-level to a one-level EAPI definition will remove
the need for documentation going forward, so I'm not sure what you mean
by this.

  Two levels really just means that any fancy tables will have to have
  one extra row (or perhaps a series of fancy tables) and any
  summaries will have to have an extra section added whenever a new
  filename extension becomes necessary.
 
 It'll mean people will carry on having to use the tables, and won't
 start remembering things as time goes on.

See comment above.  The need for documentation will only increase going
forward as new and varied EAPI definitions are created.

  If I understand the '.eapi3.eb' to which you make passing reference,
  this is just a fancy hand-wavy way to say Look, the true .eb
  extension won't ever change, just the .eapi3 part which isn't
  technically the extension... which isn't a compromise at all - It's
  an attempt to (cleverly?) obfuscate where in the filename the EAPI
  is stored.
 
 Yup. And yet there're people who are perfectly happy with .eapi3.eb
 who hate GLEP 55. That should tell you all you need to know about
 what's going on here...

Seriously?  That's scary.  But hey, if that's actually going to get
more people behind this, let's do it instead.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Jim Ramsay
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
 On Tue, 24 Feb 2009 15:37:36 -0500
 Jim Ramsay l...@gentoo.org wrote:
   They only ended up nicely documented after people moaned a lot
   that they were having a hard time keeping track of EAPIs...
  
  You can't possibly be suggesting that everyone will be able to keep
  an ever-increasing number of feature sets in his or her mind, or
  that changing from a two-level to a one-level EAPI definition will
  remove the need for documentation going forward, so I'm not sure
  what you mean by this.
 
 That's exactly what I mean. Developers can probably just about keep up
 with the two or three EAPIs they'll ever be working with on a regular
 basis, but they probably can't keep up with that if you double it.

Well, if you're assuming only two or three EAPIs in 'mental cache' at
any one time under glep-55, I'm not sure how this changes wrt. a
two-level system.  A two-level system doesn't change the number of
EAPIs in the tree or available to developers, it just changes how they
are named.

Regardless, this does not remove the need for documentation.  All
the EAPIs should be documented in both the PMS and the devmanual.  This
makes it possible for new developers to learn about the current
features available, and also helps existing devs who may need to
recover from 'mental page faults' from time to time.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-23 Thread Jim Ramsay
Alistair Bush ali_b...@gentoo.org wrote:
 Tiziano Müller wrote:
  Instead of switching file extension every time the eapi is changed
  you could also increment it only when a new EAPI breaks sourcing
  the ebuild compared to the requirements of the prior EAPI.
  (This way you'd in fact split EAPI into a major- and a
  minor-version.)
 
 Doesn't that just add extra complexity for no gain.

Actually, I think there would be a huge gain.

The gain would be that suddenly all those who oppose glep-55 because
they're afraid the filename suffix will change too often will suddenly
have nothing to worry about.

For those who think glep-55 is the right thing to do, it really
*is* glep-55, but with a small caveat that we shouldn't just change the
filename extension for every single little feature enhancement.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm,fluxbox,vim)



Re: [gentoo-dev] EAPI-2

2008-09-12 Thread Jim Ramsay
Ciaran McCreesh [EMAIL PROTECTED] wrote:
 On Tue, 9 Sep 2008 22:14:57 -0400
 Jim Ramsay [EMAIL PROTECTED] wrote:
  I was personally expecting to see some sort of section called
  EAPI-1 that contains something like:
  
  EAPI-1 consists of EAPI-0 with the following features added...
 
 Have a look at the eapi-differences-summary branch on
 git://git.overlays.gentoo.org/proj/pms.git . Is that roughly what
 you're after?

From what I could make out of the raw latex code, yes!

Unrelated topic:  What packages are actually required to 'make pms.pdf'
so I can actually read it?  I get:

! LaTeX Error: File `appendix.sty' not found.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] EAPI-2

2008-09-09 Thread Jim Ramsay
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 On Tue, 09 Sep 2008 16:31:08 +0300
 Petteri Räty [EMAIL PROTECTED] wrote:
  Jorge Manuel B. S. Vicetto kirjoitti:
   and cardoe's earlier request to the council ml, can the council
   members discuss this proposal and consider voting it?
   Does anyone have any objections to this proposal?
  
  I won't approve it for use in the tree before it's written as a GLEP
  in order to avoid the fiasco with EAPI 1 (it's still not documented 
  properly). I can however approve the list of items.
 
 What about the PMS EAPI 1 documentation do you consider 'not proper'?
 
I was personally expecting to see some sort of section called EAPI-1
that contains something like:

EAPI-1 consists of EAPI-0 with the following features added...

Then an explanation of each change and the appropriate syntax.

I did see how EAPI-1 is integrated throughout the document, which is
valuable in a different way - but it's harder to answer the question
What exactly does EAPI-1 add to EAPI-0?

Perhaps I'll try sending you a patch with something like that, if I
have time, and if it would be appreciated.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


[gentoo-dev] New license for inclusion in the tree: 'amazonmp3'

2008-09-03 Thread Jim Ramsay
This license governs a single piece of software, the mp3.amazon.com
download utility, which I would like to add to the tree shortly.

I don't think there's anything exceedingly wrong about this license,
just a standard closed-source thou shalt not... license that
RESTRICT=fetch deals with nicely.

Thought I'd post it here to double-check it looks okay.  Original
source is:

http://www.amazon.com/gp/help/customer/display.html?ie=UTF8nodeId=200154280

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)
*Amazon MP3 Music Service: Terms of Use*

THIS IS AN AGREEMENT BETWEEN YOU AND AMAZON DIGITAL SERVICES, INC. (WITH
ITS AFFILIATES, AMAZON OR WE). BEFORE USING THE AMAZON MP3 MUSIC
SERVICE (THE SERVICE), PLEASE READ THESE TERMS OF USE, ALL RULES AND
POLICIES RELATED TO THE SERVICE (INCLUDING, BUT NOT LIMITED TO, ANY
PRODUCT-SPECIFIC RULES OR USAGE PROVISIONS SPECIFIED ON ANY PRODUCT
DETAIL PAGE OR IN ANY LINK FROM A PRODUCT DETAIL PAGE), THE AMAZON.COM
PRIVACY NOTICE, AND AMAZON.COM CONDITIONS OF USE (COLLECTIVELY, THIS
AGREEMENT). IF YOU USE THE SERVICE, YOU WILL BE BOUND BY THE TERMS OF
THIS AGREEMENT.

   1. The Service
   2. Digital Content
   3. Software
   4. Reservation of Rights
   5. Territorial Restrictions
   6. General



*1. The Service*

The Service offers downloads of digitized versions of audio recordings,
artwork and information relating to such audio recordings, and other
content (individually and collectively, Digital Content) and other
services under the terms and conditions in this Agreement.

*2. Digital Content*

*2.1  License. *Upon your payment of our fees for Digital Content, we
grant you a non-exclusive, non-transferable license to use the Digital
Content for your personal, non-commercial, entertainment use, subject to
and in accordance with the terms of this Agreement. You may copy, store,
transfer and burn the Digital Content only for your personal,
non-commercial, entertainment use.

*2.2  Restrictions. *You represent, warrant and agree that you will use
the Service only for your personal, non-commercial, entertainment use
and not for any redistribution of the Digital Content or other use
restricted in this Section 2.2. You agree not to infringe the rights of
the Digital Content's copyright owners and to comply with all applicable
laws in your use of the Digital Content. Except as set forth in Section
2.1 above, you agree that you will not redistribute, transmit, assign,
sell, broadcast, rent, share, lend, modify, adapt, edit, sub-license or
otherwise transfer or use the Digital Content. You are not granted any
synchronization, public performance, promotional use, commercial sale,
resale, reproduction or distribution rights for the Digital Content. You
acknowledge that the Digital Content embodies the intellectual property
of a third party and is protected by law.

*2.3  Explicit Content. *You agree that we have no liability to you for
Digital Content you find to be offensive, indecent or objectionable.

*2.4  All Sales Final; Downloading and Risk of Loss; Availability of
Digital Content. *All sales of Digital Content are final. We do not
accept returns of Digital Content. Once you have purchased Digital
Content, we encourage you to download it promptly and to make back-up
copies of it. If you are unable to complete a download after having
reviewed our online help resources, please contact Amazon customer
service. You bear all risk of loss after purchase and for any loss of
Digital Content you have downloaded, including any loss due to a
computer or hard drive crash. We may, from time to time, remove Digital
Content from the Service without notice.

*3. Software*

*3.1  General. *We may make available to you, from time to time,
software for your use in connection with the Service (any and all such
software, individually and collectively, the Software).

*3.2  Use of the Software. *You may use the Software only in connection
with the Service. You may not separate any individual component of the
Software for use other than in connection with the Service, may not
incorporate any portion of it into your own programs or compile any
portion of it in combination with your own programs, may not transfer it
for use with another service, or use it, or any portion of it, over a
network and may not sell, rent, lease, lend, loan, distribute or
sub-license the Software or otherwise assign any rights to the Software
in whole or in part. We may discontinue some or all of any Software we
provide, and we may terminate your right to use any Software at any time
and in such event may modify it to make it inoperable.

*3.3  No Reverse Engineering, Decompilation, or Disassembly; Updates.
*You may not, and you will not encourage, assist or authorize any other
person to, modify, reverse engineer, decompile or disassemble the
Software, whether in whole or in part, or create any derivative works
from or of the Software. We may offer

Re: [gentoo-dev] License Interpretation

2008-08-22 Thread Jim Ramsay
Good news everyone!

This has become a non-issue, at least in the next version of flash
player[1].

Thanks again for all your input!

[1] http://blogs.adobe.com/penguin.swf/2008/08/curl_tradeoffs.html

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)


signature.asc
Description: PGP signature


[gentoo-dev] License Interpretation

2008-08-20 Thread Jim Ramsay
IANAL, and I'm sure most of us aren't either, but I would appreciate
some opinions on Bug https://bugs.gentoo.org/234542 and whether the
binary patch proposed there conflicts with section 2.5.1 of the license
agreement from Adobe:

http://www.adobe.com/products/eulas/pdfs/Reader_Player_WWEULA-Combined-20060724_1430.pdf

Specifically, here is the passage I'm wondering about:

2.5.1  You may not modify, adapt, translate or create derivative works
based upon the Software. You may not reverse engineer, decompile,
disassemble or otherwise attempt to discover the source code of the
Software except to the extent you may be expressly permitted to
decompile under applicable law, it is essential to do so in order to
achieve operability of the Software with another software program, and
you have first requested Adobe to provide the information necessary to
achieve such operability and Adobe has not made such information
available.

I *think* I would be okay using this binary patch since:

1) This is specifically to make it operable with libcurl.so.4
2) I have (and others have) asked Adobe to recompile it with support
for libcurl.so.4 instead of libcurl.so.3, but they have not done so (or
responded to any of these requests, as far as I am aware).

Anyone care to weigh in, lawyer or not?

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] metadata.xml USE flag descriptions

2008-07-29 Thread Jim Ramsay
Doug Goldstein [EMAIL PROTECTED] wrote:
 If people wish to take specific categories, please let this thread
 know.

I just did the rox-base and rox-extra categories.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)


signature.asc
Description: PGP signature


[gentoo-dev] RFC: Should 'imlib' USE flag be on by default in x86 and amd64 desktop profiles?

2008-07-25 Thread Jim Ramsay
I've run into it a few times now that fluxbox users running Gentoo
wonder why they can't get icons to work in the fluxbox menus.  The
short answer is that 'imlib' is off by default in many profiles,
including default-linux/amd64/2007.0/desktop and
default-linux/x86/2007.0/desktop

I know that I could turn it on by default for fluxbox only using EAPI-1,
but since it's a global USE flag, the profiles may be a better place.

I think imlib is something most desktop users would want, since it lets
them see all those pretty graphics.  Comments?  Concerns?

-- 
Jim Ramsay
Gentoo/Linux Developer (rox/gkrellm/fluxbox)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: RFC: 0-day bump requests

2008-07-08 Thread Jim Ramsay
Ryan Hill [EMAIL PROTECTED] wrote:
 On Mon, 7 Jul 2008 10:10:14 -0400
 Jim Ramsay [EMAIL PROTECTED] wrote:
 
  Here's an interesting solution for those who find it annoying
  though: Just file your own 0-day bump request in bugzilla. In
  theory some users would find this and just CC themselves on it.
  Other users could be shushed with the shame of the DUPLICATE.
  Everyone wins!
 
 I try to do this whenever there's some reason why I can't add a
 package right away.
 
 I also don't see the point of yelling at someone for trying to help in
 whatever way they can, even if that's in the form of a poke when a new
 version is released.

I wonder if a special Version Bump template for bugzilla could be a
useful thing to make this easier for both users and devs?

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] [v3] Planning for automatic assignment of bugs

2008-07-01 Thread Jim Ramsay
Mark Loeser [EMAIL PROTECTED] wrote:
 Its a good idea, but since our users don't
 always provide useful reports, it seems like we are just shifting work
 around.

I'd suggest that this would /spread/ work around - Instead of a few
folks wrangling bugs, everyone would be doing it.

That said, I have no idea how many duplicate / incomplete bugs I have
never seen due to the wonderful work of the wranglers.  In some ways it
would be a shame to lose that quality pre-reading of the bugs.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc

2008-06-16 Thread Jim Ramsay
Joe Peterson [EMAIL PROTECTED] wrote:
 As for why it would be more useful than eerror/ewarn without an
 argument: it would potentially allow for intelligent context-based
 coloring of the * (based on surrounding lines).

Well, this is true and it isn't... In the case of:

  ewarn line one
  eblank
  ewarn line two

Obviously it would be the same as ewarn.  However, what about here:

  ewarn line one
  eblank
  elog line two
  eblank
  einfo line three

I'm not sure how you could make a function like that smart enough to
really know what to do... so perhaps since the author is the only one
who can really know what colour they intend, they should just use the
appropriate ewarn/elog/einfo without args.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc

2008-06-16 Thread Jim Ramsay
Benedikt Morbach [EMAIL PROTECTED] wrote:

 On Sun, Jun 15, 2008 at 12:02 PM, Peter Volkov [EMAIL PROTECTED] wrote:
  But speaking about names of options - -A and -B are easier to
  remember as -A stands for above and -B for below and grep users
  already knew that.
 
 for grep -A means after and -B before ;)

Maybe we could have '-^' and '-v' then?

I do kind of like the idea of making these flags available for people
who think it makes their ebuilds prettier... I just don't think I'll
even use them.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc

2008-06-11 Thread Jim Ramsay
Vlastimil Babka [EMAIL PROTECTED] wrote:

 I would prefer something that 
 doesn't add extra lines to ebuild.

I think I would disagree with you here.  I think that having a special
'eblank' or 'eseparator' command is much more readable in an ebuild.
Consider:

pkg_postinst() {
elog Knock knock
eblank
ewarn Who's there?
eblank
elog Interrupting Cow
eblank
ewarn Interrup...
elog Moo!
}

Versus:

pkg_postinst() {
elog -p Knock knock
ewarn Who's there?
elog -pt Interrupting Cow
ewarn Interrup...
elog Moo!
}

I think that in the former case it's much more obvious how the actual
output is going to look.  If the cost is an ebuild that's 3 lines
longer, I think that's reasonable.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-11 Thread Jim Ramsay
David Leverton [EMAIL PROTECTED] wrote:
 Since at least one ebuild has already been modified specifically to
 work around the bug, I'd say it's pretty real.

For those of us trying to play along at home, which one is this?

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-11 Thread Jim Ramsay
Olivier Galibert [EMAIL PROTECTED] wrote:
 On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote:
  !-- EAPI=3 --
 
 *Then* would be the time to change the extension.  As long as the
 ebuild is bash-parseable with an appropriate environment, it doesn't
 make sense to change the extension because a env-variable set or a
 comment are more natural methods.
 
 If/when the format changes to something not parseable by bash, then it
 will be time to change the extension.  And then how to mark
 (sub-)version will depend on the chosen new format, in case of xml
 that would be the dtd information.
 
 I suspect the rejection of the extension change will be there as long
 as the fundamental format (bash script) doesn't change.

Well said.  This is something that I've heard bandied about on IRC now
and then, and sounds to me (notably *not* a package manager developer)
like a fairly reasonable compromise.

To the proponents of GLEP55:

Is there some reason that GLEP55 is preferable to this?

Are there reasons why a particular filename extension could not apply
to a range of EAPIs?

Why not just bump the filename suffix when it is required to support a
new EAPI that breaks the sourcing rules of previous EAPIs?

Or will backwards-incompatible changes be happening so frequently that
the package suffix will have to change for every EAPI bump anyway,
which would make this proposal equivalent to GLEP55?

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-11 Thread Jim Ramsay
Santiago M. Mola [EMAIL PROTECTED] wrote:
 On Thu, Jun 12, 2008 at 4:07 AM, Jim Ramsay [EMAIL PROTECTED] wrote:
  Why not just bump the filename suffix when it is required to
  support a new EAPI that breaks the sourcing rules of previous EAPIs?
 
  Or will backwards-incompatible changes be happening so frequently
  that the package suffix will have to change for every EAPI bump
  anyway, which would make this proposal equivalent to GLEP55?
 
 That works. Although, we'd have to keep track of two parameters when
 setting our EAPI. One being the EAPI itself and the suffix needed for
 that EAPI. So this doesn't seem to make the problem simpler.

I agree that it doesn't make things simpler.  Though it doesn't make
things that much more complex.  That said, I'm becoming more convinced
that a lot of the changes that really need to be made will indeed break
EAPI sourcing rules, so maybe the latter part of my original quote
above will indeed be the case - This would be equivalent to GLEP55.

I should add that I am not personally opposed to having the EAPI in the
filename, but this may find slightly more acceptance from the folks who
think that solution is incorrect.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] New developer : Markus Duft (mduft)

2008-04-30 Thread Jim Ramsay
Denis Dupeyron [EMAIL PROTECTED] wrote:
 Please everybody, give a very warm welcome to mduft.

Lay on, mduft,
And damn'd be him that first cries, 'Hold, enough!'

Exeunt, fighting.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


[gentoo-dev] Last rites: x11-plugins/gkrellm-bfm

2008-01-31 Thread Jim Ramsay
# Jim Ramsay [EMAIL PROTECTED] (31 Jan 2008)
# Masked for removal in 30 days. Replaced by 
# x11-plugins/bfm with USE=gkrellm.  Bug #207720
x11-plugins/gkrellm-bfm

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in rox-base/rox: ChangeLog rox-2.7-r2.ebuild

2007-12-21 Thread Jim Ramsay
Donnie Berkholz [EMAIL PROTECTED] wrote:
 On 15:05 Mon 17 Dec , Jim Ramsay (lack) wrote:
  lack07/12/17 15:05:57
  IUSE=+svg +video
 
 svg already defaults on for all the desktop profiles, so I'm not
 really sure what that's gaining you.

Good point, removed '+' there

  RDEPEND==x11-libs/gtk+-2.4
  =dev-libs/glib-2.2
  =dev-libs/libxml2-2.4.23
  =x11-misc/shared-mime-info-0.14
  svg? ( gnome-base/librsvg )
  !ppc? ( rox-base/mime-editor
  rox-base/thumbs
  video? ( rox-extra/videothumbnail ) )
 
 PPC users aren't supposed to get this stuff? If not, is it even a
 real dependency?

I'm waiting on bug 201983 for ppc to keyword those ebuilds.  They are
semi-optional runtime dependencies.  I'll explain further:

There are buttons in the ROX application's options window which
launch each of these applications.  Thus they are not *strictly*
required for basic operation, but are required for all the buttons in
the app to actually work.  videothumbnail is USE-dependent because it
needs either mplayer or totem, neither of which are very quick to
install.  The other two however (mime-editor and thumbs) are reasonably
simple python apps that really only take a second or so to download and
install.

  (cd src; make clean)  /dev/null
 
 Subshells are icky.

I agree, replaced them all with pushd/popd instead.

  chmod 0755 ${D}/usr/bin/${WRAPPERNAME}
  chmod 0755 ${D}/usr/bin/${WRAPPERNAME}uri
 
 fperms?

Ah yes.  Done.
 
  make_desktop_entry ${WRAPPERNAME} ${APPNAME} ${APPNAME}.png
  System;Utility;Core;ROX
 
 Thought I saw something about desktop entries dropping the suffix for 
 the icon, but I don't recall the details.

Yes, this is correct.  I have removed it.  Also technically speaking
there is no 'ROX' category (any more?) so I have removed it as well and
made it better match the defined menu categories.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-19 Thread Jim Ramsay
Fernando J. Pereda [EMAIL PROTECTED] wrote:
 On Wed, Dec 19, 2007 at 04:17:21PM +0100, Luca Barbato wrote:
  Piotr Jaroszyński wrote:
   Mixing EAPIs can't work.
  
  Why?
 
 Because EAPIs can define colliding features.

The sense I've gotten from this discussion so far is that if you want
features from two EAPIs you know *can* be combined without collisions,
you should define a third EAPI that is a superset of the other 2.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-19 Thread Jim Ramsay
Luca Barbato [EMAIL PROTECTED] wrote:
 How would it be different than having EAPI=string put in a defined
 position of the file?

It's not - It is just defining that position to be in the name of the
file instead of the contents :)

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in rox-base/rox-clib: ChangeLog rox-clib-2.1.10.ebuild

2007-12-07 Thread Jim Ramsay
Donnie Berkholz [EMAIL PROTECTED] wrote:
 Instead of these subshells to save the original directory, a more
 common technique is pushd/popd. Another possibility is 'cd foo;
 stuff; cd -', but that doesn't stack.

That's an excellent idea, I'll update these to not use subshells in the
future.

Is there some sort of equivalent way to back-out of whatever 'insinto'
does to the environment?

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: rox-0install.eclass

2007-12-04 Thread Jim Ramsay
Donnie Berkholz wrote:
 I don't remember this going by gentoo-dev. Always send eclasses to 
 gentoo-dev before committing them.

My apologies, I was just so excited that I'd finally finished it!

Apparently I missed a few things, thanks very much for catching
it.

  0install_native_feed() {
  local src=${1}; shift
  local path=${1}; shift
 
 This is a rather strange paradigm to me, instead of:
 
 local src=$1 path=$2
 shift 2

This is cleaner, thanks.  In fact, I don't even really need the
shift at all.

  local feedfile=$(basename ${src})
 
 You could do this in pure bash, although it doesn't really matter:
 
 local feedfile=${src##*/}

Sure, may as well, save a subshell.

  local dest=${path}/$feedfile
 
 How do you decide when not to use braces { } around variables?

In general I've used them everywhere... except there :)  Fixed.

  0distutils ${src}  tmp.native_feed || die 0distutils feed edit 
  failed
  
  if [[ ${ZEROINSTALL_STRIP_REQUIRES} ]]; then
  # Strip out all 'requires' sections
  sed -i -e '/requires.*\//d' \
  -e '/requires.*\/,/\/requires/d' tmp.native_feed
 
 What happens if the contents of a requires section are on a separate 
 line? Is this a concern?

It hasn't been so far - The convention in all known cases is
either it's all on one line, or a multi-line as is caught  by the
second sed expression.  This is just a stopgap measure until I
rework 0distutils to do this optional stripping on its own.

  local feedname
 
 You could just declare feedname local and set it in the same line.

Not if I want to potentially die on the assignment.  As I found
out in #gentoo-dev-help today, try this:

$ t() { local a=$(false) || echo Die; }; t

Versus this:

$ t() { local a; a=$(false) || echo Die; }; t
Die

  feedname=$(0distutils -e ${src}) || 0distutils URI escape failed
 
 What's the || doing? You've got a string sitting there. Is 'die' 
 missing?

Verily - nice catch!

  if ! $installed; then
 
 This is kind of a weird way to do it. I'd check instead for
 [[ -n ${installed} ]] and initialize it to empty.

Sure, that looks nicer.

I'll be committing these changes right away, since the die ones
at least are very important.  But I'll be submitting further
changes to the list first.  Sorry about that :)

Luckily only 1 ebuild so far which uses this eclass has actually
hit the tree!

-- 
Jim Ramsay
Gentoo/Linux Developer (rox/fluxbox/gkrellm)


pgp2FsjDFSTI0.pgp
Description: PGP signature


Re: [gentoo-dev] Changes to rox.eclass

2007-11-28 Thread Jim Ramsay
Petteri Räty [EMAIL PROTECTED] wrote:
 Next time could you please use a text/plain diff as the attachment.

I thought about doing that, but because of all code movement, the
unified diff was kind of ugly.  As I'm sure you'll see on the cvs list,
now that I've committed the thing.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Changes to rox.eclass

2007-11-28 Thread Jim Ramsay
Ryan Hill [EMAIL PROTECTED] wrote:
 Looks good here. 

Thanks, former fellow Saskatchewanain.  I've committed it.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


[gentoo-dev] EAPI feature suggestion: OBSOLETES (was: gentoo-x86 commit in profiles/updates: 4Q-2007)

2007-11-06 Thread Jim Ramsay
Whether or not 'move' was the correct action in the recent compiz
example, perhaps we need to consider that some times one package does
actually make another obsolete. The correct thing for the PM to
do is to first uninstall the obsolete package, then install the new one.

Now, it has been my experience that blocking dependencies are currently
used to imply this No, you have to remove cat/foo first before
installing cat/bar instead situation.  This is somewhat annoying for
me when I want to upgrade a bunch of packages, but I have to manually
uninstall a few blockers first before this is possible.

This could be automated by the PM in those cases with some sort of
thing like this in the cat/bar-1.0.ebuild:

  OBSOLETES=cat/foo

Of course this would be a regular package atom (or list thereof), so it
could be tied to specific versions of cat/foo.

I suppose this could be seen as a special case of blocking deps which
would automate a specific cat/bar is to be preferred over cat/foo

However, I'm not exactly sure what you would do if you have pkg1 which
depends on cat/foo and pkg2 which depends on cat/bar...

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use

2007-10-09 Thread Jim Ramsay
Robin H. Johnson [EMAIL PROTECTED] wrote:
 how soon can we start to use it
 to replace the old crufty no* flags

So what's going on here?  Do we need to wait for EAPI=1 and use the new
IUSE defaults?  Or can we use package.use right now?

I also have some 'disablefoo' USE flags I want to clear out for the
1.0.0 release of fluxbox.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: net-im/pidgin protocols

2007-07-20 Thread Jim Ramsay
fire-eyes wrote:
 Duncan wrote:
  OTOH, if enabling those protocols pulls in all sorts of additional 
  packages to support them, shipping with everything on just because
  it's possible is not the Gentoo way.  That's what USE flags are
  for.  If indeed additional dependencies are pulled in, IMO the USE
  flags should remain, and maybe someone needs to explain the Gentoo
  way to upstream.
 
 ++; from a user. I prefer to leave them off. However I can understand
 the other sides point of view, too.

I believe one of the main philosophies of Gentoo is to try to have an
app be as close to upstream as possible.  I personally believe that
this means the we should try to enable enough USE flags by default that
it is roughly equivalent to running upstream's './configure' with no
arguments.  USE flags then give the advanced user the ability to
disable those features normally on, or enable those features normally
off, but we want a freshly installed package by default to just
work[1] and to be as close to upstream as possible[2].

With this in mind, enabling most of the default protocols makes sense
to me.

[1]
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3chap=1#doc_chap1

[2] looking for actual references to this, but couldn't find it...
I think it's _somewhere_ in the required new-developer reading...

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Nominations open for the Gentoo Council 2007/08

2007-07-17 Thread Jim Ramsay
Jan Kundrát wrote:
 lack (he's a bit fresher, but his mails are good)

Thanks very much, I appreciate the nomination!

But I must decline.

I don't feel that I have enough experience in Gentoo land yet. Plus
I'll be starting a new job next month and am not yet sure how much time
I can commit.

Ask me again in a year :)

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] ML changes

2007-07-13 Thread Jim Ramsay
Seemant Kulleen wrote:
 Thanks for expressing your point of view that clearly.  I stand with
 you.

snip: More clear arguments

I'm just adding one more comment that I don't think I've seen yet in
this thread.  (Although it's been a long thread, and I don't remember
all the points from all the other mails this late in the game...)

To my recollection, the recent flame wars have for the most part been
between devs and non-devs.

Now, this proposed moderation only addresses one half (the non-dev
side) of that problem, by moderating it away.  I personally think
that a better solution would be to address the @gentoo.org side of the
problem, since that is, in theory, something that we already have
control over via devrel.

If we have our own house in order and provide leadership and direction
on the list by not replying to personal attacks (or perceived personal
attacks) with more personal attacks (or perceived personal attacks),
and always keeping our side of the technical discussions purely
technical and non-sarcastic, I really believe that flame wars will just
flicker and die.

Maybe this just means that we need more people to report developers
acting badly to devrel.

In closing, I also disagree with the Moderation Proposal.  I think
that it may stop the flame wars at the cost of stopping valuable
discussions.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] ML changes

2007-07-12 Thread Jim Ramsay
Mike Doty wrote:
 devs who moderate in bad posts will be subject to moderation
 themselves.

Will this be monitored/enforced by the proctors?

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] glibc-2.6 / gcc-4.2 going into ~arch

2007-07-05 Thread Jim Ramsay
Mike Frysinger [EMAIL PROTECTED] wrote:
 get your waaait dont do it votes in now, i plan on pushing:
 glibc-2.6 ~amd64 ~ppc ~ppc64 ~x86
 gcc-4.2.0 ~amd64 ~x86

Are there any crazy upgrade paths like the good old libstdc++ bump?

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] glibc-2.6 / gcc-4.2 going into ~arch

2007-07-05 Thread Jim Ramsay
Mike Frysinger [EMAIL PROTECTED] wrote:
 On Friday 06 July 2007, Jim Ramsay wrote:

  Are there any crazy upgrade paths like the good old libstdc++ bump?

 no

And there was great rejoicing.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] gentoo-dev-announce list

2007-06-21 Thread Jim Ramsay
Mike Doty wrote:
 or you could ask infra to work it's magic making any post to
 -dev-announce post to -dev as well and set the replt-to address for
 -dev-announce to -dev.  that way it's all automagic.

I hope you meant the List-Post header... unless we would like to have
another discussion on the merits/evils of reply-to munging :)

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] gentoo-dev-announce list

2007-06-21 Thread Jim Ramsay
Mike Doty wrote:
 Jim Ramsay wrote:
  Mike Doty wrote:
  or you could ask infra to work it's magic making any post to
  -dev-announce post to -dev as well and set the replt-to address for
  -dev-announce to -dev.  that way it's all automagic.
  
  I hope you meant the List-Post header... unless we would like to
  have another discussion on the merits/evils of reply-to munging :)
  
 As an announce list, you're NEVER EVER supposed to reply to the list,
 so reply-to munging in this case is appropriate IMO.

Reply-To is supposed to let you reply to the author, in case they need
to use a different return address than what is in the From header.
Which I grant is very rare for Gentoo developers.

But I do agree with you that if reply-to munging is done it should
indeed point at -dev and never the -announce list.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


[gentoo-dev] Help with libflashsupport for amd64

2007-05-14 Thread Jim Ramsay
I have just added net-www/libflashsupport-1.2 for ~x86, and would like
to get the help of at least one amd64 dev to ensure it also works for
~amd64 before I add it as an optional dependency to
net-www/netscape-flash

So, any amd64 dev who can give me a hand, please do so, and/or contact
me! Thank you.

For those who do not know already, libflashsupport adds pulseaudio,
oss, esd, and/or ssl/gnutls support to the netscape-flash binary.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Optional Package Dependencies for netscape-flash - libflashsupport

2007-05-11 Thread Jim Ramsay
Olivier Crête wrote:
 On Thu, 2007-10-05 at 14:20 -0400, Patrick McLean wrote:
  Jim Ramsay wrote:
   
   1) Create a single local USE flag (flashsupport or something)
   that will just pull in this dependency.
   
   2) Use the same set of USE flags as libflashsupport has, with any
   of them adding libflashsupport to the dep list, since these are
   all global flags and will most likely be enabled for both
   netscape-flash and libflashsupport
   
   I'm personally thinking (1) is the better of the 2 options, but
   I'd like to know if anyone has any other wondrous solutions to
   this.
  
  Does/will anything else dep on flashsupport? If not, why not just
  add the USE flags to netscape-flash and install libflashsupport as
  part of the netscape-flash install instead of a separate package.
 
 If its a separate package that will be updated separately, then it
 doesn't make sense to put it in the separate package and I support
 option 1. Otherwise, if they'll always be together, then just put it
 in the same package.

Yes, libflashsupport is distributed separately and is on a different
release schedule than netscape-flash.

I suppose I could also propose:

4) netscape-flash just RDEPENDS on libflashsupport all the time.  It's
certainly not a large library to be added on.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Optional Package Dependencies for netscape-flash - libflashsupport

2007-05-11 Thread Jim Ramsay
Josh Saddler wrote:
 Jim Ramsay wrote:
  I suppose I could also propose:
  
  4) netscape-flash just RDEPENDS on libflashsupport all the time.
  It's certainly not a large library to be added on.
  
 
 That is a terrible idea. Don't make it depend on something that it
 clearly does *not* depend on. Flash works just fine without the
 optional add-ons, and those are *definitely* optional. I've never
 needed libflashsupport and would prefer not seeing useless cruft
 attached to a perfectly working Flash installation.

Point taken - If you don't want the extra features you don't want
libflashsupport at all.

I could make it so that if all of the USE flags for libflashsupport are
turned off it doesn't actually install the library at all, just gets
added to the list of installed packages.

 If you're going to add it to USE, then make sure it's *not* on by
 default, thanks.

This way it will adhere to your current set of global USE flags. If you
have pulseaudio, esd, oss, ssl, or gnutls on globally, it will install
libflashsupport with the appropriate hooks in it.  If they are all
off (either globally or specifically for libflashsupport) you will
just get the same old netscape-flash with no add-ons.

Is this a worthy compromise?

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Optional Package Dependencies for netscape-flash - libflashsupport

2007-05-11 Thread Jim Ramsay
Olivier Crête wrote:
 On Fri, 2007-11-05 at 12:12 -0600, Jim Ramsay wrote:
  Josh Saddler wrote:
   Jim Ramsay wrote:
I suppose I could also propose:

4) netscape-flash just RDEPENDS on libflashsupport all the time.
It's certainly not a large library to be added on.

   
   That is a terrible idea. Don't make it depend on something that
   it clearly does *not* depend on. Flash works just fine without the
   optional add-ons, and those are *definitely* optional. I've never
   needed libflashsupport and would prefer not seeing useless cruft
   attached to a perfectly working Flash installation.
  
  Point taken - If you don't want the extra features you don't want
  libflashsupport at all.
  
  I could make it so that if all of the USE flags for libflashsupport
  are turned off it doesn't actually install the library at all, just
  gets added to the list of installed packages.
  
   If you're going to add it to USE, then make sure it's *not* on by
   default, thanks.
  
  This way it will adhere to your current set of global USE flags. If
  you have pulseaudio, esd, oss, ssl, or gnutls on globally, it will
  install libflashsupport with the appropriate hooks in it.  If they
  are all off (either globally or specifically for libflashsupport)
  you will just get the same old netscape-flash with no add-ons.
  
  Is this a worthy compromise?
 
 This seems even worse.. I think either having one local use flag in
 netscape-flash is probably the best solution.. The second best is to
 have all of the use flags and RDEPEND on flash-support if any is
 enabled.

Can you explain what you mean by even worse?  I think my latest
solution is more correct than any of the others yet proposed.  In fact,
here's another small improvement on it:

Have netscape-flash with IUSE=vanilla (by default it is off), which
when enabled will not pull in libflashsupport.

This meets the following goals:

1) It makes it easy for regular users to get netscape-flash with any
additions required by any global USE flags in exactly one step:
 - emerge netscape-flash
This is my #1 goal, otherwise I'd just have 'libflashsupport' as its
own separate package and those in the know would install it
separately if they want any of the extra features. But users should not
have to have special knowledge to get the features they have already
enabled in their global USE flags.

2) It makes it easy for power users to not have libflashsupport
actually install anything by disabling all the USE flags.  This will
take 3 steps:
- Notice at upgrade or install time that there's this new 'extra'
package being installed
- Enable the 'vanilla' flag for netscape-flash
- Continue with upgrade or install

Also, having all of the ssl/gnutls/pulseaudio/esd/oss flags turned off
for libflashsupport will have the effect of not actually installing the
library, so the only added cost there is one more entry in the list of
installed packages, which I hope you will agree is basically zero.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Optional Package Dependencies for netscape-flash - libflashsupport

2007-05-11 Thread Jim Ramsay
Thomas Rösner wrote:
 Jim Ramsay wrote:
  [snip]
  Have netscape-flash with IUSE=vanilla (by default it is off),
  which when enabled will not pull in libflashsupport.

 
 I don't quite see why this is necessary? Or why you do have this
 discussion?

I started this discussion to find out the best way to add
libflashsupport to netscape-flash for users who want the extra features
that it offers.

  This meets the following goals:
 
  1) It makes it easy for regular users to get netscape-flash with
  any additions required by any global USE flags in exactly one step:
   - emerge netscape-flash

 
 So, in netscape-flash:
 RDEPEND=
 ssl? ( foo/libflashsupport )
 pulseaudio? ( foo/libflashsupport )
 esd? ( foo/libflashsupport )
 oss? ( foo/libflashsupport )
 
 and IUSE=ssl pulseaudio esd oss gnutls in libflashsupport (which, as
 already said, has it's own ebuild)?

Yes, I considered this, it is option (2) in the original post in this
thread. However, I do not believe this is the best solution.  Consider
the case where:
 - A user has 'ssl' disabled globally
 - A user sees that netscape-flash now has 'ssl' support, so he/she
enables 'ssl' just for the netscape-flash ebuild.
 - The ebuild would then install libflashsupport, but do so without
actually adding ssl support, which would be quite frustrating to the
user, and probably generate unnedded bug traffic.

It would be much more clear to only use the ssl USE flag when it
actually affects ssl support.

  2) It makes it easy for power users to not have libflashsupport
  actually install anything by disabling all the USE flags.  This will
  take 3 steps:
  - Notice at upgrade or install time that there's this new 'extra'
  package being installed
  - Enable the 'vanilla' flag for netscape-flash
  - Continue with upgrade or install
 
 It's still easy enough to disable it via -* in package.use?

I'm not sure I understand what you are saying here.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Optional Package Dependencies for netscape-flash - libflashsupport

2007-05-11 Thread Jim Ramsay
Olivier Crête wrote:
 On Fri, 2007-11-05 at 13:19 -0600, Jim Ramsay wrote:
  Olivier Crête wrote:
   On Fri, 2007-11-05 at 12:12 -0600, Jim Ramsay wrote:
Josh Saddler wrote:
 Jim Ramsay wrote:
  I suppose I could also propose:
  
  4) netscape-flash just RDEPENDS on libflashsupport all the
  time. It's certainly not a large library to be added on.
  
 
 That is a terrible idea. Don't make it depend on something
 that it clearly does *not* depend on. Flash works just fine
 without the optional add-ons, and those are *definitely*
 optional. I've never needed libflashsupport and would prefer
 not seeing useless cruft attached to a perfectly working
 Flash installation.

Point taken - If you don't want the extra features you don't
want libflashsupport at all.

I could make it so that if all of the USE flags for
libflashsupport are turned off it doesn't actually install the
library at all, just gets added to the list of installed
packages.

 If you're going to add it to USE, then make sure it's *not*
 on by default, thanks.

This way it will adhere to your current set of global USE
flags. If you have pulseaudio, esd, oss, ssl, or gnutls on
globally, it will install libflashsupport with the appropriate
hooks in it.  If they are all off (either globally or
specifically for libflashsupport) you will just get the same
old netscape-flash with no add-ons.

Is this a worthy compromise?
   
   This seems even worse.. I think either having one local use flag
   in netscape-flash is probably the best solution.. The second best
   is to have all of the use flags and RDEPEND on flash-support if
   any is enabled.
  
  Can you explain what you mean by even worse?  I think my latest
  solution is more correct than any of the others yet proposed.  In
  fact, here's another small improvement on it:
  
  Have netscape-flash with IUSE=vanilla (by default it is off),
  which when enabled will not pull in libflashsupport.
 
 flashsupport should be disabled by default. I still think you should
 add a positive use flag to netscape-flash (call it flashsupport or or
 a combination of esd/ssl/gnutls/etc).

I disagree with you here.  I believe it should be installed by default
because it would then install by default any optional features that
a user has enabled in his/her global USE flags.  Which I argue is the
expected outcome of installing any package.

I guess I still don't see what the benefit would be of having it
disabled by default - It would just be making more work for users who
want the added features.  If you have a compelling argument for your
side that I'm not seeing, please let me know what it is.

  This meets the following goals:
  
  1) It makes it easy for regular users to get netscape-flash with
  any additions required by any global USE flags in exactly one step:
   - emerge netscape-flash
  This is my #1 goal, otherwise I'd just have 'libflashsupport' as its
  own separate package and those in the know would install it
  separately if they want any of the extra features. But users should
  not have to have special knowledge to get the features they have
  already enabled in their global USE flags.
  
  2) It makes it easy for power users to not have libflashsupport
  actually install anything by disabling all the USE flags.  This will
  take 3 steps:
  - Notice at upgrade or install time that there's this new 'extra'
  package being installed
  - Enable the 'vanilla' flag for netscape-flash
  - Continue with upgrade or install
  
  Also, having all of the ssl/gnutls/pulseaudio/esd/oss flags turned
  off for libflashsupport will have the effect of not actually
  installing the library, so the only added cost there is one more
  entry in the list of installed packages, which I hope you will
  agree is basically zero.
 
 Installing a package without really installing it is EVIL. The db
 should represent whats installed on the system, otherwise it will
 become very very confusion for users.

Well, I was actually going to have it install a single README file
explaining why the package didn't install very much.  I could of
course leave in the 'libflashsupport.so' library that would basically do
nothing... Really, this is just a shortcut so that if you don't want any
of the features libflashsupport provides you will not have the small
overhead of having the plugin load libflashsupport.so when it starts up.

For added information, here is what I understand happens when you load
the existing Adobe flash plugin:

 - Check for a plugin called /usr/lib/libflashsupport.so
 - If found, load it, and use any of the functions provided there to
support alternate audio, video, or ssl features.
 - If not found, carry on and use the default set of features: ALSA
sound output and no SSL support.

So the possibilities for people not wanting the added features are:
 - Have no such file called /usr/lib

Re: [gentoo-dev] Re: [gentoo-core] [POLICY] Keywording/Stabilizing Bug Assignment Policy

2007-04-18 Thread Jim Ramsay
Vlastimil Babka [EMAIL PROTECTED] wrote:
 Or maybe implement new bugzilla keywords, like STABLEREQ and
 KEYWORDREQ which would be added to the respective bugs. Then you (the
 maintainer) can easily create (and save) an advanced search that will
 filter them out, while still being able to check them in a different
 search. Might be also useful for arch teams to separate stabling and
 keywording bugs?

I think that's a great idea.  Who do we bug to get this in there?

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-core] [POLICY] Keywording/Stabilizing Bug Assignment Policy

2007-04-18 Thread Jim Ramsay
Chris Gianelloni wrote:
 On Wed, 2007-04-18 at 07:39 -0600, Jim Ramsay wrote:
  Vlastimil Babka [EMAIL PROTECTED] wrote:
   Or maybe implement new bugzilla keywords, like STABLEREQ and
   KEYWORDREQ which would be added to the respective bugs. Then you
   (the maintainer) can easily create (and save) an advanced search
   that will filter them out, while still being able to check them
   in a different search. Might be also useful for arch teams to
   separate stabling and keywording bugs?
  
  I think that's a great idea.  Who do we bug to get this in there?
 
 File a bug in the Bugzilla component.
 
I hear and obey:

http://bugs.gentoo.org/show_bug.cgi?id=175103

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April

2007-04-12 Thread Jim Ramsay
Ciaran McCreesh wrote:
 If something's supposed to be transparent, it shouldn't be on -core.
 And, conversely, if something's on -core, it's not supposed to be
 transparent. Opening up -core just makes it harder to handle those
 rare cases where things really are required to be restricted.

I agree - this is precisely the reason why I personally prefer a private
archive of -core.

 There's also the issue of whether this can legitimately be made
 retroactive. As Ned already pointed out, some developers only posted
 things to -core because they believed that it was not public.

I'm fairly sure the consensus is that this would not be retroactive.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla

2007-03-26 Thread Jim Ramsay
Kevin F. Quinn wrote:
 People reporting bugs often get annoyed when their bug is marked
 INVALID; especially when they're relatively new to the Gentoo
 Experience.  We've all seen it many times, I'm sure.

I know I'm coming in late on this one, but I can see how having a bug
marked as INVALID with no explanation could be hurtful to the reporter.

However, if you add a comment to the effect of:

  Marking this as 'invalid' because it's not really a bug, just
  unexpected.  For a longer discussion of the issue, see
  [[some reference link]].

and then mark the bug as INVALID, maybe that's all that would be needed.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: moving USE=server to global

2007-03-19 Thread Jim Ramsay
Steve Long wrote:
 I don't see what is so dangerous about a server flag. After all I
 don't set doc globally, but it is a useful global flag, with clear
 intent, as would be server.

Does it mean:

A) Compile just the server, as leaving it off compiles both client
AND server

B) Compile the client AND server, as leaving it off compiles ONLY the
client

C) All of the above

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] My turn to wear the cursed medalion of retirement

2007-03-19 Thread Jim Ramsay
/me reads one Scroll of Blessing

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: How others handle bad behaviour on mailinglists

2007-03-09 Thread Jim Ramsay
Stephen Bennett wrote:
 On Fri, 9 Mar 2007 10:41:57 -0500
 Philip Webb [EMAIL PROTECTED] wrote:
 
  Always be parliamentary;
  never be personal; have a point to make; know when to stop.
  'Parliamentary' means 'follow the rules for MPs in Ottawa or
  Westminster'.
 
 If you've seen what goes on in the House of Commons on occasion, you'd
 know that those two are contradictory.

I have only one response to this: Fuddle duddle [1].

[1] http://tinyurl.com/25cwu7

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


[gentoo-dev] New eclass: gkrellm-plugin

2007-03-08 Thread Jim Ramsay
I'm tired of maintaining essentially the same code in 20-odd ebuilds,
so I am wanting to condense the common bits into a single eclass.

Most of you probably don't care, but it may be of interest to those few
who maintain gkrellm plugin ebuilds.

I have attached my first draft of the eclass.  As you can see, there
are 3 main important benefits to using this eclass:

1 - Sets up the basic dependencies shared by all gkrellm plugins

2 - New pkg_setup check to ensure gkrellm was built with USE=X (see
bug 167227 for more info on why this is necessary for 99.9% of plugins)

3 - The plugin install location is now centralized, and available via
the gkrellm-plugin_dir function, instead of each ebuild hard-coding
'/usr/$(get_libdir)/gkrellm2/plugins'

As an added benefit, the most common variant of src_install was
centralized here too.

If there are no major objections, I will add this eclass shortly, at
which point anyone is free (and encouraged!) to use it for their gkrellm
plugin ebuilds.  I will begin converting all my ebuilds shortly
thereafter.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

#
# Original Author: Jim Ramsay [EMAIL PROTECTED]
#
# Purpose:
#   Provides common methods used by (almost) all gkrellm plugins:
#- Sets up default dependencies
#- Adds pkg_setup check to ensure gkrellm was built with USE=X (bug
#167227)
#- Provides 'gkrellm-plugin_dir' function in lieu of hard-coding the plugins
#directory (which *may* change in the future)
#- Provides the most common src_install method to avoid code duplication.
#
# Utility Routines:
#   gkrellm-plugin_dir - Returns the gkrellm-2 plugin directory
#
# Environment:
#   For src_install:
# PLUGIN_SO - The name of the plugin's .so file which will be installed in
#   the plugin dir.  Defaults to ${PN}.so
# PLUGIN_DOCS - An optional list of docs to be installed.
#

inherit multilib eutils

ECLASS=gkrellm-plugin
INHERITED=$INHERITED $ECLASS

RDEPEND==app-admin/gkrellm-2*
DEPEND=${RDEPEND}
dev-util/pkgconfig

gkrellm-plugin_dir() {
echo /usr/$(get_libdir)/gkrellm2/plugins
}

gkrellm-plugin_pkg_setup() {
if ! built_with_use app-admin/gkrellm X  \
! has X ${IUSE}; then
eerror This plugin requires the X frontend of gkrellm.
eerror Please re-emerge app-admin/gkrellm with USE=\X\
die Please re-emerge app-admin/gkrellm with USE=\X\
fi
}

gkrellm-plugin_src_install() {
insinto $(gkrellm-plugin_dir)
doins ${PLUGIN_SO:-${PN}.so}

DDOCS=README* ChangeLog AUTHORS COPYING FAQ TODO INSTALL

for doc in ${DDOCS}; do
[ -s $doc ]  dodoc $doc
done

[ -n ${PLUGIN_DOCS} ]  dodoc ${PLUGIN_DOCS}
}

EXPORT_FUNCTIONS pkg_setup src_install


signature.asc
Description: PGP signature


Re: [gentoo-dev] New eclass: gkrellm-plugin

2007-03-08 Thread Jim Ramsay
Ciaran McCreesh wrote:
 On Thu, 8 Mar 2007 11:19:20 -0600 Jim Ramsay [EMAIL PROTECTED] wrote:
  I have attached my first draft of the eclass.  As you can see, there
  are 3 main important benefits to using this eclass:
 
 You shouldn't dodoc COPYING.
 
 You don't need to set ECLASS manually any more.

Good points, and thanks :)

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] New eclass: gkrellm-plugin

2007-03-08 Thread Jim Ramsay
Petteri Räty wrote:
 Jim Ramsay wrote:
  ECLASS=gkrellm-plugin
  INHERITED=$INHERITED $ECLASS
 
 No need to set INHERITED yourself any more either. Ciaran already
 pointed out ECLASS.

Indeed, thanks for that!

They just appeared automagically when I did 'vim foo.eclass'  I wonder where 
that comes from...

  
  gkrellm-plugin_pkg_setup() {
  if ! built_with_use app-admin/gkrellm X  \
  ! has X ${IUSE}; then
  eerror This plugin requires the X frontend of
  gkrellm. eerror Please re-emerge app-admin/gkrellm with USE=\X\
  die Please re-emerge app-admin/gkrellm with
  USE=\X\ fi
  }
 
 How useful is the X use flag in gkrellm? Just thinking if it would be
 better to just remove the use flag and always build that code.

Well, gkrellm consists of two optional parts:

- gkrellmd which is a monitoring daemon, which does not require X
support at all.  It is meant for headless machines you would want to
monitor remotely.

- gkrellm2 which is the front-end which can monitor the local machine
and/or any machine running gkrellmd.

USE=X builds both parts.
USE=-X builds only the monitoring daemon.

I believe this is a useful distinction.

The plugins are only relevant when you have the GUI front-end in place,
except that there may be some plugins that have a gkrellmd-equivalent
part, in which case that ebuild should set IUSE=X and do its own
checking.

I suppose the alternative would be to split the ebuild into 'gkrellm'
and 'gkrellmd' ebuilds, which would indeed remove the need for the
'built_with_use' check.  How is this normally done for other packages
that have, for example, both a client and server part?

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] New eclass: gkrellm-plugin

2007-03-08 Thread Jim Ramsay
Marien Zwart wrote:
 On Thu, Mar 08, 2007 at 11:19:20AM -0600, Jim Ramsay wrote:
  gkrellm-plugin_pkg_setup() {
  if ! built_with_use app-admin/gkrellm X  \
  ! has X ${IUSE}; then
  eerror This plugin requires the X frontend of
  gkrellm. eerror Please re-emerge app-admin/gkrellm with USE=\X\
  die Please re-emerge app-admin/gkrellm with
  USE=\X\ fi
  }
 
 Any chance of plugins existing (or appearing in the future) that work
 with a USE=-X gkrellm and a USE=X gkrellm the same way? In that case
 that check will not do the right thing. Perhaps add a var the plugin
 ebuild can set to indicate it does not need gkrellm built with X even
 though the plugin has no X USE flag?
 
 This will also error out if you try to build a plugin that has the X
 USE flag with both the plugin and gkrellm itself built with -X, you
 probably meant to check for use X too?

Well, my intention was that such a plugin would do its own
built_with_use checking, but I see your point, and I think that having a
Don't check for X variable the ebuild can optionally set would be a
better approach than mine - That way such an ebuild could do its own
magic based on 'built_with_use gkrellm X' without having to have
IUSE=X.

Thanks!

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] New eclass: gkrellm-plugin

2007-03-08 Thread Jim Ramsay
Attached is version 2 of my draft eclass.  I have incorporated the
excellent changes suggested here, and it seems to be working great on
my local overlay.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

#
# Original Author: Jim Ramsay [EMAIL PROTECTED]
#
# Purpose:
#   Provides common methods used by (almost) all gkrellm plugins:
#- Sets up default dependencies
#- Adds pkg_setup check to ensure gkrellm was built with USE=X (bug
#167227)
#- Provides 'gkrellm-plugin_dir' function in lieu of hard-coding the plugins
#directory (which *may* change in the future)
#- Provides the most common src_install method to avoid code duplication.
#
# Utility Routines:
#   gkrellm-plugin_dir - Returns the gkrellm-2 plugin directory
#
# Environment:
#   For pkg_setup:
# PLUGIN_NO_XCHECK - If set, the default check ensuring that gkrellm2 is
#   built with USE=X is skipped, allowing plugins to build with the
#   gkrellmd-only case.  Defaults to unset.
#   For src_install:
# PLUGIN_SO - The name of the plugin's .so file which will be installed in
#   the plugin dir.  Defaults to ${PN}.so.
# PLUGIN_DOCS - An optional list of docs to be installed.  Defaults to
# unset.
#

inherit multilib eutils

RDEPEND==app-admin/gkrellm-2*
DEPEND=${RDEPEND}
dev-util/pkgconfig

gkrellm-plugin_dir() {
echo /usr/$(get_libdir)/gkrellm2/plugins
}

gkrellm-plugin_pkg_setup() {
if [[ -z ${PLUGIN_NO_XCHECK} ]]  
! built_with_use app-admin/gkrellm X; then
eerror This plugin requires the X frontend of gkrellm.
eerror Please re-emerge app-admin/gkrellm with USE=\X\
die Please re-emerge app-admin/gkrellm with USE=\X\
fi
}

gkrellm-plugin_src_install() {
insinto $(gkrellm-plugin_dir)
doins ${PLUGIN_SO:-${PN}.so} || die Plugin shared library was not 
installed

DDOCS=README* Change* AUTHORS FAQ TODO INSTALL

for doc in ${DDOCS}; do
[ -s $doc ]  dodoc $doc
done

[ -n ${PLUGIN_DOCS} ]  dodoc ${PLUGIN_DOCS}
}

EXPORT_FUNCTIONS pkg_setup src_install


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: All gkrellm-1 plugins

2007-02-22 Thread Jim Ramsay
# Jim Ramsay [EMAIL PROTECTED] (22 Feb 2007)
# Pending removal 24 Mar 2007, bug 151446
# These gkrellm-1 plugins have no gkrellm-2 equivalent
x11-plugins/gkrellm-console
x11-plugins/gkrellmitime
x11-plugins/gkrellm-logwatch
x11-plugins/gkrellmouse
x11-plugins/gkrellm-sensors
x11-plugins/gkrellmwho

(Well, except for gkrellmwho, which is replaced by a different package:
gkrellmwho2)

This is in preparation for banishing gkrellm-1 from the tree, which
in turn is because it depends on gtk+-1.2, which is apparently going
away some time.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Last Rites: All gkrellm-1 plugins

2007-02-22 Thread Jim Ramsay
Jim Ramsay wrote:
 x11-plugins/gkrellmitime

My mistake, this should not have been masked, and is no longer masked.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox)


signature.asc
Description: PGP signature


Re: [gentoo-dev] app-admin/gkrellm + x11-plugins/gkrell* stuff needs a maintainer

2007-02-20 Thread Jim Ramsay
Jakub Moc wrote:
 The maintainer has been MIA for quite some time and has a retirement
 bug open, so the bugs are piling up.
 
 Please, have a look at the tracker Bug 165185 if you are interested in
 taking over this.
 
 Basically, gkrellm-1* and ebuilds that depend on it need to be removed
 (Bug 151446), couple of version bumps and couple of other bugs that
 need some loving.

Well, no one else has taken this yet, so I suppose I will, since I
still use the beast :)

Not sure what herd I should throw it/them in, though, as most of these
packages (er, the ones that even *have* a metadata.xml) have 'no-herd'
in them... Maybe 'desktop-dock' is most appropriate?

-- 
Jim Ramsay
Gentoo/Linux Developer (rox)


signature.asc
Description: PGP signature


[gentoo-dev] A major change coming in the rox packages

2007-02-08 Thread Jim Ramsay
I am planning on moving the install locations of all the rox-base/* and
rox-extra/* applications from their current location (/usr/lib/rox) to
something a little more FHS-correct[1] and tolerant of multilib support.

The main reason for this change is that I got a bug from amd64 because
the /usr/lib path is hard-coded all over the place (ie, not multilib
compliant), but it's always sort of bugged me that these packages are
in /usr/lib - They're not actually libaries (except for rox-clib).
These rox applications are a new special case that don't fit into the
FHS, called Application Directories[2], and I need a good place to
put them.

Please note that every rox application creates a symlink in /usr/bin
which runs the application regardless of where it exists in the
filesystem, so from an end-user perspective this doesn't really
matter.  (Except a small bit of migration when I actually do move these
packages, which will be the topic for another day).

I'd like input from any interested parties on where the proper
location may be.  Here are some ideas with their justifications and
problems, as I see them:

/usr/libexec/rox - libexec isn't actually in the FHS (that I could
  see), and /usr/libexec is usually assumed to contain executable
  code, so it may be a safe place to put things.  That said, libexec
  is considered by some to be dead or about to disappear[3], so it may
  not be the right place to go.

/usr/rox - This isn't in the FHS either, I would be creating it.  The
  problem is that the FHS specifically says Large software packages
  must not use a direct subdirectory under the /usr hierarchy.

/opt/rox - This is FHS-safe, but the gentoo convention is to
  reserve /opt for binary packages only, and these appdirs are not.

/usr/bin/rox-desktop - This may be the most correct, since the FHS
  does allow subdirectories here, and doesn't explicitly prohibit new
  ones. Also, these are actually executable commands.  The problem is
  that (at least considering my currently installed packages) no one
  else has created any subdirectories in /usr/bin.  I don't know if
  that's a problem.  Also, I can't use the name 'rox' in this place
  because that conflicts with a filename from rox-base/rox.

I'm currently tending toward one of the last two, but am open to
suggestions to persuade me toward or away from any of these, or
any other, better suggestion.

Inside this new location I will be further reorganizing the packages so
most apps will be inside an 'Apps' subdirectory of this new location,
and rox-lib will be in a 'lib' subdirectory.

Now, one last thing to consider is rox-clib, which is actually a C
library.  However, thanks to the way rox software works with application
directories, it doesn't need to be in the normal library search
path at all to function properly.  I think that it would make
sense then for me to also take it out of /usr/lib altogether, and
instead put it alongside rox-lib in the new location.  It already has
an internal directory structure that provides a unique location for any
32- versus 64-bit versions of itself.

Thanks for your help!

[1] http://www.pathname.com/fhs/
[2] http://rox.sourceforge.net/desktop/AppDirs
[3] http://article.gmane.org/gmane.linux.gentoo.devel/44751 (and others)

-- 
Jim Ramsay
Gentoo/Linux Developer (rox)


signature.asc
Description: PGP signature


Re: [gentoo-dev] A major change coming in the rox packages

2007-02-08 Thread Jim Ramsay
Diego 'Flameeyes' Pettenò wrote:
 On Thursday 08 February 2007, Thomas Rösner wrote:
  AFAIR App Dirs provide internal arch distinction, so why not just put it
  in /usr/share/rox?
 
 /usr/share is not a good place for any kind of executable.

Also, after compiling the AppDirs (in the few cases where these aren't
just python source) I remove the src directory, so it will not be
recompiled for other archs.  The only thing you get in the appdir as
installed by portage is the binary for your arch.  In the case of
python, maybe this wouldn't matter as much.

 /usr/lib is more suitable for the purpose.

How would you then reconcile the issues raised in this bug[1]
regarding /usr/lib and multilib support?

I suppose I still don't know enough about multilib support to know if
putting things in /usr/$(get_libdir)/rox would be correct, or if I
should just hardcode to /usr/lib and close that bug as INVALID.  Then I
would have to somehow deal with the special case of rox-clib[2], since
it really is a library but it does not have to be in the normal ld
search path.  I suppose that could actually go in /usr/$(get_libdir)
without much trouble.

[1] http://bugs.gentoo.org/show_bug.cgi?id=164816
[2] http://bugs.gentoo.org/show_bug.cgi?id=155983

-- 
Jim Ramsay
Gentoo/Linux Developer (rox)


signature.asc
Description: PGP signature


Re: [gentoo-dev] A major change coming in the rox packages

2007-02-08 Thread Jim Ramsay
Ed Catmur wrote:
 On Thu, 2007-02-08 at 11:05 -0600, Jim Ramsay wrote:
  I am planning on moving the install locations of all the rox-base/* and
  rox-extra/* applications from their current location (/usr/lib/rox) to
  something a little more FHS-correct[1] and tolerant of multilib support.
 
 Have you considered /usr/lib/misc/rox?

Hmmm... that's actually not a bad alternative to /usr/libexec I suppose
(though it's also not in the FHS), but will features=multilib-strict
complain when I put rox-clib in /usr/lib/misc/rox/?  I suspect it
will.[1]

So then all I need to do is somehow deal with rox-clib, which may be
safe to put in /usr/$(get_libdir), which would satisfy the multilib
folks...

[1] http://bugs.gentoo.org/show_bug.cgi?id=155983

-- 
Jim Ramsay
Gentoo/Linux Developer (rox)


signature.asc
Description: PGP signature


Re: [gentoo-dev] A major change coming in the rox packages

2007-02-08 Thread Jim Ramsay
Diego 'Flameeyes' Pettenò wrote:
 On Thursday 08 February 2007, Jim Ramsay wrote:
  How would you then reconcile the issues raised in this bug[1]
  regarding /usr/lib and multilib support?
 
 /usr/lib/misc most likely, or /usr/libexec as you prefer, considering that 
 the 
 policy about that is still unwritten and probably will not appear in the next 
 few months either.

My only fear with going with /usr/lib/misc or /usr/libexec is that
the actual move won't be pretty (I'll have to come up with some
way for users to migrate some config files), so I'd prefer to only have
to do it once.

That's why I want to be sure I consider every viable option and pick the
best location: so it's less likely I have to do it all again in 6
months.

Then again, maybe my migration strategy will be so good it will be easy
to do a second time :)

-- 
Jim Ramsay
Gentoo/Linux Developer (rox)


signature.asc
Description: PGP signature


Re: [gentoo-dev] make_desktop_entry in eutils.eclass

2007-02-01 Thread Jim Ramsay
Thomas de Grenier de Latour wrote:
 On Wed, 31 Jan 2007 23:30:53 -0500, Mike Frysinger [EMAIL PROTECTED]
 wrote:
 
  about the only thing that'd work is an additional parameter called
  cruft that'd be passed unfiltered into the .desktop file
 
 You can also imagine a -v switch, which would make this function print
 the full path (with its $D prefix) of the file.desktop it has created.
 This way, people could do:
 
   src_install() {
 ...
 local desktop_file=$(make_desktop_entry -v ...) || die
 echo MimeType=...   ${desktop_file}
 ...
   }
 
 I don't say this solution is better than the cruft parameter though,
 it's really a matter of taste.

Nice.  I like this idea, and humbly request that someone implement it
in this way, or give me permission to do so.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox)


signature.asc
Description: PGP signature


Re: [gentoo-dev] make_desktop_entry in eutils.eclass

2007-01-31 Thread Jim Ramsay
Mike Frysinger wrote:
 On Tuesday 30 January 2007 16:10, Jim Ramsay wrote:
  In other words, I propose that this function should probably do
  'basename' on $exec before using it for the .desktop filename.
 
 no ... the point of using $exec is to make sure the .desktop file is unique
 
 i'll change it to sanitize the filename and turn them into underscores

Sure, but the name is already based on $exec AND ${PN} (and
SLOT too if SLOT != 0), so the uniqueness is already guaranteed
per-package, it would just be a matter of the package maintainer not
using the same exec twice in the same package, which probably
wouldn't even happen anyway.  I still think basename would be
sufficient.

  I propose an optional environment variable an ebuild can set before
  calling make_desktop_entry, called DESKTOP_BASENAME, which would be
  the basename of the file (not including the .desktop suffix) that the
  function would use (if set) to create the file.
 
 env vars to functions are lame

In that case it could be another optional parameter instead.

  3 - Allow me to add other important settings like 'NoDisplay',
  'OnlyShowIn', and/or 'MimeType'.
 
 at this point, you might as well write your own .desktop file

Personally I'd rather just add one line to my ebuild as opposed to
creating and maintaining a .desktop file in the files directory.  This
would just add a useful feature for those who want that level of
flexibility.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox)


signature.asc
Description: PGP signature


[gentoo-dev] make_desktop_entry in eutils.eclass

2007-01-30 Thread Jim Ramsay
I have a few suggestions for the make_desktop_entry function in
eutils.eclass:

1 - Allow me to pass in a full application path.  If you pass in the
full path to an executable as the first argument, it comes up with a
crazy filename like this:

  
/var/tmp/portage/rox-base/mime-editor-0.5/temp//usr/lib/rox/MIME-Editor/AppRun-mime-editor.desktop

When a more appropriate name would be:

  /var/tmp/portage/rox-base/mime-editor-0.5/temp/AppRun-mime-editor.desktop

In other words, I propose that this function should probably do
'basename' on $exec before using it for the .desktop filename.

2 - Allow me to explicitly set the name of the .desktop file.  This
would perhaps solve #1 above as well.

I propose an optional environment variable an ebuild can set before
calling make_desktop_entry, called DESKTOP_BASENAME, which would be
the basename of the file (not including the .desktop suffix) that the
function would use (if set) to create the file.

3 - Allow me to add other important settings like 'NoDisplay',
'OnlyShowIn', and/or 'MimeType'.

I propose an optional environment variable 'DESKTOP_EXTRAS' that the
ebuild could set before calling make_desktop_entry.  This would be an
actual verbatim (newline-delimited) copy of the extra lines to be added
to the desktop file, for example:

DESKTOP_EXTRAS=OnlyShowIn=Yes

or

DESKTOP_EXTRAS=MimeType=text/plain
NoDisplay=Yes

Any objections?  Suggestions?  I would be willing to add these myself
if no one else is.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox)


signature.asc
Description: PGP signature


Re: [gentoo-dev] local use flag cleanup

2006-11-09 Thread Jim Ramsay
Steve Dibb wrote:
 I've gone through some of them and here are the ones I suggest get
 moved to global, since the use flag description / functionality is
 the same or similar enough to mean support for $x:

What about 'libnotify'?

As far as I can see all 11 entries in use.local.desc amount to the same
thing, though the descriptions vary slightly.

(The one for gnome-extra/zenity is a typo: it says it uses 'libinotify'
but actually RDEPENDs on =x11-libs/libnotify-0.4.1)

-- 
Jim Ramsay
Gentoo/Linux Developer (rox)


signature.asc
Description: PGP signature


Re: [gentoo-dev] The Dreaded herd tag

2006-10-30 Thread Jim Ramsay
On Mon, Oct 30, 2006 at 11:09:53AM -0500, Chris Gianelloni wrote:
 On Sat, 2006-10-28 at 08:28 +0200, George Shapovalov wrote:
  Wanna guess how many of those happen to be stale?
 
 I would suspect fewer than you think.  As an example, I have a few
 packages which belong to no herd, but have me listed as maintainer.
 Many of the no-herd packages are the same.  Not being grouped with other
 packages doesn't mean it is unmaintained.

I agree.  All my rox stuff (rox-base/* and rox-extra/*) kind of
fits into many different herds.  Or no herd.  Or maybe its own
new herd.

 So this bears the question, what is the proper solution?
 
 Make herd optional?
 Force the maintainer's email into herd for packages without a herd?

Or force each maintainer of herdless packages to create their own
special herd.  Which I may end up doing with my rox packages
anyway.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox)


pgpzXvQNKPJtw.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Global USE flags (Was: mplayer global use flag)

2006-10-30 Thread Jim Ramsay
On Sat, Oct 28, 2006 at 05:23:50PM +0200, arfrever wrote:
 In connection with latest globalization of mplayer USE flag I would like to 
 ask for globalizing cairo, openexr and udev USE flags. These flags are used 
 by enough amount of packages.

I vote for a 'libnotify' global USE flag.  It is used now by 11
packages in use.local.desc and does the same thing in all of them
- Allows popups via libnotify (or dbus+notification-daemon, which
amounts to the same thing).

-- 
Jim Ramsay
Gentoo/Linux Developer (rox)


pgppPbZjuRCvZ.pgp
Description: PGP signature


Re: [gentoo-dev] New Developer: Jeffrey Gardner (je_fro)

2006-10-06 Thread Jim Ramsay
Petteri Räty wrote:
 He has played bass guitar for 20 years or so. Considering that he has
 been doing it before I was born, one would think he is some kind of an
 expert but maybe he is just modest when he says that he could be a LOT
 better.

Excellent, another member of the soon-to-be-famous Gentoo rock band! I
think Joshua Jackson (tsunam) has already volunteered to be the
singer :)  What is it, three new musical devs so far in the last 2
weeks?

-- 
Jim Ramsay
Gentoo/Linux Developer (rox)


signature.asc
Description: PGP signature