Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Wednesday 19 September 2007, Andrew Gaffney wrote:
> John R. Graham wrote:
> > On the forums, I've seen the question, "Why isn't my .bashrc being
> > executed when I log in as root but is being executed when I log in as a
> > normal user?," asked half a dozen times on the forums. Heck, I even
> > asked it myself a few years ago. Now, two years later, from a slightly
> > more mature level of domain knowledge, I have to ask why the root cause
> > shouldn't be addressed. Why can't the simple little default
> > .bash_profile from /etc/skel be put into /root as well?
>
> When catalyst builds a stage tarball, it doesn't add any additional files.
> All files in any stage tarball are created by one of the packages contained
> within. In order to do this, a package such as baselayout would have to
> install the file.
>
> Looking at my local install, it's actually bash that creates
> /etc/skel/.bash{rc,_logout,_profile}. You can appeal to the maintainer(s)
> of the bash ebuild (should be the base-system herd) to add that
> functionality, but I really doubt you'll convince them.
the issue is hardly limited to bash ... by this argument, you propose to have
every package which could possibly install into /etc/skel/ have special case
code to also install into /root/
what catalyst should do is just before cleaning up the stage3 root and packing
it up is run `rsync -a /etc/skel/ /root/`
no, this cannot live in baselayout (the package that creates /root/), because
it cannot be run everytime a user upgrades the baselayout package. no, it
cannot be tied to USE=build (used to make stage1) or USE=bootstrap (use to
make stage2) as the only time the /etc/skel/ -> /root/ sync can sanely happen
is in the final steps of creating a stage3 ... and there is nothing to
differentiate the creation of a stage3 from a normal build, nor is there a
sane way to make sure baselayout is the very last package in the stage3 build
step
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Wednesday 19 September 2007, Mike Doty wrote: > John R. Graham wrote: > > like sys-apps/miscfiles. But where it should or shouldn't come from > > doesn't answer the fundamental question, "Shouldn't it be there, from > > *some* source?" > > Easy answer: no. Do you really want any script to automatically run > when you login as root? think of exploits and the ability to do > "/bin/echo rm -rf / >> /root/.bash_profile" coreutils will not `rm -rf /`: rm: cannot remove root directory `/' that said, anyone who has write access to /root owns the system ... whether the file exists by default is irrelevant -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Guys, I need your assistance here
Hi all, Unfortunately I have to come to gentoo-dev with this issue. It is regarding infamous packages.gentoo.org. Solar has closed the bug, I tried to reopened, but my account can't do that. I paste the comment I tried to put on the bug: > (In reply to comment #61 (from solar)) > > > This bug is CLOSED. > > No, it is OPEN because the issue has not yet been fixed (can you tell me > where is packages.gentoo.org). Infrastructure has not yet finished because > is waiting for taviso's review, and after that, packagestest.gentoo.org has > to be brought back to it's proper hostname. > > > Infra has done it's part. We now await others to do theirs. > > If you are going to go around closing bugs like this so they come out of > your your remit, have the KINDNESS of opening another bug so the issue can > be properly followed up. And if you do that, please link that bug to p.g.o > homepage. > > And there _will_ be a patch coming again I believe, to fix this very same > issue. > > THANKS a lot. > > Arturo If solar (or somebody else) has opened new bugs, I am not aware of ANY of them (I don't think many people would be, actually, do you?) Guys, where else can I go? We _ARE_ trying hard to fix packages.gentoo.org, the maintainer resigned (no wonder!), but to be honest with you, nobody can work like this. This is the bug that is linked from the homepage, and everybody is looking at it waiting for it to happen... I just kindly ask someone to reopen the bug. The issue hasn't been fixed nor tested yet. The patch that was submitted seems to be wrong, and a new one will be required. We are waiting for taviso to confirm this, robbat2 has already confirmed it, and we are trying hard to put up a mirror so I can patch, test and resubmit. It is _OUTSTANDING_. I don't understand what is behind solar's thinking, but we can't work like this (with people taking this kind of actions without consulting others.) And, I won't give up. I am very patient and packages.gentoo.org WILL come back to life one way or another. Even if it has to be rewritten. Sorry for bringing this kind of crap to gentoo-dev but I had nowhere else to go. Thanks, Arturo. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Am Donnerstag, 20. September 2007 schrieb ext Alin Năstac: > John R. Graham wrote: > > Why can't the simple little default > > .bash_profile from /etc/skel be put into /root as well? > > $HOME directories shouldn't be touched by emerge. And especially not root's $HOME. Bye... Dirk -- Dirk Heinrichs | Tel: +49 (0)162 234 3408 Configuration Manager | Fax: +49 (0)211 47068 111 Capgemini Deutschland | Mail: [EMAIL PROTECTED] Wanheimerstraße 68 | Web: http://www.capgemini.com D-40468 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: www.keyserver.net signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: dev-util/bk_client
bk_client is the BitKeeper client. It was originally added by vivo for live building of MySQL from the upstream BitKeeper repositories. The MySQL herd (basically me, since vivo left, and chtekk is away until 2008) don't support doing that in the MySQL eclass anymore, and additionally, anybody using BitKeeper should be aware of the original license debates (http://marc.info/?l=linux-kernel&m=103384262016750&w=2). As I do development on Git and other definetly VCS things, I won't touch BK at all. If somebody else wants to, they can have it, but otherwise it's going to be punted from the tree in the usual 30 days (October 20th). -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp2Djk8cEjms.pgp Description: PGP signature
Re: [gentoo-dev] Guys, I need your assistance here
Thursday, 20. September 2007, Arturo Garcia Ви написали: > Hi all, [...] You know, it would be helpfull to know at least a number of the bug you refer to ;). >Sorry for bringing this kind of crap to gentoo-dev but I had nowhere else to >go. Actually you do. This should have gone to the gentoo-project mailing list. This is what we have created it for, isn't it? If the issue is not resolved there then I believe there is a whole entity that is supposed to deal with stuff like that. Also, if there are technical aspects to that discussion then those may or should be done here. George -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Guys, I need your assistance here
On Thursday 20 Sep 2007, George Shapovalov wrote: > Thursday, 20. September 2007, Arturo Garcia Ви написали: > > Hi all, > > [...] > You know, it would be helpfull to know at least a number of the bug you > refer to ;). http://bugs.gentoo.org/show_bug.cgi?id=187971 > >Sorry for bringing this kind of crap to gentoo-dev but I had nowhere else > > to go. > > Actually you do. This should have gone to the gentoo-project mailing list. > This is what we have created it for, isn't it? If the issue is not resolved > there then I believe there is a whole entity that is supposed to deal with > stuff like that. Well, I am not in gentoo-project, but alrightie. I will subscribe there. > Also, if there are technical aspects to that discussion then those may or > should be done here. Nope, just looking for devs with access. And the bug has been reopened and reassigned, so all happy now. Arturo. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
I didn't say anything about emerge; I was talking about the Stage tarballs. I know, I know: Catalyst uses emerge. But, hasn't anyone realized that bash is _broken_ if this file doesn't exist? Quoting from the upstream-provided man page, "When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists." Is that really the intention here? To break upstream-defined behavior? - John Alin Năstac wrote: > John R. Graham wrote: > >> Why can't the simple little default >> .bash_profile from /etc/skel be put into /root as well? >> >> > > $HOME directories shouldn't be touched by emerge. This is the user's turf. > > -- [EMAIL PROTECTED] mailing list
[gentoo-dev] New eclass to support java-virtuals
I would like to commit a new java eclass within the next week.
This eclass is designed to support the functionality that Betelgeuse
outlined within a previous post.[1]
As you will be able to see, this eclass is very simple and only uses
functionality that will be provided by the java-utils-2.eclass (see the
attached patch )
Basically all the happens is that a file is created under
/usr/share/java-config-2/virtuals/
that contains (at present) 3 variables. This file is then read by our
java-config-2 application.
The eclass is currently implemented within the java-virtuals overlay for
those who are interested
https://overlays.gentoo.org/svn/proj/java/java-virtuals/
Any suggestions, improvements and of course approvals will be gladly
accepted
Go the All Blacks!!
Alistair
[1] http://thread.gmane.org/gmane.linux.gentoo.devel/48932/focus=48933
On Sun, 29 Apr 2007 17:00:09 +0200, Petteri Räty wrote:
> We want to implement virtuals for Java at some point and for that we
> need to know the package that provides the virtual because some virtuals
> can be provided by the JDK or normal packages and this affects the JDK
> selection at build time. One option is to call into Portage to find this
> out, but of course Paludis and Pkgcore people most likely don't like
> this approach. One thing that comes to mind is to allow for virtuals to
> install files so we can install the provider information in a format
> easy for us. We need the information in format ${PN}-${SLOT} because
> that's the way we install in /usr/share. So do you think it's ok for
> virtuals to install files (we can of course call the category
> java-virtual/ too), should we call Portage code, or do you have an
> another idea?
--- gentoo/cvs/gentoo-x86/eclass/java-utils-2.eclass2007-08-05
20:17:05.0 +1200
+++ gentoo/overlays/java-virtuals/eclass/java-utils-2.eclass2007-09-12
22:23:53.0 +1200
@@ -2196,6 +2286,8 @@
JAVA_PKG_SHAREPATH="${DESTTREE}/share/${JAVA_PKG_NAME}"
JAVA_PKG_SOURCESPATH="${JAVA_PKG_SHAREPATH}/sources/"
JAVA_PKG_ENV="${D}${JAVA_PKG_SHAREPATH}/package.env"
+ JAVA_PKG_VIRTUALS_PATH="${DESTTREE}/share/java-config-2/virtuals"
+
JAVA_PKG_VIRTUAL_PROVIDER="${D}/${JAVA_PKG_VIRTUALS_PATH}/${JAVA_PKG_NAME}"
[[ -z "${JAVA_PKG_JARDEST}" ]] &&
JAVA_PKG_JARDEST="${JAVA_PKG_SHAREPATH}/lib"
[[ -z "${JAVA_PKG_LIBDEST}" ]] &&
JAVA_PKG_LIBDEST="${DESTTREE}/$(get_libdir)/${JAVA_PKG_NAME}"
@@ -2220,58 +2312,71 @@
java-pkg_do_write_() {
debug-print-function ${FUNCNAME} $*
java-pkg_init_paths_
- # Create directory for package.env
- dodir "${JAVA_PKG_SHAREPATH}"
- if [[ -n "${JAVA_PKG_CLASSPATH}" || -n "${JAVA_PKG_LIBRARY}" || -f \
- "${JAVA_PKG_DEPEND_FILE}" || -f \
- "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]]; then
- # Create package.env
- (
- echo "DESCRIPTION=\"${DESCRIPTION}\""
- echo "GENERATION=\"2\""
-
- [[ -n "${JAVA_PKG_CLASSPATH}" ]] && echo
"CLASSPATH=\"${JAVA_PKG_CLASSPATH}\""
- [[ -n "${JAVA_PKG_LIBRARY}" ]] && echo
"LIBRARY_PATH=\"${JAVA_PKG_LIBRARY}\""
- [[ -n "${JAVA_PROVIDE}" ]] && echo
"PROVIDES=\"${JAVA_PROVIDE}\""
- [[ -f "${JAVA_PKG_DEPEND_FILE}" ]] \
- && echo "DEPEND=\"$(cat
"${JAVA_PKG_DEPEND_FILE}" | uniq | tr '\n' ':')\""
- [[ -f "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]] \
- && echo "OPTIONAL_DEPEND=\"$(cat
"${JAVA_PKG_OPTIONAL_DEPEND_FILE}" | uniq | tr '\n' ':')\""
- echo "VM=\"$(echo ${RDEPEND} ${DEPEND} | sed -e 's/
/\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\"" # TODO cleanup !
- ) > "${JAVA_PKG_ENV}"
-
- # register target/source
- local target="$(java-pkg_get-target)"
- local source="$(java-pkg_get-source)"
- [[ -n ${target} ]] && echo "TARGET=\"${target}\"" >>
"${JAVA_PKG_ENV}"
- [[ -n ${source} ]] && echo "SOURCE=\"${source}\"" >>
"${JAVA_PKG_ENV}"
-
- # register javadoc info
- [[ -n ${JAVADOC_PATH} ]] && echo
"JAVADOC_PATH=\"${JAVADOC_PATH}\"" \
- >> ${JAVA_PKG_ENV}
- # register source archives
- [[ -n ${JAVA_SOURCES} ]] && echo
"JAVA_SOURCES=\"${JAVA_SOURCES}\"" \
- >> ${JAVA_PKG_ENV}
-
-
- echo "MERGE_VM=\"${GENTOO_VM}\"" >> "${JAVA_PKG_ENV}"
- [[ -n ${GENTOO_COMPILER} ]] && echo
"MERGE_COMPILER=\"${GENTOO_COMPILER}\"" >> "${JAVA_PKG_ENV}"
-
- # extra env variables
- if [[ -n "${JAVA_PKG_EXTRA_ENV_VARS}" ]]; then
- cat "${JAVA_PKG_EXTRA_ENV}" >> "${JAVA_PKG_ENV}" || die
- # nested echo to remove leadin
[gentoo-dev] Re: [gentoo-java] New eclass to support java-virtuals
Alistair Bush kirjoitti:
> I would like to commit a new java eclass within the next week.
>
> This eclass is designed to support the functionality that Betelgeuse
> outlined within a previous post.[1]
>
> As you will be able to see, this eclass is very simple and only uses
> functionality that will be provided by the java-utils-2.eclass (see the
> attached patch )
>
> Basically all the happens is that a file is created under
> /usr/share/java-config-2/virtuals/
> that contains (at present) 3 variables. This file is then read by our
> java-config-2 application.
>
>
> The eclass is currently implemented within the java-virtuals overlay for
> those who are interested
>
> https://overlays.gentoo.org/svn/proj/java/java-virtuals/
>
>
> Any suggestions, improvements and of course approvals will be gladly
> accepted
>
> Go the All Blacks!!
>
> Alistair
>
https://overlays.gentoo.org/svn/proj/java/java-virtuals/java-virtuals/javamail/javamail-1.0.ebuild
Is the JAVA_VIRTUAL variable there some old leftover? I don't see it
used anywhere and it's quite useless as you could use hasq
java-virtuals-2 ${INHERIT} any way.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
John R. Graham wrote: I didn't say anything about emerge; I was talking about the Stage tarballs. I know, I know: Catalyst uses emerge. But, hasn't anyone realized that bash is _broken_ if this file doesn't exist? Quoting from the upstream-provided man page, "When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists." Is that really the intention here? To break upstream-defined behavior? First, please don't top-post. Second, you have an odd definition of "broken". You seem to have complete glossed over the last part of the sentence that you pasted: "if that file exists". Bash will *not* freak out and rape your dog if the file doesn't exist. All it means is that you get nothing more in your env than what's defined by /etc/profile. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John R. Graham wrote: > But, hasn't anyone realized that bash is _broken_ if this file doesn't > exist? Quoting from the upstream-provided man page, "When an > interactive shell that is not a login shell is started, bash reads and > executes commands from ~/.bashrc, if that file exists." Is that really > the intention here? To break upstream-defined behavior? John, From the section you quoted there, there's absolutely no indication that a .bashrc file *must* exist, in fact, they even explicitly add the "if that file exists" to show acceptance of the fact that it might not... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFG8l6bu7rWomwgFXoRAvPwAJ9VFFL6rfLrIgtJw2h7F/WfK9ohwgCdEarz AtyrRbnXan5cAlCsOL1LL7I= =k/u0 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-java] New eclass to support java-virtuals
Petteri Räty wrote:
> Alistair Bush kirjoitti:
>> I would like to commit a new java eclass within the next week.
>>
>> This eclass is designed to support the functionality that Betelgeuse
>> outlined within a previous post.[1]
>>
>> As you will be able to see, this eclass is very simple and only uses
>> functionality that will be provided by the java-utils-2.eclass (see the
>> attached patch )
>>
>> Basically all the happens is that a file is created under
>> /usr/share/java-config-2/virtuals/
>> that contains (at present) 3 variables. This file is then read by our
>> java-config-2 application.
>>
>>
>> The eclass is currently implemented within the java-virtuals overlay for
>> those who are interested
>>
>> https://overlays.gentoo.org/svn/proj/java/java-virtuals/
>>
>>
>> Any suggestions, improvements and of course approvals will be gladly
>> accepted
>>
>> Go the All Blacks!!
>>
>> Alistair
>>
>
> https://overlays.gentoo.org/svn/proj/java/java-virtuals/java-virtuals/javamail/javamail-1.0.ebuild
>
> Is the JAVA_VIRTUAL variable there some old leftover? I don't see it
> used anywhere and it's quite useless as you could use hasq
> java-virtuals-2 ${INHERIT} any way.
>
> Regards,
> Petteri
>
Yes that is a old variable. Please ignore it.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Guys, I need your assistance here
Dnia 20-09-2007, czw o godzinie 13:15 +0200, Arturo Garcia napisał(a): > On Thursday 20 Sep 2007, George Shapovalov wrote: > > Thursday, 20. September 2007, Arturo Garcia Ви написали: > > > Hi all, > > > > [...] > > You know, it would be helpfull to know at least a number of the bug you > > refer to ;). > http://bugs.gentoo.org/show_bug.cgi?id=187971 > > > >Sorry for bringing this kind of crap to gentoo-dev but I had nowhere else > > > to go. > > > > Actually you do. This should have gone to the gentoo-project mailing list. > > This is what we have created it for, isn't it? If the issue is not resolved > > there then I believe there is a whole entity that is supposed to deal with > > stuff like that. > Well, I am not in gentoo-project, but alrightie. I will subscribe there. > > > > Also, if there are technical aspects to that discussion then those may or > > should be done here. > Nope, just looking for devs with access. And the bug has been reopened and > reassigned, so all happy now. > > Arturo. Bug number? I'm curious, because i'm working with jokey to make p.g.o up. Cheers -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Mike, I agree. But, the file that _must_ exist isn't "~/.bashrc" but "~/.bash_profile". That's where the that particular bit of man-page-defined behavior is implemented. If "~/.bash_profile" doesn't exist, then "~/.bashrc" won't be sourced whether it exists or not. - John -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Andrew. Sorry 'bout the top posting; won't do it again. For the rest, please see my reply to Mike Auty on the same topic. - John -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
"John R. Graham" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Thu, 20 Sep 2007 07:18:46 -0400: > But, hasn't anyone realized that bash is _broken_ if this file doesn't > exist? Quoting from the upstream-provided man page, "When an > interactive shell that is not a login shell is started, bash reads and > executes commands from ~/.bashrc, if that file exists." Is that really > the intention here? To break upstream-defined behavior? ... "if that file exists." IOW, it doesn't /have/ to exist, and for root, many prefer it /not/ exist. But in any case, as mentioned by others already, (human user) home dirs shouldn't be touched by ebuilds (or stages), and /root is exactly that, a (human user) home dir. Home dirs are the domain of the local users and (particularly for /root) sysadmins, not distribution packages (or stages). If the sysadmin wants a /root/.bashrc, it's naturally his privilege and responsibility to create and maintain it according to his needs/preferences. -- 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
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John R. Graham wrote:
> Mike, I agree. But, the file that _must_ exist isn't "~/.bashrc" but
> "~/.bash_profile". That's where the that particular bit of
> man-page-defined behavior is implemented. If "~/.bash_profile" doesn't
> exist, then "~/.bashrc" won't be sourced whether it exists or not.
Well, bash can't install a .bash_profile file into every user's home
directory for obvious reasons. That means they shouldn't rely on the
existence of one to source .bashrc, otherwise they could never guarantee
that functionality...
It appears as though you're looking for a location that is guaranteed to
be installed by bash and always executed when there's a non-login shell
start, from where you can source ${HOME}/.bashrc. I'm not familiar
enough with bash or Gentoo's setup of bash to comment on this I'm afraid
(possibly /etc/bash/bashrc?), but relying on .bash_profile so that you
can or can't source ${HOME}/.bashrc seems a little odd.
Moreover, however ${HOME}/.bashrc got into ${HOME}, presumably
.bash_profile could be put there at the same time if it doesn't already
exist?
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFG8mcFu7rWomwgFXoRAnIIAKCUC1ShfOYvKKt5SN4oGV1uYz8HkACfVkVU
72TtoVvFFI/RXR4WGy5ya4o=
=dxNr
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Wed, 2007-09-19 at 21:57 -0400, John R. Graham wrote: > Why can't the simple little default > .bash_profile from /etc/skel be put into /root as well /etc/skel is for users created by the add user commands. root is inherently added *before* bash is installed, thus doesn't get anything from skel. Also, don't assume that the root user uses the bash shell. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thu, 20 Sep 2007 08:09:08 -0400 "John R. Graham" <[EMAIL PROTECTED]> wrote: > Mike, I agree. But, the file that _must_ exist isn't "~/.bashrc" but > "~/.bash_profile". That's wrong. Quote: "When bash is invoked as an interactive login shell, or as a non-inter- active shell with the --login option, it first reads and executes com- mands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior." Notice "the first one that exists and is readable". > If "~/.bash_profile" doesn't exist, then "~/.bashrc" won't be sourced > whether it exists or not. Wrong again. Two paragraphs down in the man page: "When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists." In this case ~/.bashrc is sourced directly. Cheers, Renat -- Probleme kann man niemals mit derselben Denkweise loesen, durch die sie entstanden sind. (Einstein) signature.asc Description: PGP signature
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
You could add '[ -n "${BASH}" -a -f ~/.bashrc ] && . ~/.bashrc' to
/etc/profile.d/bash.sh. This file could be installed by app-shells/bash.
- --
Arfrever Frehtes Taifersar Arahesis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFG8mo1/axNJ4Xo/ZERAlTaAJ9KBBMZ5iC54va2Ajco/ezyRVipXwCgkneB
IGDioZ83MCaASlWxO9JdnnI=
=psDE
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] lastriting media-sound/{pd,supercollider}
# Samuli Suominen <[EMAIL PROTECTED]> ((20 Sep 2007) # These packages don't meet needed quality standards, # and maintaining ebuilds based on current building # system and release timing is not possible. # For pd, use pd-overlay found in layman global list. # For supercollider, use upstream subversion. # Removed from tree in 30 days. media-sound/pd media-sound/supercollider pd has dozens of build related files all messed up in their tarball, not to mention installation locations (documents to /usr/lib) and if moved elsewhere the package breaks. supercollider needs a 10MB subversion snapshot which needs to be patched (their SConstruct is insane wrt arch handling). sound is not intrested in maintaining these packages anymore, unless you want to pick them up, do the work to sanizite them, and get upstream to apply it.. they will be gone. -drac -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/elogviewer: ChangeLog elogviewer-0.5.2.ebuild
On Thursday 20 September 2007, Christian Faulhammer (opfer) wrote:
> Index: elogviewer-0.5.2.ebuild
> src_install() {
> dobin "${WORKDIR}"/elogviewer
> dodoc "${WORKDIR}"/CHANGELOG
> doman "${WORKDIR}"/elogviewer.1
> make_desktop_entry elogviewer Elogviewer "" "System" ||
> die "Couldn't make desktop entry"
> }
missing "|| die" on at least the dobin
-mike
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Last rites: app-emacs/junkbust
Hallo, # Christian Faulhammer <[EMAIL PROTECTED]> (20 Sep 2007) # Is dead upstream # Junkbuster has been replaced by Privoxy, so no need for that mode app-emacs/junkbust -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Guys, I need your assistance here
Arturo Garcia wrote: And, I won't give up. I am very patient and packages.gentoo.org WILL come back to life one way or another. Even if it has to be rewritten. Personally, I don't see the problem of someone else picking up the pieces, rewriting it, and going to town with it. The source code is in CVS on sources.gentoo.org. I've toyed with the idea of taking GPNL[1] and making a p.g.o clone, but I'm not all that interested. If someone wants the source code to my webpages as well, I'm willing to cough it up, though duplicating the backend has been available[2] for a good long while. Anyway, as rude as this sounds, no devs have any responsibility to provide any functionality just because another dev used to. What that really means is, we're all too busy and nobody's interested in doing it. Most OSS projects are a one-man force anyway. Steve p.s. I miss it too. 1. http://spaceparanoids.org/gentoo/gpnl/ 2. http://spaceparanoids.org/svn/?root=gpnl -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thu, 2007-09-20 at 03:03 -0400, Mike Frysinger wrote: > what catalyst should do is just before cleaning up the stage3 root and > packing > it up is run `rsync -a /etc/skel/ /root/` It definitely should not. One of my primary motivations with catalyst is to ensure that the users get *exactly* what would be provided by the profiles/packages. We don't add extra files into the stages and likely never will. Doing something like this in catalyst would create an inconsistency between doing a stage3 install and any previous stage installs. Yes, we don't support stage1 anymore, but we still support stage1 users once their systems are up and running. Having them inconsistent only causes one more area where we have to do extra troubleshooting to determine the cause. > no, this cannot live in baselayout (the package that creates /root/), because > it cannot be run everytime a user upgrades the baselayout package. no, it > cannot be tied to USE=build (used to make stage1) or USE=bootstrap (use to > make stage2) as the only time the /etc/skel/ -> /root/ sync can sanely happen > is in the final steps of creating a stage3 ... and there is nothing to > differentiate the creation of a stage3 from a normal build, nor is there a > sane way to make sure baselayout is the very last package in the stage3 build > step Well, it depends on whether we're interested in getting all of /etc/skel or just the .bash* files. About the only thing I would see useful as "defaults" is the .bash* stuff and a .ssh directory. I do agree that everything else should be left up to the user. If we decided what to include and limited it, it shouldn't be a problem to do it via USE=build at all. Of course, that doesn't answer the question, "Do we want to?" I have no clue. -- 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?
On Thu, 2007-09-20 at 13:29 +0100, Roy Marples wrote: > Also, don't assume that the root user uses the bash shell. The root user does *default* to the bash shell on Linux, at least. Of course, we could do whatever is appropriate for other targets. -- 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?
On Thursday 20 September 2007, Chris Gianelloni wrote: > On Thu, 2007-09-20 at 03:03 -0400, Mike Frysinger wrote: > > what catalyst should do is just before cleaning up the stage3 root and > > packing it up is run `rsync -a /etc/skel/ /root/` > > It definitely should not. One of my primary motivations with catalyst > is to ensure that the users get *exactly* what would be provided by the > profiles/packages. We don't add extra files into the stages and likely > never will. Doing something like this in catalyst would create an > inconsistency between doing a stage3 install and any previous stage > installs. Yes, we don't support stage1 anymore, but we still support > stage1 users once their systems are up and running. Having them > inconsistent only causes one more area where we have to do extra > troubleshooting to determine the cause. not really ... someone installing by hand and someone taking a default setup are different things. we know that someone taking a stage3 has never configured anything before and so we can safely put defaults into /root/. we have no idea what people have done when they run emerge themselves. that is why only putting this into catalyst makes sense. > > no, this cannot live in baselayout (the package that creates /root/), > > because it cannot be run everytime a user upgrades the baselayout > > package. no, it cannot be tied to USE=build (used to make stage1) or > > USE=bootstrap (use to make stage2) as the only time the /etc/skel/ -> > > /root/ sync can sanely happen is in the final steps of creating a stage3 > > ... and there is nothing to differentiate the creation of a stage3 from a > > normal build, nor is there a sane way to make sure baselayout is the very > > last package in the stage3 build step > > Well, it depends on whether we're interested in getting all of /etc/skel > or just the .bash* files. About the only thing I would see useful as > "defaults" is the .bash* stuff and a .ssh directory. I do agree that > everything else should be left up to the user. If we decided what to > include and limited it, it shouldn't be a problem to do it via USE=build > at all. anything that is part of the system /etc/skel/ makes sense (iow, anything that is in /etc/skel/ at the end of stage3). the files from bash and the .ssh dir are the only things that go into /etc/skel/ right now for the default system. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
Chris Gianelloni <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Thu, 20 Sep 2007 09:19:31 -0700: > While I would normally agree, there's nothing wrong with having sensible > defaults. After all, we install a bunch of stuff into /home/$user > thanks to /etc/skel, so how is this different? The big distinction (other than the privilege one) IMO is that putting things into /etc/skel isn't directly inserting them into a "live" user's home dir. There's a level of indirection, such that "live" users don't have their "live" environments interfered with, and such that there's a chance for the admin to review things if desired, before actually acting on anything in skel in terms of setting up a new user. IOW, a direct comparison would be if we setup something like /etc/rootskel/. Of course, that's not quite a correct parallel either, since it's not often that a new "root" user appears =8^P, but the point I'm trying to make by drawing the parallel should be obvious. Matter of fact, I'd rather /etc/profile was handled a bit more indirectly as well, say treating it much like /etc/make.conf, creating make.conf.example if the file already existed, or like the /usr/share/ baselayout/* files, as I handle the system profile rather differently here too, but that's a somewhat different argument as it's existing behavior (to some extent addressed with etc-update, but one could say so was fstab). At least we can avoid creating further problems of the sort we're avoiding with the above *.example and baselayout/* cases, however, as the current proposal would IMO do. -- 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] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/drbd: ChangeLog drbd-8.0.6.ebuild
On 08:35 Thu 20 Sep , Christian Zoffoli (xmerlin) wrote:
> xmerlin 07/09/20 08:35:22
>
> Modified: ChangeLog
> Added:drbd-8.0.6.ebuild
> Log:
> Version Bump.
> (Portage version: 2.1.2.2)
> 1.1 sys-cluster/drbd/drbd-8.0.6.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/drbd/drbd-8.0.6.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/drbd/drbd-8.0.6.ebuild?rev=1.1&content-type=text/plain
> pkg_setup() {
> linux-mod_pkg_setup
> }
You're just doing the default here.
> cd ${S}
> cp -R /usr/src/linux-${KV} ${WORKDIR}
> emake -j1 KDIR=/${WORKDIR}/linux-${KV} O=${KBUILD_OUTPUT} ||
> die "compile problem"
> src_install() {
> emake PREFIX=${D} install || die "install problem"
> rm -f ${D}/etc/drbd.conf
Might want to quote S, WORKDIR and D, to allow for spaces.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/csync2: ChangeLog csync2-1.34.ebuild
On 08:49 Thu 20 Sep , Christian Zoffoli (xmerlin) wrote:
> xmerlin 07/09/20 08:49:25
>
> Modified: ChangeLog
> Added:csync2-1.34.ebuild
> Log:
> Version bump.
> (Portage version: 2.1.2.2)
> 1.1 sys-cluster/csync2/csync2-1.34.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/csync2/csync2-1.34.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/csync2/csync2-1.34.ebuild?rev=1.1&content-type=text/plain
> src_compile() {
> econf \
> --localstatedir=/var \
> --sysconfdir=/etc/csync2 \
> || die
>
> emake || die
These could really use some die() messages, so you know which one failed.
> make DESTDIR=${D} \
> localstatedir=/var \
> sysconfdir=/etc/csync2 \
> install || die "install problem"
Use emake here too...
> pkg_config() {
> einfo "Updating /etc/services"
> { grep -v ^${PN} /etc/services;
> echo "csync2 30865/tcp"
> } > /etc/services.new
> mv -f /etc/services.new /etc/services
>
> if [ ! -f /etc/${PN}/csync2_ssl_key.pem ]; then
> einfo "Creating default certificate in /etc/${PN}"
>
> openssl genrsa -out /etc/${PN}/csync2_ssl_key.pem 1024 &>
> /dev/null
>
> yes '' | \
> openssl req -new \
> -key /etc/${PN}/csync2_ssl_key.pem \
> -out /etc/${PN}/csync2_ssl_cert.csr \
> &> /dev/null
>
> openssl x509 -req -days 600 \
> -in /etc/${PN}/csync2_ssl_cert.csr \
> -signkey /etc/${PN}/csync2_ssl_key.pem \
> -out /etc/${PN}/csync2_ssl_cert.pem \
> &> /dev/null
>
> rm /etc/${PN}/csync2_ssl_cert.csr
> chmod 400 /etc/${PN}/csync2_ssl_key.pem
> /etc/${PN}/csync2_ssl_cert.pem
> fi
> }
This function doesn't respect ${ROOT}.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sci-biology/stride: stride-20011129.ebuild ChangeLog
On 14:35 Thu 20 Sep , Santiago M. Mola (coldwind) wrote:
> coldwind07/09/20 14:35:18
>
> Modified: stride-20011129.ebuild ChangeLog
> Log:
> Change sed separator to :, now it doesn't fail if CC contains a path.
> (Portage version: 2.1.3.9)
>
> Revision ChangesPath
> 1.6 sci-biology/stride/stride-20011129.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-biology/stride/stride-20011129.ebuild?rev=1.6&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-biology/stride/stride-20011129.ebuild?rev=1.6&content-type=text/plain
> diff :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-biology/stride/stride-20011129.ebuild?r1=1.5&r2=1.6
> - sed -e "/^CC/s/gcc -g/$(tc-getCC) ${CFLAGS}/" -i Makefile || \
> + sed -e "/^CC/s:gcc -g:$(tc-getCC) ${CFLAGS}:" -i Makefile || \
Here's another great opportunity to use a better sed, just like the one
a day or two ago.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] gentoo-x86 commit in sys-cluster/csync2: ChangeLog csync2-1.34.ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
2007-09-20 19:20:41 Donnie Berkholz napisał(a):
> On 08:49 Thu 20 Sep , Christian Zoffoli (xmerlin) wrote:
> > xmerlin 07/09/20 08:49:25
> >
> > Modified: ChangeLog
> > Added:csync2-1.34.ebuild
> > Log:
> > Version bump.
> > (Portage version: 2.1.2.2)
>
> > 1.1 sys-cluster/csync2/csync2-1.34.ebuild
> >
> > file :
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/csync2/csync2-1.34.ebuild?rev=1.1&view=markup
> > plain:
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/csync2/csync2-1.34.ebuild?rev=1.1&content-type=text/plain
>
> > src_compile() {
> > econf \
> > --localstatedir=/var \
> > --sysconfdir=/etc/csync2 \
> > || die
> >
> > emake || die
>
> These could really use some die() messages, so you know which one failed.
econf has default "econf failed" die message.
The following would be sufficient:
econf \
--localstatedir=/var \
--sysconfdir=/etc/csync2
- --
Arfrever Frehtes Taifersar Arahesis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFG8q6q/axNJ4Xo/ZERAkj4AJ9D2hO+CfjENmHB6fhTlP8afVvyaACgprji
ARAvSORW6ojPwlzE8f/2CFw=
=UfIJ
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thu, 2007-09-20 at 12:34 -0400, Mike Frysinger wrote: > > > what catalyst should do is just before cleaning up the stage3 root and > > > packing it up is run `rsync -a /etc/skel/ /root/` > > > > It definitely should not. One of my primary motivations with catalyst > > is to ensure that the users get *exactly* what would be provided by the > > profiles/packages. We don't add extra files into the stages and likely > > never will. Doing something like this in catalyst would create an > > inconsistency between doing a stage3 install and any previous stage > > installs. Yes, we don't support stage1 anymore, but we still support > > stage1 users once their systems are up and running. Having them > > inconsistent only causes one more area where we have to do extra > > troubleshooting to determine the cause. > > not really ... someone installing by hand and someone taking a default setup > are different things. we know that someone taking a stage3 has never > configured anything before and so we can safely put defaults into /root/. we > have no idea what people have done when they run emerge themselves. that is > why only putting this into catalyst makes sense. I'll respectfully disagree and say again that I won't add anything like this to catalyst for the reasons mentioned above. I see no reason why we cannot provide sensible defaults in stages lower than three, especially since I want to see everything in ebuild code. 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? > > Well, it depends on whether we're interested in getting all of /etc/skel > > or just the .bash* files. About the only thing I would see useful as > > "defaults" is the .bash* stuff and a .ssh directory. I do agree that > > everything else should be left up to the user. If we decided what to > > include and limited it, it shouldn't be a problem to do it via USE=build > > at all. > > anything that is part of the system /etc/skel/ makes sense (iow, anything > that > is in /etc/skel/ at the end of stage3). the files from bash and the .ssh dir > are the only things that go into /etc/skel/ right now for the default system. OK. So we now know that only bash/openssh would be really important here, and the .ssh directory really isn't much of a show-stopper, since it isn't populated. I mention this only because we don't install openssh until stage3, so there's no special USE flags in use at that time. If we limited it to bash (and tcsh, etc. for non-Linux) using USE=build, it would satisfy this request, one which I personally would like to see done, and still not have to change a single line of code in catalyst, which also respects my wishes. It doesn't stomp on user's files. All in all, it seems like a safe enough solution to me. -- 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] New eclass to support java-virtuals
On 23:20 Thu 20 Sep , Alistair Bush wrote:
> - # Create package.env
> - (
> - echo "DESCRIPTION=\"${DESCRIPTION}\""
> - echo "GENERATION=\"2\""
> -
> - [[ -n "${JAVA_PKG_CLASSPATH}" ]] && echo
> "CLASSPATH=\"${JAVA_PKG_CLASSPATH}\""
> - [[ -n "${JAVA_PKG_LIBRARY}" ]] && echo
> "LIBRARY_PATH=\"${JAVA_PKG_LIBRARY}\""
> - [[ -n "${JAVA_PROVIDE}" ]] && echo
> "PROVIDES=\"${JAVA_PROVIDE}\""
> - [[ -f "${JAVA_PKG_DEPEND_FILE}" ]] \
> - && echo "DEPEND=\"$(cat
> "${JAVA_PKG_DEPEND_FILE}" | uniq | tr '\n' ':')\""
> - [[ -f "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]] \
> - && echo "OPTIONAL_DEPEND=\"$(cat
> "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" | uniq | tr '\n' ':')\""
> - echo "VM=\"$(echo ${RDEPEND} ${DEPEND} | sed -e 's/
> /\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\"" # TODO cleanup !
> - ) > "${JAVA_PKG_ENV}"
Why not use a code block {} instead of a subshell ()?
> - # register target/source
> - local target="$(java-pkg_get-target)"
> - local source="$(java-pkg_get-source)"
> - [[ -n ${target} ]] && echo "TARGET=\"${target}\"" >>
> "${JAVA_PKG_ENV}"
> - [[ -n ${source} ]] && echo "SOURCE=\"${source}\"" >>
> "${JAVA_PKG_ENV}"
> -
> - # register javadoc info
> - [[ -n ${JAVADOC_PATH} ]] && echo
> "JAVADOC_PATH=\"${JAVADOC_PATH}\"" \
> - >> ${JAVA_PKG_ENV}
> - # register source archives
> - [[ -n ${JAVA_SOURCES} ]] && echo
> "JAVA_SOURCES=\"${JAVA_SOURCES}\"" \
> - >> ${JAVA_PKG_ENV}
> -
> -
> - echo "MERGE_VM=\"${GENTOO_VM}\"" >> "${JAVA_PKG_ENV}"
> - [[ -n ${GENTOO_COMPILER} ]] && echo
> "MERGE_COMPILER=\"${GENTOO_COMPILER}\"" >> "${JAVA_PKG_ENV}"
I don't understand why all these things are done down here instead of in the
same code block as $JAVA_PKG_ENV is created.
> - # Strip unnecessary leading and trailing colons
> - # TODO try to cleanup if possible
> - sed -e "s/=\":/=\"/" -e "s/:\"$/\"/" -i "${JAVA_PKG_ENV}" ||
> die "Did you forget to call java_init ?"
> +
> + if [[ $1 != provider ]]; then
Could you explain what the next section is supposed to do, as opposed to
the above section? Are they expected to be mutually exclusive? The
comments suggest so, since both have a 'Create package.env'. But the
tests suggest otherwise, since it's not an if...else pair.
> + # Create directory for package.env
> + dodir "${JAVA_PKG_SHAREPATH}"
> + if [[ -n "${JAVA_PKG_CLASSPATH}" || -n "${JAVA_PKG_LIBRARY}" ||
> -f \
> + "${JAVA_PKG_DEPEND_FILE}" || -f \
> + "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]]; then
> + # Create package.env
> + (
> + echo "DESCRIPTION=\"${DESCRIPTION}\""
> + echo "GENERATION=\"2\""
> +
> + [[ -n "${JAVA_PKG_CLASSPATH}" ]] && echo
> "CLASSPATH=\"${JAVA_PKG_CLASSPATH}\""
> + [[ -n "${JAVA_PKG_LIBRARY}" ]] && echo
> "LIBRARY_PATH=\"${JAVA_PKG_LIBRARY}\""
> + [[ -n "${JAVA_PROVIDE}" ]] && echo
> "PROVIDES=\"${JAVA_PROVIDE}\""
> + [[ -f "${JAVA_PKG_DEPEND_FILE}" ]] \
> + && echo "DEPEND=\"$(cat
> "${JAVA_PKG_DEPEND_FILE}" | uniq | tr '\n' ':')\""
> + [[ -f "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]] \
> + && echo "OPTIONAL_DEPEND=\"$(cat
> "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" | uniq | tr '\n' ':')\""
> + echo "VM=\"$(echo ${RDEPEND} ${DEPEND} | sed -e
> 's/ /\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\"" # TODO cleanup !
> + ) > "${JAVA_PKG_ENV}"
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Council 2007 Election Results
On Wed, 2007-09-19 at 09:58 +0800, Shyam Mani wrote: > Our best wishes go out to the new Council members. Can someone write up something for our front page? Even better would be a nice press release on this to go out to the various media outlets. After all, it isn't that often that something positive gets reported about Gentoo in some of the press. -- 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-x86 commit in sys-cluster/csync2: ChangeLog csync2-1.34.ebuild
On 19:31 Thu 20 Sep , Arfrever Frehtes Taifersar Arahesis wrote:
> > > src_compile() {
> > > econf \
> > > --localstatedir=/var \
> > > --sysconfdir=/etc/csync2 \
> > > || die
> > >
> > > emake || die
> >
> > These could really use some die() messages, so you know which one failed.
>
> 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?
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Council 2007 Election Results
Chris Gianelloni wrote: > On Wed, 2007-09-19 at 09:58 +0800, Shyam Mani wrote: >> Our best wishes go out to the new Council members. > > Can someone write up something for our front page? > > Even better would be a nice press release on this to go out to the > various media outlets. After all, it isn't that often that something > positive gets reported about Gentoo in some of the press. > Next year PR should include itself in the election process so it can send out PR at the same time the officials announce on the MLs. --taco -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] gentoo-x86 commit in sys-cluster/csync2: ChangeLog csync2-1.34.ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
2007-09-20 19:53:53 Donnie Berkholz napisał(a):
> On 19:31 Thu 20 Sep , Arfrever Frehtes Taifersar Arahesis wrote:
> > > > src_compile() {
> > > > econf \
> > > > --localstatedir=/var \
> > > > --sysconfdir=/etc/csync2 \
> > > > || die
> > > >
> > > > emake || die
> > >
> > > These could really use some die() messages, so you know which one failed.
> >
> > econf has default "econf failed" die message.
> > The following would be sufficient:
> > econf \
> > --localstatedir=/var \
> > --sysconfdir=/etc/csync2
>
> Does it happen for all of the package managers?
I don't know.
> Which functions do this?
Read /usr/lib/portage/bin/ebuild.sh:econf().
> Where is it documented?
Unfortunately it's probably undocumented.
- --
Arfrever Frehtes Taifersar Arahesis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFG8rXB/axNJ4Xo/ZERAqh5AJ9iwuH3EEWKXLb5P9L/TZCaM2r95ACfdWiz
Ogzh4t/qqSvvwvjwSY/Z0R4=
=19/n
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New eclass to support java-virtuals
Donnie Berkholz wrote:
> On 23:20 Thu 20 Sep , Alistair Bush wrote:
>> -# Create package.env
>> -(
>> -echo "DESCRIPTION=\"${DESCRIPTION}\""
>> -echo "GENERATION=\"2\""
>> -
>> -[[ -n "${JAVA_PKG_CLASSPATH}" ]] && echo
>> "CLASSPATH=\"${JAVA_PKG_CLASSPATH}\""
>> -[[ -n "${JAVA_PKG_LIBRARY}" ]] && echo
>> "LIBRARY_PATH=\"${JAVA_PKG_LIBRARY}\""
>> -[[ -n "${JAVA_PROVIDE}" ]] && echo
>> "PROVIDES=\"${JAVA_PROVIDE}\""
>> -[[ -f "${JAVA_PKG_DEPEND_FILE}" ]] \
>> -&& echo "DEPEND=\"$(cat
>> "${JAVA_PKG_DEPEND_FILE}" | uniq | tr '\n' ':')\""
>> -[[ -f "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]] \
>> -&& echo "OPTIONAL_DEPEND=\"$(cat
>> "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" | uniq | tr '\n' ':')\""
>> -echo "VM=\"$(echo ${RDEPEND} ${DEPEND} | sed -e 's/
>> /\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\"" # TODO cleanup !
>> -) > "${JAVA_PKG_ENV}"
>
> Why not use a code block {} instead of a subshell ()?
You would have to ask the original author about that, but point taken.
>
>> -# register target/source
>> -local target="$(java-pkg_get-target)"
>> -local source="$(java-pkg_get-source)"
>> -[[ -n ${target} ]] && echo "TARGET=\"${target}\"" >>
>> "${JAVA_PKG_ENV}"
>> -[[ -n ${source} ]] && echo "SOURCE=\"${source}\"" >>
>> "${JAVA_PKG_ENV}"
>> -
>> -# register javadoc info
>> -[[ -n ${JAVADOC_PATH} ]] && echo
>> "JAVADOC_PATH=\"${JAVADOC_PATH}\"" \
>> ->> ${JAVA_PKG_ENV}
>> -# register source archives
>> -[[ -n ${JAVA_SOURCES} ]] && echo
>> "JAVA_SOURCES=\"${JAVA_SOURCES}\"" \
>> ->> ${JAVA_PKG_ENV}
>> -
>> -
>> -echo "MERGE_VM=\"${GENTOO_VM}\"" >> "${JAVA_PKG_ENV}"
>> -[[ -n ${GENTOO_COMPILER} ]] && echo
>> "MERGE_COMPILER=\"${GENTOO_COMPILER}\"" >> "${JAVA_PKG_ENV}"
>
> I don't understand why all these things are done down here instead of in the
> same code block as $JAVA_PKG_ENV is created.
That to is also historical, and i'm less inclined to changed it. I've
already broken the tree once with a eclass change, breaking this would
completely break java support. It could be updated as part of our
general QA, but I believe that it should be done separately, and not
bundled in with the changes i've made.
>
>> -# Strip unnecessary leading and trailing colons
>> -# TODO try to cleanup if possible
>> -sed -e "s/=\":/=\"/" -e "s/:\"$/\"/" -i "${JAVA_PKG_ENV}" ||
>> die "Did you forget to call java_init ?"
>> +
>> +if [[ $1 != provider ]]; then
>
> Could you explain what the next section is supposed to do, as opposed to
> the above section? Are they expected to be mutually exclusive? The
> comments suggest so, since both have a 'Create package.env'. But the
> tests suggest otherwise, since it's not an if...else pair.
normally java-pkg_do_write_ is called to write the package.env out, as
can be seen, and is the default behavior for the function. What I am
adding is the ability to _do_write of a "[virtual|provider].env" file.
While at present it only contains 3 variables, I see no reason why
eventually it will not include other vars that are shared between the
package.env and "virtual.env" ( e.g DESCRIPTION )
Therefore this change can be summarized as
+ if [[ $1 != provider ]]; then
#Do the default package.env behaviour
+ else
+ #Create a "virtual.env" file. This will only be invoked by
+ #ebuilds that inherit java-virtuals.eclass
+ fi
I could very well reflactor the java-pkg_do_write_ function back to its
current state and create a new function java-pkg_do_write_virtual to be
called by java-virtuals-2.eclass.
The documentation could (and will) be updated to more correctly reflect
whats happening.
>
>> +# Create directory for package.env
>> +dodir "${JAVA_PKG_SHAREPATH}"
>> +if [[ -n "${JAVA_PKG_CLASSPATH}" || -n "${JAVA_PKG_LIBRARY}" ||
>> -f \
>> +"${JAVA_PKG_DEPEND_FILE}" || -f \
>> +"${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]]; then
>> +# Create package.env
>> +(
>> +echo "DESCRIPTION=\"${DESCRIPTION}\""
>> +echo "GENERATION=\"2\""
>> +
>> +[[ -n "${JAVA_PKG_CLASSPATH}" ]] && echo
>> "CLASSPATH=\"${JAVA_PKG_CLASSPATH}\""
>> +[[ -n "${JAVA_PKG_LIBRARY}" ]] && echo
>> "LIBRARY_PATH=\"${JAVA_PKG_LIBRARY}\""
>> +[[ -n "${JAVA_PROVIDE}" ]] && echo
>> "PROVIDES=\"${JAVA_PROVIDE}\""
>> +[[ -f "${JAVA_PKG_DEPEND_FILE}"
Re: [gentoo-dev] gentoo-x86 commit in sys-cluster/csync2: ChangeLog csync2-1.34.ebuild
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. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass to support java-virtuals
On 06:58 Fri 21 Sep , Alistair Bush wrote: > normally java-pkg_do_write_ is called to write the package.env out, as > can be seen, and is the default behavior for the function. What I am > adding is the ability to _do_write of a "[virtual|provider].env" file. > While at present it only contains 3 variables, I see no reason why > eventually it will not include other vars that are shared between the > package.env and "virtual.env" ( e.g DESCRIPTION ) > > Therefore this change can be summarized as > > + if [[ $1 != provider ]]; then > #Do the default package.env behaviour > + else > + #Create a "virtual.env" file. This will only be invoked by > + #ebuilds that inherit java-virtuals.eclass > + fi > > I could very well reflactor the java-pkg_do_write_ function back to its > current state and create a new function java-pkg_do_write_virtual to be > called by java-virtuals-2.eclass. > > The documentation could (and will) be updated to more correctly reflect > whats happening. I'm concerned about code duplication, because that's what it looks like. Refactoring might be a good idea. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Guys, I need your assistance here
Dawid Węgliński schrieb: > I'm curious, because i'm working with jokey to make p.g.o > up. Right, he contributed a modified template, I wrote a new db generator already and now working on some genshi/cherrypy frontend to avoid this shtml stuff. So anyone who wants to join: http://orion7.digital-server.de/cgi-bin/gitweb.cgi?p=packages.git;a=summary git://orion7.digital-server.de/packages.git If someone wants to see source being worked on, there it is, patches and contributions welcome ;) Note: normally I'd go public after the thing is at least partially working on both parts but as people start kicking heads this imho makes sense now... Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Is anyone from infra around?
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 -- / Georgi Georgiev/ The only two things that motivate me and/ \ [EMAIL PROTECTED]\ that matter to me are revenge and guilt. - \ / http://www.gg3.net/ / - Elvis Costello/ -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Error mail
Hello ! I'm sorry I send error mail. -- Best regards, Sincerely yours, Yuriy Rusinov
Re: [gentoo-dev] I've added you as a friend on StumbleUpon
Can we just unsubscribe this person from this list? This is absolutely ludicrous. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Is anyone from infra around?
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. --taco -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Proper way to determine whether a profile is multilib?
OK. I'm looking at bug #173962[1] and bug #187683[2] currently and encountering a problem which I thought I would bring to the group to try to resolve. Both ATI and NVIDIA binary video drivers supply both 64-bit and 32-bit libraries. Now, our default profiles are multilib for amd64, but there is also a no-multilib sub-profile. The problem is that we need to install app-emulation/emul-linux-x86-xlibs on a multilib profile, but cannot install it on a no-multilib profile. The ebuilds currently use USE=multilib, which has been deprecated for a while and is masked on amd64, to determine whether to install this package. Of course, this doesn't work out. I'm pretty sure we cannot do any multilib profile checks prior to *DEPEND because they'll be done in the global scope and will affect cache generation, as the check will get the profile from the server doing cache generation. Now, on to the question... How do we *DEPEND on something that is only necessary for a multilib profile without USE=multilib and without invalidating the cache? My two "solutions" (neither of which are good) are as follows: - Re-enable USE=multilib in the multilib profiles, and force it on in the proper profiles while masking it in the others... this might be feasible simply because we *can* force-enable USE flags in a profile now, which we couldn't do back when this was deprecated - Re-create app-emulation/emul-linux-x86-nvidia with the 32-bit parts of nvidia-drivers in it and have 32-bit apps *DEPEND on this package on the affected architectures... this is also a bit less ugly than it used to be because NVIDIA is now shipping all of the required libraries so all we would need to do is make the versions match Can someone else come up with another idea, preferably a much better one? [1] http://bugs.gentoo.org/show_bug.cgi?id=173962 [2] http://bugs.gentoo.org/show_bug.cgi?id=187683 -- 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?
Renat Golubchyk wrote: > That's wrong. Quote: > > "When bash is invoked as an interactive login shell, or as a non-inter- > active shell with the --login option, it first reads and executes com- > mands from the file /etc/profile, if that file exists. After reading > that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, > in that order, and reads and executes commands from the first one that > exists and is readable. The --noprofile option may be used when the > shell is started to inhibit this behavior." > > Notice "the first one that exists and is readable". > > >> If "~/.bash_profile" doesn't exist, then "~/.bashrc" won't be sourced >> whether it exists or not. >> > > Wrong again. Two paragraphs down in the man page: > > "When an interactive shell that is not a login shell is started, bash > reads and executes commands from ~/.bashrc, if that file exists." > > In this case ~/.bashrc is sourced directly. > > > Cheers, > Renat > Rats. I checked the source and you're right. My problem domain is smaller than I thought but still valid, I think. Basically the problem is only with interactive login shells and /root. Not *broken*, per se: just contrary to recommended practice. The Bash documentation *recommends* that a ~/.bash_profile exists so that ~/.bashrc can be made to be sourced for login shells and codifies its recommendation by putting a template .bash_profile in /etc/skel. - John -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/drbd: ChangeLog drbd-8.0.6.ebuild
On Thursday 20 September 2007, Donnie Berkholz wrote:
> On 08:35 Thu 20 Sep , Christian Zoffoli (xmerlin) wrote:
> > 1.1 sys-cluster/drbd/drbd-8.0.6.ebuild
> >
> > cp -R /usr/src/linux-${KV} ${WORKDIR}
that cant be right
> > emake -j1 KDIR=/${WORKDIR}/linux-${KV} O=${KBUILD_OUTPUT} || die
prefixing $WORKDIR with a / is just silly
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thursday 20 September 2007, Chris Gianelloni wrote: > On Thu, 2007-09-20 at 12:34 -0400, Mike Frysinger wrote: > > > > what catalyst should do is just before cleaning up the stage3 root > > > > and packing it up is run `rsync -a /etc/skel/ /root/` > > > > > > It definitely should not. One of my primary motivations with catalyst > > > is to ensure that the users get *exactly* what would be provided by the > > > profiles/packages. We don't add extra files into the stages and likely > > > never will. Doing something like this in catalyst would create an > > > inconsistency between doing a stage3 install and any previous stage > > > installs. Yes, we don't support stage1 anymore, but we still support > > > stage1 users once their systems are up and running. Having them > > > inconsistent only causes one more area where we have to do extra > > > troubleshooting to determine the cause. > > > > not really ... someone installing by hand and someone taking a default > > setup are different things. we know that someone taking a stage3 has > > never configured anything before and so we can safely put defaults into > > /root/. we have no idea what people have done when they run emerge > > themselves. that is why only putting this into catalyst makes sense. > > I'll respectfully disagree and say again that I won't add anything like > this to catalyst for the reasons mentioned above. I see no reason why > we cannot provide sensible defaults in stages lower than three, > especially since I want to see everything in ebuild code. > > 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 > > > Well, it depends on whether we're interested in getting all of > > > /etc/skel or just the .bash* files. About the only thing I would see > > > useful as "defaults" is the .bash* stuff and a .ssh directory. I do > > > agree that everything else should be left up to the user. If we > > > decided what to include and limited it, it shouldn't be a problem to do > > > it via USE=build at all. > > > > anything that is part of the system /etc/skel/ makes sense (iow, anything > > that is in /etc/skel/ at the end of stage3). the files from bash and the > > .ssh dir are the only things that go into /etc/skel/ right now for the > > default system. > > OK. So we now know that only bash/openssh would be really important > here, and the .ssh directory really isn't much of a show-stopper, since > it isn't populated. I mention this only because we don't install > openssh until stage3, so there's no special USE flags in use at that > time. If we limited it to bash (and tcsh, etc. for non-Linux) using > USE=build, it would satisfy this request, one which I personally would > like to see done, and still not have to change a single line of code in > catalyst, which also respects my wishes. It doesn't stomp on user's > files. All in all, it seems like a safe enough solution to me. no ... the fact that *today* we have just bash/openssh and *today* openssh is installing an empty dir (not exactly empty, the permissions are set much stricter than default `mkdir`) is irrelevant ... i want to fix this once and only once and not see another request about XYZ package installs FOO and now we decided we also want special code to handle FOO -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] gentoo-x86 commit in sys-cluster/csync2: ChangeLog csync2-1.34.ebuild
On Thursday 20 September 2007, Donnie Berkholz wrote:
> On 19:31 Thu 20 Sep , Arfrever Frehtes Taifersar Arahesis wrote:
> > > > src_compile() {
> > > > econf \
> > > > --localstatedir=/var \
> > > > --sysconfdir=/etc/csync2 \
> > > >
> > > > || die
> > > >
> > > > emake || die
> > >
> > > These could really use some die() messages, so you know which one
> > > failed.
> >
> > 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?
econf has always died as far as i know ... however, we've been using econf||
die as a standard for just as long and i dont think we should change now
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Roy Marples wrote: > Looking over the bash man page, I cannot see the word recommended > anywhere near .bash_profile. Could you clarify where you think bash > recommends this? > > Thanks > > Roy > Why, sure. It's my interpretation, but a reasonable one, I think. It recommends it in its implementation, by creating .bash_profile in /etc/skel with content that implements a particular behavior. The documentation also states, "So, typically, your `~/.bash_profile' contains the line `if [ -f ~/.bashrc ]; then . ~/.bashrc; fi' after (or before) any login-specific initializations." And, lo, the .bash_profile file in /etc/skel has a functionally identical line in it. Doubly recommended, in a manner of speaking. - John -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thu, 2007-09-20 at 19:17 -0400, John R. Graham wrote: > Rats. I checked the source and you're right. My problem domain is > smaller than I thought but still valid, I think. Basically the problem > is only with interactive login shells and /root. Not *broken*, per se: > just contrary to recommended practice. The Bash documentation > *recommends* that a ~/.bash_profile exists so that ~/.bashrc can be made > to be sourced for login shells and codifies its recommendation by > putting a template .bash_profile in /etc/skel. Looking over the bash man page, I cannot see the word recommended anywhere near .bash_profile. Could you clarify where you think bash recommends this? Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thu, 2007-09-20 at 21:22 -0400, John R. Graham wrote: > > Roy Marples wrote: > > Looking over the bash man page, I cannot see the word recommended > > anywhere near .bash_profile. Could you clarify where you think bash > > recommends this? > > > Why, sure. It's my interpretation, but a reasonable one, I think. No it's not. bash does not recommend anything of the sort. It just states what files are optionally used during initialisation. What I'm driving at is that you're making claims that things are broken or recommended when in fact they are not. Try reading some RFC's and then you'll have a clearer (hopefully!!) understanding of the words MUST and SHOULD. Also you'll understand that if those words are not present then it's entirely optional. I fully recommend reading RFC 2131 [1] as I'm very well acquainted with it and it also provides lots of good examples of these words :) Thanks Roy [1] http://www.rfc-archive.org/getrfc.php?rfc=2131 PS - This does not necessarily mean I think /etc/skel files in /root is a bad thing, I just think you're going completely the wrong way about getting this done. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Roy Marples wrote: > No it's not. bash does not recommend anything of the sort. It just > states what files are optionally used during initialisation. > > What I'm driving at is that you're making claims that things are broken > or recommended when in fact they are not. Try reading some RFC's and > then you'll have a clearer (hopefully!!) understanding of the words MUST > and SHOULD. Also you'll understand that if those words are not present > then it's entirely optional. I fully recommend reading RFC 2131 [1] as > I'm very well acquainted with it and it also provides lots of good > examples of these words :) > > Thanks > > Roy > > [1] http://www.rfc-archive.org/getrfc.php?rfc=2131 > > PS - This does not necessarily mean I think /etc/skel files in /root is > a bad thing, I just think you're going completely the wrong way about > getting this done. > > Roy, thanks for the advice. Obviously I misstated some things. However, man pages and info docs are written in more colloquial language than formal specifications. Anyway, I promise not to beat the dead horse. - John -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Why isn't /root/.bash_profile in the stage tarballs?
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.) 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. -- 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
Re: [gentoo-dev] New eclass to support java-virtuals
Donnie Berkholz wrote: > On 06:58 Fri 21 Sep , Alistair Bush wrote: >> normally java-pkg_do_write_ is called to write the package.env out, as >> can be seen, and is the default behavior for the function. What I am >> adding is the ability to _do_write of a "[virtual|provider].env" file. >> While at present it only contains 3 variables, I see no reason why >> eventually it will not include other vars that are shared between the >> package.env and "virtual.env" ( e.g DESCRIPTION ) >> >> Therefore this change can be summarized as >> >> + if [[ $1 != provider ]]; then >> #Do the default package.env behaviour >> + else >> +#Create a "virtual.env" file. This will only be invoked by >> +#ebuilds that inherit java-virtuals.eclass >> + fi >> >> I could very well reflactor the java-pkg_do_write_ function back to its >> current state and create a new function java-pkg_do_write_virtual to be >> called by java-virtuals-2.eclass. >> >> The documentation could (and will) be updated to more correctly reflect >> whats happening. > > I'm concerned about code duplication, because that's what it looks like. > Refactoring might be a good idea. > > Thanks, > Donnie Ok, thanks for the input Donnie. I will refactor it before goes into the tree. Any more input ppl? Thanks Alistair -- [EMAIL PROTECTED] mailing list
