Re: [ITA] cmake 3.12.0

> do you need a static lib ? > I saw some distri are packaging it. Presumably the static lib should go in a -devel package? I wouldn't want to link cmake to the static lib though, that would defeat the purpose of de-vendoring it and using separately packaged dependencies. > builds successfully

Re: [ITA] cmake 3.12.0

> No, all I'm saying that there's a protocol for that.  The maintainer is > supposed to monitor this list I do read the mailing list, but don't write to it very often - composing a plain-text email is overly complicated with the mobile email clients I use most of the time, and I was traveling

Re: version anomalies

>> [f] https://cygwin.com/ml/cygwin/2015-03/msg00384.html > > socat 2.0.0-b7-1 was relabelled as test I'm seeing an attempted update to socat 2.0.0-b8-1 (which doesn't even exist on the mirror I'm using, AFAICT) so that may need the same treatment?

Re: [ITP] moreutils 0.61

>> >> -   parallel: run multiple jobs at once >> >> I'd be hesitatnt to package that since it directly clashes with GNU >> parallel (not available on Cygwin yet). > > Hmm.  I wasn't aware of GNU parallel, and I'm not sure how that sort of > problem is generally handled.  Possibly that could be

Re: mbed TLS package

> the shared library are in the wrong place: > > >>> libmbedcrypto0-2.4.2-1.tar.xz > usr/lib/cygmbedcrypto-0.dll > > >>> libmbedtls10-2.4.2-1.tar.xz > usr/lib/cygmbedtls-10.dll > > >>> libmbedx509-0-2.4.2-1.tar.xz > usr/lib/cygmbedx509-0.dll > > On cygwin the shared lib are in /usr/bin . I opened

Re: [ITP] cloudabi-toolchain, cloudab-binutils-*

Maurice Bos writes: > > Hello, > > Is there anything I can/should do to push this forward? > > Thanks. > > -Maurice- Is this packaged in any mainstream linux distributions? How long does it take to build from source, could you give build from source instructions to potential

RE: Removing cygwin32-*, cygwin64-*

Achim Gratz writes: > I guess that'd be fixable in cygport.  But if you are just worried about > having to enter the passphrase twice, you could use ssh-agent and then > ssh with agent forwarding into the second installation (or into both > from another box, as I do). Yeah, just entering the

RE: [SECURITY] p7zip: CVE-2015-1038

> You probably need to connect to cygwin.com with ssh on the command line > once in order to accept the prompt about the changed (or unknown) host > key. You can then rely on cygport's canned use of ssh again. Bingo, that was it! Thanks Achim! `ssh cygwin.com` to add the known host and everything

RE: Removing cygwin32-*, cygwin64-*

> Is anyone using the cygwin32- and/or cygwin64-* cross-compiling > toolchain for anything besides cross-building cygwin itself? I would > like to remove most of these from the distro if at all possible. Would this impact the ability to upload package builds via cygport --32 ? I just tried $

RE: [SECURITY] p7zip: CVE-2015-1038

> What means "NMU"? Sorry, that's a Debian term for "non-maintainer upload." I don't know if we ever do those in Cygwin? > Recently the default configuration has been changed to only have hashes > in that file. You could change it back or use ssh management commands > to remove the existing

RE: [SECURITY] p7zip: CVE-2015-1038

>> I don't have anything for sourceware or cygwin.com in >> ~/.ssh/known_hosts, should I? > > In theory, yes. It's usually collected the first time you connect to > the host. The idea is to have a known key to compare the host against > to disallow MITM attacks. Hm okay, what's the best way to

RE: [SECURITY] p7zip: CVE-2015-1038

>> Tony@LAPTOP-O230JCFF ~/github/cygwin-p7zip >> $ cygport p7zip-15.09-2.cygport upload > Uploading p7zip-15.09-2.x86_64 > Running lftp sftp://cyg...@cygwin.com >> Password: >> cd: Fatal error: Host key verification failed > > > The host key you stored for

Re: [SECURITY] p7zip: CVE-2015-1038

> Ack, will do today. Need to copy my ssh keys over to a new laptop, hopefully > that > will go smoothly and I've got all the build-deps installed. It didn't. Am I doing this wrong? (and should I move this to the main list?) $ eval `ssh-agent` Agent pid 12848 Tony@LAPTOP-O230JCFF

RE: [SECURITY] p7zip: CVE-2015-1038

> Tony, > > A directory traversal vulnerability has been reported in p7zip-15.09. > Could you please spin a new release with the following patch: > > http://pkgs.fedoraproject.org/cgit/rpms/p7zip.git/plain/p7zip-15.09-CVE-2015-1038.patch > > -- > Yaakov Ack, will do today. Need to copy my ssh

Re: cmake: Cygwin dllexport/dllimport

Could you please include the attached patch (created wrt 3.2.3) with the next release of cmake? It is required for building KF5. Can do. Should get to it within the next day or two. -Tony

Re: [ITP] busybox 1.23.2-1

busybox.exe with all working features enabled is ~600MB (bash: ~700MB). Removing the daemons, other rarely used commands and some features could reduce it to 300-350MB. I did't test LTO build which could further reduce size. KB, not MB, sorry :-) This is really cool, looking forward to seeing

Re: cmake update needed

Do you have any specific questions? 2.8.9-perl-libs.patch AIUI changes PERL_POSSIBLE_LIBRARY_NAMES from being set to perl{PERL_VERSION_STRING} perl only when the command `${PERL_EXECUTABLE} -V:libperl` fails, to appending those values any time PERL_EXECUTABLE is found. Is that command expected

Re: cmake update needed

Bill promised several time to update cmake, but it seems clear to me that is has no the time to take care of it. It will be better to officially declare the package orphan so another volunteer can take it. Happy to adopt it. I have some builds of latest 3.1.1 sitting around that I can send

Re: cmake update needed

Given our past experience[1][2] in working with upstream, anyone who maintains a working cmake is going to have to carry patches long-term, if not permanently. [1] http://www.cmake.org/Bug/view.php?id=10122 [2] http://www.cmake.org/pipermail/cmake/2010-October/040353.html and thread Yes, those

Re: cmake update needed

By “adopt,” you are offering to participate in the package contribution system, which involves a bit more than just putting tarballs in a shared Dropbox folder: https://cygwin.com/setup.html I'm aware, thanks, I already maintain 4 other packages. I'm putting these up for review of the

Re: cmake update needed

Obviously the patches to the modules won't affect the build of cmake itself, but they do affect the building of other packages using cmake. These patches were all added over years of testing and usage, and are required for a useful cmake package. Sure. Were the reasons for them ever written

Re: cmake update needed

Happy to adopt it. I have some builds of latest 3.1.1 sitting around that I can send to the list later today. Note that I have temporarily removed all of the patches from cygwin-ports since none of them were necessary to build, or changed the results of any of cmake's unit tests. I'll definitely

Re: [ITP] python-docutils 0.12

Tony, I have added you to cygwin-pkg-maint for the three python modules. You may upload when ready. Thanks Yaakov. I see now that I did not have every single python-* package installed, so I was missing a few dependencies (lxml and markupsafe). I will upload rebuilds of docutils and jinja2

Re: [ITP] python-sphinx 1.2.3

[sorry Yaakov about the inadvertent off-list reply, I do need a better mail client] Based on the cmake ITA thread, does this need python-jinja2 and/or python-docutils? Tony mentioned that building documentation and manual/help require it. I assume we will need them also if Bill is making the

Re: [ITA] cmake

Jinja2 and docutils are also packaged Those have similarly simple-looking cygport files in ports so guess I'll do those too. Current cmake has no cmake-doc so we can also skip HTML documentation cmake 3 uses sphinx to generate its man pages, not just the html docs. Not having a man page

[ITP] python-docutils 0.12

Packaging source taken directly from ports, bumped to latest upstream version of docutils: https://github.com/tkelman/cygwin-python-docutils setup.hint contents: category: Python requires: python python-imaging python-pygments sdesc: Python reStructuredText processing module ldesc: Docutils is

[ITP] python-jinja2 2.7.3

Packaging source taken directly from ports, bumped to latest upstream version of jinja2: https://github.com/tkelman/cygwin-python-jinja2 setup.hint contents: category: Python requires: python python-setuptools sdesc: Python template engine library ldesc: Jinja2 is a template engine written in

Re: [ITA] cmake

check if the Help files are used by the main program or by the gui If yes fit them in the same package, if not leave in cmake-doc. Very good catch Marco, thanks. The Help files are indeed used by the main cmake CLI when you call --help-*, there is some runtime .rst processing. So I moved them

Re: [ITA] cmake

SPHINX_EXECUTABLE (sphinx-build) is not found! Do we have sphinx on cygwin ? I think it is only on cygwinport Ah sorry, I should've mentioned that. I didn't find sphinx as a Cygwin package, no. I had to do `pip install sphinx`. Though now I'm trying to remember where I got pip from, since I

Re: [ITA] cmake

It may be a better fit for someone else's knowledge and day-to-day usage though. Nevermind, I should've actually looked at http://sourceforge.net/p/cygwin-ports/python-sphinx/ci/master/tree/python-sphinx.cygport first. It's using distutils instead of pip, but it looks like cygport already does

[ITP] python-sphinx 1.2.3

Packaging source taken directly from ports, bumped to latest upstream version of sphinx: https://github.com/tkelman/cygwin-python-sphinx setup.hint contents: category: Python requires: python python-imaging python-pygments python-setuptools sdesc: Python documentation generator ldesc: Sphinx is

[ITA] cmake

Feels a little odd to be proposing adopting cmake from its original author, but I guess he's a busy guy and has not been responsive to requests on cygwin lists to update the package. I found Yaakov had a recent cygport file and set of patches in ports, I started from there. I imported Yaakov's

Re: [ITA] p7zip

Thanks all for the feedback and help. Sorry for showing up at a bad time. Note: You should perhaps remove the keepdir that preserves the /usr/lib/p7zip/Codecs directory. This drops a zero-size .keep-p7zip file in there that elicits a warning from p7zip since it isn't a codec. On the other

SSH key for upload access

Name: Tony Kelman Package: p7zip BEGIN SSH2 PUBLIC KEY Comment: 2048-bit RSA, converted by Tony@TK-samsung from OpenSSH B3NzaC1yc2EDAQABAAABAQDhNCqmIEWmLB4tvAmVA/MU5WgZbYZ05pD44LmfME 29q7Z/wyis+yS02IuL3np/fg3DjXjIPR5cfw6+nHccT/2KUEN0c3GMoJKL0AjVdQ5VANGv qryKty5CMqw/Le39KcruumNEc

Re: [ITA] p7zip

Yes, there's ARCH, ARCH_i686, and ARCH_x86_64. See /usr/share/doc/cygport/manual.html. Thanks, that's a great resource. I'm used to long-form docs being online somewhere rather than already installed along with the package. I'm a bit unclear what needs to happen next, despite reading all of

[ITA] p7zip

Hi, I noticed that all of Chuck Wilson's packages are now listed as orphaned. I'm particularly interested in getting one of them, p7zip, uploaded to the 64-bit distribution. I sent a few messages to the main list in March discussing what I needed to change in order to get the existing cygport

Re: [ITA] p7zip

Rather than changing the upstream source tarball, you can add something like: CYGPORT_USE_UNSTABLE_API=1 src_unpack_hook() { dos2unix man1/7zr.1 } Ah, great, thanks, I was wondering if there was something like that in cygport. Now I know. On the topic of cygport, is there a variable