Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > My first thought was that Autoconf is a relatively trivial attack v

Re: automated release building service

* Such an automated release building service is a piece of SaaSS. CI is not SaaSS, how is it different? I can hardly imagine how we at GNU tell people "SaaSS is as bad as, or worse than, proprietary software" and at the same time advocate the use of such a service. Unneces

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

Bluntly, I don't think it would help with security. The attacker would just have to disable or adjust the distcheck target to seemingly pass. Yeah, it should be noted that the way the backdoor got into the code was by the _co-maintainer_ -- distcheck or not, would not have mattered, automak

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

> It is not yet clear if the > maintainer intentionally did this, or if the changes were introduced via > a compromise of his computer. I think it is pretty clear by now. [1][2][3] There is a bit more to it all than just this -- the maintainer wasn't responsible (Lasse Collin), the

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

- Have them distributed (automake's default). This means that they will be build in the srcdir, not in the builddir: of course, this only affects the maintainer, since for a user that builds the package from a tarball those files should *not* be rebuilt, hence ther

Re: default -g ??!?

The reason why users are helpless without debugging symbols is if a program crashes, all they can look at are the machine registers at the state of the crash. This is completely useless for figuring out why the program crashed, or getting help from another hacker to figure out why it crashed.

Re: Automake and Texinfo: clean the info or pdf file

>> � �If I call : >> � �$ make >> � �The .info file is built. >> >> � �If I call : >> � �$ make clean >> � �The .info file is not cleaned. >> >> � �It is the same thing for pdf, if I call : >> � �$ make pdf >> � �The .pdf file is built. >> >> � �If I call :

Re: Automake and Texinfo: clean the info or pdf file

>If I call : >$ make >The .info file is built. > >If I call : >$ make clean >The .info file is not cleaned. > >It is the same thing for pdf, if I call : >$ make pdf >The .pdf file is built. > >If I call : >$ ma

Re: Automake and Texinfo: clean the info or pdf file

If I call : $ make The .info file is built. If I call : $ make clean The .info file is not cleaned. It is the same thing for pdf, if I call : $ make pdf The .pdf file is built. If I call : $ make clean The .pdf file is not cleaned. Is there a rule which cl

Re: Building prog first

You say that the manuals are poor and that it is obvious, but I cannot figure out from your explanation how they are poor. I've looked at a few manuals, glibc, emacs, coreutils, autoconf, and m4, and all of them have good indices, are organised cleanly, etc. Can you mention one or two manuals, an

Re: Building prog first

2010/3/22 Alfred M. Szmidt : > If searching is the problem *Web* searching is the answer, not the problem. It isn't when you are not connected to a network. > how does the indices not fix the problem? I rarely find anything useful in the indices other than

Re: Building prog first

If searching is the problem how does the indices not fix the problem? What about using a info browser to search through the manual?

Re: Building prog first

Have you tried reading `(automake) Autotools Introduction'? It is part of the automake manual.

Re: Building prog first

However, "make install" installs unimain into /usr/local/bin Please refer to the manual, it documents how to do that, and more. You can try the chapter `(automake) Fine-grained Distribution Control'.

Re: Sun compiler and /usr/local/include

> CPPFLAGS=-I/usr/local/include ./configure Bzzt. Please pass variable settings as arguments to configure: ./configure CPPFLAGS=-I/usr/local/include not as environment variables. It has the advantage that ./config.status --recheck (which may be triggered from a makefile

Re: Sun compiler and /usr/local/include

If the file is; /usr/local/include/package/header.h and source is; #include what goes in configure.ac? You shouldn't put anything into configure.ac; if you wish to tell your compiler where to find non-standard headers (i.e. anything the compiler doesn't search by default) you should do

Re: silent installs

> I was refering to AM_SILENT_RULES, which supresses `make all' > output; so this is not a very controversial topic, it is already > in automake and used by several projects. Would you like to work > on this feature? The maintainers can't accept a patch that > doesn't exist after a

Re: silent installs

On 01/29/2010 02:05 PM, Steffen Dettmer wrote: > On Fri, Jan 29, 2010 at 9:21 AM, Ralf Corsepius wrote: >> Silent make rules are harmful: >> - Bogus defines [] >> typically do not show up as compiler warnings or errors. > > Could you please explain that? Exam

Re: silent installs

> And there are many examples of the opposite where less verbose > output is useful, automake already supports silent compilation. > I know that Yes, but automake --silent is a different tool, perhaps it should learn suppress the install mgs as well as other libtool msgs such as

Re: silent installs

And there are many examples of the opposite where less verbose output is useful, automake already supports silent compilation. I know that I have missed errors or warnings beause having had to much output to read, Joakim, would you like to work on a patch for this? I think it would be immensly use

Re: ifdef in Makefile.am

I basicall want to do in a Makefile.am ifdef automake version > 1.4 AM_LDFLAGS=... else LDFLAGS=... endif Because am version == 1.4 does not like some newer automake macros and I am moving a big project over to am 1.10. I need the 2 versions to coexist for a while

Re: Add missing bootstrap file

You didn't answer why you need this switch, only that you want it.

Re: Add missing bootstrap file

Index: automake/m4/init.m4 === --- automake.orig/m4/init.m4 +++ automake/m4/init.m4 @@ -107,6 +107,7 @@ dnl is hooked onto _AC_COMPILER_EXEEXT e AC_CONFIG_COMMANDS_PRE(dnl [m4_provide_if([_AM_COMPILER_EXEEXT],

Re: Asking for a tutorial to solve two different cases

I'm developping an application. The question is that once installed I'd like to find it hanged to my Gnome general applications menu. For this, I'm searching the info about how should I configure the autotools files project. I'd like to take the opportunity to ask you also the same

Re: improve INSTALL contents

can you please also read, and follow ? I'm sure you must have missed it because I failed to spam it to three mailing lists. But your repetitions are just as boring as those from everyone else. And get bug-coreutils a

Re: improve INSTALL contents

Indeed - I want to be very clear in INSTALL that there are some basics that pretty much any client of this file provide (make, make install), and some options that nice packages provide but which may fail if someone borrowed this file but does follow everything checked by automake's

Re: improve INSTALL contents

>In addition, if you use an unusual directory layout you can give >options like @option{--bind...@var{dir}} to specify different >values for particular kinds of files. Run @samp{configure --help} >for a list of the directories you can set and what kinds of files >

Re: improve INSTALL contents

>> What about packages that don't support arbitrary prefix override >> (all those using current libtool), or packages or systems that >> don't support DESTDIR installs? This wording creates problems >> for them. > > Indeed - I want to be very clear in INSTALL that there are some

Re: improve INSTALL contents (was: Core-utils 7.2; building only 'su')

How about this? I took into account Ralf's comments as well. In addition, if you use an unusual directory layout you can give options like @option{--bind...@var{dir}} to specify different values for particular kinds of files. Run @samp{configure --help} for a list of the directories

Re: improve INSTALL contents

>+Depending on the package, the default directory layout chosen during >+...@command{configure} can be altered during subsequent execution of >+...@command{make}. > > A `make install FOO=VAL' should never alter anything in the build > directory. The problem is if y

Re: improve INSTALL contents (was: Core-utils 7.2; building only 'su')

+Depending on the package, the default directory layout chosen during +...@command{configure} can be altered during subsequent execution of +...@command{make}. A `make install FOO=VAL' should never alter anything in the build directory. The problem is if you pass --bindir=/foo to confi

Re: Core-utils 7.2; building only 'su'

> So for maximum portability you should support this in your > package, too. BTW, why do you state that overriding just $prefix > would be "almost always wrong"? In the w32 arena, overriding $prefix at `make install' time is unilaterally *correct*. Why can your staging area not mi

Re: Core-utils 7.2; building only 'su'

>>Hmmm. Would it be worth changing autoconf to make './configure >>--help' state something like the following: >> >>| Some influential environment variables: >>| ... >>| DESTDIRleave unset during configure; allows installation

Re: Core-utils 7.2; building only 'su'

> I tend to agree that INSTALL should either mention DESTDIR (and > probably also V, which now plays a role with new enough > automake), or at least point to the GNU Coding Standards and the > Automake manual overview of the GNU build system. Does anyone > want to beat me to a patch

Re: Core-utils 7.2; building only 'su'

>packages where DESTDIR doesn't work properly. But automake >already does such a good job at providing DESTDIR support >(especially if the user remembered to run 'make distcheck'), >that I think it would be nice if using AM_INIT_AUTOMAKE did >make the ./configure

Re: Core-utils 7.2; building only 'su'

>Hmmm. Would it be worth changing autoconf to make './configure >--help' state something like the following: > >| Some influential environment variables: >| ... >| DESTDIRleave unset during configure; allows installation to >| spec