Re: setup and mintty (was Re: New setup.exe release?)

2011-05-28 Thread szgyg
2011.05.28. 10:53, Andy Koppe wrote: Another point worth noting here is that the mintty postinstall script requires mkshortcut, hence cygutils will be pulled into the default installation. Cygutils is already pulled by cygwin-doc. http://szgyg.web.elte.hu/cygwin/base.png szgyg

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-30 Thread szgyg
2011.05.28. 16:17, Andy Koppe wrote: On 28 May 2011 11:47, szgyg wrote: http://szgyg.web.elte.hu/cygwin/base.png ps: Interesting diagram. What's with the circular dependency? I don't know. Maybe it was caught by a hippo? szgyg

[PATCH] New dependencies with old packages

2011-05-30 Thread szgyg
When there is a newer version of a package, but I opt to keep the old version, setup.exe want to install the dependencies of the new package. With this patch setup.exe doesn't compute the dependecies of installed packages, except when they are current (so rerunning setup.exe to repairing an

[PATCH] Multiple --site options

2011-05-30 Thread szgyg
I want to say `./setup.exe --site ports --site local-repo', so there it is. 2011-05-30 SZAVAI Gyula sz...@ludens.elte.hu * libgetopt++/src/StringArrayOption.cc: New file. * libgetopt++/include/getopt++/StringArrayOption.h: New file. * libgetopt++/Makefile.am: Add new

Re: [ANNOUNCEMENT] Updated: tidy-20090325-1

2011-07-07 Thread szgyg
ping On 10/6/2010 11:51 AM, Jonathon Merz wrote: On Fri, Oct 1, 2010 at 5:18 AM, Lapo Luchinil...@lapo.it wrote: Version tidy-20090325-1 of HTML Tidy has been uploaded. It appears that the current/prev versions of tidy may be reversed in the setup.ini. On mirrors.xmission.com (and another

Re: Anyone want to maintain Midnight Commander?

2011-07-11 Thread szgyg
On 7/11/2011 7:30 AM, Marco Atzeri wrote: I will look on it. Thank you. Btw, I have two cygwin-specific extfs, one for the setup.ini files and one for the /etc/setup/*.lst.gz ones. szgyg shell/.lst.gz Open=%cd %p#cygpack shell/setup.ini Open=%cd %p#cygini BEGIN

Re: [ITA] mc-4.7.5.2-1

2011-07-12 Thread szgyg
? szgyg@gwen ~ $ ps ax PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 2368 12368 2368? 1004 16:13:20 /usr/bin/mintty 258423682584 38840 1004 16:13:22 /usr/bin/bash 394825843948 16000 1004 16:13:34 /usr/bin/ps

Re: [ITA] mc-4.7.5.2-1

2011-07-12 Thread szgyg
On 7/12/2011 4:31 PM, Marco atzeri wrote: On 7/12/2011 4:19 PM, szgyg wrote: On 7/12/2011 2:49 PM, Marco atzeri wrote: What about --with-subshell=optional ? currently does not work, at least on my test. It creates just zombie. I will investigate in the future Uhm, yes, you're right. :( Do

Re: [ITA] mc-4.7.5.2-1

2011-07-13 Thread szgyg
On 7/12/2011 4:31 PM, Marco atzeri wrote: On 7/12/2011 4:19 PM, szgyg wrote: What about --with-subshell=optional ? currently does not work, at least on my test. It creates just zombie. I will investigate in the future Actually, it works with the last released cygwin1.dll, but it fails

Re: [ITA] mc-4.7.5.2-1

2011-07-13 Thread szgyg
version in the distro has the same issue. It ships with subshell support switched off by default (i.e. --with-subshell=optional), so you see this only if you run `mc -U'. szgyg

Re: [PATCH] Multiple --site options

2011-07-25 Thread szgyg
On 7/22/2011 3:33 PM, Jon TURNEY wrote: On 30/05/2011 10:28, szgyg wrote: I want to say `./setup.exe --site ports --site local-repo', so there it is. However, I think it needs a clearer description: What it actually does is (i) add infrastructure for handling options which are repeated

Re: HEADSUP: Python 2.7 upgrade

2013-01-26 Thread szgyg
On 1/26/2013 6:50 AM, marco atzeri wrote: On 1/26/2013 1:08 AM, szgyg wrote: Strip copies the whole .reloc section, including entries for removed debug sections. This is documented in rebase/README. Rebase checks for this condition in Relocations::relocate and silently ignores wrong entries

Re: [RFC] incremental rebase

2014-11-17 Thread szgyg
Ken Brown, 2014.11.17. 12:00 : What I have in mind is simpler than this. There's nothing wrong with the existing texlive postinstall scripts except slowness, due to the repetition of time-consuming commands in different scripts. So I just need to do some rearranging: 1. I would create a

Re: how to manage 2 guile version

2017-03-28 Thread szgyg
time in the next month to chase it. FWIW guile 2.2.0 was released two weeks ago [0]. Mostly works, but it still has failing tests [1]. szgyg [0] https://lists.gnu.org/archive/html/guile-devel/2017-03/msg00095.html [1] https://lists.gnu.org/archive/html/guile-devel/2017-03/msg00066.html

Re: Making a package obsolete

2017-05-15 Thread szgyg
ontents="*" followed by a tar error. > > Yaakov, shouldn't the user be allowed to explicitly set PKG_CONTENTS empty > and have cygport honor that, at least for obsolete packages? I've used the attached files to create an empty, dependencies-only package. szgyg NAME="dependen

Re: Making a package obsolete

2017-05-15 Thread szgyg
On Mon, May 15, 2017 at 01:22:04PM -0400, Ken Brown wrote: > On 5/15/2017 12:51 PM, szgyg wrote: >> I've used the attached files to create an empty, dependencies-only package. > > Yes, that works around the problem by not actually creating an empty binary > tarball. But I s

Re: [PATCH setup] Send User-Agent even when setup-specific proxy is used

2018-01-22 Thread szgyg
On Fri, Jan 19, 2018 at 02:18:10PM +, Jon Turney wrote: > On 18/01/2018 19:16, SZAVAI Gyula wrote: > > Setup is sending User-Agent header if direct connection or system proxy > > is used, but not when direct(legacy) or setup-specific proxy. Fix this. > Thanks for the patch. > > This is fine,

Re: [PATCH setup 2/2] Improve file:// url handling

2018-03-08 Thread szgyg
On Tue, Mar 06, 2018 at 08:43:47PM +, Jon Turney wrote: > On 28/02/2018 11:51, SZAVAI Gyula wrote: > > [...] > > Most non-standard urls accepted by the old code should work, too. > > Paths longer than 260 characters are not supported anymore. > > Great, thanks! I applied these patches.

Re: git repositories for cygwin packaging - please test

2020-05-28 Thread szgyg
On Wed, May 27, 2020 at 11:27:49PM +0100, Jon Turney wrote: > Currently, many packages will fail to build correctly due to: > > (iii) resource limits imposed by AppVeyor's free service which is used to > perform the actual builds, or Azure Devops may worth a try. s