Warren Young:
> I’d then like to see /login change to something more generic like
> /user. If someone depends on the existing name as an API, a /login
> alias could be added, either in code or via the existing URL aliasing
> feature.
It's possible (and very convenient) to have a direct logout
It seems like the intention of the following call to cgi_set_cookie()
is to generate a cookie to expire immediately, and direct the browser
to remove it (at least this could make sense for login cookies):
http://fossil-scm.org/index.html/artifact?name=4e7cdb5c6a=354-355
But in this case,
Warren Young:
> You can open a file called NUL on Windows to get the same effect as
> /dev/null on POSIX type platforms.
A very interesting topic!
NULL
(void*)0, or nullptr (was used in a confusing manner, in my post)
\Device\Null
Windows NT (object manager) equivalent to /dev/null
Richard Hipp:
> Please test the latest trunk version and let me know if you are still
> seeing issues.
Thank you very much for the fix!
I see no more delays with "fossil ui" on Windows.
Just a thought: would it make sense to have --nodelay as a global
option recognized by all commands, and
Richard Hipp:
> Hence, if the subprocess gets involves in backoffice work, that can
> delay the return of content to the user.
> The only comes up on Windows. I do not yet have a good work-around.
I see, thank you very much for the detailed explanations.
I only have the obvious (inefficient?)
> ... writing to a FILE* pointing to NULL may have exactly the same
> effect as writing to a FILE* pointing to "/dev/null"?
Well, unless there's a directory named "dev" in the root of the
current drive, which would result in creation (due to the passed "wb"
mode) of a file named "null", on
Thank very much for your feedback!
Warren Young:
> Which is it?
With the random appearance of the delay, and the long duration of 60
seconds, I eventually gave up on "bisecting".
But with a more systematic approach, I've now got:
Last good: [06507038]
First bad: [947081aa]
> If the problem
I've noticed something with the current tip version of Fossil (on Windows):
I see random delays for the `fossil ui' command, i.e. the web browser
is opened at once, but is displaying the loading/busy indicator and a
blank page for some time, before the default web page finally appears:
Richard Hipp:
> I think this problem has been addressed in a more general way
> on the latest trunk. Please let me know if you find otherwise.
This works fine (tested only on Windows, so far), thank you very much!
--Florian
___
fossil-users mailing
> There's been some changes to fossil_exit() in the meantime, I'll check
> these, and report back here.
I was wrong, the changes were to fossil_fatal() and fossil_panic(),
and not to fossil_exit(). The current tip version of Fossil still
exhibits the behavior summarized here:
Warren Young:
> Quantify “a lot.”
I have some rarely committed-to but frequently web-accessed
repositories (with login), and I see daily backups of the modified
repository database, even though I'm sure I haven't committed
anything. It's like "hey, what's going on there with my babies?"
Just one more thought:
Copying database files (vs. cloning) also includes any hand-made meta
changes, for example I remember adjusting the page size and journal
mode for older repositories, when the defaults for new Fossil
repositories were changed.
Of course `fossil rebuild --wal' after the
Richard Hipp:
> ... create your backups by cloning and syncing ...
Thank you for your comments.
I see, this completely makes sense.
The process of "restoring" a repository from backup would include
copying database files, as syncing from backup → original might not
work if something's gone
Stephan Beal:
> .. i'm not sure that i like it enough to justify the idea of
> maintaining two files where one file is sufficient.
The current implementation uses one single cookie database shared for
all repositories in the same directory, which can be excluded from
backups, and deleted (or,
As much as I like the simplicity of keeping the full repository
history in one single SQLite database, I see a minor downside.
There's a lot of backup traffic, if "non-contents changes" (such as
the admin and user logs, the login cookies, but also the "PRAGMA
optimize" information) are causing
David Mason:
> Fossil appears to be careful with memory allocation too, with very few
> raw calls to malloc, so memory allocations can be unwound.
SQLite has the "Zero-malloc" and "Application-supplied memory
allocators" options [0], which may be helpful for cases without proper
db engine
Richard Hipp:
> It is reassuring to know that so many people routinely build Fossil
> from the trunk sources :-)
À propos build:
I have accidentally set FOSSIL_ENABLE_MINIZ=1 (in win/Makefile.msc),
and this doesn't seem to work, probably because src/shell.c includes
zlib.h without examining
Richard Hipp:
> (5) The server accepts the bundle and parks it in a separate holding
> table, but does not merge it or otherwise make it available to average
> passers by. The server then sends email notifications to developers
> with appropriate privileges to let them know that a pull request
Another issue with bundles: "push requests" derived from local private branches.
It may be not only the receiver of a "push request" to decide to
import only the final "accumulated patch", without all the detailed
"commit-by-commit" history.
It may also be the submitter to decide to keep the
More thoughts:
> fossil merge --bundle BUNDLE ?--cherrypick|--backout CHECK-IN?
* BUNDLE could be a disk file, or something like "bundle:ID" to refer
to a bundle submitted via "push request", and queued in a separate
repository db table.
* If the current check-out is different from the root of
Eduard:
> I have opened registration on Hydra. Feel free to try it out at
> [ https://hydra.ecd.space/ ], and give me your feedback.
Roy Keene:
> Is ChiselApp not serious enough for you ?
(Quotes unconnected.)
I think both ChiselApp and Hydra are very nice, and technically solid
projects (and
> Let me decide whether the bundle is committed "step-by-step"
> ... or "all-at-once" ...
I think this is what I'm looking for:
fossil merge --bundle BUNDLE ?--cherrypick|--backout CHECK-IN?
> But I would like to have some more flexibility and control when
> "applying" (or importing) bundles by
Fossil bundles are a great feature, and may be useful to implement
pull (or "push") requests.
But I would like to have some more flexibility and control when
"applying" (or importing) bundles by third parties:
* Let me decide where the bundle is committed, be it directly on trunk
instead of on a
Andy Goth:
> In my test case, the outbound arrows are white, which doesn't look
> so great against the default white background.
The timeline arrow color generated from background color #00aa00 was
not white, but #ffd6, which is an invalid HTML/CSS color value,
and happened to be displayed
Stephan Beal:
> Try stripping the debug symbols:
> strip fossil
Thank you for the useful tip, now down to 3.6 MB!
My MSVC/WinSDK toolset doesn't provide the equivalent utilities any
more, as everything is controlled by compiler and linker flags -- and
obviously for a longer time than my
Though I'm aware that this is not something you may consider useful
for Fossil, I'm posting a minor update, for the sake of correctness:
(0) Wrong Statement
Me:
> I think that "Vary: Cookie" is intended to work with unconditional
> HTTP requests: the browser is directed to stick to the expiry
When building Fossil on a recent out-of-the-box FreeBSD (amd64)
virtual machine, the resulting binary file is about 10.1 MB. The
binary files downloaded form [0] are at most 3.8 MB.
[0] http://pkg.freebsd.org/
I have tried various ./configure options, FOSSIL_DYNAMIC_BUILD is
enabled (=1), and
As `wget -N' adds 1 second to the If-Modified-Since stamp derived from
existing local files (maybe due to different time stamp resolutions on
various file systems), I noticed that the If-Modified-Since stamp
checks seem to give "reversed" results.
The following test commands display the HTTP
For the File History web page, it looks like "Classic View" is the same as
"Modern View":
http://fossil-scm.org/index.html/finfo?name=VERSION=x
--Florian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
Now I see why the clever and elegant solution to use "Vary: Cookie", as
suggested by Joerg, does not fix /uv page expiration after login and
logout, and I can also explain the strange differences between the local
Fossil built-in web server, and my remote web server.
The local Fossil built-in web
Joerg:
> Such a proxy would be pretty broken. ... Again, such a client is
> pretty much broken already under the caching model. ...
I agree. Writing an HTTP server in a perfect world may be easy. But I feel
like a lot of programming work are efforts to make broken clients (or
"components") work?
Joerg:
> I don't think you need to reset it, just sending the vary header
> should be enough?
I was able to try this, and it works fine!
Adding the following line:
fprintf(g.httpOut, "Vary: Cookie\r\n");
right after printing the ETag header in src/cgi.c (and also after printing
the
D. Richard Hipp:
> The ETag values already reset based on changes to the display
> cookie. I suppose they could change again based on the login
> cookie. The question is, would this solve Florent's problem?
Yes, adding "user.cexpire" to the ETag ingredients [0] would solve part of
the problem:
> One possible solution may be to include the "cexpire" field in
> ETag calculation, drop the If-Modified-Since handler, but still
> return a Last-Modified date.
Well, it may be possible to support both caching mechanisms. But then an
ETag mismatch should result in a cache miss, and the
Sorry for my perseveration on the topic.
I'm using a /uv index page for my repositories. After login, the index page
is not expired, and I can only see the Admin entry from the top navigation
bar until after a "hard" reload with Ctrl+F5.
So I tried to to generate a "login-time-sensitive" ETag.
Ah, now I see. I was using a script to check-in a commit to a new (empty)
repository, with the commit time older than the initial check-in time. I
aborted the script on the clock skew warning, but found an empty /timewarps
log.
It's only timewarps originating from the initial check-in that are
I'm sorry then I didn't understand what are "timewarps", and there's none
in the Fossil repository (as I had mistakenly assumed).
--Florian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
Sorry for messing up the line-width for sample commands and scripts posted
to this mailing list.
I have noticed that the /timewarps web UI does not seem to work, any more.
Test case:
fossil init --admin-user florian test.fossil
fossil open test.fossil
fossil ci -m "Older check-in date"
I have now been able to reproduce the behavior on Windows, with a fake CGI
request for an /uv cache hit.
The following commands create a new test repository with an unversioned
file, a CGI control file, and set a few environment variables.
The commands can be run from a batch file, or by
I have now had access to a fully equipped FreeBSD machine, and was able to
do more investigation.
I found that the patch appended to this message fixes the problem with the
leftover SHM and WAL files. They are seen each time an unversioned file is
accessed over the /uv web interface, with an
Sorry for spamming the list, I try short.
Just another comment about Fossil's If-Modified-Since rules:
http://fossil-scm.org/index.html/artifact?name=535a623ccd=154-157
I learned a lot about If-Modified-Since when adding HTTP caching to my
home-brewed wiki. All kind of information was important
With further testing, I noticed that the If-Modified-Since cache control
mechanism does not seem to work for /uv web pages, anymore. This can be
seen by repeatedly downloading the Fossil Source Tarball using wget:
wget -N http://www.fossil-scm.org/index.html/uv/fossil-src-2.6.tar.gz
...
For
Warren Young:
> If “fossil server” or “fossil ui” is still running in the
> background, then I would fully expect the WAL and SHM files to
> still be around. The worrying case is when they’re left behind
> after the SQLite-based process that created them has died.
My observations were from CGI
With Fossil 2.6, there's a new "unencrypted connection" security warning in
the Login/Logout form, which also has a hyperlink to a secure login page.
In some web browsers, pressing TAB to move the input focus from "User ID"
to "Password" sets the focus to this hyperlink, instead of the next form
With Fossil 2.6, sometimes there's *.fossil-shm and *.fossil-wal files left
behind in the directory where the repository databases are stored.
This happens if an unversioned file is accessed through the /uv web
interface for the second time (or more). If the web interface to view an
unversioned
I'm sorry the batch script from my previous message did not make it through
the mailing list in a ready-to-copy-and-paste form, so it's posted here:
https://pastebin.com/8StRhDHJ
--Florian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
The "crlf-glob" setting allows files to have CR, CR+LF or mixed line
endings. The "--no-warnings" option for "fossil commit" works analogously
(and also affects warnings about binary files).
As a (mostly) Windows user, I would appreciate a way to silence warnings
for all files with *consistent*
I'm using direct SQL queries on Fossil repository databases to find file
blobs, similar to what Fossil itself uses to generate the /bloblist web
page:
http://fossil-scm.org/index.html/artifact?name=d99ecd15=837-847
With a list of file blobs, it's possible to find files from one repository
It's not at all that I think I'm the expert you've summoned in your
last post on this thread. As you've been running your own high-traffic
"althttpd" server for many years, maybe you should explain the
Internet to us.
I was doing some (limited) research about RFCs, recommendations from
the Apache
D. Richard Hipp:
> Consider this sequence of operations:
>
> (1) User A does a "uv push"
> (2) User B does a "wget -N" against the uv.
> (3) User C does a "uv push" of different content.
>
> If all of (1), (2), and (3) happen during the same second and if
> unversioned content honors the
Ron:
> Someone already made an ETag wrapper for wget:
> https://www.w3.org/2001/12/rubyrdf/pack/tests/scutter/wget.pl
Thanks for the interesting link.
> There is no requirement or specification for the value of an ETag,
> could use the Fossil artifact hash as the ETag value. Then a script
>
Thinking about HTTP caching twice, the following comes to my mind:
A command line download tool, that unlike a web browser does not keep
a cache of content and associated ETags, won't be able to calculate
the ETag for a file it is going to request from a Fossil web server.
ETags are not simple
> Is the new ETag mechanism sufficient for your purposes?
That's a great addition, thanks!
However, my simple scripting tools don't support ETags, i.e. the `wget
-N' example (latest version 1.19.4) mentioned earlier still carries
out two full downloads of the Fossil source code archive.
With
> That's because autofocus causes CSS flashes on some web-browsers.
> If you can suggest a reasonable workaround, that would be great.
Oh, I'm sorry I've missed that.
The only other way I know is by JavaScript, something like:
window.onload = function() {
document.getElementById("u").focus();
I've discovered a few minor issues after updating to Fossil 2.5. As I
have skipped version 2.4, I'm not sure when they were really
introduced. I'd appreciate if they could be considered to be fixed in
case there's some nearby work, say like an occasional appendectomy ;)
1. On the Login/Logout web
Chris:
> This makes fossil a first class scm citizen together with git and others ..
Depends on your point of view, you could also say that this makes Go a
first class citizen among programming languages ... ;-)
--Florian
___
fossil-users mailing list
Compared to version 2.3 [f7914bfdfa], current tip version 2.5
[8007cfc0db] no longer displays check-in background colors on the
/leaves web page.
As the /brlist web page has recently been enhanced with an option to
show branch colors, I think this minor regression for /leaves was not
intentional,
Olivier Mascia:
> But on XP the delay is 'intolerable' rather than unnoticeable. :)
>
> A small patch for that is included along a larger IPv4/IPv6 patch
> I submitted today.
>
> I see Richard put it on trunk (see [e506ebb764]) minutes ago.
>
> Especially those of you using Windows XP would help
Thomas Schnurrenberger:
> I measured the time it takes to call StartServiceCtrlDispatcherW
> on my 8 year old Windows 7 64bit box: roughly 600 microseconds, I
> don't think this is noticeable!
> It would be interesting to known time on your XP boxes.
Thanks for your interest and for the test
Thanks for the interesting details about IPv6 and Windows.
Richard Hipp:
> I'd appreciate it if some readers could try the two versions out,
> side by side, and give their opinions.
Focusing on Windows XP here, the version with [c038de8d] works fine
and navigates to the correct page for `fossil
Re: Fossil with IPv6 support on Windows XP
I have several physical and virtual XP machines around, and `fossil
ui' doesn't work any more with the new patch.
--Florian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
A submit button would make it more evident that the page can be
updated by hitting enter or pressing the submit button.
Relying on the JavaScript "onxxx" handlers to update the page works
inconsistently across web browsers.
Moreover, the page is updated each time an individual setting is
No, my patches were about intercepting the enter key from text input
elements to submit the form and update the view.
In my tests, I found that the "onchange" handler worked fine for
drop-down lists, so you may have detected a new problem.
--Florian
As the form has no "submit" element, it works differently in different
web browsers. I've sent a set of patches directly to Richard Hipp to
make use of the "onkeydown" ("onkeyup" in the initial version) instead
of the "onchange" handler for text input elements [0], as in some web
browsers, the
At the time of this writing, the "timeline-commit-format" option seems
"orphaned", i.e. it is only referenced by the /setup_timeline web page
to display the setting, but not queried or honored any more.
As the timeline web view mode defines the display format, I'd like to
suggest to change this
Following patch fixes the clash of the short forms of the --limit and
--dryrun options for the `fossil tag' command.
Another form than -N|--limit might be preferred to ensure a better
distinction from -n|--dryrun, such as -c|--limit or -l|limit.
--Florian
Index: src/tag.c
Following patch changes all --dryrun options to the more common form
--dry-run for all commands, but this would break working scripts!
--Florian
Index: src/tag.c
==
--- src/tag.c
+++ src/tag.c
@@ -282,11 +282,11 @@
}
/*
** OR
The following command fails:
$ fossil tag add -n --user-override username tagname checkin
But this one works as expected:
$ fossil tag add --dryrun --user-override username tagname checkin
That's because -n is the short form for both --limit and --dryrun:
Warren Young:
> Switch to Modern view? :)
Verbose View seems more comfortable to use for me, as the hashes are
more prominent, so easier to read, easier to click, entries as a whole
are easier to copy-paste (only one triple-click to select all, no
mouse move required), and also easier to read
Thanks for the instructions and demonstration.
Simple to do, I agree. A minor issue for me is that I have some tasks
where I copy-paste parts of the timeline view to another program, and
some web browsers do not copy the CSS parenthesis, making things
harder to read, again. Picking individual
Yes, Modern View and Columnar View already have a good demarcation due
to spatial distance, borders, and different styles.
--Florian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
Thanks for the recent timeline changes.
Most of my check-in comments do not end with a dot. In the timeline
web view, it used to look like this:
[xx] This is the check-in comment (user: username, tags: trunk)
For the current development version in Verbose View, it looks like this:
Andy Goth:
> Does anyone know a good way to create *.lnk files from Tcl?
There's an ancient SHORTCUT.EXE command line utility:
https://ss64.com/nt/shortcut.html
It even has an -s command line option to disable link tracking.
I don't have the original. A few clones can be found in the web, but
Warren Young:
> By that reckoning, I’d rank *.lnk above Cygwin symlinks in many
> regards. Why wouldn’t that work?
Handling Windows Shell Links (*.lnk) can be tricky:
There's built-in logic to resolve links to missing targets (called
"link tracking", can be disabled). That's why portability of
> To set-up aliases, visit the Setup/URL_Aliases page.
Thanks, that's a very handy feature!
Would you consider enabling "rewriting" of the default webpage URLs,
i.e. by searching the alias list prior to the dispatch table? This
could be controlled by a global setting (potential subtle user
Patch to patch: the mprintf() is redundant.
--
Index: src/cgi.c
==
--- src/cgi.c
+++ src/cgi.c
@@ -992,11 +992,11 @@
/* Apply default query parameters for the /timeline web page */
if( strlen(z)==0 ){
z =
Following is a patch (against 9e48dad49b) to add a new option to the
/setup_timeline web page to specify the default query parameters for
the /timeline web page, that works without modifications to the web UI
skins.
To keep it simple and avoid code duplication, the QUERY_STRING
variable is
Maybe not the best idea ☹ but I was taking notes about special
characters in batch files on a Fossil markdown/wiki page.
It's even worse than what you can imagine, it seems like batch file
syntax was designed to stress-test markdown parsers:
! " % & ( ) , ; ^ | < >
I enclosed each character
> Reparenting is for doing one-time major surgery operations on a Fossil
> repo, not for everyday use.
Thank you very much for your comments, and for your suggestions about
dealing with unwanted check-ins.
I take great care to keep my Fossil repositories intact, and no such
thing as a "reparent"
Thank you very much for your reply.
I have found two simple ways to plant a `default-homepage' tag on
unversioned wiki pages, so that the script to update the wiki pages
can just search for the tag in the output of `fossil uv cat':
1. ...
2. default-homepage
But according to the Fossil Wiki
I have a few scripts to maintain my repositories, and among other
things, they add (and update) multiple flavors of (unversioned) wiki
homepages (the remote homepages have more links, such as
login/logout/index, and the local ones show a reminder about syncing).
Some repositories have customized
Zakero:
> Did you check the execution time of the "find | sort" versus the
> "listfossil()"? Looking at your script, I think you can simplify it
> a bit.
The script takes between 1.2 and 1.8 seconds in the original form, and
between 130 and 160 ms if the `listfossil()' function is simplified to
On another server, where I have access to PHP, it also takes less than
100 ms to query the repository files using the built-in PDO/sqlite
interface.
So it seems that running ./sqlite3 instead of ./fossil could speed up
the queries.
--Florian
___
Thank you very much for the quick fix, it also works fine on my system.
--Florian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
I'm using a customized repository index page to display a link to each
repository, along with the project name and description queried
directly from the repository database files.
For 10-20 repositories, the following (skeleton) shell script takes
more than 1 second to finish:
#!/bin/sh
...
On Windows, the Fossil `--skin LABEL' command line option can't be
used to load a custom skin from a subdirectory, probably because only
skin labels containing forward slashes but not backslashes are treated
as paths to subdirectories containing the skin files:
Two other interesting cases, run from the standard console:
> fossil test-prompt-password PROMPT: 0 2>&1 | more
INPUT
PROMPT:[INPUT]
4. Password is visible while typing.
> echo PASSWORD | fossil test-prompt-password PROMPT: 0 2>&1 | more
PROMPT:[PASSWORD ]
5. As expected, _isatty()
I get the following results for the new `fossil test-prompt-password'
command, run in the standard CMD.EXE console on Windows, typing
"INPUT[ENTER]" on the keyboard if possible:
> echo PASSWORD | fossil test-prompt-password PROMPT: 0
PROMPT:*
[INPUT]
1. The default case.
> echo
Just because I have done some research about this topic recently, and
find it interesting, please allow me to ask why you can make any
assumptions regarding STDIN, after only testing STDERR? Couldn't each
of the standard handles be redirected individually, as in "COMMAND
nul 2>errors.log"?
To
I noticed it's no longer possible to submit the form on top of the
timeline web view by hitting enter if one of the text input elements
("Max" or "Tag Filter") is focused in IE.
It seems that (all?) web browsers disable this logic for forms with
multiple text input elements lacking a "submit"
> Therefore, I would expect:
> env "-S perl -e 'print qq([$_] ) for (@ARGV)' a b c"
> to output:
> [a] [b] [c]
Your example works on my FreeBSD server if the double quotes are
omitted, and the command is run from a shell:
env -S perl -e 'print qq([$_] ) for (@ARGV)' a b c
==> [a] [b] [c]
But
Thanks for the link and the additional information. I have stumbled
upon a website with meticulous research about the unspecified shebang
behavior across a wide range of systems:
https://www.in-ulm.de/~mascheck/various/shebang/
There's indeed so many variants that it may not be a good idea to do
On my Windows XP machines (one is a standard installation, the other a
highly tweaked system), I noticed a considerable timeout for the web
browser to appear when `fossil ui` is invoked.
The delay seems to origin from StartServiceCtrlDispatcherW(), called
from win32_http_service() [0] inside
I'm currently stuck on a shared web host running FreeBSD 9.1 without
any C compilers available. I'm still able to run the latest version of
Fossil from [0] with some quirks (see bottom if you're interested in
details).
[0] http://pkg.freebsd.org/
I have created an extra CGI script to start
Citation from:
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg24841.html
> ... What can we do to help you move away from scripts that depend
> on the details of command-line output and toward something that is
> more likely to survive an update? ... Would it be better to run
>
With the help of the excellent documentation on the Fossil Sync
Protocol I have found a very simple solution to fix synchronization of
unversioned files. Due to how work is distributed between the server
and the client, it's correct that the server ignores "uvigot" cards,
but the client should
Andy Bradford:
> This error would seem to indicate that your client sync code
> doesn't actually know what the uvigot card is
Indeed, if I get it right from following the code paths, there are
separate functions to handle synchronization for the client:
I have another observation regarding the failed synchronization of
unversioned files:
If the `max-upload' setting is tweaked to be large enough (I set it to
the default 25*1000 on both the server and the client) so that the
synchronization operation does not require multiple round-trips,
Thank you very much for looking into my issue!
I have built the server from source code with `./configure; make'. I
haven't run `make clean' as I was working inside a new directory
containing just the extracted Fossil source code.
I have now replaced the server binary with the one matching my OS
Hello
I have just discovered a situation where Fossil seems to enter an
endless loop when synchronizing a lot of commit data and some
unversioned files. I'm not sure about the exact size limit, but
probably large enough to trigger multiple round-trips.
Steps to reproduce:
Server
==
FreeBSD
1 - 100 of 105 matches
Mail list logo
