[HEADSUP] Dropping libopenssl098 from distro

[HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

Hi folks,


it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
the 32 bit distro.  Fortunately they were never in the 64 bit distro.

The problem is that we still have packages requiring libopenssl098.
These need rebuilding or removing.

The following packages need simple rebuilding:

  ctorrent	Jari Aalto
  suck		Jari Aalto

  pure-ftpd	Kostya Altukhov

  suite3270	Peter A. Castro

The following packages are unused and should just go away:

  libcurl3	Yaakov Selkowitz

  libneon25	Dr. Volker Zell
  libneon26	Dr. Volker Zell

  libpq3	Marco Atzeri

The following packages have dependecies of their own, so they can't
go away until the dependent packages have been rebuilt:

  libarchive2	Yaakov Selkowitz

    required by:

	gvfs		Yaakov Selkowitz
	libgxps2	Yaakov Selkowitz

	gvfs and libgxps2 should be rebuilt to link against libarchive13.

  libpq		Marco Atzeri

    required by:

	clisp		Reini Urban
	libsasl2-sql	David Rothenberger
	xemacs		Dr. Volker Zell

	clisp and xemacs need rebuilding against libpq5.  libsasl2-sql
	is old and unused and can go away.

Given that Kostya Altukhov and Reini Urban seem to be AWOL, how shall we
manage their packages ideally?


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Achim Gratz]

Corinna Vinschen writes:
> 	clisp and xemacs need rebuilding against libpq5.  libsasl2-sql
> 	is old and unused and can go away.

Clisp is not yet ported to 64bit and it has problems under 32bit as well
(temporary file generation) that also affect Maxima from ports.  ONe of
the things holding a port off is libsigsegv, IIRC.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

On Jan 14 18:15, Achim Gratz wrote:
> Corinna Vinschen writes:
> > 	clisp and xemacs need rebuilding against libpq5.  libsasl2-sql
> > 	is old and unused and can go away.
> 
> Clisp is not yet ported to 64bit and it has problems under 32bit as well
> (temporary file generation) that also affect Maxima from ports.

If it's a problem with the Cygwin DLL, it would be nice to get a
bug report and, preferredly, an STC, so we have a chance to fix this.

Apart from that, I was only talking about the 32 bitr version anyway.
It requires the wrong libopenssl and needs a simple rebuild for now.

> ONe of
> the things holding a port off is libsigsegv, IIRC.

This is a bit annoying.  Libsigsegv should be optional, not required.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Yaakov Selkowitz]

On Wed, 2015-01-14 at 15:13 +0100, Corinna Vinschen wrote:
> it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
> the 32 bit distro.  Fortunately they were never in the 64 bit distro.
> The problem is that we still have packages requiring libopenssl098.
> These need rebuilding or removing.
[snip]
> The following packages are unused and should just go away:
> 
>   libcurl3	Yaakov Selkowitz
>   libneon25	Dr. Volker Zell
>   libneon26	Dr. Volker Zell
>   libpq3	Marco Atzeri

Ack.

> The following packages have dependecies of their own, so they can't
> go away until the dependent packages have been rebuilt:
> 
>   libarchive2	Yaakov Selkowitz
> 
>     required by:
> 
> 	gvfs		Yaakov Selkowitz
> 	libgxps2	Yaakov Selkowitz
> 
> 	gvfs and libgxps2 should be rebuilt to link against libarchive13.

These will be fixed with the GNOME 3.14 upgrade, currently being built.

--
Yaakov

Re: [HEADSUP] Dropping libopenssl098 from distro

[Achim Gratz]

Corinna Vinschen writes:
>> Clisp is not yet ported to 64bit and it has problems under 32bit as well
>> (temporary file generation) that also affect Maxima from ports.
>
> If it's a problem with the Cygwin DLL, it would be nice to get a
> bug report and, preferredly, an STC, so we have a chance to fix this.

AFAIK it's the same problem that produced the same symptoms in sqlite:
using a non-Cygwin API.  So no, I don't think the Cygwin DLL is to
blame.

> Apart from that, I was only talking about the 32 bitr version anyway.
> It requires the wrong libopenssl and needs a simple rebuild for now.
>
>> One of the things holding a port off is libsigsegv, IIRC.
>
> This is a bit annoying.  Libsigsegv should be optional, not required.

I have no idea whether that's possible for clisp.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [HEADSUP] Dropping libopenssl098 from distro

[Ken Brown]

On 1/14/2015 12:46 PM, Achim Gratz wrote:
> Corinna Vinschen writes:
>>> Clisp is not yet ported to 64bit and it has problems under 32bit as well
>>> (temporary file generation) that also affect Maxima from ports.
>>
>> If it's a problem with the Cygwin DLL, it would be nice to get a
>> bug report and, preferredly, an STC, so we have a chance to fix this.
>
> AFAIK it's the same problem that produced the same symptoms in sqlite:
> using a non-Cygwin API.  So no, I don't think the Cygwin DLL is to
> blame.
>
>> Apart from that, I was only talking about the 32 bitr version anyway.
>> It requires the wrong libopenssl and needs a simple rebuild for now.
>>
>>> One of the things holding a port off is libsigsegv, IIRC.
>>
>> This is a bit annoying.  Libsigsegv should be optional, not required.
>
> I have no idea whether that's possible for clisp.

It is.  There's a configure option "--ignore-absence-of-libsigsegv".  But there 
are more serious problems, affecting both the 32-bit and 64-bit versions.  (So 
even just rebuilding clisp for 32-bit Cygwin will take some work.)  The problem 
is that lisp.exe, which is built and used in the course of trying to build 
clisp.exe, crashes with a SEGV shortly after it's started.

My reason for looking at this was that clisp is needed for building xindy, an 
optional component of TeX Live.  I did successfully build clisp in the 32-bit 
case four years ago, but I can't any more.  My guess (untested) is that this is 
because the location of the heap has changed since then, and maybe the source 
code makes unwarranted assumptions about memory layout.

It's a shame that Reini isn't available to help with this.

Ken

Re: [HEADSUP] Dropping libopenssl098 from distro

[David Stacey]

On 14/01/15 14:13, Corinna Vinschen wrote:
> The following packages have dependecies of their own, so they can't
> go away until the dependent packages have been rebuilt:
>
>    libpq		Marco Atzeri
>
>      required by:
>
> 	xemacs		Dr. Volker Zell

Some time ago, there was a problem rebuilding xemacs [1]. Is this still 
an issue?

Dave.

[1] - https://cygwin.com/ml/cygwin-apps/2013-08/msg00248.html

Re: [HEADSUP] Dropping libopenssl098 from distro

[Dr. Volker Zell]

>>>>> David Stacey writes:

    > On 14/01/15 14:13, Corinna Vinschen wrote:
    >> The following packages have dependecies of their own, so they can't
    >> go away until the dependent packages have been rebuilt:
    >> 
    >> libpq		Marco Atzeri
    >> 
    >> required by:
    >> 
    >> xemacs		Dr. Volker Zell

    > Some time ago, there was a problem rebuilding xemacs [1]. Is this still an issue?

It used to compile but was not usable because of broken subprocess
support. Now it doesn't even compile :-(
    
    > Dave.

Ciao
  Volker
  

Re: [HEADSUP] Dropping libopenssl098 from distro

[Vin Shelton]

Volker -

I can build XEmacs on 32-bit Cygwin.  What doesn't work for you?

Thanks,
  Vin Shelton


On Thu, Jan 15, 2015 at 6:27 AM, Dr. Volker Zell
<dr.volker.zell@oracle.com> wrote:
>>>>>> David Stacey writes:
>
>     > On 14/01/15 14:13, Corinna Vinschen wrote:
>     >> The following packages have dependecies of their own, so they can't
>     >> go away until the dependent packages have been rebuilt:
>     >>
>     >> libpq            Marco Atzeri
>     >>
>     >> required by:
>     >>
>     >> xemacs           Dr. Volker Zell
>
>     > Some time ago, there was a problem rebuilding xemacs [1]. Is this still an issue?
>
> It used to compile but was not usable because of broken subprocess
> support. Now it doesn't even compile :-(
>
>     > Dave.
>
> Ciao
>   Volker
>

Re: [HEADSUP] Dropping libopenssl098 from distro

[Marco Atzeri]

On 1/15/2015 1:31 PM, Vin Shelton wrote:

 >>
 >> It used to compile but was not usable because of broken subprocess
 >> support. Now it doesn't even compile :-(
 >> Ciao
 >>    Volker
 >>

> Volker -
>
> I can build XEmacs on 32-bit Cygwin.  What doesn't work for you?
>
> Thanks,
>    Vin Shelton
>

Question:
0) does it work ?
1) configure parameters ?
2) have you tried a 64 build also ?

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

On Jan 15 13:50, Marco Atzeri wrote:
> On 1/15/2015 1:31 PM, Vin Shelton wrote:
> 
> >>
> >> It used to compile but was not usable because of broken subprocess
> >> support. Now it doesn't even compile :-(
> >> Ciao
> >>    Volker
> >>
> 
> >Volker -
> >
> >I can build XEmacs on 32-bit Cygwin.  What doesn't work for you?
> >
> >Thanks,
> >   Vin Shelton
> >
> 
> Question:
> 0) does it work ?
> 1) configure parameters ?
> 2) have you tried a 64 build also ?

It's nice to get more packages into the 64 bit distro, but the issue
here is to get rid of libopenssl098 in the first place.  If xemacs can
be built (and runs) on 32 bit while linked against libopenssl100 would
be a good deal already :)


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Marco Atzeri]

On 1/14/2015 3:13 PM, Corinna Vinschen wrote:
> Hi folks,
>
>
> it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
> the 32 bit distro.  Fortunately they were never in the 64 bit distro.
>
>    pure-ftpd	Kostya Altukhov

I will look on it

Regards
Marco

Re: [HEADSUP] Dropping libopenssl098 from distro

[Marco Atzeri]

On 1/15/2015 1:57 PM, Corinna Vinschen wrote:
> On Jan 15 13:50, Marco Atzeri wrote:
>> On 1/15/2015 1:31 PM, Vin Shelton wrote:
>>
>>>>
>>>> It used to compile but was not usable because of broken subprocess
>>>> support. Now it doesn't even compile :-(
>>>> Ciao
>>>>     Volker
>>>>
>>
>>> Volker -
>>>
>>> I can build XEmacs on 32-bit Cygwin.  What doesn't work for you?
>>>
>>> Thanks,
>>>    Vin Shelton
>>>
>>
>> Question:
>> 0) does it work ?
>> 1) configure parameters ?
>> 2) have you tried a 64 build also ?
>
> It's nice to get more packages into the 64 bit distro, but the issue
> here is to get rid of libopenssl098 in the first place.  If xemacs can
> be built (and runs) on 32 bit while linked against libopenssl100 would
> be a good deal already :)
>
>
> Thanks,
> Corinna
>

of course.
0 and 1 are for that.
2 is a potential plus ;-)

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

On Jan 15 14:03, Marco Atzeri wrote:
> On 1/14/2015 3:13 PM, Corinna Vinschen wrote:
> >Hi folks,
> >
> >
> >it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
> >the 32 bit distro.  Fortunately they were never in the 64 bit distro.
> >
> >   pure-ftpd	Kostya Altukhov
> 
> I will look on it

Thanks a lot!


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Vin Shelton]

Marco/Volker et al -

On Thu, Jan 15, 2015 at 7:50 AM, Marco Atzeri <marco.atzeri@gmail.com> wrote:
> On 1/15/2015 1:31 PM, Vin Shelton wrote:
>
>>>
>>> It used to compile but was not usable because of broken subprocess
>>> support. Now it doesn't even compile :-(
>>> Ciao
>>>    Volker
>>>
>
>> Volker -
>>
>> I can build XEmacs on 32-bit Cygwin.  What doesn't work for you?
>>
>> Thanks,
>>    Vin Shelton
>>
>
> Question:
> 0) does it work ?

Yes.  I am the XEmacs stable (21.4) build maintainer and make the
native Windows setup kits (both 21.4 and 21.5) for XEmacs, but I don't
use Windows very much these days.

> 1) configure parameters ?

Well, that's why I asked Volker what problems he had - it's easier to
solve problems when you have a description of them.

Here is the Installation file from my most recent cygwin build of XEmacs 21.5:

uname -a: CYGWIN_NT-5.1 legolas-xp3 1.7.33-2(0.280/5/3) 2014-11-13
15:45 i686 Cygwin

../../src/xemacs-21.5-2015-01-10-mule/configure
'--prefix=/usr/local/xemacs-21.5-2015-01-10-mule' '--enable-mule'
'--without-xim' '--enable-bignum=gmp' '--with-dialogs'
'--enable-pdump' '--with-sound=native' '--with-widgets' '--without-x'
'--with-dragndrop' '--with-cflags= -Os -malign-double -pipe
-ffast-math' '--with-default-eol-detection'
'--with-infopath=/usr/local/info'
'--with-package-path=/XEmacs/site-packages::/XEmacs/xemacs-packages'
'--with-site-prefix=' '--without-tls' 'CC=gcc' 'CFLAGS=-Os
-malign-double -pipe -ffast-math'


XEmacs 21.5-b34 "kale"  configured for `i686-pc-cygwin'.

Compilation Environment and Installation Defaults:
  Source code location:              /usr/local/src/xemacs-21.5-2015-01-10-mule
  Installation prefix:               /usr/local/xemacs-21.5-2015-01-10-mule
  Operating system description file: `s/cygwin32.h'
  Machine description file:          `m/intel386.h'
  Compiler version:                  gcc (GCC) 4.9.2
    - GCC specs file:                specs.
    - Compiler command:              gcc -I/usr/include/noX
-I/usr/include/noX -Wall -Wno-switch -Wundef -Wsign-compare
-Wno-char-subscripts -Wpacked -Wpointer-arith -Wshadow
-Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes
-Wdeclaration-after-statement  -Wunused-parameter -g   -Os
-malign-double -pipe -ffast-math
  libc version:
  Relocating allocator for buffers:  no
  GNU version of malloc:             yes

Package Search (a 'root' contains '{xemacs,mule,site}-packages'):
  User package roots:    ~/.xemacs
  System package roots:  /usr/local/xemacs-21.5-2015-01-10-mule/share/xemacs
    WARNING: /usr/local/xemacs-21.5-2015-01-10-mule/share/xemacs was
specified, but doesn't exist.
    WARNING: XEmacs functionality will be noticably limited until
    WARNING: some packages are installed.

Window System:
  Compiling in support for the Microsoft window system.
  Using MS-Windows menubars.
  Using MS-Windows scrollbars.
  Using MS-Windows dialog boxes.
  Using MS-Windows native widgets.
  Compiling in support for Drag'n'Drop (EXPERIMENTAL).
    -  Drag'n'Drop prototype:                              msw.

TTY:

Images:
  Compiling in support for XPM  images.
  Compiling in support for PNG  images.
  Compiling in support for JPEG images.

Sound:
  Compiling in support for sound (native).

Databases:

Internationalization:
  Compiling in support for Mule (multi-lingual Emacs).

Mail:
  Compiling in support for POP mail retrieval.

Network:
  Inhibiting IPv6 canonicalization at startup.

Other Features:
  Compiling in support for dynamic shared object modules.
  Compiling in support for more number types using the GNU MP library.
  Using the new GC mark algorithms (KKCC).
  WARNING: ---------------------------------------------------------
  WARNING: The new algorithms are experimental. They are enabled by
  WARNING: default for this release. Use `--disable-kkcc' to
  WARNING: turn it off.
  WARNING: ---------------------------------------------------------
  Using the new portable dumper.
  Dumping into executable.
  Compiling in support for extra debugging code.
  Compiling in support for runtime error checking.
  WARNING: ---------------------------------------------------------
  WARNING: XEmacs will run noticeably more slowly as a result.
  WARNING: Error checking is on by default for XEmacs beta releases.
  WARNING: ---------------------------------------------------------


> 2) have you tried a 64 build also ?

No, but based on feedback from the xemacs-beta mailing list, I do not
believe that 64-bit mode currently builds.

Regards,
  Vin

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

Hi Vin,
Hi Volker,

On Jan 15 09:12, Vin Shelton wrote:
> Marco/Volker et al -
> [...]
> On Thu, Jan 15, 2015 at 7:50 AM, Marco Atzeri <...> wrote:
> > Question:
> > 0) does it work ?
> [...]
> > 2) have you tried a 64 build also ?
> 
> No, but based on feedback from the xemacs-beta mailing list, I do not
> believe that 64-bit mode currently builds.

Do you have any idea what the problem might be?  It would be very
interesting to know if the problems from your feedback was pre
Cygwin-1.7.33 or with Cygwin 1.7.33, especially due to the changes in
internal exception handling in Cygwin.  This might be a likely culprit
for problems.

Another culprit could be the difference in the Windows (LLP64) vs. the
Cygwin (LP64) data model, as outlined in
https://cygwin.com/faq/faq.html#faq.programming.64bitporting and
subsequent FAQ entries, especially given the native Win32 GUI mode of
xemacs.

If you're interested in getting xemacs running on 64 bit Cygwin, feel
free to use the cygwin-apps mailing list for communication and don't
hesitate to ping me if you think the Cygwin DLL itself has a problem.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Peter A. Castro]

On Wed, 14 Jan 2015, Corinna Vinschen wrote:

> Date: Wed, 14 Jan 2015 15:13:44 +0100
> From: Corinna Vinschen <corinna-cygwin@cygwin.com>
> Reply-To: cygwin-apps@cygwin.com
> To: cygwin-apps@cygwin.com
> Cc: Jari Aalto <jari.aalto@cante.net>,
>     Kostya Altukhov <kacygwinlist@gmail.com>,
>     Peter A. Castro <doctor@fruitbat.org>,
>     Yaakov Selkowitz <yselkowitz@cygwin.com>,
>     Marco Atzeri <marco.atzeri@gmail.com>,
>     Dr. Volker Zell <dr.volker.zell@oracle.com>,
>     David Rothenberger <daveroth@acm.org>, Reini Urban <rurban@x-ray.at>
> Subject: [HEADSUP] Dropping libopenssl098 from distro
> 
> Hi folks,
>
> it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
> the 32 bit distro.  Fortunately they were never in the 64 bit distro.
>
> The problem is that we still have packages requiring libopenssl098.
> These need rebuilding or removing.
>
> The following packages need simple rebuilding:
>
>  suite3270	Peter A. Castro

I'm looking into this.  Actually, I need to upgrade the packages to newer 
versions so will get that done too.

> Thanks,
> Corinna

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: [HEADSUP] Dropping libopenssl098 from distro

[Peter A. Castro]

On Wed, 14 Jan 2015, Corinna Vinschen wrote:

> Hi folks,
>
>
> it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
> the 32 bit distro.  Fortunately they were never in the 64 bit distro.
>
> The problem is that we still have packages requiring libopenssl098.
> These need rebuilding or removing.
>
> The following packages need simple rebuilding:
[snip]
>  suite3270	Peter A. Castro

I'm looking into this.  Actually, I need to upgrade the packages to newer
versions so will get that done too.

> Thanks,
> Corinna

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: [HEADSUP] Dropping libopenssl098 from distro (DONE: ctorrent suck)

[Jari Aalto]

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

2015-01-14 16:13 Corinna Vinschen
<corinna-cygwin-rDBXBDvO6BXQT0dZR+AlfA(at)public.gmane.org>:
|
|
| it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
| the 32 bit distro.
|
|   ctorrent    Jari Aalto
|   suck        Jari Aalto

Done. Rebuilt and uploaded.

Jari

[-- Attachment #2: Type: application/pgp-signature, Size: 948 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro [pure-ftpd done]

[Marco Atzeri]

On 1/15/2015 2:03 PM, Marco Atzeri wrote:
> On 1/14/2015 3:13 PM, Corinna Vinschen wrote:
>> Hi folks,
>>
>>
>> it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
>> the 32 bit distro.  Fortunately they were never in the 64 bit distro.
>>
>>    pure-ftpd    Kostya Altukhov
>
> I will look on it
>
> Regards
> Marco
>

rebuilt and uploaded as 1.0.29-2 the 32 bit version.

I will look later to upgrade it and the 64 bit version.
It will take some time as Kostya made substantial patches
to handle quota and root.

Regards
Marco

[GOLDSTAR] Re: [HEADSUP] Dropping libopenssl098 from distro [pure-ftpd done]

[Corinna Vinschen]

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

On Jan 16 09:08, Marco Atzeri wrote:
> On 1/15/2015 2:03 PM, Marco Atzeri wrote:
> >On 1/14/2015 3:13 PM, Corinna Vinschen wrote:
> >>Hi folks,
> >>
> >>
> >>it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
> >>the 32 bit distro.  Fortunately they were never in the 64 bit distro.
> >>
> >>   pure-ftpd    Kostya Altukhov
> >
> >I will look on it
> >
> >Regards
> >Marco
> >
> 
> rebuilt and uploaded as 1.0.29-2 the 32 bit version.
> 
> I will look later to upgrade it and the 64 bit version.
> It will take some time as Kostya made substantial patches
> to handle quota and root.

Thanks, I think this is worth a goldstar.  Andrew, do your worst.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [GOLDSTAR] Re: [HEADSUP] Dropping libopenssl098 from distro [pure-ftpd done]

[Andrew Schulman]

> On Jan 16 09:08, Marco Atzeri wrote:
> > On 1/15/2015 2:03 PM, Marco Atzeri wrote:
> > >On 1/14/2015 3:13 PM, Corinna Vinschen wrote:
> > >>Hi folks,
> > >>
> > >>
> > >>it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
> > >>the 32 bit distro.  Fortunately they were never in the 64 bit distro.
> > >>
> > >>   pure-ftpd    Kostya Altukhov
> > >
> > >I will look on it
> > >
> > >Regards
> > >Marco
> > >
> > 
> > rebuilt and uploaded as 1.0.29-2 the 32 bit version.
> > 
> > I will look later to upgrade it and the 64 bit version.
> > It will take some time as Kostya made substantial patches
> > to handle quota and root.
> 
> Thanks, I think this is worth a goldstar.  Andrew, do your worst.

Awarded!  http://cygwin.com/goldstars/#MA

Re: [HEADSUP] Dropping libopenssl098 from distro

[Dr. Volker Zell]

Hi

I'm on business, no access to the logs...I will come back to this on friday.

Ciao
  Volker
  
>>>>> Vin Shelton writes:

    > Volker -
    > I can build XEmacs on 32-bit Cygwin.  What doesn't work for you?

    > Thanks,
    >   Vin Shelton


    > On Thu, Jan 15, 2015 at 6:27 AM, Dr. Volker Zell
    > <dr.volker.zell@oracle.com> wrote:
    >>>>>>> David Stacey writes:
    >> 
    >> > On 14/01/15 14:13, Corinna Vinschen wrote:
    >> >> The following packages have dependecies of their own, so they can't
    >> >> go away until the dependent packages have been rebuilt:
    >> >>
    >> >> libpq            Marco Atzeri
    >> >>
    >> >> required by:
    >> >>
    >> >> xemacs           Dr. Volker Zell
    >> 
    >> > Some time ago, there was a problem rebuilding xemacs [1]. Is this still an issue?
    >> 
    >> It used to compile but was not usable because of broken subprocess
    >> support. Now it doesn't even compile :-(
    >> 
    >> > Dave.
    >> 
    >> Ciao
    >> Volker
    >> 

-- 
DR. VOLKER ZELL | Principal Training Consultant | +49 211 74839 414
Oracle University

Oracle Deutschland GmbH | Hamborner Str. 51 | 40472 Düsseldorf

ORACLE Deutschland GmbH, Hauptverwaltung: Riesstraße 25, D-80992 München
Geschäftsführer: Jürgen Kunz, Registergericht: Amtsgericht München, HRB 82775

Re: [HEADSUP] Dropping libopenssl098 from distro

[Dr. Volker Zell]

>>>>> Volker Zell writes:

    > Hi
    > I'm on business, no access to the logs...I will come back to this on friday.

Here we are
    
    > Ciao
    >   Volker
  
>>>>> Vin Shelton writes:

    >> Volker -
    >> I can build XEmacs on 32-bit Cygwin.  What doesn't work for you?


gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2  -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c
In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0:
/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int'
 #define Status int
                ^
In file included from /usr/include/w32api/rpc.h:74:0,
                 from /usr/include/w32api/objbase.h:7,
                 from /usr/include/w32api/ole2.h:17,
                 from /usr/include/w32api/shlobj.h:85,
                 from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77,
                 from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:
/usr/include/w32api/rpcdce.h:210:51: error: unknown type name 'RPC_OBJECT_INQ_FN'
   RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN *InquiryFn);
                                                   ^
In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0:
/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int'
 #define Status int
                ^
In file included from /usr/include/w32api/rpc.h:74:0,
                 from /usr/include/w32api/objbase.h:7,
                 from /usr/include/w32api/ole2.h:17,
                 from /usr/include/w32api/shlobj.h:85,
                 from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77,
                 from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:
/usr/include/w32api/rpcdce.h:473:112: error: unknown type name 'RPC_AUTH_KEY_RETRIEVAL_FN'
   RPCRTAPI RPC_STATUS RPC_ENTRY RpcServerRegisterAuthInfoA(RPC_CSTR ServerPrincName,unsigned __LONG32 AuthnSvc,RPC_AUTH_KEY_RETRIEVAL_FN GetKeyFn,void *Arg);
                                                                                                                ^
/usr/include/w32api/rpcdce.h:474:112: error: unknown type name 'RPC_AUTH_KEY_RETRIEVAL_FN'
   RPCRTAPI RPC_STATUS RPC_ENTRY RpcServerRegisterAuthInfoW(RPC_WSTR ServerPrincName,unsigned __LONG32 AuthnSvc,RPC_AUTH_KEY_RETRIEVAL_FN GetKeyFn,void *Arg);
                                                                                                                ^
In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0:
/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int'
 #define Status int
                ^
/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int'
 #define Status int
                ^
/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int'
 #define Status int
                ^
/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int'
 #define Status int
                ^
/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int'
 #define Status int
                ^
In file included from /usr/include/w32api/rpc.h:74:0,
                 from /usr/include/w32api/objbase.h:7,
                 from /usr/include/w32api/ole2.h:17,
                 from /usr/include/w32api/shlobj.h:85,
                 from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77,
                 from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:
/usr/include/w32api/rpcdce.h:555:59: error: unknown type name 'RPC_MGMT_AUTHORIZATION_FN'
   RPCRTAPI RPC_STATUS RPC_ENTRY RpcMgmtSetAuthorizationFn(RPC_MGMT_AUTHORIZATION_FN AuthorizationFn);
                                                           ^
In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0:
/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: two or more data types in declaration specifiers
 #define Status int
                ^
/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: two or more data types in declaration specifiers
 #define Status int
                ^
/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: two or more data types in declaration specifiers
 #define Status int
                ^
/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: two or more data types in declaration specifiers
 #define Status int
                ^
In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0:
/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected identifier or '(' before 'int'
 #define Status int
                ^
GNUmakefile:59: recipe for target 'emacs.o' failed
make[1]: *** [emacs.o] Error 1
make[1]: Leaving directory '/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src'
GNUmakefile:123: recipe for target 'src' failed
make: *** [src] Error 2
^[[1;31m*** ERROR:^[[0;0m make failed

    
    >> Thanks,
    >> Vin Shelton

Ciao
  Volker
  

Re: [HEADSUP] Dropping libopenssl098 from distro

[Ken Brown]

On 1/23/2015 5:57 AM, Dr. Volker Zell wrote:
> gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2  -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c
> In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0:
> /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int'
>   #define Status int
>                  ^
> In file included from /usr/include/w32api/rpc.h:74:0,
>                   from /usr/include/w32api/objbase.h:7,
>                   from /usr/include/w32api/ole2.h:17,
>                   from /usr/include/w32api/shlobj.h:85,
>                   from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77,
>                   from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:
> /usr/include/w32api/rpcdce.h:210:51: error: unknown type name 'RPC_OBJECT_INQ_FN'
>     RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN *InquiryFn);

I think the problem is that "Status" is used in /usr/include/w32api/rpcdce.h, 
and this conflicts with "#define Status int".  I ran into a similar problem when 
trying to build clisp.

Ken

Re: [HEADSUP] Dropping libopenssl098 from distro

[Ken Brown]

On 1/14/2015 4:19 PM, Ken Brown wrote:
> On 1/14/2015 12:46 PM, Achim Gratz wrote:
>> Corinna Vinschen writes:
>>>> Clisp is not yet ported to 64bit and it has problems under 32bit as well
>>>> (temporary file generation) that also affect Maxima from ports.
>>>
>>> If it's a problem with the Cygwin DLL, it would be nice to get a
>>> bug report and, preferredly, an STC, so we have a chance to fix this.
>>
>> AFAIK it's the same problem that produced the same symptoms in sqlite:
>> using a non-Cygwin API.  So no, I don't think the Cygwin DLL is to
>> blame.
>>
>>> Apart from that, I was only talking about the 32 bitr version anyway.
>>> It requires the wrong libopenssl and needs a simple rebuild for now.
>>>
>>>> One of the things holding a port off is libsigsegv, IIRC.
>>>
>>> This is a bit annoying.  Libsigsegv should be optional, not required.
>>
>> I have no idea whether that's possible for clisp.
>
> It is.  There's a configure option "--ignore-absence-of-libsigsegv".  But there
> are more serious problems, affecting both the 32-bit and 64-bit versions.  (So
> even just rebuilding clisp for 32-bit Cygwin will take some work.)  The problem
> is that lisp.exe, which is built and used in the course of trying to build
> clisp.exe, crashes with a SEGV shortly after it's started.
>
> My reason for looking at this was that clisp is needed for building xindy, an
> optional component of TeX Live.  I did successfully build clisp in the 32-bit
> case four years ago, but I can't any more.  My guess (untested) is that this is
> because the location of the heap has changed since then, and maybe the source
> code makes unwarranted assumptions about memory layout.

My guess is correct.  lisp.exe uses bit 31 (counting from the LSB) as a marker 
during garbage collection, and this is incompatible with Cygwin's use of high 
memory for the heap.  I think I know how to fix this (by defining 
LINUX_NOEXEC_HEAPCODES in the Cygwin build), but I haven't finished testing it yet.

I'd like to know Reini's intentions before investing any more time in this. 
BTW, I am *not* qualified to take over as clisp maintainer.  I've never used 
clisp, and I know nothing about it other than the tiny bit I've learned from 
debugging the crash I mentioned above.

Ken

Re: [HEADSUP] Dropping libopenssl098 from distro

[Vin Shelton]

Hi, Volker -

Vin wrote:
>> I can build XEmacs on 32-bit Cygwin.  What doesn't work for you?

Volker wrote:
> Here we are

A few thoughts:

1. You need to use the most recent XEmacs sources from mercurial.

2. You must have an old version of libpng installed, because 21.4.22
won't compile with the newer libpng (some structure members are
hidden).

3. You will also need to add:

#define stricmp strcasecmp

to src/s/cygwin32.h

4. I will review the contents of xemacs-21.4.22-1.src.patch and
promote at least your developer info and the above stricmp hack to the
mercurial repo.

5. I have promised to release 21.4.23, so I will do that shortly after #4 above.

  - Vin

Re: [HEADSUP] Dropping libopenssl098 from distro

[Dr. Volker Zell]

>>>>> Ken Brown writes:

    > On 1/23/2015 5:57 AM, Dr. Volker Zell wrote:
    >> gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2  -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c
    >> In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0:
    >> /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int'
    >> #define Status int
    >> ^
    >> In file included from /usr/include/w32api/rpc.h:74:0,
    >> from /usr/include/w32api/objbase.h:7,
    >> from /usr/include/w32api/ole2.h:17,
    >> from /usr/include/w32api/shlobj.h:85,
    >> from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77,
    >> from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:
    >> /usr/include/w32api/rpcdce.h:210:51: error: unknown type name 'RPC_OBJECT_INQ_FN'
    >> RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN *InquiryFn);

    > I think the problem is that "Status" is used in /usr/include/w32api/rpcdce.h,
    > and this conflicts with "#define Status int".  I ran into a similar problem when
    > trying to build clisp.

Any simple fix/workaround  for this ?

Ciao
  Volker
  

Re: [HEADSUP] Dropping libopenssl098 from distro

[Vin Shelton]

On Fri, Jan 23, 2015 at 10:43 AM, Dr. Volker Zell wrote:
>>>>>> Ken Brown writes:
>
>     > On 1/23/2015 5:57 AM, Dr. Volker Zell wrote:
>     >> gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2  -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c
>     >> In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0:
>     >> /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int'
>     >> #define Status int
>     >> ^
>     >> In file included from /usr/include/w32api/rpc.h:74:0,
>     >> from /usr/include/w32api/objbase.h:7,
>     >> from /usr/include/w32api/ole2.h:17,
>     >> from /usr/include/w32api/shlobj.h:85,
>     >> from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77,
>     >> from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:
>     >> /usr/include/w32api/rpcdce.h:210:51: error: unknown type name 'RPC_OBJECT_INQ_FN'
>     >> RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN *InquiryFn);
>
>     > I think the problem is that "Status" is used in /usr/include/w32api/rpcdce.h,
>     > and this conflicts with "#define Status int".  I ran into a similar problem when
>     > trying to build clisp.
>
> Any simple fix/workaround  for this ?

I don't see that failure with latest XEmacs 21.4 sources from
mercurial.  I did not investigate further.

Regards,
  Vin

Re: [HEADSUP] Dropping libopenssl098 from distro

[Dr. Volker Zell]

>>>>> Vin Shelton writes:

    > Hi, Volker -
    > Vin wrote:
    >>> I can build XEmacs on 32-bit Cygwin.  What doesn't work for you?

    > Volker wrote:
    >> Here we are

    > A few thoughts:

    > 1. You need to use the most recent XEmacs sources from mercurial.

OK
    
    > 2. You must have an old version of libpng installed, because 21.4.22
    > won't compile with the newer libpng (some structure members are
    > hidden).

I had a patch for this..see the xemacs.cygport file.
    
    > 3. You will also need to add:

    > #define stricmp strcasecmp

    > to src/s/cygwin32.h

In the current source we have ?    

    > 4. I will review the contents of xemacs-21.4.22-1.src.patch and
    > promote at least your developer info and the above stricmp hack to the
    > mercurial repo.

Ah...ok
    
    > 5. I have promised to release 21.4.23, so I will do that shortly after #4 above.

Cool...thanks. I'll wait for that before going on.
    
    >   - Vin

Ciao
  Volker
  

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

On Jan 23 16:43, Dr. Volker Zell wrote:
> >>>>> Ken Brown writes:
> 
>     > On 1/23/2015 5:57 AM, Dr. Volker Zell wrote:
>     >> gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2  -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c
>     >> In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0:
>     >> /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int'
>     >> #define Status int
>     >> ^
>     >> In file included from /usr/include/w32api/rpc.h:74:0,
>     >> from /usr/include/w32api/objbase.h:7,
>     >> from /usr/include/w32api/ole2.h:17,
>     >> from /usr/include/w32api/shlobj.h:85,
>     >> from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77,
>     >> from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:
>     >> /usr/include/w32api/rpcdce.h:210:51: error: unknown type name 'RPC_OBJECT_INQ_FN'
>     >> RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN *InquiryFn);
> 
>     > I think the problem is that "Status" is used in /usr/include/w32api/rpcdce.h,
>     > and this conflicts with "#define Status int".  I ran into a similar problem when
>     > trying to build clisp.
> 
> Any simple fix/workaround  for this ?

It's a bug in the header, because it's polluting the namespace with
unnecessary usage of "Status" as parameter names in prototypes.  The
header should use __status__ or drop them entirely.

What you could try is either one of

- Change the order of the header files, so that the windows headers
  are included before the private header defining Status.

- Or, prior to including the Windows headers, push the macro and
  undefine it, after including the windows headers, pop the macro:

    #pragma push_macro ("Status")
    #undef Status
    #include <windows.h>
    #pragma pop_macro ("Status")

- Or, you could not include windce.h at all if you don't need any of it:

   #define __RPCDCE_H__
   #include <windows.h>
   ...

Apart from that, the header should be fixed in Mingw-w64.


HTH,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

Hi Ken,

On Jan 23 08:48, Ken Brown wrote:
> On 1/14/2015 4:19 PM, Ken Brown wrote:
> >It is.  There's a configure option "--ignore-absence-of-libsigsegv".  But there
> >are more serious problems, affecting both the 32-bit and 64-bit versions.  (So
> >even just rebuilding clisp for 32-bit Cygwin will take some work.)  The problem
> >is that lisp.exe, which is built and used in the course of trying to build
> >clisp.exe, crashes with a SEGV shortly after it's started.
> >
> >My reason for looking at this was that clisp is needed for building xindy, an
> >optional component of TeX Live.  I did successfully build clisp in the 32-bit
> >case four years ago, but I can't any more.  My guess (untested) is that this is
> >because the location of the heap has changed since then, and maybe the source
> >code makes unwarranted assumptions about memory layout.
> 
> My guess is correct.  lisp.exe uses bit 31 (counting from the LSB) as a
> marker during garbage collection, and this is incompatible with Cygwin's use
> of high memory for the heap.  I think I know how to fix this (by defining
> LINUX_NOEXEC_HEAPCODES in the Cygwin build), but I haven't finished testing
> it yet.

Given that by default *all* addresses used for 64 bit Cygwin processes
are beyond the 2GB border, it's kind of tricky to use bit 31 for anything.

But even then, the same code would fail on 32 bit Windows as well, if
it's running under WOW64 or a 32 bit kernel started with the /3GB flag
(or it's successor).  In both cases Cygwin would happily use the
addresses beyond 0x80000000 for the heap.

So, from that I conclude that using bit 31 for any dubious reason is
inherently broken.  I hope that the LINUX_NOEXEC_HEAPCODES stuff works,
and if so, it should be used for the 32 bit build as well.

> I'd like to know Reini's intentions before investing any more time in this.
> BTW, I am *not* qualified to take over as clisp maintainer.  I've never used
> clisp, and I know nothing about it other than the tiny bit I've learned from
> debugging the crash I mentioned above.

Well, it seems you're now stuck with it.

<slashdot>
I, for one, welcome our new clisp overlord!
</slashdot>


*Duck*
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Andrew Schulman]

> I, for one, welcome our new clisp overlord!

ALL HAIL THE CLISP OVERLORD

Re: [HEADSUP] Dropping libopenssl098 from distro

[Ken Brown]

On 1/23/2015 3:09 PM, Corinna Vinschen wrote:
> Hi Ken,
>
> On Jan 23 08:48, Ken Brown wrote:
>> On 1/14/2015 4:19 PM, Ken Brown wrote:
>>> It is.  There's a configure option "--ignore-absence-of-libsigsegv".  But there
>>> are more serious problems, affecting both the 32-bit and 64-bit versions.  (So
>>> even just rebuilding clisp for 32-bit Cygwin will take some work.)  The problem
>>> is that lisp.exe, which is built and used in the course of trying to build
>>> clisp.exe, crashes with a SEGV shortly after it's started.
>>>
>>> My reason for looking at this was that clisp is needed for building xindy, an
>>> optional component of TeX Live.  I did successfully build clisp in the 32-bit
>>> case four years ago, but I can't any more.  My guess (untested) is that this is
>>> because the location of the heap has changed since then, and maybe the source
>>> code makes unwarranted assumptions about memory layout.
>>
>> My guess is correct.  lisp.exe uses bit 31 (counting from the LSB) as a
>> marker during garbage collection, and this is incompatible with Cygwin's use
>> of high memory for the heap.  I think I know how to fix this (by defining
>> LINUX_NOEXEC_HEAPCODES in the Cygwin build), but I haven't finished testing
>> it yet.
>
> Given that by default *all* addresses used for 64 bit Cygwin processes
> are beyond the 2GB border, it's kind of tricky to use bit 31 for anything.
>
> But even then, the same code would fail on 32 bit Windows as well, if
> it's running under WOW64 or a 32 bit kernel started with the /3GB flag
> (or it's successor).  In both cases Cygwin would happily use the
> addresses beyond 0x80000000 for the heap.
>
> So, from that I conclude that using bit 31 for any dubious reason is
> inherently broken.  I hope that the LINUX_NOEXEC_HEAPCODES stuff works,
> and if so, it should be used for the 32 bit build as well.

Sorry, I should have been more clear.  I was only talking about the 32-bit 
build.  I haven't yet seriously tried the 64-bit build.
>
>> I'd like to know Reini's intentions before investing any more time in this.
>> BTW, I am *not* qualified to take over as clisp maintainer.  I've never used
>> clisp, and I know nothing about it other than the tiny bit I've learned from
>> debugging the crash I mentioned above.
>
> Well, it seems you're now stuck with it.
>
> <slashdot>
> I, for one, welcome our new clisp overlord!
> </slashdot>

Thanks a lot.

I'll see if I can at least get version 3.48 or 3.49 built on both platforms. 
But in view of what Reini said about it being broken upstream, I don't think 
I'll try to go further.

Ken

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

On Jan 23 15:45, Andrew Schulman wrote:
> 
> > I, for one, welcome our new clisp overlord!
> 
> ALL HAIL THE CLISP OVERLORD

YMMD,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

On Jan 23 17:43, Ken Brown wrote:
> On 1/23/2015 3:09 PM, Corinna Vinschen wrote:
> >Hi Ken,
> >
> >On Jan 23 08:48, Ken Brown wrote:
> >>[...]
> >>My guess is correct.  lisp.exe uses bit 31 (counting from the LSB) as a
> >>marker during garbage collection, and this is incompatible with Cygwin's use
> >>of high memory for the heap.  I think I know how to fix this (by defining
> >>LINUX_NOEXEC_HEAPCODES in the Cygwin build), but I haven't finished testing
> >>it yet.
> >
> >Given that by default *all* addresses used for 64 bit Cygwin processes
> >are beyond the 2GB border, it's kind of tricky to use bit 31 for anything.
> >
> >But even then, the same code would fail on 32 bit Windows as well, if
> >it's running under WOW64 or a 32 bit kernel started with the /3GB flag
> >(or it's successor).  In both cases Cygwin would happily use the
> >addresses beyond 0x80000000 for the heap.
> >
> >So, from that I conclude that using bit 31 for any dubious reason is
> >inherently broken.  I hope that the LINUX_NOEXEC_HEAPCODES stuff works,
> >and if so, it should be used for the 32 bit build as well.
> 
> Sorry, I should have been more clear.  I was only talking about the 32-bit
> build.  I haven't yet seriously tried the 64-bit build.

Oh, ok.

> >>I'd like to know Reini's intentions before investing any more time in this.
> >>BTW, I am *not* qualified to take over as clisp maintainer.  I've never used
> >>clisp, and I know nothing about it other than the tiny bit I've learned from
> >>debugging the crash I mentioned above.
> >
> >Well, it seems you're now stuck with it.
> >
> ><slashdot>
> >I, for one, welcome our new clisp overlord!
> ></slashdot>
> 
> Thanks a lot.
> 
> I'll see if I can at least get version 3.48 or 3.49 built on both platforms.
> But in view of what Reini said about it being broken upstream, I don't think
> I'll try to go further.

Whoopee!  You know, I was just making fun, but that's really good news.
If you need help to analyze problems on 64 bit, or if you have fun to
look why the newer versions won't work, feel free to discuss the problems
here.  Maybe it's something we can solve together.


Thanks a million,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Vin Shelton]

Dear Volker, Ken and Corinna,

On Fri, Jan 23, 2015 at 10:43 AM, Dr. Volker Zell wrote:
>>>>>> Ken Brown writes:
>
>     > On 1/23/2015 5:57 AM, Dr. Volker Zell wrote:
>     >> gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2  -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c
>     >> In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0:
>     >> /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int'
>     >> #define Status int
>     >> ^
>     >> In file included from /usr/include/w32api/rpc.h:74:0,
>     >> from /usr/include/w32api/objbase.h:7,
>     >> from /usr/include/w32api/ole2.h:17,
>     >> from /usr/include/w32api/shlobj.h:85,
>     >> from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77,
>     >> from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:
>     >> /usr/include/w32api/rpcdce.h:210:51: error: unknown type name 'RPC_OBJECT_INQ_FN'
>     >> RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN *InquiryFn);
>
>     > I think the problem is that "Status" is used in /usr/include/w32api/rpcdce.h,
>     > and this conflicts with "#define Status int".  I ran into a similar problem when
>     > trying to build clisp.
>
> Any simple fix/workaround  for this ?

Thanks for pointing this out.  It dawned on me yesterday that the
reason I didn't see these problems is because I don't build with X
support on Cygwin.  Once I configured in X support, I saw these errors
and a few others.  It took me awhile to work out the right changes to
make, but I have checked changes into the XEmacs 21.4 mercurial
repository that enable XEmacs 21.4 to build under Cygwin with X
support.

One problem remains - Xaw3d support does not work, so I removed that
from the configure line.  The problem I found was that XEmacs seemed
to be expecting version 8 of Xaw3d, but Cygwin supplies version 7.

I still plan to release 21.4.23 in the near future, but I would
recommend making an updated XEmacs 21.4 kit before that point.

Regards,
  Vin Shelton

Re: [HEADSUP] Dropping libopenssl098 from distro

[Reini Urban]

On 01/14/2015 03:19 PM, Ken Brown wrote:
> On 1/14/2015 12:46 PM, Achim Gratz wrote:
>> Corinna Vinschen writes:
>>>> Clisp is not yet ported to 64bit and it has problems under 32bit as
>>>> well
>>>> (temporary file generation) that also affect Maxima from ports.
>>>
>>> If it's a problem with the Cygwin DLL, it would be nice to get a
>>> bug report and, preferredly, an STC, so we have a chance to fix this.
>>
>> AFAIK it's the same problem that produced the same symptoms in sqlite:
>> using a non-Cygwin API.  So no, I don't think the Cygwin DLL is to
>> blame.
>>
>>> Apart from that, I was only talking about the 32 bitr version anyway.
>>> It requires the wrong libopenssl and needs a simple rebuild for now.
>>>
>>>> One of the things holding a port off is libsigsegv, IIRC.
>>>
>>> This is a bit annoying.  Libsigsegv should be optional, not required.
>>
>> I have no idea whether that's possible for clisp.
> 
> It is.  There's a configure option "--ignore-absence-of-libsigsegv". 
> But there are more serious problems, affecting both the 32-bit and
> 64-bit versions.  (So even just rebuilding clisp for 32-bit Cygwin will
> take some work.)  The problem is that lisp.exe, which is built and used
> in the course of trying to build clisp.exe, crashes with a SEGV shortly
> after it's started.
> 
> My reason for looking at this was that clisp is needed for building
> xindy, an optional component of TeX Live.  I did successfully build
> clisp in the 32-bit case four years ago, but I can't any more.  My guess
> (untested) is that this is because the location of the heap has changed
> since then, and maybe the source code makes unwarranted assumptions
> about memory layout.
> 
> It's a shame that Reini isn't available to help with this.

64bit is not yet possible, yes.
on 32bit, just use 2.48, which should work ok.
but the build system is tricky.

2.49 never really worked. I've tried a few times to fix modules support.
Most of my fixes are upstream, but the last released version was not
fixable anymore. A gnulib problem.

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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


Just a quick update on the libopenssl098 frontier:


On Jan 14 15:13, Corinna Vinschen wrote:
> it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
> the 32 bit distro.  Fortunately they were never in the 64 bit distro.
> 
> The problem is that we still have packages requiring libopenssl098.
> These need rebuilding or removing.
> 
> The following packages need simple rebuilding:
> 
>   suite3270	Peter A. Castro

Peter, any progress?

> The following packages have dependecies of their own, so they can't
> go away until the dependent packages have been rebuilt:
> 
>   libarchive2	Yaakov Selkowitz
> 
>     required by:
> 
> 	gvfs		Yaakov Selkowitz
> 	libgxps2	Yaakov Selkowitz
> 
> 	gvfs and libgxps2 should be rebuilt to link against libarchive13.

This needs the GNOME 3.14 update which will take some time.

>   libpq		Marco Atzeri
> 
>     required by:
> 
> 	clisp		Ken Brown
> 	xemacs		Dr. Volker Zell

These are "in the works".

> 	libsasl2	David Rothenberger

	  required by:

	    libopenldap2_3_0

Both of these packages can be removed automatically when clisp and xemacs
are rebuilt.

So the situation is grave, but not hopeless.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Ken Brown]

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

On 1/23/2015 8:48 AM, Ken Brown wrote:
> My guess is correct.  lisp.exe uses bit 31 (counting from the LSB) as a marker
> during garbage collection, and this is incompatible with Cygwin's use of high
> memory for the heap.  I think I know how to fix this (by defining
> LINUX_NOEXEC_HEAPCODES in the Cygwin build), but I haven't finished testing it yet.

I've now built clisp-2.48 with this change (32-bit only), and I've tested it as 
well as I can, given that I'm not a clisp user.  The build passes all but a 
handful of about 12,000 tests, so I think it's probably OK.  (None of the test 
failures involved crashes.)

I'm attaching the patches that I applied (on top of Reini's patches) in order to 
make the build succeed.  I also had to use libdb4.5 instead of libdb4.8.
Reini, if you're still lurking, maybe you could take a look at the patches.

Ken

[-- Attachment #2: 2.48-Handle.patch --]
[-- Type: text/plain, Size: 546 bytes --]

--- origsrc/clisp-2.48/src/unix.d	2009-06-17 10:26:40.000000000 -0400
+++ src/clisp-2.48/src/unix.d	2015-01-26 12:11:27.111212000 -0500
@@ -716,7 +716,10 @@ extern int wait2 (PID_T pid); /* see uni
 /* Interpretation of FILETIME structure: */
 #ifdef UNIX_CYGWIN32
   #define WIN32_LEAN_AND_MEAN
+  #pragma push_macro ("Handle")
+  #undef Handle
   #include <windows.h>
+  #pragma pop_macro ("Handle")
   #undef WIN32
   extern long time_t_from_filetime (const FILETIME * ptr);
   extern void time_t_to_filetime (time_t time_in, FILETIME * out);

[-- Attachment #3: 2.48-HEAPCODES.patch --]
[-- Type: text/plain, Size: 835 bytes --]

--- origsrc/clisp-2.48/src/lispbibl.d	2009-07-28 09:58:03.000000000 -0400
+++ src/clisp-2.48/src/lispbibl.d	2015-01-26 12:14:01.822061000 -0500
@@ -2603,7 +2603,7 @@ Long-Float, Ratio and Complex (only if S
      malloc results (and hence also of shared libraries) are randomized;
      only the code address is fixed around 0x1C000000 and the stack address
      is around 0xCF000000. In this case, we also use LINUX_NOEXEC_HEAPCODES. */
-    #if (defined(I80386) && defined(UNIX_LINUX)) || (defined(I80386) && defined(UNIX_OPENBSD) && defined(ADDRESS_RANGE_RANDOMIZED))
+    #if (defined(I80386) && defined(UNIX_LINUX)) || (defined(I80386) && defined(UNIX_OPENBSD) && defined(ADDRESS_RANGE_RANDOMIZED)) || (defined(I80386) && defined(UNIX_CYGWIN32))
       #define LINUX_NOEXEC_HEAPCODES
     #else
       #define STANDARD_HEAPCODES

[-- Attachment #4: 2.48-uuid.patch --]
[-- Type: text/plain, Size: 1062 bytes --]

--- origsrc/clisp-2.48/modules/syscalls/calls.c	2009-07-22 21:12:31.000000000 -0400
+++ src/clisp-2.48/modules/syscalls/calls.c	2015-01-26 12:28:34.091951900 -0500
@@ -3302,6 +3302,7 @@ DEFUN(POSIX::DUPLICATE-HANDLE, old &opti
 
 #if defined(WIN32_NATIVE) || defined(UNIX_CYGWIN32)
 #include <shlobj.h>
+#include <shlguid.h>
 DEFCHECKER(check_file_attributes, type=DWORD, reverse=uint32_to_I,      \
            default=, prefix=FILE_ATTRIBUTE, bitmasks=both,              \
            ARCHIVE COMPRESSED :DEVICE :DIRECTORY ENCRYPTED HIDDEN :NORMAL \
--- origsrc/clisp-2.48/modules/syscalls/configure	2009-07-28 12:33:13.000000000 -0400
+++ src/clisp-2.48/modules/syscalls/configure	2015-01-26 12:09:16.528743100 -0500
@@ -4085,7 +4085,7 @@ fi
 done
 
 if test "$ac_cv_header_shlobj_h" = yes ; then
-   LIBS=${LIBS}' -luser32 -lole32 -loleaut32 -luuid';
+   LIBS=${LIBS}' -luser32 -lole32 -loleaut32 -L/usr/lib/w32api -luuid';
 fi
 # The cast to long int works around a bug in the HP C Compiler
 # version HP92453-01 B.11.11.23709.GP, which incorrectly rejects

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

Hi Ken,

On Jan 29 15:25, Ken Brown wrote:
> On 1/23/2015 8:48 AM, Ken Brown wrote:
> >My guess is correct.  lisp.exe uses bit 31 (counting from the LSB) as a marker
> >during garbage collection, and this is incompatible with Cygwin's use of high
> >memory for the heap.  I think I know how to fix this (by defining
> >LINUX_NOEXEC_HEAPCODES in the Cygwin build), but I haven't finished testing it yet.
> 
> I've now built clisp-2.48 with this change (32-bit only), and I've tested it
> as well as I can, given that I'm not a clisp user.  The build passes all but
> a handful of about 12,000 tests, so I think it's probably OK.  (None of the
> test failures involved crashes.)

Sounds great to me (not being a clisp user myself).

> I'm attaching the patches that I applied (on top of Reini's patches) in
> order to make the build succeed.  I also had to use libdb4.5 instead of
> libdb4.8.

Is that ok?  I mean, shouldn't a package always try to use the latest
version?  What's the problem you're observing ?  Maybe Volker can help
here?

I just had a look and it turned out that the 64 bit release only has
a single db version, 5.3, while the 32 bit version comes with 4.5 and
4.8 only.  Volker???


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Dr. Volker Zell]

>>>>> Corinna Vinschen writes:

    > I just had a look and it turned out that the 64 bit release only has
    > a single db version, 5.3, while the 32 bit version comes with 4.5 and
    > 4.8 only.  Volker???

5.3 for 64 bit was compiled by Yaakov I think, when I was absent.

xemacs and db are the packages where I still have to catchup to
compile/recompile for the latest 32/64bit releases.

Unfortunately I will be on a business trip for one more week.

    > Corinna

Ciao
  Volker
  

Re: [HEADSUP] Dropping libopenssl098 from distro

[Ken Brown]

On 1/30/2015 4:41 AM, Corinna Vinschen wrote:
> Hi Ken,
>
> On Jan 29 15:25, Ken Brown wrote:
>> On 1/23/2015 8:48 AM, Ken Brown wrote:
>>> My guess is correct.  lisp.exe uses bit 31 (counting from the LSB) as a marker
>>> during garbage collection, and this is incompatible with Cygwin's use of high
>>> memory for the heap.  I think I know how to fix this (by defining
>>> LINUX_NOEXEC_HEAPCODES in the Cygwin build), but I haven't finished testing it yet.
>>
>> I've now built clisp-2.48 with this change (32-bit only), and I've tested it
>> as well as I can, given that I'm not a clisp user.  The build passes all but
>> a handful of about 12,000 tests, so I think it's probably OK.  (None of the
>> test failures involved crashes.)
>
> Sounds great to me (not being a clisp user myself).
>
>> I'm attaching the patches that I applied (on top of Reini's patches) in
>> order to make the build succeed.  I also had to use libdb4.5 instead of
>> libdb4.8.
>
> Is that ok?  I mean, shouldn't a package always try to use the latest
> version?  What's the problem you're observing ?  Maybe Volker can help
> here?

The clisp-2.48 code uses some macros and structures that are defined in the 
db4.5 headers but have changed or disappeared in db4.8.  I'll see if I can 
figure out how to update the code for db4.8.

Ken

Re: [HEADSUP] Dropping libopenssl098 from distro

[Ken Brown]

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

On 1/30/2015 8:25 AM, Ken Brown wrote:
> On 1/30/2015 4:41 AM, Corinna Vinschen wrote:
>> On Jan 29 15:25, Ken Brown wrote:
>>> I'm attaching the patches that I applied (on top of Reini's patches) in
>>> order to make the build succeed.  I also had to use libdb4.5 instead of
>>> libdb4.8.
>>
>> Is that ok?  I mean, shouldn't a package always try to use the latest
>> version?  What's the problem you're observing ?  Maybe Volker can help
>> here?
>
> The clisp-2.48 code uses some macros and structures that are defined in the
> db4.5 headers but have changed or disappeared in db4.8.  I'll see if I can
> figure out how to update the code for db4.8.

OK, that wasn't so hard.  I'm attaching the patch that I applied, in case Reini 
or Volker has a chance to look at it.  All 76 tests for the berkeley-db module 
passed.

Ken

[-- Attachment #2: 2.48-bdb.patch --]
[-- Type: text/plain, Size: 5568 bytes --]

--- origsrc/clisp-2.48/modules/berkeley-db/bdb.c	2009-06-27 04:13:33.000000000 -0400
+++ src/clisp-2.48/modules/berkeley-db/bdb.c	2015-01-30 10:12:11.415894600 -0500
@@ -1039,9 +1039,9 @@ static object dbe_get_lk_conflicts (DB_E
 FLAG_EXTRACTOR(dbe_get_flags_num,DB_ENV*)
 DEFUNR(BDB:DBE-GET-OPTIONS, dbe &optional what) {
   object what = STACK_0;
-  /* dbe may be NULL only for DB_XIDDATASIZE */
+  /* dbe may be NULL only for DB_GID_SIZE */
   DB_ENV *dbe = (DB_ENV*)bdb_handle(STACK_1,`BDB::DBE`,
-                                    eq(what,`:DB-XIDDATASIZE`)
+                                    eq(what,`:DB-GID-SIZE`)
                                     ? BH_NIL_IS_NULL : BH_VALID);
   what = STACK_0; skipSTACK(2);
  restart_DBE_GET_OPTIONS:
@@ -1210,8 +1210,8 @@ DEFUNR(BDB:DBE-GET-OPTIONS, dbe &optiona
     VALUES1(dbe_get_errfile(dbe));
   } else if (eq(what,`:MSGFILE`)) {
     VALUES1(dbe_get_msgfile(dbe));
-  } else if (eq(what,`:DB-XIDDATASIZE`)) {
-    VALUES1(fixnum(DB_XIDDATASIZE));
+  } else if (eq(what,`:DB-GID-SIZE`)) {
+    VALUES1(fixnum(DB_GID_SIZE));
   } else if (eq(what,`:HOME`)) {
     VALUES1(dbe_get_home_dir(dbe,true));
   } else if (eq(what,`:OPEN`)) {
@@ -1235,10 +1235,10 @@ DEFUNR(BDB:DBE-GET-OPTIONS, dbe &optiona
 
 DEFUN(BDB:DB-CREATE, dbe &key XA)
 { /* create database */
-  u_int32_t flags = missingp(STACK_0) ? 0 : DB_XA_CREATE;
+  /* u_int32_t flags = missingp(STACK_0) ? 0 : DB_XA_CREATE; */
   DB_ENV *dbe = (DB_ENV*)bdb_handle(STACK_1,`BDB::DBE`,BH_NIL_IS_NULL);
   DB *db;
-  SYSCALL(db_create,(&db,dbe,flags));
+  SYSCALL(db_create,(&db,dbe,0));
   if (!dbe) {                   /* set error callback */
     begin_system_call();
     db->set_errcall(db,&error_callback);
@@ -2706,13 +2706,13 @@ DEFUN(BDB:TXN-CHECKPOINT, dbe &key KBYTE
 }
 
 /* return the pointer into the obj (which must be
-   a (vector (unsigned-byte 8) DB_XIDDATASIZE))
+   a (vector (unsigned-byte 8) DB_GID_SIZE))
  can trigger GC, the return value is invalidated by GC */
 static u_int8_t* check_gid (gcv_object_t *obj_) {
   uintL idx = 0;
   object data_vector;
-  *obj_ = check_byte_vector_len(*obj_,DB_XIDDATASIZE);
-  data_vector = array_displace_check(*obj_,DB_XIDDATASIZE,&idx);
+  *obj_ = check_byte_vector_len(*obj_,DB_GID_SIZE);
+  data_vector = array_displace_check(*obj_,DB_GID_SIZE,&idx);
   return TheSbvector(data_vector)->data+idx;
 }
 
@@ -2724,12 +2724,12 @@ DEFUN(BDB:TXN-PREPARE, txn gid)
   VALUES0; skipSTACK(2);
 }
 
-/* allocate a (vector (unsigned-byte 8) DB_XIDDATASIZE) for this gid
+/* allocate a (vector (unsigned-byte 8) DB_GID_SIZE) for this gid
  can trigger GC */
-static object gid_to_vector (u_int8_t gid[DB_XIDDATASIZE]) {
-  object vec = allocate_bit_vector(Atype_8Bit,DB_XIDDATASIZE);
+static object gid_to_vector (u_int8_t gid[DB_GID_SIZE]) {
+  object vec = allocate_bit_vector(Atype_8Bit,DB_GID_SIZE);
   begin_system_call();
-  memcpy(TheSbvector(vec)->data,gid,DB_XIDDATASIZE);
+  memcpy(TheSbvector(vec)->data,gid,DB_GID_SIZE);
   end_system_call();
   return vec;
 }
@@ -2742,7 +2742,7 @@ DEFUN(BDB:TXN-RECOVER, dbe &key FIRST :N
   u_int32_t tx_max;
   DB_PREPLIST *preplist;
   int status, ii;
-  long retnum;
+  u_int32_t retnum;
   SYSCALL(dbe->get_tx_max,(dbe,&tx_max));
   preplist = (DB_PREPLIST*)clisp_malloc(tx_max * sizeof(DB_PREPLIST));
   begin_blocking_system_call();
@@ -2801,8 +2801,8 @@ DEFUN(BDB:TXN-STAT, dbe &key STAT-CLEAR)
       pushSTACK(uint32_to_I(txn_active->txnid));
       pushSTACK(uint32_to_I(txn_active->parentid));
       pushSTACK(make_lsn(&(txn_active->lsn)));
-      pushSTACK(uint32_to_I(txn_active->xa_status));
-      pushSTACK(gid_to_vector(txn_active->xid));
+      pushSTACK(uint32_to_I(txn_active->status));
+      pushSTACK(gid_to_vector(txn_active->gid));
       funcall(`BDB::MKTXNACTIVE`,5); pushSTACK(value1);
     }
     value1 = vectorof(size); pushSTACK(value1);
--- origsrc/clisp-2.48/modules/berkeley-db/dbi.lisp	2008-12-31 11:26:09.000000000 -0500
+++ src/clisp-2.48/modules/berkeley-db/dbi.lisp	2015-01-30 10:53:59.548351500 -0500
@@ -252,7 +252,7 @@
   (region_nowait 0 :type (unsigned-byte 32) :read-only t))
 
 (defstruct (db-txn-active (:constructor mktxnactive
-                                        (txnid parentid lsn xa_status xid)))
+                                        (txnid parentid lsn status gid)))
   ;; The transaction ID of the transaction.
   (txnid 0 :type (unsigned-byte 32) :read-only t)
   ;; The transaction ID of the parent transaction (or 0, if no parent).
@@ -261,10 +261,10 @@
   (lsn nil :type lsn :read-only t)
   ;; If the transaction is an XA transaction, the status of the
   ;; transaction, otherwise 0.
-  (xa_status 0 :type (unsigned-byte 32) :read-only t)
+  (status 0 :type (or keyword (unsigned-byte 32)) :read-only t)
   ;; If the transaction is an XA transaction, the transaction's XA ID.
-  (xid nil :type (vector (unsigned-byte 8)
-                         #,(dbe-get-options nil :DB-XIDDATASIZE))
+  (gid nil :type (vector (unsigned-byte 8)
+                         #,(dbe-get-options nil :DB-GID-SIZE))
        :read-only t))
 
 (defstruct (db-txn-stat (:constructor mktxnstat
--- origsrc/clisp-2.48/modules/berkeley-db/test.tst	2008-10-20 22:07:46.000000000 -0400
+++ src/clisp-2.48/modules/berkeley-db/test.tst	2015-01-30 10:29:23.611932800 -0500
@@ -57,6 +57,8 @@ NIL
 
 (bdb:dbe-get-options *dbe* :errpfx) "zot"
 
+(bdb:dbe-get-options *dbe* :db-gid-size) 128
+
 (bdb:dbe-open *dbe* :home "bdb-home/" :create t
               :init-mpool t :init-txn t :init-lock t :init-log t)
 NIL

Re: [HEADSUP] Dropping libopenssl098 from distro

[Yaakov Selkowitz]

On Fri, 2015-01-30 at 11:40 -0500, Ken Brown wrote:
> On 1/30/2015 8:25 AM, Ken Brown wrote:
> > On 1/30/2015 4:41 AM, Corinna Vinschen wrote:
> >> On Jan 29 15:25, Ken Brown wrote:
> >>> I'm attaching the patches that I applied (on top of Reini's patches) in
> >>> order to make the build succeed.  I also had to use libdb4.5 instead of
> >>> libdb4.8.
> >>
> >> Is that ok?  I mean, shouldn't a package always try to use the latest
> >> version?  What's the problem you're observing ?  Maybe Volker can help
> >> here?
> >
> > The clisp-2.48 code uses some macros and structures that are defined in the
> > db4.5 headers but have changed or disappeared in db4.8.  I'll see if I can
> > figure out how to update the code for db4.8.
> 
> OK, that wasn't so hard.  I'm attaching the patch that I applied, in case Reini 
> or Volker has a chance to look at it.  All 76 tests for the berkeley-db module 
> passed.

FYI, this is the patch Fedora uses for this issue:

http://pkgs.fedoraproject.org/cgit/clisp.git/plain/clisp-db.patch

Without looking at the code, I don't know which is more appropriate.

--
Yaakov

Re: [HEADSUP] Dropping libopenssl098 from distro

[Ken Brown]

On 1/30/2015 2:02 PM, Yaakov Selkowitz wrote:
> On Fri, 2015-01-30 at 11:40 -0500, Ken Brown wrote:
>> On 1/30/2015 8:25 AM, Ken Brown wrote:
>>> On 1/30/2015 4:41 AM, Corinna Vinschen wrote:
>>>> On Jan 29 15:25, Ken Brown wrote:
>>>>> I'm attaching the patches that I applied (on top of Reini's patches) in
>>>>> order to make the build succeed.  I also had to use libdb4.5 instead of
>>>>> libdb4.8.
>>>>
>>>> Is that ok?  I mean, shouldn't a package always try to use the latest
>>>> version?  What's the problem you're observing ?  Maybe Volker can help
>>>> here?
>>>
>>> The clisp-2.48 code uses some macros and structures that are defined in the
>>> db4.5 headers but have changed or disappeared in db4.8.  I'll see if I can
>>> figure out how to update the code for db4.8.
>>
>> OK, that wasn't so hard.  I'm attaching the patch that I applied, in case Reini
>> or Volker has a chance to look at it.  All 76 tests for the berkeley-db module
>> passed.
>
> FYI, this is the patch Fedora uses for this issue:
>
> http://pkgs.fedoraproject.org/cgit/clisp.git/plain/clisp-db.patch

That patch doesn't deal with the differences between db4.5 and db4.8 (e.g., 
DB_XIDDATASIZE was changed to DB_GID_SIZE, among other things).  It must be for 
a different issue.

Ken

Re: [HEADSUP] Dropping libopenssl098 from distro

[Peter A. Castro]

On Mon, 26 Jan 2015, Corinna Vinschen wrote:

> Date: Mon, 26 Jan 2015 21:43:44 +0100
> From: Corinna Vinschen
> Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
> 
>
> Just a quick update on the libopenssl098 frontier:
>
>
> On Jan 14 15:13, Corinna Vinschen wrote:
>> it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
>> the 32 bit distro.  Fortunately they were never in the 64 bit distro.
>>
>> The problem is that we still have packages requiring libopenssl098.
>> These need rebuilding or removing.
>>
>> The following packages need simple rebuilding:
>>
>>   suite3270	Peter A. Castro
>
> Peter, any progress?

Still working on it.  I'm hitting some porting issues while upgrading the 
package suite.

>> The following packages have dependecies of their own, so they can't
>> go away until the dependent packages have been rebuilt:
>>
>>   libarchive2	Yaakov Selkowitz
>>
>>     required by:
>>
>> 	gvfs		Yaakov Selkowitz
>> 	libgxps2	Yaakov Selkowitz
>>
>> 	gvfs and libgxps2 should be rebuilt to link against libarchive13.
>
> This needs the GNOME 3.14 update which will take some time.
>
>>   libpq		Marco Atzeri
>>
>>     required by:
>>
>> 	clisp		Ken Brown
>> 	xemacs		Dr. Volker Zell
>
> These are "in the works".
>
>> 	libsasl2	David Rothenberger
>
> 	  required by:
>
> 	    libopenldap2_3_0
>
> Both of these packages can be removed automatically when clisp and xemacs
> are rebuilt.
>
> So the situation is grave, but not hopeless.
>
> Corinna

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

On Jan 31 13:32, Peter A. Castro wrote:
> On Mon, 26 Jan 2015, Corinna Vinschen wrote:
> 
> >Date: Mon, 26 Jan 2015 21:43:44 +0100
> >From: Corinna Vinschen
> >Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
> >
> >
> >Just a quick update on the libopenssl098 frontier:
> >
> >
> >On Jan 14 15:13, Corinna Vinschen wrote:
> >>it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
> >>the 32 bit distro.  Fortunately they were never in the 64 bit distro.
> >>
> >>The problem is that we still have packages requiring libopenssl098.
> >>These need rebuilding or removing.
> >>
> >>The following packages need simple rebuilding:
> >>
> >>  suite3270	Peter A. Castro
> >
> >Peter, any progress?
> 
> Still working on it.  I'm hitting some porting issues while upgrading the
> package suite.

Feel free to discuss them here.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro [gcc bug]

[Ken Brown]

On 1/30/2015 11:40 AM, Ken Brown wrote:
> On 1/30/2015 8:25 AM, Ken Brown wrote:
>> On 1/30/2015 4:41 AM, Corinna Vinschen wrote:
>>> On Jan 29 15:25, Ken Brown wrote:
>>>> I'm attaching the patches that I applied (on top of Reini's patches) in
>>>> order to make the build succeed.  I also had to use libdb4.5 instead of
>>>> libdb4.8.
>>>
>>> Is that ok?  I mean, shouldn't a package always try to use the latest
>>> version?  What's the problem you're observing ?  Maybe Volker can help
>>> here?
>>
>> The clisp-2.48 code uses some macros and structures that are defined in the
>> db4.5 headers but have changed or disappeared in db4.8.  I'll see if I can
>> figure out how to update the code for db4.8.
>
> OK, that wasn't so hard.  I'm attaching the patch that I applied, in case Reini
> or Volker has a chance to look at it.  All 76 tests for the berkeley-db module
> passed.

I've now begun working on the 64-bit build.  I found a few minor things I had to 
change, and the build was pretty far along, when I apparently hit a gcc bug:

gcc -I/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/gllib -ggdb -O2 -pipe 
-Wimplicit-function-declaration -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit 
-Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O 
-falign-functions=4 -DUNICODE -I. 
-I$(/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/clisp -K boot -B 
/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build -N 
/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/locale -E UTF-8 -Epathname 
1:1 -Emisc 1:1 -norc -q -b)/linkkit -c regexi.m.c -o regexi.o
regexi.c: In function ‘C_subr_regexp_regexp_compile’:
regexi.c:56:1: error: unrecognizable insn:
  }
  ^
(insn 348 347 349 41 (set (reg/f:DI 259)
         (plus:DI (symbol_ref:DI ("module__regexp__subr_tab") [flags 0x2] 
<var_decl 0x6fffbfad360 module__regexp__subr_tab>)
             (reg:DI 260))) regexi.c:54 -1
      (expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref:DI 
("module__regexp__subr_tab") [flags 0x2] <var_decl 0x6fffbfad360 
module__regexp__subr_tab>)
                 (const_int 281474976710768 [0x1000000000070])))
         (nil)))
regexi.c:56:1: internal compiler error: in extract_insn, at recog.c:2154
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

This was initially with gcc-4.9.2-1, but the same thing happens with gcc-4.9.2-2 
and gcc-4.8.3-2.

I'll poke around a little and see if I can find a problem in the source file, 
but I may have to just report the gcc bug and put this aside until it's resolved.

Ken

Re: [HEADSUP] Dropping libopenssl098 from distro [gcc bug]

[Corinna Vinschen]

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

On Feb  2 10:46, Ken Brown wrote:
> On 1/30/2015 11:40 AM, Ken Brown wrote:
> >On 1/30/2015 8:25 AM, Ken Brown wrote:
> >>On 1/30/2015 4:41 AM, Corinna Vinschen wrote:
> >>>On Jan 29 15:25, Ken Brown wrote:
> >>>>I'm attaching the patches that I applied (on top of Reini's patches) in
> >>>>order to make the build succeed.  I also had to use libdb4.5 instead of
> >>>>libdb4.8.
> >>>
> >>>Is that ok?  I mean, shouldn't a package always try to use the latest
> >>>version?  What's the problem you're observing ?  Maybe Volker can help
> >>>here?
> >>
> >>The clisp-2.48 code uses some macros and structures that are defined in the
> >>db4.5 headers but have changed or disappeared in db4.8.  I'll see if I can
> >>figure out how to update the code for db4.8.
> >
> >OK, that wasn't so hard.  I'm attaching the patch that I applied, in case Reini
> >or Volker has a chance to look at it.  All 76 tests for the berkeley-db module
> >passed.
> 
> I've now begun working on the 64-bit build.  I found a few minor things I
> had to change, and the build was pretty far along, when I apparently hit a
> gcc bug:
> 
> gcc -I/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/gllib -ggdb -O2
> -pipe -Wimplicit-function-declaration -W -Wswitch -Wcomment -Wpointer-arith
> -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare
> -Wno-format-nonliteral -O -falign-functions=4 -DUNICODE -I.
> -I$(/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/clisp -K boot -B
> /home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build -N
> /home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/locale -E UTF-8
> -Epathname 1:1 -Emisc 1:1 -norc -q -b)/linkkit -c regexi.m.c -o regexi.o
> regexi.c: In function ‘C_subr_regexp_regexp_compile’:
> regexi.c:56:1: error: unrecognizable insn:
>  }
>  ^
> (insn 348 347 349 41 (set (reg/f:DI 259)
>         (plus:DI (symbol_ref:DI ("module__regexp__subr_tab") [flags 0x2]
> <var_decl 0x6fffbfad360 module__regexp__subr_tab>)
>             (reg:DI 260))) regexi.c:54 -1
>      (expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref:DI
> ("module__regexp__subr_tab") [flags 0x2] <var_decl 0x6fffbfad360
> module__regexp__subr_tab>)
>                 (const_int 281474976710768 [0x1000000000070])))
>         (nil)))
> regexi.c:56:1: internal compiler error: in extract_insn, at recog.c:2154
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.

Oh, that's too bad.  I hope somebody from the gcc folks take a look.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro [gcc bug]

[Ken Brown]

On 2/3/2015 4:17 AM, Corinna Vinschen wrote:
> On Feb  2 10:46, Ken Brown wrote:
>> I've now begun working on the 64-bit build.  I found a few minor things I
>> had to change, and the build was pretty far along, when I apparently hit a
>> gcc bug:
[...]
> Oh, that's too bad.  I hope somebody from the gcc folks take a look.

I've submitted the report:

   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939

Ken

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

Peter?

Ping?

On Feb  2 10:16, Corinna Vinschen wrote:
> On Jan 31 13:32, Peter A. Castro wrote:
> > On Mon, 26 Jan 2015, Corinna Vinschen wrote:
> > 
> > >Date: Mon, 26 Jan 2015 21:43:44 +0100
> > >From: Corinna Vinschen
> > >Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
> > >
> > >
> > >Just a quick update on the libopenssl098 frontier:
> > >
> > >
> > >On Jan 14 15:13, Corinna Vinschen wrote:
> > >>it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
> > >>the 32 bit distro.  Fortunately they were never in the 64 bit distro.
> > >>
> > >>The problem is that we still have packages requiring libopenssl098.
> > >>These need rebuilding or removing.
> > >>
> > >>The following packages need simple rebuilding:
> > >>
> > >>  suite3270	Peter A. Castro
> > >
> > >Peter, any progress?
> > 
> > Still working on it.  I'm hitting some porting issues while upgrading the
> > package suite.
> 
> Feel free to discuss them here.

I'll have to update libopenssl098 to 0.9.8zf just for this one
package.  Any chance you could update soon?


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Peter A. Castro]

On Thu, 19 Mar 2015, Corinna Vinschen wrote:

> Date: Thu, 19 Mar 2015 18:12:21 +0100
> From: Corinna Vinschen
> Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
> 
> Peter?
>
> Ping?

Oh Carp!  I forgot about this!  Sorry!!  It's been a very busy two months 
for me.  I'll see if I can complete my port soon.  Again, Sorry!

> On Feb  2 10:16, Corinna Vinschen wrote:
>> On Jan 31 13:32, Peter A. Castro wrote:
>>> On Mon, 26 Jan 2015, Corinna Vinschen wrote:
>>>
>>>> Date: Mon, 26 Jan 2015 21:43:44 +0100
>>>> From: Corinna Vinschen
>>>> Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
>>>>
>>>>
>>>> Just a quick update on the libopenssl098 frontier:
>>>>
>>>>
>>>> On Jan 14 15:13, Corinna Vinschen wrote:
>>>>> it's really *really* overdue to remove the OpenSSL 0.98 DLLs from
>>>>> the 32 bit distro.  Fortunately they were never in the 64 bit distro.
>>>>>
>>>>> The problem is that we still have packages requiring libopenssl098.
>>>>> These need rebuilding or removing.
>>>>>
>>>>> The following packages need simple rebuilding:
>>>>>
>>>>>  suite3270	Peter A. Castro
>>>>
>>>> Peter, any progress?
>>>
>>> Still working on it.  I'm hitting some porting issues while upgrading the
>>> package suite.
>>
>> Feel free to discuss them here.
>
> I'll have to update libopenssl098 to 0.9.8zf just for this one
> package.  Any chance you could update soon?
>
>
> Thanks,
> Corinna
>
>

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

On Mar 19 13:19, Peter A. Castro wrote:
> On Thu, 19 Mar 2015, Corinna Vinschen wrote:
> 
> >Date: Thu, 19 Mar 2015 18:12:21 +0100
> >From: Corinna Vinschen
> >Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
> >
> >Peter?
> >
> >Ping?
> 
> Oh Carp!  I forgot about this!  Sorry!!  It's been a very busy two months
> for me.  I'll see if I can complete my port soon.  Again, Sorry!

No worries.  I just don't want to remove the libopenssl098 package,
finally.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

On Mar 19 22:09, Corinna Vinschen wrote:
> On Mar 19 13:19, Peter A. Castro wrote:
> > On Thu, 19 Mar 2015, Corinna Vinschen wrote:
> > 
> > >Date: Thu, 19 Mar 2015 18:12:21 +0100
> > >From: Corinna Vinschen
> > >Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
> > >
> > >Peter?
> > >
> > >Ping?
> > 
> > Oh Carp!  I forgot about this!  Sorry!!  It's been a very busy two months
> > for me.  I'll see if I can complete my port soon.  Again, Sorry!
> 
> No worries.  I just don't want to remove the libopenssl098 package,
> finally.

Erm... hang on.  I *do* want to remove the libopenssl098 package.

:)
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

Peter?

It's another two weeks :}

On Mar 19 22:19, Corinna Vinschen wrote:
> On Mar 19 22:09, Corinna Vinschen wrote:
> > On Mar 19 13:19, Peter A. Castro wrote:
> > > On Thu, 19 Mar 2015, Corinna Vinschen wrote:
> > > 
> > > >Date: Thu, 19 Mar 2015 18:12:21 +0100
> > > >From: Corinna Vinschen
> > > >Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
> > > >
> > > >Peter?
> > > >
> > > >Ping?
> > > 
> > > Oh Carp!  I forgot about this!  Sorry!!  It's been a very busy two months
> > > for me.  I'll see if I can complete my port soon.  Again, Sorry!
> > 
> > No worries.  I just don't want to remove the libopenssl098 package,
> > finally.
> 
> Erm... hang on.  I *do* want to remove the libopenssl098 package.

Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Peter A. Castro]

On Thu, 2 Apr 2015, Corinna Vinschen wrote:

> Date: Thu, 2 Apr 2015 13:35:23 +0200
> From: Corinna Vinschen
> Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
> 
> Peter?
>
> It's another two weeks :}

Sorry. it's been a very busy 6 months.

Also, the machine I had access to disappeared a month ago and I've been 
scrambling to get another one.  But, I now have a newish Win 7 64bit 
machine available and am doing the porting work for both suite3270 and 
zsh.  Give me until the end of the week and then blast me again if I 
haven't gotten it done.

"This time for sure!  Nothing up my sleeve...." -- Bullwinkle J. Moose.

:)

> On Mar 19 22:19, Corinna Vinschen wrote:
>> On Mar 19 22:09, Corinna Vinschen wrote:
>>> On Mar 19 13:19, Peter A. Castro wrote:
>>>> On Thu, 19 Mar 2015, Corinna Vinschen wrote:
>>>>
>>>>> Date: Thu, 19 Mar 2015 18:12:21 +0100
>>>>> From: Corinna Vinschen
>>>>> Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
>>>>>
>>>>> Peter?
>>>>>
>>>>> Ping?
>>>>
>>>> Oh Carp!  I forgot about this!  Sorry!!  It's been a very busy two months
>>>> for me.  I'll see if I can complete my port soon.  Again, Sorry!
>>>
>>> No worries.  I just don't want to remove the libopenssl098 package,
>>> finally.
>>
>> Erm... hang on.  I *do* want to remove the libopenssl098 package.
>
> Thanks,
> Corinna
>
>

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: [HEADSUP] Dropping libopenssl098 from distro

[Warren Young]

On Apr 20, 2015, at 3:40 PM, Peter A. Castro <doctor@fruitbat.org> wrote:
> 
> the machine I had access to disappeared a month ago and I've been scrambling to get another one.

VirtualBox and the Windows 10 Technical Preview are free, and they run Cygwin just fine.  :)

Re: [HEADSUP] Dropping libopenssl098 from distro

[Peter A. Castro]

On Mon, 20 Apr 2015, Peter A. Castro wrote:

> Date: Mon, 20 Apr 2015 14:40:40 -0700 (PDT)
> From: Peter A. Castro 
> Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
> 
> On Thu, 2 Apr 2015, Corinna Vinschen wrote:
>
>> Date: Thu, 2 Apr 2015 13:35:23 +0200
>> From: Corinna Vinschen
>> Subject: Re: [HEADSUP] Dropping libopenssl098 from distro

Greetings, again, Corinna,
   Just to keep you up to date, I've built newer zsh 32 & 64 and am testing 
both.  I've built newer suite3270 32-bit, including tcl3270 (with the 
"new" tcl packages; had to do a little re-porting due to code 
changes) and am building 64-bit now.  I'll upload all of these this 
saturday after which you can then finally remove libopenssl098.
   Again, sorry for the delay.  It's been a busy year. :)

>> 
>> Peter?
>> 
>> It's another two weeks :}
>
> Sorry. it's been a very busy 6 months.
>
> Also, the machine I had access to disappeared a month ago and I've been 
> scrambling to get another one.  But, I now have a newish Win 7 64bit machine 
> available and am doing the porting work for both suite3270 and zsh.  Give me 
> until the end of the week and then blast me again if I haven't gotten it 
> done.
>
> "This time for sure!  Nothing up my sleeve...." -- Bullwinkle J. Moose.
>
> :)
>
>> On Mar 19 22:19, Corinna Vinschen wrote:
>>> On Mar 19 22:09, Corinna Vinschen wrote:
>>>> On Mar 19 13:19, Peter A. Castro wrote:
>>>>> On Thu, 19 Mar 2015, Corinna Vinschen wrote:
>>>>> 
>>>>>> Date: Thu, 19 Mar 2015 18:12:21 +0100
>>>>>> From: Corinna Vinschen
>>>>>> Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
>>>>>> 
>>>>>> Peter?
>>>>>> 
>>>>>> Ping?
>>>>> 
>>>>> Oh Carp!  I forgot about this!  Sorry!!  It's been a very busy two 
>>>>> months
>>>>> for me.  I'll see if I can complete my port soon.  Again, Sorry!
>>>> 
>>>> No worries.  I just don't want to remove the libopenssl098 package,
>>>> finally.
>>> 
>>> Erm... hang on.  I *do* want to remove the libopenssl098 package.
>> 
>> Thanks,
>> Corinna
>> 
>> 
>
>

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

On Apr 24 07:40, Peter A. Castro wrote:
> On Mon, 20 Apr 2015, Peter A. Castro wrote:
> 
> >Date: Mon, 20 Apr 2015 14:40:40 -0700 (PDT)
> >From: Peter A. Castro Subject: Re: [HEADSUP] Dropping libopenssl098 from
> >distro
> >
> >On Thu, 2 Apr 2015, Corinna Vinschen wrote:
> >
> >>Date: Thu, 2 Apr 2015 13:35:23 +0200
> >>From: Corinna Vinschen
> >>Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
> 
> Greetings, again, Corinna,
>   Just to keep you up to date, I've built newer zsh 32 & 64 and am testing
> both.  I've built newer suite3270 32-bit, including tcl3270 (with the "new"
> tcl packages; had to do a little re-porting due to code changes) and am
> building 64-bit now.  I'll upload all of these this saturday after which you
> can then finally remove libopenssl098.
>   Again, sorry for the delay.  It's been a busy year. :)

No worries.  Thank you.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [HEADSUP] Dropping libopenssl098 from distro

[Peter A. Castro]

On Fri, 24 Apr 2015, Peter A. Castro wrote:

> Date: Fri, 24 Apr 2015 07:40:46 -0700 (PDT)
> From: Peter A. Castro <doctor@fruitbat.org>
> To: cygwin-apps@cygwin.com
> Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
> 
> On Mon, 20 Apr 2015, Peter A. Castro wrote:
>
>> Date: Mon, 20 Apr 2015 14:40:40 -0700 (PDT)
>> From: Peter A. Castro Subject: Re: [HEADSUP] Dropping libopenssl098 from 
>> distro
>> 
>> On Thu, 2 Apr 2015, Corinna Vinschen wrote:
>> 
>>> Date: Thu, 2 Apr 2015 13:35:23 +0200
>>> From: Corinna Vinschen
>>> Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
>
> Greetings, again, Corinna,
>  Just to keep you up to date, I've built newer zsh 32 & 64 and am testing 
> both.  I've built newer suite3270 32-bit, including tcl3270 (with the "new" 
> tcl packages; had to do a little re-porting due to code changes) and am 
> building 64-bit now.  I'll upload all of these this saturday after which you 
> can then finally remove libopenssl098.
>  Again, sorry for the delay.  It's been a busy year. :)

Last update. :)

New packages have been pushed as of last friday and annoucements sent.  I 
believe there are nolonger any dependencies on libopenssl098 (at least 
from me :), so you should be clear to finally remove it.

>>> 
>>> Peter?
>>> 
>>> It's another two weeks :}
>> 
>> Sorry. it's been a very busy 6 months.
>> 
>> Also, the machine I had access to disappeared a month ago and I've been 
>> scrambling to get another one.  But, I now have a newish Win 7 64bit 
>> machine available and am doing the porting work for both suite3270 and zsh. 
>> Give me until the end of the week and then blast me again if I haven't 
>> gotten it done.
>> 
>> "This time for sure!  Nothing up my sleeve...." -- Bullwinkle J. Moose.
>> 
>> :)
>> 
>>> On Mar 19 22:19, Corinna Vinschen wrote:
>>>> On Mar 19 22:09, Corinna Vinschen wrote:
>>>>> On Mar 19 13:19, Peter A. Castro wrote:
>>>>>> On Thu, 19 Mar 2015, Corinna Vinschen wrote:
>>>>>> 
>>>>>>> Date: Thu, 19 Mar 2015 18:12:21 +0100
>>>>>>> From: Corinna Vinschen
>>>>>>> Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
>>>>>>> 
>>>>>>> Peter?
>>>>>>> 
>>>>>>> Ping?
>>>>>> 
>>>>>> Oh Carp!  I forgot about this!  Sorry!!  It's been a very busy two 
>>>>>> months
>>>>>> for me.  I'll see if I can complete my port soon.  Again, Sorry!
>>>>> 
>>>>> No worries.  I just don't want to remove the libopenssl098 package,
>>>>> finally.
>>>> 
>>>> Erm... hang on.  I *do* want to remove the libopenssl098 package.
>>> 
>>> Thanks,
>>> Corinna
>>> 
>>> 
>> 
>> 
>
>

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: [HEADSUP] Dropping libopenssl098 from distro

[Peter A. Castro]

On Fri, 24 Apr 2015, Peter A. Castro wrote:

> Date: Fri, 24 Apr 2015 07:40:46 -0700 (PDT)
> From: Peter A. Castro
> Subject: Re: [HEADSUP] Dropping libopenssl098 from distro

Ugh...resending since I forgot to remove the email addresses from the 
quoted header and expect that email to be bounce, but if not, my apologies 
in advance for a repeat message. :)

(gotta find a Reply filter that removes email addresses :)

> On Mon, 20 Apr 2015, Peter A. Castro wrote:
>
>> Date: Mon, 20 Apr 2015 14:40:40 -0700 (PDT)
>> From: Peter A. Castro Subject: Re: [HEADSUP] Dropping libopenssl098 from 
>> distro
>> 
>> On Thu, 2 Apr 2015, Corinna Vinschen wrote:
>> 
>>> Date: Thu, 2 Apr 2015 13:35:23 +0200
>>> From: Corinna Vinschen
>>> Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
>
> Greetings, again, Corinna,
>  Just to keep you up to date, I've built newer zsh 32 & 64 and am testing 
> both.  I've built newer suite3270 32-bit, including tcl3270 (with the "new" 
> tcl packages; had to do a little re-porting due to code changes) and am 
> building 64-bit now.  I'll upload all of these this saturday after which you 
> can then finally remove libopenssl098.
>  Again, sorry for the delay.  It's been a busy year. :)

Last update. :)

New packages have been pushed as of last friday and annoucements sent.  I
believe there are nolonger any dependencies on libopenssl098 (at least
from me :), so you should be clear to finally remove it.

>>> 
>>> Peter?
>>> 
>>> It's another two weeks :}
>> 
>> Sorry. it's been a very busy 6 months.
>> 
>> Also, the machine I had access to disappeared a month ago and I've been 
>> scrambling to get another one.  But, I now have a newish Win 7 64bit 
>> machine available and am doing the porting work for both suite3270 and zsh. 
>> Give me until the end of the week and then blast me again if I haven't 
>> gotten it done.
>> 
>> "This time for sure!  Nothing up my sleeve...." -- Bullwinkle J. Moose.
>> 
>> :)
>> 
>>> On Mar 19 22:19, Corinna Vinschen wrote:
>>>> On Mar 19 22:09, Corinna Vinschen wrote:
>>>>> On Mar 19 13:19, Peter A. Castro wrote:
>>>>>> On Thu, 19 Mar 2015, Corinna Vinschen wrote:
>>>>>> 
>>>>>>> Date: Thu, 19 Mar 2015 18:12:21 +0100
>>>>>>> From: Corinna Vinschen
>>>>>>> Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
>>>>>>> 
>>>>>>> Peter?
>>>>>>> 
>>>>>>> Ping?
>>>>>> 
>>>>>> Oh Carp!  I forgot about this!  Sorry!!  It's been a very busy two 
>>>>>> months
>>>>>> for me.  I'll see if I can complete my port soon.  Again, Sorry!
>>>>> 
>>>>> No worries.  I just don't want to remove the libopenssl098 package,
>>>>> finally.
>>>> 
>>>> Erm... hang on.  I *do* want to remove the libopenssl098 package.
>>> 
>>> Thanks,
>>> Corinna
>>> 
>>> 
>> 
>> 
>
>

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: [HEADSUP] Dropping libopenssl098 from distro

[Corinna Vinschen]

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

On Apr 27 12:47, Peter A. Castro wrote:
> On Fri, 24 Apr 2015, Peter A. Castro wrote:
> 
> >Date: Fri, 24 Apr 2015 07:40:46 -0700 (PDT)
> >From: Peter A. Castro
> >Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
> 
> Ugh...resending since I forgot to remove the email addresses from the quoted
> header and expect that email to be bounce, but if not, my apologies in
> advance for a repeat message. :)
> 
> (gotta find a Reply filter that removes email addresses :)
> 
> >On Mon, 20 Apr 2015, Peter A. Castro wrote:
> >
> >>Date: Mon, 20 Apr 2015 14:40:40 -0700 (PDT)
> >>From: Peter A. Castro Subject: Re: [HEADSUP] Dropping libopenssl098 from
> >>distro
> >>
> >>On Thu, 2 Apr 2015, Corinna Vinschen wrote:
> >>
> >>>Date: Thu, 2 Apr 2015 13:35:23 +0200
> >>>From: Corinna Vinschen
> >>>Subject: Re: [HEADSUP] Dropping libopenssl098 from distro
> >
> >Greetings, again, Corinna,
> > Just to keep you up to date, I've built newer zsh 32 & 64 and am testing
> >both.  I've built newer suite3270 32-bit, including tcl3270 (with the
> >"new" tcl packages; had to do a little re-porting due to code changes) and
> >am building 64-bit now.  I'll upload all of these this saturday after
> >which you can then finally remove libopenssl098.
> > Again, sorry for the delay.  It's been a busy year. :)
> 
> Last update. :)
> 
> New packages have been pushed as of last friday and annoucements sent.  I
> believe there are nolonger any dependencies on libopenssl098 (at least
> from me :), so you should be clear to finally remove it.

Thank you!


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]