Re: [ITA] libsigc2.0, [ITP] libsigc3.0

[Yaakov Selkowitz]

On Thu, 2020-05-14 at 17:14 -0400, Ken Brown via Cygwin-apps wrote:
> cygport files attached.  I've updated libsigc2.0 to the latest release in the 
> 2.0 series, and I've created libsigc3.0 as a new package, as Fedora does.  
> Note: 
> If you want to do a test build of the latter, you'll need to install the 
> updated 
> mm-common from the previous ITA.

These look fine.  Just curious, were you planning on doing the entire
(or some part of) GTKmm stack?

--
Yaakov

Re: [ITA] mm-common

[Yaakov Selkowitz]

On Thu, 2020-05-14 at 14:57 -0400, Ken Brown via Cygwin-apps wrote:
> cygport file attached.  I bumped the version to the latest upstream release, 
> and 
> I removed the custom src_compile, since the default src_compile now works 
> (and 
> the custom one doesn't, since the tarball no longer includes a configure 
> script).

This is fine, go ahead.

--
Yaakov

Re: [ITA] libpng

[Yaakov Selkowitz]

On Thu, 2020-05-14 at 11:17 -0400, Ken Brown via Cygwin-apps wrote:
> Builds fine from Yaakov's cygport file, no update needed at present.

Go ahead.

--
Yaakov

Re: cygport development

[Yaakov Selkowitz]

On Tue, 2020-05-12 at 16:59 +0200, Federico Kircheis wrote:
> On 10/14/19 10:55 AM, Federico Kircheis wrote:
> > On 13/10/2019 18.41, Achim Gratz wrote:
> > > Federico Kircheis writes:
> > > > I've sent the patches the 14.07.19, unfortunately I still got no answer.
> > > 
> > > The cygport maintainer is rather busy with non-Cygwin related work these
> > > days, I suppose.  Anyway, one of the questions I have is why you need
> > > these changes.  Most build systems do not actually work when they
> > > encounter a path with spaces if they use make under the hood, so fixing
> > > cygport to grok such path locations isn't getting you much further I'd
> > > think.  Can you explain?
> > 
> > Yep.
> > 
> > I've built some software in my windows home directory.
> > It contains a space.
> > I expected it to work.
> > 
> > Instead of failing with a clear error message, the build process deleted 
> > some unrelated files as it cd failed (or cd in the wrong directory, cant 
> > remember right now).
> > 
> > I believe it is unacceptable to delete unrelated data.
> > 
> > Even if it stated that there is no intention to support path with 
> > spaces, those scripts should fail fast and ideally with a clear error 
> > message.
> > 
> > I found it easier to quote the offending variables, as not only spaces 
> > might cause issues.
> 
> The merge request in the repository has been closed.
> 
> I'm attaching the updated patch.

This patch is clearly not limited to the protection of data, as it
quotes variables that could in no way contain a space or have anything
to do with file paths.  As mentioned multiple times, using filenames
ore directories with spaces is asking for trouble, and I have no
interest in trying to support such a case.  I'm willing to consider a
*limited* patch that makes sure that cygport doesn't do something it
shouldn't in that case, but that's about it.

--
Yaakov 

Re: [ITA] libsigc2.0, [ITP] libsigc3.0

[Marco Atzeri via Cygwin-apps]

Am 14.05.2020 um 23:14 schrieb Ken Brown via Cygwin-apps:
cygport files attached.  I've updated libsigc2.0 to the latest release 
in the 2.0 series, and I've created libsigc3.0 as a new package, as 
Fedora does.  Note: If you want to do a test build of the latter, you'll 
need to install the updated mm-common from the previous ITA.


Ken


changed maintainer and added 3.0

Re: [ITA] mm-common

[Marco Atzeri via Cygwin-apps]

Am 14.05.2020 um 20:57 schrieb Ken Brown via Cygwin-apps:
cygport file attached.  I bumped the version to the latest upstream 
release, and I removed the custom src_compile, since the default 
src_compile now works (and the custom one doesn't, since the tarball no 
longer includes a configure script).


Ken


changed maintainer

Re: Trying to build OCRmyPDF under Cygwin, hit a brick wall

[Marco Atzeri via Cygwin]

Am 15.05.2020 um 00:50 schrieb Jim Garrison via Cygwin:

The magic incantation necessary to get strdup turns out to be -
D_GNU_SOURCE, as noted on StackOverflow.

However, now I'm encountering a problem with Python's DLL handling
code.  When attempting to run OCRmyPDF I get



$ ocrmypdf --help
Traceback (most recent call last):
   File "/usr/bin/ocrmypdf", line 11, in 
 load_entry_point('ocrmypdf==9.8.0.post3+g5944044.d20200514',
'console_scripts', 'ocrmypdf')()
   File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py",
line 489, in load_entry_point
 return get_distribution(dist).load_entry_point(group, name)
   File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py",
line 2852, in load_entry_point
 return ep.load()
   File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py",
line 2443, in load
 return self.resolve()
   File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py",
line 2449, in resolve
 module = __import__(self.module_name, fromlist=['__name__'], level=0)
   File
"/usr/lib/python3.7/site-packages/ocrmypdf-9.8.0.post3+g5944044.d20200514-py3.7.egg/ocrmypdf/__init__.py",
line 18, in 
 from . import helpers, hocrtransform, leptonica, pdfa, pdfinfo
   File
"/usr/lib/python3.7/site-packages/ocrmypdf-9.8.0.post3+g5944044.d20200514-py3.7.egg/ocrmypdf/leptonica.py",
line 67, in 
 """
ocrmypdf.exceptions.MissingDependencyError:

-
 This error normally occurs when ocrmypdf can't find the Leptonica
 library, which is usually installed with Tesseract OCR. It could
be that
 Tesseract is not installed properly, we can't find the installation
 on your system PATH environment variable.

 The library we are looking for is usually called:
 liblept-5.dll   (Windows)
 liblept*.dylib  (macOS)
 liblept*.so (Linux/BSD)

 Please review our installation procedures to find a solution:
 https://ocrmypdf.readthedocs.io/en/latest/installation.html

-


In the last file of the traceback (leptonica.py) there's this:


from ctypes.util import find_library
...
if os.name == 'nt':
 libname = 'liblept-5'
 os.environ['PATH'] = shim_paths_with_program_files()
else:
 libname = 'lept'


In Cygwin, that library is /usr/bin/cyglept-5.dll (why was the name
changed?)


standard on Cygwin to differentiate from mingw build
https://cygwin.com/cygwin-ug-net/dll.html


First I created a symlink from cyglept-5.dll to liblept-5.dll, with no
effect. So I added a test for Cygwin at that point, resulting in this
code:


if os.name == 'nt':
 libname = 'liblept-5'
 os.environ['PATH'] = shim_paths_with_program_files()
elif sys.platform == 'cygwin':
 libname = 'cyglept-5'
else:
 libname = 'lept'


This also had no effect, so I tried playing with find_library() in the
interactive shell.  In Cygwin, it doesn't seem to find any DLLs even
though those DLLs are actually loadable.  Viz:


$ python3
Python 3.7.7 (default, Apr 10 2020, 07:59:19)
[GCC 9.3.0] on cygwin
Type "help", "copyright", "credits" or "license" for more information.

import os
import sys
from ctypes import *
from ctypes.util import find_library
find_library('cyglept-5') or 'Not found'

'Not found'

find_library('cyglept-5.dll') or 'Not Found'

'Not Found'

cdll.LoadLibrary('cyglept-5.dll') or 'Not Found'




So it appears to me that possibly find_library() is broken because
it doesn't find the library, but yet Python can actually load the
library.

What am I missing?



where are you looking for ?
Have you installed libleptonica_5 and libleptonica-devel ?


$ cygcheck -cd |grep lept
leptonica   1.79.0-1
libleptonica-devel  1.79.0-1
libleptonica_5  1.79.0-1




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

Re: Trying to build OCRmyPDF under Cygwin, hit a brick wall

[René Berber via Cygwin]

On 5/14/2020 5:50 PM, Jim Garrison via Cygwin wrote:


The magic incantation necessary to get strdup turns out to be -
D_GNU_SOURCE, as noted on StackOverflow.

However, now I'm encountering a problem with Python's DLL handling
code.  When attempting to run OCRmyPDF I get

[snip]

line 18, in 
 from . import helpers, hocrtransform, leptonica, pdfa, pdfinfo
   File
"/usr/lib/python3.7/site-packages/ocrmypdf-9.8.0.post3+g5944044.d20200514-py3.7.egg/ocrmypdf/leptonica.py",
line 67, in 
 """
ocrmypdf.exceptions.MissingDependencyError:

[snip]


In the last file of the traceback (leptonica.py) there's this:


from ctypes.util import find_library
...
if os.name == 'nt':
 libname = 'liblept-5'
 os.environ['PATH'] = shim_paths_with_program_files()
else:
 libname = 'lept'


In Cygwin, that library is /usr/bin/cyglept-5.dll (why was the name
changed?)

First I created a symlink from cyglept-5.dll to liblept-5.dll, with no
effect. So I added a test for Cygwin at that point, resulting in this
code:


if os.name == 'nt':
 libname = 'liblept-5'
 os.environ['PATH'] = shim_paths_with_program_files()


Notice this change in search path, dll files in Windows are executables 
and they are (must) installed in the system PATH (or the current directory).



elif sys.platform == 'cygwin':
 libname = 'cyglept-5'


On Cygwin you can do the same as above, it will contain /bin (or 
/usr/bin which are one and the same).



else:
 libname = 'lept'


This also had no effect, so I tried playing with find_library() in the
interactive shell.  In Cygwin, it doesn't seem to find any DLLs even
though those DLLs are actually loadable.  Viz:

[snip]

My guess is the search path is incorrect.

Either that or python needs the symbols file, like the linker, which in 
this case would be /usr/lib/liblept.dll.a, which is in the -devel 
package, but I doubt it.

--
R.Berber


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

Re: Console doesn't work correctly under anything else than cmd or mintty

[Takashi Yano via Cygwin]

On Thu, 14 May 2020 19:48:59 +0200
Kacper Michajlow wrote:
> On Thu, 14 May 2020 at 05:33, Takashi Yano  wrote:
> 
> > I guess setting
> > stty erase '^?'
> > on the host  resolves this problem.
> >
> 
> Nope, it still doesn't work. And '^?' default so it doesn't change
> anything. Please note that in bash Backspace works fine, but in read
> command (or any other program that ask input from stdin) it fails.

Please check the result of
xxd
Ctrl-V Backspace Enter Ctrl-D

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

Re: [ITA from Yaakov] python-wx

[Yaakov Selkowitz]

On Thu, 2020-05-14 at 11:02 +0100, Hamish McIntyre-Bhatty wrote:
> Apologies for bumping this again, I'm just waiting for this to be done
> before I start on wxPython 4, which is blocking progress for me doing
> other things. If you're not interested in this fix, just let me know
> and I'll move on to wxPython 4.
> 
> I have re-built the packages using your new cygport as the starting
> point, and it seems to work really well. I made some minor modifications
> to include the license files and the new patches from Fedora. The new
> files are available at https://www.hamishmb.com/files/cygwin-temp/ and I
> have removed the previous attempt's files.

This looks fine.

> Seeing as I have no need to rebuild wxWidgets, I guess that can stay
> under your maintainership until an update is needed, at which point
> I'll be happy to pick it up.

Let's discuss it then.

--
Yaakov

Re: Trying to build OCRmyPDF under Cygwin, hit a brick wall

[Jim Garrison via Cygwin]

The magic incantation necessary to get strdup turns out to be -
D_GNU_SOURCE, as noted on StackOverflow.

However, now I'm encountering a problem with Python's DLL handling
code.  When attempting to run OCRmyPDF I get



$ ocrmypdf --help
Traceback (most recent call last):
  File "/usr/bin/ocrmypdf", line 11, in 
load_entry_point('ocrmypdf==9.8.0.post3+g5944044.d20200514',
'console_scripts', 'ocrmypdf')()
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py",
line 489, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py",
line 2852, in load_entry_point
return ep.load()
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py",
line 2443, in load
return self.resolve()
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py",
line 2449, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File
"/usr/lib/python3.7/site-packages/ocrmypdf-9.8.0.post3+g5944044.d20200514-py3.7.egg/ocrmypdf/__init__.py",
line 18, in 
from . import helpers, hocrtransform, leptonica, pdfa, pdfinfo
  File
"/usr/lib/python3.7/site-packages/ocrmypdf-9.8.0.post3+g5944044.d20200514-py3.7.egg/ocrmypdf/leptonica.py",
line 67, in 
"""
ocrmypdf.exceptions.MissingDependencyError:

-
This error normally occurs when ocrmypdf can't find the Leptonica
library, which is usually installed with Tesseract OCR. It could
be that
Tesseract is not installed properly, we can't find the installation
on your system PATH environment variable.

The library we are looking for is usually called:
liblept-5.dll   (Windows)
liblept*.dylib  (macOS)
liblept*.so (Linux/BSD)

Please review our installation procedures to find a solution:
https://ocrmypdf.readthedocs.io/en/latest/installation.html

-


In the last file of the traceback (leptonica.py) there's this:


from ctypes.util import find_library
...
if os.name == 'nt':
libname = 'liblept-5'
os.environ['PATH'] = shim_paths_with_program_files()
else:
libname = 'lept'


In Cygwin, that library is /usr/bin/cyglept-5.dll (why was the name
changed?)

First I created a symlink from cyglept-5.dll to liblept-5.dll, with no
effect. So I added a test for Cygwin at that point, resulting in this
code:


if os.name == 'nt':
libname = 'liblept-5'
os.environ['PATH'] = shim_paths_with_program_files()
elif sys.platform == 'cygwin':
libname = 'cyglept-5'
else:
libname = 'lept'


This also had no effect, so I tried playing with find_library() in the
interactive shell.  In Cygwin, it doesn't seem to find any DLLs even
though those DLLs are actually loadable.  Viz:


$ python3
Python 3.7.7 (default, Apr 10 2020, 07:59:19)
[GCC 9.3.0] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import sys
>>> from ctypes import *
>>> from ctypes.util import find_library
>>> find_library('cyglept-5') or 'Not found'
'Not found'
>>> find_library('cyglept-5.dll') or 'Not Found'
'Not Found'
>>> cdll.LoadLibrary('cyglept-5.dll') or 'Not Found'



So it appears to me that possibly find_library() is broken because
it doesn't find the library, but yet Python can actually load the
library.

What am I missing?


-- 
Jim Garrison j...@acm.org
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[ITA] libsigc2.0, [ITP] libsigc3.0

[Ken Brown via Cygwin-apps]

cygport files attached.  I've updated libsigc2.0 to the latest release in the 
2.0 series, and I've created libsigc3.0 as a new package, as Fedora does.  Note: 
If you want to do a test build of the latter, you'll need to install the updated 
mm-common from the previous ITA.


Ken
ORIG_PN="libsigc++"
inherit gtkmm

NAME="libsigc2.0"
VERSION=2.10.3
RELEASE=1
CATEGORY="Libs"
SUMMARY="C++ typesafe callback library"
DESCRIPTION="libsigc++ implements a typesafe callback system for standard C++.
It allows you to define signals and to connect those signals to any callback
function, either global or a member function, regardless of whether it is
static or virtual."
HOMEPAGE="https://libsigcplusplus.github.io/libsigcplusplus/;

PKG_NAMES="${NAME}_0 ${NAME}-devel ${NAME}-doc"
libsigc2_0_0_CONTENTS="usr/bin/*-2.0-0.dll usr/share/doc/${NAME}/"
libsigc2_0_devel_CONTENTS='usr/include/ usr/lib/'
libsigc2_0_doc_CONTENTS='usr/share/devhelp/ usr/share/doc/libsigc++-2.0/'

BUILD_REQUIRES="mm-common"
ORIG_PN="libsigc++"
inherit gtkmm

NAME="libsigc3.0"
VERSION=3.0.3
RELEASE=1
CATEGORY="Libs"
SUMMARY="C++ typesafe callback library"
DESCRIPTION="libsigc++ implements a typesafe callback system for standard C++.
It allows you to define signals and to connect those signals to any callback
function, either global or a member function, regardless of whether it is
static or virtual."
HOMEPAGE="https://libsigcplusplus.github.io/libsigcplusplus/;

PKG_NAMES="${NAME}_0 ${NAME}-devel ${NAME}-doc"
libsigc3_0_0_CONTENTS="usr/bin/*-3.0-0.dll usr/share/doc/${NAME}/"
libsigc3_0_devel_CONTENTS='usr/include/ usr/lib/'
libsigc3_0_doc_CONTENTS='usr/share/devhelp/ usr/share/doc/libsigc++-3.0/'

BUILD_REQUIRES="mm-common"

Trying to build OCRmyPDF under Cygwin, hit a brick wall

[Jim Garrison via Cygwin]

I'm trying to build OCRmyPDF under Cygwin and have run into a brick
wall. While I've been a developer my entire career, I've worked mostly
in Java and have little knowledge of Python internals and C++. The
problem might be obvious to an expert in these areas but I'm stumped.

OCRmyPDF on Linux installs as a set of "wheel" packages. I gather a
wheel is a pre-built bundle of dependencies. For some reason, under
Cygwin the pip installer believes it cannot use the wheel bundles and
wants to rebuild from source. The problem occurs when trying to rebuild
the pikepdf package.

This post is preliminary. Including the error message here would be
hard to read as it contains very long lines that will wrap and
alignment will be messed up.  I've posted the question to StackOverflow
at https://stackoverflow.com/q/61803714/18157 where I can use markdown
to make it much more readable.

Is it OK to ask here for any interested party to look at the SO post?
If not, I apologize, and I will post the question in its entirety
here.

Thanks

-- 
Jim Garrison j...@acm.org
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[ITA] mm-common

[Ken Brown via Cygwin-apps]

cygport file attached.  I bumped the version to the latest upstream release, and 
I removed the custom src_compile, since the default src_compile now works (and 
the custom one doesn't, since the tarball no longer includes a configure script).


Ken
inherit gnome.org

NAME="mm-common"
VERSION=1.0.0
RELEASE=1
CATEGORY="Devel"
SUMMARY="GNOME C++ bindings build infrastructure"
DESCRIPTION="The mm-common module provides the build infrastructure and
utilities shared among the GNOME C++ binding libraries."

ARCH=noarch

CYGPORT_USE_UNSTABLE_API=1
src_unpack_hook() {
NOCONFIGURE=1 ./autogen.sh
}

src_compile() {
cd ${B}
cygconf
cygmake
}

Re: Console doesn't work correctly under anything else than cmd or mintty

[Kacper Michajlow via Cygwin]

On Thu, 14 May 2020 at 05:33, Takashi Yano  wrote:

> I guess setting
> stty erase '^?'
> on the host  resolves this problem.
>

Nope, it still doesn't work. And '^?' default so it doesn't change
anything. Please note that in bash Backspace works fine, but in read
command (or any other program that ask input from stdin) it fails.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

poppler 0.88.0-1, poppler-data 0.4.9-1

[Ken Brown via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* poppler-0.88.0-1
* libpoppler99-0.88.0-1
* libpoppler-devel-0.88.0-1
* libpoppler-cpp0-0.88.0-1
* libpoppler-cpp-devel-0.88.0-1
* libpoppler-glib8-0.88.0-1
* libpoppler-glib-devel-0.88.0-1
* libpoppler-glib-doc-0.88.0-1
* girepository-Poppler0.18-0.88.0-1
* libpoppler-qt5_1-0.88.0-1
* libpoppler-qt5-devel-0.88.0-1
* poppler-data-0.4.9-1
* poppler-data-devel-0.4.9-1

Poppler is a fork of the xpdf PDF viewer which provides PDF rendering
functionality as a shared library and replaces built-in code with
dependencies that are now available as standard components of modern
Unix desktop environments.

This is an update to the latest upstream release.

Ken Brown
Cygwin's poppler maintainer

[ANNOUNCEMENT] poppler 0.88.0-1, poppler-data 0.4.9-1

[Ken Brown via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* poppler-0.88.0-1
* libpoppler99-0.88.0-1
* libpoppler-devel-0.88.0-1
* libpoppler-cpp0-0.88.0-1
* libpoppler-cpp-devel-0.88.0-1
* libpoppler-glib8-0.88.0-1
* libpoppler-glib-devel-0.88.0-1
* libpoppler-glib-doc-0.88.0-1
* girepository-Poppler0.18-0.88.0-1
* libpoppler-qt5_1-0.88.0-1
* libpoppler-qt5-devel-0.88.0-1
* poppler-data-0.4.9-1
* poppler-data-devel-0.4.9-1

Poppler is a fork of the xpdf PDF viewer which provides PDF rendering
functionality as a shared library and replaces built-in code with
dependencies that are now available as standard components of modern
Unix desktop environments.

This is an update to the latest upstream release.

Ken Brown
Cygwin's poppler maintainer
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Fwd: Re: [ITA] libpng

[Marco Atzeri via Cygwin-apps]

to the right mailing list

 Weitergeleitete Nachricht 


Am 14.05.2020 um 17:17 schrieb Ken Brown via Cygwin-apps:

Builds fine from Yaakov's cygport file, no update needed at present.

Ken


updated maintainer

python-wx: new maintainer Key

[Marco Atzeri via Cygwin-apps]

On 14/05/2020 18:06, Marco Atzeri via Cygwin-apps wrote:

Am 14.05.2020 um 18:51 schrieb Hamish McIntyre-Bhatty:

On 14/05/2020 16:41, Marco Atzeri via Cygwin-apps wrote:

question: do you take both or only wxWidgets3.0  ?

python-wx    Yaakov Selkowitz
wxWidgets3.0 Yaakov Selkowitz

Regards
Marco



I think I'd take only python-wx until wxWidgets3.0 needs a rebuild -
currently wxWidgets3.0 doesn't seem to have any problems. I could have a
look and see if Fedora has any new patches for it, but AFAIK it's
working fine so perhaps just best left alone.

Hamish



python-wx is your.

please provide your SSH Key as mentioned

https://cygwin.com/packaging/key.html#sshkey


Cheers, I have provided the key. How do I know if I did it correctly?

Hamish
-
Forwarding Hamish's key submissions

It seems the mailing list has problem with the default reply-to.
I am manually overriding the current behaviour, but clearly I am not the 
only one impacted.










0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: PGP signature

SSH key for Hamish McIntyre-Bhatty

[Hamish McIntyre-Bhatty via Cygwin-apps]

Name: Hamish McIntyre-Bhatty

 BEGIN SSH2 PUBLIC KEY 
Comment: "8192-bit RSA, converted by hamish@hamish-HP-bw024na from Ope"
B3NzaC1yc2EDAQABAAAEAQDbP8s1z+JIpAtj8E+Xzy3YlGZxXVLMuGb8YLy1XF
gISiZFIChQFzRCRDDHLb7KvuFThlA0YqQdz8yJcW1Ko+2DYx1pPKtBq3mD2WZ9kU0pp8mP
fPg6YOqC0BZX7J0DQ3EqqkymHsygUjpH5lFnHj/Hi02B5hoN3/5BuNAIMNYO+oEhEkEjGF
HErAKDCOWSziu/wEf/XdQpqc+Zh9gn9HuOsMPxLFwLt3MtiAdkZHwTf1Sb5fZUHHet7e41
yFy2BIg04SKY7Sx6HGd+vJb1HwKRyURbitxe5ZZng14qOxI0cAf2c8J8bZmqdcRK5MO0OZ
AYBFeSUhZLTU+O+5js+K+O9vlCPSvRokqm3/gZltf7dYp/YgMO/N9FF0uoVELxrlF0KEMw
mDakIYJ+eEi4qWx5wQrSYyVKGmnUMAQ1sLulEkvMFmx8wVZWqqJrQXJR+TVGmm+XmmW5e9
HWFcHwzQfTD5uQ1AOudIQ0JB1HkmtXXijrrBa9z7hY6D1Zet7hZ1Fu92G7NmSiDf4Uraxr
dul5ragwmzd6AmHwpCl758JgRR34wNsuF3bX3Mdr2cbgNa4peQACxnx62C8hMT2bGhpSrm
3TCJIaRGUvZQ6yFiGoWRde68aGtwj0FGQccOTyopeNVDXzoqBqcbtnFieyzSj/q6QEOnq9
81vMntdqgnvgSESIeaW2Lldu1zCdLGGPZJMlAquiL5+8c7ajda9HJ17eC0eStkUN/RpTqu
Wnvq8ME6DfEMYxMEilnfawN2U3GOqkUd17dpVotQfeOZQrgbizsLFaH9c5HN8pptiKKG4u
zKyJCixP3a0O1EEhisf16DdMKLW/8I1AfxEG8hCouP3wHP6dpRH8zrAOfMRggHc0M/7GKt
WUL64/jADrXb6A5R7Tmjt5IWb7ts1O3MFVoBnSFDDs75mI/7jneETCuNNuO/cmzYzwKc/n
KepXrsw5pZtyc9cBODOmcX5M39hAssJdS1Wzk2Ym5DLyO3c3RNXhx2W2lb68y4vTz4doOt
SZVGxOPnnjvLLpynBhe5ZPhis+0DOr04taNJw4cRrE4W8WyUHbAXIfkRmutwZ5ROuObbaw
7lDXfzLkZi/O7b5L3eXHHL04fQC0bPpsjUwoR3w/ssPfBEjU0eu2wvn/1xkZbmoOcawKK+
lRucWZaI3XLyg8JiyWoWkQ01fFtNpgPNR2jZ9IllYbixpvwziXYgV54FWl/9Utwpyyw221
uaSq+gLnJ2ynnnT8cbQtqJrTEQL0jb4XhL+6emPnE3D+XzvD0ZmE3d7gQJv7I2Us4nS10/
C4NbaGMEHISk5gevImvH8B9J+58+piIzcccUNMbXmmwrjjBtCgzf2xSOQ9O0YklXJr
 END SSH2 PUBLIC KEY 



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: [ITA] libpng

[Marco Atzeri via Cygwin]

Am 14.05.2020 um 17:17 schrieb Ken Brown via Cygwin-apps:

Builds fine from Yaakov's cygport file, no update needed at present.

Ken


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

Re: www.cygwin.com DNS setup

[Jon Turney]

On 14/05/2020 16:54, Chad Kimes via Cygwin wrote:

Hi all,

I'm investigating an issue with GitHub Actions runners having issues
connecting to www.cygwin.com:
https://github.com/actions/virtual-environments/issues/698

I worked with the Azure DNS team and in this comment

I
detail what we believe to be the likely issue. Summarized:

www.cygwin.com is CNAME'd to server2.sourceware.org
server2.sourceware.org is an NS server for sourceware.org

We believe that the above configuration is triggering a bug in WinDNS that
is causing intermittent DNS resolution failures. I don't have an ETA for
resolution from the Azure DNS team, and internally I'm translating that to
be on the order of months before we see a fix. In order to resolve this
faster for customers, I'm reaching out to see what options we have for
updating the DNS records that are triggering this bug.

Is there a change you can make to either www.cygwin.com or
server2.sourceware.org DNS such that it doesn't have this recursive
reference issue? Some options are to replace the CNAME with an A record, or
to use something like ns2.sourceware.org for the NS record instead of
server2.sourceware.org which is being used for cygwin's A record reference.


I have drawn the attention of sourceware overseers to this.

They have requested the DNS change you suggest.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: patch command incorrectly capitalizes filenames that live on external USB flash drives

[ASSI]

Jason Gross via Cygwin writes:
> Also btw, the bug I reported to patch is at
> https://lists.gnu.org/archive/html/bug-patch/2020-05/msg0.html .
> It's not clear to me if this is a cygwin issue or a patch issue.

FWIW, I've just dug out a FAT formatted USB stick and I can't reproduce
your issue.  Again, you may not be using Cygwin's patch at all or have
some other things in the environment that need to compound to produce
this result.


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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

www.cygwin.com DNS setup

[Chad Kimes via Cygwin]

Hi all,

I'm investigating an issue with GitHub Actions runners having issues
connecting to www.cygwin.com:
https://github.com/actions/virtual-environments/issues/698

I worked with the Azure DNS team and in this comment

I
detail what we believe to be the likely issue. Summarized:

www.cygwin.com is CNAME'd to server2.sourceware.org
server2.sourceware.org is an NS server for sourceware.org

We believe that the above configuration is triggering a bug in WinDNS that
is causing intermittent DNS resolution failures. I don't have an ETA for
resolution from the Azure DNS team, and internally I'm translating that to
be on the order of months before we see a fix. In order to resolve this
faster for customers, I'm reaching out to see what options we have for
updating the DNS records that are triggering this bug.

Is there a change you can make to either www.cygwin.com or
server2.sourceware.org DNS such that it doesn't have this recursive
reference issue? Some options are to replace the CNAME with an A record, or
to use something like ns2.sourceware.org for the NS record instead of
server2.sourceware.org which is being used for cygwin's A record reference.

Thanks,
-Chad
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [ITA] poppler, poppler-data

[Marco Atzeri via Cygwin-apps]

Am 14.05.2020 um 16:54 schrieb Ken Brown via Cygwin-apps:
cygport files attached.  In both cases these are routine updates to the 
latest upstream release.  For poppler, I also updated the Fedora patches 
to those that are used in the latest Fedora release (but I ignored the 
patches that are for qt4, since the Cygwin build uses qt5).


Ken


both yours

Regards
Marco

Re: [ITA from Yaakov] python-wx

[Marco Atzeri via Cygwin-apps]

Am 14.05.2020 um 12:02 schrieb Hamish McIntyre-Bhatty via Cygwin-apps:

Apologies for bumping this again, I'm just waiting for this to be done
before I start on wxPython 4, which is blocking progress for me doing
other things. If you're not interested in this fix, just let me know
and I'll move on to wxPython 4.

I have re-built the packages using your new cygport as the starting
point, and it seems to work really well. I made some minor modifications
to include the license files and the new patches from Fedora. The new
files are available at https://www.hamishmb.com/files/cygwin-temp/ and I
have removed the previous attempt's files.

Seeing as I have no need to rebuild wxWidgets, I guess that can stay
under your maintainership until an update is needed, at which point
I'll be happy to pick it up.

Hamish



question: do you take both or only wxWidgets3.0  ?

python-wxYaakov Selkowitz
wxWidgets3.0 Yaakov Selkowitz

Regards
Marco

Re: [ITA] python2-wx and related packages for wxPython and wxwidgets

[Marco Atzeri via Cygwin-apps]

Am 23.04.2020 um 20:52 schrieb Yaakov Selkowitz:

On Thu, 2020-04-23 at 18:09 +0100, Hamish McIntyre-Bhatty wrote:

On 23/04/2020 17:08, Yaakov Selkowitz wrote:

Please keep all discussion on list.





Fair enough.  python-sip will need to be updated for that as well,
which requires also updating python-pyqt5* in sync therewith, so this
will need to be coordinated.

--
Yaakov



sorry for missing this point

I will look at both.

Marco

[ITA] libpng

[Ken Brown via Cygwin-apps]

Builds fine from Yaakov's cygport file, no update needed at present.

Ken

Re: patch command incorrectly capitalizes filenames that live on external USB flash drives

[Brian Inglis]

On 2020-05-13 23:07, Jason Gross wrote:
> On Wed, May 13, 2020 at 10:32 PM Jason Gross wrote:
>> On Wed, May 13, 2020 at 8:31 PM Jason Gross wrote:
>>> Brian Inglis wrote:
 Marco Atzeri wrote:
> Thomas Wolff wrote:
>> On Tue, Apr 28, 2020 at 3:27 PM Jason Gross wrote:

[Please insert comments inline or add at the bottom on this mailing list]

>> Consider the following script in foo.sh:
>> #!/usr/bin/env bash
>> set -ex
>> cd "$1"
>> rm -rf foo
>> mkdir foo
>> cd foo
>> cat > Makefile <> a
>> b
>> c
>> d
>> e
>> EOF
>> cat > diff <> diff --git a/Makefile b/Makefile
>> index 9405325..86d2f8c 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1,5 +1,5 @@
>>  a
>>  b
>> -c
>> +ccc
>>  d
>>  e
>> EOF
>> patch -p1 -i ./diff
>> ls
>> If I run `./foo.sh /cygdrive/c/`, I get, as expected,
>> + cd /cygdrive/c/
>> + rm -rf foo
>> + mkdir foo
>> + cd foo
>> + cat
>> + cat
>> + patch -p1 -i ./diff
>> patching file Makefile
>> + ls
>> diff  Makefile

>>> Sorry for the late reply; I can see replies to my messages at 
>>> https://cygwin.com/pipermail/cygwin/2020-April/244660.html, but somehow 
>>> I'm not receiving them in Gmail. I've tried (re?)subscribing to the 
>>> cygwin mailing list, hopefully this fixes the problem.
 You are throwing a puzzle into the mailing list and if you are lucky, 
 someone may like to solve it. But perhaps: can you try to minimize 
 your test case, please. Something
like: touch Makefile; ls (if that's it).
>>> I think there's some sort of misconception here. touch and cat create 
>>> correctly capitalized files, and sed -i doesn't change capitalization, 
>>> even on my FAT32 drive. patch is the only command I've found so far
>>> which capitalizes filenames when modifying files. I can try to dig into
>>> the source code of patch and figure out a minimal C program that breaks 
>>> casing on files, but, come on, the fact that patch seems to capitalize 
>>> the file name of every file it modifies, and no other utility does this, 
>>> that seems like a pretty minimal test-case to me. And anyway, the cygwin 
>>> patch sources (version 2.7.4) are impossible to compile, because safe.c 
>>> can't find sys/resource.h and passing -I/usr/include via CFLAGS hits an 
>>> internal bug in patch's configure script (search.h: present but cannot
>>> be compiled; sys/timeb.h: present but cannot be compiled; fcntl.h:
>>> present but cannot be compiled). (I've emailed bug-pa...@gnu.org as
>>> requested by the configure script, but so far 
>>> https://lists.gnu.org/archive/html/bug-patch/ isn't showing anything 
>>> newer than January.)
>> If I instead run `./foo.sh /cygdrive/h/`, I get
>> ```
>> + cd /cygdrive/h/
>> + rm -rf foo
>> + mkdir foo
>> + cd foo
>> + cat
>> + cat
>> + patch -p1 -i ./diff
>> patching file Makefile
>> + ls
>> diff  MAKEFILE
>> ```
>>
>> My C drive is an internal SSD (NTFS), my H drive is an external flash
>> drive (FAT32).  I installed cygwin with the commands:
>> ```
>> powershell -Command "(New-Object
>> Net.WebClient).DownloadFile('http://www.cygwin.com/setup-x86_64.exe',
>> 'setup-x86_64.exe')"
>> SET CYGMIRROR=http://mirror.easyname.at/cygwin
>> SET CYGROOT=H:\cygwin64
>> SET CYGCACHE=%CYGROOT%\var\cache\setup
>> setup-x86_64.exe -qnNdO -R %CYGROOT% -l %CYGCACHE% -s %CYGMIRROR% -P
>> rsync -P patch -P diffutils -P make -P unzip -P m4 -P findutils -P
>> time -P wget -P curl -P git -P
>> mingw64-x86_64-binutils,mingw64-x86_64-gcc-core,mingw64-x86_64-gcc-g++,mingw64-x86_64-pkg-config,mingw64-x86_64-windows_default_manifest
>> -P 
>> mingw64-x86_64-headers,mingw64-x86_64-runtime,mingw64-x86_64-pthreads,mingw64-x86_64-zlib
>> -P python3
>> ```
>>
>> Running `patch -v` says `GNU patch 2.7.4`.  Note that this happens
>> regardless of whether I install cygwin itself on my external flash
>> drive or on my internal HD.
>>
>> This came up when trying to run `opam install findlib` (which fails
>> when the home directory is on an external USB drive).

 That might be expected with FAT32, which is normally the default format
 for flash drives, for maximum compatibility with microcontrollers,
 which may not create VFAT Long File Names when file names are <= 8.3,
 so they appear as upper case.
>>> This does not explain why `ls` displays "Makefile" as "Makefile" before I
>>> run `patch`, but displays the filename as "MAKEFILE" after I run `patch`.
>>> Nor does it explain why this happens to patch-modified files, but not to
>>> files modified via sed -i.
 use a flash driver with NTFS and check the difference
>>> Indeed, I can confirm that this issue occurs when it's FAT or FAT32, and 
>>> does not occur under NTFS nor exFAT.
 I doubt it is a 

[ITA] poppler, poppler-data

[Ken Brown via Cygwin-apps]

cygport files attached.  In both cases these are routine updates to the latest 
upstream release.  For poppler, I also updated the Fedora patches to those that 
are used in the latest Fedora release (but I ignored the patches that are for 
qt4, since the Cygwin build uses qt5).


Ken
inherit qt5 cmake

NAME="poppler"
VERSION=0.88.0
RELEASE=1
CATEGORY="Libs"
SUMMARY="PDF rendering library"
DESCRIPTION="Poppler is a fork of the xpdf PDF viewer which provides PDF
rendering functionality as a shared library and replaces built-in code
with dependencies that are now available as standard components of modern
Unix desktop environments."
HOMEPAGE="http://poppler.freedesktop.org/;
SRC_URI="https://poppler.freedesktop.org/${NAME}-${VERSION}.tar.xz;
PATCH_URI="

https://src.fedoraproject.org/rpms//poppler/raw/master/f/poppler-0.30.0-rotated-words-selection.patch

https://src.fedoraproject.org/rpms//poppler/raw/master/f/poppler-0.63.0-tiling-patterns.patch

https://src.fedoraproject.org/rpms//poppler/raw/master/f/poppler-0.84.0-MacroPushRequiredVars.patch
0.30.0-cygwin-dllexport.patch
"

BUILD_REQUIRES="gtk-doc \
libQt5Gui-devel \
libboost-devel \
libcairo-devel \
libcurl-devel \
libfontconfig-devel \
libfreetype-devel \
libgdk_pixbuf2.0-devel \
libgirepository1.0-devel \
libglib2.0-devel \
libgtk3-devel \
libjpeg-devel \
liblcms2-devel \
libnss-devel \
libopenjp2-devel \
libpng-devel \
libtiff-devel \
openjpeg2 \
poppler-data-devel"

# the core is API/ABI unstable, so this changes with every release
c_abi=99
# the bindings are API/ABI stable, so these should NOT need to change
cpp_abi=0
glib_abi=8
qt5_abi=1

PKG_NAMES="${NAME} libpoppler${c_abi} libpoppler-devel"
poppler_CATEGORY="Graphics"
poppler_SUMMARY="PDF manipulation utilities"
poppler_CONTENTS="usr/bin/*.exe usr/share/doc/ usr/share/man/"
declare libpoppler${c_abi}_SUMMARY="${SUMMARY} (core runtime)"
declare libpoppler${c_abi}_REQUIRES="poppler-data"
declare libpoppler${c_abi}_CONTENTS="usr/bin/cygpoppler-${c_abi}.dll"
declare libpoppler_devel_SUMMARY="${SUMMARY} (core development)"
libpoppler_devel_CONTENTS="--exclude=*cpp* --exclude=*glib* --exclude=*qt4* 
--exclude=*qt5*
   usr/include/ usr/lib/libpoppler.* usr/lib/pkgconfig/"

PKG_NAMES+=" libpoppler-cpp${cpp_abi} libpoppler-cpp-devel"
declare libpoppler_cpp${cpp_abi}_SUMMARY="${SUMMARY} (C++ STL runtime)"
declare 
libpoppler_cpp${cpp_abi}_CONTENTS="usr/bin/cygpoppler-cpp-${cpp_abi}.dll"
libpoppler_cpp_devel_SUMMARY="${SUMMARY} (C++ STL development)"
libpoppler_cpp_devel_CONTENTS="usr/include/poppler/cpp/ usr/lib/libpoppler-cpp.*
   usr/lib/pkgconfig/poppler-cpp.pc"

PKG_NAMES+=" libpoppler-glib${glib_abi} libpoppler-glib-devel 
libpoppler-glib-doc girepository-Poppler0.18"
declare libpoppler_glib${glib_abi}_SUMMARY="${SUMMARY} (GObject runtime)"
declare 
libpoppler_glib${glib_abi}_CONTENTS="usr/bin/cygpoppler-glib-${glib_abi}.dll"
libpoppler_glib_devel_SUMMARY="${SUMMARY} (GObject development)"
libpoppler_glib_devel_CONTENTS="usr/include/poppler/glib/ 
usr/lib/libpoppler-glib.*
usr/lib/pkgconfig/poppler-glib.pc"
libpoppler_glib_doc_CATEGORY="Doc"
libpoppler_glib_doc_SUMMARY="${SUMMARY} (GObject bindings API docs)"
libpoppler_glib_doc_CONTENTS="usr/share/gtk-doc/"
girepository_Poppler0_18_SUMMARY="${SUMMARY} (GObject Introspection)"
girepository_Poppler0_18_CONTENTS="usr/*/gir*/Poppler-0.18.*"

PKG_NAMES+=" libpoppler-qt5_${qt5_abi} libpoppler-qt5-devel"
declare libpoppler_qt5_${qt5_abi}_SUMMARY="${SUMMARY} (Qt5 runtime)"
declare 
libpoppler_qt5_${qt5_abi}_CONTENTS="usr/bin/cygpoppler-qt5-${qt5_abi}.dll"
libpoppler_qt5_devel_SUMMARY="${SUMMARY} (Qt5 development)"
libpoppler_qt5_devel_REQUIRES="libQt5Core-devel libQt5Gui-devel"
libpoppler_qt5_devel_CONTENTS="usr/include/poppler/qt5/ usr/lib/libpoppler-qt5.*
   usr/lib/pkgconfig/poppler-qt5.pc"

DISTCLEANFILES="glib/*.gir"
DIFF_EXCLUDES="poppler-config.h reference"

CPPFLAGS+=" -D_XOPEN_SOURCE=500 -D_DEFAULT_SOURCE"
# BUILD_QT5_TESTS: uses private symbols which are not dllexport'ed
CYGCMAKE_ARGS="
-DENABLE_XPDF_HEADERS=ON
-DENABLE_CPP=ON
-DENABLE_GLIB=ON
-DENABLE_GTK_DOC=ON
-DENABLE_QT5=ON
-DBUILD_QT5_TESTS=OFF
-DENABLE_UTILS=ON
-DENABLE_LIBOPENJPEG=openjpeg2
-DENABLE_CMS=lcms2
-DENABLE_DCTDECODER=libjpeg
-DENABLE_LIBCURL=ON
-DENABLE_ZLIB=ON
"
NAME="poppler-data"
VERSION=0.4.9
RELEASE=1
CATEGORY="Graphics Text"
SUMMARY="PDF rendering library (encoding data)"
DESCRIPTION="Poppler is a fork of the xpdf PDF viewer which provides PDF
rendering functionality as a shared library and replaces built-in code
with dependencies that are now available as standard components of modern
Unix 

xmlto 0.0.28-1

[Ken Brown via Cygwin-announce]

The following package has been uploaded to the Cygwin distribution:

* xmlto-0.0.28-1

xmlto is a simple shell script for converting XML files to various
formats.  At the moment it supports conversion from docbook, xhtml1,
and fo format to various output formats (awt, fo, htmlhelp, javahelp,
mif, pdf, svg, xhtml, dvi, html, html-nochunks, man, pcl, ps, txt,
xhtml-nochunks).

This is an update to the latest upstream release.

Ken Brown
Cygwin's xmlto maintainer

[ANNOUNCEMENT] xmlto 0.0.28-1

[Ken Brown via Cygwin-announce]

The following package has been uploaded to the Cygwin distribution:

* xmlto-0.0.28-1

xmlto is a simple shell script for converting XML files to various
formats.  At the moment it supports conversion from docbook, xhtml1,
and fo format to various output formats (awt, fo, htmlhelp, javahelp,
mif, pdf, svg, xhtml, dvi, html, html-nochunks, man, pcl, ps, txt,
xhtml-nochunks).

This is an update to the latest upstream release.

Ken Brown
Cygwin's xmlto maintainer
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: patch command incorrectly capitalizes filenames that live on external USB flash drives

[Ken Brown via Cygwin]

On 5/13/2020 8:31 PM, Jason Gross via Cygwin wrote:

This does not explain why `ls` displays "Makefile" as "Makefile"
before I run `patch`, but displays the filename as "MAKEFILE" after I
run `patch`.  Nor does it explain why this happens to patch-modified
files, but not to files modified via sed -i.


I vaguely recall from several years ago a strange patch issue that I finally 
tracked down to environment variables used by patch to determine its temporary 
directory.  From 'man patch':


ENVIRONMENT
[...]
   TMPDIR, TMP, TEMP
  Directory  to  put temporary files in; patch uses the first environ‐
  ment variable in this list that is set.  If none are  set,  the  de‐
  fault is system-dependent; it is normally /tmp on Unix hosts.

Do you have any of those variables set to a value other than /tmp?

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

[ANNOUNCEMENT] zziplib 0.13.71-1

[Ken Brown via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* zziplib-0.13.71-1
* libzzip0.13-0.13.71-1
* libzzip-devel-0.13.71-1

The zziplib library provides read access to zipped files in a
zip-archive, using compression based solely on free algorithms
provided by zlib.  It also provides a functionality to overlay the
archive filesystem with the filesystem of the operating system
environment.

This is an update to the latest upstream release.

Ken Brown
Cygwin's zziplib maintainer
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

zziplib 0.13.71-1

[Ken Brown via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* zziplib-0.13.71-1
* libzzip0.13-0.13.71-1
* libzzip-devel-0.13.71-1

The zziplib library provides read access to zipped files in a
zip-archive, using compression based solely on free algorithms
provided by zlib.  It also provides a functionality to overlay the
archive filesystem with the filesystem of the operating system
environment.

This is an update to the latest upstream release.

Ken Brown
Cygwin's zziplib maintainer

Re: [ITA] zziplib

[Ken Brown via Cygwin-apps]

On 5/13/2020 11:10 PM, Yaakov Selkowitz wrote:

On Wed, 2020-05-13 at 14:44 -0400, Ken Brown via Cygwin-apps wrote:

2. I primed the cache so that configure would think I didn't have xmlto
installed.  The latter failed to produce man files, for reasons I didn't try to
figure out.


They build on my system with xmlto 0.0.26, so it's probably a matter of
a missing dependency.  Do you have all the docbook-* packages
installed?  What error message is shown?


The error message was

I/O error : Attempt to load network entity 
http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd


Installing docbook-xml412 fixed it (Duh!).

Thanks.

Ken

Re: Cygwin/X: KDE Desktop

[Maarten Hoes via Cygwin]

On Thu, May 14, 2020 at 3:08 AM  wrote:

> On Wed, 13 May 2020 19:22:25 +0200
> Maarten Hoes via Cygwin  wrote:
>
> > >
> > > Now that you mentioned that, I seem to be having similar behavior as
> you:
> > > Xfce start every time I try it. But now that I tried it some more,
> LXDE is
> > > not consistent for me either. Sometimes I get a black screen,
> sometimes a
> > > black screen and the right-click-on-background-menu, and sometimes a
> normal
> > > working LXDE environment. The first time I try to start LXDE after a
> reboot
> > > of my PC seems to work always, and after that I get mostly the black
> screen
> > > without pop-up menu. The only thing I seem to be able to reproduce
> reliably
> > > with LXDE is the first try after reboot.
> > >
>
> I missed the start of this thread.
>
> the menu entries that you can find under the windows start menu work every
> once in a while, but the majority of the time they do like you say:
>
> 1 nothing
> 2 runs, but black screen
> 3 runs, and window manager comes up (very seldom)
>
> interestingly , running "startx" in mintty is 100% working.
>
> I am using the xfce desktop, and this all started on the last cygwin
> upgrade i did (which also broke graphics characters in terminals , although
> i'm sure the two are not related).
>
> hangs in cygwin are quite common in my experience, i know that a lot of
> the time it is due to stupid network drives in the PATH variable causing
> problems.  I have very carefully set-up my bashrc file to remove all the
> corporate network drives from the path.  that helped a lot.
>
>

Hi,


With 'current' Cygwin, Xfce is the only desktop that works all of the time
for me. It's the other ones that give the described problems, where GNOME
and KDE always give a black screen, and LXDE works 'sometimes' and others
it's the black screen. I only tried to start X11 from the commandline (I
think with 'startxwin' and not 'startx' but I'm not sure) with a 'exec
/usr/bin/startkde' in my .xinitrc to get a KDE desktop, but I had the same
result as with the icons in the MS-Windows start menu.

Currently, I have downgraded all of Cygwin to a release dated 2016/10/02,
and there both KDE and GNOME work as expected for me (although a bit
slowly). To do the 'downgrade', I used the 'Cygwin Time Machine', [1] which
archives past Cygwin 'snapshots' (read: all packages that were 'current' at
some given date in the past) to try out older Cygwin releases (with
packages that are meant to go together as defined by release date). I fully
realize this is by no means a 'supported' configuration, but it seemed like
a better option than randomly downgrading individual Cygwin packages
without knowing if they were meant to work together to begin with.


- Maarten


[1]
http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Groups command failing me in Windows 10

[Andrey Repin]

Greetings, Chris Wagner!

> On 2020-05-12 3:45 pm, David wrote:
>> The groups command in the cmd window on Windows 10 shows None as my 
>> first group.
>> When I use the dir command to create a file, the security display
>> shows no error.
>> When I use the touch command to create a file, I get "The permissions
>> on ... are incorrectly ordered [NULL if first]

> Hi David.  The first thing to realize is that POSIX permissions and 
> Windows ACLs are almost impossible to reconcile.  Best to pick one and 
> ignore the other.

> https://cygwin.com/cygwin-ug-net/ntsec.html has additional information.

> To set your group you should do it in /etc/passwd.
> If you don't have one, do: mkpasswd > /etc/passwd

Nope.
getent group

It will configure correct group file according to current NSS settings.
But you don't need to store it. (Or, well, you do, but for very, very, very
rare occasions.)

> Then edit the file and change the 4th field on the line with your 
> username to the group Id for Users.

No need.

> david:*:123456:197153:
->>
> david:*:123456:545:

> Then restart ALL Cygwin processes and id should show Users as your 
> primary group.  Any files created by a Windows process however will 
> still put None as the group.

> Hope that helps.

If you want to configure your user's primary group for Cygwin, you'd have to
do it in your user's settings. This is explained in the same article[1],
which you quoted, but seemingly not read yourself.

[1] https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch


-- 
With best regards,
Andrey Repin
Thursday, May 14, 2020 13:00:31

Sorry for my terrible english...

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

[ITA from Yaakov] python-wx

[Hamish McIntyre-Bhatty via Cygwin-apps]

Apologies for bumping this again, I'm just waiting for this to be done
before I start on wxPython 4, which is blocking progress for me doing
other things. If you're not interested in this fix, just let me know
and I'll move on to wxPython 4.

I have re-built the packages using your new cygport as the starting
point, and it seems to work really well. I made some minor modifications
to include the license files and the new patches from Fedora. The new
files are available at https://www.hamishmb.com/files/cygwin-temp/ and I
have removed the previous attempt's files.

Seeing as I have no need to rebuild wxWidgets, I guess that can stay
under your maintainership until an update is needed, at which point
I'll be happy to pick it up.

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: [ITA] zziplib

[Marco Atzeri via Cygwin-apps]

Am 13.05.2020 um 20:44 schrieb Ken Brown via Cygwin-apps:
cygport file attached.  I bumped the version to 0.13.71, the latest 
upstream release.  I also made the following changes to Yaakov's cygport 
file, in addition to a couple of trivial ones:


1. I removed the configure argument --disable-builddir, which is no 
longer needed or supported.


2. I primed the cache so that configure would think I didn't have xmlto 
installed.  The latter failed to produce man files, for reasons I didn't 
try to figure out.


Ken


changed maintainer