date:20130327

Re: [yocto] Samba server?

2013-03-27 Thread Paul D. DeRocco

A couple weeks ago, several people here were kind enough to help me through
the process of adding the OpenEmbedded layer called
meta-openembedded/meta-oe to my core-image-base-cedartrail-nopvr build,
which I wanted because it contains Samba. I eventually got it to build
without errors. But still no Samba.

The log file shows that the layer.conf file for that layer is being read,
and there is indeed some recipes for Samba. The bitbake -s option lists
samba as one of the packages. But the logs only show a few of recipes being
processed from this layer, none having to do with Samba. I was under the
impression that adding a layer added the recipes in the layer, and caused
them to be built. Apparently not. What am I missing?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Samba server?

2013-03-27 Thread Anders Darander

* Paul D. DeRocco pdero...@ix.netcom.com [130327 09:09]:
 The log file shows that the layer.conf file for that layer is being read,
 and there is indeed some recipes for Samba. The bitbake -s option lists
 samba as one of the packages. But the logs only show a few of recipes being
 processed from this layer, none having to do with Samba. I was under the
 impression that adding a layer added the recipes in the layer, and caused
 them to be built. Apparently not. What am I missing?

Maybe a dumb question...

Have you added samba to the image that you're building?
Just adding a layer won't cause the added recipes to be built and
deployed.

If you have added samba to the image, could you share the image recipe
and build logs?
Can you build samba manually? (Calling bitbake samba, (though I don't
know if that's the correct name, as I haven't check the meta-oe-layer
for that)).

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [poky] Yocto Project 1.5 Planning

2013-03-27 Thread Burton, Ross

On 26 March 2013 20:04, Trevor Woerner twoer...@gmail.com wrote:
 On Tue, Mar 26, 2013 at 2:37 PM, Burton, Ross ross.bur...@intel.com wrote:
 Danni would be a terrible name

 Of course it would be a terrible name, that's why I suggested it; I
 figured it'd fit in with the others :-D

 (don't forget my earlier statement about this being done in jest)

I think the other names are good as far as codenames go, but then
again I made numerous releases of a CD ripper using a lyric from
whatever song I was listening to at the time as the codename...

I agree that an alphabetical sequence as Ubuntu has popularised would
be convenient, but that would go against the unwritten rules of
Richard changing theme then people start guessing and deciding the
codename at the last minute. :)

Ross
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building restricted source code

2013-03-27 Thread Jerrod Peach

Mark,

Option 1 isn't a very big concern since it's likely only developers working
on the restricted code will cause its hashes to permute.

Option 2 is precisely what we were thinking about doing. The concern,
though, is what happens when a developer who doesn't have access to the
code changes a dependency of the restricted code in such a way that it
actually affects the restricted code. That developer is unable to test the
effects of his changes without pushing them to a back-end build, which
would involve pushing untested changes somewhere. I don't love that
thought.

Another option would be to make the recipe smart enough to build restricted
source on a different machine from the user's using an SDK (which is what I
think you were suggesting), but that involves transferring the user's
uncommitted code and/or built objects to the separate machine, adding a
fairly significant layer of complexity (and likely a significant amount of
time) to what is otherwise a relatively straightforward build process.

I'm not the biggest fan of any of these options presently, but if we have
to choose one of these routes, we will. (We were likely going to use what
you presented as your second option, but that's still going to involve
someone updating recipes for restricted source every time new binaries
become available.) I do very much appreciate the input and I'm glad to
know the ideas we came up with aren't completely crazy, since someone else
has thought of them too ;-) Any other thoughts on this issue?

Kind regards,

Jerrod

On Tue, Mar 26, 2013 at 3:21 PM, Mark Hatle mark.ha...@windriver.comwrote:

On 3/26/13 7:53 AM, Jerrod Peach wrote:

As part of my company's firmware builds, we have to build some code that
only a
handful of developers are allowed to view. We call this restricted
source code.
Getting our official system builds to build this code isn't a
problem. What
is a problem is a regular developer's build of this code.

Imagine this scenario: The restricted source depends upon eglibc. Our
low-level
team, who doesn't have access to the restricted source, updates the
recipe for
eglibc. The hash for the restricted package is permuted, and so they
can't get
an sstate hit and are required to rebuild the source. But, since they
can't
check out the source, they can't build it. This would cause a build
failure.

Is anyone dealing with this scenario while using Yocto currently? If so,
how?
I know it may be unlikely that many people are hitting this since Yocto
is
primarily used to build open-source code, but I thought I'd take a shot
in the
dark and hope for the best. :-)

Two ways I know of doing this. Slightly different way of doing things:

1) If the code does -not- rely on outside influences, such as eglibc.
Configure the recipe and pretty much ignore everything else with a
vardepsexp. Then ship the sstate-cache files that cover the compiled code.
(Along with the original recipe...)

2) For code that DOES rely on outside influences.. create a custom recipe
that either downloads the source and builds it [if the user has access to
the source], or will pull the binaries from a specific location and simply
install/package them. This is actually the more common approach.

(To seed that location, you can extract the items from your restricted
build -- or build it outside the tree using an SDK or similar.)

--Mark

__**_
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building restricted source code

2013-03-27 Thread Samuel Stirtzel

While this may not resolve your problem, these are my 0.2 cents.

I assume you already know this:
The hash does not need to be permuted between dependency updates, as
(e.g.) eglibc promises ABI and API stability between major releases
(like most Linux libraries).
This means that the hash has to change _only_  if the major version of
the dependency changes (you need to recompile your restricted code
anyway in this case), or if the configuration of the dependency
changes in an incompatible way (ouch!).
Of course this is only true for library dependencies.

I am not sure if it is possible to just configure the hashing
algorithm of bitbake to consider only ABI / API breakage instead of
always rehashing every change recursively.
Some other thoughts: It may be possible to inject packages during the
build via binary package feed...

Both ideas would require expanding the bitbake code though.

2013/3/27 Jerrod Peach pea...@lexmark.com:
 Mark,

 Option 1 isn't a very big concern since it's likely only developers working
 on the restricted code will cause its hashes to permute.

 Option 2 is precisely what we were thinking about doing.  The concern,
 though, is what happens when a developer who doesn't have access to the code
 changes a dependency of the restricted code in such a way that it actually
 affects the restricted code.  That developer is unable to test the effects
 of his changes without pushing them to a back-end build, which would involve
 pushing untested changes somewhere.  I don't love that thought.

 Another option would be to make the recipe smart enough to build restricted
 source on a different machine from the user's using an SDK (which is what I
 think you were suggesting), but that involves transferring the user's
 uncommitted code and/or built objects to the separate machine, adding a
 fairly significant layer of complexity (and likely a significant amount of
 time) to what is otherwise a relatively straightforward build process.

 I'm not the biggest fan of any of these options presently, but if we have to
 choose one of these routes, we will.  (We were likely going to use what you
 presented as your second option, but that's still going to involve someone
 updating recipes for restricted source every time new binaries become
 available.)  I do very much appreciate the input and I'm glad to know the
 ideas we came up with aren't completely crazy, since someone else has
 thought of them too ;-)  Any other thoughts on this issue?

 Kind regards,

 Jerrod


 On Tue, Mar 26, 2013 at 3:21 PM, Mark Hatle mark.ha...@windriver.com
 wrote:

 On 3/26/13 7:53 AM, Jerrod Peach wrote:

 As part of my company's firmware builds, we have to build some code that
 only a
 handful of developers are allowed to view.  We call this restricted
 source code.
   Getting our official system builds to build this code isn't a
 problem.  What
 is a problem is a regular developer's build of this code.

 Imagine this scenario: The restricted source depends upon eglibc.  Our
 low-level
 team, who doesn't have access to the restricted source, updates the
 recipe for
 eglibc.  The hash for the restricted package is permuted, and so they
 can't get
 an sstate hit and are required to rebuild the source.  But, since they
 can't
 check out the source, they can't build it.  This would cause a build
 failure.

 Is anyone dealing with this scenario while using Yocto currently?  If so,
 how?
   I know it may be unlikely that many people are hitting this since Yocto
 is
 primarily used to build open-source code, but I thought I'd take a shot
 in the
 dark and hope for the best.  :-)


 Two ways I know of doing this.  Slightly different way of doing things:

 1) If the code does -not- rely on outside influences, such as eglibc.
 Configure the recipe and pretty much ignore everything else with a
 vardepsexp.  Then ship the sstate-cache files that cover the compiled code.
 (Along with the original recipe...)

 2) For code that DOES rely on outside influences.. create a custom recipe
 that either downloads the source and builds it [if the user has access to
 the source], or will pull the binaries from a specific location and simply
 install/package them.   This is actually the more common approach.

 (To seed that location, you can extract the items from your restricted
 build -- or build it outside the tree using an SDK or similar.)

 --Mark

 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto


 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto



 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto




-- 
Regards
Samuel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH v2] [eclipse-poky][master]Add more comprehensive error message for invalid project name

2013-03-27 Thread Grigoropol, IoanaX

Hi Jessica,

What is the issue that Time found you are referring to ?

Regarding the way you found to allow creating projects with invalid names, this 
comes from the org.eclipse.cdt.core.templates, and in my opinion is a bug. 
What happens is that the template arguments, in our case the project name, is 
resolved the first time we press finish, with the invalid name we have set. 
When we receive an error and choose to go back, and change the project name to 
yet a new invalid project name, the argument of the template(project name), is 
not updated(for some sort of cache reasons) and thus by using the old project 
name, it surpasses the exception received in the first case.
I will open a bug for this on the cdt bugzilla.

Thanks,
Ioana


From: Zhang, Jessica
Sent: Friday, March 15, 2013 2:06 AM
To: Grigoropol, IoanaX; yocto@yoctoproject.org
Subject: RE: [yocto] [PATCH v2] [eclipse-poky][master]Add more comprehensive
error message for invalid project name

Hi Ioana,

This patch still can't address the situation that found by Timo as following

Thanks,
Jessica

I forgot to mention. I found a way to create projects with invalid names.

# Create a new Yocto C Project
# Enter a wrong name eg. Test
# Press next
# Press finish
# -- Error Message is shown, press ok
# Press back
# Change the name to an also invalid name eg. Test$ # Click finish

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Ioana Grigoropol
Sent: Thursday, March 14, 2013 4:50 AM
To: yocto@yoctoproject.org
Subject: [yocto] [PATCH v2] [eclipse-poky][master]Add more comprehensive error 
message for invalid project name

[Yocto #4008]

Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
---
 .../org/yocto/sdk/ide/YoctoSDKMessages.properties  |1 +
 .../sdk/ide/wizard/NewYoctoCProjectTemplate.java   |   27 
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKMessages.properties 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKMessages.properties
index 8596123..fc9813f 100644
--- 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKMessages.properties
+++ b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKMessages.p
+++ roperties
@@ -10,6 +10,7 @@
  * BMW Car IT - added keys for target profiles
  
***/
 Wizard.SDK.Warning.Title = Invalid Yocto Project ADT Location
+Wizard.SDK.Error.ProjecName = Project name {0} is invalid! \nNone of
+these characters are accepted inside project names: whitespaces, {1}

 Poky.SDK.Location.Empty = Specified Toolchain Root Location is empty.
 Poky.SDK.Location.Empty.Advice = You need specify Toolchain Root Location 
before building any project.
diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoCProjectTemplate.java
 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoCProjectTemplate.java
index 5ffd6b7..4d1684a 100644
--- 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoCProjectTemplate.java
+++ b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoCPr
+++ ojectTemplate.java
@@ -10,8 +10,11 @@
  
***/
 package org.yocto.sdk.ide.wizard;

+import java.util.Arrays;
 import java.util.LinkedHashMap;
 import java.util.List;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;

 import org.eclipse.cdt.autotools.core.AutotoolsNewProjectNature;
 import org.eclipse.cdt.core.CCorePlugin; @@ -46,11 +49,12 @@ import 
org.yocto.sdk.ide.YoctoProfileElement;
 import org.yocto.sdk.ide.YoctoSDKChecker;
 import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckRequestFrom;
 import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckResults;
+import org.yocto.sdk.ide.YoctoSDKMessages;
+import org.yocto.sdk.ide.YoctoSDKPlugin; import
+org.yocto.sdk.ide.YoctoUIElement;
 import org.yocto.sdk.ide.natures.YoctoSDKEmptyProjectNature;
 import org.yocto.sdk.ide.natures.YoctoSDKProjectNature;
 import org.yocto.sdk.ide.utils.YoctoSDKUtils;
-import org.yocto.sdk.ide.YoctoSDKPlugin; -import 
org.yocto.sdk.ide.YoctoUIElement;


 @SuppressWarnings(restriction)
@@ -58,11 +62,19 @@ public class NewYoctoCProjectTemplate extends ProcessRunner 
{
protected boolean savedAutoBuildingValue;
protected ProjectCreatedActions pca;
protected IManagedBuildInfo info;
+   protected ListCharacter illegalChars = Arrays.asList('$', 
'','#','%','','\'','(',')','*', '+', 
',','.','/',':',';','','=','','?','@','[','\\',']','^','`','{','|','}','~');
+   private static final String PROJECT_NAME_ERROR =
+Wizard.SDK.Error.ProjecName;

public NewYoctoCProjectTemplate() {
pca = new ProjectCreatedActions();
}
-
+   private String printIllegalChars(){
+

[yocto] software updates on Yocto based systems with limited connectivity

2013-03-27 Thread Andrea Galbusera

Hi all,

I've recently been faced the need to support an upgrade path for a system
designed with Yocto. The format for packages is currently ipk.

While the system was under development, I was heavily relying on package
feeds and opkg update/upgrade based upgrades. However, once deployed, this
device will have very limited to no connection to the network. Having the
upgrades deployed by an http feed seems to be a no-option here. Also, every
update should be better delivered in a single file for convenience.

My first approach to the problem, which I'm currently experimenting with,
is to find a suitable way to deliver onto the device whatever is required
to keep going with the opkg update/upgrade logic.
Basically, I'm trying to give the device a filesystem based feed. This can
be deployed as a self-extracting script whose main purpose is to deliver
the usual feed content and to provide a shell script running the usual opkg
update/upgrade recipe. Such an approach would meet the requirement of
delivering a single file, i.e. by uploading it to the system's web
interface.

Now, the most challenging issue I see in moving this solution from an
experimental to a real-world one is that upgrades should be as small as
possible for the sake of efficiency. This will probably involve generating
some sort of differential package feed, say between two know hashes of
the system project's metadata. This would allow to only deliver the
required packages: basically those that need to be upgraded, any possibly
changed dependency and, maybe, any additional package that might be
required to instal during the update.

Here comes the question. Is there any effort for solving this or similar
issues, which I guess are not so uncommon in production environments with
limited connectivity? Since I'm not aware of any, I might be completely out
of luck with the described approach.

If you have any experience to share in delivering in-field updates, I'd be
very pleased to learn from your comments or suggestions.

Regards,
Andrea
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Samba server?

2013-03-27 Thread Paul D. DeRocco

 From: Anders Darander
 
 Maybe a dumb question...
 
 Have you added samba to the image that you're building?
 Just adding a layer won't cause the added recipes to be built and
 deployed.

It's not a dumb question. No, I haven't added samba to the image that I'm
building. I've read the Yocto Project Reference Manual (except certain
sections that are obviously irrelevant to a user), and the wretched Bitbake
manual, and I don't see any mention of doing anything other than adding
layers to bblayers.conf and tweaking local.conf.

I'm under the impression that, unless one is making metadata changes that
will ultimately be contributed back to the community, one treats the
poky-danny-8.0 tree as essentially readonly, and limits ones adjustments to
perhaps adding more metadata (as I've done by downloading
meta-openembedded), and editing bblayers.conf (as I've done by adding the
meta-openembedded/meta-oe layer) and a few settings in local.conf.

I don't see anything in those files that causes anything to be added to the
image other than the mentioning of various layers in bblayers.conf. Yet it
still manages to build a substantial system containing lots of stuff from
poky-danny-8.0, but only a few things from meta-openembedded/meta-oe, and
that doesn't include samba.

So where in the documentation does it explain this? If, as I suspect, the
answer is nowhere, then somebody's going to have to hold my hand and tell
me how to add samba to the image that I'm building, because I have no idea
how to do that.

Pardon my exasperation. I really do appreciate the help people have given me
here. I just wish it was possible to deduce this stuff by reading a decent
manual.

And if anyone who is part of the Yocto development team is looking for bugs
to fix, they should consider regarding the state of the documentation as a
great big fat bug, and maybe devote 10% of the time to fixing that.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Samba server?

2013-03-27 Thread Paul D. DeRocco

 From: ChenQi
 
 http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html
 section 5.2 Customizing Images
 
 In your case, you could add the following line to local.conf.
 IMAGE_INSTALL_append += samba
 
 And you can use 'bitbake -g image_recipe_name' to see 
 whether samba is pulled in.
 
 For all docs, see https://www.yoctoproject.org/documentation/current.

Thanks for that pointer. I'll try that out.

So is there a general way to peruse the collection of recipes? Does one have
to do ls -R *.bb to get the list of recipes, then read the comments inside
the files to see how to use them?

And how does one know in advance which ones get included by default? Is
there some construct one looks for in the .bb file that indicates it gets
included? Or is there some master recipe that says this depends upon this
big long list of standard recipes?

And are any of the recipes that are included by default not actually
required, and if so, how do you un-include them if you want to pare down the
system to a bare minimum?

Or is there some master documentation that I just haven't found that lists
all the recipes in the Yocto project and gives some guidance on their use?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Samba server?

2013-03-27 Thread ChenQi


On 03/28/2013 11:10 AM, Paul D. DeRocco wrote:

From: ChenQi

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html
section 5.2 Customizing Images

In your case, you could add the following line to local.conf.
IMAGE_INSTALL_append += samba

And you can use 'bitbake -g image_recipe_name' to see
whether samba is pulled in.

For all docs, see https://www.yoctoproject.org/documentation/current.

Thanks for that pointer. I'll try that out.

So is there a general way to peruse the collection of recipes? Does one have
to do ls -R *.bb to get the list of recipes, then read the comments inside
the files to see how to use them?

And how does one know in advance which ones get included by default? Is
there some construct one looks for in the .bb file that indicates it gets
included? Or is there some master recipe that says this depends upon this
big long list of standard recipes?

And are any of the recipes that are included by default not actually
required, and if so, how do you un-include them if you want to pare down the
system to a bare minimum?

Or is there some master documentation that I just haven't found that lists
all the recipes in the Yocto project and gives some guidance on their use?


http://docs.openembedded.org/bitbake/html/
http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html
The above two manuals might be sufficient for understanding the recipes 
and performing common tasks.


//Chen Qi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Samba server?

2013-03-27 Thread Anders Darander

* Paul D. DeRocco pdero...@ix.netcom.com [130328 04:11]:
  From: ChenQi

  http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html
  section 5.2 Customizing Images

  In your case, you could add the following line to local.conf.
  IMAGE_INSTALL_append += samba

  And you can use 'bitbake -g image_recipe_name' to see 
  whether samba is pulled in.

  For all docs, see https://www.yoctoproject.org/documentation/current.

 Thanks for that pointer. I'll try that out.

Chen Qi has already given you pointers to the documentation. Though,
I'll just add a few remarks that hopefully will kickstart your
understadning when reading the docs.

 So is there a general way to peruse the collection of recipes? Does one have
 to do ls -R *.bb to get the list of recipes, then read the comments inside
 the files to see how to use them?

No, the recipes themselves do not enforce their own inclusions into your
image. (That wouldn't really make sense, especially not when including
such a large layer as meta-oe).

 And how does one know in advance which ones get included by default? Is
 there some construct one looks for in the .bb file that indicates it gets
 included? Or is there some master recipe that says this depends upon this
 big long list of standard recipes?

Which image are you building? 

Say that you're building core-image-sato, then you'll have to look at
that recipe meta/recipes-sato/images/core-image-sato.bb. 

There you might find IMAGE_INSTALL, which defines what packages (and
package groupds) this recipe wants to install. 

The recipes can also define IMAGE_FEATURES, which are used by the
core-image.bbclass (which is inherited in the .bb-file), to add a number
of packages.

 And are any of the recipes that are included by default not actually
 required, and if so, how do you un-include them if you want to pare down the
 system to a bare minimum?

Sure, there's likely some stuff in most images that you're not
interested in. All the supplied images are there for some use-case, be
it demoing stuff, test, etc.

If you want to customize an image more, I'd recommend you to create your
own image. A first step might be to just copy one of the image recipes
to a layer of your own, and then modify it according to your taste.

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Samba server?

Re: [yocto] Samba server?

Re: [yocto] [poky] Yocto Project 1.5 Planning

Re: [yocto] Building restricted source code

Re: [yocto] Building restricted source code

Re: [yocto] [PATCH v2] [eclipse-poky][master]Add more comprehensive error message for invalid project name

[yocto] software updates on Yocto based systems with limited connectivity

Re: [yocto] Samba server?

Re: [yocto] Samba server?

Re: [yocto] Samba server?

Re: [yocto] Samba server?

11 matches

Site Navigation

Mail list logo

Footer information