Re: de/activate and Time Machine

2016-04-28 Thread Bradley Giesbrecht 
> On Apr 28, 2016, at 12:35 AM, René J.V. Bertin  wrote:
> 
> On Wednesday April 27 2016 23:10:20 Brandon Allbery wrote:
> 
>> I was apparently headed into a brainfog when I wrote that.. recovered today
> 
> Heh, why do I seem to relate ... :)
> 
>> backup, found that there were port components not under /opt/local missing
>> (notably the symlinks into launchd's directories), and a
>> deactivate/reactivate fixed.
> 
> That also sounds familiar in the sense of been there, done that.
> 
> Good, so it should indeed be possible to come up with a script or the like 
> that sets up Time Machine to do only an "economic" kind of backing up of 
> ${prefix}. Supposing that all ports that do use site-specific configuration 
> files store those files under etc/ .

Apache2 (2.2) stores files in prefix/apache2. Apache24-devel (2.4) fixes that.


Regards,
Bradley Giesbrecht (pixilla)

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: de/activate and Time Machine

2016-04-28 Thread René J . V . Bertin 
On Thursday April 28 2016 08:38:35 Daniel J. Luke wrote:

> 
> IIRC there is some metadata that you can set to exclude a file from backup (a 
> little googling says it's probably 
> com.apple.metadata:com_apple_backup_excludeItem) 

I think the safest way to set or unset this is via the TM commandline utility 
(addexclusion/removexclusion); see man tmutil and the discussion of the 2 types 
of exclusion.

> - it might be interesting to patch base to set this (along with possibly 
> adding some sort of 'restore' action which will do the deactivate/reactivate 
> dance).

Yes, it certainly would. I was thinking of a script that would handle this, 
which would have the benefit of easier updating, but one could of course also 
set the sticky exclusion bit on every file during activation. In fact, that 
might resolve the whole question of how to filter files that *should* be backed 
up from those that are already backed up via the software image archive.
It'd probably still be a good idea to do a directory-level exclude of those 
directories that shouldn't ever hold files that aren't part of a port, esp. if 
they can contain huge numbers of files (share/doc, share/locale, include).

Annoyingly the metadata bit set by `tmutil addexclusion foo` doesn't show up 
with `mdls foo`.

R.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: de/activate and Time Machine

2016-04-28 Thread Langer, Stephen A. (Fed) 
Would it be simpler if macports automatically kept a list of the requested
ports somewhere outside of /opt/local?  Then *all* of /opt/local could be
excluded from Time Machine backups, but could be easily (if not
necessarily quickly) restored by reinstalling the requested ports?

— Steve


On 4/28/16, 3:35 AM, "macports-users-boun...@lists.macosforge.org on
behalf of René J.V. Bertin"  wrote:

>On Wednesday April 27 2016 23:10:20 Brandon Allbery wrote:
>
>>I was apparently headed into a brainfog when I wrote that.. recovered
>>today
>
>Heh, why do I seem to relate ... :)
>
>>backup, found that there were port components not under /opt/local
>>missing
>>(notably the symlinks into launchd's directories), and a
>>deactivate/reactivate fixed.
>
>That also sounds familiar in the sense of been there, done that.
>
>Good, so it should indeed be possible to come up with a script or the
>like that sets up Time Machine to do only an "economic" kind of backing
>up of ${prefix}. Supposing that all ports that do use site-specific
>configuration files store those files under etc/ .
>I'll try to find a moment to figure out to what extent keeping an
>additional list of which ports are active is required.
>
>I just think of a complication though. The port command is installed in
>bin/ together with a few others, and there are probably libraries "base"
>uses that live in lib/ . It's probably possible to add those to Time
>Machine's filter list but it does make the idea a bit less appealing.
>
>R.
>___
>macports-users mailing list
>macports-users@lists.macosforge.org
>https://lists.macosforge.org/mailman/listinfo/macports-users

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: de/activate and Time Machine

2016-04-28 Thread Daniel J. Luke 
On Apr 28, 2016, at 3:35 AM, René J.V. Bertin  wrote:
> Good, so it should indeed be possible to come up with a script or the like 
> that sets up Time Machine to do only an "economic" kind of backing up of 
> ${prefix}. Supposing that all ports that do use site-specific configuration 
> files store those files under etc/ .
> I'll try to find a moment to figure out to what extent keeping an additional 
> list of which ports are active is required.
> 
> I just think of a complication though. The port command is installed in bin/ 
> together with a few others, and there are probably libraries "base" uses that 
> live in lib/ . It's probably possible to add those to Time Machine's filter 
> list but it does make the idea a bit less appealing.

IIRC there is some metadata that you can set to exclude a file from backup (a 
little googling says it's probably 
com.apple.metadata:com_apple_backup_excludeItem) - it might be interesting to 
patch base to set this (along with possibly adding some sort of 'restore' 
action which will do the deactivate/reactivate dance).

-- 
Daniel J. Luke

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: de/activate and Time Machine

2016-04-28 Thread René J . V . Bertin 
On Wednesday April 27 2016 23:10:20 Brandon Allbery wrote:

>I was apparently headed into a brainfog when I wrote that.. recovered today

Heh, why do I seem to relate ... :)

>backup, found that there were port components not under /opt/local missing
>(notably the symlinks into launchd's directories), and a
>deactivate/reactivate fixed.

That also sounds familiar in the sense of been there, done that.

Good, so it should indeed be possible to come up with a script or the like that 
sets up Time Machine to do only an "economic" kind of backing up of ${prefix}. 
Supposing that all ports that do use site-specific configuration files store 
those files under etc/ .
I'll try to find a moment to figure out to what extent keeping an additional 
list of which ports are active is required.

I just think of a complication though. The port command is installed in bin/ 
together with a few others, and there are probably libraries "base" uses that 
live in lib/ . It's probably possible to add those to Time Machine's filter 
list but it does make the idea a bit less appealing.

R.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: de/activate and Time Machine

2016-04-27 Thread Brandon Allbery 
On Tue, Apr 26, 2016 at 1:26 PM, René J.V.  wrote:

> >I think you can rely on that for maybe 95% of things, but the remaining
> >5%... I've had to help people fix things afterward.
>
> Do you remember what kind of issue? I'm curious to know under what
> conditions "base" cares whether supposedly installed files are actually
> present when you do a deactivate? (Not that I ever pushed this to the
> limit...)


I was apparently headed into a brainfog when I wrote that.. recovered today
but catching up on stuff. And I think it was actually the opposite
situation that was happening: someone tried to restore /opt/local from a
backup, found that there were port components not under /opt/local missing
(notably the symlinks into launchd's directories), and a
deactivate/reactivate fixed.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: de/activate and Time Machine

2016-04-26 Thread Michael 
On 2016-04-26, at 7:47 AM, Geoffrey Odhner  wrote:

> I wish what you say were true, but Time Machine eventually can get to a point 
> where it requires you to delete everything or start a new backup volume.  
> This can happen when its size is considerably larger than the size of the 
> drive it's backing up.  I know this because it has happened to me.  When it 
> reaches that point it doesn't allow you to make ANY other changes, including 
> deleting directories in the backup that you could do without.  I exclude 
> /opt/local from backups, along with other folders that can be readily 
> reconstructed so that I won't run into this problem again.

How long ago was that? 

I've managed to delete stuff from the only existing backup in 1.7.10.
And, I discovered that if you change the "what is backed up" to only a single 
small partition, Time Machine will happily back that up, and then the other 
backup is now no longer the latest and should be deleteable.

(I did that to force a full re-backup, when I had reasons to distrust the 
completeness of the existing backup.)

> 
> Regards,
> 
> Geoff Odhner
>> On 4/26/2016 9:30:57 AM, Bachsau  wrote:
>> 
>> René J.V. Bertin wrote on 26.04.2016 13:19: 
>> > Superfluous backing up of course ends up wasting significant amount of 
>> > space on the backup disk esp. for developers who regularly to something 
>> > like `port -n upgrade --force` after an incremental rebuild with only 
>> > minimal changes. It is also costly in terms of time when you're using a 
>> > NAS like my Time Capsule (even when connected via a wired gigabit 
>> > connection). 
>> 
>> In default configuration time machine will automatically discard old 
>> backups in favor of new ones, so there shouldn't be any space problems 
>> ever. 
>> 
>> ___ 
>> macports-users mailing list 
>> macports-users@lists.macosforge.org 
>> https://lists.macosforge.org/mailman/listinfo/macports-users 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

---
Entertaining minecraft videos
http://YouTube.com/keybounce

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: de/activate and Time Machine

2016-04-26 Thread René J . V . Bertin 
On Tuesday April 26 2016 13:06:20 Brandon Allbery wrote:

>I think you can rely on that for maybe 95% of things, but the remaining
>5%... I've had to help people fix things afterward.

Do you remember what kind of issue? I'm curious to know under what conditions 
"base" cares whether supposedly installed files are actually present when you 
do a deactivate? (Not that I ever pushed this to the limit...)

R.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: de/activate and Time Machine

2016-04-26 Thread Brandon Allbery 
On Tue, Apr 26, 2016 at 1:02 PM, René J.V.  wrote:

> Is that really a problem? IIRC I've already had restored files that had
> "mysteriously" gone missing by (force) deactivating the corresponding port
> and then activating it again


I think you can rely on that for maybe 95% of things, but the remaining
5%... I've had to help people fix things afterward.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: de/activate and Time Machine

2016-04-26 Thread René J . V . Bertin 
On Tuesday April 26 2016 09:28:09 Brandon Allbery wrote:

>The registry's a bit of a risk, since it will be logically inconsistent if
>you aren't backing up the whole install. If I needed to worry about this,

Is that really a problem? IIRC I've already had restored files that had 
"mysteriously" gone missing by (force) deactivating the corresponding port and 
then activating it again. IOW, I don't have the impression that it is necessary 
that the registry be consistent with the contents under ${prefix}.
You *do* have to know what ports are active of course, but I presume that 
information is stored in the registry too.

OTOH it certainly wouldn't hurt to maintain a separate list. From what I have 
seen it is perfectly possible to take an image (tarball) from software/, put it 
in var/macports/incoming/verified, and then issue the corresponding install 
command. Evidently you probably don't want to do that for a whole install, 
unless there's a secret magic trick to force a port install without satisfying 
dependencies first (cf. dpkg -i vs. apt-get install).

>inactive dump and then running port activate over the active list. (Come to
>think of it. this means backing up /opt/local/etc separately so config

It's already being updated, no? The cheap approach would be to restore it a 2nd 
time, after doing the whole reinstall/re-activate dance.

>files don't possibly get overwritten. Yes, that would indicate Portfile
>bugs, but an emergency restore is the wrong time to discover and try to
>deal with those bugs.)

Amen to that!

Cheers,
René
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: de/activate and Time Machine

2016-04-26 Thread Geoffrey Odhner 
I wish what you say were true, but Time Machine eventually can get to a point 
where it requires you to delete everything or start a new backup volume.  This 
can happen when its size is considerably larger than the size of the drive it's 
backing up.  I know this because it has happened to me.  When it reaches that 
point it doesn't allow you to make ANY other changes, including deleting 
directories in the backup that you could do without.  I exclude /opt/local from 
backups, along with other folders that can be readily reconstructed so that I 
won't run into this problem again.

Regards,

Geoff Odhner

On 4/26/2016 9:30:57 AM, Bachsau  wrote:
René J.V. Bertin wrote on 26.04.2016 13:19:
> Superfluous backing up of course ends up wasting significant amount of space 
> on the backup disk esp. for developers who regularly to something like `port 
> -n upgrade --force` after an incremental rebuild with only minimal changes. 
> It is also costly in terms of time when you're using a NAS like my Time 
> Capsule (even when connected via a wired gigabit connection).

In default configuration time machine will automatically discard old
backups in favor of new ones, so there shouldn't be any space problems
ever.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: de/activate and Time Machine

2016-04-26 Thread Bachsau 

René J.V. Bertin wrote on 26.04.2016 13:19:

Superfluous backing up of course ends up wasting significant amount of space on 
the backup disk esp. for developers who regularly to something like `port -n 
upgrade --force` after an incremental rebuild with only minimal changes. It is 
also costly in terms of time when you're using a NAS like my Time Capsule (even 
when connected via a wired gigabit connection).


In default configuration time machine will automatically discard old 
backups in favor of new ones, so there shouldn't be any space problems 
ever.




smime.p7s
Description: S/MIME Cryptographic Signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: de/activate and Time Machine

2016-04-26 Thread Brandon Allbery 
On Tue, Apr 26, 2016 at 7:19 AM, René J.V.  wrote:

> Is there a good way to exclude most of MacPorts from being backed up while
> retaining the possibility to reinstall without rebuilding? I'm thinking of
> backing up selected bits from var/macports (notably the registry and
> software directory), probably etc/macports and libexec/macports. There's
> however the issue of user config files; are there designated locations to
> install such files?
> I have already excluded var/macports/{build,log}.
>

I back up /opt/local/etc for config files; otherwise, software/ is good to
keep archives.

The registry's a bit of a risk, since it will be logically inconsistent if
you aren't backing up the whole install. If I needed to worry about this,
I'd look to dump out just the registry parts relating to archives and write
that to somewhere that is backed up. This could be tricky, as you might
well need to munge entries relating to activated packages so they look like
inactive ones. You'd also want a simple record of what packages were
activated at the time, so the system could be reconstituted from the
inactive dump and then running port activate over the active list. (Come to
think of it. this means backing up /opt/local/etc separately so config
files don't possibly get overwritten. Yes, that would indicate Portfile
bugs, but an emergency restore is the wrong time to discover and try to
deal with those bugs.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

de/activate and Time Machine

2016-04-26 Thread René J . V . Bertin 
Hi,

I'm probably not the only one who noticed: after deactivating and reactivating 
a large port like Qt5, the next Time Machine backup announces (or at least 
claims) to have much more to backup that one would expect (over 1.5Gb in case 
for Qt5). That suggests that the backup engine looks at more than just file 
name, size and date alone; possibly taking the inode number or equivalent into 
account too.

Is there a good way to exclude most of MacPorts from being backed up while 
retaining the possibility to reinstall without rebuilding? I'm thinking of 
backing up selected bits from var/macports (notably the registry and software 
directory), probably etc/macports and libexec/macports. There's however the 
issue of user config files; are there designated locations to install such 
files?
I have already excluded var/macports/{build,log}.

Superfluous backing up of course ends up wasting significant amount of space on 
the backup disk esp. for developers who regularly to something like `port -n 
upgrade --force` after an incremental rebuild with only minimal changes. It is 
also costly in terms of time when you're using a NAS like my Time Capsule (even 
when connected via a wired gigabit connection).

Thanks,
René
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users