Re: Strange failure on SL and ML buildslaves

On Jan 3, 2013, at 11:15 AM, Ryan Schmidt wrote: > > On Jan 3, 2013, at 10:33, William Siegrist wrote: > >> The ML slave was not logged in, the Lion and SL slaves were logged in. I did >> not explicitly set the slaves up to stay logged in or not, so let me know >> how you want them to behave

Re: Where to include port version in 'port pkg' output?

On 01/03/2013 04:09 PM, Rainer Müller wrote:> On 2013-01-04 00:49, Blair Zajac wrote: >>> Also, should we put the epoch number into the generated pkg and mpkg >>> filenames? I'm going to add it to the version number: >>> >>> ${epoch}.${portversion}.${portrevision} >> >> I decided to drop the epo

Re: Where to include port version in 'port pkg' output?

On 2013-01-04 00:49, Blair Zajac wrote: >> Also, should we put the epoch number into the generated pkg and mpkg >> filenames? I'm going to add it to the version number: >> >> ${epoch}.${portversion}.${portrevision} > > I decided to drop the epoch number since Apple docs suggest there's only > thr

Checksum in statefile (was: Re: [101027] trunk/dports/graphics/libwmf/files/configure.ac.diff)

On 2013-01-03 09:45, Ryan Schmidt wrote: > When you make a change to a patchfile that will fix a build problem, you > should simultaneously make some change to the Portfile as well (any change: > could just be a whitespace change) so that any users who had a failed > configuration attempt becaus

Re: Where to include port version in 'port pkg' output?

On 01/03/2013 12:23 PM, Blair Zajac wrote: On 01/03/2013 02:49 AM, Joshua Root wrote: On 2013-1-3 09:23 , Blair Zajac wrote: On my testing on 10.7, the package that is generated from 'port pkg' doesn't contain any version info, so it looks like Mac OS X treats it as a 1.0 package. Given I don'

Re: automake-1.13 (and 1.14 planning)

On Jan 3, 2013, at 2:17 PM, Rainer Müller wrote: >> Note that the backwards incompatibilities in 1.14 will be less trivial to >> fix, so if you see any warnings about INCLUDES, renaming configure.in to >> configure.ac, or MKDIR_P, you should probably fix those now, so you don't >> get bit by

Re: automake-1.13 (and 1.14 planning)

On 2013-1-4 09:17 , Rainer Müller wrote: > On 2013-01-03 19:20, Jeremy Huddleston Sequoia wrote: >> There seem to be more ports than I realized failing due to automake-1.13. >> If you encounter build failure in a port due to automake-1.13, give this >> post-patch block a try: >> >> post-patch {

Re: automake-1.13 (and 1.14 planning)

On 2013-01-03 19:20, Jeremy Huddleston Sequoia wrote: > There seem to be more ports than I realized failing due to automake-1.13. If > you encounter build failure in a port due to automake-1.13, give this > post-patch block a try: > > post-patch { > reinplace {s:AM_CONFIG_HEADER(\(.*\))

Re: Where to include port version in 'port pkg' output?

On 01/03/2013 02:49 AM, Joshua Root wrote: On 2013-1-3 09:23 , Blair Zajac wrote: On my testing on 10.7, the package that is generated from 'port pkg' doesn't contain any version info, so it looks like Mac OS X treats it as a 1.0 package. Given I don't know anything about Mac OS X packaging and

Re: Where to include port version in 'port pkg' output?

On 2013-1-4 06:09 , Ryan Schmidt wrote: > > The disadvantage is that you get a package that is not a single file. Single > files can be downloaded easily from web servers, while older bundle-style > packages are actually directories which have to be zipped or put on a disk > image to be distrib

Re: Strange failure on SL and ML buildslaves

On Thu, Jan 3, 2013 at 4:19 AM, Joshua Root wrote: > The only real solution, AFAIK, is "don't do that", or handle the failure > gracefully. I'm open to suggestion on how to achieve this. Cheers Adam ___ macports-dev mailing list macports-dev@lists.ma

Re: Strange failure on SL and ML buildslaves

On Jan 3, 2013, at 10:33, William Siegrist wrote: > The ML slave was not logged in, the Lion and SL slaves were logged in. I did > not explicitly set the slaves up to stay logged in or not, so let me know how > you want them to behave and I'll make them consistent. Thanks. If you could have t

Re: automake-1.13 (and 1.14 planning)

On Jan 3, 2013, at 12:20, Jeremy Huddleston Sequoia wrote: > There seem to be more ports than I realized failing due to automake-1.13. If > you encounter build failure in a port due to automake-1.13, give this > post-patch block a try: > > post-patch { >reinplace {s:AM_CONFIG_HEADER

Re: Where to include port version in 'port pkg' output?

On Jan 3, 2013, at 12:53, Blair Zajac wrote: > On 1/3/13 10:33 AM, Joshua Root wrote: >> On 2013-1-4 05:22 , Blair Zajac wrote: >>> BTW, it appears that packages built on older Mac OS X releases do have >>> the package version number. >> >> Yeah, on <= 10.5 we build bundle packages which use an I

Re: Where to include port version in 'port pkg' output?

On 1/3/13 10:33 AM, Joshua Root wrote: On 2013-1-4 05:22 , Blair Zajac wrote: BTW, it appears that packages built on older Mac OS X releases do have the package version number. Yeah, on <= 10.5 we build bundle packages which use an Info.plist that we write (portpkg::write_info_plist). Flat pac

Re: Where to include port version in 'port pkg' output?

On 2013-1-4 05:22 , Blair Zajac wrote: > BTW, it appears that packages built on older Mac OS X releases do have > the package version number. Yeah, on <= 10.5 we build bundle packages which use an Info.plist that we write (portpkg::write_info_plist). Flat packages don't use Info.plist. BTW, you c

Re: Where to include port version in 'port pkg' output?

On 1/3/13 1:13 AM, Ryan Schmidt wrote: On Jan 2, 2013, at 16:23, Blair Zajac wrote: On my testing on 10.7, the package that is generated from 'port pkg' doesn't contain any version info, so it looks like Mac OS X treats it as a 1.0 package. In what way does the Installer use this version i

automake-1.13 (and 1.14 planning)

There seem to be more ports than I realized failing due to automake-1.13. If you encounter build failure in a port due to automake-1.13, give this post-patch block a try: post-patch { reinplace {s:AM_CONFIG_HEADER(\(.*\)):AC_CONFIG_HEADERS([\1]):} ${worksrcpath}/configure.ac re

Re: [101027] trunk/dports/graphics/libwmf/files/configure.ac.diff

On Jan 3, 2013, at 12:45 AM, Ryan Schmidt wrote: > > When you make a change to a patchfile that will fix a build problem, you > should simultaneously make some change to the Portfile as well (any change: > could just be a whitespace change) so that any users who had a failed > configuration a

Re: Strange failure on SL and ML buildslaves

On Jan 3, 2013, at 2:19 AM, Joshua Root wrote: > On 2013-1-3 19:10 , Adam Mercer wrote: >> Hi >> >> After I recent commit: >> >> >> >> I recieved emails from buildbot regarding a failure on SL and ML: >> >>

Re: Where to include port version in 'port pkg' output?

On 2013-1-3 09:23 , Blair Zajac wrote: > On my testing on 10.7, the package that is generated from 'port pkg' > doesn't contain any version info, so it looks like Mac OS X treats it as > a 1.0 package. > > Given I don't know anything about Mac OS X packaging and need this for > an internal project

Re: [100945] trunk/dports/net/fwknop/Portfile

On 2013-1-3 06:25 , Blair Zajac wrote: > So we use {} to mean choice? Since we're quoting, can we add |,so it > would be {BSD|GPL}? '|' is not recognised as a separator. It's a regular Tcl list. > BTW, there are other ports that have a mixture of licenses in them. For > example, the old Subvers

Re: Strange failure on SL and ML buildslaves

On 2013-1-3 19:10 , Adam Mercer wrote: > Hi > > After I recent commit: > > > > I recieved emails from buildbot regarding a failure on SL and ML: > > >

Re: Strange failure on SL and ML buildslaves

On Jan 3, 2013, at 02:10, Adam Mercer wrote: > After I recent commit: > > > > I recieved emails from buildbot regarding a failure on SL and ML: > > >

Re: Where to include port version in 'port pkg' output?

On Jan 2, 2013, at 16:23, Blair Zajac wrote: > On my testing on 10.7, the package that is generated from 'port pkg' doesn't > contain any version info, so it looks like Mac OS X treats it as a 1.0 > package. In what way does the Installer use this version info? Or, how are you determining th

Re: [101027] trunk/dports/graphics/libwmf/files/configure.ac.diff

On Jan 3, 2013, at 02:34, jerem...@macports.org wrote: > Revision: 101027 > https://trac.macports.org/changeset/101027 > Author: jerem...@macports.org > Date: 2013-01-03 00:34:48 -0800 (Thu, 03 Jan 2013) > Log Message: > --- > libwmf: Build with newer automake > > Modified

Re: [100840] trunk/dports/devel/automake/Portfile

This bump is causing a ton of build failures due to backwards incompatibilities. 1.14 will similarly introduce more incompatibilities. Can you please give notice ahead of time for 1.14 (maybe 2-3 weeks) in order to let maintainers of ports have time to test them and fix such issues before you

Re: [100993] trunk/dports/devel/csu/Portfile

On Jan 2, 2013, at 19:57, mfe...@macports.org wrote: > Revision: 100993 > https://trac.macports.org/changeset/100993 > Author: mfe...@macports.org > Date: 2013-01-02 17:57:20 -0800 (Wed, 02 Jan 2013) > Log Message: > --- > csu: more specific architecture support, including

Re: [101017] trunk/dports/science

On Jan 3, 2013, at 01:28, r...@macports.org wrote: > Revision: 101017 > https://trac.macports.org/changeset/101017 > Author: r...@macports.org > Date: 2013-01-02 23:28:55 -0800 (Wed, 02 Jan 2013) > Log Message: > --- > science/gstlal-inspiral: new port > > Added Paths: > -

Strange failure on SL and ML buildslaves

Hi After I recent commit: I recieved emails from buildbot regarding a failure on SL and ML: Looki