FYI: docbook and customization layer
Hi docbook xml authors, libxslt = v1.1.11 fixed a bug that could bite you. It no longer allows your customization layer to xml:include an xslt file containing a template that you later want to modify (which is indeed the correct behaviour). You have to xml:import it instead. Also note that no other statement must precede any xml:import in your customization layer. Heads up, Patrick -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: libxml2-2.6.13-1
Gerrit P. Haase schrieb: Libxml2 has been updated to version 2.6.16 NEWS There was a bug in the 'xmlcatalog' program in version 2.6.13 of Libxml2, it is strongly recommended to upgrade as soon as possible to libxml2-2.6.16. The Cygwin Libxml2 distribution consists now of four separate packages, the main package 'libxml2' contains the runtime library and the executables 'xmlcatalog' and 'xmllint', the import library and the headers are in the package 'libxml2-devel', the Python bindings and according docs and examples are in the package 'libxml2-python' and the Libxml2 documentation has its own package now: 'libxml2-doc'. Hi Gerrit Marcel, lovely. This works (almost) as expected ;) The group elements don't get lost anymore. Unfortunately, the xml:base parameter in the group element is ignored when updating the catalog, and I end up with my relative path being substituted with an absolute one. But that's Marcel's plate again :) Can the postinstall script test whether an element is already available and replace only the relevant part, ie. make the replace parameter of the xmlcatalog --add command variable? Hm, I can see, that making this work in all cases can easily become nasty. Alternatively, you could add a note to future announcements... Anyway, thanks for your quick response and good work. Patrick -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: docbook-xml42-4.2-3
Gerrit P. Haase schrieb: Patrick Eisenacher wrote: Hi Marcel, Marcel Telka schrieb: Since I expected problems with my /etc/xml/catalog file, I kept an eye on it. And indeed it got corrupted by the update. Here is what happened: - all group definitions were lost - all identation was lost If I run the command from the postinstallscript of $ cygcheck -c docbook-xml42 Cygwin Package Information Package VersionStatus docbook-xml424.2-2 OK with libxml2: $ cygcheck -c libxml2 Cygwin Package Information Package VersionStatus libxml2 2.6.13-1 OK It works ok: ?xml version=1.0? !DOCTYPE catalog PUBLIC -//OASIS//DTD Entity Resolution XML Catalog V1.0//EN http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd; catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog group id= xml:base=file:///usr/share/ rewriteSystem systemIdStartString=http://db2latex.sourceforge.net/xsl/; rewritePrefix=db2latex-xsl-0.8pre1/xsl// rewriteSystem systemIdStartString=http://www.oasis-open.org/docbook/xml/4.2/; rewritePrefix=/usr/share/docbook-xml42// rewriteURI uriStartString=http://docbook.sourceforge.net/release/xsl/current/; rewritePrefix=docbook-xsl// /group group id= xml:base=file:///cygdrive/e/Entwicklung/Hedwig/ uri name=html.titlepage.templates.xsl uri=Object/html.titlepage.templates.xsl/ /group /catalog What version of libxml2 do you have installed? What is the content of the 4.2-3 docbook-xml42 postinstall script? Hi Gerrit, this is getting weird. I get different results than you: $ cygcheck -c docbook-xml42 Cygwin Package Information Package VersionStatus docbook-xml424.2-3 OK $ cygcheck -c libxml2 Cygwin Package Information Package VersionStatus libxml2 2.6.13-1 OK $ cat /etc/postinstall/docbook-xml42.sh.done #!/bin/sh mkdir -p /etc/xml [ -f /etc/xml/catalog ] || xmlcatalog --noout --create /etc/xml/catalog xmlcatalog --noout --add public \ -//OASIS//DTD DocBook XML V4.2//EN \ http://www.oasis-open.org/docbook/xml/4.2/ \ /etc/xml/catalog xmlcatalog --noout --add rewriteSystem \ http://www.oasis-open.org/docbook/xml/4.2/ \ /usr/share/xml/docbook/4.2/ \ /etc/xml/catalog and running that gives me a corrupted xml catalog with group elements missing as reported before: [EMAIL PROTECTED] /etc/xml $ /etc/postinstall/docbook-xml42.sh.done [EMAIL PROTECTED] /etc/xml $ cat catalog ?xml version=1.0? !DOCTYPE catalog PUBLIC -//OASIS//DTD Entity Resolution XML Catalog V1.0//EN http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd; catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog rewriteSystem systemIdStartString=http://db2latex.sourceforge.net/xsl/; rewritePrefix=db2latex-xsl-0.8pre1/xsl// rewriteSystem systemIdStartString=http://www.oasis-open.org/docbook/xml/4.2/; rewritePrefix=/usr/share/xml/docbook/4.2// rewriteURI uriStartString=http://docbook.sourceforge.net/release/xsl/current/; rewritePrefix=docbook-xsl// uri name=html.titlepage.templates.xsl uri=Object/html.titlepage.templates.xsl/ public publicId=-//OASIS//DTD DocBook XML V4.2//EN uri=http://www.oasis-open.org/docbook/xml/4.2// /catalog I played around a little bit with the xmlcatalog --shell option. The debug command is not really helpful. But as soon as I execute the first add command, the group elements get lost. Is there anything else I can provide to track this down? complete cygcheck output or such alike? I wonder why we get different results while we both have the same version of the libxml2 package installed. Marcel, judging from your post, you get the same results as I did? Cheers, Patrick -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: docbook-xml42-4.2-3
Hi Marcel, Marcel Telka schrieb: Since I expected problems with my /etc/xml/catalog file, I kept an eye on it. And indeed it got corrupted by the update. Here is what happened: - the new publicId was inserted ok - the location of the DTD was updated ok - existing entries were not altered What are the existing entries? All other catalog elements except for the group elements. BUT: - all group definitions were lost - all identation was lost Please provide an example of the problematic /etc/xml/catalog file. I attached two catalogs. The first one was my original xml catalog before the update. The latter one is the one after the update. Note: I reconstructed the latter one from memory, so order of elements could vary, but it shows the problems I reported. I use group definitions to set a common xml:base for all group elements. As a result, the paths of every former group element got corrupted. Can you please fix the catalog updating script? Thanks, Patrick ?xml version=1.0? !DOCTYPE catalog PUBLIC -//OASIS//DTD Entity Resolution XML Catalog V1.0//EN http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd; catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog group xml:base=file:///usr/share/ rewriteSystem systemIdStartString=http://db2latex.sourceforge.net/xsl/; rewritePrefix=db2latex-xsl-0.8pre1/xsl// rewriteSystem systemIdStartString=http://www.oasis-open.org/docbook/xml/4.2/; rewritePrefix=docbook-xml42// rewriteURI uriStartString=http://docbook.sourceforge.net/release/xsl/current/; rewritePrefix=docbook-xsl// /group group xml:base=file:///cygdrive/e/Entwicklung/Hedwig/ uri name=html.titlepage.templates.xsl uri=Object/html.titlepage.templates.xsl/ /group /catalog ?xml version=1.0? !DOCTYPE catalog PUBLIC -//OASIS//DTD Entity Resolution XML Catalog V1.0//EN http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd; catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog public publicId=-//OASIS//DTD DocBook XML V4.2//EN uri=http://www.oasis-open.org/docbook/xml/4.2// rewriteSystem systemIdStartString=http://db2latex.sourceforge.net/xsl/; rewritePrefix=db2latex-xsl-0.8pre1/xsl// rewriteSystem systemIdStartString=http://www.oasis-open.org/docbook/xml/4.2/; rewritePrefix=xml/docbook/4.2// rewriteURI uriStartString=http://docbook.sourceforge.net/release/xsl/current/; rewritePrefix=docbook-xsl// uri name=securitects.html.titlepage.templates.xsl uri=Object/securitects.html.titlepage.templates.xsl/ /catalog -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: docbook-xml42-4.2-3
Marcel Telka schrieb: I've updated the docbook-xml42 package to version 4.2-3. docbook-xml42 package contains Docbook XML DTD version 4.2 as published by OASIS. Changes since 4.2-2: - Added Public Identifier association with an URI into /etc/xml/catalog. - Moved DTD files to /usr/share/xml/docbook/4.2 directory. Hi Marcel, thanks for your good work. Since I expected problems with my /etc/xml/catalog file, I kept an eye on it. And indeed it got corrupted by the update. Here is what happened: - the new publicId was inserted ok - the location of the DTD was updated ok - existing entries were not altered BUT: - all group definitions were lost - all identation was lost I use group definitions to set a common xml:base for all group elements. As a result, the paths of every former group element got corrupted. Can you please fix the catalog updating script? Cheers, Patrick -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
perl v5.8.2-1 problems
Hi Gerrit, since I haven't read any statement of yours regarding the problems with perl v5.8.2-1 reported at http://cygwin.com/ml/cygwin/2003-11/msg00733.html and at http://cygwin.com/ml/cygwin/2003-11/msg00434.html I wasn't sure whether they had slipped your notice and in case wanted to bring them to your attention. Do you know whether they are cygwin-specific or of general nature? Patrick -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Apache with mod_perl trouble
Hi Dmitry, I experienced similar problems with exim and perl v5.8.2-1, see http://cygwin.com/ml/cygwin/2003-11/msg00434.html. As soon as exim tries to start the perl interpreter, it crashs. I had to downgrade to perl v5.8.0-3 again. Perl v5.8.2-1 seems to be broken. Patrick Dmitry A. Pashko schrieb: Hi! Has somebody a positive experience of use of a Apache+mod_perl 1.3.28 or 1.3.29 with perl 5.8.2-1? All perfectly worked for me with perl 5.8.0. However after updating perl to version 5.8.2 the server has ceased to start. I rebuild a Apache, but have changed nothing it. In Event Log thus the following message is written: httpd-perl : PID 45680 : starting service `httpd-perl' failed: execv: 128, Transport endpoint is not connected. Under a debugger I have detected, that at initialization perl there is a SEGFAULT near perl_construct() (mod_perl.c, perl_startup function). Any idea to resolve thes fault? Dmitry Pashko [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl CPAN module help
Hi, I just read what Peter said about 'install' and 'force install'. I had to use 'force install' as well for installing the BerkeleyDB module, as 9 out of 20 tests were failing. So far it is running fine, but I haven't done any heavy usage tests yet, just some simple storages and retrievals. I'm using Perl v5.8.0-3, BerkeleyDB v0.25 and db3.1 v3.1.17-2, but saw this behaviour ever since I started with BerkeleyDB v0.21. I'm wondering whether anybody else is seeing this behaviour and managed to do a plain install. I've attached the output I get from 'test BerkeleyDB' below. I also do get warnings when doing a normal install for other modules that they are not allowed to install into /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/, so they install into /usr/lib/perl5/site_perl/5.8.0/. Checking the ACL for above directory yields $ getfacl /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/ # file: /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/ # owner: eisenacher # group: Benutzer user::--- group::--- group:Administratoren:rwx mask:rwx other:r-x default:group:Administratoren:rwx default:mask:rwx default:other:r-x And checking my /etc/passwd shows: $ cat /etc/passwd SYSTEM:*:18:544:,S-1-5-18:: Administratoren:*:544:544:,S-1-5-32-544:: Administrator:unused_by_nt/2000/xp:500:513:U-PC-EISENACHER\Administrator,S-1-5-21-44 8539723-1606980848-1708537768-500:/home/Administrator:/bin/bash Gast:unused_by_nt/2000/xp:501:513:U-PC-EISENACHER\Gast,S-1-5-21-448539723-1606980848 -1708537768-501:/home/Gast:/bin/bash eisenacher:unused_by_nt/2000/xp:1000:513:Patrick Eisenacher,U-PC-EISENACHER\eisenacher,S-1-5-21-448539723-1606980848-1708537768-1000:/home/eisenacher:/bin/bash VUSR_PC-EISENACHER:unused_by_nt/2000/xp:1001:513:VSA Server Account,U-PC-EISENACHER\VUSR_PC-EISENACHER,S-1-5-21-448539723-1606980848-1708537768-1001:/home/VUSR_PC-EISENACHER:/bin/bash and /etc/group: $ cat '/etc/group' SYSTEM:S-1-5-18:18: Kein:S-1-5-21-448539723-1606980848-1708537768-513:513: Administratoren:S-1-5-32-544:544: Benutzer:S-1-5-32-545:545: Gäste:S-1-5-32-546:546: Hauptbenutzer:S-1-5-32-547:547: Replikations-Operator:S-1-5-32-552:552: Sicherungs-Operatoren:S-1-5-32-551:551: Which is weird in 2 ways. First I don't belong to any group, but the owning group is 'Benutzer' and perl sets up the directory in a way that only members of the group 'Administratoren' can write into it. Clearly, there are no members of any of those groups. Anybody any tips? Thanks in advance, Patrick Running make test /usr/bin/perl.exe -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/btreeok 177/244Can't call method txn_begin on an undefined value at t/btree.t line 638. t/btreedubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 28, 178-244 Failed 68/244 tests, 72.13% okay t/db-3.0...ok 1/14Can't call method set_mutexlocks on an undefined value at t/db-3.0.t line 39. t/db-3.0...dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 2-14 Failed 13/14 tests, 7.14% okay t/db-3.1...ok t/db-3.2...skipped all skipped: this needs Berkeley DB 3.2.x or better t/db-3.3...skipped all skipped: this needs Berkeley DB 3.3.x or better t/destroy..ok 1/15Can't call method txn_begin on an undefined value at t/destroy.t line 33. t/destroy..dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 2-15 Failed 14/15 tests, 6.67% okay t/encrypt..skipped all skipped: this needs Berkeley DB 4.1.x or better t/env..ok 18/50Can't call method txn_begin on an undefined value at t/env.t line 104. t/env..dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 12, 14, 21-50 Failed 32/50 tests, 36.00% okay t/examples.ok t/examples3ok t/filter...ok t/hash.ok 146/212Can't call method txn_begin on an undefined value at t/hash.t line 444. t/hash.dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 29, 147-212 Failed 67/212 tests, 68.40% okay t/join.Can't call method txn_begin on an undefined value at t/join.t line 86. t/join.dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 8-41 Failed 34/41 tests, 17.07% okay t/mldbmok t/queueskipped all skipped: Queue needs Berkeley DB 3.3.x or better t/recnook 166/226Can't call method txn_begin on an undefined value at t/recno.t line 471. t/recnodubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 28, 168-226 Failed 60/226 tests, 73.45% okay t/strict...NOK 2Use of uninitialized value in numeric eq (==) at t/strict.t line 40. t/strict...NOK 8Can't call method txn_begin on an undefined value at t/str t/strict...ok 9/44 t/strict...dubious Test returned status 255 (wstat
Re: Perl CPAN module help
man CPAN has this to offer:
# list all modules on my disk that have newer versions on CPAN
for $mod (CPAN::Shell-expand(Module,/./)){
next unless $mod-inst_file;
next if $mod-uptodate;
printf Module %s is installed as %s, could be updated to %s from C
PAN\n, $mod-id, $mod-inst_version, $mod-cpan_version;
}
which gives you a list of all installed modules, including the
distribution ones.
HTH,
Patrick
Brian Dessent schrieb:
zzapper wrote:
Peter,
cpan
cpan
How do you list modules already installed?
There's no definitive way to do this. If you just want to see if you
have the Foo::Bar module, you can use perl -MFoo::Bar -e 1 and if you
get an error then you need to install Foo::Bar.
You can also try the following script which uses the ExtUtils::Installed
module, but I have found that its output is sometimes misleading, in
that it will not display base (stock included) modules. And I'm not
sure if it knows about modules that are installed through means other
than CPAN (e.g. through your distro's package manager.)
#!/usr/bin/perl
use ExtUtils::Installed;
my $instmod = ExtUtils::Installed-new();
foreach my $module ($instmod-modules()) {
my $version = $instmod-version($module) || ???;
print $module -- $version\n;
}
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Perl CPAN module help
or quick and dirty:
perl -e 'use CPAN; CPAN::Shell-r;'
HTH,
Patrick
Brian Dessent schrieb:
zzapper wrote:
Peter,
cpan
cpan
How do you list modules already installed?
There's no definitive way to do this. If you just want to see if you
have the Foo::Bar module, you can use perl -MFoo::Bar -e 1 and if you
get an error then you need to install Foo::Bar.
You can also try the following script which uses the ExtUtils::Installed
module, but I have found that its output is sometimes misleading, in
that it will not display base (stock included) modules. And I'm not
sure if it knows about modules that are installed through means other
than CPAN (e.g. through your distro's package manager.)
#!/usr/bin/perl
use ExtUtils::Installed;
my $instmod = ExtUtils::Installed-new();
foreach my $module ($instmod-modules()) {
my $version = $instmod-version($module) || ???;
print $module -- $version\n;
}
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: cc1plus.exe not included in GCC 3.3.1-3?
I faced the same problem. Upgrading from the old monolithic gcc to the new separate front end packaged ones only gave me gcc-c. I had to separately select gcc-c++. I'm not sure whether this can be classified as a setup dependency bug, since you always face this kind of problem when you split up a monolithic package into separate smaller ones. Which one(s) do you classifiy as the default successor(s)? Patrick Brian Ford schrieb: On Thu, 13 Nov 2003, Brian P Kasper wrote: However, if you already had the old monolithic gcc package when updating to the new separate front end packages, then it is a setup/gcc dependency bug and you should have gotten gcc-g++. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: exim with embedded perl v5.8.2 broken
I don't know why, but the first mails didn't make it through onto the list, but now I subscribed, so this one should make it. I attached the output of strace. Perhaps anybody can see where the problem is. I'm still clueless. And yes, perl.o was indeed recompiled when I rebuilt exim. I even removed the compiler optimization flag, but that didn't help neither. If more info is needed to get this beast going, please let me know. Thanks, Patrick Pierre A. Humblet schrieb: Sorry to hear that, Patrick. There have been reports like that on Win9x, I think it was also a perl version issue. I am not using exim with perl and have refrained from distributing a version precompiled with perl, to avoid having to support perl issues :( Was perl.o recompiled when you rebuilt exim? You may want to run under strace, simplifying the arguments as much as possible, and see where it crashes. strace -o trace.txt exim-4.24-1.exe -d -ps (assuming your exim is still 4.24-1 and not -2 or -3) Pierre At 12:48 AM 11/11/2003 +0100, you wrote: Hi, this morning I upgraded from perl v5.8.0-5 to v5.8.2-1. I'm using exim with embedded perl support, so I rebuilt exim v4.24-1 and now exim doesn't like its embedded perl anymore. Exim works fine until it starts the perl interpreter at which time it crashes, generating an empty exim-4.24-1.exe.stackdump. $ exim -d -bd -q30m -ps Exim version 4.24 uid=1000 gid=513 pid=1612 D=fbb95cfd Probably GDBM (native mode) Support for: iconv() PAM Perl OpenSSL Authenticators: cram_md5 plaintext spa Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore/mbx autoreply pipe smtp changed uid/gid: forcing real = effective uid=1000 gid=513 pid=1612 auxiliary group list: 513 544 545 configuration file is /etc/exim.conf log selector = 0c1d99f8 Starting Perl interpreter If I don't start exim with perl_at_startup, it crashes once it loads perl, 'Starting Perl interpreter' is again the last line of debugging output that I get and the mail is stuck on the mailqueue. Running as a demon doesn't crash the main process, so I guess it's the childs that crash. Unfortunately I can not downgrade to perl v5.8.x via Cygwin Setup, but only to v5.6.x, which I don't want to. I used my own local cache to downgrade to perl v5.8.0-5, but now installing the cpan modules again doesn't work anymore. It's far after midnight now and I'm pretty frustrated. Can anybody cheer me up again? Why are the cpan modules throwing up problems? And what could be the culprit with perl v5.8.2 and exim v4.24? Your help is greatly appreciated. Patrick ** Program name: E:\Programme\Cygwin\bin\exim-4.24-1.exe (1356) App version: 1005.5, api: 0.94 DLL version: 1005.5, api: 0.94 DLL build:2003-09-20 16:31 OS version: Windows NT-5.0 Heap size:402653184 Date/Time:2003-11-12 11:11:46 ** 8752137 [main] exim-4.24-1 1356 environ_init: 0x100204D8: !C:=C:\Dokumente und Einstellungen\eisenacher 2072344 [main] exim-4.24-1 1356 environ_init: 0x10020508: !E:=E:\Programme\Cygwin\bin 1932537 [main] exim-4.24-1 1356 environ_init: 0x10020528: ALLUSERSPROFILE=C:\Dokumente und Einstellungen\All Users 1932730 [main] exim-4.24-1 1356 environ_init: 0x10020568: APPDATA=C:\Dokumente und Einstellungen\eisenacher\Anwendungsdaten 97746 100476 [main] exim-4.24-1 1356 environ_init: 0x100205B0: COMMONPROGRAMFILES=C:\Programme\Gemeinsame Dateien 203 100679 [main] exim-4.24-1 1356 environ_init: 0x100205E8: COMPUTERNAME=PC-EISENACHER 161 100840 [main] exim-4.24-1 1356 environ_init: 0x10020608: COMSPEC=C:\WINNT\system32\cmd.exe 158 100998 [main] exim-4.24-1 1356 environ_init: 0x10020008: FTP_PASSIVE=1 162 101160 [main] exim-4.24-1 1356 getwinenv: can't set native for HOME= since no environ yet 187 101347 [main] exim-4.24-1 1356 mount_info::conv_to_posix_path: conv_to_posix_path (C:\Dokumente und Einstellungen\eisenacher, no-keep-rel, no-add-slash) 132 101479 [main] exim-4.24-1 1356 normalize_win32_path: C:\Dokumente und Einstellungen\eisenacher = normalize_win32_path (C:\Dokumente und Einstellungen\eisenacher) 109 101588 [main] exim-4.24-1 1356 mount_info::conv_to_posix_path: /home/eisenacher = conv_to_posix_path (C:\Dokumente und Einstellungen\eisenacher) 243 101831 [main] exim-4.24-1 1356 win_env::add_cache: posix /home/eisenacher 83 101914 [main] exim-4.24-1 1356 win_env::add_cache: native HOME=C:\Dokumente und Einstellungen\eisenacher 86 102000 [main] exim-4.24-1 1356 posify: env var converted to HOME=/home/eisenacher 157 102157 [main] exim-4.24-1 1356 environ_init: 0x10020660: HOME=/home/eisenacher 51450 153607 [main] exim-4.24-1 1356 environ_init: 0x100207B8: HOMEDRIVE=C: 236 153843 [main] exim-4.24-1 1356 environ_init: 0x100207D0: HOMEPATH=\Dokumente und Einstellungen\eisenacher\Anwendungsdaten\ 165 154008
Re: [ANNOUNCEMENT] Updated: uw-imap and c-client 2002e-2
This fixes the problems reported here: http://cygwin.com/ml/cygwin/2003-10/msg00093.html Thank you, Patrick Backus, Abe schrieb: An updated version of the uw-imap-util, uw-imap-imapd, and c-client = packages has been uploaded to the mirror sites. Changes in 2002e-2 since 2002e-1: Updated the README with correction provided by Jari Aalto. Also, patched c-client with patch information from pine package (PLEASE see the recent IMPORTANT pine release announcement). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
uw-ipop3d 2002e-1 corrupts all mails
Hi, my setup is - Mozilla v1.4 as my mail client - exim v4.24-1 as my MTA - uw-imap-imapd 2002e-1's ipop3d as my pop server Everything worked smoothly together on Cygwin 1.3.22-1 with uw-imap-imapd 2002c-1 or 2002d-1. Now, after upgrading to Cygwin 1.5.5-1 and to uw-imap-imapd 2002e-1, when I retrieve mails, they show all kinds of corruptions: - header lines are missing - header lines are corrupted (cut off, glued together) - header lines appear in the body, ie empty lines are inserted into the header - a line containing a single dot is appended to the body Not every corruption type shows up in every mail, but the same ones show up in a consistent way when sending retrieving the same mail. The mail is still ok in my user's inbox at /var/mail/username, so it's not exim that is corrupting the mail. Oh and yes, the inbox is on a binary mount. Reading through the archives, it seems more people have problems with the latest uw-imapd package. I wonder whether the problem has already been identified by the developers or - if it's Cygwin specific - by the maintainer and whether there are any plans to release a new version in the near future. If you need more information, please let me know. Thanks, Patrick -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: openssl-0.9.7b-1, openssl-devel-0.9.7b-1
Corinna, is there an easy way to find out whether I still have a package installed that needs the openssl 0.9.6x compatibility package? I would love to get rid of this thing. Patrick There will be no 0.9.6j compatibility package anymore. The 0.9.6 package is only kept for backward compatibility of packages built for Cygwin 1.3.x. I strongly recommend to upgrade packages to Cygwin 1.5.x and then automatically to OpenSSL-0.9.7c ASAP. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ssh-keygen and slogin oddity
Corinna, do you have any reference for this? Unless this is something inherent in the ssh protocol or its implementation, which I'm not familiar with, I'm not aware that crypto systems based on discrete logarithms (DSA) are less secure than those based on factoring large integers (RSA). FWIW: - RSA verifies much faster than DSA, whereas DSA signs faster than RSA - RSA can also be used for en-/decryption, whereas DSA can not - RSA was patented in the USA, but the patent ran out in the meantime - strong encryption crypto (eg RSA) was export restricted from the US, but this restriction was deregulated Patrick Corinna Vinschen schrieb: [snip] Another btw., don't use DSA if you can avoid it. Create your own RSA ssh2 key with ssh-keygen -t rsa. It's supposed to be more secure than DSA keys. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup v2.340.2.5: inconsistent error reporting
Let me see... Install from Internet and Direct Connection in both cases. HTH, Patrick Robert Collins schrieb: On Thu, 2003-09-18 at 23:05, Patrick Eisenacher wrote: Trying to update my packages and not having enough space on my harddisk got me confused yesterday. Downloading from a mirror via http resulted in download incomplete. try again?, whereas downloading from another mirror via ftp finally revealed what really was the problem. Did you use the 'direct connection', or 'IE5 settings' method? Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
getopt output reordering (was: xmlto package install question)
Talking to Tim Waugh, the author of xmlto, revealed that the order of arguments doesn't matter on his system (that's Red Hat, I guess), whereas it matters indeed on Cygwin. Investigating it a bit further revealed that Cygwin's getopt differs from what he expected: getopt -- o: xmlto -o foo bar should output this: -o 'foo' -- 'xmlto' 'bar' Cygwin's getopt outputs like this: $ getopt -- o: xmlto -o foo bar -- 'xmlto' '-o' 'foo' 'bar' Checking the archive I found a thread from back in January talking about the inability of Cygwin's getopt to do reordering of arguments. I guess we're facing here the same issue: the option arguments are not output before the non-option arguments. Was any work done wrt this issue? Is anything planned? Tim is going to update the xmlto usage information to reflect the proper order of arguments. Patrick Gerrit P. Haase schrieb: usage: xmlto FORMAT [OPTION]... XML OPTIONs are: -v verbose output (-vv for very verbose) -x stylesheet use the specified stylesheet instead of choosing one -m fragment use the XSL fragment to customize the stylesheet -o directoryput output in the specified directory instead of the current working directory It only works if you swap 'FORMAT [OPTIONS]' to '[OPTIONS] FORMAT' which is what I found in the patch included in the source package. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: getopt output reordering
Hi Max, thanks for your quick response. Indeed, setting the POSIXLY_INCORRECT_GETOPT environment variable did the trick and produces a result that is in synch with the man page. Since I don't know anything about the various flavours of getopts around and what is posixly correct and what not, and I guess a lot of other users don't know neither, how about updating the man pages to be in synch with the current behaviour and adding a paragraph on the POSIXLY_INCORRECT_GETOPT stuff? Cheers, Patrick Max Bowsher schrieb: Patrick Eisenacher wrote: Talking to Tim Waugh, the author of xmlto, revealed that the order of arguments doesn't matter on his system (that's Red Hat, I guess), whereas it matters indeed on Cygwin. Investigating it a bit further revealed that Cygwin's getopt differs from what he expected: getopt -- o: xmlto -o foo bar should output this: -o 'foo' -- 'xmlto' 'bar' Cygwin's getopt outputs like this: $ getopt -- o: xmlto -o foo bar -- 'xmlto' '-o' 'foo' 'bar' Checking the archive I found a thread from back in January talking about the inability of Cygwin's getopt to do reordering of arguments. I guess we're facing here the same issue: the option arguments are not output before the non-option arguments. Was any work done wrt this issue? Is anything planned? IIRC, the end result of the discussion was that no consensus could be reached on whether it was better to reorder or not to reorder, so CGF had to make a ruling, and he ruled not to reorder. Reordering can be enabled by setting POSIXLY_INCORRECT_GETOPT in the environment, but because getopt is statically linked, this only works for programs rebuilt since this change was made, and many haven't been yet. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
xmlto package install question
Hi, my Cygwin xmlto installation (v0.0.14) is missing all the fo formats (dvi, pdf, ps) in /usr/share/xmlto/format/docbook, and the fo subfolder is missing from the /usr/share/xmlto/format/ directory completely. Without those files xmlto is unable to create the corresponding target document formats (provided the corresponding toolchain is installed). Talking to Tim Waugh, the author of xmlto, revealed that all formats are installed unconditionally. So I wonder why they didn't get installed on my system. Is anybody else missing those files or do they get installed on your systems? In particular the files in question are: /usr/share/xmlto/format/docbook/dvi /usr/share/xmlto/format/docbook/pdf /usr/share/xmlto/format/docbook/ps /usr/share/xmlto/format/fo/dvi /usr/share/xmlto/format/fo/pdf /usr/share/xmlto/format/fo/ps Patrick -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
profile folder missing in docbook-xsl package
Hi Marcel, the profile folder is missing in the latest docbook-xsl-1.61.3-1 package, breaking the various profile stylesheets :o( Did you drop the folder intentionally from the distribution or was it a mere oversight? Patrick -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: CygWin adding CRs, hurting CVS client/server communications?
Works like a charm here, both for binmode and textmode mounts. My system: Win2k, WinCVS and Cygwin SSH The problem mentioned in your mailing list reference was fixed long time ago. Do your line endings change as well if you scp a textfile from your client to your server? If yes, then we have indeed an ssh issue on WinXP platforms. Otherwise your problem must lie somewhere else. Patrick Hey folx...currently using OpenSSH under CygWin on an XP box to communicate with a CVS server on a Linux box. Recently upgraded my CygWin installation (1.3.22(0.78/3/2), including OpenSSH to v3.6.1p1 (the latest available under CygWin), and now CVS client/server communications over SSH (CVS_RSH=ssh) don't work. I've tracked the problem deep enough to suspect that SOMETHING in CygWin converts LF to CR+LF line terminators across SSH. This pretty much hoses CVS client/server communications, as the CVS server interprets all incoming lines as byte strings including a CR at the end (it treats LF as the actual terminator)...especially bad for pathname interpretation, but lots of other things may be affected as well. I've tried altering the CVS server code to eat the extra CRs, but too many other things break (including file data exchange I'd bet...can't tell which CRs are valid data and which are inserted by the system) for that to be effective. Found a reference in the mailing list archives to a similar problem someone was having last October, but the solution was to install a snapshot from that time period which seems to be no longer available. I'm wondering if the fix for this issue never found its way into more recent versions of the CygWin system components? I've upgraded CVS on both client and server, but based on my testing, I don't think CVS itself is adding the CRs...please flame if I'm wrong on that one. g Not sure what else to do right now but do without version control for a bit...any better ideas? - Toscani -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] New packages: docbook-xml42, docbook-xsl, xmlto
Hi Marcel, thank you for making these packages available directly via Cygwin setup. I gave xmlto a couple of runs, and it does its job as expected. Unfortunately, I can not use xmlto currently without switching off validation, because it doesn't allow postvalidating my source after evaluating the xincludes first. But I will contact Tim about this. Perhaps he is willing to include another command line switch in one of the next releases. Is there a reason why you sticked with the v1.60.1 XSL stylesheets and didn't use the v1.61.2 ones? Very nice, Patrick docbook-xml42 = docbook-xml42 package contains Docbook XML DTD version 4.2 as published by OASIS. Current version of the package is docbook-xml42-4.2-1. docbook-xsl === docbook-xsl package contains XSL stylesheets for the DocBook XML DTD created by Norman Walsh and others. Current version of the package is docbook-xsl-1.60.1-1. xmlto = xmlto is a front-end to the DocBook XML toolchain written by Tim Waugh. xmlto converts XML files to various formats using XSL stylesheets. Current version of the package is xmlto-0.0.12-1. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: libxslt-1.0.30-2
Elfyn, you rock! :o) The new version runs smooth like butter. Thank you so much for all your effort and energy and time that you put into making this new version happen. You did a tremendous job! Patrick I've made a new version of LibXSLT (1.0.30-2) available for downloading. This is a *maintainance release* only. The only addition is a one-line fix from current CVS, which fixes fixes the SIGSEGV mentioned in this http://www.cygwin.com/ml/cygwin/2003-06/msg00568.html thread. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCE] LibXSLT (1.0.27) test packages available
Hi Elfyn, sorry for the little delay, but Monday was a holiday here in Germany, so I took the chance to get some private work done. Back in the office today, I saw that you have published the updated packages. I reran the basic test I sent you and that worked fine, both with the v1.50.0 and the latest v1.61.2 XSL stylesheets. Unfortunately my next test failed :o( It gets transformed well with the old versions of libxml2 and libxslt and the v1.61.2 XSL stylesheets. But the new versions fail with the v1.61.2 XSL stylesheets. After narrowing down the problem, I identified the affiliation tag within the authorgroup tag as the culprit of causing a segmentation fault. Running the same test on a real unix box, caused xsltproc to segfault as well. So the problem seems not to be with your port, but with xsltproc itself. xsltproc crahses in the xsltApplyTemplates() function. Uff, this turns out to be a real beast...I'm going to contact Daniel about it, hoping to get a new version of xsltproc... Nevertheless, congratulations for the port! Patrick BTW: If you want to crash xsltproc, try this: -bash-2.05b$ xsltproc -catalogs /usr/local/share/xsl/docbook/html/docbook.xsl Specification.xml Specification.html with the following snippet: ?xml version=1.0 standalone='no'? !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.2//EN http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; !-- ROOT ELEMENT -- article class=specification lang=en vendor=Fillmore Labs revision=0.4 articleinfo titleSpecification/title authorgroup author firstnamePatrick/firstname surnameEisenacher/surname affiliation address email[EMAIL PROTECTED]/email /address /affiliation /author /authorgroup /articleinfo section id=introduction titleIntroduction/title para Give some short information about the product. /para /section /article Elfyn McBratney schrieb: On Thu, 5 Jun 2003, Patrick Eisenacher wrote: Hi Elfyn, unfortunately I'm less fortunate with the new libxslt package than Andreas. I cannot translate a simple xml document to html with the new version of xsltproc. Here are some infos: [...] Patrick, I've upgraded the Cygwin LibXSLT package to 1.0.30-1 and xsltproc now works with the DocBook stylesheets. Your simple test and a few others I have tried were all successful. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: openssl commandline tools always output in text mode
On Sat, Jun 07, 2003 at 11:50:21AM +0200, Corinna Vinschen wrote: Since I was a bit bored a few minutes ago I started to run your test on Linux and guess what? The testit.out file had CRLF lineendings, too. Ups, I just gave it a try on FreeBSD and got the same results as well! Weird. Perhaps this is in aticipation of some format adaption for SMTP... So it's very likely related to your input data, nothing behaving different in the Cygwin version of OpenSSL. It seems, no matter what input data the smime tool gets, it always converts it CR LF. As long as this is consistent on all platforms, I'm fine with it. Thanks for your feedback, Patrick -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
openssl commandline tools always output in text mode
Heyho, openssl's commandline tools always output in text mode, no matter what your mount type is, be it binary or text. Is this a bug or a feature? ;o) I wonder whether I can convince openssl to generate its output according to my mount type, which is binary for me. Currently I postprocess openssl's output with a small perl filter to get rid of the superfluous CRs. But this is suboptimal, as I have to remove this filter once I want to run my scripts on a real unix OS. Can anybody help? $ openssl smime -decrypt -in msg.body -recip recipient.crt -inkey recipient.key -out testit.out $ cat -A testit.out Content-Type: text/plain; charset=us-ascii; format=flowed^M$ Content-Transfer-Encoding: 7bit^M$ ^M$ test decryption^M$ ^M$ $ openssl version OpenSSL 0.9.7b 10 Apr 2003 Thanks, Patrick -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: openssl commandline tools always output in text mode
Hello Corinna, attached you find the output of cygcheck. Your example also works for me. So I should rephrase my statement, that all openssl commandline tools output in text mode to openssl's smime commandline tool outputs in text mode. Perhaps others as well... Did you try the example I provided in my last posting? Patrick On Thu, Jun 05, 2003 at 10:40:35PM +0200, Patrick Eisenacher wrote: Heyho, openssl's commandline tools always output in text mode, no matter what your mount type is, be it binary or text. Is this a bug or a feature? ;o) Weird. It works for me: [snip] Since openssl doesn't use any of the env variables TMP, TEMP, TMPDIR (which was a problem in patch(1) once), I don't know what's going on on your system. Please send a cygcheck output according to http://cygwin.com/bugs.html. Perhaps this gives a clue. Corinna Cygwin Win95/NT Configuration Diagnostics Current System Time: Fri Jun 06 13:15:14 2003 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3 Path: D:\Cygwin\usr\local\bin D:\Cygwin\bin D:\Cygwin\bin c:\WINNT\system32 c:\WINNT c:\WINNT\system32\WBEM d:\Tcl\bin c:\PROGRAMME\THINKPAD\UTILITIES d:\ULTRAE~1 d:\network associates\PGPcmdln D:\Cygwin\bin d:\WinCvs d:\Doxygen\bin e:\fillmore-labs\Entwicklung\Prototype\TestSystem\Server d:\Microsoft Visual Studio\Common\Tools\WinNT d:\Microsoft Visual Studio\Common\MSDev98\Bin d:\Microsoft Visual Studio\Common\Tools d:\Microsoft Visual Studio\VC98\bin d:\Ant\bin C:\Dokumente und Einstellungen\eisenacher\bin D:\Cygwin\bin\id.exe output (nontsec) UID: 1000(eisenacher) GID: 544(Administratoren) 513(Kein) 544(Administratoren) 545(Benutzer) D:\Cygwin\bin\id.exe output (ntsec) UID: 1000(eisenacher) GID: 544(Administratoren) 513(Kein) 544(Administratoren) 545(Benutzer) SysDir: C:\WINNT\System32 WinDir: C:\WINNT CYGWIN = `ntsec tty binmode' HOME = `C:\Dokumente und Einstellungen\eisenacher' MAKE_MODE = `unix' PWD = `/home/eisenacher' USER = `eisenacher' ALLUSERSPROFILE = `C:\Dokumente und Einstellungen\All Users' APACHE_HOME = `D:\Apache Group\Apache2' APPDATA = `C:\Dokumente und Einstellungen\eisenacher\Anwendungsdaten' CATALINA_HOME = `D:\Tomcat-4.1.18' CLASSPATH = `E:\fillmore-labs\Entwicklung\Prototype\TestSystem\Server\server.jar;E:\fillmore-labs\Entwicklung\Prototype\TestSystem\Server\xmlrpc.jar' COMMONPROGRAMFILES = `C:\Programme\Gemeinsame Dateien' COMPUTERNAME = `NB-RASTA' COMSPEC = `C:\WINNT\system32\cmd.exe' CVSROOT = `:ext:[EMAIL PROTECTED]:/cvsroot' CVS_RSH = `D:/Cygwin/bin/ssh.exe' HOMEDRIVE = `C:' HOMEPATH = `\Dokumente und Einstellungen\eisenacher\Anwendungsdaten' INCLUDE = `D:\Microsoft Visual Studio\VC98\atl\include;D:\Microsoft Visual Studio\VC98\mfc\include;D:\Microsoft Visual Studio\VC98\include' JAVA_HOME = `D:\Java' LIB = `D:\Microsoft Visual Studio\VC98\mfc\lib;D:\Microsoft Visual Studio\VC98\lib' LOGONSERVER = `\\NB-RASTA' MANPATH = `:/usr/ssl/man' MSDEVDIR = `D:\Microsoft Visual Studio\Common\MSDev98' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/usr/bin' OS2LIBPATH = `C:\WINNT\system32\os2\dll;' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.tcl' PAYMENT_HOST_CGI_BIN = `D:\Apache Group\Apache2\cgi-bin' PERLIO = `perlio' PGDATA = `/usr/local/etc/service_provider' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 11 Stepping 1, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0b01' PROGRAMFILES = `C:\Programme' PROMPT = `$P$G' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' SECUDE_ERROR_TRCFILE = `C:\Dokumente und Einstellungen\eisenacher\Desktop\error.log' SECUDE_ERROR_TRCLEVEL = `2' SGML_CATALOG_FILES = `/usr/local/lib/xml/dtd/docbook42/docbook.cat' SHLVL = `1' SSH_AGENT_PID = `1652' SSH_AUTH_SOCK = `/tmp/ssh-RchU1660/agent.1660' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINNT' TEMP = `e:\TEMP' TERM = `cygwin' TMP = `e:\TEMP' USERDOMAIN = `NB-RASTA' USERNAME = `eisenacher' USERPROFILE = `C:\Dokumente und Einstellungen\eisenacher' WINDIR = `C:\WINNT' _ = `/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00 (default) = `\\.\tape1:' unix = `/dev/st1' fbinary = 0x fsilent = 0x0001 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01 (default) = `\\.\tape0:' unix = `/dev/st0' fbinary
Re: openssl commandline tools always output in text mode
Hi Corinna, On Fri, Jun 06, 2003 at 01:29:29PM +0200, Patrick Eisenacher wrote: Did you try the example I provided in my last posting? No, I don't have keys and that stuff to test with. What I did was, to examine the source code of OpenSSL. The OpenSSL tools do open input files generally in binary mode while writing sometimes in binary mode, sometimes in the don't care mode. If your input file contains CRLFs, the output file might contain them untranslated. Is that possible here? Are your input files infected with CRLFs? Nope. But I attached you a key, cert and testmail with which you should be able to reproduce the problem. The command is: $ openssl smime -decrypt -in testmail.corinna.plain.encrypted -recip corinna.crt -inkey corinna.key -out testit.out $ cat -A testit.out Content-Type: text/plain; charset=us-ascii; format=flowed^M$ Content-Transfer-Encoding: 7bit^M$ ^M$ test plain^M$ ^M$ $ od -c testit.out 000 C o n t e n t - T y p e : t e 020 x t / p l a i n ; c h a r s e 040 t = u s - a s c i i ; f o r m 060 a t = f l o w e d \r \n C o n t e 100 n t - T r a n s f e r - E n c o 120 d i n g : 7 b i t \r \n \r \n t e 140 s t p l a i n \r \n \r \n 154 Please let me know whether you get the same result as I do and whether this helps identifying the culprit. Thanks, Patrick testcase.tar.gz Description: GNU Zip compressed data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCE] LibXSLT (1.0.27) test packages available
Hi Elfyn, unfortunately I'm less fortunate with the new libxslt package than Andreas. I cannot translate a simple xml document to html with the new version of xsltproc. Here are some infos: $ xsltproc -version Using libxml 20507, libxslt 10027 and libexslt 718 xsltproc was compiled against libxml 20507, libxslt 10027 and libexslt 718 libxslt 10027 was compiled against libxml 20507 libexslt 718 was compiled against libxml 20507 $ xsltproc -catalogs /usr/local/lib/xml/stylesheets/docbook-xsl/html/docbook.xsl Tester2.xml Tester2.html runtime error: file /usr/local/lib/xml/stylesheets/docbook-xsl/html/html-rtf.xsl line 101 element apply-templates xsl:apply-templates : can't find doc no result for Tester2.xml here's the Tester2.xml document: ?xml version=1.0 standalone='no'? !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.2//EN http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; !-- ROOT ELEMENT -- article class=specification lang=en vendor=Fillmore Labs revision=0.4 !-- revision of template -- !-- OBJECTIVES -- section id=objectives titleObjectives/title para The following chapters describe the required functionality of release 1. /para /section /article With the old version of xsltproc Tester2.xml translates fine. I'm using the 1.52.1 XSL stylesheets. I tried the 1.61.2 XSL stylesheets as well and got the same result :o( Do you know what's going wrong? Please let me know if you need more infos from my side. Patrick -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCE] LibXSLT (1.0.27) test packages available
Hi Elfyn, here's some more info on the problem I reported in my last posting: Downgrading the libxslt package didn't change anything and I still got the same error trying to transform my xml document with xsltproc. Only after I downgraded the libxml package as well, did my document transform again. Unless xsltproc is statically linked against libxml, the problem seems to be with the libxml library.. Hope that helps localizing the problem. Patrick Hi Elfyn, unfortunately I'm less fortunate with the new libxslt package than Andreas. I cannot translate a simple xml document to html with the new version of xsltproc. Here are some infos: $ xsltproc -version Using libxml 20507, libxslt 10027 and libexslt 718 xsltproc was compiled against libxml 20507, libxslt 10027 and libexslt 718 libxslt 10027 was compiled against libxml 20507 libexslt 718 was compiled against libxml 20507 $ xsltproc -catalogs /usr/local/lib/xml/stylesheets/docbook-xsl/html/docbook.xsl Tester2.xml Tester2.html runtime error: file /usr/local/lib/xml/stylesheets/docbook-xsl/html/html-rtf.xsl line 101 element apply-templates xsl:apply-templates : can't find doc no result for Tester2.xml here's the Tester2.xml document: ?xml version=1.0 standalone='no'? !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.2//EN http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; !-- ROOT ELEMENT -- article class=specification lang=en vendor=Fillmore Labs revision=0.4 !-- revision of template -- !-- OBJECTIVES -- section id=objectives titleObjectives/title para The following chapters describe the required functionality of release 1. /para /section /article With the old version of xsltproc Tester2.xml translates fine. I'm using the 1.52.1 XSL stylesheets. I tried the 1.61.2 XSL stylesheets as well and got the same result :o( Do you know what's going wrong? Please let me know if you need more infos from my side. Patrick -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCE] LibXML2 (2.5.7) test packages available
Hi Elfyn, xmllint works fine for me. I tested it with the following options: $ xmllint -noout -valid -catalogs Specification.xml not specifying -catalogs or specifying -dtdvalid URL fetches the DTD from the given URL, as expected. Without the -valid option, only the well-formedness is checked. And without the -noout option, xmllint outputs the result tree to stdout. Validity and well-formedness errors are reported if present. My document is of medium size (~400k). I haven't tested any of the other options. Now I'm looking forward for an updated xsltproc, cause that was what wasn't compatible with the latest XSL stylesheets. Good work! Thanks, Patrick I have uploaded test packages for LibXML2 version 2.5.7 to sources.redhat.com . The LibXML2 source and binary packages *should* be available on most mirrors by the beginning of next week. The source package does not *yet* contain a patch file; for some reason (me being tired?) `diff' was thinking the entire source package had changed, only the configury has changed, however. Please test the library as much as possible, as I'd like to get this update out there ASAP. If you find any problems/Cygwin related bugs, please let me know on the list ([EMAIL PROTECTED]). Updated packages for LibXSLT are to follow. Elfyn -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1
Hi Jeff, I'm waiting already for more than a month for this to happen. Needless to say, I'm pretty frustrated. But despite Robert claiming to take care of this in his initial response you cited below, no update was ever published. All further inquiries were silently ignored. The interpretation of this behaviour and consequences are up to you. Right now, Cygwin is not usable for XML editing. I recommend switching over to some other *nix and a VM. Alternatively you can use the Windows ports of the xml libaries provided by Igor Zlatkovic. His ports are always up to date: http://www.zlatkovic.com/projects/libxml/index.html Disappointed, Patrick Robert Collins said on 19 Feb 2003 07:57:58 +1100: Yes, and this takes the current version from 'old' to 'old + buggy'. I've upped my priority to get a new release out. Uhmm, end of the week should do it. Please, could we/you somehow get xsltproc associated libs in the cygwin installation repository brought up-to-date? I'm trying to use xsltproc with some docbook stuff (we're using docbook to write the next phase of ProjectLiberty specs, and I use cygwin as my *nix environment), and said docbook stuff uses xinclude. The old xsltproc et al included (still) in the cygwin install (I updated this morning) barfs on the xinclude stuff, plus it doesn't properly handle (eg skip over) included mediaobjects (eg EPS). The latest version of xsltproc et al (the various *xml* libs) handles both of these just fine. thanks, JeffH -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1
Nobody was lashing at anybody. So let's stay with this, Larry. Patrick [EMAIL PROTECTED] schrieb: If you're frustrated, imagine how frustrated Rob is receiving all these complaints for his efforts to make this package available to you (at any version level). Makes one wonder why anyone would spend their time to support a package. Anyway, it's a point to ponder the next time you are frustrated with a particular package and feel like you'd like to lash out at someone. Larry Original Message: - From: Patrick Eisenacher [EMAIL PROTECTED] Date: Mon, 24 Mar 2003 13:15:28 +0100 To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1 Hi Jeff, I'm waiting already for more than a month for this to happen. Needless to say, I'm pretty frustrated. But despite Robert claiming to take care of this in his initial response you cited below, no update was ever published. All further inquiries were silently ignored. The interpretation of this behaviour and consequences are up to you. Right now, Cygwin is not usable for XML editing. I recommend switching over to some other *nix and a VM. Alternatively you can use the Windows ports of the xml libaries provided by Igor Zlatkovic. His ports are always up to date: http://www.zlatkovic.com/projects/libxml/index.html Disappointed, Patrick Robert Collins said on 19 Feb 2003 07:57:58 +1100: Yes, and this takes the current version from 'old' to 'old + buggy'. I've upped my priority to get a new release out. Uhmm, end of the week should do it. Please, could we/you somehow get xsltproc associated libs in the cygwin installation repository brought up-to-date? I'm trying to use xsltproc with some docbook stuff (we're using docbook to write the next phase of ProjectLiberty specs, and I use cygwin as my *nix environment), and said docbook stuff uses xinclude. The old xsltproc et al included (still) in the cygwin install (I updated this morning) barfs on the xinclude stuff, plus it doesn't properly handle (eg skip over) included mediaobjects (eg EPS). The latest version of xsltproc et al (the various *xml* libs) handles both of these just fine. thanks, JeffH -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1
That's great news :o) Elfyn, please let me know when you need support on this task. Peace, Patrick [EMAIL PROTECTED] schrieb: OK, perhaps your message just suffers from poor timing and too much innuendo. Or perhaps I saw more in it than there was. ;-) Anyway, it looks like this is working out in your favor. Despite Rob's announcement that he's dropping maintainership for these packages, Elfyn has offered to pick it up. This is good news for anyone who wants to use these packages with Cygwin. I'd like to thank Rob for his efforts on this package and Elfyn for stepping in to take over. Larry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1
Hi Robert, I guess, you're plate is pretty full right now. But did you make any progress on updating the libxml and libxslt packages? Do you have any new timeframe info as to their planned release? Thanks, Patrick Robert Collins schrieb: On Wed, 2003-02-19 at 06:14, Patrick Eisenacher wrote: Greetings, May I ask the libxml and libxslt package maintainer to upgrade the packages to a newer version that fixes the crash. Are you still the maintainer, Robert? Yes, and this takes the current version from 'old' to 'old + buggy'. I've upped my priority to get a new release out. Uhmm, end of the week should do it. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
xsltproc segfaults after upgrading to docbook xsl stylesheets v1.60.1
Greetings, I just posted the attached mail to the docbook-apps list. Daniel Veillard pointed out that libxml and libxslt are quite old and that this bug has been fixed since then. Indeed, verifying this with the Windows binaries provided by Igor Zlatkovic at http://www.zlatkovic.com/projects/libxml/ proved that the segfault went away and my document gets smoothly transformed again. E:\Temp\libxslt-1.0.26.win32\utilxsltproc -version Using libxml 20503, libxslt 10026 and libexslt 717 xsltproc was compiled against libxml 20503, libxslt 10026 and libexslt 717 libxslt 10026 was compiled against libxml 20503 libexslt 717 was compiled against libxml 20503 May I ask the libxml and libxslt package maintainer to upgrade the packages to a newer version that fixes the crash. Are you still the maintainer, Robert? Thanks for your help, Patrick ---BeginMessage--- Greetings, I just upgraded my XSL stylesheets from 1.50.1 to 1.60.1 and now xsltproc complains about an undefined namespace and segfaults on one of my documents. The culprit seems to be a fileref, on which xsltproc chokes. Is this a stylesheet issue or an xsltproc issue? Can anybody help? Thanks, Patrick $ xsltproc -version Using libxml 20423, libxslt 10013 and libexslt 705 xsltproc was compiled against libxml 20417, libxslt 10013 and libexslt 705 libxslt 10013 was compiled against libxml 20417 libexslt 705 was compiled against libxml 20417 $ xsltproc -catalogs -o Specification.html /usr/local/lib/xml/stylesheets/docbook-xsl/html/docbook.xsl Specification.xml Error Undefined namespace prefix xmlXPathCompiledEval: evaluation failed Segmentation fault (core dumped) here's a doc to reproducce the segfault: ?xml version=1.0 standalone='no'? !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.2//EN http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; !-- ROOT ELEMENT -- article class=specification lang=en vendor=Fillmore Labs revision=0.4 section id=architecture titleArchitecture/title figure id=architecture-system titleSystem Architecture/title mediaobject imageobject imagedata fileref=Specification/ArchitectureSystem.jpg format=JPG align=center / /imageobject textobject phraseSystem Architecture/phrase /textobject /mediaobject /figure /section /article Exception: STATUS_ACCESS_VIOLATION at eip=6103E17D eax=004B ebx=0001 ecx=FFF9 edx=610C4F84 esi=0001 edi=10D83838 ebp=0022F000 esp=0022EFE8 program=D:\Cygwin\bin\xsltproc.exe cs=001B ds=0023 es=0023 fs=0038 gs= ss=0023 Stack trace: Frame Function Args 0022F000 6103E17D (10D83AC0, 103A62A0, 10A2DAB0, ) 0022F030 6103EC46 (0001, 103A6B20, 10A2E160, 10D83838) 0022F060 0041A67D (10D9A008, 0042BAA0, 103A6018, 6107A320) 0022F090 0041A6DB (10D99F88, 10A2DAB0, 0022F100, 004291B2) 0022F100 0042968D (10A2DAB0, 10A2E160, 103A6B20, ) 0022F160 0041AB1A (10A2DAB0, 10D839F0, 103A5EA8, 10D83870) 0022F190 0041B797 (10A2DAB0, 103A5EA8, 103A6B20, 10D83838) 0022F1C0 0041B86E (10A2DAB0, 103A5EA8, 103A6B20, ) 0022F200 0041BE2F (10A2DAB0, 103A6838, , 103CCB70) 0022F260 0042922D (10A2DAB0, 10A2E160, 103A68F0, 10392140) 0022F2A0 00428B44 (10A2DAB0, 10A2E160, , 6103EC46) 0022F330 0042C504 (10A2DAB0, 10A2DEE8, 10486818, 104850B8) 0022F390 004291B2 (10A2DAB0, 10A2DEE8, 104866F8, ) 0022F3F0 0042C823 (10A2DAB0, 10A2DEE8, 10484538, 10484C58) 0022F450 004291B2 (10A2DAB0, 10A2DEE8, 10483BD8, 10490E48) 0022F4A0 0042BC41 (10A2DAB0, 10A2DEE8, 1048BC90, 1048B760) End of stack trace (more stack frames may be present) ---End Message--- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
WinCvs hangs after upgrading CygWin on Win2k
Greetings, I use CygWin SSH for access to my repository with WinCvs. After upgrading CygWin, WinCvs 1.2 commands are aborted by the server. WinCvs 1.3b7 works, but the dos window hangs. The task manager shows, it's ssh that hangs. So I have to close the dos window manually, which is pretty annoying. I saw that problem being mentioned in the FAQ, but only for Win9x machines. I experience that problem on Win2k. Any insight whether there is a workaround, or work ongoing to fix this issue is appreciated. Thanx, Patrick __ Gesendet von Yahoo! Mail - http://mail.yahoo.de Ihre E-Mail noch individueller? - http://domains.yahoo.de -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
