Re: Noticing Perl stuff along the wire again
On Sat, Apr 5, 2014 at 1:11 AM, Mark Anderson wrote: I'm with you 100% there. Whatever we do it should be properly planned. Let me dig though and put together a draft. On Fri, Apr 4, 2014 at 7:08 PM, Joshua Root wrote: I don't really care what we do with perl as long as it works. I've done way more work on the perl ports than I ever wanted to, simply because they were broken and stopping other stuff from working. I also agree. (But maybe keep support for Perl 6 as a separate port(?) in mind.) What I would probably attempt to do (without claiming that it would work) would be to keep a huge file (database) with CPAN modules (name, version, location, checksums, dependencies, ...) automatically generated and updated with some cronjob. And then write a bit of logic around that in the PortGroup + allowing developers to patch and overwrite stuff when necessary / when things/modules/new versions break. While you are drafting all those things and thinking them through ... I would really love to see integration of ruby's rvm and support for multiple versions of rails in the future (for rails it is very important to support older versions because the applications usually only work with one version and not with others). It's not perl, but it's a very similar problem with bundle automatically installing exactly the right version of dependencies etc. It's not really clear to me how the integration could/should be done and I'm not asking you to write the code yet, but if you have some suggestion, you might think along while solving the problems with Perl. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Noticing Perl stuff along the wire again
On Sat, Apr 5, 2014 at 1:59 AM, Mojca Miklavec mo...@macports.org wrote: I also agree. (But maybe keep support for Perl 6 as a separate port(?) in mind.) Perl 6 is different enough that there's not much point in trying to fit it into this. -- 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: MacPorts Developer Meeting?
On Fri, Apr 4, 2014 at 4:47 PM, Daniel J. Luke dl...@geeklair.net wrote: On Apr 4, 2014, at 3:22 PM, Mojca Miklavec mo...@macports.org wrote: Having the meeting at two locations (one in Europe and one somewhere in USA) at the same time and organizing a short videoconference each day. But that only makes sense if there's sufficient interest and someone should organize the local event there. Let's first figure out if we have sufficient interest to organize the event at all. a /long/ time ago, I suggested a MacPorts meetup after a Macworld, and it ended up being only two people (drernie and me). I would hope that there would be more interest in something now. I was trying to figure out if there was any information about username-continent written somewhere, but couldn't find anything. (Maybe that or the default timezone like UTC+1/UTC-7/... could be useful optional information for http://trac.macports.org/wiki/MacPortsDevelopers for those who don't mind sharing that information.) I think fkr collected some info for the xglobe port - but I don't think it's been updated in forever (it's nomaintainer now...) I found it and attached it. You are right that it seems not to have been updated in forever, as it still uses @opendarwin.org email addresses instead of @macports.org ones. # This file is part of the XGLobe distribution and is taken from xearth # # Format: # latitude longitude Name [color=colorname] # positive latitude - north of equator # negative latitude - south of equator # positive longitude - east of 0ｰ meridian # negative longitude - west of 0ｰ meridian # # to be included in this file, send mail to: f...@opendarwin.org # # to just display these markers on the map: # xglobe -nomarkers -markerfile $PREFIX/share/xglobe/xglobe-markers.opendarwin 38.24 -121.26 drer...@opendarwin.org 37.19 -122.03 esei...@apple.com 37.87 -122.27 ri...@opendarwin.org 37.21 -122.05 s...@opendarwin.org 55.4012.35 ol...@opendarwin.org 51.24 0.21 chris.r...@isode.com 33.50 -118,21 tor...@mrcla.com 37.09 -122.08 j...@opendarwin.org 48.2802 7.4858 pk...@opendarwin.org 46.2248 7.3485 m...@opendarwin.org 49.5210.52 p...@opendarwin.org 38.49 -77.05 w...@opendarwin.org 50.0414.24 land...@opendarwin.org 40.36 -74.03 gwri...@opendarwin.org 33.47 -84.21 fea...@opendarwin.org 37.53 -122.16 ke...@opendarwin.org 45.520155 -122.688643 m...@opendarwin.org 45.53375-122.69855jbe...@opendarwin.org 33.27 -88.49 leim...@mac.com -27.50 152.96 ilis...@opendarwin.org -37.796355 144.981220 ye...@opendarwin.org 37.33 -122.03 wa...@opendarwin.org 34.49 134.34 po...@opendarwin.org 35.98 -78.94 d...@opendarwin.org 37.38 -122.26 fen...@opendarwin.org 48.560510 2.301050 m...@opendarwin.org 35.00 135.45 morim...@opendarwin.org 38.9 -104.75 b...@opendarwin.org 37.37 -122.03 t...@opendarwin.org 35.7194 139.6951 pgu...@opendarwin.org 42.6978230 -84.5150650 dl...@opendarwin.org 56.1610.21 dan...@opendarwin.org 10.496 -66.8982 j...@opendarwin.org 25.110433, 121.528026 dig...@opendarwin.org 48.43 -68.37y...@opendarwin.org 34.331318 135.350835 takan...@opendarwin.org 60.13 24.55 j...@opendarwin.org ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.3.0
Hi,
However, I've noticed during my last use of port_cutleaves from contrib [1]
that I see failures to open Portfiles from registry a lot more often than
I used to.
I tried investigating a little, but haven't been able to pinpoint a reason
for that. […]
Can anybody reproduce this? It might not be a critical problem though,
because it'd only break pre-/post-deactivate hooks, and we don't have a
lot of those anyway.
I've seen this happen with debug output enabled now:
DEBUG: Executing org.macports.uninstall (gettext)
DEBUG: Changing to port directory:
/opt/mports/var/macports/registry/portfiles/gettext-0.18.3.2_0/72c2558ef3fd1fb2daab1b5822e6a86e16af7bb3fb559eef213a28c352e493a4-3049
DEBUG: wrong # args: should be set varName ?newValue?
while executing
set user_options(_portgroup_search_dirs)
/opt/mports/var/macports/registry/portgroups/7bbea60c69221b3e81858a4c11b6740a082d84fa11a3212e202f31720c7e1abc...
invoked from within
$workername eval set user_options($opt) $val
(procedure macports::worker_init line 123)
invoked from within
macports::worker_init $workername $portpath $porturl
[macports::getportbuildpath $portpath] $options $variations
(procedure mportopen line 39)
invoked from within
mportopen file://${portfile_dir}/ $options $variations
(procedure mportopen_installed line 26)
invoked from within
mportopen_installed [$port name] [$port version] [$port revision] [$port
variants] $options
Warning: Failed to open Portfile from registry for gettext @0.18.3.2_0
--- Deactivating gettext @0.18.3.2_0
Can anyone make anything out of that?
I think we might actually want to hold off releasing 2.3 and have another
beta or at least an RC because there are a few things that came up in the
last few days:
Builds on Linux would probably fail because the in-tree copy of Tcl wouldn't
run because of a missing LD_LIBRARY_PATH in base/src/pkg_mkindex.sh.in. I've
added it for trunk in [1], but that hasn't been backported.
Meanwhile #43208 [2] (which only applies on trunk) uncovered that we don't
have a good way for contributed scripts that use the MacPorts API to find and
use the correct Tcl interpreter with the 2.3 release. I have added
$prefix/bin/port-tclsh
to work around the first part of this problem. (Now that I think of it, maybe
a symlink would have been easier than a wrapper script and we might want to
change that.) However, all contrib scripts also source macports_fastload.tcl
from $prefix before loading the macports1.0 package and are still not
prefix-independent because of that. I thought about a couple of ways to work
around that, but given that macports_fastload.tcl is now pretty much useless,
I've thrown it out completely in a series of commits from r118559 to r118569.
I think it makes sense to backport those into 2.3 so we can deal with the
contrib scripts once and don't have to touch them again for 2.4.
Thoughts?
[1] http://trac.macports.org/changeset/118559/trunk/base/src/pkg_mkindex.sh.in
[2] https://trac.macports.org/ticket/43208
--
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.3.0
Am 06.04.14 00:56, schrieb Clemens Lang:
I've seen this happen with debug output enabled now:
DEBUG: Executing org.macports.uninstall (gettext)
DEBUG: Changing to port directory:
/opt/mports/var/macports/registry/portfiles/gettext-0.18.3.2_0/72c2558ef3fd1fb2daab1b5822e6a86e16af7bb3fb559eef213a28c352e493a4-3049
DEBUG: wrong # args: should be set varName ?newValue?
while executing
set user_options(_portgroup_search_dirs)
/opt/mports/var/macports/registry/portgroups/7bbea60c69221b3e81858a4c11b6740a082d84fa11a3212e202f31720c7e1abc...
invoked from within
$workername eval set user_options($opt) $val
(procedure macports::worker_init line 123)
invoked from within
macports::worker_init $workername $portpath $porturl [macports::getportbuildpath
$portpath] $options $variations
(procedure mportopen line 39)
invoked from within
mportopen file://${portfile_dir}/ $options $variations
(procedure mportopen_installed line 26)
invoked from within
mportopen_installed [$port name] [$port version] [$port revision] [$port variants]
$options
Warning: Failed to open Portfile from registry for gettext @0.18.3.2_0
--- Deactivating gettext @0.18.3.2_0
Can anyone make anything out of that?
it looks to be as if the $val in $workername eval set
user_options($opt) $val
needs to be protected (by eg. [list $val]). The command set sees three
arguments.
all the best
-gn
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.3.0
On 2014-4-6 09:22 , Gustaf Neumann wrote:
Am 06.04.14 00:56, schrieb Clemens Lang:
I've seen this happen with debug output enabled now:
DEBUG: Executing org.macports.uninstall (gettext)
DEBUG: Changing to port directory:
/opt/mports/var/macports/registry/portfiles/gettext-0.18.3.2_0/72c2558ef3fd1fb2daab1b5822e6a86e16af7bb3fb559eef213a28c352e493a4-3049
DEBUG: wrong # args: should be set varName ?newValue?
while executing
set user_options(_portgroup_search_dirs)
/opt/mports/var/macports/registry/portgroups/7bbea60c69221b3e81858a4c11b6740a082d84fa11a3212e202f31720c7e1abc...
invoked from within
$workername eval set user_options($opt) $val
(procedure macports::worker_init line 123)
invoked from within
macports::worker_init $workername $portpath $porturl
[macports::getportbuildpath $portpath] $options $variations
(procedure mportopen line 39)
invoked from within
mportopen file://${portfile_dir}/ $options $variations
(procedure mportopen_installed line 26)
invoked from within
mportopen_installed [$port name] [$port version] [$port revision]
[$port variants] $options
Warning: Failed to open Portfile from registry for gettext @0.18.3.2_0
--- Deactivating gettext @0.18.3.2_0
Can anyone make anything out of that?
it looks to be as if the $val in $workername eval set
user_options($opt) $val
needs to be protected (by eg. [list $val]). The command set sees three
arguments.
And I was sure I fixed that. Is this only happening from port_cutleaves,
and not with normal uninstalls?
- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Noticing Perl stuff along the wire again
On 2014-4-6 11:24 , Mark Anderson wrote: Where would be a good place to stick this on the Wiki. There doesn't seem to be a natural spot. I guess a new page like PerlTodo would be fine. Create a ToDo category if you like. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
