that get ported can Provide: (since something like 90%+ of packages don't
need anything that isn't shared between all four variants I know of in
common use), and stop trying to pretend they're mergeable into a single
utility.
i'd expect macos & freebsd to converge on the same tool.
the most "merged" BSD make i'm aware of is:
http://www.crufty.net/help/sjg/bmake.html
.mrg.
[ i haven't really be following this discussion... ]
On the other hand, GCC3 is now a part of the mainline build stuff for
NetBSD's own release, and I believe the intent is to release 2.0 with GCC
3.mumble as the primary compiler. But don't take that as gospel...
GCC 3.3.x is going
--L6iaP+gRLNZHKoI4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Wed, Dec 17, 2003 at 12:44:07PM -0500, Nathan Hawkins wrote:
> On Fri, Dec 12, 2003 at 02:58:42PM -0700, Joel Baker wrote:
> > I really need to sit down and write a proposal / patc
This may be possible under NetBSD as well (especially with a generous
helping of COMPAT option enabling), but given the number of dire warnings
the manuals all bear about building things in the correct order, I'm not
willing to trust that it's flexible enough to start doing interest
No, we combine the advantages of Debian, GNU, and the kernel of NetBSD.
The superiority of GNU userland repect to NetBSD's is an issue too, and you
seem to be ignoring it.
no, it's more that we (at least perry and i, and most of the netbsd
developers) _don't think GNU userland is
A usable Debian GNU/KNetBSD system based on Glibc is now available:
so... can someone explain what the plan is for deb/netbsd wrt libc?
ie, will there be 2 systems one that is compatible with netbsd (ie
that people can upgrade to, run normal netbsd apps, etc) and one that
isn't (ie, glib
>This is getting more confusing :(. Maybe it means FreeBSD 3.x and lower
>didn't support PPP natively..
>
> freebsd have changed preferred ppp implemetation from the normal pppd
> that everyone else (heh) uses to their userland ppp that uses tun(4)
> instead of ppp
- "makext" probably means userland, so "sys-bsd.c" is highly likely to assume
FreeBSD. we have GNU userland, which is what the sources call "linux", so
we set makext="linux" (it's ugly to call it like this, but i can live with
it ;))
no. "sys-bsd.c" is the code to talk to a BSD-li
1) __cxa_atexit - This can be worked around (GCC is patched to avoid
using it), but it's fugly and really should be fixed. Conveniently, in
-current, it is (after a PR requesting it). Can be backported, though I'm
not entirely sure I'm comfortable with that, given how it affects eve
>> it is a bug if a new kernel with (all) COMPAT options is not able to
>> run old software. perhaps the only exception to this is ld.elf_so,
>> but in general that also applies (there *are* exceptions though.)
>
>I don't understand this - does this mean that al
>
>In considering this, I realized htat we have a potentially serious
problem
>- if you install a new libc on an older-kernel system, it may well blow
up
>in a way that cannot easily be recovered. So I've written a mini-policy
>
> this is pretty much correct.
In considering this, I realized htat we have a potentially serious problem
- if you install a new libc on an older-kernel system, it may well blow up
in a way that cannot easily be recovered. So I've written a mini-policy
this is pretty much correct. in netbsd we basically say that i
> when making such assertions it helps to be actually correct. while it
> is true that *any* old binary may require COMPAT_XX options in the kernel,
> netbsd supports binaries back to 386bsd for i386, with shorter periods
> of backwards compat for the newer plaforms. i have personal
They presumably did it because they thought it would be a good idea.
Perhaps they wanted to hide implementation differences between
different OSes. Either way, the low-level functions in FreeBSD work
just fine.
FWIW, i just ran "man funopen" on my netbsd box and it says:
HISTOR
To David Brownlee: I doubt NetBSD 1.0 binary could run against
a NetBSD 1.6 libc. They don't care much about binary compatibility. You
could not even run a statically linked 1.0 app without some COMPAT_
option in the kernel, I think.
when making such assertions it helps to be act
On Wed, Jan 15, 2003 at 09:34:45AM -0600, Steve Langasek wrote:
> On Wed, Jan 15, 2003 at 07:31:42AM -0600, Colin Watson wrote:
> > On Tue, Jan 14, 2003 at 05:40:45PM -0600, Steve Langasek wrote:
> > > FWIW, I did some research into nl_langinfo() for an upstream recently,
> > > and
There should be no real problem with this, except that you'll need native
versions of some of the NetBSD tools used during make (the NetBSD make,
for a start). Make doesn't trivially build on Linux, but if someone wants
to take a look at that it'd be a sensible thing to package.
> Well, IMHO the first thing to know is about the concepts of the other
port.s.
Indeed. It's probably best we fall in line with the other *BSD port,
especially the NetBSD ports on ia32 and alpha.
i strongly suggest following the ia32 port's lead.
> Which parts of NetBSD ar
Your webpage says "Note that for now, it looks like you can't have two
NetBSD partitions on the same drive on i386."
This is unclear.
I use NetBSD i386 with multiple fdisk partitions on same disk (although I
only boot from one).
until recently, i believe this was not well s
good warning. i've trashed myself once updating netbsd with
new /libexec/ld.elf_so :-)
Also present are the usual suspects from libc6 and libc6-dev, in their
NetBSD forms: rpcgen, gencat, zic, ldd, ld.so (and ld.elf_so), etc.
FYI:
ld.so is for a.out, so, unless you also install (eg)
OpenBSD appears to be more heavily audited though. Maybe it's just
appearance. You may have seen in the Debian Weekly News that I'm working
on a rough audit project and in such I would like to say that security
must include a heavy code audit.
i think 'appears' is a great word her
Indeed, some investigations with nm and perl show that basically all of the
core (libc12) libraries depend on libc for some set of their functions.
The only odd bits are libutil (which depends on libposix for chown, easy
enough to link) and libc, which has the undefined symbols
>Suggestions on how to properly figure out which libraries things must
link
>against (especially involving libraries which may or may not be present,
>such as libi386 and libm387 - especially the latter) would be
appreciated.
>
> well, libi386 is linked into applic
Okay. So it's a matter of historical FUBARism - which means I should, at
the very least, have a FIXME to find some way to fix it, and not turn
off the warnings.
NetBSD arguments aside, this information *should* be used on Debian, simply
because it becomes very important when
Need someone with more familiarity with NetBSD's intricacies to assist on
this one. Currently, lintian is throwing a spew of a single error (one per
library, in both libc12 and libc12-dbg), based on the fact that NetBSD,
unlike Linux, does not have every library dependant on libc (a
At present, dpkg won't build because it can't find obstack.h, which
seems to be part of glibc. Is there a patch for dpkg that I need?
isn't obstack part of libiberty?
it appears to be from my netbsd toolchain tree.
> the only problem with the Big List file is that i'd expect a lot of it
> not to apply to debian/netbsd. only those parts in sys/, lib/libc/ and
> sundry programs ... which is probably 90% of the list anyway.
A quick grep of libc reveals that it's mostly either The NetBSD foun
It's the INSTALL.txt file, not a copyright file. I have not (yet) been able
to find a copyright or license file that directly applies to the sources
in CVS, either on the website or in CVS itself. Anyone who knows where the
heck the thing is hiding, do tell. :)
look in src/distrib/
as far as i'm aware, there are very conflicting views on mixing
GPL & 4-clause software. to me, calling them "incompatible" such
that you refuse to link apps & libraries because of it is way over
stepping the mark, espcially if you are linking GPL apps against
a BSD system -- are you going to
NetBSD. Licensing.
Appears to be old (non-revised) BSD license... certainly the INSTALL.txt
file for 1.6 has lines at the beginning of the ungodly long section for
the NetBSD project (in two forms, no less!)
Pardon me while I sink into despair of ever untangling the mess,
Hmmm. The origional plan had said /lib.
yeah, i know. that's why i told you :-) basically, enough people
complained that not using /libexec/ld.elf_so would be to break the
consistency of the system, yadda yadda yadda. i don't care and
prolly would have preferred to not have a new /libex
hi folks.
just a FYI.
not sure if you saw or not, but when netbsd switched to dynamic
everything, a new /libexec directory was created to hold ld.elf_so.
it's not in /lib.
btw, what is the status of libc vs. glibc? if glibc is the 'default'
how does someone run a standard netbsd application o
> * start-stop-daemon is broken. Now that libkvm is built, I can work from
> Stockholm's patches for OpenBSD.
I've been thinking about this: using libkvm in start-stop-daemon will
ultimately make dpkg depend on specific kernel versions. (struct proc
changed at least once t
* Almost anything that looks at /proc won't work. It would be a good
idea to avoid that in code that is intended to be common to all archs.
FYI:
on netbsd, "mount -t proc -o linux procfs /proc" will provide a
portion of linux-compatible procfs (whatever parts people have
found are Requ
bsdutils, e2fsprogs, login, mount, and util-linux.
mount? this one is going to be fairly tied to the kernel...
- nto-qnx* | linux-gnu* | storm-chaos* | os2-emx* | windows32-* |
rtmk-nova*)
+ nto-qnx* | linux-gnu* | storm-chaos* | os2-emx* | windows32-* |
rtmk-nova* | netbsdelf-debian*)
you probably want "netbsd-debian*" as well.
The only packages where this caused any great trouble were gcc and
binutils, and that was fairly easily rectified.
GDB?
>Note that in the case of non-i386 ports, where 'unknown' may actually
be a
>valid vendor, config.guess is *only* filling it out if there is a single
>vendor value - IE, something that can be put into the archtable as-is,
and
>come back out again without conflict.
* i386-unknown-netbsdelf1.5 (1.5 major release, any minor)
* i386-unknown-netbsdelf1.6. (1.6_{BETA,RC}*)
* i386-unknown-netbsdelf1.6 (if you force the kernel to lie)
hmm, the "standard" config.guess scripts should end up with
i386-unknown-netbsdelf. ie
i386-unknown-n
>* Port and package UFS mkfs and fsck for Linux. Hurd might use this as
>well. Might be issues with differences between the BSD's. FreeBSD has
>some recent features that may not be in Net or Open. (Soft updates,
>snapshotting, etc.) I'm not sure if those would cau
* UFS detection in fsck. fsck is actually a wrapper that tries to detect
the filesystem, and DTRT. It would be helpful if it could identify UFS,
and run fsck.ufs, like it does with all the Linux filesystems.
FWIW, in netbsd fsck(8) is a front end to fsck_ffs(8) and others.
*
Some advice would be useful. GCC 3.2 depends on gnat-3.1; gcc-3.1 also
depended on gnat-3.1, and, mysteriously, is the source for gnat-3.1 - so,
just how the hell am I supposed to build anything past GCC 3.0, when it
depends on a package that comes out of itself, to build?
Is th
On Mon, Aug 26, 2002 at 04:28:38PM +1000, matthew green wrote:
> wow, this is such a bad idea.
It originated upstream.
mmm, xdm.
In fact, judging by CVS logs it has been in xdm's source for many, many
years.
bad ideas often hang around for a long time.
Be warned: on at least some architectures (notably IA-64), this sort of
read has been known to cause untrapped machine checks (a.k.a., lockups
or spontaneous reboots). Arguably the kernel should trap this sort of
nonsense, so you may be in the mood to file a bug against "kernel" af
Think you could port BSD libc to Linux without making a mess?
considering that we (netbsd) basically have a source-compat layer
for netbsd software on linux, this actually is a whole lot simplier
and easier than you may otherwise think.
The BSD libc is smaller for about the same reas
> can't we have both?
There's certainly no problem shipping both - what I was thinking about
more is which do we link everything against?
i know of at least one bug in glibc that wasn't a candidate for being
fixed (last i heard.) it's nfs_readdir() depends on an opaque cookie
be
I have a sufficiently working glibc that I can build binutils and gcc
against it and then use them to rebuild a working glibc, but it'll need
some work yet before it's even vaguely production ready. The general
opinion at Debconf seemed to be that going with glibc was preferable to
I've been working on getting Bruno's work on the FreeBSD port of glibc
running on NetBSD. One problem I've encountered is that once I move over
to linking everything against glibc, I end up with binaries that have
different contents in the ELF header. NetBSD checks for NetBSD specific
> I think using /usr/bsd, as I do now, is fairly simple. Given the
> complexity of the source package's build system, I'd like to keep it
> simple. (Keep in mind, this is only required to build the freebsd
> source package. You don't need it for anything else.) I think I really
On Mon, May 20, 2002 at 11:24:01AM -0700, Jeremy C. Reed wrote:
> On Mon, 20 May 2002, Robert Millan wrote:
>
> > IIRC, /bin/sh is a C shell in *BSD? Then you should set interpreter
>
> /bin/sh is not a C shell. For example, NetBSD's sh manual says:
>
> The current vers
>2) config.guess currently produces i386-unknown-netbsdelf1.5. Under
Linux,
>this is i386-pc-linux-gnu. Adding i386-unknown-netbsdelf1.5-gnu (or
>possibly even just i386-unknown-netbsd-gnu), determined by the different
>uname output, would allow for Debian-specific
Looked like a bourne shell to me. Default root shell is /bin/csh on
FreeBSD, but I believe /bin/sh is basically the same as ash.
Interestingly, MAKEDEV fails to work with bash but works fine with ash.
i'm not sure about freebsd, but netbsd has used ash in /bin/sh
for a Long Time. i
1) Modify the kernel build so uname -v includes "Debian" - this is a
pretty trivial change. It does present problems if people build kernels on
their own - one option would be to make sure that the kernel build system
ensures that this is set.
i think this will only cause things to
>http://www.crufty.net/help/sjg/bmake.html
>
> for details. it's going to have more-netbsd changes than freebsd
> or openbsd but i know simon has also worked at getting them as close
> as possible (there are some inconsistency extensions, :U and :L
> mean different things a
1) FreeBSD 5.0 pre-release... does anyone know if it's GCC 3.x clean? If
so, I might futz with trying to do up a chroot based on that, at some point
here... unless someone else desperately wants to do it or something.
2) pmake (aka /usr/src/usr.bin/make) - the source tree for th
On Sun, Mar 17, 2002 at 06:55:26PM +0100, Jeroen Dekkers wrote:
> This is certainly true. It's a wishlist item, it would be nice if all
> free kernels would use multiboot. I've heard that grub will at least
> be partly rewritten to make some new features possible, it might also
> be
> The NetBSD loader is, unsurprisingly, not subject to this restriction.
I'd
> be tempted to go with packaging this and using it as our primary boot
> mechanism unless anyone objects. The one problem I can think of is that
it
> stores the bootcode in /boot, which is a directo
GRUB appears capable of booting the kernel, but can't pass any kernel
options. This appears to include passing the root file system, requiring
it to be typed by hand later on.
The NetBSD loader is, unsurprisingly, not subject to this restriction. I'd
be tempted to go with packag
How exactly can I work on the BSD kenrel on my iMac running Debian Sid
PPC Linux? I have a 12 gig hard drive.
hmm, do you have another (unix) machine? netbooting netbsd on the mac
is the simplest way to do this, and it doesn't require repartiting
your hard drive... if you don't, you'd
> there are lots of versioned system calls. i'm sure this really
> affects more than fstat(). the others probably just cause less
> drastic (but potentially more dangerous!) lossage.
Yup, it looks like fstat, lstat, stat, chown, chown, fchown, lchown and
possibly a couple o
On Sun, Feb 24, 2002 at 08:43:11PM +, Matthew Garrett wrote:
> Fakeroot on NetBSD is dying inside libfakeroot. The mess of wrap* has left
> me sufficiently confused that I'm not really sure what's going on, and
> I've certainly got no idea why it dies. Does anyone who understands t
I thought sockets weren't affected by read-only filesystem. Just out
of curiousity, why should they be if the node is already there? There'd
be no actual writing to the filesystem. Do fifo's not work either?
creating a socked or a named pipe is creating a file on the
file system. you
On a separate note, msyslogd builds happily but uses /dev/log as its
socket by default. The NetBSD logging functions seem to be expecting
/var/run/log - symlinking the two work, and you can pass an option to
msyslog to make it produce /var/run/log instead. What's the preferable way
FYI:
a basic implementation of utmpx has been commited to netbsd-current,
completely indepedant of any work done here... i don't believe it is
100% complete yet.
> I'd been under the impression that pmake was some sort of parallel make
> (though I'm not sure why), so that can probably be assumed to just be me
> being stupid. I don't see any reason not to use pmake instead (other than
> it being a bit out of date).
>
>it is. paral
On Tue, Feb 19, 2002 at 08:59:15PM -0700, Joel Baker wrote:
> So... pmake claims to be "BSD 4.4 make", and in fact appears to be a not-
> unreasonable copy of the NetBSD make sources. Is there any particular
> reason that the make-bsd and netbsd-mk packages in the chroot can't be
>
This leads to the question of keeping pmake in sync with the source version
that it's meant to build. Perhaps I need to do a pmake- instead,
make it conflict with pmake, and figure out how to do it saner, later...
hmmm look for simon gerraty's autoconfistcated pmake -- it's based on
On Wed, Feb 20, 2002 at 03:02:26PM +1100, matthew green wrote:
>
>So... pmake claims to be "BSD 4.4 make", and in fact appears to be a
not-
>unreasonable copy of the NetBSD make sources. Is there any particular
>reason that the make-bsd and net
So... pmake claims to be "BSD 4.4 make", and in fact appears to be a not-
unreasonable copy of the NetBSD make sources. Is there any particular
reason that the make-bsd and netbsd-mk packages in the chroot can't be
replaced by the Debian-standard pmake package, if it gets updated (it's
On Mon, Feb 18, 2002 at 04:51:17PM -0700, Joel Baker wrote:
>
> This is a fix I had considered... but really should happen upstream. I
> guess perhaps I'll check the CVS version of things, and file a bug if it's
> still got this problem...
Teach me to check upstream first. P
As best I can tell, with the native NetBSD sys/socket.h, if a problem in
any way defines (or triggers definition of) _POSIX_SOURCE or _XOPEN_SOURCE,
anything which calls sys/socket.h will break horribly (since it uses values
from types.h - which it also fails to include on it's own - w
There's a field in the ELF header called OS/ABI. Readelf -h finds it, and it
looks like this:
Normal binaries:
OS/ABI:UNIX - System V
FreeBSD binaries:
OS/ABI:UNIX - FreeBSD
I need to look into it a bit
> Also, FreeBSD (and possibly NetBSD as well) uses the ELF OSABI field to
mark
> it's binaries.
The GNU/Hurd does it as well.
hmm, last i looked hurd used an ELF note, like NetBSD.
Bear in mind that quite a few systems already support multiple kinds of
binaries, and there are more on the way. Sparc, ia64 and x86-64 (not sure
if x86-64 is a Debian arch yet) all can do both 64 and 32 bit binaries. I
think s390 might too, but I'm not sure. The packaging system ne
BTW, binutils for netbsd-i386 *does* appear to work sanely, and is now in
the upstream. At least, it both compiled and run-time linked all the C++
code I could easily put my hands on to test (I used groff, which broke in
upgrading to GCC 2.95.4 local compile due to libstdc++ stuff;
I'd believe it. Another reason to use 3.0 as the default, if I can make it
work. Sadly, NetBSD still uses egcs 2.91 as it's default compiler, so I have
no idea if we might need 2.95 as a kernel compiler. Hopefully we can get
the kernel patched to be clean for 3.0, if it's not. I gue
As far as I can tell, the main difference is that "-" (bare) is considered
illegal in the NetBSD setup. I don't have any easy way to test what the
difference in "--" is, though long usage would *imply* that it means "end
parsing of all arguments here" in the GNU world.
OK, i'll see
>> Also a BSD-licensed getopt (and getopt_long) is available in the
NetBSD
>> libc.
>
>But behaves differently to GNU getopt_long, as regards its handling of
>the arguments '-' and '--'
>
> it does? this sounds like a bug. it should be compatible.
>
> On Sat, 2 Feb 2002 [EMAIL PROTECTED] wrote:
>
> > getopt is in libiberty. It's also in glibc, and people have a bad
> > habit of not checking for that in configure. I'm thinking about
> > packaging libiberty, and
>
> Also a BSD-licensed getopt (and getopt_long) is
XFree86 is wanting to link against libi386, which appears to be a NetBSD
specific library to handle some special processor manipulation. Can this
be ported to Debian? Should it? Is there a reasonable way to work around
code which wants these? Advice from NetBSD Gurus sought :)
netbsd
As I said, FreeBSD's resolver really didn't like the Linux version of the
file,
which is in base-files.
OK. i'm fairly sure this won't affect the netbsd port cuz
it won't be used at all as far as i can tell...
Modified now that Matthew's pointed out that RB_POWERDOWN exists.
(btw, "halt -p" and "shutdown -p" access this from the NetBSD userland.)
I plan to just replace ifconfig. The major headache is ifupdown. FYI, watch
out
for /etc/host.conf. The Linux version badly broke FreeBSD's resolver.
what is host.conf? don't think netbsd uses it.
Two minor changes needed (other than s/freebsd/netbsd) for the sysvinit
patch - NetBSD's reboot() doesn't seem to do poweroff, so I changed that
#define to just halt the system, and reboot() takes two arguments, magic
and a string that can be passed to the firmware under certain
cir
However, I'm still building with the NetBSD gcc/binutils/libc, and I
figured that now would be a good time to switch to a Debian "native"
compiler. =)
To accomplish this, I have binutils configured with
--target=alpha-netbsd --prefix=/some/path
and compiled wi
i think that most target tuples that `config.guess' generates have the
OS version included. certainly i can't think of anything except linux
that doesn't :-)
As you can see, different output by different config.guess scripts.
Also notable, the config string doesn't tell you I'm runnin
A) Use this file at all?
B) Support the 'compat' entries (the only major difference between the
tarball and the distributed file).
this is the default nsswitch.conf (ie, if none is present):
groupcompat
group_compat nis
hosts
On Tue, Jan 22, 2002 at 11:20:51PM +0100, Robert Millan wrote:
> - Error when building screen: "ld: cannot find -ldl". Anyone has an idea
> on this?
Much like -ldb, netbsd just puts the functionality in the libc[1], so
you don't need the library. In fact, the library doesn't ex
At least on FreeBSD, shared objects can't be ldd'd, which happens to be
exactly what debhelper does. Perhaps these .so's don't include information
for ldd to extract? It's really weird, because it's supposed to be ELF.
fortunately, on NetBSD, this isn't an issue. our ldd(1) is actua
In the current chroot, /usr/include/db.h and /usr/include/db2/db.h
seem to be from the netbsd db1. /usr/lib/libdb2.* seem to be the
libraries from the debian db2 package. /usr/lib/libdb.* are symlinks
to the db2 libraries. This is helping to cause the apt build to fail.
It is also p
I'm not quite sure what you mean here. passwd, adduser, chfn and so on
work in as much as they update /etc/passwd (they all use the libshadow
functions for this even if you don't compile it as a shared library), but
NetBSD getpwnam will only use the db format files. What I think we
I would *much* rather have the non-dependant stuff, of which there is a
whole lot, built as separate packages. Wherever the source comes from, I
don't want to have to rebuild a lot of cruft that isn't actually crucially
out of date, just to get a reasonable kernel. If I rebuild my k
utilities and libraries NEED to be built together with the kernel. It's a
feature in the BSD world. It'd be easer to keep them in sync if they're built
hmm, i wouldn't call it a feature :-) certainly in NetBSD we've done a
lot of work to remove these sorts of issues... and the trend is
Well put, and an important point. MY understanding of RMS, and of the BSD
license would seem to indicate that what's done with the code is no one's
business. If your M$, and you want to absorb BSD code, or some evil
dicator somewhere, it doesn't matter, the code is free to use, as
On a related note, FreeBSD's Makefiles use "make" sometimes where they should
use "${MAKE}", so I put the BSD make into /usr/bsd/bin. Then I mangle $PATH
before running make from debian/rules, so that the FreeBSD Makefiles always
get BSD make rather than GNU. Sounds like NetBSD has
> that's only for i386. i'm still waiting for my sparc/sparc64 patch
> to be commited (i should ping them) and i don't know the status of
> other netbsd gcc ports in gcc-current, really, at all...
Joy :) Is the 2.95 in the ports tree suitable for all architectures?
i really d
I've got my NetBSD system up and running again. I'm slowly rebuilding the
packages that I lost after my laptop was stolen, but ought to be back to
the point of having all the trivial stuff dealt with shortly. gcc-current
appears to succesfully build on NetBSD without extra patching, so
NetBSD chroot environment, and I didn't even manage to compile it (it
stopped compiling with a strange error message, namely an assembler
error message, that some alignment is not the power of 2; I tried both
this looks like the a.out vs ELF compiler problem. not surprising,
but see
FWIW, it seems that the NetBSD ELF `ldd' works with shared libraries.
i don't have an a.out system to test with but you can probably ignore
that as most netbsd port have switched or are in the process of
switching to ELF.
1 - 100 of 111 matches
Mail list logo
