Re: question for the "base gurus"
On Tue, Jan 24, 2017 at 6:53 PM, René J.V. Bertin wrote: > 0775 (0001:1101) turning into 0255 (000:10101101), there's no > logical explanation (involving umask()) for that, is there? That is what you'd get if the *umask* were 0255. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: question for the "base gurus"
On Tuesday January 24 2017 22:57:17 Clemens Lang wrote: > > %> strace -o strace.log port -nok destroot foo > > %> strace port -nok destroot foo >& strace.log > > Remember that files that have been present in destroot before might > affect the result, too. Some ports' destroot phases are written in ways > that they cannot be repeated (that doesn't seem to be the case here, but > it's worth keeping it in mind). Of course. I didn't mention it, but I erased the whole destroot directory before making another attempt. I've a script for that which also "rewinds" the state file. > The only difference in MacPorts behavior I would expect here is the > check whether output is to a terminal. Between the 2 commands above? Indeed, but there must be subtle differences in the overall context. Strace inserts code to replace standard library functions with wrappers that generate trace output, and when that output doesn't go to file directly I'd expect it to end up in main.log (in practice I'm apparently wrong there). > > initialisation, but that shouldn't be possible. Not in install.c in > > any case, but could there be a reason to assume that the argument > > parsing goes wrong somewhere? > > If that's something you suspect, I recommend you compile a copy of > Pextlib with address sanitizer. Since Pextlib is probably dlopen(3)'d by Actually, I wasn't thinking about Pextlib here, because InstallCmd() is apparently called directly from the Tcl interpreter. I could use gcc's sanitiser on Tcl itself, of course. But I had another episode well after I posted my question, which allowed me to run the process through valgrind and got me a bit further after I made the xinstall -v option activate a verbose mode. Apparently the issue is not in Tcl or Pextlib, but in getmode()/setmode(): if and when things go wrong the 775 (sic) mode I'm requesting in the Portfile is translated to a mask of 0255. My distro version had an outdated libbsd; I'm not yet sure if the update I grabbed from a later distro version actually changes anything in the setmode/getmode functions, but at least valgrind no longer complains about using an uninitialised when called from InstallCmd. 0775 (0001:1101) turning into 0255 (000:10101101), there's no logical explanation (involving umask()) for that, is there? > > Either way, I think that install.c's install_dir() really shouldn't > > ignore chmod() errors silently ... > > Patch to add error checking welcome. I'll post a patch tomorrow. There *is* error checking, btw, there's just no action that's taken when an error does occur. I take it there's less interest in the part that makes the -v option turn on verbose mode? R.
Re: question for the "base gurus"
On Tue, Jan 24, 2017 at 04:22:39PM +0100, René J.V. Bertin wrote:
> I have mentioned before that I sometimes get permissions errors during
> the destroot phase because directories created with xinstall don't
> have the intended umask. This happens episodically, and this morning I
> had one of those episodes, plus some time to look into it.
>
> In the end, I had 2 commands that should give the same result:
>
> %> strace -o strace.log port -nok destroot foo
> %> strace port -nok destroot foo >& strace.log
Remember that files that have been present in destroot before might
affect the result, too. Some ports' destroot phases are written in ways
that they cannot be repeated (that doesn't seem to be the case here, but
it's worth keeping it in mind).
> The latter form succeeded, while the former failed because at loosely
> predictable some point a ${destroot}${prefix}/lib/pkgconfig received
> the umask 0255 instead of 0755 or 0775. Loosely predictable here means
> that it occurred during a reinplace loop over the .pc files in the
> pkgconfig directory.
The only difference in MacPorts behavior I would expect here is the
check whether output is to a terminal.
> The episode stopped before I could run the destroot command through
> valgrind.
>
> I've been looking at pextlib's install.c hoping to find a possibility
> that the mode (umask) variable could be used without proper
> initialisation, but that shouldn't be possible. Not in install.c in
> any case, but could there be a reason to assume that the argument
> parsing goes wrong somewhere?
If that's something you suspect, I recommend you compile a copy of
Pextlib with address sanitizer. Since Pextlib is probably dlopen(3)'d by
Tcl at runtime, you may have to preload the address sanitizer libraries,
but (at least on OS X) the binary will tell you that.
> Either way, I think that install.c's install_dir() really shouldn't
> ignore chmod() errors silently ...
Patch to add error checking welcome.
--
Clemens
Re: [macports-ports] branch master updated: emacs: Rev-bump due to imagemagick changes
> On Jan 24, 2017, at 01:32, Ryan Schmidt wrote: > > >> On Jan 23, 2017, at 21:05, Jeremy Huddleston Sequoia >> wrote: >> commit b45c6c288b90421df0407b17a5885033bfb4efdd >> >> Author: Jeremy Huddleston Sequoia >> AuthorDate: Mon Jan 23 19:05:04 2017 -0800 >> >> >> emacs: Rev-bump due to imagemagick changes >> > I didn't include that in > https://github.com/macports/macports-ports/commit/f8d86e8444b1c125ca3e3724deabb0d51021163c > because emacs doesn't actually use ImageMagick; see > https://trac.macports.org/ticket/53315. If by "doesn't actually use" you mean that it's linking the library without any purpose (no symbol linkage, no initializers, etc), then that should certainly be fixed, but it would still require a revbump (unless the link is weak). In this particular case, it does indeed look like emacs is making use of ImageMagick: ~ $ nm -m /opt/local/bin/emacs | grep libMagick (undefined) external _AcquireExceptionInfo (from libMagickCore-6.Q16) (undefined) external _CloneMagickWand (from libMagickWand-6.Q16) (undefined) external _DestroyExceptionInfo (from libMagickCore-6.Q16) (undefined) external _DestroyMagickWand (from libMagickWand-6.Q16) (undefined) external _DestroyPixelIterator (from libMagickWand-6.Q16) (undefined) external _DestroyPixelWand (from libMagickWand-6.Q16) (undefined) external _DestroyString (from libMagickCore-6.Q16) (undefined) external _GetMagickList (from libMagickCore-6.Q16) (undefined) external _MagickCropImage (from libMagickWand-6.Q16) (undefined) external _MagickExportImagePixels (from libMagickWand-6.Q16) (undefined) external _MagickGetException (from libMagickWand-6.Q16) (undefined) external _MagickGetImage (from libMagickWand-6.Q16) (undefined) external _MagickGetImageDelay (from libMagickWand-6.Q16) (undefined) external _MagickGetImageDispose (from libMagickWand-6.Q16) (undefined) external _MagickGetImageHeight (from libMagickWand-6.Q16) (undefined) external _MagickGetImagePage (from libMagickWand-6.Q16) (undefined) external _MagickGetImageSignature (from libMagickWand-6.Q16) (undefined) external _MagickGetImageWidth (from libMagickWand-6.Q16) (undefined) external _MagickGetNumberImages (from libMagickWand-6.Q16) (undefined) external _MagickMergeImageLayers (from libMagickWand-6.Q16) (undefined) external _MagickReadImage (from libMagickWand-6.Q16) (undefined) external _MagickReadImageBlob (from libMagickWand-6.Q16) (undefined) external _MagickRelinquishMemory (from libMagickWand-6.Q16) (undefined) external _MagickRotateImage (from libMagickWand-6.Q16) (undefined) external _MagickScaleImage (from libMagickWand-6.Q16) (undefined) external _MagickSetFilename (from libMagickWand-6.Q16) (undefined) external _MagickSetImageBackgroundColor (from libMagickWand-6.Q16) (undefined) external _MagickSetIteratorIndex (from libMagickWand-6.Q16) (undefined) external _MagickWandGenesis (from libMagickWand-6.Q16) (undefined) external _MagickWandTerminus (from libMagickWand-6.Q16) (undefined) external _NewMagickWand (from libMagickWand-6.Q16) (undefined) external _NewPixelIterator (from libMagickWand-6.Q16) (undefined) external _NewPixelWand (from libMagickWand-6.Q16) (undefined) external _PixelGetAlpha (from libMagickWand-6.Q16) (undefined) external _PixelGetMagickColor (from libMagickWand-6.Q16) (undefined) external _PixelGetNextIteratorRow (from libMagickWand-6.Q16) (undefined) external _PixelSetBlue (from libMagickWand-6.Q16) (undefined) external _PixelSetGreen (from libMagickWand-6.Q16) (undefined) external _PixelSetIteratorRow (from libMagickWand-6.Q16) (undefined) external _PixelSetMagickColor (from libMagickWand-6.Q16) (undefined) external _PixelSetRed (from libMagickWand-6.Q16) (undefined) external _PixelSyncIterator (from libMagickWand-6.Q16) --Jeremy
Re: [macports-ports] 12/13: xcbuild: add new tool for xcode
Ryan Schmidt writes:
>> On Jan 23, 2017, at 18:08, Sean Farley wrote:
>>
>> Sean Farley (seanfarley) pushed a commit to branch master
>> in repository macports-ports.
>>
>>
>> https://github.com/macports/macports-ports/commit/ea02c6a2415087a43634f83653532c4aaf346a21
>>
>> commit ea02c6a2415087a43634f83653532c4aaf346a21
>>
>> Author: Sean Farley
>> AuthorDate: Mon Jan 23 16:04:28 2017 -0800
>>
>>
>> xcbuild: add new tool for xcode
>>
>> ---
>> devel/xcbuild/Portfile | 61
>> ++
>> 1 file changed, 61 insertions(+)
>>
>>
>> diff --git a/devel/xcbuild/Portfile b/devel/xcbuild/Portfile
>>
>> new file mode 100644
>>
>> index 000..958b72a
>>
>> --- /dev/null
>>
>> +++ b/devel/xcbuild/Portfile
>>
>> @@ -0,0 +1,61 @@
>>
>> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=portfile:et:sw=4:ts=4:sts=4
>>
>> +
>>
>> +PortSystem 1.0
>>
>> +PortGroup cmake 1.0
>>
>> +PortGroup github 1.0
>>
>> +
>>
>> +github.setupfacebook xcbuild 0.1.1
>>
>> +categories devel
>>
>> +platforms darwin
>>
>> +
>>
>> +universal_variant no
>>
>> +license BSD
>>
>> +maintainers sean openmaintainer
>>
>> +
>>
>> +description xcbuild is an Xcode-compatible build tool with the goal
>> of \
>>
>> +providing faster builds, better documentation of the
>> build \
>>
>> +process and running on multiple platforms
>>
>> +long_description${description}
>>
>> +
>>
>> +# Fetch from git instead of distfile because it needs submodules
>>
>> +fetch.type git
>>
>> +
>>
>> +depends_lib-append port:libpng \
>>
>> +port:pkgconfig \
>>
>> +port:zlib \
>>
>> +port:libxml2 \
>>
>> +port:cmake \
>>
>> +port:ninja
>>
>
> Does xcbuild really use pkgconfig, cmake and ninja at runtime as well?
> Usually they're only build-time dependencies. The cmake portgroup already
> adds cmake as a build-time dependency.
Yep. xcbuild is a wrapper around xcodebuild that can output both cmake
and ninja build files (along with llbuild, I believe).
>> +post-fetch {
>>
>> +system -W "${worksrcpath}" "git submodule update --init"
>>
>> +}
>>
>> +
>>
>> +# use_configure no
>>
>> +
>>
>> +configure {
>>
>> +system -W "${worksrcpath}" "${configure.cmd} -G Ninja ${configure.args}
>> ${worksrcpath}"
>>
>> +}
>>
>> +
>>
>> +build {
>>
>> +system -W "${worksrcpath}" "ninja"
>>
>> +}
>>
>> +
>>
>> +destroot {
>>
>> +system -W "${worksrcpath}" "DESTDIR=${destroot} ninja install"
>>
>> +}
>
> It might be better to get support for ninja into the cmake portgroup, if
> ninja does really provide such great benefits, rather than override the
> standard phases. See https://trac.macports.org/ticket/47127 for that request.
Ah, nice, I hadn't seen that.
question for the "base gurus"
Hello,
You know I use a very slightly adapted version of "base" to use MacPorts on
Linux. This is about an intermittent issue I see there that happens in code
which I think should be host/OS *independent*.
I have mentioned before that I sometimes get permissions errors during the
destroot phase because directories created with xinstall don't have the
intended umask. This happens episodically, and this morning I had one of those
episodes, plus some time to look into it.
In the end, I had 2 commands that should give the same result:
%> strace -o strace.log port -nok destroot foo
%> strace port -nok destroot foo >& strace.log
The latter form succeeded, while the former failed because at loosely
predictable some point a ${destroot}${prefix}/lib/pkgconfig received the umask
0255 instead of 0755 or 0775. Loosely predictable here means that it occurred
during a reinplace loop over the .pc files in the pkgconfig directory.
The episode stopped before I could run the destroot command through valgrind.
I've been looking at pextlib's install.c hoping to find a possibility that the
mode (umask) variable could be used without proper initialisation, but that
shouldn't be possible. Not in install.c in any case, but could there be a
reason to assume that the argument parsing goes wrong somewhere?
I have been assuming that the issue might be a side-effect of running on ZFS,
but that doesn't fit in with strace showing me a call to chmod(".../pkgconfig",
0255).
Either way, I think that install.c's install_dir() really shouldn't ignore
chmod() errors silently ...
Thoughts?
Thanks,
R.
Security.framework port? (was: Qt and SecureTransport vs. OpenSSL)
Hello, Does anyone (Jeremy??) know if the Security.framework sources provided on opensource.apple.com (latest version https://opensource.apple.com/source/Security/Security-57740.31.2/) are feature-complete and has anyone tried to build this framework with the goal of providing recent security updates to earlier OS X versions? Most of my attempts to build system frameworks like that have been exercises in frustration so I prefer to ask before jumping and trying. R
Re: [macports-ports] 12/13: xcbuild: add new tool for xcode
> On Jan 23, 2017, at 18:08, Sean Farley wrote:
>
> Sean Farley (seanfarley) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/ea02c6a2415087a43634f83653532c4aaf346a21
>
> commit ea02c6a2415087a43634f83653532c4aaf346a21
>
> Author: Sean Farley
> AuthorDate: Mon Jan 23 16:04:28 2017 -0800
>
>
> xcbuild: add new tool for xcode
>
> ---
> devel/xcbuild/Portfile | 61
> ++
> 1 file changed, 61 insertions(+)
>
>
> diff --git a/devel/xcbuild/Portfile b/devel/xcbuild/Portfile
>
> new file mode 100644
>
> index 000..958b72a
>
> --- /dev/null
>
> +++ b/devel/xcbuild/Portfile
>
> @@ -0,0 +1,61 @@
>
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=portfile:et:sw=4:ts=4:sts=4
>
> +
>
> +PortSystem 1.0
>
> +PortGroup cmake 1.0
>
> +PortGroup github 1.0
>
> +
>
> +github.setupfacebook xcbuild 0.1.1
>
> +categories devel
>
> +platforms darwin
>
> +
>
> +universal_variant no
>
> +license BSD
>
> +maintainers sean openmaintainer
>
> +
>
> +description xcbuild is an Xcode-compatible build tool with the goal
> of \
>
> +providing faster builds, better documentation of the
> build \
>
> +process and running on multiple platforms
>
> +long_description${description}
>
> +
>
> +# Fetch from git instead of distfile because it needs submodules
>
> +fetch.type git
>
> +
>
> +depends_lib-append port:libpng \
>
> +port:pkgconfig \
>
> +port:zlib \
>
> +port:libxml2 \
>
> +port:cmake \
>
> +port:ninja
>
Does xcbuild really use pkgconfig, cmake and ninja at runtime as well? Usually
they're only build-time dependencies. The cmake portgroup already adds cmake as
a build-time dependency.
> +post-fetch {
>
> +system -W "${worksrcpath}" "git submodule update --init"
>
> +}
>
> +
>
> +# use_configure no
>
> +
>
> +configure {
>
> +system -W "${worksrcpath}" "${configure.cmd} -G Ninja ${configure.args}
> ${worksrcpath}"
>
> +}
>
> +
>
> +build {
>
> +system -W "${worksrcpath}" "ninja"
>
> +}
>
> +
>
> +destroot {
>
> +system -W "${worksrcpath}" "DESTDIR=${destroot} ninja install"
>
> +}
It might be better to get support for ninja into the cmake portgroup, if ninja
does really provide such great benefits, rather than override the standard
phases. See https://trac.macports.org/ticket/47127 for that request.
> +post-destroot {
>
> +move {*}[glob ${destroot}/usr/local/usr/bin/*] ${destroot}${prefix}/bin
>
> +move {*}[glob ${destroot}/usr/local/usr/lib/*] ${destroot}${prefix}/lib
>
> +move ${destroot}/usr/local/Library/Xcode ${destroot}${prefix}/Library
>
> +
>
> +# these files aren't needed on macos (they are built by the project for
>
> +# future work on linux)
>
> +delete ${destroot}${prefix}/bin/PlistBuddy
>
> +delete ${destroot}${prefix}/bin/lsbom
>
> +delete ${destroot}${prefix}/bin/plutil
>
> +delete ${destroot}${prefix}/bin/xcode-select
>
> +delete ${destroot}${prefix}/bin/xcodebuild
>
> +delete ${destroot}${prefix}/bin/xcrun
>
> +}
>
>
Re: [macports-ports] branch master updated: emacs: Rev-bump due to imagemagick changes
> On Jan 23, 2017, at 21:05, Jeremy Huddleston Sequoia
> wrote:
>
> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/b45c6c288b90421df0407b17a5885033bfb4efdd
>
> The following commit(s) were added to refs/heads/master by this push:
>
> new b45c6c2 emacs: Rev-bump due to imagemagick changes
>
> b45c6c2 is described below
>
>
> commit b45c6c288b90421df0407b17a5885033bfb4efdd
>
> Author: Jeremy Huddleston Sequoia
> AuthorDate: Mon Jan 23 19:05:04 2017 -0800
>
>
> emacs: Rev-bump due to imagemagick changes
>
>
>
> Signed-off-by: Jeremy Huddleston Sequoia
>
> ---
> editors/emacs/Portfile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>
> diff --git a/editors/emacs/Portfile b/editors/emacs/Portfile
>
> index 09bb1fb..14d5a1c 100644
>
> --- a/editors/emacs/Portfile
>
> +++ b/editors/emacs/Portfile
>
> @@ -37,7 +37,7 @@ subport emacs-app-devel {
>
>
> if {$subport eq $name || $subport eq "emacs-app"} {
> version 25.1
>
> -revision2
>
> +revision3
>
>
> checksums rmd160 d29ddba846024c7df3e1dc02ac32690f3650e7b9 \
> sha256
> 763344b90db4d40e9fe90c5d14748a9dbd201ce544e2cf0835ab48a0aa4a1c67
>
> @@ -48,7 +48,7 @@ if {$subport eq $name || $subport eq "emacs-app"} {
>
>
> if {$subport eq "emacs-devel" || $subport eq "emacs-app-devel"} {
> version 20161031
>
> -revision2
>
> +revision3
I didn't include that in
https://github.com/macports/macports-ports/commit/f8d86e8444b1c125ca3e3724deabb0d51021163c
because emacs doesn't actually use ImageMagick; see
https://trac.macports.org/ticket/53315.
