Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]
On Mar 4 19:23, Achim Gratz wrote: Corinna Vinschen writes: On Mar 3 15:59, Warren Young wrote: On Mar 3, 2015, at 1:25 PM, Corinna Vinschen corinna-cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org wrote: On Mar 3 13:23, Warren Young wrote: On Mar 3, 2015, at 2:11 AM, Corinna Vinschen corinna-cygwin-rdbxbdvo6bvhl2p70bp...@public.gmane.orgm wrote: Now that we have so many goldstars in circulation, maybe we can finally use it as new currency? Hey, shall we move from goldstars to plush hippos? The standard solution is higher denominations. So, we need platinum, rhodium, and uranium stars now. Hang on... plush hippos *are* a higher denomination. What’s the exchange rate? 3.1415926 goldstars for one plush hippo. Only for the pink ones, though. ;-) Huh? The plush hippos are always pink! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp53z2ueewcK.pgp Description: PGP signature
Re: [ATTN MAINTAINER] python
Corinna Vinschen writes: The problem here is how the Windows stack works. Stack reserve is the initial size of the reserved virtual memory space used for the stack of the main thread. By default that's 2 Megs. There were in fact two threads at the point of the SEGV, one in the kernel DLL with a very short stack and the other one with a lot of stack in compile.c (I don't know which one would be the main thread). However, the stack for the main thread has a problem. The way a new process is created, the main thread stack is jammed between certain other datastructures, in the address space from 0x3 and 0x23. Since the stack is growing top-down, there's nothing a process can do when the reserved stack space is exhausted. Except generating an exception STATUS_STACK_OVERFLOW. And then... what? There's no way to reserve more space below 0x3 and even *if* it would be possible, it's only a mere 192K. I'm just saying that a message like stack overrun or something of that sort would have told me to go look for the stack size a lot earlier than just a segfault. As far as building maxima goes the problem is solved and I just posted here again in case Yaakov thinks that shouldn't have happened or maybe increase the stack size for the next build. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [ATTN MAINTAINER] python
On Mar 4 19:22, Achim Gratz wrote: Corinna Vinschen writes: The problem here is how the Windows stack works. Stack reserve is the initial size of the reserved virtual memory space used for the stack of the main thread. By default that's 2 Megs. There were in fact two threads at the point of the SEGV, one in the kernel DLL with a very short stack and the other one with a lot of stack in compile.c (I don't know which one would be the main thread). However, the stack for the main thread has a problem. The way a new process is created, the main thread stack is jammed between certain other datastructures, in the address space from 0x3 and 0x23. Since the stack is growing top-down, there's nothing a process can do when the reserved stack space is exhausted. Except generating an exception STATUS_STACK_OVERFLOW. And then... what? There's no way to reserve more space below 0x3 and even *if* it would be possible, it's only a mere 192K. I'm just saying that a message like stack overrun or something of that sort would have told me to go look for the stack size a lot earlier than just a segfault. The problem is, a stack overflow is correctly handled as SEGV from the POSIX perspective. But there should have been the right info available. If you run this under strace, you get an exception 0xc0fd or 0xc228, STATUS_STACK_OVERFLOW or STATUS_STACK_OVERFLOW_READ. Can you check? If it's an 0xc228, there is a chance we're missing to handle it in our exception handler. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpjNci5OgH84.pgp Description: PGP signature
Re: [ATTN MAINTAINER] python
Corinna Vinschen writes: The problem is, a stack overflow is correctly handled as SEGV from the POSIX perspective. But there should have been the right info available. If you run this under strace, you get an exception 0xc0fd or 0xc228, STATUS_STACK_OVERFLOW or STATUS_STACK_OVERFLOW_READ. Can you check? If it's an 0xc228, there is a chance we're missing to handle it in our exception handler. 829 2952008 [main] python2.7 604 mmap64: addr 0x0, len 262144, prot 0x3, flags 0x22, fd -1, off 0x0 35 2952043 [main] python2.7 604 mmap64: 0x6FFFB85 = mmap() 703 2952746 [main] python2.7 604 mmap64: addr 0x0, len 262144, prot 0x3, flags 0x22, fd -1, off 0x0 34 2952780 [main] python2.7 604 mmap64: 0x6FFFB81 = mmap() 596 2953376 [main] python2.7 604 mmap64: addr 0x0, len 262144, prot 0x3, flags 0x22, fd -1, off 0x0 37 2953413 [main] python2.7 604 mmap64: 0x6FFFB7D = mmap() 607 2954020 [main] python2.7 604 mmap64: addr 0x0, len 262144, prot 0x3, flags 0x22, fd -1, off 0x0 37 2954057 [main] python2.7 604 mmap64: 0x6FFFB79 = mmap() 605 2954662 [main] python2.7 604 mmap64: addr 0x0, len 262144, prot 0x3, flags 0x22, fd -1, off 0x0 33 2954695 [main] python2.7 604 mmap64: 0x6FFFB75 = mmap() 587 2955282 [main] python2.7 604 mmap64: addr 0x0, len 262144, prot 0x3, flags 0x22, fd -1, off 0x0 33 2955315 [main] python2.7 604 mmap64: 0x6FFFB71 = mmap() --- Process 604, exception c0fd at 0003E91E9619 --- Process 604, exception c005 at 0001801C2F96 Segmentation fault Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]
Corinna Vinschen writes: On Mar 3 15:59, Warren Young wrote: On Mar 3, 2015, at 1:25 PM, Corinna Vinschen corinna-cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org wrote: On Mar 3 13:23, Warren Young wrote: On Mar 3, 2015, at 2:11 AM, Corinna Vinschen corinna-cygwin-rdbxbdvo6bvhl2p70bp...@public.gmane.orgm wrote: Now that we have so many goldstars in circulation, maybe we can finally use it as new currency? Hey, shall we move from goldstars to plush hippos? The standard solution is higher denominations. So, we need platinum, rhodium, and uranium stars now. Hang on... plush hippos *are* a higher denomination. What’s the exchange rate? 3.1415926 goldstars for one plush hippo. Only for the pink ones, though. ;-) Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [ATTN MAINTAINER] python
On 3/4/2015 10:23 PM, Achim Gratz wrote: Corinna Vinschen writes: DLL version? Did you call addr2line to see where 0001801C2F96 is (hint: requires cygwin-debuginfo) in the DLL? This might give a clue. /mnt/share/maint (1962) uname -a CYGWIN_NT-6.3 Cygwin 1.7.35(0.286/5/3) 2015-02-27 17:19 x86_64 Cygwin /mnt/share/maint (1963) addr2line -e /usr/bin/python2.7.exe 0003E91E9619 0001801C2F96 ??:0 ??:0 Regards, Achim. I presume Corinna asked for this: $ addr2line.exe -a 0001801C2F96 -e /usr/bin/cygwin1.dll
Re: [ATTN MAINTAINER] python
Marco Atzeri writes: I presume Corinna asked for this: $ addr2line.exe -a 0001801C2F96 -e /usr/bin/cygwin1.dll Then that's giving us this: /mnt/share/maint (1964) addr2line.exe -a 0001801C2F96 -e /usr/bin/cygwin1.dll 0x0001801c2f96 /builddir/build/BUILD/gcc-4.8.3/build_cyg64/x86_64-pc-cygwin/libgcc/../../../libgcc/config/i386/cygwin.S:146 Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]
On Mar 4 19:23, Achim Gratz wrote: Corinna Vinschen writes: On Mar 3 15:59, Warren Young wrote: On Mar 3, 2015, at 1:25 PM, Corinna Vinschen corinna-cygwin-rdbxbdvo6bxqt0dzr+alfa-xmd5yjdbdmrexy1tmh2...@public.gmane.org wrote: On Mar 3 13:23, Warren Young wrote: On Mar 3, 2015, at 2:11 AM, Corinna Vinschen corinna-cygwin-rDBXBDvO6BVhl2p70BpVqQ-XMD5yJDbdMReXY1tMh2IBgC/g2k4z...@public.gmane.org wrote: Now that we have so many goldstars in circulation, maybe we can finally use it as new currency? Hey, shall we move from goldstars to plush hippos? The standard solution is higher denominations. So, we need platinum, rhodium, and uranium stars now. Hang on... plush hippos *are* a higher denomination. Whats the exchange rate? 3.1415926 goldstars for one plush hippo. Only for the pink ones, though. ;-) Huh? The plush hippos are always pink! Awarded! http://cygwin.com/goldstars/#CV
Re: [ATTN MAINTAINER] python
On Mar 4 20:55, Achim Gratz wrote: Corinna Vinschen writes: The problem is, a stack overflow is correctly handled as SEGV from the POSIX perspective. But there should have been the right info available. If you run this under strace, you get an exception 0xc0fd or 0xc228, STATUS_STACK_OVERFLOW or STATUS_STACK_OVERFLOW_READ. Can you check? If it's an 0xc228, there is a chance we're missing to handle it in our exception handler. 829 2952008 [main] python2.7 604 mmap64: addr 0x0, len 262144, prot 0x3, flags 0x22, fd -1, off 0x0 35 2952043 [main] python2.7 604 mmap64: 0x6FFFB85 = mmap() 703 2952746 [main] python2.7 604 mmap64: addr 0x0, len 262144, prot 0x3, flags 0x22, fd -1, off 0x0 34 2952780 [main] python2.7 604 mmap64: 0x6FFFB81 = mmap() 596 2953376 [main] python2.7 604 mmap64: addr 0x0, len 262144, prot 0x3, flags 0x22, fd -1, off 0x0 37 2953413 [main] python2.7 604 mmap64: 0x6FFFB7D = mmap() 607 2954020 [main] python2.7 604 mmap64: addr 0x0, len 262144, prot 0x3, flags 0x22, fd -1, off 0x0 37 2954057 [main] python2.7 604 mmap64: 0x6FFFB79 = mmap() 605 2954662 [main] python2.7 604 mmap64: addr 0x0, len 262144, prot 0x3, flags 0x22, fd -1, off 0x0 33 2954695 [main] python2.7 604 mmap64: 0x6FFFB75 = mmap() 587 2955282 [main] python2.7 604 mmap64: addr 0x0, len 262144, prot 0x3, flags 0x22, fd -1, off 0x0 33 2955315 [main] python2.7 604 mmap64: 0x6FFFB71 = mmap() --- Process 604, exception c0fd at 0003E91E9619 --- Process 604, exception c005 at 0001801C2F96 DLL version? Did you call addr2line to see where 0001801C2F96 is (hint: requires cygwin-debuginfo) in the DLL? This might give a clue. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpWBbDqv3DPL.pgp Description: PGP signature
Re: [ATTN MAINTAINER] python
Corinna Vinschen writes: DLL version? Did you call addr2line to see where 0001801C2F96 is (hint: requires cygwin-debuginfo) in the DLL? This might give a clue. /mnt/share/maint (1962) uname -a CYGWIN_NT-6.3 Cygwin 1.7.35(0.286/5/3) 2015-02-27 17:19 x86_64 Cygwin /mnt/share/maint (1963) addr2line -e /usr/bin/python2.7.exe 0003E91E9619 0001801C2F96 ??:0 ??:0 Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [cygport] pkg_info.cygport: correct search order for Perl dependencies
On Sun, 2015-02-22 at 23:08 +0100, Achim Gratz wrote: pkg_info.cygport: correct search order for Perl dependencies * lib/pkg_info.cygpart: Correct search order for Perl dependencies and suppress auto-generation of Perl dependencies when NO_PERL_DEPS is defined. Dependency generation for Perl at least is too simplistic and doesn't take into account that some modules required or used might actually be optional. It tends to generate too long dependency lists that vary with the Perl distributions already installed. For starters, the search order should be the reverse of @INC to skip dependencies that are built-in to perl already, but that doesn't pick up those modules that are needed with a higher version since only the presence of the module is detected. Files in site_perl shoud never be searched since these are local installs. Files in vendor_perl might be useful to check, however due to the version problem it is better to inject the module dpenedencies from the cygport file. So skip those searches when NO_PERL_DEPS is defined, which it will be for auto-generated cygport files for Perl distributions (the information is pulled from CPAN/MetaCPAN). Could you provide more detail here so I can better understand the problems? Do you have an example of the difference in dependencies with your patch? Don't we want to depend on newer versions in vendor_perl if they are present? And can I see your auto-generation script for CPAN packages, is it a candidate to include in cygport itself? -- Yaakov
Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]
On 03/04/2015 02:41 PM, Andrew Schulman wrote: Huh? The plush hippos are always pink! Awarded! http://cygwin.com/goldstars/#CV Should I get anything for taking the orphaned grep/gperf/bison/diffutils/gzip when cgf left? (A single gold star is plenty for me; that plush hippo is above and beyond the level of effort it took :) [has it really been since 2009 for my last gold star?] -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]
On Mar 4, 2015, at 6:11 PM, Eric Blake ebl...@redhat.com wrote: On 03/04/2015 02:41 PM, Andrew Schulman wrote: Huh? The plush hippos are always pink! Awarded! http://cygwin.com/goldstars/#CV Should I get anything for taking the orphaned grep/gperf/bison/diffutils/gzip when cgf left? Yes. (A single gold star is plenty for me; that plush hippo is above and beyond the level of effort it took :) I dunno. I see 5 major packages in that list. 5 ÷ π ≅ 1 hippo and two stars.
[Fwd: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6]
Marco, Well, that didn't take long, see attached. (Not that I'm surprised, given their history.) Before you update ImageMagick to upstream 6.9.0-9, you'll need to (re)build the current release (or a newer one prior to 6.9.0-9) and split the DLLs into libMagickCore6_2 (which OBSOLETES libMagickCore6), libMagickWand6_2, and libMagick++6_3. The latter will then become libMagick++6_6 after the 6.9.0-9 version bump. -- Yaakov ---BeginMessage--- Hello. I have long outstanding update of ImageMagick[1] and plan do it in rawhide in 1-3 days. So-name happened libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6 (from ImageMagick-c++ sub-package). Other names did not changed: libMagickCore-6.Q16.so.2, libMagickWand-6.Q16.so.2 Affected packages needs to be rebuild: $ repoquery --repoid=rawhide --whatrequires ImageMagick-c++ --source | sort -u | perl -pe 's/-\d.*?-\d+(\..*)?\.fc\d+(\..*)?.src.rpm//' converseen cuneiform drawtiming gtatool inkscape k3d kxstitch perl-Image-SubImageFind pfstools synfig vdr-scraper2vdr Package owners in cc. Please let me known if you wish me to rebuild your package. Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=9139666 [1]https://bugzilla.redhat.com/show_bug.cgi?id=1087263 -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct---End Message---
Re: [cygport] pkg_info.cygport: correct search order for Perl dependencies
Yaakov Selkowitz writes: Could you provide more detail here so I can better understand the problems? There are lots of Perl distributions that can optionally use some module when available. I often have those modules installed since I need them for testing or something else entirely and then the corresponding distribution will be picked up by cygport as a dependency. Do you have an example of the difference in dependencies with your patch? Off-hand, I think cpanm is the most prominent example (or was, I haven't checked lately). It's supposed to work standalone (except for tar as an external dependency). If you happen to have some totally optional modules installed, they become dependencies, which totally defeats the purpose of cpanm. Don't we want to depend on newer versions in vendor_perl if they are present? I'd say no. It's not that there are no errors to be found in META files (I correct those where I know about them), but if a distribution says it doesn't care about the version of a module or the module version built into Perl is sufficient, then I don't see why we should force installation of a newer module… Unless that fixes a bug, but again I can patch that extra bit in and forget about it. I suggest that a workable strategy for cygport to find the dependencies might be this: look at the runtime dependencies from the META.yaml or META.json file after compilation, map those module names to perl distributions and use those (with a perl- prefix) as dependencies. The important bit here is to check which of those are in Perl core and drop them. Again, you will occasionally want to modify that result, so there should be ways to both add a dependency (already there) or drop one. And can I see your auto-generation script for CPAN Let me know which email address I should send it to. packages, is it a candidate to include in cygport itself? At the moment I'd say no since it's historically grown (it started as a way to deal with the concealed dependencies via perl_vendor). I wanted to clean it up for a while, for instance to use the new MetaCPAN::API interface only (at the moment it's a wild mixture of CPAN and MetaCPAN) and then pull out some parts that have to do with how I organize the packaging locally into a support script. But just the part described above might be easier to get at and implement. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [ATTN MAINTAINER] python
On Mar 4 07:06, Achim Gratz wrote: Corinna Vinschen writes: Increasing the stack reserve size of the python executable to 0x40 on 32bit and 0x80 on 64bit avoids the SEGV. I'm not sure if this indicates an error in Python itself or simply a too restricted configuration. Maybe it just needs a really big stack? Obviously it wants something larger than it is compiled with (what exactly does stack reserve mean, btw?)… The backtrace had something like 5000 of the same call inside compile.c in it. But I would have expected it to grow the stack when necessary or give some intelligible error instead of simply segfault. The problem here is how the Windows stack works. Stack reserve is the initial size of the reserved virtual memory space used for the stack of the main thread. By default that's 2 Megs. However, the stack for the main thread has a problem. The way a new process is created, the main thread stack is jammed between certain other datastructures, in the address space from 0x3 and 0x23. Since the stack is growing top-down, there's nothing a process can do when the reserved stack space is exhausted. Except generating an exception STATUS_STACK_OVERFLOW. And then... what? There's no way to reserve more space below 0x3 and even *if* it would be possible, it's only a mere 192K. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpNob_N_QHHc.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated: dialog-1.2-20150225-1
On Mar 4 08:32, Thomas Wolff wrote: Yaakov Selkowitz wrote to cygwin-announce: The following packages have been updated in the Cygwin distribution: * dialog-1.2-20150225-1 * libdialog12-1.2-20150225-1 * libdialog-devel-1.2-20150225-1 Dialog is a script-interpreter which provides a set of widgets for in-terminal dialogs. Widgets are objects whose appearance and behavior can be customized. From the man page: EXAMPLES The dialog sources contain several samples of how to use the different box options and how they look. Just take a look into the directory samples/ of the source. This is not really helpful for a package. Examples should go into /usr/share/dialog, please. Following the Fedora packaging, this would be /usr/share/doc/dialog/samples. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpTGMtas6Rjo.pgp Description: PGP signature
Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]
On Mar 3 15:59, Warren Young wrote: On Mar 3, 2015, at 1:25 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Mar 3 13:23, Warren Young wrote: On Mar 3, 2015, at 2:11 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: Now that we have so many goldstars in circulation, maybe we can finally use it as new currency? Hey, shall we move from goldstars to plush hippos? The standard solution is higher denominations. So, we need platinum, rhodium, and uranium stars now. Hang on... plush hippos *are* a higher denomination. What’s the exchange rate? 3.1415926 goldstars for one plush hippo. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgptJKbjlDvnR.pgp Description: PGP signature
