Re: hugin build bug

[Ryan Schmidt]

> On Mar 18, 2015, at 9:02 PM, Ludwig  wrote:
> 
> Trac seems to be down so I'm leaving this here before I forget.
> 
> hugin-app @2013.0.0_7 build configuration fails to find lensfun even though it
> is installed, @0.3.0_0.  main.log attached.

We know. This will be resolved by updating the port to version 2014.0.0. There 
is an open ticket. I need to work on this.


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

hugin build bug

[Ludwig]

Trac seems to be down so I'm leaving this here before I forget.

hugin-app @2013.0.0_7 build configuration fails to find lensfun even though it
is installed, @0.3.0_0.  main.log attached.




main.log.xz
Description: Binary data


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

Re: Announce: OpenSSH 6.8 released (fwd)

[Dave Horsfall]

On Wed, 18 Mar 2015, Lawrence Velázquez wrote:

> https://trac.macports.org/ticket/47190

Ah; someone beat me to it.  I was so busy notifying other lists that I 
forgot about MacPorts...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Announce: OpenSSH 6.8 released (fwd)

[Lawrence Velázquez]

On Mar 18, 2015, at 4:46 PM, Dave Horsfall  wrote:

> Someone might want to take a look at this; both the BSD people and the 
> Penguins are all over it.

https://trac.macports.org/ticket/47190

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

Announce: OpenSSH 6.8 released (fwd)

[Dave Horsfall]

Someone might want to take a look at this; both the BSD people and the 
Penguins are all over it.

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

-- Forwarded message --
Date: Wed, 18 Mar 2015 00:56:51 -0600 (MDT)
From: Damien Miller
To: openssh-unix-annou...@mindrot.org
Subject: [openssh-unix-announce] Announce: OpenSSH 6.8 released

OpenSSH 6.8 has just been released. It will be available from the
mirrors listed at http://www.openssh.com/ shortly.

OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.

Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested snapshots or donated to the
project. More information on donations may be found at:
http://www.openssh.com/donations.html

Changes since OpenSSH 6.7
=

This is a major release, containing a number of new features as
well as a large internal re-factoring.

Potentially-incompatible changes


 * sshd(8): UseDNS now defaults to 'no'. Configurations that match
   against the client host name (via sshd_config or authorized_keys)
   may need to re-enable it or convert to matching against addresses.

New Features


 * Much of OpenSSH's internal code has been re-factored to be more
   library-like. These changes are mostly not user-visible, but
   have greatly improved OpenSSH's testability and internal layout.

 * Add FingerprintHash option to ssh(1) and sshd(8), and equivalent
   command-line flags to the other tools to control algorithm used
   for key fingerprints. The default changes from MD5 to SHA256 and
   format from hex to base64.

   Fingerprints now have the hash algorithm prepended. An example of
   the new format: SHA256:mVPwvezndPv/ARoIadVY98vAC0g+P/5633yTC4d/wXE
   Please note that visual host keys will also be different.

 * ssh(1), sshd(8): Experimental host key rotation support. Add a
   protocol extension for a server to inform a client of all its
   available host keys after authentication has completed. The client
   may record the keys in known_hosts, allowing it to upgrade to better
   host key algorithms and a server to gracefully rotate its keys.

   The client side of this is controlled by a UpdateHostkeys config
   option (default off).

 * ssh(1): Add a ssh_config HostbasedKeyType option to control which
   host public key types are tried during host-based authentication.

 * ssh(1), sshd(8): fix connection-killing host key mismatch errors
   when sshd offers multiple ECDSA keys of different lengths.

 * ssh(1): when host name canonicalisation is enabled, try to
   parse host names as addresses before looking them up for
   canonicalisation. fixes bz#2074 and avoiding needless DNS
   lookups in some cases.

 * ssh-keygen(1), sshd(8): Key Revocation Lists (KRLs) no longer
   require OpenSSH to be compiled with OpenSSL support.

 * ssh(1), ssh-keysign(8): Make ed25519 keys work for host based
   authentication.

 * sshd(8): SSH protocol v.1 workaround for the Meyer, et al,
   Bleichenbacher Side Channel Attack. Fake up a bignum key before
   RSA decryption.

 * sshd(8): Remember which public keys have been used for
   authentication and refuse to accept previously-used keys.
   This allows AuthenticationMethods=publickey,publickey to require
   that users authenticate using two _different_ public keys.

 * sshd(8): add sshd_config HostbasedAcceptedKeyTypes and
   PubkeyAcceptedKeyTypes options to allow sshd to control what
   public key types will be accepted. Currently defaults to all.

 * sshd(8): Don't count partial authentication success as a failure
   against MaxAuthTries.

 * ssh(1): Add RevokedHostKeys option for the client to allow
   text-file or KRL-based revocation of host keys.

 * ssh-keygen(1), sshd(8): Permit KRLs that revoke certificates by
   serial number or key ID without scoping to a particular CA.

 * ssh(1): Add a "Match canonical" criteria that allows ssh_config
   Match blocks to trigger only in the second config pass.

 * ssh(1): Add a -G option to ssh that causes it to parse its
   configuration and dump the result to stdout, similar to "sshd -T".

 * ssh(1): Allow Match criteria to be negated. E.g. "Match !host".

 * The regression test suite has been extended to cover more OpenSSH
   features. The unit tests have been expanded and now cover key
   exchange.

Bugfixes

 * ssh-keyscan(1): ssh-keyscan has been made much more robust again
   servers that hang or violate the SSH protocol.

 * ssh(1), ssh-keygen(1): Fix regression bz#2306: Key path names were
   being lost as comment fields.

 * ssh(1): Allow ssh_config Port options set in the second config
   parse phase to be applied (they were being ignored). bz#2286

 * ssh(1): Twea

Re: [MacPorts] #47189: submission: audacity

[Christopher Jones]

> On 18 Mar 2015, at 6:11pm, René J.V. Bertin  wrote:
> 
> On Wednesday March 18 2015 13:52:49 Arno Hautala wrote:
> 
>> Cool. I wonder if there's still an issue of sometimes using internal
>> versions and sometimes using MacPorts, but as the internal versions
>> aren't available yet, it seems like a minor issue if any. My internal
> 
> When trace mode becomes the default, that issue certainly won't exist any 
> longer...
> 
>> pedant would want the configure to explicitly use the internal
>> versions and explicitly select the available MacPorts versions, but
>> the pedant must be crushed.
> 
> Well, it's not impossible to tell configure to use the internal versions of 
> the things that don't exist in MacPorts yet, but is that really necessary? 
> They seem so specialised that there must be little chance anyone but port 
> maintainers would have them installed before installing Audacity, which means 
> they'd only get installed if port:audacity requires them explicitly…

Thats an assumption, and you know what happens with assumptions. They come back 
and bite you when you least expect it…

To my mind you should configure audacity to *always* use the internal versions, 
to prevent this happening in the future.




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: [MacPorts] #47189: submission: audacity

[Christopher Jones]

> On 18 Mar 2015, at 5:52pm, Arno Hautala  wrote:
> 
> On Wed, Mar 18, 2015 at 1:20 PM, René J.V.  wrote:
>> On Wednesday March 18 2015 12:10:07 Arno Hautala wrote:
>> 
>> So, no, there should be no fear of non-reproducible builds, at least not if 
>> I got in all the dependencies :)
>> 
>>> Regardless, I'd think the configure would still need to be set up to
>>> only use the internal or MacPorts versions.
>> 
>> Which is what it does.
> 
> Cool. I wonder if there's still an issue of sometimes using internal
> versions and sometimes using MacPorts, but as the internal versions
> aren't available yet, it seems like a minor issue if any. My internal
> pedant would want the configure to explicitly use the internal
> versions and explicitly select the available MacPorts versions, but
> the pedant must be crushed.

No, I would agree with you. Even if no ports for the various used ‘local’ 
components exist, for future protection the audacity port should be configured 
to *always* use its internal versions, regardless of what might or might not be 
available via macports (or worse elsewhere). That way the builds remain 
predictable. If at some point ports for one or other of these internal 
components become available, then the audacity port can be, if desired, updated 
to depend upon and use that port. Everything remains deterministic, which is 
how it should be.

Chris

> 
> Thanks for posting. I look forward to it being approved.
> 
> --Arno
> 
> -- 
> arno  s  hautala/-|   a...@alum.wpi.edu
> 
> pgp b2c9d448
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users



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: [MacPorts] #47189: submission: audacity

[René J . V . Bertin]

On Wednesday March 18 2015 13:52:49 Arno Hautala wrote:

> Cool. I wonder if there's still an issue of sometimes using internal
> versions and sometimes using MacPorts, but as the internal versions
> aren't available yet, it seems like a minor issue if any. My internal

When trace mode becomes the default, that issue certainly won't exist any 
longer...

> pedant would want the configure to explicitly use the internal
> versions and explicitly select the available MacPorts versions, but
> the pedant must be crushed.

Well, it's not impossible to tell configure to use the internal versions of the 
things that don't exist in MacPorts yet, but is that really necessary? They 
seem so specialised that there must be little chance anyone but port 
maintainers would have them installed before installing Audacity, which means 
they'd only get installed if port:audacity requires them explicitly...

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

Re: [MacPorts] #47189: submission: audacity

[Arno Hautala]

On Wed, Mar 18, 2015 at 1:20 PM, René J.V.  wrote:
> On Wednesday March 18 2015 12:10:07 Arno Hautala wrote:
>
> So, no, there should be no fear of non-reproducible builds, at least not if I 
> got in all the dependencies :)
>
>> Regardless, I'd think the configure would still need to be set up to
>> only use the internal or MacPorts versions.
>
> Which is what it does.

Cool. I wonder if there's still an issue of sometimes using internal
versions and sometimes using MacPorts, but as the internal versions
aren't available yet, it seems like a minor issue if any. My internal
pedant would want the configure to explicitly use the internal
versions and explicitly select the available MacPorts versions, but
the pedant must be crushed.

Thanks for posting. I look forward to it being approved.

--Arno

-- 
arno  s  hautala/-|   a...@alum.wpi.edu

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

Re: [MacPorts] #47189: submission: audacity

[René J . V . Bertin]

On Wednesday March 18 2015 12:10:07 Arno Hautala wrote:

> features should be disabled until they are available in MacPorts. Or,
> by "local version" do you mean part of the Audacity source tree?

Yes. They call that local, I just used their terminology.
So, no, there should be no fear of non-reproducible builds, at least not if I 
got in all the dependencies :)

> Regardless, I'd think the configure would still need to be set up to
> only use the internal or MacPorts versions.

Which is what it does.

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

Re: [MacPorts] #47189: submission: audacity

[Arno Hautala]

On Wed, Mar 18, 2015 at 8:54 AM, René J.V.  wrote:
> There
>  are a few required components which are not in MacPorts and for which a
>  local version is used: libsms, libsoxr, libvamp, portsmf and widgetextra.
>  Audacity's configure script will detect and use the "system" versions when
>  available, so it will be easy to adapt the port if any of these are
>  considered useful beyond Audacity and added to MacPorts.

Isn't this behavior to be avoided in ports? The configure script
detecting these wont produce replicable builds. I'd think those
features should be disabled until they are available in MacPorts. Or,
by "local version" do you mean part of the Audacity source tree?
Regardless, I'd think the configure would still need to be set up to
only use the internal or MacPorts versions.

-- 
arno  s  hautala/-|   a...@alum.wpi.edu

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

Fwd: [MacPorts] #47189: submission: audacity

[René J . V . Bertin]

For anyone interested in this kind of application: I just submitted a port for 
audacity.

R.

--  Forwarded Message  --

Subject: [MacPorts] #47189: submission: audacity
Date: Wednesday March 18 2015, 11:01:17
From: MacPorts 
To: rjvber...@gmail.com, macports-tick...@lists.macosforge.org
CC: h...@macports.org

#47189: submission: audacity
-+
 Reporter:  rjvbertin@…  |  Owner:  macports-tickets@…
 Type:  submission   | Status:  new
 Priority:  Normal   |  Milestone:
Component:  ports|Version:
 Keywords:   |   Port:  audacity
-+
 I don't think I have to introduce Audacity to anyone here. What many may
 not realise though is that Audacity uses wxWidgets 2.8 (even the current
 2.1.0 release candidate), which means it cannot run in native, 64bit mode
 (and is tricky to build on OS X versions newer than 10.6).
 I think an audio editor can reap many benefits from running in 64bit, so I
 spent some time figuring out how to build Audacity against
 `port:wxgtk-2.8`, which *does* allow 64bit builds. The result is attached.
 Lost in the process are only 2 things:

 - QuickTime import, which depends on QuickTime. Sadly inevitable as QT is
 32bit only and the SDK is no longer shipped.
 - AudioUnit plugins. This is only because those depend on a UI that uses
 platform-specific APIs. An experienced wxWidgets programmer may actually
 be able to port that to something that builds against wxGTk.

 The shared libraries aside (MP3Lame and the FFMpeg libav libraries) I have
 tried to preserve as many of the data and config locations as possible, so
 that this and the Audacity "distribution version" share as much as
 possible.

 This port uses `port:portaudio` and depends on a new patch for that port
 which has been submitted (https://trac.macports.org/ticket/47172). There
 are a few required components which are not in MacPorts and for which a
 local version is used: libsms, libsoxr, libvamp, portsmf and widgetextra.
 Audacity's configure script will detect and use the "system" versions when
 available, so it will be easy to adapt the port if any of these are
 considered useful beyond Audacity and added to MacPorts.

-- 
Ticket URL: 
MacPorts 
Ports system for OS X
-
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users