Re: [141132] trunk/dports/lang/apple-gcc42/Portfile

[Landon Fuller]

On Oct 12, 2015, at 14:14, Jeremy Huddleston Sequoia  
wrote:

> Yes, and I was quite happy that the compilers failed to work in Yosemite, 
> allowing me to mark them as unavailable.  Unfortunately, some life was 
> breathed into them again, preventing them from slipping off to their well 
> deserved graev.

If someone wants to do the maintenance work, I don’t see why we ought to 
artificially constrain their ability to do so. If nobody does the work, then 
the packages clearly aren’t a priority, and can be retired.

> libstdc++ does not exist on new platforms (eg: tvOS and watchOS).  Projects 
> should not be using libstdc++ any more and should have migrated by now 
> (unless, of course, they need to support Snow Leopard users still).

Apple has also dropped a number of POSIX-defined APIs on tvOS and watchOS, as 
well as a number of Darwin/Mach APIs; Apple’s modern platform priorities aren’t 
really a measure of what is ideal for — or required by — software users or 
developers on OS X.

>  I wouldn't be surprised if the headers disappeared from a future SDK or had 
> markup preventing them from being used with a deployment target of 10.7 or 
> higher.


If anything, I think MacPorts ought to be shielding users from Apple’s use of 
tooling updates to bitrot working software that happens to not be aligned with 
their release-to-release platform priorities.

-landonf




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: unsigned kexts on Yosemite

[Landon Fuller]

On Jun 6, 2015, at 2:53, René J.V. Bertin  wrote:

> On Friday June 05 2015 17:45:22 Landon Fuller wrote:
> 
>> but if that does work in Yosemite, it seems very likely to break in 
>> Yosemite+1 of OS X when they start applying additional iOS-style 
>> restrictions based on code signing entitlements + MAC.
> 
> Which would probably render kextd patching useless too?

Yep! Now we’re back to square one, with users having to disable kext signing 
*AND* ‘rootless’.

> The code that enforces all these things wouldn't be available via 
> opensource.apple.com, would it?

Some of the underlying implementation is — such as the TrustedBSD-derived MAC 
framework. The stuff built on top of that is hit-and-miss; for example (and 
IIRC), the Sandbox.kext that sits on top of MAC is closed source.

Obviously the sources for anything newly added for 10.11 will probably not 
appear for a while.

> 
>> 
>> Personally, I’m just staying with Mavericks.
> 
> If it had been feasible I'd have stayed with 10.6 but sadly Apple know how to 
> make you update, and now that OS updates are free 3rd party providers are 
> adopting the attitude that there's nothing keeping you from doing so (this 
> was just discussed on a Qt ML).
> [OT]
> For me personally that means I may be leaving the Apple ecosystem sooner than 
> I'd have thought, also because I wouldn't even know what to buy to replace my 
> current MBP if I had to. Not that the situation appears to be any different 
> with other manufacturers: apparently it's gone out of vogue to want a compact 
> laptop with solid build quality, a powerful CPU (i7 style), upgradable RAM 
> and 2.5" form-factor HDD/SDD, a good selection of ports including wired 
> ethernet and at least the possibility not to add a $$$ fancy display because 
> one already has a fine external display. All for the price of an MBP 13" ... 
> minus the Apple Tax if possible.
> For a while I thought I'd found a suitable OS X replacement in Linux + KDE4, 
> but "KDE5" is becoming unavoidable while still far from production-ready IMO, 
> and the same Ivvy Johnny style short-sighed design decisions have been made 
> there that will almost unavoidably lead to yet another overhaul when they go 
> out of fashion in 9 months or so.
> All this really makes me feel ripe for retirement while being far from ready 
> for it :-/
> (IT is great - pass the prozac and I'll have a dab of Botax too :))
> [/OT]

Yep.

-landonf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: unsigned kexts on Yosemite

[Landon Fuller]

On Jun 3, 2015, at 4:46, René J.V. Bertin  wrote:

> On Wednesday June 03 2015 16:47:39 Joshua Root wrote:
> 
>> Finally got around to trying an unsigned kext, and the answer is no,
>> neither kextload nor kextutil will load unsigned kexts at all (without
>> kext-dev-mode=1 in the kernel boot args).
> 
> Regardless of where you're loading them from? IIRC there was a distinction 
> between kexts installed under /System and kexts installed in "user land", 
> probably in places where they're not picked up by the default kext search 
> algorithm.

Mavericks allows unsigned kexts in /Library, but Yosemite requires that all 
kexts be signed by Apple, or by a ‘blessed’ Apple-signed Developer ID 
certificate, regardless of location:

http://xref.plausible.coop/source/xref/macosx-10.10.1/kext_tools-384.1.4/security.c#1238

It’s easy to runtime patch kextd to accept kexts signed with additional 
anchors, but that’s probably not shippable as a general solution.

It may also be possible to bypass kextd by just calling OSKextLoadWithOptions() 
directly, but if that does work in Yosemite, it seems very likely to break in 
Yosemite+1 of OS X when they start applying additional iOS-style restrictions 
based on code signing entitlements + MAC.

Personally, I’m just staying with Mavericks.

-landonf___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Move part of macports infrastructure to GitHub

[Landon Fuller]

On Mar 21, 2014, at 4:17 PM, Landon Fuller  wrote:

> 
> On Mar 20, 2014, at 8:39 PM, Ryan Schmidt  wrote:
> 
>> 
>> On Mar 20, 2014, at 19:21, Eric Gallager wrote:
>> 
>>>>> That said, a git/hg mirror on GitHub/ButBucket would definitely be nice.
>>>> 
>>>> Why would that be nicer than the read-only git mirror that Mac OS Forge 
>>>> already provides here:
>>>> 
>>>> http://www.macosforge.org/post/git-mirrors/
>>>> 
>>> Try to avoid thinking of it as "nicer than", but instead think of it as "a 
>>> nice addition to". The nice thing about distributed systems like git is 
>>> that it makes it easier to mirror a single mirror to multiple places. A git 
>>> mirror on GitHub could even be the exact same mirror as the one on 
>>> MacOSForge is. That is similar to how most of the mirrors on the 
>>> GitHub-Mirrors account work: https://github.com/mirrors (I think I 
>>> mentioned that earlier in this thread…)
>> 
>> Why is a github mirror of the git repository desirable? Why can’t users who 
>> want a git version of our repository use the one Mac OS Forge provides? Is 
>> it just to help users discover the existence of the repository or what?
> 
> In my experience, the alternative is that people republish your code on 
> GitHub anyway, in which case you have a bunch of disconnected mirrors of your 
> code under the same name as your project, none of which is obviously 
> canonical.
> 
> If your code is going to wind up republished to GitHub anyway, having a 
> mirror at least allows you to control the branding, point back to the 
> original project, and ensure that it's clear which repositories are 
> user-uploaded mirrors ("forks"), and which is the canonical mirror.

As a follow-up — it looks like Apache is doing some really neat stuff in terms 
of integrating with GitHub, while maintaining local canonical control of 
project hosting and resources:

https://blogs.apache.org/infra/entry/improved_integration_between_apache_and
https://svn.apache.org/repos/infra/infrastructure/trunk/projects/

-landonf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Move part of macports infrastructure to GitHub

[Landon Fuller]

On Mar 20, 2014, at 8:39 PM, Ryan Schmidt  wrote:

> 
> On Mar 20, 2014, at 19:21, Eric Gallager wrote:
> 
 That said, a git/hg mirror on GitHub/ButBucket would definitely be nice.
>>> 
>>> Why would that be nicer than the read-only git mirror that Mac OS Forge 
>>> already provides here:
>>> 
>>> http://www.macosforge.org/post/git-mirrors/
>>> 
>> Try to avoid thinking of it as "nicer than", but instead think of it as "a 
>> nice addition to". The nice thing about distributed systems like git is that 
>> it makes it easier to mirror a single mirror to multiple places. A git 
>> mirror on GitHub could even be the exact same mirror as the one on 
>> MacOSForge is. That is similar to how most of the mirrors on the 
>> GitHub-Mirrors account work: https://github.com/mirrors (I think I mentioned 
>> that earlier in this thread…)
> 
> Why is a github mirror of the git repository desirable? Why can’t users who 
> want a git version of our repository use the one Mac OS Forge provides? Is it 
> just to help users discover the existence of the repository or what?

In my experience, the alternative is that people republish your code on GitHub 
anyway, in which case you have a bunch of disconnected mirrors of your code 
under the same name as your project, none of which is obviously canonical.

If your code is going to wind up republished to GitHub anyway, having a mirror 
at least allows you to control the branding, point back to the original 
project, and ensure that it's clear which repositories are user-uploaded 
mirrors ("forks"), and which is the canonical mirror.

-landonf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Move part of macports infrastructure to GitHub

[Landon Fuller]

On Mar 16, 2014, at 11:40 PM, Joshua Root  wrote:

> However I would also agree with what Landon said here:
> 

I’m glad I read the full thread, as otherwise I might have reiterated this 
point without realizing I’d already made it :-)

That said —

The better I understand git, the less I like it, but the fact is that the 
industry has shifted and git is the leader for now. I’d certainly support a 
move to git, especially if we had the time and server-side control necessary to 
disable dangerous, data-destroying features such as permanent deletion of 
branches+tags and forced pushes, and thus could be assured that repository 
history would remain correct and internally consistent until the next SCM 
emerges.

However, I still think it’s a backwards step to abandon self-hosted control of 
critical project infrastructure, and I don’t think there’s a compelling 
technical or administrative argument for Github that outweighs this. I’ve not 
seen *better* or more *correct* contributions by using Github on projects; 
rather, it seems to lower the bar (and even that is arguable) on the least 
important part of the process — submitting the patch.

I also have some ethical qualms about contributing to the furtherance of what 
amounts to Github’s social network lock-in through network effects. They’re a 
commercial organization, and I don’t think an open source monoculture defined 
and driven by GitHub's business goals and ideals of how people should manage 
projects is to open source's benefit.

Lastly, I question the wisdom of tying a project that has already lived for 12 
years to a commercial “SaaS” offering. Recently, I had to move some small 
projects off of Google Code — because Google had deprecated and removed their 
data APIs, I had to actually use a screen scraper to (lossily) export my Google 
Code issues.

If you’d told me 8 years ago that Google would pull the data APIs and make it 
difficult to leave, I wouldn’t have believed it.

-landonf___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [114733] users/landonf/openjdk7/dports/java/openjdk6/Portfile

[Landon Fuller]

On Dec 28, 2013, at 0:36 , Ryan Schmidt  wrote:

> If you have reason to believe that *only* llvm-gcc — not clang, not gcc — 
> will work, then ok, whitelist only llvm-gcc. That would be unusual, but maybe 
> openjdk is unusual in its compiler needs; I don’t know.

With a mixture of a full runtime JIT compiler coupled with an assembly 
template-based interpreter (and on 32-bit systems reliance on ugly features 
like -mstackrealign), there's a lot of room for things to go very subtly wrong 
in ways that may not be immediately obvious to anyone. Targeting a consistent 
toolchain eliminates uncertainty and ensures that any failures -- whether 
they're due to bugs in OpenJDK, such as invalid ABI constructs in the 
JIT-generated and hand-written assembly templates, or simply due to compiler 
bugs -- will be *consistent* across builds.

Since Oracle is also currently using LLVM-GCC, targeting a single revision also 
leverages any work they've done in testing, especially around toolchain 
interaction issues.

>>> MacPorts will pick the next-best compiler, which will be llvm-gcc42, either 
>>> the version provided by Xcode or the one provided by MacPorts, depending on 
>>> what’s available. You can then use the variables ${configure.cc}, 
>>> ${configure.cxx}, etc. where you need them.
>> 
>> Will this actually work with llvm-gcc?
> 
> Yes, it will work with all compiler names that MacPorts recognizes. See 
> portconfigure.tcl.

It appears to work by luck; as per Lawrence Velázquez's e-mail, "llvm-gcc-4.2" 
works only because Apple doesn't vend a version-suffixed clang binary with the 
'llvm-gcc-4.2' name. If we used 'llvm-gcc' instead of 'llvm-gcc-4.2', for 
example, the implementation would, according to my reading, find Xcode's 
not-actually-llvm-gcc binary in /usr/bin.

Indeed, if 'gcc' is specified (compiler.whitelist gcc), portconfigure.tcl 
*does* return the faux system GCC:
DEBUG: Assembled command: 'cd 
"/opt/local/var/macports/build/.../openjdk7/work/openjdk" && /usr/bin/make  
CC="/usr/bin/gcc" CXX="/usr/bin/g++" ...

> I am not Apple, but clang *is* more or less compatible with most of what gcc 
> does. And since Apple decided to no longer ship gcc or llvm-gcc but only 
> clang, the two choices were: make “gcc" a symlink to clang, or provide no 
> "gcc" at all. They chose the former, and I think it was an ok choice; had 
> they chosen the latter, I can imagine a *lot* of software not being able to 
> build out of the box, since a lot of software assumes the compiler is “gcc”.

I say this as someone happy to see GCC 4.2 gone -- the problem is that "more or 
less compatible" is not good enough for anyone that cares about the compiler 
selection (such as portconfigure.tcl), and now nobody can rely on a simple test 
for 'gcc' or 'llvm-gcc' actually returning what you'd expect. Apple could have 
continued to ship GCC and LLVM-GCC, stopped shipping anything named 'gcc' and 
'llvm-gcc' outright, or even printed 'deprecation' warnings whenever invoking 
the gcc compiler-compiler front-end.

-landonf


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [114733] users/landonf/openjdk7/dports/java/openjdk6/Portfile

[Landon Fuller]

On Dec 22, 2013, at 3:11 , Ryan Schmidt  wrote:

Hey Ryan --

Thanks for looking into this.

> This will unnecessarily make users of Xcode < 5 install the llvm-gcc42 port, 
> when they have a perfectly good version of llvm-gcc42 provided by Xcode. 
> Rather than this, you should use compiler.blacklist. For example, if no clang 
> compiler will work, blacklist all of them with:
> 
> compiler.blacklist *clang*

I think I'd need 'compiler.whitelist macports-llvm-gcc-4.2 llvm-gcc-4.2' to 
make sure I always get a consistent compiler? There's an extensive test suite I 
ran with a JVM built against llvm-gcc4.2, and I hesitate to throw any variables 
into the mix.

> MacPorts will pick the next-best compiler, which will be llvm-gcc42, either 
> the version provided by Xcode or the one provided by MacPorts, depending on 
> what’s available. You can then use the variables ${configure.cc}, 
> ${configure.cxx}, etc. where you need them.

Will this actually work with llvm-gcc? Apple is still shipping 'gcc' and 
'llvm-gcc' binaries/symlinks, but they're pointed at clang; won't 
find_developer_tool still pick them up?

landonf@lambda:~> llvm-gcc -v
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)

landonf@lambda:~> llvm-gcc --help   
OVERVIEW: clang LLVM compiler
[snip]

landonf@lambda:~> gcc -v
Configured with: 
--prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)

landonf@lambda:~> gcc --help
OVERVIEW: clang LLVM compiler
[snip]

Shipping an incompatible compiler as 'gcc' and 'llvm-gcc' was an absolutely 
ridiculous decision on the part of Apple's developer tools team, but they 
didn't ask me.

-landonf


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Certificate Authorities: curl-ca-bundle, certsync, keychain

[Landon Fuller]

Howdy all --

I think certsync is now ready to be relied on by default. Here's a brief status 
update:

- On-demand Launching:

I've updated certsync to launch via launchd on-demand when relevant files 
change, rather than staying memory-resident. This eliminates any sort of 
potential runtime cost; certsync was never large, but it doesn't hurt to not 
have to run a daemon at all.

- Tiger Support

Tiger is now supported, although actually *running* Tiger turned out to be 
harder than I expected. I don't have any hardware capable of running Tiger, so 
I thought i could just bring it up in a VM. As it turns out, Tiger panics on 
boot under a VM on more modern machines (eg, my nearly 3 year old iMac).

I wound up having to track down the 10.4 kernel bug in question and produced a 
binary patch I could apply to xnu. If someone else needs to run a Tiger VM for 
some instance, I've posted the background and the patch here:

http://landonf.bikemonkey.org/code/macosx/Virtualizing_Tiger_On_Modern_CPUs.20131217.html

In light of this, and the enormous number of API differences between Tiger and 
Leopard, I'm not really sure maintaining Tiger support makes sense for 
MacPorts, but I was able to make certsync work regardless.

- Next Steps

If things look good to everyone, I'd like to move all ports over to using 
certsync as a certificate store, replacing curl-ca-bundle.

In addition, I've started extending certsync to vend a keychain-backed PKCS#11 
plugin that can be consumed by p11-kit, Java's PKCS#11 implementation, NSS, 
etc. This will provide even better integration for modern PKCS#11-aware 
software. In theory, we should be able to migrate to a fully consistent 
certificate store across all applications.

-landonf


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Certificate Authorities: curl-ca-bundle, certsync, keychain

[Landon Fuller]

On Nov 28, 2013, at 10:32 , Rainer Müller  wrote:

> The only catch is that custom added certificates or trust anchors need
> to be in the system keychain to be picked up by certsync by default.

Yeah, this was an unfortunate trade-off; since certsync is a system-wide 
daemon, and the resulting CA certs file is also system-wide, it seemed to be 
the most appropriate course of action. Most of the alternatives involve 
patching OpenSSL and some of the software that depends on it, which is a road 
I'm personally wary of committing to.

-landonf



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Certificate Authorities: curl-ca-bundle, certsync, keychain

[Landon Fuller]

[sorry for the delay, picking this up again post-holidays]

On Nov 29, 2013, at 3:38 , Ryan Schmidt  wrote:

> I’ve switched many of my MacPorts installs to certsync, including on Leopard, 
> but I don’t know if it’s working correctly (how would I test that?).

As long as you're getting a populated cert file, you're set.

> Unfortunately certsync fails to build on Tiger; I would love to get that 
> fixed.

What are the errors you're hitting? I don't have a Tiger install to work with 
locally, but in theory I could try to bring it up in VMware.

> The problem with leaving curl-ca-bundle intact and leaving ports using the 
> path:-style dependency is that all existing users of MacPorts would continue 
> to use curl-ca-bundle unless they manually intervened. If certsync is working 
> properly, it would be nice to automatically switch all users to it (i.e. make 
> curl-ca-bundle replaced_by certsync). That’s going to get tricky if we have 
> to make exceptions for older OS versions.

I'd be fine with that; let's sort out the OS compatibility and get it working 
across the board.

-landonf


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Certificate Authorities: curl-ca-bundle, certsync, keychain

[Landon Fuller]

Howdy All --

certsync is tested and works on 10.6+, and is building successfully on all the 
buildbots, and a MacPorts update has now shipped with support for auto-loading 
certsync's startup item. I've been running certsync since May without any 
noticed ill-effects.

I would like to propose that we move to using certsync by default, as a 
replacement for curl-ca-bundle. To briefly rehash the benefits of certsync:
- Uses the CAs Apple provides -- that way MacPorts doesn't have to be 
in the business of distributing CA certificates.
- Also includes any custom CAs that the user has added. This is the 
case for many people who use internal CAs to sign certificates for their 
corporate (or personal) services.
- Automatically updates when the System Keychain(s) or trust settings 
are modified. 

Thoughts?

-landonf

On May 13, 2013, at 21:39 , Landon Fuller  wrote:

> Howdy,
> 
> Over the weekend I whipped up (and added a port for) 'certsync'; it's a small 
> tool that fetches all trusted certificates from the Mac OS X system keychain, 
> and then spits them out as OpenSSL-readable pem-encode certificate bundle.
> 
> The goal was to provide a replacement for curl-ca-bundle with the following 
> benefits:
>   - Uses the CAs Apple provides -- that way MacPorts doesn't have to be 
> in the business of distributing CA certificates.
>   - Also includes any custom CAs that the user has added. This is the 
> case for many people who use internal CAs to sign certificates for their 
> corporate (or personal) services.
>   - Automatically updates (if the launchd item is loaded) when the System 
> Keychain(s) or trust settings are modified. 
> 
> There are a few gotchas that I could use input on, however:
>   - curl-ca-bundle currently lays claim to 
> ${prefix}/etc/openssl/cacerts.pem. This conflicts with certsync, and there's 
> no way to have both installed at the same time.
>   - A small number of ports directly depend on curl-ca-bundle to ensure 
> that valid CA certificates are available.
>   - certsync can only keep the cert.pem file up-to-date if the launchd 
> item is enabled. Ideally that would be done by default, but that's not 
> currently supported.
> 
> Any thoughts on how to proceed?
> 
> I'm currently using certsync locally; to install, you'll have to:
>   sudo port -f deactivate curl-ca-bundle
>   sudo port install certsync
> 
> -landonf
> ___
> 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: Detect OS upgrades and refer users to Migration

[Landon Fuller]

On Nov 17, 2013, at 14:02 , Chris Jones  wrote:

> Yes, there are. For instance the change in the default c++ runtime from 
> libstdc++ to libc++ with OSX 10.9. These two runtimes cannot reliably be 
> mixed, so rebuilding all ports is the only safe option. Yes, you might get by 
> not doing this, for a while, but sooner or later you will run into problems, 
> and the root cause is often hard to spot. users might consider the rebuild a 
> pain, but the macPorts devs equally would consider the stream of 'bug' 
> reports because this is not done, a pain... A rebuild is better all round, in 
> the long term.

Given that macports::revupgrade_scanandrebuild is already scanning for broken 
dylib dependencies, I think marking C++ runtime mismatches within the scanning 
dependency graph would be well within its purview?

-landonf___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Detect OS upgrades and refer users to Migration

[Landon Fuller]

On Nov 4, 2013, at 20:06 , Ryan Schmidt  wrote:

> ... we’d really prefer them to uninstall and reinstall all ports.

Users *really* (and rightfully) hate this, especially when there aren't binary 
packages available. For our local machines, we simply upgraded MacPorts base, 
and left the existing port installs in place -- so far, everything has worked 
fine.

In theory, Apple should provide ABI compatibility across releases; is there any 
modern reason why we should still be encouraging (or enforcing) a full 
uninstall and reinstall?

-landonf___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [110171] trunk/dports/gnome

[Landon Fuller]

On Aug 27, 2013, at 19:47 , Ryan Schmidt  wrote:

> On Aug 27, 2013, at 14:49, dev...@macports.org wrote:
> 
>> Revision: 110171
>> https://trac.macports.org/changeset/110171
>> Author:   dev...@macports.org
>> Date: 2013-08-27 12:49:23 -0700 (Tue, 27 Aug 2013)
>> Log Message:
>> ---
>> rest: new port, helps accessing web services that claim to be RESTful.
> 
>> Added: trunk/dports/gnome/rest/Portfile
> 
>> +depends_run port:curl-ca-bundle
> 
> Could certsync satisfy this dependency?

I could certainly use more test cases to see whether the build server timing 
out was an isolated incident.

-landonf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Friendly talk

[Landon Fuller]

On Aug 28, 2013, at 19:47 , Ryan Schmidt  wrote:

> On Aug 28, 2013, at 15:48, Marius Coțofană wrote:
> 
>> I have stumbled upon this [0]. It seems like the Homebrew guys
>> are using MacPorts' name in a bad way, thus generating negative
>> advertising for us.
>> 
>> I believe we can have a talk with them and solve this little 'problem'.
>> What do you think ?
>> 
>> [0] - https://www.google.ro/search?q=homebrew
> 
> I consider it friendly rivalry. They take some ideas from us, we take some 
> ideas from them. And Fink and other package managers too. We all have the 
> same goal after all: help users install software. Competition from other 
> package managers, especially for OS X, is good and keeps all of us innovating 
> and improving.

That's a much more charitable interpretation than I maintain :) We've always 
been friendly and collaborative with the Fink project members, and we certainly 
never made publicly snide comments about our respective projects.

> We haven't responded officially to Homebrew's their tagline, but we might see 
> if we could think up a clever phrase in the same vein and display it 
> somewhere.


I don't normally think this sort of thing is good behavior in our field, but:
Homebrew leaving you hungover? Try MacPorts!

-landonf :)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [109246] trunk/base/ChangeLog

[Landon Fuller]

On Aug 12, 2013, at 8:29 AM, Clemens Lang  wrote:

> On Mon, Aug 12, 2013 at 11:17:03AM -0400, Daniel J. Luke wrote:
>> While I can see where this is useful - it was purposely not added to
>> startupitem support in the early implementation and I think we at
>> least want to highly discourage anyone from using it.
> 
> I agree. There are only a few very limited cases where using this is a
> good idea. IMO, certsync is one of them …

FWIW, I'm in full agreement here. I think certsync borders the edge of where 
use of this flag is acceptable, and it should definitely never be used for 
network daemons.

-landonf___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Certificate Authorities: curl-ca-bundle, certsync, keychain

[Landon Fuller]

On May 23, 2013, at 5:00 AM, Ryan Schmidt  wrote:

> 
> On May 23, 2013, at 05:54, Rainer Müller wrote:
> 
>> I ran into this problem with the recent mercurial upgrade. I guess we
>> should rewrite this dependency such that it's satisfied by both ports:
>> 
>> depends_run  path:share/curl/curl-ca-bundle.crt:curl-ca-bundle
> 
> Ideally certsync would replace curl-ca-bundle.
> 
> 
>>> - certsync can only keep the cert.pem file up-to-date if the launchd 
>>> item is enabled. Ideally that would be done by default, but that's not 
>>> currently supported.
>> 
>> Right, but we should have a note in certsync recommending to load the
>> launchd item.
> 
> Ideally certsync should manage automatically starting and stopping the 
> launchd item. We discussed this elsewhere…

Now that this is in 2.2 (thanks Clemens!), anyone object to making the switch? 
To make sure I've got it down right:
- Existing ports have their curl-ca-bundle dependency replaced with a 
dependency on certsync
- curl-ca-bundle is marked as replaced_by certsync

-landonf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [108385] trunk/dports/gis/gdal/Portfile

[Landon Fuller]

On Jul 30, 2013, at 14:31, Ryan Schmidt  wrote:

> 
> On Jul 30, 2013, at 09:49, Landon J Fuller wrote:
> 
>> Without actually measuring the gains, there's no guarantee that these 
>> changes will actually improve performance, and in moving away from the 
>> optimization flags et al selected by the original developers, could very 
>> possibly trigger bugs in code generation output (e.g., compiler bugs, 
>> especially with bleeding-edge clang), or reveal bugs in the project that 
>> aren't apparent at lower optimization levels.
> 
> All ports in MacPorts already move away from the optimization flags selected 
> by the original developers. MacPorts 2.2 sets optflags to -Os, to match what 
> Apple uses to compile the software distributed with OS X; previous versions 
> of MacPorts set optflags to -O2. Most ports don't care what optimization 
> flags are used and respect the values MacPorts provides. Some ports do care 
> and their build systems (or in some cases their portfiles) override what 
> MacPorts sets.

-Os is a much safer default in that its widely tested and a reasonable 
conservative choice. All Xcode projects default to -Os, and as you noted,  
Apple ships most of their code compiled with -Os. The setting is also less 
aggressive than -O2, and unlikely to result in any surprises for the original 
developers.

-landonf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Certificate Authorities: curl-ca-bundle, certsync, keychain

[Landon Fuller]

Howdy,

Over the weekend I whipped up (and added a port for) 'certsync'; it's a small 
tool that fetches all trusted certificates from the Mac OS X system keychain, 
and then spits them out as OpenSSL-readable pem-encode certificate bundle.

The goal was to provide a replacement for curl-ca-bundle with the following 
benefits:
- Uses the CAs Apple provides -- that way MacPorts doesn't have to be 
in the business of distributing CA certificates.
- Also includes any custom CAs that the user has added. This is the 
case for many people who use internal CAs to sign certificates for their 
corporate (or personal) services.
- Automatically updates (if the launchd item is loaded) when the System 
Keychain(s) or trust settings are modified. 

There are a few gotchas that I could use input on, however:
- curl-ca-bundle currently lays claim to 
${prefix}/etc/openssl/cacerts.pem. This conflicts with certsync, and there's no 
way to have both installed at the same time.
- A small number of ports directly depend on curl-ca-bundle to ensure 
that valid CA certificates are available.
- certsync can only keep the cert.pem file up-to-date if the launchd 
item is enabled. Ideally that would be done by default, but that's not 
currently supported.

Any thoughts on how to proceed?

I'm currently using certsync locally; to install, you'll have to:
sudo port -f deactivate curl-ca-bundle
sudo port install certsync

-landonf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: first experiences with rev-upgrade

[Landon Fuller]

On Apr 8, 2012, at 8:42 AM, Rainer Müller wrote:

> On 2012-04-08 13:57 , Clemens Lang wrote:
>> Not running rev-upgrade automatically will probably cause it never to be
>> run at all by the average user. We could run the analysis phase
>> automatically and instruct the user to issue port rev-upgrade to trigger
>> the rebuild manually when problems occur. However, as said before,
>> there's no point in keeping broken binaries and users might just as well
>> be annoyed by updates breaking their other ports as much as they are
>> annoyed by some phase trying to fix it automatically for them.
> 
> Instead of running rev-upgrade automatically we could follow the
> approach in selfupdate/upgrade outdated. 'port selfupdate' prints a
> message that users should run 'port upgrade outdated' to upgrade their
> ports.
> 
> For rev-upgrade, that could be implemented as a message in the form of
> "X broken ports found, run 'port rev-upgrade' to rebuild these ports."
> and do not automatically pursue the upgrade.
> 
> Personally I switched to the 'report' action for rev-upgrade in
> macports.conf, which is suitable for developers. However such an option
> is not a replacement for a sane default behavior for end users.

I think it should be noted that rev-upgrade isn't really optional in the same 
way that 'upgrade outdated' is -- rev-upgrade is detecting genuinely broken 
binaries and fixing them, automatically.

As an end user, I just want things to work. If port(1) automatically fixes 
broken ports on my system, all the better. I don't personally think adding 
additional steps to fixing otherwise broken binaries is a better experience for 
users.

-landonf

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [59862] trunk/dports/archivers/zip/Portfile

[Landon Fuller]

On Oct 24, 2009, at 7:02 PM, Ryan Schmidt wrote:



On Oct 24, 2009, at 20:32, land...@macports.org wrote:


Revision: 59862
http://trac.macports.org/changeset/59862
Author:   land...@macports.org
Date: 2009-10-24 18:32:20 -0700 (Sat, 24 Oct 2009)
Log Message:
---
Fix +universal:
- Update the reinplace regexp to match the current sources
- Work-around base's automake-specific setting of --disable- 
dependency-tracking


In what way was the universal build broken?


In the ways I endeavored to list in the commit log.

I've had zlib installed universal for ages, and rebuilt it again a  
few days ago, and "lipo -info" shows that libz.dylib is universal.

Is what I've got not a proper universal build?


The port is zip, not zlib.

-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [57854] trunk/dports/www/phpmyadmin/Portfile

[Landon Fuller]

On Sep 17, 2009, at 12:08 PM, Ryan Schmidt wrote:



On Sep 17, 2009, at 13:43, Landon Fuller wrote:



On Sep 17, 2009, at 8:44 AM, Ryan Schmidt wrote:


On Sep 17, 2009, at 10:36, alaka...@macports.org wrote:


If you need to create files (like config files) outside of the  
destroot, you should do so in the post-activate phase, not in the  
destroot phase.


I believe the (documented? defacto?) standard is that example  
configuration files should be installed in destroot phase with  
a .sample extension.


Uh, yes. Well the sample config file should be installed with a name  
ending in e.g. ".sample" and this should be done in the destroot  
phase and this file should be part of the destroot. But if you then  
want to copy that sample config file to a real config file for the  
user to modify, that should be done outside the destroot and outside  
the destroot phase, after the port has been activated.


My only point was that the historically standard behavior was to  
install .sample files and not try to add configuration management  
logic to either the base system or every port that uses a  
configuration file.


If the new standard is to write custom per-port post-activate handlers  
to manually trigger ui_msg and install default configuration files,  
then perhaps it's worth revisiting the years-old decision to not add  
base system feature for handling configuration files.


*shrug*.

-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [57854] trunk/dports/www/phpmyadmin/Portfile

[Landon Fuller]

On Sep 17, 2009, at 8:44 AM, Ryan Schmidt wrote:


On Sep 17, 2009, at 10:36, alaka...@macports.org wrote:


If you need to create files (like config files) outside of the  
destroot, you should do so in the post-activate phase, not in the  
destroot phase.


I believe the (documented? defacto?) standard is that example  
configuration files should be installed in destroot phase with  
a .sample extension.


-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: openvpn2: "Cannot allocate TUN/TAP dev dynamically"

[Landon Fuller]

On Aug 28, 2008, at 1:36 AM, Uwe Schwartz wrote:

At the end I would suggest to not include the drivers in openvpn  
port, because there are also other tools which use TUN/TAP.


+1
I use openvpn2 but have externally installed tun/tap drivers, and the  
kexts would conflict.


-landonf




PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: openvpn2: "Cannot allocate TUN/TAP dev dynamically"

[Landon Fuller]

On Aug 28, 2008, at 8:58 AM, Caspar Florian Ebeling wrote:



Another problem could be a conflict with an already installed Kext  
(maybe

the legacy TUN/TAP driver or Tunnelblick).


MacPorts does not overwrite files but rather fails before doing so.
And then you just have to know how you manually configured your
system.


MacPorts shouldn't be installing files into a directory it doesn't  
control, however -- that was the thinking behind /Applications/MacPorts/


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: Weird distfile URLs

[Landon Fuller]

On Aug 1, 2008, at 3:33 AM, Caspar Florian Ebeling wrote:


it just strikes me that there was this undocumented "curl" command in
Pextlib. I'll check it later, but
it sounds exactly like what I need...


Except then your fetch would be imperative instead of declarative, and  
you'll skip some important machinery.

The command is purposefully undocumented for Portfile use.




PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [38815] trunk/dports/science/geos

[Landon Fuller]

On Jul 31, 2008, at 9:38 PM, Adam Mercer wrote:

On Thu, Jul 31, 2008 at 11:23 PM, Landon Fuller  
<[EMAIL PROTECTED]> wrote:


On Jul 31, 2008, at 9:05 PM, Adam Mercer wrote:


On Thu, Jul 31, 2008 at 7:07 PM,  <[EMAIL PROTECTED]> wrote:

3.0 's C-API is both API and binary compatible with the 2.x  
release, and

I
tested building / running PostGIS.


No it is not, py25-matplotlib-basemap is now broken, it does not  
build

against 3.0.x!



I went off the developer's statements on compatibility, but,  
unfortunately:


http://www.mail-archive.com/[EMAIL PROTECTED]/msg05301.html

So it sounds like we either need to fix the issues, or keep around  
GEOS 2.x

*and* GEOS 3.x, and that's going to be a bloody mess.

I see you rolled back the port. It looks like ticket #13699 has  
been sitting
since March -- can I just create a GEOS 2.x port and py25- 
matplotlib-basemap

can depend on that?


I've been trying since March to get basemap working with 3.0.x, it can
build but doesn't work properly. The basemap developer has also been
trying and can't get anywhere. So at the moment, the only solution is
to have a separate geos3 port. As you want to add ports that require
geos3 we'll have to go that way.


OK, I implemented the fixes for issue #13699:
geos2 committed in r38824.
py25-matplotlib-basemap updated in r38825.
py-matplotlib-basemap updated in r38826.
geos updated to 3.0.0 in r38827.
	matplotlib-basemap port revisions bumped in r38828 to ensure that the  
ports are linked to geos2.


I verified that the basemap ports were correctly linked, and ran  
example/test.py to sanity-check the output. I've got time to spend on  
this, so please let me know if anything is incorrect and I'll get it  
working.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [38815] trunk/dports/science/geos

[Landon Fuller]

On Jul 31, 2008, at 9:05 PM, Adam Mercer wrote:


On Thu, Jul 31, 2008 at 7:07 PM,  <[EMAIL PROTECTED]> wrote:

3.0 's C-API is both API and binary compatible with the 2.x  
release, and I

tested building / running PostGIS.


No it is not, py25-matplotlib-basemap is now broken, it does not build
against 3.0.x!



I went off the developer's statements on compatibility, but,  
unfortunately:

http://www.mail-archive.com/[EMAIL PROTECTED]/msg05301.html

So it sounds like we either need to fix the issues, or keep around  
GEOS 2.x *and* GEOS 3.x, and that's going to be a bloody mess.


I see you rolled back the port. It looks like ticket #13699 has been  
sitting since March -- can I just create a GEOS 2.x port and py25- 
matplotlib-basemap can depend on that?


I'd like to move the state of the world forward.

-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: Conflict with /Applications/MacPorts when multiple MacPorts instances installed

[Landon Fuller]

On Jul 30, 2008, at 8:07 AM, Anders F Björklund wrote:


- frameworks-dir (/Library/Frameworks)


Shouldn't this be ${prefix}/Library/Frameworks? It can still be  
referenced with the -F compiler/linker flag

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: Name for StartupItem Variant

[Landon Fuller]

On Jul 25, 2008, at 11:52 AM, Uwe Schwartz wrote:


Hi,

I would like to add a variant to a port which should create a  
StartupItem.
In the MacPort Guide the example uses "server" as name for the  
variant.

Is this common practice? Or are there any other suggestions?


I would suggest either *always* installing the startup item (but  
disabled by default), or creating a new port, -server, that  
depends on the base port and declares only a startup item.


The postgresql ports all provide "-server" ports -- you don't have to  
rebuild the whole port just to add a startup item.


In contrast, I can't tell you the number of times I had employees  
accidentally build MySQL without the +server variant on their  
workstation, and then have to rebuild it all again just for the  
startup item.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

caml vs. ocaml

[Landon Fuller]

A number of ports are named "caml-", but are actually OCaml ports.  
They seem to only be used as dependencies for Unison (which is written  
in OCaml).


Objections to changing their name to ocaml? This will probably cause a  
headache for anyone who currently has Unison installed.

Other suggestions?

-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [38109] trunk/base

[Landon Fuller]

On Jul 7, 2008, at 9:41 AM, Randall Wood wrote:

On Mon, Jul 7, 2008 at 12:02 PM, Landon Fuller  
<[EMAIL PROTECTED]> wrote:


On Jul 7, 2008, at 3:18 AM, Randall Wood wrote:

On Mon, Jul 7, 2008 at 5:00 AM, Ryan Schmidt <[EMAIL PROTECTED] 
>

wrote:



Do you mean to change the user's shell for them? It should be  
possible

with
NetInfo. But I don't think MacPorts should be the one to tell the  
user

what
shell to use.

Or did you mean something else?



I meant something like what fink does. See
http://trac.macports.org/wiki/SummerOfCode task 10


I'm not sure I'd want ports to assume the ability to modify my shell
environment.
The shell environment something I'm pretty specific about, and I  
wouldn't

want anything assuming that it could modify it.

-landonf



In your case, you probably don't want to source a macports script for
your environment anyway, right?

But if you are going to source some script we provide, why not let
ports set certain expected environment variables that make
correct-in-most-cases-but-not-ours assumptions that can be overridden
by setting the environment. Its better than patching the upstream code
if the code respects env. variables, and carries defaults that make
sense in almost every other UNIX out in the wild. (Specifically, I am
thinking of the environment variables that unless set or patched,
cause GNOME/KDE/other-Freedesktop-spec-implementations to look for
configuration data in /usr or /usr/local instead of /opt/local)

An ideal mechanism would be something like having a port include a
statement like:

shell.env name value

and having the install/uninstall phases generate/remove a file (1 for
each supported shell environment) containing the shell-specific syntax
for including that variable in the shell


Ports would assume those environmental variables are set (and can be  
set), rather than patching the software and having it Just Work no  
matter what environment they're run from (including non-shell  
environments).


I'd say patching is a lot less complicated, and far more polite, than  
trying to control the program's external environment.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [38109] trunk/base

[Landon Fuller]

On Jul 7, 2008, at 3:18 AM, Randall Wood wrote:

On Mon, Jul 7, 2008 at 5:00 AM, Ryan Schmidt  
<[EMAIL PROTECTED]> wrote:



Do you mean to change the user's shell for them? It should be  
possible with
NetInfo. But I don't think MacPorts should be the one to tell the  
user what

shell to use.

Or did you mean something else?



I meant something like what fink does. See
http://trac.macports.org/wiki/SummerOfCode task 10


I'm not sure I'd want ports to assume the ability to modify my shell  
environment.
The shell environment something I'm pretty specific about, and I  
wouldn't want anything assuming that it could modify it.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: checking for swig variants in a pre-fetch hook

[Landon Fuller]

On Jul 3, 2008, at 11:25 PM, Adam Mercer wrote:


The recent changes to the swig port have broken the scipy build on
Tiger, essentially the problem is that scipy requires the python
variant of swig to be installed.



Swig's variants:
	swig 1.3.36, devel/swig (Variants: universal, doc, python, perl, gcj,  
guile, mzscheme, ruby, php4, ocaml, pike, lua, chicken, allegro,  
clisp, r)


Why not enable some of these by default? Having none of them enabled  
makes swig useless, seems like defaulting to:

- python
- perl
- ruby
- php4

Would be a good start.

-landonf




PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Batteries Included Policy

[Landon Fuller]

I would like to propose a policy for general consideration. I believe  
it could save everyone energy and brain-cycles; let's call it  
"batteries included":
	As a general rule, ports should enable all standard features/ 
functionality that may be useful to an end-user.


With this:
	- You never install a port to later discover that it is missing some  
necessary piece of functionality.
	- Less likely that your port will depend on another port's specific  
set of variants.


Features that probably should be enabled by default, but often aren't:
- SSL support.
- LDAP support.
	- Database support (pgsql, mysql, sqlite). The client libraries are  
cheap to install.
	- SASL/GSSAPI support. Mac OS X is very kerberos-enabled, MacPorts  
can and should be too.


Variants should only be used for features that are highly unusual and/ 
or experimental.


I believe that aiming for "batteries included" will significantly  
reduce the headache and hassle of installing some software and getting  
on with your work.


-landonf



PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [37074] trunk/dports/lang

[Landon Fuller]

On May 26, 2008, at 2:40 PM, Rainer Müller wrote:


[EMAIL PROTECTED] wrote:

Revision: 37074
 http://trac.macosforge.org/projects/macports/changeset/37074
Author:   [EMAIL PROTECTED]
Date: 2008-05-25 16:50:14 -0700 (Sun, 25 May 2008)
Log Message:
---
Add a port for GNU smalltalk


We already had this port as "gst".

--snip--
$ port info gst
gst @3.0.1 (lang)
Variants:darwin_6, universal

GNU Smalltalk is a free implementation of the Smalltalk-80 language  
which runs

on most versions on Unix and, in general, everywhere you can find a
POSIX-compliance library. An uncommon feature of it is that it is  
well-versed to

scripting tasks and headless processing.
Homepage:http://smalltalk.gnu.org/
--snap--


My mistake, I'd only searched for 'smalltalk'. I'll rename gnu- 
smalltalk to gst-dev and normalize the ports.


Thanks,
-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: Macports's buggy configure scripts

[Landon Fuller]

On May 8, 2008, at 11:25 PM, Anders F Björklund wrote:


Confirmed, the src/Makefile doesn't rebuild the "port" binary
when you configure twice in the same directory. The workaround
for now is to "clean" base before doing the second installation.
(preferably distclean, but "dist" and "distclean" are missing)
Not sure why that doesn't use autoconf, but instead a sed hack.


To solve the opposite problem -- if you change the source file, 'make'  
should remake it. See:


http://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables

Specifically:
	Similarly, you should not rely on AC_CONFIG_FILES to replace datadir  
and friends in
	your shell scripts and other files; instead, let make manage their  
replacement. For instance
	Autoconf ships templates of its shell scripts ending with `.in', and  
uses a makefile snippet

similar to the following to build scripts like autoheader and autom4te:

edit = sed ...

If re-running configure should also cause any files to be regenerated,  
then another 'make' dependency is probably in order.


-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [35353] tinyca2 Lint Report

[Landon Fuller]

On Mar 26, 2008, at 12:13 AM, Ryan Schmidt wrote:


Patchfile naming: The old guide was contradictory, and in one place,
recommended the naming scheme "patch-*" while in another place it
recommended "patch-*.diff". The new guide is now consistent in
recommending "patch-*.diff".


The original documentation (which I wrote) was originally consistent  
with the FreeBSD

patch specification:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/slow-patch.html

We then adopted the semantic of patch-foobar.diff, where 'foobar' was  
a feature that
covered many files -- this was due to the headache of patch-per-file  
for a sizable set

of diffs.

I don't actually think it matters what name you use, as long as it  
makes sense.


As I have explained over and over on this list, I prefer this  
because my

editor can then syntax-highlight
diff files like diff files, instead of like whatever the underlying
file type is, which would be an error, because, e.g., the difference
of two C files IS NOT a C file; it is a difference file and should be
treated as such. Mac OS X cannot assign applications based on file
prefixes. It can only assign applications based on file extensions.
Therefore diff files must have a unique extension, as should all
other types of files.



I don't want to get e-mailed when I name a patch that makes *your*  
editor

unhappy when you double-click a file. The e-mail should be saved for
something that's actually an error.


Trailing whitespace: trailing whitespace after a backslash causes an
error (the line is not continued as expected). Such whitespace must
not exist. I'm not sure if there are other trailing whitespace issues
that were being caught by this check. If not, the check could be
reduced to catching trailing whitespace following a backslash.


My original newline complaint was:
Warning: Line 2 should be a newline (after RCS tag)

# $Id: Portfile 35353 2008-03-25 18:13:44Z [EMAIL PROTECTED] $
PortSystem  1.0

Why does that matter? These "your contribution is in error!" mails are  
soul draining.
It makes one feel as if you've stumbled into the Department of Motor  
Vehicles and

forgot registration form B.5.

-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Erlang category?

[Landon Fuller]

Any votes for/against creating an Erlang category, to match the Python/ 
Ruby/etc categories? First port I'd like to add is eunit 2.0 (erlang  
unit test library).

-landonf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [35353] tinyca2 Lint Report

[Landon Fuller]

On Mar 25, 2008, at 11:40 AM, Blair Zajac wrote:

> Landon Fuller wrote:
>> On Mar 25, 2008, at 11:31 AM, Blair Zajac wrote:
>>> Landon Fuller wrote:
>>>> On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote:
>>>>> How long does it take to fix it?  One minute.
>>>> It's not broken. It's just like a spell checker that gets annoyed  
>>>> when you type "colour" instead of "color".
>>>
>>> Teams have style guides for everything, such as no space before a  
>>> ( for the Subversion source code, everybody plays along with it.
>> The original style guidelines only tried to enforce things that  
>> mattered.
>>> Just go along with it.  I found a bunch of stuff in my port files  
>>> and cleaned it up.  I don't have an issue with it.  There's more  
>>> important stuff to discuss about.
>> So why do we have a machine auto-emailing humans about stuff that  
>> doesn't matter that much?
>
> I'm guessing by the few emails I've seen taking issue with the style  
> emails that most people don't mind and that that the people that  
> wrote the tool felt that style does matter.
>
> I'm in that camp.  I like seeing all the ports having the same style.

OK. If that's the prevailing opinion I'll just /dev/null the lint  
warnings, hopefully not miss anything truly important, and get on with  
work.

-landonf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [35353] tinyca2 Lint Report

[Landon Fuller]

On Mar 25, 2008, at 11:31 AM, Blair Zajac wrote:

> Landon Fuller wrote:
>> On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote:
>>> How long does it take to fix it?  One minute.
>> It's not broken. It's just like a spell checker that gets annoyed  
>> when you type "colour" instead of "color".
>
> Teams have style guides for everything, such as no space before a  
> ( for the Subversion source code, everybody plays along with it.

The original style guidelines only tried to enforce things that  
mattered.

> Just go along with it.  I found a bunch of stuff in my port files  
> and cleaned it up.  I don't have an issue with it.  There's more  
> important stuff to discuss about.

So why do we have a machine auto-emailing humans about stuff that  
doesn't matter that much?

-landonf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [35353] tinyca2 Lint Report

[Landon Fuller]

On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote:

> How long does it take to fix it?  One minute.

It's not broken. It's just like a spell checker that gets annoyed when  
you type "colour" instead of "color".

-landonf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Fwd: [35353] tinyca2 Lint Report

[Landon Fuller]

I'd like to formally request that these new style guideline be removed  
from port lint -- there's nothing wrong with the port.
This kind of style pedantry wastes everyone's time. It doesn't matter.  
The last thing I need is an e-mail about it.


I didn't place newline between the $Id: $ tag and the PortSystem line:

# $Id: Portfile 35353 2008-03-25 18:13:44Z [EMAIL PROTECTED] $
PortSystem  1.0

I named my patch file 'patch-tinyca2'.

-landonf

Begin forwarded message:


From: [EMAIL PROTECTED]
Date: March 25, 2008 11:13:49 AM PDT
To: [EMAIL PROTECTED]
Subject: [35353] tinyca2 Lint Report

Portfile: tinyca2


Warning: Line 2 should be a newline (after RCS tag)
Warning: Patchfile patch-tinyca2 does not follow the source patch  
naming policy "patch-*.diff"






___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing]

[Landon Fuller]

On Feb 25, 2008, at 1:34 PM, Rainer Müller wrote:



I didn't know they are using such a flat namespace.


They're not -- When there are distfile collisions (and there are),  
they use DIST_SUBDIR to partition a particular port's distfiles.
MacPorts by default simply places all distfiles in a port-specific  
subdirectory, since only port names are required to not conflict.

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [MacPorts Lint] Portfile Lint Errors for: dpkg

[Landon Fuller]

On Feb 6, 2008, at 13:23, Ryan Schmidt wrote:

There is no detriment that I can discern by naming patchfiles  
"patch-*.diff" as port lint recommends. There is a detriment by not  
following this convention which has been discussed at length before  
on the list.


There is a detriment. The patchfiles aren't syntax hilighted as C,  
and instead are hilighted as a patch file. This is purely a matter of  
personal preference, which is a bad reason to dictate policy.


This warning has been in port lint for quite some time already.  
It's just now been made an automated email.


Yes, and getting an e-mail about something I don't think is a problem  
is frustrating.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Fwd: [MacPorts Lint] Portfile Lint Errors for: dpkg

[Landon Fuller]

So I just received the following automated e-mail. While I think  
automated portlint is great, I'm wondering why we need a new ".diff"  
Official Policy just to appease certain people's editors.


Begin forwarded message:


From: [EMAIL PROTECTED]
Date: February 6, 2008 05:17:47 PST
To: [EMAIL PROTECTED]
Subject: [MacPorts Lint] Portfile Lint Errors for: dpkg

Portfile: dpkg


 Errors: Warning: Line 4 should be a newline (after PortSystem)
Warning: Line 33 has trailing whitespace before newline
Warning: Patchfile patch-config.h.in does not follow the source  
patch naming policy "patch-*.diff"
Warning: Patchfile patch-configure does not follow the source patch  
naming policy "patch-*.diff"
Warning: Patchfile patch-configure.in does not follow the source  
patch naming policy "patch-*.diff"
Warning: Patchfile patch-lib_utils.c does not follow the source  
patch naming policy "patch-*.diff"
Warning: Patchfile patch-lib_tarfn.c does not follow the source  
patch naming policy "patch-*.diff"
Warning: Patchfile patch-main_remove.c does not follow the source  
patch naming policy "patch-*.diff"
Warning: Patchfile patch-utils_Makefile.in does not follow the  
source patch naming policy "patch-*.diff"
Warning: Patchfile patch-main_archives.c does not follow the source  
patch naming policy "patch-*.diff"
Warning: Patchfile patch-archtable does not follow the source patch  
naming policy "patch-*.diff"
Warning: Patchfile patch-include_parsedump.h does not follow the  
source patch naming policy "patch-*.diff"
Warning: Patchfile patch-utils_start-stop-daemon.c does not follow  
the source patch naming policy "patch-*.diff"
Warning: Patchfile bsd/patch-main_help.c does not follow the source  
patch naming policy "patch-*.diff"








PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [32194] trunk/base/src/port1.0/portconfigure.tcl

[Landon Fuller]

On Jan 8, 2008, at 00:54, Markus Weissmann wrote:

This should definitely be made user-configurable. Most people will  
actually be interested in building 32 and 64 bit for their machine,  
that is either ppc+ppc64 or i386+x86_64.



Yes, please! 64-bit Intel is the only thing I need 'universal' for =)

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [32446] trunk/dports/sysutils/rpm-devel/Portfile

[Landon Fuller]

On Jan 5, 2008, at 1:42 PM, Ryan Schmidt wrote:



On Jan 3, 2008, at 05:11, Anders F Björklund wrote:


Ryan Schmidt wrote:

Perhaps, but these -devel ports usally build from tip of trunk so  
they all had revision "0"...


Ports should never build from tip of trunk or HEAD or similar  
concepts.


These do.


But that's not reproducible, and I thought we always wanted that. If  
I install a specific version of a port today, I should get the same  
software if I install that same version of that port tomorrow. By  
fetching from HEAD, you break that assumption.


This is why I've thought we should not support CVS/SVN fetching in any  
form -- No checksums, no guaranteed reproducibility.___

macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: macforge.org via https?

[Landon Fuller]

On Jan 2, 2008, at 10:40, Kevin Van Vechten wrote:



On Dec 31, 2007, at 3:26 PM, Landon Fuller wrote:


But HTTP digest doesn't solve any of the problems that SSL solves:
	- It is still vulnerable to a MITM attack. Your password is  
hashed, but the hash is password-equivalent -- an attacker can  
simply forward it on.


Not really... the server sends a random nonce-value, and the client  
must include that in the hashed-response.  Replay is not an issue.


response = MD5(MD5(username : realm : password), nonce, MD5 
(method : uri))


http://rfc.net/rfc2069.html


Replay isn't an issue, but that doesn't stop a MITM attack -- the  
password-equivalent value is usable once.


Attack scenario:
Client requests a page that requires authentication.
	MITM returns 301 redirect to the client. The redirect points to a  
URL the MITM wishes to access.
	Client automatically follows redirect. MITM passes the 401  
Unauthorized response through, client authenticates using HTTP digest.
	MITM has now successfully directed the client to a resource of its  
choice, and acquired a single-use token. Can even be used to form  
POST, via a crafted HTML page.


Nil chance of this happening at your home or internet cafe, but what  
about a targeted attack at a technical conference? Given the wide use  
and distribution of MacPorts, there is significant value in acquiring  
project access.


	- Digest authentication is indistinguishable from Basic  
authentication -- your browser will display the same dialog  
regardless of the authentication type.


Safari distinguishes them; Basic authentication dialogs say the  
password will be sent in the clear.


Currently, trying to access http://www.macosforge.org/wp-login.php in  
Safari says the following:

"Your password will be sent in the clear."

I don't have digest auth set up anywhere, so I can't test digest vs.  
non-digest in Safari.


Firefox doesn't show any difference in the auth dialog -- I'd easily  
login using the basic auth. Also, does Safari refuse to auto-login if  
the authentication type changes?


At best, it will prevent a passive attacker from acquiring your  
password. Anyone engaging in an active MITM attack will have no  
difficultly acquiring your password.



I agree SSL provides additional security benefits, but digest  
authentication isn't as transparent as you indicate.



I still hold that it is -- digest auth makes passive sniffing  
useless, but it doesn't prevent an active attack from acquiring your  
password, especially if you're using a browser that fails to  
differentiate between digest and basic auth.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: macforge.org via https?

[Landon Fuller]

On Dec 25, 2007, at 8:44 AM, Juan Manuel Palacios wrote:



On Dec 25, 2007, at 8:51 AM, js wrote:


Forwarding to macports developers.


-- Forwarded message --
From: js <[EMAIL PROTECTED]>
Date: Dec 25, 2007 12:19 AM
Subject: macforge.org via https?
To: MacPorts Users <[EMAIL PROTECTED]>


Hi list,

A simple question.

is there any reason http://www.macosforge.org/wp-login.php is not  
HTTPS?



Because we use http digest for authentication, not SSL.


But HTTP digest doesn't solve any of the problems that SSL solves:
	- It is still vulnerable to a MITM attack. Your password is hashed,  
but the hash is password-equivalent -- an attacker can simply forward  
it on.
	- Digest authentication is indistinguishable from Basic  
authentication -- your browser will display the same dialog regardless  
of the authentication type.


At best, it will prevent a passive attacker from acquiring your  
password. Anyone engaging in an active MITM attack will have no  
difficultly acquiring your password.


-landonf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [31766] trunk/dports/audio/libao

[Landon Fuller]

On Dec 6, 2007, at 3:37 PM, Ryan Schmidt wrote:

Don't change this now, but remember for next time that the first  
revision of a given port version is 0, not 1. In the future, just  
remove the revision line when upgrading a port's version to get the  
default revision of 0.


The default is helpful (I use it), but what's -wrong- with being  
explicit?


-patchfiles   patch-AU-configure patch-AU- 
src__plugins__macosx__ao_macosx.c

+patchfiles   patch-configure


Patchfiles should be named "patch-whatever.diff". See "port lint".


I guess the same question here. Is there really something wrong with  
not using the .diff extension? These patches match the original naming  
guidelines, but they were just guidelines.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Is there a license on patches

[Landon Fuller]

On Nov 9, 2007, at 15:16, Landon Fuller wrote:



On Nov 8, 2007, at 08:58, Emmanuel Hainry wrote:


Dear list,

For a port I maintain (namely rubber), there are some patches
that upstream has not yet included and are provided by the  
maintainer of

the port for pkgsrc. They are now in macports repository and I wonder
which license if any is applied to patches (as Trac.macports.org  
tells
people that what they put here is automatically under the Apache  
or BSD
License). Is there a way to credit the author of a patch and to  
cite the

license they may be under?

This problem (but is it a problem?) is, I think, not a rare thing:
the work of preparing a program to be part of a ports project is very
similar between pkgsrc, openBSD, freeBSD and macports (maybe  
gentoo and

other linux source based packages too) and hence reusing patches from
others is highly probable.


For what it's worth, it's my assumption that any patches I write  
are licensed

under the same license as the project.


Er, I should clarify. Licensed under the same license as the project  
*that I'm patching*.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Is there a license on patches

[Landon Fuller]

On Nov 8, 2007, at 08:58, Emmanuel Hainry wrote:


Dear list,

For a port I maintain (namely rubber), there are some patches
that upstream has not yet included and are provided by the  
maintainer of

the port for pkgsrc. They are now in macports repository and I wonder
which license if any is applied to patches (as Trac.macports.org tells
people that what they put here is automatically under the Apache or  
BSD
License). Is there a way to credit the author of a patch and to  
cite the

license they may be under?

This problem (but is it a problem?) is, I think, not a rare thing:
the work of preparing a program to be part of a ports project is very
similar between pkgsrc, openBSD, freeBSD and macports (maybe gentoo  
and

other linux source based packages too) and hence reusing patches from
others is highly probable.


For what it's worth, it's my assumption that any patches I write are  
licensed
under the same license as the project. I also do not claim copyright  
unless

the patch is a substantial piece of work.

I'd assume this is the general rule, as anything else can quickly run  
into

license complications.

-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [28796] trunk/base/src

[Landon Fuller]

On Sep 10, 2007, at 1:28 AM, Ryan Schmidt wrote:



On Sep 9, 2007, at 00:29, [EMAIL PROTECTED] wrote:


Revision: 28796
  http://trac.macosforge.org/projects/macports/changeset/ 
28796

Author:   [EMAIL PROTECTED]
Date: 2007-09-08 22:29:36 -0700 (Sat, 08 Sep 2007)

Log Message:
---
- Hide 'cd' as '_cd'. It should be removed entirely once the few  
uses can be fixed in port1.0

- Fix escaping of } { in strings in base/src/port1.0/portinstall.tcl


[snip]

So this means we need to get all occurrences of "cd" out of all  
portfiles before trunk becomes a released version of MacPorts, right?


It's either that, or add a deprecated wrapper for 'cd' that prints a  
warning.
Unfortunately it appears that quite a few ports have picked up on the  
'cd' usage (437), so a deprecation wrapper may be the best option.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Problem with the repository: bogus date

[Landon Fuller]

On Sep 7, 2007, at 14:29, Blair Zajac wrote:


Landon Fuller wrote:

On Sep 7, 2007, at 09:43, Rainer Müller wrote:

It's nice to fix typos in log messages. But it could be limited to
svn:log for that purpose with a pre-revprop-change like this:
The log being unversioned, that still seems a dangerous tool to  
leave open. Here at work, unrevisioned properties require local  
access to the repository -- nobody else has this. I only recall  
one instance in the past three years that I've been asked to  
change a commit log message on behalf of any of our developers,  
and I've never done so for myself.
I'd personally rather have a few uncorrected typos in commit logs  
than the potential for history-changing. Auditing the changes is  
an improvement, but why even open the door?


We do this all the time in the Subversion's own repository.  The  
standard way of handling it is to use mailer.py to send a diff of  
the before and after log message to some list.  This can be set up  
in the post-revprop-change script.


It's common to edit log messages.  In fact, the recommended  
procedure for a reverse merge of a revision is to now go back and  
edit the log message on the reverted revision indicating that it  
was reverted and in which revision.


That's crazy talk! That sort of information is generally conveyed in  
bug tracking systems, not by changing history in your source  
repository. It may be common in the subversion project's usage, but I  
don't see why it's an inherent necessity (or even a very good idea).


Given that this discussion started with accidental destruction of a  
non-revisioned historical property, it's obviously not an academic  
concern. Two options:

- Treat the commit message as immutable as the commit itself.
or
	- Allow people to fix typos and change history, with the potential  
for destructive changes.


The first option seems both simplier and safer, is the default  
configuration, and is the standard expectation of a source control  
system -- no data can be irretrievably lost.


-landonf



PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Problem with the repository: bogus date

[Landon Fuller]

On Sep 7, 2007, at 09:43, Rainer Müller wrote:


Landon Fuller wrote:


On Sep 4, 2007, at 12:03 PM, Ryan Schmidt wrote:


Very sorry! That was my fault. I've now fixed the svn:date property
of revision 2 so the log should work again. The timestamp of  
revision

1 and revision 3 are identical, so I set revision 2 to that same
timestamp.

(I issued a bad "svn propset" command the other day. I was  
meaning to

change my own repo but I was missing an argument or something and
then I couldn't figure out what I'd done. I must've been in my  
dports

tree when I issued the command.)


Oh, and I wanted to say: if we had the post-revprop-change email  
hook,

I would've noticed and been able to fix the problem right away. :-)

http://trac.macports.org/projects/macports/ticket/12593


Maybe the repository shouldn't allow unrevisioned property changes at
all? It seems like a good way to stomp on version history.


It's nice to fix typos in log messages. But it could be limited to
svn:log for that purpose with a pre-revprop-change like this:


The log being unversioned, that still seems a dangerous tool to leave  
open. Here at work, unrevisioned properties require local access to  
the repository -- nobody else has this. I only recall one instance in  
the past three years that I've been asked to change a commit log  
message on behalf of any of our developers, and I've never done so  
for myself.


I'd personally rather have a few uncorrected typos in commit logs  
than the potential for history-changing. Auditing the changes is an  
improvement, but why even open the door?


-landonf



PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Problem with the repository: bogus date

[Landon Fuller]

On Sep 4, 2007, at 12:03 PM, Ryan Schmidt wrote:

Very sorry! That was my fault. I've now fixed the svn:date  
property of revision 2 so the log should work again. The timestamp  
of revision 1 and revision 3 are identical, so I set revision 2 to  
that same timestamp.


(I issued a bad "svn propset" command the other day. I was meaning  
to change my own repo but I was missing an argument or something  
and then I couldn't figure out what I'd done. I must've been in my  
dports tree when I issued the command.)


Oh, and I wanted to say: if we had the post-revprop-change email  
hook, I would've noticed and been able to fix the problem right  
away. :-)


http://trac.macports.org/projects/macports/ticket/12593


Maybe the repository shouldn't allow unrevisioned property changes at  
all? It seems like a good way to stomp on version history.


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Default compiler suite (was Re:[28325] trunk/dports/graphics/wxWidgets-devel/Portfile)

[Landon Fuller]

On Sep 1, 2007, at 6:07 AM, Weissmann Markus wrote:

'portconfigure.tcl' from trunk will chose a default for darwin  
7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/local/ 
share/macports/Tcl/port1.0/portconfigure.tcl with http:// 
svn.macports.org/repository/macports/trunk/base/src/port1.0/ 
portconfigure.tcl manually should do the trick.


This version also fixes a bug that when using configure.compiler  
every user-added compiler selection (e.g. 'configure.cc /bin/true')  
was overwritten.


This is going to break ports that require a different compiler, but  
specify the compiler using configure.env, or arguments to configure  
via configure.args.
It's a shame that there are no auto-builds, as we don't know what  
will break.


At the very least, would you be opposed to a new flag that enables  
(or disables) this behavior?


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Features desirable for packaging

[Landon Fuller]

On Aug 30, 2007, at 2:48 AM, Anders F Björklund wrote:

It has been mentioned before, so I thought I'd summarize what  
features that could benefit the packaging targets (I'm thinking  
primarily of the "rpm" target here of course, but I'm sure it'd  
help pkg and deb targets as well):


1) Config files

We need a feature in the Portfile to mark which of the install  
files are configuration. These files will then be handled specially  
when doing installations/upgrades/removals, in that any existing  
modified configuration will *not* be overwritten. It could also be  
helpful for implementing a similar feature in the regular install/ 
activate target too.


Syntax could probably be similar to "destroot.keepdirs"


This might be a nice mechanism for doing the initial installation of  
example configuration files. I wouldn't want to go too far and do  
what Debian does -- try to manage configuration files for you. It's  
not so bad when they ask if you want to update/diff/merge the files  
(although that's annoying and in my experience a bad method for  
handling software upgrades) -- it's downright dangerous when they try  
to auto-merge configuration based on scripts (think apache, sendmail,  
exim, etc).



2) Sub-packages

When building binary packages, having everything in a single port  
increases the size of package dependencies greatly. Usually one  
doesn't need the developer files, so there's a whole bunch of  
headers and whatnot undesirable. Splitting these off into a  
subpackage called "*-dev" (from DEB) or "*-devel" (this RPM naming  
is already taken in MP unfortunately) helps here.


Not sure about syntax here. It needs to list the files.


I like subpackages -- especially for things like -server vs -client,  
but I'm not so sure about debian-style header packages -- there's not  
much advantage to not shipping headers (save a few k), and it  
complicates the dependency tree and requires the user to select  
multiple packages for installation. I also admittedly have a heavy  
developer bias here.



3) More metadata

Some metadata is currently missing from the Portfiles. It would be  
nice if these could be added with MacPorts 1.6, but it does require  
a major update since the older "port" won't understand any such new  
fields added to the syntax. Extracting changelogs from svn might be  
nice to include too, but is probably not required until it has been  
fully  automated.


a) License metadata (http://trac.macports.org/projects/macports/ 
ticket/7493)


Currently all ports have license "Unknown", no matter what the  
actual license used.


Example portfile syntax: "licenseGPL"

b) Noarch metadata (http://trac.macports.org/projects/macports/ 
ticket/12206)


Currently all ports have architecture "native", no matter what the  
actual arch is.


Example portfile syntax: "noarchyes"


I agree that we need more meta-data here -- especially licensing  
information, since there are redistribution limitations depending on  
the license.

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: The Destroot Bug

[Landon Fuller]

On Aug 30, 2007, at 11:09 AM, Anders F Björklund wrote:



I should have mentioned that the most annoying bug for all binary  
targets (archive or package) must be: http://trac.macports.org/ 
projects/macports/ticket/10881


As noted in the bug, it requires you to -force the destroot  
(usually by doing a clean and a full rebuild, or an unarchive) or  
uninstall everything that you want to package.



The main bug is:
DEBUG: Skipping com.apple.destroot (FOO) since this port is already  
installed


It should *not* skip the destroot target, even if the port is  
indeed installed.


I'm not sure why skipping of targets was added, since it's the  
dependency resolver's responsibility to determine what needs doing.  
In this case, destroot 'needs doing', and the dependency system would  
work correctly if it wasn't short circuited.


What's the advantage to the target skipping addition?

-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [28311] trunk/dports/lang

[Landon Fuller]

On Aug 28, 2007, at 10:30 PM, N_Ox wrote:


Le 29 août 07 à 01:18, Landon Fuller a écrit :



On Aug 28, 2007, at 4:16 PM, N_Ox wrote:

You shouldn't use Tcl's "cd" in a port -- it changes the current  
working directory of the entire process. We should probably  
remove the Tcl command from the interpreter.


-landonf


I think we should change this behavior rather than disabling the  
command.
Useful working directories in build stages (e.g. ${worksrcpath}  
in configure or ${destroot} in destroot) would be a nice feat.


We would have to rewrite? all file operations to take into account  
a virtual current working directory, and somehow maintain that  
context within the current execution block.
Seems safer and less work to just not depend on a the current  
working directory (which is always a good idea, anyway).


So what is the purpose of the ln procedure? and mv?


They will correctly operate on fully qualified paths.

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [28311] trunk/dports/lang

[Landon Fuller]

On Aug 28, 2007, at 4:16 PM, N_Ox wrote:

You shouldn't use Tcl's "cd" in a port -- it changes the current  
working directory of the entire process. We should probably remove  
the Tcl command from the interpreter.


-landonf


I think we should change this behavior rather than disabling the  
command.
Useful working directories in build stages (e.g. ${worksrcpath} in  
configure or ${destroot} in destroot) would be a nice feat.


We would have to rewrite? all file operations to take into account a  
virtual current working directory, and somehow maintain that context  
within the current execution block.
Seems safer and less work to just not depend on a the current working  
directory (which is always a good idea, anyway).


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [28311] trunk/dports/lang

[Landon Fuller]

On Aug 28, 2007, at 1:58 PM, N_Ox wrote:



Le 28 août 07 à 04:00, [EMAIL PROTECTED] a écrit :


Revision 28311
Author [EMAIL PROTECTED]




+	system "cd ${destroot}${prefix}/bin && ln -sf ${nprefix}/bin/gcc- 
apple-4.0 && ln -sf ${nprefix}/bin/cpp-apple-4.0"




Why don't you use cd and ln TCL procedures?


You shouldn't use Tcl's "cd" in a port -- it changes the current  
working directory of the entire process. We should probably remove  
the Tcl command from the interpreter.


-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Filename "Portfile" is evil

[Landon Fuller]

On Aug 22, 2007, at 13:29, Ryan Schmidt wrote:

Since we're already on the topic of changes to the dports dir (see  
"Categories are evil"), I'd like to propose that having 4000+ files  
named "Portfile" is evil, too.


In Mac OS X, I can associate files with applications based on the  
filename's extension. Filenames that have no extension cannot be  
associated with an application. Therefore, I can never double-click  
a Portfile and have it open into my preferred text editor; it  
always opens into the awful TextEdit. I want to be able to  
configure it to open in TextWrangler. Currently, I'm forced to  
either laboriously drag the Portfile to the TextWrangler icon, or  
type "port edit " in the Terminal, which is what I  
usually do. But being able to double-click in the Finder would be  
nice.


Also, editors like TextWrangler will do syntax highlighting of  
files, based on the filename extension. Since Portfiles have no  
extension, no syntax highlighting is provided.


Finally, it's also inconvenient that every Portfile's name is  
"Portfile". It makes them harder to distinguish them when several  
are open in the editor. Related: when I've downloaded a file  
"Portfile.diff" that someone has attached to a Trac ticket, and if  
I'm working with several tickets at once, I often forget which  
portfile the patch was meant for.


==> What if we used the name of the port, with an extension, like  
"apache2.macport"? I feel this would solve many problems at once.


(I was initially going to suggest the extension ".tcl" but the tcl  
syntax highlighting in TextWrangler is highlighting various words  
in port descriptions and such which we don't want, and which would  
probably get annoying.)


I always wanted ports to be bundles, so I think anything down this  
road is probably a good idea.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Categories are evil

[Landon Fuller]

On Aug 22, 2007, at 07:13, Daniel J. Luke wrote:


On Aug 22, 2007, at 5:34 AM, Randall Wood wrote:
Well, no, not really. Its just that I think that they are a really  
bad way to physically organize the ports collection.


why?

I understand that categories are an important and useful tool for  
organizing and grouping ports, but when thinking about a GUI for  
the MacPorts system, I realized that categories should best be  
thought of as a set of semi-standardized keywords which any  
mechanism for searching for ports should recognize. I have also  
been long bugged by the need to decide which category is the  
primary category for a port when placing it in the ports collection.


there's nothing that forces the gui to adopt a display that mirrors  
the physical (on disk) layout of the ports.


The current categories are there so that humans can browse the  
ports directory and see related ports somewhat grouped together.


Indeed. Why complicate things with weird sub-directories? If you  
really don't want an on-disk port heirarchy (understandable), then we  
could just stick them all in one directory. It's a flat namespace,  
after all.
Honestly, though, this sounds like more change for the sake of  
change. Is there a technical advantage to changing the implementation?


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [28060] trunk/dports/archivers/sharutils/Portfile

[Landon Fuller]

On Aug 20, 2007, at 8:17 AM, Rainer Müller wrote:


Daniel J. Luke wrote:

It makes sense to include NLS support by default in most ports.


I would like +nls variants, so people who want localized software  
could

enable this in variants.conf.


I don't see any advantage to adding complexity here. I believe we  
should write something like this up in the guide:
	The default installation of the software should be as feature  
complete, out of the box, as is possible. Variants should only be  
used for enabling incompatible options, or *expensive* features that  
most individuals will not need.

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: moving "macports1.0" to ${prefix}

[Landon Fuller]

On Aug 16, 2007, at 12:10, Blair Zajac wrote:

I'm just trying to get a sense of what we're talking about here,  
as we're discussing trade offs between competing concerns.

OK, then I'll simplify.
Arguments For Moving:
Developers can install multiple versions without passing -- 
with-tclpackage to configure (but they still have to pass a custom  
--prefix to configure)

Arguments Against Moving:
Placing the Tcl package in the standard Tcl package directory  
means that external tools can find the system MacPorts library out  
of the box.
It seems to me like developers already have an easily solution to  
their problem.

-landonf


I got these points.

Can you address the rest of the questions I asked in the previous  
note?  That'll provide more context to make a choice.


How many tools are out there?  I haven't used any of them, what are  
their names?


Don't know. How many tools and custom code out there uses zlib?

The choice was originally made to support the GUI PortsManager app. I  
think it was a good choice.


How does that third party software even work if I do a --with- 
tclpackage?  Does it break?


It would break unless the author endeavoured to support your non- 
standard Tcl package installation.


What about getting the third-party software to work with multiple  
MacPorts installs?  How does that work?


See answer above.

It sounds like the third-party software should grow support to  
handle multiple MacPorts installs and the ability to point it at  
the root of an install and be able to find the TCL files it needs.


Except that nobody, other than developers, will be running multiple  
MacPorts installations. You're taking a simple fix to a simple problem:
	- Install MacPorts in the standard Tcl library directory, where  
external software can access it.


And proposing a complex fix for a non-existent problem:
	Developers don't have to type an extra --with-tclpackage, and users  
have to set MACPORTS_HOME and tell any external software where to  
find the MacPorts installation


I hold that this is an entirely aesthetically-driven bike shed.  
Unless there's a *really good reason* to change something, why don't  
we just leave it, and the original logic behind it, alone?


Right now with --with-tclpackage, if everybody puts them into their  
own path under $prefix, then there's almost no hope for the third- 
party software.  If we standardize on a location in $prefix, then  
the user can point the software at a MacPorts install and except it  
to work.


So one remaining issue is how to get the third-party software to  
easily pick up the TCL files from a MacPorts install.  It could  
check for a default location in /opt/local.  Maybe use an  
environmental variable MACPORTS_HOME.


Setting environmental variables in the GUI is beyond the scope of  
most user's needs.


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: moving "macports1.0" to ${prefix}

[Landon Fuller]

On Aug 16, 2007, at 11:10, Blair Zajac wrote:


Landon Fuller wrote:

On Aug 16, 2007, at 10:55, Blair Zajac wrote:

Landon Fuller wrote:

On Aug 16, 2007, at 02:15, Anders F Björklund wrote:


For MacPorts 1.6, it might be a good idea to consider moving  
"macports1.0" from the current @TCL_PACKAGE_DIR@ directory to  
the @prefix_expanded@/share/macports/Tcl directory, in order to  
make the MacPorts installation self-contained within the  
designated prefix ?


If the "macports1.0" module needs to be in the system's Tcl  
package directory in order for other (inferior) software to  
find it, then can't this be accomplished by setting up a  
symbolic link ? e.g. /Library/Tcl/macports1.0 -> /opt/local/ 
share/macports/Tcl/macports1.0
I'll register a "please, no!". The whole point of putting  
macports in /Library/Tcl/macports1.0 was to support "inferior"  
software that needs to be able to find the system's macports  
installation, regardless of ${prefix}.


What software is this?
Any third party tool that rightfully expects "package require  
macports" to work.


I'm just trying to get a sense of what we're talking about here, as  
we're discussing trade offs between competing concerns.


OK, then I'll simplify.

Arguments For Moving:
	Developers can install multiple versions without passing --with- 
tclpackage to configure (but they still have to pass a custom -- 
prefix to configure)


Arguments Against Moving:
	Placing the Tcl package in the standard Tcl package directory means  
that external tools can find the system MacPorts library out of the box.


It seems to me like developers already have an easily solution to  
their problem.


-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: moving "macports1.0" to ${prefix}

[Landon Fuller]

On Aug 16, 2007, at 10:55, Blair Zajac wrote:


Landon Fuller wrote:

On Aug 16, 2007, at 02:15, Anders F Björklund wrote:


For MacPorts 1.6, it might be a good idea to consider moving  
"macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the  
@prefix_expanded@/share/macports/Tcl directory, in order to make  
the MacPorts installation self-contained within the designated  
prefix ?


If the "macports1.0" module needs to be in the system's Tcl  
package directory in order for other (inferior) software to find  
it, then can't this be accomplished by setting up a symbolic  
link ? e.g. /Library/Tcl/macports1.0 -> /opt/local/share/macports/ 
Tcl/macports1.0
I'll register a "please, no!". The whole point of putting macports  
in /Library/Tcl/macports1.0 was to support "inferior" software  
that needs to be able to find the system's macports installation,  
regardless of ${prefix}.


What software is this?


Any third party tool that rightfully expects "package require  
macports" to work.



The use case for having multiple MacPorts is fairly common.


Amongst developers. Not users. Most users have one installation of  
MacPorts.




We have three +1's for making the change.  Should we have a vote?


Because direct democracy is the best method for making technical  
decisions?


-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: moving "macports1.0" to ${prefix}

[Landon Fuller]

On Aug 16, 2007, at 02:15, Anders F Björklund wrote:



For MacPorts 1.6, it might be a good idea to consider moving  
"macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the  
@prefix_expanded@/share/macports/Tcl directory, in order to make  
the MacPorts installation self-contained within the designated  
prefix ?


If the "macports1.0" module needs to be in the system's Tcl package  
directory in order for other (inferior) software to find it, then  
can't this be accomplished by setting up a symbolic link ? e.g. / 
Library/Tcl/macports1.0 -> /opt/local/share/macports/Tcl/macports1.0


I'll register a "please, no!". The whole point of putting macports  
in /Library/Tcl/macports1.0 was to support "inferior" software that  
needs to be able to find the system's macports installation,  
regardless of ${prefix}.


There's always --with-tclpackage, so people can do this manually if  
they need to.


-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Using CVS [was Re: Cvs variant in portfile]

[Landon Fuller]

On Aug 13, 2007, at 17:05, N_Ox wrote:



Le 14 août 07 à 01:49, Landon Fuller a écrit :



On Aug 10, 2007, at 18:17, Ryan Schmidt wrote:

 I'm trying to figure out why you don't just fetch from CVS all  
the time


Why do we allow fetching from CVS in the standard ports tree?  
There's no way to validate the downloaded files (ie, checksums),  
and it's completely non-deterministic.




You're quite right about the checksums, but the policy is to never  
export trunk but use specific revision numbers, so we are pretty  
sure we always fetch the same thing.


Given that, the export should just be tar'd up and placed somewhere  
for download -- then checksums can be checked.


-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Using CVS [was Re: Cvs variant in portfile]

[Landon Fuller]

On Aug 10, 2007, at 18:17, Ryan Schmidt wrote:

 I'm trying to figure out why you don't just fetch from CVS all the  
time


Why do we allow fetching from CVS in the standard ports tree? There's  
no way to validate the downloaded files (ie, checksums), and it's  
completely non-deterministic.


-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: mtree violations should be debug info, should not be fatal errors

[Landon Fuller]

On Aug 12, 2007, at 15:08, Weissmann Markus wrote:


Just before this one gets a stopper for a lot of ports:
Juan will look into doing a 1.5.2 (or whatever) release which  
includes the fix for the "/Applications" bug and also turns the  
violation errors into non-fatal warnings (for now). I should have  
done it this way from the start, to let us do some cleaning before  
the fist of quality assurance hits our ports.


I think having a whitelist is always going to be troublesome. Take  
cross-compilers: The standard layout for a cross-compiler toolchain  
on all systems is:

${prefix}/
eg:
${prefix}/arm-apple-darwin

It seems like it would make much more sense to use a blacklist that  
catches common errors, rather than a whitelist that catches anything  
that can't be easily pre-defined.


-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: MacPorts should require the latest Xcode

[Landon Fuller]

On Jul 29, 2007, at 17:21, Blair Zajac wrote:



On Jul 29, 2007, at 4:11 PM, Ryan Schmidt wrote:


Here's a message from the -users list just now:

On Jul 28, 2007, at 18:39, Chris Waterson wrote:

Hey, I had the same problem.  It turns out I was using an older  
version of Xtools (specifically, version 2.3).  After upgrading  
to Xtools 2.4.1, things worked fine.  (The specific trouble,  
which you can see if you get rid of the "-j2" option in the  
makefile, is that they've changed some of the defines in the  
header files that the boehm-gc needs.)


Problems caused by old Xcode versions are reported by users with  
some regularity. I suppose we could add something to the FAQ, but  
users don't always read the FAQ, and the first step of the first  
section of the installation guide already reads: "Download and  
install the latest version of Xcode Tools—do not install an older  
version from the OS X 10.4 install disk or some ports may fail to  
install."


We should not allow users to run into this problem. Can we please  
modify MacPorts base to issue a fatal error and refuse to do  
anything unless the latest Xcode (2.4.1 on 10.4.x, 1.5.x on  
10.3.x) is installed? I think this would be a good idea. When new  
versions of Xcode are released, we can update base as needed.


+1.


Tentative -1, simply because Xcode is a massive download. Most things  
will build with an outdated version, I don't think it's particularly  
nice to force people to download a gigabyte update if they don't need  
and/or want to. Also, we shouldn't try to second guess people who do  
know what they're doing with an "unsupported" Xcode version.


-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: SoC: current status (Elias Pipping)

[Landon Fuller]

On Jul 23, 2007, at 02:09, Elias Pipping wrote:


I chose a separate repository (and wiki) for a number of reasons:

 * I do not like working with Trac (contrary to ViewVC and DokuWiki -
   If I had needed a bug tracker I would have set up BugZilla, too)
 * I did not want to spam MacPorts-Changes with my commits to merge.rb
   needlessly.
 * A separate repository makes it very easy, regarding the SoC, to say
   what I wrote - maybe it was easy already, but now it's trivial.


This looks neat, but seems to be an independent set of scripts,  
rather than anything integral (or intended to be integral) to MacPorts:

- You used a different language
- You used a different license
- You used a different source repository and wiki

Which doesn't sound very integrated =)

-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [27155] trunk/dports/python/py-psyco/Portfile

[Landon Fuller]

[from the correct e-mail address, this time]

On Jul 22, 2007, at 1:10 PM, Rainer Müller wrote:


Ryan Schmidt wrote:

You may also wish to check for compatible architecture in a different
way. Your way currently handles only on Intel Mac OS X, but  
according to

the project's web site, it works on any OS so long as it's the _86
architecture. Consider doing it the way I've done it in the wine  
port:


http://trac.macosforge.org/projects/macports/browser/trunk/dports/ 
x11/wine/Portfile

I see no reason why checking for darwin i386 could be wrong. Do we
really need to take care of other Operating Systems than Mac OS X? I
mean, it's called MacPorts now and is targeted on users of Mac OS  
X. Who

is using it on another system?


That's no reason to -intentionally- box yourself (or others) into a  
corner. The requirement is for 'x86', not for darwin, and as such,  
expressing a much broader dependency is incorrect.


-landonf



PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Base Enhancements

[Landon Fuller]

On Jul 16, 2007, at 20:03, Chris Pickel wrote:


Hi all,



12309 [1] - Currently we use sed to do some replacement in port,  
portindex, and portmirror. I think autoconf is better suited to this.


Using make for this purpose ensures that the scripts are re-built  
when their source is updated. See:
http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_mono/ 
autoconf.html#SEC24


12310 [2] - Right now we detect some libraries (curl, readline,  
etc.) and then we link them all into every dylib we compile. This  
patch slims it down so that decisions can be made separately for  
each dylib.


Looks good to me, although CFLAGS should probably be broken out too

12311 [3] - On the same note as my previous post to -dev about  
macports_fastload.tcl. This is a fix for the version comparison  
problem.


Paul should comment on this one.

12312 [4] - Several manpages reference paths according to  
variables, rather than giving the actual path; we can do the latter  
and that's more helpful to users.


Sweet, although I think this should still be done with Makefile  
substitution, as per above =)


-landonf


[1] http://trac.macports.org/projects/macports/ticket/12309
[2] http://trac.macports.org/projects/macports/ticket/12310
[3] http://trac.macports.org/projects/macports/ticket/12311
[4] http://trac.macports.org/projects/macports/ticket/12312

The only one I have a strong attachment to is 12310, but I feel the  
others are improvements too.


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: defluffing Portfiles (port lint)

[Landon Fuller]

On Jul 10, 2007, at 05:47, Anders F Björklund wrote:


Apparently one of the oldest feature requests around...
http://trac.macports.org/projects/macports/ticket/463

I created a basic implementation, for later expansion:
http://trac.macports.org/projects/macports/ticket/12211


I guess there will be NO feedback on this until it has
been committed to trunk, so maybe we can do that now ?


My only question is this:

78  proc lint_main {args} {
79  global UI_PREFIX portname portpath
80  set portfile ${portpath}/Portfile

It's inadvisable to make assumptions about the Portfile path from  
within a target -- should this be implemented outside of the build  
targets?


-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: 1.5 rc1 tag created ([26762] tags/release_1_5_0-rc1/)

[Landon Fuller]

On Jul 6, 2007, at 3:20 PM, Anders F Björklund wrote:


Juan Manuel Palacios wrote:


I will wait for two more things:

1) final word on http://trac.macports.org/projects/macports/ticket/ 
12231, whether that's a final solution to the issue or just an  
advice to leave it out of the release for the time being;

2) final word on whether or not I should merge Anders' r26737.


Main reason for #12231 is coping with selfupdate and ./configure.
It works from the BSD port anyway, since that sets all arguments.


If you're considering FreeBSD support, it should also be noted that
configure currently assumes bash and the makefiles assumes gnumake...

This means that "selfupdate" might not work out-of-the-box on systems
where /bin/sh is some other shell and make is some other make (bsd) ?

I think the very latest version of FreeBSD's sh is OK to use now
(or one could edit configure to say /bin/bash), and using gmake
instead of make will call FreeBSD's gnumake instead of bsdmake
(the errors are due to GNU-make constructs like ifeq/ifneq...)

If you want to address this portability problem, you can test
with "./configure && bsdmake" - or you can just demand GNU make ?


The Makefiles used to be BSD make compatible. If configure &&  
makefiles are incompatible with non-GNU tools, I'd consider that a bug.

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Q: variants specified in dependencies

[Landon Fuller]

On Jul 5, 2007, at 05:19, Jyrki Wahlstedt wrote:

I remember there has been discussion about this, i.e. variants  
specified in dependencies. I wonder what the current status is, as  
I noticed the ticket about this (#126, the oldest one open, I  
believe) was milestoned to 1.5. At least in one earlier discussion  
there were objections to do this due to the difficulty in  
implementing, but I would like to see this, e.g. because mpkg is  
based on very short trial useless without this capability (and mpkg  
is something that I could use). If this means that I should dive  
into the deep core of MacPorts, I would be willing to give it a try.


My own (potentially unpopular) opinion is that this is possible to  
implement and impossible to support, as it would introduce  
exponential complexity to the dependency tree.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Release 1.5 branch created

[Landon Fuller]

On Jul 4, 2007, at 03:00, Anders F Björklund wrote:


http://trac.macports.org/projects/macports/ticket/12168


Patch committed to trunk


http://trac.macports.org/projects/macports/ticket/12173


Outside of my immediate jurisdiction.


http://trac.macports.org/projects/macports/ticket/12212


I -think- the right solution for this is to use -fconstant-string- 
class=NSConstantString for GNUstep. As a start, check out the  
OD_OBJC_NSCONSTANTSTRING macro I wrote here:
	http://svn.sourceforge.net/viewvc/substrate/trunk/aclocal.m4? 
revision=283&view=markup



http://trac.macports.org/projects/macports/ticket/12225


Patch committed to trunk.


http://trac.macports.org/projects/macports/ticket/12230


I added a new pthread macro, committed to trunk.


http://trac.macports.org/projects/macports/ticket/12231


Personally I'm in favor of just using --with-tcl-sqlite3, but I could  
be swayed either way.


I'll look into merging these changes into the 1.5 release branch,  
assuming nobody objects.
Also, do you have a commit bit for base? (Do we still separate base/  
and dports/ ?). If not, you probably should =)


-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: ports with bootstrapping dependencies

[Landon Fuller]

On Jun 29, 2007, at 11:22 PM, Ryan Schmidt wrote:



On Jun 29, 2007, at 13:33, Landon Fuller wrote:


On Jun 26, 2007, at 11:39 PM, Ryan Schmidt wrote:


On Jun 25, 2007, at 09:46, Taylor R Campbell wrote:


There was some recent
discussion about a `ui_fatal' command by which to fail, although I
understand that it was simply a proposal not yet implemented.  Does
this sound plausible, however?


Not really needed, though, either. Just do ui_error "the message"  
followed by exit 1. And, again, do this in the pre-fetch phase.


Calling "exit" from a Portfile will cause any front-end using the  
dports API to exit, no? That seems bad form.


I was under the impression that doing this within the pre-fetch  
phase was acceptable. I thought we discussed this on the list  
earlier. Many ports do this: xorg, wine, mozilla, sockstat, ipcs,  
gauche-gtk, mysql5-devel, TeXShop.


It will still cause the entire front-end to exit, rather than  
throwing an error in the port sub-interpreter. It's the equivalent of  
a library calling abort() instead of returning an error code.


If that's not ok, then we really do need someone to implement  
ui_fatal. But what would that do differently?


return -code error "An error, here"

It's still not perfect, in that it's simply not declarative -- how do  
I determine whether a port can run on my system ? Execute the fetch  
phase.

However, It's still better than exit.

There are some ports that still do it directly in a platform  
selector: xloops, nestedsums, cln, GiNaC, hugs98, ghc, klisp,  
kdelibs3. I can see how that's indeed wrong and needs to be changed.


I'm surprised at the extent of the usage.

-landonf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: ports with bootstrapping dependencies

[Landon Fuller]

On Jun 26, 2007, at 11:39 PM, Ryan Schmidt wrote:



On Jun 25, 2007, at 09:46, Taylor R Campbell wrote:


Actually, it occurs to me that it's not really necessary to declare a
dependency -- that it would suffice for the variant to have a command
that checks for the existence of an executable by some name, and to
refuse to continue if this command fails.


I haven't really followed why all this complexity with the multiple  
scheme ports is required -- I realize you tried to spell it out in  
your first email but it was a bit much for me at the moment.


But assuming it really is required, then yes, this is the method  
that occurred to me as well: just test for the file's existence in,  
say, the pre-fetch phase, and fail if not found. I don't, however,  
know the portfile syntax for checking for a file's existence.



There was some recent
discussion about a `ui_fatal' command by which to fail, although I
understand that it was simply a proposal not yet implemented.  Does
this sound plausible, however?


Not really needed, though, either. Just do ui_error "the message"  
followed by exit 1. And, again, do this in the pre-fetch phase.


Calling "exit" from a Portfile will cause any front-end using the  
dports API to exit, no? That seems bad form.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [26399] trunk/dports/math/nestedsums/Portfile

[Landon Fuller]

On Jun 21, 2007, at 02:45, Ryan Schmidt wrote:



On Jun 21, 2007, at 04:31, Ryan Schmidt wrote:

But could you please not output messages and exit merely in a  
platform statement? Please do so only within a stage such as pre- 
fetch, e.g.:


platfrom darwin 7 {
pre-fetch {
ui_msg "GiNaC is not supported on Panther (OS X 10.3.x)."
exit 1
}
}

Otherwise, people running port info, portindex, etc. on darwin 7  
will be inconvenienced by the exit.


Sorry; I didn't see Chris already made these points.


It really bears re-iterating though. Calling exit(1) in a Portfile is  
just bad news, at any stage. Maybe we should remove that procedure  
from the Portfile Tcl interpreter ...


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [24619] branches/dp2mp-move/base/src/port/port.tcl

[Landon Fuller]

On Apr 28, 2007, at 8:05 PM, Ryan Schmidt wrote:



On Apr 28, 2007, at 21:06, [EMAIL PROTECTED] wrote:


+   gohome {
+   set homepage $portinfo(homepage)
+   if { $homepage != "" } {
+		# TODO we should autoconfigure this, and perhaps leave an  
option for

+   # a different command to visit 
the homepage
+   system "/usr/bin/open $homepage"
+   } else {
+   puts "(no homepage)"
+   }
+   }


Nah, I would say we don't need any options here. /usr/bin/open will  
open the homepage with the default web browser. That's perfectly  
reasonable for this use.


Except that this sort of thing shouldn't be hard-coded in the source  
-- I'd suggest autoconf'ing it for that reason alone.


Of course, there's always
port cat dict | grep ^homepage | awk '{print $2}' | xargs open

Encoded in a handy zsh function as:
	porthomepage () { port cat $==* | grep ^homepage | awk '{print $2}'  
| xargs open }


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Portfile authors: pay attention to keywords, eol-style, Id

[Landon Fuller]

On Apr 17, 2007, at 14:33, Ryan Schmidt wrote:



On Apr 17, 2007, at 16:19, Landon Fuller wrote:

I once said I would work on a pre-commit hook script we could  
install which would reject any commit that did not conform with  
these requirements. I haven't gotten around to that yet, but I  
haven't forgotten either.


If we're going to be nazis, can the pre-commit hook just set this  
stuff magically? Or can we stop being nazis about it?


The pre-commit hook can only verify the transaction and either  
accept or reject it; it cannot modify the transaction.


I think these are useful conventions to enforce, so I will work on  
a pre-commit hook to enforce this.


I'm apathetically opposed -- I don't care about $Id$ tags in my  
Portfiles, or native line breaks. If there was a way to do this  
automatically I'd be all in favor, but enforcement rubs me the wrong  
way.


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Portfile authors: pay attention to keywords, eol-style, Id

[Landon Fuller]

On Apr 17, 2007, at 03:48, Ryan Schmidt wrote:



Portfile = svn:eol-style=native;svn:keywords=Id

For consistency and conformance with the Subversion documentation  
let's please use Id, not id, for the keyword name.


This recommendation should probably be in the documentation  
somewhere but I haven't looked yet where it might best be included.  
If someone else would add this to the wiki, or even just point out  
where in the wiki it should go, that would be appreciated.



I once said I would work on a pre-commit hook script we could  
install which would reject any commit that did not conform with  
these requirements. I haven't gotten around to that yet, but I  
haven't forgotten either.


If we're going to be nazis, can the pre-commit hook just set this  
stuff magically? Or can we stop being nazis about it?


Petulantly,
-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [24079] trunk/base/src/pextlib1.0/find.c

[Landon Fuller]

On Apr 16, 2007, at 10:30 PM, Kevin Ballard wrote:

Yeah, I know, but the fact of the matter was nobody used find, and  
I mean nobody. And the other part is that, in general, it's far  
more conducive to stop thinking of code as "my code" or "his code"  
and to think of it simply as project code. Sure, you wrote it, but  
in the end does that matter? Discussion should be about the merits  
of the code, not about ownership.


There are reasons beyond ego of ownership -- the author is going to  
generally be able to provide the greatest insight into design  
decisions and implementation. "My code" and "his code" are very real  
constructs in this context, and the authorship does matter. When you  
make a significant unilateral change to an existing contributor's  
code without consultation, this may reasonably be considered a  
raucous disregard for their design and implementation choices.


At the very least, providing "change justification" demonstrates a  
full consideration of the implementation as compared to the existing  
code -- the author can then evaluate the changes according to his  
original design requirements.

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Website redesign (was Re: Please clear up DarwinPort/MacPorts confusion)

[Landon Fuller]

On Apr 9, 2007, at 02:22, Ryan Schmidt wrote:


$ cd doc/guide
$ make
xmllint --xinclude --noout "xml/guide.xml"
http://www.oasis-open.org/docbook/xml/4.2/dbpoolx.mod:99: parser  
error : Content error in the external subset



make xhtml
or make html

Try adding --nonet to the xsltproc parameters

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Website redesign (was Re: Please clear up DarwinPort/MacPorts confusion)

[Landon Fuller]

On Apr 9, 2007, at 10:17, [EMAIL PROTECTED] wrote:

But the disadvantage, as opposed to a Wiki, is that joe user can't  
make
changes to the docs.  And that is what people want.  Although I  
wonder if
we have Joe user contributing to the docs if it will really be  
better.  It

may be, I just don't know.


I've come across a number of projects using wiki documentation  
lately. Lacking any centralized editing, it tends to vary wildly in  
quality, substance, and style. Information is poorly organized and  
difficult to find, and documentation is often duplicated.


Maybe my experiences aren't a sufficiently representative example,  
but I've been left with a very poor impression of open source wiki  
documentation.


-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How can I determine if a function is available?

[Landon Fuller]

On Apr 9, 2007, at 12:46 AM, Ryan Schmidt wrote:


My preliminary patch for php5 is attached to this ticket:

https://trac.macosforge.org/projects/macports/ticket/8599

However I still need a fix that will let it work with either MP  
1.4.0 or trunk.


Also would like advice regarding any ways to reduce the size of the  
patch. I'm concerned about the duplication of the apache, apache2  
and fastcgi options. You'll see what I mean if you look in the  
patch...


Is there any way to do this by patching php5's build system? That was  
the simple fix for the zlib port.

command/command_exec/et al should probably remain internal API.

-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [23720] trunk/base/src/pextlib1.0/Pextlib.c

[Landon Fuller]

On Apr 7, 2007, at 5:10 PM, Jordan K. Hubbard wrote:

Actually, Apple has always traditionally reserved uids < 500 for  
its own use.  We simply haven't passed 100 yet. :-)


- Jordan

On Apr 7, 2007, at 11:52 AM, [EMAIL PROTECTED] wrote:

nextuid and nextgid now return the first uid/gid > 100 rather than  
the max + 1
This means that new users created with adduser are not visible on  
the login screen.
Also it was kinda silly to create a new user/group with id 502  
when 100-499 were available

Simple patch, fixed here:
http://trac.macports.org/projects/macports/changeset/23770#file3

-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Uninstall an obsolete from another (conflicting) port

[Landon Fuller]

On Apr 4, 2007, at 04:21, Yves de Champlain wrote:



Le 07-04-04 à 04:30, Randall Wood a écrit :


What's the best way to do this?

I have seen calls in ports doing this in the past like:

pre-install {
system "port -f uninstall xxx"
}

Which is not really the way to do it. Clearly the best way would  
be loop the list of versions of the port and uninstall each one  
using the MacPorts API, but given the state of the docs...


IMHO, this should be avoided as much as possible.

But if you got to do it, deactivate should just work.


There's no real safe way to do this without implementing 'conflicts'  
and 'replaces' support of some kind. The propagation of recursive  
calls to port as a work-around is unfortunate, as it's really not a  
safe thing to be doing -- there are no guarantees regarding system  
concurrency/re-entrancy.


-landonf

PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: portindex -a

[Landon Fuller]

On Apr 4, 2007, at 01:49, Randall Wood wrote:

Are there any mechanisms in place to take advantage of the  
portindex -a option?


Or if I have a collection of the archives created with that option  
how would I use them?


I implemented the -a option and HTTP port archive fetching in 2002,  
but it was never used -- I can't recall why.
Presumably it should still work; simply add an http URL to the  
sources.conf that points to a generated "archive" ports tree.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [23439] trunk/dports/archivers/zlib/Portfile

[Landon Fuller]

On Apr 1, 2007, at 11:34 AM, Landon Fuller wrote:



On Apr 1, 2007, at 10:43 AM, Ryan Schmidt wrote:



zlib +universal worked fine in MP 1.3.2 until the portfile was  
declared to be too ugly and got totally rewritten... I'll have  
more to say about that in a moment.


No, it did not.

The port broke because the 'command' private API was used. Period.  
I rewrote the port to remove the private APIs, which disabled the  
obviously experimental universal support.


And in case it's not clear, the port functioned correctly afterwards.

I didn't test pipping's new universal support because I didn't  
write (or commit) the universal support.


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [23439] trunk/dports/archivers/zlib/Portfile

[Landon Fuller]

On Apr 1, 2007, at 10:43 AM, Ryan Schmidt wrote:



zlib +universal worked fine in MP 1.3.2 until the portfile was  
declared to be too ugly and got totally rewritten... I'll have more  
to say about that in a moment.


No, it did not.

The port broke because the 'command' private API was used. Period. I  
rewrote the port to remove the private APIs, which disabled the  
obviously experimental universal support.


I didn't test pipping's new universal support because I didn't write  
(or commit) the universal support.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Hacking in Universal -- Don't!

[Landon Fuller]

On Mar 31, 2007, at 2:38 PM, Jordan K. Hubbard wrote:


Which private API are you referring to?

I know that the port was *broken* until I changed it to use the  
right command API, but that had nothing to do with building  
universal, that was a very hacky way of building the static archive.


http://trac.macports.org/projects/macports/changeset/22776

Specifically, the use of "command" -- which is undocumented and  
subject to change (it changed, as you noted when you fixed the port).


The static library support someone added some time ago was also  
pretty nasty, no doubt about that.


I implemented a two-line patch to clean up the static library  
building, and pipping implemented a similar patch for Universal. The  
port practically gleams, now:
	http://trac.macports.org/projects/macports/browser/trunk/dports/ 
archivers/zlib/Portfile?rev=23429



Of course, it'd be nice to be able to use variant universal { }  
instead of variant_isset, but you can't have everything.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [23415] trunk/dports/archivers/zlib/Portfile

[Landon Fuller]

[resending from a subscribed address]

On Mar 31, 2007, at 11:56 AM, [EMAIL PROTECTED] wrote:


Eric Hall <[EMAIL PROTECTED]> on Saturday, March 31, 2007 at
11:32 AM -0800 wrote:
	There was a rule about bugs being free for anyone to fix/patch/ 
commit

after notifying the port maintainer and a 72 hour timeout.
Has that been removed, or just lost to the fog of time?
Is that a rule that people are comfortable with?


I'm comfortable with it, but the problem is that I think we have a  
large
number of maintainers listed who are no longer maintaining.  So  
while I'm
comfortable with the rule above, and it is easy enough to remember,  
if I
see 5 old bugs that I could fix in 15 minutes and I have time right  
now
but I think the probability of any response from a maintainer (let  
alone a

fast one) is very low, then will the community (and myself) be better
served by sending out emails from trac and waiting on responses and
tracking all that stuff, or just fixing them?  If it is a complex or
critial port, then I'll not touch it, but if it is a lesser used  
broken

port and/or a minor update then I might.  If I know the maintainer is
responsive then I'll definitely cc in trac and not worry about it  
after

that.  So I think the key detail is not the rule above, but that even
responsive maintainers may not be able to respond in 72 hours and  
so few

formally drop maintainership when they stop maintaining that our whole
framework of rules about committing is shaky if taken too seriously.


I agree that the 72 hour rule is stifling when you've got a small bug  
to fix, or a simple version bump. I don't think it's entirely  
inappropriate for large changes, though.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [23415] trunk/dports/archivers/zlib/Portfile

[Landon Fuller]

On Mar 31, 2007, at 11:20 AM, Mark Duling wrote:

macports-dev@lists.macosforge.org on Saturday, March 31, 2007 at  
10:25 AM

-0800 wrote:

Revision
[ http://trac.macosforge.org/projects/macports/changeset/23415 ]23415
Author
[EMAIL PROTECTED]
Date
2007-03-31 10:25:27 -0700 (Sat, 31 Mar 2007)

Log Message

Claiming ownership of my port entirely.

Are there ports where you are listed maintainer that you shouldn't  
be?  I

think to be sure someone respects your maintainership, you should make
sure that you are only listed as maintainer one ones you really  
actively
maintain.  I really wan't aware you were still active and I  
supposed there
were a bunch of ports that you used to maintain and currently  
didn't but
never formally relinquished.  For example, I just updated openldap  
days
ago and you are listed as maintainer.  But there have been 3  
verifiable

bugs filed against it for ages and the port was pretty outdated.


I'm pretty sure I'm still active =)
http://trac.macports.org/projects/macports/search?q=landonf&changeset=on

Of the three OpenLDAP bugs, the only bug actually assigned to me was  
an enhancement request. It was opened prior to trac ever sending e- 
mail, and so I never actually saw the bug. The port wasn't  
significantly outdated -- I was intentionally was tracking the 2.2.x  
branch.


That said, I saw the  bug that you filed on Wednesday, and it all  
looked fine. I had planned on addressing it this weekend, but you  
beat me to it.


In my view, MacPorts only keeps functioning because of the efforts  
of a

few that sometimes need to bend the rules with some judgement, because
there aren't enough people concerned with fixing bugs that we can
reasonably expect those people to adhere to all the rules we set  
up.  If
we had more people doing it we could more closely adhere to the  
standards
we've setup.  A bureaucratic system with few people doesn't work  
very well
when those few have to choose between getting things done for  
others and

maximizing their volunteer time.

I'm not criticizing or complaining, I'm just saying how things  
appear to
me because, frankly, I bend the rules a lot because I don't see  
another
way right now.  The project seems to have more users than it once  
did and

tickets are opened faster, but it doesn't seem like there are many
responsive maintainers so that we rely on a few consistent bug  
chasers and
committers that sometimes bend the rules to keep from getting  
swamped by

tickets.


I agree that the maintainer flag should be considered a mutex -- I  
certainly don't have time to keep tabs on updates and bugs every  
single port I maintain.


However, I do think discretion is a must -- if you're white-space  
reformatting the entire port, doubling it in length and complexity,  
and adding dependence on undocumented private functions, something is  
probably wrong -- especially when it's something like zlib, which is  
a hugely important system dependency.


-landonf


PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev