Re: Proper syntax for recursive copying during destroot
> On Jan 30, 2017, at 08:39, Mojca Miklavec wrote:
>
> Hi,
>
> What's the proper syntax to copy from a bunch of files recursively
> during installation?
> I like "xinstall" because it's safe to call "port destroot" twice. If
> I use "move", this is probably not the case.
>
> I have something like the following structure (three folders, two of
> them contain plain files, the third one contains arbitrary folders and
> arbitrary files inside those folders). I would like to copy these to
> destroot.
>
> foo/A/fileA_1
> /...
> /fileA_N
> foo/B/fileB_1
> /...
> /fileB_N
> foo/C/dirC_1/fileC1_1
>/...
>/fileC1_N
> /dirC_2/fileC2_1
>/...
>/fileC1_N
> /...
> /dirC_N/fileCN_1
>/...
>/fileCN_N
>
> The following code worked as long as C contained just files, but
> stopped working when subfolders were introduced:
>
>set foo_share ${prefix}/share/foo
>set src ${workpath}/.home/foo
>
>foreach d {A B C} {
>xinstall -d -m 0755 ${destroot}/${foo_share}/${d}
>foreach f [glob -type f ${src}/${d}/*] {
>xinstall -W ${src}/${d} ${f} ${destroot}/${foo_share}/${d}
>}
>}
>
> I was playing a bit with various options and ended up with two nested
> glob-s plus some super ugly code to remove the prefix etc. The code
> doesn't quite work yet, but it's already so super ugly that I bet
> there must be a better solution. (I can probably always fall back to
> using "move".)
>
> Any suggestions?
>
> Thank you,
>Mojca
>
> (PS: It's not really relevant, but the port in question is "panda" & #53397.)
If "move" works, why doesn't "copy" work?
Re: Removal of llvm-3.5 and llvm-3.6
Hi Brandon -- I can't do that, but perhaps you might work that out with Clemens. Or maybe llvm-3.9 actually does magically work -- I haven't checked. -- K On 1/29/17, Brandon Allbery wrote: > Or, in other words: please revert that commit, it will build a broken ghc. > > On Sun, Jan 29, 2017 at 2:57 PM, Brandon Allbery > wrote: > >> >> On Sun, Jan 29, 2017 at 2:51 PM, Ken Cunningham < >> ken.cunningham.web...@gmail.com> wrote: >> >>> > GHC still uses 3.5. I want to change that, but haven't found the time. >>> >>> Not any more it doesn't. Not sure if it works when built against >>> llvm-3.9, but here is the commit: >> >> >> It's mot enough to change the dependency. ghc's LLVM backend is wired to >> specific LLVM versions because the LLVM IR annotations keep changing in >> incompatible ways; if you want to use a given ghc version with a >> different >> LLVM version, you will need to dig out the patches that update its >> generated IR to match, or -fllvm will produce syntax errors from LLVM. >> >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allber...@gmail.com >> ballb...@sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> > > > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >
Proper syntax for recursive copying during destroot
Hi,
What's the proper syntax to copy from a bunch of files recursively
during installation?
I like "xinstall" because it's safe to call "port destroot" twice. If
I use "move", this is probably not the case.
I have something like the following structure (three folders, two of
them contain plain files, the third one contains arbitrary folders and
arbitrary files inside those folders). I would like to copy these to
destroot.
foo/A/fileA_1
/...
/fileA_N
foo/B/fileB_1
/...
/fileB_N
foo/C/dirC_1/fileC1_1
/...
/fileC1_N
/dirC_2/fileC2_1
/...
/fileC1_N
/...
/dirC_N/fileCN_1
/...
/fileCN_N
The following code worked as long as C contained just files, but
stopped working when subfolders were introduced:
set foo_share ${prefix}/share/foo
set src ${workpath}/.home/foo
foreach d {A B C} {
xinstall -d -m 0755 ${destroot}/${foo_share}/${d}
foreach f [glob -type f ${src}/${d}/*] {
xinstall -W ${src}/${d} ${f} ${destroot}/${foo_share}/${d}
}
}
I was playing a bit with various options and ended up with two nested
glob-s plus some super ugly code to remove the prefix etc. The code
doesn't quite work yet, but it's already so super ugly that I bet
there must be a better solution. (I can probably always fall back to
using "move".)
Any suggestions?
Thank you,
Mojca
(PS: It's not really relevant, but the port in question is "panda" & #53397.)
Interactive port command asking me for installation of an existing port
Hi, The interactive "port upgrade outdated" curiously asked me for confirming installation of an existing (active) port: ---> Computing dependencies for gtk3 ---> Fetching archive for gtk3 /.../ ---> Installing gtk3 @3.22.7_0+x11 ---> Cleaning gtk3 ---> Computing dependencies for gtk3 ---> Deactivating gtk3 @3.22.6_0+x11 ---> Cleaning gtk3 ---> Activating gtk3 @3.22.7_0+x11 ---> Cleaning gtk3 ---> Computing dependencies for gstreamer1 The following dependencies will be installed: gtk3 Continue? [Y/n]: y Any clue why this would happen? (I checked and gtk was active while the prompt was waiting for my input. This is slightly annoying as I would leave the computer on hoping to get the machine upgraded by the time I come back.) Thank you, Mojca
Re: [macports-ports] 07/07: npm: use an older nodejs on < 10.7
On 30 January 2017 at 11:27, Ryan Schmidt wrote:
>> On Jan 26, 2017, at 17:17, Mojca Miklavec wrote:
>>
>> https://github.com/macports/macports-ports/commit/19b2d7444aee50a1a155c2f571b4123301ba16c4
>>
>> --- a/devel/npm4/Portfile
>> +++ b/devel/npm4/Portfile
>>
>> depends_lib path:bin/node:nodejs6
>>
>> +platform darwin {
>> +if {${os.major} < 11} {
>> +depends_lib-replace bin:node:nodejs6 bin:node:nodejs4
>> +}
>> +}
>
> This doesn't do anything. The port doesn't have a "bin:node:nodejs6"
> dependency to replace, nor should it, because that would allow non-MacPorts
> "node" binaries to satisfy the dependency, which we don't want. The port has
> a "path:bin/node:nodejs6" dependency, so the line needs to read
> "depends_lib-replace path:bin/node:nodejs6 path:bin/node:nodejs4".
Thanks a lot for spotting this. (Maintainer of npm never reviewed the
changes and I wasn't careful enough.)
> I assume you copied this block from yarn, which does have a
> "bin:node:nodejs6" dependency.
Indeed.
> I would replace that with a "path:bin/node:nodejs6" dependency
I agree.
> unless there's something special about yarn that I'm not aware of.
I don't think there's anything special. The port has been introduced recently
https://github.com/macports/macports-ports/pull/48
and I guess that nobody noticed the dependency was specified in a
slightly wrong way.
I'm CC-ing maintainers of yarn, but I committed the fixes for all
three ports (npm3, npm4, yarn). I wasn't sure if a revbump was needed
for yarn, so I didn't do it (the only affected users would probably be
those with nodejs in bin).
Mojca
Re: [macports-ports] 07/07: npm: use an older nodejs on < 10.7
> On Jan 26, 2017, at 17:17, Mojca Miklavec wrote:
>
> tobypeterson pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/19b2d7444aee50a1a155c2f571b4123301ba16c4
>
> commit 19b2d7444aee50a1a155c2f571b4123301ba16c4
>
> Author: Mojca Miklavec
> AuthorDate: Wed Dec 28 22:24:05 2016 +0100
>
>
> npm: use an older nodejs on < 10.7
>
>
>
> See: https://trac.macports.org/ticket/53166
>
> ---
> devel/npm3/Portfile | 6 ++
> devel/npm4/Portfile | 6 ++
> 2 files changed, 12 insertions(+)
>
>
> diff --git a/devel/npm3/Portfile b/devel/npm3/Portfile
>
> index 34ab8c5..dfefe8f 100644
>
> --- a/devel/npm3/Portfile
>
> +++ b/devel/npm3/Portfile
>
> @@ -36,6 +36,12 @@ worksrcdir "package"
>
>
> depends_lib path:bin/node:nodejs6
>
>
> +platform darwin {
>
> +if {${os.major} < 11} {
>
> +depends_lib-replace bin:node:nodejs6 bin:node:nodejs4
>
> +}
>
> +}
>
> +
>
> use_configure no
>
> patchfiles patch-lib-update.js.diff
>
> diff --git a/devel/npm4/Portfile b/devel/npm4/Portfile
>
> index 16f407e..395373e 100644
>
> --- a/devel/npm4/Portfile
>
> +++ b/devel/npm4/Portfile
>
> @@ -34,6 +34,12 @@ worksrcdir "package"
>
>
> depends_lib path:bin/node:nodejs6
>
>
> +platform darwin {
>
> +if {${os.major} < 11} {
>
> +depends_lib-replace bin:node:nodejs6 bin:node:nodejs4
>
> +}
>
> +}
This doesn't do anything. The port doesn't have a "bin:node:nodejs6" dependency
to replace, nor should it, because that would allow non-MacPorts "node"
binaries to satisfy the dependency, which we don't want. The port has a
"path:bin/node:nodejs6" dependency, so the line needs to read
"depends_lib-replace path:bin/node:nodejs6 path:bin/node:nodejs4".
I assume you copied this block from yarn, which does have a "bin:node:nodejs6"
dependency. I would replace that with a "path:bin/node:nodejs6" dependency
unless there's something special about yarn that I'm not aware of.
Re: [macports-ports] branch master updated: arc: re-add universal variant
> On Jan 26, 2017, at 21:09, Kurt Hindenburg wrote:
>
> Kurt Hindenburg (kurthindenburg) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/d108da56e7944b3d5145cda9d004f79ec92e992d
>
> The following commit(s) were added to refs/heads/master by this push:
>
> new d108da5 arc: re-add universal variant
>
> d108da5 is described below
>
>
> commit d108da56e7944b3d5145cda9d004f79ec92e992d
>
> Author: Kurt Hindenburg
> AuthorDate: Thu Jan 26 22:09:04 2017 -0500
>
>
> arc: re-add universal variant
>
> ---
> archivers/arc/Portfile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>
> diff --git a/archivers/arc/Portfile b/archivers/arc/Portfile
>
> index 10308fe..870c3a0 100644
>
> --- a/archivers/arc/Portfile
>
> +++ b/archivers/arc/Portfile
>
> @@ -24,12 +24,12 @@ patchfiles patch-gcc-warnings.diff \
>
>
> use_configure no
>
>
> -build.env-appendCC=${configure.cc} \
>
> +build.env-appendCC="${configure.cc} [get_canonical_archflags cc]" \
>
> CFLAGS='${configure.cflags} [get_canonical_archflags
> cc]' \
>
> -OPT='${configure.cflags} [get_canonical_archflags cc]' \
>
> LDFLAGS='${configure.ldflags} [get_canonical_archflags
> ld]' \
> PREFIX='${prefix}'
>
>
> +variant universal {}
This builds non-universally. The universal variant must be declared before the
get_canonical_archflags procedure is called for the first time, otherwise
get_canonical_archflags doesn't know there is a universal variant.
Re: [macports-ports] branch master updated (f548f90 -> f3225e3)
On 2017-1-30 19:36 , Ryan Schmidt wrote: On Jan 27, 2017, at 14:04, tobypeterson wrote: tobypeterson pushed a change to branch master in repository macports-ports. from f548f90 zsh-completions: update to 0.22.0 new 917a557 trac-53177 activator submission new ed8f58f trac-53177 change maintainer new 84a8f2a trac-53177 changes based upon feedback from @mojca new f3225e3 trac-53177 changes based upon feedback from @mojca The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: java/typesafe-activator/Portfile | 59 1 file changed, 59 insertions(+) create mode 100644 java/typesafe-activator/Portfile All of this should have been squashed into a single commit, with a better commit message, prior to merging to master. We should probably just enable the Squash and Merge button for the repo. It's unfortunate that it will be the default, since it isn't always appropriate, but I think having the option will make things easier overall, even if we have to educate our committers a bit. - Josh
Re: [macports-ports] branch master updated (f548f90 -> f3225e3)
> On Jan 27, 2017, at 14:04, tobypeterson > wrote: > > tobypeterson pushed a change to branch master > in repository macports-ports. > >from f548f90 zsh-completions: update to 0.22.0 > new 917a557 trac-53177 activator submission > new ed8f58f trac-53177 change maintainer > new 84a8f2a trac-53177 changes based upon feedback from @mojca > new f3225e3 trac-53177 changes based upon feedback from @mojca > > The 4 revisions listed above as "new" are entirely new to this > repository and will be described in separate emails. The revisions > listed as "add" were already present in the repository and have only > been added to this reference. > > > Summary of changes: > java/typesafe-activator/Portfile | 59 > 1 file changed, 59 insertions(+) > create mode 100644 java/typesafe-activator/Portfile > All of this should have been squashed into a single commit, with a better commit message, prior to merging to master.
Re: [macports-ports] 01/02: libevent: update to version 2.1.8
> On Jan 27, 2017, at 13:24, Marius Schamschula wrote:
>
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/f674c03eb39d77ac7d3a38b96f2cd2acbf2fd041
>
> commit f674c03eb39d77ac7d3a38b96f2cd2acbf2fd041
>
> Author: Marius Schamschula
> AuthorDate: Fri Jan 27 13:17:27 2017 -0600
>
>
> libevent: update to version 2.1.8
>
> ---
> devel/libevent/Portfile | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
>
> diff --git a/devel/libevent/Portfile b/devel/libevent/Portfile
>
> index db7ef8f..ce2cf01 100644
>
> --- a/devel/libevent/Portfile
>
> +++ b/devel/libevent/Portfile
>
> @@ -3,9 +3,8 @@
>
> PortSystem 1.0
> PortGroup github 1.0
>
>
> -github.setuplibevent libevent 2.0.22-stable release-
>
> +github.setuplibevent libevent 2.1.8-stable release-
>
> version [lindex [split ${version} -] 0]
>
> -revision3
>
> categories devel
> platforms darwin
> license BSD
>
> @@ -20,17 +19,13 @@ long_descriptionThe libevent API provides a mechanism
> to execute \
>
> callbacks due to signals or regular timeouts.
>
> homepagehttp://libevent.org
>
> -github.tarball_from releases
>
>
>
> -checksums rmd160 6a7e8e3ebcfd2227fa807a604b5c773c90c8b8cc \
>
> -sha256
> 71c2c49f0adadacfdbe6332a372c38cf9c8b7895bb73dabeaa53cdcc1d4e1fa3
>
> +checksums rmd160 f23ad93d555089535085c99f3f8cbb9ebae4fd53 \
>
> +sha256
> d53e88f2b31fbccab93f6b1e54fe7f4c1d536b6d8250c95cd42dbc14f958baeb
>
>
> depends_lib path:lib/libssl.dylib:openssl
>
>
> -# Don't accidentally create flat-namespace dylibs on Yosemite (#44596).
>
> -patchfiles yosemite-libtool.patch
>
> -
>
> -patchfiles-append patch-sierra-kqueue.diff
>
> +use_autoreconf yes
Why do you no longer use the release download? It's inconvenient to change it
now, but for future reference, using the release download is preferred. It
avoids the need to run autoreconf.
