Re: [gentoo-portage-dev] [PATCH] Use env to find python

[Sid Spry]

On Tue, Jun 16, 2020, at 3:57 PM, Michał Górny wrote:
> On Tue, 2020-06-16 at 15:19 -0400, Mike Gilbert wrote:
> > On Tue, Jun 16, 2020 at 1:55 PM Zac Medico  wrote:
> > > On 6/16/20 10:46 AM, Mike Gilbert wrote:
> > > > On Tue, Jun 16, 2020 at 1:45 PM Mike Gilbert  wrote:
> > > > > On Mon, Jun 15, 2020 at 9:39 AM Sid Spry  wrote:
> > > > > > On Mon, Jun 15, 2020, at 2:36 AM, Ulrich Mueller wrote:
> > > > > > > But we know that it is in /usr/bin, so why add yet another 
> > > > > > > indirection?
> > > > > > > 
> > > > > > > Attachments:
> > > > > > > * signature.asc
> > > > > > 
> > > > > > Ah, sorry -- I forgot to note this here. If you wish to support 
> > > > > > prefix it is possible it may not be in /usr/bin. Granted I am not 
> > > > > > sure if the prefix stage3 I was using is old enough to be broken in 
> > > > > > some way, but adding this would prevent future breakage.
> > > > > 
> > > > > The portage ebuild and the python distutils module already take care
> > > > > of updating shebangs at install time.
> > > > 
> > > > I suppose your patch might be useful if you are trying to run portage
> > > > from a git checkout on a prefix system.
> > > > 
> > > 
> > > So, given that the ebuild updates shebangs automatically, should't we
> > > optimize the default shebangs to be as flexible as possible?
> > 
> > Yes, that makes sense.
> > 
> > However, we should test to make sure that distutils is smart enough to
> > parse that "/usr/bin/env -S python" string and replace it with
> > version-specific python shebang.
> > 
> 
> '/usr/bin/env python' (with no extra options) is the portable shebang.
> 

I added `-S` to preserve the options passed via the shebang line. It seems they 
can be left off, does anyone know otherwise?

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Zac Medico]

On 6/16/20 7:47 PM, Michael Lienhardt wrote:
> 
> 
> On 6/16/20 11:59 PM, Zac Medico wrote:
>> On 6/16/20 6:38 PM, Michael Lienhardt wrote:
>>> With the first version of DEPEND, emerge succeed:
>>> # emerge -pv app-misc/dummy-master
>>>
>>> These are the packages that would be merged, in order:
>>>
>>> Calculating dependencies... done!
>>> [ebuild  N ] app-misc/dummy-slave-2::gentoo  USE="-static-libs" 0 KiB
>>> [ebuild  N ] app-misc/dummy-master-1::gentoo  USE="-static-libs" 0 KiB
>>
>> This success is expected, yes? Do you suggest to change the behavior
>> somehow?
> 
> The way I interpret the PMS, this success is not expected:
>  the atom ">=app-misc/dummy-slave-1" matches the cpv "app-misc/dummy-slave-1" 
> which does not contains the use flag 'static-libs',
>  and thus I expected a 'missing use flag' error.

For this calculation, it would be a waste of time to read the IUSE
metadata for app-misc/dummy-slave-1, since app-misc/dummy-slave-2 is the
highest available version.

I hope that PMS does not specify that package managers must read IUSE
metadata for irrelevant package versions!

> I'm not suggesting to change the behavior of emerge, I'm saying that:
>  - the way I read the PMS, I expect behavior A, but in practice, I see 
> behavior B.
>  - what does the portage devs / PMS gurus think about that?
> - is my understanding of the PMS wrong, and it actually says "behavior B 
> is expected"?
> - if yes, where did I fail in my understanding?
> - if no, should emerge or the PMS be updated so they both describe the 
> same behavior?
>  - I will implement your ruling in my tool, which I try to match as closely 
> as possible to the PMS

In this context I think the spirit of what PMS says is that the package
manager should emit some kind of warning message if it finds missing
IUSE. Now, in the example above, if the package manager has no reason to
examine the IUSE metadata of app-misc/dummy-slave-1 because
app-misc/dummy-slave-2 is the highest available version, then there's no
opportunity for it to emit a warning message.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Michael Lienhardt]

On 6/16/20 11:59 PM, Zac Medico wrote:
> On 6/16/20 6:38 PM, Michael Lienhardt wrote:
>> With the first version of DEPEND, emerge succeed:
>> # emerge -pv app-misc/dummy-master
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>> [ebuild  N ] app-misc/dummy-slave-2::gentoo  USE="-static-libs" 0 KiB
>> [ebuild  N ] app-misc/dummy-master-1::gentoo  USE="-static-libs" 0 KiB
> 
> This success is expected, yes? Do you suggest to change the behavior
> somehow?

The way I interpret the PMS, this success is not expected:
 the atom ">=app-misc/dummy-slave-1" matches the cpv "app-misc/dummy-slave-1" 
which does not contains the use flag 'static-libs',
 and thus I expected a 'missing use flag' error.
I'm not suggesting to change the behavior of emerge, I'm saying that:
 - the way I read the PMS, I expect behavior A, but in practice, I see behavior 
B.
 - what does the portage devs / PMS gurus think about that?
- is my understanding of the PMS wrong, and it actually says "behavior B is 
expected"?
- if yes, where did I fail in my understanding?
- if no, should emerge or the PMS be updated so they both describe the same 
behavior?
 - I will implement your ruling in my tool, which I try to match as closely as 
possible to the PMS

>> With the second version of DEPEND, emerge fails:
>> # emerge -pv app-misc/dummy-master
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>>
>> emerge: there are no ebuilds built with USE flags to satisfy 
>> "=app-misc/dummy-slave-1[static-libs?]".
>> !!! One of the following packages is required to complete your request:
>> - app-misc/dummy-slave-1::gentoo (Missing IUSE: static-libs)
>> (dependency required by "app-misc/dummy-master-1::gentoo" [ebuild])
>> (dependency required by "app-misc/dummy-master" [argument])
> 
> This failure is expected, yes? Do you suggest to change the behavior
> somehow?

The way I interpret the PMS, this failure is expected.

I'm sorry if I'm not always clear, I try to be, and many thanks to take the 
time to answer my (unexpected and strange) questions.

Best,
Michael

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Zac Medico]

On 6/16/20 6:38 PM, Michael Lienhardt wrote:
> 
> 
> On 6/16/20 9:31 PM, Zac Medico wrote:
>> On 6/16/20 11:07 PM, Michael Lienhardt wrote:
>>> I'm sorry, my client didn't allow to send plain text email anymore...
>>>
>>> So, here is my original email.
>>>
>>> Dear all,
>>>
>>> My bad for not noticing it sooner, but when there is a dependency like 
>>> ">=sys-fs/udev-208-r1:0/0[static-libs?]" (that occurs in 
>>> virtual/libgudev-215-r3),
>>>  since 'static-libs' is not a use flags of sys-fs/udev-242, that cpv is 
>>> silently not considered during dependency solving by emerge.
>>> However, the PMS states:
>>>  - it is an error for a use dependency to be applied to an ebuild which 
>>> does not have the flag in question in IUSE_REFERENCEABLE
>>>  - For EAPIs listed in table 5.4 as not supporting profile defined IUSE 
>>> injection, IUSE_REFERENCEABLE is equal to the calculated IUSE value. For 
>>> EAPIs where profile defined IUSE injection is supported, IUSE_REFERENCEABLE 
>>> is equal to IUSE_EFFECTIVE
>>> And 'static-libs' is not in the IUSE_EFFECTIVE of sys-fs/udev-242 (that 
>>> ebuild has EAPI=6).
>>> So it seems to me that this current behavior of emerge should be considered 
>>> an error, no? Or the PMS should be updated?

Yes, according to PMS it's a "error" but emerge has never reported it as
such. Adding an error message to emerge sounds fine to me.

>>> This is related to the tool I'm working on: should my tool allow this 
>>> behavior, or fail like it is currently doing (I guess the former)?
> 
>> It's valid as a 4-style dependency with use-dep-defaults.

Actually, it doesn't have use-dep-defaults but somehow my brain
associated it with that because you were talking about IUSE.

> I know. Except that in virtual/libgudev-215-r3.ebuild we have in the DEPEND:
>  
> >=sys-fs/udev-208-r1:0/0[${MULTILIB_USEDEP},gudev(-),introspection(-)?,static-libs?]
> It is a 2-style dependency (following the PMS).
> 
> I checked with 3 dummy packages
> 
> 1. app-misc/dummy-master-1
> EAPI=6
> SLOT=0
> KEYWORDS="amd64"
> IUSE="static-libs"
> DEPEND=">=app-misc/dummy-slave-1[static-libs?]"
> #DEPEND="=app-misc/dummy-slave-1[static-libs?]"
> 
> 2. app-misc/dummy-slave-1
> EAPI=6
> SLOT=0
> KEYWORDS="amd64"
> IUSE=""
> DEPEND=""
> 
> 3. app-misc/dummy-slave-2
> EAPI=6
> SLOT=0
> KEYWORDS="amd64"
> IUSE="static-libs"
> DEPEND=""
> 
> With the first version of DEPEND, emerge succeed:
> # emerge -pv app-misc/dummy-master
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild  N ] app-misc/dummy-slave-2::gentoo  USE="-static-libs" 0 KiB
> [ebuild  N ] app-misc/dummy-master-1::gentoo  USE="-static-libs" 0 KiB

This success is expected, yes? Do you suggest to change the behavior
somehow?

> With the second version of DEPEND, emerge fails:
> # emerge -pv app-misc/dummy-master
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> 
> emerge: there are no ebuilds built with USE flags to satisfy 
> "=app-misc/dummy-slave-1[static-libs?]".
> !!! One of the following packages is required to complete your request:
> - app-misc/dummy-slave-1::gentoo (Missing IUSE: static-libs)
> (dependency required by "app-misc/dummy-master-1::gentoo" [ebuild])
> (dependency required by "app-misc/dummy-master" [argument])

This failure is expected, yes? Do you suggest to change the behavior
somehow?
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Michael Lienhardt]

On 6/16/20 9:31 PM, Zac Medico wrote:
> On 6/16/20 11:07 PM, Michael Lienhardt wrote:
>> I'm sorry, my client didn't allow to send plain text email anymore...
>> 
>> So, here is my original email.
>> 
>> Dear all,
>> 
>> My bad for not noticing it sooner, but when there is a dependency like 
>> ">=sys-fs/udev-208-r1:0/0[static-libs?]" (that occurs in 
>> virtual/libgudev-215-r3),
>>  since 'static-libs' is not a use flags of sys-fs/udev-242, that cpv is 
>> silently not considered during dependency solving by emerge.
>> However, the PMS states:
>>  - it is an error for a use dependency to be applied to an ebuild which does 
>> not have the flag in question in IUSE_REFERENCEABLE
>>  - For EAPIs listed in table 5.4 as not supporting profile defined IUSE 
>> injection, IUSE_REFERENCEABLE is equal to the calculated IUSE value. For 
>> EAPIs where profile defined IUSE injection is supported, IUSE_REFERENCEABLE 
>> is equal to IUSE_EFFECTIVE
>> And 'static-libs' is not in the IUSE_EFFECTIVE of sys-fs/udev-242 (that 
>> ebuild has EAPI=6).
>> So it seems to me that this current behavior of emerge should be considered 
>> an error, no? Or the PMS should be updated?
>> 
>> This is related to the tool I'm working on: should my tool allow this 
>> behavior, or fail like it is currently doing (I guess the former)?

> It's valid as a 4-style dependency with use-dep-defaults.

I know. Except that in virtual/libgudev-215-r3.ebuild we have in the DEPEND:
 >=sys-fs/udev-208-r1:0/0[${MULTILIB_USEDEP},gudev(-),introspection(-)?,static-libs?]
It is a 2-style dependency (following the PMS).

I checked with 3 dummy packages

1. app-misc/dummy-master-1
EAPI=6
SLOT=0
KEYWORDS="amd64"
IUSE="static-libs"
DEPEND=">=app-misc/dummy-slave-1[static-libs?]"
#DEPEND="=app-misc/dummy-slave-1[static-libs?]"

2. app-misc/dummy-slave-1
EAPI=6
SLOT=0
KEYWORDS="amd64"
IUSE=""
DEPEND=""

3. app-misc/dummy-slave-2
EAPI=6
SLOT=0
KEYWORDS="amd64"
IUSE="static-libs"
DEPEND=""

With the first version of DEPEND, emerge succeed:
# emerge -pv app-misc/dummy-master

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N ] app-misc/dummy-slave-2::gentoo  USE="-static-libs" 0 KiB
[ebuild  N ] app-misc/dummy-master-1::gentoo  USE="-static-libs" 0 KiB


With the second version of DEPEND, emerge fails:
# emerge -pv app-misc/dummy-master

These are the packages that would be merged, in order:

Calculating dependencies... done!

emerge: there are no ebuilds built with USE flags to satisfy 
"=app-misc/dummy-slave-1[static-libs?]".
!!! One of the following packages is required to complete your request:
- app-misc/dummy-slave-1::gentoo (Missing IUSE: static-libs)
(dependency required by "app-misc/dummy-master-1::gentoo" [ebuild])
(dependency required by "app-misc/dummy-master" [argument])



Michael

[gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[michael.lienhardt]

‌Dear 
all,

My bad for not noticing it sooner, but when there is a dependency like 
"=sys-fs/udev-208-r1:0/0[static-libs?]" (that occurs in 
virtual/libgudev-215-r3), since 'static-libs' is not a use flags of 
sys-fs/udev-242, it is silently not considered during dependency solving by 
emerge.
However, the PMS states:
- it is an error for a use dependency to be applied to an ebuild which 
does not have the flag in question in IUSE_REFERENCEABLE
- For EAPIs listed in tablehttps://dev.gentoo.org/~ulm/pms/head/pms.html#x1-56001r4;>5.4 as not 
supporting profile defined IUSE injection, IUSE_REFERENCEABLE is equal to the calculated IUSE value. For EAPIs where profile defined IUSE injection is supported, IUSE_REFERENCEABLE is equal to IUSE_EFFECTIVE
And 'static-libs' is not in the IUSE_EFFECTIVE of sys-fs/udev-242 (that 
ebuild has EAPI=6).
So it seems to me that this current behavior of emerge should be considered an 
error, no? Or the PMS should be updated?

Best,
Michael

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Zac Medico]

On 6/16/20 11:43 AM, michael.lienhardt wrote:
> ‌Dear all,
> 
> My bad for not noticing it sooner, but when there is a dependency like
> ">=sys-fs/udev-208-r1:0/0[static-libs?]" (that occurs in
> virtual/libgudev-215-r3), since 'static-libs' is not a use flags of
> sys-fs/udev-242, it is silently not considered during dependency solving
> by emerge.
> However, the PMS states:
>  - it is an error for a use dependency to be applied to an ebuild which
> does not have the flag in question in IUSE_REFERENCEABLE
>  - For EAPIs listed in table 5.4
>  as not
> supporting profile defined IUSE injection, IUSE_REFERENCEABLE is equal
> to the calculated IUSE value. For EAPIs where profile defined IUSE
> injection is supported, IUSE_REFERENCEABLE is equal to IUSE_EFFECTIVE
> And 'static-libs' is not in the IUSE_EFFECTIVE of sys-fs/udev-242 (that
> ebuild has EAPI=6).
> So it seems to me that this current behavior of emerge should be
> considered an error, no? Or the PMS should be updated?

It's valid as a 4-style dependency with use-dep-defaults.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Michael Lienhardt]

I'm sorry, my client didn't allow to send plain text email anymore...

So, here is my original email.

Dear all,

My bad for not noticing it sooner, but when there is a dependency like 
">=sys-fs/udev-208-r1:0/0[static-libs?]" (that occurs in 
virtual/libgudev-215-r3),
 since 'static-libs' is not a use flags of sys-fs/udev-242, that cpv is 
silently not considered during dependency solving by emerge.
However, the PMS states:
 - it is an error for a use dependency to be applied to an ebuild which does 
not have the flag in question in IUSE_REFERENCEABLE
 - For EAPIs listed in table 5.4 as not supporting profile defined IUSE 
injection, IUSE_REFERENCEABLE is equal to the calculated IUSE value. For EAPIs 
where profile defined IUSE injection is supported, IUSE_REFERENCEABLE is equal 
to IUSE_EFFECTIVE
And 'static-libs' is not in the IUSE_EFFECTIVE of sys-fs/udev-242 (that ebuild 
has EAPI=6).
So it seems to me that this current behavior of emerge should be considered an 
error, no? Or the PMS should be updated?

This is related to the tool I'm working on: should my tool allow this behavior, 
or fail like it is currently doing (I guess the former)?

Best,
Michael


On 6/16/20 7:42 PM, Brian Dolbec wrote:
> 
> Please do NOT send html emails.  text only please
> 

Re: [gentoo-portage-dev] [PATCH] Use env to find python

[Michał Górny]

On Tue, 2020-06-16 at 15:19 -0400, Mike Gilbert wrote:
> On Tue, Jun 16, 2020 at 1:55 PM Zac Medico  wrote:
> > On 6/16/20 10:46 AM, Mike Gilbert wrote:
> > > On Tue, Jun 16, 2020 at 1:45 PM Mike Gilbert  wrote:
> > > > On Mon, Jun 15, 2020 at 9:39 AM Sid Spry  wrote:
> > > > > On Mon, Jun 15, 2020, at 2:36 AM, Ulrich Mueller wrote:
> > > > > > But we know that it is in /usr/bin, so why add yet another 
> > > > > > indirection?
> > > > > > 
> > > > > > Attachments:
> > > > > > * signature.asc
> > > > > 
> > > > > Ah, sorry -- I forgot to note this here. If you wish to support 
> > > > > prefix it is possible it may not be in /usr/bin. Granted I am not 
> > > > > sure if the prefix stage3 I was using is old enough to be broken in 
> > > > > some way, but adding this would prevent future breakage.
> > > > 
> > > > The portage ebuild and the python distutils module already take care
> > > > of updating shebangs at install time.
> > > 
> > > I suppose your patch might be useful if you are trying to run portage
> > > from a git checkout on a prefix system.
> > > 
> > 
> > So, given that the ebuild updates shebangs automatically, should't we
> > optimize the default shebangs to be as flexible as possible?
> 
> Yes, that makes sense.
> 
> However, we should test to make sure that distutils is smart enough to
> parse that "/usr/bin/env -S python" string and replace it with
> version-specific python shebang.
> 

'/usr/bin/env python' (with no extra options) is the portable shebang.

-- 
Best regards,
Michał Górny



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

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Brian Dolbec]

On Tue, 16 Jun 2020 20:43:44 +0200 (CEST)
"michael.lienhardt"  wrote:

> ‌Dear all, 
> My bad for not noticing it sooner, but when there is a dependency
> like "=sys-fs/udev-208-r1:0/0[static-libs?]" (that occurs in
> virtual/libgudev-215-r3), since 'static-libs' is not a use flags of
> sys-fs/udev-242, it is silently not considered during dependency
> solving by emerge. However, the PMS states: - it is an
> error for a use dependency to be applied to an ebuild which does not
> have the flag in question in  class="ectt-1000">IUSE_REFERENCEABLE - For EAPIs
> listed in table href="https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-56001r4;>5.4
> as not supporting profile defined IUSE
> injection, IUSE_REFERENCEABLE
> is equal to the calculated IUSE
> value. For EAPIs where profile defined  class="ectt-1000">IUSE injection is supported,  class="ectt-1000">IUSE_REFERENCEABLE is equal to  class="ectt-1000">IUSE_EFFECTIVE And 'static-libs' is not in the
> IUSE_EFFECTIVE of sys-fs/udev-242 (that ebuild has
> EAPI=6). So it seems to me that this current behavior of emerge
> should be considered an error, no? Or the PMS should be updated?
>  Best, Michael

Please do NOT send html emails.  text only please

Re: [gentoo-portage-dev] [PATCH] Use env to find python

[Mike Gilbert]

On Tue, Jun 16, 2020 at 1:55 PM Zac Medico  wrote:
>
> On 6/16/20 10:46 AM, Mike Gilbert wrote:
> > On Tue, Jun 16, 2020 at 1:45 PM Mike Gilbert  wrote:
> >>
> >> On Mon, Jun 15, 2020 at 9:39 AM Sid Spry  wrote:
> >>>
> >>> On Mon, Jun 15, 2020, at 2:36 AM, Ulrich Mueller wrote:
>  But we know that it is in /usr/bin, so why add yet another indirection?
> 
>  Attachments:
>  * signature.asc
> >>>
> >>> Ah, sorry -- I forgot to note this here. If you wish to support prefix it 
> >>> is possible it may not be in /usr/bin. Granted I am not sure if the 
> >>> prefix stage3 I was using is old enough to be broken in some way, but 
> >>> adding this would prevent future breakage.
> >>
> >> The portage ebuild and the python distutils module already take care
> >> of updating shebangs at install time.
> >
> > I suppose your patch might be useful if you are trying to run portage
> > from a git checkout on a prefix system.
> >
>
> So, given that the ebuild updates shebangs automatically, should't we
> optimize the default shebangs to be as flexible as possible?

Yes, that makes sense.

However, we should test to make sure that distutils is smart enough to
parse that "/usr/bin/env -S python" string and replace it with
version-specific python shebang.

Re: [gentoo-portage-dev] [PATCH] Use env to find python

[Zac Medico]

On 6/16/20 10:46 AM, Mike Gilbert wrote:
> On Tue, Jun 16, 2020 at 1:45 PM Mike Gilbert  wrote:
>>
>> On Mon, Jun 15, 2020 at 9:39 AM Sid Spry  wrote:
>>>
>>> On Mon, Jun 15, 2020, at 2:36 AM, Ulrich Mueller wrote:
 But we know that it is in /usr/bin, so why add yet another indirection?

 Attachments:
 * signature.asc
>>>
>>> Ah, sorry -- I forgot to note this here. If you wish to support prefix it 
>>> is possible it may not be in /usr/bin. Granted I am not sure if the prefix 
>>> stage3 I was using is old enough to be broken in some way, but adding this 
>>> would prevent future breakage.
>>
>> The portage ebuild and the python distutils module already take care
>> of updating shebangs at install time.
> 
> I suppose your patch might be useful if you are trying to run portage
> from a git checkout on a prefix system.
> 

So, given that the ebuild updates shebangs automatically, should't we
optimize the default shebangs to be as flexible as possible?
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH 1/1] repoman: deprecate netsurf.eclass.

[Zac Medico]

On 6/16/20 10:36 AM, Michael Orlitzky wrote:
> While investigating bug 489542, it became clear that the netsurf
> eclass is deprecated in spirit if not in fact. All of the newer
> netsurf ebuilds use a custom function loaded from a script that is
> shipped in netsurf-buildsystem's $FILESDIR to do (some of) what the
> eclass used to do. That function probably does belong in an eclass,
> but at this point, we should throw this thing out and start from
> scratch.
> 
> By deprecating the eclass, we make sure that no one else inherits it
> during the time it takes to purge the two remaining consumers. Then,
> once those are gone, the build system script magic can be put back
> into an eclass, and its consumers updated one-at-a-time.
> 
> Bug: https://bugs.gentoo.org/489542
> Bug: https://bugs.gentoo.org/637824
> Signed-off-by: Michael Orlitzky 
> ---
>  repoman/lib/repoman/modules/linechecks/deprecated/inherit.py | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py 
> b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
> index 5848a0c37..60410347b 100644
> --- a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
> +++ b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
> @@ -33,6 +33,7 @@ class InheritDeprecated(LineCheck):
>   "gst-plugins10": "gstreamer",
>   "ltprune": False,
>   "mono": "mono-env",
> + "netsurf": False,
>   "python": "python-r1 / python-single-r1 / python-any-r1",
>   "ruby": "ruby-ng",
>   "user": "GLEP 81",
> 

Thanks, applied:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=a73024729860f9224b8d1660d24c450080b67d9f
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] Use env to find python

[Mike Gilbert]

On Tue, Jun 16, 2020 at 1:45 PM Mike Gilbert  wrote:
>
> On Mon, Jun 15, 2020 at 9:39 AM Sid Spry  wrote:
> >
> > On Mon, Jun 15, 2020, at 2:36 AM, Ulrich Mueller wrote:
> > > But we know that it is in /usr/bin, so why add yet another indirection?
> > >
> > > Attachments:
> > > * signature.asc
> >
> > Ah, sorry -- I forgot to note this here. If you wish to support prefix it 
> > is possible it may not be in /usr/bin. Granted I am not sure if the prefix 
> > stage3 I was using is old enough to be broken in some way, but adding this 
> > would prevent future breakage.
>
> The portage ebuild and the python distutils module already take care
> of updating shebangs at install time.

I suppose your patch might be useful if you are trying to run portage
from a git checkout on a prefix system.

Re: [gentoo-portage-dev] [PATCH] Use env to find python

[Mike Gilbert]

On Mon, Jun 15, 2020 at 9:39 AM Sid Spry  wrote:
>
> On Mon, Jun 15, 2020, at 2:36 AM, Ulrich Mueller wrote:
> > But we know that it is in /usr/bin, so why add yet another indirection?
> >
> > Attachments:
> > * signature.asc
>
> Ah, sorry -- I forgot to note this here. If you wish to support prefix it is 
> possible it may not be in /usr/bin. Granted I am not sure if the prefix 
> stage3 I was using is old enough to be broken in some way, but adding this 
> would prevent future breakage.

The portage ebuild and the python distutils module already take care
of updating shebangs at install time.

[gentoo-portage-dev] [PATCH 1/1] repoman: deprecate netsurf.eclass.

[Michael Orlitzky]

While investigating bug 489542, it became clear that the netsurf
eclass is deprecated in spirit if not in fact. All of the newer
netsurf ebuilds use a custom function loaded from a script that is
shipped in netsurf-buildsystem's $FILESDIR to do (some of) what the
eclass used to do. That function probably does belong in an eclass,
but at this point, we should throw this thing out and start from
scratch.

By deprecating the eclass, we make sure that no one else inherits it
during the time it takes to purge the two remaining consumers. Then,
once those are gone, the build system script magic can be put back
into an eclass, and its consumers updated one-at-a-time.

Bug: https://bugs.gentoo.org/489542
Bug: https://bugs.gentoo.org/637824
Signed-off-by: Michael Orlitzky 
---
 repoman/lib/repoman/modules/linechecks/deprecated/inherit.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py 
b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
index 5848a0c37..60410347b 100644
--- a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
+++ b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
@@ -33,6 +33,7 @@ class InheritDeprecated(LineCheck):
"gst-plugins10": "gstreamer",
"ltprune": False,
"mono": "mono-env",
+   "netsurf": False,
"python": "python-r1 / python-single-r1 / python-any-r1",
"ruby": "ruby-ng",
"user": "GLEP 81",
-- 
2.26.2

[gentoo-dev] Re: [PATCH] netsurf.eclass: remove EROOT from PREFIX

[Michael Orlitzky]

On 2020-06-14 16:30, a...@freemail.hu wrote:
> 
> Suggested fix for: https://bugs.gentoo.org/show_bug.cgi?id=489542
> Bug 489542 - netsurf.eclass should not include EROOT in PREFIX
> 

Well, I've applied this as well as some other fixes for the eclass, only
to find that the problem has been relocated from netsurf.eclass into
/usr/share/netsurf-buildsystem/gentoo-helpers.sh (which it looks like is
just an out-of-tree eclass?).

There are only two ebuilds left in the tree using netsurf.eclass:

  * dev-libs/libparserutils-0.2.3 (superseded by v0.2.4-r1)
  * net-libs/libhubbub-0.3.3 (superseded by v0.3.6)

The first one needs a stabilization, but then the old versions can be
removed and netsurf.eclass can be last-rited. That leaves us with a
similar problem in gentoo-helpers.sh, which does...

  NSSHARED="${EROOT}"/usr/share/netsurf-buildsystem
  LIBDIR="$(get_libdir)"
  PREFIX="${EROOT}/usr"

Digging into the netsurf buildsystem it looks like PREFIX is already
pre/appended to the uses of NSSHARED and DESTDIR. So I think we should
have instead,

  LIBDIR="$(get_libdir)"
  PREFIX="${EPREFIX}/usr"

and then the ebuilds themselves need to be fixed. For example,

  _emake TARGET=framebuffer DESTDIR="${ED}" install

should have DESTDIR="${D}" instead, because the buildsystem already
installs to $(DESTDIR)$(PREFIX). As it is, you're getting the "E" twice.

Removing the EROOT (as in the proposed patch) would also fix this, but
the standard pattern for ebuilds is to use the "E" variables at
configure-time, and only $D at install-time.