[gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

On 30-10-2012 19:08:39 +0000, Samuli Suominen wrote:
> Added: udev.eclass
> Log:
>   New eclass to determine udevdir from udev.pc pkg-config file as requested by many people, without ML review due to unproductive feedback

Uhm...
Please, stop doing this!


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Samuli Suominen]

On 30/10/12 21:17, Fabian Groffen wrote:
> On 30-10-2012 19:08:39 +0000, Samuli Suominen wrote:
>> Added: udev.eclass
>> Log:
>>    New eclass to determine udevdir from udev.pc pkg-config file as requested by many people, without ML review due to unproductive feedback
>
> Uhm...
> Please, stop doing this!
>
>

This was sent to ML before and after conversation with another 
base-system@ member at #gentoo-dev we agreed to go on with it.

20:39 <@Cardoe> ssuominen: That's why you don't ask the ML
20:39 <@Cardoe> Too many cooks
20:39 <@Cardoe> Just do

Post feedback is still accepted and appericiated.
And, dozens of ebuilds implement the exact same code already, this was 
just to stop the pointless duplication tree-wide.

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Samuli Suominen]

On 30/10/12 21:17, Fabian Groffen wrote:
> On 30-10-2012 19:08:39 +0000, Samuli Suominen wrote:
>> Added: udev.eclass
>> Log:
>>    New eclass to determine udevdir from udev.pc pkg-config file as requested by many people, without ML review due to unproductive feedback
>
> Uhm...
> Please, stop doing this!
>
>

http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-power/upower/upower-0.9.18.ebuild?r1=1.4&r2=1.5

Take a look at that for example what this eclass does -> Drops 
duplicated code, that's all

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Doug Goldstein]

On Tue, Oct 30, 2012 at 2:17 PM, Fabian Groffen <grobian@gentoo.org> wrote:
> On 30-10-2012 19:08:39 +0000, Samuli Suominen wrote:
>> Added: udev.eclass
>> Log:
>>   New eclass to determine udevdir from udev.pc pkg-config file as requested by many people, without ML review due to unproductive feedback
>
> Uhm...
> Please, stop doing this!
>
>
> --

Stop the bike shedding. Provide real constructive improvements. I'm
not copying and pasting the same hunk of code in a bunch of ebuilds.

-- 
Doug Goldstein

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

On 30-10-2012 15:47:51 -0500, Doug Goldstein wrote:
> On Tue, Oct 30, 2012 at 2:17 PM, Fabian Groffen <grobian@gentoo.org> wrote:
> > On 30-10-2012 19:08:39 +0000, Samuli Suominen wrote:
> >> Added: udev.eclass
> >> Log:
> >>   New eclass to determine udevdir from udev.pc pkg-config file as requested by many people, without ML review due to unproductive feedback
> >
> > Uhm...
> > Please, stop doing this!
> 
> Stop the bike shedding. Provide real constructive improvements. I'm
> not copying and pasting the same hunk of code in a bunch of ebuilds.

We just have policies.  It is a bad habit to believe one is not affected
by them.

Samuli just introduced an eclass for which he had to make at least two
commits now right after its introduction to fix issues, and still it has
incorrect code, that should be fixed.  (So far he just ignored the issue.)

I wouldn't classify the feedback he got as "unproductive" at all.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Samuli Suominen]

On 30/10/12 23:16, Fabian Groffen wrote:
> On 30-10-2012 15:47:51 -0500, Doug Goldstein wrote:
>> On Tue, Oct 30, 2012 at 2:17 PM, Fabian Groffen <grobian@gentoo.org> wrote:
>>> On 30-10-2012 19:08:39 +0000, Samuli Suominen wrote:
>>>> Added: udev.eclass
>>>> Log:
>>>>    New eclass to determine udevdir from udev.pc pkg-config file as requested by many people, without ML review due to unproductive feedback
>>>
>>> Uhm...
>>> Please, stop doing this!
>>
>> Stop the bike shedding. Provide real constructive improvements. I'm
>> not copying and pasting the same hunk of code in a bunch of ebuilds.
>
> We just have policies.  It is a bad habit to believe one is not affected
> by them.
>
> Samuli just introduced an eclass for which he had to make at least two
> commits now right after its introduction to fix issues, and still it has
> incorrect code, that should be fixed.  (So far he just ignored the issue.)

One of the commits was before anything was said to ML (the EAPI change), 
the comment was later but the commenter didn't notice it just got fixed 
minutes before that.

I didn't ignore anything, but pointed this thread and the comments to 
mgorny since the exact same EPREFIX code is in systemd.eclass too. If 
you think this is incorrect, I would expect prefix@ maintainers to 
provide a patch to correct it.

And as I already pointed out, i'll be reusing the internal function 
later on in the ebuild just like systemd.eclass does, like for example, 
$(udev_do_rules_d) function.

We discussed also the conversion from echo to printf and saw it unnecessary.

So exactly what is (your) problem with the current eclass now?

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

On 30-10-2012 23:22:01 +0200, Samuli Suominen wrote:
> So exactly what is (your) problem with the current eclass now?

Your eclass pretends to support Prefix, but it is broken in that
respect, and because some other eclass does it the same way (your
claim), you refuse to fix it.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Samuli Suominen]

On 31/10/12 09:50, Fabian Groffen wrote:
> On 30-10-2012 23:22:01 +0200, Samuli Suominen wrote:
>> So exactly what is (your) problem with the current eclass now?
>
> Your eclass pretends to support Prefix, but it is broken in that
> respect, and because some other eclass does it the same way (your
> claim), you refuse to fix it.
>
>

I'm not refusing anything.

I don't do prefix and I'm _always_ expecting a patch from prefix@ for 
prefix issues.

Thanks for volunteering. I'll be looking forward in seeing the patch.

- Samuli

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]

On 31-10-2012 09:51:51 +0200, Samuli Suominen wrote:
> I don't do prefix and I'm _always_ expecting a patch from prefix@ for 
> prefix issues.

In that case, please don't invent prefix things yourself.  Thanks.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Samuli Suominen]

On 31/10/12 10:56, Fabian Groffen wrote:
> On 31-10-2012 09:51:51 +0200, Samuli Suominen wrote:
>> I don't do prefix and I'm _always_ expecting a patch from prefix@ for
>> prefix issues.
>
> In that case, please don't invent prefix things yourself.  Thanks.
>
>

Thank you for reviewing the eclass. The prefix code has been dropped 
from the eclass as requested.

- Samuli

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Gilles Dartiguelongue]

Le mercredi 31 octobre 2012 à 18:08 +0200, Samuli Suominen a écrit :
> On 31/10/12 10:56, Fabian Groffen wrote:
> > On 31-10-2012 09:51:51 +0200, Samuli Suominen wrote:
> >> I don't do prefix and I'm _always_ expecting a patch from prefix@ for
> >> prefix issues.
> >
> > In that case, please don't invent prefix things yourself.  Thanks.
> >
> >
> 
> Thank you for reviewing the eclass. The prefix code has been dropped 
> from the eclass as requested.
> 
> - Samuli
> 

This thread really looks like kindergarten. I do not have enough popcorn
the enjoy it truly though so please stop and act in a constructive way
like actually sending the eclass for review (again if you will).

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Samuli Suominen]

On 31/10/12 18:21, Gilles Dartiguelongue wrote:
> Le mercredi 31 octobre 2012 à 18:08 +0200, Samuli Suominen a écrit :
>> On 31/10/12 10:56, Fabian Groffen wrote:
>>> On 31-10-2012 09:51:51 +0200, Samuli Suominen wrote:
>>>> I don't do prefix and I'm _always_ expecting a patch from prefix@ for
>>>> prefix issues.
>>>
>>> In that case, please don't invent prefix things yourself.  Thanks.
>>>
>>>
>>
>> Thank you for reviewing the eclass. The prefix code has been dropped
>> from the eclass as requested.
>>
>> - Samuli
>>
>
> This thread really looks like kindergarten.

Yes I'd like it to end now too.

 > I do not have enough popcorn

got some :p

> the enjoy it truly though so please stop and act in a constructive way
> like actually sending the eclass for review (again if you will).
>

http://sources.gentoo.org/ "rules" :)

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/udev.eclass?view=markup

http://tinyurl.com/d8d47ma for the lazy (same link as above)

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Alexis Ballier]

On Tue, 30 Oct 2012 23:22:01 +0200
Samuli Suominen <ssuominen@gentoo.org> wrote:
[...]
> One of the commits was before anything was said to ML (the EAPI
> change), the comment was later but the commenter didn't notice it
> just got fixed minutes before that.
> 
> I didn't ignore anything, but pointed this thread and the comments to 
> mgorny since the exact same EPREFIX code is in systemd.eclass too. If 
> you think this is incorrect, I would expect prefix@ maintainers to 
> provide a patch to correct it.

That's why a review is usually useful...

> And as I already pointed out, i'll be reusing the internal function 
> later on in the ebuild just like systemd.eclass does, like for
> example, $(udev_do_rules_d) function.

Please show the code. As of now, the internal function is only
obfuscating a bit the code. This is obviously another order of
magnitude in terms of complexity but I do not want to have pyth... err
udev-ng, udev-ng-r1, udev-r1 eclasses :)

> We discussed also the conversion from echo to printf and saw it
> unnecessary.

Who is we? And why? I believe the -n to echo is not useful, so better
drop it entirely instead of wrongly making people believe not having a
newline matters.

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Samuli Suominen]

On 31/10/12 17:04, Alexis Ballier wrote:
> On Tue, 30 Oct 2012 23:22:01 +0200
> Samuli Suominen <ssuominen@gentoo.org> wrote:
> [...]
>> One of the commits was before anything was said to ML (the EAPI
>> change), the comment was later but the commenter didn't notice it
>> just got fixed minutes before that.
>>
>> I didn't ignore anything, but pointed this thread and the comments to
>> mgorny since the exact same EPREFIX code is in systemd.eclass too. If
>> you think this is incorrect, I would expect prefix@ maintainers to
>> provide a patch to correct it.
>
> That's why a review is usually useful...
>
>> And as I already pointed out, i'll be reusing the internal function
>> later on in the ebuild just like systemd.eclass does, like for
>> example, $(udev_do_rules_d) function.
>
> Please show the code. As of now, the internal function is only
> obfuscating a bit the code. This is obviously another order of
> magnitude in terms of complexity but I do not want to have pyth... err
> udev-ng, udev-ng-r1, udev-r1 eclasses :)
>
>> We discussed also the conversion from echo to printf and saw it
>> unnecessary.
>
> Who is we? And why? I believe the -n to echo is not useful, so better
> drop it entirely instead of wrongly making people believe not having a
> newline matters.
>

Was talking with the systemd/systemd.eclass maintainer in IRC.
The -n was dropped as a conclusion of the discussion from both eclasses.

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

On Tue, 30 Oct 2012 15:47:51 -0500
Doug Goldstein <cardoe@gentoo.org> wrote:
> Stop the bike shedding. Provide real constructive improvements. I'm
> not copying and pasting the same hunk of code in a bunch of ebuilds.

The point of getting approval for eclasses is not to force you to copy
and paste code. It's to ensure that the code you would otherwise be
copying and pasting is correct.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

On Tue, 30 Oct 2012 20:17:25 +0100
Fabian Groffen <grobian@gentoo.org> wrote:

> On 30-10-2012 19:08:39 +0000, Samuli Suominen wrote:
> > Added: udev.eclass
> > Log:
> >   New eclass to determine udevdir from udev.pc pkg-config file as requested by many people, without ML review due to unproductive feedback
> 
> Uhm...
> Please, stop doing this!

Also, please notice the ChangeLog file you are ignoring.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Samuli Suominen]

On 30/10/12 23:24, Michał Górny wrote:
> On Tue, 30 Oct 2012 20:17:25 +0100
> Fabian Groffen <grobian@gentoo.org> wrote:
>
>> On 30-10-2012 19:08:39 +0000, Samuli Suominen wrote:
>>> Added: udev.eclass
>>> Log:
>>>    New eclass to determine udevdir from udev.pc pkg-config file as requested by many people, without ML review due to unproductive feedback
>>
>> Uhm...
>> Please, stop doing this!
>
> Also, please notice the ChangeLog file you are ignoring.
>

Only every second person is using the ChangeLog in eclass/ as pointed 
out and discussed in this ML for so many times it's ridicilous.
Even direct contact with the people ignoring the ChangeLog in eclass/ 
has not changed their behavior. Some have replied something in line with 
"make repoman, or other post commit hook work in eclass directory if you 
want consistent behavior for the file"
The file is pointless if not everyone is using it. I've offered to 
remove the file before, and I'm reoffering to do so now.

And I'm not going to discuss this again, it's been vetted dozens of 
times here already to no result. So this is my last mail on that subject.

- Samuli

[gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

On Tue, 30 Oct 2012 23:28:47 +0200
Samuli Suominen <ssuominen@gentoo.org> wrote:

> Only every second person is using the ChangeLog in eclass/ as pointed 
> out and discussed in this ML for so many times it's ridicilous.

So step up and set a good example.  Since when do we defer to the LCD (Laziest
Common Developer)?

> The file is pointless if not everyone is using it. I've offered to 
> remove the file before, and I'm reoffering to do so now.

It's pointy enough for most uses.  Let's keep it that way.


-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] On the usefulness of eclass changelog

[Alexis Ballier]

On Tue, 30 Oct 2012 18:39:44 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
[...]
> > The file is pointless if not everyone is using it. I've offered to 
> > remove the file before, and I'm reoffering to do so now.
> 
> It's pointy enough for most uses.  Let's keep it that way.

I would like to know what are those uses. Here are my thoughts about
changelogs:

We have cvs logs, cvsweb, etc. So what is the value added from
changelogs?
Well, those logs are per-file as far as I know, and since a new version
of a package means a new .ebuild file, keeping track of changes to
packages is painful without a changelog which is global to the whole
package. Even if we have all the needed information in the cvs log,
changelogs for packages are definitely useful.
Now for eclasses the situation is different: I want to know what has
recently changed in foo.eclass, what is the fastest way? Search through
a changelog file with dozens of absolutely unrelated information, or
run cvs log/go to sources.gentoo.org ? I tend to do the latter and
find eclass changelogs completely useless.

Re: [gentoo-dev] On the usefulness of eclass changelog

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 31/10/12 11:26 AM, Alexis Ballier wrote:
> On Tue, 30 Oct 2012 18:39:44 -0600 Ryan Hill
> <dirtyepic@gentoo.org> wrote: [...]
>>> The file is pointless if not everyone is using it. I've
>>> offered to remove the file before, and I'm reoffering to do so
>>> now.
>> 
>> It's pointy enough for most uses.  Let's keep it that way.
> 
> I would like to know what are those uses. Here are my thoughts 
> about changelogs:
> 
> We have cvs logs, cvsweb, etc. So what is the value added from 
> changelogs? Well, those logs are per-file as far as I know, and 
> since a new version of a package means a new .ebuild file, keeping 
> track of changes to packages is painful without a changelog which 
> is global to the whole package. Even if we have all the needed 
> information in the cvs log, changelogs for packages are definitely 
> useful. Now for eclasses the situation is different: I want to
> know what has recently changed in foo.eclass, what is the fastest
> way? Search through a changelog file with dozens of absolutely
> unrelated information, or run cvs log/go to sources.gentoo.org ? I
> tend to do the latter and find eclass changelogs completely
> useless.
> 

Cool, you do, that's great.  This doesn't mean others don't use a
different process tho, and since it *IS* there and is *SUPPOSED* to be
filled, and it really doesn't hurt to run 'echangelog "${msg}" && cvs
ci -m "${msg}"' , why not do it?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlCRRU0ACgkQ2ugaI38ACPCobwD+LZvXFPyfsGZ+484wnkv6fk8L
oBazGyjti3n2nNAkM8IA/A5IvVNyOnd6U9lVH1B2dRA2HB1+i8Hac1aAKvs/EPF1
=F5eR
-----END PGP SIGNATURE-----

Re: [gentoo-dev] On the usefulness of eclass changelog

[Alexis Ballier]

On Wed, 31 Oct 2012 11:35:41 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 31/10/12 11:26 AM, Alexis Ballier wrote:
> > On Tue, 30 Oct 2012 18:39:44 -0600 Ryan Hill
> > <dirtyepic@gentoo.org> wrote: [...]
> >>> The file is pointless if not everyone is using it. I've
> >>> offered to remove the file before, and I'm reoffering to do so
> >>> now.
> >> 
> >> It's pointy enough for most uses.  Let's keep it that way.
> > 
> > I would like to know what are those uses. Here are my thoughts 
> > about changelogs:
> > 
> > We have cvs logs, cvsweb, etc. So what is the value added from 
> > changelogs? Well, those logs are per-file as far as I know, and 
> > since a new version of a package means a new .ebuild file, keeping 
> > track of changes to packages is painful without a changelog which 
> > is global to the whole package. Even if we have all the needed 
> > information in the cvs log, changelogs for packages are definitely 
> > useful. Now for eclasses the situation is different: I want to
> > know what has recently changed in foo.eclass, what is the fastest
> > way? Search through a changelog file with dozens of absolutely
> > unrelated information, or run cvs log/go to sources.gentoo.org ? I
> > tend to do the latter and find eclass changelogs completely
> > useless.
> > 
> 
> Cool, you do, that's great.  This doesn't mean others don't use a
> different process tho, and since it *IS* there and is *SUPPOSED* to be
> filled, and it really doesn't hurt to run 'echangelog "${msg}" && cvs
> ci -m "${msg}"' , why not do it?

so that others are not encouraged to work sub-optimally :)

Re: [gentoo-dev] On the usefulness of eclass changelog

[Samuli Suominen]

On 31/10/12 17:39, Alexis Ballier wrote:
> On Wed, 31 Oct 2012 11:35:41 -0400
> Ian Stakenvicius <axs@gentoo.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 31/10/12 11:26 AM, Alexis Ballier wrote:
>>> On Tue, 30 Oct 2012 18:39:44 -0600 Ryan Hill
>>> <dirtyepic@gentoo.org> wrote: [...]
>>>>> The file is pointless if not everyone is using it. I've
>>>>> offered to remove the file before, and I'm reoffering to do so
>>>>> now.
>>>>
>>>> It's pointy enough for most uses.  Let's keep it that way.
>>>
>>> I would like to know what are those uses. Here are my thoughts
>>> about changelogs:
>>>
>>> We have cvs logs, cvsweb, etc. So what is the value added from
>>> changelogs? Well, those logs are per-file as far as I know, and
>>> since a new version of a package means a new .ebuild file, keeping
>>> track of changes to packages is painful without a changelog which
>>> is global to the whole package. Even if we have all the needed
>>> information in the cvs log, changelogs for packages are definitely
>>> useful. Now for eclasses the situation is different: I want to
>>> know what has recently changed in foo.eclass, what is the fastest
>>> way? Search through a changelog file with dozens of absolutely
>>> unrelated information, or run cvs log/go to sources.gentoo.org ? I
>>> tend to do the latter and find eclass changelogs completely
>>> useless.
>>>
>>
>> Cool, you do, that's great.  This doesn't mean others don't use a
>> different process tho, and since it *IS* there and is *SUPPOSED* to be
>> filled, and it really doesn't hurt to run 'echangelog "${msg}" && cvs
>> ci -m "${msg}"' , why not do it?
>
> so that others are not encouraged to work sub-optimally :)
>

eclass/ handling should go to repoman and the automated ChangeLog 
process, should be rather straight forward for knowing person.

Re: [gentoo-dev] On the usefulness of eclass changelog

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 31/10/12 12:15 PM, Samuli Suominen wrote:
> On 31/10/12 17:39, Alexis Ballier wrote:
>> On Wed, 31 Oct 2012 11:35:41 -0400 Ian Stakenvicius
>> <axs@gentoo.org> wrote:
>> 
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>> 
>>> On 31/10/12 11:26 AM, Alexis Ballier wrote:
>>>> On Tue, 30 Oct 2012 18:39:44 -0600 Ryan Hill 
>>>> <dirtyepic@gentoo.org> wrote: [...]
>>>>>> The file is pointless if not everyone is using it. I've 
>>>>>> offered to remove the file before, and I'm reoffering to
>>>>>> do so now.
>>>>> 
>>>>> It's pointy enough for most uses.  Let's keep it that way.
>>>> 
>>>> I would like to know what are those uses. Here are my
>>>> thoughts about changelogs:
>>>> 
>>>> We have cvs logs, cvsweb, etc. So what is the value added
>>>> from changelogs? Well, those logs are per-file as far as I
>>>> know, and since a new version of a package means a new
>>>> .ebuild file, keeping track of changes to packages is painful
>>>> without a changelog which is global to the whole package.
>>>> Even if we have all the needed information in the cvs log,
>>>> changelogs for packages are definitely useful. Now for
>>>> eclasses the situation is different: I want to know what has
>>>> recently changed in foo.eclass, what is the fastest way?
>>>> Search through a changelog file with dozens of absolutely 
>>>> unrelated information, or run cvs log/go to
>>>> sources.gentoo.org ? I tend to do the latter and find eclass
>>>> changelogs completely useless.
>>>> 
>>> 
>>> Cool, you do, that's great.  This doesn't mean others don't use
>>> a different process tho, and since it *IS* there and is
>>> *SUPPOSED* to be filled, and it really doesn't hurt to run
>>> 'echangelog "${msg}" && cvs ci -m "${msg}"' , why not do it?
>> 
>> so that others are not encouraged to work sub-optimally :)
>> 
> 
> eclass/ handling should go to repoman and the automated ChangeLog 
> process, should be rather straight forward for knowing person.
> 

I agree, that'd make the whole thing easier.  But until repoman can
commit in eclass/ it shouldn't be that hard to just run echangelog ,
as "inefficient" as that may be. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlCRUSYACgkQ2ugaI38ACPAr7AD/ZlbMpcMm2/654o2EroXgpblD
E+g+9ARBZxqxxDLlklQA/ivTUWlSGBXufWe/qQfzpRBvm+ms+cpCys6IMe3N7S4e
=pwjP
-----END PGP SIGNATURE-----

Re: [gentoo-dev] On the usefulness of eclass changelog

[Alexis Ballier]

On Wed, 31 Oct 2012 12:26:14 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 31/10/12 12:15 PM, Samuli Suominen wrote:
> > On 31/10/12 17:39, Alexis Ballier wrote:
> >> On Wed, 31 Oct 2012 11:35:41 -0400 Ian Stakenvicius
> >> <axs@gentoo.org> wrote:
> >> 
> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >>> 
> >>> On 31/10/12 11:26 AM, Alexis Ballier wrote:
> >>>> On Tue, 30 Oct 2012 18:39:44 -0600 Ryan Hill 
> >>>> <dirtyepic@gentoo.org> wrote: [...]
> >>>>>> The file is pointless if not everyone is using it. I've 
> >>>>>> offered to remove the file before, and I'm reoffering to
> >>>>>> do so now.
> >>>>> 
> >>>>> It's pointy enough for most uses.  Let's keep it that way.
> >>>> 
> >>>> I would like to know what are those uses. Here are my
> >>>> thoughts about changelogs:
> >>>> 
> >>>> We have cvs logs, cvsweb, etc. So what is the value added
> >>>> from changelogs? Well, those logs are per-file as far as I
> >>>> know, and since a new version of a package means a new
> >>>> .ebuild file, keeping track of changes to packages is painful
> >>>> without a changelog which is global to the whole package.
> >>>> Even if we have all the needed information in the cvs log,
> >>>> changelogs for packages are definitely useful. Now for
> >>>> eclasses the situation is different: I want to know what has
> >>>> recently changed in foo.eclass, what is the fastest way?
> >>>> Search through a changelog file with dozens of absolutely 
> >>>> unrelated information, or run cvs log/go to
> >>>> sources.gentoo.org ? I tend to do the latter and find eclass
> >>>> changelogs completely useless.
> >>>> 
> >>> 
> >>> Cool, you do, that's great.  This doesn't mean others don't use
> >>> a different process tho, and since it *IS* there and is
> >>> *SUPPOSED* to be filled, and it really doesn't hurt to run
> >>> 'echangelog "${msg}" && cvs ci -m "${msg}"' , why not do it?
> >> 
> >> so that others are not encouraged to work sub-optimally :)
> >> 
> > 
> > eclass/ handling should go to repoman and the automated ChangeLog 
> > process, should be rather straight forward for knowing person.
> > 
> 
> I agree, that'd make the whole thing easier.  But until repoman can
> commit in eclass/ it shouldn't be that hard to just run echangelog ,
> as "inefficient" as that may be. :)

Don't get me wrong: thats not running echangelog that is inefficient,
trying to get information from the changelog is. A per-eclass changelog
would be much more useful, as, atm, you'd be able to access the
information without internet connection.

I have yet to see a case where a global eclass changelog is more
efficient and/or convenient.

Re: [gentoo-dev] On the usefulness of eclass changelog

[Jeroen Roovers]

On Wed, 31 Oct 2012 12:26:14 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> I agree, that'd make the whole thing easier.  But until repoman can
> commit in eclass/ it shouldn't be that hard to just run echangelog ,
> as "inefficient" as that may be. :)

https://bugs.gentoo.org/show_bug.cgi?id=390651


     jer

Re: [gentoo-dev] On the usefulness of eclass changelog

[Rich Freeman]

On Wed, Oct 31, 2012 at 12:15 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> eclass/ handling should go to repoman and the automated ChangeLog process,
> should be rather straight forward for knowing person.

Perhaps, but right now the policy is to update it, so do it.  The
policy is also to post eclass changes for review on -dev, so do that
too.  That means do it BEFORE you commit it.  I don't care if you post
it raw, or post a link to a file, or post a link to a proposed commit
on your private little git branch, but don't commit it and then send
out a link to the commit in production after the fact.

This whole double-thread is ridiculous.  If somebody at work
deliberately violated a dumb policy and pointed out it was dumb, the
answer would be, "thanks, we'll look into changing the dumb policy,
now pack up your desk to make room for the new employee who can
benefit from the improved policy."

If you don't like the rules feel free to whine, beg, and plead to QA,
the council, $DIETY, or your mother, but follow the rules until
they're changed.  There is always room for mistakes, but big projects
don't work when everybody just does whatever they feel like doing.

Rich

Re: [gentoo-dev] On the usefulness of eclass changelog

[Samuli Suominen]

On 31/10/12 20:17, Rich Freeman wrote:
> On Wed, Oct 31, 2012 at 12:15 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>> eclass/ handling should go to repoman and the automated ChangeLog process,
>> should be rather straight forward for knowing person.
>
> Perhaps, but right now the policy is to update it, so do it.  The
> policy is also to post eclass changes for review on -dev, so do that
> too.  That means do it BEFORE you commit it.  I don't care if you post
> it raw, or post a link to a file, or post a link to a proposed commit
> on your private little git branch, but don't commit it and then send
> out a link to the commit in production after the fact.
>
> This whole double-thread is ridiculous.  If somebody at work
> deliberately violated a dumb policy and pointed out it was dumb, the
> answer would be, "thanks, we'll look into changing the dumb policy,
> now pack up your desk to make room for the new employee who can
> benefit from the improved policy."
>
> If you don't like the rules feel free to whine, beg, and plead to QA,
> the council, $DIETY, or your mother, but follow the rules until
> they're changed.  There is always room for mistakes, but big projects
> don't work when everybody just does whatever they feel like doing.

I'd expect the file to be zeroed out after the repoman has been fixed to 
cover eclass/ as inconsistent ChangeLog equals useless ChangeLog

And indeed this is ridicilous as the claims of not following rules has 
not been even broken.
The eclass was sent to ML months ago already, and the conserns from back 
then have been counted in already for:

http://gentoo.2317880.n4.nabble.com/rfc-udev-rules-eclass-td45792.html

How many times are you required to do that before pushing it in? Last 
minute changes were made, yes, but this is no new news that it was 
coming in.

- Samuli

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass

[Alexis Ballier]

On Tue, 30 Oct 2012 19:08:39 +0000 (UTC)
"Samuli Suominen (ssuominen)" <ssuominen@gentoo.org> wrote:

[...]
> 
> case ${EAPI:-0} in
> 	0|1|2|3|4) ;;
> 	*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> established." esac

sounds like a useless and annoying check for just exporting one function

> 
> RDEPEND=""

useless?

> DEPEND="virtual/pkgconfig"
> 
> # @FUNCTION: _udev_get_udevdir
> # @INTERNAL
> # @DESCRIPTION:
> # Get unprefixed udevdir.
> _udev_get_udevdir() {
> 	if $($(tc-getPKG_CONFIG) --exists udev); then
> 		echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
> udev)" else
> 		echo -n /lib/udev
> 	fi
> }
> 
> # @FUNCTION: udev_get_udevdir
> # @DESCRIPTION:
> # Output the path for the udev directory (not including ${D}).
> # This function always succeeds, even if udev is not installed.
> # The fallback value is set to /lib/udev
> udev_get_udevdir() {
> 	has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> 	debug-print-function ${FUNCNAME} "${@}"
> 
> 	echo -n "${EPREFIX}$(_udev_get_udevdir)"
> }

local foo=""
unfold _udev_get_udevdir there, replacing 'echo -n' by foo=
printf ...$foo

kill the extra internal fucntion that seems useless.
echo isn't really reliable for precise formatting, prefer printf when
it matters. (in this case it doesn't matter but seems good practices)

have you checked what is the udevdir value on prefix, if at all
relevant ? I fear a double prefix issue.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass

[Samuli Suominen]

On 30/10/12 21:56, Alexis Ballier wrote:
> On Tue, 30 Oct 2012 19:08:39 +0000 (UTC)
> "Samuli Suominen (ssuominen)" <ssuominen@gentoo.org> wrote:
>
> [...]
>>
>> case ${EAPI:-0} in
>> 	0|1|2|3|4) ;;
>> 	*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
>> established." esac
>
> sounds like a useless and annoying check for just exporting one function
>
>>
>> RDEPEND=""
>
> useless?

if the ebuild is EAPI=0 or EAPI=1 then DEPEND expands to RDEPEND, so 
setting empty RDEPEND prevents that, or am I missing something?

>
>> DEPEND="virtual/pkgconfig"
>>
>> # @FUNCTION: _udev_get_udevdir
>> # @INTERNAL
>> # @DESCRIPTION:
>> # Get unprefixed udevdir.
>> _udev_get_udevdir() {
>> 	if $($(tc-getPKG_CONFIG) --exists udev); then
>> 		echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
>> udev)" else
>> 		echo -n /lib/udev
>> 	fi
>> }
>>
>> # @FUNCTION: udev_get_udevdir
>> # @DESCRIPTION:
>> # Output the path for the udev directory (not including ${D}).
>> # This function always succeeds, even if udev is not installed.
>> # The fallback value is set to /lib/udev
>> udev_get_udevdir() {
>> 	has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
>> 	debug-print-function ${FUNCNAME} "${@}"
>>
>> 	echo -n "${EPREFIX}$(_udev_get_udevdir)"
>> }
>
> local foo=""
> unfold _udev_get_udevdir there, replacing 'echo -n' by foo=
> printf ...$foo
>
> kill the extra internal fucntion that seems useless.
> echo isn't really reliable for precise formatting, prefer printf when
> it matters. (in this case it doesn't matter but seems good practices)
>
> have you checked what is the udevdir value on prefix, if at all
> relevant ? I fear a double prefix issue.
>

the code is more or less same as systemd.eclass has, I don't want to 
diverge too much from that since we are essentially dealing with the 
same package (tarball)

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass

[Alexis Ballier]

On Tue, 30 Oct 2012 21:57:11 +0200
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 30/10/12 21:56, Alexis Ballier wrote:
> > On Tue, 30 Oct 2012 19:08:39 +0000 (UTC)
> > "Samuli Suominen (ssuominen)" <ssuominen@gentoo.org> wrote:
> >
> > [...]
> >>
> >> case ${EAPI:-0} in
> >> 	0|1|2|3|4) ;;
> >> 	*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> >> established." esac
> >
> > sounds like a useless and annoying check for just exporting one
> > function
> >
> >>
> >> RDEPEND=""
> >
> > useless?
> 
> if the ebuild is EAPI=0 or EAPI=1 then DEPEND expands to RDEPEND, so 
> setting empty RDEPEND prevents that, or am I missing something?

even with eclasses and inheritence ? maybe you're right but i wouldnt
bet anything

> 
> >
> >> DEPEND="virtual/pkgconfig"
> >>
> >> # @FUNCTION: _udev_get_udevdir
> >> # @INTERNAL
> >> # @DESCRIPTION:
> >> # Get unprefixed udevdir.
> >> _udev_get_udevdir() {
> >> 	if $($(tc-getPKG_CONFIG) --exists udev); then
> >> 		echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
> >> udev)" else
> >> 		echo -n /lib/udev
> >> 	fi
> >> }
> >>
> >> # @FUNCTION: udev_get_udevdir
> >> # @DESCRIPTION:
> >> # Output the path for the udev directory (not including ${D}).
> >> # This function always succeeds, even if udev is not installed.
> >> # The fallback value is set to /lib/udev
> >> udev_get_udevdir() {
> >> 	has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> >> 	debug-print-function ${FUNCNAME} "${@}"
> >>
> >> 	echo -n "${EPREFIX}$(_udev_get_udevdir)"
> >> }
> >
> > local foo=""
> > unfold _udev_get_udevdir there, replacing 'echo -n' by foo=
> > printf ...$foo
> >
> > kill the extra internal fucntion that seems useless.
> > echo isn't really reliable for precise formatting, prefer printf
> > when it matters. (in this case it doesn't matter but seems good
> > practices)
> >
> > have you checked what is the udevdir value on prefix, if at all
> > relevant ? I fear a double prefix issue.
> >
> 
> the code is more or less same as systemd.eclass has, I don't want to 
> diverge too much from that since we are essentially dealing with the 
> same package (tarball)

well, two bad do not make a good
consider the above remarks to apply to systemd.eclass too then, and
either explain why they're not relevant or apply them to both eclasses
if you want to avoid divergence.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2864 bytes --]

On Tue, 30 Oct 2012 17:08:07 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Tue, 30 Oct 2012 21:57:11 +0200
> Samuli Suominen <ssuominen@gentoo.org> wrote:
> 
> > On 30/10/12 21:56, Alexis Ballier wrote:
> > > On Tue, 30 Oct 2012 19:08:39 +0000 (UTC)
> > > "Samuli Suominen (ssuominen)" <ssuominen@gentoo.org> wrote:
> > >
> > > [...]
> > >>
> > >> case ${EAPI:-0} in
> > >> 	0|1|2|3|4) ;;
> > >> 	*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> > >> established." esac
> > >
> > > sounds like a useless and annoying check for just exporting one
> > > function
> > >
> > >>
> > >> RDEPEND=""
> > >
> > > useless?
> > 
> > if the ebuild is EAPI=0 or EAPI=1 then DEPEND expands to RDEPEND, so 
> > setting empty RDEPEND prevents that, or am I missing something?
> 
> even with eclasses and inheritence ? maybe you're right but i wouldnt
> bet anything
> 
> > 
> > >
> > >> DEPEND="virtual/pkgconfig"
> > >>
> > >> # @FUNCTION: _udev_get_udevdir
> > >> # @INTERNAL
> > >> # @DESCRIPTION:
> > >> # Get unprefixed udevdir.
> > >> _udev_get_udevdir() {
> > >> 	if $($(tc-getPKG_CONFIG) --exists udev); then
> > >> 		echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
> > >> udev)" else
> > >> 		echo -n /lib/udev
> > >> 	fi
> > >> }
> > >>
> > >> # @FUNCTION: udev_get_udevdir
> > >> # @DESCRIPTION:
> > >> # Output the path for the udev directory (not including ${D}).
> > >> # This function always succeeds, even if udev is not installed.
> > >> # The fallback value is set to /lib/udev
> > >> udev_get_udevdir() {
> > >> 	has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> > >> 	debug-print-function ${FUNCNAME} "${@}"
> > >>
> > >> 	echo -n "${EPREFIX}$(_udev_get_udevdir)"
> > >> }
> > >
> > > local foo=""
> > > unfold _udev_get_udevdir there, replacing 'echo -n' by foo=
> > > printf ...$foo
> > >
> > > kill the extra internal fucntion that seems useless.
> > > echo isn't really reliable for precise formatting, prefer printf
> > > when it matters. (in this case it doesn't matter but seems good
> > > practices)
> > >
> > > have you checked what is the udevdir value on prefix, if at all
> > > relevant ? I fear a double prefix issue.
> > >
> > 
> > the code is more or less same as systemd.eclass has, I don't want to 
> > diverge too much from that since we are essentially dealing with the 
> > same package (tarball)
> 
> well, two bad do not make a good
> consider the above remarks to apply to systemd.eclass too then, and
> either explain why they're not relevant or apply them to both eclasses
> if you want to avoid divergence.

Don't even try to touch any of my eclasses without prior asking.

And the additional internal function there was used in order to get
unprefixed path for do*() and new*() functions.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass

[Samuli Suominen]

On 30/10/12 22:18, Michał Górny wrote:
> On Tue, 30 Oct 2012 17:08:07 -0300
> Alexis Ballier <aballier@gentoo.org> wrote:
>
>> On Tue, 30 Oct 2012 21:57:11 +0200
>> Samuli Suominen <ssuominen@gentoo.org> wrote:
>>
>>> On 30/10/12 21:56, Alexis Ballier wrote:
>>>> On Tue, 30 Oct 2012 19:08:39 +0000 (UTC)
>>>> "Samuli Suominen (ssuominen)" <ssuominen@gentoo.org> wrote:
>>>>
>>>> [...]
>>>>>
>>>>> case ${EAPI:-0} in
>>>>> 	0|1|2|3|4) ;;
>>>>> 	*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
>>>>> established." esac
>>>>
>>>> sounds like a useless and annoying check for just exporting one
>>>> function
>>>>
>>>>>
>>>>> RDEPEND=""
>>>>
>>>> useless?
>>>
>>> if the ebuild is EAPI=0 or EAPI=1 then DEPEND expands to RDEPEND, so
>>> setting empty RDEPEND prevents that, or am I missing something?
>>
>> even with eclasses and inheritence ? maybe you're right but i wouldnt
>> bet anything
>>
>>>
>>>>
>>>>> DEPEND="virtual/pkgconfig"
>>>>>
>>>>> # @FUNCTION: _udev_get_udevdir
>>>>> # @INTERNAL
>>>>> # @DESCRIPTION:
>>>>> # Get unprefixed udevdir.
>>>>> _udev_get_udevdir() {
>>>>> 	if $($(tc-getPKG_CONFIG) --exists udev); then
>>>>> 		echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
>>>>> udev)" else
>>>>> 		echo -n /lib/udev
>>>>> 	fi
>>>>> }
>>>>>
>>>>> # @FUNCTION: udev_get_udevdir
>>>>> # @DESCRIPTION:
>>>>> # Output the path for the udev directory (not including ${D}).
>>>>> # This function always succeeds, even if udev is not installed.
>>>>> # The fallback value is set to /lib/udev
>>>>> udev_get_udevdir() {
>>>>> 	has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
>>>>> 	debug-print-function ${FUNCNAME} "${@}"
>>>>>
>>>>> 	echo -n "${EPREFIX}$(_udev_get_udevdir)"
>>>>> }
>>>>
>>>> local foo=""
>>>> unfold _udev_get_udevdir there, replacing 'echo -n' by foo=
>>>> printf ...$foo
>>>>
>>>> kill the extra internal fucntion that seems useless.
>>>> echo isn't really reliable for precise formatting, prefer printf
>>>> when it matters. (in this case it doesn't matter but seems good
>>>> practices)
>>>>
>>>> have you checked what is the udevdir value on prefix, if at all
>>>> relevant ? I fear a double prefix issue.
>>>>
>>>
>>> the code is more or less same as systemd.eclass has, I don't want to
>>> diverge too much from that since we are essentially dealing with the
>>> same package (tarball)
>>
>> well, two bad do not make a good
>> consider the above remarks to apply to systemd.eclass too then, and
>> either explain why they're not relevant or apply them to both eclasses
>> if you want to avoid divergence.
>
> Don't even try to touch any of my eclasses without prior asking.
>
> And the additional internal function there was used in order to get
> unprefixed path for do*() and new*() functions.
>

same as i'll propably reuse the function for something like 
$(do_udev_rules) later on

the udev.eclass might have one function now, but that's just a 
rudementary start to drop most of the duplication from ebuilds

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass

[Alexis Ballier]

On Tue, 30 Oct 2012 21:18:02 +0100
Michał Górny <mgorny@gentoo.org> wrote:
[...]
> Don't even try to touch any of my eclasses without prior asking.

A bit aggressive but its rather obvious that this is the norm not the
exception, meaning the argument 'I do not want to diverge from
$other eclass' is moot.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

On Wed, 31 Oct 2012 11:57:49 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Tue, 30 Oct 2012 21:18:02 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> [...]
> > Don't even try to touch any of my eclasses without prior asking.
> 
> A bit aggressive but its rather obvious that this is the norm not the
> exception, meaning the argument 'I do not want to diverge from
> $other eclass' is moot.

It's aggressive because Samuli has a history of touching (and sometimes
breaking) other people's packages without even asking or pinging that
he did that, and believing he's above all the rules here.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass

[Samuli Suominen]

On 31/10/12 17:09, Michał Górny wrote:
> On Wed, 31 Oct 2012 11:57:49 -0300
> Alexis Ballier <aballier@gentoo.org> wrote:
>
>> On Tue, 30 Oct 2012 21:18:02 +0100
>> Michał Górny <mgorny@gentoo.org> wrote:
>> [...]
>>> Don't even try to touch any of my eclasses without prior asking.
>>
>> A bit aggressive but its rather obvious that this is the norm not the
>> exception, meaning the argument 'I do not want to diverge from
>> $other eclass' is moot.
>
> It's aggressive because Samuli has a history of touching (and sometimes
> breaking) other people's packages without even asking or pinging that
> he did that, and believing he's above all the rules here.
>

You don't know me clearly, that's definately the opposite of what I'm 
doing and intending to do, walking the fine line and bothering people 
only when something real changes...

Breaking? Hardly, since I never commit untested code, and the exceptions 
I've fixed myself usually very quickly as I'm watching incoming bugs, 
forums, and more

I'm being cooperative with you and keeping udev.eclass with 
systemd.eclass sort of 'in sync' due to the nature of both
packages being from the same tarball. What more do you want? Seriously.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass

[Markos Chandras]

On Wed, Oct 31, 2012 at 3:36 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 31/10/12 17:09, Michał Górny wrote:
>>
>> On Wed, 31 Oct 2012 11:57:49 -0300
>> Alexis Ballier <aballier@gentoo.org> wrote:
>>
>>> On Tue, 30 Oct 2012 21:18:02 +0100
>>> Michał Górny <mgorny@gentoo.org> wrote:
>>> [...]
>>>>
>>>> Don't even try to touch any of my eclasses without prior asking.
>>>
>>>
>>> A bit aggressive but its rather obvious that this is the norm not the
>>> exception, meaning the argument 'I do not want to diverge from
>>> $other eclass' is moot.
>>
>>
>> It's aggressive because Samuli has a history of touching (and sometimes
>> breaking) other people's packages without even asking or pinging that
>> he did that, and believing he's above all the rules here.
>>
>
> You don't know me clearly, that's definately the opposite of what I'm doing
> and intending to do, walking the fine line and bothering people only when
> something real changes...
>
> Breaking? Hardly, since I never commit untested code, and the exceptions
> I've fixed myself usually very quickly as I'm watching incoming bugs,
> forums, and more
>
> I'm being cooperative with you and keeping udev.eclass with systemd.eclass
> sort of 'in sync' due to the nature of both
> packages being from the same tarball. What more do you want? Seriously.
>

Please stop _NOW_. The thread is about the eclass review. Either
comment on that or go flame somewhere else.
Did he break your eclass this time or is this a preemptive complain
just in case he does in the future?

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

On 30-10-2012 16:56:21 -0300, Alexis Ballier wrote:
> > # @FUNCTION: _udev_get_udevdir
> > # @INTERNAL
> > # @DESCRIPTION:
> > # Get unprefixed udevdir.
> > _udev_get_udevdir() {
> > 	if $($(tc-getPKG_CONFIG) --exists udev); then
> > 		echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
> > udev)" else
> > 		echo -n /lib/udev
> > 	fi
> > }
> > 
> > # @FUNCTION: udev_get_udevdir
> > # @DESCRIPTION:
> > # Output the path for the udev directory (not including ${D}).
> > # This function always succeeds, even if udev is not installed.
> > # The fallback value is set to /lib/udev
> > udev_get_udevdir() {
> > 	has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> > 	debug-print-function ${FUNCNAME} "${@}"
> > 
> > 	echo -n "${EPREFIX}$(_udev_get_udevdir)"
> > }
> 
> local foo=""
> unfold _udev_get_udevdir there, replacing 'echo -n' by foo=
> printf ...$foo
> 
> kill the extra internal fucntion that seems useless.
> echo isn't really reliable for precise formatting, prefer printf when
> it matters. (in this case it doesn't matter but seems good practices)

echo -n is not always working, but in this case no point in using it at
all.

> have you checked what is the udevdir value on prefix, if at all
> relevant ? I fear a double prefix issue.

I definitely share your concern.  (_udev_get_udevdir has a broken
implementation, given its contract per documentation)


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/10/12 03:56 PM, Alexis Ballier wrote:
> On Tue, 30 Oct 2012 19:08:39 +0000 (UTC) "Samuli Suominen
> (ssuominen)" <ssuominen@gentoo.org> wrote:
> 
> [...]
>> 
>> case ${EAPI:-0} in 0|1|2|3|4) ;; *) die "${ECLASS}.eclass API in
>> EAPI ${EAPI} not yet established." esac
> 
> sounds like a useless and annoying check for just exporting one
> function
> 

Also we have EAPI=5 now, so that check needs to be expanded.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlCQMz0ACgkQ2ugaI38ACPBuuwD+MCMAnbp3d8O/rnTdhNe/W/KW
qIipm9jLbGDf5Hc9w+QBALmbJDmeOc7KUcGellrNFGRS5xWhjhhG9M0z5gb370XR
=WHxK
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass

[Samuli Suominen]

On 30/10/12 22:06, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 30/10/12 03:56 PM, Alexis Ballier wrote:
>> On Tue, 30 Oct 2012 19:08:39 +0000 (UTC) "Samuli Suominen
>> (ssuominen)" <ssuominen@gentoo.org> wrote:
>>
>> [...]
>>>
>>> case ${EAPI:-0} in 0|1|2|3|4) ;; *) die "${ECLASS}.eclass API in
>>> EAPI ${EAPI} not yet established." esac
>>
>> sounds like a useless and annoying check for just exporting one
>> function
>>
>
> Also we have EAPI=5 now, so that check needs to be expanded.

already done :)