Virus found in a message you sent
A virus was found in a message sent by this account. --- Scan information follows --- Result: Virus Detected Virus Name: [EMAIL PROTECTED] File Attachment: message.zip Attachment Status: infected Result: Virus Detected Virus Name: [EMAIL PROTECTED] File Attachment: message.zip/document.txt .exe Attachment Status: infected --- Original message information follows --- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Tue, 20 Apr 2004 10:31:32 +0200 Subject: Re: Message Error Message-Id: [EMAIL PROTECTED] Received: from relay01s.clb.oleane.net ([213.56.31.142]) by relais2.steria.fr (SAVSMTP 3.1.0.29) with SMTP id M2004042010313526882 for [EMAIL PROTECTED]; Tue, 20 Apr 2004 10:31:35 +0200
Re: Automake 1.8.3 doesn't build?
On Mon, 19 Apr 2004 21:01:58 +0200, Alexandre Duret-Lutz wrote: A suggestion was to always use `SHELL = /bin/sh' in Makefiles. I simply don't know how correct this is, because that's how it was in the past before Chris Provenzano changed it to what it is now. The reason for that change seems to have been lost. Because Chris had a cygnus email address it could be a cygwin singularity? Maybe it's for systems that do not have /bin/sh? Reverting to a state where SHELL is hard-coded as /bin/sh does indeed seem undesirable. As Richard Dawe points out, DJGPP would not benefit from a reversion to /bin/sh; and, in general, the flexibility of an Autoconf substitution just makes more sense. In automake Makefiles, most auxiliary scripts like depcomp, missing, etc. are run as an argument of $(SHELL). A few are run directly (e.g., install-sh), go figure why. Since all of them are executable, start with `#!/bin/sh', and require only basic shell features, I wonder why we bother running them we $(SHELL). It is sometimes the case when transporting code between platforms that a script's execute status gets lost, which causes the script to fail when it is run directly. The $(SHELL) indirection works in all cases, regardless of the script's execute permission. I work on projects, for instance, which are developed heavily by Unix and Windows users. When Windows users create new scripts and commit them to a CVS repository, very often, they do not have the execute bit enabled. By employing the $(SHELL) indirection when running the scripts, we avoid what would otherwise be a fatal problem caused by the missing executable status. I would think that the aforementioned invocation of install-sh should be upgraded to also employ the $(SHELL) indirection. Obviously when $(SHELL) is Zsh most of these scripts will break with unsplit variable symptoms. Unless we equip these scripts (and many Makefile rules) with the _AS_BOURNE_COMPATIBLE code. The patch which I submitted to autoconf-patches yesterday will at least make it much, much less likely for zsh to be chosen. Regarding the aforementioned thread, I'm not really fond of the proposal to introduce a MAKE_SHELL variable and use SHELL = @MAKE_SHELL@ because in order to access the CONFIG_SHELL variable set at configure time we would have to use CONFIG_SHELL = @SHELL@ creating a spaghetti plate of variables definitions. I'm not quite sure why CONFIG_SHELL is even being exported from configure. My understanding of CONFIG_SHELL is that it is an implementation detail of configure itself which should never have escaped to the outside world. CONFIG_SHELL is a flag used internally by configure to tell itself that it does not have to re-perform the preferred-shell search when it re-runs itself after finding a preferred shell. This of course assumes we know how to compute @SHELL@, which I don't. If I had to vote for a definition, I'd say it would be useful that @SHELL@ be the most POSIX compliant shell that does not require any configuration code (such as _AS_BOURNE_COMPATIBLE) to work. This is an interesting idea, and Paolo's generic shell testing and selection code in Autoconf CVS is just about able to handle this additional requirement. (The only hitch is that his code presently invokes _AS_BOURNE_COMPATIBLE when testing each candidate shell, but with a little re-factoring, invocation of that macro could become optional, thus making it possible to detect a shell which does not require it.) This raises the question of what constitutes a POSIX-compliant shell (at least in terms of what Autoconf and Automake expect), and how does one test for those features? The shell's split behavior is one obvious case, but what are the others (if any)? CONFIG_SHELL would allow shell that require such extra code. I'm not sure that I see the point to this. If a POSIX-compliant shell is discovered which is suitable for Automake's needs, then the same shell will be suitable for Autoconf, so why make a distinction? It is true that Autoconf contains compatibility code to deal with less capable shells, and can safely fall back to using even very crippled shells, but I don't see the benefit of making a distinction between a shell suitable for Automake and one suitable for Autoconf. Note that the above definition of SHELL would be useful to configure itself. For instance it currently runs things like ac_config_guess=$SHELL $ac_aux_dir/config.guess ac_config_sub=$SHELL $ac_aux_dir/config.sub ac_configure=$SHELL $ac_aux_dir/configure and I doubt these will enjoy zsh. I am wondering if this discussion about SHELL vs. CONFIG_SHELL vs. MAKE_SHELL is actually obscuring a more basic issue. It is, of course, a reasonable idea to search out and utilize the most capable shell available, but, just because a search for a capable shell is performed, does not mean that such a shell will be found. Therefore,
Re: Automake 1.8.3 doesn't build?
Regarding use of Zsh, is it not possible to add options to the SHELL definition so that even if Zsh is the selected shell, it will properly split arguments. For example, in my Zsh manual page, I see that the -y option enables SH_WORD_SPLIT so presumably SHELL = /bin/zsh -y should emulate the Bourne shell in this respect. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: AMTAR brokenness
Paul == Paul Eggert [EMAIL PROTECTED] writes:
[...]
Paul Many tar implementations have trouble with path names longer than 99
Paul bytes. This includes the current GNU tar official latest non-alpha
Paul release (which is buggy in this area). It would be reasonable to add
Paul an automake option that checks for longer-than-99-byte file names, for
Paul people who are worried about such things. But I don't think it needs
Paul to be high priority.
I've prepared this. However I'm not really proud of the name
`filenames-99'. Maybe someone can suggest some nicer name?
2004-04-20 Alexandre Duret-Lutz [EMAIL PROTECTED]
For PR automake/414:
Introduce option filenames-99.
* doc/automake.texi (Options): Document it.
* configure.ac (AM_INIT_AUTOMAKE): Use it.
* lib/Automake/Options.pm (_process_option_list): Recognize it.
* automake.in (handle_dist): Set FILENAMES_99.
* lib/am/distdir.am (distdir) [FILENAMES_99]: Diagnose long
filenames.
* tests/fn99.test: New file.
* tests/Makefile.am (TESTS): Add fn99.test.
Index: NEWS
===
RCS file: /cvs/automake/automake/NEWS,v
retrieving revision 1.268
diff -u -r1.268 NEWS
--- NEWS19 Apr 2004 23:20:07 - 1.268
+++ NEWS20 Apr 2004 20:30:56 -
@@ -45,8 +45,8 @@
* Diagnose AC_CONFIG_AUX_DIR calls following AM_INIT_AUTOMAKE. (PR/49)
* Tar format can be chosen with the new options tar-v7, tar-ustar, and
- tar-pax.
-
+ tar-pax. The new option filenames-99 helps diagnosing filenames
+ that are too long for tar-v7.
New in 1.8:
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1553
diff -u -r1.1553 automake.in
--- automake.in 17 Apr 2004 18:46:05 - 1.1553
+++ automake.in 20 Apr 2004 20:31:00 -
@@ -3500,7 +3500,8 @@
$output_rules .= file_contents ('distdir',
new Automake::Location,
- %transform);
+ %transform,
+ FILENAMES_99 = !! option 'filenames-99');
}
Index: configure.ac
===
RCS file: /cvs/automake/automake/configure.ac,v
retrieving revision 1.14
diff -u -r1.14 configure.ac
--- configure.ac10 Apr 2004 17:18:01 - 1.14
+++ configure.ac20 Apr 2004 20:31:02 -
@@ -1,6 +1,6 @@
# Process this file with autoconf to produce a configure script.
-# Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
+# Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004
# Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
@@ -36,7 +36,7 @@
# bothered by `missing'.
am_AUTOCONF=${AUTOCONF-autoconf}
-AM_INIT_AUTOMAKE([1.6 dist-bzip2])
+AM_INIT_AUTOMAKE([1.6 dist-bzip2 filenames-99])
# The API version is the base version. We must guarantee
# compatibility for all releases with the same API version.
Index: doc/automake.texi
===
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.32
diff -u -r1.32 automake.texi
--- doc/automake.texi 19 Apr 2004 23:20:07 - 1.32
+++ doc/automake.texi 20 Apr 2004 20:31:07 -
@@ -5812,6 +5812,16 @@
Hook @code{dist-tarZ} to @code{dist}.
@trindex dist-tarZ
[EMAIL PROTECTED] @code{filenames-99}
[EMAIL PROTECTED] Option, filenames-99
[EMAIL PROTECTED] filenames-99
+Abort if filenames longer than 99 characters are found during
[EMAIL PROTECTED] dist}. Such long filenames are generally considered not to
+be portable in tarballs. See the @code{tar-v7} and @code{tar-ustar}
+options below. This option should be used in the top-level
[EMAIL PROTECTED] or as an argument of @code{AM_INIT_AUTOMAKE} in
[EMAIL PROTECTED], it will be ignored otherwise.
+
@item @code{no-define}
@cindex Option, no-define
This options is meaningful only when passed as an argument to
@@ -5919,6 +5929,17 @@
@item @code{tar-v7}
@itemx @code{tar-ustar}
@itemx @code{tar-pax}
[EMAIL PROTECTED] Option, tar-v7
[EMAIL PROTECTED] Option, tar-ustar
[EMAIL PROTECTED] Option, tar-pax
[EMAIL PROTECTED] tar formats
[EMAIL PROTECTED] v7 tar format
[EMAIL PROTECTED] ustar format
[EMAIL PROTECTED] pax format
[EMAIL PROTECTED] tar-v7
[EMAIL PROTECTED] tar-ustar
[EMAIL PROTECTED] tar-pax
+
These three mutually exclusive options select the tar format to use
when generating tarballs with @code{make dist}. (The tar file created
is then compressed according to the set of @code{no-dist-gzip},
@@ -5935,7 +5956,8 @@
given longer filenames some tar implementations will diagnose the
problem while other will generate broken tarballs or use non-portable
extensions. Furthermore, the
Re: Automake 1.8.3 doesn't build?
Eric Sunshine [EMAIL PROTECTED] writes: Autoconf could, for example, publish a macro such as the following: AS_SELECT_SHELL([features], [action-if-found], [action-if-not-found]) I like this basic idea approach (though of course it would take some hacking).
Re: AMTAR brokenness
Alexandre Duret-Lutz [EMAIL PROTECTED] writes: I've prepared this. However I'm not really proud of the name `filenames-99'. Maybe someone can suggest some nicer name? I don't know what the rules are for Automake option spelling, but how about filename-length-max=99? This is because the obvious generalization is to be able to specify whatever length you like.
SUPPLY PRODUCT
ATTENTION: PRESIDENT/CEO. . I am a government official and I am directed to contact you, the Government of Nigeria in confidence want to embark on a supply project of your products. Details of the contract will be communicated to you when you contact me. However, I sincerely hope you will be given the opportunity to impact your experience in this business concern as we believe time and prompt service is the hallmark of any serious business concern. I need a confirmation from you on your capability to handle this contract to enable us proceed. As we look forward to a mutual business relationship. Note, Please include the prices list for the products. I remain doing business with you. yours sincerely, Dr Mrs Mary Balogun note.you can send your mails to this [EMAIL PROTECTED]
Purchase V.icodin Online Easily Today
Buy top painkillers without prescription Today's special: Free overnight Fedex delivery Vicodin.$2.50/dose Hydrocodone$2.17/dose Norco...$2.90/dose Stock is limited and selling fast, so hurry Buy them here
'make distcheck' fails due to Automake
I am once again experiencing problems with Automake leaving behind the distribution files it built so 'make distcheck' fails: ERROR: files left in build directory after distclean: ./GraphicsMagick-1.2.020040419.tar.gz ./GraphicsMagick-1.2.020040419.tar.bz2 ./GraphicsMagick-1.2.020040419.zip gmake[1]: *** [distcleancheck] Error 1 gmake[1]: Leaving directory `/usr/home/bfriesen/build/GraphicsMagick-8-static/GraphicsMagick-1.2.020040418/_build' % automake --version automake (GNU automake) 1.8.3 This is under FreeBSD 5.X. What steps should I take to find the cause of this problem? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: 'make distcheck' fails due to Automake
I should mention that changing to the source directory and executing 'automake --force' seems to clear up this problem when it occurs. It seems that there must be an ordering problem to maintainer-mode activities which results in the tarballs not being removed properly. I have seen the problem three times already while using Automake 1.8.3. I did not see it with 1.8.2 (which was used for quite a while), but I did see it several minor releases back (don't remember which). Bob On Tue, 20 Apr 2004, Bob Friesenhahn wrote: I am once again experiencing problems with Automake leaving behind the distribution files it built so 'make distcheck' fails: ERROR: files left in build directory after distclean: ./GraphicsMagick-1.2.020040419.tar.gz ./GraphicsMagick-1.2.020040419.tar.bz2 ./GraphicsMagick-1.2.020040419.zip gmake[1]: *** [distcleancheck] Error 1 gmake[1]: Leaving directory `/usr/home/bfriesen/build/GraphicsMagick-8-static/GraphicsMagick-1.2.020040418/_build' % automake --version automake (GNU automake) 1.8.3 This is under FreeBSD 5.X. What steps should I take to find the cause of this problem? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
want a university degree without going to university?
Title: GET GET YOUR UNIVERSITY DIPLOMADo you want a prosperous future, increased earning powermore money and the respect of all?Call this number: 1-212-714-8290 (24 hours) There are no required tests, classes, books, or interviews! Get a Bachelors, Masters, MBA, and Doctorate (PhD) diploma! Receive the benefits and admiration that comes with a diploma! No one is turned down! Call Today 1-212-714-8290 Confidentiality assured! shea pessimum parade woodpeck vitriolic aseptic blasphemous honeymoon coccidiosis moot businessman warn descent sparrow empiric sombre hirsch maltese assyria cretaceous shuck sowbelly queasy inhomogeneous splint dichotomize nsf confidante splenetic intensive effluvium popular drank ebony henderson dyke religion acuity inferential invert top lampblack lenient chlorophyll conceive berkelium plunder show delicacy runaway ourselves zoo bulwark dressmake We are located in USA international callers are very welcome shipyard carnegie secrecy oral benefit predatory commando yalta calcium workman fulminate oughtn't crimp switchgear heritable bald belfast choke champ around monocular crabapple comic crutch infield ostrich recurring dervish benton sung veil option pinehurst cromwell davy equipoise airfare diode muezzin sire chablis emotion bidiagonal admissible arrive yet cunard disperse burgher vernier nereid exhortation redact hammerhead severalty pixel sequoia besmirch hatchet perceptible chickadee pursuant babbitt deprave korea del basel grackle mph steamboat cetera weary prow pta okay senior smucker cheyenne drowsy merchant dyeing padre burroughs supreme refrigerate dane gorgeous devote teeth concretion yokohama lackadaisic fraudulent davison coulomb toolmake fortify wispy hexagonal dugout eugenia his emotional pug disruption disneyland aseptic benzene cervantes teaspoon astray beautiful slowdown market pinhole neurosis deny redden telex kaleidescope sunken adipic desecrater bakery catchup boca fbi eggplant detract inverse massive cahoot reversion sandalwood combatant chopin conceptual referendum chime cagey schuster flagler byproduct caucus toll
