Re: [gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?

2007-09-21 Thread Mike Frysinger
On Friday 21 September 2007, Duncan wrote:
 Mike Frysinger [EMAIL PROTECTED] posted
 [EMAIL PROTECTED], excerpted below, on  Thu, 20 Sep

 2007 12:34:41 -0400:
  we know that someone taking a stage3 has never configured anything
  before and so we can safely put defaults into /root/.

 Just to point out... I've seen people mention overlaying a stage-3 on an
 existing installation for recovery reasons, generally broken gcc or (on
 amd64) switching back to multilib from 64-bit only profiles, so it
 /cannot/ be rightly assumed that there's not an existing configuration
 in /root/.  (Whether that's the right way to accomplish such recovery
 isn't the point; the point is, it's done, by people desperate to get a
 working system once again who know no other way to do it.)

there's a ton of other files that'd get blown away (like everything 
in /etc) ... anyone who blindly unpacks a stage3 onto their system gets what 
they deserve in my eyes

 Chris's idea of testing both USE=build *AND* that there's no existing
 file there that's going to get blown away, sounds reasonable, regardless
 of the debate over where the code is eventually placed.

except that doesnt address the issue you raised above at all ... the files 
are going into /root/ ... how they get there is the subject of the debate
-mike


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


Re: [gentoo-dev] I've added you as a friend on StumbleUpon

2007-09-21 Thread Yuriy Rusinov
I'm sorry. I visit site and uncarefully click submit.

On 9/21/07, Seemant Kulleen [EMAIL PROTECTED] wrote:

 Can we just unsubscribe this person from this list?  This is absolutely
 ludicrous.


I'm really sorry.


-- 
Best regards,
Sincerely yours,
Yuriy Rusinov


Re: [gentoo-dev] gentoo-x86 commit in sys-cluster/csync2: ChangeLog csync2-1.34.ebuild

2007-09-21 Thread Denis Dupeyron
On 9/20/07, Bo Ørsted Andresen [EMAIL PROTECTED] wrote:
 On Thursday 20 September 2007 19:54:16 Donnie Berkholz wrote:
   econf has default econf failed die message.
   The following would be sufficient:
   econf \
   --localstatedir=/var \
   --sysconfdir=/etc/csync2
 
  Is that so ... when did that appear? Does it happen for all of the
  package managers? Which functions do this? Where is it documented?

 The currect PMS draft documents it (for econf only). All three package
 managers conform to it.

As you seem to know, PMS is still a draft and as such can't be
considered a valid reference document yet. The econf function is
indeed the only one that is officially documented as aborting
automatically via die(). You can find this in our Gentoo Development
Guide available at devmanual.gentoo.org.

In any case it is considered good practice to always add '||
die(message)' after all helper functions. The reason is you can't
(or shouldn't) rely on any of them dying properly now or in the
future. Plus adding a specific message helps debugging.

And about the existence of other package managers, yes, I've heard
that rumor too. I've even heard that they may work, but I can't
confirm.

Denis.
���^����(� ��X��X�

[gentoo-dev] Unmasking udev-115-r5

2007-09-21 Thread Matthias Schwarzott
Hi there!

If nobody objects, I will unmask udev-115-r5 (or later if needed) today or 
tomorrow. There are some rules that got removed between udev-115-r1 and newer 
version. If you miss anything please contact us. Either these need to be 
added back, or installed by other relevant packages.

One package I know that needs this is aoetools (Bug #193315).

Please, if you use or maintain any unusual hardware/driver, please test if 
there are no regressions in udev-115-r5.

One still open regression is this: As we no longer use a wrapper around 
modprobe blacklisting will not work in all cases, until module-init-tools is 
patched (Bug #192201).

Matthias

-- 
Matthias Schwarzott (zzam)
-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Re: gentoo-x86 commit in net-irc/epic4: ChangeLog epic4-2.8.ebuild

2007-09-21 Thread Torsten Veller
* Raul Porcel (armin76) [EMAIL PROTECTED]:
 armin76 07/09/20 19:10:45
 
   Modified: ChangeLog
   Added:epic4-2.8.ebuild
   Log:
   Version bump
   (Portage version: 2.1.3.9)
 
 1.1  net-irc/epic4/epic4-2.8.ebuild
 
 file : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-irc/epic4/epic4-2.8.ebuild?rev=1.1view=markup
 plain: 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-irc/epic4/epic4-2.8.ebuild?rev=1.1content-type=text/plain
 
 Index: epic4-2.8.ebuild
 ===
 # Copyright 1999-2007 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/net-irc/epic4/epic4-2.8.ebuild,v 1.1 
 2007/09/20 19:10:44 armin76 Exp $
 
 inherit flag-o-matic eutils
 
 HELP_V=20050315
 
 DESCRIPTION=Epic4 IRC Client
 HOMEPAGE=http://epicsol.org/;
 SRC_URI=ftp://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/${P}.tar.bz2
   ftp://prbh.org/pub/epic/EPIC4-PRODUCTION/epic4-help-${HELP_V}.tar.gz
   mirror://gentoo/epic4-local.bz2
 
[...]
 pkg_postinst() {
   if [ ! -f ${ROOT}/usr/share/epic/script/local ]
   then
   elog /usr/share/epic/script/local does not exist, I will now
   elog create it. If you do not like the look/feel of this file, 
 or
   elog if you'd prefer to use your own script, simply remove 
 this
   elog file.  If you want to prevent this file from being 
 installed
   elog in the future, simply create an empty file with this 
 name.
   cp ${WORKDIR}/epic4-local ${ROOT}/usr/share/epic/script/local
   ^^
This probably does not exist.
Installing a default file and testing in pkg_preinst() might be better.

src_install() {
[...]
newins ${WORKDIR}/epic4-local local.gentoodefault
[...]
}
pkg_preinst() {
if [ ! -f ${ROOT}/usr/share/epic/script/local ]  \
   [ ! -f ${D}/usr/share/epic/script/local ]
then
elog ...
cp ${D}/usr/share/epic/script/local{.gentoodefault,}
fi
}


-- 
.:  Regards Torsten   |   :.
-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?

2007-09-21 Thread Duncan
Mike Frysinger [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on  Fri, 21 Sep
2007 03:16:49 -0400:

 On Friday 21 September 2007, Duncan wrote:
 Mike Frysinger [EMAIL PROTECTED] posted
 [EMAIL PROTECTED], excerpted below, on  Thu, 20 Sep

 2007 12:34:41 -0400:
  we know that someone taking a stage3 has never configured anything
  before and so we can safely put defaults into /root/.

 Just to point out... I've seen people mention overlaying a stage-3 on
 an existing installation for recovery reasons[.]  (Whether that's the
 right way to accomplish such recovery isn't the point[.]
 
 anyone who blindly unpacks a stage3 onto their system gets what they
 deserve in my eyes

Agreed, but I was trying to stay strictly on target and not go there 
(thus the whole whether that's the right way to do it is beside the point 
thing).  I was/am just pointing out that the base assumption isn't always 
correct.  

If the policy is to be the you do it, you get to keep the pieces 
concept, great, but that's rather different than pretending it won't 
happen.

I'd still rather not see anything going into /root based on principle, 
but the only at stage-build time, and if there's something there, don't 
overwrite it is IMO a reasonable compromise.  (That's quite apart from 
the question of what package gets the privilege of dealing with it; 
I've no dog in that fight to have an opinion on.)

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

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Gentoo vmware/virtualbox/qemu images

2007-09-21 Thread Tiziano Müller
Hi there,

At the OpenExpo here in Zurich I got many requests for a vmware image of
Gentoo. What do you think of providing a live image in addition to the
minimal- and live-cd's?

Cheers,
Tiziano


-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Is anyone from infra around?

2007-09-21 Thread Георги Георгиев
maillog: 20/09/2007-13:47:17(-0700): Mike Doty types
 Georgi Georgiev wrote:
  The IP for rsync1.jp.gentoo.org changed not too long ago. I notified
  gentoo-mirrors two weeks ago, but even today, neither the DNS nor the
  ACL has been updated.
  
  Could someone poke the relevant parties and refer them to the message
  below?
  
  http://archives.gentoo.org/gentoo-mirrors/msg_01262.xml
  
 infra was aware of the change, but dropped the ball.  we've updated our DNS 
 and
 acls.  In the future, would you please either file a bug or send a email to
 [EMAIL PROTECTED] instead?  This list isn't the appropriate place.

Ah, yes, I forgot all about it but I did open a bug on 9/11.
https://bugs.gentoo.org/show_bug.cgi?id=192064

-- 
(*   Georgi Georgiev   (* Dull women have immaculate homes.  (*
*)[EMAIL PROTECTED]*)*)
(* http://www.gg3.net/ (*(*
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?

2007-09-21 Thread Chris Gianelloni
On Fri, 2007-09-21 at 04:23 +, Duncan wrote:
 Just to point out... I've seen people mention overlaying a stage-3 on an 
 existing installation for recovery reasons, generally broken gcc or (on 
 amd64) switching back to multilib from 64-bit only profiles, so it 
 /cannot/ be rightly assumed that there's not an existing configuration 
 in /root/.  (Whether that's the right way to accomplish such recovery 
 isn't the point; the point is, it's done, by people desperate to get a 
 working system once again who know no other way to do it.)

Anyone doing anything like this deserves all the suck that comes with
it.  If some file gets overwritten on their system, so be it.  It's not
our job to hand hold when people are doing things that are pretty stupid
to begin with when anyone with sense would be sure to --exclude things
they know they won't want (like /root)... ;]

 Chris's idea of testing both USE=build *AND* that there's no existing 
 file there that's going to get blown away, sounds reasonable, regardless 
 of the debate over where the code is eventually placed.

Thanks, but if the maintainers don't want to do it, there's not much we
can do about it.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation


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


Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?

2007-09-21 Thread Chris Gianelloni
On Thu, 2007-09-20 at 20:52 -0400, Mike Frysinger wrote:
 On Thursday 20 September 2007, Chris Gianelloni wrote:
  Also, my plan for this would be add the copying of the .bash* files
  from /etc/skel if and only if USE=build *and* the files do not already
  exist, done during pkg_preinst/pkg_postinst somewhere.  This will pull
  it into the stage1 tarball, making it available to everyone on all
  further stages, it keeps it from being done every time someone emerges
  bash, it doesn't stomp on existing files, and it doesn't show up in VDB
  linked to the bash package.  Is this acceptable?
 
 no, bash is not a special case
 
 why not add an `emerge --config baselayout` to the end of stage3 and i'll do 
 the /root/ default setup in the baselayout ebuild

I'd rather not do anything that isn't accomplished automatically by the
ebuild when it is being merged.  If this really is so objectionable, I'd
just assume WONTFIX the request and move on with it.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation


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


Re: [gentoo-dev] Gentoo vmware/virtualbox/qemu images

2007-09-21 Thread Chris Gianelloni
On Fri, 2007-09-21 at 19:01 +0200, Tiziano Müller wrote:
 Hi there,
 
 At the OpenExpo here in Zurich I got many requests for a vmware image of
 Gentoo. What do you think of providing a live image in addition to the
 minimal- and live-cd's?

Bug #115902

If you can answer the questions in that bug sufficiently, feel free to
revisit this.  Also, please contact the team that would likely be doing
all of the work to get this sort of thing done prior to bringing up such
a proposal, especially when there's already a bug report open for
it.  ;]

We now have a wonderful x86 Release Coordinator, which was one of the
blockers in doing a VMware image before.  Of course, there's always the
what is Gentoo question to determine what we would put in a VM.

I don't get this obsession with a live image when someone can boot the
LiveCD/LiveDVD on real hardware *or* in VMware.  They can even boot the
ISO directly and not even have to burn to disk, so people without a DVD
burner can still use the LiveDVD.  So exactly what problem are we trying
to solve with creating an image that cannot be solved with our current
media?  Where do you plan on storing such a large image?  What other
media are you planning on us removing to support it?

(By the way, I am planning on adding support for creating VMware images
to catalyst, so this will eventually be something much easier for us in
Release Engineering...)

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation


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


Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?

2007-09-21 Thread Steev Klimaszewski
On Fri, 2007-09-21 at 11:37 -0700, Chris Gianelloni wrote:

 ebuild when it is being merged.  If this really is so objectionable, I'd
 just assume WONTFIX the request and move on with it.
 

+1

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?

2007-09-21 Thread Mike Frysinger
On Friday 21 September 2007, Chris Gianelloni wrote:
 On Thu, 2007-09-20 at 20:52 -0400, Mike Frysinger wrote:
  On Thursday 20 September 2007, Chris Gianelloni wrote:
   Also, my plan for this would be add the copying of the .bash* files
   from /etc/skel if and only if USE=build *and* the files do not already
   exist, done during pkg_preinst/pkg_postinst somewhere.  This will pull
   it into the stage1 tarball, making it available to everyone on all
   further stages, it keeps it from being done every time someone emerges
   bash, it doesn't stomp on existing files, and it doesn't show up in VDB
   linked to the bash package.  Is this acceptable?
 
  no, bash is not a special case
 
  why not add an `emerge --config baselayout` to the end of stage3 and i'll
  do the /root/ default setup in the baselayout ebuild

 I'd rather not do anything that isn't accomplished automatically by the
 ebuild when it is being merged.  If this really is so objectionable, I'd
 just assume WONTFIX the request and move on with it.

as outlined already, it's objectionable in the sense that once a user has 
entered the system, nothing can be assumed in the automatic case.  by the 
user running `emerge --config baselayout`, we can assume that the behavior it 
exhibits (for example, setting up files in /root that dont exist 
from /etc/skel/) is expected.

as also explained, tying into USE=bootstrap and USE=build is not correct as 
that does not represent everything in stage3 and there is no way to detect 
the stage2-stage3 state vs a normal emerge.

the compromise is simple: catalyst runs --config at the end of stage3 for 
appropriate packages, but as to what those things actually do is left in the 
ebuilds.
-mike


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


Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?

2007-09-21 Thread Chris Gianelloni
On Fri, 2007-09-21 at 17:45 -0400, Mike Frysinger wrote:
 the compromise is simple: catalyst runs --config at the end of stage3 for 
 appropriate packages, but as to what those things actually do is left in the 
 ebuilds.

I've already stated my preference for not doing *anything* outside of
merging packages in the stages.  Were this stage3, I wouldn't care.
Anyway, I'd much rather leave everything as it is now than add the
emerge --config stuff.  You're free to add it to the ebuilds, of course,
which would satisfy the people that want it, but I would prefer not add
it to the stages, even if it is documented in the Handbook, as it isn't
required.  Basically, I'd rather we either throw it into the earlier
stages, or not do it at all.  You've given good reason on why, while
technically feasible since we're only caring about bash at this time, it
is still a bad idea as it opens us up to yet another slippery slope.  I
completely see your point, which is why I'm taking the stance that
things are best left as they are now.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation


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


Re: [gentoo-dev] Gentoo vmware/virtualbox/qemu images

2007-09-21 Thread Mike Doty

Chris Gianelloni wrote:

On Fri, 2007-09-21 at 19:01 +0200, Tiziano Müller wrote:

Hi there,

At the OpenExpo here in Zurich I got many requests for a vmware image of
Gentoo. What do you think of providing a live image in addition to the
minimal- and live-cd's?


Bug #115902

If you can answer the questions in that bug sufficiently, feel free to
revisit this.  Also, please contact the team that would likely be doing
all of the work to get this sort of thing done prior to bringing up such
a proposal, especially when there's already a bug report open for
it.  ;]

We now have a wonderful x86 Release Coordinator, which was one of the
blockers in doing a VMware image before.  Of course, there's always the
what is Gentoo question to determine what we would put in a VM.

I don't get this obsession with a live image when someone can boot the
LiveCD/LiveDVD on real hardware *or* in VMware.  They can even boot the
ISO directly and not even have to burn to disk, so people without a DVD
burner can still use the LiveDVD.  So exactly what problem are we trying
to solve with creating an image that cannot be solved with our current
media?  Where do you plan on storing such a large image?  What other
media are you planning on us removing to support it?

(By the way, I am planning on adding support for creating VMware images
to catalyst, so this will eventually be something much easier for us in
Release Engineering...)

The only advantage I see is less than technical people(read windows/osx 
users) who don't know/are afraid of ISOs and such, yet know how to 
operate vmware-player.  Were we to consider Enterprise Gentoo we'd 
certainly want to offer it to people interested in gentoo.  Think of it 
more as a marketing tool.


As for what to put on it, liveDVD is the only sane choice.  That said; 
It would be awsome if when catalyst can build vmware images, to make a 
minimal one as well, so groups(maybe xfce4, kde, ) can make their 
own demos based on that.


--
===
Mike Doty  kingtaco -at- gentoo.org
Gentoo Infrastructure
Gentoo/AMD64 Strategic Lead
GPG: E1A5 1C9C 93FE F430 C1D6  F2AF 806B A2E4 19F4 AE05
===
--
[EMAIL PROTECTED] mailing list