Re: Trusted maintainers (was: Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko))
On May 13 12:18, Marco Atzeri via Cygwin-apps wrote: > On 11.05.2023 15:57, Andrew Schulman via Cygwin-apps wrote: > > > Entrusted with these strange superpowers, the following god-like beings > > > walk unknown amongst us: > > > > > > Achim Gratz > > > Corinna Vinschen > > > Ken Brown > > > Marco Atzeri > > > > Hippos! https://cygwin.com/goldstars/ > > > > I have the impression that Jon is also in the list Hehe. > another Hippo please for all the work he is doing on the infrastructure > of the Cygwin project. I second that and it already occured, fortunately. But here's a strange thought... Would it make sense to document this somewhere, like, say, on the cygwin website? Or did this already happen? Thanks, Corinna
Re: Trusted maintainers (was: Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko))
> On 11.05.2023 15:57, Andrew Schulman via Cygwin-apps wrote: > >> Entrusted with these strange superpowers, the following god-like beings > >> walk unknown amongst us: > >> > >> Achim Gratz > >> Corinna Vinschen > >> Ken Brown > >> Marco Atzeri > > > > Hippos! https://cygwin.com/goldstars/ > > > > I have the impression that Jon is also in the list > > another Hippo please for all the work he is doing on the infrastructure > of the Cygwin project. > > Marco Awarded! https://cygwin.com/goldstars/#JTy
Re: Trusted maintainers (was: Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko))
On 11.05.2023 15:57, Andrew Schulman via Cygwin-apps wrote: Entrusted with these strange superpowers, the following god-like beings walk unknown amongst us: Achim Gratz Corinna Vinschen Ken Brown Marco Atzeri Hippos! https://cygwin.com/goldstars/ I have the impression that Jon is also in the list another Hippo please for all the work he is doing on the infrastructure of the Cygwin project. Marco
Re: Trusted maintainers (was: Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko))
> Entrusted with these strange superpowers, the following god-like beings > walk unknown amongst us: > > Achim Gratz > Corinna Vinschen > Ken Brown > Marco Atzeri Hippos! https://cygwin.com/goldstars/
Trusted maintainers (was: Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko))
On 01/12/2022 19:41, Jon Turney wrote: On 04/11/2022 13:05, Chad Dougherty wrote: On 2022-11-04 08:34, Jon Turney wrote: [...] Well, maybe. I think a common way for distros to handle this is to have some subset of maintainers who are allowed to make NMUs for these "important" updates. The problem is we don't really have the concept of an NMU currently, although this is (again) due to accidents of history, rather than by design. The current upload policy is: - Only the maintainer for a package maintainer is allowed to upload that package. - If a package is orphaned (has no maintainer), there are some "trusted" maintainers who are allowed to upload it. I'm kind of inclined to relax that a bit, although I'm not sure what to. I've cleaned-up a lot of the inconsistencies around the abilities of "trusted" maintainers. They can already modify the package maintainer database to handle ITPs, package orphaning, adoption and removal. They should now be permitted to upload, git push, deploy, vault, etc. all packages (orphaned or not), as if they were the package maintainer. Entrusted with these strange superpowers, the following god-like beings walk unknown amongst us: Achim Gratz Corinna Vinschen Ken Brown Marco Atzeri (as a note, they can already do all the above, and more, by virtue of having cygwin group shell access on sourceware, but I don't consider that a pre-requisite for the future)
Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
Dne 05.12.2022 v 21:54 Jon Turney via Cygwin-apps napsal(a): On 01/12/2022 20:18, Libor Ukropec wrote: Dne 01.12.2022 v 20:41 Jon Turney napsal(a): On 17/11/2022 10:24, Libor Ukropec wrote: > > If that's not what the desired outcome here, please let me know. I wanted that. Sorry for taking so long over this. I guess somebody should ping Michael Wild to ask about the rest of his packages. I already did that 29 days ago, no response yet https://github.com/wildmichael/cygwin/issues/1 The paramiko depends on python-bcrypt and python-nacl so I'd like to ask for their ownership too, otherwise the ownership for paramiko does not make sense. I've given you maintainer-ship of these as well (Marco is a co-maintainer of python-bcrypt). thanks, python-nacl already in playground, tests are passing. I wanted to ask for ITA, but didn't find a time for it, I hope it is not a big problem from the process view and also the other developers. I've run my ctm2git tool [1] to generate the packaging git repos for python-paramiko and python-nacl with history, which I try to remember to do for package adoptions, when it doesn't already exist. Let me know if you'd like those removed. no need to remove, always good to have track of history from which it has derived (I didn't run if for bcrypt in case Marco doesn't want that) it seems it is not necessary, as bcrypt is the latest we can support (3.2.0) and Python 3.9 is supported too. python-paramiko seems to have more issues to solve, for now I'm disabling the python tests Thank you, Libor [1] https://github.com/jon-turney/ctm2git (but it's totally janky, so you're better off just asking me to run it :)) If Michael Wild by any chance responds and still would like to maintain those packages, I'll be happy to return them :)
Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
Dne 02.12.2022 v 9:20 Marco Atzeri napsal(a): On 01.12.2022 21:18, Libor Ukropec wrote: Dne 01.12.2022 v 20:41 Jon Turney napsal(a): On 17/11/2022 10:24, Libor Ukropec wrote: Dne 16.11.2022 v 12:52 Thomas Wolff napsal(a): What I do not want to do is the violent take over, so I gave some time to the original owner of the python-paramiko to respond. I created a bug on github.com almost 2 weeks ago and so far no reaction: https://github.com/wildmichael/cygwin/issues/1 As a general comment, I'd like to point out that "almost 2 weeks" is even less than someone's holiday time may be... See above in the thread - author did not react here on cygwin for months. What I did, I've found the author on GitHub and contacted him there as well. >>Jon Turney: It's undefined how many times we should ping, or how long we should wait for a response, but I think that the ~10 months that's elapsed here is more than enough! Yeah, 10 months is not 2 weeks. Libor, I've given you maintainer-ship of python-paramiko. Jon, I did not ask for it officially yet (quite busy and had issues with duplicity that depends on the paramiko itself, so I intentionally waited if something happens). > > If that's not what the desired outcome here, please let me know. I wanted that. Sorry for taking so long over this. I guess somebody should ping Michael Wild to ask about the rest of his packages. I already did that 29 days ago, no response yet https://github.com/wildmichael/cygwin/issues/1 The paramiko depends on python-bcrypt and python-nacl so I'd like to ask for their ownership too, otherwise the ownership for paramiko does not make sense. If Michael Wild by any chance responds and still would like to maintain those packages, I'll be happy to return them :) you can ITA python-nacl there is little to do for python-bcrypt as newer versions require rust and we have no compiler for it. Yes, I learned that 3.2.0 is the last we can support in Cygwin. I didn't notice that bcrypt is also for Python 3.9 (becuase nacl wasn't and all was in paramiko repository). In this case, I'm unblocked. Regards, Libor Regards Marco
Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
On 01/12/2022 20:18, Libor Ukropec wrote: Dne 01.12.2022 v 20:41 Jon Turney napsal(a): On 17/11/2022 10:24, Libor Ukropec wrote: > > If that's not what the desired outcome here, please let me know. I wanted that. Sorry for taking so long over this. I guess somebody should ping Michael Wild to ask about the rest of his packages. I already did that 29 days ago, no response yet https://github.com/wildmichael/cygwin/issues/1 The paramiko depends on python-bcrypt and python-nacl so I'd like to ask for their ownership too, otherwise the ownership for paramiko does not make sense. I've given you maintainer-ship of these as well (Marco is a co-maintainer of python-bcrypt). I've run my ctm2git tool [1] to generate the packaging git repos for python-paramiko and python-nacl with history, which I try to remember to do for package adoptions, when it doesn't already exist. Let me know if you'd like those removed. (I didn't run if for bcrypt in case Marco doesn't want that) [1] https://github.com/jon-turney/ctm2git (but it's totally janky, so you're better off just asking me to run it :)) If Michael Wild by any chance responds and still would like to maintain those packages, I'll be happy to return them :)
Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
On 01.12.2022 21:18, Libor Ukropec wrote: Dne 01.12.2022 v 20:41 Jon Turney napsal(a): On 17/11/2022 10:24, Libor Ukropec wrote: Dne 16.11.2022 v 12:52 Thomas Wolff napsal(a): What I do not want to do is the violent take over, so I gave some time to the original owner of the python-paramiko to respond. I created a bug on github.com almost 2 weeks ago and so far no reaction: https://github.com/wildmichael/cygwin/issues/1 As a general comment, I'd like to point out that "almost 2 weeks" is even less than someone's holiday time may be... See above in the thread - author did not react here on cygwin for months. What I did, I've found the author on GitHub and contacted him there as well. >>Jon Turney: It's undefined how many times we should ping, or how long we should wait for a response, but I think that the ~10 months that's elapsed here is more than enough! Yeah, 10 months is not 2 weeks. Libor, I've given you maintainer-ship of python-paramiko. Jon, I did not ask for it officially yet (quite busy and had issues with duplicity that depends on the paramiko itself, so I intentionally waited if something happens). > > If that's not what the desired outcome here, please let me know. I wanted that. Sorry for taking so long over this. I guess somebody should ping Michael Wild to ask about the rest of his packages. I already did that 29 days ago, no response yet https://github.com/wildmichael/cygwin/issues/1 The paramiko depends on python-bcrypt and python-nacl so I'd like to ask for their ownership too, otherwise the ownership for paramiko does not make sense. If Michael Wild by any chance responds and still would like to maintain those packages, I'll be happy to return them :) you can ITA python-nacl there is little to do for python-bcrypt as newer versions require rust and we have no compiler for it. Regards Marco
Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
Dne 01.12.2022 v 20:41 Jon Turney napsal(a): On 17/11/2022 10:24, Libor Ukropec wrote: Dne 16.11.2022 v 12:52 Thomas Wolff napsal(a): What I do not want to do is the violent take over, so I gave some time to the original owner of the python-paramiko to respond. I created a bug on github.com almost 2 weeks ago and so far no reaction: https://github.com/wildmichael/cygwin/issues/1 As a general comment, I'd like to point out that "almost 2 weeks" is even less than someone's holiday time may be... See above in the thread - author did not react here on cygwin for months. What I did, I've found the author on GitHub and contacted him there as well. >>Jon Turney: It's undefined how many times we should ping, or how long we should wait for a response, but I think that the ~10 months that's elapsed here is more than enough! Yeah, 10 months is not 2 weeks. Libor, I've given you maintainer-ship of python-paramiko. Jon, I did not ask for it officially yet (quite busy and had issues with duplicity that depends on the paramiko itself, so I intentionally waited if something happens). > > If that's not what the desired outcome here, please let me know. I wanted that. Sorry for taking so long over this. I guess somebody should ping Michael Wild to ask about the rest of his packages. I already did that 29 days ago, no response yet https://github.com/wildmichael/cygwin/issues/1 The paramiko depends on python-bcrypt and python-nacl so I'd like to ask for their ownership too, otherwise the ownership for paramiko does not make sense. If Michael Wild by any chance responds and still would like to maintain those packages, I'll be happy to return them :) Thx! the cygport is executing in "src_test" some python tests that in the end requires some python packages not available as cygwin packages (typing_extensions, mock, pytest-mock, may be others). So should I a) remove the test? (this is not my preference) or b) specify/execute in the cygport `pip3 install pkg1 pkg2 ...` - I'd expect that executing any stuff in the cygport is not allowed (and I do not want to trigger 'misuse alarm') Any advice to this? I think BUILD_REQUIRES should include any src_test requirements. I'll try to document that more clearly. and additional question - how do I execute scallywag "before" the ITA is approved and git repo created? Can/should I use 'playground' branch for another package that I already maintain? I do not see guide on cygwin.com is explaining this. and this? You can always use the 'playground' repository for any tests or experiments.
Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
Jon Turney writes: > The current upload policy is: > - Only the maintainer for a package maintainer is allowed to upload > that package. > - If a package is orphaned (has no maintainer), there are some > "trusted" maintainers who are allowed to upload it. > > I'm kind of inclined to relax that a bit, although I'm not sure what to. Given that any maintainer can push to the playground branch, we could either use that directly for someone(tm) to merge that branch into main and thus trigger the publishing / upload or create a separate NMU branch for the same purpose. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
On 04/11/2022 13:05, Chad Dougherty wrote: On 2022-11-04 08:34, Jon Turney wrote: The second is not so clear: A package is orphaned if it's maintainer is not responsive to queries as to if they still want to be the maintainer of the package. It's undefined how many times we should ping, or how long we should wait for a response, but I think that the ~10 months that's elapsed here is more than enough! If the prospective adopter is also proposing an update that addresses security vulnerabilities in the old package, I suggest that that, and the severity and impact of those vulnerabilities be factored into the timeout decision. Well, maybe. I think a common way for distros to handle this is to have some subset of maintainers who are allowed to make NMUs for these "important" updates. The problem is we don't really have the concept of an NMU currently, although this is (again) due to accidents of history, rather than by design. The current upload policy is: - Only the maintainer for a package maintainer is allowed to upload that package. - If a package is orphaned (has no maintainer), there are some "trusted" maintainers who are allowed to upload it. I'm kind of inclined to relax that a bit, although I'm not sure what to.
Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
On 17/11/2022 10:24, Libor Ukropec wrote: Dne 16.11.2022 v 12:52 Thomas Wolff napsal(a): What I do not want to do is the violent take over, so I gave some time to the original owner of the python-paramiko to respond. I created a bug on github.com almost 2 weeks ago and so far no reaction: https://github.com/wildmichael/cygwin/issues/1 As a general comment, I'd like to point out that "almost 2 weeks" is even less than someone's holiday time may be... See above in the thread - author did not react here on cygwin for months. What I did, I've found the author on GitHub and contacted him there as well. >>Jon Turney: It's undefined how many times we should ping, or how long we should wait for a response, but I think that the ~10 months that's elapsed here is more than enough! Yeah, 10 months is not 2 weeks. Libor, I've given you maintainer-ship of python-paramiko. If that's not what the desired outcome here, please let me know. Sorry for taking so long over this. I guess somebody should ping Michael Wild to ask about the rest of his packages. the cygport is executing in "src_test" some python tests that in the end requires some python packages not available as cygwin packages (typing_extensions, mock, pytest-mock, may be others). So should I a) remove the test? (this is not my preference) or b) specify/execute in the cygport `pip3 install pkg1 pkg2 ...` - I'd expect that executing any stuff in the cygport is not allowed (and I do not want to trigger 'misuse alarm') Any advice to this? I think BUILD_REQUIRES should include any src_test requirements. I'll try to document that more clearly. and additional question - how do I execute scallywag "before" the ITA is approved and git repo created? Can/should I use 'playground' branch for another package that I already maintain? I do not see guide on cygwin.com is explaining this. and this? You can always use the 'playground' repository for any tests or experiments.
Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
On Thu, 17 Nov 2022 11:24:38 +0100, Libor Ukropec wrote: the cygport is executing in "src_test" some python tests that in the end requires some python packages not available as cygwin packages (typing_extensions, mock, pytest-mock, may be others). So should I a) remove the test? (this is not my preference) or b) specify/execute in the cygport `pip3 install pkg1 pkg2 ...` - I'd expect that executing any stuff in the cygport is not allowed (and I do not want to trigger 'misuse alarm') Any advice to this? Check for cygport python*.cygclass src_test or other overrides. Then, check that the pip3 install ... and cygport ... check work on your local system. Finally, add to src_test prefixed with verbose to ensure logging and visibility, and check that works as expected. and additional question - how do I execute scallywag "before" the ITA is approved and git repo created? Can/should I use 'playground' branch for another package that I already maintain? I do not see guide on cygwin.com is explaining this. and this? If the git/cygwin-packages/PKG.git repo already exists, you can force push to the playground branch of that repo, otherwise you have to force push to the playground branch of the git/cygwin-packages/playground repo. See: https://cygwin.com/packaging/repos.html -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirerbut when there is no more to cut -- Antoine de Saint-Exupéry
Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
Dne 16.11.2022 v 12:52 Thomas Wolff napsal(a): What I do not want to do is the violent take over, so I gave some time to the original owner of the python-paramiko to respond. I created a bug on github.com almost 2 weeks ago and so far no reaction: https://github.com/wildmichael/cygwin/issues/1 As a general comment, I'd like to point out that "almost 2 weeks" is even less than someone's holiday time may be... See above in the thread - author did not react here on cygwin for months. What I did, I've found the author on GitHub and contacted him there as well. >>Jon Turney: It's undefined how many times we should ping, or how long we should wait for a response, but I think that the ~10 months that's elapsed here is more than enough! the cygport is executing in "src_test" some python tests that in the end requires some python packages not available as cygwin packages (typing_extensions, mock, pytest-mock, may be others). So should I a) remove the test? (this is not my preference) or b) specify/execute in the cygport `pip3 install pkg1 pkg2 ...` - I'd expect that executing any stuff in the cygport is not allowed (and I do not want to trigger 'misuse alarm') Any advice to this? and additional question - how do I execute scallywag "before" the ITA is approved and git repo created? Can/should I use 'playground' branch for another package that I already maintain? I do not see guide on cygwin.com is explaining this. and this? Thank you, Libor
Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
Am 15/11/2022 um 19:47 schrieb Libor Ukropec: Dne 04.11.2022 v 14:05 Chad Dougherty napsal(a): On 2022-11-04 08:34, Jon Turney wrote: The second is not so clear: A package is orphaned if it's maintainer is not responsive to queries as to if they still want to be the maintainer of the package. It's undefined how many times we should ping, or how long we should wait for a response, but I think that the ~10 months that's elapsed here is more than enough! If the prospective adopter is also proposing an update that addresses security vulnerabilities in the old package, I suggest that that, and the severity and impact of those vulnerabilities be factored into the timeout decision. What I do not want to do is the violent take over, so I gave some time to the original owner of the python-paramiko to respond. I created a bug on github.com almost 2 weeks ago and so far no reaction: https://github.com/wildmichael/cygwin/issues/1 As a general comment, I'd like to point out that "almost 2 weeks" is even less than someone's holiday time may be... So I'd like to ask for ITA for his several packages, BUT: the cygport is executing in "src_test" some python tests that in the end requires some python packages not available as cygwin packages (typing_extensions, mock, pytest-mock, may be others). So should I a) remove the test? (this is not my preference) or b) specify/execute in the cygport `pip3 install pkg1 pkg2 ...` - I'd expect that executing any stuff in the cygport is not allowed (and I do not want to trigger 'misuse alarm') and additional question - how do I execute scallywag "before" the ITA is approved and git repo created? Can/should I use 'playground' branch for another package that I already maintain? I do not see guide on cygwin.com is explaining this. Thank you, Libor
Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
Dne 04.11.2022 v 14:05 Chad Dougherty napsal(a): On 2022-11-04 08:34, Jon Turney wrote: The second is not so clear: A package is orphaned if it's maintainer is not responsive to queries as to if they still want to be the maintainer of the package. It's undefined how many times we should ping, or how long we should wait for a response, but I think that the ~10 months that's elapsed here is more than enough! If the prospective adopter is also proposing an update that addresses security vulnerabilities in the old package, I suggest that that, and the severity and impact of those vulnerabilities be factored into the timeout decision. What I do not want to do is the violent take over, so I gave some time to the original owner of the python-paramiko to respond. I created a bug on github.com almost 2 weeks ago and so far no reaction: https://github.com/wildmichael/cygwin/issues/1 So I'd like to ask for ITA for his several packages, BUT: the cygport is executing in "src_test" some python tests that in the end requires some python packages not available as cygwin packages (typing_extensions, mock, pytest-mock, may be others). So should I a) remove the test? (this is not my preference) or b) specify/execute in the cygport `pip3 install pkg1 pkg2 ...` - I'd expect that executing any stuff in the cygport is not allowed (and I do not want to trigger 'misuse alarm') and additional question - how do I execute scallywag "before" the ITA is approved and git repo created? Can/should I use 'playground' branch for another package that I already maintain? I do not see guide on cygwin.com is explaining this. Thank you, Libor
Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
On 2022-11-04 08:34, Jon Turney wrote: The second is not so clear: A package is orphaned if it's maintainer is not responsive to queries as to if they still want to be the maintainer of the package. It's undefined how many times we should ping, or how long we should wait for a response, but I think that the ~10 months that's elapsed here is more than enough! If the prospective adopter is also proposing an update that addresses security vulnerabilities in the old package, I suggest that that, and the severity and impact of those vulnerabilities be factored into the timeout decision. -- -Chad
How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
On 02/11/2022 20:04, Libor Ukropec wrote: Hello Michael, Marco, any update for paramiko and Python 3.9? I'd like to update duplicity that depends on the paramiko lib and because the default Python is 3.9 I hit the wall. Also I do not see the paramiko in the GIT repositories (https://www.cygwin.com/git-cygwin-packages/?a=project_list;pf=git/cygwin-packages) nor the https://cygwin.com/packages/summary/python-paramiko-src.html does not mention the GIT repo at all. Is the package orphaned? If yes, I'd be happy to take over. (btw how package becames orphaned?) I think the same case will be the python-nacl and python-bcrypt Yeah, we could probably do with a clearer policy on that. There are two cases: The first is simple: A package can become orphaned by it's maintainer announcing that they are orphaning it, or retiring. The second is not so clear: A package is orphaned if it's maintainer is not responsive to queries as to if they still want to be the maintainer of the package. It's undefined how many times we should ping, or how long we should wait for a response, but I think that the ~10 months that's elapsed here is more than enough!
Re: Attn maintainer: python-paramiko
Hello Michael, Marco, any update for paramiko and Python 3.9? I'd like to update duplicity that depends on the paramiko lib and because the default Python is 3.9 I hit the wall. Also I do not see the paramiko in the GIT repositories (https://www.cygwin.com/git-cygwin-packages/?a=project_list;pf=git/cygwin-packages) nor the https://cygwin.com/packages/summary/python-paramiko-src.html does not mention the GIT repo at all. Is the package orphaned? If yes, I'd be happy to take over. (btw how package becames orphaned?) I think the same case will be the python-nacl and python-bcrypt Regards, Libor Dne 27.01.2022 v 5:18 Marco Atzeri napsal(a): On 23.01.2022 23:17, Marco Atzeri wrote: Michael, can you please add the python39 $ cygcheck -cd |grep paramiko python36-paramiko 2.7.2-0 python37-paramiko 2.7.2-0 python38-paramiko 2.7.2-0 and please avoid the usage of revision 0 Regards Marco Michael, let me know if I should upload for you Regards Marco
Re: Attn maintainer: python-paramiko
On 23.01.2022 23:17, Marco Atzeri wrote: Michael, can you please add the python39 $ cygcheck -cd |grep paramiko python36-paramiko 2.7.2-0 python37-paramiko 2.7.2-0 python38-paramiko 2.7.2-0 and please avoid the usage of revision 0 Regards Marco Michael, let me know if I should upload for you Regards Marco
Re: [ATTN MAINTAINER] python
On Mar 4 22:39, Achim Gratz wrote: > 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 Nothing to see here. That's just gcc's alloca implementation crashing due to a stack overflow. No hint as for the cause of the excessive stack usage, unfortunately. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpJ_V9OkdVPA.pgp Description: PGP signature
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: [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
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: [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: > 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: [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 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 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: [ATTN MAINTAINER] python
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. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [ATTN MAINTAINER] python
On Mar 3 21:51, Achim Gratz wrote: > Achim Gratz writes: > > While building maxima I've come across a consistent SEGV crash of python > > on both architectures. To reproduce, change into the doc/info dirextory > > and run > > > > $ sh ./extract_categories.sh maxima > > > > The crash seems to relate to the number of lines in the program (thare > > are about 2 lines and it does not crash with just 5000). The same > > program works without problems on Linux. It creates and deletes a lot > > of variables, so the SEGV might be related to either the GC or memory > > allocation in Python. > > 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? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpe0sQHeBMgJ.pgp Description: PGP signature
Re: [ATTN MAINTAINER] python
Achim Gratz writes: > While building maxima I've come across a consistent SEGV crash of python > on both architectures. To reproduce, change into the doc/info dirextory > and run > > $ sh ./extract_categories.sh maxima > > The crash seems to relate to the number of lines in the program (thare > are about 2 lines and it does not crash with just 5000). The same > program works without problems on Linux. It creates and deletes a lot > of variables, so the SEGV might be related to either the GC or memory > allocation in Python. 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. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
