Re: [gentoo-dev] Re: Keyword amd64 -> x86_64
On Thu, 2008-02-21 at 16:27 +1100, Andrew Cowie wrote: > On Wed, 2008-02-20 at 19:42 -0600, Ryan Hill wrote: > > But I agree, rekeywording amd64 to x86_64 would probably be more work than > > it's > > worth. > > Can we not just hardwire an alias into the emerge codebase? > > I must admit, from a purely optical standpoint, the idea of saying my > system is "amd64" when it is nothing of the sort really grates. If, > internally, it just translated "x86_64" to "amd64" wouldn't that be ok? I really don't see the problem with AMD64, why it would be more wrong than ia32 or x86 (based on Intel's product numbers!). AMD64 was invented by AMD and they get to pick the name for it. The keyword amd64 in Gentoo when Intel was still dismissing AMD64... -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Keyword amd64 -> x86_64
On Wed, 2008-02-20 at 19:42 -0600, Ryan Hill wrote: > But I agree, rekeywording amd64 to x86_64 would probably be more work than > it's > worth. Can we not just hardwire an alias into the emerge codebase? I must admit, from a purely optical standpoint, the idea of saying my system is "amd64" when it is nothing of the sort really grates. If, internally, it just translated "x86_64" to "amd64" wouldn't that be ok? AfC Sydney -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/asterisk-addons: ChangeLog asterisk-addons-1.2.8.ebuild asterisk-addons-1.2.5-r1.ebuild asterisk-addons-1.2.4.ebuild asterisk-addons-1.2
On 04:07 Thu 21 Feb , Rajiv Aaron Manglani (rajiv) wrote:
> 1.1 net-misc/asterisk-addons/asterisk-addons-1.2.8.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/asterisk-addons/asterisk-addons-1.2.8.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/asterisk-addons/asterisk-addons-1.2.8.ebuild?rev=1.1&content-type=text/plain
> pkg_setup() {
> local n dosleep=0
> einfo "Running pre-flight checks..."
>
> if use h323 && built_with_use net-misc/asterisk h323; then
> echo
> ewarn "h323: Emerging ${PN} with the h323 flag enabled will
> overwrite asterisk's chan_h323.so!"
> ewarn "h323: Be sure to upgrade ${ROOT}etc/asterisk/h323.conf
> afterwards!"
> dosleep=1
> fi
>
> if use sqlite && built_with_use net-misc/asterisk sqlite; then
> echo
> ewarn "sqlite: Emerging ${PN} with the sqlite flag enabled will
> overwrite asterisk's res_sqlite.so!"
> ewarn "sqlite: Be sure to upgrade
> ${ROOT}etc/asterisk/res_sqlite.conf afterwards!"
> dosleep=1
> fi
>
> echo
> if [[ $dosleep -gt 0 ]]; then
> ebeep
> n=10
> while [[ $n -gt 0 ]]; do
> echo -en " Waiting $n seconds...\r"
> sleep 1
> (( n-- ))
> done
This is what epause() is for, or ebeep() if you really want people to
notice.
> fi
> }
>
> src_unpack() {
> unpack ${A}
> cd ${S}
>
> #
> # gentoo patchset
> #
> epatch ${FILESDIR}/${PN}-1.2.0-gentoo-base.diff
> epatch ${FILESDIR}/${PN}-1.2.0-gentoo-res_sqlite3.diff
> epatch ${FILESDIR}/${PN}-1.2.2-gentoo-format_mp3.diff
> epatch ${FILESDIR}/${PN}-1.2.3-gentoo-ooh323c.diff
>
> # patch from jaervosz for uclibc
> if use elibc_uclibc; then
> epatch ${FILESDIR}/${PN}-1.2.2-uclibc.diff
> epatch ${FILESDIR}/${PN}-1.2.4-uclibc.diff
> fi
> # patch sqlite
> if use sqlite; then
> cd ${WORKDIR}/sqlite-${SQLITE_PV}
>
> epatch ${FILESDIR}/sqlite-${SQLITE_PV}-data-corruption.patch
> epunt_cxx
> fi
>
> # rebuild ooh323c configure
> if use h323; then
> cd ${S}/asterisk-ooh323c
> eautoreconf
> fi
> }
Repoman should be yelling at you about lack of quotes here. Are you on
the latest version?
> src_install() {
> make DESTDIR=${D} install || die "Make install failed"
Does emake work? If not, please note why in a comment. Same question for
other 'make' calls.
> if use h323 || use mysql; then
> einfo "Fixing permissions"
> chown -R root:asterisk ${D}etc/asterisk
> chmod -R u=rwX,g=rX,o= ${D}etc/asterisk
> fi
You could change these to fperms/fowners while you're fixing.
Thanks,
Donnie
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Keyword amd64 -> x86_64
Christoph Mende wrote: On Wed, 20 Feb 2008 12:59:11 -0500 "William L. Thomson Jr." <[EMAIL PROTECTED]> wrote: Unless the work to do that is greater than the value of the change. It most likely is. And beside of that: amd64 is the technically correct term. :p *sigh* I know I'm going to regret going down this road, but, "lies!". ;) AMD implemented x86-64, and marketed it as "AMD64". Intel cloned it as "EM64T", later renamed "Intel 64". GCC compiles for x86-64 which is the subset of the two. But I agree, rekeywording amd64 to x86_64 would probably be more work than it's worth. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Keyword amd64 -> x86_64
On Wed, 20 Feb 2008 12:59:11 -0500 "William L. Thomson Jr." <[EMAIL PROTECTED]> wrote: > Unless the work to do that is greater than the value of the change. It most likely is. And beside of that: amd64 is the technically correct term. :p signature.asc Description: PGP signature
[gentoo-dev] The future of ebuild
Hi gentooists,
I've been reading news sites about some changes happening in Gentoo
and I thought it might be a good time to submit some ideas I've been
baking for several years.
I come from a Linux From Scratch background, I like the feeling of
knowing every single corner of my system and the fact that there isn't
anything that I don't want or need. However, typing every single
command by hand is far from ideal, so at first I started writing some
scripts and eventually I wrote a build system that suited my needs. I
did it in bash for several reasons.
After a while I realized bash wasn't exactly the best language to
write such thing. Mainly because:
a) The code ends up with a lot of stuff for handling strings properly
(like escaping sequences)
b) Error are difficult to handle since bash doesn't have exceptions
c) Persistent information is difficult to achieve (no database stuff)
d) Package information is difficult to fetch/store (no objects/struct)
A more featured language could allow for example: filtered output,
exception handling->state storage->resuming.
But the big deal is with the package definition, recently I learned
about Domain Specific Languages, and I think that is the best option.
A new dsl allows many interesting features in the package definition
itself like: inheritance, exceptions, arrays, hash tables, objects,
modules, documentation, information messages, etc.
Take this example:
package Binutils < Gnu
definition
@version = "2.17"
@name = "binutils"
super() # run the Gnu definition stuff
@config_opts = "--disable-nls --with-sysroot=\"#{$sys_root}\"
--enable-shared --disable-multilib"
end
steps
build
cd #{$top_build_dir}
mkdir -p [EMAIL PROTECTED]
cd [EMAIL PROTECTED]
:configure "script" => "../[EMAIL PROTECTED]/configure", "opts" =>
@config_opts
make configure-host
make
end
install
cd #{$top_build_dir}
cd [EMAIL PROTECTED]
make install
end
end
end
This is based on an already working prototype made in Ruby, so it's
biased towards Ruby facilities.
I've tried different build systems: rpm, dpkg, autopackage.
Unfortunately I never tried ebuild because it was based on bash as far
as I could tell.
After almost a decade of using Linux I still haven't found a build
system that suits all my needs. AFAIK ebuild is the most advanced but
it's still relying on ancient technology (bash scripts) so there will
always be limitations despite the brilliant ideas.
The core of a distribution is the "packaging" system, and the core of
the packaging system is the building system, which has no reason not
to be distribution agnostic, and actually, packaging system agnostic.
Why not create a new build system with a state of the art programming
language, and an advanced DSL that actually other distributions could
use?
I would like to hear your opinions on this matter.
--
Felipe Contreras
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Keyword amd64 -> x86_64
On 20-02-2008 19:23:26 +0100, Marius Mauch wrote: > On Wed, 20 Feb 2008 12:59:11 -0500 > "William L. Thomson Jr." <[EMAIL PROTECTED]> wrote: > > > Please excuse my ignorance if this is a naive comment or has been > > brought up before. With all the non amd processors now with 64bit > > support. amd64 as a keyword seems a bit odd and off maybe. > > > > What's the possibility of switching amd64 to x86_64? > > > > Unless the work to do that is greater than the value of the change. > > As the benefit is close to nothing IMO the required work is definitely > greater by several orders of magnitude. Well, that depends a bit. We basically introduced x64 a shorthand, and changed some keywords in prefix, of which I just finished the transition. It's basically just setting the new keyword in the profiles, and then gradually changing the keywords, e.g. on a repoman commit. That's sort of how I did it. You don't need any Portage support, IMHO. But I think for the current amd64 keyword, it's not worth the hassle to change it. Though, if for instance amd64-fbsd would be introduced, I think this keyword should have something more generic arch instead, like the x64 we use in prefix now. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Keyword amd64 -> x86_64
On Wed, 20 Feb 2008 12:59:11 -0500 "William L. Thomson Jr." <[EMAIL PROTECTED]> wrote: > Please excuse my ignorance if this is a naive comment or has been > brought up before. With all the non amd processors now with 64bit > support. amd64 as a keyword seems a bit odd and off maybe. > > What's the possibility of switching amd64 to x86_64? > > Unless the work to do that is greater than the value of the change. As the benefit is close to nothing IMO the required work is definitely greater by several orders of magnitude. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Keyword amd64 -> x86_64
William L. Thomson Jr. a écrit : Please excuse my ignorance if this is a naive comment or has been brought up before. With all the non amd processors now with 64bit support. amd64 as a keyword seems a bit odd and off maybe. I think we'd already discussed this a while back, and decided not to change it. (I don't remember the final reasons though) I for one don't really care, except that "x86_64" is longer to type than "amd64" ;) That's the only reason I could find. Rémi -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Keyword amd64 -> x86_64
Please excuse my ignorance if this is a naive comment or has been brought up before. With all the non amd processors now with 64bit support. amd64 as a keyword seems a bit odd and off maybe. What's the possibility of switching amd64 to x86_64? Unless the work to do that is greater than the value of the change. I was thinking if portage could be updated to see both as the same arch. Then we could transition ebuilds at their own pace. No massive changes to tree. Not sure how it would play with like use amd64, if statements, etc Anyway just a thought. Not one of any importance to me. So feel free to bash the idea to hell :) Plz not me, I am doing a good job on my own of writing my own ticket to hell ;) -- William L. Thomson Jr. Gentoo/amd64/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] subversion.eclass
Doug Klima wrote:
Doug Klima wrote:
Doug Klima wrote:
Doug Klima wrote:
Bo Ørsted Andresen wrote:
For quite a while the KDE herd has had a modified version of
subversion.eclass in the kde overlay. During that time we have
added the following features to the eclass which we would like to
put back in gentoo-x86 soon. Since the changes are fairly
extensive we decided to send it to this list for review first.
1) ESVN_REVISION (before this people had to use ESVN_OPTIONS for
this purpose).
2) ESVN_OFFLINE which disables svn up.
3) ESVN_UP_FREQ which uses GNU find to determine if the specified
number of hours has passed and only do svn up if it has. This is
currently used in the kde4svn-meta eclass for split kde ebuilds
that use the same checkout of each module.
4) ESCM_LOGDIR for logging which revisions packages get installed
with. See [1]. Users need to explicitly enable this feature to use
it.
Other than this the eclass has been documented for use with
eclass-manpages.
[1] http://thread.gmane.org/gmane.linux.gentoo.devel/54233
ok. Well zlin and I have been talking lately and we've hammered out
his proposed changes and mine. I'm attaching a patch for the first
set of changes I have proposed.
Attached is a patch for the following:
- use $ECLASS
- adding rsync to deps
- fixing some quoting
- remove multiple subshell calls and problematic to upper usage
(bug #s escape me right now)
- provide some more information about the working copy that will be
used in the future.
- supporting svn switch
The most important being the svn switch functionality.
Please review for commit.
And the eclass-manpages documentation broken out into it's own patch.
Please review for commit.
Here's a patch that implements the ESVN_REVISION variable. It finally
removes all the problematic to_upper usage. It builds off the
previous patches that make the official way for an ebuild to pass the
revision it wants via the ESVN_REPO_URI. It ewarn's if an ebuild
tries to stick a revision into ESVN_OPTIONS. It prints out the
revision that it's going to be pulling. This was the issue I had with
zlin's original patch since it would break for the MythTV ebuilds
since we request the revision in the ebuild.
Here's another patch in the series.
This patch will skip running svn update when it's unnecessary.
Basically if your local working copy is the same URI and same
revision, it won't run svn update which should speed up emerge times
for those svn KDE users that specify a revision they're looking to
use. Also MythTV users that re-emerge with different use flags.
The following patch makes changes to where the svn checkouts are stored.
This will fix the issue where for example:
mytharchive, mythdvd, mythvideo, mythweather are all stored in
http://svn.mythtv/svn/trunk/mythplugins
the KDE team has similar issues with their split out ebuilds and are
currently solving the issues by calling "private" subversion.eclass
Giving the ebuild and eclass programmer full control over the
ESVN_PROJECT path will allow for these hacks to disappear.
--- subversion-4.eclass 2008-02-20 11:14:23.0 -0500
+++ subversion-5.eclass 2008-02-20 11:35:10.0 -0500
@@ -104,9 +104,9 @@
# # jakarta commons-loggin
# ESVN_PROJECT=commons/logging
#
-# default: ${PN/-svn}.
+# default: ${CATEGORY/${PN/-svn}.
#
-: ${ESVN_PROJECT:=${PN/-svn}}
+: ${ESVN_PROJECT:=${CATEGORY}/${PN}}
# @ECLASS-VARIABLE: ESVN_BOOTSTRAP
@@ -410,7 +410,7 @@
debug-print "${FUNCNAME}: repo_uri = ${repo_uri}"
- echo "${ESVN_STORE_DIR}/${ESVN_PROJECT}/${repo_uri##*/}"
+ echo "${ESVN_STORE_DIR}/${ESVN_PROJECT}/"
}
Re: [gentoo-dev] subversion.eclass
Doug Klima wrote:
Doug Klima wrote:
Doug Klima wrote:
Bo Ørsted Andresen wrote:
For quite a while the KDE herd has had a modified version of
subversion.eclass in the kde overlay. During that time we have
added the following features to the eclass which we would like to
put back in gentoo-x86 soon. Since the changes are fairly extensive
we decided to send it to this list for review first.
1) ESVN_REVISION (before this people had to use ESVN_OPTIONS for
this purpose).
2) ESVN_OFFLINE which disables svn up.
3) ESVN_UP_FREQ which uses GNU find to determine if the specified
number of hours has passed and only do svn up if it has. This is
currently used in the kde4svn-meta eclass for split kde ebuilds
that use the same checkout of each module.
4) ESCM_LOGDIR for logging which revisions packages get installed
with. See [1]. Users need to explicitly enable this feature to use it.
Other than this the eclass has been documented for use with
eclass-manpages.
[1] http://thread.gmane.org/gmane.linux.gentoo.devel/54233
ok. Well zlin and I have been talking lately and we've hammered out
his proposed changes and mine. I'm attaching a patch for the first
set of changes I have proposed.
Attached is a patch for the following:
- use $ECLASS
- adding rsync to deps
- fixing some quoting
- remove multiple subshell calls and problematic to upper usage (bug
#s escape me right now)
- provide some more information about the working copy that will be
used in the future.
- supporting svn switch
The most important being the svn switch functionality.
Please review for commit.
And the eclass-manpages documentation broken out into it's own patch.
Please review for commit.
Here's a patch that implements the ESVN_REVISION variable. It finally
removes all the problematic to_upper usage. It builds off the previous
patches that make the official way for an ebuild to pass the revision
it wants via the ESVN_REPO_URI. It ewarn's if an ebuild tries to stick
a revision into ESVN_OPTIONS. It prints out the revision that it's
going to be pulling. This was the issue I had with zlin's original
patch since it would break for the MythTV ebuilds since we request the
revision in the ebuild.
Here's another patch in the series.
This patch will skip running svn update when it's unnecessary. Basically
if your local working copy is the same URI and same revision, it won't
run svn update which should speed up emerge times for those svn KDE
users that specify a revision they're looking to use. Also MythTV users
that re-emerge with different use flags.
--- subversion-3.eclass 2008-02-20 11:07:57.0 -0500
+++ subversion-4.eclass 2008-02-20 11:14:23.0 -0500
@@ -222,14 +222,14 @@
if [ "${ESVN_WC_URL}" != "$(subversion__get_repository_uri "${repo_uri}")" ]; then
einfo "subversion switch start -->"
- einfo " old repository: ${ESVN_WC_URL}"
+ einfo " old repository: [EMAIL PROTECTED]"
einfo " new repository: ${repo_uri}${revision:[EMAIL PROTECTED]"
debug-print "${FUNCNAME}: ${ESVN_SWITCH_CMD} ${options}"
cd "${wc_path}" || die "${ESVN}: can't chdir to ${wc_path}"
${ESVN_SWITCH_CMD} ${options} ${repo_uri} || die "${ESVN}: can't switch to ${repo_uri}."
- else
+ elif [ "${ESVN_WC_REVISION}" -ne "${revision}" ]; then
# update working copy
einfo "subversion update start -->"
einfo " repository: ${repo_uri}${revision:[EMAIL PROTECTED]"
@@ -238,6 +238,8 @@
cd "${wc_path}" || die "${ESVN}: can't chdir to ${wc_path}"
${ESVN_UPDATE_CMD} ${options} || die "${ESVN}: can't update from ${repo_uri}."
+ else
+ einfo "subversion update skipped. local copy is at requested revision"
fi
fi
Re: [gentoo-dev] subversion.eclass
Doug Klima wrote:
Doug Klima wrote:
Bo Ørsted Andresen wrote:
For quite a while the KDE herd has had a modified version of
subversion.eclass in the kde overlay. During that time we have added
the following features to the eclass which we would like to put back
in gentoo-x86 soon. Since the changes are fairly extensive we
decided to send it to this list for review first.
1) ESVN_REVISION (before this people had to use ESVN_OPTIONS for
this purpose).
2) ESVN_OFFLINE which disables svn up.
3) ESVN_UP_FREQ which uses GNU find to determine if the specified
number of hours has passed and only do svn up if it has. This is
currently used in the kde4svn-meta eclass for split kde ebuilds that
use the same checkout of each module.
4) ESCM_LOGDIR for logging which revisions packages get installed
with. See [1]. Users need to explicitly enable this feature to use it.
Other than this the eclass has been documented for use with
eclass-manpages.
[1] http://thread.gmane.org/gmane.linux.gentoo.devel/54233
ok. Well zlin and I have been talking lately and we've hammered out
his proposed changes and mine. I'm attaching a patch for the first
set of changes I have proposed.
Attached is a patch for the following:
- use $ECLASS
- adding rsync to deps
- fixing some quoting
- remove multiple subshell calls and problematic to upper usage (bug
#s escape me right now)
- provide some more information about the working copy that will be
used in the future.
- supporting svn switch
The most important being the svn switch functionality.
Please review for commit.
And the eclass-manpages documentation broken out into it's own patch.
Please review for commit.
Here's a patch that implements the ESVN_REVISION variable. It finally
removes all the problematic to_upper usage. It builds off the previous
patches that make the official way for an ebuild to pass the revision it
wants via the ESVN_REPO_URI. It ewarn's if an ebuild tries to stick a
revision into ESVN_OPTIONS. It prints out the revision that it's going
to be pulling. This was the issue I had with zlin's original patch since
it would break for the MythTV ebuilds since we request the revision in
the ebuild.
--- subversion-2.eclass 2008-02-19 16:34:15.0 -0500
+++ subversion-3.eclass 2008-02-20 11:07:57.0 -0500
@@ -75,6 +75,14 @@
#
: ${ESVN_REPO_URI:=}
+# @ECLASS-VARIABLE: ESVN_REVISION
+# @DESCRIPTION:
+# user configurable revision to use from the repo
+#
+# useful for live svn or trunk svn ebuilds to allow pegging to
+# a specific revision
+: ${ESVN_REVISION:=}
+
# @ECLASS-VARIABLE: ESVN_PROJECT
# @DESCRIPTION:
@@ -143,9 +151,14 @@
#
function subversion_fetch() {
- local repo_uri="$(subversion__get_repository_uri "${1}")"
+ local repo_uri="$(subversion__get_repository_uri "${1:-${ESVN_REPO_URI}}")"
+ local revision="$(subversion__get_peg_revision "${1:-${ESVN_REPO_URI}}")"
local S_dest="${2}"
+ if [[ -n "${ESVN_REVISION}" ]]; then
+ revision="${ESVN_REVISION}"
+ fi
+
# check for the protocol
local protocol="${repo_uri%%:*}"
@@ -180,6 +193,15 @@
local wc_path="$(subversion__get_wc_path "${repo_uri}")"
local options="${ESVN_OPTIONS} --config-dir ${ESVN_STORE_DIR}/.subversion"
+ if [[ -n "${revision}" ]]; then
+ options="${options} -r ${revision}"
+ fi
+
+ if [[ "${ESVN_OPTIONS}" = *-r* ]]; then
+ ewarn "\${ESVN_OPTIONS} contains -r, this usage is unsupported. Please"
+ ewarn "see \${ESVN_REPO_URI}"
+ fi
+
debug-print "${FUNCNAME}: wc_path = \"${wc_path}\""
debug-print "${FUNCNAME}: ESVN_OPTIONS = \"${ESVN_OPTIONS}\""
debug-print "${FUNCNAME}: options = \"${options}\""
@@ -187,7 +209,7 @@
if [[ ! -d "${wc_path}/.svn" ]]; then
# first check out
einfo "subversion check out start -->"
- einfo " repository: ${repo_uri}"
+ einfo " repository: ${repo_uri}${revision:[EMAIL PROTECTED]"
debug-print "${FUNCNAME}: ${ESVN_FETCH_CMD} ${options} ${repo_uri}"
@@ -198,10 +220,10 @@
else
subversion_wc_info "${repo_uri}" || die "${ESVN}: unknown problem occurred while accessing working copy."
- if [ "${ESVN_WC_URL}" != "$(subversion__get_repository_uri "${repo_uri}" 1)" ]; then
+ if [ "${ESVN_WC_URL}" != "$(subversion__get_repository_uri "${repo_uri}")" ]; then
einfo "subversion switch start -->"
einfo " old repository: ${ESVN_WC_URL}"
- einfo " new repository: ${repo_uri}"
+ einfo " new repository: ${repo_uri}${revision:[EMAIL PROTECTED]"
debug-print "${FUNCNAME}: ${ESVN_SWITCH_CMD} ${options}"
@@ -210,7 +232,7 @@
else
# update working copy
einfo "subversion update start -->"
- einfo " repository: ${repo_uri}"
+ einfo " repository: ${repo_uri}${revision:[EMAIL PROTECTED]"
debug-print "${FUNCNAME}: ${ESVN_UPDATE_CMD} ${options}"
@@ -297,7 +319,7 @@
# default src-Unpack. fetches and bootstraps
function subversion_src_unpack() {
- subversion_fetch || die "${ESVN}: unknown problem occurred in subversion_fetch."
+ sub
