Re: [gentoo-dev] Re: USE flag transition: tetex and latex

[Robert Buchholz]

Am 07.11.2007 um 14:09 schrieb Ferris McCormick:

On Wed, 2007-11-07 at 09:13 +0100, Alexis Ballier wrote:

Hi,

 Yes, we should introduce tex, latex and kpathsea USE flags.   
Anyone?


+1 for latex & kpathsea. How/when do we start ? :) I'd say start  
moving
useflags on a per package basis, making them local for now. Once  
there
are enough, let us move to a global one. Once this is finished,  
let us

deprecate the tetex useflag.

+0.5 for tex: it's a good idea, but I dont know about any package  
using

only tex and not latex (and where it would be optional). Perhaps I'm
wrong there.



I don't think documentation using texinfo.tex (the documentation that
comes in .texi files) uses latex --- I believe that texinfo.tex uses
just plain tex.


Do we even provide plain tex via an ebuild or useflag?
If not, why bother to differentiate?

Robert

--
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Ciaran McCreesh]

On Sat, 10 Nov 2007 01:39:18 +0100
Carsten Lohrke <[EMAIL PROTECTED]> wrote:
> Handling depends a bit upon, if EAPI should always be downwards
> compatible.

It won't be. It's likely that future EAPIs will introduce new
strictness requirements and remove certain legacy variables and
utilities.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Carsten Lohrke]

On Freitag, 9. November 2007, Petteri Räty wrote:
> What if I want to use EAPI=1 features in an eclass? So if we for example
> we have an ebuild using EAPI=2 and then it inherits and eclass that sets
> EAPI=1 for slot deps.

You check which EAPI the ebuild sets, then either continue or die. Handling 
depends a bit upon, if EAPI should always be downwards compatible. Ideally 
only unset EAPI (for trivial ebuilds) and same EAPI would be allowed 
combinations, as this would simplify doing incompatible upgrades.


Carsten


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: RFC: Place of EAPI variable in ebuild

[Petteri Räty]

Markus Ullmann kirjoitti:
>> What if I want to use EAPI=1 features in an eclass? So if we for example
>> we have an ebuild using EAPI=2 and then it inherits and eclass that sets
>> EAPI=1 for slot deps.
> 
> shouldn't be an issue as eapi 1 and 2 would have slot deps
> though for other things like src functions defined in the eclass this
> might become really interesting, especially if we get src_configure in eapi2
> 
> Greetz
> Jokey
> 

You didn't get my point. Unless inherit has some EAPI handling logic
setting EAPI in an eclass would overwrite the one in the ebuild.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: RFC: Place of EAPI variable in ebuild

[Markus Ullmann]

> What if I want to use EAPI=1 features in an eclass? So if we for example
> we have an ebuild using EAPI=2 and then it inherits and eclass that sets
> EAPI=1 for slot deps.

shouldn't be an issue as eapi 1 and 2 would have slot deps
though for other things like src functions defined in the eclass this
might become really interesting, especially if we get src_configure in eapi2

Greetz
Jokey



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Petteri Räty]

Ciaran McCreesh kirjoitti:
> On Fri, 09 Nov 2007 23:55:51 +0200
> Petteri Räty <[EMAIL PROTECTED]> wrote:
>> Usually it's best that ebuild variables follow the order that is in
>> skel.ebuild. So know we should decide where to place EAPI. I suggest
>> we put it it after LICENSE as that's where the more technical stuff
>> like SLOT starts. Attached a patch for skel.ebuild.
> 
> It needs to go right at the top, before 'inherit'.
> 

What if I want to use EAPI=1 features in an eclass? So if we for example
we have an ebuild using EAPI=2 and then it inherits and eclass that sets
EAPI=1 for slot deps.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Phase invariancy and exclusivity requirements

[Ciaran McCreesh]

What specifically are the phase invariancy and exclusivity requirements
for ebuilds? Currently PMS doesn't have anything to say about this;
clearly it needs to, since existing ebuilds fairly obviously do have
invariancy and exclusivity requirements.

Note that we're only discussing package manager related things here. If
the user manually upgrades libc / switches compiler / whatever whilst a
package manager is busy, there's nothing we can do.

Is the following set sufficient? Is the following set the least
restrictive correct solution?

* No syncing whilst anything else is going on.

* Variancy is any package manager action that modifies ROOT in a way
that isn't merely a simple addition of something that doesn't alter
other packages. This includes any non-default pkg_(pre|post)(inst|rm),
merging to ROOT and unmerging from ROOT.

* As an exception, changes to DISTDIR do not count as variancy. [1]

* pkg_setup does not introduce variancy. [2]

* Any pkg_ function that is not the default must be run exclusively. [3]

* No variancy may be introduced at any point between a package's
pkg_setup run up to the point that it is merged, except for any
variancy introduced by that package.

* There must be no variancy between a package's pkg_setup and a
package's pkg_postinst, except for any variancy introduced by that
package.

[1]: This allows background fetching. It means DISTDIR can be added to
by other processes at any point. It doesn't mean that a package's ${A}
can be nuked randomly.

[2]: Because otherwise a failed install would result in a damaged
system, and an install would temporarily damage a system until
complete. Adding a user isn't variancy by our definition, since when
combined with the exclusivity requirements it doesn't alter any part of
other packages.

[3]: Weird stuff happens if, for example, two package's pkg_postinsts
are run at the same time, since ebuilds do no ROOT locking. I'm fairly
sure the exclusivity needs to be shared amongst all pkg_ phases (think
package one doing a useradd fred in pkg_setup and package two doing it
in pkg_postinst).

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Fabian Groffen]

On 09-11-2007 23:55:51 +0200, Petteri Räty wrote:
> Usually it's best that ebuild variables follow the order that is in
> skel.ebuild. So know we should decide where to place EAPI. I suggest we
> put it it after LICENSE as that's where the more technical stuff like
> SLOT starts. Attached a patch for skel.ebuild.

Just my 2 cents, I have placed EAPI right after the # $Header: line of
each ebuild, as I felt that it was the first thing to know of the
ebuild, as it describes how you possibly have to process the rest of the
ebuild.  Examples can be found in the prefix overlay, e.g.
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/app-shells/bash/bash-3.2_p17-r00.1.ebuild

It has the advantage for me that EAPI is never hidden away somewhere
down the ebuild, and it is just inserted by a simple bash script
automagically (eapify in this case).


-- 
Fabian Groffen
Gentoo on a different level
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Ciaran McCreesh]

On Fri, 09 Nov 2007 23:55:51 +0200
Petteri Räty <[EMAIL PROTECTED]> wrote:
> Usually it's best that ebuild variables follow the order that is in
> skel.ebuild. So know we should decide where to place EAPI. I suggest
> we put it it after LICENSE as that's where the more technical stuff
> like SLOT starts. Attached a patch for skel.ebuild.

It needs to go right at the top, before 'inherit'.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

[gentoo-dev] RFC: Place of EAPI variable in ebuild

[Petteri Räty]

Usually it's best that ebuild variables follow the order that is in
skel.ebuild. So know we should decide where to place EAPI. I suggest we
put it it after LICENSE as that's where the more technical stuff like
SLOT starts. Attached a patch for skel.ebuild.

Regards,
Petteri
Index: skel.ebuild
===
RCS file: /var/cvsroot/gentoo-x86/skel.ebuild,v
retrieving revision 1.42
diff -u -r1.42 skel.ebuild
--- skel.ebuild 1 Jan 2007 12:18:17 -   1.42
+++ skel.ebuild 9 Nov 2007 21:55:43 -
@@ -40,6 +40,10 @@
 # docs on gentoo.org for details.
 LICENSE=""
 
+# The EAPI variable tells the ebuild format in use.
+# Defaults to 0 if not specified. See current PMS draft for more details.
+EAPI=1
+
 # The SLOT variable is used to tell Portage if it's OK to keep multiple
 # versions of the same package installed at the same time.  For example,
 # if we have a libfoo-1.2.2 and libfoo-1.3.2 (which is not compatible


signature.asc
Description: OpenPGP digital signature

Re: src_fetch (was Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April))

[Ciaran McCreesh]

On Fri, 09 Nov 2007 18:41:38 +0100
"Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:
> Use case one: package is completely unversioned upstream.
> Have src_fetch add a version as appropriate to the downloaded/mirrored
> version. This will work as change of upstream sources will be
> detected by all the checksums we do.

You're confusing multiple problems here. src_fetch *won't* work for
checksums. If we're talking merely badly named tarballs, a better
solution is SRC_URI arrow support.

> Use case two: package is incompatibly versioned.
> smlnj for example releases unversioned files in a versioned
> directory. There is currently no way to mirror that in distfiles as
> there is nowhere that I could specify that I want files to go to a
> separate directory.

Again, SRC_URI arrow support is a much better solution.

> Right. These use cases are really a bonus. Having src_fetch that we
> can redefine is simply the right thing and I can't believe it doesn't
> exist already.
> 
> Consider this my vote for an EAPI 2 which adds user-redefinable
> src_fetch ASAP.

src_fetch is necessary, yes, but it shouldn't be used in the cases you
describe. Arrows solve the same problem, don't break mirroring (if
implemented correctly) and don't break checksumming.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: New eclass: cmake-utils.eclass

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marijn Schouten (hkBst) wrote:
> ý wrote:
>> Wulf C. Krueger schrieb:
>>> On Friday, 09. November 2007 10:10:42 Rený 'Necoro' Neumann wrote:
 But as I think, that the uppercase version is the common behavior here,
 it should not need this extra "PYTHON". :) That's why the patch ;)
>>> Actually, the mixed-case is what we have encountered in most cases. 
>>> Furthermore, as you stated correctly yourself, cmake is case-sensitive and 
>>> a patch that works around that fact only to have one parameter less for a 
>>> function doesn't really make much sense in my book.
>> Hmm ... ok - if you say, that more applications used the mixed case
>> versions, the current version is ok :)
>> I did not want to reduce one parameter, but when I first used this
>> eclass function, I assumed, that it will do the right thing (that is:
>> make it uppercase). It did not do so - that's why the patch ;).
> 
>> Another way would be to enhance the comment and state explicitly that it
>> takes the useflag literally and does not do any case transition :)
> 
> Please don't reuse other people's digital signatures, Necoro.

Never mind, I take it back.

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHNJ4Qp/VmCx0OL2wRAlNSAJwMzJyjMgcywE05LQSJIIvlZp8L5ACfUEnU
d0YFSB4eC7r+dHvVY1j4y9A=
=qJmh
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: New eclass: cmake-utils.eclass

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

� wrote:
> Wulf C. Krueger schrieb:
>> On Friday, 09. November 2007 10:10:42 Rený 'Necoro' Neumann wrote:
>>> But as I think, that the uppercase version is the common behavior here,
>>> it should not need this extra "PYTHON". :) That's why the patch ;)
>> Actually, the mixed-case is what we have encountered in most cases. 
> 
>> Furthermore, as you stated correctly yourself, cmake is case-sensitive and 
>> a patch that works around that fact only to have one parameter less for a 
>> function doesn't really make much sense in my book.
> 
> Hmm ... ok - if you say, that more applications used the mixed case
> versions, the current version is ok :)
> I did not want to reduce one parameter, but when I first used this
> eclass function, I assumed, that it will do the right thing (that is:
> make it uppercase). It did not do so - that's why the patch ;).
> 
> Another way would be to enhance the comment and state explicitly that it
> takes the useflag literally and does not do any case transition :)

Please don't reuse other people's digital signatures, Necoro.

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHNJy/p/VmCx0OL2wRApycAJwLttjtkPEEzEEkM0XlNg93FCzgCgCgtkRU
/HTtrpUXuHV4jjcQ8qGqlSM=
=K51B
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

src_fetch (was Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April))

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
> On Fri, 13 Apr 2007 14:21:16 +0200
> Marius Mauch <[EMAIL PROTECTED]> wrote:
>> On Wed, 11 Apr 2007 15:41:01 +0100
>> Ciaran McCreesh <[EMAIL PROTECTED]> wrote:

>>> * Phase changes: src_fetch -> src_unpack -> src_prepare ->
>>> src_configure -> src_compile -> src_test -> src_install
>> No to src_fetch
> 
> Why? It would be useful for CVS, SVN etc ebuilds. I'm not suggesting it
> be used for SRC_URI things.

Hi list,

Not having src_fetch is really braindead. There are always gonna be silly
packages that don't fit into the nice default SRC_URI scheme.

Use case one: package is completely unversioned upstream.
Have src_fetch add a version as appropriate to the downloaded/mirrored
version. This will work as change of upstream sources will be detected by all
the checksums we do.

Use case two: package is incompatibly versioned.
smlnj for example releases unversioned files in a versioned directory. There
is currently no way to mirror that in distfiles as there is nowhere that I
could specify that I want files to go to a separate directory.

Right. These use cases are really a bonus. Having src_fetch that we can
redefine is simply the right thing and I can't believe it doesn't exist already.

Consider this my vote for an EAPI 2 which adds user-redefinable src_fetch ASAP.

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHNJvRp/VmCx0OL2wRAnc9AJ0bIm1snoGivLSZgTEE4dx7e2VgQwCeL7Kk
fwvaBcfVHv+nSXQd1KTT3ls=
=44uf
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: New eclass: cmake-utils.eclass

[Wulf C. Krueger]

On Friday, 09. November 2007 10:10:42 René 'Necoro' Neumann wrote:
> But as I think, that the uppercase version is the common behavior here,
> it should not need this extra "PYTHON". :) That's why the patch ;)

Actually, the mixed-case is what we have encountered in most cases. 

Furthermore, as you stated correctly yourself, cmake is case-sensitive and 
a patch that works around that fact only to have one parameter less for a 
function doesn't really make much sense in my book.

-- 
Best regards, Wulf


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: New eclass: cmake-utils.eclass

[René 'Necoro' Neumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Wulf C. Krueger schrieb:
> On Friday, 09. November 2007 10:10:42 René 'Necoro' Neumann wrote:
>> But as I think, that the uppercase version is the common behavior here,
>> it should not need this extra "PYTHON". :) That's why the patch ;)
> 
> Actually, the mixed-case is what we have encountered in most cases. 
> 
> Furthermore, as you stated correctly yourself, cmake is case-sensitive and 
> a patch that works around that fact only to have one parameter less for a 
> function doesn't really make much sense in my book.
> 
Hmm ... ok - if you say, that more applications used the mixed case
versions, the current version is ok :)
I did not want to reduce one parameter, but when I first used this
eclass function, I assumed, that it will do the right thing (that is:
make it uppercase). It did not do so - that's why the patch ;).

Another way would be to enhance the comment and state explicitly that it
takes the useflag literally and does not do any case transition :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHNIZt4UOg/zhYFuARAhuNAJ97EaX5W2ffNUrtPsFLLY1ZzTQFFQCffyCE
mThno69KazBAWmnsifjxM8E=
=7Xbk
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-core] packages2 testing

[Doug Klima]

Robin H. Johnson wrote:
> On Thu, Nov 08, 2007 at 07:52:49PM +0100, Marijn Schouten (hkBst) wrote:
>   
>> Isn't there supposed to be a search box too?
>> 
> Does anybody actually read the FAQ?
>
> - Short packages2 TODO list
>   - "Search": match a given string against: a substring in packages
> names, and description
>
>   
That's the same thing as expecting commenters on Slashdot to read the
article before commenting, let alone the people that write the summary.
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-print/cups: ChangeLog cups-1.3.4-r1.ebuild cups-1.3.4.ebuild

[Rémi Cardona]

Ciaran McCreesh a écrit :

On Fri, 9 Nov 2007 00:13:39 -0800
Donnie Berkholz <[EMAIL PROTECTED]> wrote:

PDEPEND="
ppds? ( || (
(
net-print/foomatic-filters-ppds
net-print/foomatic-db-ppds
)
net-print/foomatic-filters-ppds
net-print/foomatic-db-ppds
net-print/hplip
media-gfx/gimp-print
net-print/foo2zjs
net-print/cups-pdf
) )

I'm not sure I understand this dep. Either these two packages, or
these two packages and a lot more? When would the second one ever
happen?


Looks like it's a silly hack that relies upon the resolver taking the
first available option if nothing's installed. So if the user already
has any one of the listed packages, it does nothing, otherwise it
installs the two in their own block.

Which is rather perverse, and doesn't have the desired effect anyway,
since one of the listed options could well be pulled in as an earlier
dep anyway, in which case the pair wouldn't be chosen even if the user
previously had none of those packages.



Either way, those are just runtime deps.

Wouldn't it be best to drop them from the ebuild and add an einfo 
printing out this list of possible driver packages and let users decide 
which one they are going to use?


Rémi
--
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-print/cups: ChangeLog cups-1.3.4-r1.ebuild cups-1.3.4.ebuild

[Ciaran McCreesh]

On Fri, 9 Nov 2007 00:13:39 -0800
Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> > PDEPEND="
> > ppds? ( || (
> > (
> > net-print/foomatic-filters-ppds
> > net-print/foomatic-db-ppds
> > )
> > net-print/foomatic-filters-ppds
> > net-print/foomatic-db-ppds
> > net-print/hplip
> > media-gfx/gimp-print
> > net-print/foo2zjs
> > net-print/cups-pdf
> > ) )
> 
> I'm not sure I understand this dep. Either these two packages, or
> these two packages and a lot more? When would the second one ever
> happen?

Looks like it's a silly hack that relies upon the resolver taking the
first available option if nothing's installed. So if the user already
has any one of the listed packages, it does nothing, otherwise it
installs the two in their own block.

Which is rather perverse, and doesn't have the desired effect anyway,
since one of the listed options could well be pulled in as an earlier
dep anyway, in which case the pair wouldn't be chosen even if the user
previously had none of those packages.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-print/cups: ChangeLog cups-1.3.4-r1.ebuild cups-1.3.4.ebuild

[Petteri Räty]

Donnie Berkholz kirjoitti:
> On 23:15 Thu 08 Nov , Timo Gurr (tgurr) wrote:
>> 1.1  net-print/cups/cups-1.3.4-r1.ebuild
>>
>> file : 
>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-print/cups/cups-1.3.4-r1.ebuild?rev=1.1&view=markup
>> plain: 
>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-print/cups/cups-1.3.4-r1.ebuild?rev=1.1&content-type=text/plain
> 
>> PDEPEND="
>>  ppds? ( || (
>>  (
>>  net-print/foomatic-filters-ppds
>>  net-print/foomatic-db-ppds
>>  )
>>  net-print/foomatic-filters-ppds
>>  net-print/foomatic-db-ppds
>>  net-print/hplip
>>  media-gfx/gimp-print
>>  net-print/foo2zjs
>>  net-print/cups-pdf
>>  ) )
> 
> I'm not sure I understand this dep. Either these two packages, or these 
> two packages and a lot more? When would the second one ever happen?

It means these two packages or any one of the following I think.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: New eclass: cmake-utils.eclass

[René 'Necoro' Neumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ingmar Vanhassel schrieb:
> 2007/11/9, René 'Necoro' Neumann <[EMAIL PROTECTED]>:
>> Steve Long schrieb:
>>> René 'Necoro' Neumann wrote:
 cmake-utils_src_enable python => -DENABLE_python=...

 Wanted would be that it returned -DENABLE_PYTHON=...

 I'm not into bash scripting that much, so I do not know a way to do so -
 but I guess someone else is ;)

>>> Unfortunately BASH doesn't support ksh93 or zsh style casting to
>> uppercase.
>>> The best way really is via tr:
>>> alias toUpper='tr [[:lower:]] [[:upper:]]'
>>> alias toLower='tr [[:upper:]] [[:lower:]]'
>>>
>>> (er aliases don't normally work in scripts, but you get the idea.) Bear in
>>> mind that tr reads stdin and writes to stdout. It has the advantage of
>>> being locale-safe. Every other method I've looked at is much slower and
>>> only works with ASCII.
>>>
>>> A function wouldn't be too hard:
>>> toUpper() {
>>> for i; do
>>> echo "$i" |tr [[:lower:]] [[:upper:]]
>>> done
>>> }
>>>
>>> Usage depends on the parameters you pass.
>>> var=$(toUpper $var) # for single vars with no newlines in
>> This is right the version I've chosen ... so with the help of Steve: a
>> small patch ;)
>>
>> Regards,
>> Necoro
> 
> Hi Necoro,
> 
> You can just use 'cmake-utils_use_enable python PYTHON'
> 
> It's mentioned in the cmake-utils.eclass manpage 
> (app-portage/eclass-manpages),
> as well as in the patch you just sent: cmake-utils_use_enable  flag> [flag name]
> 
> :-)
> 
> Regards,
> Ingmar Vanhassel
> ���^����(�   ��X��X�t===
 I know this :) ... and this is how I did this at the moment.
But as I think, that the uppercase version is the common behavior here,
it should not need this extra "PYTHON". :) That's why the patch ;)

Regards,
Necoro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHNCQS4UOg/zhYFuARAmdhAJ9idOAgUEX7GIvQrkDIIOT8heg5YgCfdSAM
09YrI9Nky6kmKVNg4Egafgk=
=ZT15
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-process/fcron: ChangeLog fcron-3.0.4.ebuild

[Donnie Berkholz]

On 08:54 Fri 09 Nov , Wolfram Schlich (wschlich) wrote:
> 1.1  sys-process/fcron/fcron-3.0.4.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-process/fcron/fcron-3.0.4.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-process/fcron/fcron-3.0.4.ebuild?rev=1.1&content-type=text/plain

>   if useq debug; then

use() is useq() now. Dunno whether this is common enough to deserve a 
repoman check.

>   if ls -1 /var/spool/cron/fcrontabs/* >&/dev/null; then

This particular check ignores ROOT, and so does the rest of 
pkg_postinst(). Seems to me that a cron daemon is a package relatively 
likely to be installed using ROOT, so it's worth fixing.

>   ewarn
>   ewarn "WARNING: fcron now uses a dedicated fcron-specific"
>   ewarn "spooldir /var/spool/fcron instead of the commonly"
>   ewarn "used /var/spool/cron for several reasons."
>   ewarn
>   ewarn "Copying over existing crontabs from 
> /var/spool/cron/fcrontabs"
>   cp /var/spool/cron/fcrontabs/* /var/spool/fcron/ >&/dev/null \
>   || die "failed to migrate existing crontabs"
>   ewarn "You should now remove /var/spool/cron/fcrontabs!"
>   ewarn
>   ewarn "Fixing permissions and ownership of /var/spool/fcron"
>   chown root:root /var/spool/fcron/* >&/dev/null
>   chmod 0600 /var/spool/fcron/* >&/dev/null
>   chown fcron:fcron /var/spool/fcron/*.orig >&/dev/null
>   chmod 0640 /var/spool/fcron/*.orig >&/dev/null
>   ewarn
>   ewarn "*** YOU SHOULD IMMEDIATELY UPDATE THE"
>   ewarn "*** fcrontabs ENTRY IN /etc/fcron/fcron.conf"
>   ewarn "*** AND RESTART YOUR FCRON DAEMON!"
>   ebeep 20
>   epause 10

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-print/cups: ChangeLog cups-1.3.4-r1.ebuild cups-1.3.4.ebuild

[Donnie Berkholz]

On 23:15 Thu 08 Nov , Timo Gurr (tgurr) wrote:
> 1.1  net-print/cups/cups-1.3.4-r1.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-print/cups/cups-1.3.4-r1.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-print/cups/cups-1.3.4-r1.ebuild?rev=1.1&content-type=text/plain

> PDEPEND="
>   ppds? ( || (
>   (
>   net-print/foomatic-filters-ppds
>   net-print/foomatic-db-ppds
>   )
>   net-print/foomatic-filters-ppds
>   net-print/foomatic-db-ppds
>   net-print/hplip
>   media-gfx/gimp-print
>   net-print/foo2zjs
>   net-print/cups-pdf
>   ) )

I'm not sure I understand this dep. Either these two packages, or these 
two packages and a lot more? When would the second one ever happen?

> pkg_preinst() {
>   # cleanups
>   [ -n "${PN}" ] && rm -fR "${ROOT}"/usr/share/doc/"${PN}"-*
> }

This looks a bit weird.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-mail/getmail: ChangeLog getmail-4.7.7.ebuild

[Donnie Berkholz]

On 18:12 Thu 08 Nov , Andrej Kacian (ticho) wrote:
> 1.1  net-mail/getmail/getmail-4.7.7.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/getmail/getmail-4.7.7.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/getmail/getmail-4.7.7.ebuild?rev=1.1&content-type=text/plain

> src_compile() {
>   distutils_src_compile
> }

This is the default.

> 
> src_install() {
>   distutils_src_install
> 
>   if has_version "=net-mail/getmail-3*" ; then
>   mv ${D}/usr/bin/getmail ${D}/usr/bin/getmail4
>   mv ${D}/usr/bin/getmail_maildir ${D}/usr/bin/getmail_maildir4
>   mv ${D}/usr/bin/getmail_mbox ${D}/usr/bin/getmail_mbox4
>   fi
> 
>   # handle docs the gentoo way
>   if [ ${P} != ${PF} ]; then
>   mv ${D}/usr/share/doc/${P} ${D}/usr/share/doc/${PF}
>   fi
> 
>   dodir /usr/share/doc/${PF}/html
>   mv ${D}/usr/share/doc/${PF}/*.html ${D}/usr/share/doc/${PF}/*.css 
> ${D}/usr/share/doc/${PF}/html
> }

All kinds of quoting issues, did you check repoman warnings?

> 
> pkg_postinst() {
>   python_version
>   python_mod_optimize /usr/lib/python${PYVER}/site-packages/getmailcore

Could call distutils_pkg_postinst() instead of these.

> pkg_postrm() {
>   python_version
>   python_mod_cleanup
> }

This is the default.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list