On Friday April 08 2016 21:07:15 Clemens Lang wrote:
Hi,
> So your registry wasn't broken, apparently?
Apparently. I guess we'll never know.
> I think I have previously had situations where the database seemed to be
> rather slow and re-creating fixed it. I did not investigate further,
> thoug
Hi,
On Wed, Apr 06, 2016 at 03:08:09PM +0200, René J. V. Bertin wrote:
> That doesn't teach me much new
> %> bunzip2 < /opt/local/var/macports/registry/registry-corrupt.db.bz2 > kk.db
> %> /opt/local/bin/sqlite3 kk.db
> %> .load MacPorts-svn/src/cregistry/macports.sqlext
> %> pragma integrity_chec
Clemens Lang wrote:
Hi,
> http://serverfault.com/questions/8048/how-can-i-verify-that-a-sqlite-db3-file-is-valid-consistent
>
> See also
> https://trac.macports.org/browser/trunk/base/src/cregistry/README.sqlext
That doesn't teach me much new
%> bunzip2 < /opt/local/var/macports/registry/regist
Hi,
On Mon, Apr 04, 2016 at 07:04:46PM +0200, René J.V. Bertin wrote:
> How would one check that (without putting my whole install at risk)?
http://serverfault.com/questions/8048/how-can-i-verify-that-a-sqlite-db3-file-is-valid-consistent
See also
https://trac.macports.org/browser/trunk/base/src
On Monday April 04 2016 18:52:08 Clemens Lang wrote:
>However, now I'm interested why the backup worked flawlessly, but
>MacPorts failed to open the registry. Maybe there was something wrong
>with one of the indexes in the database (which wouldn't be used when
>doing a full dump or backup, but are
> On Apr 4, 2016, at 9:45 AM, Bradley Giesbrecht wrote:
>
>> On Apr 4, 2016, at 9:42 AM, René J. V. Bertin wrote:
>>
>> Bradley Giesbrecht wrote:
>>
>>> Did you keep a copy of the registry? If so, try opening it with the sqlite
>>> client.
>>
>> Thanks for the suggestion. Curiously that went
On Mon, Apr 04, 2016 at 06:42:24PM +0200, René J. V. Bertin wrote:
> Thanks for the suggestion. Curiously that went just fine, but it also
> seems to contradict the previous claim that any interaction with an
> sqlite3 db modifies it.
No, any writing interaction modifies it (that should be obvious
> On Apr 4, 2016, at 9:42 AM, René J. V. Bertin wrote:
>
> Bradley Giesbrecht wrote:
>
>> Did you keep a copy of the registry? If so, try opening it with the sqlite
>> client.
>
> Thanks for the suggestion. Curiously that went just fine, but it also seems
> to
> contradict the previous claim
Bradley Giesbrecht wrote:
> Did you keep a copy of the registry? If so, try opening it with the sqlite
> client.
Thanks for the suggestion. Curiously that went just fine, but it also seems to
contradict the previous claim that any interaction with an sqlite3 db modifies
it. I did a .dump which
> On Apr 3, 2016, at 2:31 AM, René J.V. Bertin wrote:
>
> Hi,
>
> I just went through a bit of a hairy exercise. With a bit too much
> distraction and hurry going on I did a `port upgrade --force` of a port I'd
> just rebuilt from source so I forgot both the -s and t
On 2016-04-03 16:02, Clemens Lang wrote:
> On Sun, Apr 03, 2016 at 11:19:33PM +1000, Joshua Root wrote:
>> Not if they have outdated dependencies. Upgrade without -n is a
>> recursive operation.
>
> Good point.
>
>> Not passing the --force flag on to the deps by default would be ok I
>> guess, bu
ports::global_options(ports_nodeps)]} {
set macports::global_options(ports_nodeps) yes
set orig_nodeps no
}
}}}
which seems weird as it suggests that global_options(ports_nodeps) is set to
yes (equivalent to using -n) when it doesn't exist ... which would be the
o
On 2016-4-4 03:01 , Clemens Lang wrote:
Josh's answer sounds like it's not that much effort. I don't know,
however, I'm not very familiar with that part of MacPorts base.
I was more going for "Something could be done, but the situation is
perhaps more complex than you think, so do your homewor
afely copy a consistent representation of a database without
using the database access layer (on standard OS X filesystems), so this
achieves nothing: How would you ensure that the database isn't being
modified while you copy it?
> > I agree, upgrade --force should imply only rebuilding
of the
last known valid state.
I know I mentioned an offline procedure, but that was with launchd's
file-watching feature in mind which would trigger the copy after each change to
the file. But there are other solutions of course, like forking a script that
does the copy in the backgroun
On Sun, Apr 03, 2016 at 11:19:33PM +1000, Joshua Root wrote:
> Not if they have outdated dependencies. Upgrade without -n is a
> recursive operation.
Good point.
> Not passing the --force flag on to the deps by default would be ok I
> guess, but what if the user wants that?
Doesn't the global -f
On 2016-4-3 22:41 , Clemens Lang wrote:
I agree, upgrade --force should imply only rebuilding the given ports.
Not if they have outdated dependencies. Upgrade without -n is a
recursive operation. Not passing the --force flag on to the deps by
default would be ok I guess, but what if the user
y.
Only if the contents are the same, which isn't the case in general when
the backup is a day old. Doing this kind of recovery automatically would
silently introduce corrupted data -- a very bad idea.
> In addition, what do you think of using the existing prompting
> mechanisms
Hi,
I just went through a bit of a hairy exercise. With a bit too much distraction
and hurry going on I did a `port upgrade --force` of a port I'd just rebuilt
from source so I forgot both the -s and the (crucial) -n options. Seeing the
resulting "reinstall all dependencies" beg
+1
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Under "port upgrade --force", wouldn't it be better to wait until the Portfile
is ready to activate the newly built port before deactivating and uninstalling
the existing port?
$ sudo port -n upgrade --force phonon
---> Computing dependencies for phonon
---> Cleaning p
21 matches
Mail list logo
