Re: [gentoo-dev] python module

2005-08-04 Thread Alin Dobre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Rene Zbinden wrote:
 Hi
 
 I want to write an ebuild, that installs a python module. After unpacking the 
 zipfile there is only one module module.py. What is the best way to install 
 that package. Is there an eclass that I can use?
 

# The distutils eclass is designed to allow easier installation of
# distutils-based python modules and their incorporation into
# the Gentoo Linux system.


- --
Alin DOBRE
Romanian Lead Translator
Gentoo Documentation Project: http://www.gentoo.org/doc/en/
Gentoo.RO Community:  http://www.gentoo.ro/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC8cCEmG51ym6Hu9gRAk9gAKCRMqjuq6p/2Ol3IWe+PJ8w9QIwngCg7bqZ
EW6k7a7lCsDq+vABZDPR+dg=
=3coQ
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] python module

2005-08-04 Thread Rene Zbinden
Yes in the meantime I found that eclass. The problem was, that there was no 
setup.py file. I created my own and put it into the files directory. 

Here is my ebuild:
http://bugs.gentoo.org/show_bug.cgi?id=101296

pyamazon is a Python wrapper for the Amazon web API.
Homepage: http://www.josephson.org/projects/pyamazon/

You can check it out if you want. Comments are welcome.

On Thursday 04 August 2005 09:15, Alin Dobre wrote:
 Rene Zbinden wrote:
  Hi
 
  I want to write an ebuild, that installs a python module. After unpacking
  the zipfile there is only one module module.py. What is the best way to
  install that package. Is there an eclass that I can use?

 # The distutils eclass is designed to allow easier installation of
 # distutils-based python modules and their incorporation into
 # the Gentoo Linux system.


 --
 Alin DOBRE
 Romanian Lead Translator
 Gentoo Documentation Project: http://www.gentoo.org/doc/en/
 Gentoo.RO Community:  http://www.gentoo.ro/

-- 
cheers,
reen
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-04 Thread Bertrand Jacquin
that's great :)

Thanks for doing that.
That's exactly what I done with XCB ebuilds. Maybe some of you don't
know xcb, it a remplacement for Xlib. Currently it only available on
cvs. I think it couldn't have to be ignore it.

Some ebuilds for :
http://guybrush.ath.cx/svn/public/portage/x11-libs/

Website :
http://freedesktop.org/Software/xcb

Also It's on heavy devlopment, and I'not a dev. So take the choice
you'll find the best :)

++
Beber

On 8/1/05, Donnie Berkholz [EMAIL PROTECTED] wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 (This is an expanded, updated version of a recent blog post, so some of
 you may have already seen parts of it.)
 
 Background: Upstream is splitting up the monolithic X.Org X11 release
 into a huge number of modular releases, the combination of which will be
 released as X11R7. Simultaneously, a source-identical monolith will be
 released as X11R6.9.
 
 Gentoo will only add X11R7, the modular release. Roughly 280 packages
 will comprise this release, so this will entail adding a few new
 categories to deal with them.
 
 Here's the categories I'm looking at using, which is mostly a mirror of
 how upstream breaks it down:
 
 ~* x11-apps: The various applications that come along with all X11RX
 releases. 86 ebuilds.
 
 ~* x11-proto: The protocol headers. 30 ebuilds.
 
 ~* x11-libs: 43 ebuilds.
 
 ~* media-fonts: 35 ebuilds.
 
 ~* x11-drivers: All the video and input drivers. 68 ebuilds.
 
 ~* x11-base: The actual X server, and meta-ebuilds. 10 ebuilds.
 
 ~* app-doc: Old-format docs that haven't been broken into individual
 packages yet. Probably just a couple ebuilds.
 
 ~* x11-misc: The data module, which contains bitmaps and xkbdata.
 Also the util module, with imake, etc. 10 ebuilds.
 
 The new categories are x11-apps, x11-proto and x11-drivers. Of these,
 the name for x11-proto (the protocol headers) is debatable. The upstream
 module they're all in is called proto, and their pkg-config (*.pc)
 files are called fooproto. But I'm also open to names such as
 x11-protocol or x11-headers, so let me know what you think makes the
 most sense, both in understanding the meaning and in combination with
 upstream's naming.
 
 My plan is to have a series of submetabuilds that combine into a
 supermetabuild, which will be the actual xorg-x11 ebuild. There will
 be one submetabuild for each major component: apps, drivers, libraries,
 etc. This will allow me to split USE flags out a bit (so e.g., x11-fonts
 would have 100dpi, 75dpi, truetype as flags) as well as allow people who
 only want e.g. libraries for a headless server to get them cleanly.
 
 I intend to begin adding these packages to the tree shortly after the
 first release candidate, which should be happening very soon.
 
 
 Repercussions:
 
 All packages in the tree will need to clearly enunciate exactly which
 parts of X they need as DEPENDs and RDEPENDs, down to the library or
 application level.
 
 Until such time as that becomes possible for everyone to do, the
 x11-libs metabuild will PROVIDE virtual/x11. But realize that not
 everybody will have or want all the X libraries installed, when they
 only need a few.
 
 If your package depends on virtual/x11 for any reason besides libraries,
 it will require a dependency update to work with the new packages.
 
 
 My preliminary work on the modular ebuilds is at
 http://dev.gentoo.org/~spyderous/x-modular/ -- browse this at your
 leisure. The metabuilds are all in x11-base/. There will be no tarball
 of this overlay available because I'm not interested in dealing with
 other testers before the first release candidate has even come out.
 
 I eagerly await your questions and concerns.
 
 Thanks,
 Donnie
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.1 (GNU/Linux)
 
 iD8DBQFC7owDXVaO67S1rtsRAu68AJwISOSEwUChCvgQ96Y1KJGFmNYb/wCfaOEz
 WURqd84yUyrb9cJqmiZE6sc=
 =L4yH
 -END PGP SIGNATURE-
 --
 gentoo-dev@gentoo.org mailing list
 


-- 
gentoo-dev@gentoo.org mailing list



RE: [gentoo-dev] Re: where goes Gentoo?

2005-08-04 Thread Eric Brown


Interesting thread.  I have used Gentoo in enterprise situations very
successfully, and I think the whole QA/live-tree argument is moot.  In
an enterprise environment, you might have a backup/testing machine to
run your updates on first before they went live.  You also wouldn't run
new packages unless they passed your own QA tests first.

Given the incredible flexibility of portage to support local mirrors,
binary package preparation, and localized versions of packages
(portdir_overlay), I would say that Gentoo is quite a contender in the
enterprise environment.

Perhaps we need some enterprise documentation to help people realize the
full potential of portage?


-Eric

-- 
gentoo-dev@gentoo.org mailing list



RE: [gentoo-dev] Re: where goes Gentoo?

2005-08-04 Thread Chris Gianelloni
On Thu, 2005-08-04 at 09:04 -0400, Eric Brown wrote:
 
 Interesting thread.  I have used Gentoo in enterprise situations very
 successfully, and I think the whole QA/live-tree argument is moot.  In
 an enterprise environment, you might have a backup/testing machine to
 run your updates on first before they went live.  You also wouldn't run
 new packages unless they passed your own QA tests first.
 
 Given the incredible flexibility of portage to support local mirrors,
 binary package preparation, and localized versions of packages
 (portdir_overlay), I would say that Gentoo is quite a contender in the
 enterprise environment.
 
 Perhaps we need some enterprise documentation to help people realize the
 full potential of portage?

I think you've missed some of the idea of enterprise support.  See,
for starters, every person shouldn't have to create their own
implementation of everything.  Perhaps a better solution would be a
package that when installed, builds up a local mirror, a binary package
repository (with revision control), an automated update system, a system
for updating rolled out machines without forcing the use of etc-update
on each machine, a slower moving stable tree capable of being certified
with applications, and most likely a phone number of someone to call
when the shit hits the fan.

While I will completely agree that Gentoo *can* be used in the
enterprise successfully, that does not make it enterprise-ready, in
any sense.  Many people also seem to misunderstand the concept of
enterprise when we are referring to it in this manner.  We don't mean
I'm running it on 10 servers in production or anything like that.  We
mean I'm running this as our production platform for Linux services
across our entire enterprise, that could be hundreds or even thousands
of servers instead.  While it might be possible to maintain a handful
of Gentoo servers, it is next to impossible to maintain an army of them,
without spending significant up-front manpower to design, test, and
implement your own set of management tools.  Gentoo has no real
management tools.  There are a few here and there that do specific
tasks, but there isn't anything designed to really take control over
your network of systems.  To be fair, Red Hat doesn't have anything like
this, either.  Their Satellite Server product is good for initial
builds and for updates, but falls short on the management aspects.
Novell's offerings are probably the best examples of what we really
need.  Of course, most people would be happy with even rudimentary
management capabilities, as currently, we have none.  We don't have any
form of update server.  You have to build one yourself.  We don't have
any form of jump-start or kickstart for rapid automated deployments.
You have to build one yourself.  Now, we do have the Gentoo Linux
Installer project, which has this as one of its goals, so we will have
this component at some point in the future.

Last, there's the Our servers just went belly up, and I want to call up
someone on the phone and give them a piece of my mind issue which gives
managers a warm, fuzzy feeling, that we cannot provide.  If something
goes wrong with RHEL or SLES, you call up Red Hat or Novell and get them
to work on the problem.  If something goes wrong with Gentoo, you hop on
IRC, or file a bug, and hope that somebody can help you in the time you
need it done in, and not in 3 weeks when the maintaining developer gets
back from his tour of the African Dung Beetle in it's own environment.
Liability is a big selling point for the enterprise.

I work for a telecommunications company, and we run Linux and Solaris.
For our Linux, we run Red Hat, even though they have, on staff, one of
the people that understands Gentoo's deployment capabilities better than
most, via catalyst and the GLI.  Why do we run Red Hat?  When something
breaks with one of their packages, we call them, and expect them to fix
it.  It is also a name that gives upper management the warm fuzzies.
Gentoo has neither the brand recognition, nor the support capabilities
to be a good sale to management.

I'm not denying that Gentoo is very powerful, flexible, and gives the
power back to the administrator, but that doesn't make it enterprise
ready or friendly.  A few success stories from a few people isn't much
to support the position, when we are lacking in so many simple and
obvious ways.  Remember, if a manager can think of multiple ways to
knock down the use of Gentoo, like the ones I've given above, what are
you going to do to refute his claims?

I want to see Gentoo as an enterprise-capable distribution myself, but I
also understand that it is a long, hard road ahead of us, and there will
still be some things we simply cannot provide as a community
distribution, which was my reasoning behind the fork.  There would
need to be an entity that is responsible, liable, if you will, when
something goes wrong, and that has the manpower and resources to fix it.

-- 
Chris Gianelloni

RE: [gentoo-dev] Re: where goes Gentoo?

2005-08-04 Thread Eric Brown



On Thu, 2005-08-04 at 09:04 -0400, Eric Brown wrote:
 
 Interesting thread.  I have used Gentoo in enterprise situations very
 successfully, and I think the whole QA/live-tree argument is moot.  In
 an enterprise environment, you might have a backup/testing machine to
 run your updates on first before they went live.  You also wouldn't run
 new packages unless they passed your own QA tests first.
 
 Given the incredible flexibility of portage to support local mirrors,
 binary package preparation, and localized versions of packages
 (portdir_overlay), I would say that Gentoo is quite a contender in the
 enterprise environment.
 
 Perhaps we need some enterprise documentation to help people realize the
 full potential of portage?

I think you've missed some of the idea of enterprise support.  See,
for starters, every person shouldn't have to create their own
implementation of everything.  Perhaps a better solution would be a
package that when installed, builds up a local mirror, a binary package
repository (with revision control), an automated update system, a system
for updating rolled out machines without forcing the use of etc-update
on each machine, a slower moving stable tree capable of being certified
with applications, and most likely a phone number of someone to call
when the shit hits the fan.

Every business application of Gentoo I've done has been different.  I don't 
think I could generalize my needs into a single ebuild.  Although generally I 
have used rsyncd and apache, I never use them in the same way.  What's so hard 
about using the default rsyncd config, and adding distfiles to your apache 
document root? (what 90% of people would use).

About automating updates and etc-update:  you can rsync your config file 
sometimes and just bypass all of the portage stuff.  You could mount some 
config dirs over nfs even.  You could even remove config_protect on some dirs 
and roll your own custom packages.

About a slower moving portage tree for enterprise users:  Great idea, I think 
there's a GLEP about that.  I think it's best handled by third parties who can 
spend the money/man power on that kind of QA.

This brings me to your last point about calling someone when there are 
problems:  There are companies that provide Linux services, even Gentoo 
specific services.  Some of these companies might even provide enterprise-grade 
portage mirrors with support for the packages they maintain there.


While I will completely agree that Gentoo *can* be used in the
enterprise successfully, that does not make it enterprise-ready, in
any sense.  Many people also seem to misunderstand the concept of
enterprise when we are referring to it in this manner.  We don't mean
I'm running it on 10 servers in production or anything like that.  We
mean I'm running this as our production platform for Linux services
across our entire enterprise, that could be hundreds or even thousands
of servers instead.  While it might be possible to maintain a handful
of Gentoo servers, it is next to impossible to maintain an army of them,
without spending significant up-front manpower to design, test, and
implement your own set of management tools.  Gentoo has no real
management tools.  There are a few here and there that do specific
tasks, but there isn't anything designed to really take control over
your network of systems.  To be fair, Red Hat doesn't have anything like
this, either.  Their Satellite Server product is good for initial
builds and for updates, but falls short on the management aspects.
Novell's offerings are probably the best examples of what we really
need.  Of course, most people would be happy with even rudimentary
management capabilities, as currently, we have none.  We don't have any
form of update server.  You have to build one yourself.  We don't have
any form of jump-start or kickstart for rapid automated deployments.
You have to build one yourself.  Now, we do have the Gentoo Linux
Installer project, which has this as one of its goals, so we will have
this component at some point in the future.

I'm sorry, I never ran 1000 Gentoo machines in production like that, I thought 
enterprise meant this (answers.com):

en·ter·prise (ĕn'tər-prīz') pronunciation
n.

   1. An undertaking, especially one of some scope, complication, and risk.
   2. A business organization.
   3. Industrious, systematic activity, especially when directed toward profit: 
Private enterprise is basic to capitalism.
   4. Willingness to undertake new ventures; initiative: “Through want of 
enterprise and faith men are where they are, buying and selling, and spending 
their lives like serfs” (Henry David Thoreau).

Doesn't this just go to show that in business, everyone wants something 
different from Gentoo?  What does Novell offer to manage large numbers of linux 
boxen?  Are you sure projects like OpenMosix don't have tools you could use to 
manage such a large number of machines?

Maybe we can't rely on portage so much in scenarios 

RE: [gentoo-dev] Re: where goes Gentoo?

2005-08-04 Thread Chris Gianelloni
On Thu, 2005-08-04 at 11:48 -0400, Eric Brown wrote:
 Every business application of Gentoo I've done has been different.  I don't 
 think I could generalize my needs into a single ebuild.  Although generally I 
 have used rsyncd and apache, I never use them in the same way.  What's so 
 hard about using the default rsyncd config, and adding distfiles to your 
 apache document root? (what 90% of people would use).

You completely missed the management aspect here.  I'm talking about
some form of actual enterprise-ready management framework for
controlling a set of Gentoo servers centrally from deployment to
maintenance and upgrades.

 About automating updates and etc-update:  you can rsync your config file 
 sometimes and just bypass all of the portage stuff.  You could mount some 
 config dirs over nfs even.  You could even remove config_protect on some dirs 
 and roll your own custom packages.

You can... You can... You can...

All I heard here was a bunch of excuses about how a person can take the
time to implement something that's been implemented by countless other
people, because Gentoo does not provide a framework for doing this.  The
whole idea of being enterprise-ready is having a drop-in solution that
works right off the bat, with minimal to no configuration for basic
services.  All of your solutions requires manpower to accomplish that
not every enterprise can afford to spend.  Once again, this is why
Gentoo is currently not used in these situations.

 About a slower moving portage tree for enterprise users:  Great idea, I think 
 there's a GLEP about that.  I think it's best handled by third parties who 
 can spend the money/man power on that kind of QA.

Yes, there is a GLEP about this.  This is also the first step to being
able to provide any level of enterprise-readiness.  You simply cannot
tell someone to upgrade glibc to some new version if something is wrong
with the current one.  They want a patch for the current one.  Think
bug-fixes only with absolutely zero new features between whatever form
of releases are created.

 This brings me to your last point about calling someone when there are 
 problems:  There are companies that provide Linux services, even Gentoo 
 specific services.  Some of these companies might even provide 
 enterprise-grade portage mirrors with support for the packages they maintain 
 there.

I don't think I would stake my company's infrastructure on the reliance
on Bob and Joe's Gentoo Support Hotline, sorry.  Not to mention you
haven't actually given a single example of someone who can provide this
level of enterprise support.  There's a reason why you haven't given an
example.  None exists.

 I'm sorry, I never ran 1000 Gentoo machines in production like that, I 
 thought enterprise meant this (answers.com):
 
 en·ter·prise (ĕn'tər-prīz') pronunciation
 n.
 
1. An undertaking, especially one of some scope, complication, and risk.
2. A business organization.
3. Industrious, systematic activity, especially when directed toward 
 profit: Private enterprise is basic to capitalism.
4. Willingness to undertake new ventures; initiative: “Through want of 
 enterprise and faith men are where they are, buying and selling, and spending 
 their lives like serfs” (Henry David Thoreau).

Wow.  A dictionary definition that is completely out of context and
doesn't account for the word enterprise being used as a technical
representation.

I've got a few enterprise definitions for you, too.

The Enterprise type is a two-man hiking sailing dinghy with a
distinctive blue sail and no spinnaker. Despite being one of the older
classes of dinghies, it remains popular and well used for both cruising
and racing. It has a combination of stability, size and power which
contiues to appeal to all ages, and to sailing schools.

...or...

Star Trek: Enterprise is a science fiction television series set in the
Star Trek universe.(Until the third season its title was simply
Enterprise, and it is often abbreviated as ST:ENT or ENT).The series
follows the adventures of the crew of the Enterprise (NX-01), the first
human interstellar ship that can achieve Warp 5.Enterprise premiered in
the United States on September 26, 2001, and is presently in its fourth,
and final, season.

...though the one I am looking for, and the one that fits the scope of
this conversation is this one:

In the computer industry, an enterprise is an organization that uses
computers. In practice, the term is applied much more often to larger
organizations than smaller ones.

We are using this in practice.  Therefore, we are speaking of large
organizations, and not just *any* organization.

 Doesn't this just go to show that in business, everyone wants something 
 different from Gentoo?  What does Novell offer to manage large numbers of 
 linux boxen?  Are you sure projects like OpenMosix don't have tools you could 
 use to manage such a large number of machines?

Not really.  It does go to show that you'll go 

Re: [gentoo-dev] Re: where goes Gentoo?

2005-08-04 Thread Philip Webb
050804 Chris Gianelloni wrote:
-- long interesting account of life in the enterprise snipped --
 I want to see Gentoo as an enterprise-capable distribution myself,
 but I also understand that it is a long, hard road ahead of us
 and there will still be things we cannot provide as a community distro.
 There would need to be an entity responsible when something goes wrong
 and that has the manpower and resources to fix it.

There's no way a volunteer organisation like Gentoo could undertake that.
What would be essential is a company with capital invested
 probably an insurance policy somewhere in the background,
which employs Gentoo-knowledgeable staff to build  fix systems.
It would probably have its own mirror with a selection of Gentoo packages,
which it is prepared to guarantee as reliable  safe to use,
 would develop all the enterprise-level management tools you describe.
Hopefully, it would give something back to the underlying volunteer Gentoo
by way of free staff time  some tools all of us might benefit from.

The first step is a visit to your friendly neighbourhood bank manager (smile).

-- 
,,
SUPPORT ___//___,  Philip Webb : [EMAIL PROTECTED]
ELECTRIC   /] [] [] [] [] []|  Centre for Urban  Community Studies
TRANSIT`-O--O---'  University of Toronto
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: where goes Gentoo?

2005-08-04 Thread Brian D. Harring
Long one kiddies... responses inlined, bit more interested in 
discussion of what's required/desired then your definition of 
enterprise sucks... (throws on the flamesuit)...


On Thu, Aug 04, 2005 at 02:35:08PM -0400, Chris Gianelloni wrote:
 On Thu, 2005-08-04 at 11:48 -0400, Eric Brown wrote:
  Every business application of Gentoo I've done has been different.  I don't 
  think I could generalize my needs into a single ebuild.  Although generally 
  I have used rsyncd and apache, I never use them in the same way.  What's so 
  hard about using the default rsyncd config, and adding distfiles to your 
  apache document root? (what 90% of people would use).
 
 You completely missed the management aspect here.  I'm talking about
 some form of actual enterprise-ready management framework for
 controlling a set of Gentoo servers centrally from deployment to
 maintenance and upgrades.

Elaborate on what you explicitly want out of portage please- the 
domain concept (aside from being useful design wise) *should* allow 
groupping of boxes (groupping of domains really) behind it, so you can 
effectively have a set of boxes, pushing changes to each.

Mind you no code written, but current design is intended to allow 
remote chunks to be swapped in/out of portagelib on the fly 
(including the actual portage configuration).

  About automating updates and etc-update:  you can rsync your config file 
  sometimes and just bypass all of the portage stuff.  You could mount some 
  config dirs over nfs even.  You could even remove config_protect on some 
  dirs and roll your own custom packages.
 
 You can... You can... You can...
 
 All I heard here was a bunch of excuses about how a person can take the
 time to implement something that's been implemented by countless other
 people, because Gentoo does not provide a framework for doing this.  The
 whole idea of being enterprise-ready is having a drop-in solution that
 works right off the bat, with minimal to no configuration for basic
 services.  All of your solutions requires manpower to accomplish that
 not every enterprise can afford to spend.  Once again, this is why
 Gentoo is currently not used in these situations.

Better angle of discussion rather then we aren't there yet is the 
specifics of what is needed to *get* there in peoples opinion.

It's not an overnight thing, glep19 (stable portage tree) addresses a 
chunk of concerns when/if it's implemented, but I'm a bit more 
interested in the the other tools people desire alongside.

Re: a drop-in solution, considering that gentoo is effectively all 
over the map (seriously, look at the tree), define the profile for the 
drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc.

Specifics...

Hell, I have yet to see what I would define as a proper solution for 
config manamagent for N gentoo boxes.  NFS solution possibly, but that 
seems a bit hackish to me.

  This brings me to your last point about calling someone when there are 
  problems:  There are companies that provide Linux services, even Gentoo 
  specific services.  Some of these companies might even provide 
  enterprise-grade portage mirrors with support for the packages they 
  maintain there.
 
 I don't think I would stake my company's infrastructure on the reliance
 on Bob and Joe's Gentoo Support Hotline, sorry.  Not to mention you
 haven't actually given a single example of someone who can provide this
 level of enterprise support.  There's a reason why you haven't given an
 example.  None exists.

Moot point frankly, considering we're all volunteers; someone 
*could* get off their butts and start up an attempt to provide hand 
holding (effectively what you're coloring the management arg as) 
services, but even if they did, the followup arg would be that you 
can't yet trust this new support company, because they're new.
Etc.

Basically, we don't have control over that portion, so... what 
can be mangled that we *do* have control over, and has an effect?


 
 [snip]
 In the computer industry, an enterprise is an organization that uses
 computers. In practice, the term is applied much more often to larger
 organizations than smaller ones.
 
 We are using this in practice.  Therefore, we are speaking of large
 organizations, and not just *any* organization.

That's a really crappy description, rather nebulous. :)
And... nobody probably cares about loose definitions, 'cause loose 
definitions are moving targets.  Again, specific suggestions/requests 
would rock.

Mentioned management tools, well, get into specifics; pxe network 
installs/imaging?  Single tree/cache for N servers?  Ability to push 
updates out to a specific box, or set of servers?  Integration of 
portage contents db with IDS tools?


 Novell has several tools, that when used in combination, form a cohesive
 framework for deploying, managing, and upgrading systems.  What's even
 better, is it isn't just limited to Linux, but I'll leave that as an
 exercise for the 

RE: [gentoo-dev] Re: where goes Gentoo?

2005-08-04 Thread Eric Brown
I think Brian is right, we should stick to being constructive.

Let's start an enterprise project on Gentoo.org
Goals:
1) provide documentation on existing tools and practices for
business/enterprise users.
2) try to enhance the set of tools to build a comprehensive
framework that makes it easy to use and deploy Gentoo in a
business/enterprise environment.
3) provide information so that concerned parties can find
companies that specialize in Gentoo deployment/management/support.


Any ideas?


--Eric

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Last rites for media-video/DFBsee

2005-08-04 Thread Diego 'Flameeyes' Pettenò
This is my first last rites post, yay :)

Ok well I just seen this today and I looked for it: media-video/dfbsee is just 
a copy of media-video/DFBsee, that doesn't seems maintained anymore.

ChrisWhite started moving it but the job is stuck at December 2004.

If nobody has a good reason against this, I'm going to remove 
media-video/DFBsee from the tree a week from now.

-- 
Diego Flameeyes Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgppFhu4uRu7u.pgp
Description: PGP signature


Re: [gentoo-dev] Re: where goes Gentoo?

2005-08-04 Thread Chris Gianelloni
On Thu, 2005-08-04 at 14:37 -0500, Brian D. Harring wrote:
 Elaborate on what you explicitly want out of portage please- the 
 domain concept (aside from being useful design wise) *should* allow 
 groupping of boxes (groupping of domains really) behind it, so you can 
 effectively have a set of boxes, pushing changes to each.
 
 Mind you no code written, but current design is intended to allow 
 remote chunks to be swapped in/out of portagelib on the fly 
 (including the actual portage configuration).

The only things I could see being needed out of portage itself is the
ability to control emerge commands remotely, such as forcing an update
of apache to $version to resolve a vulnerability.

Besides the back-end portage pieces, there would need to be a front-end
interface for performing these tasks.

 Better angle of discussion rather then we aren't there yet is the 
 specifics of what is needed to *get* there in peoples opinion.

Agreed completely.

Some things I could see as needed:

1. applying updates on any file that is under CONFIG_PROTECT where the
md5/file-size matches that in /var/db for the file without user
interaction
2. automatic removal of files under CONFIG_PROTECT where the
md5/file-size matches that in /var/db during unmerge

 It's not an overnight thing, glep19 (stable portage tree) addresses a 
 chunk of concerns when/if it's implemented, but I'm a bit more 
 interested in the the other tools people desire alongside.

As am I.  The Installer is one such project.  We do not have any project
that I am aware of that is designed to resolve the problem of remotely
managing a server.  There is nothing for pushing config changes/package
updates/new packages.  There would need to be some interface for doing
these things.  Stop by any trade show, such as LWE, and you'll see guys
pushing their wares on remotely managing Linux.  We should provide
something like this ourselves.

eg. If I want to change the subnet mask or default router on 50 machines
on my network, I should be able to do so via a simple interface and have
the work done automatically.

 Re: a drop-in solution, considering that gentoo is effectively all 
 over the map (seriously, look at the tree), define the profile for the 
 drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc.

I meant a drop-in management solution, not a specific set of server
profiles, though those could be created with the Installer.  In fact, I
see the Installer as one of the first pieces of the framework necessary
for deployment and management of a large number of servers.  Once the
netfe interface is completed with the Installer, you will be able to PXE
boot your server and have it load a specific installer profile, and it
will install Gentoo to those specifications.  Beyond that, we lose
control of the server and must manually perform all other actions.

 Specifics...
 
 Hell, I have yet to see what I would define as a proper solution for 
 config manamagent for N gentoo boxes.  NFS solution possibly, but that 
 seems a bit hackish to me.

There isn't a proper solution yet.  Honestly, something like a
repository holding configuration information with revision control would
probably be best, so you can revert changes.  There are quite a few
systems like this out for Red Hat and others, but nothing that is
Gentoo-specific, or even Gentoo-capable, as far as I know.  We should
beat people to the punch and design one ourselves.

The main things we need to provide are:

Provisioning - building a server from bare metal to some pre-determined
state
Management - being able to make changes to existing servers without
manually logging into each to make the changes
Updates - this somewhat goes with management, but a facility for
disseminating patches or updated packages to servers

 Moot point frankly, considering we're all volunteers; someone 
 *could* get off their butts and start up an attempt to provide hand 
 holding (effectively what you're coloring the management arg as) 
 services, but even if they did, the followup arg would be that you 
 can't yet trust this new support company, because they're new.
 Etc.

Not entirely moot, as a company could be formed in cooperation with the
Foundation, as I stated earlier in the thread.  This symbiotic
relationship would give the new company a bit more credit, as it will be
supported by the Foundation.  This could be a Foundation-owned company,
or a completely separate entity.  Anyway, this isn't so much my point,
as many people *are* willing to forgo having a human voice on the end of
a phone.

 Basically, we don't have control over that portion, so... what 
 can be mangled that we *do* have control over, and has an effect?

Our tools.  Currently, we have very few Gentoo tools used for managing
a system.  We would need to define the requirements for these tools, and
then work on ways of getting them built.  It's like I said, I think the
primary weakness in Gentoo's enterprise adoption is the need for each

[gentoo-dev] Bugday announcement

2005-08-04 Thread Bjarke Istrup Pedersen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Alright everybody, here we go again :-)

This is my first announcement, so let?s hope I get everything right.
On next Saturday it will be bugday again, unfortunately the new bugday
website isn't done yet, but the little dwarf sitting under my table
doing all the coding has run away, and I haven't been able to find him
yet.

Well, back to business, it will be on #gentoo-bugs on irc.freenode.net
on Saturday. (Thanks to time zones, it almost lasts two days, so join
in early).

Bugday has existed two years now, and we have an article in the newest
GWN, so if you haven't read it yet, take the time to do so, you can
find it here: http://www.gentoo.org/news/en/gwn/20050801-newsletter.xml

Hope to see a lot of you there; unfortunately there won't be free
cookies this time.

Best Regards
Bjarke Istrup Pedersen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
 
iD8DBQFC8pSzO+Ewtpi9rLERAtI4AJ9wdTbg/iWpkNwzLNqR1QtpYZzqLgCgzYBR
LHTDe2BKRzT9+SldEjIesyY=
=IALR
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Bugday announcement

2005-08-04 Thread Scott Shawcroft
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bjarke Istrup Pedersen wrote:

 Alright everybody, here we go again :-)

 This is my first announcement, so let?s hope I get everything
 right. On next Saturday it will be bugday again, unfortunately the
 new bugday website isn't done yet, but the little dwarf sitting
 under my table doing all the coding has run away, and I haven't
 been able to find him yet.

 Well, back to business, it will be on #gentoo-bugs on
 irc.freenode.net on Saturday. (Thanks to time zones, it almost
 lasts two days, so join in early).

 Bugday has existed two years now, and we have an article in the
 newest GWN, so if you haven't read it yet, take the time to do so,
 you can find it here:
 http://www.gentoo.org/news/en/gwn/20050801-newsletter.xml

 Hope to see a lot of you there; unfortunately there won't be free
 cookies this time.

 Best Regards Bjarke Istrup Pedersen

I'll be there as much as I can.  I'd like to get going on the new site.
~Scott
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC8pT+10ekhar8gdURAsOcAJkBfA0yg/e6m7fYq5hFCZQ6X5Xn/QCeIHKR
tNNtW4A3hM44aXuaGJUkBEk=
=CRPd
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] utf-8 fixes for metadata.xml

2005-08-04 Thread Ciaran McCreesh
I've just gone through and fixed all of the broken utf-8 in metadata.xml
files. I think... There was rather a lot of it due to various editor
bugs which I'm hoping are no longer an issue. Requests:

- Could anyone who can read whatever language 'vi' is please check a few
of the category metadata.xml files?

- Could anyone editing metadata.xml files please do a 'cvs diff' and
check that whatever you did didn't screw up any encodings? Usually you
can tell by checking that cvs diff isn't giving you any expected lines
changed on things that contain strange characters. If things do seem to
be going screwy, please let me know what you were doing that did it so
that I can figure out whether we still have broken editors / tools out
there... If you're entering utf-8 I'd hope that you'd know how to check
already :)

- If anyone is still going to throw a hissy fit and refuse to play nice
with this utf-8 thing, please let me know now so that I don't waste more
time fixing things.

There are still broken ChangeLogs and one or two h0rked ebuilds in the
tree. I'll get to those once I'm sure that I'm not wasting my time.

-- 
Ciaran McCreesh
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] python module

2005-08-04 Thread Colin Kingsley

Rene Zbinden wrote:
Yes in the meantime I found that eclass. The problem was, that there was no 
setup.py file. I created my own and put it into the files directory. 


If that works for you then I can't really see any reason why you 
shouldn't do it, but I find it far easier and cleaner to simply not use 
all the functions provided by distutils.


It should be much simpler to implement whatever you need in ebuild 
functions, instead of doing them in setup.py and then calling that from 
the ebuild.


I'm sure many python module ebuilds could show examples of this, but the
only one I can direct you to for certain is dev-python/visual-3.2.1.


--Colin
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: where goes Gentoo?

2005-08-04 Thread Brian D. Harring
On Thu, Aug 04, 2005 at 05:31:43PM -0400, Chris Gianelloni wrote:
 The only things I could see being needed out of portage itself is the
 ability to control emerge commands remotely, such as forcing an update
 of apache to $version to resolve a vulnerability.

The requirements of portage, or whatever component supplies 
(essentially) pkg management of remote boxes is going to be a bit more 
complex then just pushing emerge commands out; aside from config data, 
it'll probably centralize the vdb type contents somewhere, let alone 
avoiding N copies of the ebuild tree on each server.

Basically, whatever daemon is running clientside for all of this will 
have to support a good bit of handing off commands to portage, hence 
the interest (since from my point of view, it's a starting point).


 Some things I could see as needed:
 
 1. applying updates on any file that is under CONFIG_PROTECT where the
 md5/file-size matches that in /var/db for the file without user
 interactio

That would have to be determined prior to starting the update push.
I'd think basically a CONFIG_PROTECT limited scan of boxes to be 
updated, verifying things are in order according to the vdb (whether 
remote or local to that box) probably would fly.


 2. automatic removal of files under CONFIG_PROTECT where the
 md5/file-size matches that in /var/db during unmerge

current vdb implementation relies on md5/file-size, future should rely 
on refcount, and be a good bit more configurable.


  It's not an overnight thing, glep19 (stable portage tree) addresses a 
  chunk of concerns when/if it's implemented, but I'm a bit more 
  interested in the the other tools people desire alongside.
Offhand, responding to my own snippet, I'd love to know what's going 
on with glep19...

 
 As am I.  The Installer is one such project.  We do not have any project
 that I am aware of that is designed to resolve the problem of remotely
 managing a server.  There is nothing for pushing config changes/package
 updates/new packages.  There would need to be some interface for doing
 these things.  Stop by any trade show, such as LWE, and you'll see guys
 pushing their wares on remotely managing Linux.  We should provide
 something like this ourselves.
 
 eg. If I want to change the subnet mask or default router on 50 machines
 on my network, I should be able to do so via a simple interface and have
 the work done automatically.

Approach I've been thinking about (that fits semi-neatly exempting 
collision-protect) is essentially config pkgs, binding them on the fly 
to pkgs being pushed out.  Essentially, base apache pkg (that out of 
an ebuild tree), with it's depend tweaked automatically to pull in a 
matching configuration pkg.

Pushing out config updates wouldn't be too hard if handled in this 
manner, although generation of the config pkgs themselves would be a 
bit tricky.


  Re: a drop-in solution, considering that gentoo is effectively all 
  over the map (seriously, look at the tree), define the profile for the 
  drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc.
 
 I meant a drop-in management solution, not a specific set of server
 profiles, though those could be created with the Installer.  In fact, I
 see the Installer as one of the first pieces of the framework necessary
 for deployment and management of a large number of servers.  Once the
 netfe interface is completed with the Installer, you will be able to PXE
 boot your server and have it load a specific installer profile, and it
 will install Gentoo to those specifications.  Beyond that, we lose
 control of the server and must manually perform all other actions.
Niete.

  Specifics...
  
  Hell, I have yet to see what I would define as a proper solution for 
  config manamagent for N gentoo boxes.  NFS solution possibly, but that 
  seems a bit hackish to me.
 
 There isn't a proper solution yet.  Honestly, something like a
 repository holding configuration information with revision control would
 probably be best, so you can revert changes.  There are quite a few
 systems like this out for Red Hat and others, but nothing that is
 Gentoo-specific, or even Gentoo-capable, as far as I know.  We should
 beat people to the punch and design one ourselves.
 
 The main things we need to provide are:
 
 Provisioning - building a server from bare metal to some pre-determined
 state
Installer...

 Management - being able to make changes to existing servers without
 manually logging into each to make the changes
Domain class should provide for it
 Updates - this somewhat goes with management, but a facility for
 disseminating patches or updated packages to servers
Same as above


 Our tools.  Currently, we have very few Gentoo tools used for managing
 a system.  We would need to define the requirements for these tools, and
 then work on ways of getting them built.  It's like I said, I think the
 primary weakness in Gentoo's enterprise adoption is the need for each
 company to 

Re: [gentoo-dev] utf-8 fixes for metadata.xml

2005-08-04 Thread Georgi Georgiev
maillog: 04/08/2005-19:15:15(-0700): Robin H. Johnson types
 On Fri, Aug 05, 2005 at 01:13:31AM +0100, Ciaran McCreesh wrote:
  I've just gone through and fixed all of the broken utf-8 in metadata.xml
  files. I think... There was rather a lot of it due to various editor
  bugs which I'm hoping are no longer an issue. Requests:
  
  - Could anyone who can read whatever language 'vi' is please check a few
  of the category metadata.xml files?
 vim-6.3.084 still breaks them, unless you set encoding=utf-8 in your vim
 settings. It's the same bug I spoke to you about earlier today.
 
 Open the metadata.xml (see no '[converted]' text).
 Save metadata.xml (see the '[converted]' text).
 File is now broken.
 
 As a vim workaround, maybe force encoding=utf-8 in the gentoo filetype
 stuff?

But utf-8 is supposed to be autodetected, since the default
fileencodings always contains utf-8, doesn't it? It is not
autodetected only if the file is not *strictly* utf-8.

-- 
()   Georgi Georgiev   () C-3PO: We're doomed! ()
()[EMAIL PROTECTED]()  ()
()  +81(90)2877-8845   ()  ()


pgpryKdiwJjwF.pgp
Description: PGP signature


Re: [gentoo-dev] utf-8 fixes for metadata.xml

2005-08-04 Thread Robin H. Johnson
On Fri, Aug 05, 2005 at 11:28:46AM +0900, Georgi Georgiev wrote:
  As a vim workaround, maybe force encoding=utf-8 in the gentoo filetype
  stuff?
 But utf-8 is supposed to be autodetected, since the default
 fileencodings always contains utf-8, doesn't it? It is not
 autodetected only if the file is not *strictly* utf-8.
It sets 'fileencoding' correctly, but 'encoding' is not set at all.

Here's the vim settings that I see after opening the file and running :set.

  autoindent  hlsearchtabstop=4   ttymouse=xterm
  backspace=2 ruler   textwidth=80viminfo='20,500
  history=50  shiftwidth=4ttyfast
  commentstring=!--%s--
  fileencoding=utf-8
  fileencodings=ucs-bom,utf-8,default
  filetype=gentoo-metadata
  suffixes=.bak,~,.o,.h,.info,.swp,.obj,.info,.aux,.log,.dvi,.bbl,.out
  syntax=gentoo-metadata

-- 
Robin Hugh Johnson
E-Mail : [EMAIL PROTECTED]
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#   : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgp77CL7le3Iz.pgp
Description: PGP signature


[gentoo-dev] digest + manifest = new file format

2005-08-04 Thread Alec Warner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is basically a resubmission of Genone's file format merger [1].

The code to handle digests and manifests is currently being designed and
rewritten.  As such we need two things from the developer community.
One is a decision of what the new format will entail.  Two is a firm
agreement on the migration plan.

1.  The file format is specified in Genone's original mail, but I'll go
over it again to save you the extra linkage ;)

Inside of the digest-manifest we have:
EBUILD Filename SIZE 1234567 MD5 A4FD085FF SHA-256 A7439FDB1
type filename size-tag size hash-tag value hash-tag
value
Where type is the type of file (DIGEST, SRC_URI, EBUILD, PATCH, etc)

*Note, that the size-tag was added to make the human parsing easier.

2.  If you didn't notice by now, this format breaks versions of portage
that don't support it ( ie 2.0.X ).  This leads us to a few options as
users migrate to a version of portage that supports the new file format.

A.  Write some code into the final stable version to do both kind of
formats and/or use the new format style but fall back to the old style (
since at release time the new style format probably won't be in the tree
yet ).  Either way, the last release of 2.0.X should work with the new
file format in enough of a fashion to not break.  This means that when
the old manifest + digests are combined in the tree, most users should
be ok even if they aren't upgraded to 2.1.X.

B.  Have a migration time where both formats are in the tree.  For a
while the tree will be larger, and many people will have issues with
this.  However, old portage will use the old files, and new releases
will use the new files.  Then after a period of however long ( 6 months?
) announce loudly beforehand that portage-2.0.X will no longer be
supported and pull the old digests/manifests out of the tree.

C.  The Carpaski way ;)[2]  Add support for the new format in 2.1,
while also adding support for current format.  Force everyone to upgrade
to 2.1.X, while announcing that 2.0.X will not work in the future.  When
we have confidence that most users are upgraded, pull the old format and
add the new format to the tree.

Problems with all of these include the same problems as the cascaded
profiles, some goofball doesn't upgrade for a year, syncs with new
digests...how does he get his portage upgraded?  An upgrade path should
be provided and documented in this case.

The best route is probably some combination of the above.  Pre-emptively
add support for the new format to stable, while announcing the death of
the old format after 2.1's release.  When most users upgrade normally to
the latest 2.0.X series ( perhaps fearing the changes of 2.1.X ) they
will gain support for the new file format (or if not support, merely a
working portage instead of broken).  We should catch the majority of
users who upgrade with either the last 2.0.X release or the new release
of 2.1.X.

Suggestions, criticisms, etc... welcome.

[1] http://marc.theaimsgroup.com/?l=gentoo-devm=109725383228494w=2
[2] http://marc.theaimsgroup.com/?l=gentoo-devm=109725779909405w=2
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQvLQuGzglR5RwbyYAQLykg//TbNRfPlUutmLIn09IzQ5nX1XR1RZNUVo
e4dgiOWbJz+dBbc4jU8NxrMlSp7tv1rMhSaHw+oqhtPFZGCBbTXIFEZkBgvq9H2L
AYO62Oht8xgfYgIl/KIJgWTJTmlbC2mLRMhceD83pfJKDhp6px435g+7oUyK/sPz
rxcDHn95veT+4WdkrwrGK8rGbAsWQ9NivyUySzfPyZN83/mc50XLd7x2cyHHKmkx
wwPORG8wdhWYFeLD16SZPyBmiVW1MkA1LIK95fDRV3j9wA2mqftZlSMR0lO76fJr
tgbrKewJKVvms4+MbFJwRJGL9R6mg4VstjFeNw6smZtTSUgXtGV6qJX4S3Zj+YQJ
37gpl/zCVVvmGEa8uN0gGRDnVHEyeAAHeZbeniukc6m3fn/6JvXeDqPRFGTwWorS
B4G2DyaoJCg0Sia5lwAYBqgnikKXOZ4Q3eD0fMP1kCwBZdTUG2CTV1hNvF6FfV/e
+V26rqI2R/rXmPnXmnipM1XsajT2GLnhqY1L7OUZfWF52QuqJI4sta7VybQ4lBny
cSFEmjJM+nHoCnTW90iYWhEcwNC7/F20LZEsin/uim0/rHhqhuLPyTZ6hkg3CauW
BeLfRfGC4NY00M/xamkVzPlnoMsIZzsX9W7WkpBgwgB4lljwzUmQ6CXPiQsu8tLC
SYKtXlGJhI8=
=At7Y
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] digest + manifest = new file format

2005-08-04 Thread Alec Warner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Whoopse, should have gone to gentoo-portage-dev, my bad ;)

Alec Warner wrote:
 This is basically a resubmission of Genone's file format merger [1].
 
 The code to handle digests and manifests is currently being designed and
 rewritten.  As such we need two things from the developer community.
 One is a decision of what the new format will entail.  Two is a firm
 agreement on the migration plan.
 
 1.  The file format is specified in Genone's original mail, but I'll go
 over it again to save you the extra linkage ;)
 
 Inside of the digest-manifest we have:
 EBUILD Filename SIZE 1234567 MD5 A4FD085FF SHA-256 A7439FDB1
 type filename size-tag size hash-tag value hash-tag
 value
 Where type is the type of file (DIGEST, SRC_URI, EBUILD, PATCH, etc)
 
 *Note, that the size-tag was added to make the human parsing easier.
 
 2.  If you didn't notice by now, this format breaks versions of portage
 that don't support it ( ie 2.0.X ).  This leads us to a few options as
 users migrate to a version of portage that supports the new file format.
 
   A.  Write some code into the final stable version to do both kind of
 formats and/or use the new format style but fall back to the old style (
 since at release time the new style format probably won't be in the tree
 yet ).  Either way, the last release of 2.0.X should work with the new
 file format in enough of a fashion to not break.  This means that when
 the old manifest + digests are combined in the tree, most users should
 be ok even if they aren't upgraded to 2.1.X.
 
   B.  Have a migration time where both formats are in the tree.  For a
 while the tree will be larger, and many people will have issues with
 this.  However, old portage will use the old files, and new releases
 will use the new files.  Then after a period of however long ( 6 months?
 ) announce loudly beforehand that portage-2.0.X will no longer be
 supported and pull the old digests/manifests out of the tree.
 
   C.  The Carpaski way ;)[2]  Add support for the new format in 2.1,
 while also adding support for current format.  Force everyone to upgrade
 to 2.1.X, while announcing that 2.0.X will not work in the future.  When
 we have confidence that most users are upgraded, pull the old format and
 add the new format to the tree.
 
   Problems with all of these include the same problems as the cascaded
 profiles, some goofball doesn't upgrade for a year, syncs with new
 digests...how does he get his portage upgraded?  An upgrade path should
 be provided and documented in this case.
 
 The best route is probably some combination of the above.  Pre-emptively
 add support for the new format to stable, while announcing the death of
 the old format after 2.1's release.  When most users upgrade normally to
 the latest 2.0.X series ( perhaps fearing the changes of 2.1.X ) they
 will gain support for the new file format (or if not support, merely a
 working portage instead of broken).  We should catch the majority of
 users who upgrade with either the last 2.0.X release or the new release
 of 2.1.X.
 
 Suggestions, criticisms, etc... welcome.
 
 [1] http://marc.theaimsgroup.com/?l=gentoo-devm=109725383228494w=2
 [2] http://marc.theaimsgroup.com/?l=gentoo-devm=109725779909405w=2
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQvLSLmzglR5RwbyYAQJkEQ//aQFAjvEFJ1tRq988HOEyh/XxHlsPnksm
HAQCs8iSkLY6cI9IcRniTgkLuNwLYMqElEMACSWlTWCGmL5lrG/6XDkPaXDBeNLg
jyw1h5yCauQnH8THwzuLQ4RVg3pFsmIthrJyB55V4i/DDiAY6JGfs7xwSys1Poih
rUohcrWiI/gWr2UHzrlS4xtqO4iWw5kpUBAslDk8D+RZEjn1i5GcW/3J8GBS3RUF
TFKkzBf/ruhqN50Cpbo6Q0gEnvKcgtQSrYBlIyCdw+GpGqbalPVbGPVbozApwk6d
DQvLbMgZq7G8oM8vo8IL0cThdocNfWcNDAUrPadxzA6szzxxCiu3DiCVNLRoAhOy
2JCyGfTEY3KStX39NvCCcnkGTcP6XbGw3ummPJwLlNxP6x+KwCbHj5Hats+LDO71
dxOjh8+GeOCmafO89OmSD2W2l/zAdmU6KPUYY7OfUttrmbcTZehdTksQBZqlohRg
Coz4Fe6BxMn3dQ2C3wplALwRIikLsP95UwH7MSlAIFzrEdy7XPQydPKB/kjOk4e3
r7nrM/EOoW54QbhX8ItY+y3dEDJWNKJduax7uYXbz+tMH0J74oxiVswcu/LTgXFv
RkCJ4UqED7zvyQafaL5yTk8UYknI/oeo7x9siiqSJ90J7Y6m2GrX1i8vLoiOnyTf
+2gWdQCckT8=
=TOrq
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] utf-8 fixes for metadata.xml

2005-08-04 Thread Georgi Georgiev
maillog: 04/08/2005-19:35:01(-0700): Robin H. Johnson types
 On Fri, Aug 05, 2005 at 11:28:46AM +0900, Georgi Georgiev wrote:
   As a vim workaround, maybe force encoding=utf-8 in the gentoo filetype
   stuff?
  But utf-8 is supposed to be autodetected, since the default
  fileencodings always contains utf-8, doesn't it? It is not
  autodetected only if the file is not *strictly* utf-8.
 It sets 'fileencoding' correctly, but 'encoding' is not set at all.
 
 Here's the vim settings that I see after opening the file and running :set.
 
   autoindent  hlsearchtabstop=4   ttymouse=xterm
   backspace=2 ruler   textwidth=80viminfo='20,500
   history=50  shiftwidth=4ttyfast
   commentstring=!--%s--
   fileencoding=utf-8
   fileencodings=ucs-bom,utf-8,default
   filetype=gentoo-metadata
   suffixes=.bak,~,.o,.h,.info,.swp,.obj,.info,.aux,.log,.dvi,.bbl,.out
   syntax=gentoo-metadata

What does set enc? say?

Anyway, setting enc=utf-8 when your terminal is using something else
makes the output look like shit. Furthermore, you wouldn't be able to
input any non-ascii characters anyway (or maybe you will, depending on
your locale, but they would appear as garbage on the screen). If you're
not going to go anywhere near non-ascii text it might be OK.

I guess you're better off using gvim if locale -k charmap doesn't say
UTF-8 in your term.

-- 
-*   Georgi Georgiev   -* Each honest calling, each walk of life,  -*
*-[EMAIL PROTECTED]*- has its own elite, its own aristocracy   *-
-*  +81(90)2877-8845   -* based on excellence of performance. --   -*
*- --- *- James Bryant Conant  *-


pgpPQHC1ZNRox.pgp
Description: PGP signature


[gentoo-portage-dev] Re: [gentoo-dev] digest + manifest = new file format

2005-08-04 Thread Alec Warner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Whoopse, should have gone to gentoo-portage-dev, my bad ;)

Alec Warner wrote:
 This is basically a resubmission of Genone's file format merger [1].
 
 The code to handle digests and manifests is currently being designed and
 rewritten.  As such we need two things from the developer community.
 One is a decision of what the new format will entail.  Two is a firm
 agreement on the migration plan.
 
 1.  The file format is specified in Genone's original mail, but I'll go
 over it again to save you the extra linkage ;)
 
 Inside of the digest-manifest we have:
 EBUILD Filename SIZE 1234567 MD5 A4FD085FF SHA-256 A7439FDB1
 type filename size-tag size hash-tag value hash-tag
 value
 Where type is the type of file (DIGEST, SRC_URI, EBUILD, PATCH, etc)
 
 *Note, that the size-tag was added to make the human parsing easier.
 
 2.  If you didn't notice by now, this format breaks versions of portage
 that don't support it ( ie 2.0.X ).  This leads us to a few options as
 users migrate to a version of portage that supports the new file format.
 
   A.  Write some code into the final stable version to do both kind of
 formats and/or use the new format style but fall back to the old style (
 since at release time the new style format probably won't be in the tree
 yet ).  Either way, the last release of 2.0.X should work with the new
 file format in enough of a fashion to not break.  This means that when
 the old manifest + digests are combined in the tree, most users should
 be ok even if they aren't upgraded to 2.1.X.
 
   B.  Have a migration time where both formats are in the tree.  For a
 while the tree will be larger, and many people will have issues with
 this.  However, old portage will use the old files, and new releases
 will use the new files.  Then after a period of however long ( 6 months?
 ) announce loudly beforehand that portage-2.0.X will no longer be
 supported and pull the old digests/manifests out of the tree.
 
   C.  The Carpaski way ;)[2]  Add support for the new format in 2.1,
 while also adding support for current format.  Force everyone to upgrade
 to 2.1.X, while announcing that 2.0.X will not work in the future.  When
 we have confidence that most users are upgraded, pull the old format and
 add the new format to the tree.
 
   Problems with all of these include the same problems as the cascaded
 profiles, some goofball doesn't upgrade for a year, syncs with new
 digests...how does he get his portage upgraded?  An upgrade path should
 be provided and documented in this case.
 
 The best route is probably some combination of the above.  Pre-emptively
 add support for the new format to stable, while announcing the death of
 the old format after 2.1's release.  When most users upgrade normally to
 the latest 2.0.X series ( perhaps fearing the changes of 2.1.X ) they
 will gain support for the new file format (or if not support, merely a
 working portage instead of broken).  We should catch the majority of
 users who upgrade with either the last 2.0.X release or the new release
 of 2.1.X.
 
 Suggestions, criticisms, etc... welcome.
 
 [1] http://marc.theaimsgroup.com/?l=gentoo-devm=109725383228494w=2
 [2] http://marc.theaimsgroup.com/?l=gentoo-devm=109725779909405w=2
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQvLSLmzglR5RwbyYAQJkEQ//aQFAjvEFJ1tRq988HOEyh/XxHlsPnksm
HAQCs8iSkLY6cI9IcRniTgkLuNwLYMqElEMACSWlTWCGmL5lrG/6XDkPaXDBeNLg
jyw1h5yCauQnH8THwzuLQ4RVg3pFsmIthrJyB55V4i/DDiAY6JGfs7xwSys1Poih
rUohcrWiI/gWr2UHzrlS4xtqO4iWw5kpUBAslDk8D+RZEjn1i5GcW/3J8GBS3RUF
TFKkzBf/ruhqN50Cpbo6Q0gEnvKcgtQSrYBlIyCdw+GpGqbalPVbGPVbozApwk6d
DQvLbMgZq7G8oM8vo8IL0cThdocNfWcNDAUrPadxzA6szzxxCiu3DiCVNLRoAhOy
2JCyGfTEY3KStX39NvCCcnkGTcP6XbGw3ummPJwLlNxP6x+KwCbHj5Hats+LDO71
dxOjh8+GeOCmafO89OmSD2W2l/zAdmU6KPUYY7OfUttrmbcTZehdTksQBZqlohRg
Coz4Fe6BxMn3dQ2C3wplALwRIikLsP95UwH7MSlAIFzrEdy7XPQydPKB/kjOk4e3
r7nrM/EOoW54QbhX8ItY+y3dEDJWNKJduax7uYXbz+tMH0J74oxiVswcu/LTgXFv
RkCJ4UqED7zvyQafaL5yTk8UYknI/oeo7x9siiqSJ90J7Y6m2GrX1i8vLoiOnyTf
+2gWdQCckT8=
=TOrq
-END PGP SIGNATURE-
-- 
gentoo-portage-dev@gentoo.org mailing list