Re: Memcache/d (Orig: Re: Composer segfault on multiple configurations)
On Fri, May 26, 2017 at 12:11 AM, Richard H Lee wrote: > On 25/05/2017 08:50, Sky Diver wrote: > PHP 5.5.9, PHP 5.6.2 on Cygwin? > Were they even released on Cygwin? Sure did. Requires a bit of digging through the "cygwin time machine" archive but they are all there. > Unfortunately, I think memcache is a separate package from php and it would > not be compiled in by cygports. Due to an accident, I happened to delete my entire C:\cygwin\bin directory a few days back when installing and re-installing various cygwin versions. Currently I can't get Memcache to work anymore, but I definitely had Memcache-related code running under cygwin with no problems. > For most websites memcache/d is optional. If the website detects that > memcache/d is not present during setup, it simply does not use it. I agree with that and I guess the fastest solution would be to use Memcache (or Memcachd or apc_*()) if present or ignore if it's not. Thank you. -- 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: Mintty does not close after "exit" command
On Wed, May 24, 2017 at 11:42 AM, Dani Moncayo wrote: > To reproduce the problem, just open the standard cygwin terminal (e.g. > by double-clicking the desktop icon), an then type the "exit" command > in the bash shell. > > I see a "logout" message for a fraction of a second, then the terminal > becomes empty (without text), but the mintty window remains visible > but unresponsive, with the title bar showing "~ (Not Responding)". I've seen this happen several times in the past few days. This may be related to the fact that I'm installing cygwin a lot these days. It may happen after installing a package that doesn't require to close any open cygwin terminal. Usually I close everything by default but since I'm installing a lot lately I sometimes skip it if it's not required (e.g. installing a php extension). Maybe you have some cygwin service running in the background (you can check it with: cygrunsrv -L). Regardless, maybe a full rebase could help. -- 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: Composer segfault on multiple configurations
On Mon, May 22, 2017 at 9:38 PM, Richard H Lee wrote: > Just in case Sky Diver or anyone else is interested in compiling php from > Cygports, here are some simple steps to do so. Thanks Richard, I may try this at some point, but am currently experiencing other instabilities. For some reason, I started getting the message "Class 'Memcache' not found" when running memcache-aware PHP code. Since then I went back in time and installed PHP 5.5.9, PHP 5.6.20 but the result is the same. There's no php-memcache extension to install (on Ubuntu, for example, that's the way to add it). I'm pretty sure I didn't go through the "pecl install memcache" process, and doing so now fails during compilation. So I might end up following your steps in order to build PHP, hoping I could enable built-in memcache support while at it (Bash on Ubuntu on Windows, for example, has memcache and memcached included out of the box). -- 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: ANSI colors not showing by default
On Mon, May 22, 2017 at 1:49 PM, Richard H Lee wrote: > It appears you needs to install the php-posix package to get termcap info. Wow Richard, another hit on the nail's head. Impressive. That did the trick. Thank you very much! -- 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: ANSI colors not showing by default
On Sun, May 21, 2017 at 11:49 PM, Thomas Wolff wrote: > Hi, your symptom description is quite sparse... > > Am 21.05.2017 um 22:45 schrieb Sky Diver: >> >> Lately I noticed that colors are not showing by default in some >> situations. >> The most apparent case is when running composer. > > What "composer"? PHP composer https://getcomposer.org >> The latest composer version on "Bash on Ubuntu on Windows" console, >> and even when running it via a mintty shell looks just fine. But from >> cygwin the output is monochrome. > > "From cygwin" could mean (guessing) from a cygwin console window, where your > TERM setting would be "cygwin". > That could cause an application to assume no colour support. So it would > help if you tell us what your settings are. (*) I thought that cygcheck.out would answer these type of questions. The default TERM value is 'xterm', even when I rename my home-dir and launch a shell that creates a fresh one. >> I would love to understand what's going on. >> I tried the following: >> - Change the TERM var to several values > > Which values? TERM=xterm TERM=xterm-256color TERM=Cygwin TERM=cygwin This one also didn't help: export CYGWIN=codepage:ansi -- 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
ANSI colors not showing by default
Lately I noticed that colors are not showing by default in some situations. The most apparent case is when running composer. The latest composer version on "Bash on Ubuntu on Windows" console, and even when running it via a mintty shell looks just fine. But from cygwin the output is monochrome. Attached is cygcheck.out. I would love to understand what's going on. I tried the following: - Change the TERM var to several values - Renamed my home-dir and dropped into a shell in order to get a clean new home-dir. - Installed cygwin from scratch Any help would be appreciated. cygcheck.out Description: Binary data -- 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: setup-x86.exe default view
On Thu, May 18, 2017 at 9:35 PM, Brian Inglis wrote: > You should always check Pending last, to see what will be installed > or upgraded, if there is anything you forgot, don't need, or don't > want upgraded, and the download sizes, if time, speed, or space are > concerns, or you just don't want a pile of time or space used up by > some bloated packages. Actually, the preferred user experience would be to: 1. Start in Category view 2. Select whatever packages to install/remove/etc. 3. Click "Next" 4. Have the Pending view show up in order to review whatever is going to be installed. 5. Have the option to Approve / Cancel / Go Back This way, the Pending view is shown at the right moment (after setup instead of before) so there's no need to remember to manually do that. Personally I don't use the setup program too often so I don't think I'll remember to do that each time, especially when most setup programs will show you a final summary with the list of files/packages that would be installed and the amount of required disk space - prior to installing the software - and will also wait for confirmation (even text-based installers like apt-get, for example, behave like that). -- 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: setup-x86.exe default view
On Thu, May 18, 2017 at 8:34 PM, Ted To wrote: > Unfortunately it defaults to "Pending" and does not remember when I set it > to "Category." The next question is: If it did remember, where would that > be? I.e., what file do I edit to make it default to "Category"? FWIW, I was planning on asking the same question because it looks like the behavior is hard-coded, but I then realized that starting in 'Pending' mode make more sense. This way you're able to see up front which modules will get auto-upgraded and decide if to upgrade or keep the existing. As an example, if this feature were on a while back, it would have saved me a trip to the time machine in order to roll back PHP7 to PHP5. -- 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: Composer segfault on multiple configurations
On Thu, May 18, 2017 at 3:34 PM, Andrey Repin wrote:
> Please don't top-post, and don't quote raw email addresses.
Fair enough.
On Thu, May 18, 2017 at 3:59 PM, Richard H Lee wrote:
> On 18/05/2017 13:34, Andrey Repin wrote:
>>
>> Try turning pcre.jit off, it was known to be a problem in the past.
>
>
> This is already turned off in the cygport patches.
I'm not sure if Richard is referring to a released version or a
manually compiled one, but prior to posting my issue I already went
over earlier discussions regarding pcre.jit.
This is the configuration in my php.ini:
pcre.jit=0
I assume this means it's off.
On Thu, May 18, 2017 at 3:34 PM, Andrey Repin <anrdae...@yandex.ru> wrote:
> Greetings, Sky Diver!
>
> Please don't top-post, and don't quote raw email addresses.
>
>> On Wed, May 17, 2017 at 11:24 PM, Richard H Lee wrote:
>>> On 17/05/2017 20:17, Sky Diver wrote:
>>>>
>>>> Running "composer install" with the following composer.json ends up in
>>>> a segmentation fault.
>>>>
>>>> -- START ---
>>>> {
>>>> "require": {
>>>> "propel/propel": "~2.0@dev"
>>>> },
>>>> "config": {
>>>> "optimize-autoloader": true
>>>> }
>>>> }
>>>> -- END -
>>>>
>>>> (*) Note: when "optimize-autoloader" is set to false the error doesn't
>>>> occur.
>>>
>>> I think this may be to do with the 4096 error bug.
>>>
>>> Composer will pull in the files and run them. One of them is:
>>> vendor/propel/propel/src/Propel/Runtime/DataFetcher/PDODataFetcher.php
>>>
>>> From you project directory, try running:
>>> php vendor/propel/propel/src/Propel/Runtime/DataFetcher/PDODataFetcher.php
>>>
>>> That probably will give you a segfault. I'm not sure if changing the
>>> filesize will help, because composer probably will fetch a fresh copy of
>>> the file.
>>>
>>> I did provide a small patch a few weeks ago. That might help. You'd need
>>> to recompile and install php though cygports to use it.
>
>> Thanks Richard, you've hit the nail right on the head.
>> Running PHP on that specific file does produce the segfault.
>
>> I'm currently running composer via "Bash on Ubuntu on Windows". I may
>> compile PHP from cygports later but currently I need to make up for
>> lost time at work over this.
>> Any idea when your fix will get released as an official cygwin PHP package?
>
>> Thanks again.
>
> Try turning pcre.jit off, it was known to be a problem in the past.
>
>
> --
> With best regards,
> Andrey Repin
> Thursday, May 18, 2017 15:31:02
>
> Sorry for my terrible english...
>
--
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: Composer segfault on multiple configurations
Thanks Richard, you've hit the nail right on the head.
Running PHP on that specific file does produce the segfault.
I'm currently running composer via "Bash on Ubuntu on Windows". I may
compile PHP from cygports later but currently I need to make up for
lost time at work over this.
Any idea when your fix will get released as an official cygwin PHP package?
Thanks again.
On Wed, May 17, 2017 at 11:24 PM, Richard H Lee
<ricardohenry...@gmail.com> wrote:
> On 17/05/2017 20:17, Sky Diver wrote:
>>
>> Running "composer install" with the following composer.json ends up in
>> a segmentation fault.
>>
>> -- START ---
>> {
>> "require": {
>> "propel/propel": "~2.0@dev"
>> },
>> "config": {
>> "optimize-autoloader": true
>> }
>> }
>> -- END -
>>
>> (*) Note: when "optimize-autoloader" is set to false the error doesn't
>> occur.
>
> I think this may be to do with the 4096 error bug.
>
> Composer will pull in the files and run them. One of them is:
> vendor/propel/propel/src/Propel/Runtime/DataFetcher/PDODataFetcher.php
>
> From you project directory, try running:
> php vendor/propel/propel/src/Propel/Runtime/DataFetcher/PDODataFetcher.php
>
> That probably will give you a segfault. I'm not sure if changing the
> filesize will help, because composer probably will fetch a fresh copy of
> the file.
>
> I did provide a small patch a few weeks ago. That might help. You'd need
> to recompile and install php though cygports to use it.
>
> --
> 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
>
--
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
Composer segfault on multiple configurations
Hi,
Running "composer install" with the following composer.json ends up in
a segmentation fault.
-- START ---
{
"require": {
"propel/propel": "~2.0@dev"
},
"config": {
"optimize-autoloader": true
}
}
-- END -
(*) Note: when "optimize-autoloader" is set to false the error doesn't occur.
Attached are the segfault core dump file (I didn't edit the stack
trace, it's empty) + cygcheck.out (with sensitive data edited out).
I tested the following cases:
- PHP 7.0.18
- PHP 7.0.19
- PHP 5.6.10.
- After rebase all
- After a reinstall (setup -> category view -> all -> reinstall)
- After a fresh cygwin 32-bit install in an empty directory (this is
the version I run with for years)
- After a fresh cygwin 64-bit install in an empty directory
My reason for thinking this is a cygwin issue is that this behavior
doesn't repeat under Ubuntu distros, both running in a VirtualBox VM
and via Bash/WSL (a.k.a.: Bash on Ubuntu on Windows).
Would love to hear of a fix/workaround for this issue.
Thanks.
php.exe.stackdump
Description: Binary data
cygcheck.out
Description: Binary data
--
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
How to install PHP apcu extension?
Hi, I can't seem to find an answer on google nor the cygwin mailing lists. I'd like to understand how could I add extensions, specifically - apcu, to the php module. Can someone help? -- 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: ACL Hell
Sorry for the late reply. Ran both commands from an elevated shell and it still doesn't work. I see this was discussed before but there was no concrete conclusion. https://www.cygwin.com/ml/cygwin/2013-04/msg00066.html The two options that do work so far are: 1. Run cygwin as administrator 2. Disable UAC altogether (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA=0 in the registry) I use the first option at work and the second one at home. Cheers. On Fri, Jul 17, 2015 at 2:29 PM, Kurt Franke kurt-fra...@web.de wrote: Sky Diver skydivergm at gmail.com writes: ... Still, how can I get a normal behavior (i.e. normal Windows symlinks as produces in winsymlinks:nativestrict mode) in a regular session w/o elevation? You could grant the necessary privilege to your account or to the group Users editrights -u sky -a SeCreateSymbolicLinkPrivilege or editrights -u Users -a SeCreateSymbolicLinkPrivilege regards kf -- 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 -- 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: ACL Hell
Hey Andrey, Are you running with superadmin credentials? Unlike Linux, Windows doesn't let regular users make symlinks. I'm using cygwin for years already. I didn't use to have this problem in the past. It's something relatively new, that became way more intense in the past few months where I both re-installed windows at home, and got a fresh PC at work. On both machines I'm referring to the main user, which is part of the Administrators group. I believe that answers your question. Both machine are Windows 8.1 64-bit, standalone station at home and part of a domain at work. One more thing, here's my CYGWIN env. varv: $ echo $CYGWIN winsymlinks:nativestrict This is the only way to produce windows compliant links (at least in my case). Thanks. -- 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: ACL Hell
To Larry Hall: 1. I'd love to reply to your post, but I'm new to this mailing-list concept so I neglected to subscribe to the mailing list (yeah, I'm an old fashioned kinda guy, work only with thread-level google-groups / StackOverflow forum types ;) TBH: If Andrey wouldn't have CC'ed me on his reply, I wouldn't even know that someone addressed my case... 2. I admit I didn't read the whole Reporting Problems page. As soon as I found the 'appropriate mailing list' link, I was off to another page. 2.1. Having read the page in full, I apologize for violating 3+ rules. 3. To the matter at hand: first of all, I attached cygcheck.out to this mail. Second, indeed I am using a non-default symlink mode: winsymlinks:nativestrict. This is the only mode that work for my needs (I can elaborate upon request). Have to say that even after re-reading the documentation now, I don't see it mentioning anything about elevated privileges. I AM aware of the fact that with an elevated session, the problem doesn't exist. However, I avoided using this mode because every new file/directory were created as Administrators:None instead of sky:None. For some weird reason, I just tried creating both a file and a directory with an elevated session and they were created with sky:None... I can't tell what's what anymore (sorry, I just got totally baffled). Still, how can I get a normal behavior (i.e. normal Windows symlinks as produces in winsymlinks:nativestrict mode) in a regular session w/o elevation? Thanks! On Wed, Jul 15, 2015 at 10:17 PM, Sky Diver skydive...@gmail.com wrote: Hey Andrey, Are you running with superadmin credentials? Unlike Linux, Windows doesn't let regular users make symlinks. I'm using cygwin for years already. I didn't use to have this problem in the past. It's something relatively new, that became way more intense in the past few months where I both re-installed windows at home, and got a fresh PC at work. On both machines I'm referring to the main user, which is part of the Administrators group. I believe that answers your question. Both machine are Windows 8.1 64-bit, standalone station at home and part of a domain at work. One more thing, here's my CYGWIN env. varv: $ echo $CYGWIN winsymlinks:nativestrict This is the only way to produce windows compliant links (at least in my case). Thanks. cygcheck.out Description: Binary data -- 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
ACL Hell
Hi, in the past several months or so, cygwin started giving me ACL pain in small surges which are gradually growing.. Here's a basic scenario that is slowly, but surely, driving me NUTZ: $ ln -s /cygdrive/c/tmp /tmp ln: failed to create symbolic link ‘/tmp’: Operation not permitted Some other examples (it doesn't matter which is the current working dir): $ touch x $ ls -l x -rw-rwxr--+ 1 sky None 0 Jul 15 00:46 x* $ getfacl x # file: x # owner: sky # group: None user::rw- group::r-- group:root:rwx group:Authenticated Users:rwx group:SYSTEM:rwx group:Users:r-x mask:rwx other:r-- $ ln -s x y ln: failed to create symbolic link ‘y’: Operation not permitted This didn't use to be like that. Cygwin's directory itself seems to be ok: $ ls -ld cygwin drwxrwx---+ 1 sky None 0 Jul 15 00:19 cygwin/ $ getfacl cygwin/ # file: cygwin/ # owner: sky # group: None user::rwx group::--- group:root:rwx group:Authenticated Users:rwx group:SYSTEM:rwx group:Users:r-x mask:rwx other:--- default:user::rwx default:user:sky:rwx default:group::--- default:group:root:rwx default:group:Authenticated Users:rwx default:group:SYSTEM:rwx default:group:Users:r-x default:mask:rwx default:other:--- I found a thread that shows how to remove ACL... Avec Plaisir! I replaced the line in /etc/fstab with this one: none /cygdrive cygdrive binary,noacl,posix=0,user 0 0 Closed all cygwin terminals, reopened and issue: $ getfacl cygwin/ # file: cygwin/ # owner: sky # group: None user::rwx group::r-x other:r-x Much better for all I care. However, this didn't change anything. Touching x and linking y yielded the exact same results as above. Here's my cygwin details: $ uname -a CYGWIN_NT-6.3-WOW sky-pc 2.0.2(0.287/5/3) 2015-05-08 17:03 i686 Cygwin Looking at cygwin via Properties - Security tab, the user (sky) is the owner of the directory and has Full Control (recursively). My main goal is not to get stuck on trivialities like soft linking of file creation. But what I would really like is to get rid of ACL altogether (towards that end I'll mention that I switched UAC off long time ago). I don't care about security, I just want to work and this is holding me back both at home and at my work place. Please.. Help... -- 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
