e question for
> "necessary".
Re 'necessary': Tests for scientific packages are surely necessary, i'd
even claim they're mandatory. Nothing is as bad as having a program
that yields unreproducable (read: wrong) results.
Been there, seen that, had the primordial urge to kill things.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
[EMAIL PROTECTED] mailing list
ember of the sci team I have to say I completely disagree with you
here. sci-* packages mostly have reasonable test suites, the importance
to run them is very high (you do want reproducable and correct results,
don't you?). However, sometimes you cannot run those tests from an
ebuild's env
s assigned directly to me, but to the herd instead.
> > > While for others I _do_ want the duplicate.
> >
> > Could "contact" be named differently then?
>
> 'autocontact' then?
> Both 'assign' and 'cc' (and derivations the
compare
multiple suffixes there will be no problem.
This Council decission was to avoid 'existing practice' that might be
necessary to include in PMS.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
[EMAIL PROTECTED] mailing list
quot; which might need to
be respected by either PMS or tree policy.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
[EMAIL PROTECTED] mailing list
ssible?) that affects pretty much all Gentoo developers (and
> prospective developers).
Anybody who attends the regular Council meetings and/or reads their
logs/summaries knew that this kind of decission is possible.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
[EMAIL PROTECTED] mailing list
ly spoken.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
[EMAIL PROTECTED] mailing list
ymore, and I think
> it's quite easy to imagine when this additional -r1 would be
> neccessary.
I'd like to refer you that this is kind of 'best-practice' for the tree.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
[EMAIL PROTECTED] mailing list
n? Wouldn't that prevent portage from enforcing update to _rc3
> when it's delivered? Of course I might be wrong and if this is the
> case then excuse me for the whole fuss ;)
Existing _rcX cases can be handled like this:
_rc2-rYYYYMMDD
Portage will update from _rc2 to a version with re
Am Dienstag, 24. April 2007 schrieb Petteri Räty:
> Danny van Dyk kirjoitti:
> > Hi all,
> >
> > [CC'ing [EMAIL PROTECTED] as requested by GLEP amendment from March 8th,
> > 2007]
> >
> > A subset of council members decided today that multiple version
Am Dienstag, 24. April 2007 schrieb Fernando J. Pereda:
> On Tue, Apr 24, 2007 at 03:16:38PM -0400, Doug Goldstein wrote:
> > Danny van Dyk wrote:
> > > Hi all,
> > Danny,
> >
> > This wouldn't have to be because you have a vested interest in
> > p
yone has any suggestions for naming schemes in the
> meantime, I'm all ears.
Only a short response, as I'm a bit in a hurry right now. From
#gentoo-council earlier:
18:25 <@robbat2> make him covert it to "_rc%04d%04d%02d%02d",$RC,$YEAR,
$MONTH,$DAY
I hope that helps,
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
[EMAIL PROTECTED] mailing list
Am Dienstag, 24. April 2007 schrieb Doug Goldstein:
> Danny van Dyk wrote:
> > Hi all,
> >
> > [CC'ing [EMAIL PROTECTED] as requested by GLEP amendment from March 8th,
> > 2007]
> >
> > A subset of council members decided today that multiple version
Am Dienstag, 24. April 2007 schrieb Danny van Dyk:
> Hi all,
>
> [CC'ing [EMAIL PROTECTED] as requested by GLEP amendment from March 8th,
> 2007]
>
> A subset of council members decided today that multiple version
> suffixes are illegal in the tree pending further notic
scode-1.0.3_rc2_p20070310-r1
An illegal version specification of media-sound/alsa-driver has already
been removed from the tree.
I would like to ask the affected package maintainers to move these
versions to sane version specifications as soon as possible. Thanks in
advance for this.
Danny
--
Danny va
Am Sonntag, 22. April 2007 schrieb Kevin F. Quinn:
> On Sun, 22 Apr 2007 17:46:18 +0200
>
> Danny van Dyk <[EMAIL PROTECTED]> wrote:
> > Am Sonntag, 22. April 2007 schrieb Michael Cummings:
> > > On Sat, Apr 21, 2007 at 08:47:54AM +0100, Kevin F. Quinn wrote:
> &
ir ebuilds/eclasses/profiles and forget/lie about it, and still
have the same $Headers$ line.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
[EMAIL PROTECTED] mailing list
eapi=1 today, zac implements it tonight, and releases it tomorrow
> morning (with no bugs).
Very well. I'd like to target this for KDE people to use it for kde-4.
> So... again- it's not pretty, but it's not an issue that's going to
> be solved tomorrow, so it's not
for a start,
> instead of trying to make one big bump that will bring all changes we
> can think of now, but will be implemented only in 2010...
I agree fully. Nobody said we can't finetune the EAPI steps/bumps.
> Now it may look like I contradict myself saying to bump ASAP but not
&
Am Donnerstag, 5. April 2007 23:24 schrieb Brian Harring:
> On Thu, Apr 05, 2007 at 10:40:55PM +0200, Danny van Dyk wrote:
> > Am Donnerstag, 5. April 2007 20:20 schrieb Mike Doty:
> > > Torsten Veller wrote:
> > > > * Mike Doty <[EMAIL PROTECTED]>:
> > &
see.
>
> another one i had mentioned earlier:
> - a time frame on moving gentoo-core to public archives ... two
> years ? -mike
What happened to 1 year?
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
gentoo ebuild
devs*) either with lists of QA problems in the tree to fix, or with
tools that enable you to search for one particular (kind of) QA
violation in the whole tree, whatever your prefer.
Danny
*I'm only adressing gentoo devs here as patches against the whole tree
don't make sen
ike any privacy
in that at all. vapier comes to my mind there :-D
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
is FUD about forking
Gentoo. Paludis is not a fork of Gentoo, it's new package manager. The
relation between Portage and Paludis can, if at all, probably be
compared to dselect vs apt.
Don't reply to this mail, just let it drop. Thank you very much.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
should probably add a bullet point g) Hasn't looked yet.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
ly ebuild repositories.
This is what comes to my mind right now. The list is certainly not
complete :-)
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
x27; in eclasses and ebuilds.
>
> sci-mathematics/octave/octave-2.1.57-r1.ebuild:34:
> sci-mathematics/octave/octave-2.1.69.ebuild:36:
^^ fixed. Must have slipped through in my first round.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
lplot/plplot-5.5.2.ebuild:
>use fortran && ! use ifc || if [ -z 'which g77' ]; then
> ./sci-visualization/xd3d/xd3d-8.2.1.ebuild:
>which g77 2> /dev/null || die "No GNU Fortran compiler found!"
^^^ fixed, too.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
grass/grass-6.2.0-r1.ebuild:111:
> sci-geosciences/mapserver/mapserver-4.10.0.ebuild:106:
> sci-misc/boinc/boinc-4.72.20050813-r3.ebuild:56:
> sci-misc/boinc/boinc-5.2.14.ebuild:57:
> sci-misc/boinc/boinc-5.4.11.ebuild:53:
> sci-misc/boinc/boinc-5.5.6.ebuild:59:
^^^ fixed as well.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
gt; ./trunk/general-concepts/install-destinations/text.xml:"${IMAGE}"<
>/c>.
>
> Can you corrent the devmanual then?
Done.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Am Samstag, 3. März 2007 19:48 schrieb Thomas Rösner:
> Hi,
>
> Danny van Dyk schrieb:
> > 2) There are countries who acutally adhere to the Berne Convention
> > (1886). This means even the deed of commiting sources with a
> > "Copyright (C) Gentoo Foundati
> part a legal structure to protect our collective work, (code, logos,
> etc.) and would be considered a third-party project.
>
> I'd be really surprised - flabbergasted, really - if this has
> changed. But at this point I almost wouldn't be surprised. :)
Suprise! :-)
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Am Donnerstag, 22. Februar 2007 17:41 schrieb Brian Harring:
> On Thu, Feb 22, 2007 at 05:07:22PM +0100, Danny van Dyk wrote:
> > Am Donnerstag, 22. Februar 2007 14:26 schrieb Brian Harring:
> > > On Thu, Feb 22, 2007 at 04:13:11AM +, Ciaran McCreesh wrote:
> > > >
out is intended to get multiple folks
> involved who each have their own specialized domain knowledge.
>
> For example, dismissing Chris when he's effectively the "profiles
> guy". Granted, can involve him afterwards, but don't much see the
> point in *not* doing it up front.
Read again, he did not dismiss Chris, he dismissed the claim that
Infrastructure should send somebody to discuss the package manager
standard.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Am Mittwoch, 21. Februar 2007 20:10 schrieb Stephen Bennett:
> Please welcome Richard to our ranks, or accuse him of being an evil
> cabalist (he works on Paludis, particularly maintaining its Ruby
> bindings), as you see fit.
Welcome aboard Richard!
Danny
--
Danny van Dyk <[EMA
g
> reports if i remove custom-cflags use and also mplayer.
What about making custom-cflags default in the base profile?
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
27;s done, which is not now.
>
> Council- y'all were after getting this finished as far as I know,
> perhaps you could discuss intentions?
Why? There is work done on this, and there will be further work being
done. Several council member have access to it - including me - and
are quite
Am Samstag, 17. Februar 2007 00:52 schrieb Diego 'Flameeyes' Pettenò:
> On Saturday 17 February 2007, Danny van Dyk wrote:
> > a) It's _qualudis_ ;-)
>
> Whatever, can we get back on track?
>
> How much good did Google Summer of Code to the Gentoo _community_
tribute(d) to it, including
yourself ;-)
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
usually say yes,
* Mike usually says yes,
* you're aboard.
It's just that we don't have sufficient _active_ devs. :-/
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Hi,
besides a deprecated call to check_KV, matrox.eclass sets
SLOT=${KV}
which breaks the metadata cache. Any objections to change it
to
SLOT=0
anyone?
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Am Mittwoch, 8. November 2006 16:07 schrieb Kurt Lieber:
> On Mon, Nov 06, 2006 at 11:25:19PM +0100 or thereabouts, Danny van Dyk
wrote:
> > Kurt: Please write up a short text to explain why you think this is
> > necessary for Gentoo mailservers. Thanks in advance!
>
>
eciate if Kurt could write up a short text which
explains why SPF is a good thing(TM) for Gentoo Infrastructure, so I
can understand it :-)
My vote would be: Remove, unless there is a real need for it. But this
could change rather quickly once Kurt (or anybody else from Infra) has
replied.
Danny
--
Reply-To:'-munging:
I'm going to vote to keep it as is, and i don't think that anybody would
be able to convince me otherwise.
In regard to SPF: If klieber (or any other infra member) can explain to
me why SPF is a good thing(tm) to have for Gentoo Infrastructure, and
convince me t
; is (in my eyes) at
least sloppy. If it doesn't work for all sensible cases, it shouldn't
be labelled as 'works'.
> reports about paludis, would you?
This is why we discourage bugreports w/p prior contact on IRC.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
alyst, new profile
structure, planning for 2007.0
Robbin H. Johnson: tree-signing, infra (Bugzilla, anon(cvs|svn))
Danny van Dyk: AMD64 releng (testing, soon new profiles)
Kingtaco: infra(Bugzilla, anon(cvs|svn), utf8 on pecker)
Mike Frysinger:tool
nches/branch-1.0.x.
* Use only modules from branch-1.0.x when you update/bump packages in
the tree, as it will take sometime till 1.2.x will hit the tree.
Thank you for your attention :-)
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev
lt USE-flags at one spot (per profile) _is_ easier to maintain.
Ciaran has a point here: Default useflags have annoyed me in the past
while building releases, and having to change several packages (and
redigesting them) for the snapshot is way more:
* complicated
* time-consuming
* error-prone
tha
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Y}/${PN}:${SLOT}.
Yay!
> I thought we were eventually going to use that format to specify deps
> with specific USE set.
Nope, that was ${CATEGORY}/${PN}[foo].
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
ould take
some time, it should be done in a seperate repository for the time
being.
The Seeds project could do something like this:
+-Seeds
|
+-amd64-lamp, inherits releases/2006.1/amd64-hardened and adds lamp
specific useflags/packages.
But i lack knowledge here. Stuart?
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
ven't) made my time here so
> enjoyable.
Thank you very much
> So long, and thanks for all the fish...
I think you oughta know that I'm feeling very depressed :-(
Danny, who hopes to see you again next year!
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Hi all,
FYI, I just created a Bugzilla account for the Council.
You can assign/CC us on bugs via '[EMAIL PROTECTED]'.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
s mailing list. I for one don't consider it anywhere near
appropriate. This shall be no offense, just a comment in regard that
you can do better.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
that more llama action be put in GLEPS (rar?).
Senseless.
What did you want to contribute to the discussion?
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Am Mittwoch, 20. September 2006 20:56 schrieb Donnie Berkholz:
> Danny van Dyk wrote:
> > * How do you want to implement the profiles?
> >
> > * Re: the meta-ebuilds you'd been talking about in this thread:
> > Have you yet considered to use the profiles' p
net-wireless/{bcm43xx,ieee80211softmac} had been in package mask since
June, as they
* didn't work with recent kernel versions
* were moved into kernel as of 2.6.17.
* were plain obsolete.
I just removed them.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo
Just a short note:
The new council will be showing more presence in #gentoo-council.
This means: even when no meeting is taking place you can reach us all
together on IRC to discuss Gentoo development or to point out problems.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 P
non
cummultative. I'd like to keep it hardcoded, as loading of such
variables can go wrong and you'd end up without a working env tool.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
t.
Sadly we don't suspend developers for extended history of QA violations.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
ch compilation would actually succeed, you'd
still have ~8e28 seconds. The age of the universe is approximately 4e17
seconds.
This hasn't yet investigated allt he possible combinations of packages
depending on dev-lang/php, or the ~10,000 other packages in the tree.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
ere two deprecated eclasses, it
> would falsely label the new class as mod-kernels.
ECLASS_DEPRECATED="${ECLASS_DEPRECATED} foo:new-foo,new-foo-modules"
> Meanwhile; I'd just stick a file up somewhere on gentoo.org, and
> mangle repoman to pull down a copy every N days as ne
new file for that IMHO. I'd propose to add something
like
ECLASS_DEPRECATED="${ECLASS_DEPRECATED} foo"
ECLASS_REPLACEMENTS="${ECLASS_REPLACEMENT} new-foo"
to foo.eclass. In my eyes this is much less work as repoman merely has
to check for 2 envvars.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Handbook list of authors contains former
Gentoo devs.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
job'. We _could_ implement it, but none of the possible implementations
is really elegant. We considered these possibilites:
* using an external repo, that autogenerates the dep information _after
downloading all of CPAN_. (yes, that would be necessary)
* g-cpan mode of autogenerating the bu
27;t be to hard to change it from /emul to /lib32
and /usr/lib32. And yes, /emul was there from the very beginning aka
Tester/brad_mssw :-)
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
pe team.
Not to forget he's working on an eselect module for app-admin/logrotate.
Welcome aboard, Andrew!
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Am Samstag, 5. August 2006 11:19 schrieb Kevin F. Quinn:
> On Sat, 5 Aug 2006 02:39:16 +0200
>
> Danny van Dyk <[EMAIL PROTECTED]> wrote:
> > Am Samstag, 5. August 2006 02:11 schrieb Kevin F. Quinn:
> > > At the very least, ebuild maintainers and ATs should be runnin
d making FEATURES="test" a
default.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
haviour changed. Much better than
informing users of the other 4 packages that the behaviour changed.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Am Mittwoch, 12. Juli 2006 15:36 schrieb Jakub Moc:
> Danny van Dyk wrote:
>
> Wrt the pcmcia thing, well not really ebuilds' fault, see
> http://bugs.gentoo.org/show_bug.cgi?id=122868
Yeah, genstef is working on it.
> There are already bugs filed for some of the rest
Am Mittwoch, 12. Juli 2006 17:00 schrieb Aron Griffis:
> Danny van Dyk wrote: [Wed Jul 12 2006, 09:16:30AM EDT]
>
> > There are 505 ebuilds which are missing use flags in IUSE that they
> > use in other places.
Much of those 505 violations are a missing pcmcia flag, which i stop
Am Mittwoch, 12. Juli 2006 15:23 schrieb Matthias Schwarzott:
> On Wednesday 12 July 2006 15:16, Danny van Dyk wrote:
> > Hi all,
> While reading your list I have seen pcmcia often. e.g. on my ebuild
> v4l-dvb-hg not supporting pcmcia as conditional. A bit digging showed
> tha
Am Freitag, 7. Juli 2006 16:19 schrieb Diego 'Flameeyes' Pettenò:
> On Friday 07 July 2006 16:20, Danny van Dyk wrote:
> > I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree.
>
> Improvement respect the current situation? You're just asking f
feel
uncomfortable to be unable to use cpuflags in metadata phase. This is
what worries me most.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
has support for xchg16 since the very beginning.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
g
Thanks, I accept this nomination.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
maintain it.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
ny damage to applications that have not been directly
> installed from the overlay.
Only when you have FEATURES="collision-protect".
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
ny damage to applications that have not been directly
> installed from the overlay.
>
That is only true, if you have enabled FEATURES="collision-protect".
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
ny damage to applications that have not been directly
> installed from the overlay.
Only when you got FEATURES="collision-protect".
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
r an enhancement request. I'm
quite positive we can get it going. :-)
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Hi Kumba,
> In a similar vein, will this eselect tool eventually supplant the
> functionality of binutils-config as well (and thus need its own
> wrapper script)?
Have a look at eselect binutils please, which is shipped with
app-admin/eselect.
Danny
--
Danny van Dyk <[EMAIL PROTEC
this and you'll break merging of approx. 30% of the ebuild in
scientific herd. As long as there is no use-based deps, fortran should
stay in default.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
execute the new code instead.
As a member of Release Engineering who encountered already a problem
with user-management code in eutils.eclass, i beg you: _plase_
don't add it to that eclass. Instead, create a new eclass 'euser' or
something similar and add it there.
Dann
lementations are hardcoded into the modules rather than being
> autodetected from the system. This just doesn't scale well, and it
> ties upgrades and changes to BLAS/LAPACK/whatever into a required
> update of eselect.
>
> A point of disagreement between Danny van Dyk (Ku
Am Freitag, 26. Mai 2006 01:10 schrieb Danny van Dyk:
> Am Freitag, 26. Mai 2006 00:50 schrieb Panard:
> > I removed need-cmake function and add :
> >
> > if [ ! -z "${NEED_CMAKE}" ]; then
> > DEPEND="dev-util/cmake"
> > else
> >
t;
>
> is it ok ?
Rather use
DEPEND="dev-util/cmake-${NEED_CMAKE+-${NEED_CMAKE}}"
please.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
see no major difference between doing 'need-cmake x.y' and
'NEED_CMAKE x.y'...
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
in touch.
I which you all the best for whatever you'll be doing next. :-)
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
don't file bugs with gentoo. Come to
#paludis and discuss with us. If we tell you to do so, file bugs with
[EMAIL PROTECTED] We are really interested to know which packages
don't work.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Hi,
It is my pleasure to announce publicly that ian! has passed all
necessary quizzes to touch our holy gra^H^H^H portage tree.
He'll be helping mcummings in his perpetuate combat with perl and its
dependencies. May the source be with him.
Congratulations Christian! :-)
Danny
--
Dann
irith? ;-)). His current work is a research job at the
Federal University of Itajubá where he tries to build Cylons^H^H^H neural
networks. At least this is more exciting than his brother's job who's a math
professor.
bbj, welcome aboard!
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
tions!
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
stated
above.
This is how it has been handled so far except in the ciaranm incident. This is
how I personally think this should be handled in future.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Portage tree, and you're not fit to be a Gentoo dev in the first place
I would say this should be clarified some more. Surely anybody with an access
to an overlay can commit, but the projects should be the keepers of the keys.
Overlays are not the tree, they are probably very experimental.
and
swiming, watching movies and chilling with his favourite music.
Karol joined Gentoo to help with the Gentoo/OpenBSD project. I guess Flameeyes
will be happy with another slav^H^Hminio^H^H^Hhelping hand :-)
Karol, welcome aboard :-)
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo
tion "
echo
}
pkg_prepare() {
local ret=0
if use foo && use bar ; then
emutexuse foo bar
ret=1
fi
if use fnord2 && ! use fnord ; then
emissinguse fnord fnord2
ret=1
hat chokes on coding style (like tabs and whitespaces) should be
> ifself fixed.
Hmm, you never used repoman, right? repoman checks for whitespace and tab
oddities and warns you, if you want to commit them.
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
e.
Danny
- --
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFEBKe7aVNL8NrtU6IRAl75AKCT9h+9V4sM9YxRgIoaD+136dug9ACgkqoI
chBYTGNn2hEChDAi/WfV1+k=
=INNg
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
1 - 100 of 150 matches
Mail list logo
