[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.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-db/firebird/firebird-2.0.3.12981.0-r1.ebuild?rev=1.1&content-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.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/keepalived/keepalived-1.1.15.ebuild?rev=1.1&content-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
