Bob,
Super! Thanks!
The treatment of stock images was something of a moving target in Gtk3 so you
may have to do some config/cmake work to figure out what to use and then
conditionally compile based the result. We do need to look good on 3.10-3.22
and everything in between. I think complaints
> On Jun 16, 2017, at 1:40 PM, Geert Janssens
> wrote:
>
> On vrijdag 16 juni 2017 19:25:25 CEST Adrien Monteleone wrote:
>> Adrien Monteleone
>> adrien.montele...@gmail.com
>> 337-593-8208
>> 103 Rosalind street
>> Lafayette, Louisiana
>>
>>> On Jun 16, 2017, at 2:47 AM, Geert Janssens
>>>
On vrijdag 16 juni 2017 19:25:25 CEST Adrien Monteleone wrote:
> Adrien Monteleone
> adrien.montele...@gmail.com
> 337-593-8208
> 103 Rosalind street
> Lafayette, Louisiana
>
> > On Jun 16, 2017, at 2:47 AM, Geert Janssens
> > wrote:
> >
> > My (limited) experience is with drupal as well.
> >
>
I just pulled down a copy of GnuCash.org with SiteSucker. Total size is 228MB,
210MB of which are docs in various formats and translations. (ePub, etc.)
There is less than 1MB of images, though I’d suppose that may change in the
future.
And this is uncompressed.
The site itself is nill. The in
Derek,
> On Jun 16, 2017, at 10:33 PM, Derek Atkins wrote:
>
> Adrien Monteleone writes:
>
>>> A side effect of the content being in a db rather than in git is it is no
>>> longer stored in a distributed way. So it will be important to implement a
>>> backup plan for the data.
>>
>> The sit
On Fri, 16 Jun 2017, Jon Daley wrote:
On Fri, 16 Jun 2017, Derek Atkins wrote:
Jon Daley writes:
How much data do you have that needs to be backed up? I have
space that I can offer, depending on how big it is.
Right now the backup volume uses 645GB:
[root@freenas] ~# df -h /mnt/fre
On Fri, 16 Jun 2017, Derek Atkins wrote:
Jon Daley writes:
How much data do you have that needs to be backed up? I have
space that I can offer, depending on how big it is.
Right now the backup volume uses 645GB:
[root@freenas] ~# df -h /mnt/freenas-0/backups/
Filesystem Si
On Fri, 16 Jun 2017, Adrien Monteleone wrote:
On Jun 16, 2017, at 11:54 AM, Jon Daley wrote:
On Fri, 16 Jun 2017, Derek Atkins wrote:
Code performs a nightly mysql dump, and I have a nightly backup of all
my servers (including code) to a backup server with storage on my
FreeNAS box. This is al
Jon Daley writes:
> On Fri, 16 Jun 2017, Derek Atkins wrote:
>> Code performs a nightly mysql dump, and I have a nightly backup of all
>> my servers (including code) to a backup server with storage on my
>> FreeNAS box. This is all completely automated. The only thing I do not
>> have, yet, is
Adrien Monteleone writes:
> Then I don’t suppose it’s a major issue. You’d just need a backup of
> public_html (or WWW folder, whichever is used) like is probably being
> done now, and a dump of whatever db is used for the cms. Since there
> is already a dump of the wiki db, it would just be an e
Adrien Monteleone writes:
>> A side effect of the content being in a db rather than in git is it is no
>> longer stored in a distributed way. So it will be important to implement a
>> backup plan for the data.
>
> The site host should provide a facility for this either through
> cPanel/Plex, or
On vrijdag 16 juni 2017 18:58:35 CEST Adrien Monteleone wrote:
> Then I don’t suppose it’s a major issue. You’d just need a backup of
> public_html (or WWW folder, whichever is used) like is probably being done
> now, and a dump of whatever db is used for the cms. Since there is already
> a dump of
On vrijdag 16 juni 2017 18:58:35 CEST Adrien Monteleone wrote:
> Then I don’t suppose it’s a major issue. You’d just need a backup of
> public_html (or WWW folder, whichever is used) like is probably being done
> now, and a dump of whatever db is used for the cms. Since there is already
> a dump of
Adrien Monteleone
adrien.montele...@gmail.com
337-593-8208
103 Rosalind street
Lafayette, Louisiana
> On Jun 16, 2017, at 2:47 AM, Geert Janssens
> wrote:
>
> My (limited) experience is with drupal as well.
>
> Regarding your first question (how to map version management on a cms driven
> we
> On Jun 16, 2017, at 11:54 AM, Jon Daley wrote:
>
> On Fri, 16 Jun 2017, Derek Atkins wrote:
>> Code performs a nightly mysql dump, and I have a nightly backup of all
>> my servers (including code) to a backup server with storage on my
>> FreeNAS box. This is all completely automated. The onl
Then I don’t suppose it’s a major issue. You’d just need a backup of
public_html (or WWW folder, whichever is used) like is probably being done now,
and a dump of whatever db is used for the cms. Since there is already a dump of
the wiki db, it would just be an extra one of those for the cms db.
On Fri, 16 Jun 2017, Derek Atkins wrote:
Code performs a nightly mysql dump, and I have a nightly backup of all
my servers (including code) to a backup server with storage on my
FreeNAS box. This is all completely automated. The only thing I do not
have, yet, is a an offsite backup plan to prot
Hi,
Geert Janssens writes:
> That goes for the current wiki as well by the way. Do we have a backup in
> place there ?
Code performs a nightly mysql dump, and I have a nightly backup of all
my servers (including code) to a backup server with storage on my
FreeNAS box. This is all completely a
OK, I have been tapping away with the following progress...
I downgraded a clone VM to Gtk+3.10.8 which successfully builds and runs
but I seem to of lost some stock images, not an issue as I can temporary
replace them
but I can use it to make sure I have not included any newer functions.
In the
> On Jun 16, 2017, at 8:30 AM, Adrien Monteleone
> wrote:
>
>>
>> On Jun 16, 2017, at 2:47 AM, Geert Janssens
>> wrote:
>>
>> My (limited) experience is with drupal as well.
>>
>> Regarding your first question (how to map version management on a cms driven
>> website): usually only the cm
> On Jun 16, 2017, at 2:47 AM, Geert Janssens
> wrote:
>
> My (limited) experience is with drupal as well.
>
> Regarding your first question (how to map version management on a cms driven
> website): usually only the cms code, modules and themes are version managed.
> The data resides in a d
My (limited) experience is with drupal as well.
Regarding your first question (how to map version management on a cms driven
website): usually only the cms code, modules and themes are version managed.
The data resides in a database which is not well suited for version
management. So code, modu
22 matches
Mail list logo