Paul Wise wrote:
Bob Proulx wrote:
How can I as a system administrator clean that obsolete conffile up?
rm -f /etc/some-obsolete-conffile
apt-get --reinstall install package-that-provided-the-obsolete-conffile
Ah! Thanks. That works.
I have many obsolete conffiles on my system
Paul Wise wrote:
Please file bugs about obsolete conffiles when you find new ones. The
packages themselves should clean up their obsolete conffiles.
Is there a bug example or two you could point me to so that I can
follow the standard template of reporting these problems? It appears
I have
I have many obsolete conffiles on my system. It has been upgraded
through many releases.
dpkg-query -W -f='${Conffiles}\n' | grep obsolete
Picking a simple one as an example:
/etc/skel/.bash_profile d1a8c44e7dd1bed2f3e75d1343b6e4e1 obsolete
If I purge the package and install it fresh then
. What is your desire? I am getting a little nervous about
getting the current update uploaded before the freeze. I would like
to be ahead of the wave and get through the autobuilders.
Thanks!
Bob
Russ Allbery wrote:
Bob Proulx writes:
It was. But then Russ Allbery noted some oddities! :-) I
Russ Allbery wrote:
Bob, I've uploaded the latest version. Thank you for your work!
Thanks!
Bob
signature.asc
Description: Digital signature
Russ Allbery wrote:
* There seems to be something odd about the time info file. If I run info
time, and then press space, rather than proceeding to the next child
node the way that info normally does, info just reports no more nodes
in this file. The same is true at a few points in the
: #663260)
-
+ * Fix man page formatting oddities. Thanks Russ Allbery for the nice patch.
+See Bug#677013#68 for the discussion.
+ * Fix texinfo standalone info program navigation oddity. Reported by
+Russ Allbery. See Bug#677013#63.
+
-- Bob Proulx b...@proulx.com Mon, 23 Feb 2012
Bart Martens wrote:
Bob Proulx wrote:
Bart Martens wrote:
The file debian/copyright should name the original authors, and
David Keppel is such an author.
I have looked through many copyright files and do not see one that
does this. See for example this one along with many others
Russ Allbery wrote:
* The formatting of the man page isn't great. There are a few places that
seem to have spurious line breaks (the --append documentation, for
example),
That appears to have been some spurious spaces in bad places in the
man page. Fixed.
and it's traditional to have
...@qed.econ.queensu.ca
Copyright 2005, 2008 Tollef Fog Heen tfh...@debian.org
Copyright 2010 Salvatore Bonaccorso salvatore.bonacco...@gmail.com
Copyright 2012 Bob Proulx b...@proulx.com
License: GPL-2+
Files: debian/time.1
Copyright: Copyright 1996 Dirk Eddelbuettel
The latest 'time' package release candidate is here:
http://www.proulx.com/~bob/debian/pool/sid/main/time/2012-06-21/
-rw-r--r-- 1 16649 Jun 21 13:38 time_1.7-24.debian.tar.gz
-rw-rw-r-- 1 1038 Jun 21 13:48 time_1.7-24.dsc
-rw-r--r-- 1 12317 Jun 21 13:39 time_1.7-24_amd64.build
Ferenc Wagner wrote:
Bob Proulx writes:
Yes. But note that those had been made before too. I only updated
the autotools files (again) because the current ones were quite aged
and dearly in need of being updated. Those were not patched in the
sense of editing the file with changes
Sandro Tosi wrote:
Hello Bob,
here's a brief review of the package.
Thank you for reviewing the package!
debian/changelog
- don't rewrite history, so please restore the old changelog entries,
even if they have a weird Closes=xxx in the first entry line
The two entries are:
time (1.7-4)
Sandro Tosi wrote:
Bart Martens wrote:
Package: sponsorship-requests
Owner: Bob Proulx b...@proulx.com
I'm opening this RFS on behalf of Bob Proulx who owns ITA 652670.
Bob Proulx wrote:
Hi Bart,
How is progress on this ITA ?
Can I admit that it is a little frustrating? I
What is the best procedure to use for removing a stop script from a
package?
Moving from:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
dh_installinit
To:
# Default-Start: 2 3 4 5
# Default-Stop:
dh_installinit --update-rcd-params=start 99 2 3 4 5 .
If nothing more
Ansgar Burchardt wrote:
Sven Joachim wrote:
Bob Proulx wrote:
I am hoping to understand the obsolete flag on conffiles in the dpkg
status file. There are many packages that include this flag at the
end of the line. For example:
[...]
They are obsolete because they no longer exist
I am hoping to understand the obsolete flag on conffiles in the dpkg
status file. There are many packages that include this flag at the
end of the line. For example:
Package: file
Conffiles:
/etc/magic.mime 272913026300e7ae9b5e2d51f138e674 obsolete
/etc/magic 272913026300e7ae9b5e2d51f138e674
PJ Weisberg wrote:
Ben Hutchings wrote:
Don't even think of doing this in a package uploaded to Debian.
Right. I mentioned it mostly for completness, since it's the answer
to the question that was actually asked. I almost added, I don't
think any Debian packages actually do this, but
Ben Finney wrote:
Richard Hector writes:
We've run into an issue here, when we deploy a package (created
in-house) on a system that uses NFS for some filesystems. Due to
root-squashing, the postinst can't create or chmod/chown the files it
needs to.
...
* You're root-squashing
Recai Oktas wrote:
Steve Langasek wrote:
awk is virtually essential: it can't be Essential: yes because
that would prevent removing mawk in favor of gawk, but awk is a
dependency of another essential package to ensure that you can use
basic awk functionality without having to depend on
I need a clarification because I am confused. If I have a script that
uses awk do I need the package to Depends: awk? Or is awk like
basename where we are able to assume it is on the system without any
explicit dependencies?
I see that many packages do Depends: awk. But awk is an alternative
Henrique de Moraes Holschuh wrote:
Then tell the user that, and DO NOT TOUCH /etc/inittab.
...
Yes. But AFAIK there are absolutely no plans to provide an interface for
ANY package to touch /etc/inittab. Screwing it up is so utterly callous,
that one would have to be out of his mind to
gregor herrmann wrote:
On Thu, Jul 07, 2005 at 08:15:06PM +0200, Rakotomandimby Mihamina wrote:
But what and how should I separate the created files?
Should I put them into the same directory? orig, diff, dsc,.. in a flat
way? I guess yes
Yup.
Maybe you'd like to take a look at
John Skaller wrote:
(a) it does not provide binary packages
(b) apt tools can't build from source
The latter is exceptionally annoying (which I consider
a very polite form of what I'd like to actually say ;)
Is there a tool which does that?
I use Synaptic GUI tool, it would be nice if
Stefano Zacchiroli wrote:
Are there any problem in uploading packages built inside that chroot?
It should be fine. In fact that is a recommended practice. It
prevents flavor from the developer's machine leaking into the build.
The 'pbuilder' package is very nice for managing these types of
Jarle Aase wrote:
I'm about to make some .deb packages. Some will hopefully be accepted as
official packages, while others will be built for my own convenience (to
ease installation and upgrades on Debian servers I maintain).
The packages includes shared C++ libraries, binaries, databases
John Hendrickson wrote:
Why in the world did DMs compile KDE to say: You must use LessTif and
uninstall Motif???
What kde package requires lesstif? I was unable to locate one using
'apt-cache showpkg lesstif1' and 'apt-cache showpkg lesstif2'.
Note that lesstif1 and lesstif2 implement
Anthony Towns wrote:
GNU Interactive Tools hasn't seen an upstream update at all since 2001,
and looking at the diffs since .18, doesn't seem to have had any
significant changes since 1999. The Debian updates seem mostly to be
updating the build system, rather than user-visible changes.
I
Steven Augart wrote:
First, a retraction:
James Damour wrote:
On Tue, 2004-05-18 at 09:03, Steven Augart wrote:
As you probably know, when a shell sees that it is running a setuid or
setgid shell script, it detects this because the euid and ruid or egid
and rgid are different. It fixes
Jarno Elonen wrote:
..and the said utility script looks like this:
source /etc/upgrade-system.conf
echo Updating available package lists...
apt-get -q=2 update
Are you randomizing your start time? Look at cron-apt for an example.
Otherwise there is a
Jarno Elonen wrote:
..and the said utility script looks like this:
source /etc/upgrade-system.conf
echo Updating available package lists...
apt-get -q=2 update
Are you randomizing your start time? Look at cron-apt for an example.
Otherwise there is a
Steven Augart wrote:
First, a retraction:
James Damour wrote:
On Tue, 2004-05-18 at 09:03, Steven Augart wrote:
As you probably know, when a shell sees that it is running a setuid or
setgid shell script, it detects this because the euid and ruid or egid
and rgid are different. It fixes
Halim Boukaram wrote:
I've finished making the rpm for my package.
Should i convert it to a 'deb' file (using alien)
before trying to get it uploaded to debian test folder
or should it be rpm or tarred.
The 'alien' program is really good. But it is not perfect. And we
would like Debian
Frank Küster wrote:
Colin Watson [EMAIL PROTECTED] schrieb:
It's easier to use DESTDIR=$(CURDIR)/debian/tmp if DESTDIR support is
available; that way you get less confused by /etc.
[..]
Hm, how do I know (other by trial and error) whether a package supports
this? autoconf'iscated ones do
Frank Küster wrote:
Colin Watson [EMAIL PROTECTED] schrieb:
It's easier to use DESTDIR=$(CURDIR)/debian/tmp if DESTDIR support is
available; that way you get less confused by /etc.
[..]
Hm, how do I know (other by trial and error) whether a package supports
this? autoconf'iscated ones do
Rene Engelhard wrote:
Bob Proulx wrote:
Why does building a package with pbuilder generate the seemingly wrong
version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the
installed library? What am I doing wrong?
Nothing.
[EMAIL PROTECTED]:~$ sudo chroot chroots/stable cat
I just recently started using pbuilder. Previously I have been
maintaining my own chroots as required. I can see why people
recommend pbuilder. It is very nice! But things do not seem to be
operating as I believe they should and I have been unable to figure
this out. Let me set the stage.
I just recently started using pbuilder. Previously I have been
maintaining my own chroots as required. I can see why people
recommend pbuilder. It is very nice! But things do not seem to be
operating as I believe they should and I have been unable to figure
this out. Let me set the stage.
John Lightsey wrote:
If anyone with a non-x86 machine would like to take a look again and give
feedback on wheter or not it compiles properly, I'd really appreciate it.
The build logs that I recieved were very helpfull.
I grabbed that and gave it another run. There are still -O9
references
John Lightsey wrote:
If anyone with a non-x86 machine would like to take a look again and give
feedback on wheter or not it compiles properly, I'd really appreciate it.
The build logs that I recieved were very helpfull.
I grabbed that and gave it another run. There are still -O9
references
John Lightsey wrote:
I'm trying to adopt xmms-goom which has a release critical bug related to
!x86 architectures. I believe the version I've packaged fixes the problem,
but I don't have access to a !x86 machine running unstable to test it on. If
someone could download, build, and test
John Lightsey wrote:
I'm trying to adopt xmms-goom which has a release critical bug related to
!x86 architectures. I believe the version I've packaged fixes the problem,
but I don't have access to a !x86 machine running unstable to test it on. If
someone could download, build, and test
Christoph Berg wrote:
Re: Bob Proulx in [EMAIL PROTECTED]
perl -e 'printf(%o\n,(stat($ARGV[0]))[2]);' /tmp # print mode in octal
41777
My only question now is where did that '4' come from in the mode? But
the last four digits always seem to be correct.
stat(2):
S_IFDIR
Christoph Berg wrote:
Re: Bob Proulx in [EMAIL PROTECTED]
perl -e 'printf(%o\n,(stat($ARGV[0]))[2]);' /tmp # print mode in octal
41777
My only question now is where did that '4' come from in the mode? But
the last four digits always seem to be correct.
stat(2):
S_IFDIR
Andreas Metzler wrote:
Frank Küster wrote:
in a package that I maintain (sponsored by a DD), I use a call to
stat. In sarge, /usr/bin/stat is in coreutils - of course I don't need a
dependency on that. However, in woody stat was in a separate
package. Usually packages keep really old
Frank Küster wrote:
stat is called to get uid and exact permissions of a temporary
configuration file which has just been created.
Perl is standard on systems. I hesitate to put more use of it in init
scripts but... Perhaps this would be of use instead of stat just to
work around this
Andreas Metzler wrote:
Frank Küster wrote:
in a package that I maintain (sponsored by a DD), I use a call to
stat. In sarge, /usr/bin/stat is in coreutils - of course I don't need a
dependency on that. However, in woody stat was in a separate
package. Usually packages keep really old
Frank Küster wrote:
stat is called to get uid and exact permissions of a temporary
configuration file which has just been created.
Perl is standard on systems. I hesitate to put more use of it in init
scripts but... Perhaps this would be of use instead of stat just to
work around this
I am setting up a scripted update for a pool of machines and trying to
understand the ramifications.
In the dpkg man page:
confnew: If a conffile has been modified always
install the new version without prompting, unless
the --force-confdef is
I am setting up a scripted update for a pool of machines and trying to
understand the ramifications.
In the dpkg man page:
confnew: If a conffile has been modified always
install the new version without prompting, unless
the --force-confdef is
Matthias Urlichs wrote:
As packages are normally upgraded through the life of a system I train
people to always say 'Y' to the replace a conffile question. Sure
this may leave the system in a generic and locally unworkable state.
So why not N? That may leave the package, at worst, in a I
Matthias Urlichs wrote:
As packages are normally upgraded through the life of a system I train
people to always say 'Y' to the replace a conffile question. Sure
this may leave the system in a generic and locally unworkable state.
So why not N? That may leave the package, at worst, in a I
Andrei Mitrofanow wrote:
nobody interestet to fvwm-themes?
http://smilebef.homelinux.org/~smilebef/
[Reading my note before sending it I see it sounds harsh. I don't
mean it that way. I mean it constructively so that you will know why
I personally have not tried any of your packages. Please
Andrei Mitrofanow wrote:
nobody interestet to fvwm-themes?
http://smilebef.homelinux.org/~smilebef/
[Reading my note before sending it I see it sounds harsh. I don't
mean it that way. I mean it constructively so that you will know why
I personally have not tried any of your packages. Please
Eric Winger wrote:
Can't I even Depend on a package and then fine tune its configuration
though?
I don't think you can depend upon a package and tweak its
conffiles. It would be interesting to be able to do that and it
certainly makes sense from an object oriented inherit and modify
Eric Winger wrote:
Can't I even Depend on a package and then fine tune its configuration
though?
I don't think you can depend upon a package and tweak its
conffiles. It would be interesting to be able to do that and it
certainly makes sense from an object oriented inherit and modify
David Meggy wrote:
Searching the mailing lists, oddly shows up nothing. I think the debian
mailing list search page needs some fixing.
I think this was in debian-devel. Since I had the page up in my
browser when I read your message here it is.
David Meggy wrote:
Searching the mailing lists, oddly shows up nothing. I think the debian
mailing list search page needs some fixing.
I think this was in debian-devel. Since I had the page up in my
browser when I read your message here it is.
Eric Winger wrote:
would it be sacreligious to ask why sources are kept in non-free?
You are asking an obvious question and the answer is the obvious one.
The sources are in non-free because they are not free. Look at the
copyrights of any of the packages in non-free and you will see that
they
Eric Winger wrote:
would it be sacreligious to ask why sources are kept in non-free?
You are asking an obvious question and the answer is the obvious one.
The sources are in non-free because they are not free. Look at the
copyrights of any of the packages in non-free and you will see that
they
Andreas Metzler wrote:
Frank Kuster wrote:
users working with Debian woody often do not look at archived bugs when
reporting bugs on a package. Therefore it is likely that bugs that have
long been fixed in unstable, but will never be in woody will be reported
multiple times again.
I have
Andreas Metzler wrote:
Frank Kuster wrote:
users working with Debian woody often do not look at archived bugs when
reporting bugs on a package. Therefore it is likely that bugs that have
long been fixed in unstable, but will never be in woody will be reported
multiple times again.
I have
Brian Nelson wrote:
Would it be somehow possible to change the default behavior?
[of debuild to be debuild -uc -us]
Uh, have you filed a wishlist bug?
Good idea! Just did that. Bug#194678
Bob
pgpfOUP2e7fXk.pgp
Description: PGP signature
Colin Watson wrote:
I actually don't see how dpkg-buildpackage's
sign-immediately-after-build defaults ever make sense (except when
dpkg-buildpackage was originally written, when debsign didn't yet
exist). Why would you want to waste time signing a package you haven't
tested yet? Surely the
Matthew Palmer wrote:
Out of interest, are there any MUAs which have a separate reply to list
function?
KDE's 'kmail' for those into GUIs to read text. But you have to
configure the list address on a per folder basis.
Bob
pgpKg8pXDLrj4.pgp
Description: PGP signature
Tony Maro wrote:
Why do I feel like I opened a can of worms?
It is that squirmy feeling in the gut. Like just before the alien
claws its way out.
Bob
pgpClP4tDDzjT.pgp
Description: PGP signature
The released version of Debian is 'stable. Why are bug reports closed
against 'sid'? Shouldn't bug reports be closed only in released
versions of Debian? What am I missing? Requesting education.
http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-handling
5.8.4 When
The released version of Debian is 'stable. Why are bug reports closed
against 'sid'? Shouldn't bug reports be closed only in released
versions of Debian? What am I missing? Requesting education.
http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-handling
5.8.4 When
Neil L. Roeth wrote:
Examining the buildd logs showed it tried to run automake to build
[...]
But, *why* did this happen? I had created Makefile.in in the source
tree after aclocal.m4, so it was a *newer* file there and did not
trigger a call to automake on my build machine.
You asked the
Neil L. Roeth wrote:
Examining the buildd logs showed it tried to run automake to build
[...]
But, *why* did this happen? I had created Makefile.in in the source
tree after aclocal.m4, so it was a *newer* file there and did not
trigger a call to automake on my build machine.
You asked the
Bastian Kleineidam wrote:
On Fri, Feb 28, 2003 at 08:19:51PM +0100, Henning Moll wrote:
In addition i have some questions to the Depends section in
debian/control: ${shlibs:Depends} is a nice feature, but i think
for many packages/libraries it is way to strict, because it's
always using
Bastian Kleineidam wrote:
On Fri, Feb 28, 2003 at 08:19:51PM +0100, Henning Moll wrote:
In addition i have some questions to the Depends section in
debian/control: ${shlibs:Depends} is a nice feature, but i think
for many packages/libraries it is way to strict, because it's
always using
Aaron Haviland wrote:
Bob Proulx cursed the gypsies with this chant:
Bug 179614! It appears to me that this is a similar but not quite
identical problem. In that bug the packages were all real packages
and none of them were virtual. I could not deduce that any of them
were virtual. So
Aaron Haviland wrote:
Bob Proulx cursed the gypsies with this chant:
Bug 179614! It appears to me that this is a similar but not quite
identical problem. In that bug the packages were all real packages
and none of them were virtual. I could not deduce that any of them
were virtual. So
Matt Zimmerman wrote:
Why does it think rsh-client is a virtual package?
It is a mixed virtual package. There is a real package rsh-client, but also
several other packages provide rsh-client (apt-cache showpkg rsh-client).
Aha! Interesting. Since I *knew* that rsh-client was a real
Matt Zimmerman wrote:
Why does it think rsh-client is a virtual package?
It is a mixed virtual package. There is a real package rsh-client, but also
several other packages provide rsh-client (apt-cache showpkg rsh-client).
Aha! Interesting. Since I *knew* that rsh-client was a real
Colin Watson wrote:
It's a false positive, yes. Please file it as a bug against lintian
(also compare #179614).
Bug 179614! It appears to me that this is a similar but not quite
identical problem. In that bug the packages were all real packages
and none of them were virtual. I could not
I am unable to determine why I am getting this message from lintian.
Help?
My control file seems normal to me with this header. I am attempting
to build a meta package that contains nothing but depends so that I
can pull in various packages easily by installing my metapackage.
I have reduced
I am unable to determine why I am getting this message from lintian.
Help?
My control file seems normal to me with this header. I am attempting
to build a meta package that contains nothing but depends so that I
can pull in various packages easily by installing my metapackage.
I have reduced
Chad Miller wrote:
On Sun, Jan 26, 2003 at 09:12:21AM +0100, Szilveszter Farkas wrote:
i would like to create a package which needs a system user and a group
to be added. which uid/gid shall i use? leave it over 1000 (default),
or should i set it under 1000?
There's policy already set up
Chad Miller wrote:
On Sun, Jan 26, 2003 at 09:12:21AM +0100, Szilveszter Farkas wrote:
i would like to create a package which needs a system user and a group
to be added. which uid/gid shall i use? leave it over 1000 (default),
or should i set it under 1000?
There's policy already set up
Andrew Stribblehill [EMAIL PROTECTED] [2002-11-08 15:49:27 +]:
I can see a number of ways out of it, but have no clear idea which is
best:
* Split the package into its component parts, such that each daemon
is in a separate package. Have an init script for each. The admin
chooses
Andrew Stribblehill [EMAIL PROTECTED] [2002-11-08 15:49:27 +]:
I can see a number of ways out of it, but have no clear idea which is
best:
* Split the package into its component parts, such that each daemon
is in a separate package. Have an init script for each. The admin
chooses
Drew Parsons [EMAIL PROTECTED] [2002-10-14 00:41:49 +1000]:
OK, I'll try to remember to restrip for sarge :)
Perhaps the BTS could be a help in remembering this?
Bob
msg07487/pgp0.pgp
Description: PGP signature
Drew Parsons [EMAIL PROTECTED] [2002-10-14 00:41:49 +1000]:
OK, I'll try to remember to restrip for sarge :)
Perhaps the BTS could be a help in remembering this?
Bob
pgpoGeZUVTmOR.pgp
Description: PGP signature
Jay Graves [EMAIL PROTECTED] [2002-10-10 16:39:18 -0600]:
debian/rules should have something like this:
make install DESTDIR=$(CURDIR)/debian/tmp
well my debian rules looks like this
./configure (lots of stuff here) --datadir=/etc/X11
This implies that the application is using data itself
Jay Graves [EMAIL PROTECTED] [2002-10-10 16:39:18 -0600]:
debian/rules should have something like this:
make install DESTDIR=$(CURDIR)/debian/tmp
well my debian rules looks like this
./configure (lots of stuff here) --datadir=/etc/X11
This implies that the application is using data itself
Devin Carraway [EMAIL PROTECTED] [2002-09-22 01:35:32 -0700]:
I'm working on a package containing several executables, whose common
functionality lives in a few shared libraries. They're linked in the
usual way at compile time. Policy says they should live in
/usr/lib/packagename/, but I
Devin Carraway [EMAIL PROTECTED] [2002-09-22 01:35:32 -0700]:
BTW, I wanted to also say...
I know of three ways to deal with this one -- add a new path to
ld.so.conf (yuck),
Blech! Very yucky taste in mouth. ;-)
link with -rpath, or wrap the apps in a script which alters
Junichi Uekawa [EMAIL PROTECTED] [2002-09-22 20:54:19 +0900]:
What would be the point of restricting the shared libraries to
within the software ?
The traditional argument is usually that shared libraries save disk
space. If your have a large amount of code that is completely shared
between N
Devin Carraway [EMAIL PROTECTED] [2002-09-22 01:35:32 -0700]:
I'm working on a package containing several executables, whose common
functionality lives in a few shared libraries. They're linked in the
usual way at compile time. Policy says they should live in
/usr/lib/packagename/, but I
Devin Carraway [EMAIL PROTECTED] [2002-09-22 01:35:32 -0700]:
BTW, I wanted to also say...
I know of three ways to deal with this one -- add a new path to
ld.so.conf (yuck),
Blech! Very yucky taste in mouth. ;-)
link with -rpath, or wrap the apps in a script which alters
Junichi Uekawa [EMAIL PROTECTED] [2002-09-22 20:54:19 +0900]:
What would be the point of restricting the shared libraries to
within the software ?
The traditional argument is usually that shared libraries save disk
space. If your have a large amount of code that is completely shared
between N
Marco Presi [EMAIL PROTECTED] [2002-09-08 22:45:23 +0200]:
I am packaging a multiple binary from a single sources. The two
binaries provides the same server functionality and differs just for
compilation options, let's say:
server and server-enhanced.
Are they overlapping packages,
Marco Presi [EMAIL PROTECTED] [2002-09-08 22:45:23 +0200]:
I am packaging a multiple binary from a single sources. The two
binaries provides the same server functionality and differs just for
compilation options, let's say:
server and server-enhanced.
Are they overlapping packages,
95 matches
Mail list logo
