Re: [Evolution] Compose plain text emails that render well on MS Outlook

2022-08-31 Thread Jorge P. de Morais Neto via evolution-list
Hi.  I reply below:

Em [2022-08-28 dom 13:29:29+0100], Pete Biggs escreveu:

> If your work requires you to use HTML emails, then I suspect it's a
> battle not worth fighting.  However when you use HTML, Evolution
> surrounds the sig with   to try and maintain it's integrity
> and that seems to work OK for me.  Perhaps you just need to adjust your
> sig so that it looks OK after Outlook has done things to it.

The situation is a bit disappointing, but anyway I thank you for
replying.

Regards,
  Jorge
-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: https://www.fsf.org/free-software-supporter
- If an email of mine arrives at your spam box, please notify me.
___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list


Re: [Evolution] Restoring Evolution

2022-08-31 Thread Patrick O'Callaghan
On Wed, 2022-08-31 at 07:46 -0400, Adam Tauno Williams wrote:
> On Wed, 2022-08-31 at 11:22 +0200, Milan Crha via evolution-list
> wrote:
> > On Wed, 2022-08-31 at 09:57 +0100, Pete Biggs wrote:
> > > In the past, when the config
> > > was stored in dconf, it was a bit more complicated since the
> > > dconf
> > > keys needed to be dumped and then backed up. But now everything
> > > is
> > > stored in .config/evolution.
> > for what it's worth, most of the things in the Preferences (and in
> > other parts) are still stored in the GSettings, which usually means
> > DConf, which the backup/restore does back up and restore. 
> 
> This is a useful addendum to any backup:
> 
>    gsettings list-recursively
> 
> My backup procedure dumps the output of that to a file that is
> included
> in the backup.  You can dump a 'restored' system and diff the two
> files
> to discover what you had changed [but have no recollection of] and
> restore the setting(s) using the same command.
> 
Good tip.

poc
___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list


Re: [Evolution] Restoring Evolution

2022-08-31 Thread Adam Tauno Williams
On Wed, 2022-08-31 at 11:22 +0200, Milan Crha via evolution-list wrote:
> On Wed, 2022-08-31 at 09:57 +0100, Pete Biggs wrote:
> > In the past, when the config
> > was stored in dconf, it was a bit more complicated since the dconf
> > keys needed to be dumped and then backed up. But now everything is
> > stored in .config/evolution.
> for what it's worth, most of the things in the Preferences (and in
> other parts) are still stored in the GSettings, which usually means
> DConf, which the backup/restore does back up and restore. 

This is a useful addendum to any backup:

   gsettings list-recursively

My backup procedure dumps the output of that to a file that is included
in the backup.  You can dump a 'restored' system and diff the two files
to discover what you had changed [but have no recollection of] and
restore the setting(s) using the same command.

-- 
Adam Tauno Williams  GPG D95ED383
OpenGroupware Developer 

___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list


Re: [Evolution] Restoring Evolution

2022-08-31 Thread Milan Crha via evolution-list
On Tue, 2022-08-30 at 10:29 -0400, Adam Tauno Williams wrote:
> The only reliable mechanism to verify a tar archive is valid is to
> table it.  :(

Hi,
I opened:
https://gitlab.gnome.org/GNOME/evolution/-/issues/2011
for this, thus it's not forgotten.
Bye
Milan

___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list


Re: [Evolution] Restoring Evolution

2022-08-31 Thread Milan Crha via evolution-list
On Wed, 2022-08-31 at 10:44 +0100, Pete Biggs wrote:
> Is backup-restore-gsettings.ini only generated when you create a
> backup or is it part of the usual operation of Evolution?

Hi,
it's created by the backup/restore only.

> Also, mine is over 2Mb, is that normal?

Not really. I guess you receive reminders, but you do not dismiss them,
at least not within the evolution-alarm-notify. Some desktop
environments (like the GNOME) make it hard to spot pending reminders
due to hidden/non-existent system tray.

When you set in Evolution Edit->Preferences->Calendar and Tasks->
Reminders->Display Reminders window with notifications, then the next
time a reminder will trigger you'll see a window, which, I guess, will
be full of past events.

There is filled a bug for it:
https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/234
The used workaround there is something I do not like, but it's at least
something which will cleanup the setting for users whom do not have
better choice (and whom do not know about the growing setting).

Bye,
Milan

___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list


Re: [Evolution] Restoring Evolution

2022-08-31 Thread Pete Biggs
On Wed, 2022-08-31 at 11:22 +0200, Milan Crha via evolution-list wrote:
> On Wed, 2022-08-31 at 09:57 +0100, Pete Biggs wrote:
> > In the past, when the config
> > was stored in dconf, it was a bit more complicated since the dconf
> > keys needed to be dumped and then backed up. But now everything is
> > stored in .config/evolution.
> 
>   Hi,
> for what it's worth, most of the things in the Preferences (and in
> other parts) are still stored in the GSettings, which usually means
> DConf, which the backup/restore does back up and restore. Without that
> the tweaks the users do in the Preferences would be lost.

Sorry, I was looking for where those settings were backed up but
couldn't find it.  I thought it would be under .config but I now see
that it's under .local/share.

Is backup-restore-gsettings.ini only generated when you create a backup
or is it part of the usual operation of Evolution?  Also, mine is over
2Mb, is that normal?

P.
___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list


Re: [Evolution] Restoring Evolution

2022-08-31 Thread Milan Crha via evolution-list
On Wed, 2022-08-31 at 09:57 +0100, Pete Biggs wrote:
> In the past, when the config
> was stored in dconf, it was a bit more complicated since the dconf
> keys needed to be dumped and then backed up. But now everything is
> stored in .config/evolution.

Hi,
for what it's worth, most of the things in the Preferences (and in
other parts) are still stored in the GSettings, which usually means
DConf, which the backup/restore does back up and restore. Without that
the tweaks the users do in the Preferences would be lost.
Bye,
Milan

___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list


Re: [Evolution] “cannot VACUUM from within a transaction”

2022-08-31 Thread Joakim Tjernlund via evolution-list
On Wed, 2022-08-31 at 11:12 +0200, Milan Crha via evolution-list wrote:
> On Tue, 2022-08-30 at 16:28 +0200, Joakim Tjernlund wrote:
> > maybe it depends on number of emails to purge?
> 
>   Hi,
> that's correct, the vacuum is not run always, only when it looks like
> it could help.
> 
> Thanks for the backtrace (from the other mail in this thread), it's
> helpful. I'll look on this soon and will update the bug report when I
> have anything.

Funny thing, now I get this error every time I purge emails, even when Deleted 
Items is empty.
But if I restart Evo it will be gone.

 JOcke
___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list


Re: [Evolution] “cannot VACUUM from within a transaction”

2022-08-31 Thread Milan Crha via evolution-list
On Tue, 2022-08-30 at 16:28 +0200, Joakim Tjernlund wrote:
> maybe it depends on number of emails to purge?

Hi,
that's correct, the vacuum is not run always, only when it looks like
it could help.

Thanks for the backtrace (from the other mail in this thread), it's
helpful. I'll look on this soon and will update the bug report when I
have anything.
Bye,
Milan

___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list


Re: [Evolution] Restoring Evolution

2022-08-31 Thread Pete Biggs


> 
> If the file size was too large for the file system, it still doesn't
> explain why there was no standard error stream and appropriate exit
> status. Such an event would have caused error messages.

I think you need to consider how the backup process is run.  Normally
people start Evolution from the GUI - click on an icon etc. The backup
process is that the when you click the menu item, it starts an external
program which closes Evolution and it's associated factories, does the
backup, then restarts Evolution.  In that process, because you didn't
start Evolution from the command line, there's nowhere for any messages
to appear, and because it restarts Evolution before terminating,
there's no return code to Evolution to indicate an error occurred and
there's no parent process to display the error. 


P.

___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list


Re: [Evolution] Restoring Evolution

2022-08-31 Thread Pete Biggs
On Tue, 2022-08-30 at 11:51 -0500, c. marlow wrote:
> > > On Tue, 2022-08-30 at 11:49 +0100, Pete Biggs wrote:
> 
> > > > I would possibly go as far as to say that that particular
> > > > functionality
> > > > has run its course and could be consigned to the big bit-bucket
> > > > in
> > > > the
> > > > sky.  
> 
> SEVERELY DISAGREE... I'd go back to Claws if the backup / restore
> feature was removed from Evo.

What about if there was an external program - say something called
'evolution-backup' - that you could run to do a backup. Is it
absolutely necessary to have it as a menu item?

> 
> Even though I fully use IMAP now with Fastmail, I still use the
> Backup / Restore feature to restore the years of emails I have stored
> under " Saved on this computer" I think is what it says..  Also,  the
> backup and restore feature, restores not only my email but my account
> information too, to where when the restore is done, all I have to do
> is input my passwords and boom! I am back up and running in like 10
> sec.

There's nothing magical about the Evolution backup. It is just a gzip
tar file of .local/share/evolution (for the mail files) and
.config/evolution (for the configuration). In the past, when the config
was stored in dconf, it was a bit more complicated since the dconf keys
needed to be dumped and then backed up. But now everything is stored in
.config/evolution.  That's also why a much better way of dealing with
backups is to use standard backup procedures with versioning and so on
- then just restore the two directories from the nightly backups like
anything else you need to recover. 


P.

___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list


Re: [Evolution] Restoring Evolution

2022-08-31 Thread Ralf Mardorf via evolution-list
On Tue, 2022-08-30 at 21:33 -0700, Mr. J wrote:
> So there's something about the process or
> the external hard drive (or both?) that prevents the creation of a
> valid .tar.gz backup file on my hard drive.  It was recently
> formatted, so I'm at a loss to explain.

Hi,

while even a brand new drive could be broken, I'm still sceptic. Drives
have got mechanisms to detect and mark bad blocks and to automagically
rewrite data. It could happen that a block was ok when writing and got
broken 10 minutes later when trying to read, this is possible, but not
much likely and it unlikely was a write error, the drive couldn't
workaround, since such a write error more or less without doubts would
have caused error messages.

On Tue, 2022-08-30 at 22:20 -0700, Mr.J wrote:
> That’s IT, I think. The external drive is formatted in FAT, and not
> exFAT. If both .tar.gz files were over 4gb, I (over) cooked my own
> goose. Talk about noobie errors.

If the file size was too large for the file system, it still doesn't
explain why there was no standard error stream and appropriate exit
status. Such an event would have caused error messages.

As already mentioned by previous mails, tar doesn't always provide error
messages when something goes wrong and the exit status could be 0, even
if an archive is corrupted, _but_ any IO error, e.g. a write error due
to a hardware issue or a violation of the size limit does cause error
messages. This is at least what I experienced.

Assuming you are using Linux, if you don't share the drive among
different operating systems, consider to format the partition/s with
ext4.

I'm usually using ext4 only and sometimes a very small FAT32 partition
for BIOS usage. To share data between Linux and iPadOS by an external
drive, I'm using hfs+. Unfortunately hfs+ isn't well supported by Linux.
Each time the drive was connected to iPadOS, I need to run fsck.hfsplus
on Linux, bevor I can more or less safely write to the drive. Very
seldom data gets lost without notification and seemingly for no reason.
"Very seldom" is still way to often for backup purpose. Whatever kind of
FAT is used, it doesn't hold UNIX-alike information used by Linux and
iPadOS. OTOH this UNIX-alike information might be irrelevant when
sharing data among Linux and iPadOS. In short, I still don't know what
file system I'll use in the future for this shared data.

For convenience I run Windows 11 as well as older Windows releases
neither on bare metal, nor as a QEMU/KVM guest or something similar, but
as a VirtualBox guest on a Linux host, hence sharing files among Linux
and Windows neither requires a special server, nor a non-Linux file
system. Unfortunately even the VirtualBox Oracle branded binaries are
often a PITA, not that much as from packages provided by distros, but
still a problem child.

Sharing data among operating systems isn't fun! It's half-baked crap and
file systems used for sharing data shouldn't be used for backups. Yes,
tar does hold UNIX-alike information inside the archive, FAT is better
supported than hfs+, but it's still not a good choice for Linux backups.

Regards,
Ralf
___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list