Re: [gentoo-dev] The feature patch mess in the webalizer ebuild (and how to deal with it)

2010-03-10 Thread Alistair Bush
 Solution
 
 1) Add two new packages to the tree:
- app-admin/geolizer (/usr/bin/geolizer)
- app-admin/webalizer-xtended (/usr/bin/webalizer-xtended)
 
 2) Bump webalizer to 2.21 while
   - no longer applying either feature patch
   - removing use flag xtended
   - keeping now hollow use flag geoip to reduce breakage
 
 3) Close related bug 231859
https://bugs.gentoo.org/show_bug.cgi?id=231859
 
 I volunteer to do that.
 
 Any objections or suggestions?

+1  we really should be attempting to keep as close to upstream as possible.



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

2010-03-10 Thread Mike Frysinger
On Tuesday 09 March 2010 23:08:24 Sebastian Pipping wrote:
 We have about 500 bump request open at the moment:
 https://bugs.gentoo.org/buglist.cgi?quicksearch=bump
 
 I assume that quite a few of them would be no big deal to their
 maintainers in Gentoo.
 
 
 Bugday is occupying the first Saturday of the month: how about bumpday
 on the third Saturday of the month?  First bumpday could be March 20th,
 10 days from now.
 
 What do you think?

for the maintainer-needed ones, np.  for the ones with maintainers, i think 
you need an ack from someone first.
-mike


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


[gentoo-dev] Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Mike Frysinger
the front page of http://gentoo.org/ now links to a Google Calendar (see side 
bar).  this has been around for a while, but it seems it's been more of an 
underground thing, so it's time to raise its awareness.

like other aspects of Gentoo, all Gentoo developers have access to it to add 
their own events.  anything Gentoo related may be added of course !  meetings, 
events, scheduled package events, etc...

the access step requires a bit of help though -- simply e-mail me off list 
your gmail account and we can get you set up.  once you have access, you may 
easily pass it on to other Gentoo peeps.
-mike


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


Re: [gentoo-dev] Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Alex Alexander
On Wed, Mar 10, 2010 at 07:45:21AM -0500, Mike Frysinger wrote:
 the front page of http://gentoo.org/ now links to a Google Calendar (see side 
 bar).  this has been around for a while, but it seems it's been more of an 
 underground thing, so it's time to raise its awareness.
 
 like other aspects of Gentoo, all Gentoo developers have access to it to add 
 their own events.  anything Gentoo related may be added of course !  
 meetings, 
 events, scheduled package events, etc...
 
 the access step requires a bit of help though -- simply e-mail me off list 
 your gmail account and we can get you set up.  once you have access, you may 
 easily pass it on to other Gentoo peeps.
 -mike

excellent idea! thanks for taking the time to do this :)

i've added my gentoo email to my personal google account so you should be
able to add me using that, could you try?

thanks,
-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgp0zEFpLLvJM.pgp
Description: PGP signature


[gentoo-dev] Re: Python 3.1: Stabilization and news item

2010-03-10 Thread Christian Faulhammer
Hi,

Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org:

 All problems, which were blocking stabilization of Python 3, have
 been fixed. Stabilization of Python 3.1.2 is currently scheduled on
 2010-04-19. I'm attaching the news item for Python 3.1.

 Will add my comments for the whole thread here:

 As far as I can see, there is no danger to any program as long as
Python 3 is not set as system python.  As soon as the request is filed
I will install it on my stable systems and try it...for some weeks to
be absolutely sure nothing happens.  Then I have nothing against
marking it stable on x86 and will do so.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode

URL:http://gentoo.faulhammer.org/


signature.asc
Description: PGP signature


Re: [gentoo-dev] Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Mike Frysinger
On Wednesday 10 March 2010 07:56:42 Alex Alexander wrote:
 On Wed, Mar 10, 2010 at 07:45:21AM -0500, Mike Frysinger wrote:
  the front page of http://gentoo.org/ now links to a Google Calendar (see
  side bar).  this has been around for a while, but it seems it's been
  more of an underground thing, so it's time to raise its awareness.
  
  like other aspects of Gentoo, all Gentoo developers have access to it to
  add their own events.  anything Gentoo related may be added of course ! 
  meetings, events, scheduled package events, etc...
  
  the access step requires a bit of help though -- simply e-mail me off
  list your gmail account and we can get you set up.  once you have
  access, you may easily pass it on to other Gentoo peeps.
 
 excellent idea! thanks for taking the time to do this :)

sorry, i didnt mean to make it sound like this was my idea ... Diego put it 
together originally and it's slowly grown since

 i've added my gentoo email to my personal google account so you should be
 able to add me using that, could you try?

google didnt warn when i added, so presumably it worked
-mike


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


Re: [gentoo-dev] Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Alex Alexander
On Wed, Mar 10, 2010 at 08:18:11AM -0500, Mike Frysinger wrote:
 On Wednesday 10 March 2010 07:56:42 Alex Alexander wrote:
  On Wed, Mar 10, 2010 at 07:45:21AM -0500, Mike Frysinger wrote:
   the front page of http://gentoo.org/ now links to a Google Calendar (see
   side bar).  this has been around for a while, but it seems it's been
   more of an underground thing, so it's time to raise its awareness.
   
   like other aspects of Gentoo, all Gentoo developers have access to it to
   add their own events.  anything Gentoo related may be added of course ! 
   meetings, events, scheduled package events, etc...
   
   the access step requires a bit of help though -- simply e-mail me off
   list your gmail account and we can get you set up.  once you have
   access, you may easily pass it on to other Gentoo peeps.
  
  excellent idea! thanks for taking the time to do this :)
 
 sorry, i didnt mean to make it sound like this was my idea ... Diego put it 
 together originally and it's slowly grown since

  i've added my gentoo email to my personal google account so you should be
  able to add me using that, could you try?
 
 google didnt warn when i added, so presumably it worked
 -mike

it did, thanks
-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgpXOawPoPzEV.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Dror Levin
On Wed, Mar 10, 2010 at 14:45, Mike Frysinger vap...@gentoo.org wrote:

 the front page of http://gentoo.org/ now links to a Google Calendar (see
 side
 bar).  this has been around for a while, but it seems it's been more of an
 underground thing, so it's time to raise its awareness.

 like other aspects of Gentoo, all Gentoo developers have access to it to
 add
 their own events.  anything Gentoo related may be added of course !
  meetings,
 events, scheduled package events, etc...

 the access step requires a bit of help though -- simply e-mail me off list
 your gmail account and we can get you set up.  once you have access, you
 may
 easily pass it on to other Gentoo peeps.
 -mike


I added my gentoo mail to my google account, so it should now work. Please
add me :)

Thanks a lot,
Dror Levin


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

2010-03-10 Thread Ben de Groot
On 10 March 2010 06:17, Sebastian Pipping sp...@gentoo.org wrote:
 On 03/10/10 06:00, Joshua Saddler wrote:
 Bumpdays are otherwise a good idea, though I'm not sure why we need a 
 separate day for that in addition to our standard bugdays.

[...]
 Also, another day means one more day a month with people working on
 Gentoo theoretically.

I think it would be better to have it all happen on the same day. If those
are easy bumps, they fit very well with bugday. And those devs who
want to work on that, can then join the general bugday mayhem. ;-)
You might be spreading things too thinly otherwise. And even for the
more involved bumps it could be handy to have users around for
testing.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
__



Re: [gentoo-dev] [RFC] New eclass for x11 packages

2010-03-10 Thread Tomáš Chvátal
As last step i fixed issue with circular dependencies.
So please speak-up now because if no complains are sent, i will add this
eclass in 5 hours into main tree.

For the eclass see attachment.

Tomas
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# @ECLASS: xorg-2.eclass
# @MAINTAINER:
# x...@gentoo.org

# Author: Tomáš Chvátal scarab...@gentoo.org
# Author: Donnie Berkholz dberkh...@gentoo.org
# @BLURB: Reduces code duplication in the modularized X11 ebuilds.
# @DESCRIPTION:
# This eclass makes trivial X ebuilds possible for apps, fonts, drivers,
# and more. Many things that would normally be done in various functions
# can be accessed by setting variables instead, such as patching,
# running eautoreconf, passing options to configure and installing docs.
#
# All you need to do in a basic ebuild is inherit this eclass and set
# DESCRIPTION, KEYWORDS and RDEPEND/DEPEND. If your package is hosted
# with the other X packages, you don't need to set SRC_URI. Pretty much
# everything else should be automatic.

GIT_ECLASS=
if [[ ${PV} == ** ]]; then
GIT_ECLASS=git
XORG_EAUTORECONF=yes
SRC_URI=
fi

# If we're a font package, but not the font.alias one
FONT_ECLASS=
if [[ ${PN} == font* \
 ${CATEGORY} = media-fonts \
 ${PN} != font-alias \
 ${PN} != font-util ]]; then
# Activate font code in the rest of the eclass
FONT=yes
FONT_ECLASS=font
fi

inherit eutils base libtool multilib toolchain-funcs flag-o-matic autotools \
${FONT_ECLASS} ${GIT_ECLASS}

EXPORTED_FUNCTIONS=src_unpack src_compile src_install pkg_postinst pkg_postrm
case ${EAPI:-0} in
3) EXPORTED_FUNCTIONS=${EXPORTED_FUNCTIONS} src_prepare src_configure 
;;
*) DEPEND=EAPI-UNSUPPORTED ;;
esac

# exports must be ALWAYS after inherit
EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}

IUSE=
HOMEPAGE=http://xorg.freedesktop.org/;

# @ECLASS-VARIABLE: XORG_EAUTORECONF
# @DESCRIPTION:
# If set to 'yes' and configure.ac exists, eautoreconf will run. Set
# before inheriting this eclass.
: ${XORG_EAUTORECONF:=no}

# Set up SRC_URI for individual modular releases
BASE_INDIVIDUAL_URI=http://xorg.freedesktop.org/releases/individual;
# @ECLASS-VARIABLE: MODULE
# @DESCRIPTION:
# The subdirectory to download source from. Possible settings are app,
# doc, data, util, driver, font, lib, proto, xserver. Set above the
# inherit to override the default autoconfigured module.
if [[ -z ${MODULE} ]]; then
MODULE=
case ${CATEGORY} in
app-doc) MODULE=doc ;;
media-fonts) MODULE=font;;
x11-apps|x11-wm) MODULE=app ;;
x11-misc|x11-themes) MODULE=util;;
x11-drivers) MODULE=driver  ;;
x11-base)MODULE=xserver ;;
x11-proto)   MODULE=proto   ;;
x11-libs)MODULE=lib ;;
esac
fi

if [[ -n ${GIT_ECLASS} ]]; then
EGIT_REPO_URI=git://anongit.freedesktop.org/git/xorg/${MODULE}/${PN}
else
SRC_URI+= ${BASE_INDIVIDUAL_URI}/${MODULE}/${P}.tar.bz2
fi

: ${SLOT:=0}

# Set the license for the package. This can be overridden by setting
# LICENSE after the inherit. Nearly all FreeDesktop-hosted X packages
# are under the MIT license. (This is what Red Hat does in their rpms)
: ${LICENSE=MIT}

# Set up shared dependencies
if [[ ${XORG_EAUTORECONF} != no ]]; then
DEPEND+=
=sys-devel/libtool-2.2.6a
sys-devel/m4
# This MUST BE STABLE
if [[ ${PN} != util-macros ]] ; then
DEPEND+= =x11-misc/util-macros-1.5.0
# Required even by xorg-server
[[ ${PN} == font-util ]] || DEPEND+= 
=media-fonts/font-util-1.1.1-r1
fi
WANT_AUTOCONF=latest
WANT_AUTOMAKE=latest
fi

if [[ ${FONT} == yes ]]; then
RDEPEND+= media-fonts/encodings
x11-apps/mkfontscale
x11-apps/mkfontdir
PDEPEND+= media-fonts/font-alias

# @ECLASS-VARIABLE: FONT_DIR
# @DESCRIPTION:
# If you're creating a font package and the suffix of PN is not equal to
# the subdirectory of /usr/share/fonts/ it should install into, set
# FONT_DIR to that directory or directories. Set before inheriting this
# eclass.
[[ -z ${FONT_DIR} ]]  FONT_DIR=${PN##*-}

# Fix case of font directories
FONT_DIR=${FONT_DIR/ttf/TTF}
FONT_DIR=${FONT_DIR/otf/OTF}
FONT_DIR=${FONT_DIR/type1/Type1}
FONT_DIR=${FONT_DIR/speedo/Speedo}

# Set up configure options, wrapped so ebuilds can override if need be
[[ -z ${FONT_OPTIONS} ]]  
FONT_OPTIONS=--with-fontdir=\${EPREFIX}/usr/share/fonts/${FONT_DIR}\

[[ ${PN##*-} = misc || ${PN##*-} = 75dpi || ${PN##*-} = 100dpi || 
${PN##*-} = cyrillic ]]  IUSE+= 

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

2010-03-10 Thread Mark Loeser
Mike Frysinger vap...@gentoo.org said:
 On Tuesday 09 March 2010 23:08:24 Sebastian Pipping wrote:
  We have about 500 bump request open at the moment:
  https://bugs.gentoo.org/buglist.cgi?quicksearch=bump
  
  I assume that quite a few of them would be no big deal to their
  maintainers in Gentoo.
  
  
  Bugday is occupying the first Saturday of the month: how about bumpday
  on the third Saturday of the month?  First bumpday could be March 20th,
  10 days from now.
  
  What do you think?
 
 for the maintainer-needed ones, np.  for the ones with maintainers, i think 
 you need an ack from someone first.

I don't even think the maintainer-needed ones should be bumped.  Who
knows what bugs you are introducing into the tree.  This is why things
eventually get treecleaned.

As Mike said, for ones with maintainers, don't touch them unless you
have explicit permission.  We have maintainers for a reason, and if you
don't know the intricacies of the package, you shouldn't be touching it.
You should know how it works, how to test it, and what the normal
problems of a bump are.

With that being said, I don't really see the point of a bumpday.  These
day ideas are ignoring the fact that we don't have enough active developers,
which is the real problem.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


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

2010-03-10 Thread Markos Chandras
On Wednesday 10 March 2010 16:41:59 Mark Loeser wrote:
 Mike Frysinger vap...@gentoo.org said:
  On Tuesday 09 March 2010 23:08:24 Sebastian Pipping wrote:
   We have about 500 bump request open at the moment:
   https://bugs.gentoo.org/buglist.cgi?quicksearch=bump
   
   I assume that quite a few of them would be no big deal to their
   maintainers in Gentoo.
   
   
   Bugday is occupying the first Saturday of the month: how about bumpday
   on the third Saturday of the month?  First bumpday could be March 20th,
   10 days from now.
   
   What do you think?
  
  for the maintainer-needed ones, np.  for the ones with maintainers, i
  think you need an ack from someone first.
 
 I don't even think the maintainer-needed ones should be bumped.  Who
 knows what bugs you are introducing into the tree.  This is why things
 eventually get treecleaned.
I run occasionally the maintainer-needed list and bump those packages ( and 
YES I try to do proper bumps not just renaming the ebuilds ), so yes 
maintainer-needed package could get some love as well :)


-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org



Re: [gentoo-dev] webapp-config needs a new maintainer

2010-03-10 Thread Maciej Mrozowski
On Wednesday 10 of March 2010 07:52:28 Benedikt Böhm wrote:
 Hi!
 
 On Wed, Mar 10, 2010 at 4:30 AM, Sebastian Pipping sp...@gentoo.org wrote:
  There are quite a few bugs open for it plus the latest version (1.50.18)
  is not even in Gentoo but on SourceForge only.
 
 The release on sourceforge is not compatible with the current
 implementation in Gentoo AFAIK.
 
  So your first task would be a proper bump and a maybe few bug fixes after:
 webapp-config is in a horrible shape and also has several design
 flaws. i wouldn't touch it. that's why i already added an idea to the
 GSoC list for a complete w-c rewrite. i talked to gunnar in 2008 or
 2009 at chemnitz linux days, and we agreed that w-c needs a rewrite.
 but none of us had/has time to do it. hopefully gsoc can change this
 situation.

This issue always bothered me. Why do we need exclusive web-app config 
application that effectively mirrors what emerge is supposed to do?
I mean installation/removal/updates, and what's the most important config 
updates.
I see this solution suboptimal.
Don't bash me, maybe I'm obviously missing something but I'd really prefer 
simpler, Debian-like approach to webapps, so:
- web-apps installed in /usr/share instead of /var/www (is there any benefit 
from polluting /var/www with system-managed applications?)
- webapp-specific apache config installed in let's say /etc/apache2/conf.d/ 
and included from httpd.conf so that any application works out of the box 
(Alias directive may be suitable in example below)

(example entry for phppgadmin:)
Directory /usr/share/phppgadmin/
  DirectoryIndex index.php
  Options +FollowSymLinks
  AllowOverride None
  Order deny,allow
  Allow from all
  IfModule mod_php5.c
php_flag magic_quotes_gpc Off
php_flag track_vars On
php_value include_path .
  /IfModule
/Directory

That file (apache config) as well as wep-app specific config file 
(/usr/share/phppgadmin/conf/config.inc.php) would be under config-protect, so 
any modifications are tracked.

It's obviously less flexible than webapp-config (no automatic vhosts handling 
- it would be installed initially for all vhosts, sure, one can easily 
configure that), but at least doesn't need webapp-config anymore.

-- 
regards
MM



Re: [gentoo-dev] webapp-config needs a new maintainer

2010-03-10 Thread Benedikt Böhm
On Wed, Mar 10, 2010 at 4:09 PM, Maciej Mrozowski reave...@gmail.com wrote:
 On Wednesday 10 of March 2010 07:52:28 Benedikt Böhm wrote:
 On Wed, Mar 10, 2010 at 4:30 AM, Sebastian Pipping sp...@gentoo.org wrote:
  There are quite a few bugs open for it plus the latest version (1.50.18)
  is not even in Gentoo but on SourceForge only.

 The release on sourceforge is not compatible with the current
 implementation in Gentoo AFAIK.

 webapp-config is in a horrible shape and also has several design
 flaws. i wouldn't touch it. that's why i already added an idea to the
 GSoC list for a complete w-c rewrite. i talked to gunnar in 2008 or
 2009 at chemnitz linux days, and we agreed that w-c needs a rewrite.
 but none of us had/has time to do it. hopefully gsoc can change this
 situation.

 This issue always bothered me. Why do we need exclusive web-app config
 application that effectively mirrors what emerge is supposed to do?

as you obviously figured the replicated package manager behaviour is
for installing apps into multiple vhosts. at first i thought this was
a nice idea, but after some time managing webapps with w-c, i really
hate it and install most things manually nowadays ;-)

 Don't bash me, maybe I'm obviously missing something but I'd really prefer
 simpler, Debian-like approach to webapps, so:
 - web-apps installed in /usr/share instead of /var/www (is there any benefit
 from polluting /var/www with system-managed applications?)
 - webapp-specific apache config installed in let's say /etc/apache2/conf.d/
 and included from httpd.conf so that any application works out of the box
 (Alias directive may be suitable in example below)

i am in favour of debian-like approach too, but i think there are
people relying on the w-c approach now, so an optimal solution would
be to just make webapp-config optional, but this may be an impossible
task, i don't really know.

Bene



Re: [gentoo-dev] webapp-config needs a new maintainer

2010-03-10 Thread Ciaran McCreesh
On Wed, 10 Mar 2010 16:09:26 +0100
Maciej Mrozowski reave...@gmail.com wrote:
 This issue always bothered me. Why do we need exclusive web-app
 config application that effectively mirrors what emerge is supposed
 to do? I mean installation/removal/updates, and what's the most
 important config updates.

webapp-config was originally designed as a standalone, distribution
independent, multi-os tool (Windows support being a priority) that would
operate largely independently of the package manager. It just happened
to have been developed on Gentoo first. In the early days it would get
up to all kinds of crazy stuff like trying to call 'emerge -C' from
within pkg_postinst of an ebuild...

Unfortunately, in those days, bypassing Portage was considered easier
than extending it.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The feature patch mess in the webalizer ebuild (and how to deal with it)

2010-03-10 Thread Sebastian Pipping
Done.

Three packages now, webalizer bumped.
- app-admin/geolizer
- app-admin/webalizer
- app-admin/webalizer-xtended

I'm 100% sure i broke something, please let me know what it is once you
found out ;-)



Sebastian



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

2010-03-10 Thread Gilles Dartiguelongue
Le mardi 09 mars 2010 à 22:32 -0600, Nathan Zachary a écrit :
 On 09/03/10 22:08, Sebastian Pipping wrote: 
  Hello!
  
  
  We have about 500 bump request open at the moment:
  https://bugs.gentoo.org/buglist.cgi?quicksearch=bump
  
  I assume that quite a few of them would be no big deal to their
  maintainers in Gentoo.

For gnome assigned bumps, I can tell all of them have a reason/policy
that explains why they are not done yet and I definitively don't want
non-maintainer bumps for them.

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

That I would buy. I often hear users complaining that stable isn't that
stable and they try to mix ~arch or completely move to ~arch instead of
asking for stablereq. Here too gnome has a policy for some packages but
a couple of them can be stabilized independently. Either way the
reaction is generally quick.

-- 
Gilles Dartiguelongue e...@gentoo.org
Gentoo




Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item

2010-03-10 Thread Arfrever Frehtes Taifersar Arahesis
2010-03-08 22:28:16 William Hubbs napisał(a):
 On Fri, Mar 05, 2010 at 04:19:36PM -0800, Zac Medico wrote:
  No, it won't. To prove it, I've just tested with a stable stage3
  containing portage-2.1.7.x. Here are the steps:
  
  1) extract stable stage3 and chroot into it
  2) mkdir /etc/portage  echo dev-lang/python ~* 
  /etc/portage/package.keywords
  3) Run `emerge -pu --deep=1 portage`:
 These are the packages that would be merged, in order:
  
 Calculating dependencies... done!
 [ebuild UD] sys-apps/sandbox-1.6-r2 [2.2]
 [ebuild UD] app-shells/bash-4.0_p35 [4.0_p37]
 [ebuild U ] dev-lang/python-2.6.4-r1 [2.6.4]
  
  If you try `emerge -puD world` then you will see
  dev-lang/python-3.1.1-r1 pulled in by the unspecific dev-lang/python
  atoms in the cracklib and libxml2 dependencies. However, in
  portage-2.1.7.x (current stable), there is support for
  pseudo-version-ranges in dependencies. This allows you use a
  dependency like dev-lang/python-3 in a package that doesn't support
  python3, and that will prevent it from getting pulled into the
 
 According to this, we can fix all of the dependencies in the tree then
 stabilize python3 without having any issues, so I would vote for this
 route, because it still oinsures that the stable tree will work
 together.

Almost everybody has at least 1 package installed which supports both Python 2
and Python 3 and depends on dev-lang/python without version specification,
so Python 3 would be pulled into dependency graph, so fixing of dependencies
doesn't need to block stabilization of Python 3.

-- 
Arfrever Frehtes Taifersar Arahesis


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


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

2010-03-10 Thread Sebastian Pipping
On 03/10/10 15:41, Mark Loeser wrote:
 I don't even think the maintainer-needed ones should be bumped.  Who
 knows what bugs you are introducing into the tree.  This is why things
 eventually get treecleaned.

I purposely wrote no big deal _to their maintainers_ - I wonder why
everyone is so scare about their packages getting touched now :-)
The requirements for touching packages shall be as on any other day. For
maintainer-needed I wouldn't make such a strong cut, though.


 As Mike said, for ones with maintainers, don't touch them unless you
 have explicit permission.  We have maintainers for a reason, and if you
 don't know the intricacies of the package, you shouldn't be touching it.
 You should know how it works, how to test it, and what the normal
 problems of a bump are.

Right.  As you say it this way: we have maintainers for another reason
too: so someone keeps the package up to date.  It's both a right and a duty.


 With that being said, I don't really see the point of a bumpday.  These
 day ideas are ignoring the fact that we don't have enough active developers,
 which is the real problem.

I assume that many half-active developers would be more active if they
were motivated stronger.  Bumpday could be another step to reactivate
existing developers.  But yes, we need more developers.



Sebastian



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

2010-03-10 Thread Alec Warner
On Wed, Mar 10, 2010 at 6:41 AM, Mark Loeser halc...@gentoo.org wrote:
 Mike Frysinger vap...@gentoo.org said:
 On Tuesday 09 March 2010 23:08:24 Sebastian Pipping wrote:
  We have about 500 bump request open at the moment:
  https://bugs.gentoo.org/buglist.cgi?quicksearch=bump
 
  I assume that quite a few of them would be no big deal to their
  maintainers in Gentoo.
 
 
  Bugday is occupying the first Saturday of the month: how about bumpday
  on the third Saturday of the month?  First bumpday could be March 20th,
  10 days from now.
 
  What do you think?

 for the maintainer-needed ones, np.  for the ones with maintainers, i think
 you need an ack from someone first.

 I don't even think the maintainer-needed ones should be bumped.  Who
 knows what bugs you are introducing into the tree.  This is why things
 eventually get treecleaned.

 As Mike said, for ones with maintainers, don't touch them unless you
 have explicit permission.  We have maintainers for a reason, and if you
 don't know the intricacies of the package, you shouldn't be touching it.
 You should know how it works, how to test it, and what the normal
 problems of a bump are.

 With that being said, I don't really see the point of a bumpday.  These
 day ideas are ignoring the fact that we don't have enough active developers,
 which is the real problem.


We have plenty of developers, the problem is we have too many packages ;p

-A

 --
 Mark Loeser
 email         -   halcy0n AT gentoo DOT org
 email         -   mark AT halcy0n DOT com
 web           -   http://www.halcy0n.com

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.6 (GNU/Linux)

 iD8DBQFLl6+3CRZPokWLroQRAp07AKDgqdRi1gWsIp0wG+QLIaYEXss5OwCdHNZ6
 Owj8ESEixDWVN03OwJV53EQ=
 =F2pI
 -END PGP SIGNATURE-





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

2010-03-10 Thread Sebastian Pipping
On 03/10/10 14:59, Ben de Groot wrote:
 I think it would be better to have it all happen on the same day. If those
 are easy bumps, they fit very well with bugday. And those devs who
 want to work on that, can then join the general bugday mayhem. ;-)
 You might be spreading things too thinly otherwise. And even for the
 more involved bumps it could be handy to have users around for
 testing.

Testing is a point, easy bumps are a point to.
The thing is bugday will soon not be thin anymore: it will require all
the attention of all online devs: there weill be no time to do bumps
that need your brain in parallel.  To summarize: we have to allow Gentoo
to grow or it won't.



Sebastian




Re: [gentoo-dev] Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Roy Bamford
On 2010.03.10 12:45, Mike Frysinger wrote:
 the front page of http://gentoo.org/ now links to a Google Calendar
 (see side 
 bar).  
[snip]
 
 the access step requires a bit of help though -- simply e-mail me off
 list 
 your gmail account and we can get you set up.  once you have access,
 you may 
 easily pass it on to other Gentoo peeps.
 -mike
 

Mike,

Please add roy.bamf...@googlemail.com

-- 
Regards,

Roy Bamford
(Neddyseagoon) an member of
gentoo-ops
forum-mods
trustees



pgpnqPvDP10A5.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] New eclass for x11 packages

2010-03-10 Thread Dawid Węgliński
On Wednesday 10 March 2010 15:13:40 Tomáš Chvátal wrote:
 As last step i fixed issue with circular dependencies.
 So please speak-up now because if no complains are sent, i will add this
 eclass in 5 hours into main tree.
 
 For the eclass see attachment.
 
 Tomas

5 hours? :o

-- 
Cheers
Dawid Węgliński



Re: [gentoo-dev] [RFC] New eclass for x11 packages

2010-03-10 Thread Tomáš Chvátal
Dne 03/10/2010 08:40 PM, Dawid Węgliński napsal(a):
 On Wednesday 10 March 2010 15:13:40 Tomáš Chvátal wrote:
 As last step i fixed issue with circular dependencies.
 So please speak-up now because if no complains are sent, i will add this
 eclass in 5 hours into main tree.

 For the eclass see attachment.

 Tomas
 
 5 hours? :o
 
First mail was 18.2. So just asking if anything has something really
really urgent that might stop inclusion. :]

Tom



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Duncan
Mike Frysinger posted on Wed, 10 Mar 2010 07:45:21 -0500 as excerpted:

 the front page of http://gentoo.org/ now links to a Google Calendar (see
 side bar).  this has been around for a while, but it seems it's been
 more of an underground thing, so it's time to raise its awareness.
 
 like other aspects of Gentoo, all Gentoo developers have access to it to
 add their own events.  anything Gentoo related may be added of course !
 meetings, events, scheduled package events, etc...
 
 the access step requires a bit of help though -- simply e-mail me off
 list your gmail account and we can get you set up.  once you have
 access, you may easily pass it on to other Gentoo peeps.

So a gmail account is now considered mandatory for Gentoo devs, at least 
if they want calendar access?

What about those who might think that Google knows enough about them with 
search and the web crawling and database correlation Google does, and 
whatever ad serving might leak thru, and object to having a gmail account 
on principle?

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




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

2010-03-10 Thread Ben de Groot
On 10 March 2010 19:50, Sebastian Pipping sp...@gentoo.org wrote:
 On 03/10/10 14:59, Ben de Groot wrote:
 I think it would be better to have it all happen on the same day.

 The thing is bugday will soon not be thin anymore: it will require all
 the attention of all online devs: there weill be no time to do bumps
 that need your brain in parallel.

If and when that happens, we can reevaluate and adjust accordingly.
Until such time, it will be easier to have developers commit to one
set day a month rather than two.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
__



Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item

2010-03-10 Thread Ben de Groot
On 10 March 2010 18:36, Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org wrote:
 Almost everybody has at least 1 package installed which supports both Python 2
 and Python 3 and depends on dev-lang/python without version specification,
 so Python 3 would be pulled into dependency graph,

The problem is that we want to prevent that from happening.
Or at the very least advise our users that they should mask
python-3* unless they want it to be pulled in.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
__



Re: [gentoo-dev] Re: Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Mark Loeser
Duncan 1i5t5.dun...@cox.net said:
 So a gmail account is now considered mandatory for Gentoo devs, at least 
 if they want calendar access?
 
 What about those who might think that Google knows enough about them with 
 search and the web crawling and database correlation Google does, and 
 whatever ad serving might leak thru, and object to having a gmail account 
 on principle?

Then they don't get to see the calendar

Seriously though, who cares.  If it becomes a problem, we can deal with
it then.  Until that point, use what we have or implement something
that's better.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Richard Freeman

On 03/10/2010 04:42 PM, Duncan wrote:

So a gmail account is now considered mandatory for Gentoo devs, at least
if they want calendar access?

What about those who might think that Google knows enough about them with
search and the web crawling and database correlation Google does, and
whatever ad serving might leak thru, and object to having a gmail account
on principle?



Honestly, Google calendar works well enough that I'm not sure that I 
like the idea of re-inventing the wheel.  Maybe if somebody designed 
some kind of open calendar access protocol that was comparable.


If you don't like Google tracking all that you do, create a gmail 
account and don't use it for ANYTHING but Google Calendar.  That will 
greatly limit the amount of database correlation they can do.


If somebody has a suggestion for a reasonable multi-user calendaring 
infrastructure that has reasonably close feature parity and isn't a bear 
to maintain I'm sure it would be considered.


Rich



[gentoo-dev] Re: Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Duncan
Richard Freeman posted on Wed, 10 Mar 2010 18:04:54 -0500 as excerpted:

 On 03/10/2010 04:42 PM, Duncan wrote:
 So a gmail account is now considered mandatory for Gentoo devs, at
 least if they want calendar access?

 What about those who might think that Google knows enough about them
 with search and the web crawling and database correlation Google does,
 and whatever ad serving might leak thru, and object to having a gmail
 account on principle?

 Honestly, Google calendar works well enough that I'm not sure that I
 like the idea of re-inventing the wheel.  Maybe if somebody designed
 some kind of open calendar access protocol that was comparable.

I guess that's two separate objections.  One is simply to the /assumption/ 
that /everyone/ (well, all Gentoo devs interested in calendar activities, 
at least) has or at least doesn't object to getting a gmail account.  I 
suppose that's corrected to some degree by the posting itself, but it's an 
assumption that really shouldn't be taken lightly, IMO.

The other is to google /requiring/ a gmail account in the first place, but 
of course, gentoo really doesn't have much to do with that, except to 
possibly refuse to use the tools so made available (gratis), which could 
be argued should be done, but is it worth it in practice?  I don't know.

The first one is what really hit me here tho.  Why the assumption?  If 
it'd have been made explicit that this was something some might have an 
issue with and they'd simply need to choose, it wouldn't have been so bad 
as the issue would have been recognized.  So it was the simple assumption 
I found most offensive, and as I said, my post corrected that to some 
degree, so...

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




Re: [gentoo-dev] Re: Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Mike Frysinger
On Wednesday 10 March 2010 16:42:43 Duncan wrote:
 Mike Frysinger posted on Wed, 10 Mar 2010 07:45:21 -0500 as excerpted:
  the front page of http://gentoo.org/ now links to a Google Calendar (see
  side bar).  this has been around for a while, but it seems it's been
  more of an underground thing, so it's time to raise its awareness.
  
  like other aspects of Gentoo, all Gentoo developers have access to it to
  add their own events.  anything Gentoo related may be added of course !
  meetings, events, scheduled package events, etc...
  
  the access step requires a bit of help though -- simply e-mail me off
  list your gmail account and we can get you set up.  once you have
  access, you may easily pass it on to other Gentoo peeps.
 
 So a gmail account is now considered mandatory for Gentoo devs, at least
 if they want calendar access?
 
 What about those who might think that Google knows enough about them with
 search and the web crawling and database correlation Google does, and
 whatever ad serving might leak thru, and object to having a gmail account
 on principle?

then you dont get write access.  anyone can read it anonymously.  if you want 
an entry added, go ask someone who does have write access.
-mike


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


Re: [gentoo-dev] Re: Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Gilles Dartiguelongue
Le mercredi 10 mars 2010 à 18:04 -0500, Richard Freeman a écrit :
 On 03/10/2010 04:42 PM, Duncan wrote:
  So a gmail account is now considered mandatory for Gentoo devs, at least
  if they want calendar access?
 
  What about those who might think that Google knows enough about them with
  search and the web crawling and database correlation Google does, and
  whatever ad serving might leak thru, and object to having a gmail account
  on principle?
 
 
 Honestly, Google calendar works well enough that I'm not sure that I 
 like the idea of re-inventing the wheel.  Maybe if somebody designed 
 some kind of open calendar access protocol that was comparable.
 
 If you don't like Google tracking all that you do, create a gmail 
 account and don't use it for ANYTHING but Google Calendar.  That will 
 greatly limit the amount of database correlation they can do.
 
 If somebody has a suggestion for a reasonable multi-user calendaring 
 infrastructure that has reasonably close feature parity and isn't a bear 
 to maintain I'm sure it would be considered.

that's called caldav. There's at least one opensource server that is
working decently well with evolution although it's in php.

-- 
Gilles Dartiguelongue e...@gentoo.org
Gentoo


signature.asc
Description: Ceci est une partie de message numériquement signée


Re: [gentoo-dev] Re: Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Nirbheek Chauhan
On Thu, Mar 11, 2010 at 3:12 AM, Duncan 1i5t5.dun...@cox.net wrote:
 So a gmail account is now considered mandatory for Gentoo devs, at least
 if they want calendar access?


Write access.

 What about those who might think that Google knows enough about them with
 search and the web crawling and database correlation Google does, and
 whatever ad serving might leak thru, and object to having a gmail account
 on principle?


If some gentoo dev actually has this problem, they should speak up and
we'll discuss it then.


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team



Re: [gentoo-dev] Re: Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Gilles Dartiguelongue
Le jeudi 11 mars 2010 à 05:28 +0530, Nirbheek Chauhan a écrit :
 On Thu, Mar 11, 2010 at 3:12 AM, Duncan 1i5t5.dun...@cox.net wrote:
  So a gmail account is now considered mandatory for Gentoo devs, at least
  if they want calendar access?
 
 
 Write access.
 
  What about those who might think that Google knows enough about them with
  search and the web crawling and database correlation Google does, and
  whatever ad serving might leak thru, and object to having a gmail account
  on principle?
 
 
 If some gentoo dev actually has this problem, they should speak up and
 we'll discuss it then.

I have a problem with using google resources out of lazyness (nothing
from what I read indicates the opposite) to setup and/or ask infra what
can be done to solve this need.

-- 
Gilles Dartiguelongue e...@gentoo.org
Gentoo


signature.asc
Description: Ceci est une partie de message numériquement signée


Re: [gentoo-dev] Re: Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Mike Frysinger
On Wednesday 10 March 2010 19:02:19 Gilles Dartiguelongue wrote:
 Le jeudi 11 mars 2010 à 05:28 +0530, Nirbheek Chauhan a écrit :
  On Thu, Mar 11, 2010 at 3:12 AM, Duncan 1i5t5.dun...@cox.net wrote:
   So a gmail account is now considered mandatory for Gentoo devs, at
   least if they want calendar access?
  
  Write access.
  
   What about those who might think that Google knows enough about them
   with search and the web crawling and database correlation Google does,
   and whatever ad serving might leak thru, and object to having a gmail
   account on principle?
  
  If some gentoo dev actually has this problem, they should speak up and
  we'll discuss it then.
 
 I have a problem with using google resources out of lazyness (nothing
 from what I read indicates the opposite) to setup and/or ask infra what
 can be done to solve this need.

infra is already tasked enough without having to tackle such a trivial 
resource need.  google calendar is working today and exports all of its stuff 
via a variety of formats for people to important into their own calendaring 
system.

there are plenty of devs who dont have a problem signing in to use google 
calendar which means it should be trivial for you to find someone to add an 
event if you so desire.  or to use a standard invite format and e-mail it to 
someone who simply adds it to the calendar via the gmail interface.
-mike


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


Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item

2010-03-10 Thread William Hubbs
On Wed, Mar 10, 2010 at 11:43:04PM +0100, Ben de Groot wrote:
 On 10 March 2010 18:36, Arfrever Frehtes Taifersar Arahesis
 arfre...@gentoo.org wrote:
  Almost everybody has at least 1 package installed which supports both 
  Python 2
  and Python 3 and depends on dev-lang/python without version specification,
  so Python 3 would be pulled into dependency graph,
 
 The problem is that we want to prevent that from happening.
 Or at the very least advise our users that they should mask
 python-3* unless they want it to be pulled in.
 
 If someone has a package that truly works with either python 2 or 3,
 what is the harm in automatically pulling in python 3 and installing
 the package for both python 2 and 3?

 As long as pulling in python-3 doesn't change the system's default
 python interpretor I don't see a problem with having them both
 installed.

William



pgpnrRLKYVc4i.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Robin H. Johnson
On Wed, Mar 10, 2010 at 09:42:43PM +, Duncan wrote:
 So a gmail account is now considered mandatory for Gentoo devs, at least 
 if they want calendar access?
A Google account != Gmail account.

I use Google calendars extensively myself, but it's NOT linked to a
Gmail account. So the above really should have said Google account.

That said, simply emailing vcard events to an organizer should work
fine.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee  Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85



Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item

2010-03-10 Thread Ben de Groot
On 11 March 2010 01:25, William Hubbs willi...@gentoo.org wrote:
  If someone has a package that truly works with either python 2 or 3,
  what is the harm in automatically pulling in python 3 and installing
  the package for both python 2 and 3?

  As long as pulling in python-3 doesn't change the system's default
  python interpretor I don't see a problem with having them both
  installed.

I've seen enough python-3 specific bugs to know it is not without
problems. It's a waste of time and resources for something that is
not ready to be used anyway. While it can be argued that that is
what our testing branch is for, it is certainly not something that
should be pushed to stable users.

Even if it would be just dead weight, it is not something we should
wish for. It is bloat, it is unnecessary, and causes more problems
than that it solves. Why should users have to compile multiple
python versions, if they only use one anyway?

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
__



Re: [gentoo-dev] Re: Split desktop profile patches news item for review

2010-03-10 Thread Ben de Groot
On 8 March 2010 02:17, Theo Chatzimichos tampak...@gentoo.org wrote:

 I attached the news item, please review. Meanwhile, I'll create docs patches.

 Also, I'm CCing hardened as my No.1 question was not answered. Please do.
 Thanks

Seeing as there were no further comments, I think we are good to go!

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
__



Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item

2010-03-10 Thread William Hubbs
On Thu, Mar 11, 2010 at 02:24:46AM +0100, Ben de Groot wrote:
 On 11 March 2010 01:25, William Hubbs willi...@gentoo.org wrote:
  ??If someone has a package that truly works with either python 2 or 3,
  ??what is the harm in automatically pulling in python 3 and installing
  ??the package for both python 2 and 3?
 
  ??As long as pulling in python-3 doesn't change the system's default
  ??python interpretor I don't see a problem with having them both
  ??installed.
 
 I've seen enough python-3 specific bugs to know it is not without
 problems. It's a waste of time and resources for something that is
 not ready to be used anyway. While it can be argued that that is
 what our testing branch is for, it is certainly not something that
 should be pushed to stable users.
 
 What does upstream say about python 3.1?  Are they calling it stable?
 Yes, it is incompatible with python-2, but, it is set up so both can be
 on a system at the same time.  I'm no expert on python, but I think
 even upstream has python deliberately set up that way.

 Even if it would be just dead weight, it is not something we should
 wish for. It is bloat, it is unnecessary, and causes more problems
 than that it solves. Why should users have to compile multiple
 python versions, if they only use one anyway?
 
 If they are only using python-2 and all of the packages they use only work
 with python-2, then the dependencies of the packages should be fixed to
 reflect that.

Even if python-3 is stable and the dependencies of the
 packages they have say that they only support python-2
 python-3 will not be on their systems.

Someone compared pythohn to gcc earlier in this thread, but I'm not sure
that is a fair comparison.  AFAIK, gcc is not slotted by upstream, and
python is.  I think that makes a difference in how we handle it.

William



pgptqhpeP9Ks3.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item

2010-03-10 Thread Jacob Godserv
The problem here, I think, is everyone has their opinion about what it
means for something to go stable, and I haven't seen more than one or
two references to what has been predetermined as policy for
stabilization. I think we should do a little less debating over
personal opinions (which is a hot topic, apparently) and more about
how Gentoo guidelines determine what can go stable. If the guidelines
don't cover this, then they ought to be fixed.

-- 
Jacob

For then there will be great distress, unequaled
from the beginning of the world until now — and never
to be equaled again. If those days had not been cut
short, no one would survive, but for the sake of the
elect those days will be shortened.

Are you ready?



Re: [gentoo-dev] Re: Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Jeroen Roovers
On Wed, 10 Mar 2010 21:42:43 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:

 So a gmail account is now considered mandatory for Gentoo devs, at
 least if they want calendar access?
 
 What about those who might think that Google knows enough about them
 with search and the web crawling and database correlation Google
 does, and whatever ad serving might leak thru, and object to having a
 gmail account on principle?

That's OK. I'm a Gentoo dev and I won't be subscribing. Fair enough?


 jer



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

2010-03-10 Thread Ryan Hill
On Wed, 10 Mar 2010 09:41:59 -0500
Mark Loeser halc...@gentoo.org wrote:

 As Mike said, for ones with maintainers, don't touch them unless you
 have explicit permission.  We have maintainers for a reason, and if you
 don't know the intricacies of the package, you shouldn't be touching it.
 You should know how it works, how to test it, and what the normal
 problems of a bump are.

And if you're already getting the maintainer to take the time to review your
work and make sure it doesn't break anything they might as well be doing the
bump themselves.

That said, I think there's still a case for taking action yourself if you
can't get a response out of the maintainer within a reasonable time and the
bump is necessary (ie. fixes a real problem, not just because there's a newer
version out).


-- 
fonts,by design, by neglect
gcc-porting,  for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature


[gentoo-portage-dev] a feature called stabilize wanted

2010-03-10 Thread Johannes Kellner
Hello List ans anyone!

I'm searching for a feature or an hint how and where to implement it.

The desired feature could be called stabilize or update to stable
and would change the selected packages when doing an update (emerge
-avuND world).
Just to give you an initial idea/example, some packages:
package A - (the old_stable) has: 3.0 3.4 3.8 ~3.9
package B - (the young_stable) has: ~1.3 ~1.4 ~1.6
package C - (the unstable) has: ~0.6 ~0.8 ~1.1
So version numbers with the ~ are unstable/~amd64, where numbers without
are stable/amd64.

Case 1 (amd64): using system wide only stable/amd64
Installing anything would result in a...@3.8 and C,B not installed

Case 2 (~amd64): using system wide the unstable/~amd64 keyword
Installing anything would result in a...@~3.9 b...@~1.6 c...@~1.1

Case 3 (real world): get it managed with masks and keywords that the
major packages are stable, while new features could arrive
Installing anything with the result a...@3.8 b...@~1.6 c...@~1.1

Nothing new so far, now new package versions arrive:
package A - (the old_stable) has: 3.0 3.4 3.8 ~3.9 NEW: 4.0 ~4.1
package B - (the young_stable) has: ~1.3 ~1.4 ~1.6 NEW: 1.8 ~1.9
package C - (the unstable) has: ~0.6 ~0.8 ~1.1 NEW: ~1.2 ~1.4

So if we now update (emerge -avuND) right now the results are:
Case 1 (amd64): Update a...@3.8 to 4.0, B,C not installed
Case 2 (~amd64): Update a...@~3.9 to ~4.1, b...@~1.6 to ~1.9, c...@~1.1 to ~1.4
Case 3 (real world): depends on the new set of masks and keywords...
much work ahead

What I search is the stabilize feature for the update e.g. (emerge
-avusND) should result in:
Case 1 (amd64):
  - update a...@3.8 to a...@4.0, because a new stable version updates the old
stable version
  - B, C not installed

Case 2 (~amd64):
  - update a...@~3.9 to a...@4.0 update unstable packages to the stable
version when arrived, stop using unstable.
  - update b...@~1.6 to b...@1.8 update unstable packages to the stable
version when arrived, stop using unstable.
  - update c...@~1.1 to C~1.4 update unstable packages, the never unstable
versions.

Case 3 (real world):
  - update a...@3.8 to a...@4.0 update stable package to newer stable version
when arrived.
  - update b...@~1.6 to b...@1.8 update unstable packages to the stable
version when arrived, stop using unstable.
  - update c...@~1.1 to C~1.4 update unstable packages, the never unstable
versions.
  Optional: make is possible to ignore/filter/select the unstable to
unstable updates, those might cause trouble.


Anyone, could help me? Give me a hint if this would be possible? Any
hints where in code this could be implemented? I'm programmer,
professional, so if I get the right hints, will invest spare time in
this. Also I'll ready to setup and run various tests. But I never before
worked at portage...
It might be a good start if the people with the Know-How, will start a
discussing about this idea, what problems need to be solved, which code
parts will need an update and so one. Than I could try to get it
working, but right now, I doesn't even know the right questions.

Best regards,
- Johannes Kellner

-- 
--
Johannes Kellner
freiberuflicher Informatiker

Gostritzer Str. 12, 01217 Dresden, Germany
Mobil: +49 162 4145161
Home: +49 351 4087058
cont...@johannes-kellner.eu
www.johannes-kellner.eu
UStId: DE 2568 79021
--




Re: [gentoo-portage-dev] a feature called stabilize wanted

2010-03-10 Thread Alistair Bush
 Hello List ans anyone!
 
 I'm searching for a feature or an hint how and where to implement it.

Mmmm... Im not one of the knowledgable ppl around here but

you can have version ranges within files like package.keywords eg
cat/A-4.0

which would mean  ~arch  A-4.0 = arch

which is essentially what your asking for.

The biggest issue I have with a feature like this is that you seems to be 
overriding the config files all ready present.   That would only last until the 
next time you ran emerge.

I think this could be better solved with tools ( gui or cli ) that allowed a 
user to manage package.keywords, etc.   Now a tool that actually did this 
would be very interesting indeed. 

Alistair.

 
 The desired feature could be called stabilize or update to stable
 and would change the selected packages when doing an update (emerge
 -avuND world).
 Just to give you an initial idea/example, some packages:
 package A - (the old_stable) has: 3.0 3.4 3.8 ~3.9
 package B - (the young_stable) has: ~1.3 ~1.4 ~1.6
 package C - (the unstable) has: ~0.6 ~0.8 ~1.1
 So version numbers with the ~ are unstable/~amd64, where numbers without
 are stable/amd64.
 
 Case 1 (amd64): using system wide only stable/amd64
 Installing anything would result in a...@3.8 and C,B not installed
 
 Case 2 (~amd64): using system wide the unstable/~amd64 keyword
 Installing anything would result in a...@~3.9 b...@~1.6 c...@~1.1
 
 Case 3 (real world): get it managed with masks and keywords that the
 major packages are stable, while new features could arrive
 Installing anything with the result a...@3.8 b...@~1.6 c...@~1.1
 
 Nothing new so far, now new package versions arrive:
 package A - (the old_stable) has: 3.0 3.4 3.8 ~3.9 NEW: 4.0 ~4.1
 package B - (the young_stable) has: ~1.3 ~1.4 ~1.6 NEW: 1.8 ~1.9
 package C - (the unstable) has: ~0.6 ~0.8 ~1.1 NEW: ~1.2 ~1.4
 
 So if we now update (emerge -avuND) right now the results are:
 Case 1 (amd64): Update a...@3.8 to 4.0, B,C not installed
 Case 2 (~amd64): Update a...@~3.9 to ~4.1, b...@~1.6 to ~1.9, c...@~1.1 to 
 ~1.4
 Case 3 (real world): depends on the new set of masks and keywords...
 much work ahead
 
 What I search is the stabilize feature for the update e.g. (emerge
 -avusND) should result in:
 Case 1 (amd64):
   - update a...@3.8 to a...@4.0, because a new stable version updates the old
 stable version
   - B, C not installed
 
 Case 2 (~amd64):
   - update a...@~3.9 to a...@4.0 update unstable packages to the stable
 version when arrived, stop using unstable.
   - update b...@~1.6 to b...@1.8 update unstable packages to the stable
 version when arrived, stop using unstable.
   - update c...@~1.1 to C~1.4 update unstable packages, the never unstable
 versions.
 
 Case 3 (real world):
   - update a...@3.8 to a...@4.0 update stable package to newer stable version
 when arrived.
   - update b...@~1.6 to b...@1.8 update unstable packages to the stable
 version when arrived, stop using unstable.
   - update c...@~1.1 to C~1.4 update unstable packages, the never unstable
 versions.
   Optional: make is possible to ignore/filter/select the unstable to
 unstable updates, those might cause trouble.
 
 
 Anyone, could help me? Give me a hint if this would be possible? Any
 hints where in code this could be implemented? I'm programmer,
 professional, so if I get the right hints, will invest spare time in
 this. Also I'll ready to setup and run various tests. But I never before
 worked at portage...
 It might be a good start if the people with the Know-How, will start a
 discussing about this idea, what problems need to be solved, which code
 parts will need an update and so one. Than I could try to get it
 working, but right now, I doesn't even know the right questions.
 
 Best regards,
 - Johannes Kellner