Re: Setup patch to keep test version if test version installed
On Feb 8 21:24, Achim Gratz wrote: Corinna Vinschen writes: Please apply. Done. The notice via cygwin-apps-cvs was lost while the mailer was having trouble to recognize the cygwin.com mailing lists. The patch is in, that's the important part :) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpO6ECHNY8n1.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: Please apply. Done. The notice via cygwin-apps-cvs was lost while the mailer was having trouble to recognize the cygwin.com mailing lists. 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: Setup patch to keep test version if test version installed
On Feb 5 22:47, Achim Gratz wrote: Corinna Vinschen writes: ...in other words, just drop the last three lines in your setup.hint, and the external-source hint. Done. I noticed just in time that the preremove scripts can't be dash scripts at the moment. Here's a patch to change that and also allow .cmd scripts, just like already done for postinstall scripts: install.cc: allow .dash and .cmd extensions for preremove scripts also Please apply. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpedGuXIIPdq.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: On Feb 5 22:57, Achim Gratz wrote: Oh, and while you are so deep in the bowels of setup.exe, would it be possible to somehow fake a pty to shell scripts and a console to cmd so that the scripts run by setup.exe produce their output in line-buffered instead of fully buffered mode? Er... uh... *cough*... PTC? I was hoping you had an idea of how to do this. I'm coming up empty. For Cygwin processes this would require to duplicate lots of the pty code from Cygwin to Setup. For native commands it might be enough to play with the process creation flags in the call to CreateProcess, but that might lead to a flickering taskbar entry for a hidden console. I've tried to look for recipes, but have not found any that look promising. http://www.pixelbeat.org/programming/stdio_buffering/ I notice the lack of both unbuffer and stdbuf in Cygwin packages… I don't think it's possible to ask another application to flush their buffers or is there? The other problem is that the stdio handles are redirected to a file and thus, even if you have a console or pty, the output from the command will use fully buffered mode. The only way around that, afaics, is some sort of global setting (env var?) for the buffering mode which is honored by native processes and which may be read by the Cygwin DLL as well to enforce line buffering. But I'm not aware such a setting exists. Doesn't sound appealing. Maybe we just have to live with 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: Setup patch to keep test version if test version installed
On Feb 6 12:25, Achim Gratz wrote: Corinna Vinschen writes: On Feb 5 22:57, Achim Gratz wrote: Oh, and while you are so deep in the bowels of setup.exe, would it be possible to somehow fake a pty to shell scripts and a console to cmd so that the scripts run by setup.exe produce their output in line-buffered instead of fully buffered mode? Er... uh... *cough*... PTC? I was hoping you had an idea of how to do this. I'm coming up empty. For Cygwin processes this would require to duplicate lots of the pty code from Cygwin to Setup. For native commands it might be enough to play with the process creation flags in the call to CreateProcess, but that might lead to a flickering taskbar entry for a hidden console. I've tried to look for recipes, but have not found any that look promising. http://www.pixelbeat.org/programming/stdio_buffering/ I notice the lack of both unbuffer and stdbuf in Cygwin packages… Unbuffer should be in the expect package, stdbuf in coreutils. In both cases I don't know why they are missing in Cygwin. Yaakov? Eric? I don't think it's possible to ask another application to flush their buffers or is there? If the application isn't prepared to do that (e.g. via signal), no. The other problem is that the stdio handles are redirected to a file and thus, even if you have a console or pty, the output from the command will use fully buffered mode. The only way around that, afaics, is some sort of global setting (env var?) for the buffering mode which is honored by native processes and which may be read by the Cygwin DLL as well to enforce line buffering. But I'm not aware such a setting exists. Doesn't sound appealing. Maybe we just have to live with it. Looks like it, sorry. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp87H01Ty0xU.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Feb 5 22:57, Achim Gratz wrote: Oh, and while you are so deep in the bowels of setup.exe, would it be possible to somehow fake a pty to shell scripts and a console to cmd so that the scripts run by setup.exe produce their output in line-buffered instead of fully buffered mode? Er... uh... *cough*... PTC? For Cygwin processes this would require to duplicate lots of the pty code from Cygwin to Setup. For native commands it might be enough to play with the process creation flags in the call to CreateProcess, but that might lead to a flickering taskbar entry for a hidden console. The other problem is that the stdio handles are redirected to a file and thus, even if you have a console or pty, the output from the command will use fully buffered mode. The only way around that, afaics, is some sort of global setting (env var?) for the buffering mode which is honored by native processes and which may be read by the Cygwin DLL as well to enforce line buffering. But I'm not aware such a setting exists. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp9vcUPsxY_U.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On 02/06/2015 02:24 AM, Corinna Vinschen wrote: On Feb 5 22:57, Achim Gratz wrote: Oh, and while you are so deep in the bowels of setup.exe, would it be possible to somehow fake a pty to shell scripts and a console to cmd so that the scripts run by setup.exe produce their output in line-buffered instead of fully buffered mode? Er... uh... *cough*... PTC? For Cygwin processes this would require to duplicate lots of the pty code from Cygwin to Setup. For native commands it might be enough to play with the process creation flags in the call to CreateProcess, but that might lead to a flickering taskbar entry for a hidden console. For native commands (.bat, .cmd postinstalls), I have no idea. But for cygwin processes (.sh postinstalls), it would be neat if we could get coreutils' stdbuf utility working on cygwin, then we just invoke 'sh -c stdbuf script.sh' instead of 'sh -c script.sh'. The other problem is that the stdio handles are redirected to a file and thus, even if you have a console or pty, the output from the command will use fully buffered mode. The only way around that, afaics, is some sort of global setting (env var?) for the buffering mode which is honored by native processes and which may be read by the Cygwin DLL as well to enforce line buffering. But I'm not aware such a setting exists. stdbuf uses LD_PRELOAD to tell a process in main() that it should use line or no buffering, regardless of whether the output file is a file. And cygwin supports LD_PRELOAD. But to date, no one has helped figure out how to port it to cygwin (I assume it should work, but have not had time to try it - the difficulties lie more in getting the coreutils Makefile to target the difference in cygwin naming with .dll instead of .so and with .exe suffixes to worry about). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Setup patch to keep test version if test version installed
On Feb 6 07:00, Eric Blake wrote: On 02/06/2015 02:24 AM, Corinna Vinschen wrote: On Feb 5 22:57, Achim Gratz wrote: Oh, and while you are so deep in the bowels of setup.exe, would it be possible to somehow fake a pty to shell scripts and a console to cmd so that the scripts run by setup.exe produce their output in line-buffered instead of fully buffered mode? Er... uh... *cough*... PTC? For Cygwin processes this would require to duplicate lots of the pty code from Cygwin to Setup. For native commands it might be enough to play with the process creation flags in the call to CreateProcess, but that might lead to a flickering taskbar entry for a hidden console. For native commands (.bat, .cmd postinstalls), I have no idea. But for cygwin processes (.sh postinstalls), it would be neat if we could get coreutils' stdbuf utility working on cygwin, then we just invoke 'sh -c stdbuf script.sh' instead of 'sh -c script.sh'. The other problem is that the stdio handles are redirected to a file and thus, even if you have a console or pty, the output from the command will use fully buffered mode. The only way around that, afaics, is some sort of global setting (env var?) for the buffering mode which is honored by native processes and which may be read by the Cygwin DLL as well to enforce line buffering. But I'm not aware such a setting exists. stdbuf uses LD_PRELOAD to tell a process in main() that it should use line or no buffering, regardless of whether the output file is a file. And cygwin supports LD_PRELOAD. So it probably hooks into setbuf, setbuffer, setlinebuf and setvbuf. LD_PRELOADing libc aka cygwin1.dll itself? That sounds a bit tricky. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpPm3ilcgRix.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: ...in other words, just drop the last three lines in your setup.hint, and the external-source hint. Uploaded. Let's see what upset does with this. Regards, 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: Setup patch to keep test version if test version installed
On Feb 5 10:19, Corinna Vinschen wrote: On Feb 5 10:12, Achim Gratz wrote: Corinna Vinschen writes: Yaakov, can we *please* get this done so we can upload the new _autorebase? I guess we can do it anyway, it's not creating a new problem if these files are provided a few days later. Let me know when you've switched off the _autorebase autodep and version increment stuff and I'll upload the package. The autodep stuff is automatically removed as soon as you overwrite _autorebase'es setup.hint file since everything is code in there: s/code/coded/ sdesc: Run rebaseall automatically #external-source: rebase category: _PostInstallLast requires: noautodep: cygwin autodep: .*/[^/]*\.(?:dll|so|oct)$ incver_ifdep: yes ...in other words, just drop the last three lines in your setup.hint, and the external-source hint. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpAEgpWxX00T.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Thu, 2015-02-05 at 16:24 +0100, Achim Gratz wrote: Achim Gratz writes: Corinna Vinschen writes: ...in other words, just drop the last three lines in your setup.hint, and the external-source hint. Uploaded. Let's see what upset does with this. The pending update is currently blocked by a duplicate python-doc package... Yes, we know; it's fixed now. Yaakov
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes:
...in other words, just drop the last three lines in your setup.hint,
and the external-source hint.
Done.
I noticed just in time that the preremove scripts can't be dash scripts
at the moment.
Here's a patch to change that and also allow .cmd scripts, just like
already done for postinstall scripts:
install.cc: allow .dash and .cmd extensions for preremove scripts also
Modified install.cc
diff --git a/install.cc b/install.cc
index 60c248d..653d623 100644
--- a/install.cc
+++ b/install.cc
@@ -160,10 +160,12 @@ Installer::preremoveOne (packagemeta pkg)
Progress.SetText1 (Running preremove script...);
Progress.SetText2 (pkg.name.c_str());
Log (LOG_PLAIN) Running preremove script forpkg.name endLog;
- try_run_script (/etc/preremove/, pkg.name, .sh);
- try_run_script (/etc/preremove/, pkg.name, .bat);
+ const unsigned numexts = 4;
+ const char* exts[numexts] = { .dash, .sh, .bat, .cmd };
+ for (unsigned i = 0; i numexts; i++)
+try_run_script (/etc/preremove/, pkg.name, exts[i]);
}
void
Installer::uninstallOne (packagemeta pkg)
{
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: The pending update is currently blocked by a duplicate python-doc package... I just had a look and there's no x86/release/python/python-doc directory. It must have been removed in the last couple of minutes. With that out of the way… can someone please hand over (co-)ownership of _autorebase in cygwin-pkg-maint and !packages to me so that I can actually upload the new package? 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: Setup patch to keep test version if test version installed
On Feb 2 10:17, Corinna Vinschen wrote: On Jan 30 20:13, Achim Gratz wrote: Corinna Vinschen writes: Btw., when, do you think, is showtime for _autorebase 2.0? Sometime during the next week would be good, if not then another window I'm on vaca today, but this week sounds good to me. I will release 1.7.34, too, later this week. would be two weeks later. From the responses so far I gathered that Marco doesn#t think he needs to do something for Octave and R, I will take care of Perl myself. That leaves PHP, Ruby and Python... so Yaakov and Jason need to tell us when things are ready on their side I'd think. Well, Jason has dropped maintaiwnrship, so it's Yaakov. Yaakov? Yaakov, can we *please* get this done so we can upload the new _autorebase? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpPMipYSbhzW.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Achim Gratz writes: Corinna Vinschen writes: ...in other words, just drop the last three lines in your setup.hint, and the external-source hint. Uploaded. Let's see what upset does with this. The pending update is currently blocked by a duplicate python-doc package... 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: Setup patch to keep test version if test version installed
Oh, and while you are so deep in the bowels of setup.exe, would it be possible to somehow fake a pty to shell scripts and a console to cmd so that the scripts run by setup.exe produce their output in line-buffered instead of fully buffered mode? 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
Re: Setup patch to keep test version if test version installed
Yaakov Selkowitz writes: The pending update is currently blocked by a duplicate python-doc package... Yes, we know; it's fixed now. Rats, it had removed the !ready files before the transfer took place. I'll have to arm it again. Regards, 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: Setup patch to keep test version if test version installed
On Feb 5 16:24, Achim Gratz wrote: Achim Gratz writes: Corinna Vinschen writes: ...in other words, just drop the last three lines in your setup.hint, and the external-source hint. Uploaded. Let's see what upset does with this. The pending update is currently blocked by a duplicate python-doc package... I just had a look and there's no x86/release/python/python-doc directory. It must have been removed in the last couple of minutes. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpuDqVNGZ8V6.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Feb 5 10:12, Achim Gratz wrote: Corinna Vinschen writes: Yaakov, can we *please* get this done so we can upload the new _autorebase? I guess we can do it anyway, it's not creating a new problem if these files are provided a few days later. Let me know when you've switched off the _autorebase autodep and version increment stuff and I'll upload the package. The autodep stuff is automatically removed as soon as you overwrite _autorebase'es setup.hint file since everything is code in there: sdesc: Run rebaseall automatically #external-source: rebase category: _PostInstallLast requires: noautodep: cygwin autodep: .*/[^/]*\.(?:dll|so|oct)$ incver_ifdep: yes Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgptNQEZCXum3.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: Yaakov, can we *please* get this done so we can upload the new _autorebase? I guess we can do it anyway, it's not creating a new problem if these files are provided a few days later. Let me know when you've switched off the _autorebase autodep and version increment stuff and I'll upload the package. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Setup patch to keep test version if test version installed
On Thu, 2015-02-05 at 09:57 +0100, Corinna Vinschen wrote: On Feb 2 10:17, Corinna Vinschen wrote: On Jan 30 20:13, Achim Gratz wrote: Corinna Vinschen writes: Btw., when, do you think, is showtime for _autorebase 2.0? Sometime during the next week would be good, if not then another window I'm on vaca today, but this week sounds good to me. I will release 1.7.34, too, later this week. would be two weeks later. From the responses so far I gathered that Marco doesn#t think he needs to do something for Octave and R, I will take care of Perl myself. That leaves PHP, Ruby and Python... so Yaakov and Jason need to tell us when things are ready on their side I'd think. Well, Jason has dropped maintaiwnrship, so it's Yaakov. Yaakov? Yaakov, can we *please* get this done so we can upload the new _autorebase? Don't wait for me, my queue is a bit backlogged at the moment. -- Yaakov
Re: Setup patch to keep test version if test version installed
Marco Atzeri writes: done. You are no co-owner with Corinna Great, just in time to re-trigger the upload before the next sync. :-) Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Setup patch to keep test version if test version installed
On 2/5/2015 8:18 PM, Achim Gratz wrote: Corinna Vinschen writes: With that out of the way… can someone please hand over (co-)ownership of _autorebase in cygwin-pkg-maint and !packages to me so that I can actually upload the new package? done. You are no co-owner with Corinna Regards, Achim. Marco
Re: Setup patch to keep test version if test version installed
Hi Ken, On Feb 3 16:50, Ken Brown wrote: On 2/3/2015 10:27 AM, Corinna Vinschen wrote: On Feb 3 08:04, Ken Brown wrote: On 2/3/2015 6:33 AM, Corinna Vinschen wrote: Hey guys, On Jan 28 21:23, Corinna Vinschen wrote: https://cygwin.com/setup-test-x86.exe https://cygwin.com/setup-test-x86_64.exe [...] Did you test this version? Is it ok to become the release version of setup? It works fine for me. Nice. Are you a potential user of the -m option? No, so I couldn't test that. But it seems that others have tested it by now. Right, and thus I released this version :) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpjq5hmKQAF_.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: Try this: Works a treat, please install. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: Setup patch to keep test version if test version installed
On Feb 3 22:27, Corinna Vinschen wrote: On Feb 3 22:04, Corinna Vinschen wrote: On Feb 3 21:37, Achim Gratz wrote: I'm not sure we're talking about the same thing. I've recently added code to print an error message along with the parameter usage when a wrong option or other non-parseable stuff was given instead of simply exiting with no indication other than the non-zero exit code. The changes you've just installed look good to me, but they don't touch the exit path in question: [...] I guess with those changes one could now use Log (LOG_TIMESTAMP) instead of cerr in that place and hopefully the output would appear again? I was pretty certain I tested that in both mintty and CMD, but maybe not... I was referring explicitely to the CMD prompt being too early. I didn't test the situation when specifying a wrong option, sorry. The point in the file where this occurs is somewhat early. At this point the log stuff isn't initialized and AttachConsole hasn't been called. I'll look into that, maybe it can be fixed easily. Try this: On second thought, this is still unclean. What bugs me is that the behaviour of LogFile::exit is not easier conditionalized. I'm going to change LogFile::exit to something like this: LogFile::exit (int exit_code, bool show_end_of_install_msg) This allows to separate printing the Ending cygwin install message from the exit_code and so we can exit with a non-zero exit code *and* skip showing the message. Hang on for a bit... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgplex3psDuyR.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: I just applied a bigger patch, which not only changed exit, but the way how the actual LogFile instance gets accessed in general. I removed the variable theLog entirely and now, rather than [...] Please give it a try. For your convenience I created test releases again: Built and tested OK. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Setup patch to keep test version if test version installed
On Feb 4 12:19, Achim Gratz wrote: Corinna Vinschen writes: I just applied a bigger patch, which not only changed exit, but the way how the actual LogFile instance gets accessed in general. I removed the variable theLog entirely and now, rather than [...] Please give it a try. For your convenience I created test releases again: Built and tested OK. Thanks for testing! I'm not going to upload this for the public yet. I'm just uploading cygwin 1.7.34, that's enough to choke on for the next couple of days :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp7QZdA56zNm.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Feb 4 10:01, Corinna Vinschen wrote: On Feb 3 22:27, Corinna Vinschen wrote: On Feb 3 22:04, Corinna Vinschen wrote: On Feb 3 21:37, Achim Gratz wrote: I'm not sure we're talking about the same thing. I've recently added code to print an error message along with the parameter usage when a wrong option or other non-parseable stuff was given instead of simply exiting with no indication other than the non-zero exit code. The changes you've just installed look good to me, but they don't touch the exit path in question: [...] I guess with those changes one could now use Log (LOG_TIMESTAMP) instead of cerr in that place and hopefully the output would appear again? I was pretty certain I tested that in both mintty and CMD, but maybe not... I was referring explicitely to the CMD prompt being too early. I didn't test the situation when specifying a wrong option, sorry. The point in the file where this occurs is somewhat early. At this point the log stuff isn't initialized and AttachConsole hasn't been called. I'll look into that, maybe it can be fixed easily. Try this: On second thought, this is still unclean. What bugs me is that the behaviour of LogFile::exit is not easier conditionalized. I'm going to change LogFile::exit to something like this: LogFile::exit (int exit_code, bool show_end_of_install_msg) This allows to separate printing the Ending cygwin install message from the exit_code and so we can exit with a non-zero exit code *and* skip showing the message. Hang on for a bit... I just applied a bigger patch, which not only changed exit, but the way how the actual LogFile instance gets accessed in general. I removed the variable theLog entirely and now, rather than LogSingleton::GetInstance ().exit (1); or extern LogFile *theLog; theLog-exit (1); you can simply use the macro Logger: Logger ().exit (1); I also moved the global variable exit_msg into the LogFile class as static, protected variable, and now you access it via Logger ().setExitMsg (42); Logger ().getExitMsg (); This is much cleaner IMHO. Please give it a try. For your convenience I created test releases again: https://cygwin.com/setup-test-x86.exe https://cygwin.com/setup-test-x86_64.exe Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpPc4F71xI80.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: Did you test this version? Is it ok to become the release version of setup? WJFFM. I didn't test the downgrade scenario since none of my installations have test or prev packages in setup.ini, though. 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: Setup patch to keep test version if test version installed
On Feb 3 16:09, Achim Gratz wrote: Achim Gratz writes: [TEST 2] [TEST 3] *frown* Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpSYYQo2uQAv.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
[TEST] Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: Setup patch to keep test version if test version installed
[TEST 2] 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: Setup patch to keep test version if test version installed
Achim Gratz writes: [TEST 2] [TEST 3] Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Setup patch to keep test version if test version installed
On Feb 3 08:04, Ken Brown wrote: On 2/3/2015 6:33 AM, Corinna Vinschen wrote: Hey guys, On Jan 28 21:23, Corinna Vinschen wrote: https://cygwin.com/setup-test-x86.exe https://cygwin.com/setup-test-x86_64.exe These should fix the aforementioned bug I introduced, as well as another subtil problem when checking and unchecking the Bin/Src boxes. If both boxes were deselected, the package got uninstalled without showing up in the Pending view. I worked around that by setting the package state explicitely to Uninstall if both boxes got deselected. This version also introduces an experimental option -m/--mirror-mode. There's something bugging me for a long time as well. We're running our own Cygwin mirror on a local Linux box. The directory is mounted via NFS on my Windows boxes. So, rather than installing from internet, I Install from Local Directory, with the local directory being the NFS-mounted mirror directory. This works fine, except that, after parsing setup.ini, setup hangs unresponsive for about 2 minutes. Only then the chooser window opens. It turned out that the 2 minutes are spent iterating throught the full set of packages and testing each package and each packageversion if the underlying package file exists in the download directory. Given that the directory is a mirror in my case, the test makes only marginal sense. Therefore I added the -m option which avoids most file system access and only checks in a border case (installed version is not in setup.ini). If you're doing as I do, running a local mirror, you may welcome this option. I just don't guarantee that it always works ;} If you find a bug, don't hesitate to report it. Did you test this version? Is it ok to become the release version of setup? It works fine for me. Nice. Are you a potential user of the -m option? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpX4GHl8bdyu.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Feb 3 14:56, ASSI wrote: Corinna Vinschen writes: Did you test this version? Is it ok to become the release version of setup? WJFFM. I didn't test the downgrade scenario since none of my installations have test or prev packages in setup.ini, though. You're a user of the new -m option if I understood you correctly. Does it work for you? What about allowing to specify this in the GUI? I was mulling over adding a fourth option to the Choose A Download Source dialog: o Install from Internet o Download Without Installing o Install from Local Download Directory o Install from Local Mirror Directory Option 3 is the same as before, but specifying Download Directory to distinguish this from Mirror Directory. Good/Bad/Ugly? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpcng1if5ArM.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Hey guys, On Jan 28 21:23, Corinna Vinschen wrote: https://cygwin.com/setup-test-x86.exe https://cygwin.com/setup-test-x86_64.exe These should fix the aforementioned bug I introduced, as well as another subtil problem when checking and unchecking the Bin/Src boxes. If both boxes were deselected, the package got uninstalled without showing up in the Pending view. I worked around that by setting the package state explicitely to Uninstall if both boxes got deselected. This version also introduces an experimental option -m/--mirror-mode. There's something bugging me for a long time as well. We're running our own Cygwin mirror on a local Linux box. The directory is mounted via NFS on my Windows boxes. So, rather than installing from internet, I Install from Local Directory, with the local directory being the NFS-mounted mirror directory. This works fine, except that, after parsing setup.ini, setup hangs unresponsive for about 2 minutes. Only then the chooser window opens. It turned out that the 2 minutes are spent iterating throught the full set of packages and testing each package and each packageversion if the underlying package file exists in the download directory. Given that the directory is a mirror in my case, the test makes only marginal sense. Therefore I added the -m option which avoids most file system access and only checks in a border case (installed version is not in setup.ini). If you're doing as I do, running a local mirror, you may welcome this option. I just don't guarantee that it always works ;} If you find a bug, don't hesitate to report it. Did you test this version? Is it ok to become the release version of setup? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpYp_tBdEwmE.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: You're a user of the new -m option if I understood you correctly. Does it work for you? Yes, very well indeed. What about allowing to specify this in the GUI? I was mulling over adding a fourth option to the Choose A Download Source dialog: o Install from Internet o Download Without Installing o Install from Local Download Directory o Install from Local Mirror Directory Option 3 is the same as before, but specifying Download Directory to distinguish this from Mirror Directory. Good/Bad/Ugly? I'm not sure it's useful in the GUI-only scenario when someone just double-clicks the icon. At least in my case that use is strictly for script-controlled installations. It will be hard for people to tell what the difference is between Download and Mirror directory and which they should use. People who know what they're doing can just as easily make a shortcut that adds the -m option. BTW, there seems to be a regression that I don't understand: when a wrong option is given, a message to this effect should be emitted and then the parameter usage. This used to work, but even though the code did not change this is not happening anymore. I've rolled back to the old version of setup, but not cygwin1.dll, so if its not the compiler it would be a change in the DLL that is responsible. I suspect there is some race with the output since also in the case of --help the output from setup somehow mixes in with the prompt from cmd and you have to press Enter a second time to get the prompt back. 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: Setup patch to keep test version if test version installed
On Feb 3 17:07, Achim Gratz wrote: Corinna Vinschen writes: You're a user of the new -m option if I understood you correctly. Does it work for you? Yes, very well indeed. What about allowing to specify this in the GUI? I was mulling over adding a fourth option to the Choose A Download Source dialog: o Install from Internet o Download Without Installing o Install from Local Download Directory o Install from Local Mirror Directory Option 3 is the same as before, but specifying Download Directory to distinguish this from Mirror Directory. Good/Bad/Ugly? I'm not sure it's useful in the GUI-only scenario when someone just double-clicks the icon. At least in my case that use is strictly for script-controlled installations. It will be hard for people to tell what the difference is between Download and Mirror directory and which they should use. People who know what they're doing can just as easily make a shortcut that adds the -m option. BTW, there seems to be a regression that I don't understand: when a wrong option is given, a message to this effect should be emitted and then the parameter usage. This used to work, but even though the code did not change this is not happening anymore. I've rolled back to the old version of setup, but not cygwin1.dll, so if its not the compiler it would be a change in the DLL that is responsible. How so? Setup is not a Cygwin application. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpJ6zd43JUCk.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: On Feb 3 16:09, Achim Gratz wrote: Achim Gratz writes: [TEST 2] [TEST 3] *frown* Sorry for that, but the mail server I use needed a configuration change and this is the only mailing list that was affected so I had to test directly. Things are back to normal, I can reply and post again from Gnus. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: How so? Setup is not a Cygwin application. Good point. Then I've no idea at all, save the compiler. 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
Re: Setup patch to keep test version if test version installed
On 2/3/2015 6:33 AM, Corinna Vinschen wrote: Hey guys, On Jan 28 21:23, Corinna Vinschen wrote: https://cygwin.com/setup-test-x86.exe https://cygwin.com/setup-test-x86_64.exe These should fix the aforementioned bug I introduced, as well as another subtil problem when checking and unchecking the Bin/Src boxes. If both boxes were deselected, the package got uninstalled without showing up in the Pending view. I worked around that by setting the package state explicitely to Uninstall if both boxes got deselected. This version also introduces an experimental option -m/--mirror-mode. There's something bugging me for a long time as well. We're running our own Cygwin mirror on a local Linux box. The directory is mounted via NFS on my Windows boxes. So, rather than installing from internet, I Install from Local Directory, with the local directory being the NFS-mounted mirror directory. This works fine, except that, after parsing setup.ini, setup hangs unresponsive for about 2 minutes. Only then the chooser window opens. It turned out that the 2 minutes are spent iterating throught the full set of packages and testing each package and each packageversion if the underlying package file exists in the download directory. Given that the directory is a mirror in my case, the test makes only marginal sense. Therefore I added the -m option which avoids most file system access and only checks in a border case (installed version is not in setup.ini). If you're doing as I do, running a local mirror, you may welcome this option. I just don't guarantee that it always works ;} If you find a bug, don't hesitate to report it. Did you test this version? Is it ok to become the release version of setup? It works fine for me. Ken
Re: Setup patch to keep test version if test version installed
On Feb 3 21:37, Achim Gratz wrote:
Corinna Vinschen writes:
On Feb 3 18:08, Achim Gratz wrote:
Corinna Vinschen writes:
How so? Setup is not a Cygwin application.
Good point. Then I've no idea at all, save the compiler.
I had a look into this and even rearranged the behaviour when --help
output is requested...
However, I'm mildly sure this behaviour didn't change in the last couple
of years. The reason is that setup is not a console application but a
GUI application. When running a GUI application from CMD, CMD will
detach. Of course, when --help output is requested, setup calls
AllocConsole, but that's too late. This does not occur in a Cygwin
shell becasue Cygwin always waits for process completion unless the
process is sent to the background.
I now made the latest setup 2.864 available as standard setup version
on sourceware and removed the test releases.
I'm not sure we're talking about the same thing. I've recently added
code to print an error message along with the parameter usage when a
wrong option or other non-parseable stuff was given instead of simply
exiting with no indication other than the non-zero exit code. The
changes you've just installed look good to me, but they don't touch the
exit path in question:
--8---cut here---start-8---
if (!GetOption::GetInstance ().Process (argc,_argv, NULL))
- exit (1);
+ {
+ GetOption::GetInstance ().ParameterUsage (cerr
+\nError during option
processing.
+\nCommand Line
Options:\n);
+ exit (1);
+ }
--8---cut here---end---8---
I guess with those changes one could now use Log (LOG_TIMESTAMP) instead
of cerr in that place and hopefully the output would appear again? I
was pretty certain I tested that in both mintty and CMD, but maybe
not...
I was referring explicitely to the CMD prompt being too early. I didn't
test the situation when specifying a wrong option, sorry. The point in
the file where this occurs is somewhat early. At this point the log
stuff isn't initialized and AttachConsole hasn't been called. I'll
look into that, maybe it can be fixed easily.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpMA3MMGdE_g.pgp
Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Feb 3 18:08, Achim Gratz wrote: Corinna Vinschen writes: How so? Setup is not a Cygwin application. Good point. Then I've no idea at all, save the compiler. I had a look into this and even rearranged the behaviour when --help output is requested... However, I'm mildly sure this behaviour didn't change in the last couple of years. The reason is that setup is not a console application but a GUI application. When running a GUI application from CMD, CMD will detach. Of course, when --help output is requested, setup calls AllocConsole, but that's too late. This does not occur in a Cygwin shell becasue Cygwin always waits for process completion unless the process is sent to the background. I now made the latest setup 2.864 available as standard setup version on sourceware and removed the test releases. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpGXc_MG3SXy.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes:
On Feb 3 18:08, Achim Gratz wrote:
Corinna Vinschen writes:
How so? Setup is not a Cygwin application.
Good point. Then I've no idea at all, save the compiler.
I had a look into this and even rearranged the behaviour when --help
output is requested...
However, I'm mildly sure this behaviour didn't change in the last couple
of years. The reason is that setup is not a console application but a
GUI application. When running a GUI application from CMD, CMD will
detach. Of course, when --help output is requested, setup calls
AllocConsole, but that's too late. This does not occur in a Cygwin
shell becasue Cygwin always waits for process completion unless the
process is sent to the background.
I now made the latest setup 2.864 available as standard setup version
on sourceware and removed the test releases.
I'm not sure we're talking about the same thing. I've recently added
code to print an error message along with the parameter usage when a
wrong option or other non-parseable stuff was given instead of simply
exiting with no indication other than the non-zero exit code. The
changes you've just installed look good to me, but they don't touch the
exit path in question:
--8---cut here---start-8---
if (!GetOption::GetInstance ().Process (argc,_argv, NULL))
- exit (1);
+ {
+ GetOption::GetInstance ().ParameterUsage (cerr
+ \nError during option
processing.
+ \nCommand Line
Options:\n);
+ exit (1);
+ }
--8---cut here---end---8---
I guess with those changes one could now use Log (LOG_TIMESTAMP) instead
of cerr in that place and hopefully the output would appear again? I
was pretty certain I tested that in both mintty and CMD, but maybe
not...
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: Setup patch to keep test version if test version installed
On Feb 3 22:04, Corinna Vinschen wrote:
On Feb 3 21:37, Achim Gratz wrote:
Corinna Vinschen writes:
On Feb 3 18:08, Achim Gratz wrote:
Corinna Vinschen writes:
How so? Setup is not a Cygwin application.
Good point. Then I've no idea at all, save the compiler.
I had a look into this and even rearranged the behaviour when --help
output is requested...
However, I'm mildly sure this behaviour didn't change in the last couple
of years. The reason is that setup is not a console application but a
GUI application. When running a GUI application from CMD, CMD will
detach. Of course, when --help output is requested, setup calls
AllocConsole, but that's too late. This does not occur in a Cygwin
shell becasue Cygwin always waits for process completion unless the
process is sent to the background.
I now made the latest setup 2.864 available as standard setup version
on sourceware and removed the test releases.
I'm not sure we're talking about the same thing. I've recently added
code to print an error message along with the parameter usage when a
wrong option or other non-parseable stuff was given instead of simply
exiting with no indication other than the non-zero exit code. The
changes you've just installed look good to me, but they don't touch the
exit path in question:
--8---cut here---start-8---
if (!GetOption::GetInstance ().Process (argc,_argv, NULL))
- exit (1);
+ {
+ GetOption::GetInstance ().ParameterUsage (cerr
+ \nError during option
processing.
+ \nCommand Line
Options:\n);
+ exit (1);
+ }
--8---cut here---end---8---
I guess with those changes one could now use Log (LOG_TIMESTAMP) instead
of cerr in that place and hopefully the output would appear again? I
was pretty certain I tested that in both mintty and CMD, but maybe
not...
I was referring explicitely to the CMD prompt being too early. I didn't
test the situation when specifying a wrong option, sorry. The point in
the file where this occurs is somewhat early. At this point the log
stuff isn't initialized and AttachConsole hasn't been called. I'll
look into that, maybe it can be fixed easily.
Try this:
Index: main.cc
===
RCS file: /cvs/cygwin-apps/setup/main.cc,v
retrieving revision 2.79
diff -u -p -r2.79 main.cc
--- main.cc 3 Feb 2015 19:51:49 - 2.79
+++ main.cc 3 Feb 2015 21:27:31 -
@@ -227,17 +227,16 @@ WinMain (HINSTANCE h,
_argv = __argv;
try {
+bool help_option = false;
+bool invalid_option = false;
char cwd[MAX_PATH];
GetCurrentDirectory (MAX_PATH, cwd);
local_dir = std::string (cwd);
if (!GetOption::GetInstance ().Process (argc,_argv, NULL))
- {
- GetOption::GetInstance ().ParameterUsage (cerr
- \nError during option
processing.
- \nCommand Line
Options:\n);
- exit (1);
- }
+ help_option = invalid_option = true;
+else if (HelpOption)
+ help_option = true;
if (!((string) Arch).size ())
{
@@ -264,7 +263,7 @@ WinMain (HINSTANCE h,
unattended_mode = PackageManagerOption ? chooseronly
: (UnattendedOption ? unattended : attended);
-if (unattended_mode || HelpOption)
+if (unattended_mode || help_option)
set_cout ();
/* Get System info */
@@ -275,7 +274,7 @@ WinMain (HINSTANCE h,
supposed to elevate. */
nt_sec.initialiseWellKnownSIDs ();
/* Check if we have to elevate. */
-bool elevate = !HelpOption version.dwMajorVersion = 6
+bool elevate = !help_option version.dwMajorVersion = 6
!NoAdminOption !nt_sec.isRunAsAdmin ();
/* Start logging only if we don't elevate. Same for setting default
@@ -284,7 +283,7 @@ WinMain (HINSTANCE h,
const char *sep = isdirsep (local_dir[local_dir.size () - 1])
? : \\;
/* Don't create log files for help output only. */
-if (!elevate !HelpOption)
+if (!elevate !help_option)
{
theLog-setFile (LOG_BABBLE, local_dir + sep + setup.log.full,
false);
@@ -293,8 +292,10 @@ WinMain (HINSTANCE h,
setup_version endLog;
}
-if (HelpOption)
+if (help_option)
{
+ if (invalid_option)
+ Log (LOG_PLAIN) \nError during option processing. endLog;
Log (LOG_PLAIN) \nCommand Line Options:\n endLog;
GetOption::GetInstance ().ParameterUsage (Log (LOG_PLAIN));
Log (LOG_PLAIN) endLog;
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Re: Setup patch to keep test version if test version installed
On 2/3/2015 10:27 AM, Corinna Vinschen wrote: On Feb 3 08:04, Ken Brown wrote: On 2/3/2015 6:33 AM, Corinna Vinschen wrote: Hey guys, On Jan 28 21:23, Corinna Vinschen wrote: https://cygwin.com/setup-test-x86.exe https://cygwin.com/setup-test-x86_64.exe These should fix the aforementioned bug I introduced, as well as another subtil problem when checking and unchecking the Bin/Src boxes. If both boxes were deselected, the package got uninstalled without showing up in the Pending view. I worked around that by setting the package state explicitely to Uninstall if both boxes got deselected. This version also introduces an experimental option -m/--mirror-mode. There's something bugging me for a long time as well. We're running our own Cygwin mirror on a local Linux box. The directory is mounted via NFS on my Windows boxes. So, rather than installing from internet, I Install from Local Directory, with the local directory being the NFS-mounted mirror directory. This works fine, except that, after parsing setup.ini, setup hangs unresponsive for about 2 minutes. Only then the chooser window opens. It turned out that the 2 minutes are spent iterating throught the full set of packages and testing each package and each packageversion if the underlying package file exists in the download directory. Given that the directory is a mirror in my case, the test makes only marginal sense. Therefore I added the -m option which avoids most file system access and only checks in a border case (installed version is not in setup.ini). If you're doing as I do, running a local mirror, you may welcome this option. I just don't guarantee that it always works ;} If you find a bug, don't hesitate to report it. Did you test this version? Is it ok to become the release version of setup? It works fine for me. Nice. Are you a potential user of the -m option? No, so I couldn't test that. But it seems that others have tested it by now. Ken
Re: Setup patch to keep test version if test version installed
On Jan 30 20:13, Achim Gratz wrote: Corinna Vinschen writes: Btw., when, do you think, is showtime for _autorebase 2.0? Sometime during the next week would be good, if not then another window I'm on vaca today, but this week sounds good to me. I will release 1.7.34, too, later this week. would be two weeks later. From the responses so far I gathered that Marco doesn#t think he needs to do something for Octave and R, I will take care of Perl myself. That leaves PHP, Ruby and Python... so Yaakov and Jason need to tell us when things are ready on their side I'd think. Well, Jason has dropped maintaiwnrship, so it's Yaakov. Yaakov? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp36yOAoZMqK.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On 1/30/2015 8:13 PM, Achim Gratz wrote: Corinna Vinschen writes: Btw., when, do you think, is showtime for _autorebase 2.0? Sometime during the next week would be good, if not then another window would be two weeks later. From the responses so far I gathered that Marco doesn#t think he needs to do something for Octave and R, I will take care of Perl myself. That leaves PHP, Ruby and Python... so Yaakov and Jason need to tell us when things are ready on their side I'd think. Octave no, but R yes. I will upload the R_autorebase-001001-1.tar.xz together with the new 3.1.2 build as soon ready Regards, Achim. Regards Marco
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: Btw., when, do you think, is showtime for _autorebase 2.0? Sometime during the next week would be good, if not then another window would be two weeks later. From the responses so far I gathered that Marco doesn#t think he needs to do something for Octave and R, I will take care of Perl myself. That leaves PHP, Ruby and Python... so Yaakov and Jason need to tell us when things are ready on their side I'd think. 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: Setup patch to keep test version if test version installed
On 1/30/2015 11:11 PM, Marco Atzeri wrote: On 1/30/2015 8:13 PM, Achim Gratz wrote: Corinna Vinschen writes: Btw., when, do you think, is showtime for _autorebase 2.0? Octave no, but R yes. I will upload the R_autorebase-001001-1.tar.xz together with the new 3.1.2 build as soon ready R_autorebase is up Marco
Re: Setup patch to keep test version if test version installed
On Jan 29 18:27, Achim Gratz wrote: Corinna Vinschen writes: Thank you for this! Well, I added it for entirely selfish reasons, so I'm not sure I deserve getting thanks :) I thanked you for the selfish reason that I got this crossed off my TODO list without any effort on my part, so we're even. ;-) Heh :) Btw., when, do you think, is showtime for _autorebase 2.0? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqFXL2dqHff.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: Thank you for this! Well, I added it for entirely selfish reasons, so I'm not sure I deserve getting thanks :) I thanked you for the selfish reason that I got this crossed off my TODO list without any effort on my part, so we're even. ;-) 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
Re: Setup patch to keep test version if test version installed
On Jan 28 22:55, Achim Gratz wrote: Corinna Vinschen writes: This version also introduces an experimental option -m/--mirror-mode. Thank you for this! Well, I added it for entirely selfish reasons, so I'm not sure I deserve getting thanks :) In the meantime I tried what happens if the mirror is broken. For instance, if a file which is supposed to be installed, is missing. Fortunately this situation is catched by the checksum check performed right before uninstalling the old packages. Setup opens a dialog asking if this package should be skipped. That's reassuring. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpFtskFjINXL.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Jan 27 22:14, Corinna Vinschen wrote: On Jan 27 22:04, Achim Gratz wrote: Corinna Vinschen writes: Or today. Can you try this patch? Most of it is a bit of reformatting, the importnat part is the last set_action call. I think I'll get this wedged in sometime tomorrow. Thanks. I think I have a better one, though. The CleanOrphansOption in cinjunction of not having a curr package should immediately trigger the packagemeta::Uninstall_action: Index: choose.cc === RCS file: /cvs/cygwin-apps/setup/choose.cc,v retrieving revision 2.169 diff -u -p -r2.169 choose.cc --- choose.cc 26 Jan 2015 21:05:45 - 2.169 +++ choose.cc 27 Jan 2015 21:12:01 - @@ -252,19 +252,22 @@ ChooserPage::OnInit () bool deleted = pkg.isManuallyDeleted(); bool basemisc = (pkg.categories.find (Base) != pkg.categories.end () || pkg.categories.find (Misc) != pkg.categories.end ()); - bool current = pkg.curr || CleanOrphansOption; - bool upgrade = wanted || (!pkg.installed basemisc) || UpgradeAlsoOption || !hasManualSelections; + bool upgrade = wanted || (!pkg.installed basemisc) + || UpgradeAlsoOption || !hasManualSelections; bool install = wanted !deleted !pkg.installed; bool reinstall = (wanted || basemisc ) deleted; - bool uninstall = !(wanted || basemisc ) deleted; + bool uninstall = (!(wanted || basemisc ) deleted) +|| (!pkg.curr CleanOrphansOption); if (install) - pkg.set_action( packagemeta::Install_action, pkg.curr ); + pkg.set_action (packagemeta::Install_action, pkg.curr); else if (reinstall) - pkg.set_action( packagemeta::Reinstall_action, pkg.curr ); + pkg.set_action (packagemeta::Reinstall_action, pkg.curr); else if (uninstall) - pkg.set_action( packagemeta::Uninstall_action, packageversion() ); + pkg.set_action (packagemeta::Uninstall_action, packageversion ()); else - pkg.set_action( packagemeta::Default_action, ((upgrade current) ? pkg.trustp (true, TRUST_UNKNOWN) : pkg.installed) ); + pkg.set_action (packagemeta::Default_action, + upgrade ? pkg.trustp (true, TRUST_UNKNOWN) + : pkg.installed); } ClearBusy (); This test release has another puzzeling problem I have to figure out yet. For some reason, it's impossible to downgrade packages at all. Worse, if you try that, it will remove the package. That's a rather weird side effect of my changes, which were only supposed to change the selection method, not the underlying workings. Oh well. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpkSqZBL81eQ.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: This version also introduces an experimental option -m/--mirror-mode. Thank you for this! 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: Setup patch to keep test version if test version installed
Corinna Vinschen writes: On Jan 27 07:55, Achim Gratz wrote: You may have solved a long-standing problem. Let's see if everything else still works... :-) Orpahned package removal doesn't work anymore, but I have no time to take a closer look this week. BTW, if you switch one package to test (or prev), then all packages belonging to the same source package must be switched to the same state. I'm currently doing this with an external tool via setup.ini rewrites, but setup.exe should be taught how to do that for manual intervention. That's a bit over my head in terms of understanding setup's dependency resolution algorithm. Perhaps we should rewrite it in plain C... The idea would be to tie the decision of what version gets installed to the source package rather than each individual one. I haven't looked into how that might be possible, but since each package already knows its source package that shouldn't be impossible. 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: Setup patch to keep test version if test version installed
On 1/27/2015 7:25 PM, Achim Gratz wrote: Corinna Vinschen writes: On Jan 27 07:55, Achim Gratz wrote: You may have solved a long-standing problem. Let's see if everything else still works... :-) Orpahned package removal doesn't work anymore, but I have no time to take a closer look this week. The idea would be to tie the decision of what version gets installed to the source package rather than each individual one. I haven't looked into how that might be possible, but since each package already knows its source package that shouldn't be impossible. Pay attention that not all packages have a source one. On 32bit, these packages has no source _autorebase _update-info-dir base-cygwin base-files chere cygcheck-dep groff-perl libXaw8 libXft1 libXp6 libgc-devel libgc1 libopencdk8 libostyle-devel libostyle1 singular-help singular-icons singular-share singular-surf tesseract-ocr-deu tesseract-ocr-eng tesseract-ocr-fra tesseract-ocr-ita tesseract-ocr-nld tesseract-ocr-por tesseract-ocr-spa tesseract-ocr-vie xemacs-emacs-common xemacs-tags Regards, Achim. Regards Marco
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: Example? I just tried the libppl and libmpc1 packages, and they simply don;'t show up anymore, neither in the current setup 2.859, nor ithe test setup 2.861. I don't see a difference in behaviour. You have to use the -o / --delete-orphans option for this to kick in. It should still work in 2.859 or at least it did for me. This trustp business in setup is a bit annoying and intransparent, but I'll figure out how to fix it again. Maybe it was a mistake to simpy remove the packages, rather then going out of my way and mark the packages obsolete instead? I can make obsolescence packages if anybody thinks it's useful. That's another type of dependency. You're talking about installing all packages that are created from the same source, which is a good idea, certainly. No, I'm only talking about installing all packages from the same source with the same version selector (from prev/curr/exp). The user still gets to chose which of the packages to install, but shouldn't be able to install devel from curr and doc from prev and libwhatever from test. I was talking about entirely different packages the test package depends on. Let's say, Eric releases a new test bash and a new test readline. When somebody chooses to install the test bash, the dependency algorithm should automatically install the test libreadline since bash depends on readline. I've thought about this before, but that would require the format of setup.hint and setup.ini to change and (at least optionally) allow different dependencies per prev/curr/exp section. Resolving your kind of dependency is probably much easier to solve. The other type of dependency, if implemented in all seriousness, would probably require to define version dependecies, kind of like defining minimum version numbers for dependencies in setup.hint. I sort of have that already, just that I use a setup.conf file to integrate different package sources coherently into a new setup.ini file. At the moment I can only override by prev/test or by putting a package in a higher priority package source (that's how I implement patches), but explicit version overrides are on the TODO list. 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: Setup patch to keep test version if test version installed
On Jan 27 07:55, Achim Gratz wrote: Corinna Vinschen writes: I checked in code which fixes this issue, which simplifies the package choosing algorithm when clicking on the package line, and which implements the default package in a way which never downgrades a package without the user's explicit consent by choosing the lower package version manually. This is much more in line with the update mechanism in Linux package managers. You may have solved a long-standing problem. Let's see if everything else still works... :-) BTW, if you switch one package to test (or prev), then all packages belonging to the same source package must be switched to the same state. I'm currently doing this with an external tool via setup.ini rewrites, but setup.exe should be taught how to do that for manual intervention. That's a bit over my head in terms of understanding setup's dependency resolution algorithm. Perhaps we should rewrite it in plain C... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpvG_bftXQqx.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Jan 27 21:37, Corinna Vinschen wrote: On Jan 27 20:59, Achim Gratz wrote: Corinna Vinschen writes: Example? I just tried the libppl and libmpc1 packages, and they simply don;'t show up anymore, neither in the current setup 2.859, nor ithe test setup 2.861. I don't see a difference in behaviour. You have to use the -o / --delete-orphans option for this to kick in. It should still work in 2.859 or at least it did for me. This trustp business in setup is a bit annoying and intransparent, but I'll figure out how to fix it again. I think I see why this happens. I'll have a closer look tomorrow. Or today. Can you try this patch? Most of it is a bit of reformatting, the importnat part is the last set_action call. Index: choose.cc === RCS file: /cvs/cygwin-apps/setup/choose.cc,v retrieving revision 2.169 diff -u -p -r2.169 choose.cc --- choose.cc 26 Jan 2015 21:05:45 - 2.169 +++ choose.cc 27 Jan 2015 20:58:17 - @@ -252,19 +252,23 @@ ChooserPage::OnInit () bool deleted = pkg.isManuallyDeleted(); bool basemisc = (pkg.categories.find (Base) != pkg.categories.end () || pkg.categories.find (Misc) != pkg.categories.end ()); - bool current = pkg.curr || CleanOrphansOption; - bool upgrade = wanted || (!pkg.installed basemisc) || UpgradeAlsoOption || !hasManualSelections; + bool upgrade = wanted || (!pkg.installed basemisc) + || UpgradeAlsoOption || !hasManualSelections; bool install = wanted !deleted !pkg.installed; bool reinstall = (wanted || basemisc ) deleted; bool uninstall = !(wanted || basemisc ) deleted; if (install) - pkg.set_action( packagemeta::Install_action, pkg.curr ); + pkg.set_action (packagemeta::Install_action, pkg.curr); else if (reinstall) - pkg.set_action( packagemeta::Reinstall_action, pkg.curr ); + pkg.set_action (packagemeta::Reinstall_action, pkg.curr); else if (uninstall) - pkg.set_action( packagemeta::Uninstall_action, packageversion() ); + pkg.set_action (packagemeta::Uninstall_action, packageversion ()); else - pkg.set_action( packagemeta::Default_action, ((upgrade current) ? pkg.trustp (true, TRUST_UNKNOWN) : pkg.installed) ); + pkg.set_action (packagemeta::Default_action, + (upgrade pkg.curr) + ? pkg.trustp (true, TRUST_UNKNOWN) + : (!pkg.curr CleanOrphansOption) + ? pkg.curr : pkg.installed); } ClearBusy (); Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgppUeYapqNzc.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Jan 27 20:59, Achim Gratz wrote: Corinna Vinschen writes: Example? I just tried the libppl and libmpc1 packages, and they simply don;'t show up anymore, neither in the current setup 2.859, nor ithe test setup 2.861. I don't see a difference in behaviour. You have to use the -o / --delete-orphans option for this to kick in. It should still work in 2.859 or at least it did for me. This trustp business in setup is a bit annoying and intransparent, but I'll figure out how to fix it again. I think I see why this happens. I'll have a closer look tomorrow. Maybe it was a mistake to simpy remove the packages, rather then going out of my way and mark the packages obsolete instead? I can make obsolescence packages if anybody thinks it's useful. Thanks, but if the -o option works again, probably not. That's another type of dependency. You're talking about installing all packages that are created from the same source, which is a good idea, certainly. No, I'm only talking about installing all packages from the same source with the same version selector (from prev/curr/exp). The user still gets to chose which of the packages to install, but shouldn't be able to install devel from curr and doc from prev and libwhatever from test. Why not? Consider: I want to *run* the new DLL, but I want to *build* packages for the current release. That means, I need cygwin-1.7.34-005 but cygwin-devel-1.7.33-1. I was talking about entirely different packages the test package depends on. Let's say, Eric releases a new test bash and a new test readline. When somebody chooses to install the test bash, the dependency algorithm should automatically install the test libreadline since bash depends on readline. I've thought about this before, but that would require the format of setup.hint and setup.ini to change and (at least optionally) allow different dependencies per prev/curr/exp section. Exactly. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpA69wzQ2Kjn.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: Why not? Consider: I want to *run* the new DLL, but I want to *build* packages for the current release. That means, I need cygwin-1.7.34-005 but cygwin-devel-1.7.33-1. That's exactly why I properly package all snapshots by integrating them with their base packages. I've posted the Makefile before but, it has changed a bit in the last few months, so if you're interested I can post it again. 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: Setup patch to keep test version if test version installed
Corinna Vinschen writes: That's exactly why I properly package all snapshots by integrating them with their base packages. I've posted the Makefile before but, it has changed a bit in the last few months, so if you're interested I can post it again. You lost me here. What snapshots?!? At the moment I'm running on the 2015-01-22 snapshot. I always make patch packages for installation via setup for these (the version on those packages is 1.7.34-005s20150122). Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: Or today. Can you try this patch? Most of it is a bit of reformatting, the importnat part is the last set_action call. I think I'll get this wedged in sometime tomorrow. Regards, 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: Setup patch to keep test version if test version installed
On Jan 27 22:04, Achim Gratz wrote: Corinna Vinschen writes: Or today. Can you try this patch? Most of it is a bit of reformatting, the importnat part is the last set_action call. I think I'll get this wedged in sometime tomorrow. Thanks. I think I have a better one, though. The CleanOrphansOption in cinjunction of not having a curr package should immediately trigger the packagemeta::Uninstall_action: Index: choose.cc === RCS file: /cvs/cygwin-apps/setup/choose.cc,v retrieving revision 2.169 diff -u -p -r2.169 choose.cc --- choose.cc 26 Jan 2015 21:05:45 - 2.169 +++ choose.cc 27 Jan 2015 21:12:01 - @@ -252,19 +252,22 @@ ChooserPage::OnInit () bool deleted = pkg.isManuallyDeleted(); bool basemisc = (pkg.categories.find (Base) != pkg.categories.end () || pkg.categories.find (Misc) != pkg.categories.end ()); - bool current = pkg.curr || CleanOrphansOption; - bool upgrade = wanted || (!pkg.installed basemisc) || UpgradeAlsoOption || !hasManualSelections; + bool upgrade = wanted || (!pkg.installed basemisc) + || UpgradeAlsoOption || !hasManualSelections; bool install = wanted !deleted !pkg.installed; bool reinstall = (wanted || basemisc ) deleted; - bool uninstall = !(wanted || basemisc ) deleted; + bool uninstall = (!(wanted || basemisc ) deleted) + || (!pkg.curr CleanOrphansOption); if (install) - pkg.set_action( packagemeta::Install_action, pkg.curr ); + pkg.set_action (packagemeta::Install_action, pkg.curr); else if (reinstall) - pkg.set_action( packagemeta::Reinstall_action, pkg.curr ); + pkg.set_action (packagemeta::Reinstall_action, pkg.curr); else if (uninstall) - pkg.set_action( packagemeta::Uninstall_action, packageversion() ); + pkg.set_action (packagemeta::Uninstall_action, packageversion ()); else - pkg.set_action( packagemeta::Default_action, ((upgrade current) ? pkg.trustp (true, TRUST_UNKNOWN) : pkg.installed) ); + pkg.set_action (packagemeta::Default_action, + upgrade ? pkg.trustp (true, TRUST_UNKNOWN) + : pkg.installed); } ClearBusy (); Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpHeysEsmPIF.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Jan 27 21:50, Achim Gratz wrote: Corinna Vinschen writes: Why not? Consider: I want to *run* the new DLL, but I want to *build* packages for the current release. That means, I need cygwin-1.7.34-005 but cygwin-devel-1.7.33-1. That's exactly why I properly package all snapshots by integrating them with their base packages. I've posted the Makefile before but, it has changed a bit in the last few months, so if you're interested I can post it again. You lost me here. What snapshots?!? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpRH_fczc9BF.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Jan 27 19:25, Achim Gratz wrote: Corinna Vinschen writes: On Jan 27 07:55, Achim Gratz wrote: You may have solved a long-standing problem. Let's see if everything else still works... :-) Orpahned package removal doesn't work anymore, but I have no time to take a closer look this week. Example? I just tried the libppl and libmpc1 packages, and they simply don;'t show up anymore, neither in the current setup 2.859, nor ithe test setup 2.861. I don't see a difference in behaviour. Maybe it was a mistake to simpy remove the packages, rather then going out of my way and mark the packages obsolete instead? BTW, if you switch one package to test (or prev), then all packages belonging to the same source package must be switched to the same state. I'm currently doing this with an external tool via setup.ini rewrites, but setup.exe should be taught how to do that for manual intervention. That's a bit over my head in terms of understanding setup's dependency resolution algorithm. Perhaps we should rewrite it in plain C... The idea would be to tie the decision of what version gets installed to the source package rather than each individual one. I haven't looked into how that might be possible, but since each package already knows its source package that shouldn't be impossible. That's another type of dependency. You're talking about installing all packages that are created from the same source, which is a good idea, certainly. I was talking about entirely different packages the test package depends on. Let's say, Eric releases a new test bash and a new test readline. When somebody chooses to install the test bash, the dependency algorithm should automatically install the test libreadline since bash depends on readline. Resolving your kind of dependency is probably much easier to solve. The other type of dependency, if implemented in all seriousness, would probably require to define version dependecies, kind of like defining minimum version numbers for dependencies in setup.hint. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpYam7eiFTln.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Jan 26 11:45, Corinna Vinschen wrote: On Jan 26 11:15, Achim Gratz wrote: Corinna Vinschen writes: No, no. Thanks for noticing! I was sure that the comparison operators are comparing using compareVersions() under the hood so I didn't check. How embarrassing. Now I see that they only do a casecompare, as you said. That's arguably a bug in the comparison operator implementation, so maybe we should fix that instead? I'm not so sure in which scenarios the operators are used. In those scenarios the caasecompare might be the right thing to do. Btw., while playing with my patch, I found that setup has a bug. I first thought this is my patches fault, but the current release of setup already shows this behaviour: Consider the cygwin package: Installed: 1.7.34-004 Curr: 1.7.33-1 Test: 1.7.34-005 When I enter the chooser dialog, the New version is set to 1.7.33-1. Now I click on the version number multiple times: 1.7.33-1--click--Keep --click--1.7.34-005 --click--Uninstall --click--Keep Huh? --click--1.7.34-005 --click--Uninstall --click--Keep Where's 1.7.33-1? --click--1.7.34-005 --click--Uninstall --click--Keep Argh. Where does *this* occur? I guess the above needs fixing before I apply any changes to the default selection :((( I checked in code which fixes this issue, which simplifies the package choosing algorithm when clicking on the package line, and which implements the default package in a way which never downgrades a package without the user's explicit consent by choosing the lower package version manually. This is much more in line with the update mechanism in Linux package managers. I uploaded test builds of this setup to cygwin.com: https://cygwin.com/setup-test-x86.exe https://cygwin.com/setup-test-x86_64.exe Please give it a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpkCQMBcX3O6.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: I checked in code which fixes this issue, which simplifies the package choosing algorithm when clicking on the package line, and which implements the default package in a way which never downgrades a package without the user's explicit consent by choosing the lower package version manually. This is much more in line with the update mechanism in Linux package managers. You may have solved a long-standing problem. Let's see if everything else still works... :-) BTW, if you switch one package to test (or prev), then all packages belonging to the same source package must be switched to the same state. I'm currently doing this with an external tool via setup.ini rewrites, but setup.exe should be taught how to do that for manual intervention. 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: Setup patch to keep test version if test version installed
On Jan 25 18:20, Corinna Vinschen wrote: Example: foo-1.22-1 is installed foo-1.23-1 is curr foo-1.24-1 is test == Setup chooses 1.23-1 as default. User installs 1.24-1. Next Setup run: foo-1.24-1 is installed foo-1.23-1 is curr foo-1.24-1 is test == Setup chooses 1.24-1 as default. Maintainer releases a new test version: foo-1.24-1 is installed foo-1.23-1 is curr foo-1.24-2 is test == Setup chooses 1.24-2 as default. Maintainer releases test version as curr version: foo-1.24-2 is installed foo-1.24-2 is curr == Setup chooses 1.24-2 as default. Maintainer releases new test version: foo-1.24-2 is installed foo-1.24-2 is curr foo-1.25-1 is test == Setup chooses 1.24-2 as default. Another case occured to me a few minutes ago. What if the test version gets removed, without updating curr? foo-1.24-1 is installed foo-1.23-1 is curr no test version Now what? Right now, Setup pulls the user back to curr, so 1.23-1 will be preselected. This is more or less equivalent to `yum distro-sync' on Fedora. What would make more(?) sense is sticking to installed instead, because the version number is higher than the curr version. This behaviour would reflect the behaviour of `yum update'. What do you think? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp2x0wQCTKSX.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: No, no. Thanks for noticing! I was sure that the comparison operators are comparing using compareVersions() under the hood so I didn't check. How embarrassing. Now I see that they only do a casecompare, as you said. That's arguably a bug in the comparison operator implementation, so maybe we should fix that instead? 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: Setup patch to keep test version if test version installed
Corinna Vinschen writes: What if the test version gets removed, without updating curr? Then there presumably was a good reason to pull that test version. What would make more(?) sense is sticking to installed instead, because the version number is higher than the curr version. This behaviour would reflect the behaviour of `yum update'. With test releases that get pulled I think it really is correct that the default reverts back to curr. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: Setup patch to keep test version if test version installed
On Jan 26 11:20, Achim Gratz wrote: Corinna Vinschen writes: What if the test version gets removed, without updating curr? Then there presumably was a good reason to pull that test version. What would make more(?) sense is sticking to installed instead, because the version number is higher than the curr version. This behaviour would reflect the behaviour of `yum update'. With test releases that get pulled I think it really is correct that the default reverts back to curr. Really? Here's what I'm doing on Linux: The latest upstream release 1.24 adds a feature I need. The official package version 1.23-44 is obviously still missing this feature, so I build my own rpm with the upstream version 1.24-0 and install that: Official: 1.23-44 Installed: 1.24-0 The official package gets updated to 1.23-47. What I'm expecting now is that the update does NOT update my package, and that's what yum or apper will do. They will leave my higher version alone: Official: 1.23-47 Installed: 1.24-0 Now the official version is pulled up to the next upstream version. The new package is 1.24-3. This time the version number is higher, so yum or apper will update: Official: 1.24-3 Installed: 1.24-3 Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpD7JrBK7XoP.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Mon, 2015-01-26 at 10:58 +0100, Corinna Vinschen wrote: On Jan 25 18:20, Corinna Vinschen wrote: Example: foo-1.22-1 is installed foo-1.23-1 is curr foo-1.24-1 is test == Setup chooses 1.23-1 as default. User installs 1.24-1. Next Setup run: foo-1.24-1 is installed foo-1.23-1 is curr foo-1.24-1 is test == Setup chooses 1.24-1 as default. Maintainer releases a new test version: foo-1.24-1 is installed foo-1.23-1 is curr foo-1.24-2 is test == Setup chooses 1.24-2 as default. Maintainer releases test version as curr version: foo-1.24-2 is installed foo-1.24-2 is curr == Setup chooses 1.24-2 as default. Maintainer releases new test version: foo-1.24-2 is installed foo-1.24-2 is curr foo-1.25-1 is test == Setup chooses 1.24-2 as default. These all make sense to me. Another case occured to me a few minutes ago. What if the test version gets removed, without updating curr? foo-1.24-1 is installed foo-1.23-1 is curr no test version A similar question would arise if 1.24-1 had been curr, then pulled for some reason and not replaced immediately with a 1.24-2. (In such a case on Fedora, the downgrade would be forced through an epoch bump.) Also relevant would be the case where a newer version of a package is installed from a third-party repository (e.g. cmake in Ports), then in a subsequent run, the download cache was removed and said repository is not selected. Now what? Right now, Setup pulls the user back to curr, so 1.23-1 will be preselected. This is more or less equivalent to `yum distro-sync' on Fedora. What would make more(?) sense is sticking to installed instead, because the version number is higher than the curr version. This behaviour would reflect the behaviour of `yum update'. What do you think? Unfortunately the answer depends on the scenario. Would it be feasible to support both modes in setup? Yaakov
Re: Setup patch to keep test version if test version installed
Hi Achim,
On Jan 25 19:42, Achim Gratz wrote:
Corinna Vinschen writes:
Instead of always defaulting to the curr version, Setup now checks if
the installed version of a package is higher than the curr version of
the package. If so, and if a test version exists for this package, it
will choose the test version by default. A welcome side effect of this
is, if the test version becomes the curr version, the installed version
will not be higher than curr, thus the curr version will be chosen
again.
I'd say that's good enough for now.
Index: package_meta.h
===
RCS file: /cvs/cygwin-apps/setup/package_meta.h,v
retrieving revision 2.42
diff -u -p -r2.42 package_meta.h
--- package_meta.h 25 Jul 2013 12:03:49 - 2.42
+++ package_meta.h 25 Jan 2015 17:16:30 -
@@ -94,6 +94,8 @@ public:
{
if (t == TRUST_TEST exp)
return exp;
+else if (curr installed exp)
+ return exp;
else if (curr)
return curr;
else
I'd prefer to re-arrange the tests to something along the lines of
--8---cut here---start-8---
if (exp)
{
if ( (t == TRUST_TEST) ||
(curr installed) )
--8---cut here---end---8---
Nnnno. I was planning to rearrange the code slightly and to add
comments to explain what the code does. Every time I'm looking into
setup I'm desperately missing comments. Roberts C++ class system is a
teeny little bit confusing for my taste :}
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpgMxtkL0dO0.pgp
Description: PGP signature
Re: Setup patch to keep test version if test version installed
Hi David, On Jan 25 23:46, David Stacey wrote: On 25/01/15 17:20, Corinna Vinschen wrote: Instead of always defaulting to the curr version, Setup now checks if the installed version of a package is higher than the curr version of the package. This sounds like a great idea - providing that the logic to compare two version numbers is sufficiently clever. Looking at operator() in package_version.cc, it appears as though this is performing simple string comparison on the version numbers. This would fail in a number of cases. A real example from setup.ini: package: at-spi2-atk curr: 2.10.2-1 prev: 2.8.1-1 A simple string comparison would prefer prev over curr! In your patch, maybe it could be better to call packageversion::compareVersions() rather than use operator(). I'm not terribly familiar with the setup code, so please excuse me if I'm mistaken, got lost in the code, or am completely barking up the wrong tree. No, no. Thanks for noticing! I was sure that the comparison operators are comparing using compareVersions() under the hood so I didn't check. How embarrassing. Now I see that they only do a casecompare, as you said. I'll fix that in my code and check it in. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpYVMrk89drn.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Jan 26 11:15, Achim Gratz wrote: Corinna Vinschen writes: No, no. Thanks for noticing! I was sure that the comparison operators are comparing using compareVersions() under the hood so I didn't check. How embarrassing. Now I see that they only do a casecompare, as you said. That's arguably a bug in the comparison operator implementation, so maybe we should fix that instead? I'm not so sure in which scenarios the operators are used. In those scenarios the caasecompare might be the right thing to do. Btw., while playing with my patch, I found that setup has a bug. I first thought this is my patches fault, but the current release of setup already shows this behaviour: Consider the cygwin package: Installed: 1.7.34-004 Curr: 1.7.33-1 Test: 1.7.34-005 When I enter the chooser dialog, the New version is set to 1.7.33-1. Now I click on the version number multiple times: 1.7.33-1--click--Keep --click--1.7.34-005 --click--Uninstall --click--Keep Huh? --click--1.7.34-005 --click--Uninstall --click--Keep Where's 1.7.33-1? --click--1.7.34-005 --click--Uninstall --click--Keep Argh. Where does *this* occur? I guess the above needs fixing before I apply any changes to the default selection :((( Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpSAvEd4O11S.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes:
Instead of always defaulting to the curr version, Setup now checks if
the installed version of a package is higher than the curr version of
the package. If so, and if a test version exists for this package, it
will choose the test version by default. A welcome side effect of this
is, if the test version becomes the curr version, the installed version
will not be higher than curr, thus the curr version will be chosen
again.
I'd say that's good enough for now.
Index: package_meta.h
===
RCS file: /cvs/cygwin-apps/setup/package_meta.h,v
retrieving revision 2.42
diff -u -p -r2.42 package_meta.h
--- package_meta.h25 Jul 2013 12:03:49 - 2.42
+++ package_meta.h25 Jan 2015 17:16:30 -
@@ -94,6 +94,8 @@ public:
{
if (t == TRUST_TEST exp)
return exp;
+else if (curr installed exp)
+ return exp;
else if (curr)
return curr;
else
I'd prefer to re-arrange the tests to something along the lines of
--8---cut here---start-8---
if (exp)
{
if ( (t == TRUST_TEST) ||
(curr installed) )
--8---cut here---end---8---
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Setup patch to keep test version if test version installed
On 25/01/15 17:20, Corinna Vinschen wrote: Instead of always defaulting to the curr version, Setup now checks if the installed version of a package is higher than the curr version of the package. This sounds like a great idea - providing that the logic to compare two version numbers is sufficiently clever. Looking at operator() in package_version.cc, it appears as though this is performing simple string comparison on the version numbers. This would fail in a number of cases. A real example from setup.ini: package: at-spi2-atk curr: 2.10.2-1 prev: 2.8.1-1 A simple string comparison would prefer prev over curr! In your patch, maybe it could be better to call packageversion::compareVersions() rather than use operator(). I'm not terribly familiar with the setup code, so please excuse me if I'm mistaken, got lost in the code, or am completely barking up the wrong tree. Dave.
