rth, all things the
harness isn't going to know how to do. So I guess I would recommend
against writing tests that way, but there is probably some motivation that
I'm missing.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
not
represent some known-to-not-work bug or missing feature that will
eventually be fixed, but rather is just a more convenient way to write the
test.
I haven't encountered that scenario before, and indeed I don't believe TAP
includes any semantics for that.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
re how
much interoperability between different TAP harnesses matters -- but
strictly speaking there is a way to achieve what I think you want within
the TAP protocol without extensions.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
build-to-host.m4 had been checked into the repository, but this
is indeed not the case.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
of the necessary tools available.
It's not a panacea (there are no panaceas), but it's less aggressive and
disruptive than some other ideas that have been proposed, and I think it's
mostly best practice already.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
attacker in compromising those folks, since there isn't
the same mangification of scale as compromising the distro packages.)
> Well, it'd at least make things more difficult for the attacker, even if
> it wouldn't stop them completely.
This is the whole field of security. Not
n't answer the
question of why that's in the test suite log, though.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
ows the #include and builds
your generated code.
Does that get at the problem that you're having?
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
out the interaction
between user variables, ‘AM_’ shadow variables, and per-target
variables.
and
https://www.gnu.org/software/automake/manual/automake.html#Flag-Variables-Ordering
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
;m fairly sure that, back when I was actively maintaining
and installing software on Solaris, I never bothered with separate
directories for the lettered subsections, and it never caused problems.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
opment tool, and is just going to cause frustration for someone who
has downloaded the package and wants to use it, not develop on it.
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
he
situation with Perl, Python, Node, or Ruby: languages that have their own
supported build systems deeply integrated into their ecosystem, where the
best solution for Automake projects is generally to find a way to hook
into that build system and delegate the build steps to the native build
support nor ignore those
sequences, I'd very much like to know so that I can update my
compatibility chart.
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
ore adding
colors. Those address the much more common case of redirecting test
output to a file, where the ANSI codes cause a lot of problems.)
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Autoconf create the
directory by adding:
AC_CONFIG_COMMANDS([server], [test -d server || mkdir server])
(in my case, the name of the directory containing the scripts was server).
It's kind of a hack, but it works.
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
nerated files in version control since they're often not mergable and
cause all sorts of irritating issues on branching, commits from systems
with slightly different tool versions, etc.
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
be in
for a lot more work over time, since the build system changes a lot.
> http://www.eyrie.org/~eagle/journal/2013-01/025.html suggested not to
> use ExtUtils::MakeMaker at all.
Yeah, I still need to find time to do that writeup I promised I'd do. :)
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
e.org/~eagle/software/remctl/
Version: @PACKAGE_VERSION@
Cflags: -I${includedir}
Libs: -L${libdir} -lremctl
Libs.private: @GSSAPI_LDFLAGS@ @GSSAPI_LIBS@
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
"Arthur Schwarz" writes:
> automake (GNU automake) 1.14.1
> Chapter 15.4.1, page 112 "Test::Harness::TAP" link is no longer active. I
> found "http://testanything.org/"; which may be a suitable replacement.
TAP::Parser::Grammar is the direct repl
unately doesn't run when you want. You could try:
dist:: man
although I'm not positive that's portable to every make.
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
cd php && touch config.m4 && $(PHPIZE) --clean && cd .. ; \
fi ; \
rm -f php/config.h.in~ php/config.m4 ;\
fi
set -e; if [ -f "ruby/Makefile" ] ; then\
cd ruby && $(MAKE) distclean ; \
fi
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
much more complex than your problem, since it also has to integrate with
the native build systems of Perl, Python, PHP, and Ruby.
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
been in the convenience library being built multiple times with
meaningless compiler flag variations. That can reintroduce quite a lot of
build slowness, as well as duplication of warning messages, etc.
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
butions. Many major Linux packages now use it extensively in their
configure probes. I'm not sure what the uptake outside of the Linux world
looks like. But systemd itself is only available on Linux, so you're
pretty much guaranteed that any system that has systemd also has
pkg-config or
e is in "Installing Systemd Service
Files" in daemon(7).
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
don't think I can use -I parameters to fix this because it would
> require modifying the generated scripts.
I would try first to run the script explicitly with perl -I parameters,
and if the mechanisms are such that this doesn't work, I'd use PERL5LIB.
In other words, I think you'v
es (and detect errors). If one is using a command-line compiler that
can't generate similar sorts of dependency information, it's usually best
to just rebuild all the *.java files that make up a JAR if any of them
have changed, to ensure that no errors have been introduced and no
internal APIs have changed.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
cases where I've seen user rules in play don't involve anything for
which automatic deps are particularly meaningful or important. Usually
normal make dependencies are sufficient and unexciting.
I can't comment on cross-compilation having never done it myself.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
n package maintainer and may have more context.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
nd knowledge of how it works
is built into a large number of supporting tools (dh and dh-autoreconf on
the Debian side, for example). There's an advantage to sticking with a
suboptimal process if it's the process that everyone else is using. It
all depends on how significant the gains are.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
(as with Debian/Ubuntu
multiarch) or it will be the 64-bit multiarch system library path.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
lag. Hiding the dollar
sign from Automake so that it can't detect the portability issue is an odd
way of expressing things and just adds complexity to no real purpose.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
ed that last level of branching. I suspect you'll
find that you will use it once or twice but not as a systematic practice.
Usually, it's easier to just make releases from the stable branch and
version them (either minor or micro) according to the nature of the
changes that have accumulated.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Sure, that also works. It just seems kind of silly to have to deceive
make rather than just removing the make rules that one doesn't want.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Ineiev writes:
> On 02/08/2013 08:30 PM, Russ Allbery wrote:
>> Another place where the default behavior frequently breaks is if one is
>> applying a patch to both the generated file and the source file,
>> usually because one explicitly *doesn't* want to re-run
enerated file before the source file, make then tries to re-run
Automake and everything explodes.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
aving fun with it, and I think that's important!
To be honest, the main reason why I've not already started playing with it
is that it's not packaged for Debian, which is enough of a hurdle that I
haven't found the time to fiddle with it.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
oing
to want it to continue to be easy to run tests serially on an ongoing,
permanent basis, and may even want to consider some way to mark specific
tests as non-parallelizable (so that as many tests as possible can be run
in parallel anyway).
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
ing
something to this section talking about how Linux distributors need to
have silent rules be disabled by default as well, in case people are
reading the bit about "casual user" and going "well, my package doesn't
have any casual users, so I don't care.")
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
rest of the
code.
So there are some reasons to do this. However, I agree that when you have
dozens of them, there may be something amiss.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
t rm was added because it
was discovered that some of Autoconf's probes for working compilers and
compiler properties would cause some buggy vendor compilers to core dump.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
ture to have, and the TAP protocol supports it and it sounds like the
Automake support for it will be there.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
lot easier to do your test setup in shell or some other scripting language
rather than C, while the core test code has to be written in C because of
what it's testing.)
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
hich will take care of defining SOURCE and BUILD, and then tests/runtests
-o will work as expected.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
a particular environment variable is set. You can
do similar things for any other missing feature, and of course skip only
part of the tests in a particular case case if you want (although
currently, with the C TAP Harness harness, the latter doesn't tell you the
reason why the test was skippe
Bob Friesenhahn writes:
> On Wed, 21 Mar 2012, Russ Allbery wrote:
>> Miles Bader writes:
>>> [Relying on source-code execute bits always being correctly maintained
>>> is one of those things that ... well... doesn't really feel very robust.
>>> I dunno,
uppose
that people could chmod +x the configure script before running it, but
I've never had to do that.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Harlan Stenn writes:
> What's the problem with bin_SCRIPTS?
Ack, sorry, that's what I meant in my reply.
Note that the Automake documentation also defines how to handle variable
substitution if necessary for scripts, although it doesn't have the magic
to handle non-verbose
rwise that seems rather pointless, compared to just:
bin_PROGRAMS = myprog
and having the script just be named that and already be executable, which
is what I do with any exectuable shell scripts.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
y
arranged to run that at the end of make install. Is that not happening
for some reason?
libtool --mode=finish will run ldconfig. It's much of the point of having
a separate finish mode.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
mplicated and other parts of the compilation
process dominate the time. C++ is significantly different than C in how
much complexity it puts into its headers.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
for Debian, of course, but isn't part of a typical install.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
7; then the output format can be certain.
The problem, of course, being that pax probably isn't available, which
makes it hard for a default choice.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
doesn't expand them and lets the shell expand them.
(cd $(top_builddir)/$(NSI_INSTALL_DIR)/doc; \
FILES=`find . -type f`; \
for file in $$FILES; do \
echo "Processing "$$file; \
todos -p $$file; \
mv $$file $$file".txt"; \
done)
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
he EXTRA file list for the given target.
In other words, if this is used to build libfoo.a, then add:
EXTRA_libfoo_a_SOURCES = foo.c
to your Makefile.am.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
to be completed within the given time frame.
You may be interested in:
http://www.eyrie.org/~eagle/software/c-tap-harness/
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
in that location?
luadir = $(LUA_DIR)
lua_LTLIBRARIES = cairo.la
and then set LUA_DIR as an AC_SUBST variable in your Autoconf
configure.ac, which can then apply platform-specific logic, use a --with
flag to specify the path, etc.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Bob Friesenhahn writes:
> On Thu, 29 Apr 2010, Russ Allbery wrote:
>> I think this just varies based on what your developers are like and how
>> closed your project is, basically. People often say that they find it
>> fairly easy to make all developers on a project use ide
NightStrike writes:
> On Thu, Apr 29, 2010 at 7:53 PM, Russ Allbery wrote:
>> I suspect it depends on what sort of activities you expect people using
>> a VCS checkout directly to be doing, and also how sophisticated of a
>> VCS you're using. If you're using CVS
l
merge conflicts from auto-generated files probably aren't making your life
much worse the way that they would in Git.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Trevor Harmon writes:
> On Apr 29, 2010, at 12:25 AM, Russ Allbery wrote:
>> Although I must admit that now that I've switched to Git for
>> everything, I'm finding myself more and more just using git clean -x -f
>> -d
> What does that do?
Deletes every fil
hat make distclean is for.
Although I must admit that now that I've switched to Git for everything,
I'm finding myself more and more just using git clean -x -f -d rather than
worrying about the maintainer-clean target.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
either or
> ? Or would that break too much backwards
> compatability?
It breaks the basic assumption that Makefile.am is basically a makefile.
I suppose that Automake could try to transform the whitespace as part of
its processing, but I'm not sure that's a good idea.
--
Russ Allbe
Ralf Wildenhues writes:
> * Russ Allbery wrote on Mon, Apr 19, 2010 at 08:39:48PM CEST:
>> Ralf Wildenhues writes:
>>> * Ralf Wildenhues wrote on Mon, Apr 19, 2010 at 06:55:30PM CEST:
>>>> * Russ Allbery wrote on Fri, Apr 16, 2010 at 10:27:11PM CEST
Ralf Wildenhues writes:
> * Ralf Wildenhues wrote on Mon, Apr 19, 2010 at 06:55:30PM CEST:
>> * Russ Allbery wrote on Fri, Apr 16, 2010 at 10:27:11PM CEST:
>>>> parallel.1: parallel
>>>>pod2man --release='$(PACKAGE_VERSION)' --center=
s not make the man page either.
Hurm. I could have sworn that the man_MANS target was automatically
built. What's the output of the latter command?
Also, if make install knows to install the man page, make should
automatically attempt to build it as well, so I'm confused as to why that
wouldn't happen.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
= program
man_MANS = program.1
program.1: program
pod2man --release='$(PACKAGE_VERSION)' --center='$(PACKAGE_NAME)' \
--section=1 program > program.1
CLEANFILES = program.1
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
ne's concerns. A lot of things that make it into standards are
widespread existing practice before then, and it's too much work to change
them.
I suspect this is part of why, as you point out, the standard also
introduces int_t at the same time, but "long long" is more wi
he CPPFLAGS setting for this
compilation, so they look like individual source files. I suspect that
somewhere you're setting the wrong Automake variable to a list of header
files, although I don't see that in the Makefile.am excerpt that you
included.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
ay to turn
them off and somewhat lesser but probably still reasonable consensus that
turning them on as an Automake-wide default is a bad idea, but I don't
think any of the maintainers are going to object to making it silent when
that's explicitly requested.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
or-core/COPYING?revision=560&view=markup
Yeah, using that license is fine. It's part of INN, which is under a
different form of the BSD license, but I wrote it, and I have no
objections to you using it under the license you link to above.
--
Russ Allbery (r...@stanford.edu)
er done. I just
write explicit rules.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
#! /bin/sh
## $Id: fixconfig.in 8471 2009-05-17 08:25:35Z iulius $
##
## Make variable substitutions in configuration files.
##
## This script does something very simila
onfig.h file.
Because of the requirements for expansion of shell variables, usually it's
best to not put paths into config.h. Instead, passing them on the
compiler command line is usually easier.
See info autoconf FAQ 'Defining Directories'
--
Russ Allbery (r...@stanford.edu)
Ralf Wildenhues writes:
> * Russ Allbery wrote on Wed, Dec 16, 2009 at 05:08:14AM CET:
>> Do you really want to generate separate copies of the man page for each
>> function documented by the same source POD file? It's more normal to
>> generate one copy of the man
espondance between
source files and output *roff files, at which point (if they're named
accordingly) the pattern rule would work.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
RNINGS)"
# PHP's build system uses INSTALL_ROOT where everyone else uses DESTDIR.
install-data-local-php: php/modules/remctl.so
cd php && $(MAKE) install INSTALL_ROOT=$(DESTDIR)
# Build and install the PHP bindings if desired.
BINDINGS =
BINDINGS_INSTALL =
if BUILD_PHP
BINDINGS += php/modules/remctl.so
BINDINGS_INSTALL += install-data-local-php
endif
all-local: $(BINDINGS)
install-data-local: $(BINDINGS_INSTALL)
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
dd a new Automake option that says
to check all the versions of scripts included in the package at make dist
time and not default it to on.
The less conservative approach would be to check the scripts at make dist
time by default but add an option similar to foreign that lets people turn
that check off
version checks
normally go against the philosophy of the Autotools, but in this case
they're files shipped by Automake itself, and it might be the easiest
path.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
commands ...
> subdir/my-dirstamp:
> @$(MKDIR_P) subdir
> @: > $@
> DISTCLEANFILES += subdir/my-dirstamp
A possibly simpler way, depending on what you're trying to accomplish, is
to do this at configure time:
AC_CONFIG_COMMANDS([tests/data/.placeholder],
krb5_get_init_creds_opt_set_default_flags \
krb5_get_renewed_creds])
AC_CHECK_TYPES([krb5_realm], , , [#include ])
RRA_LIB_KRB5_RESTORE
for cases like that.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
I don't recall seeing anything
in the FHS, but it's possible that LSB has additional file layout
standards outside the FHS.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
.m4 <==
AC_INIT([foo], [1.0], [...@stanford.edu])
Seems to work for me, although I've not used it for a real package. You
then just automatically generate version.m4 as part of your bootstrap
process before running autoconf.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
omething is wrong in your setup, because I do not need to list
> all indirect libraries. The only exception is when dealing with
> non-libtooled static libraries that have poor subobject management.
This does depend on the platform. Modern ELF platforms support
transitive shared library depen
se architectures are
becoming increasingly less common.
Thankfully, I just misunderstood the footnote entirely and nothing about
this change will affect that continued position.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Ralf Wildenhues writes:
>> [1] I'm asking because Automake 1.11 will reliably not install files if
>> their respective installation directory is empty. This is not yet
>> functional in Automake 1.10.2. The test for emptiness in 1.11 will not
th:
./configure --prefix=/usr/local
make
make install prefix=/usr/local/stow/package-version
DESTDIR cannot easily be used here because the stow layout should have
simple bin, etc, lib, etc. directories directly under that directory, not
with an extra /usr/local in the way.
ically generated
and rarely contain useful information, get in the way of seeing bits of
output that are actually important.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
1) == 0)
return 1;
If your uses of strtod don't care, you probably don't care about this one
either.
The Autoconf manual has the documentation for both of these.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
replacements, they're not very useful. I think autoscan will
suggest using them if you ever use either of those functions, but you may
or may not need the portability there.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
"Gerald I. Evenden" writes:
> On Thursday 26 March 2009 10:26:13 pm Russ Allbery wrote:
>> However, more fundamentally, you're reinventing AC_REPLACE_FUNC, which
>> you probably don't want to do. Check the Autoconf manual for
>> AC_REPLACE_FUNC, which do
strcasecmp? It's required by POSIX and is usually in the set
of things that aren't worth bothering checking for unless you're porting
to Windows (which particularly for shared libraries involves quite a bit
of work that Automake can't entirely help with).
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
omake and generate its output files without having make
installed, I believe. The resulting generated files are not useful
without make, but they may not be intended for use on that same system.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
e Makefile from Makefile.in. It doesn't
have a mechanism for eliminating entire lines of output, but adding or not
adding comment characters is fairly straightforward.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
as
planning on doing it. So I have a working work-around.
Thanks for the queued TODO item!
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
s would avoid the problems you mention above.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Hi Russ,
> * Russ Allbery wrote on Wed, Apr 23, 2008 at 02:16:34AM CEST:
>>> If I add:
>>>
>>> portable_libportable_a_CPPFLAGS = $(KRB5_LDFLAGS) $(KAFS_LDFLAGS)
>> Er, obviously that should be KRB5_CP
Russ Allbery <[EMAIL PROTECTED]> writes:
> If I add:
>
> portable_libportable_a_CPPFLAGS = $(KRB5_LDFLAGS) $(KAFS_LDFLAGS)
Er, obviously that should be KRB5_CPPFLAGS and KAFS_CPPFLAGS. Sorry about
the confusion.
> it has no effect, which after thinking about it for a moment
FLAGS) $(KAFS_LDFLAGS)
it has no effect, which after thinking about it for a moment makes some
sense. However, setting LIBOBJS_CPPFLAGS doesn't do anything either.
Could some facility to handle this be added?
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
hat
it looks like were fixed in 1.10.1 (or at least some workaround code that
I had doesn't appear to be necesary any more).
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
le who aren't so enamoured of the FSF project as to be
willing to make everything a GPL-covered GNU project but who are quite
willing to share code, bug reports, and general software infrastructure.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
1 - 100 of 168 matches
Mail list logo
