On Nov 18, 2015, at 5:34 PM, Bradley Giesbrecht wrote:
>> On Nov 18, 2015, at 3:14 PM, nore...@macports.org wrote:
>>
>> The Buildbot has detected a failed build on builder
>> buildports-yosemite-x86_64 while building MacPorts.
>> Full details are available at:
>> http://build.macports.org/buil
> On Nov 18, 2015, at 3:14 PM, nore...@macports.org wrote:
>
> The Buildbot has detected a failed build on builder
> buildports-yosemite-x86_64 while building MacPorts.
> Full details are available at:
> http://build.macports.org/builders/buildports-yosemite-x86_64/builds/6247
>
> Buildbot URL:
the livecheck for maven31 doesn't correctly work and also maven 3.1.x is no
longer actively maintained so their won't be anymore updates.
could this enhancement be merged.
cheers,
john
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http
>
> Replying to [comment:4 ryandesign@…]:
>> [...]
>
>>
>> It doesn't look like the static variant does anything. If the user does
> not select the static variant, the static libraries should not be built.
>
> When the user selects the static build of cpp-netlib there is no need to
> change the
If there would be only readers, locking would not be necessary. When
there is a single concurrent writer, locking is necessary, otherwise the
reader could see inconsistent state (e.g. partial writes in the
database, or in the file system, or in the interaction between these).
Most systems use p
On 2015-11-18 12:52, René J.V. Bertin wrote:
> I agree that there should be a lock that prevents concurrent access
> to the registry database, as that's something that appears likely to
> lead to registry corruption. If the registry lock were to be set when
> doing an (un)install or (de)activate, i
On Wednesday November 18 2015 10:08:25 Rainer Müller wrote:
> The registry lock needs to be taken when the action relies on the set of
> installed ports. For example, when a 'port build' is running, you should
> not be able to uninstall a dependency at the same time.
Frankly? That's a risk-less o
On 2015-11-18 09:44, René J.V. Bertin wrote:
> On Tuesday November 17 2015 18:56:39 Ryan Schmidt wrote:
>
>> "port list" is a read-only operation; there's no reason why it would need to
>> set a lock nor be restricted by a lock.
>
> And AFAIK so is everything that does not involve `port install`
On Tuesday November 17 2015 18:56:39 Ryan Schmidt wrote:
>"port list" is a read-only operation; there's no reason why it would need to
>set a lock nor be restricted by a lock.
And AFAIK so is everything that does not involve `port install`, `port
uninstall`, `port activate` and `port deactivate
