Re: [gentoo-dev] Re: John Jawed & Alex Tarkovsky's einput eclass
On Sun, 08 Jul 2007 04:53:40 +0100 Steve Long <[EMAIL PROTECTED]> wrote: > I understand that games are a `special case', but why not make it a > RESTRICT=interact which would automatically mean repoman would not > allow the package into stable, and admins could easily weed such > packages out? That way any category could use the same thing for > packages with more restrictive licenses. (I'm not suggesting this > should be merged with fetch-restricted as I accept that some stable > Java packages have this set, and there's zero benefit in changing > them.) This isn't about stable or not stable, or about games being special. No ebuild _should_ be interactive, period. However in some cases there is no way to make it non-interactive, and the concentration of those cases is particulary high in the games category (mainly because of a lack of high quality OSS games). Oh, and I've withdrawn the RESTRICT idea as there is a better/more generic solution (not yet implemented though). > So yeah I guess it's encouragement, but if the policy is such > packages can never hit stable, where's the harm? A user has to > explicitly allow such a package (or run unstable in which case they > will be used to dealing with glitches ;) and scripts can still avoid > interactive packages. (And bear in mind, it's not just uis we're > talking about, but stuff like QA automation.) Again, interactivity isn't a criterium for a package becoming stable or not. Marius -- Marius Mauch <[EMAIL PROTECTED]> -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: John Jawed & Alex Tarkovsky's einput eclass
On 7/7/07, Steve Long <[EMAIL PROTECTED]> wrote: I'm ofc not including fetch-restricted which also require interaction, although that is standardised enough for a script to deal with[1]. Having found this for games, I can deal with that too ofc, but I still think the I'm not sure whether special license agreements are a legitimate case for interactivity in some ebuilds, but I can tell you the einput eclass was intended to be used only in pkg_config(), meaning the only time the user would ever encounter einput is when they specifically run "emerge --config foo" after installation, and even then it would be only in a handful of ebuilds that actually need einput's services. Burdening the user with the prospect of interactivity in any other ebuild phase does seem to go against the Portage philosophy, so I feel that einput.eclass is an edge case tool at best. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] automated extended information gathering
On 7/8/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
On Sunday 08 July 2007, Kent Fredric wrote:
> Ok, I've re-thought some of my ideas and tried to come up with a more
> concise explanation
> with some practical example syntax. The basic concept of 'check' was
> 'this will work even if the package aint installed yet' and info was
> 'for working but bust packages only', but that can be superceded with
> a CHECKLIST and a conditional driven INFO function.
as they say, the devil is in the details ...
> pkg_getinfo(){
> if [[ installed ]]; then
> someSelfCheck;
> someSelfCheck;
> echo someversionNumberStuff;
> fi
> someBasicSystemCheckRequiredForPkgToWork();
> if [[ someCondition ]]; then
> get_info( some-cat/d-lib ); # its not on the dep list, but we want
> to check its info status as part of /our/ info status.
> fi
> }
the claim i'm making is that there generally isnt any code/checks worth adding
to ebuilds that would be useful for the purpose of an ebuild diagnosing
itself to determine whether it is broken and how it is broken. we just dont
have a language yet to properly describe the process of diagnosing and fixing
oneself. a fun thesis for an AI doctorate :p
-mike
On 7/8/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
often times when i get a bug report about certain packages, there's
information about that package that i usually ask for ... i wonder if this
can be automated
The idea was to place the code to provide that information into the
applications pkg_getinfo() section, nothing major, just version
numbers etc, and possibly code to test for scenarios that are known to
exist but theres currently no known way to fix them.
Some of these basic checks can be as simple as grabbing the files
CONTENTS out of edb, and checking all the files listed in it exist,
and are of the right type ( cat CONTENTS | tr "\n" "\0" | xargs -iSTR
-0 file STR ), and arn't symlinks that don't go anywhere, you know,
the usual sort of bugs that flare up as a result of user interaction
;))
The output of those checks are still going to be want to be read and
interpreted by a human, but the more you know of a situation, the more
you have to find the bug with.
--
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil [EMAIL PROTECTED]"[(2*x)..(2*x+1)]}'
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] automated extended information gathering
On Sunday 08 July 2007, Kent Fredric wrote:
> Ok, I've re-thought some of my ideas and tried to come up with a more
> concise explanation
> with some practical example syntax. The basic concept of 'check' was
> 'this will work even if the package aint installed yet' and info was
> 'for working but bust packages only', but that can be superceded with
> a CHECKLIST and a conditional driven INFO function.
as they say, the devil is in the details ...
> pkg_getinfo(){
> if [[ installed ]]; then
> someSelfCheck;
> someSelfCheck;
> echo someversionNumberStuff;
> fi
> someBasicSystemCheckRequiredForPkgToWork();
> if [[ someCondition ]]; then
> get_info( some-cat/d-lib ); # its not on the dep list, but we want
> to check its info status as part of /our/ info status.
> fi
> }
the claim i'm making is that there generally isnt any code/checks worth adding
to ebuilds that would be useful for the purpose of an ebuild diagnosing
itself to determine whether it is broken and how it is broken. we just dont
have a language yet to properly describe the process of diagnosing and fixing
oneself. a fun thesis for an AI doctorate :p
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] automated extended information gathering
On 7/8/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
On Saturday 07 July 2007, Kent Fredric wrote:
> On 7/8/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > On Saturday 07 July 2007, Kent Fredric wrote:
> > > Implementation details wise, I would like to see packages have
> > > possibly 2 functions,
> > > 1: Info, and 2: Check.
> > > Reason Being that you wont be able to fetch installation status info
> > > on a package thats not installed, and if a package is failing to
> > > install, you're more likely wanting to check the status of the things
> > > it depends on, not the package itself.
> >
> > i dont really understand what you're going for here ... the point was to
> > get extended information on things that are installed ... i dont know
> > what you'd want/expect for trying to query packages that arent installed
> >
> > > Check would contain manual tests for a given package, thats either
> > > installed or not installed ,as well as names of packages to run info
> > > on.
> > >
> > > Info would be more usefull in diagnosing mis-installed packages or
> > > packages that failed to run properly despite being compiled and
> > > installed without a hitch ( it happens )
> >
> > sounds like you're duplicating the point of src_test() but without any
> > real way of quantifying it or making it useful to coordinate things ...
> > please expound on what you're going for because i'm just not seeing it
> > ...
>
> 50% of bugs I tend to see are compile failures.
>
> Compile Failures are often a result of things that the compile was
> dependant on.
>
> Thus, finding info on a given package to understand what its problem
> is, you should be info-querying its dependants, not the package
> itself, no?
>
> Information you want sent to bug reports are related to the software
> that it depended on, no? ( ie: xine-libs wont compile : emerge --info
> xine-libs should report information on ffmpeg, which has changed,
> causing the failure )
>
> And if xine libs wasnt installed, it would be pointless to report
> information about xine-libs installation when its not installed
> becasue it cant be ;)
>
> So instead of asking the user what version of X dependant they have,
> emerge --info atom should report that in a standardised way, making
> them able to provide more relevant information in the initial report
so you're asking for `emerge --info ` to walk the dependency tree and
include --info for all things that depends on ? how is this relevant
to the check() function you proposed ?
Ok, I've re-thought some of my ideas and tried to come up with a more
concise explanation
with some practical example syntax. The basic concept of 'check' was
'this will work even if the package aint installed yet' and info was
'for working but bust packages only', but that can be superceded with
a CHECKLIST and a conditional driven INFO function.
CHECKLIST="
a? ( some-cat/a-lib )
b? ( some-cat/b-lib )
"
That would make building a checklist for lazy people as simple as
CHECKLIST="${RDEPEND}"
pkg_getinfo(){
if [[ installed ]]; then
someSelfCheck;
someSelfCheck;
echo someversionNumberStuff;
fi
someBasicSystemCheckRequiredForPkgToWork();
if [[ someCondition ]]; then
get_info( some-cat/d-lib ); # its not on the dep list, but we want
to check its info status as part of /our/ info status.
fi
}
in this case:
emerge --info Pkg
--> pkg_getinfo();
--> foreach( $ChecklistItem )
> pkg_getinfo()
That way if somethings installed but merely bust, you get all the
useful information,
and if it wont install, you still get the useful information as to why
you are trying to install package X which depends on package Y which is
broken ... i dont think it's possible/feasible to have ebuilds try and
diagnosis itself automatically to figure out *how* exactly package Y is
broken ... if it were possible, we'd be able to write self-healing ebuilds
-mike
--
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil [EMAIL PROTECTED]"[(2*x)..(2*x+1)]}'
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Script for easier stabilising of ebuilds
Hi devs,
my fingers were tired of typing the same things over and
over again when I stabilised an ebuild. So I wrote the
attached script which should take away the work.
Now I only have to attach the bug-number and optionally an
ebuild with atom version. If there is no second argument,
the script tries to resolve the wanted ebuild from the bugs'
summary (like app-portage/gatt-svn does). The script also
makes use of www-client/pybugz for an appropriate
bug-comment and removing the given arch from the bug. It
can also close the bug, if you see that no other arch is
listed as Assignee or on CC.
It might also be possible that you can use the script for
mass-stabilisation in a for-loop, but I did not test that
case yet. Probably that's a nice extension for a future
version, where you can attach a list of ebuilds, which
should be stabilised.
Comments are welcome!
Regards, Lars
--
Lars Weiler <[EMAIL PROTECTED]> +49-171-1963258
Instant Messaging : [EMAIL PROTECTED]
Gentoo Linux PowerPC : Developer
Gentoo Infrastructure : CVS Administrator
#!/bin/bash
#
# Stabilise an ebuild in cvs with a bug-number and ebuild-atom given
# Version: 1.0
#
#Copyright (C) 2007 Lars Weiler <[EMAIL PROTECTED]>
#
#This program is free software; you can redistribute it and/or modify
#it under the terms of the GNU General Public License as published by
#the Free Software Foundation; version 2 of the License.
#
#This program is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU General Public License for more details.
#
#You should have received a copy of the GNU General Public License
#along with this program; if not, write to the Free Software
#Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
#
# Thanks to
# Aron Griffis for his rc()-function
# Robin H. Johnson for his earch-script
# kojiro on IRC for the ebuild with Atom Version regexp
# Options can alse be hardcoded in this script
CVSDIR=""
ARCH=""
BUGZ_USER=""
BUGZ_PASSWORD=""
PATH=/usr/local/bin:/usr/bin:/bin
die() {
echo $1 > /dev/stderr
exit -1
}
print_usage() {
echo "Usage: $(basename ${0}) [-a arch] [-c cvs-dir] [-u username]"
echo " [-p password] [-y] bug-number [ebuild with Atom Version]"
echo
echo "Make an ebuild stable for a given arch and change the related
bug."
echo
echo "Options:"
echo " -aSet the architecture"
echo " -c Path to the gentoo-x86 repository"
echo " -uUser name for Bugzilla"
echo " -pPassword for Bugzilla"
echo " -q Quickrun: always choose the default answer on"
echo " questions. Useful for scripting."
}
splitpackage() {
case $1 in
section)
echo ${2%/*} ;;
name)
tmp=${2#*/}
echo ${tmp%-[0-9]*}
;;
ebuild)
echo ${2#*/} ;;
esac
}
# rc-function stolen from Aron Griffis in
http://archives.gentoo.org/gentoo-dev/msg_122004.xml
rc() {
declare msg
if [[ -n $* ]]; then
msg="$*"
echo "* Using msg from command-line" >&2
else
msg=$(perl &2
return 1
fi
echo "* Parsed msg from ChangeLog" >&2
fi
echo "--" >&2
echo "$msg" >&2
echo "--" >&2
repoman commit -m "$msg" || return 1
if [[ -x /usr/bin/eviewcvs ]]; then
local f entry=$(perl -00ne '/^ \d/ and print, last' ChangeLog)
entry=${entry%%:*}
entry=${entry##*>}
entry=${entry//,/ }
for f in $entry; do
[[ $f == -* ]] && continue
f=${f#+}
echo "$f"
done | xargs -n1 eviewcvs
fi
}
### main routine ###
# get the arguments
while getopts "a:c:u:p:yh" OPTION
do
case "${OPTION}" in
a) ARCH="$OPTARG" ;;
c) CVSDIR="$OPTARG" ;;
u) BUGZ_USERNAME="$OPTARG" ;;
p) BUGZ_PASSWORD="$OPTARG" ;;
q) quickrun="y" ;;
h) print_usage; exit 0 ;;
esac
done
shift $((OPTIND -1))
if [[ $# -lt 1 ]]; then
print_usage
die
fi
# check if we have an arch given
if [[ -z "$ARCH" ]]; then
print_usage
die "Please set your arch."
fi
# check for the CVSDIR
if [[ -z "$CVSDIR" ]]; then
print_usage
die "Please set the path to your gentoo-x86 repository."
fi
# check the bug-number
case ${1} in
*[!0-9]*|"")
print_usage
die "Argument 1 must be a bug-number."
;;
esac
bugz_number=${1}
# without pybugz, a second argument is mandatory
if [[ -x /usr/bin/bugz ]]; then
bugz=y
bugz_info=$(bugz get ${bugz_number} -n)
echo "${bugz_info}"
if [[ $
Re: [gentoo-dev] Inotify and (f)crontabs
On Sunday 08 July 2007, Ryan Reich wrote: > On 7/7/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Saturday 07 July 2007, Peter Gordon wrote: > > > On Sat, 2007-07-07 at 04:23 -0400, Mike Frysinger wrote: > > > > you missed a critical aspect: offline time. the way run-crons is > > > > implemented, if you happen to routinely shut your machine off at the > > > > time that the cronjob is supposed to fire, then the standard you > > > > proposed will pretty much never fire. the run-crons implementation > > > > however has a pretty good guarantee that the periodic crons will get > > > > fired at the next uptime opportunity. > > > > > > Isn't this perfectly what anacron is intended for? > > > > yes and no ... anacron is designed with this issue in mind, but as the > > homepage of anacron explains, it does not replace the normal cron > > functionality and as such cannot be used on its own > > I have to disagree in this particular case. The anacron homepage, > anacron.sourceforge.net, gives this exact situation as its primary > example of what anacron is intended for. Sure, it's not good for > handling more complex scheduling, but it seems to do what run-crons > tries to do: run jobs that should have been executed while the > computer was off, as soon as it comes back on. Am I missing something > subtle? run-crons transparently gives all crons this behavior with very little overhead rather than making every user set up a dual system: a standard cron and anacron. run-crons is a default helper for crons that just works. if you want to not use it but opt for anacron instead, nothing is stopping you from doing exactly that. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Inotify and (f)crontabs
On 7/7/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: On Saturday 07 July 2007, Peter Gordon wrote: > On Sat, 2007-07-07 at 04:23 -0400, Mike Frysinger wrote: > > you missed a critical aspect: offline time. the way run-crons is > > implemented, if you happen to routinely shut your machine off at the time > > that the cronjob is supposed to fire, then the standard you proposed will > > pretty much never fire. the run-crons implementation however has a > > pretty good guarantee that the periodic crons will get fired at the next > > uptime opportunity. > > Isn't this perfectly what anacron is intended for? yes and no ... anacron is designed with this issue in mind, but as the homepage of anacron explains, it does not replace the normal cron functionality and as such cannot be used on its own I have to disagree in this particular case. The anacron homepage, anacron.sourceforge.net, gives this exact situation as its primary example of what anacron is intended for. Sure, it's not good for handling more complex scheduling, but it seems to do what run-crons tries to do: run jobs that should have been executed while the computer was off, as soon as it comes back on. Am I missing something subtle? -- Ryan Reich -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] automated extended information gathering
On Saturday 07 July 2007, Kent Fredric wrote: > On 7/8/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Saturday 07 July 2007, Kent Fredric wrote: > > > Implementation details wise, I would like to see packages have > > > possibly 2 functions, > > > 1: Info, and 2: Check. > > > Reason Being that you wont be able to fetch installation status info > > > on a package thats not installed, and if a package is failing to > > > install, you're more likely wanting to check the status of the things > > > it depends on, not the package itself. > > > > i dont really understand what you're going for here ... the point was to > > get extended information on things that are installed ... i dont know > > what you'd want/expect for trying to query packages that arent installed > > > > > Check would contain manual tests for a given package, thats either > > > installed or not installed ,as well as names of packages to run info > > > on. > > > > > > Info would be more usefull in diagnosing mis-installed packages or > > > packages that failed to run properly despite being compiled and > > > installed without a hitch ( it happens ) > > > > sounds like you're duplicating the point of src_test() but without any > > real way of quantifying it or making it useful to coordinate things ... > > please expound on what you're going for because i'm just not seeing it > > ... > > 50% of bugs I tend to see are compile failures. > > Compile Failures are often a result of things that the compile was > dependant on. > > Thus, finding info on a given package to understand what its problem > is, you should be info-querying its dependants, not the package > itself, no? > > Information you want sent to bug reports are related to the software > that it depended on, no? ( ie: xine-libs wont compile : emerge --info > xine-libs should report information on ffmpeg, which has changed, > causing the failure ) > > And if xine libs wasnt installed, it would be pointless to report > information about xine-libs installation when its not installed > becasue it cant be ;) > > So instead of asking the user what version of X dependant they have, > emerge --info atom should report that in a standardised way, making > them able to provide more relevant information in the initial report so you're asking for `emerge --info ` to walk the dependency tree and include --info for all things that depends on ? how is this relevant to the check() function you proposed ? you are trying to install package X which depends on package Y which is broken ... i dont think it's possible/feasible to have ebuilds try and diagnosis itself automatically to figure out *how* exactly package Y is broken ... if it were possible, we'd be able to write self-healing ebuilds -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: John Jawed & Alex Tarkovsky's einput eclass
Rémi Cardona wrote: > Could you list the packages which could use this? Because if only 3 pkgs > need it, it might not be worth the hassle to add it. /usr/portage $ grep -lR 'GAMES_CHECK_LICENSE="yes"' *games*|wc -l 40 I'm ofc not including fetch-restricted which also require interaction, although that is standardised enough for a script to deal with[1]. Having found this for games, I can deal with that too ofc, but I still think the idea has merit. Consider, for example, a package with separate licenses for parts, some of which the user may be happy with, others not. ATM the only way to do that is with split ebuilds, aiui. > As you pointed it out, ebuilds should not be interactive. Imho, adding > an eclass to encourage it is counter-productive. > Wow a humble gentoo dev! /me gets up off floor ;) I understand that games are a `special case', but why not make it a RESTRICT=interact which would automatically mean repoman would not allow the package into stable, and admins could easily weed such packages out? That way any category could use the same thing for packages with more restrictive licenses. (I'm not suggesting this should be merged with fetch-restricted as I accept that some stable Java packages have this set, and there's zero benefit in changing them.) So yeah I guess it's encouragement, but if the policy is such packages can never hit stable, where's the harm? A user has to explicitly allow such a package (or run unstable in which case they will be used to dealing with glitches ;) and scripts can still avoid interactive packages. (And bear in mind, it's not just uis we're talking about, but stuff like QA automation.) My 2p. [Apologies to older devs if this is a rehashed discussion.. Ignore Thread in Kontact is fantastic ;p Besides, circumstances _change_. All it comes down it to is: A) how useful is it? and B) how tough is it to implement? The rest of it's horsesh1t imnsho. C) who will implement? is usually whichever idiot came up with it ;) (see the original thread for an example of how this list /could/ *work*.)] [1] http://forums.gentoo.org/viewtopic-t-546828.html There'll be a new one out in a few days with a really nice --sync interface; and no hanging on game installs :D -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] automated extended information gathering
On 7/8/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
On Saturday 07 July 2007, Kent Fredric wrote:
> Implementation details wise, I would like to see packages have
> possibly 2 functions,
> 1: Info, and 2: Check.
> Reason Being that you wont be able to fetch installation status info
> on a package thats not installed, and if a package is failing to
> install, you're more likely wanting to check the status of the things
> it depends on, not the package itself.
i dont really understand what you're going for here ... the point was to get
extended information on things that are installed ... i dont know what you'd
want/expect for trying to query packages that arent installed
> Check would contain manual tests for a given package, thats either
> installed or not installed ,as well as names of packages to run info
> on.
>
> Info would be more usefull in diagnosing mis-installed packages or
> packages that failed to run properly despite being compiled and
> installed without a hitch ( it happens )
sounds like you're duplicating the point of src_test() but without any real
way of quantifying it or making it useful to coordinate things ... please
expound on what you're going for because i'm just not seeing it ...
-mike
50% of bugs I tend to see are compile failures.
Compile Failures are often a result of things that the compile was dependant on.
Thus, finding info on a given package to understand what its problem
is, you should be info-querying its dependants, not the package
itself, no?
Information you want sent to bug reports are related to the software
that it depended on, no? ( ie: xine-libs wont compile : emerge --info
xine-libs should report information on ffmpeg, which has changed,
causing the failure )
And if xine libs wasnt installed, it would be pointless to report
information about xine-libs installation when its not installed
becasue it cant be ;)
So instead of asking the user what version of X dependant they have,
emerge --info atom should report that in a standardised way, making
them able to provide more relevant information in the initial report
--
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil [EMAIL PROTECTED]"[(2*x)..(2*x+1)]}'
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Inotify and (f)crontabs
On Saturday 07 July 2007, Peter Gordon wrote: > On Sat, 2007-07-07 at 04:23 -0400, Mike Frysinger wrote: > > you missed a critical aspect: offline time. the way run-crons is > > implemented, if you happen to routinely shut your machine off at the time > > that the cronjob is supposed to fire, then the standard you proposed will > > pretty much never fire. the run-crons implementation however has a > > pretty good guarantee that the periodic crons will get fired at the next > > uptime opportunity. > > Isn't this perfectly what anacron is intended for? yes and no ... anacron is designed with this issue in mind, but as the homepage of anacron explains, it does not replace the normal cron functionality and as such cannot be used on its own -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] automated extended information gathering
On Saturday 07 July 2007, Kent Fredric wrote: > Implementation details wise, I would like to see packages have > possibly 2 functions, > 1: Info, and 2: Check. > Reason Being that you wont be able to fetch installation status info > on a package thats not installed, and if a package is failing to > install, you're more likely wanting to check the status of the things > it depends on, not the package itself. i dont really understand what you're going for here ... the point was to get extended information on things that are installed ... i dont know what you'd want/expect for trying to query packages that arent installed > Check would contain manual tests for a given package, thats either > installed or not installed ,as well as names of packages to run info > on. > > Info would be more usefull in diagnosing mis-installed packages or > packages that failed to run properly despite being compiled and > installed without a hitch ( it happens ) sounds like you're duplicating the point of src_test() but without any real way of quantifying it or making it useful to coordinate things ... please expound on what you're going for because i'm just not seeing it ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] automated extended information gathering
On 7/8/07, Kevin Lacquement <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
>
> 5) considering 3), I'd rather see such information be specified by
> ebuilds somehow, not a global file (think about overlays). Maybe by
> installing a script in a specific location or so.
>
> Marius
How about adding another function to the ebuild format? pkg_getinfo()?
Kevin
Implementation details wise, I would like to see packages have
possibly 2 functions,
1: Info, and 2: Check.
Reason Being that you wont be able to fetch installation status info
on a package thats not installed, and if a package is failing to
install, you're more likely wanting to check the status of the things
it depends on, not the package itself.
Check would contain manual tests for a given package, thats either
installed or not installed ,as well as names of packages to run info
on.
Info would be more usefull in diagnosing mis-installed packages or
packages that failed to run properly despite being compiled and
installed without a hitch ( it happens )
( These could even be good enough to help the user self-diagnose the
problem, a feature I consider wonderfully intuitive and not in any
other distribution yet ;) )
pkg_check()
{
if ( uses blah )
{
some_basic_check();
pkg_getinfo_installed( x11-wm/blah );
}
}
I may be on to a good thing, I may be retarded, but I'd rather
provide something that could be a potentially good thing with the risk
of being retarded than to have hidden that good thing. ;)
--
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil [EMAIL PROTECTED]"[(2*x)..(2*x+1)]}'
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: automated extended information gathering
Mike Frysinger <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 07 Jul 2007 19:41:37 -0400: > On Saturday 07 July 2007, Kevin Lacquement wrote: >> >> How about adding another function to the ebuild format? pkg_getinfo()? > > that trumps everything i got ;) It's pretty intuitive as well. So much so that on initial read, that's what I thought you were suggesting originally. Should be pretty easy for users to figure out, and it could be mentioned (as is emerge --info) right in bugzilla, too. I'd suggest a bugzy bug to that effect as soon as the feature is in portage. -- 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] automated extended information gathering
On Saturday 07 July 2007, Kevin Lacquement wrote: > Marius Mauch wrote: > > 5) considering 3), I'd rather see such information be specified by > > ebuilds somehow, not a global file (think about overlays). Maybe by > > installing a script in a specific location or so. > > How about adding another function to the ebuild format? pkg_getinfo()? that trumps everything i got ;) -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] automated extended information gathering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: > > 5) considering 3), I'd rather see such information be specified by > ebuilds somehow, not a global file (think about overlays). Maybe by > installing a script in a specific location or so. > > Marius How about adding another function to the ebuild format? pkg_getinfo()? Kevin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGkCDCr4p8oOjnnKARAojFAJ0duN7Ur5wmf8e770AztJip7nxPngCgg5yH Fqtd2iL+ourVZM+uMTP9SMY= =ShqV -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] automated extended information gathering
On Sat, 7 Jul 2007 17:43:44 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > often times when i get a bug report about certain packages, there's > information about that package that i usually ask for ... i wonder if > this can be automated > > perhaps extend the syntax of profiles/info_pkgs: > [command to pass to system()] > sys-libs/glibc /lib/libc.so.6 > > then when people run `emerge --verbose --info`, for every atom > matched as installed, it'd automatically run the listed command and > display the output > > useful ? security issue waiting to explode ? crazy wacky monkey ? I see several problems with that approach: 1) adding a secondary purpose to info_pkgs, history has shown that we should avoid such things (think packages file) 2) as a consequence of 1), I assume people would add packages to info_pkgs only for the new purpose, cluttering regular --info output with irrelevant information 3) sounds more like something that should only trigger in `emerge --info foo` 4) likely not backwards compatible 5) considering 3), I'd rather see such information be specified by ebuilds somehow, not a global file (think about overlays). Maybe by installing a script in a specific location or so. Marius -- Marius Mauch <[EMAIL PROTECTED]> -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] automated extended information gathering
Mike Frysinger kirjoitti: > often times when i get a bug report about certain packages, there's > information about that package that i usually ask for ... i wonder if this > can be automated > > perhaps extend the syntax of profiles/info_pkgs: > [command to pass to system()] > sys-libs/glibc /lib/libc.so.6 > > then when people run `emerge --verbose --info`, for every atom matched as > installed, it'd automatically run the listed command and display the output > > useful ? security issue waiting to explode ? crazy wacky monkey ? > -mike Or a new bug wizard that gives you a list of packages and and asks extra info based on that. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] automated extended information gathering
often times when i get a bug report about certain packages, there's information about that package that i usually ask for ... i wonder if this can be automated perhaps extend the syntax of profiles/info_pkgs: [command to pass to system()] sys-libs/glibc /lib/libc.so.6 then when people run `emerge --verbose --info`, for every atom matched as installed, it'd automatically run the listed command and display the output useful ? security issue waiting to explode ? crazy wacky monkey ? -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Watch out for license changes to GPL-3.
Ah it's not the actual ebuild's fault it's the site's fault as per according to https://bugs.gentoo.org/182943 ;) hopefully someone will get on that. -Kalidarn On Sat, 2007-07-07 at 21:35 +0300, Petteri Räty wrote: > David kirjoitti: > > Hi, > > > > Was suggested I make a post on the mailing list in addition to lodging > > bug https://bugs.gentoo.org/184522 > > > > Don't know why you were suggested it but any way yes everyone should be > on the lookout for license changes. > > Regards, > Petteri > > signature.asc Description: This is a digitally signed message part
[gentoo-dev] Watch out for license changes to GPL-3.
David kirjoitti: > Hi, > > Was suggested I make a post on the mailing list in addition to lodging > bug https://bugs.gentoo.org/184522 > Don't know why you were suggested it but any way yes everyone should be on the lookout for license changes. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] app-arch/cpio-2.9 is now GPLv3
Hi, Was suggested I make a post on the mailing list in addition to lodging bug https://bugs.gentoo.org/184522 According to the website http://www.gnu.org/software/cpio/cpio.html CPIO 2.9 as of 2007-06-28 is now licensed under GPLv3. -Kalidarn signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Inotify and (f)crontabs
On Sat, 2007-07-07 at 04:23 -0400, Mike Frysinger wrote: > you missed a critical aspect: offline time. the way run-crons is > implemented, > if you happen to routinely shut your machine off at the time that the cronjob > is supposed to fire, then the standard you proposed will pretty much never > fire. the run-crons implementation however has a pretty good guarantee that > the periodic crons will get fired at the next uptime opportunity. Isn't this perfectly what anacron is intended for? -- Peter Gordon (codergeek42) Gentoo Forums Global Moderator GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] Inotify and (f)crontabs
On 7/7/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
On Sunday 01 July 2007, Ryan Reich wrote:
> This is a small essay on Gentoo's setup for fcron.
which is troublesome because some of the things here are specific to fcron
(which frankly dont interest me) while others are specific to the cronbase
package which installs `run-crons` (which does interest me as it is a
Gentooism) ... i'll try to pick out only the relevant pieces as you said
yourself, the fcron things should go upstream.
I'm sorry you don't care about my fcron criticisms, but that's the
cron I use so it's the one I picked on. The problems with
check_system_crontabs were only half the point, anyway.
> 2. is implmented by putting the following rules in /etc/crontab:
> 0 * * * * rm -f /var/spool/cron/lastrun/cron.hourly
> 1 3 * * * rm -f /var/spool/cron/lastrun/cron.daily
> 15 4 * * 6 rm -f /var/spool/cron/lastrun/cron.weekly
> 30 5 1 * * rm -f /var/spool/cron/lastrun/cron.monthly
> */10 * * * * /usr/bin/test -x /usr/sbin/run-crons &&
> /usr/sbin/run-crons
> whose effect is, at intevals of one hour, day, week, and month, to
> remove some state files for the script run-crons, and also to run said
> script every ten minutes. The purpose of run-crons is to run the
> scripts in /etc/cron.{hourly,...} at the appropriate intervals, thus
> saving me the effort of adding a lot of lines looking like
> 1 3 * * * * some-command
> to my crontab.
you missed a critical aspect: offline time. the way run-crons is implemented,
if you happen to routinely shut your machine off at the time that the cronjob
is supposed to fire, then the standard you proposed will pretty much never
fire. the run-crons implementation however has a pretty good guarantee that
the periodic crons will get fired at the next uptime opportunity.
This point is where your uninterest in fcron puts us at odds. See,
fcron allows you to have such commands run at boot, and allows you to
schedule commands that run at periods of uptime rather than wall time,
so this is not an issue for fcron. And for other crons, there exists
anacron, which is recommended precisely for this purpose by Gentoo.
The only thing that's accomplished by putting this functionality in
run-crons is to duplicate it, awkwardly.
> Furthermore, the files /var/spool/cron/lastrun/cron.* are
> ALREADY handled in the run-crons script itself, so that most of the
> above commands would seem to be redundant.
this is most likely true.
> This one also has the
> additional unpleasant property of filling the logs with useless
> messages:
> [fcron] Job /usr/bin/test -x /usr/sbin/run-crons &&
> /usr/sbin/run-crons started for user
> systab
yes, this sucks, but so it goes.
So if it sucks, you would approve of an alternative that doesn't
exhibit this behavior?
--
Ryan Reich
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: Inotify and (f)crontabs
On 7/6/07, Steve Long <[EMAIL PROTECTED]> wrote:
Ryan Reich wrote:
>
> If there's interest in incorporating this, I wouldn't mind testing my
> idea. Once I get past the initial resistance to doing anything at
> all, it's probably two minutes' compilation time plus two more writing
> the config files to set up.
>
I think I should point out that comments like that really get people's backs
up; if it's so quick and easy why didn't you implement it first and then
ask for comments on a working project? If you only wanted discussion then
cool, you got it ;)
Please do post a follow up with a link to the working code.
(BTW my 5 minute projects always take weeks.. ;)
I don't know if I got anyone else's back up with this, but you got
mine up with your letter :) So I wrote an ebuild for incron (though I
notice that there's an extremely minimal one pending on
bugs.gentoo.org). It includes, in addition to the actual ebuild file,
a boot script, an incrontab similar to the one I conceptualized in one
of my earlier letters, and a little script that handles files in
/etc/cron.{hourly,...}. I've tested it on my machine (indeed, I'm
running it now) and it does work. Basically, the incrontab (called
"fcrontabs" and which goes in /etc/incron.d) runs my little script to
generate a one-line fcrontab which it puts in /etc/cron, whenever it
sees something change in one of the cron.timely directories; the
one-liner just runs the script which changed. It also makes
check_system_crontabs the responsibility of incrond. The net result
is that adding anything to any /etc/cron.timely/ results in a periodic
fcron job, like
@ 1d makewhatis -u
being added to the fcrontab for "systab" immediately. The contents of
/etc/crontab and /etc/fcrontab are redundant under this scheme and the
files should be emptied if this is used.
I've tarred and bzipped the whole ebuild directory and attached it;
it's only four kilobytes so I hope no one minds (this letter is
probably longer). I don't know where the correct forum to submit this
sort of thing for comment is, so if this isn't it I'd be happy to take
it somewhere else. But I thought anyone following this discussion
would like to see it here.
--
Ryan Reich
incron-ebuild.tar.bz2
Description: BZip2 compressed data
Re: [gentoo-dev] Non-new developer: Tobias Heinlein (keytoaster)
Denis Dupeyron wrote: > So please, everybody, give a warm non-welcome to Tobias. Happy break^Whacking! lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] John Jawed & Alex Tarkovsky's einput eclass
Steve Long wrote: > Hi, > A link on bugzilla somehow led me (isn't the web wonderful ;) to this: > http://thread.gmane.org/gmane.linux.gentoo.devel/40596 > which appears (to a user) like a really good idea. There is a version still > at: http://jawed.name/dev/gentoo/einput.eclass > > A search at: http://dir.gmane.org/gmane.linux.gentoo.devel > found only that thread, nor could I find anything on bugzilla. I was just > wondering what became of the idea? > I appreciate that stable ebuilds aren't supposed to be interactive, but > this would be nice, eg for games, imo. Could you list the packages which could use this? Because if only 3 pkgs need it, it might not be worth the hassle to add it. As you pointed it out, ebuilds should not be interactive. Imho, adding an eclass to encourage it is counter-productive. My 0.02€ :) Cheers Rémi -- [EMAIL PROTECTED] mailing list
[gentoo-dev] John Jawed & Alex Tarkovsky's einput eclass
Hi, A link on bugzilla somehow led me (isn't the web wonderful ;) to this: http://thread.gmane.org/gmane.linux.gentoo.devel/40596 which appears (to a user) like a really good idea. There is a version still at: http://jawed.name/dev/gentoo/einput.eclass A search at: http://dir.gmane.org/gmane.linux.gentoo.devel found only that thread, nor could I find anything on bugzilla. I was just wondering what became of the idea? I appreciate that stable ebuilds aren't supposed to be interactive, but this would be nice, eg for games, imo. Regards, steveL. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Non-new developer: Tobias Heinlein (keytoaster)
Denis Dupeyron wrote: > Tobias tells us his hobbies were computers, programming, reading, > meeting friends, and sleeping. Which means it's now down to computers > and programming only. > > So please, everybody, give a warm non-welcome to Tobias. Congrats! :) Und mach nix kaputt :P Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[gentoo-dev] Re: Non-new developer: Tobias Heinlein (keytoaster)
Denis Dupeyron schrieb: > So please, everybody, give a warm non-welcome to Tobias. /me adds him to the dark lords list, also known as the evil german conspiracy Congrats to your upgrade :) -Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] glibc-2.6 / gcc-4.2 going into ~arch
On Friday 06 July 2007 06:08:43 Mike Frysinger wrote: > get your "waaait dont do it" votes in now, i plan on pushing: > glibc-2.6 ~amd64 ~ppc ~ppc64 ~x86 > gcc-4.2.0 ~amd64 ~x86 > in the next day or so > -mike As Adam already pointed/asked earlier, are we going to see Kevin's work being merged with gcc-4.2 ? Or are we ever going to see hardened supoprt for gcc-4 ? I really appreciate your effort on doing gcc (and the whole lotta of other things you maintain), but we're (as in the hardened folks) getting rather impatient. It's been sitting on your plate for about a month (or is it two ?). If you can't do it yourself, please tell us. I think we have the resources to merge it into the tree ourselves. Thanks and kind regards, Christian -- Christian Heim GPG key ID: 9A9F68E6 Fingerprint: AEC4 87B8 32B8 4922 B3A9 DF79 CAE3 556F 9A9F 68E6 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last rites: media-gfx/bootsplash
Alon Bar-Lev napsal(a): > On 7/7/07, Rémi Cardona <[EMAIL PROTECTED]> wrote: >> Try using vesafb-tng (I know it doesn't support some resolutions either) >> but interactions between vesafb-tng and the intel X driver are _much_ >> better. > > Does not work either. > There is a memory conflict between the X space and vesa. > I basically think that users (As advanced Gentoo user can be) cannot > have a workable environment in a reasonable effort... I know I have > failed. vesafb-tng works just perfectly fine here w/ nVidia/ATI/Intel. You are doing something weird. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: media-gfx/bootsplash
On 7/7/07, Roy Marples <[EMAIL PROTECTED]> wrote: The whole thing is moot anyway as baselayout-2 now uses C plugins for hooks like splash. So unless you or someone else steps up to the plate and write a baselayout-2 plugin for bootsplash there will be a point where it will stop working. I don't use bootsplash either... If I get this correctly, since both bootsplash and fbsplash are framebuffer users, there is no much different between them... It is fine to drop boosplash support. But both is unworkable for many users. Alon. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites: media-gfx/bootsplash
On Sat, 7 Jul 2007 11:38:14 +0300 "Alon Bar-Lev" <[EMAIL PROTECTED]> wrote: > We need to provide simper and workable solution. The whole thing is moot anyway as baselayout-2 now uses C plugins for hooks like splash. So unless you or someone else steps up to the plate and write a baselayout-2 plugin for bootsplash there will be a point where it will stop working. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites: media-gfx/bootsplash
On 7/7/07, Rémi Cardona <[EMAIL PROTECTED]> wrote: Try using vesafb-tng (I know it doesn't support some resolutions either) but interactions between vesafb-tng and the intel X driver are _much_ better. Does not work either. There is a memory conflict between the X space and vesa. I basically think that users (As advanced Gentoo user can be) cannot have a workable environment in a reasonable effort... I know I have failed. We need to provide simper and workable solution. Alon. ��í¢^����(� ��X��X�
[gentoo-dev] It's Bugday!
Hi, Don't forget that today is Bugday, so come along, and join the fun! For those of you who don't know, Bugday is a great opportunity for users to start fixing bugs, as well as testing bugfixes submitted by other users (and getting/giving help in the process). Feel free to join in by joining #gentoo-bugs on irc.freenode.net More information can be found at the following links: http://bugday.gentoo.org/ http://www.gentoo.org/proj/en/bugday/index.xml Thanks, welp signature.asc Description: PGP signature
Re: [gentoo-dev] Re: glibc-2.6 / gcc-4.2 going into ~arch
On Fri, 2007-07-06 at 19:44 -0600, Ryan Hill wrote: > BTW, the GCC 4.2 porting tracker is bug #162167. If you find any > crazyass bugs, please block the tracker bug. Openoffice team, you may > want to examine the patch in bug #184054. This is fixed now. bye Andreas -- Andreas Proschofsky Gentoo Developer / OpenOffice.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: media-gfx/bootsplash
Alon Bar-Lev wrote: > i915, even if splash gets working X does not. > A lot of issues there. intelfb is terribly broken : it explicitly doesn't work on laptop LCD displays, it doesn't support all the funky resolutions DVI or VGA displays have nowadays. Basically, it's nearly useless. Try using vesafb-tng (I know it doesn't support some resolutions either) but interactions between vesafb-tng and the intel X driver are _much_ better. As for loading X very early in the boot process, this is a long debate, but it's being worked on by X folks, I suggest you look at the general xorg mailing list over at freedesktop for more info. Cheers, Rémi -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Inotify and (f)crontabs
On Sunday 01 July 2007, Ryan Reich wrote:
> This is a small essay on Gentoo's setup for fcron.
which is troublesome because some of the things here are specific to fcron
(which frankly dont interest me) while others are specific to the cronbase
package which installs `run-crons` (which does interest me as it is a
Gentooism) ... i'll try to pick out only the relevant pieces as you said
yourself, the fcron things should go upstream.
> 2. is implmented by putting the following rules in /etc/crontab:
> 0 * * * * rm -f /var/spool/cron/lastrun/cron.hourly
> 1 3 * * * rm -f /var/spool/cron/lastrun/cron.daily
> 15 4 * * 6 rm -f /var/spool/cron/lastrun/cron.weekly
> 30 5 1 * * rm -f /var/spool/cron/lastrun/cron.monthly
> */10 * * * * /usr/bin/test -x /usr/sbin/run-crons &&
> /usr/sbin/run-crons
> whose effect is, at intevals of one hour, day, week, and month, to
> remove some state files for the script run-crons, and also to run said
> script every ten minutes. The purpose of run-crons is to run the
> scripts in /etc/cron.{hourly,...} at the appropriate intervals, thus
> saving me the effort of adding a lot of lines looking like
> 1 3 * * * * some-command
> to my crontab.
you missed a critical aspect: offline time. the way run-crons is implemented,
if you happen to routinely shut your machine off at the time that the cronjob
is supposed to fire, then the standard you proposed will pretty much never
fire. the run-crons implementation however has a pretty good guarantee that
the periodic crons will get fired at the next uptime opportunity.
> Criticism:
> Both of these ideas are, in principle and in practice, inefficient and
> irritating.
> 1. Since I will only ever update my crontabs rarely, checking every
> ten minutes is likely to yield a negative result virtually 100% of the
> time; however, since one wants the system to respond quickly when a
> change is made, it is necessary to check frequently. This would seem
> to be a contradiction.
>
> 2. The problem is even worse: though it is conceivable that a real
> cron demon would be updating his crontabs willy-nilly, and thus that 1
> is not actually inefficient for him, it is not possible, even in
> principle, for 2 to be worthwhile. run-crons runs commands at
> intervals of no less than one hour, but is itself run every ten
> minutes.
these statements are incorrect as they are based on incorrect assumptions.
the point of the 10 minute cycle is not to see if anything of the cron dirs
have changed, but if any routine cronjob needs to fire (refer to my comment
above).
> Furthermore, the files /var/spool/cron/lastrun/cron.* are
> ALREADY handled in the run-crons script itself, so that most of the
> above commands would seem to be redundant.
this is most likely true.
> This one also has the
> additional unpleasant property of filling the logs with useless
> messages:
> [fcron] Job /usr/bin/test -x /usr/sbin/run-crons &&
> /usr/sbin/run-crons started for user
> systab
yes, this sucks, but so it goes.
> The reason that run-crons doesn't log is unclear to me.
there probably isnt one; file a bug with a patch if you like or just file a
bug.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc-2.6 / gcc-4.2 going into ~arch
Mike Frysinger wrote: get your "waaait dont do it" votes in now, i plan on pushing: glibc-2.6 ~amd64 ~ppc ~ppc64 ~x86 gcc-4.2.0 ~amd64 ~x86 in the next day or so -mike FYI, seems one of the R10K patches fails for mips after all (compile failure below). Probably a define that shifted and I'll have to go trace it down. So no unstable for us for now. ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a libbackend.a(options.o):(.data.rel.ro+0x4774): undefined reference to `TARGET_R10K_SPECEX' libbackend.a(options.o):(.data.rel.ro+0x4914): undefined reference to `TARGET_R10K_SPECEX' libbackend.a(options.o):(.data.rel.ro+0x4934): undefined reference to `TARGET_R10K_SPECEX' libbackend.a(mips.o): In function `check_p_pattern_for_store': mips.c:(.text+0x3520): undefined reference to `TARGET_R10K_SPECEX' libbackend.a(mips.o): In function `mips_reorg': mips.c:(.text+0x6a64): undefined reference to `TARGET_R10K_SPECEX' collect2: ld returned 1 exit status make[3]: *** [cc1-dummy] Error 1 --Kumba -- Gentoo/MIPS Team Lead "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond -- [EMAIL PROTECTED] mailing list
