[gentoo-dev] Re: New category for version control

2010-03-04 Thread Dirkjan Ochtman
On Thu, Mar 4, 2010 at 10:07, Christian Faulhammer fa...@gentoo.org wrote:
 as dev-util is really crowded, maybe splitting off a category for
 source code management systems would be a good idea.  They are more
 important today than some years ago.
  Are any of you against such a split? My proposal would be to call it
 dev-scm and put all version controls, direct frontends, plugins and the
 like into that.  Diffing tools or programs that only have some kind of
 binding to a scm should stay in dev-util.

I don't know that they're more important, but there are much more of
them, more people using them, and more tools. Great idea, +1 from me.

Cheers,

Dirkjan



Re: [gentoo-dev] New category for version control

2010-03-04 Thread Ulrich Mueller
 On Thu, 4 Mar 2010, Christian Faulhammer wrote:

 My proposal would be to call it dev-scm and put all version
 controls, direct frontends, plugins and the like into that.

Better call it dev-vcs to avoid confusion with both the Scheme
language and with software configuration management.

Ulrich



Re: [gentoo-dev] New category for version control

2010-03-04 Thread Ciaran McCreesh
On Thu, 4 Mar 2010 10:32:47 +0100
Ulrich Mueller u...@gentoo.org wrote:
  On Thu, 4 Mar 2010, Christian Faulhammer wrote:
  My proposal would be to call it dev-scm and put all version
  controls, direct frontends, plugins and the like into that.
 
 Better call it dev-vcs to avoid confusion with both the Scheme
 language and with software configuration management.

And this is why the move wasn't done five years ago: by the time we'd
worked out everything we'd need to do by hand because epkgmove was
broken, the whole thing got bikeshedded to death.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2

2010-03-04 Thread Ulrich Mueller
 On Thu, 04 Mar 2010, Petteri Räty wrote:

 I think removal of functions is a special case of Adding and
 Updating Eclasses and we already have a policy for this.

 Removing functions needs a migration plan. For example how long to
 have a warning there, how long before it can be removed etc.

There may be no general answer to these questions. If it's an eclass
with limited scope and if the functions are no longer used in the
tree, then I don't see the need for a long transition period. OTOH,
for widespread eclasses like eutils you'd probably want it.

 I don't see how you can get those from the common policy?

If you don't email gentoo-dev first, and end up breaking something,
expect to be in a lot of trouble.

Ulrich



Re: [gentoo-dev] New category for version control

2010-03-04 Thread Alex Alexander
On Thu, Mar 04, 2010 at 10:32:47AM +0100, Ulrich Mueller wrote:
  On Thu, 4 Mar 2010, Christian Faulhammer wrote:
 
  My proposal would be to call it dev-scm and put all version
  controls, direct frontends, plugins and the like into that.
 
 Better call it dev-vcs to avoid confusion with both the Scheme
 language and with software configuration management.

Nice idea, +1.

I too prefer dev-vcs as the category name.

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


pgphqAM5dBleT.pgp
Description: PGP signature


Re: [gentoo-dev] New category for version control

2010-03-04 Thread Petteri Räty
On 03/04/2010 11:35 AM, Ciaran McCreesh wrote:
 On Thu, 4 Mar 2010 10:32:47 +0100
 Ulrich Mueller u...@gentoo.org wrote:
 On Thu, 4 Mar 2010, Christian Faulhammer wrote:
 My proposal would be to call it dev-scm and put all version
 controls, direct frontends, plugins and the like into that.

 Better call it dev-vcs to avoid confusion with both the Scheme
 language and with software configuration management.
 
 And this is why the move wasn't done five years ago: by the time we'd
 worked out everything we'd need to do by hand because epkgmove was
 broken, the whole thing got bikeshedded to death.
 

I would let the people maintaining the packages in the new category
decide what to call it.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New category for version control

2010-03-04 Thread Dirkjan Ochtman
On Thu, Mar 4, 2010 at 11:28, Petteri Räty betelge...@gentoo.org wrote:
 I would let the people maintaining the packages in the new category
 decide what to call it.

As the primary maintainer for mercurial, hgsubversion and hg-git, I
would prefer dev-vcs.

I wonder, would a Python re-implementation of git libraries belong in
dev-vcs or in dev-python (it's currently dev-python/dulwich)?

Cheers,

Dirkjan



[gentoo-dev] Re: New category for version control

2010-03-04 Thread Christian Faulhammer
Hi,

Dirkjan Ochtman d...@gentoo.org:
 As the primary maintainer for mercurial, hgsubversion and hg-git, I
 would prefer dev-vcs.

 Yes, I agree now, too.
 
 I wonder, would a Python re-implementation of git libraries belong in
 dev-vcs or in dev-python (it's currently dev-python/dulwich)?

 Up to your common sense (I would go with dev-python).

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] [RFC] Remove cups from default profile to solve circular deps

2010-03-04 Thread Ben de Groot
2010/3/4 Dawid Węgliński c...@gentoo.org:
 On Wednesday 03 March 2010 22:51:10 Ben de Groot wrote:
 I'm not talking about selectively disabling cups. My proposal is
 to no longer enable the cups useflag in the base profile.

 How is that going to fix circular dependency problem? What will you do if 
 every
 user add cups to USE in make.conf? Say we don't support cups turned on by
 default? I hope no. Removing this flag from profile will not fix any problem 
 but
 hide it.

It will fix the out of the box circular dependency for people who
switch to a default desktop profile. This is the main problem we
need to solve now. Certain useflag and package combinations
will trigger a circular dep, that is a know occurrence in Gentoo.
But at least with a default configuration things should work out of
the box. For other configurations there are workarounds (in this
case: install gtk+ without cups, or poppler without cairo enabled
first).

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



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

2010-03-04 Thread Ben de Groot
On 4 March 2010 08:27, Zeerak Mustafa Waseem zeera...@gmail.com wrote:
 Isn't the split of the desktop profile, into KDE and gnome profiles, whilst 
 leaving a base Desktop profile, exactly meant for the purpose that if you're 
 not building KDE/Gnome, then you don't need to set the qt flags, unless some 
 application needs it, or you find that you'd prefer to have them set 
 system-wide?

The toolkits should still be enabled in the default desktop profile,
they are not DE specific.

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



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

2010-03-04 Thread Ben de Groot
On 4 March 2010 08:08, Joshua Saddler nightmo...@gentoo.org wrote:
 Your logic is very thin here. By that same line of reasoning, neither are the 
 gtk or qt flags, since you don't need 'em if you're building, say, a *box 
 desktop.

Toolkits are more directly useful to a desktop than printing.

 Printing is something I'd argue is part of a desktop environment.

And I'd argue it isn't necessarily so.

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



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

2010-03-04 Thread Markus Oehme
At Wed, 03 Mar 2010 21:19:42 -0600,
Dale wrote:
 Now watch some geek find a really simple solution next week.  ;-)

I'm not very expirienced at gentoo development, but I just thought of (I
hope) a possible solution to this.

A circular dependency should always be caused by some USE flags (otherwise
it could never be satisfied). So if portage detects a circular dependency,
it could try first merging the circle without _any_ USE flags and in a
second sweep do the merges with the correct USE flags (so some packages get
merged twice in a run with circular dependencies).

Since this seems to be what would be done manually otherwise I think this
should work, but I'm just a noob, so no guarantees ;)

 Markus

--
Aoccdrnig to a threoy, it deosn't mttaer in waht oredr the ltteers in a wrod
are, the olny iprmoatnt tihng is taht the frist and lsat ltteer are in the
rghit pclae. The rset can be a taotl mses and you can sitll raed it in msot
csaes. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef,
but the wrod as a wlohe. And I awlyas thought slpeling was ipmorantt.



Re: [gentoo-dev] New category for version control

2010-03-04 Thread Ben de Groot
On 4 March 2010 10:58, Alex Alexander wi...@gentoo.org wrote:
 Nice idea, +1.

 I too prefer dev-vcs as the category name.

My thoughts exactly.

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



Re: [gentoo-dev] New category for version control

2010-03-04 Thread Antoni Grzymala
Ulrich Mueller dixit (2010-03-04, 10:32):

  On Thu, 4 Mar 2010, Christian Faulhammer wrote:
 
  My proposal would be to call it dev-scm and put all version
  controls, direct frontends, plugins and the like into that.
 
 Better call it dev-vcs to avoid confusion with both the Scheme
 language and with software configuration management.

+1 for vcs for the above reason. Also, I think vcs is a more popular
acronym than scm (don't quote me on this, though :)).

-- 
[a]



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

2010-03-04 Thread Luca Barbato
On 03/03/2010 07:45 PM, Mart Raudsepp wrote:
 I don't think there was any such problem until poppler maintainers
 decided to unsplit poppler into one big packages with USE flags again
 instead of the nice split poppler, poppler-glib (that should have been
 named poppler-cairo probably instead), poppler-qt3, poppler-qt4 and
 poppler-utils.

If we could manage to convince poppler upstream that would be nice to
actually provide bindings packages aside a core one...

lu


-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero




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

2010-03-04 Thread Theo Chatzimichos
Hello
I have managed to split the desktop profile to gnome and kde submenus. The 
result can be found in kde-crazy overlay (not in layman) [1]
I splitted every desktop/ folder i found. The following issues raised though:
1) I didn't touch the hardened and selinux directories although they do 
contain a desktop folder. Should I proceed in those or not?
2) Some mips/ subdirs don't point to targets/, so I guess the split went to 
/dev/null. So I asked ssuominen who suggested to skip the mips directories, 
and I reverted. (Edit: ssuominen just committed changes in mips profiles in 
tree).
3) There were no desktop dirs for bsd/prefix etc.
4) Also take a look at how I splitted the USE flags (with ssuominen's and 
yngwin's suggestions) and propose your corrections plz. For example, I don't 
really like the firefox flag in kde, and I'd suggest a -firefox (ugly, I know) 
in 
kde's make.defaults

Please Please Please Please Please TEST / REVIEW (especially the arch teams 
plz)

I'll give three days max for the suggestions here etc, and then I'll proceed 
in creating the news item. So I guess it will be committed in a week max. 
Thanks

[1] http://git.overlays.gentoo.org/gitweb/?p=proj/kde-crazy.git;a=summary
-- 
Theo Chatzimichos (tampakrap)
Gentoo KDE/Qt Teams
blog.tampakrap.gr


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


Re: [gentoo-dev] New category for version control

2010-03-04 Thread Jeroen Roovers
On Thu, 4 Mar 2010 09:35:28 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 And this is why the move wasn't done five years ago: by the time we'd
 worked out everything we'd need to do by hand because epkgmove was
 broken, the whole thing got bikeshedded to death.


https://bugs.gentoo.org/show_bug.cgi?id=56967



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

2010-03-04 Thread Jeremy Olexa

On Thu, 4 Mar 2010 16:52:50 +0200, Theo Chatzimichos
tampak...@gentoo.org
wrote:
snip
 The following issues raised though:
snip
 3) There were no desktop dirs for bsd/prefix etc.

That is not an issue for any prefix profiles. It is this way on purpose.

Thanks,
Jeremy



[gentoo-dev] RFC: News item for removal of 2008.0 and old hardened profiles

2010-03-04 Thread Samuli Suominen
Attached you can find the news item for up coming profile cleanup.
Title: Up coming removal of deprecated 2008.0 and hardened profiles
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2010-04-03
Revision: 1
News-Item-Format: 1.0
Display-If-Profile: hardened/ppc
Display-If-Profile: hardened/x86/2.6
Display-If-Profile: hardened/x86
Display-If-Profile: hardened/x86/minimal
Display-If-Profile: hardened/ppc64
Display-If-Profile: hardened/amd64/multilib
Display-If-Profile: hardened/amd64
Display-If-Profile: hardened/ia64
Display-If-Profile: hardened/linux/powerpc/ppc32/2008.0/developer
Display-If-Profile: hardened/linux/powerpc/ppc32/2008.0
Display-If-Profile: hardened/linux/powerpc/ppc32/2008.0/desktop
Display-If-Profile: hardened/linux/powerpc/ppc32/2008.0/server
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/64bit-userland/developer
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/64bit-userland
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/64bit-userland/desktop
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/64bit-userland/server
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/developer
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/32bit-userland/developer
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/32bit-userland
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/32bit-userland/desktop
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/32bit-userland/server
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/desktop
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/server
Display-If-Profile: hardened/linux/x86/2008.0/no-nptl
Display-If-Profile: hardened/linux/x86/2008.0/developer
Display-If-Profile: hardened/linux/x86/2008.0
Display-If-Profile: hardened/linux/x86/2008.0/desktop
Display-If-Profile: hardened/linux/x86/2008.0/server
Display-If-Profile: hardened/linux/amd64/2008.0/no-multilib
Display-If-Profile: hardened/linux/amd64/2008.0/developer
Display-If-Profile: hardened/linux/amd64/2008.0
Display-If-Profile: hardened/linux/amd64/2008.0/desktop
Display-If-Profile: hardened/linux/amd64/2008.0/server
Display-If-Profile: hardened/linux/ia64/2008.0/developer
Display-If-Profile: hardened/linux/ia64/2008.0
Display-If-Profile: hardened/linux/ia64/2008.0/desktop
Display-If-Profile: hardened/linux/ia64/2008.0/server
Display-If-Profile: default/linux/alpha/2008.0/developer
Display-If-Profile: default/linux/alpha/2008.0
Display-If-Profile: default/linux/alpha/2008.0/desktop
Display-If-Profile: default/linux/alpha/2008.0/server
Display-If-Profile: default/linux/s390/2008.0
Display-If-Profile: default/linux/s390/2008.0/server
Display-If-Profile: default/linux/sh/2008.0/developer
Display-If-Profile: default/linux/sh/2008.0
Display-If-Profile: default/linux/sh/2008.0/desktop
Display-If-Profile: default/linux/sh/2008.0/server
Display-If-Profile: default/linux/powerpc/ppc32/2008.0/developer
Display-If-Profile: default/linux/powerpc/ppc32/2008.0
Display-If-Profile: default/linux/powerpc/ppc32/2008.0/desktop
Display-If-Profile: default/linux/powerpc/ppc32/2008.0/server
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/64bit-userland/developer
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/64bit-userland
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/64bit-userland/desktop
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/64bit-userland/server
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/developer
Display-If-Profile: default/linux/powerpc/ppc64/2008.0
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/32bit-userland/developer
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/32bit-userland
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/32bit-userland/desktop
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/32bit-userland/server
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/desktop
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/server
Display-If-Profile: default/linux/m68k/2008.0/developer
Display-If-Profile: default/linux/m68k/2008.0
Display-If-Profile: default/linux/m68k/2008.0/desktop
Display-If-Profile: default/linux/m68k/2008.0/server
Display-If-Profile: default/linux/hppa/2008.0/developer
Display-If-Profile: default/linux/hppa/2008.0
Display-If-Profile: default/linux/hppa/2008.0/desktop
Display-If-Profile: default/linux/hppa/2008.0/server
Display-If-Profile: default/linux/x86/2008.0/developer
Display-If-Profile: default/linux/x86/2008.0
Display-If-Profile: default/linux/x86/2008.0/desktop
Display-If-Profile: default/linux/x86/2008.0/server
Display-If-Profile: default/linux/mips/2008.0/cobalt/developer
Display-If-Profile: default/linux/mips/2008.0/cobalt
Display-If-Profile: default/linux/mips/2008.0/cobalt/desktop
Display-If-Profile: default/linux/mips/2008.0/cobalt/server
Display-If-Profile: default/linux/mips/2008.0/developer
Display-If-Profile: default/linux/mips/2008.0

Re: [gentoo-dev] RFC: News item for removal of 2008.0 and old hardened profiles

2010-03-04 Thread Ben de Groot
 Users using these profiles are expected to migrate to a new profile
 before 2010-01-04, at which point the profiles will be removed.

I think you want another date here, unless you invented time travel :p

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



Re: [gentoo-dev] RFC: News item for removal of 2008.0 and old hardened profiles

2010-03-04 Thread Samuli Suominen
On 03/04/2010 06:10 PM, Ben de Groot wrote:
 Users using these profiles are expected to migrate to a new profile
 before 2010-01-04, at which point the profiles will be removed.
 
 I think you want another date here, unless you invented time travel :p
 

nice one


Title: Up coming removal of deprecated 2008.0 and hardened profiles
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2010-03-04
Revision: 1
News-Item-Format: 1.0
Display-If-Profile: hardened/ppc
Display-If-Profile: hardened/x86/2.6
Display-If-Profile: hardened/x86
Display-If-Profile: hardened/x86/minimal
Display-If-Profile: hardened/ppc64
Display-If-Profile: hardened/amd64/multilib
Display-If-Profile: hardened/amd64
Display-If-Profile: hardened/ia64
Display-If-Profile: hardened/linux/powerpc/ppc32/2008.0/developer
Display-If-Profile: hardened/linux/powerpc/ppc32/2008.0
Display-If-Profile: hardened/linux/powerpc/ppc32/2008.0/desktop
Display-If-Profile: hardened/linux/powerpc/ppc32/2008.0/server
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/64bit-userland/developer
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/64bit-userland
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/64bit-userland/desktop
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/64bit-userland/server
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/developer
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/32bit-userland/developer
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/32bit-userland
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/32bit-userland/desktop
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/32bit-userland/server
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/desktop
Display-If-Profile: hardened/linux/powerpc/ppc64/2008.0/server
Display-If-Profile: hardened/linux/x86/2008.0/no-nptl
Display-If-Profile: hardened/linux/x86/2008.0/developer
Display-If-Profile: hardened/linux/x86/2008.0
Display-If-Profile: hardened/linux/x86/2008.0/desktop
Display-If-Profile: hardened/linux/x86/2008.0/server
Display-If-Profile: hardened/linux/amd64/2008.0/no-multilib
Display-If-Profile: hardened/linux/amd64/2008.0/developer
Display-If-Profile: hardened/linux/amd64/2008.0
Display-If-Profile: hardened/linux/amd64/2008.0/desktop
Display-If-Profile: hardened/linux/amd64/2008.0/server
Display-If-Profile: hardened/linux/ia64/2008.0/developer
Display-If-Profile: hardened/linux/ia64/2008.0
Display-If-Profile: hardened/linux/ia64/2008.0/desktop
Display-If-Profile: hardened/linux/ia64/2008.0/server
Display-If-Profile: default/linux/alpha/2008.0/developer
Display-If-Profile: default/linux/alpha/2008.0
Display-If-Profile: default/linux/alpha/2008.0/desktop
Display-If-Profile: default/linux/alpha/2008.0/server
Display-If-Profile: default/linux/s390/2008.0
Display-If-Profile: default/linux/s390/2008.0/server
Display-If-Profile: default/linux/sh/2008.0/developer
Display-If-Profile: default/linux/sh/2008.0
Display-If-Profile: default/linux/sh/2008.0/desktop
Display-If-Profile: default/linux/sh/2008.0/server
Display-If-Profile: default/linux/powerpc/ppc32/2008.0/developer
Display-If-Profile: default/linux/powerpc/ppc32/2008.0
Display-If-Profile: default/linux/powerpc/ppc32/2008.0/desktop
Display-If-Profile: default/linux/powerpc/ppc32/2008.0/server
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/64bit-userland/developer
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/64bit-userland
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/64bit-userland/desktop
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/64bit-userland/server
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/developer
Display-If-Profile: default/linux/powerpc/ppc64/2008.0
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/32bit-userland/developer
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/32bit-userland
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/32bit-userland/desktop
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/32bit-userland/server
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/desktop
Display-If-Profile: default/linux/powerpc/ppc64/2008.0/server
Display-If-Profile: default/linux/m68k/2008.0/developer
Display-If-Profile: default/linux/m68k/2008.0
Display-If-Profile: default/linux/m68k/2008.0/desktop
Display-If-Profile: default/linux/m68k/2008.0/server
Display-If-Profile: default/linux/hppa/2008.0/developer
Display-If-Profile: default/linux/hppa/2008.0
Display-If-Profile: default/linux/hppa/2008.0/desktop
Display-If-Profile: default/linux/hppa/2008.0/server
Display-If-Profile: default/linux/x86/2008.0/developer
Display-If-Profile: default/linux/x86/2008.0
Display-If-Profile: default/linux/x86/2008.0/desktop
Display-If-Profile: default/linux/x86/2008.0/server
Display-If-Profile: default/linux/mips/2008.0/cobalt/developer
Display-If-Profile: default/linux/mips/2008.0/cobalt
Display-If-Profile: 

Re: [gentoo-dev] RFC: News item for removal of 2008.0 and old hardened profiles

2010-03-04 Thread Theo Chatzimichos
On Thursday 04 March 2010 18:08:52 Samuli Suominen wrote:
 Attached you can find the news item for up coming profile cleanup.

don't you need a Display-If-Profile here or something similar?

btw it will be very handy if we could define a date until news items will be 
shown and then deleted from svn
-- 
Theo Chatzimichos (tampakrap)
Gentoo KDE/Qt Teams
blog.tampakrap.gr


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


Re: [gentoo-dev] New category for version control

2010-03-04 Thread Sebastian Pipping
On 03/04/10 10:35, Ciaran McCreesh wrote:
 On Thu, 4 Mar 2010 10:32:47 +0100
 Ulrich Mueller u...@gentoo.org wrote:
 On Thu, 4 Mar 2010, Christian Faulhammer wrote:
 My proposal would be to call it dev-scm and put all version
 controls, direct frontends, plugins and the like into that.

I like the idea, +1 from me


 Better call it dev-vcs to avoid confusion with both the Scheme
 language and with software configuration management.

Agreed, scm is a bad choice.


 And this is why the move wasn't done five years ago: by the time we'd
 worked out everything we'd need to do by hand because epkgmove was
 broken, the whole thing got bikeshedded to death.

So that's a great chance for all of us to prove we can do better this
time.  We have at least two more names in the pool:

  VCS = version control system/software
  RCS = revision control system/software

The former seems more common to me though the second seems prefered in
wikipedia:
- Version_control forwards to Revision control
- Comparison of revision control software
  http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

I'd still propose dev-vcs, unless someone spots something bad about it.



Sebastian



[gentoo-dev] Re: New category for version control

2010-03-04 Thread Christian Faulhammer
Hi,

Sebastian Pipping sp...@gentoo.org:
 Agreed, scm is a bad choice.

 So it is really tracked in
http://bugs.gentoo.org/show_bug.cgi?id=56967 now.  If there is
anything to comment do it there.  Anyone can start moving the packages
over properly to dev-vcs (with profiles/updates entries of course), just
make it know somehow when you are working on packages not maintained by
you.

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] Re: New category for version control

2010-03-04 Thread Sebastian Pipping
On 03/04/10 17:38, Christian Faulhammer wrote:
 Hi,
 
 Sebastian Pipping sp...@gentoo.org:
 Agreed, scm is a bad choice.
 
  So it is really tracked in
 http://bugs.gentoo.org/show_bug.cgi?id=56967 now.  If there is
 anything to comment do it there.

Is that a good idea?
Maybe we should restrict the bug to status updates on moving and keep
discussions on here?


 Anyone can start moving the packages
 over properly to dev-vcs (with profiles/updates entries of course),

There seems to be a lot more to it:
- Updating eclasses?
- Updating documentation
- Updating reverse dependencies?
- Pushing news out to Gentoo users (and developers)
- Update package names used in Layman (my task)
- more here

What else can you think of?

Maybe make a new thread dev-vcs migration roadmap from here?



Sebastian



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

2010-03-04 Thread Mart Raudsepp
On N, 2010-03-04 at 12:50 +0100, Ben de Groot wrote: 
 2010/3/4 Dawid Węgliński c...@gentoo.org:
  On Wednesday 03 March 2010 22:51:10 Ben de Groot wrote:
  I'm not talking about selectively disabling cups. My proposal is
  to no longer enable the cups useflag in the base profile.
 
  How is that going to fix circular dependency problem? What will you do if 
  every
  user add cups to USE in make.conf? Say we don't support cups turned on by
  default? I hope no. Removing this flag from profile will not fix any 
  problem but
  hide it.
 
 It will fix the out of the box circular dependency for people who
 switch to a default desktop profile. This is the main problem we
 need to solve now.

The main problem to solve here is the circular dependency that you
yourself introduced as a co-maintainer of poppler, by converting poppler
to be monolithic. This from the outside looks like it was done to reduce
your maintenance workload in the (possibly accidental) expense of users
who are now getting circular dependencies in a fairly common setup.

If cups should be enabled in the desktop profile or not is a completely
different question.

The correct solution here is to fix the core problem that is now
happening - not to start removing common desktop needed USE flags from
the desktop profiles to delay the correct fix for this circular
dependency you guys have introduced for us.

 Certain useflag and package combinations
 will trigger a circular dep, that is a know occurrence in Gentoo.
 But at least with a default configuration things should work out of
 the box. For other configurations there are workarounds (in this
 case: install gtk+ without cups, or poppler without cairo enabled
 first).

Circular dependencies shouldn't happen in any situation. I claim there
is always a solution to avoid it. A different question is if the cost of
the solution is acceptable compared to the problems it causes. I believe
an inconvenience for the poppler maintainers is completely justified
here for the benefit of users in the form of properly split packages,
considering how this affects a majority of desktop users (problem hidden
by default or not).


I'll later make sure there is a bug for fixing this circular dependency
mess properly. I believe the only possible fix is to split poppler back
to at least core, bindings and utils, as it seems to be a problem due to
poppler-utils requirement by cups. It doesn't need poppler-glib, so
utils and bindings being a separate package, as it always was before,
would nicely solve it.


-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio


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


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

2010-03-04 Thread Duncan
Ben de Groot posted on Thu, 04 Mar 2010 13:28:24 +0100 as excerpted:

 On 4 March 2010 08:08, Joshua Saddler nightmo...@gentoo.org wrote:
 Your logic is very thin here. By that same line of reasoning, neither
 are the gtk or qt flags, since you don't need 'em if you're building,
 say, a *box desktop.
 
 Toolkits are more directly useful to a desktop than printing.
 
 Printing is something I'd argue is part of a desktop environment.
 
 And I'd argue it isn't necessarily so.

Indeed.  Some (many?) of us use printing uncommonly enough that it's 
cheaper to put it on a thumb drive and take it to a printer than buy a 
printer -- and pay for another $10-30 ink cartridge every time we want to 
print something, because the last one dried up between uses.  (I keep 
thinking I'll buy a laser printer, but never seem to get around to doing 
the research on best supported, etc, and always seem to have other things 
to spend the money on.  Besides, the tech keeps getting better, so a bit 
of delay isn't hurting... which I've been saying for years now.  How many 
are in a similar position?)

-- 
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: [RFC] Remove cups from default profile to solve circular deps

2010-03-04 Thread Jeremy Olexa

On Thu, 4 Mar 2010 17:04:17 + (UTC), Duncan 1i5t5.dun...@cox.net
wrote:
 Ben de Groot posted on Thu, 04 Mar 2010 13:28:24 +0100 as excerpted:
 
 On 4 March 2010 08:08, Joshua Saddler nightmo...@gentoo.org wrote:
 Your logic is very thin here. By that same line of reasoning, neither
 are the gtk or qt flags, since you don't need 'em if you're building,
 say, a *box desktop.
 
 Toolkits are more directly useful to a desktop than printing.
 
 Printing is something I'd argue is part of a desktop environment.
 
 And I'd argue it isn't necessarily so.
 
 Indeed.  Some (many?) of us use printing uncommonly enough that it's 
 cheaper to put it on a thumb drive and take it to a printer than buy a 
 printer -- and pay for another $10-30 ink cartridge every time we want
to 
 print something, because the last one dried up between uses.  (I keep 
 thinking I'll buy a laser printer, but never seem to get around to doing

 the research on best supported, etc, and always seem to have other
things 
 to spend the money on.  Besides, the tech keeps getting better, so a bit

 of delay isn't hurting... which I've been saying for years now.  How
many 
 are in a similar position?)

Similarly, I have never *owned* a printer because work or school always
has had free printing. So, my opinion is that the Gentoo default of
USE=cups in desktop profiles is bogus for *my* Gentoo desktops. But, I'm
not a desktop profile consumer anyway because they are sub-optimal, imo. ;)

-Jeremy



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

2010-03-04 Thread Duncan
Theo Chatzimichos posted on Thu, 04 Mar 2010 16:52:50 +0200 as excerpted:

 For example, I don't really like the
 firefox flag in kde, and I'd suggest a -firefox (ugly, I know) in kde's
 make.defaults

That's not particularly practical, unfortunately.  konqueror seems to be 
dropping behind, doesn't have proper ssl/certificate management support 
with 4.x, and in general is getting less and less useful as a general 
purpose browser, and there's simply no way to keep up with the community 
development power of its extensions even if kde wanted to.  Pretty much 
everyone (including kde devs, based on remarks on the kde lists and 
planet) seems to use firefox for at least some of their browsing these 
days.

Someday, the webkit based rekonq is likely to take over from konqueror, 
but upstream says it's not yet mature enough for that.  Others use chrome 
or chromium, or icecat, or something else.  But firefox really does tend 
to be the cross-DE default, at least to the point that I believe that 
defaulting to USE=-firefox in the kde profiles would be a mistake.  Some 
of us would like nothing better than to be able to remove both it and with 
it gtk, but reality is, that's not going to be a useful default for some 
time, and given that, IMO, full optional but default-on support for it in 
the KDE desktop profiles via USE flags should be maintained.

-- 
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: [RFC] Remove cups from default profile to solve circular deps

2010-03-04 Thread Ben de Groot
On 4 March 2010 18:23, Jeremy Olexa darks...@gentoo.org wrote:
 On Thu, 4 Mar 2010 17:04:17 + (UTC), Duncan 1i5t5.dun...@cox.net
 wrote:
 Indeed.  Some (many?) of us use printing uncommonly enough that it's
 cheaper to put it on a thumb drive and take it to a printer than buy a
 printer -- and pay for another $10-30 ink cartridge every time we want
 to print something, because the last one dried up between uses.

 Similarly, I have never *owned* a printer because work or school always
 has had free printing. So, my opinion is that the Gentoo default of
 USE=cups in desktop profiles is bogus for *my* Gentoo desktops.

Exactly. The last time I owned a printer is over 5 years ago. So I don't
think cups warrants to be in the standard desktop profile.

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



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

2010-03-04 Thread Sebastian Pipping
On 03/04/10 15:52, Theo Chatzimichos wrote:
 Hello
 I have managed to split the desktop profile to gnome and kde submenus.

How about XFCE (and LXDE)?


 The 
 result can be found in kde-crazy overlay (not in layman) [1]

If this is ever going to be used as a real overlay please set repo_name
to something other than gentoo, e.g. kde-crazy.


 I'll give three days max for the suggestions here etc, and then I'll proceed 
 in creating the news item. So I guess it will be committed in a week max. 

Out of curiosity: why the hurry?



Sebastian



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

2010-03-04 Thread Samuli Suominen
On 03/04/2010 07:59 PM, Sebastian Pipping wrote:
 On 03/04/10 15:52, Theo Chatzimichos wrote:
 Hello
 I have managed to split the desktop profile to gnome and kde submenus.
 
 How about XFCE (and LXDE)?

Pointless.

We (xfce) are fine with plain desktop/ profile (now, and after the gnome
and kde flags are stripped out of it).
The required flags are somewhat jpeg, png, dbus, cairo, gtk and that's
about it. HAL is optional.

I guess it's pretty much same for LXDE.



[gentoo-dev] Re: [gentoo-dev-announce] Lastrite: games-fps/openarena

2010-03-04 Thread Victor Ostorga
On Wed, 03 Mar 2010 13:35:10 +0200
Samuli Suominen ssuomi...@gentoo.org wrote:

 # Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010)
 # Masked for QA, security
 #
 # Internal copies of vuln. zlib, jpeg, speex and likely
 # others
 #
 # http://bugs.gentoo.org/show_bug.cgi?id=255453
 #
 # Masked for removal in 60 days.
 games-fps/openarena
 

0.8.5 was released on february 23, 2010 and the patch at bug
255453 seems to work fine.
Please don't remove one of the greatest open source games.

Regards,

-- 
Víctor Ostorga
Gentoo Linux developer (lxde, treecleaners)
http://www.gentoo.org


signature.asc
Description: PGP signature


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

2010-03-04 Thread Arfrever Frehtes Taifersar Arahesis
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.

-- 
Arfrever Frehtes Taifersar Arahesis
Title: Python 3.1
Author: Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org
Content-Type: text/plain
Posted: 2010-03-04
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: =dev-lang/python-3.1*

Python 3 is a new major version of Python and is intentionally incompatible
with Python 2. Many external modules have not been ported yet to Python 3, so
currently Python 3.1 should not be set as main active version of Python.
Setting Python 3.1 as main active version of Python is currently unsupported.
When it will change, a separate news item will be created to notify users.

'eselect python COMMAND --python3 [ARGUMENTS]' can be used to manage
configuration of active version of Python 3.

Although Python 3.1 should not be set as main active version of Python, users
should run python-updater after installation of Python 3.1. By default,
modules, which support both Python 2 and Python 3, are installed for both
active version of Python 2 and active version of Python 3, when both Python 2
and Python 3 are installed.

It is recommended to use a UTF-8 locale to avoid potential problems. Especially
C and POSIX locales are discouraged. If locale has not been explicitly set,
then POSIX locale is used, so users should explicitly set locale. Problems
occuring only with non-UTF-8 locales should be reported directly to upstream
developers of given packages.


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


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

2010-03-04 Thread Paweł Hajdan, Jr.
On 3/4/10 7:22 PM, Arfrever Frehtes Taifersar Arahesis wrote:
 Setting Python 3.1 as main active version of Python is currently unsupported.
 When it will change, a separate news item will be created to notify users.

I'd suggest s/users/you

 'eselect python COMMAND --python3 [ARGUMENTS]' can be used to manage
 configuration of active version of Python 3.

I'm confused by the above paragraph. I had to spend a longer while to
see that it really means if you want to use eselect-python to manage
your python3 configuration, pass the --python3 switch. Before that I
wondered what is the meaning of COMMAND and ARGUMENTS. Would be nice to
make it more clear.

 Although Python 3.1 should not be set as main active version of Python, users
 should run python-updater after installation of Python 3.1. By default,

Again, IMHO s/users/you, or please run.

 It is recommended to use a UTF-8 locale to avoid potential problems. 
 Especially

Link to the UTF-8 guide please?

 C and POSIX locales are discouraged. If locale has not been explicitly set,
 then POSIX locale is used, so users should explicitly set locale. Problems

I'd suggest s/users/you, or maybe make sure you have set locale.

 occuring only with non-UTF-8 locales should be reported directly to upstream

nit: occuring - occurring

Paweł Hajdan jr



signature.asc
Description: OpenPGP digital signature


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

2010-03-04 Thread Roy Bamford
On 2010.03.01 21:17, Ioannis Aslanidis wrote:
 Hello,
 
[snip]

 Bug Day, followed by an announcement the week before and a reminder
 the day before. This needs to happen in publicly visible places (and
 has happened in some of them as far as I recall): forums, gentoo-
 user,
 gentoo-dev, gentoo-announce, gentoo-dev-announce, the newsletter
 (dead?) and the website. Having people related to the Bug Day project
 posting to their blogs can help a lot in this case as well.
[snip
 
 Regards.
 
 
[snip]
 
 
 -- 
 Ioannis Aslanidis
 http://www.deathwing00.org
 deathwing00[at]gentoo.org 0x47F370A0
 

I used to do the announces, sometimes under the psudonym of Welps PA. 
I can chip in again and with some of the organisation and the 
announces.

Its definately worth saving bugday - it brings devs and users closer 
together.

sping was looking at two days in plain Python  - do we need a 
developer to do that or could that be one of the bugs for bugday ?
I realise that gentoo.org will host it, so we need to validate it but 
that should be much less time than writing the code.
 
--  
Regards,

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



pgpSzOs2UpSyL.pgp
Description: PGP signature


Re: [gentoo-dev] Re: New category for version control

2010-03-04 Thread Dirkjan Ochtman
On Thu, Mar 4, 2010 at 17:47, Sebastian Pipping sp...@gentoo.org wrote:
 There seems to be a lot more to it:
 - Updating eclasses?
 - Updating documentation
 - Updating reverse dependencies?
 - Pushing news out to Gentoo users (and developers)
 - Update package names used in Layman (my task)
 - more here

This is a good list, but it seems much easier to keep track of such a
list in a bug.

Cheers,

Dirkjan



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

2010-03-04 Thread Dale

chrome://messenger/locale/messengercompose/composeMsgs.properties:

On 4 March 2010 08:08, Joshua Saddlernightmo...@gentoo.org  wrote:
   

Your logic is very thin here. By that same line of reasoning, neither are the 
gtk or qt flags, since you don't need 'em if you're building, say, a *box 
desktop.
 

Toolkits are more directly useful to a desktop than printing.

   

Printing is something I'd argue is part of a desktop environment.
 

And I'd argue it isn't necessarily so.

Cheers,
   


Sounds like your argument is more like a opinion.  I built my desktop 
about 6 years ago and the next thing bought after the build was a 
printer.  I use it daily.  I'm 42 so I don't have access to a free 
printer at a school or some public printer.  Everyone here charges by 
the page so it is much cheaper for me to own my own printer.


Removing the cups USE flag still doesn't fix the problem I pointed out 
in another reply.  If you unpack the tarball and set the USE line as you 
should, the circular dependency is still there.  Correct?  So nothing is 
fixed by doing this.


Dale

:-)  :-)



[gentoo-dev] Add NGINX_MODULES to USE_EXPAND

2010-03-04 Thread Benedikt Böhm
Hi all,

i'd like to add NGINX_MODULES to USE_EXPAND. If there are no
objections i will commit it end of the week.

Thanks,
Bene



[gentoo-dev] Moving packages to dev-vcs

2010-03-04 Thread Sebastian Pipping
Hello!


So now that we have a new category dev-vcs we need to move suitable
stuff over there.  Moving packages is complex and error prone:
This mail tries to guide you through and summarize the process, please
read on.

HINT:  Please keep CVS' radius of operation small to reduce risks.


0. Prepare
==
- Check if your package fits:
Is it a utility focused on version control?

- Ensure that you have permission  (if you are not the main maintainer)

- Sync the whole tree including profiles
  (as you'll be inspecting reverse dependencies)


1. Copy
===
- Duplicate any traces of dev-util/${PN} in profiles/ to dev-vcs/${PN}
  (fgrep -Rw dev-util/${PN} profiles/)

- Copy complete package dev-util/${PN} to dev-vcs/${PN}
  (watch out CVS directories)


2. Switch
=
- Update eclasses
fgrep -w dev-util/${PN} eclass/*.eclass

- Update reverse dependencies
http://tinderbox.dev.gentoo.org/misc/dindex/dev-util/${PN}
http://tinderbox.dev.gentoo.org/misc/rindex/dev-util/${PN}
^^^
fgrep -w dev-util/${PN} */*/*.ebuild

- Append move dev-util/${PN} dev-vcs/${PN} line to
  profiles/updates/1Q-2010
  (must come last, described in [1])


3. Remove
=
- Remove package dev-util/${PN} from CVS (as in [2])
cd dev-util
cvs rm -Rf ${PN}
cvs ci -m dev-util/${PN}: Remove (renamed to dev-vcs/${PN}) ${PN}
  ^
- Remove any traces of dev-util/${PN} in profiles/


4. Notify
=
- Report back problems with this process

- Mail fellow maintainers of dev-util/${PN} about the move

- If ${PN} is a big one (Subversion, Git, you know the list)
  - Update documentation  (now or open a bug at least, please)
  - Drop sp...@g.o. a mail to update references in Layman
  - (Notify users and developers through Planet Gentoo?)


5. Final words
==
- Help for filling profiles/updates documentation is wanted,
  it's currently _all empty_:
  http://devmanual.gentoo.org/profiles/updates/index.html

- Feel free to CC yourself to dev-vcs bug #56967 [3]



Sebastian


[1]
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=5#doc_chap6
[2]
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=5#doc_chap7
[3] https://bugs.gentoo.org/show_bug.cgi?id=56967



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

2010-03-04 Thread Sebastian Pipping
On 03/04/10 19:22, Arfrever Frehtes Taifersar Arahesis wrote:
 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.

#python on Freenode still reads It's too early to use Python 3.x.
Are they wrong?

Are we at a point already where we can feed 90% of the Python 2.x code
out there to Python 3 without problems?

Has QA given their blessing to this?


Personally I want yes three times to see you continue with Python 3
stabilization.



Sebastian



Re: [gentoo-dev] Moving packages to dev-vcs

2010-03-04 Thread Ulrich Mueller
 On Thu, 04 Mar 2010, Sebastian Pipping wrote:

 2. Switch
 =

 - Update reverse dependencies
 http://tinderbox.dev.gentoo.org/misc/dindex/dev-util/${PN}
 http://tinderbox.dev.gentoo.org/misc/rindex/dev-util/${PN}
 ^^^
 fgrep -w dev-util/${PN} */*/*.ebuild

Also check metadata.xml which may contain package references.
For example (from app-portage/layman/metadata.xml):

  flag name='git'Support pkgdev-util/git/pkg based overlays/flag

Ulrich



Re: [gentoo-dev] Add NGINX_MODULES to USE_EXPAND

2010-03-04 Thread Tiziano Müller
Hi Benedikt

Did you look at the nginx ebuild in my overlay? I already created an
ebuild with USE flags for the different features and with USE_EXPANDable
flags in mind.
Even though there are only 3 mail modules I'd prefer two USE_EXPAND
vars: NGINX_HTTP_MODULES and NGINX_MAIL_MODULES, since upstream makes a
difference between http-modules and mail-modules.

Cheers,
Tiziano

Am Donnerstag, den 04.03.2010, 21:27 +0100 schrieb Benedikt Böhm:
 Hi all,
 
 i'd like to add NGINX_MODULES to USE_EXPAND. If there are no
 objections i will commit it end of the week.
 
 Thanks,
 Bene
 

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature


Re: [gentoo-dev] Moving packages to dev-vcs

2010-03-04 Thread Markos Chandras
On Thursday 04 March 2010 23:08:06 Sebastian Pipping wrote:
 Hello!
 
 
 So now that we have a new category dev-vcs we need to move suitable
 stuff over there.  Moving packages is complex and error prone:
 This mail tries to guide you through and summarize the process, please
 read on.
 
 HINT:  Please keep CVS' radius of operation small to reduce risks.
 
 
 0. Prepare
 ==
 - Check if your package fits:
 Is it a utility focused on version control?
 
 - Ensure that you have permission  (if you are not the main maintainer)
 
 - Sync the whole tree including profiles
   (as you'll be inspecting reverse dependencies)
 
 
 1. Copy
 ===
 - Duplicate any traces of dev-util/${PN} in profiles/ to dev-vcs/${PN}
   (fgrep -Rw dev-util/${PN} profiles/)
 
 - Copy complete package dev-util/${PN} to dev-vcs/${PN}
   (watch out CVS directories)
 
 
 2. Switch
 =
 - Update eclasses
 fgrep -w dev-util/${PN} eclass/*.eclass
 
 - Update reverse dependencies
 http://tinderbox.dev.gentoo.org/misc/dindex/dev-util/${PN}
 http://tinderbox.dev.gentoo.org/misc/rindex/dev-util/${PN}
This might require too much time so the tree will be broken for a while I 
guess

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


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


Re: [gentoo-dev] Moving packages to dev-vcs

2010-03-04 Thread Robin H. Johnson
On Thu, Mar 04, 2010 at 10:08:06PM +0100, Sebastian Pipping wrote:
 So now that we have a new category dev-vcs we need to move suitable
 stuff over there.  Moving packages is complex and error prone:
 This mail tries to guide you through and summarize the process, please
 read on.
This contains a critical bug...

cvs add and the matching commit aren't mentioned anywhere...

-- 
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] Moving packages to dev-vcs

2010-03-04 Thread Dirkjan Ochtman
On Thu, Mar 4, 2010 at 22:38, Robin H. Johnson robb...@gentoo.org wrote:
 This contains a critical bug...

 cvs add and the matching commit aren't mentioned anywhere...

Well, it *is* a summary.

Thanks for the guide, that'll be useful.

Cheers,

Dirkjan



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

2010-03-04 Thread Dirkjan Ochtman
On Thu, Mar 4, 2010 at 22:16, Sebastian Pipping sp...@gentoo.org wrote:
 Are we at a point already where we can feed 90% of the Python 2.x code
 out there to Python 3 without problems?

No, and that point will never come, but this is not a problem right now.

Python 3 will be installed slotted, as an extra version, and it will
not disturb the Python 2.x versions or any packages that don't work on
3.x (which are marked as such). I have this working on a bunch of
boxes, and it hasn't caused me any problems so far.

Cheers,

Dirkjan



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

2010-03-04 Thread Dirkjan Ochtman
On Thu, Mar 4, 2010 at 21:01, Dale rdalek1...@gmail.com wrote:
 Sounds like your argument is more like a opinion.  I built my desktop about

Since people keep talking about not wanting cups disabled for the
desktop profiles, can we at least agree that it should be disabled by
default for the non-desktop profiles?

Cheers,

Dirkjan



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

2010-03-04 Thread Dale

chrome://messenger/locale/messengercompose/composeMsgs.properties:

On Thu, Mar 4, 2010 at 21:01, Dalerdalek1...@gmail.com  wrote:
   

Sounds like your argument is more like a opinion.  I built my desktop about
 

Since people keep talking about not wanting cups disabled for the
desktop profiles, can we at least agree that it should be disabled by
default for the non-desktop profiles?

Cheers,

Dirkjan

   


To me, that makes sense.  It certainly seems more logical to do that.  
I'm of the opinion that a server profile should be very limited.  Let 
the user decide what kind of server they are going to have.  A desktop 
profile can be limited but should include the more common options.  
There may be things that would depend on what type of GUI you are 
running but that could be left up to the user and documented in the 
docs.  Let the user pick which path they want to go down.


Dale

:-)  :-)



Re: [gentoo-dev] Moving packages to dev-vcs

2010-03-04 Thread Brian Harring
On Thu, Mar 04, 2010 at 10:08:06PM +0100, Sebastian Pipping wrote:
 1. Copy
 ===
 - Duplicate any traces of dev-util/${PN} in profiles/ to dev-vcs/${PN}
   (fgrep -Rw dev-util/${PN} profiles/)
 
 - Copy complete package dev-util/${PN} to dev-vcs/${PN}
   (watch out CVS directories)
 
 
 2. Switch
 =
 - Update eclasses
 fgrep -w dev-util/${PN} eclass/*.eclass
 
 - Update reverse dependencies
 http://tinderbox.dev.gentoo.org/misc/dindex/dev-util/${PN}
 http://tinderbox.dev.gentoo.org/misc/rindex/dev-util/${PN}
 ^^^
 fgrep -w dev-util/${PN} */*/*.ebuild

I'd suggest 

pquery --revdep dev-util/${PN} --raw --repo $PORTDIR

instead- throw in a '--attr inherited' if you want to look for 
eclasses that are implicated in addition, but it's a safer bet then 
relying on fgrep (since it's literal metadata searching) and doesn't 
have the potential for staleness tinderbox does.  Speed wise it'll be 
slower then grep, but not hugely so- reasonably up to date cache, it's 
9s on my hardware so... there's no reason to not do it properly.


 - Append move dev-util/${PN} dev-vcs/${PN} line to
   profiles/updates/1Q-2010
   (must come last, described in [1])
 
 
 3. Remove
 =
 - Remove package dev-util/${PN} from CVS (as in [2])
 cd dev-util
 cvs rm -Rf ${PN}
 cvs ci -m dev-util/${PN}: Remove (renamed to dev-vcs/${PN}) ${PN}


Realistically, the dev *really* should be doing visibility scans 
after their efforts- yes bones does them too, but it's better to do 
the scan after to ensure any breakage is caught quickly.  Specifically 
via pkgcore-checks, I'd suggest running

pcheck -r $PORTDIR -c visibility '*'

prior to the move, and a dump of that commands output after the cvs rm 
invocation above.  Presuming everything was updated properly, the 
line count should be the same- output will vary slightly (previous 
complaints about dev-util/bzr being unavailable become dev-vcs/bzr 
unavailable specifically).

At least for my hardware, it's a 3.5 minute scan- so there really 
isn't a reason to *not* do this check (if the mips profiles were 
cleaned up/out prior it's more like 2.5 minutes on a sidenote)...


If folks are aware of alternate tools for doing these sort of checks 
in a timely fashion, feel free to pipe up also- I'm just suggesting 
the tools I know.


Random sidenote, anyone looked at using an alternate vcs to do the 
work, then proxy it back?  Specifically thinking of workflow like svk 
(or in this case hg cvs, 
https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS ).  The 
reason I ask is that via building the work up outside of cvs, then 
proxying the add/remove/modifications back into it, it should be 
possible to minimize the window of cvs breakage down to bare minimum 
while still getting the same level of QA validation for the changes.

That's assuming hg/cvs behaves sanely of course, and doing a checkout 
(tip as it were) from cvs into hg is fast enough to be viable.  Just a 
thought- djc, you got any comments on this usage of hg?

~harring


pgpZEgVbgxFUU.pgp
Description: PGP signature


[gentoo-dev] Re: New category for version control

2010-03-04 Thread Christian Faulhammer
Hi,

Sebastian Pipping sp...@gentoo.org:
 Is that a good idea?
 Maybe we should restrict the bug to status updates on moving and keep
 discussions on here?

 I don't expect too many discussions. :)

  Anyone can start moving the packages
  over properly to dev-vcs (with profiles/updates entries of course),
 
 There seems to be a lot more to it:
 - Updating eclasses?
 - Updating reverse dependencies?

 That is the normal procedure when pkgmoving a package.  So nothing
special. :)

 - Updating documentation

 A simple grep for dev-util/ should be sufficient.

 - Pushing news out to Gentoo users (and developers)

 For what? pkgmove should handle that.
 
 - Update package names used in Layman (my task)

 Yes.

 What else can you think of?

 At the moment, nothing.

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] [RFC] Remove cups from default profile to solve circular deps

2010-03-04 Thread Dale

chrome://messenger/locale/messengercompose/composeMsgs.properties:

On 4 March 2010 21:01, Dalerdalek1...@gmail.com  wrote:
   

Removing the cups USE flag still doesn't fix the problem I pointed out in
another reply.  If you unpack the tarball and set the USE line as you
should, the circular dependency is still there.  Correct?  So nothing is
fixed by doing this.
 

What it fixes is (1) the circular dependency that people run into on a
fresh install and the default desktop profile, and (2) the default
dependency on cups that many users do not need.

What it does not fix is the case of users who enable both cairo and
cups useflags on a system where neither gtk+ nor cups is present
yet. But this issue can be discussed separately from whether cups
should be enabled in profiles.

Cheers,
   


In the other post, I explained how this will not fix this at all.  As 
mentioned, untar the tarball, copy the make.conf and world file over 
then start the install.  Guess what, the circular dependency is right 
there.  If I had to reinstall Gentoo from scratch, because of say a hard 
drive failure, that is what I would do.  If a person follows the 
documentation and enables the USE flags they need, same thing.  It's not 
like cups is a hidden feature.  Anyone even familiar with Linux a little 
bit knows what cups is.


As I have learned a long time ago, you enable the USE flags as soon as 
possible.  If you don't, you end up recompiling a lot of packages just 
to enable them later.


Dale

:-)  :-)



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

2010-03-04 Thread Ben de Groot
On 4 March 2010 19:15, Samuli Suominen ssuomi...@gentoo.org wrote:
 On 03/04/2010 07:59 PM, Sebastian Pipping wrote:
 On 03/04/10 15:52, Theo Chatzimichos wrote:
 Hello
 I have managed to split the desktop profile to gnome and kde submenus.

 How about XFCE (and LXDE)?

 Pointless.

 We (xfce) are fine with plain desktop/ profile (now, and after the gnome
 and kde flags are stripped out of it).
 The required flags are somewhat jpeg, png, dbus, cairo, gtk and that's
 about it. HAL is optional.

 I guess it's pretty much same for LXDE.

As LXDE lead, I am very much for a lighter default desktop profile
without gnome and kde specific stuff enabled (as they are going to be
in their own subprofiles). There is no need for a separate profile for
LXDE, just a base desktop profile without too much bloat.

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



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

2010-03-04 Thread Ben de Groot
On 4 March 2010 22:16, Sebastian Pipping sp...@gentoo.org wrote:
 On 03/04/10 19:22, Arfrever Frehtes Taifersar Arahesis wrote:
 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.

 #python on Freenode still reads It's too early to use Python 3.x.
 Are they wrong?

No, they are not wrong. Python 3 is useless for most users. At best
it wastes resources by installing extra python-3 versions of packages
that will never be used because python-2 is the default interpreter,
and they have nothing that really needs python-3. It will also result
in needless runs of python-updater. And it may result in breakage
specific to python-3 which users would not run into if they had only
version 2.x installed.

We need some mechanism to prevent installation of python-3 on
systems of unsuspecting users, and make sure it only gets installed
when the user explicitly chooses to do so. Personally I am
recommending people to locally mask python-3*. I think we should
consider to add it to our package.mask, unless we can find some
other solution.

I am not against it being marked stable, but I am against having
it pulled in on systems that don't need it.

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



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

2010-03-04 Thread Vincent Launchbury

On 03/04/10 12:53, Ben de Groot wrote:

Exactly. The last time I owned a printer is over 5 years ago. So I don't
think cups warrants to be in the standard desktop profile.

Cheers,


I print almost daily, but I'm not sure if printers are commonplace
enough for cups to be a default. Some users may expect it though.

As for the circular deps, it would seem more logical to fix the problem 
at the source, rather than to cover it up for one subset of users.




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

2010-03-04 Thread Dale

chrome://messenger/locale/messengercompose/composeMsgs.properties:

On 5 March 2010 00:27, Dalerdalek1...@gmail.com  wrote:
   

But this issue can be discussed separately from whether cups
should be enabled in profiles.
   

Actually, it is the problem.  You want to remove cups to solve the problem
of circular dependencies.
 

What I wrote was:

   

What it fixes is (1) the circular dependency that people run into on a
fresh install and the default desktop profile, and (2) the default
dependency on cups that many users do not need.
   

But if you choose to ignore what I actually write, then I'd better stop
responding.

Good night,
   


You notice what I wrote?  If I had to install Gentoo again, I would copy 
or set my USE flags first then install.  If I do that right after 
unpacking the tarball, which is how it should be done, then you have 
fixed nothing.  The problem you claim to have fixed is not fixed at all.


Maybe it is not me that should stop responding?

Dale

:-)  :-)



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

2010-03-04 Thread Dale

chrome://messenger/locale/messengercompose/composeMsgs.properties:

On 03/04/10 12:53, Ben de Groot wrote:

Exactly. The last time I owned a printer is over 5 years ago. So I don't
think cups warrants to be in the standard desktop profile.

Cheers,


I print almost daily, but I'm not sure if printers are commonplace
enough for cups to be a default. Some users may expect it though.

As for the circular deps, it would seem more logical to fix the 
problem at the source, rather than to cover it up for one subset of 
users.



I can't think of anyone that doesn't have a printer.  All my friends and 
family that has a computer has a printer.  Heck, I had a printer hooked 
up to my old Vic-20 for goodness sake.  That was over 20 years ago.


He wants to remove the USE flag so that it hides the fact it is not 
really fixed.  If a person does their install as they should, the 
problem will be right there for them to deal with.  Of course, the user 
will the one getting pointed at since they added the flag.  It takes the 
problem off the people that created it and adds it to the user.  That is 
not how it should be fixed.


Dale

:-)  :-)



Re: [gentoo-dev] Re: New category for version control

2010-03-04 Thread Sebastian Pipping
On 03/04/10 23:19, Christian Faulhammer wrote:
  That is the normal procedure when pkgmoving a package.  So nothing
 special. :)

I'm a bit worried because I assume that moving packages is not an
everyday action for most developers.


 - Pushing news out to Gentoo users (and developers)
 
  For what? pkgmove should handle that.

For the cases where being told works better than finding out yourself
the hard way.  I haven't thought to an end what cases that will be.



Sebastian



Re: [gentoo-dev] Moving packages to dev-vcs

2010-03-04 Thread Sebastian Pipping
On 03/04/10 22:38, Robin H. Johnson wrote:
 This contains a critical bug...
 
 cvs add and the matching commit aren't mentioned anywhere...

That's a valid complaint, yes.

I left it out knowingly, maybe not for the better.



Sebastian



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

2010-03-04 Thread Brian Harring
On Thu, Mar 04, 2010 at 06:07:17PM -0600, Dale wrote:
 chrome://messenger/locale/messengercompose/composeMsgs.properties:
  On 03/04/10 12:53, Ben de Groot wrote:
  Exactly. The last time I owned a printer is over 5 years ago. So I don't
  think cups warrants to be in the standard desktop profile.
 
  Cheers,
 
  I print almost daily, but I'm not sure if printers are commonplace
  enough for cups to be a default. Some users may expect it though.
 
  As for the circular deps, it would seem more logical to fix the 
  problem at the source, rather than to cover it up for one subset of 
  users.
 
 
 I can't think of anyone that doesn't have a printer.  All my friends and 
 family that has a computer has a printer.  Heck, I had a printer hooked 
 up to my old Vic-20 for goodness sake.  That was over 20 years ago.

A sampling size of one is of course representive of the whole.  The 
vast majority of gentoo deployments I deal in, cups is bloat- my 
personal laptop, sure, that's a different story.  That's well under a 
tenth of my installs however.

The point there is that one size doesn't fit all- we have inheritance 
in the profiles for a reason.  Shift cups out of the base and into 
desktop specific profiles.

That one shouldn't be a point of debate.


 He wants to remove the USE flag so that it hides the fact it is not 
 really fixed.  If a person does their install as they should, the 
 problem will be right there for them to deal with.  Of course, the user 
 will the one getting pointed at since they added the flag.

Two scenarios.

1) flag is left on by default.  emerge pukes at them about the use 
cycle, user has to go googling and try to figure out the way around 
this (with the end result being flip the flag off, merge stuff, flip 
it back on, rebuild the affected pkgs

2) flag is left off by default.  things emerge fine, but user finds 
they don't have printing.  So... they google it, find out that they 
need to turn a use flag on and then do an emerge -N.


Of the two *viable* scenarios, #2 is frankly the one that's going to 
be less of a pita to users- the folk who need cups on a desktop have a 
clear and simple path to getting cups, versus #1 which requires the 
user to understand dependency cycles induced by use state.

One thing to note- for #1, the user is going to have to do the same 
steps as #2, they're just going to hit a terse failure instead of 
finding that when they go to print, they need to rebuild w/ cups 
support on.  #2 contains the issues/breakage a helluva lot more than 
#1 does.


 It takes the problem off the people that created it and adds it to 
 the user.  That is not how it should be fixed.

Lay off pointing fingers.  Cycles exist and are rather hard to fix- if 
in doubt I strongly suggest you do some research into how stages are 
built (and the existance of the build use flag).  The problem is the 
interdependence in the raw src itself, not ebuild devs.

The use state induced hard dependency cycle issue has been known for a 
long while- the solution to this requires the resolver being able to 
break the cycle via building the pkg multiple times with the use 
state varied to break cycles (as far as I know, none of the PMs do 
this although pkgcore could at one point).

Modifying the resolver to do that sort of cycle breaking is rather 
tricky- work should be done towards it, but it's not the sort of 
thing that's going to be implemented today, and stabled tomorrow.

Basically, punt the flag if you don't want users to hit a cycle on 
fresh installs- it's the only option that exists *now* (and those 
screaming should focus their efforts on implementing the use cycle 
breaking I mentioned above).

~harring


pgpALdmcTUP2i.pgp
Description: PGP signature


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

2010-03-04 Thread Patrick Nagel
Hi,

On 2010-03-05 00:00 UTC Dale wrote:
 chrome://messenger/locale/messengercompose/composeMsgs.properties:
  On 5 March 2010 00:27, Dalerdalek1...@gmail.com  wrote:
  But this issue can be discussed separately from whether cups
  should be enabled in profiles.
  
  Actually, it is the problem.  You want to remove cups to solve the
  problem of circular dependencies.
  
  What I wrote was:
  What it fixes is (1) the circular dependency that people run into on a
  fresh install and the default desktop profile, and (2) the default
  dependency on cups that many users do not need.
  
  But if you choose to ignore what I actually write, then I'd better stop
  responding.
  
  Good night,
 
 You notice what I wrote?  If I had to install Gentoo again, I would copy
 or set my USE flags first then install.  If I do that right after
 unpacking the tarball, which is how it should be done, then you have
 fixed nothing.  The problem you claim to have fixed is not fixed at all.
 
 Maybe it is not me that should stop responding?

Obviously, users who re-install Gentoo the way you do will have less 
difficulties resolving a circular dependency than those who are just following 
the guide and getting their first Gentoo experience.

Patrick.

-- 
Key ID: 0x86E346D4http://patrick-nagel.net/key.asc
Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4


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


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

2010-03-04 Thread Richard Freeman

On 03/04/2010 08:57 PM, Patrick Nagel wrote:

Obviously, users who re-install Gentoo the way you do will have less
difficulties resolving a circular dependency than those who are just following
the guide and getting their first Gentoo experience.


I think that the cups issue is probably worth mentioning in the 
Handbook.  Whether it is there by default or not lots of people get 
burned by it.  A little advanced warning would help.


I think that at the very least following the handbooks to the letter 
should never lead to an error.


I think that a good argument can be made for or against having cups in 
the desktop profile - this might actually be the sort of thing a survey 
would be useful to address.


I think that is separate from the circular dependency issue.  As long as 
we have an unresolved circular dependency I think cups should be off the 
list.  However, I'd be the first to agree that this is a short-term 
solution.


The problem is that we only have two long-term solutions so far:

1.  A smarter package manager that can work through these dependencies 
automatically.


2.  Splitting packages like poppler that have these issues.

Both of these need effort to address.  #1 requires PM work, and #2 
requires an ongoing commitment to do more work to keep poppler working.


Unless somebody can come up with a #3 at this point the most 
constructive thing anybody can do is help out.  A good place to start 
would be to write up some patches to the handbook that clearly explain 
how to deal with this problem.


I'm not sure I agree with the poppler maintainers but they may have 
reasons that aren't apparent to me and the fact is that it is a whole 
lot easier to tell somebody how to maintain a package when I'm not the 
one actually doing the work.  Nothing gets results in FOSS like dirty 
hands...


Rich



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

2010-03-04 Thread Dale

chrome://messenger/locale/messengercompose/composeMsgs.properties:

Hi,

On 2010-03-05 00:00 UTC Dale wrote:
   

chrome://messenger/locale/messengercompose/composeMsgs.properties:
 

On 5 March 2010 00:27, Dalerdalek1...@gmail.com   wrote:
   

But this issue can be discussed separately from whether cups
should be enabled in profiles.
   

Actually, it is the problem.  You want to remove cups to solve the
problem of circular dependencies.
 

What I wrote was:
   

What it fixes is (1) the circular dependency that people run into on a
fresh install and the default desktop profile, and (2) the default
dependency on cups that many users do not need.
   

But if you choose to ignore what I actually write, then I'd better stop
responding.

Good night,
   

You notice what I wrote?  If I had to install Gentoo again, I would copy
or set my USE flags first then install.  If I do that right after
unpacking the tarball, which is how it should be done, then you have
fixed nothing.  The problem you claim to have fixed is not fixed at all.

Maybe it is not me that should stop responding?
 

Obviously, users who re-install Gentoo the way you do will have less
difficulties resolving a circular dependency than those who are just following
the guide and getting their first Gentoo experience.

Patrick.

   


Not quite.  If a person reads the docs and other howto's, they will know 
to set up the USE flags and other things in make.conf.  Isn't the USE 
flags one of Gentoo's strong points?  It is one reason I chose Gentoo 
after all.  I have read where others say it as a strong point as well.  
So, the same thing will most likely happen to anyone installing Gentoo.


Case in point, I also went here:

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1chap=6

If you scroll down to section 2.3, that is where it tells you to select 
your profile.  Want to guess what is next?  Yep, setting the USE flags.  
So, chroot in, sync the tree, select the profile then add your USE 
flags.  So far, we are where we was several replies ago.  Same problem 
and that is following the official install guide.  I wasn't looking at 
the expert guide, that is the general user guide for newbies.


If this was some rarely used flag then maybe this would make a little 
sense.  This is cups.  It's not something that is rarely used or that 
someone even a little familiar with Linux wouldn't know to turn it on.  
They may not know what cups stands for but they know it makes their 
printer work.


I guess like with some other things, the devs can do it their way and 
let that be the end of it.  I just feel the best way is to find a long 
term fix for this and other similar issues.  If it is not done now, it 
will just pile up until it is fixed.  Just like the problem with 
blocks.  It got bad enough that someone had to find a way to fix it.  
Someone did just that.  I don't know who that person is but that was a 
job well done.  We need the same type of person to deal with this.


Dale

:-)  :-)



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

2010-03-04 Thread Dale

chrome://messenger/locale/messengercompose/composeMsgs.properties:

On 03/04/2010 08:57 PM, Patrick Nagel wrote:

Obviously, users who re-install Gentoo the way you do will have less
difficulties resolving a circular dependency than those who are just 
following

the guide and getting their first Gentoo experience.


I think that the cups issue is probably worth mentioning in the 
Handbook.  Whether it is there by default or not lots of people get 
burned by it.  A little advanced warning would help.


I think that at the very least following the handbooks to the letter 
should never lead to an error.


I think that a good argument can be made for or against having cups in 
the desktop profile - this might actually be the sort of thing a 
survey would be useful to address.


I think that is separate from the circular dependency issue.  As long 
as we have an unresolved circular dependency I think cups should be 
off the list.  However, I'd be the first to agree that this is a 
short-term solution.


The problem is that we only have two long-term solutions so far:

1.  A smarter package manager that can work through these dependencies 
automatically.


2.  Splitting packages like poppler that have these issues.

Both of these need effort to address.  #1 requires PM work, and #2 
requires an ongoing commitment to do more work to keep poppler working.


Unless somebody can come up with a #3 at this point the most 
constructive thing anybody can do is help out.  A good place to start 
would be to write up some patches to the handbook that clearly explain 
how to deal with this problem.


I'm not sure I agree with the poppler maintainers but they may have 
reasons that aren't apparent to me and the fact is that it is a whole 
lot easier to tell somebody how to maintain a package when I'm not the 
one actually doing the work.  Nothing gets results in FOSS like dirty 
hands...


Rich




Well said.  I agree with this.  The devs may not be able to fix this 
specific issue but circular deps come up.  We need a long term fix and 
now is as good a time as any to start thinking of one.  Heck, I don't 
expect this to be done this week.  It may take months to fix this or 
just figure out a way to do it.  I just know this is becoming a problem 
and it isn't getting any better even tho people are trying.  I would 
like to see a solution like happened with the blocks issue.  Just some 
way that is easy for the devs to keep the tree clean but also have a 
package manager that can work around this.  Even if it means portage 
spitting out a message that some packages shouldn't be used during the 
update because some packages have to be uninstalled first, that would be 
good.  Let portage wait for a yes/no reply before doing the updates and 
doing them as close to first thing as possible.  Read that as, don't 
compile openoffice then come back to the deps part.


Progress.

Dale

:-)  :-)



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

2010-03-04 Thread Graham Murray
Richard Freeman ri...@gentoo.org writes:

 I think that is separate from the circular dependency issue.  As long
 as we have an unresolved circular dependency I think cups should be
 off the list.  However, I'd be the first to agree that this is a
 short-term solution.

 The problem is that we only have two long-term solutions so far:

 1.  A smarter package manager that can work through these dependencies
 automatically.

 2.  Splitting packages like poppler that have these issues.

Is there not a third, maybe obvious, solution to circular dependencies
on initial install?

3.  Include one or both of the packages in the stage tarball.



[gentoo-dev] Re: Moving packages to dev-vcs

2010-03-04 Thread Ryan Hill
On Thu, 04 Mar 2010 22:08:06 +0100
Sebastian Pipping sp...@gentoo.org wrote:

 So now that we have a new category dev-vcs we need to move suitable
 stuff over there.  Moving packages is complex and error prone:
 This mail tries to guide you through and summarize the process, please
 read on.
 
 [stuff]

Also search through our documentation and fix any package references.


-- 
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-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2

2010-03-04 Thread Ryan Hill
On Thu, 4 Mar 2010 10:43:00 +0100
Ulrich Mueller u...@gentoo.org wrote:

  On Thu, 04 Mar 2010, Petteri Räty wrote:
 
  I think removal of functions is a special case of Adding and
  Updating Eclasses and we already have a policy for this.
 
  Removing functions needs a migration plan. For example how long to
  have a warning there, how long before it can be removed etc.
 
 There may be no general answer to these questions. If it's an eclass
 with limited scope and if the functions are no longer used in the
 tree, then I don't see the need for a long transition period. OTOH,
 for widespread eclasses like eutils you'd probably want it.
 
  I don't see how you can get those from the common policy?
 
 If you don't email gentoo-dev first, and end up breaking something,
 expect to be in a lot of trouble.

Now that's a policy I can get behind. :)


-- 
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


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

2010-03-04 Thread Dale

chrome://messenger/locale/messengercompose/composeMsgs.properties:

Richard Freemanri...@gentoo.org  writes:

   

I think that is separate from the circular dependency issue.  As long
as we have an unresolved circular dependency I think cups should be
off the list.  However, I'd be the first to agree that this is a
short-term solution.

The problem is that we only have two long-term solutions so far:

1.  A smarter package manager that can work through these dependencies
automatically.

2.  Splitting packages like poppler that have these issues.
 

Is there not a third, maybe obvious, solution to circular dependencies
on initial install?

3.  Include one or both of the packages in the stage tarball.

   


I'm not a dev but what else uses poppler or other packages that would be 
added?  Also, this would affect server profiles.  Last I checked, 
server, desktop or any other profile starts from the same tarball.  It's 
a idea but would it be a good one?  I don't know the answer to that 
question.


Is this a Gentoo thing or is this caused by upstream?  I only use Gentoo 
so maybe it affects other distros as well.


Dale

:-)  :-)



Re: [gentoo-dev] Moving packages to dev-vcs

2010-03-04 Thread Serkan Kaba
I'm hitting a repoman failure

repoman: dev-vcs is not an official category.  Skipping QA checks in
this directory.
Please ensure that you add dev-vcs to
/home/firari/Desktop/çalışma/gentoo/gentoo-x86/profiles/categories
if it is a new category.
-
After hitting it for the first time I updated the whole profiles dir and
still failing

Thanks in advance.
-- 
Sincerely,
Serkan KABA
Gentoo Developer



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

2010-03-04 Thread Zeerak Mustafa Waseem
On Thu, Mar 04, 2010 at 10:19:05PM -0600, Dale wrote:
 chrome://messenger/locale/messengercompose/composeMsgs.properties:
  Richard Freemanri...@gentoo.org  writes:
 
 
  I think that is separate from the circular dependency issue.  As long
  as we have an unresolved circular dependency I think cups should be
  off the list.  However, I'd be the first to agree that this is a
  short-term solution.
 
  The problem is that we only have two long-term solutions so far:
 
  1.  A smarter package manager that can work through these dependencies
  automatically.
 
  2.  Splitting packages like poppler that have these issues.
   
  Is there not a third, maybe obvious, solution to circular dependencies
  on initial install?
 
  3.  Include one or both of the packages in the stage tarball.
 
 
 
 I'm not a dev but what else uses poppler or other packages that would be 
 added?  Also, this would affect server profiles.  Last I checked, 
 server, desktop or any other profile starts from the same tarball.  It's 
 a idea but would it be a good one?  I don't know the answer to that 
 question.
 
 Is this a Gentoo thing or is this caused by upstream?  I only use Gentoo 
 so maybe it affects other distros as well.
 
 Dale
 
 :-)  :-)
 

Well the merge of the poppler packages seems to have been made in upstream. So 
it should affect other distros as well. Perhaps not binary distros, though. 
For now I don't see any other way to solve it other than removing the use flag, 
and perhaps adding a warning in the handbook about this circular dep.
the idea about using a tarball is good enough, the problem with that (as I see 
it) is what Dale also points out. Desktop and server profiles start from the 
same tarball, so in order to do this effectively (I seem to remember people 
coming to an agreement that a server profile wouldn't need cups), there'd have 
to be a tarball for desktops and one for servers.
I quite like the idea of a unified tarball, and going from there, choosing the 
right profile etc. As opposed to choosing the right tarball, then choosing the 
right profile that fits with that tarball. To me it seems to complicate matters 
where there's no need. And also, we would like for portage to continue to grow, 
and being able to resolve circular dependencies automatically, doesn't seem 
like a bad goal. :-)

-- 
Zeerak Waseem


pgpe6E98z7YDh.pgp
Description: PGP signature


Re: [gentoo-dev] Moving packages to dev-vcs

2010-03-04 Thread Petteri Räty
On 03/04/2010 11:28 PM, Markos Chandras wrote:
 On Thursday 04 March 2010 23:08:06 Sebastian Pipping wrote:


 - Update reverse dependencies
 http://tinderbox.dev.gentoo.org/misc/dindex/dev-util/${PN}
 http://tinderbox.dev.gentoo.org/misc/rindex/dev-util/${PN}
 This might require too much time so the tree will be broken for a while I 
 guess
 

When doing something like this, you can ask infra to suspend CVS to
rsync for you for a while.

Regards,
Petteri




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] VCS used for development of portage

2010-03-04 Thread Zac Medico
On 03/02/2010 03:22 PM, Sebastian Pipping wrote:
 Hello!
 
 
 I've been playing with Git conversions of the portage repository.
 The current demo conversion from anon SVN is up here:
 
   http://git.goodpoint.de/?p=portage.git;a=summary
 
 NOTE: Do not use it for development, yet - it's a demo!

It looks very nice to me. I noticed that it preserved continuity
when branches got moved around, so the history seems like it will be
fully intact. Great job!
-- 
Thanks,
Zac