ATTENTION: Tcl/Tk transition

ATTENTION: Tcl/Tk transition

[Yaakov (Cygwin/X)]

[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]

cgf has asked me to take over tcl/tk/expect maintainership and
transition the distro from our Win32/GDI hybrid 8.4 to the *NIX/X11 8.5
currently in Ports.

ITA:
expect
tcltk (to be obsoleted)

ITP (in place of tcltk):
tcl
tcl-itcl
tcl-itk
tcl-iwidgets
tcl-tix
tcl-tk

(I have more extensions in Ports if anyone needs them.)

The packages are currently available in Ports here:

ftp://ftp.cygwinports.org/pub/cygwinports/release-2/Tcl/

For the purpose of a smooth upgrade, affected maintainers should run the
following commands before rebuilding:

# cygcheck -l tcltk | d2u | xargs rm -f
# tar jxf tcl-8.5.10-1.tar.bz2 -C /
# tar jxf tcl-tk-8.5.10-1.tar.bz2 -C /

Once rebuilt, please respond to this email with an RFU, and I'll upload
once enough is in place to avoid breaking the distro.

The following packages will need an IMMEDIATE rebuild:

* db [tcl-dbX.Y] (Dr. Volker Zell)
new requires: tcl
notes: perhaps you should just build the latest db 4.x and/or 5.x with
this tcl and we can drop the earlier bindings?

* ming [tcl-ming] (Dr. Volker Zell)
new requires: tcl
notes: needs a pkgIndex.tcl file to be of any use

* python[-tkinter] (Jason Tishler)
new requires: tcl tcl-tk tcl-tix
notes: requires attached patch

* ruby (Corinna Vinschen)
new requires: tcl tcl-tk
notes: I suggest making a make separate ruby-tcltk package due to the
additional deps.

* suite3270 [tcl3270] (Peter A. Castro)
new requires: tcl

* WordNet (Dr. Volker Zell)
new requires: tcl tcl-tk
notes: needs patches for security vulnerabilities, patches available
from all major distros, e.g.:
http://pkgs.fedoraproject.org/gitweb/?p=wordnet.git;a=tree

The following packages do NOT require an immediate rebuild, so I'll just
change their requires on sourceware accordingly:

* catdoc (Reini Urban)
new requires: tcl tcl-tk

* gdb (cgf)
Version 7.x no longer requires tcltk.

* git [gitg/git-gui] (Eric Blake)
new requires: tcl tcl-tk
notes: need to ditch the cygpath line with the next release


Yaakov
Cygwin/X


[-- Attachment #2: 2.5.2-tkinter-x11.patch --]
[-- Type: text/x-patch, Size: 1110 bytes --]

--- origsrc/Python-2.5.2/setup.py	2008-02-04 17:41:02.000000000 -0600
+++ src/Python-2.5.2/setup.py	2008-07-02 02:11:28.671875000 -0500
@@ -1277,12 +1279,6 @@
             include_dirs.append('/usr/X11/include')
             added_lib_dirs.append('/usr/X11/lib')
 
-        # If Cygwin, then verify that X is installed before proceeding
-        if platform == 'cygwin':
-            x11_inc = find_file('X11/Xlib.h', [], include_dirs)
-            if x11_inc is None:
-                return
-
         # Check for BLT extension
         if self.compiler.find_library_file(lib_dirs + added_lib_dirs,
                                            'BLT8.0'):
@@ -1300,9 +1296,8 @@
         if platform in ['aix3', 'aix4']:
             libs.append('ld')
 
-        # Finally, link with the X11 libraries (not appropriate on cygwin)
-        if platform != "cygwin":
-            libs.append('X11')
+        # Finally, link with the X11 libraries
+        libs.append('X11')
 
         ext = Extension('_tkinter', ['_tkinter.c', 'tkappinit.c'],
                         define_macros=[('WITH_APPINIT', 1)] + defs,

Re: ATTENTION: Tcl/Tk transition

[Yaakov (Cygwin/X)]

On Wed, 2011-10-26 at 16:02 -0500, Yaakov (Cygwin/X) wrote:
> The following packages will need an IMMEDIATE rebuild:

Oops, I missed one:

* brltty [tcl-brlapi] (Samuel Thibault)
new requires: tcl


Yaakov

Re: ATTENTION: Tcl/Tk transition

[Marco Atzeri]

On 10/26/2011 11:06 PM, Yaakov (Cygwin/X) wrote:
> On Wed, 2011-10-26 at 16:02 -0500, Yaakov (Cygwin/X) wrote:
>> The following packages will need an IMMEDIATE rebuild:
>
> Oops, I missed one:
>
> * brltty [tcl-brlapi] (Samuel Thibault)
> new requires: tcl
>
>
> Yaakov
>
>

stupid question: should not be easier for testing the new packages
and upgrading the other ones that you put them in the distro as
experimental ?
I know that the maintainers you mentioned have no problems
but eventually there are other people that need to test them in advance.


Regards
Marco

Re: ATTENTION: Tcl/Tk transition

[Marco Atzeri]

On 10/26/2011 11:24 PM, Marco Atzeri wrote:

>
> stupid question: should not be easier for testing the new packages
> and upgrading the other ones that you put them in the distro as
> experimental ?
> I know that the maintainers you mentioned have no problems
> but eventually there are other people that need to test them in advance.
>
>
> Regards
> Marco
>

it is a stupid question, setup will install in any case also the
old packages so a crash is assured...

Regards
Marco

Re: ATTENTION: Tcl/Tk transition

[Cary R.]

Yaakov,



If I'm understanding this correctly once this change has been
pushed we will be required to start an X server beforerunning
gitk. As someone who uses git and gitk all the time having to
start the X server to run gitk is a pain. I haven't checked this
recently, but in the past the X server was a bit of a resource
hog so my typical pattern is toonly start it when needed and
that's not very often.


I understand the desire to switch to X, but I think this deserves
some thought on how it will effect the general users.


Cary

----- Original Message -----
From: Yaakov (Cygwin/X)
Subject: ATTENTION: Tcl/Tk transition

cgf has asked me to take over tcl/tk/expect maintainership and
transition the distro from our Win32/GDI hybrid 8.4 to the *NIX/X11 8.5
currently in Ports.

<SNIP>

* git [gitg/git-gui] (Eric Blake)
new requires: tcl tcl-tk
notes: need to ditch the cygpath line with the next release


Yaakov
Cygwin/X

Re: ATTENTION: Tcl/Tk transition

[Christopher Faylor]

On Wed, Oct 26, 2011 at 02:53:48PM -0700, Cary R. wrote:
>Yaakov,
>
>
>
>If I'm understanding this correctly once this change has been
>pushed we will be required to start an X server beforerunning
>gitk. As someone who uses git and gitk all the time having to
>start the X server to run gitk is a pain. I haven't checked this
>recently, but in the past the X server was a bit of a resource
>hog so my typical pattern is toonly start it when needed and
>that's not very often.
>
>
>I understand the desire to switch to X, but I think this deserves
>some thought on how it will effect the general users.

We made the decision to switch to a "real" X-based tk long ago.  The
hacked version has always been barely supported and is very out of date.
Continuing to support it would require real understanding of tk and
I don't think anyone wants to take on that task, unless you're
volunteering.

cgf

Re: ATTENTION: Tcl/Tk transition

[Charles Wilson]

On 10/26/2011 5:53 PM, Cary R. wrote:
> If I'm understanding this correctly once this change has been
> pushed we will be required to start an X server beforerunning
> gitk.

Yes.

> As someone who uses git and gitk all the time having to
> start the X server to run gitk is a pain. I haven't checked this
> recently, but in the past the X server was a bit of a resource
> hog so my typical pattern is toonly start it when needed and
> that's not very often.

Well, the cygwin-X folks have made a lot of improvements over the past
year or so (and the accelerated version looks to be coming along...).
However, because XWin.exe /is/ a cygwin app, it suffers all the normal
posix->win32 emulation penalties that every cygwin app does.

So, one solution is to just use the native win32 XMing xserver
(free-as-in-beer version, or the donation-supported one).  tk only
depends on libX11.dll (no other X extensions), so on the client side tk
is fairly light in its X-incarnation.

Also, here's the cygwin-git maintainer from three years ago:
http://www.cygwin.com/ml/cygwin/2008-08/msg00095.html
Eric Blake wrote:
> According to Christopher Faylor on 8/4/2008 5:38 PM:
> | That opens the door to building a
> | real version of tcl/tk for cygwin and linking insight to it.
> 
> 
> YEAH!  Among others, the git package would appreciate the availability of
> a modern tcl/tk.

So...

> I understand the desire to switch to X, but I think this deserves
> some thought on how it will effect the general users.

Well, I think it *has* been thought about, and discussed, quite a bit.
The decision was pretty much adopted -- only the implementation has been
delayed due to (a) lack of roundtuits of the 'cgf' denomination, (b) in
the far past, we had no /modern/ (7.x) X implementation and were limping
along with a very old X distro.

Obviously, until (b) was fixed, it made no sense to modify tcltk.  And
until (a) improved -- which, apparently, it never did -- the
implementation couldn't happen.  Hence, cgf's decision to invite Yaakov
to take over.

Here are some of the previous discussions:

Interest in "native" Tcl/Tk/Expect/Itcl/... packages?
http://cygwin.com/ml/cygwin-apps/2004-10/msg00316.html

Does anyone use insight on cygwin?
http://www.cygwin.com/ml/cygwin/2008-08/msg00089.html

tcl/tk/expect/dejagnu/gdb/insight
http://cygwin.com/ml/cygwin/2009-09/msg00311.html

gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32
app.
http://cygwin.com/ml/cygwin/2010-08/msg00913.html

====NOTE====
in the gitk thread above, Reini Urban, the cygwin perl and parrot
maintainer, was vehemently against switching tcltk from GDI to X11.  I
wonder if his opinion has changed in the past year...

Tcl file separator
http://cygwin.com/ml/cygwin/2011-01/msg00257.html
(esp. http://cygwin.com/ml/cygwin/2011-01/msg00369.html)

Re: RFC: Cygwin 64 bit?
http://cygwin.com/ml/cygwin-developers/2011-06/msg00081.html

--
Chuck

Re: ATTENTION: Tcl/Tk transition

[Cary R.]

I already spend most of my free time working on an
open source Verilog simulator, so unfortunately, no,
I'm not goingto volunteer. I understand the reason
for switching,but be prepared for some serious user
complaintsonce this is implemented.


I don't normally have time to read the general cygwin
list, but if you haven't done so already I will strongly
suggest starting a thread there that discusses this
changeand its ramifications. To me the ramifications
are the most important for the general users. I'm sure
the developers have discussed this in great detail and
I vaguely remember discussions about this in the
past,but I'mguessing the normal users will be quite

surprised bythis change.


I can adapt and Linux inside VirtualBox has softened
my usage of cygwin already. gitk requiring an X server
maypush me a bit further in that direction.


Cary



----- Original Message -----
cfg wrote
Subject: Re: ATTENTION: Tcl/Tk transition

On Wed, Oct 26, 2011 at 02:53:48PM -0700, Cary R. wrote:
>Yaakov,
>
>
>
>If I'm understanding this correctly once this change has been
>pushed we will be required to start an X server beforerunning
>gitk. As someone who uses git and gitk all the time having to
>start the X server to run gitk is a pain. I haven't checked this
>recently, but in the past the X server was a bit of a resource
>hog so my typical pattern is toonly start it when needed and
>that's not very often.
>
>
>I understand the desire to switch to X, but I think this deserves
>some thought on how it will effect the general users.

We made the decision to switch to a "real" X-based tk long ago.  The
hacked version has always been barely supported and is very out of date.
Continuing to support it would require real understanding of tk and
I don't think anyone wants to take on that task, unless you're
volunteering.

cgf

Re: ATTENTION: Tcl/Tk transition

[Christopher Faylor]

On Wed, Oct 26, 2011 at 03:59:18PM -0700, Cary R. wrote:
>I already spend most of my free time working on an open source Verilog
>simulator, so unfortunately, no, I'm not going to volunteer.  I
>understand the reason for switching, but be prepared for some serious
>user complaints once this is implemented.

I've been with the Cygwin project for more than a decade.  I know what
to (excuse the expression) expect.  And, I'm sure that Yaakov who has
also been around for a while and maintains scores of important packages
is also quite aware that people will be surprised by any major change,
even ones that are preannounced.

You don't have the inclination to work on supporting
tk-on-windows-with-a-side-of-cygwin.  Neither does anyone else.  Keeping
tcl/tk in the dark ages and potentially causing problems for programs
like expect and gitk is a sure recipe for complaints since programs are
drifting further and further from optimal configurations.  In fact, this
whole thread is prompted by a complaint/request in the cygwin list.

>I don't normally have time to read the general cygwin list, but if you
>haven't done so already I will strongly suggest starting a thread there
>that discusses this changeand its ramifications.  To me the
>ramifications are the most important for the general users.  I'm sure
>the developers have discussed this in great detail and I vaguely
>remember discussions about this in the past, but I'm guessing the
>normal users will be quite surprised bythis change.
>
>I can adapt and Linux inside VirtualBox has softened my usage of cygwin
>already.  gitk requiring an X server may push me a bit further in that
>direction.

If you feel the need to raise the alarm to the Cygwin list, please go
ahead.  It's hard for me to see what you're expecting, though.  You
don't want things to change but you don't seem to be proposing any
solutions other than, presumably, "don't update anything".

If you think that running VirtualBox is really an alternative to just
starting X then that's definitely something you should pursue even if
it's hard to see how that jives with your concern that "the X server was
a bit of a resource hog".

cgf

Re: ATTENTION: Tcl/Tk transition

[Yaakov (Cygwin/X)]

[-- Attachment #1: Type: text/plain, Size: 250 bytes --]

On Wed, 2011-10-26 at 16:02 -0500, Yaakov (Cygwin/X) wrote:
> * ruby (Corinna Vinschen)
> new requires: tcl tcl-tk
> notes: I suggest making a make separate ruby-tcltk package due to the
> additional deps.

Patches for 1.8.7-p352 attached.


Yaakov


[-- Attachment #2: 1.8.7-cygwin-uuid.patch --]
[-- Type: text/x-patch, Size: 432 bytes --]

libuuid from util-linux hides the w32api libuuid.a, which serves a 
completely different purpose.

--- origsrc/ruby-1.8.7-p352/ext/win32ole/extconf.rb	2010-11-22 01:22:26.000000000 -0600
+++ src/ruby-1.8.7-p352/ext/win32ole/extconf.rb	2011-10-26 19:21:29.696817700 -0500
@@ -35,5 +35,7 @@ end
 case RUBY_PLATFORM
 when /mswin32/
   $CFLAGS += ' /W3'
+when /cygwin/
+  $LDFLAGS += ' -L/usr/lib/w32api'
 end
 create_win32ole_makefile

[-- Attachment #3: 1.8.7-cygwin-tcltk.patch --]
[-- Type: text/x-patch, Size: 601 bytes --]

--- origsrc/ruby-1.8.7-p352/ext/tk/extconf.rb	2011-06-29 22:53:30.000000000 -0500
+++ src/ruby-1.8.7-p352/ext/tk/extconf.rb	2011-10-26 19:07:48.530860500 -0500
@@ -106,7 +106,7 @@ end
 # fuctions
 ##############################################################
 def is_win32?
-  /mswin|mingw|cygwin|bccwin/ =~ RUBY_PLATFORM
+  /mswin|mingw|bccwin/ =~ RUBY_PLATFORM
 end
 
 def is_macosx?
@@ -1762,7 +1762,6 @@ unless is_win32?
   print("\n") # progress
 end
 $CPPFLAGS ||= ""
-$CPPFLAGS += ' -D_WIN32' if /cygwin/ =~ RUBY_PLATFORM
 
 # Does ruby have nativethread ?
 TkLib_Config["ruby_with_thread"] =

[-- Attachment #4: 1.8.7-cygwin17.patch --]
[-- Type: text/x-patch, Size: 1357 bytes --]

_longjmp now returns void, but they don't need to be prototyped here.

--- origsrc/ruby-1.8.7-p72/eval.c	2008-08-03 22:24:26.000000000 -0500
+++ src/ruby-1.8.7-p72/eval.c	2009-03-17 22:31:22.248727500 -0500
@@ -196,9 +196,6 @@ static int volatile freebsd_clear_carry_
 #  define ruby_setjmp(just_before_setjmp, env) \
      ((just_before_setjmp), RUBY_SETJMP(env))
 #  define ruby_longjmp(env,val) RUBY_LONGJMP(env,val)
-#  ifdef __CYGWIN__
-int _setjmp(), _longjmp();
-#  endif
 #endif
 
 #include <sys/types.h>
--- origsrc/ruby-1.8.7-p72/file.c	2008-07-10 04:47:31.000000000 -0500
+++ src/ruby-1.8.7-p72/file.c	2009-03-17 22:51:40.295602500 -0500
@@ -2758,7 +2758,7 @@ file_expand_path(fname, dname, result)
 	    is_symlink = 1;
 	    *p = '\0';
 	}
-	if (cygwin_conv_to_win32_path((*buf ? buf : "/"), w32buf) == 0) {
+	if (cygwin_conv_path(CCP_POSIX_TO_WIN_A, (*buf ? buf : "/"), w32buf, MAXPATHLEN) == 0) {
 	    b = w32buf;
 	}
 	if (is_symlink && b == w32buf) {
--- origsrc/ruby-1.8.7-p72/gc.c	2008-08-03 22:24:26.000000000 -0500
+++ src/ruby-1.8.7-p72/gc.c	2009-03-17 22:52:17.420602500 -0500
@@ -39,9 +39,6 @@ void rb_io_fptr_finalize _((struct rb_io
 
 #define rb_setjmp(env) RUBY_SETJMP(env)
 #define rb_jmp_buf rb_jmpbuf_t
-#ifdef __CYGWIN__
-int _setjmp(), _longjmp();
-#endif
 
 /* Make alloca work the best possible way.  */
 #ifdef __GNUC__

Re: ATTENTION: Tcl/Tk transition

[Cary R.]

And I've been using Cygwin for over a decade. While I'm at it

thanks to all for making life bearable on a windows machine!

FYI expect is what drew me to Tcl/Tk a very long time ago.

Trust that I understand the need to be using a more modern
version of Tcl/Tk. I'm just whining that we're going to loose the
GDI support. Since I'm not going to do anything to help the
situation thisis the last I'll post on the subject.

I did some quick testing and yes the new X server is much
better. All my prejudices came from Cygwin 1.5 days on a
slower laptop. The combination of a newer laptop and
Cygwin 1.7/newer X server makes a significant difference.


The benefit I get from using VirtualBox for development  is

that with Cygwinour test suite takes 818 second andwith
Linuxinside VirtualBox it takes 45 seconds. As you can
see itdoesn'ttake too many test cycles to result in a
significanttimesavings and yes this is the same version
of the codeon the same machine with all the other
processes idle. For me the resource cost of Virtual Box
is 1G of memory and a 30-45 second startup/shutdown
times. Depending on what I'm doing and how long I'm
going to be doing it this is acceptable given the smaller
testing times.

Don't construe any of this as a slam on Cygwin. I still
think it is a great setup!


Cary (who understands and appreciates all that goes

        into working on free software)



----- Original Message -----
From: Christopher Faylor
Sent: Wednesday, October 26, 2011 4:34 PM
Subject: Re: ATTENTION: Tcl/Tk transition

On Wed, Oct 26, 2011 at 03:59:18PM -0700, Cary R. wrote:
>I already spend most of my free time working on an open source Verilog
>simulator, so unfortunately, no, I'm not going to volunteer.  I
>understand the reason for switching, but be prepared for some serious
>user complaints once this is implemented.

I've been with the Cygwin project for more than a decade.  I know what
to (excuse the expression) expect.  And, I'm sure that Yaakov who has
also been around for a while and maintains scores of important packages
is also quite aware that people will be surprised by any major change,
even ones that are preannounced.

You don't have the inclination to work on supporting
tk-on-windows-with-a-side-of-cygwin.  Neither does anyone else.  Keeping
tcl/tk in the dark ages and potentially causing problems for programs
like expect and gitk is a sure recipe for complaints since programs are
drifting further and further from optimal configurations.  In fact, this
whole thread is prompted by a complaint/request in the cygwin list.

>I don't normally have time to read the general cygwin list, but if you
>haven't done so already I will strongly suggest starting a thread there
>that discusses this changeand its ramifications.  To me the
>ramifications are the most important for the general users.  I'm sure
>the developers have discussed this in great detail and I vaguely
>remember discussions about this in the past, but I'm guessing the
>normal users will be quite surprised bythis change.
>
>I can adapt and Linux inside VirtualBox has softened my usage of cygwin
>already.  gitk requiring an X server may push me a bit further in that
>direction.

If you feel the need to raise the alarm to the Cygwin list, please go
ahead.  It's hard for me to see what you're expecting, though.  You
don't want things to change but you don't seem to be proposing any
solutions other than, presumably, "don't update anything".

If you think that running VirtualBox is really an alternative to just
starting X then that's definitely something you should pursue even if
it's hard to see how that jives with your concern that "the X server was
a bit of a resource hog".

cgf

Re: ATTENTION: Tcl/Tk transition

[Dave Korn]

On 26/10/2011 22:02, Yaakov (Cygwin/X) wrote:
> cgf has asked me to take over tcl/tk/expect maintainership and
> transition the distro from our Win32/GDI hybrid 8.4 to the *NIX/X11 8.5
> currently in Ports.

  To anyone feeling apprehensive, I've been using the 'ports versions of tcl
and expect for a long time now to test GCC and binutils, and they seem to work
pretty well to me.

    cheers,
      DaveK

Re: ATTENTION: Tcl/Tk transition

[Christopher Faylor]

On Thu, Oct 27, 2011 at 02:31:28AM +0100, Dave Korn wrote:
>On 26/10/2011 22:02, Yaakov (Cygwin/X) wrote:
>> cgf has asked me to take over tcl/tk/expect maintainership and
>> transition the distro from our Win32/GDI hybrid 8.4 to the *NIX/X11 8.5
>> currently in Ports.
>
>  To anyone feeling apprehensive, I've been using the 'ports versions of tcl
>and expect for a long time now to test GCC and binutils, and they seem to work
>pretty well to me.

tcl isn't the problem.  tk is.

cgf

Re: ATTENTION: Tcl/Tk transition

[Christopher Faylor]

On Wed, Oct 26, 2011 at 06:26:34PM -0700, Cary R. wrote:
>FYI expect is what drew me to Tcl/Tk a very long time ago.
>
>Trust that I understand the need to be using a more modern version of
>Tcl/Tk.  I'm just whining that we're going to loose the GDI support.
>Since I'm not going to do anything to help the situation thisis the
>last I'll post on the subject.
>
>I did some quick testing and yes the new X server is much better.  All
>my prejudices came from Cygwin 1.5 days on a slower laptop.  The
>combination of a newer laptop and Cygwin 1.7/newer X server makes a
>significant difference.
>
>The benefit I get from using VirtualBox for development?  is that with
>Cygwinour test suite takes 818 second andwith Linuxinside VirtualBox it
>takes 45 seconds.  As you can see itdoesn'ttake too many test cycles to
>result in a significanttimesavings and yes this is the same version of
>the codeon the same machine with all the other processes idle.  For me
>the resource cost of Virtual Box is 1G of memory and a 30-45 second
>startup/shutdown times.  Depending on what I'm doing and how long I'm
>going to be doing it this is acceptable given the smaller testing
>times.
>
>Don't construe any of this as a slam on Cygwin.  I still think it is a
>great setup!

I don't construe it as a slam.  I construe it as continuing down the
"off-topic for this mailing list" road.  You've hijacked what should be
a rebuild and packaging discussion with YA astonished observation that
"Cygwin is slow".  Moreover, as far as I can tell you are not even a
package maintainer.

If you have more to say then use the Cygwin mailing list.

cgf

Re: ATTENTION: Tcl/Tk transition

[Corinna Vinschen]

On Oct 26 19:42, Yaakov (Cygwin/X) wrote:
> On Wed, 2011-10-26 at 16:02 -0500, Yaakov (Cygwin/X) wrote:
> > * ruby (Corinna Vinschen)
> > new requires: tcl tcl-tk
> > notes: I suggest making a make separate ruby-tcltk package due to the
> > additional deps.
> 
> Patches for 1.8.7-p352 attached.

Cool, thanks!  You don't want to take over ruby maintainership as well,
do you? :}


Corinna

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

Re: ATTENTION: Tcl/Tk transition

[Yaakov (Cygwin/X)]

On Thu, 2011-10-27 at 10:07 +0200, Corinna Vinschen wrote:
> Cool, thanks!  You don't want to take over ruby maintainership as well,
> do you? :}

Would your adding getgrouplist(3) be a fair price? :-)

http://www.kernel.org/doc/man-pages/online/pages/man3/getgrouplist.3.html

I need this for an attempt to port polkit-1, and I haven't learned that
part of the codebase yet.  Deal? :-)


Yaakov

Re: ATTENTION: Tcl/Tk transition

[Christopher Faylor]

On Thu, Oct 27, 2011 at 10:11:03PM -0500, Yaakov (Cygwin/X) wrote:
>On Thu, 2011-10-27 at 10:07 +0200, Corinna Vinschen wrote:
>> Cool, thanks!  You don't want to take over ruby maintainership as well,
>> do you? :}
>
>Would your adding getgrouplist(3) be a fair price? :-)
>
>http://www.kernel.org/doc/man-pages/online/pages/man3/getgrouplist.3.html
>
>I need this for an attempt to port polkit-1, and I haven't learned that
>part of the codebase yet.  Deal? :-)

I can add that tomorrow if the morning shift doesn't beat me to it.

cgf

Re: ATTENTION: Tcl/Tk transition

[Corinna Vinschen]

On Oct 27 23:54, Christopher Faylor wrote:
> On Thu, Oct 27, 2011 at 10:11:03PM -0500, Yaakov (Cygwin/X) wrote:
> >On Thu, 2011-10-27 at 10:07 +0200, Corinna Vinschen wrote:
> >> Cool, thanks!  You don't want to take over ruby maintainership as well,
> >> do you? :}
> >
> >Would your adding getgrouplist(3) be a fair price? :-)
> >
> >http://www.kernel.org/doc/man-pages/online/pages/man3/getgrouplist.3.html
> >
> >I need this for an attempt to port polkit-1, and I haven't learned that
> >part of the codebase yet.  Deal? :-)

Deal!

> I can add that tomorrow if the morning shift doesn't beat me to it.

The morning shift will have a look, but here's a question, Yaakov.

I assume you want the full group list, represented by the user's token
if one would like to construct the token, right?

If so, that requires to create a SID list by fetching the information
from the local SAM and AD, quite similar to the initgroups function.

On second thought, that would be practically identical to our
initgroups32 function, except for the cygheap->user.groups.update_supp
call, which would be replaced by filling the group list given as
argument.


Corinna

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

Re: ATTENTION: Tcl/Tk transition

[Yaakov (Cygwin/X)]

On Fri, 2011-10-28 at 09:56 +0200, Corinna Vinschen wrote:
> > On Thu, Oct 27, 2011 at 10:11:03PM -0500, Yaakov (Cygwin/X) wrote:
> > >On Thu, 2011-10-27 at 10:07 +0200, Corinna Vinschen wrote:
> > >> Cool, thanks!  You don't want to take over ruby maintainership as well,
> > >> do you? :}
> > >
> > >Would your adding getgrouplist(3) be a fair price? :-)
> > >
> > >http://www.kernel.org/doc/man-pages/online/pages/man3/getgrouplist.3.html
> > >
> > >I need this for an attempt to port polkit-1, and I haven't learned that
> > >part of the codebase yet.  Deal? :-)
> 
> Deal!

Done.  ruby-1.8.7-p352 with separate ruby-tcltk package is ready.

> I assume you want the full group list, represented by the user's token
> if one would like to construct the token, right?

See the "spec" noted above, but if ngroups is correctly sized, all
groups to which the given user belongs are returned AND the given group
even if the user is not a member thereof.

> If so, that requires to create a SID list by fetching the information
> from the local SAM and AD, quite similar to the initgroups function.
> 
> On second thought, that would be practically identical to our
> initgroups32 function, except for the cygheap->user.groups.update_supp
> call, which would be replaced by filling the group list given as
> argument.

That makes sense, given that on BSD[1], initgroups(3) is basically
getgrouplist() followed by setgroups().  The primary difference will be
adding the given group if not a member and assuring proper size of
ngroups.  (Yes, I did look into this myself once upon a time.)


Yaakov

[1]
http://svnweb.FreeBSD.org/base/head/lib/libc/gen/initgroups.c?view=markup

Re: ATTENTION: Tcl/Tk transition

[Corinna Vinschen]

On Oct 28 03:20, Yaakov (Cygwin/X) wrote:
> On Fri, 2011-10-28 at 09:56 +0200, Corinna Vinschen wrote:
> > > On Thu, Oct 27, 2011 at 10:11:03PM -0500, Yaakov (Cygwin/X) wrote:
> > > >On Thu, 2011-10-27 at 10:07 +0200, Corinna Vinschen wrote:
> > > >> Cool, thanks!  You don't want to take over ruby maintainership as well,
> > > >> do you? :}
> > > >
> > > >Would your adding getgrouplist(3) be a fair price? :-)
> > > >
> > > >http://www.kernel.org/doc/man-pages/online/pages/man3/getgrouplist.3.html
> > > >
> > > >I need this for an attempt to port polkit-1, and I haven't learned that
> > > >part of the codebase yet.  Deal? :-)
> > 
> > Deal!
> 
> Done.  ruby-1.8.7-p352 with separate ruby-tcltk package is ready.

Cool, thanks!

> > I assume you want the full group list, represented by the user's token
> > if one would like to construct the token, right?
> 
> See the "spec" noted above, but if ngroups is correctly sized, all
> groups to which the given user belongs are returned AND the given group
> even if the user is not a member thereof.

Uh, maybe I wasn't clear.  I didn't talk about Linux or so, I was
just refering to two possible implementations on Cygwin, one looking
into /etc/groups only, the other fetching the information from the OS.
But that was YA ENOCOFFEE question since I gave up on using the
supplemetary groups from /etc/group anyway.  Only what the OS allows
should count.

> > If so, that requires to create a SID list by fetching the information
> > from the local SAM and AD, quite similar to the initgroups function.
> > 
> > On second thought, that would be practically identical to our
> > initgroups32 function, except for the cygheap->user.groups.update_supp
> > call, which would be replaced by filling the group list given as
> > argument.
> 
> That makes sense, given that on BSD[1], initgroups(3) is basically
> getgrouplist() followed by setgroups().  The primary difference will be
> adding the given group if not a member and assuring proper size of
> ngroups.  (Yes, I did look into this myself once upon a time.)

Yup, I'm comparing the implementations of glibc and FreeBSD right
now.  The Linux getgrouplist man page doesn't tell anything of
the handling of NULL pointers, so I had to use the source to see
how they handle this.  FreeBSD asserts, GLibc just crashes.  FreeBSD
also allows a NULL group pointer if *ngroups is 0.  I like FreeBSD 
better here, so I'll do the same.


Corinna

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

Re: ATTENTION: Tcl/Tk transition

[Corinna Vinschen]

On Oct 28 10:48, Corinna Vinschen wrote:
> On Oct 28 03:20, Yaakov (Cygwin/X) wrote:
> > On Fri, 2011-10-28 at 09:56 +0200, Corinna Vinschen wrote:
> > > > On Thu, Oct 27, 2011 at 10:11:03PM -0500, Yaakov (Cygwin/X) wrote:
> > > > >On Thu, 2011-10-27 at 10:07 +0200, Corinna Vinschen wrote:
> > > > >> Cool, thanks!  You don't want to take over ruby maintainership as well,
> > > > >> do you? :}
> > > > >
> > > > >Would your adding getgrouplist(3) be a fair price? :-)
> > > > >
> > > > >http://www.kernel.org/doc/man-pages/online/pages/man3/getgrouplist.3.html
> > > > >
> > > > >I need this for an attempt to port polkit-1, and I haven't learned that
> > > > >part of the codebase yet.  Deal? :-)
> > > 
> > > Deal!
> > 
> > Done.  ruby-1.8.7-p352 with separate ruby-tcltk package is ready.
> 
> Cool, thanks!
> 
> > > I assume you want the full group list, represented by the user's token
> > > if one would like to construct the token, right?
> > 
> > See the "spec" noted above, but if ngroups is correctly sized, all
> > groups to which the given user belongs are returned AND the given group
> > even if the user is not a member thereof.
> 
> Uh, maybe I wasn't clear.  I didn't talk about Linux or so, I was
> just refering to two possible implementations on Cygwin, one looking
> into /etc/groups only, the other fetching the information from the OS.
> But that was YA ENOCOFFEE question since I gave up on using the
> supplemetary groups from /etc/group anyway.  Only what the OS allows
> should count.
> 
> > > If so, that requires to create a SID list by fetching the information
> > > from the local SAM and AD, quite similar to the initgroups function.
> > > 
> > > On second thought, that would be practically identical to our
> > > initgroups32 function, except for the cygheap->user.groups.update_supp
> > > call, which would be replaced by filling the group list given as
> > > argument.
> > 
> > That makes sense, given that on BSD[1], initgroups(3) is basically
> > getgrouplist() followed by setgroups().  The primary difference will be
> > adding the given group if not a member and assuring proper size of
> > ngroups.  (Yes, I did look into this myself once upon a time.)
> 
> Yup, I'm comparing the implementations of glibc and FreeBSD right
> now.  The Linux getgrouplist man page doesn't tell anything of
> the handling of NULL pointers, so I had to use the source to see
> how they handle this.  FreeBSD asserts, GLibc just crashes.  FreeBSD
> also allows a NULL group pointer if *ngroups is 0.  I like FreeBSD 
> better here, so I'll do the same.

Done.  Please give it a try.  I used this STC for testing:

$ cat > ggl.c <<EOF
#include <stdio.h>
#include <grp.h>

int
main (int argc, char **argv)
{
  int ret, ngroups;
  gid_t groups[256];

  ngroups = 0;
  ret = getgrouplist (argv[1], 20000, NULL, &ngroups);
  printf ("ret = %d, ngroups = %d\n", ret, ngroups);

  ngroups = 1;
  ret = getgrouplist (argv[1], 20000, NULL, &ngroups);
  printf ("ret = %d, ngroups = %d\n", ret, ngroups);

  ngroups = 1;
  ret = getgrouplist (argv[1], 20000, groups, &ngroups);
  printf ("ret = %d, ngroups = %d\n", ret, ngroups);

  ngroups = 256;
  ret = getgrouplist (argv[1], 20000, groups, &ngroups);
  printf ("ret = %d, ngroups = %d\n", ret, ngroups);
  for (ret = 0; ret < ngroups; ++ret)
    printf ("  %d%s", groups[ret], ret < ngroups - 1 ? ", " : "\n");

  ret = getgrouplist (argv[1], 20000, groups, NULL);
  printf ("ret = %d, ngroups = %d\n", ret, ngroups);

  return 0;
}
EOF

The last getgrouplist call should always abort due to an assertion.
The first call should abort if you don't give an argument.  The group
20000 is an arbitrary group in my /etc/group file which exists, but
which no user is a member of.

Please note that getgrouplist does not always add the gid to the
group list in my implementation.  The requirement is that it must
exist in /etc/groups.  There's no good reason to add a group to
the group list if the group isn't backed by a OS SID.


Corinna

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

Re: ATTENTION: Tcl/Tk transition

[Reini Urban]

On Wed, Oct 26, 2011 at 5:33 PM, Charles Wilson wrote:
> Here are some of the previous discussions:
>
> Interest in "native" Tcl/Tk/Expect/Itcl/... packages?
> http://cygwin.com/ml/cygwin-apps/2004-10/msg00316.html
>
> Does anyone use insight on cygwin?
> http://www.cygwin.com/ml/cygwin/2008-08/msg00089.html
>
> tcl/tk/expect/dejagnu/gdb/insight
> http://cygwin.com/ml/cygwin/2009-09/msg00311.html
>
> gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32
> app.
> http://cygwin.com/ml/cygwin/2010-08/msg00913.html
>
> ====NOTE====
> in the gitk thread above, Reini Urban, the cygwin perl and parrot
> maintainer, was vehemently against switching tcltk from GDI to X11.  I
> wonder if his opinion has changed in the past year...

No, I'm still against it, but in minority.
I tried to fix it, but ran out of time.

Maybe later I can come up with a tk/tcl-native.
-- 
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/

Re: ATTENTION: Tcl/Tk transition

[Christopher Faylor]

On Sat, Oct 29, 2011 at 06:31:59PM -0500, Reini Urban wrote:
>On Wed, Oct 26, 2011 at 5:33 PM, Charles Wilson wrote:
>> Here are some of the previous discussions:
>>
>> Interest in "native" Tcl/Tk/Expect/Itcl/... packages?
>> http://cygwin.com/ml/cygwin-apps/2004-10/msg00316.html
>>
>> Does anyone use insight on cygwin?
>> http://www.cygwin.com/ml/cygwin/2008-08/msg00089.html
>>
>> tcl/tk/expect/dejagnu/gdb/insight
>> http://cygwin.com/ml/cygwin/2009-09/msg00311.html
>>
>> gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32
>> app.
>> http://cygwin.com/ml/cygwin/2010-08/msg00913.html
>>
>> ====NOTE====
>> in the gitk thread above, Reini Urban, the cygwin perl and parrot
>> maintainer, was vehemently against switching tcltk from GDI to X11. ?I
>> wonder if his opinion has changed in the past year...
>
>No, I'm still against it, but in minority.
>I tried to fix it, but ran out of time.
>
>Maybe later I can come up with a tk/tcl-native.

I don't see why you need a tcl-native but it should be possible to use
the Windows version of tk to do Windows-native GUI stuff without relying
on X11.  The trick is getting that + Cygwin paths, signals, etc.  to
play together.

cgf

Re: ATTENTION: Tcl/Tk transition

[Yaakov (Cygwin/X)]

On Sun, 2011-10-30 at 00:53 -0400, Christopher Faylor wrote:
> On Sat, Oct 29, 2011 at 06:31:59PM -0500, Reini Urban wrote:
> >On Wed, Oct 26, 2011 at 5:33 PM, Charles Wilson wrote:
> >> in the gitk thread above, Reini Urban, the cygwin perl and parrot
> >> maintainer, was vehemently against switching tcltk from GDI to X11. ?I
> >> wonder if his opinion has changed in the past year...
> >
> >No, I'm still against it, but in minority.
> >I tried to fix it, but ran out of time.
> >
> >Maybe later I can come up with a tk/tcl-native.
> 
> I don't see why you need a tcl-native but it should be possible to use
> the Windows version of tk to do Windows-native GUI stuff without relying
> on X11.  The trick is getting that + Cygwin paths, signals, etc.  to
> play together.

Please don't.  The problem with a GDI Tk is not only getting it to work
properly, but how it interoperates with other (X11) GUI software.  Some
examples from Ports:

* Pidgin (a GTK2/X11 app) has a Tcl scripting plugin which also uses Tk.
Mixing an X11 app with a GDI plugin is a sure recipe for disaster.

* PyOpenGL is used by several Python libraries, such as PyGame,
PyGtkGLExt, and wxPython, all of which are X11-based.  But PyOpenGL
includes a Tkinter/Togl interface as well.  If Tk is GDI-based, then so
will Tkinter have to be, but PyOpenGL can't bind both GLX and WGL at the
same time.

This is just the beginning.  Mixing GDI and X11 just doesn't work, and
since X11 is used for all other GUIs on Cygwin, so must Tk.


Yaakov

Re: ATTENTION: Tcl/Tk transition

[Charles Wilson]

On 10/30/2011 8:44 PM, Yaakov (Cygwin/X) wrote:
> Please don't.
...
> This is just the beginning.  Mixing GDI and X11 just doesn't work, and
> since X11 is used for all other GUIs on Cygwin, so must Tk.

My suggestion, for those who wanted this, was to build the entire 
tcl/tk(GDI) "stack" with a unique prefix -- that way it wouldn't BE 
mixed with the other clients which (will soon be) compiled to use the 
X11 version.  And, to even use it at all, one would have to put it in 
the PATH "ahead" of /usr/bin.  That's surely not standard; and if 
somebody does this and it breaks something -- then they get to keep both 
pieces. WJM, after all.

--
Chuck

Re: ATTENTION: Tcl/Tk transition

[Charles Wilson]

On 10/31/2011 7:39 PM, Charles Wilson wrote:
> On 10/30/2011 8:44 PM, Yaakov (Cygwin/X) wrote:
>> Please don't.
> ...
>> This is just the beginning. Mixing GDI and X11 just doesn't work, and
>> since X11 is used for all other GUIs on Cygwin, so must Tk.
>
> My suggestion, for those who wanted this, was to build the entire
> tcl/tk(GDI) "stack" with a unique prefix -- that way it wouldn't BE
> mixed with the other clients which (will soon be) compiled to use the
> X11 version. And, to even use it at all, one would have to put it in the
> PATH "ahead" of /usr/bin. That's surely not standard; and if somebody
> does this and it breaks something -- then they get to keep both pieces.
> WJM, after all.

In case it wasn't clear, my suggestion was that if somebody did this, it 
should be hosted by a a third-party repository (similar to how 
cygwin-ports is structured), and not part of the actual cygwin distribution.

--
Chuck

Re: ATTENTION: Tcl/Tk transition

[Dr. Volker Zell]

On 26.10.2011 23:02, Yaakov (Cygwin/X) wrote:
> cgf has asked me to take over tcl/tk/expect maintainership and
> transition the distro from our Win32/GDI hybrid 8.4 to the *NIX/X11 8.5
> currently in Ports.
>
> The following packages will need an IMMEDIATE rebuild:
>
> * db [tcl-dbX.Y] (Dr. Volker Zell)
> new requires: tcl
> notes: perhaps you should just build the latest db 4.x and/or 5.x with
> this tcl and we can drop the earlier bindings?

Done.

I obsoleted the following packages:

   db-2.7.7
   db-3.1.17
   db-3.3.11.2
   db-4.0.14
   db-4.1.25.3
   db-4.2.52.5
   db-4.3.29.1
   db-4.4.20.4

did a rebuild of

   db-4.5.20.2

and added

   db-4.8.30

5.x will follow later when the dust settles.

> * ming [tcl-ming] (Dr. Volker Zell)
> new requires: tcl
> notes: needs a pkgIndex.tcl file to be of any use

Done. It has now a pkgIndex.tcl file.

> * WordNet (Dr. Volker Zell)
> new requires: tcl tcl-tk
> notes: needs patches for security vulnerabilities, patches available
> from all major distros, e.g.:
> http://pkgs.fedoraproject.org/gitweb/?p=wordnet.git;a=tree

Done, with all the paches and security fixes.

You will find the packages under /home/vzell on sourceware. Just copy 
(scp -r) them over when everybody is ready.

Thanks
   Volker

Re: ATTENTION: Tcl/Tk transition

[Yaakov (Cygwin/X)]

On Tue, 2011-11-08 at 02:18 +0100, Dr. Volker Zell wrote:
> I obsoleted the following packages:
> 
>    db-2.7.7
>    db-3.1.17
>    db-3.3.11.2
>    db-4.0.14
>    db-4.1.25.3
>    db-4.2.52.5
>    db-4.3.29.1
>    db-4.4.20.4

IMO there is no reason to keep these old versions, as nothing in the
distro depends on them.  So if there are no objections, we can just
outright remove them, and use _obsolete packages only for tcl-db*.*.

> did a rebuild of
> 
>    db-4.5.20.2
> 
> and added
> 
>    db-4.8.30

Something is wrong with these packages; the libdb* and tcl-db* packages
aren't versioned.  (BTW, I think the tcl-db4.5 should also be an
_obsolete package, pointing to tcl-db4.8.)

> 5.x will follow later when the dust settles.

That will be helpful.

> > * ming [tcl-ming] (Dr. Volker Zell)
> > new requires: tcl
> > notes: needs a pkgIndex.tcl file to be of any use
> 
> Done. It has now a pkgIndex.tcl file.
> 
> > * WordNet (Dr. Volker Zell)
> > new requires: tcl tcl-tk
> > notes: needs patches for security vulnerabilities, patches available
> > from all major distros, e.g.:
> > http://pkgs.fedoraproject.org/gitweb/?p=wordnet.git;a=tree
> 
> Done, with all the paches and security fixes.

These look good.

> You will find the packages under /home/vzell on sourceware. Just copy 
> (scp -r) them over when everybody is ready.

Thank you for your prompt attention to this.   Since space on /home is
tight, I have copied the ming and WordNet into a staging area until
we're ready for the move.

Thanks,


Yaakov
Cygwin/X

Re: ATTENTION: Tcl/Tk transition

[Dr. Volker Zell]

On 10.11.2011 00:51, Yaakov (Cygwin/X) wrote:
> On Tue, 2011-11-08 at 02:18 +0100, Dr. Volker Zell wrote:
>> I obsoleted the following packages:
>>
>>     db-2.7.7
>>     db-3.1.17
>>     db-3.3.11.2
>>     db-4.0.14
>>     db-4.1.25.3
>>     db-4.2.52.5
>>     db-4.3.29.1
>>     db-4.4.20.4
>
> IMO there is no reason to keep these old versions, as nothing in the
> distro depends on them.  So if there are no objections, we can just
> outright remove them, and use _obsolete packages only for tcl-db*.*.
>
>> did a rebuild of
>>
>>     db-4.5.20.2
>>
>> and added
>>
>>     db-4.8.30
>
> Something is wrong with these packages; the libdb* and tcl-db* packages
> aren't versioned.  (BTW, I think the tcl-db4.5 should also be an
> _obsolete package, pointing to tcl-db4.8.)

What do you mean with arent't versioned ?

tar -tvjf db-4.5.20.2-3/dist/db/tcl-db/tcl-db-4.5.20.2-3.tar.bz2
  usr/lib/tcl8.5/
  usr/lib/tcl8.5/db4.5/
  usr/lib/tcl8.5/db4.5/cygdb_tcl-4.5.dll
  usr/lib/tcl8.5/db4.5/pkgIndex.tcl

tar -tvjf db-4.5.20.2-3/dist/db/libdb/libdb-4.5.20.2-3.tar.bz2
  usr/bin/cygdb-4.5.dll
  usr/bin/cygdb_cxx-4.5.dll

tar -tvjf db-4.8.30-1/dist/db/tcl-db/tcl-db-4.8.30-1.tar.bz2
  usr/lib/tcl8.5/
  usr/lib/tcl8.5/db4.8/
  usr/lib/tcl8.5/db4.8/cygdb_tcl-4.8.dll
  usr/lib/tcl8.5/db4.8/pkgIndex.tcl

tar -tvjf db-4.8.30-1/dist/db/libdb/libdb-4.8.30-1.tar.bz2
  usr/bin/cygdb-4.8.dll
  usr/bin/cygdb_cxx-4.8.dll

Ciao
   Volker

Re: ATTENTION: Tcl/Tk transition

[Yaakov (Cygwin/X)]

On Thu, 2011-11-10 at 03:00 +0100, Dr. Volker Zell wrote:
> What do you mean with arent't versioned ?

The package names themselves:

> tar -tvjf db-4.5.20.2-3/dist/db/libdb/libdb-4.5.20.2-3.tar.bz2
> tar -tvjf db-4.8.30-1/dist/db/libdb/libdb-4.8.30-1.tar.bz2

The libdb packages must be libdb4.5 and libdb4.8.  As for the -devel
packages, perhaps we only need the latest one?

> tar -tvjf db-4.5.20.2-3/dist/db/tcl-db/tcl-db-4.5.20.2-3.tar.bz2
> tar -tvjf db-4.8.30-1/dist/db/tcl-db/tcl-db-4.8.30-1.tar.bz2

If we need only one version of the Tcl bindings, fine (and it should
come from 4.8), otherwise these need to be tcl-db4.5 and tcl-db4.8.  


Yaakov

Re: ATTENTION: Tcl/Tk transition

[Dr. Volker Zell]

On 10.11.2011 03:37, Yaakov (Cygwin/X) wrote:
> On Thu, 2011-11-10 at 03:00 +0100, Dr. Volker Zell wrote:
>> What do you mean with arent't versioned ?
>
> The package names themselves:

I see, a stupid packaging error on my side.

>> tar -tvjf db-4.5.20.2-3/dist/db/libdb/libdb-4.5.20.2-3.tar.bz2
>> tar -tvjf db-4.8.30-1/dist/db/libdb/libdb-4.8.30-1.tar.bz2
>
> The libdb packages must be libdb4.5 and libdb4.8.  As for the -devel
> packages, perhaps we only need the latest one?
>
>> tar -tvjf db-4.5.20.2-3/dist/db/tcl-db/tcl-db-4.5.20.2-3.tar.bz2
>> tar -tvjf db-4.8.30-1/dist/db/tcl-db/tcl-db-4.8.30-1.tar.bz2
>
> If we need only one version of the Tcl bindings, fine (and it should
> come from 4.8), otherwise these need to be tcl-db4.5 and tcl-db4.8.

Both are now versioned.

Ciao
   Volker

Re: ATTENTION: Tcl/Tk transition

[Charles Wilson]

Yaakov -- the installed tclConfig.sh and tkConfig.sh files include stuff 
like this:

TCL_DEFS='-DPACKAGE_NAME=\"tcl\" -DPACKAGE_TARNAME=\"tcl\" 
-DPACKAGE_VERSION=\"8.5\" -DPACKAGE_STRING=\"tcl\ 8.5\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 ....

This causes warnings (PACKAGE_NAME redefined, etc) when building other 
packages.  Could you update your .cygport(5) to add a line like this:

	-e '/^TCL_DEFS/s|-DPACKAGE[^=]*=\\\"[^"]*" ||g' \

to the "munge the tclConfig.sh" section of src_install?  (Likewise 
TK_DEFS etc).

--
Chuck

Re: ATTENTION: Tcl/Tk transition

[Yaakov (Cygwin/X)]

On Sat, 2011-12-03 at 18:45 -0500, Charles Wilson wrote:
> Yaakov -- the installed tclConfig.sh and tkConfig.sh files include stuff 
> like this:
> 
> TCL_DEFS='-DPACKAGE_NAME=\"tcl\" -DPACKAGE_TARNAME=\"tcl\" 
> -DPACKAGE_VERSION=\"8.5\" -DPACKAGE_STRING=\"tcl\ 8.5\" 
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 ....
> 
> This causes warnings (PACKAGE_NAME redefined, etc) when building other 
> packages.

Which packages are you referring to?


Yaakov

Re: ATTENTION: Tcl/Tk transition

[Charles Wilson]

On 12/4/2011 7:33 PM, Yaakov (Cygwin/X) wrote:
> On Sat, 2011-12-03 at 18:45 -0500, Charles Wilson wrote:
>> Yaakov -- the installed tclConfig.sh and tkConfig.sh files include stuff
>> like this:
>>
>> TCL_DEFS='-DPACKAGE_NAME=\"tcl\" -DPACKAGE_TARNAME=\"tcl\"
>> -DPACKAGE_VERSION=\"8.5\" -DPACKAGE_STRING=\"tcl\ 8.5\"
>> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 ....
>>
>> This causes warnings (PACKAGE_NAME redefined, etc) when building other
>> packages.
>
> Which packages are you referring to?

I found this while building (msys) versions of tcl and tk, (loosely) 
based on your cygports.  However...I modified tk's configure.in to do a 
"proper" AC_INIT.  So now, tk defines PACKAGE_NAME as "tk" -- but 
inherits tclConfig's setting of "tcl" (and etc.).

It's possible that because tk doesn't, OOB, use the proper AC_INIT 
invocation that you don't see this problem with your builds.  But...is 
it really right for tk to self-identify as "tcl"?

Fix that...and then you see the warning.

However, it just seems unambiguously correct, to me, that derived 
packages should NOT inherit "tcl's" settings of those particular macros.

--
Chuck

Re: ATTENTION: Tcl/Tk transition

[Yaakov (Cygwin/X)]

On Sun, 2011-12-04 at 21:05 -0500, Charles Wilson wrote:
> I found this while building (msys) versions of tcl and tk, (loosely) 
> based on your cygports.  However...I modified tk's configure.in to do a 
> "proper" AC_INIT.  So now, tk defines PACKAGE_NAME as "tk" -- but 
> inherits tclConfig's setting of "tcl" (and etc.).
> 
> Fix that...and then you see the warning.

It is win/configure.in which doesn't AC_INIT properly, not
unix/configure.in.  Try building my tcl-tk and you won't see any such
warnings, and PACKAGE_NAME is "tk".  So it would seem that your "fix" is
incorrect.


Yaakov

Re: ATTENTION: Tcl/Tk transition

[Yaakov (Cygwin/X)]

Thank you to Dr. Volker Zell for rebuilding his packages.  That still leaves:

> * brltty [tcl-brlapi] (Samuel Thibault)
> * python[-tkinter] (Jason Tishler)
> * suite3270 [tcl3270] (Peter A. Castro)

In order to provide a seamless transition for users, your packages must
be rebuilt for the new Tcl/Tk per my original instructions[1].  Please
let us know when you will be able to do this, or if you need any
assistance.


Yaakov

[1] http://cygwin.com/ml/cygwin-apps/2011-10/msg00083.html

Re: ATTENTION: Tcl/Tk transition

[Charles Wilson]

On 12/4/2011 10:03 PM, Yaakov (Cygwin/X) wrote:
> On Sun, 2011-12-04 at 21:05 -0500, Charles Wilson wrote:
>> I found this while building (msys) versions of tcl and tk, (loosely)
>> based on your cygports.  However...I modified tk's configure.in to do a
>> "proper" AC_INIT.  So now, tk defines PACKAGE_NAME as "tk" -- but
>> inherits tclConfig's setting of "tcl" (and etc.).
>>
>> Fix that...and then you see the warning.
>
> It is win/configure.in which doesn't AC_INIT properly, not
> unix/configure.in.

D'oh! You're right.

> Try building my tcl-tk and you won't see any such
> warnings, and PACKAGE_NAME is "tk".  So it would seem that your "fix" is
> incorrect.

But...I'm going to have to figure out WHY you don't see the warnings. 
How can configure.in/config.status/Makefile-$(DEFS) set PACKAGE_NAME to 
tk, yet *also* include the DEFS settings sifted from tclConfig.sh which 
sets PACKAGE_NAME to tcl, and /not/ trigger the a macro redefinition 
warning? (Don't answer; it just strikes me as odd -- something funny is 
going on in the unix/ side and I probably ought to figure out what.)


Aside: the win/ side of things is /severely/ bitrotted with regards to 
mingw and cygwin -- I think they only care for MSVC now -- so it's just 
as well your new cygwin implementations are strictly unix/-only.  On the 
MSYS side I'm trying to hybridize: tcl=unix, tk=winGDI but with "proper" 
unixy path handing (which means translations when calling into, and of 
return values from, w32api functions).  It's...slow going.  And I wonder 
-- when I get that far -- whether the additional add-ons (itcl, itk, 
tix) will be workable at all, with tcl-ish headers under unix/ and 
tk-ish headers under win/; the TEA tcl.m4 seems to have provisions for 
such a separation...but will it work?  TBD.   msys-tcl seems ok so far 
but msys-tcl-tk: it's an unholy mess, really.  :-(

--
Chuck

Re: ATTENTION: Tcl/Tk transition

[Christopher Faylor]

On Mon, Dec 05, 2011 at 01:25:16AM -0500, Charles Wilson wrote:
>[SNIP]
>msys-tcl seems ok so far but msys-tcl-tk: it's an unholy mess, really.
>:-(

If Yaakov's packaging works correctly under Cygwin (and I'd be
astonished if it didn't) that's all that we care about in Cygwin mailing
lists.  Discussion of mingw/msys concerns is not appropriate here.

cgf

Re: ATTENTION: Tcl/Tk transition

[Samuel Thibault]

Yaakov (Cygwin/X), le Sun 04 Dec 2011 23:32:14 -0600, a écrit :
> Thank you to Dr. Volker Zell for rebuilding his packages.  That still leaves:
> 
> > * brltty [tcl-brlapi] (Samuel Thibault)
> > * python[-tkinter] (Jason Tishler)
> > * suite3270 [tcl3270] (Peter A. Castro)
> 
> In order to provide a seamless transition for users, your packages must
> be rebuilt for the new Tcl/Tk per my original instructions[1].  Please
> let us know when you will be able to do this, or if you need any
> assistance.
> 
> 
> Yaakov
> 
> [1] http://cygwin.com/ml/cygwin-apps/2011-10/msg00083.html

Here is the updated build, sorry it took so long.

http://brl.thefreecat.org/brltty/cygwin/brltty-4.2-3-src.tar.bz2
http://brl.thefreecat.org/brltty/cygwin/brltty-4.2-3.tar.bz2
http://brl.thefreecat.org/brltty/cygwin/java-brlapi/java-brlapi-4.2-3.tar.bz2
http://brl.thefreecat.org/brltty/cygwin/libbrlapi/libbrlapi-4.2-3.tar.bz2
http://brl.thefreecat.org/brltty/cygwin/libbrlapi-devel/libbrlapi-devel-4.2-3.tar.bz2
http://brl.thefreecat.org/brltty/cygwin/python-brlapi/python-brlapi-4.2-3.tar.bz2
http://brl.thefreecat.org/brltty/cygwin/tcl-brlapi/tcl-brlapi-4.2-3.tar.bz2
http://brl.thefreecat.org/brltty/cygwin/xbrlapi/xbrlapi-4.2-3.tar.bz2

Samuel

Re: ATTENTION: Tcl/Tk transition

[Yaakov (Cygwin/X)]

On Sun, 2012-01-08 at 02:57 +0100, Samuel Thibault wrote:
> Here is the updated build, sorry it took so long.
> 
> http://brl.thefreecat.org/brltty/cygwin/brltty-4.2-3-src.tar.bz2
> http://brl.thefreecat.org/brltty/cygwin/brltty-4.2-3.tar.bz2
> http://brl.thefreecat.org/brltty/cygwin/java-brlapi/java-brlapi-4.2-3.tar.bz2
> http://brl.thefreecat.org/brltty/cygwin/libbrlapi/libbrlapi-4.2-3.tar.bz2
> http://brl.thefreecat.org/brltty/cygwin/libbrlapi-devel/libbrlapi-devel-4.2-3.tar.bz2
> http://brl.thefreecat.org/brltty/cygwin/python-brlapi/python-brlapi-4.2-3.tar.bz2
> http://brl.thefreecat.org/brltty/cygwin/tcl-brlapi/tcl-brlapi-4.2-3.tar.bz2
> http://brl.thefreecat.org/brltty/cygwin/xbrlapi/xbrlapi-4.2-3.tar.bz2

Moved to staging area.  Please be sure to update your master copy of
tcl-brlapi/setup.hint requires: line as previously indicated; I will fix
the copy on sourceware when this is moved in.


Yaakov

Re: ATTENTION: Tcl/Tk transition

[Yaakov (Cygwin/X)]

Still outstanding are:
> * python[-tkinter] (Jason Tishler)
> * suite3270 [tcl3270] (Peter A. Castro)

In order to provide a seamless transition for users, your packages must
be rebuilt for the new Tcl/Tk per my original instructions[1].  Please
let us know when you will be able to do this, or if you need any
assistance.

Jason: I don't want to break Tkinter.  Can you make this a priority,
please?

Peter: If your update is not ready in time, I will have to remove
tcl3270 from the distro.


Yaakov

[1] http://cygwin.com/ml/cygwin-apps/2011-10/msg00083.html

Re: ATTENTION: Tcl/Tk transition

[Peter A. Castro]

On Sat, 7 Jan 2012, Yaakov (Cygwin/X) wrote:

> Still outstanding are:
>> * python[-tkinter] (Jason Tishler)
>> * suite3270 [tcl3270] (Peter A. Castro)
>
> In order to provide a seamless transition for users, your packages must
> be rebuilt for the new Tcl/Tk per my original instructions[1].  Please
> let us know when you will be able to do this, or if you need any
> assistance.
>
> Jason: I don't want to break Tkinter.  Can you make this a priority,
> please?
>
> Peter: If your update is not ready in time, I will have to remove
> tcl3270 from the distro.

Yaakov,
   I don't know what your timeline is for this (did I somehow miss you
posting a date for this transition?), but I'll see if I can rebuild this
week.

> Yaakov
>
> [1] http://cygwin.com/ml/cygwin-apps/2011-10/msg00083.html

-- 
Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com>
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: ATTENTION: Tcl/Tk transition

[Jason Tishler]

Yaakov,

On Sat, Jan 07, 2012 at 09:47:05PM -0600, Yaakov (Cygwin/X) wrote:
> Still outstanding are:
> > * python[-tkinter] (Jason Tishler)
> > * suite3270 [tcl3270] (Peter A. Castro)
> 
> In order to provide a seamless transition for users, your packages
> must be rebuilt for the new Tcl/Tk per my original instructions[1].
> Please let us know when you will be able to do this, or if you need
> any assistance.

I had hoped to find time to rebuild python[-tkinter] over the
holidays...

> Jason: I don't want to break Tkinter.  Can you make this a priority,
> please?

Yes.  Sorry for the delay.

Jason