date:20090628

On Jun 28 12:08, Andy Koppe wrote:
 For both 1.5 and 1.7:
 
 wget http://mintty.googlecode.com/files/mintty-0.4.2-1.tar.bz2
 wget http://mintty.googlecode.com/files/mintty-0.4.2-1-src.tar.bz2
 
 Please delete 0.4.0-1.

Done.  I also removed 0.3.10-1.  I hope that was ok.


Thanks,
Corinna

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

Re: [ITP] task-1.7.1-1 (pinging for awaiting review)

Federico Hernandez wrote:

 Apart from the fixed packages of task fro cygwin-1.5 I have now also
 uploaded packages for cygwin-1.7.
 
 So you can find the packages for the review and upload under
 
 cygwin-1.5)
   http://taskwarrior.org/download/cygwin/setup.hint

  Looks fine.

   http://taskwarrior.org/download/cygwin/task-1.7.1-1-src.tar.bz2

  Works and regenerates the package precisely.

   http://taskwarrior.org/download/cygwin/task-1.7.1-1.tar.bz2

  Correct packaging.  Installed and checked that a couple of basic commands
worked (they did).

  AFAICS this one is GTG.

 cygwin-1.7)
   http://taskwarrior.org/download/cygwin/1.7/setup.hint
   http://taskwarrior.org/download/cygwin/1.7/task-1.7.1-1-src.tar.bz2
   http://taskwarrior.org/download/cygwin/1.7/task-1.7.1-1.tar.bz2

  Urrgh.  I see you noticed a problem of some sort.  It appears to install a
duplicate set of docs into both usr/share/doc/task-1.7.1 and
usr/share/doc/task, and you've had to add a few packaging definitions to get
around it; quite possibly as a side-effect of this, the cygwin-specific readme
gets installed as usr/share/doc/Cygwin/task.README, without any version
number.  Also, you choose to keep usr/share/doc/task and drop
usr/share/doc/task-1.7.1, which I think is the wrong way round.

  I'll see if I can find a fix for you.  Hang on in there a little while ...

cheers,
  DaveK

Re: [ITP] task-1.7.1-1 (pinging for awaiting review)

Dave Korn wrote:
 Federico Hernandez wrote:
 cygwin-1.7)
   http://taskwarrior.org/download/cygwin/1.7/setup.hint
   http://taskwarrior.org/download/cygwin/1.7/task-1.7.1-1-src.tar.bz2
   http://taskwarrior.org/download/cygwin/1.7/task-1.7.1-1.tar.bz2
 
   Urrgh.  I see you noticed a problem of some sort.  It appears to install a
 duplicate set of docs into both usr/share/doc/task-1.7.1 and
 usr/share/doc/task

  This appears to be intentional behaviour on the part of cygport at first
glance.  I removed the PKG_* and DOCS definitions from the .cygport file to
see what a normal build would look like.  After the cygport install stage, I
have this:

$ find task-1.7.1-1/inst/
task-1.7.1-1/inst/
task-1.7.1-1/inst/usr
task-1.7.1-1/inst/usr/bin
task-1.7.1-1/inst/usr/bin/task.exe
task-1.7.1-1/inst/usr/share
task-1.7.1-1/inst/usr/share/doc
task-1.7.1-1/inst/usr/share/doc/Cygwin
task-1.7.1-1/inst/usr/share/doc/Cygwin/task.README
task-1.7.1-1/inst/usr/share/doc/task
task-1.7.1-1/inst/usr/share/doc/task/AUTHORS
task-1.7.1-1/inst/usr/share/doc/task/ChangeLog
task-1.7.1-1/inst/usr/share/doc/task/COPYING
task-1.7.1-1/inst/usr/share/doc/task/NEWS
task-1.7.1-1/inst/usr/share/doc/task/README
task-1.7.1-1/inst/usr/share/doc/task-1.7.1
task-1.7.1-1/inst/usr/share/doc/task-1.7.1/AUTHORS
task-1.7.1-1/inst/usr/share/doc/task-1.7.1/ChangeLog
task-1.7.1-1/inst/usr/share/doc/task-1.7.1/COPYING
task-1.7.1-1/inst/usr/share/doc/task-1.7.1/INSTALL
task-1.7.1-1/inst/usr/share/doc/task-1.7.1/NEWS
task-1.7.1-1/inst/usr/share/doc/task-1.7.1/README
task-1.7.1-1/inst/usr/share/doc/task-1.7.1/task_completion.sh
task-1.7.1-1/inst/usr/share/man
task-1.7.1-1/inst/usr/share/man/man1
task-1.7.1-1/inst/usr/share/man/man1/task.1.gz
task-1.7.1-1/inst/usr/share/man/man5
task-1.7.1-1/inst/usr/share/man/man5/taskrc.5.gz

... but if I run the install manually from the build dir into a fresh install 
dir:

$ cd task-1.7.1-1/build/
$ make DESTDIR=/tmp/task/regen4/task-1.7.1-1/inst2 install
$ cd ../..

... I only see one set of docs, in the place where I'd expect to find it:

$ find task-1.7.1-1/inst2/
task-1.7.1-1/inst2/
task-1.7.1-1/inst2/usr
task-1.7.1-1/inst2/usr/bin
task-1.7.1-1/inst2/usr/bin/task.exe
task-1.7.1-1/inst2/usr/share
task-1.7.1-1/inst2/usr/share/doc
task-1.7.1-1/inst2/usr/share/doc/task-1.7.1
task-1.7.1-1/inst2/usr/share/doc/task-1.7.1/AUTHORS
task-1.7.1-1/inst2/usr/share/doc/task-1.7.1/ChangeLog
task-1.7.1-1/inst2/usr/share/doc/task-1.7.1/COPYING
task-1.7.1-1/inst2/usr/share/doc/task-1.7.1/INSTALL
task-1.7.1-1/inst2/usr/share/doc/task-1.7.1/NEWS
task-1.7.1-1/inst2/usr/share/doc/task-1.7.1/README
task-1.7.1-1/inst2/usr/share/doc/task-1.7.1/task_completion.sh
task-1.7.1-1/inst2/usr/share/man
task-1.7.1-1/inst2/usr/share/man/man1
task-1.7.1-1/inst2/usr/share/man/man1/task.1
task-1.7.1-1/inst2/usr/share/man/man5
task-1.7.1-1/inst2/usr/share/man/man5/taskrc.5

  I'll take a look through cygport and see if I can understand what it's doing
and why.  Yaakov, are you out there by any chance?

cheers,
  DaveK

Re: [ITP] task-1.7.1-1 (pinging for awaiting review)

2009-06-28 Thread Federico Hernandez

Hi Dave

Thx for your time and help. It's appreciated.

Great news about the task package for 1.5. As you have mentioned that
it is GTG - will you upload it then and when. I just ask so that the
upstream prpject could inform users about this.

Now regarding 1.7:

  This appears to be intentional behaviour on the part of cygport at first
 glance.  I removed the PKG_* and DOCS definitions from the .cygport file to
 see what a normal build would look like.  After the cygport install stage, I
 have this:

 task-1.7.1-1/inst/usr/share/doc/task
 ...
 task-1.7.1-1/inst/usr/share/doc/task-1.7.1

As I saw this 2 DOCDIRS I thought that cygport has changed from 1.5 to
1.7 and looked around other packages how they get installed in cygwin
1.7 - for example wget. This one puts everything into
/usr/share/doc/wget. So I assumed that this is the new standard to
omit the version number of the package.

Since the upstream project choosed to install the documentation in a
versioned DOCDIR I decided that I had to add the PKG_* and DOCS
definitions to the cygport file to as well have an unversioned DOCDIR
for task like the other packages in cygwin 1.7.

How should we proceed. Is the package otherwise OK? Apart for this. Do
you want me to change something else?

/Federico

PS I have another question: For the future how would updates/new
version of the package be handled. As I have seen I would post a RFU
(Request for update) to this mailinglist. Is that correct?

Re: [RFU] mintty-0.4.2-1

2009-06-28 Thread Andy Koppe

2009/6/28 Corinna Vinschen:
 For both 1.5 and 1.7:

 wget http://mintty.googlecode.com/files/mintty-0.4.2-1.tar.bz2
 wget http://mintty.googlecode.com/files/mintty-0.4.2-1-src.tar.bz2

 Please delete 0.4.0-1.

 Done.  I also removed 0.3.10-1.  I hope that was ok.

Yep, that's fine.

Thanks!
Andy

Re: [ITP] task-1.7.1-1 (pinging for awaiting review)

Federico Hernandez wrote:

 Great news about the task package for 1.5. As you have mentioned that
 it is GTG - will you upload it then and when. I just ask so that the
 upstream prpject could inform users about this.

http://cygwin.com/setup.html#submitting

  The normal procedure (see Package acceptation) is that after getting a GTG
for your new package, you send an RFU separately and then whichever of cgf and
corinna gets to it first uploads.  I'm not sure it would be right for the
reviewer to go ahead and upload it directly - having a second pair of eyes
helps catch anything the reviewer might have missed, like for instance this:

 # setup.hint for task 1.7.1-1
 category: Utils
 requires: libncurses9
 sdesc: A command-line to do list manager
 ldesc: Task is a command-line to do list manager.
 It has support for GTD functionality and includes
 the following features: tags, colorful tabular output,
 reports and graphs, lots of manipulation commands,
 low-level API, abbreviations for all commands and
 options, multiuser file locking, recurring tasks.

  I think you should replace to do list by to-do list or maybe TO-DO
list throughout :-)

 Now regarding 1.7:
 
  This appears to be intentional behaviour on the part of cygport at first
 glance.

 As I saw this 2 DOCDIRS I thought that cygport has changed from 1.5 to
 1.7 and looked around other packages how they get installed in cygwin
 1.7 - for example wget. This one puts everything into
 /usr/share/doc/wget. So I assumed that this is the new standard to
 omit the version number of the package.

  It does seem to be.  I looked at /usr/share/doc and saw a lot of packages
that did have versions and a lot that didn't; but now I try again (using 'ls
-rt' this time) I see that it tends to be older packages that haven't been
updated in a while.

 Since the upstream project choosed to install the documentation in a
 versioned DOCDIR I decided that I had to add the PKG_* and DOCS
 definitions to the cygport file to as well have an unversioned DOCDIR
 for task like the other packages in cygwin 1.7.

  This seems right, but I noticed a couple of hints that suggest it isn't
working right.  First off, during the build, I see that the configure line
includes --docdir=/usr/share/doc/task; but after the build, the docs end up
in .../doc/task-1.7.1, which is strange.  And the technique of using a tar
--exclude option in PKG_CONTENTS[0] causes a warning from cygport when it is
surprised to find the excluded files didn't end up in the tarball:

 Checking packages for missing or duplicate files
 *** Warning: Packages are missing files:
 -usr/share/doc/task-1.7.1/AUTHORS
 -usr/share/doc/task-1.7.1/COPYING
 -usr/share/doc/task-1.7.1/ChangeLog
 -usr/share/doc/task-1.7.1/INSTALL
 -usr/share/doc/task-1.7.1/NEWS
 -usr/share/doc/task-1.7.1/README
 -usr/share/doc/task-1.7.1/task_completion.sh
 
 Creating source patches

  I am led to wonder if there is some different behaviour between autoconf
versions that is confusing cygport.

 How should we proceed. Is the package otherwise OK? Apart for this. Do
 you want me to change something else?

  The package is fundamentally OK.  I recommend changing the wording of
setup.hint as suggested above, for both 1.5 and 1.7 versions, but it's only a
minor nicety, not critical.  So for the docs, there are three things we could
conceivably do:

1) Nothing.  Live with the warning, and assume the lack of versions on the
README and docs/task dir are the correct thing to do.  (We should have a quick
google through the list archives and see if we can find a post discussing this
standard).

2) Remove the PKG_* and DOCS definitions from your cygport, and add a line
reading:

_CYGPORT_RESTRICT_postinst_doc_=1

  This gets us a package in the 1.5 style, with versioned Cygwin/README and
doc/ dirs.

3) Wait a while and see if Yaakov (cygport maintainer) can help us out here.

  I'll try a build using autoconf-2.61 instead of -2.63 and see if that makes
any difference.

 PS I have another question: For the future how would updates/new
 version of the package be handled. As I have seen I would post a RFU
 (Request for update) to this mailinglist. Is that correct?

  Yep, apart from the U stands for Upload, not Update!  See the section
Updating a package at the URL I linked above, and

http://cygwin.com/acronyms/#RFU

cheers,
  DaveK

Re: [ITP] task-1.7.1-1 (pinging for awaiting review)

Dave Korn wrote:

   I'll try a build using autoconf-2.61 instead of -2.63 and see if that makes
 any difference.

  ROFL.  I tried it with autoconf-2.59 and got this error:

 Compiling task-1.7.1-1
 autoreconf: Entering directory `.'
 autoreconf: configure.ac: not using Gettext
 autoreconf: running: aclocal --force
 configure.ac:4: error: Autoconf version 2.61 or higher is required
 configure.ac:4: the top level
 autom4te: /usr/bin/m4 failed with exit status: 63
 aclocal: autom4te failed with exit status: 63
 autoreconf: aclocal failed with exit status: 63
 *** ERROR: autoreconf failed

... so I tried again with autoconf-2.61 ... only to see:

 *** Info: patch task-1.7.1-1.src.patch not found
 Compiling task-1.7.1-1
 autoreconf-2.61: Entering directory `.'
 autoreconf-2.61: configure.ac: not using Gettext
 autoreconf-2.61: running: aclocal --force
 configure.ac:35: error: Autoconf version 2.62 or higher is required
 /usr/share/aclocal-1.11/init.m4:26: AM_INIT_AUTOMAKE is expanded from...
 configure.ac:35: the top level
 autom4te-2.61: /usr/bin/m4 failed with exit status: 63
 aclocal-1.11: autom4te failed with exit status: 63
 autoreconf-2.61: aclocal failed with exit status: 63
 *** ERROR: autoreconf failed

  So I tried using automake-1.10 as well as autoconf-2.61, and that just gave
me the same behaviour as using the latest versions: an extra doc dir that has
to be excluded at PKG_ time.  Humph.

  Perhaps there's actually a problem with task's makefiles or configury not
understanding --docdir=/usr/share/doc/task correctly?

cheers,
  DaveK

Re: [ITP] task-1.7.1-1 (pinging for awaiting review)

Dave Korn wrote:

   Perhaps there's actually a problem with task's makefiles or configury not
 understanding --docdir=/usr/share/doc/task correctly?

  This is task-1.7.1/Makefile.am:

 SUBDIRS = src
 EXTRA_DIST = task_completion.sh doc/man1/task.1 doc/man5/taskrc.5
 man1_MANS = doc/man1/task.1
 man5_MANS = doc/man5/taskrc.5
 otherdir = $(datadir)/doc/task-$(VERSION)
 other_DATA = AUTHORS ChangeLog COPYING INSTALL NEWS README task_completion.sh

  That does seem a funny way to do things to me, and it obviously ignores
$docdir.  You might want to discuss this upstream; the autoconf-2.63
documentation defines those two variables as:

 -- Variable: datadir
 The directory for installing idiosyncratic read-only
 architecture-independent data.

 -- Variable: docdir
 The directory for installing documentation files (other than Info
 and man).

so you want to allow for the possibility that the user will have changed one
or the other on the configure command-line.

cheers,
  DaveK

Re: [ITP] task-1.7.1-1 (pinging for awaiting review)

Dave Korn wrote:

   Perhaps there's actually a problem with task's makefiles or configury not
 understanding --docdir=/usr/share/doc/task correctly?

  This is task-1.7.1/Makefile.am:

 SUBDIRS = src
 EXTRA_DIST = task_completion.sh doc/man1/task.1 doc/man5/taskrc.5
 man1_MANS = doc/man1/task.1
 man5_MANS = doc/man5/taskrc.5
 otherdir = $(datadir)/doc/task-$(VERSION)
 other_DATA = AUTHORS ChangeLog COPYING INSTALL NEWS README task_completion.sh

  That does seem a funny way to do things to me, and it obviously ignores
$docdir.  You might want to discuss this upstream; the autoconf-2.63
documentation defines those two variables as:

 -- Variable: datadir
 The directory for installing idiosyncratic read-only
 architecture-independent data.

 -- Variable: docdir
 The directory for installing documentation files (other than Info
 and man).

so you want it to allow for the possibility that the user will have changed
one or the other on the configure command-line.

cheers,
  DaveK

Re: [ITP] task-1.7.1-1 (pinging for awaiting review)

2009-06-28 Thread Federico Hernandez

  The normal procedure (see Package acceptation) is that after getting a GTG
 for your new package, you send an RFU separately and then whichever of cgf and
 corinna gets to it first uploads.  I'm not sure it would be right for the
 reviewer to go ahead and upload it directly - having a second pair of eyes
 helps catch anything the reviewer might have missed, like for instance this:

I will do then a RFU just for cygwin 1.5 for the time being - and
later on for 1.7.


  I think you should replace to do list by to-do list or maybe TO-DO
 list throughout :-)

You know, I/we had the capitalized TO-DO version first. And while
submitting it to Ubuntu/Debian then encouraged us to change it to to
do. So I guess there are endless ways of writing this...

 includes --docdir=/usr/share/doc/task; but after the build, the docs end up
 in .../doc/task-1.7.1, which is strange.  And the technique of using a tar

The Makefile.am file has a specific explicit mentioning of

 docdir = $(datadir)/doc/${PACKAGE}-${VERSION}

 2) Remove the PKG_* and DOCS definitions from your cygport, and add a line
 reading:

 _CYGPORT_RESTRICT_postinst_doc_=1

  This gets us a package in the 1.5 style, with versioned Cygwin/README and
 doc/ dirs.

I would tend to do this as it makes the installed base of files more
consistent acorss versions unless there is a reason/decision not to do
it anymore.


Again.

Thanks for the help.

/Federico

Re: [ITP] task-1.7.1-1 (pinging for awaiting review)

Dave Korn wrote:
[ a duplicate post]

  Oops.  Sorry for the dup everybody.  I blame it on Thunderbird's somewhat
confused status-reporting:

http://img188.imageshack.us/img188/5273/messagesuccessfullyfail.png

cheers,
  DaveK

Re: [ITP] task-1.7.1-1 (pinging for awaiting review)

Federico Hernandez wrote:

  I think you should replace to do list by to-do list or maybe TO-DO
 list throughout :-)
 
 You know, I/we had the capitalized TO-DO version first. And while
 submitting it to Ubuntu/Debian then encouraged us to change it to to
 do. So I guess there are endless ways of writing this...

  Well, I guess it makes sense to stay consistent with the other packages then.

 includes --docdir=/usr/share/doc/task; but after the build, the docs end up
 in .../doc/task-1.7.1, which is strange.  And the technique of using a tar
 
 The Makefile.am file has a specific explicit mentioning of
 
  docdir = $(datadir)/doc/${PACKAGE}-${VERSION}

  :) Heh, your email crossed with mine while I was rebooting my modem.

 I would tend to do this as it makes the installed base of files more
 consistent acorss versions unless there is a reason/decision not to do
 it anymore.

  Well, 1.5 is basically moribund and 1.7 is going to introduce a whole new
bunch of ways of doing things that break with tradition, so consistency
between them might not be a relevant consideration.  (That said, I don't
actually know whether this is a new standard way of doing things or not -
still got to go digging in the archives for that.)

cheers,
  DaveK

Re: [ITP] task-1.7.1-1 (pinging for awaiting review)

2009-06-28 Thread Federico Hernandez

No problem regarding the dupe...

  Well, I guess it makes sense to stay consistent with the other packages then.

;-) I could change it later on when task reaches 2.0 and will
introduce a whole lot of new things.

  The Makefile.am file has a specific explicit mentioning of
 
       docdir = $(datadir)/doc/${PACKAGE}-${VERSION}

  :) Heh, your email crossed with mine while I was rebooting my modem.

I will discuss the docdir issue with upstream. Though it might not
result in a change for task 1.7.1 - but I could do a patch for cygwin
and supply it as a cygwinpatch file for cygport though.


  Well, 1.5 is basically moribund and 1.7 is going to introduce a whole new
 bunch of ways of doing things that break with tradition, so consistency
 between them might not be a relevant consideration.  (That said, I don't
 actually know whether this is a new standard way of doing things or not -
 still got to go digging in the archives for that.)

Thx for your help with this. When I encountered the problem I started
aswell to search but didn't really know where to look first and how to
get further. There might have been a lot of discussion around this...

/Federico

Re: [ITP] task-1.7.1-1 (pinging for awaiting review)

Dave Korn wrote:
   Urrgh.  I see you noticed a problem of some sort.  It appears to install a
 duplicate set of docs into both usr/share/doc/task-1.7.1 and
 usr/share/doc/task, and you've had to add a few packaging definitions to get
 around it; quite possibly as a side-effect of this, the cygwin-specific readme
 gets installed as usr/share/doc/Cygwin/task.README, without any version
 number.  Also, you choose to keep usr/share/doc/task and drop
 usr/share/doc/task-1.7.1, which I think is the wrong way round.

From the cygport NEWS file:

0.9.2:
* SRC_URI: now accepts SRPMs.
* PATCH_URI: now accepts multiple-patch tarballs.
* Installs documentation into /usr/share/doc/PACKAGE.

This is a deliberate change between 0.4.x for cygwin-1.5, and 0.9.x for
cygwin-1.7.  However, it relies on the underlying package understanding
and working with
   docdir (for older autoconf)
   datarootdir (for newer autoconf)

So, if upstream task doesn't use the correct variables, then cygport
is going to have trouble.  It will manually install some of the doc
files into /usr/share/doc/PACKAGE, while the base package's make install
might install some sub- or super- or disjoint set of files into $where_ever.

disclaimerI haven't looked at this specific underlying package.

--
Chuck

Novice Question

2009-06-28 Thread Andys

Trying to get the lastest X to run on Cygwin 1-7 but only seem to be able to 
get a core dump  the log:

XWin was started with the following command line:

/usr/bin/XWin -multiwindow -clipboard -silent-dup-error

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1680 h 1050
winInitializeDefaultScreens - Returning
_XSERVTransSocketCreateListener: failed to bind listener
_XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: failed to create listener for inet6


When I run the commands manually from the startxwin.bat I get a Segmentation 
Fault (core dumped) 

IP6 is installed on a Vista32 OS but I have no clue on how to  further 
diagnose the problem

All software used is the latest as of today

Any suggestions welcome

thanks


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

Re: Novice Question

2009-06-28 Thread Jon TURNEY


Andys wrote:
Trying to get the lastest X to run on Cygwin 1-7 but only seem to be able to 
get a core dump  the log:


Firstly, thanks very much for trying it out and reporting the problem.


XWin was started with the following command line:

/usr/bin/XWin -multiwindow -clipboard -silent-dup-error

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1680 h 1050
winInitializeDefaultScreens - Returning
_XSERVTransSocketCreateListener: failed to bind listener
_XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: failed to create listener for inet6


When I run the commands manually from the startxwin.bat I get a Segmentation 
Fault (core dumped) 

IP6 is installed on a Vista32 OS but I have no clue on how to  further 
diagnose the problem


I don't believe IPv6 is the cause of the problem you are seeing, this just 
happens to be the last line of output written.


You could test this by adding '-nolisten inet6' to the command line used to 
start the X server.



All software used is the latest as of today

Any suggestions welcome


If the suggestion above fails, I'd like your help to get a backtrace, if you 
are willing:


1. Download ftp://cygwin.com/pub/cygwinx/XWin.20090628173519.exe.bz2
(this is a build of the 1.6.0.0-1 X server but with debugging symbols 
unstripped)
2. bunzip2 XWin.20090628173519.exe.bz2 to uncompress it
3. gdb --args ./XWin.20090628173519.exe  -multiwindow -clipboard -logverbose 3
(you may need to install the gdb package)
4  wait for the '(gdb)' prompt, type 'r'
5. wait for the segmentation fault to occur, you should get another '(gdb)' 
prompt, bt full

6. post the output

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

Re: [1.7] Socket problems after xorg-server update

2009-06-28 Thread Jon TURNEY

Ken Brown wrote:

After I upgraded to xorg-server-1.6.0-10, XWin.exe exited immediately
with the following error message in the log file:

_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6

Although it's clear as mud, this message should not be a fatal error, just a
warning.

This is curious. I don't seem to have IPv6 installed and the server starts
fine for me, with that warning.

You could try disabling the IPv6 socket with '-nolisten inet6' to see if it
makes a difference.

Cygwin 1.7 adds IPv6 support, so the IPv6 support in xtrans is now turned on.
I guess there could easily be cygwin-specific problems with it...

After some googling, I decided that the problem might be that the IPv6
protocol wasn't installed. So I installed it, following the
instructions at

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ip_v6_pro_inst.mspx?mfr=true

Now XWin.exe works (except for two problems I'll describe below), but
the log file contains

_XSERVTransSocketCreateListener: failed to bind listener
_XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: failed to create listener for inet6

Could this still indicate a problem involving IPv6? Should I have done
some configuration after installing it? I did run 'ipv6.exe if' and
compare it to the output from a different machine on which IPv6 had been
preinstalled. I didn't notice any substantial differences, but maybe I
don't know what to look for.

The server probably hasn't been tested on cygwin with IPv6 enabled (certainly
not by me) so you're breaking new ground :-)

It certainly should not require IPv6 to work.

Now for the two problems:

1. After running startxwin.bat, it takes about 20 seconds for the X icon
to appear in the taskbar. I guess that's related to the socket problems
reported in the log.

This is possible if it's trying some IPv6 address autoconf or something.

2. After I shut down the server by right-clicking the taskbar icon and
choosing Exit, the files /tmp/.X0-lock and /tmp/.X11-unix/X0 don't get
deleted.

I don't think this is a change from the previous version.

The lock file is used by creating a temporary file and trying to rename it to
the lock file name (which is expected to fail if the lock file is being held
open by another process), so leaving the old one around is tolerable (although
may cause us some permissions problems if the server is next run by another
user or something, which is why there is ...)

Two last bits of information:

First, while the X server was running, I gave the command 'netstat -b'
and didn't see anything indicating a problem. Again, maybe I don't know
what to look for.

Second, when I started XWin.exe, I didn't get the expected popup from
the Windows firewall. (Maybe that's because the first time I tried it,
it exited too quickly because of the missing IPv6.) I then tried to
manually add the exception, but I get the message that the exception was
already there. This surprised me, because I usually have to unblock a
program each time a new version of the binary is installed.

I agree this is not normal.

Suggestions would be appreciated. I'm attaching cygcheck output, the
XWin log, and partial output from 'netstat -b'. (The deleted portions
don't involve port 6000.)

I guess in the first place I'd suggest you try adding '-nolisten inet6' and
see if that makes a difference to your startup time, then uninstall IPv6 and
see if you can start the server at all with that flag.

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

RE: Novice Question

2009-06-28 Thread Andy

Jon,
Thanks for your help

Yes your correct the IP6 had nothing to do with the problem ..(again thanks)

Here is the backtrace requested



an...@andys-pc /usr/bin
$ gdb --args ./XWin.20090628173519.exe  -multiwindow -clipboard -logverbose
3
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as i686-pc-cygwin...
(gdb) r
Starting program: /usr/bin/XWin.20090628173519.exe -multiwindow -clipboard
-logverbose 3
[New thread 6936.0x1a44]
[New thread 6936.0x1c3c]

Program received signal SIGSEGV, Segmentation fault.
0x0058941d in DefineSelf (fd=1) at
/opt/wip/cygport-svn/xorg-server/xorg-server-1.6.0-10/src/xorg-server-1.6.0/
os/access.c:816
816
/opt/wip/cygport-svn/xorg-server/xorg-server-1.6.0-10/src/xorg-server-1.6.0/
os/access.c: No such file or directory.
in
/opt/wip/cygport-svn/xorg-server/xorg-server-1.6.0-10/src/xorg-server-1.6.0/
os/access.c
(gdb) bt full
#0  0x0058941d in DefineSelf (fd=1) at
/opt/wip/cygport-svn/xorg-server/xorg-server-1.6.0-10/src/xorg-server-1.6.0/
os/access.c:816
broad_addr = {sa_family = 52248, sa_data =
\\000^á\017a\bÐ\\000ôE]}
ifap = (struct ifaddrs *) 0x18271b8
ifr = (struct ifaddrs *) 0x18274a8
len = 4
addr = (unsigned char *) 0x18274f4 :§/\233
family = 0
host = (HOST *) 0x181a190
#1  0x005813d0 in CreateWellKnownSockets ()
at
/opt/wip/cygport-svn/xorg-server/xorg-server-1.6.0-10/src/xorg-server-1.6.0/
os/connection.c:421
fd = 1
i = 0
partial = 0
port = 0\000\000\000\200\233\201\001\230Ì\\000SEX\000\005\000\000
#2  0x00512720 in main (argc=5, argv=incomplete type, envp=incomplete
type)
at
/opt/wip/cygport-svn/xorg-server/xorg-server-1.6.0-10/src/xorg-server-1.6.0/
dix/main.c:285
i = 0
alwaysCheckForInput = {0, 1}
(gdb)

-Original Message-
From: Jon TURNEY [mailto:jon.tur...@dronecode.org.uk] 
Sent: Monday, 29 June 2009 3:23 AM
To: cygwin-xfree@cygwin.com
Cc: andy.stai...@gmail.com
Subject: Re: Novice Question

Andys wrote:
 Trying to get the lastest X to run on Cygwin 1-7 but only seem to be able
to 
 get a core dump  the log:

Firstly, thanks very much for trying it out and reporting the problem.

 XWin was started with the following command line:
 
 /usr/bin/XWin -multiwindow -clipboard -silent-dup-error
 
 ddxProcessArgument - Initializing default screens
 winInitializeDefaultScreens - w 1680 h 1050
 winInitializeDefaultScreens - Returning
 _XSERVTransSocketCreateListener: failed to bind listener
 _XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed
 _XSERVTransMakeAllCOTSServerListeners: failed to create listener for inet6
 
 
 When I run the commands manually from the startxwin.bat I get a
Segmentation 
 Fault (core dumped) 
 
 IP6 is installed on a Vista32 OS but I have no clue on how to  further 
 diagnose the problem

I don't believe IPv6 is the cause of the problem you are seeing, this just 
happens to be the last line of output written.

You could test this by adding '-nolisten inet6' to the command line used to 
start the X server.

 All software used is the latest as of today
 
 Any suggestions welcome

If the suggestion above fails, I'd like your help to get a backtrace, if you

are willing:

1. Download ftp://cygwin.com/pub/cygwinx/XWin.20090628173519.exe.bz2
(this is a build of the 1.6.0.0-1 X server but with debugging symbols
unstripped)
2. bunzip2 XWin.20090628173519.exe.bz2 to uncompress it
3. gdb --args ./XWin.20090628173519.exe  -multiwindow -clipboard -logverbose
3
(you may need to install the gdb package)
4  wait for the '(gdb)' prompt, type 'r'
5. wait for the segmentation fault to occur, you should get another '(gdb)' 
prompt, bt full
6. post the output


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

Re: [1.7] Socket problems after xorg-server update

2009-06-28 Thread Yaakov (Cygwin/X)


On 28/06/2009 13:17, Jon TURNEY wrote:

This is curious. I don't seem to have IPv6 installed and the server
starts fine for me, with that warning.


I was running 1.6.0 on WinXP w/o IPv6 installed for some time.


You could try disabling the IPv6 socket with '-nolisten inet6' to see if
it makes a difference.


It does start a bit faster.


Cygwin 1.7 adds IPv6 support, so the IPv6 support in xtrans is now
turned on.
I guess there could easily be cygwin-specific problems with it...


It seems that the same applies for the other xservers.  But 
interestingly, xscope (which is also acts as an X server, and uses 
Xtrans) starts immediately while emitting the same warning.  So I 
suspect the culprit is in xserver/os/ rather than Xtrans.



1. After running startxwin.bat, it takes about 20 seconds for the X
icon to appear in the taskbar. I guess that's related to the socket
problems reported in the log.


Confirmed; I just hadn't noticed it because of how I was launching X.


Yaakov

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

Re: Novice Question

2009-06-28 Thread Jon TURNEY


Andy wrote:

Jon,
Thanks for your help

Yes your correct the IP6 had nothing to do with the problem ..(again thanks)


Well, I think perhaps the situation is a bit more complex that that :-)



Here is the backtrace requested


Thanks very much, very helpful.

I wonder if I might trouble you to try that all again (you may start from step 
3), also add trying 'p *ifr' at the '(gdb)' prompt...



(gdb) bt full
#0  0x0058941d in DefineSelf (fd=1) at
/opt/wip/cygport-svn/xorg-server/xorg-server-1.6.0-10/src/xorg-server-1.6.0/
os/access.c:816
broad_addr = {sa_family = 52248, sa_data =
\\000^á\017a\bÐ\\000ôE]}
ifap = (struct ifaddrs *) 0x18271b8
ifr = (struct ifaddrs *) 0x18274a8
len = 4
addr = (unsigned char *) 0x18274f4 :§/\233
family = 0
host = (HOST *) 0x181a190



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

Re: [1.7] Socket problems after xorg-server update

2009-06-28 Thread Ken Brown


On 6/28/2009 2:17 PM, Jon TURNEY wrote:

Ken Brown wrote:

After I upgraded to xorg-server-1.6.0-10, XWin.exe exited immediately
with the following error message in the log file:

  _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6


Although it's clear as mud, this message should not be a fatal error, 
just a warning.

[...]
After running startxwin.bat, it takes about 20 seconds for the X 
icon to appear in the taskbar.  I guess that's related to the socket 
problems reported in the log.


This is possible if it's trying some IPv6 address autoconf or something.

I guess in the first place I'd suggest you try adding '-nolisten inet6' 
and see if that makes a difference to your startup time, then uninstall 
IPv6 and see if you can start the server at all with that flag.


Adding that flag cuts the startup time down to 1 or 2 seconds (and the 
error messages are gone from the log file).  I then uninstalled IPv6, 
and XWin.exe died with no error message.  Here's the entire log file:


--
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.6.0.0 (20090401)
Contact: cygwin-xfree@cygwin.com
XWin was started with the following command line:

/usr/bin/XWin -multiwindow -clipboard -silent-dup-error
 -nolisten inet6

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1400 h 1050
winInitializeDefaultScreens - Returning


I reinstalled IPv6 and I'm back in business.  So the bottom line on my 
system is that I need to have IPv6 installed in order to run the X 
server, and I need to tell the X server not to use IPv6 in order to get 
a reasonable startup time.  Strange!


Ken

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

Cannot convert string nil2 to type FontStruct, was: post-upgrade problems

2009-06-28 Thread Tom Roche


Tom Roche Mon, May 25, 2009 at 3:54 PM
 After upgrading from X 6.8.99.901-1 to 7.4-1, I had font problems,
 but could launch an xterm from the new cygwin. After attempting to
 fix that by installing fonts, I cannot launch an xterm

Jon TURNEY Wed, May 27, 2009 at 4:48 PM (heavily edited)
 http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-how-do-i-get-rid-of-xterm-menu

 http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-where-are-my-fonts

Thanks: those (and fiddling) have solved most of my problems. The one
annoyance that remain is this:

Despite installing package=font-misc-misc (recommended by

http://cygwin.com/cgi-bin2/package-grep.cgi?grep=nil2

) via setup.exe, everytime I start an xterm I get

 Warning: Cannot convert string nil2 to type FontStruct

This doesn't seem to cause any functional problem, it just annoys.
(I.e. I hafta hit Enter to get my prompt back.) Uninstalling and
reinstalling font-misc-misc (via setup.exe) was no fix. Any
suggestions?

TIA, Tom Roche tom_ro...@pobox.com

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

winsup/cygwin ChangeLog cygwin.din fhandler.cc ...

2009-06-28 Thread cgf

CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: c...@sourceware.org 2009-06-28 18:23:36

Modified files:
cygwin : ChangeLog cygwin.din fhandler.cc gendef 
 select.cc 

Log message:
* gendef (cleanup): Rename from 'nocr'.  Remove comments and trailing 
spaces.
* cygwin.din: Add long-needed comment describing what 
dll_crt0__FP11per_process
demangles to.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4537r2=1.4538
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/cygwin.din.diff?cvsroot=uberbaumr1=1.211r2=1.212
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler.cc.diff?cvsroot=uberbaumr1=1.346r2=1.347
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/gendef.diff?cvsroot=uberbaumr1=1.32r2=1.33
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/select.cc.diff?cvsroot=uberbaumr1=1.146r2=1.147

winsup/cygwin ChangeLog fhandler.cc fhandler.h ...

2009-06-28 Thread cgf

CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: c...@sourceware.org 2009-06-28 19:23:13

Modified files:
cygwin : ChangeLog fhandler.cc fhandler.h select.cc 

Log message:
* fhandler.h (fhandler_base::has_ongoing_io): Declare new function.
* fhandler.cc (fhandler_base::has_ongoing_io): Define new function.
(fhandler_base::read_overlapped): Use has_ongoing_io to avoid writing 
when
handle has not completed last I/O.
(fhandler_base::write_overlapped): Ditto.
* select.cc (peek_pipe): Be more careful about accessing hEvent field 
from
get_overlapped().

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4538r2=1.4539
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler.cc.diff?cvsroot=uberbaumr1=1.347r2=1.348
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler.h.diff?cvsroot=uberbaumr1=1.365r2=1.366
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/select.cc.diff?cvsroot=uberbaumr1=1.147r2=1.148

winsup/cygwin ChangeLog select.cc

2009-06-28 Thread cgf

CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: c...@sourceware.org 2009-06-28 19:27:15

Modified files:
cygwin : ChangeLog select.cc 

Log message:
* select.cc (peek_pipe): Use has_ongoing_io() to determine if the pipe 
is ready
for writing rather than performing brute-force checks.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4539r2=1.4540
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/select.cc.diff?cvsroot=uberbaumr1=1.148r2=1.149

Re: [RFC] jpeg library

Yaakov (Cygwin/X) wrote:
 On 27/06/2009 13:30, Charles Wilson wrote:
 Well, I no longer need to deal with that sort of imagery, and private
 never really was very private, and it DID cause lots of people grief.
 
 Moreso, the patch removed the height_in_blocks/width_in_blocks members
 from struct jpeg_component_info, which are used in a transupp.c file
 which is part of several desktop image viewers (I know of at least six),
 as well as the progressive_mode member from the jpeg_compress_struct
 struct, which is used in gtk+-2.12 and up.

This is precisely what I'm talking about.  Those fields in struct
jpeg_component_info are explicitly marked private in jpeglib.h:

  /* Remaining fields should be treated as private by applications. */

But they ARE PRESENT in that file, so there is an argument as to exactly
how private they really are. (There's a well established technique for
using opaque pointers to truly private data structures; why doesn't
libjpeg use those techniques?)

So, arguably, those six desktop image viewers as well as gtk+2.12 are
being slightly naughty.

But that's all by the by.  I want to revert the lossless patch going
forward; the question here is how to manage the transition.

 And, our build environment for packages is much nicer now than it was in
 the early days, so any Joe who needs lossless jpeg can easily build it
 themselves.  So, it'd be nice to get rid of the lossless jpeg patch.
 
 +1
 
 Why shouldn't we get rid of it?  Well, because over the years those
 other clients have added lots of workarounds to accommodate cygwin's
 jpeg library.  If we removed the lossless jpeg stuff, then they wouldn't
 need them -- but until they too removed their workarounds, their builds
 would break on cygwin again!
 
 What is the chance of breakage for regular clients?

You mean for clients that aren't naughty, and do not/never did access
these private fields?  None, as far as I can tell.  The *size* of the
struct doesn't change. Only the names of some of the fields (not their
type), and their meaning.  Some purely internal structs change
significantly, but that shouldn't affect external clients, even naughty
ones.

Although the actual strings associated with various error code numbers
changes, so that could lead to some surprising incorrect error messages
until clients are recompiled.

In any event, if I release a new cygjpeg-62.dll (same as current name)
without the lossless jpeg patch, and it DOES break everything in sight,
well then, I'll withdraw it and we'll go with the plan B transition.

 I propose to release a new libjpeg for cygwin-1.7 using gcc4 with the
 shared libgcc runtime, once both cygwin-1.7 and gcc4 are officially
 non-beta (e.g. moved to curr, not test).  This libjpeg will be named:
 
 I presume that an upstream (ABI) version bump -- the easiest time to
 make changes like this -- is not in sight.

Nope. Upstream development is DEAD.  There was some flurry of activity
about two years ago, but it never went anywhere.   If IJG's libjpeg
wasn't so widespread and widely used, I'd want to look at some other
library that supports the format...

 just like the current packages, where N  20  The DLL number, name, and
 package name will NOT be incremented.  Existing packages that use
 libjpeg, AND that illegally accessed the so-called private data
 members, will break and will need to be recompiled, without whatever
 internal workarounds they had previously implemented to deal with our
 lossless stuff.
 
 May I suggest making these available for a limited-time manual download
 for maintainers to test and, if necessary, rebuild their own packages to
 be ready when these are released.

Well, test release, sure.  But given the interlocking dependencies of
libraries (esp. graphics libraries), you'd need an ever-increasing
number of these libraries in pending/test state. I don't have the
bandwidth to manage that outside of the sourceware facilities.  Since we
have a perfectly good mirror system and test status already available
for such things...

 I could be persuaded to release it earlier.  That is, before cygwin-1.7
 goes live although I'd rather not cause instability in the distro this
 close to cygwin-1.7's release.  Or, sometime after cygwin-1.7.1, but
 before gcc-4.x goes gold.
 
 I think earlier is better, but it should be coordinated.

Well, with 1.7 due out sometime in the next week or so, I really don't
want to destabilize that.

 The downside of this approach is cygwin's jpeg DLL would have a
 different name than is normally implied by the stock build machinery, and
a) we would continue to have to patch our jpeg builds to use the new
 numbering sequence in perpetuity
 
 Which is one reason I was against gcc4-ABI-bumps in the first place.

Where I begin acting as the devil's advocate:

Yeah, but on the other hand, every distro out there has a stack of
patches for libjpeg, because upstream is dead but the code has bugs.
Thus, debian has a list of libjpeg patches that, for all

Re: [RFC] jpeg library

2009-06-28 Thread Yaakov (Cygwin/X)


On 28/06/2009 01:17, Charles Wilson wrote:

You mean for clients that aren't naughty, and do not/never did access
these private fields?  None, as far as I can tell.  The *size* of the
struct doesn't change. Only the names of some of the fields (not their
type), and their meaning.  Some purely internal structs change
significantly, but that shouldn't affect external clients, even naughty
ones.

Although the actual strings associated with various error code numbers
changes, so that could lead to some surprising incorrect error messages
until clients are recompiled.

In any event, if I release a new cygjpeg-62.dll (same as current name)
without the lossless jpeg patch, and it DOES break everything in sight,
well then, I'll withdraw it and we'll go with the plan B transition.


That should be easily verified with a bit of testing on everyone's part, 
*before* the release.



Well, test release, sure.  But given the interlocking dependencies of
libraries (esp. graphics libraries), you'd need an ever-increasing
number of these libraries in pending/test state. I don't have the
bandwidth to manage that outside of the sourceware facilities.  Since we
have a perfectly good mirror system and test status already available
for such things...


If there is indeed no ABI breakage in the normal case, there shouldn't 
be any need for a bunch of packages in testing; everyone just tests the 
new libjpeg62, and if their package(s) still work, nothing more to do, 
right?



Well, with 1.7 due out sometime in the next week or so, I really don't
want to destabilize that.


That shouldn't stop you from a test: version ASAP.


Yeah, but on the other hand, every distro out there has a stack of
patches for libjpeg, because upstream is dead but the code has bugs.
Thus, debian has a list of libjpeg patches that, for all intents and
purposes, they must now maintain in perpetuity.


True; thankfully the Linux distros are doing the hard work for us. :-)


But this isn't a pseudo-incompatibility caused by a simple switch to
gcc4/shared-libgcc. This is a real ABI violation we're contemplating.
It's exactly what DLL version number bumps are FOR.


Freetype went through a similar transition some time ago[1]: they used 
to expose many internal symbols and headers, and before 2.2.0 they 
stopped.  Interestingly, they didn't change the ABI number, since the 
only changes were to things supposed to be internal.  Everyone fixed 
their packages (and the FT devs did help provide packages), and life 
moved on.


[1] http://freetype.sourceforge.net/freetype2/freetype-2.2.0.html


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: [RFC] jpeg library

2009-06-28 Thread Yaakov (Cygwin/X)


On 28/06/2009 01:17, Charles Wilson wrote:

Nope. Upstream development is DEAD.  There was some flurry of activity
about two years ago, but it never went anywhere.   If IJG's libjpeg
wasn't so widespread and widely used, I'd want to look at some other
library that supports the format...


Actually, are you sure about that?  http://www.ijg.org/ lists a version 
7, released yesterday, as the current version.



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: Installing Tidyview.pl on Cygwin

2009-06-28 Thread Reini Urban

2009/6/28 Chap Harrison:
 Has anyone successfully installed Tidyview on Cygwin ?
 Or, for that matter, ANYTHING Tk-related?

perl-Tk is for X11, so you need various X.Org devel packages.

perl Tk native does not yet compile under cygwin.
I've made some progress with Tk native last year but I don't think
my patches are already included. You might check the bugtracker.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/

--
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: Cygwin OpenSSH and Windows 7 RC

2009-06-28 Thread Matthias Meyer

David Christensen wrote:

 Matthias Meyer wrote:
 Most of the time ssh can not connect to the sshd in Windows7.
 In my logfile (in Windows7) I found:
  7300 [main] sshd 3772 child_copy: linked dll data write copy failed,
 0x2C5000..0x2C52E0, done 0, windows pid 3512, Win32 error 487
 
 Have you done a rebaseall?
 
  
 http://www.heikkitoivonen.net/blog/2008/11/26/cygwin-upgrades-and-rebase
 all/
 
 
 I was getting weird Perl 'make test' errors, and rebaseall fixed them.
 
 
 David

If I rebase within Windows7 I can not use this programs and librarys within
other versions of Windows, right?

Matthias
-- 
Don't Panic


--
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: popup consoles on Windows 7

On Jun 27 09:39, Andy Koppe wrote:
 2009/6/26 Corinna Vinschen:
  On Jun 26 15:08, Julio Costa wrote:
  I've been following this discussion, crossing fingers to someone came
  to some conclusion, as this is the biggest show-stopper for Cygwin in
  several months.
 
  I've not access to a Win 7, but I would like at least to drop some
  ideas to someone with more insight comment on and (hopefully) come to
  a solution.
 
  1) If we make a service (let's call it cygconsole, or include it in
  cygserver, whatever), with no desktop interaction, whose only purpose
  is to AllocConsole()...
  1.a) do that console gets created?
  1.b) Is it invisible?
 
  2) IF the two answers are true, then
  2.a) Do an arbitary process can do an attachconsole to the PID of that 
  service?
 
  IF it is also an YES, we have a framework for an
  workaround/alternative implementation! Cool?
 
  It's an interesting idea, but rather tricky to implement.  I assume
  you will get an ERROR_ACCESS_DENIED when trying to attach to a console
  of another user, and a cygserver service would usually run under SYSTEM.
  Relying on a service at all doesn't sound overly tempting, either.  I'm
  still hoping for another solution.
 
 How about implementing this idea solely in the Cygwin DLL rather than
 through a service, i.e. the first process that needs a hidden console
 allocates one, and any subsequent processes attach to that.
 
 Only problem is that the console is automatically freed once all
 processes using it have finished, so a new one would have to be
 allocated again when another process comes along that needs one.

Yeah, that could be an option as a per-session workaround if there's
no other way to accomplish it.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: Cygwin OpenSSH and Windows 7 RC

On Jun 28 12:18, Matthias Meyer wrote:
 David Christensen wrote:
 
  Matthias Meyer wrote:
  Most of the time ssh can not connect to the sshd in Windows7.
  In my logfile (in Windows7) I found:
   7300 [main] sshd 3772 child_copy: linked dll data write copy failed,
  0x2C5000..0x2C52E0, done 0, windows pid 3512, Win32 error 487
  
  Have you done a rebaseall?
  
   
  http://www.heikkitoivonen.net/blog/2008/11/26/cygwin-upgrades-and-rebase
  all/
  
  
  I was getting weird Perl 'make test' errors, and rebaseall fixed them.
  
  
  David
 
 If I rebase within Windows7 I can not use this programs and librarys within
 other versions of Windows, right?

rebasing has nothing to do with the OS on which you use the DLLs.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: Running 1.5 and 1.7 sshd in parallel

On Jun 26 22:25, Federico Hernandez wrote:
 THX for the fast answer. That is exactly what I tried.
 
 1.5 on port 22
 1.7 on port 
 
 but when I ssh into  I endup in $HOME of 1.5 and sometimes the
 sshd on  doesn't start.
 
 How can I select each of the sshd in a more controlled way so that I
 can specify which daemon to start and stop?

Install it under different service names.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: Network drive issue -- 'no such host or network path'

On Jun 27 18:40, Stephen Wilkinson wrote:
 Hello,
 
 I use cygwin on a computer with mapped network drives. In the cygwin shell, I 
 can list the contents of local drives, but not that of mapped network drives, 
 even though I have no problem in DOS. It's frustrating because I can't use 
 tab completion on a file on a network drive either.
 
 For example, drive U: is mapped to a network shared folder. In DOS 'dir U:\' 
 works, but in bash in cygwin 'ls /cygdrive/u/' gives me the error 'no such 
 host or network path'.

Is that on 1.5.25?  Did you try with Cygwin 1.7?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: mkstemps

On Jun 27 16:56, Eric Blake wrote:
 It would be nice to have mkstemps in cygwin.  In particular, git would
 like to use it, because it is often the case that a temporary file should
 have the same extension as what it is being modified from, for tools that
 care about file suffix.  I've proposed adding it to newlib, but cygwin
 doesn't use newlib's mktemp.c, and I'm not sure whether the changes are
 trivial enough for me to do for cygwin (where I don't have copyright on
 file), so I'm floating this out there to see if anyone else is willing to
 write the patch.

Well, if your patch is accepted in newlib, it should be not much of a
problem to tweak it slightly for inclusion into Cygwin, even if you're
doing the tweak...


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: Running 1.5 and 1.7 sshd in parallel

2009-06-28 Thread Spiro Trikaliotis

Hello,

* On Sun, Jun 28, 2009 at 12:31:09PM +0200 Corinna Vinschen wrote:
 On Jun 26 22:25, Federico Hernandez wrote:
  THX for the fast answer. That is exactly what I tried.
  
  1.5 on port 22
  1.7 on port 
  
  but when I ssh into  I endup in $HOME of 1.5 and sometimes the
  sshd on  doesn't start.
  
  How can I select each of the sshd in a more controlled way so that I
  can specify which daemon to start and stop?
 
 Install it under different service names.

Just a question: Wouldn't the differing cygwin1.dll (1.5 vs 1.7) be
problematic when both sshd are started?

Regards,
Spiro.

-- 
Spiro R. Trikaliotis  http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.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: [RFC] jpeg library

Yaakov (Cygwin/X) wrote:
 On 28/06/2009 01:17, Charles Wilson wrote:
 Nope. Upstream development is DEAD.  There was some flurry of activity
 about two years ago, but it never went anywhere.   If IJG's libjpeg
 wasn't so widespread and widely used, I'd want to look at some other
 library that supports the format...
 
 Actually, are you sure about that?  http://www.ijg.org/ lists a version
 7, released yesterday, as the current version.

  I was just about to say We could always try and find a security
vulnerability, that's the only thing that would cause upstream to update
libjpeg these days!  :)  But then I took a look at the new change.log and it's
actually crammed with new and improved functionality, so this is an ideal
opportunity.

  I think the makes freezing (obsoleting) libjpeg-6b forever with the lossless
patch incorporated, and just moving to a straight unpatched release of
libjpeg-7 a no-brainer doesn't it?  What a fortuitous bit of timing!

cheers,
  DaveK


--
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: [RFC] jpeg library

Yaakov (Cygwin/X) wrote:
 On 28/06/2009 01:17, Charles Wilson wrote:
 Nope. Upstream development is DEAD.  There was some flurry of activity
 about two years ago, but it never went anywhere.   If IJG's libjpeg
 wasn't so widespread and widely used, I'd want to look at some other
 library that supports the format...
 
 Actually, are you sure about that?  http://www.ijg.org/ lists a version
 7, released yesterday, as the current version.

WTH?  You're kidding me...I'm floored.  There's a private mailing list
(with no online archives, natch) for the IJG project, but my
subscription is with an different email account, so I haven't checked it
in a while...nope, no activity on THAT list recently.  Maybe there's a
new list?

Anyway, wow.  OK, this changes things...

From the (competing?) libjpeg on sourceforge, there was a conversation
earlier this week, involving Guido Vollbeding (current IJG jpeg
maintainer), Tom Lane (previous IJG jpeg maintainer), and Bob
Friesenhahn (sourceforge libjpeg maintainer, GraphicsMagick).  Guido said:

 I have taken great care that v6b can be replaced seamlessly with v7,
 and even v8 will remain API compatible while introducing essential
 novelties.

BUT...they went ahead and changed the library version number anyway. In
the sourceforge code (on which cygwin's current jpeg is based), it was
-version-info=62.  In the new jpeg-v7 code, it is -version-info=7:0

In effect, this represents a change from cygjpeg-62.dll to
cygjpeg-7.dll.  Given the speed of jpeg development, I doubt any of us
will be alive when the new DLL number series gets up to 61 (at over 10
years per major number...it'll be 2549 A.D. before we get there).

In that same conversation, there is a lot of mention of the use of
symbol versioning as the panacea for all possible version conflicts.
Nobody has seemed to point out that it works only on ELF systems.

Looks like jpeg-7 incorporates a number of the Debian patches, and many
of the patches from jpegclub.org, so that's good (Hmmm. Actually, the
jpegclub.org website has been updated and now claims
JPEGclub.org...maintains the Independent JPEG Group's (IJG) software..
I guess this isn't surprising, as jpegclub.org has always been Guido
Vollbeding's site; now that he's taken over from Tom Lane officially,
this only makes sense).

So, to sum up: ORDINARILY, the new jpeg library should be binary
compatible (and definitely API compatible) with the old one.  It has
lots of new functionality, but in a backwards-compatible way.  However,
they changed the SONAME anyway, which gives us the perfect opportunity
we're looking for.

OK...new plan:  jpeg-v7 will be released for cygwin-1.7 only, using
gcc4/dw2/shared-libgcc only, and will have the name cygjpeg-7.dll.  It
will NOT have lossless jpeg support.

I'll do this soon.

--
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: [RFC] jpeg library

Dave Korn wrote:
   I was just about to say We could always try and find a security
 vulnerability, that's the only thing that would cause upstream to update
 libjpeg these days!  :)  But then I took a look at the new change.log and it's
 actually crammed with new and improved functionality, so this is an ideal
 opportunity.
 
   I think the makes freezing (obsoleting) libjpeg-6b forever with the lossless
 patch incorporated, and just moving to a straight unpatched release of
 libjpeg-7 a no-brainer doesn't it?  What a fortuitous bit of timing!

Yep.  Sometimes you get lucky.  Not often -- that's why it's called luck.

--
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: Cygwin OpenSSH and Windows 7 RC

2009-06-28 Thread Matthias Meyer

Corinna Vinschen wrote:

 On Jun 28 12:18, Matthias Meyer wrote:
 David Christensen wrote:
 
  Matthias Meyer wrote:
  Most of the time ssh can not connect to the sshd in Windows7.
  In my logfile (in Windows7) I found:
   7300 [main] sshd 3772 child_copy: linked dll data write copy failed,
  0x2C5000..0x2C52E0, done 0, windows pid 3512, Win32 error 487
  
  Have you done a rebaseall?
  
   
 
http://www.heikkitoivonen.net/blog/2008/11/26/cygwin-upgrades-and-rebase
  all/
  
  
  I was getting weird Perl 'make test' errors, and rebaseall fixed them.
  
  
  David
 
 If I rebase within Windows7 I can not use this programs and librarys
 within other versions of Windows, right?
 
 rebasing has nothing to do with the OS on which you use the DLLs.
 
 
 Corinna
 
Than, maybee, rebasing is not a solution for my problem.
I build an own setup, similar cwrsync. This setup run well within XP and
Vista. But in Windows7rc the sshd have the above problem.

So I want to ask:
Should I rebase cygwin within Windows7?
And if I install this rebased programs and librarys within XP, should it
work too?

Thanks
Matthias
-- 
Don't Panic


--
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: [RFC] jpeg library

Charles Wilson wrote:

 In that same conversation, there is a lot of mention of the use of
 symbol versioning as the panacea for all possible version conflicts.
 Nobody has seemed to point out that it works only on ELF systems.

  This will not be a problem for us forever, I hope :)

cheers,
  DaveK


--
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

Update request: cygwin binutils package due to an available patch

2009-06-28 Thread Claudius Schnörr


Hello,

due to a bug I reported recently 
(http://sourceware.org/bugzilla/show_bug.cgi?id=9909) a patch is available.

Patch: http://sourceware.org/bugzilla/attachment.cgi?id=3868action=view

Could anyone please provide an update for cygwin-binutils? I woule 
appreciate it very much.


Thank you,

Claudius

--
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: Update request: cygwin binutils package due to an available patch