Defaulting to stabs debug output from AS Cygwin64

[Michael Enright]

I am working on a little compiler for fun, which generates assembly
code. At this point I manually invoke as and ld.

For debugging I added the -g option to the invocation of as, but then
ld failed with

 t.o:t.s:1:(.stab+0x14): relocation truncated to fit: R_X86_64_32
against `.text'

Looking into this on Stack Overflow I was taught that stabs is
obsolete. I think 'obsolete' may not be quite the right
interpretation, but 'wrong for Cygwin64' could be the right story.
Practically speaking, without thinking about it too critically,
-gdwarf2 in place of -g is the solution.

I'm trying to find authority for saying anything exact about the situation:
1) Is there a reason why stabs is the default for '-g' with Cygwin64?
1a) Is a patch desired to make dwarf2 the default?
2) Is there a way within Cygwin64 that a .o file with stabs can be
properly processed by ld to give proper input to gdb?
3) Is stabs fatally flawed for the purposes of Cygwin64 or could it be
upgraded, within the existing meaning of the stabs specification, so
that it would work?
3a) To put it another way, is this just a stabs bug that could be
fixed for Cygwin64?

Above when I say Cygwin64, I'm talking about straightforward native
use of as, ld, and gdb, not cross-compiling to some other platform.

--
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: Request new Ruby release

[Steven Penny]

On Mon, 14 May 2018 10:31:18, cyg Simple wrote:

because they have merit? i said that already.



Since you stated in the form of a question, I can say for me, they do
not and based on the conversation of others, not for anyone but you.


let me rephrase: they have merit, full stop. Example 1, quoting myself:


yaakov said he would look into it after 2.5.1 came out


fact. here is the proof:

http://github.com/cygwinports/ruby/issues/1

Example 2, quoting myself again:


and its out:


fact. here is the proof:

http://github.com/ruby/ruby/releases/tag/v2_5_1

Example 3, quoting myself again:


and yaakov handles a massive amount of packages


fact. here is the proof:

http://cygwin.com/cygwin-pkg-maint

Example 4, quoting myself again:


cygwin *does* keep up to date with *some* important packages


fact. example is the Git package, which as of this writing is totally up to
date:

- http://cygwin.mirrors.hoobly.com/x86_64/release/git
- http://github.com/git/git/releases

Example 5, quoting myself again:


but not other important packages


fact. Current Cygwin Ruby is 2.3, which was released Dec 2015:

- http://cygwin.mirrors.hoobly.com/x86_64/release/ruby
- http://wikipedia.org/wiki/Ruby_%28programming_language%29#Ruby_2.3


A base package such as GCC requires time to release to an OS and Cygwin
is a emulation of an OS.


thats what test package is for


Releasing just because its fresh off the press isn't going to happen.


like me, i dont see you on this list:

http://cygwin.com/cygwin-pkg-maint

so i'd say you arent in a position to say that. test packages allow this to
happen if the maintainer chooses.


You have the opportunity to build it for yourself if you need it sooner but
then you are on your own.


I have mentioned twice already that i have done this:

- http://cygwin.com/ml/cygwin/2018-05/msg00099.html
- http://cygwin.com/ml/cygwin/2018-05/msg00082.html


Jon does not maintain all of the cross-compilers,


yes he does?



In the form of a question again, he definitely does a great job.


what criteria are you basing this comment on? i am not arguing with you on this
point per se. i have given concrete arguments here where release velocity could
be improved:

- http://cygwin.com/ml/cygwin/2018-05/msg00099.html
- http://cygwin.com/ml/cygwin/2018-05/msg00086.html
- http://cygwin.com/ml/cygwin/2018-05/msg00082.html
- http://cygwin.com/ml/cygwin/2018-05/msg00076.html


Why are you not "blessed" with your work?  If you provide a service to
Cygwin then why aren't you in the cygwin-pkg-maint list?  It's because
you haven't requested to maintain a package.


perhaps you should read the entire thread - i see you missed my other posts,
but it seems you missed Smoogen as well:

http://cygwin.com/ml/cygwin/2018-05/msg00087.html


And then you offend the maintainers who provide their time to provide
you a service of distribution.


thats your opinion, and its not germane to this topic. the original topic is
requesting a ruby release, as it is out of date.


If you want to maintain or co-maintain a package then ask to see if the
maintainer needs help.


i dont want to do that, but i will volunteer if a spot opens.


You haven't done that, you DEMAND that a release be made. You might not see it
as a DEMAND but it is one.


sry, nop.


And you a free to do so.  MinGW isn't GCC


yes it is. when you compile GCC, as i have done:

http://github.com/svnpenn/glade/blob/master/mingw-w64-x86-64/gcc

you choose a target. normally for this community that is "x86_64-pc-cygwin", but
in my case it is "x86_64-w64-mingw32". but you dont use some magical "MinGW"
repo, its the same GCC. granted, you do need to also install the target
"binutils", "headers" and "runtime", but the same source is used to build GCC
itself.


Maybe to you it doesn't seem like a crazy DEMAND but perhaps there are
reasons you're unaware of.  Ask to help rather than DEMANDing.


again not a demand.


While your intention isn't one of insults those who maintain the
packages read them as such because you DEMAND more of their time with no
effort toward progressing Cygwin from yourself.  That is the insult.


i am not demanding anything. i am stating what i think are reasonable
expectations for any software community. if they want to ignore them, thats
their business. ive already moved on, i build my own GCC, which i will use until
the official one drops. however note this: GCC 7 was released over a year ago:

http://gnu.mirrors.hoobly.com/gcc/gcc-7.1.0

if a test package was dropped at that time, we could have tested for 6 months,
then released a final build, and still been 6 months ahead of the current
schedule.


--
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: CYGWIN 2.8

[cyg Simple]

On 5/14/2018 3:29 PM, Lee wrote:
> On 5/14/18, cyg Simple   wrote:
>> On 5/8/2018 3:28 PM, Hans-Bernhard Bröker wrote:
>>> Am 08.05.2018 um 13:22 schrieb David Spencer:
 Morning,

 I am trying to get CYGWIN Version 2.8, this is the only version
 approved for our system at present,
>>
>> So your company is stating it wants to use buggy and susceptible
>> applications.  I don't think so.
> 
> And I don't think you've ever experienced the joys of being a USG contractor 
> :)
> 

Thank the heavens, I have not; however, I have been a contractor where
the contracting firm places the same restrictions on it's employees but
that doesn't matter.

> Go back to the original post & look at their email address.  I'm
> betting they're a contractor.
> 

So what!  If you follow the correct policies and don't come off crass in
your request to install software to get the work done then it shouldn't
be too difficult.

>>  Go back to the IT security team and
>> state that 2.10 is the latest version of Cygwin and ask if it is okay.
> 
> Which is assuming that whatever person on the IT security team you ask
> has the authority to override policy.  Staff _follows_ policy, they
> don't make it.
> 

Yes, I should have worded it slightly better, you must follow the
official process of getting the approved list updated.

>> If not then ask them to provide you with a suitable version.
> 
> You seem to be under the impression that contractors are allowed to
> make waves and stay employed there.
> 

I worked as a contractor for many years, now retired, and "made waves"
successfully by being thorough in what I was stating with facts.  If you
prove that you know what you're talking about then people listen even to
contractors.

>>> Providing that is, to a great extent, actually the job of whoever
>>> approves versions of Cygwin for you.
> 
> I'd say it's the job of whoever came up with the policy of having an
> 'approved software' list in the first place to also come up with a
> policy of keeping the list current but whatever..
> 

Perhaps but I'm guessing the policy creator may no longer be around to
improve the policy.  It's now up to a department of people to make those
changes.

> 
> It'd be nice to think the situation has changed in the years since I
> was in the same position but apparently not.  What worked for me was
> opening a support ticket with the group that keeps the approved
> software list and asking what it takes to get the current version of
> cygwin approved.
> 
> There's forms to be filled out, procedures to be followed, and in a
> few weeks the current version of cygwin is on the approved list.
> 

Yes, exactly there are forms to be filled out but that doesn't mean
those forms just be filled out and not followed up by other communication.

-- 
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: segfault in xwin-xdg-menu.exe

[Jon Turney]

On 14/05/2018 08:50, Fabio Rossi wrote:

Il 12 maggio 2018 alle 16.27 Jon Turney ha scritto:

Yeah, this is the same problem, which is under investigation.

See also https://cygwin.com/ml/cygwin/2018-05/msg00152.html for another
workaround.


I have recompiled fontconfig and solved the issue as suggested in the
other topic. Is it possible to update the binary packages installed
by setup.exe?


This has been done.

https://cygwin.com/ml/cygwin/2018-05/msg00184.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

Re: libharfbuzz0 1.7.6-1 update causing xwin-xdg-menu.exe to crash

[Jon Turney]

On 14/05/2018 20:30, Brian Inglis wrote:

On 2018-04-26 08:03, Jon Turney wrote:

On 19/04/2018 22:15, Gilles Detillieux wrote:

Has anybody else run into this problem? I've done two installations of
Cygwin/X on Windows 10 systems this week, and they both had problems with the
XWin Server dying just a few seconds after starting up. I traced the problem
back to xwin-xdg-menu.exe getting a Segmentation fault, which then causes XWin
Server to exit. I hacked an alternate .startxwinrc file to prevent XWin Server
from dying (it ends with a "sleep infinity"), so I could debug it further.

With the XWin Server running reliably, I then ran "strace xwin-xdg-menu.exe"
and saw that it got a segmentation fault just after reading a TTF font from
the Windows Font directory (bahnschrift.ttf if it matters). I noticed there
were two recent library updates related to font handling, so I tried back out
to the previous version for each. It turns out that when I reverted to version
1.7.4-1 of libharfbuzz0, xwin-xdg-menu.exe stopped crashing.

If it matters, both these systems are the Fall Creator's Update (1709) of
Windows 10 64-bit, and I'm running the 32-bit version of Cygwin.

Hopefully someone can track down and fix this recent bug!


Thanks for reporting this.

I can reproduce this problem, but it only seems to occur with 32-bit cygwin.

(Obviously you also need a recent enough Windows 10 to have the Bahnschrift 
font)

The actual crash seems to be in fontconfig, e.g. 'fc-query
/usr/share/fonts/microsoft/bahnschrift.ttf' fails in the same way.

I didn't get very far investigating the problem, as rebuilding the fontconfig
package with the current toolchain seems to be enough to make the problem go 
away.


I haven't noticed any problems with Bahnschrift, but as it is a DE DIN 1451


Note that this problem only effects 32-bit Cygwin.


Schrift (typeface), based on the original URW Fette Mittelschrift (bold
regular), Engschrift (condensed), Breitschrift (expanded), it could be
substituted by similar free fonts such as the Google Fonts Roboto family or SIL
OFL licensed equivalents.


--
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: libharfbuzz0 1.7.6-1 update causing xwin-xdg-menu.exe to crash

[Jon Turney]

On 14/05/2018 18:05, Gilles Detillieux wrote:

Thanks, Jon. The local.conf blacklist rule worked like a charm!

It's odd that the fontconfig packages appear not to have been built with 
the latest stable gcc release, but so long as it's just this one 


I don't know if that's the case or not.  More things than just the 
compiler can effect the resulting binary.


(unneeded) font that's causing the headaches I'll just keep blacklisting 
it on our systems.


Yaakov has rebuilt and uploaded the fontconfig 2.12.6-2, which doesn't 
seem to suffer from this problem in my testing.


--
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: xorg-server-1.20.0-1 (TEST)

[Jon Turney]

The following packages have been updated in the Cygwin distribution:

*** xorg-server-1.20.0-1
*** xorg-server-common-1.20.0-1
*** xorg-server-debuginfo-1.20.0-1
*** xorg-server-devel-1.20.0-1
*** xorg-server-dmx-1.20.0-1
*** xorg-server-extra-1.20.0-1
*** xorg-server-xorg-1.20.0-1
*** xwinclip-1.20.0-1

These packages contain XWin and the other X.Org X11 servers.

This is the first release of the xserver 1.20 series.  It is currently 
available as a test release, and will be made stable in a few weeks, if 
no major regressions are reported.


Please try test releases and report problems to the Cygwin mailing list. 
Testing helps ensure good releases!


In addition to upstream fixes and improvements [1][2][3][4][5][6], there 
are no (intentional) cygwin-specific changes since 1.19.6-2.


PACKAGING CHANGES:

The Xfake server has been removed upstream.  Please use Xvfb, or Xorg 
with the xf86-video-dummy driver instead.


The Xorg modular server is now packaged separately as xorg-server-xorg.

These packages are now built using the meson build system.

[1] https://lists.x.org/archives/xorg-announce/2018-May/002893.html
[2] https://lists.x.org/archives/xorg-announce/2018-April/002891.html
[3] https://lists.x.org/archives/xorg-announce/2018-April/002890.html
[4] https://lists.x.org/archives/xorg-announce/2018-April/002888.html
[5] https://lists.x.org/archives/xorg-announce/2018-March/002887.html
[6] https://lists.x.org/archives/xorg-announce/2018-February/002842.html

x86:
0f078bf79bc8b0fe080c3c164813d21bb6c27819d4981f4f6f9c977ef1701789eb0acc7f67efc50fd0e82220dd5053dc9bcbea64c93bcba90846928505fd69e5 
*xorg-server-1.20.0-1-src.tar.xz
5da46868fcb5a4f0cb1329ed25430f285a4c3bf47179a123df47a9d738b44275963b8719e596963040a93abe91e041f53bef8d480e816a372c2c9622269d79c8 
*xorg-server-1.20.0-1.tar.xz
53508c8f3cf7289faf4088b059caeafdd2e9358dcdb50a3c6289b08077cf6d9669668a1f12f298190af5cafa9e61b9e94d7394c348f3a833cb05296c3bf735cd 
*xorg-server-common-1.20.0-1.tar.xz
48d2ebe7955b32181cd31442dcdd522a3afb11ad582ffba4d97e6dceaa5a318c7c559856b7126170a5148640e64702d099c68c664129e8d09e85798555b6ae38 
*xorg-server-debuginfo-1.20.0-1.tar.xz
e792f178e9698853491c24f2b674a99fb1931b20a3ce38de5b1e9c88a930717f504668dc166932d42f23569d2d514f3d4cf87171f4fab9ad85dda884eb2e7840 
*xorg-server-devel-1.20.0-1.tar.xz
d1e0417a1486f4825a566578ebacb7ca13f755ed1245ec524b62188cefa5c6b2a1973bc778805e02c70f6e433e68e23d7c9b7b3e6b309702fbcf733b6cf568f0 
*xorg-server-dmx-1.20.0-1.tar.xz
c1d4dafe8aab1e0e5bd80e5df3c2dda26b953837184c357497cef78519d4dfd9f9bbfa77c45c6613877ef851bba8e0b6a895eecbdb5efd98d2e48a16e286637d 
*xorg-server-extra-1.20.0-1.tar.xz
a140c9664da094f49e97d075466d1fe641efc52723467dc3fa13ae673cf0ee0541fbe9153513955223cac7031c98170b4f1fcf04c56b5f7bf01627c7fa6b0805 
*xorg-server-xorg-1.20.0-1.tar.xz
0ed0ab3b400a76fb3d4754769d6d4d8485d3dc13a4ae7eb3f0f76397027a2a5328b0bd717f0d9c443914a183a7a7c19aa7199515561ea84c7442511c56357b37 
*xwinclip-1.20.0-1.tar.xz


x86_64:
b7a8a6664891b3847fcc8f7900f494caa1e487e3287725d8b7c7fba501a9ecaf767e2a903f0ec15163807cce84194e60f9be75c5b21567b802594d779b557e2a 
*xorg-server-1.20.0-1-src.tar.xz
5aaefcd59dcb5c1d5979463302c10a850e21d3842d7d554ab2280d6fb0d2b0bff855c61df19d88a00ccb20cbec69663f8c529d121af1df864e86f032a37b2ed5 
*xorg-server-1.20.0-1.tar.xz
2efaddff19559f85472123635b5b8d8eb8bfe6c5f7771bb0893a9af562f2bd41d5330ad603f695d12af5f8e3da26078774e832a07efd29aa46bb42715bc0e284 
*xorg-server-common-1.20.0-1.tar.xz
43f07eadb23779f95de7194420615c329805bd95b8455b05b90175620fdb50d9ffde49df14200cde69aa82ea21878035c8540b0fe2b5d520b84be232815d0639 
*xorg-server-debuginfo-1.20.0-1.tar.xz
ede4c2616cdc928bf41e88b90bbdda90b7d69391362b63a1cb242c81926de37664a538ba4caaa99ae8ea478e8f6dd5c79e4202d8cd9624183a1da46643f68449 
*xorg-server-devel-1.20.0-1.tar.xz
2a12e6be69f1f4b8910aef3291ec01f2aa7a13d30501293420856853b78d1808f83d4e241968d8e1ed0ab00437eacca74ac2e18c9a9918ff872e1b1ec6dc055b 
*xorg-server-dmx-1.20.0-1.tar.xz
5637252225dd219e5bb151fd05f1775605fef51243b44f49a2f3230045a784de0bb698dae3ef7fd89eb9eaf9c76bc56c8b8d000f3993862043f0df334b2653f6 
*xorg-server-extra-1.20.0-1.tar.xz
0ba66e41fdfe67024f0015941d90d67798fd7d7d725325565fa313c901133b776a350a0ef891e355695063f8b4b66e03d5beb119672a371c95a77da5ddaf5a33 
*xorg-server-xorg-1.20.0-1.tar.xz
90741d3ee44e2584fee51f05199aa8de446904130141519c453e7e6df2d81dd7f7aba20f12d43022266115fc5bcc9ef2335ef6c151d3224348a33025e1384f01 
*xwinclip-1.20.0-1.tar.xz


--
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

Updated: xorg-server-1.20.0-1 (TEST)

[Jon Turney]

The following packages have been updated in the Cygwin distribution:

*** xorg-server-1.20.0-1
*** xorg-server-common-1.20.0-1
*** xorg-server-debuginfo-1.20.0-1
*** xorg-server-devel-1.20.0-1
*** xorg-server-dmx-1.20.0-1
*** xorg-server-extra-1.20.0-1
*** xorg-server-xorg-1.20.0-1
*** xwinclip-1.20.0-1

These packages contain XWin and the other X.Org X11 servers.

This is the first release of the xserver 1.20 series.  It is currently 
available as a test release, and will be made stable in a few weeks, if 
no major regressions are reported.


Please try test releases and report problems to the Cygwin mailing list. 
Testing helps ensure good releases!


In addition to upstream fixes and improvements [1][2][3][4][5][6], there 
are no (intentional) cygwin-specific changes since 1.19.6-2.


PACKAGING CHANGES:

The Xfake server has been removed upstream.  Please use Xvfb, or Xorg 
with the xf86-video-dummy driver instead.


The Xorg modular server is now packaged separately as xorg-server-xorg.

These packages are now built using the meson build system.

[1] https://lists.x.org/archives/xorg-announce/2018-May/002893.html
[2] https://lists.x.org/archives/xorg-announce/2018-April/002891.html
[3] https://lists.x.org/archives/xorg-announce/2018-April/002890.html
[4] https://lists.x.org/archives/xorg-announce/2018-April/002888.html
[5] https://lists.x.org/archives/xorg-announce/2018-March/002887.html
[6] https://lists.x.org/archives/xorg-announce/2018-February/002842.html

x86:
0f078bf79bc8b0fe080c3c164813d21bb6c27819d4981f4f6f9c977ef1701789eb0acc7f67efc50fd0e82220dd5053dc9bcbea64c93bcba90846928505fd69e5 
*xorg-server-1.20.0-1-src.tar.xz
5da46868fcb5a4f0cb1329ed25430f285a4c3bf47179a123df47a9d738b44275963b8719e596963040a93abe91e041f53bef8d480e816a372c2c9622269d79c8 
*xorg-server-1.20.0-1.tar.xz
53508c8f3cf7289faf4088b059caeafdd2e9358dcdb50a3c6289b08077cf6d9669668a1f12f298190af5cafa9e61b9e94d7394c348f3a833cb05296c3bf735cd 
*xorg-server-common-1.20.0-1.tar.xz
48d2ebe7955b32181cd31442dcdd522a3afb11ad582ffba4d97e6dceaa5a318c7c559856b7126170a5148640e64702d099c68c664129e8d09e85798555b6ae38 
*xorg-server-debuginfo-1.20.0-1.tar.xz
e792f178e9698853491c24f2b674a99fb1931b20a3ce38de5b1e9c88a930717f504668dc166932d42f23569d2d514f3d4cf87171f4fab9ad85dda884eb2e7840 
*xorg-server-devel-1.20.0-1.tar.xz
d1e0417a1486f4825a566578ebacb7ca13f755ed1245ec524b62188cefa5c6b2a1973bc778805e02c70f6e433e68e23d7c9b7b3e6b309702fbcf733b6cf568f0 
*xorg-server-dmx-1.20.0-1.tar.xz
c1d4dafe8aab1e0e5bd80e5df3c2dda26b953837184c357497cef78519d4dfd9f9bbfa77c45c6613877ef851bba8e0b6a895eecbdb5efd98d2e48a16e286637d 
*xorg-server-extra-1.20.0-1.tar.xz
a140c9664da094f49e97d075466d1fe641efc52723467dc3fa13ae673cf0ee0541fbe9153513955223cac7031c98170b4f1fcf04c56b5f7bf01627c7fa6b0805 
*xorg-server-xorg-1.20.0-1.tar.xz
0ed0ab3b400a76fb3d4754769d6d4d8485d3dc13a4ae7eb3f0f76397027a2a5328b0bd717f0d9c443914a183a7a7c19aa7199515561ea84c7442511c56357b37 
*xwinclip-1.20.0-1.tar.xz


x86_64:
b7a8a6664891b3847fcc8f7900f494caa1e487e3287725d8b7c7fba501a9ecaf767e2a903f0ec15163807cce84194e60f9be75c5b21567b802594d779b557e2a 
*xorg-server-1.20.0-1-src.tar.xz
5aaefcd59dcb5c1d5979463302c10a850e21d3842d7d554ab2280d6fb0d2b0bff855c61df19d88a00ccb20cbec69663f8c529d121af1df864e86f032a37b2ed5 
*xorg-server-1.20.0-1.tar.xz
2efaddff19559f85472123635b5b8d8eb8bfe6c5f7771bb0893a9af562f2bd41d5330ad603f695d12af5f8e3da26078774e832a07efd29aa46bb42715bc0e284 
*xorg-server-common-1.20.0-1.tar.xz
43f07eadb23779f95de7194420615c329805bd95b8455b05b90175620fdb50d9ffde49df14200cde69aa82ea21878035c8540b0fe2b5d520b84be232815d0639 
*xorg-server-debuginfo-1.20.0-1.tar.xz
ede4c2616cdc928bf41e88b90bbdda90b7d69391362b63a1cb242c81926de37664a538ba4caaa99ae8ea478e8f6dd5c79e4202d8cd9624183a1da46643f68449 
*xorg-server-devel-1.20.0-1.tar.xz
2a12e6be69f1f4b8910aef3291ec01f2aa7a13d30501293420856853b78d1808f83d4e241968d8e1ed0ab00437eacca74ac2e18c9a9918ff872e1b1ec6dc055b 
*xorg-server-dmx-1.20.0-1.tar.xz
5637252225dd219e5bb151fd05f1775605fef51243b44f49a2f3230045a784de0bb698dae3ef7fd89eb9eaf9c76bc56c8b8d000f3993862043f0df334b2653f6 
*xorg-server-extra-1.20.0-1.tar.xz
0ba66e41fdfe67024f0015941d90d67798fd7d7d725325565fa313c901133b776a350a0ef891e355695063f8b4b66e03d5beb119672a371c95a77da5ddaf5a33 
*xorg-server-xorg-1.20.0-1.tar.xz
90741d3ee44e2584fee51f05199aa8de446904130141519c453e7e6df2d81dd7f7aba20f12d43022266115fc5bcc9ef2335ef6c151d3224348a33025e1384f01 
*xwinclip-1.20.0-1.tar.xz

[ITP] perl-Algorithm-Combinatorics

[Achim Gratz]

[repost]

The package was requested by a user on the main list and since I've used
it before in my local installation and it hasn't changed for quite soem
time upstream I see no problem of providing it officially.  It's in
openSUSE and Debian (probably in other distributions as well).


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: libharfbuzz0 1.7.6-1 update causing xwin-xdg-menu.exe to crash

[Brian Inglis]

On 2018-04-26 08:03, Jon Turney wrote:
> On 19/04/2018 22:15, Gilles Detillieux wrote:
>> Has anybody else run into this problem? I've done two installations of
>> Cygwin/X on Windows 10 systems this week, and they both had problems with the
>> XWin Server dying just a few seconds after starting up. I traced the problem
>> back to xwin-xdg-menu.exe getting a Segmentation fault, which then causes 
>> XWin
>> Server to exit. I hacked an alternate .startxwinrc file to prevent XWin 
>> Server
>> from dying (it ends with a "sleep infinity"), so I could debug it further.
>>
>> With the XWin Server running reliably, I then ran "strace xwin-xdg-menu.exe"
>> and saw that it got a segmentation fault just after reading a TTF font from
>> the Windows Font directory (bahnschrift.ttf if it matters). I noticed there
>> were two recent library updates related to font handling, so I tried back out
>> to the previous version for each. It turns out that when I reverted to 
>> version
>> 1.7.4-1 of libharfbuzz0, xwin-xdg-menu.exe stopped crashing.
>>
>> If it matters, both these systems are the Fall Creator's Update (1709) of
>> Windows 10 64-bit, and I'm running the 32-bit version of Cygwin.
>>
>> Hopefully someone can track down and fix this recent bug!
> 
> Thanks for reporting this.
> 
> I can reproduce this problem, but it only seems to occur with 32-bit cygwin.
> 
> (Obviously you also need a recent enough Windows 10 to have the Bahnschrift 
> font)
> 
> The actual crash seems to be in fontconfig, e.g. 'fc-query
> /usr/share/fonts/microsoft/bahnschrift.ttf' fails in the same way.
> 
> I didn't get very far investigating the problem, as rebuilding the fontconfig
> package with the current toolchain seems to be enough to make the problem go 
> away.

I haven't noticed any problems with Bahnschrift, but as it is a DE DIN 1451
Schrift (typeface), based on the original URW Fette Mittelschrift (bold
regular), Engschrift (condensed), Breitschrift (expanded), it could be
substituted by similar free fonts such as the Google Fonts Roboto family or SIL
OFL licensed equivalents.

-- 
Take care. Thanks, Brian Inglis, 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: CYGWIN 2.8

[Lee]

On 5/14/18, cyg Simple   wrote:
> On 5/8/2018 3:28 PM, Hans-Bernhard Bröker wrote:
>> Am 08.05.2018 um 13:22 schrieb David Spencer:
>>> Morning,
>>>
>>> I am trying to get CYGWIN Version 2.8, this is the only version
>>> approved for our system at present,
>
> So your company is stating it wants to use buggy and susceptible
> applications.  I don't think so.

And I don't think you've ever experienced the joys of being a USG contractor :)

Go back to the original post & look at their email address.  I'm
betting they're a contractor.

>  Go back to the IT security team and
> state that 2.10 is the latest version of Cygwin and ask if it is okay.

Which is assuming that whatever person on the IT security team you ask
has the authority to override policy.  Staff _follows_ policy, they
don't make it.

> If not then ask them to provide you with a suitable version.

You seem to be under the impression that contractors are allowed to
make waves and stay employed there.

>> Providing that is, to a great extent, actually the job of whoever
>> approves versions of Cygwin for you.

I'd say it's the job of whoever came up with the policy of having an
'approved software' list in the first place to also come up with a
policy of keeping the list current but whatever..


It'd be nice to think the situation has changed in the years since I
was in the same position but apparently not.  What worked for me was
opening a support ticket with the group that keeps the approved
software list and asking what it takes to get the current version of
cygwin approved.

There's forms to be filled out, procedures to be followed, and in a
few weeks the current version of cygwin is on the approved list.

Regards,
Lee

--
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: libharfbuzz0 1.7.6-1 update causing xwin-xdg-menu.exe to crash

[Gilles Detillieux]

Thanks, Jon. The local.conf blacklist rule worked like a charm!

It's odd that the fontconfig packages appear not to have been built with 
the latest stable gcc release, but so long as it's just this one 
(unneeded) font that's causing the headaches I'll just keep blacklisting 
it on our systems.


On 2018-05-12 09:23, Jon Turney wrote:

On 26/04/2018 16:40, Gilles Detillieux wrote:

On 2018-04-26 09:03, Jon Turney wrote:

On 19/04/2018 22:15, Gilles Detillieux wrote:
Has anybody else run into this problem? I've done two installations 
of Cygwin/X on Windows 10 systems this week, and they both had 
problems with the XWin Server dying just a few seconds after 
starting up. I traced the problem back to xwin-xdg-menu.exe getting 
a Segmentation fault, which then causes XWin Server to exit. I 
hacked an alternate .startxwinrc file to prevent XWin Server from 
dying (it ends with a "sleep infinity"), so I could debug it further.


With the XWin Server running reliably, I then ran "strace 
xwin-xdg-menu.exe" and saw that it got a segmentation fault just 
after reading a TTF font from the Windows Font directory 
(bahnschrift.ttf if it matters). I noticed there were two recent 
library updates related to font handling, so I tried back out to 
the previous version for each. It turns out that when I reverted to 
version 1.7.4-1 of libharfbuzz0, xwin-xdg-menu.exe stopped crashing.


If it matters, both these systems are the Fall Creator's Update 
(1709) of Windows 10 64-bit, and I'm running the 32-bit version of 
Cygwin.


Hopefully someone can track down and fix this recent bug!


Thanks for reporting this.

I can reproduce this problem, but it only seems to occur with 32-bit 
cygwin.


(Obviously you also need a recent enough Windows 10 to have the 
Bahnschrift font)


The actual crash seems to be in fontconfig, e.g. 'fc-query 
/usr/share/fonts/microsoft/bahnschrift.ttf' fails in the same way.


Another possible workaround seems to be to blacklist this particular 
font, e.g.:


create a /etc/fonts/conf.d/local.conf containing:


    
/usr/share/fonts/microsoft/bahnschrift.ttf
    


I didn't get very far investigating the problem, as rebuilding the 
fontconfig package with the current toolchain seems to be enough to 
make the problem go away.


Thanks for the follow-up and narrowing down the problem, Jon. 
Interesting that rebuilding fontconfig clears up the issue. Although, 
if it's a memory corruption issue, it could just be that the new 
toolchain lays things out differently enough that the bug doesn't 
manifest itself the same way. It could also be that the new gcc fixes 
a compiler or optimizer bug that led to the problem. Perhaps you and 
Yaakov could touch base on which toolchain versions you're using and 
see if an update to his toolchain may be in order.


Are you using the test version of gcc (7.3.0-1) announced April 11, 
or the older release. I've got gcc-core-6.4.0-5 on mine, which I 
assume is the latest stable release.


The latest stable release, 6.4.0-5.



--
Gilles R. Detillieux  E-mail: 
Spinal Cord Research Centre   WWW:http://www.scrc.umanitoba.ca/
Dept. of Physiology and Pathophysiology, Faculty of Health Sciences,
Univ. of Manitoba  Winnipeg, MB  R3E 0J9  (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: CYGWIN 2.8

[Brian Inglis]

On 2018-05-08 06:13, Marco Atzeri wrote:
> On 5/8/2018 1:22 PM, David Spencer wrote:
>> I am trying to get CYGWIN Version 2.8, this is the only version approved for
>> our system at present, is there a way I can Version 2.8
> you should use the "Cygwin Time Machine Information"
> http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html

You really need a date/time stamp to characterize Cygwin "releases". Which of
the 3 Cygwin dll releases 2.8.0 thru 2.8.2, and 118 rolling package release sets
from 2017-04 thru 2017-09 do you have from:

http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/64bit/index.html

and which packages were picked from the 10,000 available in each release, as
shown by running:

$ grep '1$' /etc/setup/installed.db

-- 
Take care. Thanks, Brian Inglis, 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: Request new Ruby release

[cyg Simple]

On 5/6/2018 10:08 AM, Steven Penny wrote:
> On Sun, 6 May 2018 00:54:23, Yaakov Selkowitz wrote:
>> The question is, if you actually understand your comments are not
>> appreciated, why do you insist on making them anyway?
> 
> because they have merit? i said that already.
> 

Since you stated in the form of a question, I can say for me, they do
not and based on the conversation of others, not for anyone but you.

>>> GCC as an example is a fast updating package.
>>
>> No, not really.
> 
> its fast in comparison to cygwin releases.
> 

A base package such as GCC requires time to release to an OS and Cygwin
is a emulation of an OS.  Releasing just because its fresh off the press
isn't going to happen.  You have the opportunity to build it for
yourself if you need it sooner but then you are on your own.

>> Jon does not maintain all of the cross-compilers,
> 
> yes he does?
> 

In the form of a question again, he definitely does a great job.

> http://cygwin.com/cygwin-pkg-maint
> 
>> Exactly.  Griping (or worse) at those who are actually doing the work
>> while you contribute nothing doesn't get you very far.
> 
> this is just patently false. while my builds may not be "blessed" by
> cygwin,
> they are available for anyone to use, and have been for several years.
> 

Why are you not "blessed" with your work?  If you provide a service to
Cygwin then why aren't you in the cygwin-pkg-maint list?  It's because
you haven't requested to maintain a package.

>> I have never forgotten that, and hence am prepared to similarly defend
>> my fellow contributors (albeit probably not as eloquently).
> 
> thats nice, but i think your "defense" is unwarranted. all i am asking
> here is
> for at least yearly updates, even if in the form of "[test]" packages, of
> important packages. for example, with these:
> 
> 1. gcc-core
> 2. gcc-g++
> 3. mingw64-x86_64-gcc-core
> 4. mingw64-x86_64-gcc-g++
> 

And then you offend the maintainers who provide their time to provide
you a service of distribution.  If you want to maintain or co-maintain a
package then ask to see if the maintainer needs help.  You haven't done
that, you DEMAND that a release be made.  You might not see it as a
DEMAND but it is one.

> only 2 of the 4 would meet that criteria. as i was tired of waiting, i
> built 3
> and 4 myself:
> 

And you a free to do so.  MinGW isn't GCC and those providing a package
based on it do so in their free time as a gift to you and me.

> http://github.com/svnpenn/glade/tree/master/mingw-w64-x86-64/gcc
> 
> and to my surprise with the right options a build only takes about 15
> minutes.
> so its doesnt seem like a crazy request to me, to have a test build
> uploaded in
> this case.
> 

Maybe to you it doesn't seem like a crazy DEMAND but perhaps there are
reasons you're unaware of.  Ask to help rather than DEMANDing.

>> You are the one who insists on throwing insults time and again, and I
>> have warned you about your tone before.  I suggest you take heed.
> 
> do i though? seriously i would like to know. i went through my posts on
> this
> thread:
> 
> - http://cygwin.com/ml/cygwin/2018-05/msg00086.html
> - http://cygwin.com/ml/cygwin/2018-05/msg00082.html
> - http://cygwin.com/ml/cygwin/2018-05/msg00076.html
> - http://cygwin.com/ml/cygwin/2018-05/msg00059.html
> 
> and i dont see a single insult that i have made. i might be critical of the
> current state of certain packages, but i am not seeing insults here from
> my end.
> take care.

While your intention isn't one of insults those who maintain the
packages read them as such because you DEMAND more of their time with no
effort toward progressing Cygwin from yourself.  That is the insult.

-- 
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: CYGWIN 2.8

[cyg Simple]

On 5/8/2018 3:28 PM, Hans-Bernhard Bröker wrote:
> Am 08.05.2018 um 13:22 schrieb David Spencer:
>> Morning,
>>
>> I am trying to get CYGWIN Version 2.8, this is the only version
>> approved for our system at present, 


So your company is stating it wants to use buggy and susceptible
applications.  I don't think so.  Go back to the IT security team and
state that 2.10 is the latest version of Cygwin and ask if it is okay.
If not then ask them to provide you with a suitable version.

>
> Providing that is, to a great extent, actually the job of whoever
> approves versions of Cygwin for you.
>

The company should provide a common mirror of approved applications.

> That's because the version number of cygwin itself barely begins to
> define an actual fixed configuration of the whole Cygwin environment
> you'll be installing: that's _one_ package whose version number has been
> nailed down, but _hundreds_ of others left totally floating.
> 

The version number of the Cygwin DLL doesn't provide the versions of all
of the components possible to use.  A company approving a specific
version of Cygwin DLL is clueless as to what Cygwin is.

> The only practical way of defining an installation of which it can even
> make sense to call it "approved" is to host a fixed mirror repository
> that's controlled by whoever does the approving, inside the organization
> that requires said approval.
> 

Exactly!

-- 
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: /usr/include/ssp/wchar.h:78:1: error: unknown type name ‘FILE’ (during cygport package build)

[Ken Brown]

On 5/13/2018 12:01 PM, waterlan wrote:
> Hi,
> 
> I'm trying to create a new wcd package, but I get compile errors during
> the cygport build of the wcd package.
> 
> gcc -ggdb -O2 -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong
> --param=ssp-buffer-size=4
> -fdebug-prefix-map=/cygdrive/c/Users/waterlan/src/cygwin/wcd/wcd-6.0.2-1.x86_64/build=/usr/src/debug/wcd-6.0.2-1
> -fdebug-prefix-map=/cygdrive/c/Users/waterlan/src/cygwin/wcd/wcd-6.0.2-1.x86_64/src/wcd-6.0.2=/usr/src/debug/wcd-6.0.2-1
> -O2 -Wall -Wextra -Wno-unused-parameter -Wconversion-Ic3po
> -DVERSION=\"6.0.2\" -DVERSION_DATE=\"2018-05-10\"  -std=gnu99
> -DWCD_UNICODE -DWCD_UNINORM -DENABLE_NLS
> -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"wcd\"
> -I/usr/include/ncursesw -I/usr/include -DDEBUG=0 -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64 -DUNIX -DWCD_USECURSES  -D_XOPEN_SOURCE
> -D_XOPEN_SOURCE_EXTENDED  -c wcwidth.c -o wcwidth.o
> 
> In file included from /usr/include/ssp/wchar.h:5:0,
>   from /usr/include/wchar.h:336,
>   from wcwidth.c:62:
> /usr/include/ssp/wchar.h:78:1: error: unknown type name 'FILE'
>   __ssp_decl(wchar_t *, fgetws, (wchar_t *__restrict __buf, int __wlen,
> FILE *__restrict __fp))

This is a newlib issue that has been fixed:

https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=829820af6e5bccefe93485023e93821807fb99b8;hp=e494b560350cabef94126a4478096aae89ae35a0

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: segfault in xwin-xdg-menu.exe

[Fabio Rossi]

> Il 12 maggio 2018 alle 16.27 Jon Turney  ha 
> scritto:
> 
> Yeah, this is the same problem, which is under investigation.
> 
> See also https://cygwin.com/ml/cygwin/2018-05/msg00152.html for another 
> workaround.

I have recompiled fontconfig and solved the issue as suggested in the other 
topic. Is it possible to update the binary packages installed by setup.exe?

--
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