Re: [gentoo-dev] [GLEP] scm package version suffix

2007-12-09 Thread Nirbheek Chauhan
On Dec 10, 2007 12:48 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
> Feature as opposed to release branches would still have to be separate
> packages, especially if you need to depend upon a particular feature.

I don't understand how having to depend on a particular feature causes
one to need a separate package. Infact, if a branch has a new feature
that I want to test against a lot of packages, having a separate
package means I have to either || ( sys-apps/package
sys-apps/package-branch ) for all packages that I want to test it
against, or make a virtual package sys-apps/package- which just
depends on sys-apps/package-branch. The former is too much work
sometimes, and the latter just brings us full circle.

Why not just have something like
sys-devel/gcc-4.2.3_p20071127-scm_b${BRANCHNAME}-r1 ?
It should be easy to parse since it'll always be after "scm" and will
be the last portion of the version string before "-rN".
In case ${BRANCHNAME} itself ends in "-rN" (highly unlikely), the
entire version string could be made to end with "-r0" to signify that
it's revision 0 and not revision N.

Also, releases are often tagged rather than being branched out, which
would have to be kept in mind as well.

-- 
~Nirbheek Chauhan
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [GLEP] scm package version suffix

2007-12-09 Thread Ciaran McCreesh
On Sun, 9 Dec 2007 20:31:46 -0800
Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> On 18:57 Sun 09 Dec , Ciaran McCreesh wrote:
> > On Sun, 09 Dec 2007 19:45:27 +0100
> > Jan Kundrát <[EMAIL PROTECTED]> wrote:
> > > What is the point of using version information along the scm
> > > suffix?
> > 
> > Branches.
> 
> How would I handle branches that aren't numbers but are instead
> strings, which seems to grow increasingly more common as VCSs can
> handle it? Just give them arbitrary numbers?

Feature as opposed to release branches would still have to be separate
packages, especially if you need to depend upon a particular feature.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/xmltv: ChangeLog xmltv-0.5.50.ebuild

2007-12-09 Thread Donnie Berkholz
On 11:08 Sat 08 Dec , Matteo Azzali (mattepiu) wrote:
> 1.1  media-tv/xmltv/xmltv-0.5.50.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/xmltv/xmltv-0.5.50.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/xmltv/xmltv-0.5.50.ebuild?rev=1.1&content-type=text/plain

> make_config() {
>   # Never except default configuration
>   echo "no"
> 
>   # Enable Australian
>   #use au && echo "yes" || echo "no"
>   # Enable Agentina
>   use ar && echo "yes" || echo "no"
>   # Enable Brazil
>   #use br && echo "yes" || echo "no"
>   # Enable Brazil Cable
>   use brnet && echo "yes" || echo "no"

... snip more ...

You could simplify this with the yesno() function that's in a number of 
ebuilds around the tree, for example sys-apps/less.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [GLEP] scm package version suffix

2007-12-09 Thread Donnie Berkholz
On 18:57 Sun 09 Dec , Ciaran McCreesh wrote:
> On Sun, 09 Dec 2007 19:45:27 +0100
> Jan Kundrát <[EMAIL PROTECTED]> wrote:
> > What is the point of using version information along the scm suffix?
> 
> Branches.

How would I handle branches that aren't numbers but are instead strings, 
which seems to grow increasingly more common as VCSs can handle it? Just 
give them arbitrary numbers?

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Last Rites: December 2nd - 9th, 2007

2007-12-09 Thread Ryan Hill
Attached are the packages marked for removal this week.


-- 
looks like christmas at fifty-five degrees
this latitude weakens my knees
EFFD 380E 047A 4B51 D2BD  C64F 8AA8 8346 F9A4 0662 (0xF9A40662)
www-apps/viewcvs   Gunnar Wrobel <[EMAIL PROTECTED]>02 Jan 
2008
app-emacs/md5  Ulrich Mueller <[EMAIL PROTECTED]>  04 
Jan 2008
app-emacs/sha1 Ulrich Mueller <[EMAIL PROTECTED]>  04 
Jan 2008
net-www/pears  Ryan Hill <[EMAIL PROTECTED]> 04 Jan 2008
app-accessibility/festival-gaim Olivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
gnustep-base/gnustep-env   Bernard Cafarelli <[EMAIL PROTECTED]>  08 Jan 
2008
gnustep-libs/artresources  Bernard Cafarelli <[EMAIL PROTECTED]>  08 Jan 
2008
net-im/gaim-bloggerOlivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
net-im/gaim-bnet   Olivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
net-im/gaim-meanwhile  Olivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
net-im/gaimOlivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
net-im/gaim-snpp   Olivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-plugins/autoprofileOlivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-plugins/bangexec   Olivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-plugins/gaim-assistant Olivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-plugins/gaim-encryptionOlivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-plugins/gaim-extprefs  Olivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-plugins/gaim-galagoOlivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-plugins/gaim-hotkeys   Olivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-plugins/gaim-latex Olivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-plugins/gaimosdOlivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-plugins/gaim-otr   Olivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-plugins/gaim-rhythmbox Olivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-plugins/gaim-slashexec Olivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-plugins/gaim-xfire Olivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-plugins/ignorance  Olivier Crete <[EMAIL PROTECTED]>08 Jan 
2008
x11-themes/gaim-smileysOlivier Crete <[EMAIL PROTECTED]>08 Jan 
2008



 
 Package:
 Removal date:
 Contact:
 



 http://packages.gentoo.org/package/www-apps/viewcvs";>www-apps/viewcvs
 02 Jan 2008
 Gunnar Wrobel
 


 http://packages.gentoo.org/package/app-emacs/md5";>app-emacs/md5
 04 Jan 2008
 Ulrich Mueller
 


 http://packages.gentoo.org/package/app-emacs/sha1";>app-emacs/sha1
 04 Jan 2008
 Ulrich Mueller
 


 http://packages.gentoo.org/package/net-www/pears";>net-www/pears
 04 Jan 2008
 Ryan Hill
 


 http://packages.gentoo.org/package/app-accessibility/festival-gaim";>app-accessibility/festival-gaim
 08 Jan 2008
 Olivier Crete
 


 http://packages.gentoo.org/package/gnustep-base/gnustep-env";>gnustep-base/gnustep-env
 08 Jan 2008
 Bernard Cafarelli
 


 http://packages.gentoo.org/package/gnustep-libs/artresources";>gnustep-libs/artresources
 08 Jan 2008
 Bernard Cafarelli
 


 http://packages.gentoo.org/package/net-im/gaim-blogger";>net-im/gaim-blogger
 08 Jan 2008
 Olivier Crete
 


 http://packages.gentoo.org/package/net-im/gaim-bnet";>net-im/gaim-bnet
 08 Jan 2008
 Olivier Crete
 


 http://packages.gentoo.org/package/net-im/gaim-meanwhile";>net-im/gaim-meanwhile
 08 Jan 2008
 Olivier Crete
 


 http://packages.gentoo.org/package/net-im/gaim";>net-im/gaim
 08 Jan 2008
 Olivier Crete
 


 http://packages.gentoo.org/package/net-im/gaim-snpp";>net-im/gaim-snpp
 08 Jan 2008
 Olivier Crete
 


 http://packages.gentoo.org/package/x11-plugins/autoprofile";>x11-plugins/autoprofile
 08 Jan 2008
 Olivier Crete
 


 http://packages.gentoo.org/package/x11-plugins/bangexec";>x11-plugins/bangexec
 08 Jan 2008
 Olivier Crete
 


 http://packages.gentoo.org/package/x11-plugins/gaim-assistant";>x11-plugins/gaim-assistant
 08 Jan 2008
 Olivier Crete
 


 http://packages.gentoo.org/package/x11-plugins/gaim-encryption";>x11-plugins/gaim-encryption
 08 Jan 2008
 Olivier Crete
 


 http://packages.gentoo.org/package/x11-plugins/gaim-extprefs";>x11-plugins/gaim-extprefs
 08 Jan 2008
 Olivier Crete
 


 http://packages.gentoo.org/package/x11-plugins/gaim-galago";>x11-plugins/gaim-galago
 08 Jan 2008
 Olivier Crete
 


 http://packages.gentoo.org/package/x11-plugins/gaim-hotkeys";>x11-plugins/gaim-hotkeys
 08 Jan 2008
 Olivier Crete
 


 http://packages.gentoo.org/package/x11-plugins/gaim-latex";>x11-plugins/gaim-latex
 08 Jan 2008
 Olivier Crete
 


 http://packages.gentoo.org/package/x11-plugins/gaimosd";>x11-plugins/gaimosd
 08 Jan 2008
 Olivier Crete
 


 http://packages.gento

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2007-12-09 23h59 UTC

2007-12-09 Thread Robin H. Johnson
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2007-12-09 23h59 UTC.

Removals:
games-arcade/ultrastar-songs2007-12-03 21:20:49 tupone
dev-java/sun-jaf-bin2007-12-05 01:51:12 
betelgeuse

Additions:
x11-themes/qtcurve-qt4  2007-12-03 09:43:08 nelchael
media-plugins/vdr-joystick  2007-12-03 20:47:01 
hd_brummy
games-arcade/ultrastar-songs2007-12-03 21:08:34 tupone
dev-perl/TextToHTML 2007-12-03 22:56:46 
hd_brummy
rox-base/zeroinstall-injector   2007-12-04 17:02:45 lack
net-www/diamondx2007-12-05 02:06:59 jer
x11-themes/xxv-skins2007-12-05 20:35:24 
hd_brummy
dev-php/PEAR-HTML_QuickForm_advmultiselect  2007-12-06 00:11:49 jokey
sys-fs/owfs 2007-12-06 15:00:50 wschlich
sys-apps/dtc2007-12-07 02:20:32 lu_zero
dev-python/pyfltk   2007-12-07 11:24:11 bicatali
dev-embedded/gnome-avrdude  2007-12-09 16:39:43 calchan

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
games-arcade/ultrastar-songs,removed,tupone,2007-12-03 21:20:49
dev-java/sun-jaf-bin,removed,betelgeuse,2007-12-05 01:51:12
Added Packages:
x11-themes/qtcurve-qt4,added,nelchael,2007-12-03 09:43:08
media-plugins/vdr-joystick,added,hd_brummy,2007-12-03 20:47:01
games-arcade/ultrastar-songs,added,tupone,2007-12-03 21:08:34
dev-perl/TextToHTML,added,hd_brummy,2007-12-03 22:56:46
rox-base/zeroinstall-injector,added,lack,2007-12-04 17:02:45
net-www/diamondx,added,jer,2007-12-05 02:06:59
x11-themes/xxv-skins,added,hd_brummy,2007-12-05 20:35:24
dev-php/PEAR-HTML_QuickForm_advmultiselect,added,jokey,2007-12-06 00:11:49
sys-fs/owfs,added,wschlich,2007-12-06 15:00:50
sys-apps/dtc,added,lu_zero,2007-12-07 02:20:32
dev-python/pyfltk,added,bicatali,2007-12-07 11:24:11
dev-embedded/gnome-avrdude,added,calchan,2007-12-09 16:39:43

Done.

[gentoo-dev] Re: [GLEP] scm package version suffix

2007-12-09 Thread Ryan Hill
� wrote:
>> Specification
>> =
>>
>> ``scm`` is a special suffix. It can be used on its own, but also in any other
>> valid version spec, just before the place where revision would go. And just 
>> like
>> revision it can be used only once in a version spec, e.g.:
>>
>>   *  ``cat/pkg-1.0_alpha0-scm``
>>   *  ``cat/pkg-1.0_alpha-scm``
>>   *  ``cat/pkg-1.0-scm-r3``
>>   *  ``cat/pkg-1-scm``
>>   *  ``cat/pkg-1-scm-r2``
>>   *  ``cat/pkg-scm``
>>
>> These package atoms are sorted in ascending order (see `Version 
>> Comparison`_).
> 
> What is the point of using version information along the scm suffix?
> From the logical POV, scm is a special decorator saying "this is a
> special tarball that can change in time and we don't know its version
> when parsing ebuild, we'd have to ask the repository". Surely I can
> think of uses for *revision* specification (as in "revision of the
> ebuild"), but why to support full version for scm packages?

for example:
sys-devel/gcc-4.2.3_p20071127-scm-r1 would be GCC 4.2 branch prerelease
with the 20071127 patchset and one ebuild revision.

or more generally, why go through the /extra/ trouble of /not/ allowing
normal version specifiers?

-- 
looks like christmas at fifty-five degrees
this latitude weakens my knees
EFFD 380E 047A 4B51 D2BD  C64F 8AA8 8346 F9A4 0662 (0xF9A40662)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [GLEP] scm package version suffix

2007-12-09 Thread Ciaran McCreesh
On Sun, 09 Dec 2007 19:45:27 +0100
Jan Kundrát <[EMAIL PROTECTED]> wrote:
> What is the point of using version information along the scm suffix?

Branches.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] [GLEP] scm package version suffix

2007-12-09 Thread Jan Kundrát
> Specification
> =
> 
> ``scm`` is a special suffix. It can be used on its own, but also in any other
> valid version spec, just before the place where revision would go. And just 
> like
> revision it can be used only once in a version spec, e.g.:
> 
>   *  ``cat/pkg-1.0_alpha0-scm``
>   *  ``cat/pkg-1.0_alpha-scm``
>   *  ``cat/pkg-1.0-scm-r3``
>   *  ``cat/pkg-1-scm``
>   *  ``cat/pkg-1-scm-r2``
>   *  ``cat/pkg-scm``
> 
> These package atoms are sorted in ascending order (see `Version Comparison`_).

What is the point of using version information along the scm suffix?
From the logical POV, scm is a special decorator saying "this is a
special tarball that can change in time and we don't know its version
when parsing ebuild, we'd have to ask the repository". Surely I can
think of uses for *revision* specification (as in "revision of the
ebuild"), but why to support full version for scm packages?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [GLEP] scm package version suffix

2007-12-09 Thread Piotr Jaroszyński
On Sunday 09 of December 2007 18:52:22 Petteri Räty wrote:
> "Portage versions prior to 2.1.2.12 (included in 2007.0) doesn't handle
> arbitrary
> version suffixes"
>
> doesn't --> don't

thanks, fixed.

-- 
Best Regards,
Piotr Jaroszyński
--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [GLEP] scm package version suffix

2007-12-09 Thread Petteri Räty
"Portage versions prior to 2.1.2.12 (included in 2007.0) doesn't handle
arbitrary
version suffixes"

doesn't --> don't



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [GLEP] scm package version suffix

2007-12-09 Thread Piotr Jaroszyński
On Sunday 09 of December 2007 17:18:08 Josh Sled wrote:
> Piotr Jaroszyński <[EMAIL PROTECTED]> writes:
> > Current html version available here:
> > http://dev.gentoo.org/~peper/glep-0054.html
>
> Until reading the abstract, I thought this was Scheme related.
>
> I'd suggest "-vc" (version controlled) or "-vcs" instead.

$ wtf vc
vc: nothing appropriate
$ wtf vcs
vcs  (4)  - virtual console memory
$ wtf scm
SCM: software configuration management
source code management

scm wins :)

-- 
Best Regards,
Piotr Jaroszyński
--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [GLEP] scm package version suffix

2007-12-09 Thread Josh Sled
Piotr Jaroszyński <[EMAIL PROTECTED]> writes:
> Current html version available here:
> http://dev.gentoo.org/~peper/glep-0054.html

Until reading the abstract, I thought this was Scheme related.

I'd suggest "-vc" (version controlled) or "-vcs" instead.

(...not that it matters much, of course.)

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpnfRvZpove4.pgp
Description: PGP signature


[gentoo-dev] [GLEP] scm package version suffix

2007-12-09 Thread Piotr Jaroszyński
Hello,

Attaching the GLEP source.

Current html version available here:
http://dev.gentoo.org/~peper/glep-0054.html

-- 
Best Regards,
Piotr Jaroszyński
GLEP: 54
Title: scm package version suffix
Version: $Revision: $
Last-Modified: $Date: $
Author: Piotr Jaroszyński <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 09-Dec-2007
Post-History: 09-Dec-2007

Abstract


This GLEP proposes addition of a new special package version suffix - ``scm`` -
for ebuilds checking out source directly from a source code management system.

Motivation
==

Currently there is no standard way of marking SCM ebuilds. Using  as the
version is pretty common, but it is handled like any other ebuild and hence
portage cannot provide any additional features for packages with such a version.
Another way is adding separate package with -cvs suffix in its name, but that
forces to use ``|| ( cat/pkg cat/pkg-cvs )`` dependencies. The closest to what
is proposed in this GLEP is the ``cvs`` version part, but its implementation is
of very limited use. It has strange comparison rules, no documentation, has
never been used in the tree and has a misleading name.

The possibility for package managers to recognise SCM ebuilds would allow them
to add features dedicated specially to said ebuilds. One such feature could be
automatic re-installation of SCM packages once a day or week, but that's beyond
this GLEP.

Specification
=

``scm`` is a special suffix. It can be used on its own, but also in any other
valid version spec, just before the place where revision would go. And just like
revision it can be used only once in a version spec, e.g.:

  *  ``cat/pkg-1.0_alpha0-scm``
  *  ``cat/pkg-1.0_alpha-scm``
  *  ``cat/pkg-1.0-scm-r3``
  *  ``cat/pkg-1-scm``
  *  ``cat/pkg-1-scm-r2``
  *  ``cat/pkg-scm``

These package atoms are sorted in ascending order (see `Version Comparison`_).

Version Comparison
==

The addition of the scm suffix yields changes in version comparison:

  *  When comparing version components from left to right the scm component has 
the
 highest priority.
  *  Current suffixes with no number part no longer default to zero if they are
 followed by an scm suffix. If that's the case the number part is considered
 to be of a maximum value. Hence ``1_alpha2-scm < 1_alpha-scm``, but still
 ``1_alpha == 1_alpha0``.

Example parsing:

  *  ``cat/pkg-scm > cat/pkg-1``
   When parsing from left to right the first difference is ``scm`` and
   ``1``. ``cat/pkg-scm`` wins.
  *  ``cat/pkg-1-scm > cat/pkg-1.0-scm``
   When parsing from left to right the first difference is ``scm`` and
   ``0``. ``cat/pkg-1-scm`` wins.
  *  ``cat/pkg-1_alpha-scm > cat/pkg-1_alpha1-scm``
   In the first package version ``alpha`` doesn't have a number part *and*
   is followed by an ``scm`` suffix, hence it is considered to have a 
maximum
   value as the number part. When parsing from left to right the first
   difference is the number part of the ``alpha`` suffix. Maximum value
   yielded by the following ``scm`` suffix wins with ``1``.

List of version specs in ascending order:

  *  ``1``
  *  ``1.1-scm``
  *  ``1.2_alpha-scm``
  *  ``1.2_beta_p``
  *  ``1.2_beta_p0-scm``
  *  ``1.2_beta_p1-scm``
  *  ``1.2_beta_p-scm``
  *  ``1.2_beta1_p-scm``
  *  ``1.2_beta10``
  *  ``1.2_beta10_p1-scm``
  *  ``1.2_beta10-scm``
  *  ``1.2_beta-scm``
  *  ``1.2``
  *  ``1.2-scm``
  *  ``1.2-scm-r1``
  *  ``1-scm``
  *  ``10``
  *  ``scm``
  *  ``scm-r3``


Backwards Compatibility
===

Portage versions prior to 2.1.2.12 (included in 2007.0) doesn't handle arbitrary
version suffixes and die during various tasks making portage hard or impossible
to use. Later versions just ignore them displaying warnings. Hence use of
``scm`` suffixes in gentoo-x86 tree will probably have to wait till 2008.0
release or later.

Copyright
=

This document has been placed in the public domain.

.. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :


Re: [gentoo-dev] New USE flags documentation

2007-12-09 Thread Santiago M. Mola
On Nov 24, 2007 4:19 PM, Doug Goldstein <[EMAIL PROTECTED]> wrote:
> Jose Luis Rivero wrote:
> > I'm not asking for an extra overhead of 'bureaucracy' (write specs,
> > mailling @dev, send to the council, etc.) but a bit more of communication
> > would be appreciated:
> >
> All the above is completely unnecessary and I would be happy to discuss
> details with you off list.

I'm not against the changes in metadata but I felt a bit angry when
the changes were made bypassing established processes and skipping the
feedback-rethinking cycle (as other people pointer out... ignoring the
community). So, I agree with people asking for freezing the use of the
new features until a GLEP is proposed, discussed and approved.

Regards,
Santiago

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] New USE flags documentation

2007-12-09 Thread Thilo Bangert
Jeroen Roovers <[EMAIL PROTECTED]> said:
> On Sat, 24 Nov 2007 15:10:58 +0100
>
> Thilo Bangert <[EMAIL PROTECTED]> wrote:
> > the idea is really great
> >
> > [...]
> >
> > now this needs to be [...] made mandatory for all ebuilds.
>
> Uh, what?
>
> Why? If the idea is that great, then why does it need to be mandatory?

This is one more way the maintainer can document the functionality of the 
ebuild. IMHO this documentation is so usefull that every ebuild should 
provide it.

see the recent blogpost by nichoj
http://technicalpickles.com/posts/pidgin-idle-time
which supports this reasoning.

regards
Thilo

>
>
> Kind regards,
>  JeR


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