Re: cygutils Postinstall Script Errors With Exit Code 128

Re: cygutils Postinstall Script Errors With Exit Code 128

[Reini Urban]

On Tue, May 28, 2013 at 2:43 Paul.Nickerson wrote:
> I am attempting to install Cygwin, and am getting errors near the end of
> the process. I am using version 2.774 of setup.exe on Microsoft Windows
> Server 2003 R2 Datacenter x64 Edition Service Pack 2 and the default
> Cygwin packages. This is an Amazon AWS EC2 instance, and I am remote
> desktopping in. In the Cygwin Setup GUI, after it goes through the install
> procedure, I get a window titled Postinstall script errors, with the below
> output text:
>
> Package: base-cygwin
>         000-cygwin-post-install.sh exit code 128
> Package: terminfo
>         terminfo.sh exit code 128
> Package: bash
>         bash.sh exit code 128
> Package: coreutils
>         coreutils.sh exit code 128
> Package: _autorebase
>         autorebase.bat exit code -1073741819
> Package: base-files
>         base-files-profile.sh exit code 2816
>         base-files-mketc.sh exit code 128
> Package: cygutils
>         cygutils.sh exit code 127
> Package: man
>         man.sh exit code 128

I got the cygutils postinstall error also, caused by missing dependencies.

$ cat /etc/postinstall/cygutils.sh
/usr/bin/update-desktop-database
/usr/bin/update-mime-database /usr/share/mime

both scripts do not exist, and are no cygutils reqs.
please test against it.
like:
test -f /usr/bin/update-desktop-database && /usr/bin/update-desktop-database
test -f /usr/bin/update-mime-database && /usr/bin/update-mime-database
/usr/share/mime

> If I then open Cygwin Terminal using the Desktop shortcut, I get a window
> titled "-sh" and a prompt that says "-sh-4.1$". The command "ls" returns
> "-sh: ls: command not found", but echo works. I have tried re-running
> setup.exe, removing the cygwin directory, re-downloading the setup.exe,
> removing HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygwin from the registry,
> setting "Turn on DEP for essential Windows programs and services only" and
> rebooting, altering file and folder permissions, deleting the cache and
> using different mirrors, and using rdesktop in CentOS vs. mstsc.exe in
> Windows to remote desktop in, but none of this changes the behavior.
>
> I have an odd and possibly related behavior. If I open Command Prompt, run
> C:\cygwin\bin\bash.exe --norc --noprofile
> to get a "bash-4.1$" prompt, then in there run
> if [ "foo" = "foo" ]; then echo "Expression evaluated as true."; fi
> the bash prompt will exit back to command prompt, and %ERRORLEVEL% has
> been set to 128.
> Running that if statement in the window brought up by the Cygwin Terminal
> Desktop shortcut will sometimes make the window close, but not always. I
> have not explored how I might be triggering the Desktop shortcut to work
> or not work.
>
> I have attached setup.log and setup.log.full.
>
> When I run cygcheck -s -v -r > cygcheck.out, it hangs and does not exit.
> Checking Task Manager, I see that it's using ~45% CPU (I have 2 virtual
> cores). It does write some things out to cygcheck.out, which I have
> attached. When I run the command in Command Prompt without redirecting
> output to a file, I get a little more information before it hangs, which I
> have copied out of the command prompt and attached as
> cygcheck-no-redirect.out. I do not know why it's saying I have multiple
> cygwin1.dlls on my path. There is only C:\cygwin\bin\cygwin1.dll.
>
> Looking at cygcheck.out, I am running in a Terminal Service session, which
> makes sense as I am remote desktopped in. My problem might be related to
> FAQ #2.14 (http://cygwin.com/faq-nochunks.html#faq.setup.setup-fails-on-ts
> ), but the DEP solution is not helping me. I tried running
> "C:\cygwin\bin>peflags --tsaware=true --tsaware *" in Command Prompt, but
> it did not change anything.

--
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygutils Postinstall Script Errors With Exit Code 128

[Paul.Nickerson]

cygwin-owner at cygwin dot com wrote on 05/29/2013 11:47:20 AM:

> From: Reini Urban <rurban at x-ray dot at>
> To: The Cygwin Mailing List <cygwin at cygwin dot com>, Charles Wilson 
> <cygwin at cwilson dot fastmail dot fm>, 
> Date: 05/29/2013 11:47 AM
> Subject: Re: cygutils Postinstall Script Errors With Exit Code 128
> Sent by: cygwin-owner at cygwin dot com
> 
> On Tue, May 28, 2013 at 2:43 Paul.Nickerson wrote:
<snip>
> > Package: cygutils
> >         cygutils.sh exit code 127
> > Package: man
> >         man.sh exit code 128
> 
> I got the cygutils postinstall error also, caused by missing 
dependencies.
> 
> $ cat /etc/postinstall/cygutils.sh
> /usr/bin/update-desktop-database
> /usr/bin/update-mime-database /usr/share/mime
> 
> both scripts do not exist, and are no cygutils reqs.
> please test against it.
> like:
> test -f /usr/bin/update-desktop-database && 
/usr/bin/update-desktop-database
> test -f /usr/bin/update-mime-database && /usr/bin/update-mime-database
> /usr/share/mime
<snip>
> --
> Reini Urban
> http://cpanel.net/   http://www.perl-compiler.org/

Those update-* files do not exist for me either. However, I think my 
problems are starting before cygutils.sh returns with exit code 127.
Are you asking me to test that the files exist before I run them? Or, are 
you asking the Cygwin maintainers to have their cygutils script do so?

 ~ Paul

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]

[Charles Wilson]

On 5/29/2013 11:47 AM, Reini Urban wrote:
> I got the cygutils postinstall error also, caused by missing dependencies.
>
> $ cat /etc/postinstall/cygutils.sh
> /usr/bin/update-desktop-database
> /usr/bin/update-mime-database /usr/share/mime
>
> both scripts do not exist, and are no cygutils reqs.
> please test against it.
> like:
> test -f /usr/bin/update-desktop-database && /usr/bin/update-desktop-database
> test -f /usr/bin/update-mime-database && /usr/bin/update-mime-database
> /usr/share/mime
>

Known issue, waiting for cygport fix.  cygutils relies on cygport 
auto-generating the postinstall scripts which invoke those tools. 
Cygport does this because the install package contains the following two 
files:

/usr/share/applications/cygstart.desktop
/usr/share/mime/packages/cygutils.xml

...and it generates the postinstall script unconditionally (e.g. I can't 
turn it off) and the generated postinstall scripts themselves call the 
tools unconditionally.  Cygport also automatically adds the packages 
which contain those tools to the requires: field of the setup.hint, 
so...under normal circumstances, everything should be fine.

However, at user request I've manually removed the requires: line, 
because the addition of these two files to the cygutils package 
shouldn't have the effect of pulling *PERL* into the Base category. I 
assumed we'd live with the semi-brokenness for a few days, until...

...I'm waiting for Yaakov to say whether this should be "fixed" in 
cygport [1], or if I should override all the auto-generation stuff by 
manually creating an explicit postinstall script (with suitable tool 
existence checks) and setup.hint.

[1] arguably, cygport is doing the right thing: (1) ensuring that the 
tools are called to install the two files, and (2) ensuring that the 
packages which contain those tools are listed in the requires: line. So, 
I'm not sure what the "correct" fix should be, and am waiting for 
Yaakov's input.


See: http://cygwin.com/ml/cygwin/2013-05/msg00211.html

--
Chuck


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]

[Yaakov (Cygwin/X)]

Sorry for missing this before.

On 2013-05-29 17:43, Charles Wilson wrote:
> Known issue, waiting for cygport fix.  cygutils relies on cygport
> auto-generating the postinstall scripts which invoke those tools.
> Cygport does this because the install package contains the following two
> files:
>
> /usr/share/applications/cygstart.desktop
> /usr/share/mime/packages/cygutils.xml
>
> ...and it generates the postinstall script unconditionally (e.g. I can't
> turn it off) and the generated postinstall scripts themselves call the
> tools unconditionally.  Cygport also automatically adds the packages
> which contain those tools to the requires: field of the setup.hint,
> so...under normal circumstances, everything should be fine.

Right, because packages providing those kind of files usually need those 
commands to be run in order for them to take effect; see below.

> However, at user request I've manually removed the requires: line,
> because the addition of these two files to the cygutils package
> shouldn't have the effect of pulling *PERL* into the Base category. I
> assumed we'd live with the semi-brokenness for a few days, until...

Perl?  I thought it was Python, due to a false positive in the 
dependency detection with glib2.0, which I fixed on sourceware.

But now that you mention it, is cygutils *supposed* to be in Base?  It 
is marked category: Utils, but seems to be pulled into Base only because 
of cygwin-doc (which *is* in Base, oddly enough; shouldn't it just be 
Doc?) listing it as a dependency.

> ...I'm waiting for Yaakov to say whether this should be "fixed" in
> cygport [1], or if I should override all the auto-generation stuff by
> manually creating an explicit postinstall script (with suitable tool
> existence checks) and setup.hint.

The "problem" here is that cygutils is not primarily a desktop-oriented 
package.  Most packages providing XDG menu and mime entries *are*, so 
these dependencies not only mandatory, but quite modest by those 
standards.  I added these files because it allows better integration 
between desktop file managers 
(Nautilus/Caja/Thunar/PCManFM/Dolphin/etc.) and Windows, e.g. making it 
easy to launch an EXE/MSI installer from one's Downloads folder. 
However, most people use cygutils outside of the desktop, so 
particularly if its pulled into Base, these deps would be more than the 
bare-minimal system.

If cygutils should be in Base, the "solution" is probably one of the 
following:

* provide these files (and postinstall scripts) in a 'cygutils-x11' 
subpackage;

* OR move them to another package (not sure which yet) which will 
already be installed in desktop scenarios, and adding cygutils as a 
dependency thereto.

For now, should we go with the first option?


Yaakov


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]

[Corinna Vinschen]

On May 29 18:51, Yaakov (Cygwin/X) wrote:
> But now that you mention it, is cygutils *supposed* to be in Base?
> It is marked category: Utils, but seems to be pulled into Base only
> because of cygwin-doc (which *is* in Base, oddly enough; shouldn't
> it just be Doc?) listing it as a dependency.

That sounds strange.  Was cygwin-doc always in Base?  It contains the
cygwin docs and basic man pages but that doesn't really  qualify for the
Base category.

Also, why does cygwin-doc depend on cygutils at all?  It only contains
info and man pages, so the deps should be coreutils and man, but nothing
else, AFAICS.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]

[Charles Wilson]

On 5/29/2013 7:51 PM, Yaakov (Cygwin/X) wrote:
> On 2013-05-29 17:43, Charles Wilson wrote:
>> /usr/share/applications/cygstart.desktop
>> /usr/share/mime/packages/cygutils.xml
>
> Right, because packages providing those kind of files usually need those
> commands to be run in order for them to take effect; see below.
>
>> However, at user request I've manually removed the requires: line,
>> because the addition of these two files to the cygutils package
>> shouldn't have the effect of pulling *PERL* into the Base category. I
>> assumed we'd live with the semi-brokenness for a few days, until...
>
> Perl?  I thought it was Python, due to a false positive in the
> dependency detection with glib2.0, which I fixed on sourceware.

You're right, it was python. One of the gigantic "p*" packages, anyway...

> But now that you mention it, is cygutils *supposed* to be in Base?  It
> is marked category: Utils, but seems to be pulled into Base only because
> of cygwin-doc (which *is* in Base, oddly enough; shouldn't it just be
> Doc?) listing it as a dependency.

I've got email from 2006 [1] where the following was mentioned: "Since 
cygutils is required by some packages in the Base category, ..." so 
maybe at one point, several packages required it.

It's also possible, at one point, that we explicitly wanted it to be in 
that category, as it provided our d2u/u2d tools. Obviously now that we 
have an standalone u2d package that isn't an issue (but I note that 
dos2unix is NOT in Base, but IS listed as requirement for cygutils. So 
if we take action to (effectively) remove cygutils from Base, then 
dos2unix will also go "missing".

> The "problem" here is that cygutils is not primarily a desktop-oriented
> package.  Most packages providing XDG menu and mime entries *are*, so
> these dependencies not only mandatory, but quite modest by those
> standards.  I added these files because it allows better integration
> between desktop file managers
> (Nautilus/Caja/Thunar/PCManFM/Dolphin/etc.) and Windows, e.g. making it
> easy to launch an EXE/MSI installer from one's Downloads folder.
> However, most people use cygutils outside of the desktop, so
> particularly if its pulled into Base, these deps would be more than the
> bare-minimal system.
>
> If cygutils should be in Base, the "solution" is probably one of the
> following:
>
> * provide these files (and postinstall scripts) in a 'cygutils-x11'
> subpackage;
>
> * OR move them to another package (not sure which yet) which will
> already be installed in desktop scenarios, and adding cygutils as a
> dependency thereto.
>
> For now, should we go with the first option?

Yes, that's probably the best way to go. I'll roll a new release with 
that change, for both 32- and 64- cygwin, soon. (Need to investigate the 
recent resurrected report about cygdrop and privelege dropping first).

[1] http://cygwin.com/ml/cygwin-apps/2006-03/msg00117.html

--
Chuck


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]

[Charles Wilson]

On 5/30/2013 5:08 AM, Corinna Vinschen wrote:
> On May 29 18:51, Yaakov (Cygwin/X) wrote:
>> But now that you mention it, is cygutils *supposed* to be in Base?
>> It is marked category: Utils, but seems to be pulled into Base only
>> because of cygwin-doc (which *is* in Base, oddly enough; shouldn't
>> it just be Doc?) listing it as a dependency.
>
> That sounds strange.  Was cygwin-doc always in Base?  It contains the
> cygwin docs and basic man pages but that doesn't really  qualify for the
> Base category.

Over the years, cygutils has "lost" a lot of content to other packages 
(standalone, util-linux, etc), and gained a smaller collection of new 
tools.  In the past, cygutils may have been considered more central than 
its current incarnation deserves.

current contents of cygutils:

banner.exe              getclip.exe             readshortcut.exe
conv.exe                ipck                    semstat.exe
cygdrop.exe             lpr.exe                 semtool.exe
cygicons-0.dll          mkshortcut.exe          shmtool.exe
cygstart.exe            msgtool.exe             winln.exe
dump.exe                putclip.exe

Other than cygstart, cygdrop and lpr(?), and maybe the new winln, I 
can't see that any of those really deserve to be in Base.  If cygwin-doc 
is truly the only thing pulling cygutils into Base, then (a) removing 
cygutils from cygwin-doc's requires:, or (b) removing cygwin-doc from 
Base, would have the (desired?) effect of removing cygutils from Base.

One caveat, mentioned in my other reply: cygutils' own requires: line 
lists dos2unix, so right now a Base install gets that package. This is 
probably desirable, but if we (effectively) remove cygutils from a Base 
install, we probably would want to add dos2unix to Base explicitly.

If we want to include (some subset of) cygutils explicitly in Base, I 
could see splitting into three subpackages:
    cygutils (Base):
       cygdrop cygstart lpr mkshortcut readshortcut winln
    cygutils-extra (Util): [requires: cygutils]
       almost everything else, including documentation and man
       pages (even for the exe's in the Base package)
    cygutils-x11 (X11): [requires: cygutils]
       the two desktop files, and the postinstall scripts that
       handle them
This way, any package that currently requires: cygutils will almost 
certainly get the tool it is looking for, without having to change its 
requires line (and besides, if cygutils is in Base you'd get those anyway).

 > Also, why does cygwin-doc depend on cygutils at all?  It only contains
 > info and man pages, so the deps should be coreutils and man,
 > but nothing else, AFAICS.

Maybe it used to install a shortcut to the documentation into the Start 
Menu, and needed mkshortcut to do so?  It doesn't do that anymore (if it 
ever did), so the dependency on cygutils sure seems superfluous.

--
Chuck


--
Chuck


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]

[Corinna Vinschen]

On May 30 16:50, Charles Wilson wrote:
> On 5/30/2013 5:08 AM, Corinna Vinschen wrote:
> >That sounds strange.  Was cygwin-doc always in Base?  It contains the
> >cygwin docs and basic man pages but that doesn't really  qualify for the
> >Base category.
> [...]
> One caveat, mentioned in my other reply: cygutils' own requires:
> line lists dos2unix, so right now a Base install gets that package.
> This is probably desirable, but if we (effectively) remove cygutils
> from a Base install, we probably would want to add dos2unix to Base
> explicitly.
> 
> If we want to include (some subset of) cygutils explicitly in Base,
> I could see splitting into three subpackages:
>    cygutils (Base):
>       cygdrop cygstart lpr mkshortcut readshortcut winln

What about "cygstart mkshortcut readshortcut"?  These may be used by
postinstall scripts, the other stuff is extra, afaics.

>    cygutils-extra (Util): [requires: cygutils]
>       almost everything else, including documentation and man
>       pages (even for the exe's in the Base package)
>    cygutils-x11 (X11): [requires: cygutils]
>       the two desktop files, and the postinstall scripts that
>       handle them
> 
> This way, any package that currently requires: cygutils will almost
> certainly get the tool it is looking for, without having to change
> its requires line (and besides, if cygutils is in Base you'd get
> those anyway).

So, as result, we should do this for a start:

- cygwin-doc drops "Base" from the categories.
- dos2unix adds "Base" to the categories.
- cygutils drops "dos2unix" from requires.

And additionally you propose the above change to cygutils.  Sounds good
to me.  Yaakov?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]

[Yaakov (Cygwin/X)]

On 2013-05-31 03:34, Corinna Vinschen wrote:
> On May 30 16:50, Charles Wilson wrote:
>> If we want to include (some subset of) cygutils explicitly in Base,
>> I could see splitting into three subpackages:
>>     cygutils (Base):
>>        cygdrop cygstart lpr mkshortcut readshortcut winln
>
> What about "cygstart mkshortcut readshortcut"?  These may be used by
> postinstall scripts, the other stuff is extra, afaics.

Agreed.

>>     cygutils-extra (Util): [requires: cygutils]
>>        almost everything else, including documentation and man
>>        pages (even for the exe's in the Base package)

IMO man1 pages should be packaged together with their executables.

>>     cygutils-x11 (X11): [requires: cygutils]
>>        the two desktop files, and the postinstall scripts that
>>        handle them
>>
>> This way, any package that currently requires: cygutils will almost
>> certainly get the tool it is looking for, without having to change
>> its requires line (and besides, if cygutils is in Base you'd get
>> those anyway).
>
> So, as result, we should do this for a start:
>
> - cygwin-doc drops "Base" from the categories.
> - dos2unix adds "Base" to the categories.
> - cygutils drops "dos2unix" from requires.
>
> And additionally you propose the above change to cygutils.  Sounds good
> to me.  Yaakov?

The man3 and info pages definitely don't need to be in Base, but it 
would be nice if the man1 pages were packaged with cygwin.  Is that 
possible?  Otherwise, this sounds good to me.


Yaakov


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]

[Charles Wilson]

On 6/5/2013 12:47 PM, Yaakov (Cygwin/X) wrote:
> On 2013-05-31 03:34, Corinna Vinschen wrote:
>> On May 30 16:50, Charles Wilson wrote:
>>> If we want to include (some subset of) cygutils explicitly in Base,
>>> I could see splitting into three subpackages:
>>>     cygutils (Base):
>>>        cygdrop cygstart lpr mkshortcut readshortcut winln
>>
>> What about "cygstart mkshortcut readshortcut"?  These may be used by
>> postinstall scripts, the other stuff is extra, afaics.
>
> Agreed.

Ack.

> IMO man1 pages should be packaged together with their executables.

Ack.

>> So, as result, we should do this for a start:
>>
>> - cygwin-doc drops "Base" from the categories.
>> - dos2unix adds "Base" to the categories.
>> - cygutils drops "dos2unix" from requires.

Yes.

> The man3 and info pages definitely don't need to be in Base, but it
> would be nice if the man1 pages were packaged with cygwin.  Is that
> possible?  Otherwise, this sounds good to me.

Sure, I can do that. I'll roll a new release tonight (for both 32- and 64-).

--
Chuck



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygutils Postinstall Script Errors With Exit Code 128

[dylanhay]

exit  code 128
<http://www.keepdynamic.com/barcoding/asp-net-barcode-generator.shtml>  
Generally, this kind of failure stems from a few common problems:

  1. The existence of another (often old) cygwin1.dll.  Find it.  Remove it.
  2. http://cygwin.com/acronyms/#BLODA.  Remove BLODA.
  3. Possibly fork failures.  Install the rebase package and run
     rebaseall after reading the README in /usr/share/doc/Cygwin.


Also, make sure you're using the latest 'setup.exe' as found at cygwin.com.
Beware of proxies along your path that could be caching an old version.
You want version 2.697.


    Problem reports: http://cygwin.com/problems.html 


If it's none of the above, please provide cygcheck output as requested by
the link above.



--
View this message in context: http://cygwin.1069669.n5.nabble.com/Re-cygutils-Postinstall-Script-Errors-With-Exit-Code-128-tp99002p109846.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple