the editor then I did
git pull --rebase
For the reasons I don't understand, merge has been recorded.
Sorry for the mess. I hope someone can fix this.
Regards,
Takeshi
---
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev
Dear David,
> I just noticed that you created a port lapack (including BLAS) in r146856. Is
> this really useful? We already have the ATLAS port which provides BLAS and
> LAPACK; the OpenBLAS port which provides exactly the same implementation of
> LAPACK from netlib as your port lapack; and
chosen for reasons which may still be valid, and we
> have a growing collection of currently over 10,000 Portfiles.
I believe that Tcl's unique syntax keeps Portfile concise.
The old languages like Fortran and Tcl survive
because they have their raison d’être!
Takeshi
-
Takeshi Enomoto
is found by
${prefix}/share/cmake-3.5/Modules/FindHDF5.cmake.
HDF5_C_LIBRARY and HDF5_HL_LIBRARY are used in netcdf’s CMakeLists.txt during
the configuration.
-
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev
t care the internal/policy of the package manager.
What they need is a quick way to install the ports they need.
The installation should be preferably automatic.
Most of the users will be upset with the error messages and find that MacPorts
are not for them.
Regards,
Takeshi
-
Takeshi Enomot
If there is a reason behind treating default_variants and manually set variants,
I’d like to know.
If there is no reason and it can be changed, I will file a ticket for this as a
feature request.
I tried to read the MacPorts source but lost at some point...
Takeshi
-
Takeshi Enomoto
take
pretty soon,
but there are other software packages that require 1.6/1.8 API.
Mark, could you roll back and create hdf5-18?
-----
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge
ncarg required the latter option (r147504).
hdfeos5 fails because int and hid_t are used interchangeably.
I created a patches and committed in r147503.
---
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosfor
Dear Ryan and Mojca,
OK. So I see that this is not the problem of the port.
I don’t have a solution at this time,
but I hope that the manually specified variants
and default_variants should be treated equally
in the future.
Regards,
Takeshi
-
Takeshi Enomoto
take...@macports.org
+a.
sudo port install A +a
will install B+a, but when a is in default_variants in A
A/Portfile:
default_variants +a
B is installed, not B+a.
<https://trac.macports.org/ticket/50782>
-
Takeshi Enomoto
take...@macports.org
___
macports-dev m
> since it changes the files the port installs.
The commit with netcdf rev bumps was a mistake but I believe it is worthwhile
to instal this header so I will increase the revision.
Regards,
Takeshi
-----
Takeshi Enomoto
take...@macports.org
___
macports
This means that __LP64__ is not defined for a 32-bit target.
If the machine is 32-bit, long int, which is 32-bit is selected.
But long int is 64-bit on 64-bit machine and this caused an error.
I set universal_variant no to solve the problem.
Thanks a lot.
Takeshi
-----
Takeshi Enomoto
take...@
priate.
> Does this script need to use the same php as the wordpress installation
> it manages?
I don't think you need the same version.
BTW our wordpress port is out of date.
WP-CLI installs the newest version by default,
we don't have to maintain this port.
---
Takeshi Enomoto
take...@
nstall.
So I thought we should also provide a Portfile.
- The script runs with php that it finds. Is this OK?
- The script in phar does not require the extract phase. Can I
destroot directly from ${distpath}?
---
Takeshi Enomoto
take...@macports.org
Portfile
Description: Binar
Dear David,
Thank you for letting me know.
OK, let’s wait a few days to see if we need gsl116 or not.
Regards,
Takeshi
-
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https
Hi,
It seems that the update to gsl-2.x broke fgsl (#50295), which is compatible
with 1.16.
We may need gsl116 until the updates are provided by the upstream.
Regards,
Takeshi
-
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
Dear Ryan,
> Using a Subversion working copy and "svn commit”?
I use subversion.
I use git for other projects, but I used to use subversion at work.
I don’t have any problems with subversion.
I think subversion is suited for centralized repositories.
Regards,
Takeshi
-
Takeshi
ove cc from compilers.choose
when OpenMP is officially supported in clang.
Comments welcome.
Regards,
Takeshi
-----
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mail
Hi,
hdfeos5 was fixed in r143729 and ncarg in r144029.
Thanks,
Regards,
Takeshi
-
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
with a few other ports.
Best,
Takeshi
-
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
if it compiles the ports I
maintain.
I did a quick survey in science directory on the number of ports with
default_variants
gcc46 0
gcc47 4
gcc48 5
gcc49 7
gcc5 0
gcc6 0
Best,
Takeshi
-
Takeshi Enomoto
take...@macports.org
___
macports-dev
as
path:lib/pkgconfig/glib-2.0.pc:glib2 so that glib2-devel could satisfy it.
Done in r138111.
Regards,
Takeshi
-
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman
Dear Josh,
Perhaps pkgconfig?
Yes. You are right. Thanks!
r138121.
Best,
Takeshi
-
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Dear Ryan,
Thanks. Done in r138102.
Best,
Takeshi
-
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
\
The cmake-1.0 portgroup sets CMAKE_INSTALL_NAME_DIR and other helpful
configure.args for you. To take advantage of them, all you have to do is
append to configure.args rather than overwrite it.
Thanks! Now I see the right way.
Takeshi
-
Takeshi Enomoto
take...@macports.org
, but not ld64, on which clang-3.5 depends.
Takeshi
---
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
is the Xcode version of the buildbot?
Is it up-to-date?
Regards,
Takeshi
---
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
.
Takeshi
-
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
.
Regards,
Takeshi
-
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
${configure.f90}.
What is wrong?
A part of a pseudo Portfile:
PortGroup mpi 1.0
use_configure no
compilers.choosef90 cxx
compilers.setup require_fortran
build.env F90=${configure.f90} \
CXX=${configure.cxx}
-
Takeshi Enomoto
take
Dear Ryan and all,
This is unusual. What's the basis for this? Is it because of libstdc++? or
because of the clang version? or something else?
Thank you for noting this. This is not related to libstdc++ because g95 is
written in C.
Probably it is due to clang version.
Clang is somewhat
to the maintainers or the port.
We don't have to remove what are still available for PPC.
Personally I still use a big-endian Power Mac and try to maintain some ports
as far as I can.
-
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing
Hi,
The build initiated by
https://trac.macports.org/changeset/125857
caused a disk overflow of the buildbot for Lion.
https://build.macports.org/builders/buildports-lion-x86_64/builds/23545
Could someone fix the buildbot?
Thanks
Takeshi
-
Takeshi Enomoto
take...@macports.org
Hi,
The build initiated by
https://trac.macports.org/changeset/125857
caused a disk overflow of the buildbot for Lion.
https://build.macports.org/builders/buildports-lion-x86_64/builds/23545
Could someone fix the buildbot?
Thanks
Takeshi
-
Takeshi Enomoto
take...@macports.org
Hi,
The stealth updates of dmd and phobos were handled in r124868 and r124869,
respectively.
Regards
Takeshi
-
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org
.
I expect the tag to refer to a specific state of source.
Can a developer make changes to the tagged source?
If so it would be tedious to follow the stealth update for each commit.
Should I use a release?
Takeshi
---
Takeshi Enomoto
take...@macports.org
successfully parsed: 0
Ports failed: 2
Up-to-date ports skipped: 19914
Regards,
Blair
--
---
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https
with if {! as in
the doc or parse error occurs.
Takeshi
---
Takeshi Enomoto
take...@macports.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Michael,
Thank you for working on this.
I thank you, too.
I imagine many users are using octave-devel right now, not because they want
a development version, but because they want any version that works.
I am one of them, but as a port maintainer-committer I know that
*-devel ports are
Ryan,
Thanks for pointing this out. Done in r111831 and r111834.
BTW buildbot complains the lack of /opt/local/bin/cmake.
Portgroup cmake is used and plplot depends on cmake so cmake should be
installed.
Do I have to explicitly write depends_build port:cmake?
2013/10/2 Ryan Schmidt
Rainer,
Thank you for your help.
depends_build-appendport:pkgconfig
Yes, you are right. I was not careful enough.
It seems that I don't get buildbot failure messages this time.
Takeshi
___
macports-dev mailing list
You're right. Thank you for your suggestion. Committed in r101740. Takeshi
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
The variant could just be removed, which would accomplish the same thing
without annoying the user.
I removed the error message and gcc42 variant that doesn't do anything.
r101744.
Takeshi
___
macports-dev mailing list
Hello,
I need a help from a cmake guru.
I maintain plplot, which has variants to support Fortran bindings.
In fact, these variants do not work except for g95.
https://trac.macports.org/ticket/36982
CMAKE_Fortran_COMPILER passed via configure.args is not used
when checking the Fortran compiler.
How does cmake find a Fortran compiler?
Which file? A file provided in plplot or cmake installation?
After some trials, I found the followings.
* CMAKE_Fortran_COMPILER is used during the main cmake call in build directory.
* However, in build/language_tests/Fortran, the compiler set in FC and
Marko,
Before I notice your message, I updated the port to enable build on Lion.
http://trac.macports.org/changeset/81012
I don't have an intention to maintain this.
Takeshi
___
macports-dev mailing list
macports-dev@lists.macosforge.org
I would assume that the user's difficulty building the software has nothing
to do with the kernel version
You are right! The user reported that g95 built without any problem.
Takeshi
___
macports-dev mailing list
macports-dev@lists.macosforge.org
Hi,
A user reported a problem in building g95 but I could not reproduce the problem
(#28782).
His main.log indicates that he uses a new kernel probably shipped with new Mac
Book Pro (Thunderbolt).
:debug:main OS darwin/10.7.1 (Mac OS X 10.6) arch i386
I could fix Portfile by detecting 10.7.x
I updated ncarg in r75337 that addresses #28043. It turned out that this was
related to update of libpng.
The source code of ncarg uses a symbol int_p_NULL, which has been removed in
libpng 1.4.
In this case I was able to handle the problem by replacing that with (int*)NULL.
There might be
Ryan,
I think it is a good idea to encourage the port writer to contact the
developers.
I have try to do so and often they are happy to mention the MacPorts package
on their web page.
Some of them are MacPorts users and they install the prerequisite software.
Others list MacPorts without
The developer of gcc upc is curious the number of
downloads through MacPorts.
It is not possible to count the installed ports by users
but as a proxy we could count the number of downloads of
source tar balls through the MacPorts mirror sites.
Is there a way for a port maintainer to know a
Hi,
A few years ago sci port maintainers agreed to use gcc43 (now gcc44)
as defaut.
I prefer g95 but I accepted it since gfortran is a majority
has more features (cray pointers, OpenMP) and has become as reliable as g95.
There is a drawback.
It takes hours to build gcc4x to obtain gfortran.
g95
metis: added configure.cc_archflags to aid build for ppc64
...and every other non-default build_arch (for example, building i386 on a
64-bit Snow Leopard machine, or building x86_64 on a 64-bit Leopard machine).
I don't have every arch/os/cpu combination;
ppc64 is the arch I actually
Blair, Ryan,
Thanks for your help. I can sleep well.
Takeshi
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Normally you'd install the older one into a subdir (e.g. lib/${name} and
include/${name}) and have the dependents use appropriate -I/-L flags. Or
you might get away with renaming the files and having the dependents use
something like -ljpeg6.
I decided to create jpeg6b port and install it in
Hello,
I recently updated hdf4. During the update process I found that hdf4
is incompatible with jpeg 7 and higher.
I decided to compile libjpeg.a in pre-configure and keep it and
headers in ${prefix}/lib/hdf4.
I wonder if there are other ports affected especially in graphics.
Similar problems
Josh and Jeremy,
I don't understand this change. Gnuplot seems to work fine with aquaterm for
me on x86_64.
It was my misunderstanding that Aquaterm relies upon Carbon.
I committed the previous version.
Takeshi
___
macports-dev mailing list
Thank you for all the help.
My guess that replacement of libnco.la by ${prefix}/lib ./.libs/libnco.a
is a cause of duplicate name with the old library ${prefix}/lib
seems to be wrong.
Since ./.libs/libnco.a is specified in the full path and nothing else like
-lnco,
the former should be used.
Adam, Jeremy,
Thank you for your reply. Not solved yet. I keep on investigating.
use_autoreconf yes
autoreconf.args -fvi
I tried this but did not help.
I have problem running automake with nco.
The -L${prefix}/lib might be because the Makefile.am is including $(LDFLAGS)
before other link
Hi,
I need a help from autotools (libtool) guru.
I have a port (such as #23645) that have a link problem in which
the older library is found in ${prefix}/lib rather than a freshly built in
e.g. .libs/.
The cause of the problem seems to be libtool --mode link adds
unwated -L${preflix}/lib in
Hi, all,
I'd like to revisit an old issue and see how the fftw-3 and
fftw-3-single ports can be merged into a single port
Can the single- and double-precision ports be made to install in a
non-conflicting manner?
They already do.
I used to maintain fftw-3.
I would like to thank the
Hi,
Can one write a Portfile without version?
The source code I might add to MacPorts does not have a version with it.
Takeshi
___
macports-dev mailing list
macports-dev@lists.macosforge.org
Hi,
I decided to take over the maintenance of netcdf.
I made netcdf built without --enable-netcdf-4 by removing netcdf4 and
dap from default variants. This removes new features but made much
more compatible with many existing packages. For a few exceptions such
as nco, cdo and wgrib2, one can
Ryan,
Thank you for your comments.
MacPorts 1.8.0 will have a replaced_by keyword which will make stub ports
simpler.
I myself experienced problem of conflicts between vis5d and vis5d+
but I don't think there are many users of this package so
I can handle if a user email me.
I used port
Hello,
I maintain vis5d+. I am writing another package that depends on vis5d+.
With vis5d+ in depends_lib, port (1.7.1) command gives error.
DEBUG: can't set depends_lib: invalid depspec: port:vis5d+
port lint does not gives error.
Should I report this as a port bug or change the name vis5d+?
I think scientific users want not universal (i386 and ppc) but 64-bit
(x86_64 and ppc64)
if they have a 64-bit machine.
If a package is build for all the four (i386 x86_64 ppc ppc64),
there will be not problem but it is not always easy to support this.
For example source in fortran is
Hi,
However, to properly link against libfoo.a I also need to
include -lgfortran.
With a fortran compiler, necessary libraries will be linked.
What is the right C compiler
to link against code compiled with g95?
Currently g95 builds against gcc-4.0.4, which is the same source code
as
Hello all,
I did not have problems on Intel Mac but on iMac G5.
So I make small changes for 2.9.15.
Portfiles for versions 2.9.17 and 3.0.1 seem to be ready
and 2.9.19 is available.
IMHO, octave3 deserves a different port since it is said
``significantly different''.
Regards,
Takeshi
Dear Jochen,
the port is openmaintainer, so it is fine to submit reasonable changes
without asking the maintainer (me).
I should have contact you.
With regard to your previous change: are you sure thread-safety works for
all Mac OS X systems. I vaguely remember that it is not supported on
Hi,
A defect of gnudatalanguage has been reported.
http://trac.macosforge.org/projects/macports/ticket/15000
It turned out that the name of a library of ImageMagick had been changed
from libMagick to libMagicCore.
Header file Magick++.h is now in ${prefix}/include/ImageMagick ($
Hi,
I have not been aware of the difference between ghostview and gv
until I found the installation error of the former.
gv-3.5.8 also has some problems with Leopard.
So I recently updated gv to 3.6.3.
I don't see any problems with removing ghostview.
Takeshi
Hi,
This ticket (libwww) has not been taken care of for a while.
http://trac.macports.org/projects/macports/ticket/12851
A package I maintain (science/grads) depends upon libwww.
For grads, the contributed patch seems to be sufficient.
However, I imagine that libwww should affect a number of
Hi,
It would be nice if someone could commit those tickets.
Build failure of g95, in particular, is affetting a number of other
ports.
I submitted hdf4 and tcl-nap about a month ago.
Thanks in advance,
Takeshi
g95: fixes libiconv problem
Peter,
Does not have -I/opt/local/include
Does have -L/opt/local/lib
You are right. Thanks.
There is an inconsistency.
With MacPorts' iconv.h iconv_* are redefined to libiconv_*.
I think I fixed the problem.
I will upload the patch after Trac is back.
Takeshi
Hello Ryan,
I have received an error report on g95.
http://trac.macosforge.org/projects/macports/ticket/13841
It is related to MacPorts' libiconv.
MacPorts' libiconv does not have symbols iconv_*.
There are libiconv_* instead.
System's libiconv have both.
A quick google search tells me that
I can ask the developers of iconv why those functions are not present.
Man pages are iconv_* rather than libiconv_*.
If LIBICONV_PLUG is defined, iconv_* are used.
(See include/iconv.h.in)
It must be introduce to avoid some conflicts...
But if so gcc source should be using libiconv_*.
Please
Markus,
I found that it does not build if mpich2 is installed.
Like a file conflict or a build-time conflict?
opt/local/include/mpio.h
installed by mpich2 conflicts with headers of Open MPI.
I'm not a big fan of conflicting ports: So far we managed to make
most port non-conflicting
Hello,
I have just created a ticket for openmpi to suport fortran better.
I found that it does not build if mpich2 is installed.
If we do not allow both to install at the same time,
(is there a counterpart of Conflicts field of Fink?)
we do not need to put open before mpirun mpicc and mpif90.
Hello,
I became aware of the official release of Tcl/Tk 8.5 in the other
thread.
I tried to upgrade but failed as already reported by Stephen.
The ports for Tcl/Tk require some work to be stable.
http://trac.macosforge.org/projects/macports/ticket/13682
I wanted to upgrade Tcl/Tk to see if
Hello,
I uploaded patches to g95.
It should compile on Leopard on both ppc and i386.
Takeshi
#13190: BUG: g95-0.90 Installation of py-scipy fails because g95
won't compile
Now g95 compiles sources without complaining :-)
___
macports-dev
Hello Juan,
I submitted a ticket for nco-3.9.2 (belongs to science).
If you give us the ticket number... maybe we can help ;-)
Sorry. That is #12639.
I've just added a missing patch.
The old patch to configure is no longer needed.
Takeshi
Hello,
I submitted a ticket for nco-3.9.2 (belongs to science).
Thanks.
Takeshi
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
I updated nco and related libraries.
libdap-3.7.8 #12271
libnc-dap #12253 (in response to the patch Ben MacCall sent to me)
nco-3.9.1 #12274 (please change type to enhancement. would be nice if
the submitter could change or at least confirm before submission)
I would also like you to examine
Hello
I am not with recent discussions these days,
but it seems that the universal option is added to g95 as well.
A user reported that the build with +universal fails on Intel Mac.
I imagine that it would not be easy to build g95 with the universal
option.
At the momemnt, please remove
Ok, let's install both double and float versions as default.
http://trac.macosforge.org/projects/macports/ticket/11613
Looks good.
Thank you for examining my submission.
Should we
- let fftw-3 succeed both double and float versions or
- create a new fftw3 package?
In either cases,
- we
I work on a project that
requires both single and double precision FFTW
Ok, let's install both double and float versions as default.
I was affected by the .Mac's trouble.
Sorry for slow reply.
I made single version in the default.
http://trac.macosforge.org/projects/macports/ticket/11613
I revised nco-3.1.9 to enable ncap2 variants back.
http://trac.macosforge.org/projects/macports/ticket/11611
Please review this fix and commit.
BTW, the cause of the failure is case sensitivity
(there are Ncap2.hh and ncap2.hh in the same directory).
I moved ncap2.hh to ncap.hh and reinplace'd
Hi,
I'd be happy to hear from those have knowledge to suggest a fix.
http://trac.macosforge.org/projects/macports/ticket/11613
fftw-3-sigle does not build on my MacBook Pro.
I should fix this because I am the maintainer of fftw-3 and I need
this for GDL.
But the error below is beyond my
Ryan,
Thanks for letting me know of fftw-3.
I can maintain this.
Mine has a g95 variant.
I'd happy if you consider adding this.
I submitted a portfile for fftw-3.1.2.
fftw-2 and fftw-3 are incompatible so port fftw should remain as
it is.
I submitted a portfile for fftw-3.1.2.
fftw-2 and fftw-3 are incompatible so port fftw should remain as it is.
http://trac.macosforge.org/projects/macports/ticket/11578
Takeshi
___
macports-dev mailing list
macports-dev@lists.macosforge.org
Thank you for commiting GrADS.
However, there are a few loose ends.
1. a few ports required for GrADS are not yet commited.
#11543 netcdf: nomaintainer. I submitted netcdf-3.6.2 and I can
maintain this.
#11542 udunits
#11515 libnc-dap
2. I understand the use of Tcl, but I need a link to
Hello,
I am new to MacPorts and would like to contribute new and update ports
mainly in math and science.
I have some comments on MacPorts homepage.
I find the home page unfriendly to newbies.
They have to find clicking wiki.
Although I understand that WordPress is used so news are shown,
a
92 matches
Mail list logo
