Re: Failed cleanup
On Jan 10, 2015, at 9:58 AM, Joshua Root j...@macports.org wrote: On 2015-1-11 00:18 , Clemens Lang wrote: - On 10 Jan, 2015, at 12:28, Mojca Miklavec mo...@macports.org wrote: I already mentioned a while ago some annoying behaviour of macports: sudo port uninstall some port (maybe also sudo clean) sometimes takes forever. I can uninstall 10 ports, but the time won't multiply by 10, it seems that there's only a single very time consuming step somewhere in the process, but it's not always exactly reproducible. Might be the registry VACUUM at the end. Do you see the uninstall output in normal speed and then it hangs before returning? That is what generally takes a lot of time after uninstalls. Ideally we would only vacuum when the amount of wasted space reaches a certain significant level, but that would not make it any quicker when it does happen, probably the opposite in fact. Not sure if we could add a progress indicator either. We could check the ratio of free pages to total pages and VACUUM only when we reach a certain threshold. This would be VACUUM to recover unused space, but not necessarily to eliminate fragmentation. In general, I’d think VACUUM always takes about the same amount of time, given the same size of data: the algorithm is that a new file is created, and tables are copied into it one by one, I believe. See pragmas for freelist_count https://sqlite.org/pragma.html#pragma_freelist_count and page_count https://sqlite.org/pragma.html#pragma_page_count. James ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Migration instructions
Given that the outdated pseudo port now returns all ports where the darwin version doesn’t match the current version, is it true that Migration of ports (following update of MacPorts) is as simple as: sudo port upgrade outdated This has worked well for me in the last few OS updates, including for Yosemite. If so, maybe the migration instructions here: https://trac.macports.org/wiki/Migration https://trac.macports.org/wiki/Migration should be updated? James___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Configuration and environment check command
Ok, I’ll bite with a few more… port correct port audit port investigate port checkup port repair port fix port fixup port troubleshoot I rather like the last, I think. James ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port echo prints trailing whitespace
Hi Ryan, It does this because it’s prepared to handle showing the version as well. i.e., in port echo installed, for instance. The special cases could be changed to use a minimal amount of white space, I suppose, depending on what fields are being displayed. Note, too, that passing the quiet flag prints only the port name, and no extra whitespace. James On Aug 13, 2014, at 1:55 PM, Ryan Schmidt ryandes...@macports.org wrote: Each line is padded to 32 chars. Anybody know why? More than once I've had to pipe the result through sed -E 's/ +$//' to get rid of this. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New MacPorts web site
Ryan, Congrats. I think it’s starting to look really good. A couple of quick comments: - I think I would swap-in “that” for “which” in the following sentence: MacPorts is a package management system for OS X which lets you easily install… (see http://www.quickanddirtytips.com/education/grammar/which-versus-that-0) - The Install, Upgrade, and Uninstall icons are floppy-disks, if I recognize them correctly. Since nobody uses floppies anymore, and wonder about finding icons that are more apt. James On Apr 7, 2014, at 8:01 AM, Ryan Schmidt ryandes...@macports.org wrote: Dear fellow MacPorts developers and enthusiasts, I’ve been working on a new MacPorts web site for some time, and I would like to share with you my work so far: url: http://macports.ryandesign.com:8080 username: mp password: 333 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks java recipe?
On Nov 16, 2013, at 2:45 PM, Christoph Iserlohn ciserl...@macports.org wrote: Am 16.11.13 22:46, schrieb Ryan Schmidt: On Nov 15, 2013, at 14:04, Daniel J. Luke wrote: Before I do more work on #41378, I figured that I'd ask and see if anyone has worked up a nice recipe for detecting a java install on Mavericks yet? I'd like the subversion-javahlbindings port to be able to warn people and exit early if the appropriate java bits aren't present and I imagine other ports might want the same thing (possibly a candidate for a portgroup, too). We already have a java portgroup… is that for this, or for something else? Currently the java portgroup just tries various methods to find a JAVA_HOME and set it for configure.env, build.env and destroot.env. It does not detect if a JRE or JDK is installed nor does it exit if it can't find a suitable JAVA_HOME. The java port group could stand to be enhanced. Among its lesser sins, it looks repeated for JAVA_HOME rather than looking once and caching that result. In any event, I think this code would be a place to start for enhancement: it’s so simplistic now that there shouldn’t be too much risk of breaking ports that use it. James ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Can't find Tcl configuration definitions: better solution?
On Oct 28, 2013, at 5:12 PM, Ned Deily n...@acm.org wrote: In article a4bc8b94-e300-4d96-be95-889180c33...@macports.org, Ryan Schmidt ryandes...@macports.org wrote: If you do that, make sure you only print that on Mavericks and later, since on earlier OS versions tclConfig.sh is not part of the command line tools and it should already be there out of the box. AFAIK, (and I just checked on a vanilla 10.8.5 system that has never had the CLT installed), tclConfig.sh is *not* present in /System/Library/Frameworks until you install the CLT. That is not a change in Mavericks. What is a change in Mavericks is xcode-select --install vs installing via Xcode Preferences. The --install option is not available in earlier releases, even on 10.8 with Xcode 5 installed. The other thing that is different is that under Mavericks, there are tool shims that will thunk the compilers, etc, into versions in Xcode. So with Mavericks, the MacPorts source install will get a lot further that it would have previously (assuming Xcode has been install)… because the tools available under Xcode are used, and things don’t go bad until it tries to find something (tcl config, in this case), that would be installed by the Command Line Tools, but isn’t available thourgh the shims that provide functionality through Xcode. Note that in the same situation, if Xcode hadn’t yet been installed, the Xcode/CLT install dialog would have been invoked when the shims were first exercised by trying to access clang, or whatever. James ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Can't find Tcl configuration definitions: better solution?
On Oct 28, 2013, at 5:34 PM, James Berry jbe...@macports.org wrote: On Oct 28, 2013, at 5:12 PM, Ned Deily n...@acm.org wrote: In article a4bc8b94-e300-4d96-be95-889180c33...@macports.org, Ryan Schmidt ryandes...@macports.org wrote: If you do that, make sure you only print that on Mavericks and later, since on earlier OS versions tclConfig.sh is not part of the command line tools and it should already be there out of the box. AFAIK, (and I just checked on a vanilla 10.8.5 system that has never had the CLT installed), tclConfig.sh is *not* present in /System/Library/Frameworks until you install the CLT. That is not a change in Mavericks. What is a change in Mavericks is xcode-select --install vs installing via Xcode Preferences. The --install option is not available in earlier releases, even on 10.8 with Xcode 5 installed. The other thing that is different is that under Mavericks, there are tool shims that will thunk the compilers, etc, into versions in Xcode. So with Mavericks, the MacPorts source install will get a lot further that it would have previously (assuming Xcode has been install)… because the tools available under Xcode are used, and things don’t go bad until it tries to find something (tcl config, in this case), that would be installed by the Command Line Tools, but isn’t available thourgh the shims that provide functionality through Xcode. Note that in the same situation, if Xcode hadn’t yet been installed, the Xcode/CLT install dialog would have been invoked when the shims were first exercised by trying to access clang, or whatever. So actually looking for something like tclConfig.sh that is installed by CLT, is probably sufficient, Mavericks or earlier, to complain: you need to install the Command Line Tools. Though on somewhat older Xcode’s that requirement might have been served by installing Xcode itself, not the CLT. James ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112573] trunk/dports/_resources/port1.0/group/github-1.0.tcl
On Oct 27, 2013, at 5:45 AM, Ryan Schmidt ryandes...@macports.org wrote: On Oct 26, 2013, at 16:45, James Berry wrote: On Oct 26, 2013, at 2:01 PM, Ryan Schmidt wrote: On Oct 26, 2013, at 14:09, jbe...@macports.org wrote: Revision 112573 Author jbe...@macports.org Date 2013-10-26 12:09:19 -0700 (Sat, 26 Oct 2013) Log Message Allow the github portgroup to specify that tarballs should come from the archive area In what way does this differ from the tags and downloads? Hi Ryan, Well… partly because I was confused, and partly because github is apparently changing it’s mind. It seems the downloads method is obsolete, Downloads are deprecated. Projects cannot create new downloads, and downloads are no longer shown on the github interface. However downloads that existed before the feature was deprecated still exist, and they can still be downloaded, so ports that use “github.tarball_from downloads” still work. and it also seems that the tarball urls are at least deprecated… see https://github.com/mxcl/homebrew/issues/18797 also. But despite the rumors of deprecation, the tarball/tags url would have worked for me but for a quirk of circumstances that made me believe it was no longer working at all. After your email I went back to check and apparently the tarball style url would work… but note that the checksum is different for some reason between the tarball url for a tag and the archive url for a “release”. Ah yes, releases. When I looked into this previously, the only difference between the “tags” download and the “archive” download was the name of the distfile and the name of the enclosing directory, and yes, as a result, the checksums. For this reason I couldn’t just switch the portgroup to always use “archive”, since that would have invalidated the checksums of all existing ports using “tags”. Since the “tags” URLs still worked, I didn’t bother making a way to download from “archive”. Do we believe downloading from “tags” will stop working in the future? If so that would be a reason to move toward “archive”. If not, then maybe we don’t want to clutter things up with yet another different way to download. It’s not really clear to me whether the github folks have made a clear statement on this. I guess we should just continue with the status quo for now, recognizing that we may need to make a change in the future. I’ve reverted my change that added explicit support for the archive URLs. I’m not quite sure where to go from here. If we believe the brew guys, then we shouldn’t be pouring energy into the tarball urls, as they’re old news, and should be adopting the archive urls, which this change goes in the direction of. If we want to move toward adopting “archive” URLs, the best way may be to switch the github portgroup’s default “github.tarball_from” from “tags” to “archive” and edit all ports currently using the portgroup and not setting “github.tarball_from” and set them to “github.tarball_from tags” along with a comment recommending this line be removed and the portfile adapted accordingly at its next version update. (No need to update ports without a version update, since that would just cause an unnecessary extra distfile fetch and mirror.) Things I wasn’t clear on yet: * Does livecheck behavior need to be updated for archives? I didn’t look into this. * Some ports fetch from a git commit hash instead of a tagged release. What needs to happen with them? I think that as long as these continue to work we’re ok. James ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112573] trunk/dports/_resources/port1.0/group/github-1.0.tcl
On Oct 26, 2013, at 2:01 PM, Ryan Schmidt ryandes...@macports.org wrote: On Oct 26, 2013, at 14:09, jbe...@macports.org wrote: Revision 112573 Author jbe...@macports.org Date 2013-10-26 12:09:19 -0700 (Sat, 26 Oct 2013) Log Message Allow the github portgroup to specify that tarballs should come from the archive area In what way does this differ from the tags and downloads? Hi Ryan, Well… partly because I was confused, and partly because github is apparently changing it’s mind. It seems the downloads method is obsolete, and it also seems that the tarball urls are at least deprecated… see https://github.com/mxcl/homebrew/issues/18797 also. But despite the rumors of deprecation, the tarball/tags url would have worked for me but for a quirk of circumstances that made me believe it was no longer working at all. After your email I went back to check and apparently the tarball style url would work… but note that the checksum is different for some reason between the tarball url for a tag and the archive url for a “release”. I’m not quite sure where to go from here. If we believe the brew guys, then we shouldn’t be pouring energy into the tarball urls, as they’re old news, and should be adopting the archive urls, which this change goes in the direction of. Given that you wrote that port group, I guess I’ll lean your way for advice. James ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112183] trunk/base/src/macports1.0/macports.tcl
On Oct 15, 2013, at 8:02 AM, Jeremy Huddleston Sequoia jerem...@macports.org
wrote:
On Oct 15, 2013, at 3:36, Rainer Müller rai...@macports.org wrote:
On 2013-10-15 01:53, Jeremy Huddleston Sequoia wrote:
On Oct 14, 2013, at 12:34, Rainer Müller rai...@macports.org wrote:
On 2013-10-14 21:22, jerem...@macports.org wrote:
Modified: trunk/base/src/macports1.0/macports.tcl
===
--- trunk/base/src/macports1.0/macports.tcl 2013-10-14 19:00:23 UTC
(rev 112182)
+++ trunk/base/src/macports1.0/macports.tcl 2013-10-14 19:22:30 UTC
(rev 112183)
@@ -597,8 +597,7 @@
set os_endian [string range $tcl_platform(byteOrder) 0 end-6]
set macosx_version {}
if {$os_platform eq {darwin}} {
-# This will probably break when Apple changes versioning
-set macosx_version 10.[expr {$os_major - 4}]
+set macosx_version [exec sw_vers -productVersion]
Afther this change, macosx_version contains the string 10.8.5 instead
of 10.8 as it did before. This breaks some code in base that compares
this variable as a string to 10.5 or 10.4.
Well then those are bugs that certainly should be fixed as well =)
The question would be whether we want macosx_version to story 10.X
only as it did before or fix the comparisons to use version comparison.
We should fix the comparisons.
Writing this condition as
[vercmp $macosx_version 10.5] = 0 [vercmp $macosx_version 10.6] 0
seems a bit cumbersome.
Cumbersome yet correct.
Maybe we just need to add a new version comparison verb, like
vercmp_major_minor that compares only the major and minor segments of the
version.This would accomplish both goals I think: simplify the version
comparison while still allowing us to keep the full version around for
“correctness”.
James
Is there an advantage of storing the third part
of the version number?
Correctness, consistency, the possible need to do something differently for
different dot releases, etc.
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
A couple of port suggestions: jq and awscli
I ran across a couple of utilities just now that aren't yet available in MacPorts. I don't have time to look at these at the moment, but thought somebody else might, as they both look good: awscli -- A cli for Amazon AWS, from Amazon: https://github.com/aws/aws-cli jq -- A very nice looking command line json processor: http://stedolan.github.io/jq James ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [102310] trunk/dports/sysutils/natsort
On Jan 31, 2013, at 3:08 AM, Ryan Schmidt ryandes...@macports.org wrote:
On Jan 30, 2013, at 11:16, jbe...@macports.org wrote:
Revision: 102310
https://trac.macports.org/changeset/102310
Author: jbe...@macports.org
Date: 2013-01-30 09:16:19 -0800 (Wed, 30 Jan 2013)
Log Message:
---
natsort: fix build issue with pickier compiler; add openmaintainer with
permission of maintainer
It's not an issue with the compiler; the issue is that Lion introduces a
function called getline, which conflicts with the function of the same name
that this project defines.
Ooops, I didn't realize getline wasn't available until Lion on Mac OS. My
comment about the compiler getting pickier referred to the fact that it didn't
like the slightly different type definition of the internal getline definition.
Anyway, thanks for fixing that.,
James
Added: trunk/dports/sysutils/natsort/files/natsort.c.diff
===
--- trunk/dports/sysutils/natsort/files/natsort.c.diff
(rev 0)
+++ trunk/dports/sysutils/natsort/files/natsort.c.diff 2013-01-30
17:16:19 UTC (rev 102310)
@@ -0,0 +1,20 @@
+--- natsort.c.orig 2013-01-29 17:23:19.0 -0800
natsort.c 2013-01-29 17:24:23.0 -0800
+@@ -40,7 +40,7 @@
+ #endif
+
+ static int fold_case = 0, verbose = 0, reverse = 0;
+-size_t getline(char **lineptr, int *n, FILE *stream);
++size_t redundant_getline(char **lineptr, int *n, FILE *stream);
+
+ static void trace_result(char const *a, char const *b, int ret)
+ {
+@@ -170,7 +170,7 @@
+ }
+
+ /* This code is public domain -- Will Hartung 4/9/09 */
+-size_t getline(char **lineptr, int *n, FILE *stream) {
++size_t redundant_getline(char **lineptr, int *n, FILE *stream) {
+ char *bufptr = NULL;
+ char *p = bufptr;
+ size_t size;
This patch is incomplete: you've changed the definition of the project's
getline function, but haven't changed the place where the project calls that
function, so this fails to build on Snow Leopard with:
Undefined symbols:
_getline, referenced from:
_main in natsort.o
(maybe you meant: _redundant_getline)
ld: symbol(s) not found
because Snow Leopard doesn't provide a getline function.
Fixed along with other changes:
https://trac.macports.org/changeset/102329
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
MacPorts Mountain Lion Futures
Here's a bit of dreaming out loud about MacPorts under Mountain Lion and future architectures in a Gatekeeper world. With Gatekeeper, there are three (or four) tiers of binary deliver we can/should/might consider signing: (a) The MacPorts installer should be signed. (b) The MacPorts-installation should be signed. The binaries here include daemondo, as well as the Tcl extension libraries. (c) Binaries built by the MacPorts build-bots could be signed. (d) Binaries built by MacPorts users could be signed. I think this would call for at least three-different signing keys: (1) Official MacPorts distribution signing key for (a) and (b). (2) MacPorts build-bot signing key, for (c). This key is more vulnerable to revocation than (1), since it is used to sign a broad variety of software (the ports) that we have somewhat less control over, so it should likely be distinct. (3) The MacPorts user could have a per-user or per-machine signing key with which to sign software built by the user on their machine. If it's possible and feasible to sign binaries for ports, then a per-user and/or per-machine key should be used to sign binaries for each port built. It would be very nice if this didn't require per-port changes, and could be done wholesale. One approach I've pondered: - Create an additional phase (sign) to code-sign. Maybe this would run on the destroot? - The sign phase would examine all files (in the destroot?), and sign each binary (executable, library or framework?) (if not already signed?). - The signing key would be per-user/per-machine. So on the build-bot this would be the configured build-bot key (2), and on a user machine it would be the user's key. If no key then no signing. It seems plausible that all that could be accomplished without too many huge hacks. I likely won't work on any of that any time soon, but thought I'd expose my thinking in case anybody else is so-inclined. I believe Josh has put in the work already to at least accomplish (a). Do we need to create an apple-recognized official signing key for (1) before we distribute that? James smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: MacPorts Mountain Lion Futures
Hi Blair, On Jun 18, 2012, at 8:39 PM, Blair Zajac wrote: Backing up a bit, what do we get by signing? My understanding is that this is required for the App Store, but MacPorts isn't distributed that way. What issues do we run into if we don't sign? Can MacPorts not install preconpiled software without signing? The user has choices to: - Accept only signed apps through the Mac App Store - Accept any signed apps - Allow all apps to run http://arstechnica.com/apple/2012/02/developers-gatekeeper-a-concern-but-still-gives-power-users-control/ Without signing of our binaries, using MacPorts would require Allow all apps to run. Implementing some or all of what I proposed wouid potentially allow Accept any signed apps level of permission. I'll note that I believe it's also possible to specify more granular permissions (allow the execute at this path to run even though it's not signed). Whether doing the work to allow us to notch back the degree of gatekeeper control is important or necessary is up for discussion… (another potential implementation would conceivably tell Mountain Lion to allow our unsigned binaries by path during install). James Regards, Blair On Jun 18, 2012, at 8:30 PM, James Berry jbe...@macports.org wrote: Here's a bit of dreaming out loud about MacPorts under Mountain Lion and future architectures in a Gatekeeper world. With Gatekeeper, there are three (or four) tiers of binary deliver we can/should/might consider signing: (a) The MacPorts installer should be signed. (b) The MacPorts-installation should be signed. The binaries here include daemondo, as well as the Tcl extension libraries. (c) Binaries built by the MacPorts build-bots could be signed. (d) Binaries built by MacPorts users could be signed. I think this would call for at least three-different signing keys: (1) Official MacPorts distribution signing key for (a) and (b). (2) MacPorts build-bot signing key, for (c). This key is more vulnerable to revocation than (1), since it is used to sign a broad variety of software (the ports) that we have somewhat less control over, so it should likely be distinct. (3) The MacPorts user could have a per-user or per-machine signing key with which to sign software built by the user on their machine. If it's possible and feasible to sign binaries for ports, then a per-user and/or per-machine key should be used to sign binaries for each port built. It would be very nice if this didn't require per-port changes, and could be done wholesale. One approach I've pondered: - Create an additional phase (sign) to code-sign. Maybe this would run on the destroot? - The sign phase would examine all files (in the destroot?), and sign each binary (executable, library or framework?) (if not already signed?). - The signing key would be per-user/per-machine. So on the build-bot this would be the configured build-bot key (2), and on a user machine it would be the user's key. If no key then no signing. It seems plausible that all that could be accomplished without too many huge hacks. I likely won't work on any of that any time soon, but thought I'd expose my thinking in case anybody else is so-inclined. I believe Josh has put in the work already to at least accomplish (a). Do we need to create an apple-recognized official signing key for (1) before we distribute that? James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: MacPorts Mountain Lion Futures
On Jun 18, 2012, at 8:56 PM, Joshua Root wrote: On 2012-6-19 13:30 , James Berry wrote: I believe Josh has put in the work already to at least accomplish (a). Do we need to create an apple-recognized official signing key for (1) before we distribute that? That work was basically just support for building flat packages. The person building the release can now simply run productsign(1) on each .pkg. I've done that for the 2.1.x releases. I don't know if you can get a Developer ID registered to a team rather than an individual without buying a corporate ADC subscription. Maybe we can get help from our friends at Apple to get a corporate-style Developer account set up for MacPorts. Since we're not an official organization and have no papers, etc, I have a feeling we'd have a hard-time getting through their qualification process otherwise, but an individual account doesn't seem to really fit the bill either. (Jordan or Ernie: can either of you be of help with this?) James smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: MacPorts 2.1.0 has been released - problems with the progress lines
On May 16, 2012, at 3:51 PM, Bjarne D Mathiesen wrote: Clemens Lang wrote: On Wed, May 16, 2012 at 11:17:02PM +0100, Chris Jones wrote: Is there something I can do to switch this progess thingy off ??? disabling the feature isn't really the same thing as just disabling the eye-candy progress count-down. I suspect you are not the only one who pipes port output to file like this. I don't anymore, but used to when I ran an update via cron. If there is really no way to disable the count down, for this sort of use case, then probably a trac feature request is in order ;) There currently is no way to do this. Please, by all means, file a ticket, and I'll try to get to it as soon as possible. It'll probably involve making a tcl version of isatty(3) and only printing the eyecandy when connected to a tty. Note that we already have a tcl version of isatty, defined in pextlib. James Other than that, running port in verbose mode with -v also disables the eyecandy. ticket filed : https://trac.macports.org/ticket/34480 smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Potential disruption to MacPorts domain registration
It would be best to transfer to another registrar asap, but we are unable to do so because: (1) Our domain is currently under registrar lock because, according to GKG policies, it is within a 60-day period following renewal. (2) Pending resolution of our current dispute, they may decide unilaterally to further extend this registrar lock, effectively holding our domains hostage. James On Mar 29, 2012, at 9:45 AM, Sam Kuper wrote: gkg.net sounds awful. Hope I never have any dealings with them! Wouldn't it be best to simply transfer the domain to another registrar asap? I've found Dreamhost, Moniker and 123-reg to all be reasonably helpful and reasonably priced for domain registration. Sam On 29 March 2012 17:09, Joshua Root j...@macports.org wrote: Short version: Our domain registrar, gkg.net, is threatening to cancel the registration of macports.org and other domains that redirect to it. We do not know whether they will follow through on this threat. If they do, we will have no choice but to move our services to another domain, at least temporarily. Tentatively, that would be macports.macosforge.org for www.macports.org, and trac.macosforge.org/projects/macports for trac.macports.org. We also have macportz.org and macportz.com registered through another registrar in case we need them. If this does happen, the mailing lists will keep working, though @macports.org email aliases will not. Our IRC channel, #macports on Freenode, will also continue to be available. Further information will be posted in these two places if necessary. Background on the issue: James Berry, who handles the domain registrations for the project, recently renewed them. While doing so, he accidentally checked a box requesting another service along with the registrations. He immediately informed GKG of the error, and for the next several weeks corresponded with them, asking them to cancel the unwanted service and provide a refund. They refused to do so. He then sought and obtained a chargeback from his credit card company. After that, GKG contacted him and stated that to avoid closure of his account, he had to pay a chargeback fee (which was greater than the amount refunded), and provide a notarized letter from the Registrant and the person who paid for the services (if the person is different from the Registrant) stating that they understand the charges they incurred, they agreed to the charges, and they will not charge the services back. The letter will also agree to the domains remaining on Registrar Lock until GKG decides that there is no longer a threat of a chargeback from the Registrant and/or the person who paid for the services originally. James will not be providing the requested letter since some of the statements in it would be false. - Josh (for PortMgr) ___ macports-users mailing list macports-us...@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-us...@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Potential disruption to MacPorts domain registration
On Mar 29, 2012, at 8:56 PM, Jeremy Lavergne wrote: My take on this is that GKG.NET has at least one example on record of their behaving in a less than exemplary manner, namely using the BBB logo without permission: http://www.bbb.org/bryan/business-reviews/internet-services/gkgnet-in-bryan-tx-7007745 Sounds like there should be a new complaint filed very soon ... Let's please consider complaints about this issue only after we are able to transition to another registrar… James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Potential disruption to MacPorts domain registration
Sam, On Mar 29, 2012, at 8:24 PM, Sam Kuper wrote: On 29 March 2012 20:11, Ryan Schmidt ryandes...@macports.org wrote: On Mar 29, 2012, at 14:04, Jan Stary wrote: What exactly is the relation of macports to Apple as a corporation? http://trac.macports.org/wiki/MacPortsHistory This is helpful but not very detailed. It doesn't clearly explain how much involvement, if any, Apple has had since this email was sent[1], in which is was written that, 'James Berry, a member of the DarwinPorts steering committee says: We are pleased that by offering us hosting and administrative support services, Apple continues to demonstrate its strong commitment to the open source community. That support is vital to our project. Apple continues to be a big help with many of MacPorts costs through providing hosting, internet access, machine administration, etc, through MacOSForge. A number of Apple employees maintain ports and contribute to the project. We have spoken to some folks at Apple about this issue, they are aware of the potential infrastructure needs this might bring up, and I'm sure they will help help out there as needed. I don't think I'll go into potential legal avenues at this time... James If Apple is still providing hosting and administrative support services, perhaps they could intervene (legally/financially/technologically) to ensure that there is no disruption to the Macports project because of gkg.net's shameful intransigence. If so, who would be the right person to contact at Apple, to bring this to Apple's attention? Is there still a DarwinPorts/MacPorts steering committee? Does anyone here have time to look over http://www.icann.org/en/resources/registrars/registrant-rights-responsibilities and/or related documents for any applicable clauses that might disallow registrars from acting as gkg.net has done? Might be worthwhile. Sam [1] http://article.gmane.org/gmane.os.opendarwin.darwinports/18725 ___ macports-users mailing list macports-us...@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [90075] trunk/base/src/macports1.0/macports.tcl
I agree with Josh. Consider that we're just saying I'm going to be calling myself 'macports' for a while, and I want Xcode to have my preferences while I do. The macports user is a user that macports controls, and is really just a proxy for the current user while macports is running. The irony is that with sudo xcodebuild -license you would be doing something far more expansive: accepting the license for all users of the machine ;) James On Feb 24, 2012, at 4:06 AM, Joshua Root wrote: We're not saving EULA acceptance, just putting it somewhere that xcodebuild can find it when we're running as the macports user. If a different user runs port, their own plist is copied, so if they haven't accepted the EULA they can't still use xcode based on a previous user's acceptance. (Whereas that's exactly what can happen if one user runs 'sudo xcodebuild -license' and then another user runs port.) Can we even tell whether xcodebuild or xcrun is failing because it wants EULA acceptance as opposed to some other reason? - Josh On 2012-2-24 20:56 , Jeremy Huddleston wrote: Wait a minute... I'm jumping in a bit at the end here and missed a bit of this progress, so apologies if I'm a bit off based with my limited context... are you guys saving EULA acceptance for the user by copying the plist? IANAL, but that seems far inside the not-quite-legal zone. Macports should do no copying of the plist or otherwise mess with the license setting for the user. If it encounters a problem, it should tell the user to run 'sudo xcodebuild -license' ... not copy preferences around all over the place. Again, IANAL, but that sounds like the safest bet to me. --Jeremy On Feb 21, 2012, at 12:08 PM, Dan Ports dpo...@macports.org wrote: On Wed, Feb 22, 2012 at 02:39:42AM +1100, Joshua Root wrote: And why did Dan set the ownership in the first place? I can see that making sense in the per-port dirs but not really in the global one. Without it, the plist had 0600 permissions and it was owned by root, so xcodebuild couldn't access it once we dropped privileges. Changing the permissions works to. Speaking of which, do we actually need to create the plist in both the global and per-port home directories? It looks like only the global one is actually used, regardless of $HOME. (This surprised me, I figured it'd be the other way around.) Dan ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [90075] trunk/base/src/macports1.0/macports.tcl
On Feb 24, 2012, at 2:55 PM, Jeremy Lavergne wrote: I'm honestly not sure, sorry. I did file a radar asking for a better command line interface to accepting and checking the status of acceptance, and that should work for your needs, but unfortunately that doesn't quite help with the released product =/ It happens, sometimes more than not :-) The other thread indicated the accepted for everyone approach is what we'd like to avoid for legal reasons, so I think MacPorts plans to make due with the user plist copying. Despite the tenor of that thread, I'm far more concerned that we don't put speed bumps in the way of the user. Adopting their existing preferences is a reasonable way to be pretty certain that they've already accepted the agreement, as they've likely run the Xcode GUI. It cuts way down on the number of people who won't be able to tell what's going on, and to whom we would have to explain to run some separate command to accept the preferences. rantIdeally, there would be a way to check if the license has been accepted for a given user. Even more ideally, that stupid command line license agreement wouldn't be in the command line tool. It's got to be one of the stupidest, most big-company-bureaucratic things I've ever seen. But I guess I can't deny that Apple is now big-company, can I? I mean, what are they protecting by making you accept a license agreement to run xcodebuild from the command line? What are they protecting that you don't already agree to when you download Xcode, or join the developer program, or run any number of other command line tools? Frankly, I don't know, because like 99% of users I haven't read the agreement, even though I've accepted it, a fact that makes click-through licenses like this hard to enforce in court. /rant :) James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Xcode command line EULA
On Feb 24, 2012, at 3:48 PM, Jeremy Huddleston wrote: On Feb 24, 2012, at 15:08, James Berry wrote: ... I mean, what are they protecting by making you accept a license agreement to run xcodebuild from the command line? What are they protecting that you don't already agree to when you download Xcode, You didn't agree to anything when you downloaded XCode (accept maybe the App Store TOS). See below. or join the developer program, You don't need to join the developer program to run XCode or run any number of other command line tools? They're making you accept the XCode EULA. In the past, you used to accept this when you ran the XCode installer package. Now that XCode.app is just copied, they needed a new way of showing you the EULA, so it's done on first launch of XCode (or any of the XCode command line tools that are covered by it). Yes, the '$PAGER /path/to/License.txt' approach is not as pretty as the AppKit version, but you're running a command line tool, so you're already opting in to that way of doing things. As Xcode is available only through the Mac App Store now (or through the developer program), and because the app store allows a custom EULA to be attached to an app, it seems that a much more reasoned approach would be to simply attach the Xcode EULA to the App Store entry for Xcode, and have it be done with. I don't know, maybe they did that too ;) In any event, when the user accepts the App Store terms of service, they agree to be bound by the terms of any custom agreements attached to apps that they buy… (http://support.realmacsoftware.com/discussions/rapidweaver/3434-mac-app-store-license). As convoluted as is that chain of agreements, I'm not sure it's any less enforceable than is the new command line EULA. But frankly, I don't think enforceability is really the issue: it's all just bureaucratic CYA, like I said before ;) James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Xcode 4.3 issues, potential solutions
On Feb 20, 2012, at 3:15 AM, Dan Ports wrote: On Fri, Feb 17, 2012 at 10:32:48AM -0800, James Berry wrote: (2) If developer_dir is not set, or is not correct, do the following, in order (a) Use any valid value from: xcode-select -print-path (the user has chosen an Xcode, or Xcode's default is correct) [...] I've basically implemented 2.a and 2.b in r88970-88971, btw. The only caveat being that if the user has explicitly set an invalid developer_dir in macports.conf, I don't catch or warn about that. I tried this on a fresh Lion install that didn't have a previous installation of Xcode. I installed 4.3 and didn't run xcode-select, leaving it with no selected Xcode. I didn't get any warnings about needing to run xcode-select. I'll take a closer look tomorrow, but I think what's going on here is that xcode-select exists, but fails to run. `xcode-select -print-path` gives an error message and returns with a non-zero error code, and set_developer_dir doesn't handle that. Dan: thanks. Any more information you can give about the failure mode would be appreciated. According to my testing, xcode-select -print-path can be safely run even if you've never agreed to the Xcode agreement, so I don't think that's what this is, though I could be wrong. Is it truly the case that xcode-select -print-path did return an error code, or didn't return a valid path? If the path it was returning was valid, maybe everything was working just right. A last alternative is that mdfind wasn't finding any Xcode's, a case in which we give the user no pre-fabricated command lines, and also no warning at all (something can happen, as you know, if the spotlight index isn't complete yet) James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [90028] branches/release_2_0/base
On Feb 20, 2012, at 1:49 AM, Joshua Root wrote: On 2012-2-20 19:32 , Dan Ports wrote: On Mon, Feb 20, 2012 at 05:48:55PM +1100, Joshua Root wrote: On 2012-2-20 11:14 , jberry at macports.org wrote: Use xcrun -find to find xcode compiler if it's not found in /usr/bin. I deliberately didn't merge these, and the changes in r90031, in order to minimise the changes made on the stable branch. I'd really rather both merges were reverted. Every line of code that's changed means more delay before we can do an Xcode 4.3 compatible release and a greater likelihood of something going horribly wrong. Does that mean we'll have to require people to have both Xcode and the command-line tools package installed? Yes, that seems the best way to avoid future problems if the compiler paths inside developer_dir change again. We require other stuff in /usr/bin anyway, like make. Much as I'd like to be able to avoid having to require the stand-alone tools installer, I agree with Joshua that it's going to be hard to dispense with for now. We could get quite a way with xcrun -find, and could likely even successfully use it for tools like Make, but I think getting there is not a short term solution. We have a stable and well-known solution at present, in the stand-alone tools installer. For tools that _are_ only in the develoer_dir, I think that using xcrun -find is a better solution than hard-coding paths into the Xcode binary: we're better off asking Xcode where those things are than trying to sneak around its back to find them. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Xcode 4.3 issues, potential solutions
On Feb 20, 2012, at 5:40 PM, Dan Ports wrote: On Mon, Feb 20, 2012 at 07:41:00AM -0800, James Berry wrote: Any more information you can give about the failure mode would be appreciated. According to my testing, xcode-select -print-path can be safely run even if you've never agreed to the Xcode agreement, so I don't think that's what this is, though I could be wrong. Is it truly the case that xcode-select -print-path did return an error code, or didn't return a valid path? Yes -- it seems that xcode-select returns an error code if no Xcode directory is selected (vs. having an invalid one selected). AFAICT, this happens only if there was no earlier Xcode version installed, and it doesn't matter whether or not you've launched Xcode and accepted the EULA. I fixed this in r90074. After that change, your mdfind stuff works great and suggests the right command to run. (This shouldn't affect any older systems; on all the ones I've seen, either `xcode-select -print-path` works or it doesn't exist at all.) Cool, thanks. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [89994] trunk/base/src
On Feb 18, 2012, at 10:46 PM, j...@macports.org wrote: set env(HOME) to our own dirs (#31827) and link user's xcode 4.3 plist into them Josh, Have you tested this? On my lion system, ~/Library/Preferences is 0700 permissions (and I don't think I've done anything to change that), which would presumably imply that symlinking to Xcode prefs from ~macports/Library/Preferences/xcodeprefs wouldn't achieve anything, as the Xcode user wouldn't be able to resolve the symlink to a directory it could read. That 0700 permissions there, btw, was also why I set perms on ~macports/Library/Preferences to that value… ??? James___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: XCode 4.3
Art, On Feb 19, 2012, at 5:11 AM, Art McGee wrote: Sorry to intrude: sudo xcode-select -switch /Applications/Xcode.app Shouldn't the command actually be: sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer If you use the former, then xcodebuild -version returns: error: can't exec '/Applications/Xcode.app/usr/bin/xcodebuild' (No such file or directory) For me, using either /Applications/Xcode.app or the longer version seem to accomplish the same thing. My xcode-select doesn't have any trouble with the shorter version. % sudo xcode-select -switch /Applications/Xcode.app xcode-select -print-path xcodebuild -version /Applications/Xcode.app/Contents/Developer Xcode 4.3 Build version 4E109 What's your system version? Perhaps the version of xcode-select you have is less capable? % xcode-select -version xcode-select version 2307. James I also tried an experiment, to see if Xcode.app can only reside in /Applications, and it doesn't seem like it has to. I've chosen to place Xcode 4.3 and all the other downloadable utilities in their own directory, leaving 4.2.1 in place, and switching between them: Command: sudo xcode-select -switch /Developer xcode-select -print-path xcodebuild -version Output: /Developer Xcode 4.2.1 Build version 4D502 Command: sudo xcode-select -switch /Xcode/Xcode.app/Contents/Developer xcode-select -print-path xcodebuild -version Output: /Xcode/Xcode.app/Contents/Developer Xcode 4.3 Build version 4E109 I've got MacPorts, Fink, and Pkgsrc co-existing on my machine, and they're working OK so far. Art ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: XCode 4.3
On Feb 19, 2012, at 9:00 AM, James Berry wrote: Art, On Feb 19, 2012, at 5:11 AM, Art McGee wrote: Sorry to intrude: sudo xcode-select -switch /Applications/Xcode.app Shouldn't the command actually be: sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer If you use the former, then xcodebuild -version returns: error: can't exec '/Applications/Xcode.app/usr/bin/xcodebuild' (No such file or directory) For me, using either /Applications/Xcode.app or the longer version seem to accomplish the same thing. My xcode-select doesn't have any trouble with the shorter version. % sudo xcode-select -switch /Applications/Xcode.app xcode-select -print-path xcodebuild -version /Applications/Xcode.app/Contents/Developer Xcode 4.3 Build version 4E109 What's your system version? Perhaps the version of xcode-select you have is less capable? % xcode-select -version xcode-select version 2307. Okay: before Xcode 4.3 (with Xcode 4.2.x, for instance), it's necessary to pass xcode-select the path of the top-level developer directory instead of to the app itself. I've change macports in r90018-90019 to suggest a path that's appropriate for the version of Xcode found. James James I also tried an experiment, to see if Xcode.app can only reside in /Applications, and it doesn't seem like it has to. I've chosen to place Xcode 4.3 and all the other downloadable utilities in their own directory, leaving 4.2.1 in place, and switching between them: Command: sudo xcode-select -switch /Developer xcode-select -print-path xcodebuild -version Output: /Developer Xcode 4.2.1 Build version 4D502 Command: sudo xcode-select -switch /Xcode/Xcode.app/Contents/Developer xcode-select -print-path xcodebuild -version Output: /Xcode/Xcode.app/Contents/Developer Xcode 4.3 Build version 4E109 I've got MacPorts, Fink, and Pkgsrc co-existing on my machine, and they're working OK so far. Art ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [90028] branches/release_2_0/base
On Feb 19, 2012, at 10:48 PM, Joshua Root wrote: On 2012-2-20 11:14 , jberry at macports.org wrote: Revision: 90028 http://trac.macports.org/changeset/90028 Author: jberry at macports.org Date: 2012-02-19 16:14:16 -0800 (Sun, 19 Feb 2012) Log Message: --- Merge from trunk: r88540,r88541,r88546,r88777,r88779,r88787,r89359,r89984 Use xcrun -find to find xcode compiler if it's not found in /usr/bin. I deliberately didn't merge these, and the changes in r90031, in order to minimise the changes made on the stable branch. I'd really rather both merges were reverted. Every line of code that's changed means more delay before we can do an Xcode 4.3 compatible release and a greater likelihood of something going horribly wrong. Josh: it's your call. I want to see an Xcode 4.3 compatibility ASAP too. Reverted. James. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: XCode 4.3
On Feb 18, 2012, at 10:09 AM, Dan Ports wrote: On Sat, Feb 18, 2012 at 08:32:40AM -0800, James Berry wrote: - The record of whether you've agree to the license is stored per-user in ~/Library/Preferences/com.apple.dt.Xcode.plist: [...] Maybe we need to create a macports user home at something like /opt/local/users/macports, with no access except to /opt/local/users/macportsLibrary/Preferences??? ? Well, there are already some ports that want to access the macports user's $HOME and run into problems because it's /var/empty. In https://trac.macports.org/ticket/31827 we were talking about creating a temporary, per-build home directory. If we're going to do that, which sounds like a good idea, we could populate it with that plist. Of course, we'd still have to get the user to accept the license once to generate that plist. For now, in r89989, I've changed the home directory for the MacPorts user to /opt/local/var/macports/home, and made this writable by root only, and given it a preferences directory that the macports user can write to. These means the user will be able to create an Xcode preference that sticks for the macports user. There are several things this change doesn't attempt to accomplish: - It doesn't provide any particular special checking, prompting, or help for the user to create this preference. - It doesn't (pending further feedback) update the dmg installer to fixup the setting for the macports home directory. - I also didn't attempt to fix r31827 or even think much about that case. If it is desired to create a per-build home directory, then copying certain files into it from /opt/local/var/macports/home/... and or the user's real home directory might make sense. I'm not convinced that using /opt/local/var/macports/home is any safer than using /var/empty. Root can change files in either one. By using /opt/local/var/macports/home, we at least isolate macport's damages to it, and avoid having ports that might dirty /var/empty; we could also choose to clean it of files we don't want. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Xcode 4.3 issues, potential solutions
On Feb 17, 2012, at 8:05 AM, James Berry wrote: Sounds like there are at least several issues that MacPorts is facing with Xcode, not all of which are new: (1) Make sure the Xcode terms have been accepted (2) Find the proper Xcode is use. We can no longer assume /Developer (3) Ensure the command line tools have been installed. While we use xcrun now to find Xcode compilers, I think we still have a dependency on the command line tools for thinks like the linker… (?) [the xcrun discovery code is not yet in a release MacPorts] Some potential solutions to these issues: (1) Likely, we should examine the result from xcodebuild or xcode-select to look for the case where the terms have not be accepted, and ask the user to first run Xcode. I haven't explored this at all. (2) If developer_dir is not set, or is not correct, do the following, in order (a) Use any valid value from: xcode-select -print-path (the user has chosen an Xcode, or Xcode's default is correct) (b) Examine the output from: mdfind kMDItemCFBundleIdentifier == 'com.apple.dt.Xcode' - This may give multiple results if the user has multiple Xcodes installed - The best solution to multiple results would likely to display those results, and ask the user to run xcode-select to select one. - Alternatively, we could examine the versions from mdls -name 'kMDItemVersion', and use the most recent version installed I've basically implemented 2.a and 2.b in r88970-88971, btw. The only caveat being that if the user has explicitly set an invalid developer_dir in macports.conf, I don't catch or warn about that. I'm not working on 1 or 3 at the present time, btw, in case somebody else wants to. James (3) If we do have a dependency on the command line tools package, we could either look for key files we know we need (compilers, linker, etc) or use pkgutil to ensure the package has been installed: pkgutil --pkgs | grep com.apple.pkg.DeveloperToolsCLI, potentially followed by something like pkgutil -pkg-info or -verify (likely it would be easier to just look for some required tools and ask them to install the command line tools) ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Xcode 4.3: where do xcode-select, xcodebuild, xcrun, etc, come from?
The idea behind Xcode 4.3, as I understand it, is that it can be a first-class App Store app: it doesn't need to install anything as root, or outside of its sandbox: it uses external installers for this (witness the Command Line Tools installer, etc). So if that is indeed the case, I have a question some of the tools of Xcode that are installed in /usr/bin: xcodebuild, xcode-select, xcrun, etc. My questions are these: (1) Do these tools exist on a machine if Xcode has never been installed? (i.e., are they part of the core os?) (2) Are these tools installed when Xcode 4.3 is first run? (or at some later time?) (3) Are these tools installed only when the Command Line Tools installer is run? I don't have a virgin machine to use to get to the bottom of that, but if anybody can help with answers it would be useful… James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: XCode 4.3
Hi Dan, On Feb 17, 2012, at 2:43 PM, Dan Ports wrote: On Fri, Feb 17, 2012 at 12:58:56PM -0800, James Berry wrote: On Feb 17, 2012, at 12:41 PM, Daniel J. Luke wrote: I had 4.2 installed, downloaded 4.3 from the app store, ran new Xcode (4.3), told it to uninstall 4.2 (/Developer and the installer from /Applications), had it install the command line tools, quit and xcode-select -print-path was set to /Developer I just tried this in a VM that previously had Xcode 4.2 installed. Same procedure, same result. If you're still in this state, (unlikely), maybe you could check that the code I checked in earlier handles this case correctly for you? I tried this with trunk at r89972. What I got wasn't particularly helpful: Warning: xcodebuild exists but failed to execute Error: No valid Xcode installation was found; please install Xcode Error: Error: No valid Xcode installation was found: please install Xcode Error: Error: No valid Xcode installation was found; please install Xcode Error: Error: No valid Xcode installation was found: please install Xcode Error: Warning: Xcode does not appear to be installed; most ports will likely fail to build. Interesting. Questions: - Was Xcode 4.3 installed at that point? - Had Xcode been run after the install? (In other words, had you agreed to the license?) - I'm particularly intrigued by xcodebuild exists but failed to execute. Is that a symptom of it trying to get you to agree to the license? - What would xcodebuild -version and xcode-select -print-path have returned at that point? The other messages imply that (a) xcodeselect -print-path failed to return anything valid, and (b) that mdfind didn't find the Xcode binary anywhere, and (c) that there was no Xcode at /Developer. The fact that the messages are duplicated several times is due to the way in which those messages are hooked in. While it's not ideal, too many messages is better than none at all! James Dan -- Dan R. K. Ports MIT CSAILhttp://drkp.net/ ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: XCode 4.3
On Feb 17, 2012, at 3:02 PM, Dan Ports wrote: On Fri, Feb 17, 2012 at 02:53:13PM -0800, James Berry wrote: - Was Xcode 4.3 installed at that point? - Had Xcode been run after the install? (In other words, had you agreed to the license?) Yes, I had installed Xcode 4.3, launched it, accepted its offer to remove the 4.2 installation, and installed the command-line tools. - I'm particularly intrigued by xcodebuild exists but failed to execute. Is that a symptom of it trying to get you to agree to the license? - What would xcodebuild -version and xcode-select -print-path have returned at that point? I don't think so. I didn't try xcode-select -print-path, but I did try xcodebuild and xcrun and in both cases got: Error: No developer directory found at /Developer. Run /usr/bin/xcode-select to update the developer directory path. ...so presumably the developer directory path was set to /Developer. It would be interesting to know what xcode-select -print-path returns at this point. The other messages imply that (a) xcodeselect -print-path failed to return anything valid, and (b) that mdfind didn't find the Xcode binary anywhere, and (c) that there was no Xcode at /Developer. The fact that the messages are duplicated several times is due to the way in which those messages are hooked in. While it's not ideal, too many messages is better than none at all! Yes, I also tried the mdfind command in the shell and it didn't seem to return anything either. What Mac OS X version is this on? What does the following return? mdls /Applications/Xcode.app James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Xcode 4.3: where do xcode-select, xcodebuild, xcrun, etc, come from?
On Feb 17, 2012, at 2:45 PM, James Berry wrote: The idea behind Xcode 4.3, as I understand it, is that it can be a first-class App Store app: it doesn't need to install anything as root, or outside of its sandbox: it uses external installers for this (witness the Command Line Tools installer, etc). So if that is indeed the case, I have a question about some of the tools of Xcode that are installed in /usr/bin: xcodebuild, xcode-select, xcrun, etc. My questions are these: (1) Do these tools exist on a machine if Xcode has never been installed? (i.e., are they part of the core os?) (2) Are these tools installed when Xcode 4.3 is first run? (or at some later time?) (3) Are these tools installed only when the Command Line Tools installer is run? I don't have a virgin machine to use to get to the bottom of that, but if anybody can help with answers it would be useful… As a partial answer to my own question, it appears that these files are installed at least as part of the 10.7.3 update: pkgutil --file-info /usr/bin/xcodebuild shows that Xcode build was in the com.apple.pkg.update.os.10.7.3.11D50b.combo update, along with some other packages, such as com.apple.pkg.InstrumentsSystemSupport. (xcrun and xcode-select are in those packages too). So my early conclusion is that Apple saw Xcode 4.3 coming, and snuck these tools into the 10.7.3 update; this may be an oversimplification. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Xcode 4.3 missing X1SDK?
On Feb 16, 2012, at 11:43 AM, Jack Howarth wrote: Does anyone know what the situation is for Xcode 4.3 vs X11 SDK? The Xcode 4.3 installation doesn't install the Command Line Tools by default and installing Xcode 4.3 from the AppStore left the Downloads preference panel in Xcode 4.3 showing the Command Line Tools as installed. This forced me to use the deinstallation scripts to remove Xcode 4.2.1 entirely and reinstall Xcode 4.3. However now I see no way to reinstall the X11 SDK for Xcode 4.3. I hope this isn't pointing to Apple deprecating X11 completely out of Mac OS X with Mountain Lion. Sigh. Jack ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev Try explicitly running the installer for the Command Line Tools for Xcode - February 2012, available from the developer downloads page. You can get to this from Xcode Open Developer Tool/More Developer Tools… I just did this and I believe it installed X11 stuff. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: xcode 4.3 breaks macports
On Jan 29, 2012, at 1:34 AM, Andrea D'Amore wrote: On Sat, Jan 28, 2012 at 18:04, James Berry jbe...@macports.org wrote: (3) With my recent changes to finding compilers, we now use xcrun to find a compiler, but not to invoke it. One possible change that could help this issue of the sdk setting would be to use the xcrun to actually invoke the compiler, passing the -sdk option to it (this option takes the sdk name, rather than the full path, letting it use its knowledge of the Xcode and sdk locations to form the ultimate path). But this option wouldn't help at all for invoking non-xcode compiler versions. (4) I played around with various ideas for getting the Xcode tools xcrun or xcodebuild to actually spit out the needed sdk path. One thing that would I think work would be to build, and include with MacPorts, a simple xcode project that contained a script phase that would print out needed paths. This project could be invoked with xcodebuild, passing it the needed -sdk name, and the output from the script phase parsed to garner any needed paths for isysroot, and even for Xcode itself if needed. Hopefully somebody with time and/or inclination can implement one of these options, or one of their own ;) Generally speaking I'd say that 4) seems wrong to me, I haven't checked how compiler is actually invoked (exec, open, mp's tcl extension?) but I'd say that 3) would be a better option. Let me be clear that #4 is just a way to get Xcode to tell us the path to the sdk(s). It wouldn't actually be used to actually build. We would just call xcodebuild with the project, and parse the output, which would give us the sdk path as needed to build our configure.sdkroot. I see that xcrun has a -find option that prints the full path to the tool passed as argument, has this option gone in 4.3? In macports trunk, we call xcrun with the -find option to get it to tell us the path to the desired compiler. This seems to be working well. I suspect that final builds of Xcode 4.3 may improve the compiler installations such that this may not be necessary, but it also lets us work with the Xcode 4.3 of today, and should't hurt anything in the future. If xcrun is unable to give a path to the compiler, we fall-back to looking in /usr/bin/, etc.. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: xcode 4.3 breaks macports
On Jan 29, 2012, at 3:48 AM, Rainer Müller wrote: On 2012-01-28 00:18 , James Gregurich wrote: I'm not sure if this is known or not, but Xcode 4.3 breaks macports. I'll report what I have learned in hacking my macports install into working. Note that /Developer has been moved inside the Xcode.app package and the internal structure of Developer has changed. I don't have access to Xcode 4.3 and this is just a developer preview, not the final product. I would suggest in whatever project you got access to this pre-release, please file an enhancement request to clarify how the final product will implement this. However, if it really moves /Developer into /Applications/Xcode.app, will there be any symlinks for the tools in /usr/bin? Would it require running Xcode once to create them? Or will users have to edit their PATH to use them? Code in trunk now uses xcrun -find to find the compilers, so users shouldn't have to edit their paths. Note that James Gregurich's issue is with the change of location for the /Developer directory, and how that affects the sdkroot location. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: xcode 4.3 breaks macports
On Jan 27, 2012, at 5:32 PM, James Gregurich wrote:
expat.
I'm developing on 10.7 against the 10.6 sdk.
On Jan 27, 2012, at 5:03 PM, James Berry wrote:
James,
I've check into svn a fix for the first problem. We now use xcrun to find
the compiler tools, and so can find the compilers okay.
I hadn't encountered the other issue, likely because I haven't been building
any macports app that use the sdk.
I'll see if I can take a look at the other issue (sdkroot) as well. Is there
a particular port you saw this issue with?
I looked a bit into the issue of the sdkroot. I'm not inclined to work on it
any more, as it's not something I have time for, nor particular interest in, at
the moment. But I thought I'd take a moment to give some ideas for anybody who
might want to look into it:
(1) Xcode keeps moving this stuff around, and is now moving it yet again, and
into the Xcode app directory. The fact that we're having to add lots of special
cases likely indicates we're going about things in the wrong way. We might want
to consider a change of approach for this setting.
(2) That said, one possibility would be to just add some new checks and
special cases, figure out where the user has their Xcode app (either by looking
in the application directory in system and user domains, or perhaps by using
the mdfind tool), and perpetuate the madness with new special cases and checks
to find the SDKs therein. This likely, would be the easiest thing to do, at
least in the short term.
(3) With my recent changes to finding compilers, we now use xcrun to find a
compiler, but not to invoke it. One possible change that could help this issue
of the sdk setting would be to use the xcrun to actually invoke the compiler,
passing the -sdk option to it (this option takes the sdk name, rather than the
full path, letting it use its knowledge of the Xcode and sdk locations to form
the ultimate path). But this option wouldn't help at all for invoking non-xcode
compiler versions.
(4) I played around with various ideas for getting the Xcode tools xcrun or
xcodebuild to actually spit out the needed sdk path. One thing that would I
think work would be to build, and include with MacPorts, a simple xcode project
that contained a script phase that would print out needed paths. This project
could be invoked with xcodebuild, passing it the needed -sdk name, and the
output from the script phase parsed to garner any needed paths for isysroot,
and even for Xcode itself if needed.
Hopefully somebody with time and/or inclination can implement one of these
options, or one of their own ;)
James
James
On Jan 27, 2012, at 3:18 PM, James Gregurich wrote:
I'm not sure if this is known or not, but Xcode 4.3 breaks macports. I'll
report what I have learned in hacking my macports install into working.
Note that /Developer has been moved inside the Xcode.app package and the
internal structure of Developer has changed.
In xcode 4.3, /Applications/Xcode.app/Contents/Developer/usr/bin does
not contain clang and clang++.
Also, the sdkroot calculation is also now wrong as the macosx sdk is now in
the platforms folder. To illustrate, the path to the 10.6 sdk is now:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk
Here is the line I corrected to make the change in portconfigure….although
I'm sure you'll need more logic to make this change only for Xcode 4.3.
set sdk
${developer_dir}/Platforms/MacOSX.platform/Developer/SDKs/MacOSX${macosx_deployment_target}.sdk
-James
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: xcode 4.3 breaks macports
James,
I've check into svn a fix for the first problem. We now use xcrun to find the
compiler tools, and so can find the compilers okay.
I hadn't encountered the other issue, likely because I haven't been building
any macports app that use the sdk.
I'll see if I can take a look at the other issue (sdkroot) as well. Is there a
particular port you saw this issue with?
James
On Jan 27, 2012, at 3:18 PM, James Gregurich wrote:
I'm not sure if this is known or not, but Xcode 4.3 breaks macports. I'll
report what I have learned in hacking my macports install into working. Note
that /Developer has been moved inside the Xcode.app package and the internal
structure of Developer has changed.
In xcode 4.3, /Applications/Xcode.app/Contents/Developer/usr/bin does not
contain clang and clang++.
Also, the sdkroot calculation is also now wrong as the macosx sdk is now in
the platforms folder. To illustrate, the path to the 10.6 sdk is now:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk
Here is the line I corrected to make the change in portconfigure….although
I'm sure you'll need more logic to make this change only for Xcode 4.3.
set sdk
${developer_dir}/Platforms/MacOSX.platform/Developer/SDKs/MacOSX${macosx_deployment_target}.sdk
-James
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [89359] trunk/base/src/port1.0/portconfigure.tcl
On Jan 26, 2012, at 1:32 PM, Ryan Schmidt wrote:
On Jan 26, 2012, at 14:01, jbe...@macports.org wrote:
Revision: 89359
http://trac.macports.org/changeset/89359
Author: jbe...@macports.org
Date: 2012-01-26 12:01:52 -0800 (Thu, 26 Jan 2012)
Log Message:
---
Guard search for xcrun inside catch clause.
If xcrun is not present (Xcode 2.x, apparently), then
this allows us to fall-back to a conventional compiler
location rather than failing outright due to a lack of
xcrun.
This fixes this ticket, right?
https://trac.macports.org/ticket/32890
Yes. Thanks, I hadn't noticed that ticket. Marked as fixed.
James
Modified: trunk/base/src/port1.0/portconfigure.tcl
===
--- trunk/base/src/port1.0/portconfigure.tcl 2012-01-26 18:37:43 UTC (rev
89358)
+++ trunk/base/src/port1.0/portconfigure.tcl 2012-01-26 20:01:52 UTC (rev
89359)
@@ -430,8 +430,7 @@
global developer_dir
# Use xcode's xcrun to find the named tool.
-set xcrun [findBinary xcrun $portutil::autoconf::xcrun_path]
-if {[catch {set toolpath [exec ${xcrun} -find ${name}]} result] == 0} {
+if {[catch {set toolpath [exec [findBinary xcrun
$portutil::autoconf::xcrun_path] -find ${name}]} result] == 0} {
return ${toolpath}
}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: macfuse
On Dec 22, 2011, at 10:08 AM, Jordan K. Hubbard wrote: Just wondering if it's time to remove this port given that it's been abandonware since 2008 and fuse4x has effectively replaced it on all versions of OS X that matter. The maintainer for it is set to dports, hence this query on the general list. Hi Jordan: dports is Dan Ports, a real person. I understand your confusion ;) James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Strange Behavior
On Dec 21, 2011, at 6:24 AM, Jeremy Lavergne wrote:
This code is in opIntersection in base/src/port/port.tcl [1]. First, it
creates a map from the port names to the list index in $b. If a port
appears multiple times in this list, the last index is stored in the
array. This is clearly wrong as we would want to keep the first entry.
I'd recommend we simply do a check before [re]setting the port in the array:
if {[lempty [array get port $bitem]]} {
lempty returns 1 if we get an empty list of matches back.
array get returns a list containing pairs of elements (using string
match). If the array contains no elements then an empty list is returned.
Interesting. I wrote that code, though it's been a while.
The intersection code wasn't really written to consider multiple identical
items, and frankly the concept of any order within those lists seems a little
accidental, so I'd be a little leery of even assuming that order counts,
especially given that the source of the ordering is some other operation.
Though it might work in the case described here.
If you want to enforce having a local port override the tree, what if you were
to do that by enforcing that the database search for category:kde, etc, return
only the first of any such items found?
There are clearly other ways to generate a portlist which includes multiple
identical ports: I'm not sure that first wins or last wins is always better.
Another question I'll ask: at the level of the portlist, ports are identified
only by name and version. Are these ports even distinct at that point? What are
the name/version of the two ports in this case? (fullname as stored in a port
entry in the portlist)?
James
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Strange Behavior
On Dec 21, 2011, at 8:46 AM, Jeremy Lavergne wrote: If you want to enforce having a local port override the tree, what if you were to do that by enforcing that the database search for category:kde, etc, return only the first of any such items found? It's not so much a local port as it is a local repository, where they're controlled in sources.conf. Listing sources [default] or simply higher in the list is suppose to give precedence. There are clearly other ways to generate a portlist which includes multiple identical ports: I'm not sure that first wins or last wins is always better. In this instance, documentation does say first wins. What will we impact by changes in this area of the code though? Another question I'll ask: at the level of the portlist, ports are identified only by name and version. Are these ports even distinct at that point? What are the name/version of the two ports in this case? (fullname as stored in a port entry in the portlist)? I believe a single repository can have duplicates, otherwise we'd never run into the web site update failing due to duplicate portnames. Granted I was using two separate repositories, but the fact they're coalesced might indicate we currently treat it as one giant repository without any checks such as enforcing order. In my case, any KDE package that was I was upgrading triggered this: * kde4-runtime @4.7.4_0 (from file://...) * kde4-runtime @4.7.3_0 (from ports.tar) I checked in a change to opIntersection, which makes sure the two lists being passed to opIntersection are unique. Can you verify that fixes your problem? James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: MacPorts is hijacking account on MacOSXServer
On Jul 25, 2011, at 7:16 PM, Rodolfo Aramayo wrote: David is right. This is a hard issue and believe me I have burn many, many candles during Holidays and weekends trying to solve userIDs conflicts in MacOSServers. It looks to me that MacPorts installer has these options: 1. Look if the machine is a server 2. If NOT a server then: 3. Either just create the 'user:macports group:macports' account picking: a. the next available UUID account number (somewhere in the 500s) b. using a pre-determined UUID and GUID, say 600... c. giving the user the option to select which one or what =I assume that if the machine is not a server but IS listening to a server through OD it does not matter, as long as there are UUIDs in the 500s available 4. If the machine is a server then: 5. Check if the server is listening to an OD and if yes then either quit and request a user 'macports' and a group 'macports' be created on the master OD or proceed to create the user 'macports' and a group 'macports' on the master OD. 6. If however the server is running a 'local directory' then test if all 500 numbers are taken and of they are proceed to create a user 'macports' and a group 'macports' in the 1000s. Because the server is running a local directory this should be OK, because all the users in the 1000s should be accounted for. The problem is when you pick a user 'macports' and a group 'macports' without testing the server/non-server/local/master OD configuration Am I missing something? What if MacPorts were simply always to try to find an unused id in the range 500 - 1000, using whatever algorithm is convenient? James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [79522] branches/gsoc11-statistics/base/src/port/port.tcl
On Jun 16, 2011, at 12:44 PM, Daniel J. Luke wrote: On Jun 16, 2011, at 3:40 PM, Ryan Schmidt wrote: I assume you are correct. I'm not sure whether Bradley was pointing this out as a good or bad thing, but in my opinion it might be a bad thing. If I have ports installed that are not part of the MacPorts repository, I might not want the MacPorts project to know about them. In which case you would simply not opt-in to turning on this data sharing, right? I suppose, too, that we could do some filtering of ports against the main repository. That might be tough on the client side, as I'm not sure we know which the main port tree is from the client perspective, but certainly on the server side, before any stats are collected (or maybe displayed?), the list of ports could be filtered against those ports in the main repository. Doing so would protect not just the privacy concerns that Ryan is worried about (though I also agree with Daniel's solution to these), but would also avoid any confusion by users due to the appearance of such phantom ports that would otherwise show up in usage but aren't available publicly. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Xcode 4 issues
Sorry for the cross-post, but as this issue has been on both the users and the dev lists, I'm posting to both. I know that there's a lot of concern about the cost of Xcode 4, as well as of some compatibility issues. I know the portmgr team has been thinking about this, and has passed on some of the concerns to some relevant people within Apple. I thought I'd take a moment to bring up what we do know about this issue, based on various reports. (1) Xcode 4 is currently not free. It is available for $5 US through the Mac App Store, or available to developer who have a paid Apple Developer account (~$99). (2) Xcode 3 is still available, and remains free at this time. (3) PortMgr is requesting that wherever possible, no Xcode 4 requirements be placed into ports. (4) By and large, the Xcode 4 tools, if installed, should be compatible with MacPorts, though this issue hasn't been widely explored; there may be some issues with SDK versions available in the various Xcode installs. (5) The SDKs installed by various versions of Xcode have always been a changing target; this isn't a completely new issue. (6) Apple has made no public announcements, that I know of, concerning the developer tools environment in Mac OS X Lion, expected for release this year. We don't know, for instance, if Xcode 3 will continue to be free, or whether it will function on Lion, nor if there will be any other build environment (tools, SDKs, etc) available for free for Lion. I think that's a fair list of some of the issues. If there are more, they can be added to the list. Maybe somebody can get some of this growing compilation onto the Wiki. It's my hope and desire, and I believe that of most members of the MacPorts project, that there will continue to be no-charge development tools and SDKs available on Mac OS X into the future. A good compromise between free and not free might be for there to be free command line tools and SDK, with the Xcode GUI available for a fee. In summary, not much has changed as-of yet: Xcode 3 is still available and free; what the future holds is somewhat less certain. I encourage MacPorts developers and users who want to influence that future to make their wishes known to any Apple contacts you might be able to leverage. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: multiple arch flags won't work with -E
On Feb 3, 2011, at 11:05 AM, Toby Peterson wrote:
On Feb 2, 2011, at 5:49 PM, James Gregurich wrote:
Im not sure what to do about this one. The expat port does not use
muniversal to do a universal build. The configure script fails when it
attempts to invoke the preprocessor. Is the correct answer to switch the
port to muniversal or is there another flaw for which I should be looking? I
suppose this is happening because I modified the system to put the arch
flags in CPPFLAGS. However, if you don't supply an arch flag of some kind
when building ppc on i386, it seems that should be incorrect behavior even
if it happens to work. It definitely doesn't work without the -arch flag
when building armv6 on x86_64. Can I get some guidance on what this system
SHOULD be doing?
configure scripts simply aren't good at cross-compiling. A typical approach
is to run the configure script and just correct the results after the fact. A
few of my ports do this by running ed scripts that replace definitions with
appropriate #ifdef'd values.
I haven't looked in detail at the work you did on MacPorts to try to allow
cross compiling to iOS, James, but my impression is that it's kind of a hack
that might work in some cases but probably can't be made to work reliably or
consistently across ports. I suspect that a better solution is to come up with
a consistent variant name ('ios' or something) that could be implemented
per-port as needed, and with appropriate tweaks for each particular port. There
might be some scaffolding or support that the generic macports infrastructure
could supply (paths to to the iOS SDKs or compilers, for instance, perhaps) but
in general I think you'll find each port will need to be individually addressed.
James
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Thanking the MacPorts team
I'd like to take a moment to reflect on the last year and thank the great team at MacPorts for all the work that's been done over the last year by port Committers and Maintainers, the PortMgr team, and by all the users who file bug reports. MacPorts has 136 committers, something like 7671 ports, and countless users. Over the last 4 years there have been over 56000 commits to the MacPorts repository, if I am to believe the CIA committer tracker here: http://cia.vc/stats/project/MacPorts. Thanks to the port managers, Josh, Rainer, Ryan, and Bryan (I could almost make that rhyme). Thanks to Josh and Rainer, among many, many others, for all the great updates to the MacPorts base code, to Ryan who amazingly has committed over 7751 times to the repository in the last 4 years, primarily in updating ports. Thanks to Bill and MacOSForge and Apple for hosting MacPorts. The list could go on and on, but it would start to sound like the Golden Globes :) Thanks everybody. You know who you are. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Looking for maintainer interested in Java ports
Hi Dave, You're not already a MacPorts committer, right? Why don't you prepare any patches you want to Maven, and submit them as a ticket. Among that change should be your change to the maintainer line. Please note in the ticket that you want to become maintainer of the port. Also, please let me know when you've filed that ticket, and I'll get it applied right away. Thanks! James On Oct 11, 2010, at 4:36 AM, David Hudson wrote: Hi, I'll take Maven. Thanks Dave - I'm listed as a maintainer on a lot of key Java ports, which I've been sadly neglecting of late because I'm not doing much with Java recently. Is there anybody out there who would be interested in adopting those ports? James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Looking for maintainer interested in Java ports
Dave, One other note: you may want to check in and coordinate with Blair Zajac who is one of the maintainers of the maven2 and maven3 ports. James On Oct 11, 2010, at 8:22 AM, James Berry wrote: Hi Dave, You're not already a MacPorts committer, right? Why don't you prepare any patches you want to Maven, and submit them as a ticket. Among that change should be your change to the maintainer line. Please note in the ticket that you want to become maintainer of the port. Also, please let me know when you've filed that ticket, and I'll get it applied right away. Thanks! James On Oct 11, 2010, at 4:36 AM, David Hudson wrote: Hi, I'll take Maven. Thanks Dave - I'm listed as a maintainer on a lot of key Java ports, which I've been sadly neglecting of late because I'm not doing much with Java recently. Is there anybody out there who would be interested in adopting those ports? James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Looking for maintainer interested in Java ports
I'm listed as a maintainer on a lot of key Java ports, which I've been sadly neglecting of late because I'm not doing much with Java recently. Is there anybody out there who would be interested in adopting those ports? James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: darwinports.com legal action
When we last looked into forming a legal entity for MacPorts, we decided that creating our own legal entity was probably too onerous and too expense, both in terms of up-front money and in terms of annual costs and legal/accounting maintenance. One of the options that we considered then, and should perhaps consider again, is something like the Open Source Conservancy, which basically operates as a legal umbrella organization for open source projects: http://conservancy.softwarefreedom.org/overview/ We started discussions with them then, but they seemed to get pretty bogged down details that had no end, so dropped the discussion for lack of a significant driver. James On Mar 7, 2010, at 4:28 PM, Jeremy Huddleston wrote: LLC is probably the wrong approach. The X.org foundation has been having issues updating their status from an LLC to a Non Profit Corporation. We should probably incorporate, then make ourselves an NPO. I'll look up what's involved with this. Registering a trademark does not mean we would need to be aggressive about enforcing it. In fact, we DO have marks for DarwinPorts and Macports, but they are not registered. In order to take legal action, we would be required to register those marks. Registering the mark just gives us more legal footing to stand on. It does not in any way force us to take action against individuals. It allows us to do so if we want to. I will ask Apple Legal before taking any action, since I am an employee of Apple and don't want to in any way appear as though my actions in making this protest are representative of Apple (unless it is the decision of Apple Legal to take that route). As I mentioned, I am just doing this from a consumer protection standpoint. If anyone else wants to get onboard (The MacPorts Project or Apple Inc.), that would certainly be welcome. I'm getting the impression that The MacPorts Project would be interested in pursuing this so long as it was not costly, so I'll start looking into options along that front. Thanks, Jeremy On Mar 7, 2010, at 16:01, Ryan Schmidt wrote: On Mar 7, 2010, at 17:36, Joshua Root wrote: Thanks for taking this on. The MacPorts Project is, legally, just a collection of individuals. MacPorts is not a registered trademark. (Neither is/was DarwinPorts.) We're not really happy about that being the state of affairs, but when we looked into creating a legally recognised organisation, we concluded that it would be too expensive. I haven't looked into nonprofit organizations, but for comparison, to start an LLC in the U.S. only costs a couple hundred dollars, as does registering a trademark. And I understand we have some money available from past Google Summer of Code projects. Of course, if we registered a trademark, we'd have to enforce it and go after everyone who uses the name without permission. (There are probably a half dozen sites I've found that use MP or DP in their names and are confusing e.g. in that they don't say they aren't an official site.) My impression is that Apple is interested in having MacPorts be useful and successful. It has therefore occurred to me to ask if Apple Legal would be interested in taking on this issue for us. But I have not asked them. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: The opendarwin .com debacle
So all of this comes down to page rank for our site vs that other site. I've got to believe we have better incoming links to our site, so if we better structured our site to do cross linking between categories (and perhaps stoop to the subdomain tricks he does), we could presumably improve this situation immensely. James On Oct 22, 2009, at 11:21 AM, Mark Hattam wrote: On 22 Oct 2009, at 18:54, Jordan K. Hubbard wrote: Ultimately, I don't think anyone is going to be able to force the darwinports.com folks from doing what they're doing (and I really wish the original poster had managed to keep the notion of opendarwin / darwinports separate in his head, since they're really not related issues, yet there's opendarwin in the subject on this whole thread). Those who were around back when macports was chosen as the new name will know that this was, in fact, one of the big reasons for doing so. This problem has been around for as long as MacPorts has been renamed. The real problem at this point, however, is not darwinports.com and all this chest-thumping and hand wringing is giving me nothing but feelings of deja-vu since we have done it all before. It didn't help then and it's utterly unlikely to accomplish anything now. The real problem here is one of branding. Why/where are users even hearing the name darwinports when it's been essentially dead for over 3 years? Projects rename themselves all the time and somehow manage to make the name change stick. What this project needs to ask itself is why the name change has not stuck as successfully here and then fix that problem rather than re-fighting old battles. - Jordan Go to Google ... enter something like ... mysql5 port macosx 1. mysql.com 2. out of date way to get php5, mysql5, apache2 using MacPorts ... what's gawk nawk ??? 3. the unwanted site ... 8. again the unwanted site, with a sublist of lots more results ... further down some hits for the trac to with bugs ... nowhere in the first 100 hits iswww.macports.org So it's little wonder that the other site keeps cropping up. Google does have a good number of pages ... search for ... site:www.macports.org In fact there are 328 hits for site:www.macports.org mysql5 but having found which of those is a relevant one ... most of them have the generic The Macports Project - Available Ports page title. Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: The opendarwin .com debacle
Well, Mat Caughron m...@caughron.com, or caugh...@gmail.com, who is the guy who runs the darwinports [dot] com site in question, and who makes money by confusing our users and soliciting donations for the work of the macports proejct, none of which ever get to the project, is a apparently a consultant who professes to specialize in OS and web security. Maybe we should just publicize all of the information about what a sleeze-ball he is about this, and see if it gets back to his clients? We could put a big banner on our page: Mat Caughron is a sleezeball: read more. Maybe we can get some of the trade press to do an article on people who make money by unethically pretending to be open-source software projects? James On Oct 14, 2009, at 7:14 PM, Bryan Blackburn wrote: On Wed, Oct 14, 2009 at 03:55:14PM -0700, Scott Haneda said: On Oct 14, 2009, at 1:16 PM, Jeremy Lavergne wrote: [...] I recall in the past when reading his emails with the portmgrs that he thought it was helpful to visitors. We need to document that it's clearly not and inform him as such. Legal action can already be taken since macports.org is copywriter with all rights reserved. He is likely stealing content from us. What is the last communication that was had with Matt, and what is his position? Is there any point in opening dialogue with him again? The last public communication, that I know of, is linked on our DarwinPorts page: http://trac.macports.org/wiki/DarwinPorts [...] What is it, it is not .net as far as I can tell, which seems to be available. I would like to purchase this domain now, and donate it to macports, I can do the redirection or they can have the entire domain. How do I proceed? I used to own darwinports dot net and just had it forward to the right place; I didn't renew it a couple years ago because of the move to MacPorts in all things. At this point, it's been MacPorts for over three years now, so the real message these days is really, DarwinPorts is long dead. This is a concern, that site is beating the official source in ranking http://www.google.com/search?hl=ensource=hpq=darwinportsaq=foq=aqi=g10 Yeah, I think that's mostly because of portname.domain being used. [...] It is a violation: all rights for access to content on macports.org are RESERVED. We can technically already slap him with a takedown notice. Can you find the ISP? I do not think there would be a lot of luck hitting up register.com, as domain take downs are a nasty road to go down. Note that there really isn't any kind of actionable violation, as MacPorts uses the BSD license, and the web page there looks to be his own creation... Bryan [...] ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Removal of port options i and x
Hi Bryan, On Mar 12, 2009, at 10:54 PM, Bryan Blackburn wrote: I'd like to see two options from port removed, -i and -x. For -i, the man page says Read commands from stdin. Short for -F - which means for handling commands from, eg, pipes. However, not using -i does that anyway as echo info pkgconfig | port works identically to echo info pkgconfig | port -i. Using 'port -i' is also identical to just 'port' as they both drop you into interactive mode. The only difference I can see is that -i allows you to specify commands on port's command line, then when those are done, port drops to interactive mode instead of exiting. If there's no other use for it, is that a very necessary option? I wrote all that stuff, so I'll comment. I think later use was the primary motivation for -i. When this was written there was not yet any experience with interactive mode, piping of commands, etc. So it wasn't clear to what degree we'd need control. I think time has shown there to be little demand for the subtleties of this feature, so I'm fine with removing -i, especially as one can reconstruct it using -F - As far as -x, that's on ticket #13918: http://trac.macports.org/ticket/13918 Basically we have two mutually exclusive options -x and -p, but without specifying either port acts in some other, odd, almost in-between mode. As mentioned on that ticket, I'd much prefer to see port default to what -x does, and simply keep -p for those who want port to continue past errors. Any objections? Here, too, when port was largely rewritten to add support for having commands work on multiple ports/pseudo-ports, there was a bit of a change of behavior, so I put these extra flags in to control how it might work. I think defaulting to the -x behavior is fine. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Deprecating port list
Hi Ryan, On Mar 13, 2009, at 1:42 AM, Ryan Schmidt wrote: I have not used port list or port echo very often. Now that I'm looking at them, I'm confused about echo's behavior. I'll try to answer this; the reasons for this are a little subtle. As the author of this stuff, at least I understand the motivations involved. The ports that may be specified on the command line may be general (apache), or more specific (apa...@1.1), or more specific yet (addition of variant specs). So the list of ports we build up includes those various degrees of information. port tries to be careful not to assume more than it knows. If you just say port echo zlib, it just knows that you've specified zlib, but not anything else about it. pseudo-ports, at least in some cases, expand to much more specific information. port echo installed, for instance, knows exactly which version of apache is installed, and so will expand the pseudo-port to that more specific instance of the apache port. You're thankful for this behavior when you say something like port uninstall inactive, and rely on the inactive pseudo-port to expand to a specific port and version of the inactive port. Depending on the particular pseudo-port, the version information may relate to the latest version of the port, or a version that is installed. port is also careful, when doing set operations on ports, to do the right thing in promoting or coalescing this information. If I remember right, for instance, apache and apa...@1.1 will resolve to apa...@1.1, but apa...@2.0 and apa...@1.1 will resolve to the null set. Etc. That background laid, I'll try to get to the answer. port echo really does just tell you all the information this it has about the port specifications you've given. In the case of port apache (or port zlib), it doesn't know anything else. Where you specified more, or where a pseudo-port supplied more specific information, it has more knowledge, and will report it. Remember that port echo, itself, doesn't query any database of ports: it just echos what you gave it (including expansions thereof). The pseudo-ports, on the other hand, do hit the database, and so may have supplied more information from there. Hope that helps. James I have zlib installed: $ port installed zlib The following ports are currently installed: zlib @1.2.3_2+universal (active) port list zlib shows the name, version and category: $ port list zlib zlib @1.2.3 archivers/zlib port echo zlib shows the name only: $ port echo zlib zlib But port echo installed shows the name and version, revision and variants: $ port echo installed | grep ^zlib zlib @1.2.3_2+universal Why does echo behave differently depending on whether zlib was specified implicitly via the installed pseudo-port, or explicitly on the command line? I guess what's happening is that installed is expanding to not only the names of the installed ports but also their version, revision and variants, which I can even fake: $ port echo zlib @1.0_0+foo+bar zlib @1.0_0+bar+foo ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Deprecating port list
On Mar 12, 2009, at 11:28 PM, Andre Stechert wrote: The difference in the output between 'port installed' and 'port echo installed' seems to be about as minor as the difference between 'port echo installed' and 'port list installed': 'port installed' lines look like: a52dec @0.7.4_0 (active) 'port echo installed' lines look like: a52dec @0.7.4_0 'port list installed' lines look like: a52dec @0.7.4 audio/a52dec Why not just make the output of port echo installed rich enough to handle whatever use cases A good answer is that if you read the reply I just gave to Ryan, you'll see that port echo is extremely lightweight, and meant to be so. It just tells you what you told it. It really doesn't have the information that port list gets. And if we put it into the position of having to get that information, than it looses its value of just parroting what you've told it. port cat - well, i guess technically cat is technically a noun, but in this case, I think it's being used as a verb :-). port cd - you can do that only in interactive mode, right? Strictly speaking, you can do port cd on the command line, but it doesn't generally have any effect. (port can change the current directory for the duration of its execution, but there's no way it can change the current directory for its parent process. It would be cool if it could, but I know no way to achieve that. Any ideas? Even more strictly speaking, you can use the cd command on the command line. Try this, for instance: port cd apache \; file \; dir \; url :) Jaes ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Deprecating port list
On Mar 13, 2009, at 9:22 AM, Andre Stechert wrote: A good answer is that if you read the reply I just gave to Ryan, you'll see that port echo is extremely lightweight, and meant to be so. It just tells you what you told it. It really doesn't have the information that port list gets. And if we put it into the position of having to get that information, than it looses its value of just parroting what you've told it. Indeed. I guess what I was trying to point out is that the subtle differences between 'port installed', 'port echo installed', and 'port list installed' will likely be lost on most users and even if they weren't, the value of doing the lightweight thing may not justify the amount of confusion it causes. All that being said, no measurement has been done, so this is all conjecture. I would advocate keeping echo as it is, since it has a very real function which would be mutated by trying to add more to it. If list needs to be modified to be more useful, or renamed show, or whatever, I think that's fine. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: MacPorts 1.7.0 has been released
Congratulations to all of those who worked so hard on this release, and who pulled the final rabbit out of the hat by releasing it! Well done. James On Dec 13, 2008, at 8:12 PM, Bryan Blackburn wrote: The MacPorts Project is happy to announce that, after nearly a year in the making, the 1.7.0 version has been released. It is now available via the usual methods: ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
New PortMgr team announced!
The (current) PortMgr team is pleased to be able to announce the appointment of a new PortMgr team. Four people expressed interest in the PortMgr positions, and have all been appointed by proclamation: Ryan Schmidt Rainer Müller Joshua Root Bryan Blackburn We, the (previous) members of the PortMgr team, will do all we can to assist in a transition to the new members. As previously discussed, we will move to a group (loosely and temporarily named the MacPorts Council of Elders) which serves as an advisory board to the project. Please welcome Ryan, Rainer, Joshua, and Bryan, and direct further questions at them ;) Sincerely, the past portmgr members, Juan, Markus, James smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Terms? Re: New PortMgr team announced!
Hi Ernie, Your question is an excellent one, and probably one best addressed by the new portmgr team... I think your proposal sounds good. James On Oct 14, 2008, at 9:12 AM, Ernest Prabhakar wrote: Hi James et al, Are there any explicit terms of service (in both senses of the phrase :-)? I'd like to propose that the new team commit to serve from Oct 1st, 2008 (retroactively) to Oct 1st, 2009, with an option for them to renew in one year blocks. In particular, they need to indicate their desire to continue as PortMgr by July 1st, 2009, so as to give plenty of notice in case they need a replacement. Is that reasonable? -- Ernie P. On Oct 14, 2008, at 6:39 AM, James Berry wrote: The (current) PortMgr team is pleased to be able to announce the appointment of a new PortMgr team. Four people expressed interest in the PortMgr positions, and have all been appointed by proclamation: Ryan Schmidt Rainer Müller Joshua Root Bryan Blackburn We, the (previous) members of the PortMgr team, will do all we can to assist in a transition to the new members. As previously discussed, we will move to a group (loosely and temporarily named the MacPorts Council of Elders) which serves as an advisory board to the project. Please welcome Ryan, Rainer, Joshua, and Bryan, and direct further questions at them ;) Sincerely, the past portmgr members, Juan, Markus, James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [macports-mgr] Hey, I would like to propose that we cut the gordian knot.
Hi Jordan, As usual, you work well to cut through the bureaucracy ;) I'm not so opposed to going along with your suggestion to just get this thing done, or that an official vote may be superflous. But I also think it's premature to assume that the list of nominees so far, is complete, given that we haven't called for nominees (or interested parties) yet. So I'd like to request that anybody interested in PortMgr announce their intent (via nomination, or not) by the close of this Friday. James On Oct 8, 2008, at 5:55 AM, Jordan K. Hubbard wrote: (http://en.wikipedia.org/wiki/Gordian_knot) Having just read jmpp's request for a bit more time to sort out a voting process, I must confess to feeling more trepidation than assurance. To be completely fair, he does note several times that he and the rest of the moribund portmgr team would like to move quickly, but given the degree to which that group has also demonstrated itself to be overworked and less than involved in the day to day affairs of MacPorts, anything which delays a solution also runs the risk of blunting some of the current enthusiasm should said process end up dragging out longer than anticipated (which, as experience amply suggests, it invariably does) and I honestly don't think we can afford that at this late stage. I would therefore like to suggest that we simply ratify the following list rather than dragging out a lengthy voting process for a set of positions which, from a certain angle, might even be viewed as largely ceremonial since there is no real power afforded by membership in the portmgr team. Volunteers will always choose to follow (or not) such a group on the basis of the credibility of its individual members rather than any fancy paper hats they may be wearing, and the sooner we simply slam those hats on some credible heads and say Thank you! Get started!, the sooner we can all get back to discussing the real question of how to get to where we need to go next. As a courtesy to the outgoing portmgr team, I would also be perfectly happy to see them be the official ratifiers of this new team, assuming it passes their sniff test and they're also willing to do so in the next day or two, otherwise I would be just as happy with a statement along the lines of if there are no significant, well-argued objections in the next 72 hours, they're it! Quick, before they change their minds! :-) Portmgr (subject to individual acceptance, of course - we still haven't heard from two of the four): Ryan Schmidt Bryan Blackburn Rainer Mueller Joshua Root [Note: Any subset of the above would also be acceptable - 4 is not some magic minimum number, for all the reasons I've already outlined] Release engineering team: Ryan Schmidt (interim or longer, if he wants it) Julio Biason I'm really not trying to undercut anyone here, least of all jmpp, but seriously folks - we've been suffering from a leadership/ directional vacuum for quite some time now and I don't think we need to bog down the only solution to be offered in quite some time by getting all constitutional about it or saying hey, wait, let's all think about this for awhile and engage in lengthy discussion! That might have been a good plan of action about a year ago, and I would be also more than happy to see the new portmgr establish a framework for elections and term limits and all the other checks and balances that they might wish to create for future generations, but what we need right now is an immediate interim government and some long overdue action on the release engineering front. Any objections? - Jordan ___ macports-mgr mailing list [EMAIL PROTECTED] http://lists.macosforge.org/mailman/listinfo.cgi/macports-mgr smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Call for PortMgr interest/nominations
Per my previous note to Jordan, I'd like to set a deadline of this coming Friday, Oct 10, for those wishing to be part of the new PortMgr slate. If you are interested in these posts, please express your interest, or ask somebody to nominate you, by that time. In throwing in your hat, or accepting a nomination, I think it would be appropriate to include a paragraph or so about what makes you want to be involved, and why we should care ;) Such notices should be given in email to the MacPorts development list. If you have already written such a note, you don't need to do so again. Based on the amount of interest, we'll decide on an appropriate way to select the new slate. James smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [PATCH] Inheritance of macports.conf configuration files
Adam, Thanks for the patch. This looks good to me. Does anybody have a use case where inheritance is not the right thing here? James On Sep 30, 2008, at 12:03 PM, Adam Byrtek wrote: There had been no response to my previous post (quoted below), so I decided to try again. Could one of the MacPorts maintainers take a look at the patch, please? This is actually quite a trivial change that will make the user configuration much more convenient. Best regards Adam Byrtek On Fri, Aug 22, 2008 at 10:21 AM, Adam Byrtek [EMAIL PROTECTED] wrote: I've made a tweak in handling of macports.conf configuration file, now the global file defines defaults and user configuration can just override parts of it. More information can be found in this thread on macports-users: http://lists.macosforge.org/pipermail/macports-users/2008-August/011273.html The actual patch is available here: http://trac.macports.org/ticket/16329 A similar problem had been raised on this list a year ago, bus as far as I know didn't result in a patch: http://lists.macosforge.org/pipermail/macports-dev/2007-April/001373.html I'm looking forward for reviewing and applying the patch if you find it valid. Best regards, Adam Byrtek ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [37774] trunk/dports/net/sobby/Portfile
Hi Philip, Just a reminder to you (and others): If there is no other maintainer, then the maintainer should be set to nomaintainer. openmaintainer should be used only in conjunction with a primary maintainer(s), indicating that the primary maintainer is willing for others to make changes as necessary to the port. More information about the special maintainers nomaintainer and openmaintainer is available at http://trac.macports.org/wiki/SpecialMaintainerAddresses . Let me know if you have any questions. James On Jun 22, 2008, at 11:22 AM, [EMAIL PROTECTED] wrote: Revision 37774 Author [EMAIL PROTECTED] Date 2008-06-22 11:22:58 -0700 (Sun, 22 Jun 2008) Log Message bump version to 0.4.4, change maintainer to openmaintainer Modified Paths trunk/dports/net/sobby/Portfile Diff Modified: trunk/dports/net/sobby/Portfile (37773 = 37774) --- trunk/dports/net/sobby/Portfile 2008-06-22 18:21:03 UTC (rev 37773) +++ trunk/dports/net/sobby/Portfile 2008-06-22 18:22:58 UTC (rev 37774) @@ -2,11 +2,11 @@ PortSystem 1.0 name sobby -version0.4.1 +version0.4.4 categories net -maintainers[EMAIL PROTECTED] +maintainers[EMAIL PROTECTED] descriptionDedicated server for collaborative editing -homepage http://darcs.0x539.de/trac/obby/ +homepage http://gobby.0x539.de/ platforms darwin freebsd long_description \ @@ -16,7 +16,7 @@ master_sites http://gentoo.osuosl.org/distfiles/ \ http://releases.0x539.de/sobby/ -checksums md5 126a32a448f8b84e589258522149ffad +checksums md5 805f37a544567e649e1dcbb385683486 depends_build port:pkgconfig depends_libport:glib2 \ ___ macports-changes mailing list [EMAIL PROTECTED] http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Website
Bill, Done. The test host is wwt.macports.org. James On Jun 13, 2008, at 10:24 AM, William Siegrist wrote: James, can you add a domain for this test website? Maybe Randall has a desired hostname, but anything should do. www2? www-test? test? Just point it to the same IP as the real website. Thanks, -Bill On Jun 13, 2008, at 2:07 AM, Randall Wood wrote: Thanks. The branch is /users/rhwood/macports-www off of SVN root On Mon, Jun 9, 2008 at 11:00 AM, William Siegrist [EMAIL PROTECTED] wrote: On Jun 9, 2008, at 5:23 AM, Randall Wood wrote: I have a substantive change I would like to propose to the MacPorts website. This change has some issues that need to be resolved before it can be used though. Does anyone have a public server that they would let me post it onto for discussion? You can branch the www directory and I can set it up on an alternate hostname. We'll need jberry to handle the DNS. Then just let me know what the name of the branch is. -Bill William Siegrist Mac OS Forge http://macosforge.org/ -- Randall Wood [EMAIL PROTECTED] The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy. William Siegrist Mac OS Forge http://macosforge.org/ ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Jaguar support
Our official policy is to support only the two most recent OS versions. I think I interpret that pretty loosely. For those working on MacPorts base: - Don't kill worry too much about keeping stuff alive pre-Tiger, or about not implementing features that might not work pre-Tiger. - But don't remove such old support unless it's causing undo clutter or complexity, or causing you pain. For port maintainers: - It's entirely up to you whether you remove support for pre-tiger ports. - Once again, I'd say if there's pain involved, then remove the support, unless you have meaningful reasons not to. (We do have archives of older MacPorts versions, and port trees, that might be useful to those trying to support older OS versions). James On Jun 13, 2008, at 10:59 AM, Jordan K. Hubbard wrote: On Jun 13, 2008, at 1:17 AM, Ryan Schmidt wrote: Given all this, shouldn't we remove the remaining Jaguar-specific code from those 99 ports and declare that MacPorts not only isn't supported on Jaguar and earlier, but that it in fact will not work? Yes. If even Apple does not officially support Jaguar any longer, I see no reason why MacPorts should kill itself attempting to go back that far. - Jordan ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Ticket #14796 (pike): please commit
On Apr 2, 2008, at 3:44 PM, Peter O'Gorman wrote: Eric Hall wrote: On Tue, Apr 01, 2008 at 02:02:57AM -0700, Jordan K. Hubbard wrote: On Apr 1, 2008, at 1:27 AM, Florian Ebeling wrote: This is sadly somewhat controversial. I think dependencies should definitely be directed at the depot location, e.g. something that links with, say, jpeg version 6.2, shouldn't link to /usr/lib/ libjpeg. 62.dylib but rather /opt/local/var/macports/software/jpeg/6b_2/opt/ local/lib/libjpeg.62.dylib, and so on and so forth for any absolute- path dependencies. Then whether something is active or not has nothing to do with whether it can be depended on. Every time the subject comes up, however, various people rapidly get the creeping crawlies and we lose the courage to actually attempt this. I've always thought this was an excellent idea, it neatly solves conflicting version problems (libnet for example) and allows a new version of $THIS_DEPENDENCY to be installed without breaking $OTHER_SOFTWARE that's linked against $OLDER_VERSION_OF_THIS_DEPENDENCY, and/or resulting in the massive rebuild fsck to bring everything back to happyness when a dependency is upgraded. It does not solve all that much, as all the embedded paths are still /opt/local, the install_name of the libs is still /opt/local, applications will still look for resources in /opt/local, they will not look in the depot. Passing the -L -I PKG_CONFIG_PATH etc flags to link to the stuff in the depot will have absolutely no effect on the resulting binary, making such a change, imo, pointless, older versions of things will still be broken when you update some dependency. I also worry about cases like when A links against B and C. B was linked against D.version1 while C was linked against D.version2. Thus when A loads, it pulls in two (?) potentially incompatible versions of D? James smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
MacPorts GSoC application!!! Extended!!! Students can earn summer money $$$ and prestige!!!
Those of you who are a college student, work on a college campus, know college students, or have a college student as a child, please notice: The Google Summer of Code student application deadline for 2008 has been extended for one week to April 7. This means that students have one additional week to apply for a summer job to help extend MacPorts!!! This is a great opportunity for students to get real, live, on the ground programming experience, work on an exciting open source project with an experienced adult mentor, and (best of all) to be paid $4500 USD by google for the summer of work. MacPorts has many great tasks that could use attention, and still has lots of slots for volunteers; we could use more applicants. Please pass the word to qualified and interested student applicants: the more applicants we get, the more slots we'll positions we'll be granted by google. This is a great opportunity not just for the students, but to foster and extend the MacPorts project. Please see http://trac.macosforge.org/projects/macports/wiki/SummerOfCode for more details. If you have questions, do hesitate to directly contact me, William Siegrist, or any of the other mentors. James smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Ticket #14796 (pike): please commit
On Mar 31, 2008, at 9:47 AM, Daniel J. Luke wrote: On Mar 31, 2008, at 12:41 PM, Jordan K. Hubbard wrote: No offense to jmpp intended, but I think what macports is really lacking is effective technical leadership. There are a lot of good ideas floating around, but nobody really driving the bus. I also used to think that you could elect someone to drive the bus and was a strong proponent of the democratic process which led FreeBSD to elect its core team, but I was wrong. Completely, utterly and totally wrong. :-) In this case, I don't think you were totally wrong ;-) When we originally did our Portmgr elections the plan was for a limited term (but allowing people to run for re-election). Additionally, there was an at least tacit understanding that people who ended up not having enough time to dedicate to the project would step down. I don't think anybody would disagree that many of us don't have enough time to dedicate to the project at present. Of the three elected members of PortMgr, and know that mww has effectively stepped away from the project and would be happy to have a replacement. I know I have been far too busy elsewhere lately to effectively lead the MacPorts effort, and would be happy to step away if there are other people with the time and energy to step in and make progress. I won't speak for jmpp. The last time the three of us discussed this, the best thing for the project seemed to be to encourage a continuity of leadership. It's been several years since that discussion, our respective time commitments have changed, and things have stabilized to a large degree, not to mention that we've transitioned to a new name and home, all of which have helped. It may be time to address this situation. I am encouraged by some of those who have recently brought in a new surge of energy (I'm thinking of afb, raim, and Ryan, in particular, not to mention wms, though I'm sure I'm missing others, to whom I apologize). If anyone is interested in taking a more direct and sanctioned leadership role, please do speak up: your destiny may lie just ahead! James smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Ticket #14796 (pike): please commit
On Mar 31, 2008, at 9:14 AM, Jordan K. Hubbard wrote: There are two few committers for dports/ and REALLY very few committers for base/ - I think we should be more liberal in allowing new committers, being ever mindful of the fact that source control always means you can back things out (and, as we grow, I think it's also important to be flexible about that during/because of any dispute). We have tried over the last year to really loosen up the committer requirements, solicit new committers, etc. We've called a number of times for new submitter applications and basically take anybody who has shown any sort of commitment or experience with MacPorts. So I'll say it once more: if you're interested in being a macports committer, please just ask: http://trac.macosforge.org/projects/macports/wiki/NewCommittersGuide . James smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [35275] trunk/dports
Hi Thomas,
On Mar 23, 2008, at 8:58 PM, Adam Mercer wrote:
On Sun, Mar 23, 2008 at 10:05 PM, Thomas Reifferscheid
[EMAIL PROTECTED] wrote:
Dear James, I dont feel well with your changes. It will make life
even
harder for submitters to the ticket database choosing the right
maintainer.
Why? MacPorts understands this obfuscation, it will expand to the
appropriate address. For example, running 'port info' for these ports
will return the correct email address: 'user' will be expanded to
[EMAIL PROTECTED] and 'example.com:user' will be expanded to
[EMAIL PROTECTED]
I use this on all my ports, along with many other maintainers.
Yes, as Adam says, this is our standard and supported behavior, and is
used for many ports. I'm not sure it's documented anywhere however,
but Adam's explanation is correct; we support two forms of
obfuscation, a specific one for the macports.org case, and a more
general variety for any email address. The rationale is to cut down on
the possibility of spam to committers, though this is only one leak of
email addresses, and there are others that remain unfixed (bug
reports, irc logs, etc).
Implemented by the following code in port.tcl:
proc unobscure_maintainers { list } {
set result {}
foreach m $list {
if {[string first @ $m] 0} {
if {[string first : $m] = 0} {
set m [regsub -- (.*):(.*) $m [EMAIL PROTECTED]]
} else {
set m [EMAIL PROTECTED]
}
}
lappend result $m
}
return $result
}
James
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [35275] trunk/dports
Hi Thomas,
On Mar 23, 2008, at 8:58 PM, Adam Mercer wrote:
On Sun, Mar 23, 2008 at 10:05 PM, Thomas Reifferscheid
[EMAIL PROTECTED] wrote:
Dear James, I dont feel well with your changes. It will make life
even
harder for submitters to the ticket database choosing the right
maintainer.
Why? MacPorts understands this obfuscation, it will expand to the
appropriate address. For example, running 'port info' for these ports
will return the correct email address: 'user' will be expanded to
[EMAIL PROTECTED] and 'example.com:user' will be expanded to
[EMAIL PROTECTED]
I use this on all my ports, along with many other maintainers.
Yes, as Adam says, this is our standard and supported behavior, and is
used for many ports. I'm not sure it's documented anywhere however,
but Adam's explanation is correct; we support two forms of
obfuscation, a specific one for the macports.org case, and a more
general variety for any email address. The rationale is to cut down on
the possibility of spam to committers, though this is only one leak of
email addresses, and there are others that remain unfixed (bug
reports, irc logs, etc).
Implemented by the following code in port.tcl:
proc unobscure_maintainers { list } {
set result {}
foreach m $list {
if {[string first @ $m] 0} {
if {[string first : $m] = 0} {
set m [regsub -- (.*):(.*) $m [EMAIL PROTECTED]]
} else {
set m [EMAIL PROTECTED]
}
}
lappend result $m
}
return $result
}
James
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [macports-mgr] Google SoC 2008
Bill, Glad to hear you'll be able to help out with this. I'd like to ask anybody who would be willing to mentor to please communicate with Bill. Our timeframe is very short to get an application together by noon PDT tomorrow. James On Mar 10, 2008, at 3:15 PM, William Siegrist wrote: I can shepherd the GSoC effort for macports. I've gone through the wiki page and made the initial changes for 2008. http://trac.macosforge.org/projects/macports/wiki/SummerOfCode The next thing we need to do is to verify which of those tasks are obsolete or completed, and which tasks we should add. If you can be mentor for the project, please add your name to the list and any tasks you can help with. I'll be working on the application today and tomorrow, so we need to move quickly. Thanks -Bill On Mar 7, 2008, at 11:14 AM, Jordan K. Hubbard wrote: Gah! If it's me or nobody, I'll do it. :-) We really shouldn't let the opportunity just slip through our fingers. Hey, Jumpy, where are you? :-) - Jordan On Mar 7, 2008, at 8:38 AM, James Berry wrote: I haven't heard back from anybody regarding this plea/opportunity. I don't have time to shepherd GSoC this year. If no body steps up to do so, or to be mentors, I'm going to let this opportunity slide by. Deadline for us to apply to Google, with projects in hand, is next Wednesday, March 12. Anybody? James On Mar 4, 2008, at 8:27 AM, James Berry wrote: Thanks to everybody who pitched ideas for GSoC 2008. Now the rubber needs to meet the road. We need: - Somebody to head up our GSoC 2008 effort (get us signed up with Google, document the proposed projects, etc). - And committed mentors for any projects. Volunteers? As Paul Guyot points out, one thing we found last year was that google seems to allocate project funding to a project based on the total number of student applications. So a project that gets applications from 50 students is likely to be allocated more student slots than a project that gets only 3 student applications. The number of student applications is probably guided in part by several factors: promotion and appeal to the student community; number and appeal of project proposals; etc. James On Feb 29, 2008, at 3:48 PM, James Berry wrote: I'm writing to attempt to gauge interest in whether and how MacPorts should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ . You might be inclined to address any of the following questions: - Do you feel MacPorts should participate in GSoC 2008? - Are there particular MacPorts projects you'd like to suggest? - Are you willing to be a GSoC mentor? - Would you be interested, as a student, in participating in a GSoC project for MacPorts? GSoC pays students a wage for the summer to work on open source projects, and also a stipend to the project for each student project. If interested, we need to move very quickly. As the Google GSoC FAQ says: We'll begin accepting applications from open source mentoring organizations on Monday, March 3, 2008; we'll stop accepting organization applications on Wednesday, March 12th. Your feedback is welcome James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ [EMAIL PROTECTED] 408 862 7337 ___ macports-mgr mailing list [EMAIL PROTECTED] http://lists.macosforge.org/mailman/listinfo.cgi/macports-mgr ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Google SoC 2008
Thanks to everybody who pitched ideas for GSoC 2008. Now the rubber needs to meet the road. We need: - Somebody to head up our GSoC 2008 effort (get us signed up with Google, document the proposed projects, etc). - And committed mentors for any projects. Volunteers? As Paul Guyot points out, one thing we found last year was that google seems to allocate project funding to a project based on the total number of student applications. So a project that gets applications from 50 students is likely to be allocated more student slots than a project that gets only 3 student applications. The number of student applications is probably guided in part by several factors: promotion and appeal to the student community; number and appeal of project proposals; etc. James On Feb 29, 2008, at 3:48 PM, James Berry wrote: I'm writing to attempt to gauge interest in whether and how MacPorts should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ . You might be inclined to address any of the following questions: - Do you feel MacPorts should participate in GSoC 2008? - Are there particular MacPorts projects you'd like to suggest? - Are you willing to be a GSoC mentor? - Would you be interested, as a student, in participating in a GSoC project for MacPorts? GSoC pays students a wage for the summer to work on open source projects, and also a stipend to the project for each student project. If interested, we need to move very quickly. As the Google GSoC FAQ says: We'll begin accepting applications from open source mentoring organizations on Monday, March 3, 2008; we'll stop accepting organization applications on Wednesday, March 12th. Your feedback is welcome James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Google SoC 2008
I'm writing to attempt to gauge interest in whether and how MacPorts should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ . You might be inclined to address any of the following questions: - Do you feel MacPorts should participate in GSoC 2008? - Are there particular MacPorts projects you'd like to suggest? - Are you willing to be a GSoC mentor? - Would you be interested, as a student, in participating in a GSoC project for MacPorts? GSoC pays students a wage for the summer to work on open source projects, and also a stipend to the project for each student project. If interested, we need to move very quickly. As the Google GSoC FAQ says: We'll begin accepting applications from open source mentoring organizations on Monday, March 3, 2008; we'll stop accepting organization applications on Wednesday, March 12th. Your feedback is welcome James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: upgrading a port with no maintainer
On Jan 21, 2008, at 2:25 PM, Kevin Van Vechten wrote: On Jan 21, 2008, at 6:15 AM, Juan Manuel Palacios wrote: Whatever happened to the port submit project initiative anyway? Wasn't that supposed to come about for free with the remote index? :-) Sure, it was! Remote Index would have brought that and many other goodies. Sadly enough, remote index was never implemented, so we don't have them at present :-( Hope somebody steps up in the not too distant future to start doing some of the leg work ;-) It was implemented, just never integrated ;) All the sources are in subversion, though probably suffering from bit-rot at this point. Note that the some of this stuff is manifested in mpwa (look at http://db.macports.org ), which uses a (heavilly) modified version of Kevin's submit code to submit changes to the db. A cron job runs every 20 minutes (and has been for about 10 months now) to autosubmit any ports that have been changed and checked into svn. In a better world, any joe blow could simply run port submit to submit changes to a port. That almost (maybe does?) work right now. So mpwa can serve as the index, but we don't have any integration currently to query that index. Allowing generalized submission to mpwa would require a stronger implementation of user authentication and signing, which isn't too hard. Anyone interested should review the docs http://svn.macports.org/repository/macports/users/jberry/mpwa/doc/. I'd be happy to brainstorm, take criticism, answer questions, etc. The one thing I don't have right now, however, is the time to take this further just now (though I hope to in the indefinite and optimistic future). Others are welcome to pick this up, with appropriate discussion of course. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Subject: [32751] net/dhcp startupitem
Hi Mark,
So it looks like the bit magic that got this to work is the -f
command, which basically tells dhcpd not to daemonize, which would be
a good thing in our case, as the process of daemonizing would look to
daemondo or launchd as if dhcpd were exiting, which would cause the
constantly restarting behavior Blair described.
The startupitem.name spec should be completely redundant and unneeded;
the name will default to the name of the port, which is dhcpd, right?
Does that answer your question?
James
On Jan 13, 2008, at 1:25 PM, [EMAIL PROTECTED] wrote:
Blair,
I see. That's fine then. I just wanted to be sure there was a
reason for
making it a script startupitem and there is. I'm cc'ing James
(master of
all things startupitem) just in case he knows why the executable
startupitem type wasn't adequate in this case. It seems like it
should
have worked. Thanks for fixing the port.
Mark
On Jan 13, 2008, at 12:42 PM, Blair Zajac wrote:
Mark,
It works fine if I use this:
startupitem.create yes
startupitem.namedhcpd
startupitem.executable ${prefix}/sbin/dhcpd -f
startupitem.netchange yes
How's that?
Hi Mark,
I was seeing the following:
1) One dhcpd would start.
2) Every 10 seconds thereafter, another dhcpd would be started, but
it
couldn't bind to the port since the first one was running.
It appears that the startupitem infrastructure wasn't keeping track
of
dhcpd running and deamonizing itself.
I haven't read the guide yet.† What do you suggest?† Putting a -f to
dhcpd so it stays in the foreground?
Regards,
Blair
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
[EMAIL PROTECTED]
Subversion training, consulting and support
[
https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fwww.orcaware.com%2fsvn%2f
]http://www.orcaware.com/svn/
On Jan 13, 2008, at 12:11 PM, [EMAIL PROTECTED] wrote:
Hi Blair,
Executable startupitems are the preferred type.† Daemondo can track
pids
automatically and reliably restart an application if it quits.† See
the
guide on this:
[
https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fguide.macports.org%2f%23reference.startupitems
]http://guide.macports.org/#reference.startupitems
Given how startupitem executables work, I don't see an advantage to
reverting to a script startupitem.† Or is there something I am
missing
particular to dhcp?
___
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
MacPorts servers will be down for a bit in about 5 hours
Our friends at MacOSForge tell us that the servers running macports will be down in about 5 hours for some scheduled maintenance: We need to take the servers down briefly to apply some updates and configuration changes. All services will have 5-10m of downtime starting around 8PM on Monday. The Trac Subversion services will have additional downtime to upgrade the RAM to improve performance. I expect Trac/SVN to be down for 30m total. I'll make announcements in #macosforge as each services goes down and up. Everything should be back to normal around 9pm. If the unexpected occurs, as it sometimes does, please bear with us. If you need a status update you might stop in on the #macports or #macosforge channels on freenode, where more information might or might not be available ;) James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [32441] trunk/base/src/port1.0/portchecksum.tcl
Hi Ryan, On Jan 1, 2008, at 12:56 PM, Ryan Schmidt wrote: On Jan 1, 2008, at 11:09, [EMAIL PROTECTED] wrote: Revision: 32441 http://trac.macosforge.org/projects/macports/changeset/32441 Author: [EMAIL PROTECTED] Date: 2008-01-01 09:09:21 -0800 (Tue, 01 Jan 2008) Log Message: --- If checksum is mismatched, and in verbose mode, present a corrected pre-fabricated checksum statement to make it easy to update a port. That does, of course, make it easier for people to just blindly copy and paste, rather than thinking about whether they should be changing the portfile checksum at all. Yes, I did consider this argument for why it might not be a good idea, but quickly came to the conclusion that taking away the drudge work will hopefully give people _more_ time to consider some of those other factors. I don't believe that this is a case where we're putting a hair-trigger on a gun, or something; we're making the fife of a maintainer easier. I don't think this will make it more or less likely that someone will ignore the root cause behind a bad checksum. Besides, I think 99% of the time spent in updating checksums is for updated versions, rather than files which miraculously change in the night. Once again, hopefully this will make it more likely that maintainers will consider verifying the checksum against a signed version from the distro. James http://trac.macosforge.org/projects/macports/wiki/ FAQ#IgetError:checksummd5sha1rmd160mismatchforport.WhatcanIdoaboutit ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard
Hi Juan, On Dec 2, 2007, at 9:50 AM, Juan Manuel Palacios wrote: So, has any conclusion been reached for this issue? I'm inclined to backing this feature out of the release_1_6 branch until a working consensus is reached, and only release it to the public at that time (in 1.6.x (x 0)). Until now we've only been modifying the user profile for a range of bourne based shells and the cshrc file for equivalent C based shells, which has worked fairly well, I believe; anyone experienced enough to create something like ~/.bash_profile or anything else very shell specific would be savvy enough to setup his/her own environment to their content, I'm sure. I'd strongly favor sticking to this approach in 1.6.0 until something better is found, unless it explicitly breaks expected behavior on Leopard. Does it? Well, given that man pages are broken at present with a standard MacPorts install under Leopard, something has to be done. A few choices: (1) Use this scheme, as implemented. (Downsides: affects /etc, MacPorts paths are added at the end of PATH and MANPATH). (2) Supplement this scheme by munging PATH inside the MacPorts code to ensure that $prefix is always at the head of the path during builds, and to guard against the sort of build problems suggested by kvv. (3) Modify existing path modification code to also add MacPorts paths to MANPATH. (This might break other man pages on Tiger where the system provides no meaningful default for MANPATH—maybe we do it only if MANPATH is already defined?) I've been mulling over this situation for the last week or so, but haven't done anything because I'm not very happy with any of the solutions I think (3), however is the lowest risk approach. James___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard
Hi Ryan, On Dec 2, 2007, at 2:39 PM, Juan Manuel Palacios wrote: On Dec 2, 2007, at 5:49 PM, Ryan Schmidt wrote: On Dec 2, 2007, at 12:35, Juan Manuel Palacios wrote: (2) Supplement this scheme by munging PATH inside the MacPorts code to ensure that $prefix is always at the head of the path during builds, and to guard against the sort of build problems suggested by kvv. MacPorts already sets its internal path for a few things, so this suggestion may be easy to implement but might, just might, have repercussions that we may want to test more thoroughly (not on the verge of a release, in my opinion ;-) Yes, just to chime in a bit on that point: I'm rather unhappy about all these changes that appear to be going into 1.6.0 after we've already had two release candidates. That's not what release candidate means. Release candidate means that it is a candidate for release, and if no major problems are found, it will be released as is. It does not mean that we will add lots of other code and then release it, especially not with another release candidate. I don't want another MacPorts 1.4.0--no wait, 1.4.1--no wait, 1.4.2--no wait, 1.4.3. That's exactly what release candidates are supposed to prevent. Yes, I agree 100% percent. But please do note that all the changes I merged into the release_1_6 branch since rc2, except for 2, have had nothing to do with MacPorts functionality. Mostly just with the PortIndex2MySQL script (after working with Bill to deploy it on Mac OS Forge), which, on the one hand, I've been testing locally extensively for a really long time and, on the other hand, is something most regular users never even see. Of the two commits that do have to do with MacPorts functionality: *) one is a corner-case bugfix against the dp2mp-move upgrade code (paths with spaces embedded in them), which I satisfactorily tested, and *) the other is the path munging work by James Berry, which I'm inclined to remove from the branch. Note please that my addition was a 100% non-code change, to try to fix MANPATH which is 100% broken in Leopard, Ryan, a situation that was not present in Tiger or before. Which isn't to say (as I wrote earlier) that I'm completely happy with the state of things so far, but that we do need to fix this problem before a 1.6 release. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [31640] trunk/base
Hi Ryan, On Dec 2, 2007, at 3:45 PM, Ryan Schmidt wrote: On Nov 30, 2007, at 21:32, [EMAIL PROTECTED] wrote: The ChangeLog was orignally meant to be a user-parsable file listing only major changes to base, so that we could use it in our release process to advertise our new goodies. Unfortunately, lately it has turned into a litle bit of a file tracking commits to base, with a little bit of user level information and a lot of gaps in between to do either one right, bleh! Therefore add a real user-parsable NEWS file in which new features and bug fixes for each release will be advertised, starting with the contents of 1.6.0 Here's hoping that from now on the ChangeLog will turn into a file that truly tracks commits to base, with proper revision numbers for each entry and ticket numbers in case of bug fixes, after being spared from having to remain user-parsable. Can't people who are interested in that kind of information just read the Subversion log? I don't want to have to bother with updating the ChangeLog every time I change something on base. Granted, it's not that often for me. But for others who make many changes on base, this would seem to be annoying. Yes, I basically agree with you. I believe that: (1) The ChangeLog should be developer's best attempt to communicate to the outside world what's happening to base. This is often a somewhat different level of detail from what goes into the subversion commit log. (2) That the ChangeLog should not have too much detail, as otherwise it would simply replicate the svn commit log. Juan says that he may rewrite svn log entries and/or ChangeLog entries into the NEWS file. I'm not sure I would have that much energy in building a release, and would be more apt just to rely on developer's summaries in the ChangeLog file. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard
On Nov 29, 2007, at 6:16 AM, Adam Mercer wrote: On 29/11/2007, James Berry [EMAIL PROTECTED] wrote: The only way to turn it off is to manually remove or modify the files installed by macports. Note that having the paths in your PATHs twice shouldn't hurt anything and probably adds minimal performance slowdown only in the failure case. One enhancement we could potentially make would be to not overwrite versions of these files. That way, if you remove their contents once, subsequent versions of MacPorts would not overwrite you change. The downside of that is that if we wanted to push out changes to these files, it would be less-clear how to update existing users. Comments, anyone? Could an option be added to configure to disable installing these at all, obviously the default should be to install them. Yes, that's certainly a possibility, but I'm not sure it's worth the time and added complexity. Can you explain your objection to the double paths, other than on aesthetic grounds? ;) James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard
Hi Adam,
On Nov 29, 2007, at 5:49 AM, Adam Mercer wrote:
On 25/11/2007, James Berry [EMAIL PROTECTED] wrote:
On Nov 25, 2007, at 1:14 PM, James Berry wrote:
I just checked in some code (r31491:31492) that supplies and
installs spec files for the /etc/paths.d and /etc/manpaths.d
directories if they are present, as they are on Leopard.
The contents of these files are automatically added to the users
PATHS and MANPATHS environment variables, and should mean that we
don't need to configure the user's profile under Leopard. Note that
support for this is though path_helper(8).
Note that paths added through this mechanism are added at the
_end_of_
the PATH and MANPATH variables, and so won't automatically override
any system-supplied commands.
Is there a way to turn this off? i.e. I want to have
/opt/local/{bin,sbin} in my PATH before /usr/{bin,sbin}. At the
moment I add these explicitly myself, but since this change
/opt/local/{bin,sbin} are in my PATH twice.
The only way to turn it off is to manually remove or modify the files
installed by macports. Note that having the paths in your PATHs twice
shouldn't hurt anything and probably adds minimal performance slowdown
only in the failure case.
One enhancement we could potentially make would be to not overwrite
versions of these files. That way, if you remove their contents once,
subsequent versions of MacPorts would not overwrite you change. The
downside of that is that if we wanted to push out changes to these
files, it would be less-clear how to update existing users.
Comments, anyone?
James
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard
Hi Emmanuel, On Nov 29, 2007, at 7:03 AM, Emmanuel Hainry wrote: Citando James Berry : I just checked in some code (r31491:31492) that supplies and installs spec files for the /etc/paths.d and /etc/manpaths.d directories if they are present, as they are on Leopard. I thought macports was supposed not to mess with anything outside /opt/local. (apart from /Application/Macports and /Library/LaunchDaemons and a few others but aiming to reduce them whenever possible). Modifying things in the user's home directory is acceptable though. I general, we don't do stuff outside of /opt/local, though we do also install into /Library/Tcl, if memory serves, and also /Library/ LaunchDaemons, for instance. We try to be as minimal as possible, and I think this fits into that category. And it seems to be, warts and all, the Leopard way to do things. Your question/point , however, is a completely valid one, which we'd love feedback on. There's something very nice and clean about the change I made (we just throw some files into a directory and don't worry about editing the ~/.profile, which has its own share of problems and snafus for less experienced users). I think it's a question for the group in general: which is the best approach? The range of choices we have is basically to pick from the following menu: - Install a file into /etc/manpaths.d/ - Install a file into /etc/paths.d/ - Munge ~/.profile to munge MANPATH - Munge ~/.profile to munge PATH Note that for man to work on Leopard, we have to do either 1 or 3, at least, as Leopard now sets MANPATH, which means that the auto path stuff for man doesn't work. Note that just changing ~/.profile means that anybody who already has ~/.bash_profile, for instance, doesn't get the fix (though this could be improved with better selection based on what profiles are available and what SHELL is. Feedback welcome. Anybody? James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [31500] trunk/base/src/port
Hi Randall, On Nov 26, 2007, at 1:40 AM, Randall Wood wrote: Is there a good reason not to do this in the MacPorts API? I'm happy to have any thoughts on the approach. I tend to think this is in the API layer, since it's implemented as a target. So in other words, it's on parr with clean, lint, trace, activate, etc. But I'm clearly missing the intent behind your words. How do you think it should be implemented, and why? James On 26 Nov 2007, at 00:47, [EMAIL PROTECTED] wrote: Revision 31500 Author [EMAIL PROTECTED] Date 2007-11-25 21:47:26 -0800 (Sun, 25 Nov 2007) Log Message Initial support for port load and port unload actions. These actions call invoke launchctl to load or unload the startupitem.plist for the specified port(s). Modified Paths trunk/base/src/port/port.tcl trunk/base/src/port1.0/Makefile trunk/base/src/port1.0/port.tcl trunk/base/src/port1.0/portdestroot.tcl trunk/base/src/port1.0/portstartupitem.tcl Added Paths trunk/base/src/port1.0/portload.tcl trunk/base/src/port1.0/portunload.tcl ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Change in mail routine for @macports.org addresses
Hi Simon, On Nov 26, 2007, at 9:52 AM, Simon Ruderich wrote: On Mon, Nov 26, 2007 at 08:51:22AM -0800, James Berry wrote: As part of ongoing spam-fighting efforts, mail to our @macports.org addresses is now being routed through the main apple email servers in order to better filter out spam. Please let us know if you see any adverse effects from this change. James I'm not sure, but I just received a mail from [EMAIL PROTECTED] with the following content. Not sure if this has anything to do with it: The special maintainers identified by [EMAIL PROTECTED] and [EMAIL PROTECTED] are described on the MacPorts wiki at http://trac.macports.org/projects/macports/wiki/SpecialMaintainerAddresses . Please read that page for more information about those maintainers. You should receive mail from that address only if you sent mail to [EMAIL PROTECTED] or [EMAIL PROTECTED] Is that what you did? Or did you send mail elsewhere? James Thanks, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 1.6.0 rc2 created (Was Re: [31193] branches/release_1_6/base/src)
Hi Juan, On Nov 18, 2007, at 10:35 AM, Juan Manuel Palacios wrote: On Nov 18, 2007, at 5:23 AM, Ryan Schmidt wrote: On Nov 18, 2007, at 00:20, Juan Manuel Palacios wrote: And while we're at it, I just created an rc2 tag for 1.6.0, differing from rc1 only in James' turning readline support into an optional configuration (r31139-31139 and merged into the release_1_6 branch in r31190) and in the Tcl cd command hiding reversion thing (r31193 only in the release_1_6 branch). Every developer/committer should reinstall MacPorts off this tag and test as extensively as possible! Apparently the lack of readline is making interactive mode very strange. Note how the prompt doesn't appear until after the thing I typed. We were missing a flush after the prompt was output, before the get operation. I added that single line in r31338:31339. Hope that can get into 1.6. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Hypothetical port load, port unload commands (and turn script)
Hi Ryan, On Nov 20, 2007, at 9:01 AM, Ryan Schmidt wrote: I've written many replies on this list explaining to people how to use launchctl to start and stop various services installed by MacPorts. Every time I do, I have to refer back to my notes to remember the exact launchctl command and the exact path to the plist. Admit it: sudo launchctl load -w /Library/LaunchDaemons/org.macports.foo.plist is not easy to remember, and it's a lot to type. On my system, I wrote a script turn to simplify things for me. I can say things like: turn foo on or turn off bar and it knows where to look for the plist and how to execute the appropriate launchctl command. It's short and easy to remember. It also prints helpful messages if you try to turn something on when it's already on, or off when it's already off. It would be nice to have easier-to-remember commands included with MacPorts, but a script called turn hardly seems to fit in with the rest of the project. But what about: sudo port load foo and sudo port unload bar ? That's pretty easy to remember in my opinion. What do you think? I like this. We could look for a startupitem in the port, get the name, and put the proper command together for launchctl. Very nice. Do we have any other conceivable uses for the words load and unload that this might conflict with? James This proposed syntax limits us to one launchctl plist per port. However, we already have that limit, so I don't consider it a big problem at this time. P.S: I'm including my turn script for others to examine and try out and even use, if they like. But I'm not suggesting that this script be incorporated as-is into MacPorts. I would fully intend for the hypothetical port load and port unload commands to be properly implemented in Tcl. turn___ 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: Your MacPorts ports need some love: the cd command is going away
Hi Ernie, On Nov 12, 2007, at 2:52 PM, Ernest Prabhakar wrote: Hi Ryan, Apology for a stupid question, but I can't get your script to run: On Nov 12, 2007, at 1:37 AM, Ryan Schmidt wrote: To see everywhere in your ports where the cd command is currently being used, you can use a command like this in the Terminal (replacing EMAIL with your maintainer email address (to which this email was sent)): port file maintainer:EMAIL \ | xargs grep [[:space:]]cd[[:space:]] \ | grep -v system[[:space:]] Am I doing something wrong? This is on Leopard with a fresh install of 1.5.0 -enp ernest$ port file maintainer:[EMAIL PROTECTED] Can't map the URL 'file://.' to a port description file (Could not find Portfile in /Users/ernest). Please verify that the directory and portfile syntax are correct. To use the current port, you must be in a port's directory. (you might also see this message if a pseudo-port such as outdated or installed expands to no ports). Error: Port not found It looks to me like there are no ports for which you are listed as maintainer. (Am I wrong?) Therefore, you get this result, which isn't, admittedly, the most beautiful thing in the world. James ___ 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: passing params to startupitem.executable / portfile.7
Hi Mark, On Oct 27, 2007, at 6:27 PM, [EMAIL PROTECTED] wrote: James, I've got the startupitems documented as best I can. http://geeklair.net/new_macports_guide/#reference.portfile But I have one remaining question. How could I pass parameters such as -d 10 -t 600 to a startupitem.executable? I'm not sure how to do that. I'm pretty sure that if you specify this like: startupitem.executable mybinary -d 10 -t 600 that it will work correctly. In other words, don't do the following: startupitem.executable mybinary -d 10 -t 600 Also, I think the portfile.7 man page needs to be split up because it is getting so big. I propose splitting portfile.7 into four parts. What do you think? I guess I'm open to this. I'd love to hear comment from others, however, And would there still be a portfile.7 manpage that gave general overview and gets people started? James portfile-global (global vars keywords) portfile-phases (keywords related to phases) portfile-startupitems portfile-tcl (Tcl extensions) Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: startupitem.pidfile options
Hi Mark (and others interested)
Let me try to explain the pipfile options. I'm expressing these in
terms of daemondo, but understand that something similar should
happen if a SystemStarter script is generated instead.
none:
daemondo will not try to read, create, or write a pidfile for the
daemon process.
It's basically flying blind, and won't be able to detect if the
process dies.
exec:
daemondo will remember the pid generated from execution of
the .executable
or .start command, and will use this to track operation of the
daemon.
If a pidfile is also specified, then daemondo will also write a
pidfile to contain
the pid (note that this is only for your sake, as daemondo doesn't
need this for
its own operation).
auto:
The started process is expected to create and destroy (when
appropriate) a pid file
that specifies the pid of the daemon process.
After starting the process, daemondo will try to read this pidfile
in order to scavenge the
pid of the daemon process to track.
clean:
The started process is expected to create a pid file that specifies
the pid of the daemon
process, but is not reliable in always deleting it when the process
dies.
After starting the process, daemondo will try to read this pidfile
in order to scavenge the
pid of the daemon process to track, and will try to delete the
pidfile when it detects
that the process has died.
Note that the startupitem.pidfile options above are mapped to
slightly differently factored native daemondo parameters.
As a separate note, it looks to me like the nedi port that you
recently modified would be shorter, less verbose, and less prone to
failure if you specified the startup options in this way:
startupitem.create yes
startupitem.name nedimonitor
startupitem.executable ${nedimonitorbin}
In other words, since it appears that it is $nedimonitorbin that is
the true deamon (your script is just storing its pid in a pidfile),
you really just need to tell daemondo to execute that command, and it
will remember the pid all by itself. You don't need to generate a
pidfile at all, and everybody is better off if daemondo just does all
the work and you don't have shell scripts to run. If you want a
pidfile for your own enjoyment, then specify a pidfile with exec, and
daemondo will store the pid there for you to examine.
The case mentioned above is the best case, and one we'd like to work
for in all cases, but often there is no convenient executable for
daemondo to execute (being hidden behind multiple layers of scripts
etc), and the best we can do is tell it how to find the pid of the
actual deamon by reading a pidfile. Note that there are additional
failure modes inherent in such an operation (what if the daemon
crashes between the time that daemondo starts the script and the time
it gets a chance to read the pidfile)? (Daemondo looks for the
pidfile immediately after executing the start code, then begins to
poll for it at 1 second intervals thereafter, until it gives up doing
this).
I hope that helps. Thanks for all your efforts in documenting and
testing the startupitem / daemondo behavior. I haven't answered your
questions below, but I hope I've given enough information that you
could now answer them for yourself. Let me know if you have questions.
James
On Oct 25, 2007, at 12:06 PM, [EMAIL PROTECTED] wrote:
James,
I don't fully understand the startupitem.pidfile options. I think
I've
got the documentation improved for startupitems, but like to
improve it
some more.
Here are the current new docs on the options:
---
Pidfile handling options:
none - The daemon is not to use a pidfile.
auto - The daemon generates its own pidfile.
manual - The daemon never generates a pidfile; the StartupItem must
manage
the pidfile on its own.
clean - The daemon generates its own but will not delete it; the
StartupItem must delete it.
-
Question 1)
I have a startupitem that creates the pidfile like this:
'startupitem.start ${nedimonitorbin} echo \$!
${nedimonitorpid}'
I thought manual would be the best option. But manual deleted my
pidfile when launchctl executed. Why would that be? Also, it sets
string--pid=exec/string in the .plist. Is this correct?
I had to use the clean option, and it works fine, but I don't
understand
why manual worked as it did, or why clean works since it says the
startupitem must delete it and mine doesn't. Should the docs say
daemondo must delete it, instead of StartupItem must delete it?
Question 2)
none - This means that pidfile startupitem.pidfile disabled, correct?
Same as not using the startupitem.pidfile keyword at all.
auto - This option deletes the pidfile as well, correct?
clean - The daemon
Re: daemondo is not restarting processes that die
Mark, and others: In r30313 I've modified daemondo to use kqueue/kevent to watch for the death of the targeted process. This should catch the situation where we're watching for a grandchild process, for which we don't receive child death notices. Let me know if this helps. James Checkin notes: Improve Daemondo to use kqueue/kevent to watch for the death of the target process. Previously Daemondo relied on child death signals, which are given only for direct offspring, and not grandchildren, etc. The use of the kevents now gives notice when the targetted process is not direct offspring. Note: these changes may introduce compatibility issues for Panther, or even Tiger, since I have not yet tested in those environments. They may also introduce compilation problems on platforms for which there is no kqueue support at all. Bug reports are welcome. On Oct 22, 2007, at 7:36 PM, [EMAIL PROTECTED] wrote: James Berry [EMAIL PROTECTED] writes: I'll have to look at the Daemondo code again. I'm not sure whether it will get a child death notice for a script that it didn't start directly, and this may be the problem in the case that you describe. Looking... Thanks James, I appreciate it. If it can't do that the docs will need updated because I thought it would. But I guess I was supposing that daemondo monitored the process by looking at the pidfile; if it has to passively receive a death notice I can see how that might not work. Would actively monitoring daemons (for non-executable startupitems) be too expensive? It seems like it has most of the logic to do it based on the way it started multiple processes when the pidfile wasn't located correctly. It seems like having it check once in awhile after it is running wouldn't be to much of a stretch. But then you know what they say, the less you know about something, the easier it seems. :) Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: daemondo is not restarting processes that die
On Oct 24, 2007, at 12:30 PM, [EMAIL PROTECTED] wrote: James Berry [EMAIL PROTECTED] writes: Mark, and others: In r30313 I've modified daemondo to use kqueue/kevent to watch for the death of the targeted process. This should catch the situation where we're watching for a grandchild process, for which we don't receive child death notices. Let me know if this helps. James James, It works! I tested it on 10.4. When I kill the process it starts again immediately. Thanks! It helps me out a lot, and it will others I'm sure as well. Great to hear. If it weren't hard, perhaps it would be valuable to have the notification of process death reported in the startupitem.logfile when present. Or at least if you agree with that. Right now the only indication a process died is by noting the starting process message in startupitem.logfile. Not a big deal though. By default, logs are requested at level 1 if you ask for the startupitem.logfile. So I've added some additional logging at level 1 that should make clear when the process dies, as well as a couple of other cases (receipt of SIGHUP and SIGTERM). Let me know if that helps: r30335. James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Spam control
On Oct 23, 2007, at 7:08 AM, Juan Manuel Palacios wrote: On Oct 22, 2007, at 11:07 PM, James Berry wrote: On Oct 22, 2007, at 8:09 PM, Juan Manuel Palacios wrote: Evening everyone! As you may have seen from my somewhat obnoxious commits recently, I abstracted *all* appearances of the openmaintainer and nomaintainer addresses in our Portfiles -- the amount of spam our lists have been blocking lately is just bewildering! Hi Juan, But openmaintainer and nomaintainer are answer by an autoresponder, right? So we never see mail destined for those addresses? Geee... you got me thinking there, could have sworn they were forwarding! I'll ask BIll about it. I checked last night be sending mail to the addresses. The autoresponder is working fine. These addresses don't contribute to our spam load. James But in any case, the anti-spam measures are still a big plus, so ;-) Regards,... -jmpp ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: daemondo is not restarting processes that die
Hi Mark, I'll have to look at the Daemondo code again. I'm not sure whether it will get a child death notice for a script that it didn't start directly, and this may be the problem in the case that you describe. Looking... James On Oct 19, 2007, at 2:52 PM, [EMAIL PROTECTED] wrote: Daemondo is not restarting a process for me that dies. I am sure it is tracking the script's pid correctly (using startupitem.pidfile) and I have setup logging to verify all this. At first I did not have the startupitem pidfile configured properly and daemondo kept starting more instances of the daemon, which was a good sign to me that it was looking for the pidfile, using it, and might in fact restart a process that died. But after fixing the startupitem.pidfile properly, if I kill the script (to simulate the script dying abnormally) daemondo never restarts it. Or is kiling it using the Unix kill command a valid test? Is there a bug in daemondo? It isn't behaving as the main.c comments (or our documentation) say it should. I have never explicitly tested it before, and I'm not sure anyone else has either so it seems like a bug. Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Spam control
On Oct 22, 2007, at 8:09 PM, Juan Manuel Palacios wrote: Evening everyone! As you may have seen from my somewhat obnoxious commits recently, I abstracted *all* appearances of the openmaintainer and nomaintainer addresses in our Portfiles -- the amount of spam our lists have been blocking lately is just bewildering! Hi Juan, But openmaintainer and nomaintainer are answer by an autoresponder, right? So we never see mail destined for those addresses? James So I'd like to ask everyone to please not use the full e-mail address format when switching your ports to either of those, any way in which we can reduce this spam plague is appreciated! (mails sent there forward to this list) If you choose to keep your ports with the full format, then that's your own predicament... sorry, prerogative... eeer, however you wanna put it ;-) Thanks for your help and understanding! Regards,... -jmpp ___ 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
