Re: CMake issue: binary (needed during build) links againts /opt/local/lib/foo.dylib

[Joshua Root]

On 2016-9-30 12:18 , Ryan Schmidt wrote:



On Sep 29, 2016, at 8:30 PM, Mojca Miklavec  wrote:

Hi,

Under
https://svn.macports.org/repository/macports/users/mojca/ports/tex/miktex

I have a preliminary port for MikTeX with the following problem:
   https://sourceforge.net/p/miktex/bugs/2485/

The developer was fast in fixing many issues, but this one is
something that probably doesn't affect linux users, so he cannot
easily test.

The problem is that a binary that is needed as part of the build
procedure gets built and links against /opt/local/lib/something.dylib.
Usually that would be desired, but in this case the library
something.dylib cannot be found before the package is installed. The
build system should thus first give the libraries the id of the build
path and only fix that at the very end of the build procedure, but
it's not entirely clear to me how to properly achieve that.

Does anyone with a deeper understanding of CMake build system have any
idea what to fix?


The solution is to set DYLD_FALLBACK_LIBRARY_PATH to the path where the library 
can be found at build time. Set that environment variable at the time that you 
want to run the program that needs the library.

I don't know how to accomplish that in cmake specifically.


Actually, this is a valid situation for using DYLD_LIBRARY_PATH. If you 
use DYLD_FALLBACK_LIBRARY_PATH, and there is an older version of the 
library installed in ${prefix}/lib, the linker will find that first and 
run the executable with it instead of the new version in the build dir.


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

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Leonardo Brondani Schenkel]

On 2016-09-29 22:58, Ken Cunningham wrote:

Hmmm. I get the same error today:

:info:build /opt/local/bin/clang-mp-3.7  -pipe -Os -arch x86_64  
-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -stdlib=libc++ 
-L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -o 
mutt_dotlock mutt_dotlock.o strndup.o strnlen.o wcscasecmp.o regex.o
:info:build Undefined symbols for architecture x86_64:
:info:build   "_safe_malloc", referenced from:
:info:build   _strndup in strndup.o
:info:build ld: symbol(s) not found for architecture x86_64


In which OS X version? I never encountered this failure until I got an 
e-mail from the buildbot (and the only failure I received was on 10.5 
PPC, not any other combination).


I have reported the failure upstream:
https://github.com/neomutt/neomutt/issues/168

The maintainer said it's a bug with autoconf and it'll be fixed in the 
next NeoMutt release. I have created a ticket to track the progress of 
fixing the build:

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

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

Re: CMake issue: binary (needed during build) links againts /opt/local/lib/foo.dylib

[Ryan Schmidt]

> On Sep 29, 2016, at 8:30 PM, Mojca Miklavec  wrote:
> 
> Hi,
> 
> Under
> https://svn.macports.org/repository/macports/users/mojca/ports/tex/miktex
> 
> I have a preliminary port for MikTeX with the following problem:
>https://sourceforge.net/p/miktex/bugs/2485/
> 
> The developer was fast in fixing many issues, but this one is
> something that probably doesn't affect linux users, so he cannot
> easily test.
> 
> The problem is that a binary that is needed as part of the build
> procedure gets built and links against /opt/local/lib/something.dylib.
> Usually that would be desired, but in this case the library
> something.dylib cannot be found before the package is installed. The
> build system should thus first give the libraries the id of the build
> path and only fix that at the very end of the build procedure, but
> it's not entirely clear to me how to properly achieve that.
> 
> Does anyone with a deeper understanding of CMake build system have any
> idea what to fix?

The solution is to set DYLD_FALLBACK_LIBRARY_PATH to the path where the library 
can be found at build time. Set that environment variable at the time that you 
want to run the program that needs the library.

I don't know how to accomplish that in cmake specifically.


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

CMake issue: binary (needed during build) links againts /opt/local/lib/foo.dylib

[Mojca Miklavec]

Hi,

Under
https://svn.macports.org/repository/macports/users/mojca/ports/tex/miktex

I have a preliminary port for MikTeX with the following problem:
https://sourceforge.net/p/miktex/bugs/2485/

The developer was fast in fixing many issues, but this one is
something that probably doesn't affect linux users, so he cannot
easily test.

The problem is that a binary that is needed as part of the build
procedure gets built and links against /opt/local/lib/something.dylib.
Usually that would be desired, but in this case the library
something.dylib cannot be found before the package is installed. The
build system should thus first give the libraries the id of the build
path and only fix that at the very end of the build procedure, but
it's not entirely clear to me how to properly achieve that.

Does anyone with a deeper understanding of CMake build system have any
idea what to fix?

Thank you very much,
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Ken Cunningham]

>> 
>> I for one am very happy that patches are accepted for older systems, unlike 
>> homebrew and fink.
> 
> Just curious: where did you get that information? 

Mojca, you are right, I should read footnotes - I have not personally tried to 
submit patches to those places, so I can't really say for sure they would not 
be accepted. 

thanks for the clarification. 


Ken

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

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Daniel J. Luke]

On Sep 29, 2016, at 6:09 PM, Brandon Allbery  wrote:
> The policy changed,

Do you have links to where this was discussed? I did some brief searching and 
couldn't find the discussion/decision.

> and it did so because Apple changed its policy to that as of 10.10. So with 
> 10.12 out Apple is providing security updates for 10.10 and up only (unless I 
> missed them changing it again).

As mentioned on this thread, Apple hasn't published a policy (that I'm aware 
of). If you've seen a published security update policy from Apple - I'd be very 
happy to be pointed to it.

-- 
Daniel J. Luke



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

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Mojca Miklavec]

On 30 September 2016 at 01:29, Ken Cunningham wrote:
>
> I for one am very happy that patches are accepted for older systems, unlike 
> homebrew and fink.

Just curious: where did you get that information? I'm not too familiar
with homebrew, but
https://github.com/Homebrew/brew/blob/master/docs/Installation.md#2
says

"10.10 or higher is recommended. 10.5 - 10.8 are supported on a
best-effort basis. For 10.4 and 10.5, see Tigerbrew."


We don't have any special branch for old OSes, Tiger works from the
same sources, but the rest of the claim holds pretty much the same way
for MP. The software will keep working [only] as long as someone with
the required hardware / skill / interest would be willing to fix
problems. If upstream drops support for older versions entirely,
there's little we can do (short of installing different versions for
different OSes or maintaining separate branches, none of which is
ideal).

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

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Ken Cunningham]

> When I updated the install page for Sierra, I left Mavericks on the list, 
> because that's good cut-off point, with Mavericks being the first OS X 
> version to use libc++ by default.
> 
> I concur with keeping more Mac operating system releases "supported" by 
> MacPorts, given Apple's increased frequency of releases (i.e. yearly), vs. 
> every two or three years as in the beforetime.


I for one am very happy that patches are accepted for older systems, unlike 
homebrew and fink. And based on the hoopla when osxfuse wouldn't build on 10.6, 
I think I'm not the only one... I certainly don't expect anyone to spend time 
to work on these fixes, but I'm happy the fixes are accepted (and usually 
improved :>). My fixes aren't always the elegant solutions, and I'm always very 
happy to learn the better way.

Just so people realize, though -- with relatively modest changes, and with 
Jeremy's libc++ update to Snow Leopard, there are almost no ports that I can't 
install on SL so far. 

glfw on SL is pegged at the last version.
qt5 is ugly - I'm hoping to help out / find a way with a qt5.3 or qt5.4 version 
- but there aren't many ports that require qt5 yet anyway.
That's about it.

In fact a very large number of ports install all the way back to Tiger without 
any problem at all. 

So although of course the future has to be and always will be the focus, I hope 
that supporting backwards is not considered a total waste of time, if it 
doesn't take much or any effort other than tweaking and committing a patch. 

I take great satisfaction in keeping these older machines out of the landfill 
and doing useful things, and MacPorts is a big part of that.

Thanks to all!

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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[Ryan Schmidt]

> On Sep 29, 2016, at 5:10 AM, René J.V. Bertin  wrote:
> 
> On Thursday September 29 2016 07:14:11 MacPorts wrote:
>> #49559: nepomuk-core can't be installed on a case-sensitive system
> 
> Hi,
> 
>> The new buildbot setup does not show this behavior, so I revbumped
>> nepomuk-core in r153339 so that all the packages are correctly rebuilt for
>> case-sensitive systems. See also #42904.
> 
> Ah, good news, because Qt5 and the KF5 frameworks have unfortunately 
> standardised the behaviour of using capitalised letters in C++ header 
> filenames. 

Someone needs to make it clear to them that this is not a good idea. Not all 
filesystems are case sensitive. Mac OS has been around since 1984, always by 
default with a case insensitive filesystem, and Mac OS is used by a lot more 
people than Linux, so nobody has any excuse to be surprised by this anymore or 
to ignore this problem.


> I've been thinking recently about how this kind of thing could be avoided, in 
> relation to my earlier question about the build directory. I toyed with the 
> idea that instead of being a simple subdirectory, ${workpath} could be the 
> mountpoint of a RW dmg with appropriate filesystem settings, like 
> case-sensitivity. 
> 
> But why do it only for ${workpath}; the whole of ${prefix} could be on a 
> case-sensitive RW dynamically-sized disk image (a sparse bundle?) that gets 
> created by the MacPorts installer, with some magic to get it to mount 
> automagically at the right time.
> 
> That would solve all case-sensitivity issues once and for all (or almost), 
> without need for telling users to convert their whole (boot) volume to 
> case-sensitivity. It's probably less easy to implement than it sounds, but 
> maybe it's something to consider?

This sound convoluted. Also remember that MacPorts is not confined to 
installing files in ${prefix}. Projects should not assume case sensitive 
filesystems.


> Something else: I seem to recall preprocessor errors either on `#include 
> ` or `#include ` even if the underlying system calls 
> (fopen("foo/foo.h","r") or fopen("Foo/Foo","r")) should succeed regardless 
> the exact case, on a case-insensitive HFS. I can no longer reproduce this, 
> but has that been a known issue at some point? Or is it just a figment of my 
> imagination (if not simply the result of a testing error)?

I don't recall that, but maybe I forgot.

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

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Ryan Schmidt]

> On Sep 29, 2016, at 5:42 PM, Rainer Müller  wrote:
> 
> When Apple switched to yearly releases, consensus in discussions was to
> support the last three releases of the Mac operating system. Anything
> older are legacy systems, for which we try to provide a working base and
> accept patches for ports. If something is broken on these older
> releases, maintainers should not invest their time to get it fixed -
> unless they have personal interest, in which case we cannot stop them
> anyway.
> 
> The only indicator of this policy seems to be our downloads page, which
> at the moment still lists OS X 10.9 Mavericks as non-legacy. I would
> move that to legacy once macOS 10.12 Sierra has been out for at least a
> month.
> 
> https://www.macports.org/install.php

When I updated the install page for Sierra, I left Mavericks on the list, 
because that's good cut-off point, with Mavericks being the first OS X version 
to use libc++ by default.

I concur with keeping more Mac operating system releases "supported" by 
MacPorts, given Apple's increased frequency of releases (i.e. yearly), vs. 
every two or three years as in the beforetime.

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

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Rainer Müller]

On 2016-09-30 00:09, Brandon Allbery wrote:
> On Thu, Sep 29, 2016 at 4:28 PM, Daniel J. Luke  > wrote:
> 
> On Sep 29, 2016, at 3:51 PM, Lawrence Velázquez  > wrote:
> > Our blanket policy is to support the three most recent major OS
> > versions.
> 
> unless policy has actually changed (and I somehow missed it), the
> policy is current release and one previous.
> [and if anything, the policy should be further restricted to only
> include OS releases still supported by Apple - ie those actively
> getting security updates]
> 
> 
> The policy changed, and it did so because Apple changed its policy to
> that as of 10.10. So with 10.12 out Apple is providing security updates
> for 10.10 and up only (unless I missed them changing it again).

I am not aware Apple has any public security policy.

Security updates just seem to happen when they want to. For example,
macOS 10.12 Sierra is the recommended update to fix security bugs
discovered and left vulnerable in OS X 10.11 El Capitan:

https://support.apple.com/en-us/HT207170


When Apple switched to yearly releases, consensus in discussions was to
support the last three releases of the Mac operating system. Anything
older are legacy systems, for which we try to provide a working base and
accept patches for ports. If something is broken on these older
releases, maintainers should not invest their time to get it fixed -
unless they have personal interest, in which case we cannot stop them
anyway.

The only indicator of this policy seems to be our downloads page, which
at the moment still lists OS X 10.9 Mavericks as non-legacy. I would
move that to legacy once macOS 10.12 Sierra has been out for at least a
month.

https://www.macports.org/install.php

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

Re: [153356] trunk/dports/gnome/gnucash

[Ryan Schmidt]

> On Sep 29, 2016, at 3:16 AM, dpo...@macports.org wrote:
> 
> Revision
> 153356
> Author
> dpo...@macports.org
> Date
> 2016-09-29 01:16:39 -0700 (Thu, 29 Sep 2016)
> Log Message
> 
> gnucash: fix +python27 variant (#43254)
> Modified Paths
> 
>   • trunk/dports/gnome/gnucash/Portfile
> Removed Paths
> 
>   • trunk/dports/gnome/gnucash/files/patch-configure-python.diff
> Diff
> 
> Modified: trunk/dports/gnome/gnucash/Portfile (153355 => 153356)
> 
> --- trunk/dports/gnome/gnucash/Portfile   2016-09-29 07:45:33 UTC (rev 
> 153355)
> +++ trunk/dports/gnome/gnucash/Portfile   2016-09-29 08:16:39 UTC (rev 
> 153356)
> 
> @@ -88,10 +88,16 @@
> 
>  
> 
>  post-patch {
> 
>  xinstall -m 755 ${filespath}/autogen.sh ${worksrcpath}
> 
> +system "cd ${worksrcpath} && ./autogen.sh"

You should use system's -W argument, rather than manually running cd:

system -W ${worksrcpath} "./autogen.sh"

However, you can't run autogen.sh in post-patch; the dependencies are not 
guaranteed to have been installed until the configure phase starts.


> +if {[variant_isset python27]} {
> +# Fix python exec_prefix
> +reinplace 
> "s|\\(PYTHON_EXEC_PREFIX=\\).*$|\\1${frameworks_dir}/Python.framework/Versions/2.7/|"
>  \
> +${worksrcpath}/configure
> +reinplace 
> "s|\\(PYTHON_PREFIX=\\).*$|\\1${frameworks_dir}/Python.framework/Versions/2.7/|"
>  \
> +${worksrcpath}/configure
> +}
> 
>  }
> 
>  
> 
> -configure.cmd ./autogen.sh && ./configure
> -
> 
>  configure.args--disable-dependency-tracking \
> 
>--disable-aqbanking \
> 
>--disable-ofx \
> 
> @@ -126,12 +132,14 @@
> 
>  
> 
>  default_variants +ofx +hbci
> 
>  
> 
> -# variant python27 description {Install Python bindings for Python 2.7} {
> -# #patchfiles-append patch-configure-python.diff
> -# depends_lib-append port:python27
> -# configure.args-append --enable-python
> -# configure.python ${prefix}/bin/python2.7
> -# }
> 
> +variant python27 description {Install Python bindings for Python 2.7} { 
> +depends_lib-append  port:python27 
> +set python_bindir ${frameworks_dir}/Python.framework/Versions/2.7/bin/ 
> +configure.args-append --enable-python \
> +  
> PYTHON_EXTRA_LDFLAGS=\"\`${python_bindir}/python2.7-config --ldflags\`\" \
> +  
> PYTHON_CPPFLAGS=\"\`${python_bindir}/python2.7-config --cflags\`\" 
> +configure.python${python_bindir}/python2.7 
> +} 
> 
>  
> 
>  post-activate {
> 
>  system "${prefix}/bin/gtk-update-icon-cache -f -t 
> ${prefix}/share/icons/hicolor"

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

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Lawrence Velázquez]

> On Sep 29, 2016, at 5:46 PM, Mojca Miklavec  wrote:
> 
>> On 29 September 2016 at 22:10, Leonardo Brondani Schenkel wrote:
>> 
>> 1. Should I open a ticket when a build broke to track the progress of fixing
>> it?
> 
> Yes.

I would encourage doing so. Sometimes old tickets have information that
proves useful elsewhere.

>> 2. In case a package simply cannot be built in an unsupported version/ arch
>> of OS X (because upstream won't fix it and I don't know how to fix it), is
>> it possible to blacklist that combination on the Portfile so the buildbot
>> won't attempt to build it and/or users will be notified if they try to
>> install that package on that combination?

If you really have no intention of attempting to support the old
platform, you can bail out in a pre-fetch stage (I think) with an error
message. It's much less than ideal, but it's better than failing with an
obtuse linking error or something.

>> When I feel that I need a
>> second pair of eyes, like in this case, should I prefer to contact first the
>> -user or -devel lists or upstream?
> 
> I would suggest macports-devel and/or upstream.
> 
> This is not something that plain users should be concerned about, it's
> clearly a "developer" issue. Whether asking on the -devel mailing list
> or upstream depends a bit on situation. You could do both.

Don't hesitate to email macports-dev about maintainence issues. That's
its raison d'être, after all.

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

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Brandon Allbery]

On Thu, Sep 29, 2016 at 4:28 PM, Daniel J. Luke  wrote:

> On Sep 29, 2016, at 3:51 PM, Lawrence Velázquez 
> wrote:
> > Our blanket policy is to support the three most recent major OS
> > versions.
>
> unless policy has actually changed (and I somehow missed it), the policy
> is current release and one previous.
> [and if anything, the policy should be further restricted to only include
> OS releases still supported by Apple - ie those actively getting security
> updates]


The policy changed, and it did so because Apple changed its policy to that
as of 10.10. So with 10.12 out Apple is providing security updates for
10.10 and up only (unless I missed them changing it again).

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

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Mojca Miklavec]

On 29 September 2016 at 22:10, Leonardo Brondani Schenkel wrote:
> On 2016-09-29 21:51, Lawrence Velázquez wrote:
>>
>> If the problem occurs on an earlier OS (as yours did), then it's up to
>> you. We'd like to keep ports working on as many systems as possible, but
>> you are not obligated to expend effort doing so. You should still report
>> the issue upstream, but upstream developers often don't want to support
>> legacy systems either. Sometimes you just have to choose between fixing
>> it yourself, opening a Trac ticket and hoping another intrepid dev takes
>> a crack at it, or leaving the port broken.
>
> Two general questions, and a concrete one:
>
> 1. Should I open a ticket when a build broke to track the progress of fixing
> it?

Yes.

But in case a build is (known to be) broken on PPC and if there is no
easy way to fix it, you can just as well make that clear in the
portfile itself. There's no real need to worry too much about such an
old platform.

> 2. In case a package simply cannot be built in an unsupported version/ arch
> of OS X (because upstream won't fix it and I don't know how to fix it), is
> it possible to blacklist that combination on the Portfile so the buildbot
> won't attempt to build it and/or users will be notified if they try to
> install that package on that combination?

See the thread "Determine before installation whether a port can be installed"

https://lists.macosforge.org/pipermail/macports-dev/2016-July/033286.html

(It's inconveniently spread among several months.)

> 3. In my specific case I'm a bit confused since the two missing symbols
> *are* defined in neomutt source code: 'safe_malloc' is in lib.c and
> 'strndup' in strndup.c. I can see both files being compiled
> (https://build.macports.org/builders/ports-10.5_ppc_legacy-builder/builds/5905/steps/install-port/logs/stdio)
> so I can't explain why later they are not found.

The following command doesn't link against lib.o though:

/usr/bin/gcc-4.2 -std=gnu99  -pipe -Os -arch ppc  -L/opt/local/lib
-Wl,-headerpad_max_install_names -arch ppc -L/opt/local/lib
-L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -o mutt_dotlock
mutt_dotlock.o strndup.o strnlen.o wcscasecmp.o regex.o


> When I feel that I need a
> second pair of eyes, like in this case, should I prefer to contact first the
> -user or -devel lists or upstream?

I would suggest macports-devel and/or upstream.

This is not something that plain users should be concerned about, it's
clearly a "developer" issue. Whether asking on the -devel mailing list
or upstream depends a bit on situation. You could do both.

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

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Ken Cunningham]

On 2016-09-29, at 12:26 PM, Leonardo Brondani Schenkel wrote:

> Hi,
> 
> I recently started maintaining some MacPorts packages. For the first time 
> today I got a message from the buildbot: apparently the neomutt package does 
> not build on OS X 10.5 PPC due to '_safe_malloc' being undefined 
> (https://build.macports.org/builders/ports-10.5_ppc_legacy-watcher/builds/632).
>  My first question is regarding the procedure for failed builds: what is it 
> expected that I as the maintainer should do in this case? Should I notify 
> upstream and so maybe we could come up with a patch? Something else?
> 
> After that mail I got dozens of mails today from the buildbot regarding other 
> unrelated packages, many just a few seconds or minutes apart. Is this 
> expected or was there a glitch? I don't get why I'm getting mails for 
> packages that I didn't change or maintain.
> 
> Maybe what I am asking is explained somewhere in the documentation, but 
> honestly I couldn't find it. I may be looking at the wrong place.



Hmmm. I get the same error today:

:info:build /opt/local/bin/clang-mp-3.7  -pipe -Os -arch x86_64  
-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -stdlib=libc++ 
-L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -o 
mutt_dotlock mutt_dotlock.o strndup.o strnlen.o wcscasecmp.o regex.o 
:info:build Undefined symbols for architecture x86_64:
:info:build   "_safe_malloc", referenced from:
:info:build   _strndup in strndup.o
:info:build ld: symbol(s) not found for architecture x86_64


I see he recently added it:

2016-06-04 11:32 -0700  Kevin McCarthy    (39639dc7e9e7)

* sidebar.c: Fix sidebar check_sec.sh warnings.

Use safe_malloc, FREE, and the safe_strcat functions.



==

and it seems to be defined here:
neomutt-20160916/rfc822.c


#if HAVE_CONFIG_H
# include "config.h"
#endif

#include 
#include 

#ifndef TESTING
#include "mutt.h"
#else
#define safe_strdup strdup
#define safe_malloc malloc
#define FREE(x) safe_free(x)
#define strfcpy(a,b,c) {if (c) {strncpy(a,b,c);a[c-1]=0;}}
#define LONG_STRING 1024
#include "rfc822.h"
#endif


and so I thought if I defined TESTING in config.h that might work -- 

/* config.h.  Generated from config.h.in by configure.  */
/* config.h.in.  Generated from configure.ac by autoheader.  */

#define TESTING 1

but it generate other errors.

Does this build for you?

Ken






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

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Daniel J. Luke]

On Sep 29, 2016, at 3:51 PM, Lawrence Velázquez  wrote:
> Our blanket policy is to support the three most recent major OS
> versions.

unless policy has actually changed (and I somehow missed it), the policy is 
current release and one previous.

[and if anything, the policy should be further restricted to only include OS 
releases still supported by Apple - ie those actively getting security updates]

-- 
Daniel J. Luke



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

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Leonardo Brondani Schenkel]

On 2016-09-29 21:51, Lawrence Velázquez wrote:

If the problem occurs on an earlier OS (as yours did), then it's up to
you. We'd like to keep ports working on as many systems as possible, but
you are not obligated to expend effort doing so. You should still report
the issue upstream, but upstream developers often don't want to support
legacy systems either. Sometimes you just have to choose between fixing
it yourself, opening a Trac ticket and hoping another intrepid dev takes
a crack at it, or leaving the port broken.


Two general questions, and a concrete one:

1. Should I open a ticket when a build broke to track the progress of 
fixing it?


2. In case a package simply cannot be built in an unsupported version/ 
arch of OS X (because upstream won't fix it and I don't know how to fix 
it), is it possible to blacklist that combination on the Portfile so the 
buildbot won't attempt to build it and/or users will be notified if they 
try to install that package on that combination?


3. In my specific case I'm a bit confused since the two missing symbols 
*are* defined in neomutt source code: 'safe_malloc' is in lib.c and 
'strndup' in strndup.c. I can see both files being compiled 
(https://build.macports.org/builders/ports-10.5_ppc_legacy-builder/builds/5905/steps/install-port/logs/stdio) 
so I can't explain why later they are not found. When I feel that I need 
a second pair of eyes, like in this case, should I prefer to contact 
first the -user or -devel lists or upstream?


Thanks,
Leonardo.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Lawrence Velázquez]

> On Sep 29, 2016, at 3:51 PM, Lawrence Velázquez  wrote:
> 
>> On Sep 29, 2016, at 3:26 PM, Leonardo Brondani Schenkel
>>  wrote:
>> 
>> After that mail I got dozens of mails today from the buildbot
>> regarding other unrelated packages, many just a few seconds or minutes
>> apart. Is this expected or was there a glitch? I don't get why I'm
>> getting mails for packages that I didn't change or maintain.
> 
> This is a known bug in our configuration that we are attempting to
> address: https://trac.macports.org/ticket/52446

It is fixed: https://trac.macports.org/changeset/153387

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

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Lawrence Velázquez]

> On Sep 29, 2016, at 3:26 PM, Leonardo Brondani Schenkel
>  wrote:
> 
> I recently started maintaining some MacPorts packages. For the first
> time today I got a message from the buildbot: apparently the neomutt
> package does not build on OS X 10.5 PPC due to '_safe_malloc' being
> undefined
> (https://build.macports.org/builders/ports-10.5_ppc_legacy-watcher/builds/632).
> My first question is regarding the procedure for failed builds: what
> is it expected that I as the maintainer should do in this case? Should
> I notify upstream and so maybe we could come up with a patch?
> Something else?

Our blanket policy is to support the three most recent major OS
versions. As of right now, that means Yosemite, El Capitan, and Sierra.
If you receive a failure notification from one of the relevant
buildslaves, you are expected to do something about it. Ideally you
would report the problem to upstream, who would then develop a general
fix that benefits all users. If the problem is not with the software
itself but with our packaging, hopefully upstream would be kind enough
to help you fix that. If upstream is uninterested for some reason,
you'll have to fix everything yourself and consider whether it's worth
maintaining a port with such an uncooperative upstream.

If the problem occurs on an earlier OS (as yours did), then it's up to
you. We'd like to keep ports working on as many systems as possible, but
you are not obligated to expend effort doing so. You should still report
the issue upstream, but upstream developers often don't want to support
legacy systems either. Sometimes you just have to choose between fixing
it yourself, opening a Trac ticket and hoping another intrepid dev takes
a crack at it, or leaving the port broken.

> After that mail I got dozens of mails today from the buildbot
> regarding other unrelated packages, many just a few seconds or minutes
> apart. Is this expected or was there a glitch? I don't get why I'm
> getting mails for packages that I didn't change or maintain.

This is a known bug in our configuration that we are attempting to
address: https://trac.macports.org/ticket/52446

> Maybe what I am asking is explained somewhere in the documentation,
> but honestly I couldn't find it. I may be looking at the wrong place.

We don't really have much documentation on the Buildbot infrastructure.

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

I'm a newbie mantainer and I'm confused about the buildbot

[Leonardo Brondani Schenkel]

Hi,

I recently started maintaining some MacPorts packages. For the first 
time today I got a message from the buildbot: apparently the neomutt 
package does not build on OS X 10.5 PPC due to '_safe_malloc' being 
undefined 
(https://build.macports.org/builders/ports-10.5_ppc_legacy-watcher/builds/632). 
My first question is regarding the procedure for failed builds: what is 
it expected that I as the maintainer should do in this case? Should I 
notify upstream and so maybe we could come up with a patch? Something else?


After that mail I got dozens of mails today from the buildbot regarding 
other unrelated packages, many just a few seconds or minutes apart. Is 
this expected or was there a glitch? I don't get why I'm getting mails 
for packages that I didn't change or maintain.


Maybe what I am asking is explained somewhere in the documentation, but 
honestly I couldn't find it. I may be looking at the wrong place.


Thanks in advance for any help,
Leonardo.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

l3afpad port

[Russell Jones]

Hi all,

Could someone review and commit https://trac.macports.org/ticket/52246 
please?


Russell

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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[René J . V . Bertin]

On Thursday September 29 2016 07:14:11 MacPorts wrote:
>#49559: nepomuk-core can't be installed on a case-sensitive system

Hi,

> The new buildbot setup does not show this behavior, so I revbumped
> nepomuk-core in r153339 so that all the packages are correctly rebuilt for
> case-sensitive systems. See also #42904.

Ah, good news, because Qt5 and the KF5 frameworks have unfortunately 
standardised the behaviour of using capitalised letters in C++ header 
filenames. 

I've been thinking recently about how this kind of thing could be avoided, in 
relation to my earlier question about the build directory. I toyed with the 
idea that instead of being a simple subdirectory, ${workpath} could be the 
mountpoint of a RW dmg with appropriate filesystem settings, like 
case-sensitivity. 

But why do it only for ${workpath}; the whole of ${prefix} could be on a 
case-sensitive RW dynamically-sized disk image (a sparse bundle?) that gets 
created by the MacPorts installer, with some magic to get it to mount 
automagically at the right time.

That would solve all case-sensitivity issues once and for all (or almost), 
without need for telling users to convert their whole (boot) volume to 
case-sensitivity. It's probably less easy to implement than it sounds, but 
maybe it's something to consider?

Something else: I seem to recall preprocessor errors either on `#include 
` or `#include ` even if the underlying system calls 
(fopen("foo/foo.h","r") or fopen("Foo/Foo","r")) should succeed regardless the 
exact case, on a case-insensitive HFS. I can no longer reproduce this, but has 
that been a known issue at some point? Or is it just a figment of my 
imagination (if not simply the result of a testing error)?

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