Re: best practice for upgrading config files?
Igor Peshansky wrote: ... If the user has modified the default configuration, she most likely knows what she is doing, and probably wouldn't want the installation to muck with her changes (not even if we could create diffs This is certainly true. (On the other hand, having experienced this nuisance of certain packages a number of times, it is good advice anyway not to rely on changing system configurations whenever possible, but rather add overriding local configurations.) But - again on the other hand - if a new release brings in additional parameters, I would of course want them to show up in the configuration so they become effective (and configurable :). with the previous version and cleanly apply the patch). What would be nice in this case, though, is some feedback like Not replacing config file /etc/lftp.conf due to user changes to the postinstall script's stdout, which will end up in the setup.log file. Considering what I said above, I think an automatic merge would be the best, not changing modified parameters, and adding any new parameters. Apart from some moderate handling effort, the only remaining problem would be whether to change default values of previously unchanged parameters - which might have been deliberately unchanged by the user! (3) Compute a checksum of the current /etc/lftp.conf, and compare it to the checksum of the old default. If they're the same, then the user hasn't touched the old default so copy the new default in. If they're different, then prompt the user as in (2). So we need to store checksums of default config files somewhere. This is Debian's method. ... 2) In the preremove, compare each config file from the manifest with the current default version of that file, and remove the config file if they are identical (using cmp). ... Approaches which either can only replace or not, depending on comparison of the complete file, or delegate all merging problems to the user, are unsuitable for my taste. Kind regards, Thomas Wolff
Re: ITP: rxvt-unicode-X
Sorry for the very late response, but I've finally succeessfully pursuaded rxvt-unicode now to actually support Unicode on cygwin, and I'd like to suggest to include that in the package. Charles Wilson wrote on Tue, 21 Mar 2006 16:54:11 -0500: ... So what is the actual newlib problem that prevents rxvt from supporting Unicode - apparently even from trying to support it? I don't know. All I know is that (a) I didn't see it actually work, and (b) I've read other reports that unicode doesn't actually work on cygwin. Maybe I'm wrong. I'm pretty clueless on unicode issues: do I need a specific unicode font to even try it? How many LC_* variables *should* I have to set in order to enable unicode -- say, if I were on a Linux system will full unicode support? I dunno. I was hoping others with more experience could use my package -- or my build system -- and experiment, reporting successess and failures. I know, that's fairly pollyanna-ish of me, but... I was eventually planning on building rxvt-unicode with identical options over on my Linux box, and play around with it there, but that's a roudtuit item. Some general remarks: Depending on the application, Unicode may be triggered either 1) explicitly or 2) using the locale mechanism (which is bogus on cygwin). It should be noted that the set of locale variables (LC_* and LANG) are not identical to the locale mechanism which needs addtional library support. 1) For example, xterm has an explicit command line option: xterm -u8 which invokes xterm in UTF-8 mode. Additional configuration is needed to use Unicode fonts. And LC_* variables are unfortunately not set implicitly in this invocation mode which confuses many applications. My package mined includes a script uterm which invokes xterm in a suitable mode, including font setup. Cygwin/X does include some Unicode fonts, but apparently a very outdated version of them with a very limited character range. I would offer to maintain a package of Unicode X fonts if that helps. 2) Rxvt insists on locale configuration to provide desired encodings. This means, you would have to invoke rxvt like this: LC_CTYPE=en_US.UTF-8 rxvt or LC_ALL=vi_VN rxvt (Note: vi_VN is one of the UTF-8 locales that lack the usual indication suffix.) And rxvt would run in UTF-8 mode where the locale mechanism works (which it doesn't on cygwin). The reason why I couldn't trick out rxvt before by just setting the variables was that it also depends on the wide character library functions which in turn depend on a working locale mechanism. I have now replaced those functions (well, the subset of them needed by rxvt) with substitutes that either operate in UTF-8 mode, or delegate to the system functions, depending on the setting of the locale variables, and it works. At least it does so for display, although it suppresses 8-bit input for some obscure reason still to be found. I will send the files to you (Charles Wilson) directly and would appreciate if you confirm the solution. Kind regards, Thomas Wolff
Re: best practice for upgrading config files?
On Wed, 10 May 2006, Thomas Wolff wrote: Igor Peshansky wrote: ... If the user has modified the default configuration, she most likely knows what she is doing, and probably wouldn't want the installation to muck with her changes (not even if we could create diffs This is certainly true. (On the other hand, having experienced this nuisance of certain packages a number of times, it is good advice anyway not to rely on changing system configurations whenever possible, but rather add overriding local configurations.) As long as you only change existing option values, the patches should apply (possibly with some amount of fuzz). But if you add new configuration option settings, there is a possibility of changing the state of the config file to something invalid. If you're really that concerned with the users keeping their changes *and* getting new updates, split the configuration files into user-modifiable (i.e., those that will only have the user-overridden settings) and standard (which should not be modified by the users), and include the user-modifiable version into the standard one (if your application supports it). But - again on the other hand - if a new release brings in additional parameters, I would of course want them to show up in the configuration so they become effective (and configurable :). with the previous version and cleanly apply the patch). What would be nice in this case, though, is some feedback like Not replacing config file /etc/lftp.conf due to user changes to the postinstall script's stdout, which will end up in the setup.log file. Considering what I said above, I think an automatic merge would be the best, not changing modified parameters, and adding any new parameters. Apart from some moderate handling effort, the only remaining problem would be whether to change default values of previously unchanged parameters - which might have been deliberately unchanged by the user! Dealing with configuration files is usually quite a large can of worms. The users are expected to read release announcements (though I admit, Cygwin setup doesn't make it very easy to find them[*]). (3) Compute a checksum of the current /etc/lftp.conf, and compare it to the checksum of the old default. If they're the same, then the user hasn't touched the old default so copy the new default in. If they're different, then prompt the user as in (2). So we need to store checksums of default config files somewhere. This is Debian's method. ... 2) In the preremove, compare each config file from the manifest with the current default version of that file, and remove the config file if they are identical (using cmp). ... Approaches which either can only replace or not, depending on comparison of the complete file, or delegate all merging problems to the user, are unsuitable for my taste. Unless the part that you're comparing *can* be replaced as a whole (i.e., all user changes are confined to another file that is included into the main config). [*] Would there be interest in propagating URLs of announcement messages in setup.ini, so that Cygwin setup can let the users view the announcements from the chooser screen? An alternative would be keeping this information separately on the sourceware server, writing a CGI script that would retrieve the announcement(s) based on the range of versions, and have setup reference the URL of that CGI script instead. The database of announcements could be updated when announcement messages are forwarded to cygwin-announce, but I don't know enough about that mechanism to offer any concrete suggestions at the moment. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac
Please Upload: naim-0.11.8.2-1
http://jca.sdf1.org/cygwin/naim-0.11.8.2-1-src.tar.bz2 http://jca.sdf1.org/cygwin/naim-0.11.8.2-1.tar.bz2 http://jca.sdf1.org/cygwin/setup.hint jca
Re: rxvt-unicode-common setup.hint error
Christopher Faylor wrote: I just got an error: upset: *** warning package rxvt-unicode-common refers to non-existent external-source: unicode-rxvt-X So, I changed unicode-rxvt-X - rxvt-unicode-X in the rxvt-unicode-common setup.hint. Thanks. I'll make sure it's fixed in the package in the next release. -- Chuck
Re: ITP: rxvt-unicode-X
Thomas Wolff wrote: Sorry for the very late response, but I've finally succeessfully pursuaded rxvt-unicode now to actually support Unicode on cygwin, and I'd like to suggest to include that in the package. That's great, thank you very much. I received your other emails and will take a look as soon as possible. However, I'll let the brand new (not even announced yet) rxvt-unicode-X package stay as-is for a while to give folks a chance to try it out before incorporating any new features/changes. Some general remarks: Depending on the application, Unicode may be triggered either 1) explicitly or 2) using the locale mechanism (which is bogus on cygwin). It should be noted that the set of locale variables (LC_* and LANG) are not identical to the locale mechanism which needs addtional library support. 1) For example, xterm has an explicit command line option: xterm -u8 which invokes xterm in UTF-8 mode. Additional configuration is needed to use Unicode fonts. And LC_* variables are unfortunately not set implicitly in this invocation mode which confuses many applications. My package mined includes a script uterm which invokes xterm in a suitable mode, including font setup. Cygwin/X does include some Unicode fonts, but apparently a very outdated version of them with a very limited character range. I would offer to maintain a package of Unicode X fonts if that helps. 2) Rxvt insists on locale configuration to provide desired encodings. This means, you would have to invoke rxvt like this: LC_CTYPE=en_US.UTF-8 rxvt or LC_ALL=vi_VN rxvt (Note: vi_VN is one of the UTF-8 locales that lack the usual indication suffix.) And rxvt would run in UTF-8 mode where the locale mechanism works (which it doesn't on cygwin). So, you're saying that rxvt-unicode doesn't have an explicit switch, but relies on pre-existing env vars. This is good, because the apps one runs IN the terminal will need those env vars too, something a command line switch won't set for you properly anyway. BUT... The reason why I couldn't trick out rxvt before by just setting the variables was that it also depends on the wide character library functions which in turn depend on a working locale mechanism. if the wide char library functions don't exist, then rxvt ignores the LC vars anyway. Gotcha. I have now replaced those functions (well, the subset of them needed by rxvt) with substitutes that either operate in UTF-8 mode, or delegate to the system functions, depending on the setting of the locale variables, and it works. Shims -- that's a reasonable approach. (I'd prefer if unicode/locale support were added to cygwin's version of newlib but that might be Augean Stables-level of effort.) OTOH, I *really* prefer things-that-work, sooner rather than later -- so this is good. At least it does so for display, although it suppresses 8-bit input for some obscure reason still to be found. I'm just guessing, but this could be related to the configure settings in my build script, if that's what you were using: --enable-shared --enable-utmp --enable-wtmp --enable-lastlog \ --enable-xft --enable-font-styles --disable-xim --enable-combining \ --enable-fallback=Rxvt --with-res-name=urxvt --with-res-class=URxvt \ --program-suffix=-X \ --enable-xpm-background --enable-menubar --enable-rxvt-scroll \ --enable-next-scroll --enable-xterm-scroll --enable-plain-scroll \ --enable-transparency --enable-tinting --enable-fading \ --enable-frills --enable-smart-resize --enable-pointer-blank \ --enable-mousewheel --enable-slipwheeling --enable-keepscrolling \ --enable-old-selection --disable-perl \ --with-xpm-includes=/usr/X11R6/include --with-xpm-library=/usr/X11R6/lib \ --x-libraries=/usr/X11R6/lib Note: --disable-xim as well as not specifying --enable-8bitctrls Now, the latter is not recommended and its only effect is the following block of code in the input-processing loop: #ifdef EIGHT_BIT_CONTROLS // 8-bit controls case 0x90:/* DCS */ process_dcs_seq (); break; case 0x9b:/* CSI */ process_csi_seq (); break; case 0x9d:/* CSI */ process_osc_seq (); break; #endif So, I don't think that's it. = While 8bit input != xim, there are two things I've discovered about the rxvt-unicode sourcecode: (1) very little testing is done in non-default configurations (and --enable-xim is the default) (2) some #define macros turn on/turn off more than their simple names and descriptions might suggest -- and the code often makes unwarranted assumptions (e.g. see earlier thread about an unwarranted linkage between transparency and XPM support) So, it's possible that --disable-xim turns off some non-XIM input support needed for 8bit entry. Try: --enable-xim. = Also, try the iso14755 support (CTRL-SHFT-key).
