Portfile Workflow Advice
Hi! I've been finding developing and especially updating Portfiles a bit tricky and error prone, so have been writing some tools for myself to help with this... https://github.com/rodnaph/pearl https://github.com/rodnaph/ghsum But while submitting the second via Trac it was pointed out you can do this already with Macports... $ port -d checksum So I was wondering what tools everyone else uses to create and update their Portfiles? Are all the utilities provided through the port tool and I'm just missing them? Or are there other utilities (like https://trac.macports.org/browser/users/ryandesign/scripts/portcheckup) that are available to help? Any links/tips appreciated, and I'd be especially interested if someone could describe their workflow too. Thanks. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101504] trunk/base/src/port1.0/portextract.tcl
On Sun, Jan 13, 2013 at 8:46 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Jan 13, 2013, at 18:53, Blair Zajac wrote:
On 01/13/2013 03:36 PM, Ryan Schmidt wrote:
https://trac.macports.org/ticket/21117
I think the problem still remains when you have a non-root MacPorts
installation; that's the configuration I was using when I initially filed
the ticket, before the privilege-dropping code was added to MacPorts and
made it an issue for everyone. The way I was thinking of fixing it was to
exclude those files from copying that we don't need anyway and I think that
still might be a better way, but I didn't really know how to do that which
is why I never did anything about the ticket.
If you're doing this as non-root, then presumably you have permissions
yourself to mount a DMG. Are you saying that even if you can mount it,
there's files in there you cannot see?
I haven't tried using a non-root MacPorts installation in awhile; it just
seemed to become totally impossible once the privilege-dropping branch got
merged in. Maybe those bugs have been fixed by now.
But here's an example from outside of MacPorts, using the distfile for the
cliclick port:
$ open cliclick/2.1/cliclick.dmg
$ cd /Volumes/cliclick
$ find . -print0 | xargs -0 ls -ld
find: ./.Trashes: Permission denied
drwxr-xr-x 12 rschmidt rschmidt476 Sep 26 02:12 .
-rw-r--r--@ 1 rschmidt rschmidt 12292 Sep 26 02:14 ./.DS_Store
d-wx-wx-wt 2 rschmidt rschmidt 68 Sep 26 02:15 ./.Trashes
drwxr-xr-x 8 rschmidt rschmidt272 Sep 26 02:13 ./.assets
-rw-r--r-- 1 rschmidt rschmidt 5639 Sep 26 02:11 ./.assets/AppIcon.png
-rw-r--r-- 1 rschmidt rschmidt 95 Sep 26 02:11 ./.assets/bar.gif
-rw-r--r-- 1 rschmidt rschmidt 4535 Sep 14 05:24
./.assets/diskimage-background.png
-rw-r--r-- 1 rschmidt rschmidt 67 Sep 26 02:11 ./.assets/li.gif
-rw-r--r-- 1 rschmidt rschmidt 1193 Sep 26 02:11 ./.assets/logo.gif
-rw-r--r-- 1 rschmidt rschmidt 1301 Sep 26 02:11 ./.assets/style.css
drwx-- 4 rschmidt rschmidt136 Sep 26 02:15 ./.fseventsd
-rw--- 1 rschmidt rschmidt209 Sep 26 02:15
./.fseventsd/6365733132517f42
-rw--- 1 rschmidt rschmidt 36 Sep 26 02:15
./.fseventsd/fseventsd-uuid
-rw-r--r-- 1 rschmidt rschmidt277 Sep 26 02:11 ./Contact.webloc
-rw-r--r--@ 1 rschmidt rschmidt 4676 Sep 26 02:11 ./Read me.html
-rw-r--r-- 1 rschmidt rschmidt265 Sep 26 02:11 ./Website.webloc
-rwxr-xr-x 1 rschmidt rschmidt 89216 Sep 26 02:11 ./cliclick
So .Trashes cannot be seen. One solution I thought of was to just not copy
anything beginning with a period. In other words, cp * ${worksrcpath}. (*
expansion does not include items starting with .)
A more elaborate and more correct solution would be to actually look at the
permissions of each item and just not copy those we're not allowed to, but
doing that in a single-line command execution, such as is required by the
extract system, was daunting.
Well, could we just use the `find` command instead? Conceptually,
something like this,
$ /usr/bin/find . -mindepth 1 -maxdepth 1 ! -perm -01000 -print0
2/dev/null | xargs -0 -I{} echo cp -R {} /tmp
cp -R ./.assets /tmp
cp -R ./.DS_Store /tmp
cp -R ./.fseventsd /tmp
cp -R ./cliclick /tmp
cp -R ./Contact.webloc /tmp
cp -R ./Read me.html /tmp
cp -R ./Website.webloc /tmp
but the one-liner would be
$ /usr/bin/find . -mindepth 1 -maxdepth 1 ! -perm -01000 -exec cp -R {} /tmp \;
I think all we really need to do in cases like these are ignore files
/ directories that have the sticky bit set.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101569] trunk/dports/shells/zsh/Portfile
On Jan 14, 2013, at 2:17 AM, Ryan Schmidt ryandes...@macports.org wrote: Since this changes what files are installed, the revision should be increased. Yeahhh, I realized that after the fact. I just went ahead with the 5.0.2 version update. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101504] trunk/base/src/port1.0/portextract.tcl
On 2013-01-14 09:20, Sean Farley wrote:
$ /usr/bin/find . -mindepth 1 -maxdepth 1 ! -perm -01000 -exec cp -R {} /tmp
\;
I think all we really need to do in cases like these are ignore files
/ directories that have the sticky bit set.
The problem is not the sticky bit, but the missing read permissions.
I would say this should be:
/usr/bin/find . -mindepth 1 -maxdepth 1 -perm -+r -exec cp -R {} /tmp \;
The syntax is strange, but I think -+r is really what we want:
read permissions for at least one of owner, group or others.
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Compilation failure of texlive: a bug in clang or application code?
Dear MacPorts wizards,
This is a preliminary problem. I have problems compiling the trunk
version of software that's already part of MacPorts (only an older
version), but it is not clear to me if the one to be blamed are clang
header files or the software that fails to compile.
I'm asking now because it would make sense to solve the issue before
the release that's expected somewhere between March and June. XeTeX
(http://sourceforge.net/projects/xetex/,
http://xetex.git.sourceforge.net or
http://tug.org/svn/texlive/trunk/Build/source/) finally builds under
x86_64 without patching (earlier it didn't compile at all and the
current version in MacPorts disables part of the functionality that
depends on Carbon libraries for handling AAT). The modifications are
not 100% finished yet, but the sources are building fine with
llvm-gcc-4.2.
The problem is that an ancient code from TeX Live and some clang
libraries clash with each other when loading Carbon (or CoreServices
ApplicationServices).
The problematic code is the following (around line 1100 of
/usr/lib/clang/3.1/include/emmintrin.h):
static __inline__ __m128i __attribute__((__always_inline__, __nodebug__))
_mm_set_epi8(char b15, char b14, char b13, char b12, char b11, char
b10, char b9, char b8, char b7, char b6, char b5, char b4, char b3,
char b2, char b1, char b0)
{
return (__m128i)(__v16qi){ b0, b1, b2, b3, b4, b5, b6, b7, b8, b9,
b10, b11, b12, b13, b14, b15 };
}
clashing with
#define b0 u.B0
#define b1 u.B1
#define b2 u.B2
#define b3 u.B3
from
http://tug.org/svn/texlive/trunk/Build/source/texk/web2c/texmfmem.h?view=markup
The reported error is:
In file included from ../../../texk/web2c/xetexdir/XeTeX_ext.c:57:
In file included from ./xetexd.h:571:
In file included from ./xetexcoerce.h:1202:
In file included from ../../../texk/web2c/xetexdir/xetex.h:103:
In file included from ../../../texk/web2c/xetexdir/XeTeXOTMath.h:36:
In file included from ../../../texk/web2c/xetexdir/XeTeX_ext.h:78:
In file included from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20:
In file included from
/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21:
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20:
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:129:
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32:
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:29:
In file included from /usr/bin/../lib/clang/3.1/include/xmmintrin.h:985:
/usr/bin/../lib/clang/3.1/include/emmintrin.h:1100:133: error: expected ')'
_mm_set_epi8(char b15, char b14, char b13, char b12, char b11, char
b10, char b9, char b8, char b7, char b6, char b5, char b4, char b3,
char b2, char b1, char b0)
^
../../../texk/web2c/texmfmem.h:171:13: note: expanded from macro 'b3'
#define b3 u.B3
^
/usr/bin/../lib/clang/3.1/include/emmintrin.h:1100:13: note: to match this '('
_mm_set_epi8(char b15, char b14, char b13, char b12, char b11, char
b10, char b9, char b8, char b7, char b6, char b5, char b4, char b3,
char b2, char b1, char b0)
^
/usr/bin/../lib/clang/3.1/include/emmintrin.h:1102:30: error: member
reference base type 'char' is not a structure or union
return (__m128i)(__v16qi){ b0, b1, b2, b3, b4, b5, b6, b7, b8, b9,
b10, b11, b12, b13, b14, b15 };
^~
../../../texk/web2c/texmfmem.h:168:14: note: expanded from macro 'b0'
#define b0 u.B0
~ ^
One of the main developers of TeX Live argued with the following:
the corresponding code in
/usr/lib/gcc/ix86-linux-gnu/4.7.2/include/emmintrin.h:597ff
reads
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_set_epi8 (char __q15, char __q14, char __q13, char __q12,
char __q11, char __q10, char __q09, char __q08,
char __q07, char __q06, char __q05, char __q04,
char __q03, char __q02, char __q01, char __q00)
{
return __extension__ (__m128i)(__v16qi){
__q00, __q01, __q02, __q03, __q04, __q05, __q06, __q07,
__q08, __q09, __q10, __q11, __q12, __q13, __q14, __q15
};
and I'd say that clang must not usurpate user space variables such as b0,
b1, b2, etc. It is certainly legitimate to #define them to whatever is
useful for the user code. So this is a bug in clang!
Regards
Peter
So my question is basically: can this be considered a bug in clang and
if so: what would be the best place to report it to? (And if not, is
anyone willing to take a look to see if there's an easy workaround
before the port maintainer gets bitten by this issue?)
Mojca
Re: filetype in modeline
On 2013-01-14 16:07, Clemens Lang wrote: On Mon, Jan 14, 2013 at 09:33:34AM -0500, Jeremy Lavergne wrote: Another way to make sure Portfiles have filetype set to Portfile despite the modeline is adding the following line to your .vimrc: au BufNewFile,BufRead,BufWinEnter Portfile setlocal ft=Portfile That way you can use mpvim with your Portfiles but still use the standard modeline. We could update the standard modeline to include that too :-) No we can't, because - I think the command wouldn't be effective in a modeline - it would be no different from putting ft=Portfile in the modeline directly - it would break for all users without mpvim, which is just what we're trying to avoid. We could however put that line into mpvim. It already is in ftdetect/macports.vim [1], except that it is only done for the events BufNewFile,BufRead and not for BufWinEnter, while the latter is the reason your line actually works. The filetype is overridden each time again the buffer of a Portfile is displayed. Although this works in most circumstances, it has side effects when using hidden buffers. Rainer [1] https://trac.macports.org/browser/contrib/mpvim/ftdetect/macports.vim ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101504] trunk/base/src/port1.0/portextract.tcl
On 01/14/2013 07:07 AM, Rainer Müller wrote:
On 2013-01-14 09:20, Sean Farley wrote:
$ /usr/bin/find . -mindepth 1 -maxdepth 1 ! -perm -01000 -exec cp -R {} /tmp \;
I think all we really need to do in cases like these are ignore files
/ directories that have the sticky bit set.
The problem is not the sticky bit, but the missing read permissions.
I would say this should be:
/usr/bin/find . -mindepth 1 -maxdepth 1 -perm -+r -exec cp -R {} /tmp \;
This worked for me running it as myself:
/usr/bin/find /Volumes/Cg-3.1.0013 -depth -perm -+r -print0 |
/usr/bin/cpio -0 -p -d -m -u /tmp/Cg
find: /Volumes/Cg-3.1.0013/.Trashes: Permission denied
80164 blocks
Blair
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101504] trunk/base/src/port1.0/portextract.tcl
On 01/13/2013 06:46 PM, Ryan Schmidt wrote:
On Jan 13, 2013, at 18:53, Blair Zajac wrote:
On 01/13/2013 03:36 PM, Ryan Schmidt wrote:
https://trac.macports.org/ticket/21117
I think the problem still remains when you have a non-root MacPorts
installation; that's the configuration I was using when I initially filed the
ticket, before the privilege-dropping code was added to MacPorts and made it an
issue for everyone. The way I was thinking of fixing it was to exclude those
files from copying that we don't need anyway and I think that still might be a
better way, but I didn't really know how to do that which is why I never did
anything about the ticket.
If you're doing this as non-root, then presumably you have permissions yourself
to mount a DMG. Are you saying that even if you can mount it, there's files in
there you cannot see?
I haven't tried using a non-root MacPorts installation in awhile; it just
seemed to become totally impossible once the privilege-dropping branch got
merged in. Maybe those bugs have been fixed by now.
But here's an example from outside of MacPorts, using the distfile for the
cliclick port:
$ open cliclick/2.1/cliclick.dmg
$ cd /Volumes/cliclick
$ find . -print0 | xargs -0 ls -ld
find: ./.Trashes: Permission denied
drwxr-xr-x 12 rschmidt rschmidt476 Sep 26 02:12 .
-rw-r--r--@ 1 rschmidt rschmidt 12292 Sep 26 02:14 ./.DS_Store
d-wx-wx-wt 2 rschmidt rschmidt 68 Sep 26 02:15 ./.Trashes
drwxr-xr-x 8 rschmidt rschmidt272 Sep 26 02:13 ./.assets
-rw-r--r-- 1 rschmidt rschmidt 5639 Sep 26 02:11 ./.assets/AppIcon.png
-rw-r--r-- 1 rschmidt rschmidt 95 Sep 26 02:11 ./.assets/bar.gif
-rw-r--r-- 1 rschmidt rschmidt 4535 Sep 14 05:24
./.assets/diskimage-background.png
-rw-r--r-- 1 rschmidt rschmidt 67 Sep 26 02:11 ./.assets/li.gif
-rw-r--r-- 1 rschmidt rschmidt 1193 Sep 26 02:11 ./.assets/logo.gif
-rw-r--r-- 1 rschmidt rschmidt 1301 Sep 26 02:11 ./.assets/style.css
drwx-- 4 rschmidt rschmidt136 Sep 26 02:15 ./.fseventsd
-rw--- 1 rschmidt rschmidt209 Sep 26 02:15
./.fseventsd/6365733132517f42
-rw--- 1 rschmidt rschmidt 36 Sep 26 02:15
./.fseventsd/fseventsd-uuid
-rw-r--r-- 1 rschmidt rschmidt277 Sep 26 02:11 ./Contact.webloc
-rw-r--r--@ 1 rschmidt rschmidt 4676 Sep 26 02:11 ./Read me.html
-rw-r--r-- 1 rschmidt rschmidt265 Sep 26 02:11 ./Website.webloc
-rwxr-xr-x 1 rschmidt rschmidt 89216 Sep 26 02:11 ./cliclick
So .Trashes cannot be seen. One solution I thought of was to just not copy anything beginning with a period.
In other words, cp * ${worksrcpath}. (* expansion does not include items starting
with .)
A more elaborate and more correct solution would be to actually look at the
permissions of each item and just not copy those we're not allowed to, but
doing that in a single-line command execution, such as is required by the
extract system, was daunting.
Instead of tar, you can use find's -perms flag. I haven't tried this,
but this may work:
$ find PATH -depth -perms +r -print0 | cpio -0 -p -d -m -u -v $worksrcpath
Blair
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101511] trunk/dports/lang
On Mon, Jan 14, 2013 at 01:02:39AM -0600, Ryan Schmidt wrote: I was under the impression that the reason the nodejs ports don't support PowerPC is because v8 doesn't support PowerPC. (The comment in the nodejs port reads # V8 only supports ARM and IA-32 processors.) If that's so, then the v8 port should similarly declare supported_archs i386 x86_64. That's correct. Added in http://trac.macports.org/changeset/101604. Should we specify other values than i386 and x86_64, e.g. arm, if applicable? -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New committers: larryv and sean
Hi, On Fri, Jan 04, 2013 at 10:00:42PM +0100, Rainer Müller wrote: Please join us in welcoming the following new MacPorts committers: - Larry Velásquez (larryv) - Sean Farley (sean) We look forward to continued excellent contributions from these new team members. welcome to MacPorts. Maybe now all those patches Sean wrote that I've never gotten around to commiting will be integrated after all? :) -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Build server request: patch for use_dmg support
I don't think we want to have a mix of patches applied to the buildbots, since it makes reproducing problems harder. It might be useful to have the base builder install the result of each build such that the ports builder will use it (so the ports builder effectively uses trunk), but that probably introduces its own support burden too. -Bill On Jan 11, 2013, at 8:48 PM, Blair Zajac bl...@orcaware.com wrote: Can somebody who has access to the build bots review the following commits and apply them: https://trac.macports.org/changeset/101503 https://trac.macports.org/changeset/101504 Right now it's causing cg-toolkit failure because the process doesn't have the right to copy what it needs out of the DMG. Thanks, Blair ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101504] trunk/base/src/port1.0/portextract.tcl
On Mon, Jan 14, 2013 at 9:07 AM, Rainer Müller rai...@macports.org wrote:
On 2013-01-14 09:20, Sean Farley wrote:
$ /usr/bin/find . -mindepth 1 -maxdepth 1 ! -perm -01000 -exec cp -R {} /tmp
\;
I think all we really need to do in cases like these are ignore files
/ directories that have the sticky bit set.
The problem is not the sticky bit, but the missing read permissions.
I would say this should be:
/usr/bin/find . -mindepth 1 -maxdepth 1 -perm -+r -exec cp -R {} /tmp \;
The syntax is strange, but I think -+r is really what we want:
read permissions for at least one of owner, group or others.
You and Jeremy are right about the stick bit. Sigh, that's what I get
for trying to think after my bedtime.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101504] trunk/base/src/port1.0/portextract.tcl
On Mon, Jan 14, 2013 at 11:09 AM, Blair Zajac bl...@orcaware.com wrote:
On 01/13/2013 06:46 PM, Ryan Schmidt wrote:
On Jan 13, 2013, at 18:53, Blair Zajac wrote:
On 01/13/2013 03:36 PM, Ryan Schmidt wrote:
https://trac.macports.org/ticket/21117
I think the problem still remains when you have a non-root MacPorts
installation; that's the configuration I was using when I initially filed
the ticket, before the privilege-dropping code was added to MacPorts and
made it an issue for everyone. The way I was thinking of fixing it was to
exclude those files from copying that we don't need anyway and I think that
still might be a better way, but I didn't really know how to do that which
is why I never did anything about the ticket.
If you're doing this as non-root, then presumably you have permissions
yourself to mount a DMG. Are you saying that even if you can mount it,
there's files in there you cannot see?
I haven't tried using a non-root MacPorts installation in awhile; it just
seemed to become totally impossible once the privilege-dropping branch got
merged in. Maybe those bugs have been fixed by now.
But here's an example from outside of MacPorts, using the distfile for the
cliclick port:
$ open cliclick/2.1/cliclick.dmg
$ cd /Volumes/cliclick
$ find . -print0 | xargs -0 ls -ld
find: ./.Trashes: Permission denied
drwxr-xr-x 12 rschmidt rschmidt476 Sep 26 02:12 .
-rw-r--r--@ 1 rschmidt rschmidt 12292 Sep 26 02:14 ./.DS_Store
d-wx-wx-wt 2 rschmidt rschmidt 68 Sep 26 02:15 ./.Trashes
drwxr-xr-x 8 rschmidt rschmidt272 Sep 26 02:13 ./.assets
-rw-r--r-- 1 rschmidt rschmidt 5639 Sep 26 02:11
./.assets/AppIcon.png
-rw-r--r-- 1 rschmidt rschmidt 95 Sep 26 02:11 ./.assets/bar.gif
-rw-r--r-- 1 rschmidt rschmidt 4535 Sep 14 05:24
./.assets/diskimage-background.png
-rw-r--r-- 1 rschmidt rschmidt 67 Sep 26 02:11 ./.assets/li.gif
-rw-r--r-- 1 rschmidt rschmidt 1193 Sep 26 02:11 ./.assets/logo.gif
-rw-r--r-- 1 rschmidt rschmidt 1301 Sep 26 02:11 ./.assets/style.css
drwx-- 4 rschmidt rschmidt136 Sep 26 02:15 ./.fseventsd
-rw--- 1 rschmidt rschmidt209 Sep 26 02:15
./.fseventsd/6365733132517f42
-rw--- 1 rschmidt rschmidt 36 Sep 26 02:15
./.fseventsd/fseventsd-uuid
-rw-r--r-- 1 rschmidt rschmidt277 Sep 26 02:11 ./Contact.webloc
-rw-r--r--@ 1 rschmidt rschmidt 4676 Sep 26 02:11 ./Read me.html
-rw-r--r-- 1 rschmidt rschmidt265 Sep 26 02:11 ./Website.webloc
-rwxr-xr-x 1 rschmidt rschmidt 89216 Sep 26 02:11 ./cliclick
So .Trashes cannot be seen. One solution I thought of was to just not copy
anything beginning with a period. In other words, cp * ${worksrcpath}.
(* expansion does not include items starting with .)
A more elaborate and more correct solution would be to actually look at
the permissions of each item and just not copy those we're not allowed to,
but doing that in a single-line command execution, such as is required by
the extract system, was daunting.
Instead of tar, you can use find's -perms flag. I haven't tried this, but
this may work:
$ find PATH -depth -perms +r -print0 | cpio -0 -p -d -m -u -v $worksrcpath
I would agree with Jeremy's suggestion to use rsync. I think that will
be the most elegant and not involve any piping or redirection, etc.
Though, I haven't tried to formulate the command yet; I'm just
thinking out loud here.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New committers: larryv and sean
On Mon, Jan 14, 2013 at 12:36 PM, Clemens Lang c...@macports.org wrote: Hi, On Fri, Jan 04, 2013 at 10:00:42PM +0100, Rainer Müller wrote: Please join us in welcoming the following new MacPorts committers: - Larry Velásquez (larryv) - Sean Farley (sean) We look forward to continued excellent contributions from these new team members. welcome to MacPorts. Maybe now all those patches Sean wrote that I've never gotten around to commiting will be integrated after all? :) That's my plan :-) … a little slower than I hoped as I try to wrestle with preparing for my Ph.D oral exam (not defense) :-( ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101504] trunk/base/src/port1.0/portextract.tcl
On 01/14/2013 05:33 PM, Sean Farley wrote:
On Mon, Jan 14, 2013 at 11:09 AM, Blair Zajac bl...@orcaware.com wrote:
On 01/13/2013 06:46 PM, Ryan Schmidt wrote:
On Jan 13, 2013, at 18:53, Blair Zajac wrote:
On 01/13/2013 03:36 PM, Ryan Schmidt wrote:
https://trac.macports.org/ticket/21117
I think the problem still remains when you have a non-root MacPorts
installation; that's the configuration I was using when I initially filed
the ticket, before the privilege-dropping code was added to MacPorts and
made it an issue for everyone. The way I was thinking of fixing it was to
exclude those files from copying that we don't need anyway and I think that
still might be a better way, but I didn't really know how to do that which
is why I never did anything about the ticket.
If you're doing this as non-root, then presumably you have permissions
yourself to mount a DMG. Are you saying that even if you can mount it,
there's files in there you cannot see?
I haven't tried using a non-root MacPorts installation in awhile; it just
seemed to become totally impossible once the privilege-dropping branch got
merged in. Maybe those bugs have been fixed by now.
But here's an example from outside of MacPorts, using the distfile for the
cliclick port:
$ open cliclick/2.1/cliclick.dmg
$ cd /Volumes/cliclick
$ find . -print0 | xargs -0 ls -ld
find: ./.Trashes: Permission denied
drwxr-xr-x 12 rschmidt rschmidt476 Sep 26 02:12 .
-rw-r--r--@ 1 rschmidt rschmidt 12292 Sep 26 02:14 ./.DS_Store
d-wx-wx-wt 2 rschmidt rschmidt 68 Sep 26 02:15 ./.Trashes
drwxr-xr-x 8 rschmidt rschmidt272 Sep 26 02:13 ./.assets
-rw-r--r-- 1 rschmidt rschmidt 5639 Sep 26 02:11
./.assets/AppIcon.png
-rw-r--r-- 1 rschmidt rschmidt 95 Sep 26 02:11 ./.assets/bar.gif
-rw-r--r-- 1 rschmidt rschmidt 4535 Sep 14 05:24
./.assets/diskimage-background.png
-rw-r--r-- 1 rschmidt rschmidt 67 Sep 26 02:11 ./.assets/li.gif
-rw-r--r-- 1 rschmidt rschmidt 1193 Sep 26 02:11 ./.assets/logo.gif
-rw-r--r-- 1 rschmidt rschmidt 1301 Sep 26 02:11 ./.assets/style.css
drwx-- 4 rschmidt rschmidt136 Sep 26 02:15 ./.fseventsd
-rw--- 1 rschmidt rschmidt209 Sep 26 02:15
./.fseventsd/6365733132517f42
-rw--- 1 rschmidt rschmidt 36 Sep 26 02:15
./.fseventsd/fseventsd-uuid
-rw-r--r-- 1 rschmidt rschmidt277 Sep 26 02:11 ./Contact.webloc
-rw-r--r--@ 1 rschmidt rschmidt 4676 Sep 26 02:11 ./Read me.html
-rw-r--r-- 1 rschmidt rschmidt265 Sep 26 02:11 ./Website.webloc
-rwxr-xr-x 1 rschmidt rschmidt 89216 Sep 26 02:11 ./cliclick
So .Trashes cannot be seen. One solution I thought of was to just not copy
anything beginning with a period. In other words, cp * ${worksrcpath}.
(* expansion does not include items starting with .)
A more elaborate and more correct solution would be to actually look at
the permissions of each item and just not copy those we're not allowed to,
but doing that in a single-line command execution, such as is required by
the extract system, was daunting.
Instead of tar, you can use find's -perms flag. I haven't tried this, but
this may work:
$ find PATH -depth -perms +r -print0 | cpio -0 -p -d -m -u -v $worksrcpath
I would agree with Jeremy's suggestion to use rsync. I think that will
be the most elegant and not involve any piping or redirection, etc.
Though, I haven't tried to formulate the command yet; I'm just
thinking out loud here.
That'll work also, but you'll get more errors from rsync on the files
and directories it cannot read. Granted, find will also warn on
directories it cannot descend into.
Blair
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
