Here's a strange one. When I check out cygport and try to run its
autogen.sh, I get a bunch of errors about DOS line endings:
/tmp git clone
git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/cygport
Cloning into 'cygport'...
remote: Counting objects: 9806, done.
remote: Compressing
On 2014-12-30 09:43, Andrew Schulman wrote:
Here's a strange one. When I check out cygport and try to run its
autogen.sh, I get a bunch of errors about DOS line endings:
Are you sure you're using a Cygwin git?
--
Yaakov
On 2014-12-30 09:43, Andrew Schulman wrote:
Here's a strange one. When I check out cygport and try to run its
autogen.sh, I get a bunch of errors about DOS line endings:
Are you sure you're using a Cygwin git?
Yes.
/tmp which git
/usr/bin/git
/tmp git --version
git version 2.1.1
I
On 2014-12-30 09:43, Andrew Schulman wrote:
Here's a strange one. When I check out cygport and try to run its
autogen.sh, I get a bunch of errors about DOS line endings:
Are you sure you're using a Cygwin git?
So is Cygwin git normally supposed to take care of the DOS line endings?
I noticed that updating to the latest xinit (1.3.4-1) from the previous
one (1.3.2 I believe) completely breaks existing configurations.
The changes have been mentioned in the release announcement:
https://cygwin.com/ml/cygwin-xfree/2014-11/msg00029.html
And numerous posts have since reported
Laurens Blankers wrote:
I noticed that updating to the latest xinit (1.3.4-1) from the previous
one (1.3.2 I believe) completely breaks existing configurations.
What about changing the way X server is started? I flagged here:
https://cygwin.com/ml/cygwin-xfree/2014-11/msg00040.html
my
On 30-12-2014 13:46, Angelo Graziosi wrote:
What about changing the way X server is started?
I could change the way I start X, and I have successfully gotten things
to work by doing so. But that is not my point. My point is that I need
to make significant changes to the configuration to get back
Laurens Blankers wrote:
Then I drag the X icon to my
Start-up folder, so that it starts every time my desktop boots
The same you can do with the link created as suggested in my previous
replay. When I had Win XP I did that way for almost 7 years without
tacking care of any configuration
On 30-12-2014 17:04, Angelo Graziosi wrote:
The same you can do with the link created as suggested in my previous
replay.
You are probably right, but again, that is not the issue. The point I am
trying to make is that breaking configurations which have worked for
many years in a patch release is
The following packages have been updated in the Cygwin distribution:
*** xorg-server-*1.16.3-1
These packages contain XWin and the other X.Org X11 servers.
In addition to upstream fixes [1], the following cygwin-specific changes
have been made since 1.16.2-1:
* Defend against and report
Hello !
While trying to install and run SSH daemon in cygwin I found the
following strange behavior of cygwin's ID command (I did all my testing
on a Windows 8 system freshly installed on a virgin virtual machine from
the DVD image en_windows_8_enterprise_x64_dvd_917522.iso downloaded from
12/29/2014 06:30 PM, ext Ken Brown пишет:
If you were really running in an elevated shell, I don't know why 544 didn't show up in
the output of id -G.
But that's exactly what's happening with the testing version of cygwin
DLL (I wrote a bug report as a new mail thread)
--
Problem reports:
Marco Atzeri wrote:
Version 6.9.0.0-1 of
ImageMagick
ImageMagick-doc
libMagickCore6
libMagick-devel
perl-Image-Magick
have been uploaded for cygwin
After this upgrade, Emacs fails to build from trunk:
[...]
Configured for `x86_64-pc-cygwin'.
Where should the build process
On 12/30/2014 3:20 PM, Angelo Graziosi wrote:
Marco Atzeri wrote:
Version 6.9.0.0-1 of
ImageMagick
ImageMagick-doc
libMagickCore6
libMagick-devel
perl-Image-Magick
have been uploaded for cygwin
After this upgrade, Emacs fails to build from trunk:
[...]
Configured for
On 12/29/2014 11:27 PM, Houder wrote:
If you were really running in an elevated shell, I don't know why 544
didn't show up in the output of id -G.
Ken
Because Ilya's /etc/group file has a line that reads:
root:S-1-5-32-544:0:
in stead of:
Administrators:S-1-5-32-544:544:
?
Put
Il 30/12/2014 17:16, Marco Atzeri ha scritto:
On 12/30/2014 3:20 PM, Angelo Graziosi wrote:
Marco Atzeri wrote:
Version 6.9.0.0-1 of
ImageMagick
ImageMagick-doc
libMagickCore6
libMagick-devel
perl-Image-Magick
have been uploaded for cygwin
After this upgrade, Emacs fails to
On 12/30/2014 10:23 PM, Angelo Graziosi wrote:
Il 30/12/2014 17:16, Marco Atzeri ha scritto:
On 12/30/2014 3:20 PM, Angelo Graziosi wrote:
Marco Atzeri wrote:
Version 6.9.0.0-1 of
ImageMagick
ImageMagick-doc
libMagickCore6
libMagick-devel
perl-Image-Magick
have been uploaded
On 12/30/2014 4:51 PM, Marco Atzeri wrote:
On 12/30/2014 10:23 PM, Angelo Graziosi wrote:
Sure it isn't a packaging bug? I see that now ImageMagick has missed
/usr/lib/libMagickCore.dll.a... and this
changed name upstream.
cd /usr/lib
ln -sf libMagickCore-6.Q16.dll.a libMagickCore.dll.a
If you were really running in an elevated shell, I don't know why 544
didn't show up in the output of id -G.
Ken
Because Ilya's /etc/group file has a line that reads:
root:S-1-5-32-544:0:
in stead of:
Administrators:S-1-5-32-544:544:
?
Put
If you were really running in an elevated shell, I don't know why 544 didn't
show up in the output of id -G.
Ken
Because Ilya's /etc/group file has a line that reads:
root:S-1-5-32-544:0:
in stead of:
Administrators:S-1-5-32-544:544:
?
Put differently, he has copied an old group
On 2014-12-30 16:12, Ken Brown wrote:
On 12/30/2014 4:51 PM, Marco Atzeri wrote:
On 12/30/2014 10:23 PM, Angelo Graziosi wrote:
Sure it isn't a packaging bug? I see that now ImageMagick has missed
/usr/lib/libMagickCore.dll.a... and this
changed name upstream.
cd /usr/lib
ln -sf
21 matches
Mail list logo
