On Jul 12, dev wrote:
thx for quick response.
Just so you're aware - you responded directly to my address; you should have
responded to the mailing list. :-) I'll copy my message to the list for
convenience of other users.
Am 12.07.19 um 18:52 schrieb Maciej Delmanowski:
>On Jul 12, dev wrote:
>>since there is no forum, AFAIK, I just subscribed and hope get infos here
>>instead of (mis)using github-issues…
>There is no forum. I feel that creating one would add yet another place me and
>other people would have to keep track of. Mailing list messages just come to
>your usual mailbox, and you don't need to do anything to keep track of things.
>Although, an upgrade to Mailman 3 could probably improve the usability a bit,
>with web-based forum-like system. But that would have to go through DebOps
>first, so a new set of roles for Mailman, especially that mailman3 packages
>are now available in Debian.
I totally understand your point regarding the forum.
since I have no clue about mailman3, within a forum it's just easy to search
& find already answered questions and maybe complete configs as inspiration.
why not drop the mailing list and replace it with a forum, where one can
send mails to? just an idea…
A switch to Mailman3 would accomplish this. You can check the mailman3-users
mailing list to see how the new web interface looks like and what capabilities
it has (for example search in the archives):
Of course switching to it in the DebOps case would require a new set of
Ansible roles to deploy Mailman3. They will be written eventually, at some
>>Q: how to set lc_collate on postgres DB-creation?
>Good question! At the moment the 'debops.postgresql_server' role uses the
>'pg_createcluster' script to create new PostgreSQL clusters. There is an
>option for setting up locale (via item.locale) parameter, but not specifically
>collation. You can see the code here:
>Would setting the locale suffice in your case, or do you need to set collation
>specifically? I suppose that adding the --lc-collate parameter with default
>the same as --locale wouldn't hurt. I'm not sure how often that option has to
>be differently set than the locale.
>Anyway, to change the locale for all clusters, you can set in the inventory:
>For the default cluster only, at the moment the easiest way would be to
>override the main cluster variable definition:
> name: 'main'
> port: '5432'
> locale: 'en_US.UTF-8'
in that case, it's not about different locales & lc-collate, it's more about
different locales/lc-collates per database
at the moment, I'm working on a customers server, which also uses atlassian
atlassian suggests for jira a Locale=C:
/Create a database for Jira to store issues in (e.g. //|*jiradb* |//) with
| CREATE DATABASE jiradb WITH ENCODING 'UNICODE' LC_COLLATE 'C'
'C' TEMPLATE template0;|
but for confluence: it must not be 'C':
/Next, create a database (for example //|confluence|//): /
* /*Owner*// is your new database user (for example //|confluenceuser|//)/
* /*Character encoding*// must be set to //|utf8|// encoding./
* /*Collation*//must also be set to //|utf8|//. Other collations, such
as "C", are known to cause issues with Confluence. //
since unicode collation is allowed with jira, I hope that it will work for
my customer and will report back if not.
other apps, like bitbucket, crowd … don't have any recommendations on
locales & collations.
I see. In that case, perhaps having a parameter for collation might be useful.
If nobody else makes a PR, I can look into it if you still have problems.