Is this ALL good advise

[Keith Bainbridge]

Good evening All


Just wondering if this is ALL good advice?

Should I use it for ALL my mail, or just sensitive stuff, like lobbying 
politicians.


Thanks

Enhance your email security

Encrypt your mail! For enhanced message security use Encrypted Email.
There are many vulnerabilities with how secure connections work. If 
you need high security, you should always connect to Riseup services 
using the Riseup VPN. This will prevent a long list of potential attacks 
against your communication.
To enhance connection security you can use Tor to connect to 
Riseup’s .onion services for IMAP and SMTP. Look for the onion address 
for mail.riseup.net and smtp.riseup.net addresses and use those instead. 
Note: * SMTP port 465 is often blocked by exit nodes, but port 587 is 
less frequently blocked. If you have a problem sending mail, try port 
587 or configure your client to use Riseup’s email hidden service in 
place of the regular mail.riseup.net domain. This is better than sending 
traffic through a Tor exit as it is MITM resistant, but it will generate 
certificate errors on the client side.


Add some extensions

We suggest these extensions for Thunderbird:

Enigmail: get started in no time encrypting and decrypting emails 
and verifying that emails you receive are from the people who you expect 
them to be.
Display Quota: This extension will display the current status of 
your IMAP quota in Thunderbird’s statusbar and will warn you when you 
reach a configurable limit.
TorBirdy: This extension configures Thunderbird to make connections 
over the Tor anonymity network.


Use hidden options to speed up Thunderbird

Per default every time you open a mail or change the status Thunderbird 
connects to the mail server. For slow connections or when Riseup’s 
servers are busy this can be pain.


Luckily there is a fix: Thunderbird has some hidden options, that a does 
a complete sync when connecting the server. This will speed up your work 
flow and makes your day better.


To set this, go to the menu Edit > Preferences > Advanced > General > 
Config Editor


set use_status_for_biff to false
set mail.server.default.autosync_offline_stores to true


Keith Bainbridge

ke1th3...@gmail.com
0447 667 468

Help with --regex in locate

[Rh Kramer]

Notes:

   * In general, reply to the list, I am subscribed under a slightly different 
username and will see any replies.

   * As is often the case, there is more than one way to skin this cat, 
although I won't mind other approaches, especially if they are simpler, I 
would like to learn what I'm doing wrong with locate --regex.

Overall objective:

I have several .git repositories on this computer.  I want to get a list of 
those repositories without getting a listing of all the files in each 
repository.

Each repository is in a different subdirectory, and with varying path lengths 
(both in number of characters and number of parent directories).

Each repository has several files, including one file ending with .git, e.g.:

/rhk03/Dusan_scintilla_git/RS041-scintilla-syntax-highlighter/.giti
/rhk03/Dusan_scintilla_git/scintilla-scite/.git
/rhk03/Dusan_scintilla_git/scintilla-scite-pre20190419/.git
/rhk03/chroot/scintilla-scite/Scintilla-SciTE/.git
/rhk03/chroot/scintilla-scite/Scintilla-SciTE.git/.git
/rhk03/chroot/scintilla-scite-pre20190419/.git
/rhk03/chroot/scintilla-scite-preKDevelop/.git

(Just for the record, I edited the .gitignore results shown below to the the 
.git results shown above, to show what I'm trying to get.)

I believe I have achieved my objective by searching and finding similar lines 
that end with .gitignore, using this locate command (I've achieved my 
objective if every .git repository includes a file named .gitignore -- at the 
moment, I believe that is true):

locate --regex \/\.gitignore

which finds:

/rhk03/Dusan_scintilla_git/RS041-scintilla-syntax-highlighter/.gitignore
/rhk03/Dusan_scintilla_git/scintilla-scite/.gitignore
/rhk03/Dusan_scintilla_git/scintilla-scite-pre20190419/.gitignore
/rhk03/chroot/scintilla-scite/Scintilla-SciTE/.gitignore
/rhk03/chroot/scintilla-scite/Scintilla-SciTE.git/.gitignore
/rhk03/chroot/scintilla-scite-pre20190419/.gitignore
/rhk03/chroot/scintilla-scite-preKDevelop/.gitignore

But I've had no luck finding only the paths that end in .git.  I've tried a 
number of locate commands (in almost a shotgun approach) none of them have 
worked, and some have given me some really strange results (finding files in 
/usr that have git somewhere in the filename, but not just .git)

Some of the commands I tried:

rhk@s31:/rhk03$ locate --regex \/\.git
rhk@s31:/rhk03$ locate --regex \/\.git[^\/]
rhk@s31:/rhk03$ locate --regex \/\.git[^\/][:blank:] 
rhk@s31:/rhk03$ locate --regex \/git[^\.][:blank:]
rhk@s31:/rhk03$ locate --regex \.git[^\.][:blank:] 
rhk@s31:/rhk03$ locate --regex \.git[\.][:blank:]
rhk@s31:/rhk03$ locate --regex \.git[:blank:]

Any help / insights will be appreciated!

Resolved: Re: Help with --regex in locate

[Rh Kramer]

Ohh, two more things:

On the following line, I failed to delete the last i (part of ignore)

> /rhk03/Dusan_scintilla_git/RS041-scintilla-syntax-highlighter/.giti

Ahh, I think I found my problem -- .git is a directory, not a file --  sorry 
for the noise.

On Tuesday, December 03, 2019 5:54:33 AM Rh Kramer wrote:
> Notes:
> 
>* In general, reply to the list, I am subscribed under a slightly
> different username and will see any replies.
> 
>* As is often the case, there is more than one way to skin this cat,
> although I won't mind other approaches, especially if they are simpler, I
> would like to learn what I'm doing wrong with locate --regex.
> 
> Overall objective:
> 
> I have several .git repositories on this computer.  I want to get a list of
> those repositories without getting a listing of all the files in each
> repository.
> 
> Each repository is in a different subdirectory, and with varying path
> lengths (both in number of characters and number of parent directories).
> 
> Each repository has several files, including one file ending with .git,
> e.g.:
> 
> /rhk03/Dusan_scintilla_git/RS041-scintilla-syntax-highlighter/.giti
> /rhk03/Dusan_scintilla_git/scintilla-scite/.git
> /rhk03/Dusan_scintilla_git/scintilla-scite-pre20190419/.git
> /rhk03/chroot/scintilla-scite/Scintilla-SciTE/.git
> /rhk03/chroot/scintilla-scite/Scintilla-SciTE.git/.git
> /rhk03/chroot/scintilla-scite-pre20190419/.git
> /rhk03/chroot/scintilla-scite-preKDevelop/.git
> 
> (Just for the record, I edited the .gitignore results shown below to the the
> .git results shown above, to show what I'm trying to get.)
> 
> I believe I have achieved my objective by searching and finding similar
> lines that end with .gitignore, using this locate command (I've achieved my
> objective if every .git repository includes a file named .gitignore -- at
> the moment, I believe that is true):
> 
> locate --regex \/\.gitignore
> 
> which finds:
> 
> /rhk03/Dusan_scintilla_git/RS041-scintilla-syntax-highlighter/.gitignore
> /rhk03/Dusan_scintilla_git/scintilla-scite/.gitignore
> /rhk03/Dusan_scintilla_git/scintilla-scite-pre20190419/.gitignore
> /rhk03/chroot/scintilla-scite/Scintilla-SciTE/.gitignore
> /rhk03/chroot/scintilla-scite/Scintilla-SciTE.git/.gitignore
> /rhk03/chroot/scintilla-scite-pre20190419/.gitignore
> /rhk03/chroot/scintilla-scite-preKDevelop/.gitignore
> 
> But I've had no luck finding only the paths that end in .git.  I've tried a
> number of locate commands (in almost a shotgun approach) none of them have
> worked, and some have given me some really strange results (finding files in
> /usr that have git somewhere in the filename, but not just .git)
> 
> Some of the commands I tried:
> 
> rhk@s31:/rhk03$ locate --regex \/\.git
> rhk@s31:/rhk03$ locate --regex \/\.git[^\/]
> rhk@s31:/rhk03$ locate --regex \/\.git[^\/][:blank:]
> rhk@s31:/rhk03$ locate --regex \/git[^\.][:blank:]
> rhk@s31:/rhk03$ locate --regex \.git[^\.][:blank:]
> rhk@s31:/rhk03$ locate --regex \.git[\.][:blank:]
> rhk@s31:/rhk03$ locate --regex \.git[:blank:]
> 
> Any help / insights will be appreciated!

Re: Docking browser tabs to windows manager.

[Andrei POPESCU]

On Lu, 02 dec 19, 19:09:55, Tomas Zubiri wrote:
> Hello, I'm mainly a browser user, the OS is a thin shell that I require to
> run a browser,
> I check my email in GMail, do my finances in google sheets, use whatsapp
> through a web interface, banking through a browser interface, etc...
> 
> Is there a windows manager that would allow me to split a tab into a new
> window such that the new window is recognized as a separate application?
> 
> Here's a couple of possible integrations,
> Windows manager could use favicon on OS toolbar.
> Navigation with alt+tab would work making alt+~ unnecessary.
> Webapps could be pinned to OS toolbar, effectively providing an
> 'installation' UX mechanism that is technically equal to the command
> 'browser-app url'.
> 
> This sounds pretty cool, but the window manager I'm using (gnome) doesn't
> support any of it. Any alternative window manager (or os) I could look into?

You are describing Chromium OS / Chrome OS.

To stay slightly on topic, depending on how powerful the machine is you 
would be using for it one can run Debian in a chroot (see the crouton 
project) or in a container (crostini project).

Chrome OS (not sure about Chromium OS) also supports installing Android 
Apps (make sure this is enabled for the specific Chromebook you might be 
considering). At some point Android Apps worked significantly better on 
ARM machines, though this might have changed in the meantime.

If you don't care about Android Apps in my opinion a very interesting 
option is the Pinebook Pro (200$ + shipping and custom taxes). 
Apparently its SoC (RK3399, also known as OP1) was designed specifically 
for Chromebooks (used in Asus Chromebook Flip C101 and Samsung 
Chromebook Plus v1) and the Chromium OS build for the PBP is supposed to 
be quite good. I'm looking forward to running pure Debian on one to 
replace my Acer Chromebook R13 (Chrome OS + crouton).

Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Is this ALL good advise

[Andrei POPESCU]

On Ma, 03 dec 19, 20:42:30, Keith Bainbridge wrote:
> Good evening All
> 
> 
> Just wondering if this is ALL good advice?
> 
> Should I use it for ALL my mail, or just sensitive stuff, like lobbying
> politicians.

Most appear to be quite sensible, but I'm not using Thunderbird.

Do note that encryption can work only if the other side supports it as 
well and you have their public key.

I believe opportunistic signing and/or encrypting of e-mails should be 
the default in all e-mail clients.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Help with --regex in locate

[Andrei POPESCU]

On Ma, 03 dec 19, 05:54:33, Rh Kramer wrote:
> Notes:
> 
>* In general, reply to the list, I am subscribed under a slightly 
> different 
> username and will see any replies.
> 
>* As is often the case, there is more than one way to skin this cat, 
> although I won't mind other approaches, especially if they are simpler, I 
> would like to learn what I'm doing wrong with locate --regex.

With 'find' instead of 'locate'.

find dir_with_repos -type d -name .git

or

find dir_with_repos -type d -name "*.git"

if you also have git bare clones ('-name' expects a shell pattern).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Help with --regex in locate

[rhkramer]

Andrei,

Thanks very much!  (Please forgive the nitpicky comment below.)


On Tuesday, December 03, 2019 07:16:22 AM Andrei POPESCU wrote:
> With 'find' instead of 'locate'.
> 
> find dir_with_repos -type d -name .git
> 
> or
> 
> find dir_with_repos -type d -name "*.git"
> 
> if you also have git bare clones ('-name' expects a shell pattern).

It took me a minute (well, a trial) to realize that dir_with_repos is a 
metaname (right word?).  I prefer a syntax like: 

find  -type d -name .git

Re: Help with --regex in locate

[Brian]

On Tue 03 Dec 2019 at 08:07:16 -0500, rhkra...@gmail.com wrote:

> On Tuesday, December 03, 2019 07:16:22 AM Andrei POPESCU wrote:
> > With 'find' instead of 'locate'.
> > 
> > find dir_with_repos -type d -name .git
> > 
> > or
> > 
> > find dir_with_repos -type d -name "*.git"
> > 
> > if you also have git bare clones ('-name' expects a shell pattern).
> 
> It took me a minute (well, a trial) to realize that dir_with_repos is a 
> metaname (right word?).  I prefer a syntax like: 
> 
> find  -type d -name .git

I prefer that syntax too but many users (particularly new ones) end up
typing the angle brackets, which, of course, leads to a failed command.
A second mail is then needed to clear up the confusion. I've taken to
doing what Andrei does or giving an instruction as to what to type.

-- 
Brian.

Re: Help with --regex in locate

[Greg Wooledge]

On Tue, Dec 03, 2019 at 05:54:33AM -0500, Rh Kramer wrote:
> locate --regex \/\.gitignore

Your quoting is all wrong here.  What you want is:

locate --regex '/\.gitignore'

The / does not need to be quoted, either for the shell, or for the
regex.  It's just a regular old character with no special meaning.
The . on the other hand DOES need to be quoted, not for the shell,
but for the regex.  Because in a regex, it means "any character".

Within the regex, you quote it by putting a \ in front of it.  However,
then that backslash needs to be quoted for the SHELL, because otherwise
the shell interprets it:

wooledg:~$ echo \.
.

See, that's not what you want.  You need to pass the payload /\.gitignore
as the regex, so you need to quote that in such a way that the shell
doesn't screw with it.  Thus, the single quotes around it.

wooledg:~$ echo '/\.gitignore'
/\.gitignore

> But I've had no luck finding only the paths that end in .git.

locate --regex '\.git$'

Again, the single quotes protect the regex from interpretation by the
shell.

Re: Help with --regex in locate

[Jonas Smedegaard]

Quoting Brian (2019-12-03 14:39:28)
> On Tue 03 Dec 2019 at 08:07:16 -0500, rhkra...@gmail.com wrote:
> 
> > On Tuesday, December 03, 2019 07:16:22 AM Andrei POPESCU wrote:
> > > With 'find' instead of 'locate'.
> > > 
> > > find dir_with_repos -type d -name .git
> > > 
> > > or
> > > 
> > > find dir_with_repos -type d -name "*.git"
> > > 
> > > if you also have git bare clones ('-name' expects a shell pattern).
> > 
> > It took me a minute (well, a trial) to realize that dir_with_repos 
> > is a metaname (right word?).  I prefer a syntax like:
> > 
> > find  -type d -name .git
> 
> I prefer that syntax too but many users (particularly new ones) end up 
> typing the angle brackets, which, of course, leads to a failed 
> command. A second mail is then needed to clear up the confusion. I've 
> taken to doing what Andrei does or giving an instruction as to what to 
> type.

I agree that angle brackets has a real risk of wreaking havoc for less 
experienced users following instructions "to the letter".  I did so 
myself back in 1998 when moving from MacOS 8 to Linux :-)

What I have so far settled on is to distinguish "variables" in capital 
letters, and explicitly hint that it should be changed, like this:

With 'find' instead of 'locate' (adapt dir):

  find DIR_WITH_REPOS -type d -name .git


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Help with --regex in locate

[rhkramer]

On Tuesday, December 03, 2019 08:39:28 AM Brian wrote:
> On Tue 03 Dec 2019 at 08:07:16 -0500, rhkra...@gmail.com wrote:
> > On Tuesday, December 03, 2019 07:16:22 AM Andrei POPESCU wrote:
> > > With 'find' instead of 'locate'.
> > > 
> > > find dir_with_repos -type d -name .git
> > > 
> > > or
> > > 
> > > find dir_with_repos -type d -name "*.git"
> > > 
> > > if you also have git bare clones ('-name' expects a shell pattern).
> > 
> > It took me a minute (well, a trial) to realize that dir_with_repos is a
> > metaname (right word?).  I prefer a syntax like:
> > 
> > find  -type d -name .git
> 
> I prefer that syntax too but many users (particularly new ones) end up
> typing the angle brackets, which, of course, leads to a failed command.
> A second mail is then needed to clear up the confusion. I've taken to
> doing what Andrei does or giving an instruction as to what to type.

Yes, you're right.  On occasion (when I remember / think about it), I do 
something like this (copied from my other recent reply):

Command:

find  -type d -name "*.git"

For example:

find /rhk -type d -name "*.git"

But, I don't always remember.  I wish there was a universal unambiguous way to 
convey that information in one line ;-)

Or maybe dir_to_search would have come across to me better, I sort of had a 
brain f___ when I saw with dir_with_repos, without being familiar with find (I 
almost never use it), my first thought was that it was sort of a file type 
specification.  (Obviously, that is silly, but, there is no accounting for how 
my mind works at times (or doesn't) ;-)

Re: Help with --regex in locate

[rhkramer]

On Tuesday, December 03, 2019 09:09:45 AM Jonas Smedegaard wrote:
> With 'find' instead of 'locate' (adapt dir):
> 
>   find DIR_WITH_REPOS -type d -name .git

That helps, also, especially with the note "adapt dir" (or maybe "adjust dir", 
or "specify dir appropriately" (I don't know why I'm trying to play wordsmith 
;-)

Re: Is this ALL good advise

[Dan Clery]

Any security advise without consideration of your threat model is less than
ideal.

As others have said, if you send me an encrypted email, and I'm not
prepared to deal with it, your message won't be recieved (your great aunt
Tilly isn't going to be able to read your encrypted emails without a bunch
of support)

In a general sense, the more we encrypt communication,  the better we hide
our source IP address, the safer we are, because if you only encrypt
dangerous communications, it's a clear flag of what messages are dangerous.
If they're drops in a sea of noise, it's harder to identify the important
stuff.

There's another side of the coin though. You want to be careful doing
mundane stuff over the same channel you would do dangerous things.

An example - I use a VPN for whenever I torrent stuff I don't want to point
at my home. My browser talked to Facebook enough to trigger their
suspicious activity bot, making me change my password. So the IP I was
using to do secret stuff could theoretically be tied to an IP I was using
at the same time for mundane stuff. If my personal safety was a risk over
what I was doing, I'd be worried.

On Tue, Dec 3, 2019, 07:05 Andrei POPESCU  wrote:

> On Ma, 03 dec 19, 20:42:30, Keith Bainbridge wrote:
> > Good evening All
> >
> >
> > Just wondering if this is ALL good advice?
> >
> > Should I use it for ALL my mail, or just sensitive stuff, like lobbying
> > politicians.
>
> Most appear to be quite sensible, but I'm not using Thunderbird.
>
> Do note that encryption can work only if the other side supports it as
> well and you have their public key.
>
> I believe opportunistic signing and/or encrypting of e-mails should be
> the default in all e-mail clients.
>
> Kind regards,
> Andrei
> --
> http://wiki.debian.org/FAQsFromDebianUser
>

Re: Help with --regex in locate

[rhkramer]

On Tuesday, December 03, 2019 09:01:16 AM Greg Wooledge wrote:
> On Tue, Dec 03, 2019 at 05:54:33AM -0500, Rh Kramer wrote:
> > locate --regex \/\.gitignore
> 
> Your quoting is all wrong here.  What you want is:
> 
> locate --regex '/\.gitignore'
> 
> The / does not need to be quoted, either for the shell, or for the
> regex.  It's just a regular old character with no special meaning.
> The . on the other hand DOES need to be quoted, not for the shell,
> but for the regex.  Because in a regex, it means "any character".
> 
> Within the regex, you quote it by putting a \ in front of it.  However,
> then that backslash needs to be quoted for the SHELL, because otherwise
> the shell interprets it:
> 
> wooledg:~$ echo \.
> .
> 
> See, that's not what you want.  You need to pass the payload /\.gitignore
> as the regex, so you need to quote that in such a way that the shell
> doesn't screw with it.  Thus, the single quotes around it.
> 
> wooledg:~$ echo '/\.gitignore'
> /\.gitignore
> 
> > But I've had no luck finding only the paths that end in .git.
> 
> locate --regex '\.git$'

Thanks that works! (Well, exept for bare repositories, which I'm really not 
concerned about, at least at this time!)

I always have trouble with all the rigamarole around quoting for the shell vs. 
quoting for the regex (or quoting or not quoting for anything else).

I don't know what it will take to get it to sink into my head.  (Maybe in my 
next life ;-)

I do find it useful to think of the backslash as "escaping" vs. "quoting".

> Again, the single quotes protect the regex from interpretation by the
> shell.

Metavariable [was: Help with --regex in locate]

[tomas]

On Tue, Dec 03, 2019 at 08:07:16AM -0500, rhkra...@gmail.com wrote:

[...]

> On Tuesday, December 03, 2019 07:16:22 AM Andrei POPESCU wrote:
> > With 'find' instead of 'locate'.
[...]

> It took me a minute (well, a trial) to realize that dir_with_repos is a 
> metaname (right word?).  I prefer a syntax like: 

I think the canonical name is "metasyntactic variable" [1]. I've
seen also just "metavariable", although Wikipedia would say that
the latter belongs in the realm of logic [2], not programming.

But "metaname" was close enough for me to grok what you wanted
to say.

Cheers

[1] https://en.wikipedia.org/wiki/Metasyntactic_variable
[2] https://en.wikipedia.org/wiki/Metavariable

-- tomás


signature.asc
Description: Digital signature

Re: Help with --regex in locate

[Andrei POPESCU]

On Ma, 03 dec 19, 15:09:45, Jonas Smedegaard wrote:
> 
> What I have so far settled on is to distinguish "variables" in capital 
> letters, and explicitly hint that it should be changed, like this:
> 
> With 'find' instead of 'locate' (adapt dir):
> 
>   find DIR_WITH_REPOS -type d -name .git
> 
> 
>  - Jonas

Good idea, will try to use something like this as well in the future.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Postgresql logging problem

[Johann Spies]

We have upgraded two servers by installing postgresql(pgpd) 12.  Both
servers are running Debian Stable.

On the problem server we have:
pg_lsclusters
Ver Cluster Port Status OwnerData directory  Log file
11  main5432 online postgres /var/lib/postgresql/11/main
/var/log/postgresql/postgresql-11-main.log
12  main5434 online postgres /var/lib/postgresql/12/main
/var/log/postgresql/postgresql-12-main.log

But nothing gets written to the logfiles.  In stead the logs appear on the
console when the user postgresql is connecting to the database.

On the other server:
$ pg_lsclusters
Ver Cluster Port Status OwnerData directory  Log file
11  main5433 down   postgres /var/lib/postgresql/11/main
/var/log/postgresql/postgresql-11-main.log
12  main5432 online postgres /var/lib/postgresql/12/main
/var/log/postgresql/postgresql-12-main.log

The logging works as expected.

The postgresql.conf for version 12 is identical on both servers - the
default installed by Debian.

This is with logging_collector off.

When switching logging_collector  on on the problem server, it logs to
/var/lib/postgresql/11/main/log/.

Our preference would be to have the logs on both servers in
/var/log/postgresql.

Where do we look for the cause of this behaviour?  On both servers the
configuration for rsyslog seems to be identical.

Regards.

Johann



-- 
Because experiencing your loyal love is better than life itself,
my lips will praise you.  (Psalm 63:3)

Re: Metavariable [was: Help with --regex in locate]

[Stefan Monnier]

> I think the canonical name is "metasyntactic variable" [1]. I've
> seen also just "metavariable", although Wikipedia would say that
> the latter belongs in the realm of logic [2], not programming.

AFAICT those two usages are one and the same: when you see "foo" it's
because the code is actually described in a (human) meta-language.


Stefan

Re: Metavariable [was: Help with --regex in locate]

[tomas]

On Tue, Dec 03, 2019 at 10:18:59AM -0500, Stefan Monnier wrote:
> > I think the canonical name is "metasyntactic variable" [1]. I've
> > seen also just "metavariable", although Wikipedia would say that
> > the latter belongs in the realm of logic [2], not programming.
> 
> AFAICT those two usages are one and the same: when you see "foo" it's
> because the code is actually described in a (human) meta-language.

My take, too.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Docking browser tabs to windows manager.

[Jonathan Dowland]

The Chromium (and Chrome) browsers have (or had) a feature called 
"application link" which does something similar to what you are asking 
for. You browse to a site/page/app that you wish to make into an 
"application", and then ask the browser to create an "application link".  

In the background this creates a .desktop file which instructs a new 
instance of chrome to be launched, that is isolated in some fashion from 
your normal one. As it's a .desktop file, it shows up in your desktop 
environment's list of applications, has an icon, etc. The browser that 
starts when you launch it is treated as separate in GNOME's alt-tab 
window (for example) for selecting applications, and the browser URL bar 
and buttons typically do not get drawn for that instance.



--

Jonathan Dowland

Subcontratacion y Outsourcing: Lo legal y lo fiscal para este 2020

[Paulina Escobar Camargo]

Buenas tardes,

Eres un Outsourcing o subcontratas personal a través de uno? Esto puede ser de 
tu interés.

Este 2020 será un año de modificaciones, cambios y actualizaciones en materia 
laboral y fiscal. Es bien sabido por todos que la actual administración tiene 
como prioridad en su agenda política el regular y fiscalizar la subcontratación 
del personal en México. Y a pesar de que organismos como la COPARMEX se han 
pronunciado en contra de las reformas fiscales y laborales que afectan al 
outsourcing, parece que no hay marcha atrás. 

La recomendación de todos los expertos es que las Empresas sepamos claramente 
cuáles son esos cambios fiscales y laborales que podrían afectar a nuestra 
Compañía; si me lo permites te mando la información de un entrenamiento 100% 
especializado en las Implicaciones Legales y Fiscales del uso del Outsourcing 
para el 2020. Éste se llevará a cabo en la Ciudad de México y será impartido 
por uno de los mayores expertos en el tema laboral, y que actualmente es 
reconocido como uno de los pioneros en estrategias de fiscalización en la 
subcontratación del personal. 

FOLLETO OUTSOURCING 2020


Esperando que esta información sea útil y oportuna, quedo de tus comentarios 
ante cualquier aspecto.

Saludo grande.



C.P. Paulina Escobar Camargo
Recursos Humanos y Desarrollo Organizacional
Altec y Soluciones Tecnológicas S.A. de C.V.
55 4262 0076 terminaciones 77/78/79
altecsoluciones.com.mx






















Este boletín informativo tiene como finalidad darle valor a usted y a su 
Compañía. Si desea dejar de recibir este tipo de información favor de contestar 
con la palabra BAJAOUTSOURCING9-10.
O en su defecto en el siguiente enlace: unsubscribe from this list

Re: password refused by cups on localhost:631 (fwd)

[Pierre Frenkiel]

On Sat, 30 Nov 2019, Roberto C. Sanchez wrote:
   It has a been a while, but my recollection is that you add a normal user
   to the lpadmin group.  Then by authenticating as that user you can
   administer through the web interface.

   hi Roberto,
   alas, I already did that, without success.

no more answers 
nobody can give an advice?

best regards,
--
Pierre Frenkiel

Re: Is this ALL good advise

[Brad Rogers]

On Tue, 3 Dec 2019 20:42:30 +1100
Keith Bainbridge  wrote:

Hello Keith,

>Should I use it for ALL my mail, or just sensitive stuff, like lobbying 
>politicians.

Ideally, all one's email should be encrypted because if it isn't, the
ones that *are* encrypted simply SCREAM 'look at me, I'm interesting'.

Of course, as others have already said, it's never gonna happen because
most people simply aren't going to have (not to mention _want_ to have)
the necessary tool chain.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Buy some love at the five and dime
You Have Placed A Chill In My Heart - Eurythmics


pgpn_DqeKeAQL.pgp
Description: OpenPGP digital signature

Re: password refused by cups on localhost:631 (fwd)

[Brian]

On Tue 03 Dec 2019 at 17:37:59 +0100, Pierre Frenkiel wrote:

> On Sat, 30 Nov 2019, Roberto C. Sanchez wrote:
>It has a been a while, but my recollection is that you add a normal user
>to the lpadmin group.  Then by authenticating as that user you can
>administer through the web interface.
> 
>hi Roberto,
>alas, I already did that, without success.
> 
> no more answers 
> nobody can give an advice?

After being added to a group a user has to log out and log in again.
Can we assume you have not altered any .conf file in /etc/cups?

-- 
Brian.

Re: Is this ALL good advise

[Andrei POPESCU]

On Ma, 03 dec 19, 15:55:37, Brad Rogers wrote:
> On Tue, 3 Dec 2019 20:42:30 +1100
> Keith Bainbridge  wrote:
> 
> Hello Keith,
> 
> >Should I use it for ALL my mail, or just sensitive stuff, like lobbying 
> >politicians.
> 
> Ideally, all one's email should be encrypted because if it isn't, the
> ones that *are* encrypted simply SCREAM 'look at me, I'm interesting'.
> 
> Of course, as others have already said, it's never gonna happen because
> most people simply aren't going to have (not to mention _want_ to have)
> the necessary tool chain.

In my opinion "never" is too strong here, especially with free services 
like ProtonMail offering encryption out-of-the-box with minimal user 
input required.

Also in the corporate world encryption is (slowly) starting to see more 
use, due to GDPR or similar requirements.

As it sees more use the tools should also improve to make for a better 
user experience.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: password refused by cups on localhost:631 (fwd)

[Gene Heskett]

On Tuesday 03 December 2019 11:37:59 Pierre Frenkiel wrote:

> On Sat, 30 Nov 2019, Roberto C. Sanchez wrote:
> It has a been a while, but my recollection is that you add a
> normal user to the lpadmin group.  Then by authenticating as that user
> you can administer through the web interface.
>
> hi Roberto,
> alas, I already did that, without success.
>
When it pops up the requester, did you change it from the default root to 
your name you've added to lpadmin and your passwd?  That works here. 

Cumbersome but works. On a system w/o a root passwd, I use sudo for 
everything, I haven't a clue how cups expects to get a valid passwd for 
root. Boggles the mind, but it insists.  So change it yourself.

> no more answers 
> nobody can give an advice?
>
> best regards,


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

camera led flashes while waking system up from sleep

[dinar qurbanov]

laptop camera led flashes while waking system up from sleep. i would
like to report a bug. which package should i put? i think it is
systemd or lightdm, or both. i am using debian 10 with xfce.

camera led flashes while waking system up from sleep

[dinar qurbanov]

laptop camera led flashes while waking system up from sleep. i would
like to report a bug. which package should i put? i think it is
systemd or lightdm, or both. i am using debian 10 with xfce.

Re: Is this ALL good advise

[John Hasler]

https://www.wired.com/2015/10/mr-robot-uses-protonmail-still-isnt-fully-secure/

Besides, most users will continue to use Gmail and the like.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: password refused by cups on localhost:631 (fwd)

[Brian]

On Tue 03 Dec 2019 at 13:17:21 -0500, Gene Heskett wrote:

> On Tuesday 03 December 2019 11:37:59 Pierre Frenkiel wrote:
> 
> > On Sat, 30 Nov 2019, Roberto C. Sanchez wrote:
> > It has a been a while, but my recollection is that you add a
> > normal user to the lpadmin group.  Then by authenticating as that user
> > you can administer through the web interface.
> >
> > hi Roberto,
> > alas, I already did that, without success.
> >
> When it pops up the requester, did you change it from the default root to 
> your name you've added to lpadmin and your passwd?  That works here.

I wish I could have confidence in your interpretation of what you see.
The pop-up has two blank fields. Why you maintain the default user is
"root" and it needs to be changed is beyond me.

-- 
Brian.

Re: password refused by cups on localhost:631 (fwd)

[Pierre Frenkiel]

On Tue, 3 Dec 2019, Gene Heskett wrote:


When it pops up the requester, did you change it from the default root to
your name you've added to lpadmin and your passwd?  That works here.


  yes, I do that, and my password is refused, as well as the root one

Re: password refused by cups on localhost:631 (fwd)

[Gene Heskett]

On Tuesday 03 December 2019 14:23:34 Brian wrote:

> On Tue 03 Dec 2019 at 13:17:21 -0500, Gene Heskett wrote:
> > On Tuesday 03 December 2019 11:37:59 Pierre Frenkiel wrote:
> > > On Sat, 30 Nov 2019, Roberto C. Sanchez wrote:
> > > It has a been a while, but my recollection is that you add a
> > > normal user to the lpadmin group.  Then by authenticating as that
> > > user you can administer through the web interface.
> > >
> > > hi Roberto,
> > > alas, I already did that, without success.
> >
> > When it pops up the requester, did you change it from the default
> > root to your name you've added to lpadmin and your passwd?  That
> > works here.
>
> I wish I could have confidence in your interpretation of what you see.
> The pop-up has two blank fields. Why you maintain the default user is
> "root" and it needs to be changed is beyond me.

Well, since about 6.04 of the ubuntu thread, its always popped up with 
the root line filled with "root", and about 15 dots that represents the 
missing root pw. I just change them both to me & my pw and it sorta 
works.

Explaining the "sorta" would be TL;DR and has been posted many times and 
just as many times ignored. Both on this list and the cups list.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: password refused by cups on localhost:631 (fwd)

[Gene Heskett]

On Tuesday 03 December 2019 15:58:45 Pierre Frenkiel wrote:

> On Tue, 3 Dec 2019, Gene Heskett wrote:
> > When it pops up the requester, did you change it from the default
> > root to your name you've added to lpadmin and your passwd?  That
> > works here.
>
>yes, I do that, and my password is refused, as well as the root one
And your /etc/group entry for lpadmin resembles this?:
lpadmin:x:116:gene


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

solved - Re: password refused by cups on localhost:631

[Pierre Frenkiel]

On Tue, 3 Dec 2019, Brian wrote:


I wish I could have confidence in your interpretation of what you see.
The pop-up has two blank fields. Why you maintain the default user is
"root" and it needs to be changed is beyond me.


  Yes, I maintain it...
  I don't have 2 blank fields,
  but 2 fields containing "root" and the registred root password
  Anyway, I found that there were 2 running cupsd.
  After killing one, everything works fine, i.e for either root or me,
  the password is accepted.

  thanks everybody for your advices.

best regards,
--
Pierre Frenkiel

Re: Is this ALL good advise

[Keith Bainbridge]

On 3/12/19 11:04 pm, Andrei POPESCU wrote:

Most appear to be quite sensible, but I'm not using Thunderbird.

Do note that encryption can work only if the other side supports it as
well and you have their public key.



Thanks everybody

One advantage of sleeping while most of you are wide awake is that so 
many replies to my questions are waiting for me over my morning coffee.




I was a little surprised with the strong suggestion for Thunderbird. But 
I have yo say that it is overall easy to use (and after >20 years) very 
familiar.


Several have commented on the usefulness of encryption. The people I 
will be a addressing will mainly fall under the group that wont bother 
trying.



Other responses follow


--
Keith Bainbridge

ke1th3...@gmail.com
+61 (0)447 667 468

Re: password refused by cups on localhost:631 (fwd)

[Brian]

On Tue 03 Dec 2019 at 16:13:19 -0500, Gene Heskett wrote:

> On Tuesday 03 December 2019 14:23:34 Brian wrote:
> 
> > On Tue 03 Dec 2019 at 13:17:21 -0500, Gene Heskett wrote:
> > > On Tuesday 03 December 2019 11:37:59 Pierre Frenkiel wrote:
> > > > On Sat, 30 Nov 2019, Roberto C. Sanchez wrote:
> > > > It has a been a while, but my recollection is that you add a
> > > > normal user to the lpadmin group.  Then by authenticating as that
> > > > user you can administer through the web interface.
> > > >
> > > > hi Roberto,
> > > > alas, I already did that, without success.
> > >
> > > When it pops up the requester, did you change it from the default
> > > root to your name you've added to lpadmin and your passwd?  That
> > > works here.
> >
> > I wish I could have confidence in your interpretation of what you see.
> > The pop-up has two blank fields. Why you maintain the default user is
> > "root" and it needs to be changed is beyond me.
> 
> Well, since about 6.04 of the ubuntu thread, its always popped up with 
> the root line filled with "root", and about 15 dots that represents the 
> missing root pw. I just change them both to me & my pw and it sorta 
> works.

Ubuntu? You might have noticed we are talking about behaviour on Debian.
You'll have checked, of course. Well, perhaps not. It's easier to hark
back to some dim menory of a long forgotten distribution.

-- 
Brian.

Re: Is this ALL good advise

[Andrei POPESCU]

On Ma, 03 dec 19, 12:50:24, John Hasler wrote:
> https://www.wired.com/2015/10/mr-robot-uses-protonmail-still-isnt-fully-secure/

Noting the article is more than 4 years old.
 
> Besides, most users will continue to use Gmail and the like.

Sure, but ProtonMail also allows to communicate fairly secure even with 
persons who don't have a GPG key. They would receive a link to access 
the message on the web with a password set by the sender.

I won't let the perfect be the enemy of good.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Is this ALL good advise

[Keith Bainbridge]

On 4/12/19 1:19 am, Dan Clery wrote:


In a general sense, the more we encrypt communication,  the better we 
hide our source IP address, the safer we are, because if you only 
encrypt dangerous communications, it's a clear flag of what messages are 
dangerous. If they're drops in a sea of noise, it's harder to identify 
the important stuff.


There's another side of the coin though. You want to be careful doing 
mundane stuff over the same channel you would do dangerous things.


Dan

Am I correct to interpret you as the best protection sometimes backfires?

I was advised by a Government agency that I should get separate email. 
Hence my question earlier about safe email providers. My marginal 
Asperger's told me that, that meant safer email, including encryption. 
Perhaps a more secure email provider is my best course?



More food for thought.

I'll be back  later, with personal thanks for other responses. My 
typing speed is slower than I like to believe.



--
Keith Bainbridge

ke1th3...@gmail.com
+61 (0)447 667 468

Re: camera led flashes while waking system up from sleep

[dinar qurbanov]

i have reported it for "base" pseudo package.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946122 .

Re: Is this ALL good advise

[John Hasler]

Keith Bainbridge writes:
>Perhaps a more secure email provider is my best course?

Yes.  I suggest Newsguy or another for-pay email provider.  Do as I do
and configure Fetchmail to download all your new mail every five minutes
(and delete it on the server, of course).  The snoops rely on people
using IMAP or Webmail and leaving all their mail on the server forever.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Best/Proper way to dist-upgrade Debian Testing except the kernel?

[riveravaldez]

Because updating the kernel requires to reboot the system -AFAIK- in
many cases I would prefer to 'dist-upgrade' (all packages) except the
kernel -until a moment in which I can reboot the system-, so:

1. Is this something right/viable/acceptable to do?

2. Which would be the best/proper way to do it? (I mean, 'apt-get
update && apt-get dist-upgrade' for all packages *except* the kernel.)

3. If 'apt-mark hold package' would be the way to do it: which
'package' -exactly- should I mark for hold?

Thanks a lot!

Re: Help with --regex in locate

[David]

On Wed, 4 Dec 2019 at 01:36,  wrote:

> I always have trouble with all the rigamarole around quoting for the shell vs.
> quoting for the regex (or quoting or not quoting for anything else).
>
> I don't know what it will take to get it to sink into my head.  (Maybe in my
> next life ;-)

Hi, yes, it's complicated and confusing.

Here's a suggestion ...

Apologies if some of the following is stating
things that are obvious, I just try to give
complete instructions.

We can make a helper command that shows us
exactly what the shell does to any arguments
before it sends them to a command.

First we need a name for this helper command.
Let's use the name show_args.bash, but you
can use whatever name you like.

I suggest this name because it is unlikely to
already be in use on your system. Let's check:

$ type show_args.bash
bash: type: show_args.bash: not found

Ok, that name is not in use, so let's use it.
We are not going to put this command into
the PATH so name collision doesn't really
matter, but I'm just giving ideas and trying
to be thorough.

Open your favourite editor and create
a file that contains the next paragraph
(use cut and paste if possible, it must be
exactly as shown):

#!/bin/bash
printf '%s' "$# args:"
printf ' [%s]' "$@"
printf '\n'

Save this file with the name: show_args.bash

Now make that file executable:

$ chmod -v u+x show_args.bash
mode of 'show_args.bash' changed from 0640 (rw-r-) to 0740 (rwxr-)

Now we have created a command that just
displays the arguments that it receives from
the shell.

The command is in the current directory
and not in the PATH, so we need to specify
its location when invoking it: ./show_args.bash

Here's what it shows for a couple of commands
that you had trouble with.

$ ./show_args.bash locate --regex \/\.gitignore
3 args: [locate] [--regex] [/.gitignore]

The above shows that your attempt to put \.
into the regex did not work because the shell
removed that escape-quoting.

$ ./show_args.bash locate --regex '/\.gitignore'
3 args: [locate] [--regex] [/\.gitignore]

The above shows that adding single quotes
prevented that quote removal and the \.
remained in the regex argument that was
seen by locate.

A helper command like this is useful when
trying to apply the explanations at:
http://mywiki.wooledge.org/Quotes
to your own requirements.

Re: Help with --regex in locate

[rhkramer]

Thanks -- I'll try that sometime tomorrow!

On Tuesday, December 03, 2019 07:24:49 PM David wrote:
> On Wed, 4 Dec 2019 at 01:36,  wrote:
> > I always have trouble with all the rigamarole around quoting for the
> > shell vs. quoting for the regex (or quoting or not quoting for anything
> > else).
> > 
> > I don't know what it will take to get it to sink into my head.  (Maybe in
> > my next life ;-)
> 
> Hi, yes, it's complicated and confusing.
> 
> Here's a suggestion ...
> 
> Apologies if some of the following is stating
> things that are obvious, I just try to give
> complete instructions.
> 
> We can make a helper command that shows us
> exactly what the shell does to any arguments
> before it sends them to a command.
> 
> First we need a name for this helper command.
> Let's use the name show_args.bash, but you
> can use whatever name you like.
> 
> I suggest this name because it is unlikely to
> already be in use on your system. Let's check:
> 
> $ type show_args.bash
> bash: type: show_args.bash: not found
> 
> Ok, that name is not in use, so let's use it.
> We are not going to put this command into
> the PATH so name collision doesn't really
> matter, but I'm just giving ideas and trying
> to be thorough.
> 
> Open your favourite editor and create
> a file that contains the next paragraph
> (use cut and paste if possible, it must be
> exactly as shown):
> 
> #!/bin/bash
> printf '%s' "$# args:"
> printf ' [%s]' "$@"
> printf '\n'
> 
> Save this file with the name: show_args.bash
> 
> Now make that file executable:
> 
> $ chmod -v u+x show_args.bash
> mode of 'show_args.bash' changed from 0640 (rw-r-) to 0740 (rwxr-)
> 
> Now we have created a command that just
> displays the arguments that it receives from
> the shell.
> 
> The command is in the current directory
> and not in the PATH, so we need to specify
> its location when invoking it: ./show_args.bash
> 
> Here's what it shows for a couple of commands
> that you had trouble with.
> 
> $ ./show_args.bash locate --regex \/\.gitignore
> 3 args: [locate] [--regex] [/.gitignore]
> 
> The above shows that your attempt to put \.
> into the regex did not work because the shell
> removed that escape-quoting.
> 
> $ ./show_args.bash locate --regex '/\.gitignore'
> 3 args: [locate] [--regex] [/\.gitignore]
> 
> The above shows that adding single quotes
> prevented that quote removal and the \.
> remained in the regex argument that was
> seen by locate.
> 
> A helper command like this is useful when
> trying to apply the explanations at:
> http://mywiki.wooledge.org/Quotes
> to your own requirements.

Re: RFC Debian and Xfce daily desktop on Dell Latitude 54XX

[David Christensen]

On 2019-12-02 21:32, deloptes wrote:

David Christensen wrote:


debian-user:

Is anyone running Debian and Xfce as a daily desktop on a Dell Latitude
54XX laptop?  If so, please comment.


David

https://wiki.debian.org/InstallingDebianOn/Dell/Latitude5480

https://wiki.debian.org/InstallingDebianOn/Dell/Latitude5490


I have 5440. Never tried UEFI, but could do soon. I am also not using Xfce.
The computer works just fine - no issues for the past 5y. I think I bought
it in 2015.


Thanks for the reply.  :-)


Do you use X?  If so, which display manager or desktop?  What are the 
hardware specs and how does it hold up with heavy desktop usage?



David

p.s.  I should have stated that I am looking to replace my daily driver, 
a hot-rodded 2007 Dell Inspiron E1505 with over-spec Core 2 Duo 7400 
processor, max RAM (2 GB, dual channel), 60 GB Intel Series 520 SSD, 
1280x800 display, Stretch, and Xfce.  It has a hard time keeping up with 
multiple Firefox browsers and/or tabs, 720p video can be marginal, and 
Fast Ethernet just isn't fast enough any more.

calibre mobile read forum?

[Karen Lewellen]

Any one here use calibre and a part of the mobile read forum?
I wish to join, but the contact form uses captcha.
A private answer may be best.
thanks,
karen

Re: RFC Debian and Xfce daily desktop on Dell Latitude 54XX

[deloptes]

David Christensen wrote:

> Thanks for the reply.  :-)
> 
> 
> Do you use X?  If so, which display manager or desktop?  What are the
> hardware specs and how does it hold up with heavy desktop usage?

Yes X and TDE former KDE3 as display manager (might be exotic to some, but
it is so stable and has such a small footprint that the community could not
give it up).
Regarding heavy desktop use - it has 4 cores and AES in the CPU - it has no
problem to work on encrypted partition and compile stuff while watching
youtube.
The GPU is Intel. (I took the cheapest - I think it was about 800,- brand
new). I don't do games or video/audio processing - though I have used some
video/audio tools.

hope this helps

PS: Latitude is much better than Inspiron - I even think they can not be
compared. But you can try TDE on Inspiron as well

Re: Postgresql logging problem

[Johann Spies]

Solved: changing the ownership of the custom log in conf.d solved the
problem.

Regards
Johann

On Tue, 3 Dec 2019 at 17:14, Johann Spies  wrote:

> We have upgraded two servers by installing postgresql(pgpd) 12.  Both
> servers are running Debian Stable.
>
> On the problem server we have:
> pg_lsclusters
> Ver Cluster Port Status OwnerData directory  Log file
> 11  main5432 online postgres /var/lib/postgresql/11/main
> /var/log/postgresql/postgresql-11-main.log
> 12  main5434 online postgres /var/lib/postgresql/12/main
> /var/log/postgresql/postgresql-12-main.log
>
> But nothing gets written to the logfiles.  In stead the logs appear on the
> console when the user postgresql is connecting to the database.
>
> On the other server:
> $ pg_lsclusters
> Ver Cluster Port Status OwnerData directory  Log file
> 11  main5433 down   postgres /var/lib/postgresql/11/main
> /var/log/postgresql/postgresql-11-main.log
> 12  main5432 online postgres /var/lib/postgresql/12/main
> /var/log/postgresql/postgresql-12-main.log
>
> The logging works as expected.
>
> The postgresql.conf for version 12 is identical on both servers - the
> default installed by Debian.
>
> This is with logging_collector off.
>
> When switching logging_collector  on on the problem server, it logs to
> /var/lib/postgresql/11/main/log/.
>
> Our preference would be to have the logs on both servers in
> /var/log/postgresql.
>
> Where do we look for the cause of this behaviour?  On both servers the
> configuration for rsyslog seems to be identical.
>
> Regards.
>
> Johann
>
>
>
> --
> Because experiencing your loyal love is better than life itself,
> my lips will praise you.  (Psalm 63:3)
>


-- 
Because experiencing your loyal love is better than life itself,
my lips will praise you.  (Psalm 63:3)