On Nov 17 11:57, ggl329 via Cygwin wrote:
> cygfido2-1.dll (from libfido2-1.9.0-1) depends on cygcbor-0.8.dll .
> But the dependency is dropped in setup.ini (depends2 field).
> In addition, the current libcbor-0.9.0-2 doesn’t provide cygcbor-0.8.dll but
> cygcbor-0.9.dll .
> Maybe,
cygfido2-1.dll (from libfido2-1.9.0-1) depends on cygcbor-0.8.dll .
But the dependency is dropped in setup.ini (depends2 field).
In addition, the current libcbor-0.9.0-2 doesn’t provide cygcbor-0.8.dll but
cygcbor-0.9.dll .
Maybe, libfido2 needs to be rebuilt with libcbor-0.9 .
Thanks
On 2021-05-18 18:32, Brian Inglis wrote:
On 2021-05-18 10:05, Marco Atzeri via Cygwin-apps wrote:
On 18.05.2021 15:47, Brian Inglis wrote:
Needed dependency for libidn build missing from x86.
It seems Rafel has missed to note the need to build for
both architectures.
Ping Rafel Amer - need
Веснин Юрий Александрович writes:
> It's definitely a bug. What's the proper way to fix it?
It's not a fix, but for starters you could create a bunch of smaller packages.
> Addition:
> @ rdc-deps
> sdesc: "RDC's devel dependencies"
> ldesc: "RDC's devel dependencies"
> category: Base
> requires:
>>> If you provide more details on that problem, I can probably give some
>>> advice.
>>
>> I suppose that bug comes from parsing setup.ini because of cygwin hangs on
>> such stage.
>> You can find more details by following previously described step
On 13/08/2019 17:56, Веснин Юрий Александрович wrote:
If you provide more details on that problem, I can probably give some
advice.
I suppose that bug comes from parsing setup.ini because of cygwin hangs on such
stage.
You can find more details by following previously described steps.
You
> If you provide more details on that problem, I can probably give some
> advice.
I suppose that bug comes from parsing setup.ini because of cygwin hangs on such
stage.
You can find more details by following previously described steps.
>> How to reproduce the problem:
>> 1.
On 12/08/2019 10:44, Веснин Юрий Александрович wrote:
After creating a huge custom package, we meet inaccessibility of using
setup.exe. It hangs on parsing setup.ini. By doing a little research we've
found that this behavior appears when package size is greater than 1GiB (not
accurate
After creating a huge custom package, we meet inaccessibility of using
setup.exe. It hangs on parsing setup.ini. By doing a little research we've
found that this behavior appears when package size is greater than 1GiB (not
accurate 1GiB but 1.4GB is enough). We started to invest
On Sun, Apr 29, 2018 at 1:38 PM, Keith Thompson
wrote:
> I'm using a freshly downloaded copy of https://cygwin.com/setup-x86_64.exe,
> which reports itself to be "Setup.exe version 2.884 (64 bit)".
No, I wasn't. I had the correct version in the directory where I
*thought* I was running it from,
On Sun, 29 Apr 2018 13:38:04, Keith Thompson wrote:
I'm using a freshly downloaded copy of https://cygwin.com/setup-x86_64.exe,
which reports itself to be "Setup.exe version 2.884 (64 bit)".
You sure about that?
$ curl -O cygwin.com/setup-x86_64.exe
$ ./setup-x86_64 -V
Cygwin setup 2.
ersion of setup-x86_64.exe. If you
have any trouble installing, please download a fresh version from
http://www.cygwin.com/setup-x86_64.exe.
I've confirmed that the ini file at
http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.ini
contains:
release: cygwin
ar
On 07/11/2017 10:25, Houder wrote:
On Mon, 06 Nov 2017 19:02:08, Achim Gratz wrote:
Jon Turney writes:
Since [1], there's no way to install a prev version using setup,
without explicitly selecting which version you want, so the ordering
of those [prev] versions in setup.ini is relat
On Mon, 06 Nov 2017 19:02:08, Achim Gratz wrote:
> Jon Turney writes:
> > Since [1], there's no way to install a prev version using setup,
> > without explicitly selecting which version you want, so the ordering
> > of those [prev] versions in setup.ini is relatively u
Jon Turney writes:
> Since [1], there's no way to install a prev version using setup,
> without explicitly selecting which version you want, so the ordering
> of those [prev] versions in setup.ini is relatively unimportant.
For setup that is true, but linear parsers that can only ke
quot;),
In fact, setup makes some decisions based on label, and some based on
version ordering, which part of the current mess...
that is without any order, then both semantics and syntax of "version"
must be rigidly defined in [1] ...
... if you want it to be a specification for setu
ms.
This is the list that I assembled, based of yesterday's setup.ini
[snip]
Yes, this looks like the list of what got changed when I fixed it.
These should be correctly ordered as of setup.ini with setup-timestamp:
1509977795 or later.
--
Problem reports: http://cygwin.com/pr
both semantics and syntax of "version"
must be rigidly defined in [1] ...
... if you want it to be a specification for setup.ini.
Regards,
Henri
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cy
On 2017-11-06 15:20, Jon Turney wrote:
[snip]
Since [1], there's no way to install a prev version using setup,
without explicitly selecting which version you want, so the ordering
of those [prev] versions in setup.ini is relatively unimportant.
[1] https://cygwin.com/ml/cygwin-apps/20
led, based of yesterday's setup.ini
Regards.
Henri
-
gdb c t t p t ... correct wrt
to the most recent test entry
lftp c t p
mingw64-i686-binutilsc t p
mingw64-i686-gcc-core
On 05/11/2017 18:04, Houder wrote:
On 2017-11-05 18:32, Houder wrote:
On 2017-11-05 13:48, Houder wrote:
Currently, I am only interested in the _specification_ that you have
in mind for setup.ini ...
I try to keep [1] accurate and up-to-date, but the 'specification' is
really &
On 05/11/2017 17:32, Houder wrote:
On 2017-11-05 13:48, Houder wrote:
After I had downloaded and exercised setup version 2.882, I noticed
that setup.ini has multiple (2?) "prev" entries per package ...
Why? Did I miss one of your announcements mentioning this change?
https://
On 2017-11-05 18:32, Houder wrote:
On 2017-11-05 13:48, Houder wrote:
Hi John (Turney),
After I had downloaded and exercised setup version 2.882, I noticed
that setup.ini has multiple (2?) "prev" entries per package ...
Why? Did I miss one of your announcements mentioning this cha
On 2017-11-05 13:48, Houder wrote:
Hi John (Turney),
After I had downloaded and exercised setup version 2.882, I noticed
that setup.ini has multiple (2?) "prev" entries per package ...
Why? Did I miss one of your announcements mentioning this change?
Jon,
https://cygwin.com
On 2017-11-05 13:48, Houder wrote:
Hi John (Turney),
After I had downloaded and exercised setup version 2.882, I noticed
that setup.ini has multiple (2?) "prev" entries per package ...
Why? Did I miss one of your announcements mentioning this change?
See https://cygwin.com/ml/c
On 2017-11-05 15:03, Vince Rice wrote:
It's Jon, and yes, you did. I'm on the way out the door, but you can
search the archives. The discussion was on apps, IIRC, and was in the
last month or two.
Thank you.
Not Jon
Sorry about that.
Regards,
Henri
--
Problem reports: http://cygwi
> On Nov 5, 2017, at 6:48 AM, Houder wrote:
>
> Hi John (Turney),
>
> After I had downloaded and exercised setup version 2.882, I noticed
> that setup.ini has multiple (2?) "prev" entries per package ...
>
> Why? Did I miss one of your announcements me
Hi John (Turney),
After I had downloaded and exercised setup version 2.882, I noticed
that setup.ini has multiple (2?) "prev" entries per package ...
Why? Did I miss one of your announcements mentioning this change?
Regards,
Henri
Announcements (setup):
- https://cygwin.com/ml/c
ps in the 'requires' fields in
setup.ini - even to the point that some packages depend upon themselves!
Cycles in the dependency graph are unfortunately a real thing (although
all cycles which exist may not be correct or unavoidable)
cygwin-debuginfo depending on itself is simply a bug in
On 30/09/2017 12:23, Andrey Repin wrote:
>
>> Indeed. However, while off label usage of Cygwin is anathema to me but
>> sometimes I wish 'base' wasn't quite so big and have to pare things down
>> a little once installed, e.g. as part of a makefile- and/or
>> Eclipse-based build tree in source code
Greetings, Sam Edge!
>>> It's not production ready yet but it's already flagged up some issues.
>>> For example we have lots of dependency loops in the 'requires' fields in
>>> setup.ini - even to the point that some packages depend upon themselves!
and-alone utility.
> I'm eager to see the fruits of your labor.
Don't hold your breath! :-) I'm doing it partly to teach myself the
subtleties of Python classes and I've not yet got to the process of
turning it into an installable import module. Also, its re-based parser
is s
p some issues.
> For example we have lots of dependency loops in the 'requires' fields in
> setup.ini - even to the point that some packages depend upon themselves!
Dependency upon itself is curious, but other than that, this is a normal
situation for a package manager. Some package
On 30/09/2017 00:39, Steven Penny wrote:
On Fri, 29 Sep 2017 21:16:17, "Sam Edge (Cygwin)" wrote:
For example we have lots of dependency loops in the 'requires' fields in
setup.ini - even to the point that some packages depend upon themselves!
It is the job of the packa
On 29/09/2017 23:39, Steven Penny wrote:
> On Fri, 29 Sep 2017 21:16:17, "Sam Edge (Cygwin)" wrote:
>> For example we have lots of dependency loops in the 'requires' fields in
>> setup.ini - even to the point that some packages depend upon themselves!
>
>
On Fri, 29 Sep 2017 17:53:52, Doug Henderson wrote:
mintty is a windows, non-cygwin, executable
No, its not:
$ cygcheck mintty
Found: C:\cygwin64\bin\mintty.exe
C:\cygwin64\bin\mintty.exe
C:\cygwin64\bin\cygwin1.dll
which does not depend on cygwin1.dll
Yes, it does:
$ ldd /bin/mintty.exe
On 29 September 2017 at 14:16, Sam Edge (Cygwin) wrote:
> … mintty doesn't
> depend upon anything - it has no requires field. …
mintty is a windows, non-cygwin, executable which does not depend on cygwin1.dll
There are a few other such programs, which (I guess) are built using
the mingw32 tools
On Fri, 29 Sep 2017 21:16:17, "Sam Edge (Cygwin)" wrote:
For example we have lots of dependency loops in the 'requires' fields in
setup.ini - even to the point that some packages depend upon themselves!
It is the job of the package manager to detect and avoid such loops. No
pt of Michael A. Chase's 'clean_setup' utility but
as a scriptable tool set rather than a stand-alone utility.
It's not production ready yet but it's already flagged up some issues.
For example we have lots of dependency loops in the 'requires' fields in
setup.in
On Thu, 02 Feb 2017 19:29:19, Steven Penny wrote:
> This patch was submitted 5 years ago, and has still not been merged:
> http://cygwin.com/git/gitweb.cgi?p=cygwin-apps/genini.git;f=genini;h=33b46fe
> Can we make this happen?
My bad, it looks like Cygwin calm replaced genini:
http://cygwin.com/g
On Mon, 18 Apr 2011 23:38:34, Jens Schweikhardt wrote:
> For starters, the categories have apparently changed. The latest setup.exe
> does not have Comm and Sound, but has gained Accessibility and Security.
> --- genini.orig 2011-04-18 23:28:30.0 +0200
> +++ genini2011-04-18 23:32
;debuginfo".
I was not surprised to see that intention fail ...
Only after I had modified setup.ini, where I removed the "source:" line
from tar-debuginfo, setup was able to "install" the source code
tarball.
A mirror (at least the mirror I use) does not have
o see that intention fail ...
Only after I had modified setup.ini, where I removed the "source:" line
from tar-debuginfo, setup was able to "install" the source code tarball.
A mirror (at least the mirror I use) does not have a source-code tarball
in a *-debuginfo subdirect
ash as the legitimate
package, in a computationally useful time frame.
But, that is not the value MD5 is providing to setup.exe. If you are
downloading a package from bad-actor.com, you are also downloading setup.ini
from there, so they can rewrite the hashes. Only if you take the extra step t
On 8/24/2015 2:22 PM, Andrey Repin wrote:
> Greetings, Dennis Putnam!
>
>> That is what I do. However, I discovered something else that may or may
>> not shed some light but I don't understand it. Again keeping in mind
>> that my browser has no trouble finding URLs, I tried 'nslookup' from a
>> com
On Mon, Aug 24, 2015 at 10:46 AM, Dennis Putnam wrote:
> On 8/24/2015 1:42 PM, Achim Gratz wrote:
>> Dennis Putnam writes:
>>> Again keeping in mind
>>> that my browser has no trouble finding URLs, I tried 'nslookup' from a
>>> command prompt and it can find nothing. The error is no response from
Greetings, Dennis Putnam!
> That is what I do. However, I discovered something else that may or may
> not shed some light but I don't understand it. Again keeping in mind
> that my browser has no trouble finding URLs, I tried 'nslookup' from a
> command prompt and it can find nothing. The error is
On 8/24/2015 1:42 PM, Achim Gratz wrote:
> Dennis Putnam writes:
>> That is what I do. However, I discovered something else that may or may
>> not shed some light but I don't understand it. Again keeping in mind
>> that my browser has no trouble finding URLs, I tried 'nslookup' from a
>> command pr
Dennis Putnam writes:
> That is what I do. However, I discovered something else that may or may
> not shed some light but I don't understand it. Again keeping in mind
> that my browser has no trouble finding URLs, I tried 'nslookup' from a
> command prompt and it can find nothing. The error is no r
On 8/24/2015 1:01 PM, Achim Gratz wrote:
> Dennis Putnam writes:
>>> Just to test if you can access it at all but that was expectable.
>> OK. I have no networking problems with anything other than cygwin which
>> is why I was asking for someone to explain how it interfaces with the OS
>> network. T
Dennis Putnam writes:
>> Just to test if you can access it at all but that was expectable.
> OK. I have no networking problems with anything other than cygwin which
> is why I was asking for someone to explain how it interfaces with the OS
> network. This all started with the Lavasoft malware and I
Dennis Putnam
Mon, 24 Aug 2015 07:41:00 -0400
---
> OK. I have no networking problems with anything other than cygwin which
Another idea:
You could download the packages needed for a basic install from any
server, e.g.:
ftp://ftp-stud.hs-esslinge
On 8/23/2015 7:34 PM, Helmut Karlowski wrote:
> Am 23.08.2015, 19:42 Uhr, schrieb Dennis Putnam:
>
>> Hi Helmut,
>>
>> Thanks for the reply. I can download that file but now that I have it,
>> how do I get setup to use it? However, I don't think that would work
>
> Just to test if you can access it
Am 23.08.2015, 19:42 Uhr, schrieb Dennis Putnam:
Hi Helmut,
Thanks for the reply. I can download that file but now that I have it,
how do I get setup to use it? However, I don't think that would work
Just to test if you can access it at all but that was expectable.
either since the problem
ror message. Clearly setup is having trouble communicating on
>> the network and it is probably related to something left over from the
>
> Have you tried to download setup.ini manually?
>
> Are you able to access for example:
>
> ftp://ftp-stud.hs-esslingen.de/pub/Mirrors/sour
lling Cygwin from scratch and it will not even
download the list of mirrors. If I add a specific mirror I get the same
subject error message. Clearly setup is having trouble communicating on
the network and it is probably related to something left over from the
Have you tried to download setu
Since I have gotten no response to this and am stuck I assume my problem
is badly worded. I don't know how else to present it. Perhaps someone
explaining how setup uses the windows network interface would help.
If it helps, I tried installing Cygwin from scratch and it will not even
download the l
In the process of correcting another problem (removed Lavasoft malware)
I am no longer able to run setup. All the references to this error seem
to pertain to the 32 bit version. I am completely shutdown with Cygwin
and need help resolving this. Thanks in advance.
signature.asc
Description: OpenP
On 16/08/2015 15:33, Marco Atzeri wrote:
On 16/08/2015 16:19, Emily Jackson wrote:
When I try to update cygwin I get an empty setup.ini file and the only
packages that appear are the ones I already have installed--they are all
listed under "Miscellaneous". I get this with every mirror
On 16/08/2015 16:19, Emily Jackson wrote:
When I try to update cygwin I get an empty setup.ini file and the only
packages that appear are the ones I already have installed--they are all
listed under "Miscellaneous". I get this with every mirror I try and on
two different PCs, bo
When I try to update cygwin I get an empty setup.ini file and the only
packages that appear are the ones I already have installed--they are all
listed under "Miscellaneous". I get this with every mirror I try and on
two different PCs, both running Windows 10. This is from setup.log:
201
I was looking at a fresh copy of setup.ini today, and I noticed this
requires: libcrypt0 libdb5.3 libgdbm4 libssp0 perl_base perl_base
and this
requires: perl perl_base cygwin
In the first example, perl_base is listed twice. In the second example, perl and
perl_base are listed. This is
Fergus Daly writes:
> Just done a check on md5sums in setup.ini setup-timestamp: 1428012611
> Usually the entries are of the style
> filename filesize md5sum
> but in setup.ini setup-timestamp: 1428012611 (and also I see earlier, so this
> is not entirely recent) there are entr
Just done a check on md5sums in setup.ini setup-timestamp: 1428012611
Usually the entries are of the style
filename filesize md5sum
but in setup.ini setup-timestamp: 1428012611 (and also I see earlier, so this
is not entirely recent) there are entries of the form
install: x86/release/dos2unix
> On 1/29/2015 19:57, Houder wrote:
[snip]
>> As far as I understand, -4 is the "best" release of version 4.8.3-*. Just
>> wondering ... I would say that
>> setup.ini SHOULD show -4 as previous. What do say?
>>
>
> -3 and -4 is broken iirc, I had to r
y, 2014)
> -3 17/08/14
> -4 15/11/14
>
> gcc 4.9.2-1 03/11/14 (euh? ... well, why not)
>
> Setup allows me to keep or UNinstall 4.8.3-4 (FOUR!), but NOT to retrieve
> that version of gcc ...
> Surprisingly, it allows me to retrieve version 4.8.3-2
s me to keep or UNinstall 4.8.3-4 (FOUR!), but NOT to retrieve that
version of gcc ...
Surprisingly, it allows me to retrieve version 4.8.3-2 ...
Looking at the latest setup.ini shows me the following for "gcc":
current: 4.9.2-1
previous: 4.8.3-2
As far as I understand, -4 is the &quo
On May 23 09:04, Sean Daugherty wrote:
> The x86_64 setup.ini has _autorebase listed as version 000149-1, but
> the files in release/_autorebase are for version 000152-1. Thus, setup
> fails for me due to a "Download Incomplete" error.
>
> Similarly, for x86, setup.i
The x86_64 setup.ini has _autorebase listed as version 000149-1, but
the files in release/_autorebase are for version 000152-1. Thus, setup
fails for me due to a "Download Incomplete" error.
Similarly, for x86, setup.ini refers to 000550-1 and
release/_autorebase only contains versio
On 19/03/2014 02:12, Andrew Jones wrote:
Apparently cygwin64-openssl is available in various locations on the
web, but the setup.ini file does not contain the necessary information
to download it and I dont understand it well enough to fix it. Can
someone please help? Or am I being stupid
Apparently cygwin64-openssl is available in various locations on the
web, but the setup.ini file does not contain the necessary information
to download it and I dont understand it well enough to fix it. Can
someone please help? Or am I being stupid?
--
Problem reports: http://cygwin.com
Charles Wilson writes:
> On 11/4/2013 11:00 AM, Christopher Faylor wrote:
>> On Mon, Nov 04, 2013 at 09:32:10AM -0500, Charles Wilson wrote:
>>> I've got a few cleanups, and then I'll share the result. It's already
>>> helped me generate a few re-packaging requests I plan to post over on
>>> cygwi
On 04/11/13 17:30, Charles Wilson wrote:
On 11/4/2013 11:00 AM, Christopher Faylor wrote:
On Mon, Nov 04, 2013 at 09:32:10AM -0500, Charles Wilson wrote:
I've got a few cleanups, and then I'll share the result. It's already
helped me generate a few re-packaging requests I plan to post over on
On 04/11/2013 11:00 AM, Christopher Faylor wrote:
On Mon, Nov 04, 2013 at 09:32:10AM -0500, Charles Wilson wrote:
On 10/30/2013 9:51 AM, Ryan Johnson wrote:
On 30/10/2013 8:48 AM, Charles Wilson wrote:
Yeah; even for my stripped-down version, I need to pre-process the
setup.ini and remove all
On Mon, Nov 04, 2013 at 09:32:10AM -0500, Charles Wilson wrote:
>On 10/30/2013 9:51 AM, Ryan Johnson wrote:
>> On 30/10/2013 8:48 AM, Charles Wilson wrote:
>>> Yeah; even for my stripped-down version, I need to pre-process the
>>> setup.ini and remove all mentions of
On 10/30/2013 9:51 AM, Ryan Johnson wrote:
On 30/10/2013 8:48 AM, Charles Wilson wrote:
Yeah; even for my stripped-down version, I need to pre-process the
setup.ini and remove all mentions of cygwin, libstdc++6, libgcc1, etc.
The ncurses DLLs are also a huge nexus. (It's probably easi
27; to generate the dependency graph in whatever format you
require. Put the perl script and your 'setup.ini' file in the same
directory and type:
./graph_setup_ini.pl | dot -Tpdf -osetup.pdf
Thanks, that worked well.
Your problem here is Big Data: Cygwin has 3041 packages, and
ever format you
require. Put the perl script and your 'setup.ini' file in the same
directory and type:
./graph_setup_ini.pl | dot -Tpdf -osetup.pdf
Thanks, that worked well.
Your problem here is Big Data: Cygwin has 3041 packages, and any
dependency graph with this number of nodes is
On 10/27/2013 1:00 AM, Linda Walsh wrote:
On 10/25/2013 5:29 PM, Ryan Johnson wrote:
On 25/10/2013 12:12 PM, Charles Wilson wrote:
Does anybody have a script or a tool that can parse a setup.ini and
generate a dependency graph? I'm using pmcyg to create a
stripped-down standalone install
On 10/25/2013 5:29 PM, Ryan Johnson wrote:
On 25/10/2013 12:12 PM, Charles Wilson wrote:
Does anybody have a script or a tool that can parse a setup.ini and
generate a dependency graph? I'm using pmcyg to create a
stripped-down standalone installation CD and it's too big, so I&#x
On 25/10/13 17:12, Charles Wilson wrote:
Does anybody have a script or a tool that can parse a setup.ini and
generate a dependency graph? I'm using pmcyg to create a
stripped-down standalone installation CD and it's too big, so I'm
trying to figure out where the culprit is th
On 25/10/2013 12:12 PM, Charles Wilson wrote:
Does anybody have a script or a tool that can parse a setup.ini and
generate a dependency graph? I'm using pmcyg to create a
stripped-down standalone installation CD and it's too big, so I'm
trying to figure out where the culprit is
Does anybody have a script or a tool that can parse a setup.ini and
generate a dependency graph? I'm using pmcyg to create a stripped-down
standalone installation CD and it's too big, so I'm trying to figure out
where the culprit is that's pulling in so much stuff...
On 7/10/2013 17:52, JonY wrote:
> On 7/10/2013 06:35, Angelo Graziosi wrote:
>> Setup.exe has updates (4.5.3 ==> 4.7.3) for mingw64-i686-gcc-core but
>> not for other language (fortran, g++ etc.).
>>
>> Beside this, it wants install mingw64-i686-gcc-debuginfo.. Usually
>> *debuginfo packages are op
On 7/10/2013 06:35, Angelo Graziosi wrote:
> Setup.exe has updates (4.5.3 ==> 4.7.3) for mingw64-i686-gcc-core but
> not for other language (fortran, g++ etc.).
>
> Beside this, it wants install mingw64-i686-gcc-debuginfo.. Usually
> *debuginfo packages are optional not mandatory.. Or not?
>
It
Setup.exe has updates (4.5.3 ==> 4.7.3) for mingw64-i686-gcc-core but
not for other language (fortran, g++ etc.).
Beside this, it wants install mingw64-i686-gcc-debuginfo.. Usually
*debuginfo packages are optional not mandatory.. Or not?
Ciao,
Angelo.
--
Problem reports: http://cygwi
Greetings, Christopher Faylor!
>>Setup64.exe downloaded from cygwin.com is trying to access
>>$MIRROR/x86_64/setup.ini instead of actually present setup64.ini
> You likely aren't using ftp://cygwin.com/64bit/setup64.exe . That is
> the version you should be using for
On Fri, Jun 28, 2013 at 10:55:19PM +0400, Andrey Repin wrote:
>Greetings, All!
>
>Setup64.exe downloaded from cygwin.com is trying to access
>$MIRROR/x86_64/setup.ini instead of actually present setup64.ini
You likely aren't using ftp://cygwin.com/64bit/setup64.exe . That i
Greetings, All!
Setup64.exe downloaded from cygwin.com is trying to access
$MIRROR/x86_64/setup.ini instead of actually present setup64.ini
---
Cygwin Setup
---
Unable to get x86_64/setup.ini from <http://cygwin.cybermirror.
marco atzeri gmail.com> writes:
> On 4/28/2013 6:31 PM, I wrote:
> > Is setup.ini out of sync with the package files? The latest setup.ini
file
> > references 70 files that don't exist on any mirror that I've checked.
Here's
> > the first 10 non-exis
On 4/28/2013 6:31 PM, Fran L. wrote:
Is setup.ini out of sync with the package files? The latest setup.ini file
references 70 files that don't exist on any mirror that I've checked. Here's
the first 10 non-existent files:
release/gnome/gnome-common/gnome-common-3.7.4-1.tar.bz2
Is setup.ini out of sync with the package files? The latest setup.ini file
references 70 files that don't exist on any mirror that I've checked. Here's
the first 10 non-existent files:
release/gnome/gnome-common/gnome-common-3.7.4-1.tar.bz2
release/gnome/gnome-keyring/gnome-
On Tue, Aug 28, 2012 at 01:29:53PM -0500, Yaakov (Cygwin/X) wrote:
>On Tue, 2012-08-28 at 09:53 +0100, Fergus wrote:
>> In the latest setup.ini timestamp 1346110211 the subdirectory
>> release/Ruby has replaced the prviously named release/ruby. The new
>> release/Ruby/ ha
On Tue, 2012-08-28 at 09:53 +0100, Fergus wrote:
> In the latest setup.ini timestamp 1346110211 the subdirectory
> release/Ruby has replaced the prviously named release/ruby. The new
> release/Ruby/ has a subdirectory ruby/ with subdirectories as for the
> old release/ruby/.
In the latest setup.ini timestamp 1346110211 the subdirectory
release/Ruby has replaced the prviously named release/ruby. The new
release/Ruby/ has a subdirectory ruby/ with subdirectories as for the
old release/ruby/. So this new architecture looks weird but might be
intentional. Is it
Sorry, my mistake,
all is OK, the entry is included
Roman Pach
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Hi,
there is no entry for perl-libwin32
in the last setup.ini with
setup-timestamp: 1342941674
Roman Pach
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http
The current setup.ini timestamp 1329084611 mentions both
base-files-4.0-9.tar.bz2 (current)
base-files-4.0-8.tar.bz2 (prev)
but mirrors now have only 0-5, 0-6, 0-9. Please could setup.ini be
revised (or mirrors resourced) so that all of [prev] are available?
Thank you.
Fergus
--
Problem
On Nov 21 10:22, Fergus wrote:
> All install: references in latest setup.ini timestamp 1321833972 are to
> /sourceware/ftp/anonftp/pub/cygwin/release/..
> instead of
> release/..
> Fergus
I just checked on sourceware. Latest setup.ini has timestamp 1321869647
and the install re
All install: references in latest setup.ini timestamp 1321833972 are to
/sourceware/ftp/anonftp/pub/cygwin/release/..
instead of
release/..
Fergus
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com
1 - 100 of 295 matches
Mail list logo
