Re: Base 64-bit Cygwin now requires Perl? (indent DONE)
On Nov 2 09:33, Jari Aalto wrote: > 2014-11-01 21:16 Corinna Vinschen : > | > | > > indent > | > > | > Not sure this is needed either. > | > | Removed on sourceware. > | > | Jari, can you please keep track of this change? > > Uploaded new x64 *-2 without texinfo dependency. Thanks! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpfpVdnr_H8E.pgp Description: PGP signature
Re: Setup 2.774 texlive postinstall takes 10+ hours
On Nov 2 13:02, Ken Brown wrote: > On 10/30/2014 6:27 PM, Don MacDougall wrote: > >So, why the > >postinst scripts failed to run before, now becomes an academic matter for > >me. > > Nevertheless, let me point out for the sake of the archives that the answer > was contained in one of your earlier messages: > > On 10/24/2014 3:11 AM, Don MacDougall wrote: > > Can't fork, trying again in 5 seconds at /usr/bin/updmap line 59. > >7 [main] perl 8088 child_info_fork::abort: unable to remap Fcntl.dll > > to same address as parent (0x2E) - try running rebaseall > > The problem is that many of the texlive postinstall scripts run perl > scripts, and these failed as above because rebaseall needed to be run. I > guess this problem will occur whenever perl and texlive are installed > simultaneously. > > I'm not sure what the solution is. Would it be hard to tweak setup.exe so > that it runs the autorebase postinstall script before running any others? > Or would this be a bad idea for other reasons? Off the top of my head I don't know how hard that would be, but it doesn't sound like an especially bad idea to me. Au contraire. The only reasons not to do that would be if an installer script would move DLLs around (Do we have that? I hope not) or if there's a simpler solution. One thing we could test is if we can't get away without tweaking setup.exe, by changing the dependencies only. Right now _autorebase requires rebase and dash packages. Both are in Base anyway, but they pull in more dependencies which result in something like a rat tail of dependencies. So I'm wondering if tweaking _autorebase' setup.hint file like this: sdesc: "Run rebaseall automatically" #external-source: rebase category: _PostInstallLast -requires: rebase dash autodep: .*/[^/]*\.(?:dll|so|oct)$ incver_ifdep: yes +noautodep: cygwin and tweaking cygwin's setup.hint file like this: sdesc: "The UNIX emulation engine" category: Base -requires: base-cygwin +requires: base-cygwin _autorebase noautodep: _update-info-dir autodep: .* would do the trick. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp7osbGwhJqu.pgp Description: PGP signature
Re: Setup 2.774 texlive postinstall takes 10+ hours
On 11/3/2014 5:25 AM, Corinna Vinschen wrote: On Nov 2 13:02, Ken Brown wrote: On 10/30/2014 6:27 PM, Don MacDougall wrote: So, why the postinst scripts failed to run before, now becomes an academic matter for me. Nevertheless, let me point out for the sake of the archives that the answer was contained in one of your earlier messages: On 10/24/2014 3:11 AM, Don MacDougall wrote: Can't fork, trying again in 5 seconds at /usr/bin/updmap line 59. 7 [main] perl 8088 child_info_fork::abort: unable to remap Fcntl.dll to same address as parent (0x2E) - try running rebaseall The problem is that many of the texlive postinstall scripts run perl scripts, and these failed as above because rebaseall needed to be run. I guess this problem will occur whenever perl and texlive are installed simultaneously. I'm not sure what the solution is. Would it be hard to tweak setup.exe so that it runs the autorebase postinstall script before running any others? Or would this be a bad idea for other reasons? Off the top of my head I don't know how hard that would be, but it doesn't sound like an especially bad idea to me. Au contraire. The only reasons not to do that would be if an installer script would move DLLs around (Do we have that? I hope not) or if there's a simpler solution. One thing we could test is if we can't get away without tweaking setup.exe, by changing the dependencies only. Right now _autorebase requires rebase and dash packages. Both are in Base anyway, but they pull in more dependencies which result in something like a rat tail of dependencies. So I'm wondering if tweaking _autorebase' setup.hint file like this: It's worth a try. sdesc: "Run rebaseall automatically" #external-source: rebase category: _PostInstallLast ^^^ Wouldn't we also have to get rid of this? -requires: rebase dash autodep: .*/[^/]*\.(?:dll|so|oct)$ incver_ifdep: yes +noautodep: cygwin and tweaking cygwin's setup.hint file like this: sdesc: "The UNIX emulation engine" category: Base -requires: base-cygwin +requires: base-cygwin _autorebase noautodep: _update-info-dir autodep: .* would do the trick. Ken -- 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
Re: Setup 2.774 texlive postinstall takes 10+ hours
On Nov 3 07:43, Ken Brown wrote: > On 11/3/2014 5:25 AM, Corinna Vinschen wrote: > >On Nov 2 13:02, Ken Brown wrote: > >>On 10/30/2014 6:27 PM, Don MacDougall wrote: > >>>So, why the > >>>postinst scripts failed to run before, now becomes an academic matter for > >>>me. > >> > >>Nevertheless, let me point out for the sake of the archives that the answer > >>was contained in one of your earlier messages: > >> > >>On 10/24/2014 3:11 AM, Don MacDougall wrote: > >>>Can't fork, trying again in 5 seconds at /usr/bin/updmap line 59. > >>>7 [main] perl 8088 child_info_fork::abort: unable to remap > >>> Fcntl.dll > >>>to same address as parent (0x2E) - try running rebaseall > >> > >>The problem is that many of the texlive postinstall scripts run perl > >>scripts, and these failed as above because rebaseall needed to be run. I > >>guess this problem will occur whenever perl and texlive are installed > >>simultaneously. > >> > >>I'm not sure what the solution is. Would it be hard to tweak setup.exe so > >>that it runs the autorebase postinstall script before running any others? > >>Or would this be a bad idea for other reasons? > > > >Off the top of my head I don't know how hard that would be, but it > >doesn't sound like an especially bad idea to me. Au contraire. > > > >The only reasons not to do that would be if an installer script would > >move DLLs around (Do we have that? I hope not) or if there's a simpler > >solution. > > > >One thing we could test is if we can't get away without tweaking > >setup.exe, by changing the dependencies only. Right now _autorebase > >requires rebase and dash packages. Both are in Base anyway, but they > >pull in more dependencies which result in something like a rat tail of > >dependencies. So I'm wondering if tweaking _autorebase' setup.hint file > >like this: > > It's worth a try. > > > sdesc: "Run rebaseall automatically" > > #external-source: rebase > > category: _PostInstallLast > ^^^ > Wouldn't we also have to get rid of this? This is just a category name, and to the best of my knowledge there's no special handling in terms of this category name in either setup or upset. It just starts with an underscore so that packages in this category don't show up in setup's package selection by default. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp8qWtS0rT4l.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.4
On Nov 1 18:40, Corinna Vinschen wrote:
> On Nov 1 17:58, Christian Franke wrote:
> > Corinna Vinschen wrote:
> > >I just released a 4th TEST version of the next upcoming Cygwin release,
> > >1.7.33-0.4.
> >
> > There is an older regression in mkgroup.
> > A separator without a preceding domain name is printed for the builtin
> > groups:
> >
> > $ mkgroup -L THISHOST
> > SYSTEM:S-1-5-18:18:
> > TrustedInstaller:S-1-5-80-...
> > +Administratoren:S-1-5-32-544:544:
> > +Benutzer:S-1-5-32-545:545:
> > ...
> > THISHOST+HelpLibraryUpdaters:S-1-5-21-...
> >
> >
> > Introduced in mkgroup.c CVS 1.54, April 2014:
> >
> > @@ -415,8 +341,8 @@ enum_local_groups (...)
> > ...
> > printf ("%ls%s%ls:%s:%" PRIu32 ":\n",
> > - with_dom && !is_builtin ? domain_name : L"",
> > - with_dom && !is_builtin ? sep : "",
> > + mach->with_dom && !is_builtin ? domain_name : L"",
> > + mach->with_dom || is_builtin ? sep : "", < Hmm :-)
>
> Thanks! It would be nice if you could send a patch to cygwin-patches.
Never mind, I applied a patch.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpha4vId_ro_.pgp
Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.4
> On Nov 1 17:58, Christian Franke wrote:
>> Corinna Vinschen wrote:
>> >I just released a 4th TEST version of the next upcoming Cygwin release,
>> >1.7.33-0.4.
>>
>> There is an older regression in mkgroup.
>> A separator without a preceding domain name is printed for the builtin
>> groups:
>>
>> $ mkgroup -L THISHOST
>> SYSTEM:S-1-5-18:18:
>> TrustedInstaller:S-1-5-80-...
>> +Administratoren:S-1-5-32-544:544:
>> +Benutzer:S-1-5-32-545:545:
>> ...
>> THISHOST+HelpLibraryUpdaters:S-1-5-21-...
>>
>>
>> Introduced in mkgroup.c CVS 1.54, April 2014:
>>
>> @@ -415,8 +341,8 @@ enum_local_groups (...)
>> ...
>> printf ("%ls%s%ls:%s:%" PRIu32 ":\n",
>> - with_dom && !is_builtin ? domain_name : L"",
>> - with_dom && !is_builtin ? sep : "",
>> + mach->with_dom && !is_builtin ? domain_name : L"",
>> + mach->with_dom || is_builtin ? sep : "", < Hmm :-)
>
> Thanks! It would be nice if you could send a patch to cygwin-patches.
>
>> BTW: mkgroup should possibly also print the extra builtin groups which are
>> now reported by getgroups(), for example 4(Interactive), 11(Authenticated
>> Users), ...
>
> Doesn't make much sense. Generating them via "db" is incredibly fast.
> There is also one person on the list (sorry, don't remember your name)
Me, perhaps? (Henri) ... https://cygwin.com/ml/cygwin/2014-10/msg00491.html
My "nsswitch.conf":
passwd:files
group: files
db_enum: files
In short, no problem at my end: id shows the short list (as before ...)
> claiming he would rather not see the big group list in id while using
> the "files"-only setting.
>
>
> Corinna
=
--
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
Re: Setup 2.774 texlive postinstall takes 10+ hours
On Nov 3 15:52, Corinna Vinschen wrote: > On Nov 3 07:43, Ken Brown wrote: > > On 11/3/2014 5:25 AM, Corinna Vinschen wrote: > > >On Nov 2 13:02, Ken Brown wrote: > > >>On 10/24/2014 3:11 AM, Don MacDougall wrote: > > >>>Can't fork, trying again in 5 seconds at /usr/bin/updmap line 59. > > >>>7 [main] perl 8088 child_info_fork::abort: unable to remap > > >>> Fcntl.dll > > >>>to same address as parent (0x2E) - try running rebaseall > > >> > > >>The problem is that many of the texlive postinstall scripts run perl > > >>scripts, and these failed as above because rebaseall needed to be run. I > > >>guess this problem will occur whenever perl and texlive are installed > > >>simultaneously. > > >> > > >>I'm not sure what the solution is. Would it be hard to tweak setup.exe so > > >>that it runs the autorebase postinstall script before running any others? > > >>Or would this be a bad idea for other reasons? > > > > > >Off the top of my head I don't know how hard that would be, but it > > >doesn't sound like an especially bad idea to me. Au contraire. > > > > > >The only reasons not to do that would be if an installer script would > > >move DLLs around (Do we have that? I hope not) or if there's a simpler > > >solution. > > > > > >One thing we could test is if we can't get away without tweaking > > >setup.exe, by changing the dependencies only. Right now _autorebase > > >requires rebase and dash packages. Both are in Base anyway, but they > > >pull in more dependencies which result in something like a rat tail of > > >dependencies. So I'm wondering if tweaking _autorebase' setup.hint file > > >like this: > > > > It's worth a try. I changed that now on sourceware, but please keep in mind that this doesn't solve all problems. Assuming you update a few packages and then start setup again and install some more packages, then the version number of the _autorebase package hasn't changed and it won't be started by the second setup run. Only if a package gets updated which comes with DLLs, the _autorebase version number is bumped on the server and only then it will be started by setup anew. Same thing for _update-info-dir, but with minor consequences. In theory, we could need a solution which is built into setup, and which makes setup re-run the _autorebase script every time a package with DLLs is updated or installed. Analog for _update-info-dir. The dependency thingy is fine in upset, but the logic needs some support on the client side it seems. I would not be too unhappy if somebody would like to take a stab at setup's code for this... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp0cNZ5htxWV.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.4
On Nov 3 16:09, Houder wrote:
> > On Nov 1 17:58, Christian Franke wrote:
> >> Corinna Vinschen wrote:
> >> >I just released a 4th TEST version of the next upcoming Cygwin release,
> >> >1.7.33-0.4.
> >>
> >> There is an older regression in mkgroup.
> >> A separator without a preceding domain name is printed for the builtin
> >> groups:
> >>
> >> $ mkgroup -L THISHOST
> >> SYSTEM:S-1-5-18:18:
> >> TrustedInstaller:S-1-5-80-...
> >> +Administratoren:S-1-5-32-544:544:
> >> +Benutzer:S-1-5-32-545:545:
> >> ...
> >> THISHOST+HelpLibraryUpdaters:S-1-5-21-...
> >>
> >>
> >> Introduced in mkgroup.c CVS 1.54, April 2014:
> >>
> >> @@ -415,8 +341,8 @@ enum_local_groups (...)
> >> ...
> >> printf ("%ls%s%ls:%s:%" PRIu32 ":\n",
> >> - with_dom && !is_builtin ? domain_name : L"",
> >> - with_dom && !is_builtin ? sep : "",
> >> + mach->with_dom && !is_builtin ? domain_name : L"",
> >> + mach->with_dom || is_builtin ? sep : "", < Hmm
> >> :-)
> >
> > Thanks! It would be nice if you could send a patch to cygwin-patches.
> >
> >> BTW: mkgroup should possibly also print the extra builtin groups which are
> >> now reported by getgroups(), for example 4(Interactive), 11(Authenticated
> >> Users), ...
> >
> > Doesn't make much sense. Generating them via "db" is incredibly fast.
> > There is also one person on the list (sorry, don't remember your name)
>
> Me, perhaps? (Henri) ... https://cygwin.com/ml/cygwin/2014-10/msg00491.html
It might have been you, but it's not that thread. I'm referring to
some discussion a few months ago when I asked for testing the new
stuff in the snapshots. My memory for names is really bad, sorry.
> My "nsswitch.conf":
>
> passwd:files
> group: files
>
> db_enum: files
>
> In short, no problem at my end: id shows the short list (as before ...)
The question would be: What's the problem with the long list from id?
Enumerating the builtin accounts is very fast and you shouldn't have
any downside. On the upside, *iff* there are files owned by some
account not listed in /etc/passwd or /etc/group, the additional "db"
setting would still allow to show the ownership correctly...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpMiqT4bVeqB.pgp
Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.4
>> > Doesn't make much sense. Generating them via "db" is incredibly fast. >> > There is also one person on the list (sorry, don't remember your name) >> >> Me, perhaps? (Henri) ... https://cygwin.com/ml/cygwin/2014-10/msg00491.html > > It might have been you, but it's not that thread. I'm referring to > some discussion a few months ago when I asked for testing the new > stuff in the snapshots. My memory for names is really bad, sorry. February perhaps? I made a similar remark about the output of id then ... https://cygwin.com/ml/cygwin/2014-02/msg00545.htm >> My "nsswitch.conf": >> >> passwd:files >> group: files >> >> db_enum: files >> >> In short, no problem at my end: id shows the short list (as before ...) > > The question would be: What's the problem with the long list from id? > Enumerating the builtin accounts is very fast and you shouldn't have > any downside. On the upside, *iff* there are files owned by some > account not listed in /etc/passwd or /etc/group, the additional "db" > setting would still allow to show the ownership correctly... Should? :-) I have no doubt that you did an excellent job ... and that it all very fast ... Perhaps, it is mere matter of perspective ? - you want to be informed "about what the machine does" ... - I am only interested in "my files" (a specific point on the filesystem), a point where I have "rucksichtlos" eliminated all references to identities I do not care about (as I noted before, Windows is not really 'my cup of tea') In short, there is no problem that requires your immediate attention. And I am happy, that I can still control Cygwin to do it in the "old-fashioned" way. Sorry. Regards, Henri = -- 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
Re: Setup 2.774 texlive postinstall takes 10+ hours
Corinna Vinschen writes: > Off the top of my head I don't know how hard that would be, but it > doesn't sound like an especially bad idea to me. Au contraire. It should be quite easy since the postinstall scripts are run in POSIX sort order. Just give the script a name like 1_autorebase.bat and it should always be the first one that runs. > One thing we could test is if we can't get away without tweaking > setup.exe, by changing the dependencies only. Right now _autorebase > requires rebase and dash packages. Both are in Base anyway, but they > pull in more dependencies which result in something like a rat tail of > dependencies. So I'm wondering if tweaking _autorebase' setup.hint file > like this: Dependencies are not evaluated at all when installing or running scripts. But it would really be better to use triggers for these sort of scripts. I have something implemented for my "perpetual" postinstall that does an incremental rebase after each setup run, but it could be extended to be controlled by setup.ini instead of a naming convention. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html -- 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
[ANNOUNCEMENT] Updated: unzip-6.0-11
The following package has been updated in the Cygwin distribution: * unzip-6.0-11 UnZip is an extraction utility for archives compressed in .zip format. Although highly compatible both with PKWARE's PKZIP and PKUNZIP utilities for MS-DOS and with Info-ZIP's own Zip program, the primary objective is portability and non-MSDOS functionality. This release adds the current patchset from Fedora. -- Yaakov -- 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
gcc packaging bug?
The setup.hint files for gcc and its subpackages now say curr: 4.8.3-2 prev: 4.8.3-3 test: 4.9.2-1 I assume this is a typo; it causes everyone who is not installing the test release to get downgraded from 4.8.3-3 to 4.8.3-2. Ken -- 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
Re: Setup 2.774 texlive postinstall takes 10+ hours
On 11/3/2014 1:03 PM, Achim Gratz wrote: Corinna Vinschen writes: Off the top of my head I don't know how hard that would be, but it doesn't sound like an especially bad idea to me. Au contraire. It should be quite easy since the postinstall scripts are run in POSIX sort order. That's now what I see here, unless I'm badly confused about what POSIX sort order is. I did an update a few days ago in which the postinstall scripts were run in the following order: update-info-dir.sh autorebase.bat wget.sh Just give the script a name like 1_autorebase.bat and it should always be the first one that runs. One thing we could test is if we can't get away without tweaking setup.exe, by changing the dependencies only. Right now _autorebase requires rebase and dash packages. Both are in Base anyway, but they pull in more dependencies which result in something like a rat tail of dependencies. So I'm wondering if tweaking _autorebase' setup.hint file like this: Dependencies are not evaluated at all when installing or running scripts. But it would really be better to use triggers for these sort of scripts. I have something implemented for my "perpetual" postinstall that does an incremental rebase after each setup run, but it could be extended to be controlled by setup.ini instead of a naming convention. Ken -- 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
Re: gcc packaging bug?
On 11/4/2014 05:46, Ken Brown wrote: > The setup.hint files for gcc and its subpackages now say > > curr: 4.8.3-2 > prev: 4.8.3-3 > test: 4.9.2-1 > > I assume this is a typo; it causes everyone who is not installing the > test release to get downgraded from 4.8.3-3 to 4.8.3-2. No, this is deliberate, 4.8.3-3 is bugged, it could not build later versions of gcc. signature.asc Description: OpenPGP digital signature
Re: gcc packaging bug?
On 11/4/2014 06:04, JonY wrote: > On 11/4/2014 05:46, Ken Brown wrote: >> The setup.hint files for gcc and its subpackages now say >> >> curr: 4.8.3-2 >> prev: 4.8.3-3 >> test: 4.9.2-1 >> >> I assume this is a typo; it causes everyone who is not installing the >> test release to get downgraded from 4.8.3-3 to 4.8.3-2. > > No, this is deliberate, 4.8.3-3 is bugged, it could not build later > versions of gcc. > I forgot to mention 4.8.3-4 will be uploaded soon to fix the problem atexit use in libgcc. It was causing configure failures in stage1 libgcc by causing link test to return $? 0 even if it failed. signature.asc Description: OpenPGP digital signature
qt5 announce please
Hello, Could somebody please tell us a little bit more about the new qt5-related packages that we received recently (at least for x86)? Perhaps unrelated, i cannot compile cmake-3.1.0-rc1 any more since that. Thanks in advance. Denis Excoffier. -- 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
Re: gcc packaging bug?
On 2014-11-03 16:04, JonY wrote: On 11/4/2014 05:46, Ken Brown wrote: The setup.hint files for gcc and its subpackages now say curr: 4.8.3-2 prev: 4.8.3-3 test: 4.9.2-1 I assume this is a typo; it causes everyone who is not installing the test release to get downgraded from 4.8.3-3 to 4.8.3-2. No, this is deliberate, 4.8.3-3 is bugged, it could not build later versions of gcc. How so? -- Yaakov -- 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
[ANNOUNCEMENT] Updated: gcc-4.9.2-1 (x86/x86_64) (Test)
gcc-4.9.2-1 has been uploaded for 32bit and 64bit Cygwin. This version is set to test. Note that any C++ code built with this version WILL NOT RUN on earlier versions of Cygwin (1.7.32-1). *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. signature.asc Description: OpenPGP digital signature
Re: terminfo and /usr/share/terminfo requirement
On Fri, Oct 31, 2014 at 5:10 PM, Corinna Vinschen wrote:
>
> There's no /share directory in a standard Cygwin installation. /usr is
> a real dir within your Cygwin installation dir. It doesn't have to be
> mounted, nor does /usr/share, which is also created by setup-${arch}.exe
> by default.
>
So straight out of the archive, we have a PREFIX/usr directory which
contains a few other items including a share/ directory. If you now
start Cygwin the output of /bin/mount will show /usr/bin and /usr/lib
are automounted. That is not true for /usr/share. This causes the
terminal interface to be broken because /usr/share/terminfo cannot be
found. If I then 'mount `cygpath -m /` /usr' the terminal interface
finds /usr/share/terminfo and all is fine and works well.
It is true that I am not using setup-${arch}.exe but that shouldn't
matter as long as I have the dependencies resolved.
--
cyg Simple
--
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
Re: qt5 announce please
On 2014-11-03 16:10, Denis Excoffier wrote:
Could somebody please tell us a little bit more about the new qt5-related
packages that we received recently (at least for x86)?
https://cygwin.com/ml/cygwin-xfree-announce/2014-10/msg9.html
Perhaps unrelated, i cannot compile cmake-3.1.0-rc1 any more since that.
http://sourceforge.net/p/cygwin-ports/cmake/ci/master/tree/2.8.12-gui-qt4.patch
or, presumably, inherit qt5 instead of qt4 and change the boostrap
argument to --qt-qmake=${QT5_QMAKE}.
--
Yaakov
--
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
Re: terminfo and /usr/share/terminfo requirement
On 2014-11-03 16:14, cyg Simple wrote:
It is true that I am not using setup-${arch}.exe but that shouldn't
matter as long as I have the dependencies resolved.
Yes, it does matter; Cygwin setup is the only supported method of
creating and managing a Cygwin installation. Please try again from
scratch with Cygwin setup and you will see that there is absolutely no
need for a /usr/share => /share mount.
Yaakov
--
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
Re: gcc packaging bug?
On 11/4/2014 06:11, Yaakov Selkowitz wrote: > On 2014-11-03 16:04, JonY wrote: >> On 11/4/2014 05:46, Ken Brown wrote: >>> The setup.hint files for gcc and its subpackages now say >>> >>> curr: 4.8.3-2 >>> prev: 4.8.3-3 >>> test: 4.9.2-1 >>> >>> I assume this is a typo; it causes everyone who is not installing the >>> test release to get downgraded from 4.8.3-3 to 4.8.3-2. >> >> No, this is deliberate, 4.8.3-3 is bugged, it could not build later >> versions of gcc. > > How so? As explained in the other email, it made failed link test return $? 0 anyway. This broke the stage 1 libgcc configure tests. Reverting to an older version of gcc and then using it to build 4.9.2-1 succeeded. I also used 4.9.2-1 to build a copy of itself as test, seems like it works. The only real change was changing atexit use to __cxa_atexit in libgcc. Corinna mentioned some problems with gcc misoptimizing atexit over IRC. signature.asc Description: OpenPGP digital signature
Re: qt5 announce please
On 2014-11-03 23:17, Yaakov Selkowitz wrote:
>
> On 2014-11-03 16:10, Denis Excoffier wrote:
>> Could somebody please tell us a little bit more about the new qt5-related
>> packages that we received recently (at least for x86)?
>
> https://cygwin.com/ml/cygwin-xfree-announce/2014-10/msg9.html
Oh, sorry, i was not aware of this cygwin-xfree-announce list.
>
>> Perhaps unrelated, i cannot compile cmake-3.1.0-rc1 any more since that.
>
> http://sourceforge.net/p/cygwin-ports/cmake/ci/master/tree/2.8.12-gui-qt4.patch
>
> or, presumably, inherit qt5 instead of qt4 and change the boostrap argument
> to --qt-qmake=${QT5_QMAKE}.
Thanks for the hints.
Regards,
Denis Excoffier.
--
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
Re: terminfo and /usr/share/terminfo requirement
On Mon, Nov 3, 2014 at 5:23 PM, Yaakov Selkowitz wrote:
> On 2014-11-03 16:14, cyg Simple wrote:
>>
>> It is true that I am not using setup-${arch}.exe but that shouldn't
>> matter as long as I have the dependencies resolved.
>
>
> Yes, it does matter; Cygwin setup is the only supported method of creating
> and managing a Cygwin installation. Please try again from scratch with
> Cygwin setup and you will see that there is absolutely no need for a
> /usr/share => /share mount.
Are you saying setup or some post install file doesn't mount
/usr/share? If a mounted /usr/share isn't important then why is
/usr/bin and /usr/lib automounted?
--
cyg Simple
--
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
Re: bug/deficiency in unzip: large files not supported?
On 2014-10-30 19:01, Brent wrote: I have encountered an inconsistency between cygwin's zip and unzip programs that I think reflects a bug (or incomplete implementation) in unzip. The issue: zip can successfully archive large (> 4 GiB) files that unzip cannot extract. Could you please try again with the new upset-6.0-11? -- Yaakov -- 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
Mailing link notes
Please change the html code for the notes at https://cygwin.com/lists.html#notes from to on the hope visitors will pay (more) attention to them. Also, may I suggest that we add a note to emphasize that a default recipient list in reply-to the list should be modified, if necessary, to include the list address only. The email addresses of the original poster, well known personalities, and other list members should not be included in the recipient lists. E.g. "* Please edit the recipient list to only reference the list address in posts and replies." Thanks, Doug -- Doug Henderson, Calgary, Alberta, Canada -- 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
Re: gcc packaging bug?
On 3 November 2014 14:46, Ken Brown wrote: > The setup.hint files for gcc and its subpackages now say > > curr: 4.8.3-2 > prev: 4.8.3-3 > test: 4.9.2-1 Setup-x86_64.exe is reporting that cygwin-devel is a dependency of gcc-core now. Is this an intentional change? Doug -- Doug Henderson, Calgary, Alberta, Canada -- 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
Re: bug/deficiency in unzip: large files not supported?
On 2014-11-03 15:19:05-0600, Yaakov Selkowitz wrote: >On 2014-10-30 19:01, Brent wrote: >>I have encountered an inconsistency between cygwin's zip and unzip programs >>that I think reflects a bug (or incomplete implementation) in unzip. >>The issue: zip can successfully archive large (> 4 GiB) files that unzip >>cannot extract. >Could you please try again with the new upset-6.0-11? Yaakov: I just downloaded unzip-6.0-11. (Freudian slip with the upset?!). Thanks much for the update! I can verify that cygwin unzip passes my large file tests perfectly now. I used a 5 GiB sized file filled with pseudo random data, but that should exceed the old 4 GiB file size limitation well enough. I used all 4 combinations of Java and cygwin to archive and extract that file, verifying each time that the extraction perfectly reproduced the original large file, byte for byte. Any thoughts on the bug that I found with cygwin unzip regarding its unicode handling? In particular, cygwin unzip seems to work with cygwin zip, but cannot extract archives produced by multiple other mainstream zip programs. My last email detailing this is https://cygwin.com/ml/cygwin/2014-11/msg00023.html -- 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
