[gentoo-dev] Re: Gentoo vmware/virtualbox/qemu images
Mike Doty wrote: 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. This guy: http://gentoovm.blogspot.com/ works for vmware according to his first post here: http://www.vmwhere.net/category/gentoo/ (where he makes clear he has nothing to do with releng, and that his work is in no way to be seen as official.) He might be a good guy to rope in? He seems to be having trouble with hosting and hasn't released since 2006.0 so he'd most likely welcome the approach, imo. Wrt to second use case (custom ones for groups) there's nothing stopping someone doing that from a minimal iso right now afaict. (It's a lot easier if you work in a partition, and make the image at the end for deployment.) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
Chris Gianelloni wrote: 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. With respect, this is a little confusing. I didn't get past the learning curve for catalyst, but it's clearly not the same as simply merging packages, or you wouldn't need a special tool. 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. It seemed to me that a clean, *simple* solution which would work for any future packages that might also need this functionality was proposed. Why not just use it? It's only one command, and the standardisation would mean users could rely on the mechanism for system recovery. Or am I missing some deeper technical implication? -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: gentoo-x86 commit in net-irc/epic4: ChangeLog epic4-2.8.ebuild
* Torsten Veller [EMAIL PROTECTED]:
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
}
:(
I thought it might be an advantage to record the file. But it isn't.
On upgrades portage calls: pkg_preinst, pkg_postinst, pkg_prerm,
pkg_postrm. So it first merges the new version and cleans the old one
later.
So for above pkg_preinst the file exists but it will be removed later
(if it wasn't modified)
Next version: Use your old pkg_postinst but don't use WOKDIR but the
installed default file. (If you don't want to merge the default file to
ROOT you install it but move to T in pkg_preinst and to ROOT in pkg_postinst.)
Comments?
--
.: Torsten Veller | :.
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: gentoo-x86 commit in dev-db/firebird: ChangeLog metadata.xml firebird-2.0.3.12981.0-r1.ebuild firebird-2.0.1.12855.0-r4.ebuild firebird-2.0.1.12855.0-r5.ebuild
* William Thomson (wltjr) [EMAIL PROTECTED]:
wltjr 07/09/21 02:15:03
Modified: ChangeLog metadata.xml
Added:firebird-2.0.3.12981.0-r1.ebuild
Removed: firebird-2.0.1.12855.0-r4.ebuild
firebird-2.0.1.12855.0-r5.ebuild
Log:
Major changes, Firebird is no longer installed in opt :). Added paths
patch. Took over as sole maintainer since I am doing all the work anyway ;)
(Portage version: 2.1.3.9)
1.1 dev-db/firebird/firebird-2.0.3.12981.0-r1.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-db/firebird/firebird-2.0.3.12981.0-r1.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-db/firebird/firebird-2.0.3.12981.0-r1.ebuild?rev=1.1content-type=text/plain
src_unpack() {
if use doc; then
# Unpack docs
mkdir ${WORKDIR}/manuals
cd ${WORKDIR}/manuals
unpack ib_b60_doc.zip
cd ${WORKDIR}
fi
unpack ${MY_P}.tar.bz2
mkdir -p ${WORKDIR}/../etc \
^^
What is this?
${WORKDIR}/usr \
${WORKDIR}/var/log/firebird \
${WORKDIR}/var/run/firebird
cd ${WORKDIR}/usr; ln -s ${WORKDIR}/${MY_P}/gen/firebird/bin
cd ${WORKDIR}/../etc; ln -s ${WORKDIR}/${MY_P}/gen/firebird firebird
cd ${S}
pkg_postinst() {
# Hack to fix ownership/perms
chown -fR firebird:firebird /etc/firebird /usr/share/firebird
chmod 750 /etc/firebird
ROOT!=/ ?
pkg_config() {
cd /usr/share/firebird
same
--
.:Torsten | :.
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: gentoo-x86 commit in dev-db/firebird: ChangeLog metadata.xml firebird-2.0.3.12981.0-r1.ebuild firebird-2.0.1.12855.0-r4.ebuild firebird-2.0.1.12855.0-r5.ebuild
Torsten Veller wrote:
pkg_postinst() {
# Hack to fix ownership/perms
chown -fR firebird:firebird /etc/firebird /usr/share/firebird
chmod 750 /etc/firebird
ROOT!=/ ?
pkg_config() {
cd /usr/share/firebird
same
Does the above only apply to phases other than compile and install?
(I think that's where the confusion arises, or at least it did for me.)
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: gentoo-x86 commit in dev-db/firebird: ChangeLog metadata.xml firebird-2.0.3.12981.0-r1.ebuild firebird-2.0.1.12855.0-r4.ebuild firebird-2.0.1.12855.0-r5.ebuild
On Saturday 22 September 2007, Steve Long wrote:
Torsten Veller wrote:
pkg_postinst() {
# Hack to fix ownership/perms
chown -fR firebird:firebird /etc/firebird /usr/share/firebird
chmod 750 /etc/firebird
ROOT!=/ ?
pkg_config() {
cd /usr/share/firebird
same
Does the above only apply to phases other than compile and install?
(I think that's where the confusion arises, or at least it did for me.)
ROOT is always used in pkg_* functions, not /
-mike
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Last rites: app-emacs/eieio and app-emacs/semantic
# Ulrich Mueller [EMAIL PROTECTED] (22 Sep 2007) # Does not work with Emacs 22. Last upstream release as separate # packages in 2002 and 2003, respectively; eieio and semantic are now # included with app-emacs/cedet which should be used as replacement. # Masked for removal in 30 days. Bug #190768. app-emacs/eieio app-emacs/semantic Note: app-emacs/speedbar will follow once emacs-22.1 is stable. Ulrich -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Gentoo vmware/virtualbox/qemu images
On Sat, 2007-09-22 at 07:19 +0100, Steve Long wrote: This guy: http://gentoovm.blogspot.com/ works for vmware according to his first post here: http://www.vmwhere.net/category/gentoo/ (where he makes clear he has nothing to do with releng, and that his work is in no way to be seen as official.) He might be a good guy to rope in? He seems to be having trouble with hosting and hasn't released since 2006.0 so he'd most likely welcome the approach, imo. He was on the bug. Also, people seem to forget that we would also very likely have an issue with hosting, too. We do not have unlimited space on our community-donated mirrors. It has always been a constant struggle within Release Engineering to keep our sizes down. This is one of the reasons that we've not undertaken such a task. To be honest, once I get support in catalyst, it'll be much more likely that I'll end up creating these, since I'll be able to share the catalyst caches and such between LiveDVD and VM image builds, so it'll take almost no time to produce the builds. Currently, Release Engineering is quite understaffed. We have lost a few release coordinators between the last release and now. The arch teams are picking up the slack and getting people to fill the roles, but they have to be trained, which means more time spent training and less time spent working, which delays a release fairly significantly. I have no intentions on pulling in more media for us to support when we're having difficulty supporting what we have now. That's just an unfortunate fact of life. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
On Sat, 2007-09-22 at 08:01 +0100, Steve Long wrote: I've already stated my preference for not doing *anything* outside of merging packages in the stages. With respect, this is a little confusing. I didn't get past the learning curve for catalyst, but it's clearly not the same as simply merging packages, or you wouldn't need a special tool. The tool does things like setting up the chroot. The code run by catalyst to get a stage3 from a stage2, not counting things like chroot setup, is emerge -e world just like going from a stage2-stage3 by hand. Anyway, you don't really need to understand it, as I do, and vapier does. If you're really interested, learn a bit about catalyst. Uninformed opinions help no one. It seemed to me that a clean, *simple* solution which would work for any future packages that might also need this functionality was proposed. Why not just use it? It's only one command, and the standardisation would mean users could rely on the mechanism for system recovery. Uhh... what does adding emerge --config have to do with catalyst? There's nothing stopping vapier/anyone from adding the emerge --config steps to the ebuilds. I simply said that I'm not wanting to add code to run those to catalyst for the reasons I have already stated. In no way does that impact the usefulness of the config code for end users. It only affects what goes into the stages. Or am I missing some deeper technical implication? Yup. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: gentoo-x86 commit in dev-db/firebird: ChangeLog metadata.xml firebird-2.0.3.12981.0-r1.ebuild firebird-2.0.1.12855.0-r4.ebuild firebird-2.0.1.12855.0-r5.ebuild
On Sat, 2007-09-22 at 10:29 +0200, Torsten Veller wrote:
* William Thomson (wltjr) [EMAIL PROTECTED]:
mkdir -p ${WORKDIR}/../etc \
^^
What is this?
${WORKDIR}/usr \
${WORKDIR}/var/log/firebird \
${WORKDIR}/var/run/firebird
cd ${WORKDIR}/usr; ln -s ${WORKDIR}/${MY_P}/gen/firebird/bin
cd ${WORKDIR}/../etc; ln -s ${WORKDIR}/${MY_P}/gen/firebird firebird
It's symlinks so the runtime changes as to Firebirds don't prevent the
build system from completing. Since the build system and normal Firebird
installs expect everything to be under one directory. Not split into
many. Nothing gets placed there, and they only act as links.
I know it's not pretty or ideal, but didn't have to many other ways to
go about it. At least not that I am familiar with or could think of.
pkg_postinst() {
# Hack to fix ownership/perms
chown -fR firebird:firebird /etc/firebird /usr/share/firebird
chmod 750 /etc/firebird
ROOT!=/ ?
pkg_config() {
cd /usr/share/firebird
same
What should I be using instead? I see what your talking about wrt to
chroots and etc. Not even sure that's relevant or needed anymore. Was to
correct some past issues and hopefully can be removed ASAP.
The pkg_config part might remain not sure there.
--
William L. Thomson Jr.
Gentoo/Java
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Re: Re: Why isn't /root/.bash_profile in the stage tarballs?
Chris Gianelloni wrote: On Sat, 2007-09-22 at 08:01 +0100, Steve Long wrote: I've already stated my preference for not doing *anything* outside of merging packages in the stages. With respect, this is a little confusing. I didn't get past the learning curve for catalyst, but it's clearly not the same as simply merging packages, or you wouldn't need a special tool. The tool does things like setting up the chroot. The code run by catalyst to get a stage3 from a stage2, not counting things like chroot setup, is emerge -e world just like going from a stage2-stage3 by hand. Anyway, you don't really need to understand it, as I do, and vapier does. If you're really interested, learn a bit about catalyst. Uninformed opinions help no one. So I don't need to understand it do understand the argument, or I do? Thanks for conceding that it does a little bit more than merging packages, in any case. It seemed to me that a clean, *simple* solution which would work for any future packages that might also need this functionality was proposed. Why not just use it? It's only one command, and the standardisation would mean users could rely on the mechanism for system recovery. Uhh... what does adding emerge --config have to do with catalyst? There's nothing stopping vapier/anyone from adding the emerge --config steps to the ebuilds. I simply said that I'm not wanting to add code to run those to catalyst for the reasons I have already stated. In no way does that impact the usefulness of the config code for end users. It only affects what goes into the stages. Well clearly it's affected at least one user (or was it a dev; it doesn't matter does it really?) who stated it affects others. If vapier's solution of adding *one* command line to catalyst doesn't fulfil the user requirement, could you state how? Or am I missing some deeper technical implication? Yup. Great. What exactly? How does fulfilling the user requirement with vapier's solution mess up catalyst? -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/keepalived: ChangeLog keepalived-1.1.15.ebuild
On 09:12 Sat 22 Sep , Robin H. Johnson (robbat2) wrote:
robbat2 07/09/22 09:12:37
Modified: ChangeLog
Added:keepalived-1.1.15.ebuild
Log:
Version bump.
(Portage version: 2.1.3.7)
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/keepalived/keepalived-1.1.15.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/keepalived/keepalived-1.1.15.ebuild?rev=1.1content-type=text/plain
# This patch allows us to avoid needing kernel sources for the
configure phase
EPATCH_OPTS=-p1 -d${S} epatch \
${FILESDIR}/${PN}-1.1.13-do-not-need-kernel-sources.patch
cd ${S}
mkdir -p ${S}/include/net || die Failed to prepare ipvs header
directory
cp -f ${FILESDIR}/${PN}-1.1.13-linux-2.6.21-ip_vs.h \
${S}/include/net/ip_vs.h || die Failed to add ipvs header
# Ensure that keepalived can find the header that we are injecting
append-flags -I${S}/include
rm -f ${D}/etc/keepalived/samples/*.pem
rm -rf ${D}/etc/sysconfig ${D}/etc/rc.d/
Could use some quotes added in $D and $S for safety ...
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Re: Gentoo vmware/virtualbox/qemu images
Chris Gianelloni wrote: On Sat, 2007-09-22 at 07:19 +0100, Steve Long wrote: This guy: http://gentoovm.blogspot.com/ works for vmware according to his first post here: http://www.vmwhere.net/category/gentoo/ (where he makes clear he has nothing to do with releng, and that his work is in no way to be seen as official.) He might be a good guy to rope in? He seems to be having trouble with hosting and hasn't released since 2006.0 so he'd most likely welcome the approach, imo. He was on the bug. Also, people seem to forget that we would also very likely have an issue with hosting, too. We do not have unlimited space on our community-donated mirrors. Yeah I hear that a lot from gentoo devs on irc. Funny thing is, whenever I turn around and say Oh there was someone the other day asking whether they could donate CPU time and bandwidth, they suddenly lose all interest. I have no idea why. People don't feel good about donating to an email address. It has always been a constant struggle within Release Engineering to keep our sizes down. This is one of the reasons that we've not undertaken such a task. To be honest, once I get support in catalyst, it'll be much more likely that I'll end up creating these, since I'll be able to share the catalyst caches and such between LiveDVD and VM image builds, so it'll take almost no time to produce the builds. So is it the time or the hosting requirement that's the overwhelming factor? As users are clearly happy to step up and fill in the gaps (as that page and the bug show.) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Why isn't /root/.bash_profile in the stage tarballs?
Steve Long wrote:
Great. What exactly? How does fulfilling the user requirement with vapier's
solution mess up catalyst?
This is the the first time I've heard of a user requesting this change. It seems
to me that many people prefer to *not* have a .bash{rc,_profile} in /root, which
is the way it's always been. Why not just add the ability to copy these files
with 'emerge --config' to certain ebuilds, and then add a note to the handbook
telling users to run the command if they want to?
Even better, just tell the users to run 'cp -a /etc/skel/* /root/' if they
really want the stuff, and not modify any ebuilds at all?
--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Why isn't /root/.bash_profile in the stage tarballs?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
2007-09-22 21:57:43 Andrew Gaffney napisał(a):
Even better, just tell the users to run 'cp -a /etc/skel/* /root/'
Rather:
cp -a /etc/skel/{*,.[^.]*,..?*} /root
- --
Arfrever Frehtes Taifersar Arahesis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFG9Xab/axNJ4Xo/ZERAq4cAKCNrdHT3G3QrRF+LVyAXP3+QhwB4ACfZz8S
0axPBQmlUNdYHfgHD1jp+Ro=
=KW3v
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: gentoo-x86 commit in dev-db/firebird: ChangeLog metadata.xml firebird-2.0.3.12981.0-r1.ebuild firebird-2.0.1.12855.0-r4.ebuild firebird-2.0.1.12855.0-r5.ebuild
William L. Thomson Jr. wrote:
On Sat, 2007-09-22 at 10:29 +0200, Torsten Veller wrote:
pkg_postinst() {
# Hack to fix ownership/perms
chown -fR firebird:firebird /etc/firebird /usr/share/firebird
chmod 750 /etc/firebird
ROOT!=/ ?
pkg_config() {
cd /usr/share/firebird
same
What should I be using instead? I see what your talking about wrt to
chroots and etc. Not even sure that's relevant or needed anymore. Was to
correct some past issues and hopefully can be removed ASAP.
Just replace the root / with ${ROOT}. ie:
pkg_postinst() {
# Hack to fix ownership/perms
chown -fR firebird:firebird ${ROOT}etc/firebird
${ROOT}usr/share/firebird
chmod 750 ${ROOT}etc/firebird
pkg_config() {
cd ${ROOT}usr/share/firebird
--
fonts / wxWindows / gcc-porting / treecleaners
9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)
--
[EMAIL PROTECTED] mailing list
