Re: [PATCH] setup.exe
On Sat, Jan 19, 2013 at 08:41:05AM +0100, Achim Gratz wrote: Christopher Faylor writes: You'd really be much better served to submit one patch at a time. Noted. If you look at bootstrap.sh, you will see why I'm puzzled why this should be needed. The script is intended to be run from the build directory which should be separate from the source directory. In all the combinations I tried, this didn't result in a working build environment, but let me try again. It is possible I got fooled by CVSgrab and there's still something missing in my source tree. strip as a target is really not a good idea. I'm not wedded to the name and I really only intend to use upx myself (whose name is also up for grabs if you don't like it). Who is the target audience for this? I'm in the process of updating our age-old IT approved Cygwin installation to 1.7.x. One of the things I need to provide is the ability to freeze and roll back installations to some known state and do it from a script. I'm really not too keen on adding hacks to setup so that people can use it for other than its intended purpose. The code is already a complicated obtuse mishmash and adding more stuff which would be used by only one person doesn't seem like a good idea. cgf
Re: [PATCH] setup.exe
Christopher Faylor writes: I'm really not too keen on adding hacks to setup so that people can use it for other than its intended purpose. If there is another method to do an unattended Cygwin install, I'm all ears. I have briefly pondered to script a standalone installer, but it requires too much infrastructure and I don't see much value in trying to re-do what setup.exe already does. The question of doing unattended installs comes up often enough that official support would be nice, IMHO. The code is already a complicated obtuse mishmash and adding more stuff which would be used by only one person doesn't seem like a good idea. A self-fulfilling prophecy: nobody is doing it because nobody is doing it. I'll have to add on whatever I need, if it's useless to you then just don't use it. 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: [PATCH] setup.exe
On Sat, Jan 19, 2013 at 09:47:31PM +0100, Achim Gratz wrote: Christopher Faylor writes: I'm really not too keen on adding hacks to setup so that people can use it for other than its intended purpose. If there is another method to do an unattended Cygwin install, I'm all ears. I have briefly pondered to script a standalone installer, but it requires too much infrastructure and I don't see much value in trying to re-do what setup.exe already does. The question of doing unattended installs comes up often enough that official support would be nice, IMHO. I was referring to your change which handled versioned setup.ini's. That is not a requirement for an unattended Cygwin install. The code is already a complicated obtuse mishmash and adding more stuff which would be used by only one person doesn't seem like a good idea. A self-fulfilling prophecy: nobody is doing it because nobody is doing it. I'll have to add on whatever I need, if it's useless to you then just don't use it. If there was a general hue and cry for the feature that you want to add, I'd consider adding it. AFAIK, there isn't. If we did add it we would be obligated to support it so, if there is a need for this type of feature, I'd like to see a lot more discussion about why it's necessary and the best way to implement it. cgf
Re: [PATCH] setup.exe
Achim, reguardless of if this code getting into cygwin (or not), could you be able to provide a copy of this on public git/whatever server? I really like this. Just for note, in the past, unattended instalation/update using automated package management, we resorted into using apt-cyg written by Stephen Jungels. (http://code.google.com/apt-cyg) However, I had requirements for closed network instalation, and (back then nobody supported that) added options for --localdiskcache, --force, --ForceUpdate and md5sum file check... etc. The modified script is floating in superuser.com (superuser.com/questions/99198/cygwin-offline-installer) if anyone wants it. Its just that we have duplication on effort here, not just me, Achim, the cyg-apt(diffrent guy), more then few Alternative installers on the net, each admin having their own way of ghosting/cloneing/setting up cygwin... It may not be the intended use-case of the cygwin dev, however with all respect, there is a need for a solid cui with /short and sweet options/automated install/update/package management/use of proxy(s)/cache/use of mirror/alternative dir as source/dl from multiple servers/offline/version check/hash check, as a bare minimum requirement when managing multilpe clients. And setup.exe has very good GUI, with new and improved commandlines, its just that it is not suitable for day to day administration purpose. However we all have diffrent ways of providing the package data. Nfs/mirror/rsync/ftp/p2p/samba/dvd/ghost/proxy, etc,etc... Trying to provide Everything in setup.exe is cauing the code to get into spagetti. Could we somehow share and concatinate the effort? My 2cents worth of thought tells me, providing setup.exe as front end/stub/gui to call a solid back end package manager is a reasonable way to go. For admin purpose using the backend directly. With well difined porotocol on package version control, we could start writeing / or even re-use existing package managers. Just a thought. GreenFox On 1/20/13, Christopher Faylor wrote: On Sat, Jan 19, 2013 at 09:47:31PM +0100, Achim Gratz wrote: Christopher Faylor writes: I'm really not too keen on adding hacks to setup so that people can use it for other than its intended purpose. If there is another method to do an unattended Cygwin install, I'm all ears. I have briefly pondered to script a standalone installer, but it requires too much infrastructure and I don't see much value in trying to re-do what setup.exe already does. The question of doing unattended installs comes up often enough that official support would be nice, IMHO. I was referring to your change which handled versioned setup.ini's. That is not a requirement for an unattended Cygwin install. The code is already a complicated obtuse mishmash and adding more stuff which would be used by only one person doesn't seem like a good idea. A self-fulfilling prophecy: nobody is doing it because nobody is doing it. I'll have to add on whatever I need, if it's useless to you then just don't use it. If there was a general hue and cry for the feature that you want to add, I'd consider adding it. AFAIK, there isn't. If we did add it we would be obligated to support it so, if there is a need for this type of feature, I'd like to see a lot more discussion about why it's necessary and the best way to implement it. cgf
Re: [PATCH] setup.exe
green fox writes: Achim, reguardless of if this code getting into cygwin (or not), could you be able to provide a copy of this on public git/whatever server? I plan to publish my infrastructure, but haven't yet since it a) isn't feature complete and b) I need to clean up a few things. I don't want to fork setup.exe if I can help it. I really like this. Thanks. Just for note, in the past, unattended instalation/update using automated package management, we resorted into using apt-cyg written by Stephen Jungels. I've looked at apt-cyg and all the other alternative installers I could find, but they could either not bootstrap Cygwin or would require too much infrastructure for installation. That's why I decided to stick with setup.exe (also because it is the supported Cygwin installer). Let me briefly describe how it works: I currently use lftp to mirror Cygwin and Cygport locally (in a pinch you could use setup.exe itself to do this). I have locally built packages and (sometimes) the Cygwin snapshots re-packaged into Cygwin packages as additional package sources. I then use a Perl script to combine all package sources, pull in dependencies of the selected packages and write this out to a new setup.ini and install hierarchy (optionally with removing unreferenced files from earlier versions). I'm injecting additional groups into the new setup.ini so that I can do different installs from the same setup.ini easily (I currently have CLI, GUI, Devel, CygDev - but you can define whatever you want). This is what then gets distributed to the software servers and installed via batch files, or you could even put it on a flash drive or burn a DVD. This is working and it doesn't require any changes to setup.exe. The users can use setup.exe to alter their installations if they think they know what they're doing and I can keep providing updated versions without messing up all those installations each time. As I said, I have additional requirements to provide different releases, which for the sake of discussion can be simplified to being able to take a setup.ini and freeze it along with all the package files it references and then be able to install it again in exactly that state at a later time. Its just that we have duplication on effort here, not just me, Achim, the cyg-apt(diffrent guy), more then few Alternative installers on the net, each admin having their own way of ghosting/cloneing/setting up cygwin... I guess anyone trying to get Cygwin into a corporate network is in the same boat. It may not be the intended use-case of the cygwin dev, however with all respect, there is a need for a solid cui with /short and sweet options/automated install/update/package management/use of proxy(s)/cache/use of mirror/alternative dir as source/dl from multiple servers/offline/version check/hash check, as a bare minimum requirement when managing multilpe clients. So far, the only things I would want to change in setup.exe is to name alternative setup.ini files (for which I sent the patch), but given the resistance I've met I'll check again if I can work around this without duplicating whole directory trees or using links/junctions. If it's possible to do the moral equivalent by just changing the directory structure, then I'll happily drop the patch. The remaining wishes are to add an option to again provide the install+update functionality that was briefly present but then got changed into either install or update (which currently requires to start setup.exe two times in a row) and the ability to delete packages from the command line. The functionality to do this already is in setup.exe, there are just no controls for this on the command line. Maybe an option to suppress the GUI completely would be nice, but I personally like to have the progress status on screen. And setup.exe has very good GUI, with new and improved commandlines, its just that it is not suitable for day to day administration purpose. However we all have diffrent ways of providing the package data. Nfs/mirror/rsync/ftp/p2p/samba/dvd/ghost/proxy, etc,etc... Trying to provide Everything in setup.exe is cauing the code to get into spagetti. As I said, this is all dealt with outside setup.exe already and I agree that this should _not_ be bolted onto setup.exe at all. My 2cents worth of thought tells me, providing setup.exe as front end/stub/gui to call a solid back end package manager is a reasonable way to go. That would be a different setup.exe than we have today. If Cygwin wants to go that route, a more capable package backend would be nice, libzypp anyone? For admin purpose using the backend directly. With well difined porotocol on package version control, we could start writeing / or even re-use existing package managers. Just a thought. While I'd love to see something like this, see above why the current state isn't that far from what is needed, at least in the short term. Regards, Achim. -- +[Q+
Re: [PATCH] setup.exe
Christopher Faylor writes: I was referring to your change which handled versioned setup.ini's. That is not a requirement for an unattended Cygwin install. I do have that requirement, not that I love it very much. If there was a general hue and cry for the feature that you want to add, I'd consider adding it. AFAIK, there isn't. The mere existence of multiple alternative installers should speak to you. If we did add it we would be obligated to support it so, if there is a need for this type of feature, I'd like to see a lot more discussion about why it's necessary and the best way to implement it. I have one last idea of how to live without that particular change. If it works, I'll drop the patch. I will propose at least two other changes that I don't think have workarounds that wouldn't require to duplicate large swathes of functionality that already is in setup.exe, but simply not accessible from the command line. 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
src/winsup/cygwin ChangeLog exceptions.cc sigp ...
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2013-01-19 15:41:56 Modified files: winsup/cygwin : ChangeLog exceptions.cc sigproc.cc syscalls.cc Log message: Pull in changes from HEAD Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.5939.2.47r2=1.5939.2.48 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/exceptions.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.391.2.10r2=1.391.2.11 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/sigproc.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.388.2.10r2=1.388.2.11 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.638.2.7r2=1.638.2.8
src/winsup/cygwin ChangeLog.64bit dcrt0.cc per ...
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2013-01-19 17:20:34 Modified files: winsup/cygwin : ChangeLog.64bit dcrt0.cc perprocess.h winsup/cygwin/include/sys: cygwin.h Log message: * dcrt0.cc (_cygwin_exit_return): Define to allow usage of same C symbol name independent of target. * perprocess.h (SIZEOF_PER_PROCESS): Define for x86_64. * include/sys/cygwin.h (struct per_process): Tweak definition for x86_64. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.64bit.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.1.2.66r2=1.1.2.67 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dcrt0.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.434.2.8r2=1.434.2.9 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/perprocess.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.3r2=1.3.38.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/sys/cygwin.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.99.2.5r2=1.99.2.6
winsup/cygwin ChangeLog sigproc.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2013-01-20 06:34:59 Modified files: cygwin : ChangeLog sigproc.cc Log message: * sigproc.cc (sig_dispatch_pending): Add correct regparm attributes to match declaration. (pid_exists): Ditto. (proc_subproc): Ditto. (sig_clear): Ditto. (sig_send): Ditto. (checkstate): Ditto. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.6045r2=1.6046 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/sigproc.cc.diff?cvsroot=uberbaumr1=1.406r2=1.407
Re: Binutils objcopy bug (was Re: rebase segfault)
On 1/16/2013 1:35 PM, Corinna Vinschen wrote: This is a serious bug in objcopy in the current binutils. Given that cygport creates the debug info automatically, we might end up with spuriously broken DLLs in the distro. I checked with objcopy from the older binutils 2.51.53-2, and the problem did not show up. I also built the latest binutils release 2.23.1 and the problem also doesn't show, so we probably can get away with just a black eye by updating binutils to 2.23.1. Chris? Hi Corinna, it seems not so easy. Just built from cvs objcopy --version GNU objcopy (GNU Binutils) 2.23.51.20130119 but the problem is still there Corinna Regards Marco -- 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: Binutils objcopy bug (was Re: rebase segfault)
On Jan 19 09:56, marco atzeri wrote: On 1/16/2013 1:35 PM, Corinna Vinschen wrote: This is a serious bug in objcopy in the current binutils. Given that cygport creates the debug info automatically, we might end up with spuriously broken DLLs in the distro. I checked with objcopy from the older binutils 2.51.53-2, and the problem did not show up. I also built the latest binutils release 2.23.1 and the problem also doesn't show, so we probably can get away with just a black eye by updating binutils to 2.23.1. Chris? Hi Corinna, it seems not so easy. Just built from cvs objcopy --version GNU objcopy (GNU Binutils) 2.23.51.20130119 but the problem is still there You're right, unfortunately. I don't know what I did when testing it 3 days ago, but now I can reproduce the crash even with 2.23.1. Bummer. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Fwd:
http://vinipoderevecciano.it/admin/about/ht6wn2.php -- 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: deadlock with busy waiting on sigfe
On 2013-01-16 AM 11:14, Christopher Faylor wrote: On Tue, Jan 15, 2013 at 08:46:46PM -0500, Christopher Faylor wrote: Sorry, the backtraces were actually useful because they show that you are apparently running cygwin-snapshot-20130107. Apparently you haven't been watching the discussion about this issue in the Cygwin list. The problem of a Cygwin process hanging after a single CTRL-C should be fixed in later snapshots although there is another reported CTRL-C issue. cgf now i found hang where the argument of program was sed s/^\(.*\)-\([^-]*-[^-]*\)$/\2/ with newer cygwin snapshot. (gdb) thread apply all bt Thread 4 (Thread 12972.0x382c): #0 0x7c95a22a in ntdll!DbgBreakPoint () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c97fc68 in ntdll!DbgUiRemoteBreakin () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x0005 in ?? () #3 0x0001 in ?? () #4 0x003effd0 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 2 (Thread 12972.0x32c8): #0 0x7c96845c in ntdll!KiFastSystemCallRet () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c9678c9 in ntdll!ZwSetInformationThread () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c8324f9 in SetThreadPriority () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x6108760b in yield () at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/miscfuncs.cc:244 #4 0x610d6ee4 in _cygtls::lock() () from /usr/bin/cygwin1.dll #5 0x6103035e in sigpacket::setup_handler (this=0x6cac34, handler=0x6102fe30 signal_exit(int, siginfo_t*), siga=..., tls=0x22ce64) ---Type return to continue, or q return to quit--- at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/exceptions.cc:796 #6 0x61031a48 in sigpacket::process (this=0x6cac34) at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/exceptions.cc:1274 #7 0x610dd2dc in wait_sig () at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/sigproc.cc:1389 #8 0x61003ea5 in cygthread::callfunc (this=0x6118b400 threads, issimplestub=optimized out) at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/cygthread.cc:51 #9 0x6100442f in cygthread::stub (arg=0x6118b400 threads) at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/cygthread.cc:93 #10 0x6100538d in _cygtls::call2 (this=optimized out, func=0x610043e0 _ZN9cygthread4stubEPv@4, arg=0x6118b400 threads, buf=0x6100551b _cygtls::call(unsigned long (*)(void*, void*), void*)+91) at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/cygtls.cc:99 #11 0x006cffb8 in ?? () #12 0x7c82484f in KERNEL32!GetModuleHandleA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #13 0x in ?? () Thread 1 (Thread 12972.0x2f38): #0 0x7c96845c in ntdll!KiFastSystemCallRet () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c9678c9 in ntdll!ZwSetInformationThread () ---Type return to continue, or q return to quit--- from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c8324f9 in SetThreadPriority () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x6108764d in yield () at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/miscfuncs.cc:253 #4 0x610d6dcc in _sigfe () from /usr/bin/cygwin1.dll #5 0x61083a40 in mallinfo () at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/malloc_wrapper.cc:2 6 #6 0x6123e9a0 in saved_categories () from /usr/bin/cygwin1.dll #7 0x in ?? () (gdb) (gdb) x 7ffdd000+4 0x7ffdd004: 0x0023 (gdb) x ((_cygtls*)(0x0023-319c))-stackptr 0x22da30: 0x61083ac9 (gdb) i line *0x61083ac9 Line 290 of /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/malloc_wrapper .cc starts at address 0x61083ac9 malloc_init()+57 and ends at 0x61083ad3 malloc_init()+67. It seems that malloc_init called sigfe-annotated malloc or free during wait_sig thread tried to process exit signal. -- Regards. -- 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: deadlock with busy waiting on sigfe
On Sun, Jan 20, 2013 at 02:23:23PM +0900, jojelino wrote: On 2013-01-16 AM 11:14, Christopher Faylor wrote: On Tue, Jan 15, 2013 at 08:46:46PM -0500, Christopher Faylor wrote: Sorry, the backtraces were actually useful because they show that you are apparently running cygwin-snapshot-20130107. Apparently you haven't been watching the discussion about this issue in the Cygwin list. The problem of a Cygwin process hanging after a single CTRL-C should be fixed in later snapshots although there is another reported CTRL-C issue. now i found hang where the argument of program was sed s/^\(.*\)-\([^-]*-[^-]*\)$/\2/ with newer cygwin snapshot. Once again: don't care about your backtraces. Submit a proper bug report. cgf -- 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
