Re: 2010 the year for package builds? [was Re: Is it time to start regression testing yet?]

Yes, I think you're right. Using an AR data persistence model that shouldn't make a big difference, though. Florian On 06.01.2010, at 00:52, Joshua Root wrote: On 2010-1-6 10:38 , C. Florian Ebeling wrote: William Siegrist who looks after the other MP systems was pushing into the direction

Re: Identifying portname in a bug?

> The field was already added recently. But it is not used in older bugs. > So it would help if only anyone editing a bug would populate this field > as well. oh, yes, sorry, so I missed that and my information was stale. Florian -- Florian Ebeling [EMAIL PROTECTED] ___

Re: Identifying portname in a bug?

On Fri, Sep 12, 2008 at 3:36 PM, Jay Levitt <[EMAIL PROTECTED]> wrote: > Is there any way to search for bugs in a specific port? I think the current > answer is "no", unless the portname happens to be a usefully unique word. > I'm running into a bug building "file", and I have no idea how to searc

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

> Note that python24 does not (or at least will not, as of MacPorts 1.7.0) use > /opt/local/Library/Frameworks/Python.framework, or even > ${prefix}/Library/Frameworks/Python.framework, which is what you probably > meant. In MacPorts 1.7.0 we have a new variable ${frameworks_dir}, so it > will go i

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

>> The package wants to put the kexts into /Library/Extensions, which is >> /opt/local/Library/Extensions for us. That violates the mtree. Would >> /opt/local/lib/{tap|tun}.kext be an good place to keep them instead? > > /opt/local/Library/Extensions seems fine to me. /opt/local/Library is > alread

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

On Fri, Aug 29, 2008 at 4:18 PM, Daniel J. Luke <[EMAIL PROTECTED]> wrote: > On Aug 29, 2008, at 6:02 AM, Kevin Ballard wrote: >> >> If the kext is meant to be loaded by the system at startup, > > by IOKit matching... > >> it has to go in the System-provided folder. > > or a startup script/launchd

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

>> So one way of dealing with this would be to provide an oldfashioned >> script. But where to put that. I would be tempted to put it into >> /opt/local/init.d/, >> but there is nothing yet. > > Well, I'm not an experienced Ports developer, so I don't know what's the > rigth way. But I don't like t

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

> I would also like to see TUN/TAP drivers in MacPorts. > After a quick look on the Makefile in the git repository the Portfile should > contain: > > use_configureno > (because there is no configure) > > I'm not sure where to put the kext files. If we put it in the usual > /Library/Extensions f

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

-- Forwarded message -- From: Pierre Queinnec <[EMAIL PROTECTED]> Date: Wed, Aug 27, 2008 at 9:05 AM Subject: Re: openvpn2: "Cannot allocate TUN/TAP dev dynamically" To: MacPorts Users <[EMAIL PROTECTED]> Caspar Florian Ebeling wrote: > Is anyone using op

Re: MacPorts 1.7.0 without GSoC contributions

> Releasing something/anything would open up the experimentation again. That's my hope as well. >> That said, I can understand Ryan's worry very well. There hasn't been >> a release in ages, and if the next release cycle is as long as the >> current one, the upcoming release better be good, not b

Re: MacPorts 1.7.0 without GSoC contributions

In general I think it is not good to hold back features, they should rather be there and usable once created. That said, I can understand Ryan's worry very well. There hasn't been a release in ages, and if the next release cycle is as long as the current one, the upcoming release better be good, n

Re: Weird distfile URLs

On Fri, Aug 1, 2008 at 5:36 PM, Landon Fuller <[EMAIL PROTECTED]> wrote: > > 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 >>

Re: Weird distfile URLs

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... On Fri, Aug 1, 2008 at 9:36 AM, Ryan Schmidt <[EMAIL PROTECTED]> wrote: > On Aug 1, 2008, at 02:12, Caspar Florian Ebeling wrote

Weird distfile URLs

Is is possible to download distfiles with weird URLs like this: http://cvs.m17n.org/viewcvs/ruby/ruby-cvs.tar.gz?only_with_tag=ruby-cvs-0_2 Florian -- Florian Ebeling [EMAIL PROTECTED] ___ macports-dev mailing list macports-dev@lists.macosforge.org htt

Re: [38761] trunk/dports/devel/darcs

> On further reflection, I'm not sure that's necessary. Because if a user > needs a variant that is not available at the time, the user should file a > ticket requesting that variant, or Cc themselves on an existing ticket > requesting that variant. When the variant is added to the port, the ticket

Re: [38683] trunk/base/src/port1.0/resources/group

On Thu, Jul 31, 2008 at 9:08 AM, Ryan Schmidt <[EMAIL PROTECTED]> wrote: > On Jul 28, 2008, at 16:21, [EMAIL PROTECTED] wrote: >> Added: trunk/base/src/port1.0/resources/group/tests/ruby-1.0.tcl >> === >> --- trunk/base/src/port1.0/res

Re: [38761] trunk/dports/devel/darcs

On Thu, Jul 31, 2008 at 6:26 AM, Blair Zajac <[EMAIL PROTECTED]> wrote: > Ryan Schmidt wrote: >> On Jul 30, 2008, at 12:50, [EMAIL PROTECTED] wrote: >> >>> Revision: 38761 >>> http://trac.macosforge.org/projects/macports/changeset/38761 >>> Author: [EMAIL PROTECTED] >>> Date: 2008-0

Distfiles

I know there was a discussion about distfiles in svn lately, but I missed the central point. What is the right place to put them now, in cases where there is no suitable download location? Should they still live in svn/distfiles or elsewhere? Florian -- Florian Ebeling [EMAIL PROTECTED]

Re: [38646] trunk/doc-new/guide

On Tue, Jul 29, 2008 at 8:32 PM, Rainer Müller <[EMAIL PROTECTED]> wrote: > Rainer Müller wrote: >> >> I will try to build it completely new in a different prefix and diff the >> files afterwards to find the issue. > > Seems like I finally found the issue. > It was something in /opt/local/etc/xml/

Re: [38646] trunk/doc-new/guide

> So I uninstalled docbook-xml, docbook-xsl and libxslt. I made sure that > there are no files left in /opt/local/share/xml/docbook or > /opt/local/share/xsl. > > Then I reinstalled docbook-xml, docbook-xsl and libxslt. And it still needs > more than 11 minutes to compile the guide. > > I will try

Re: [38646] trunk/doc-new/guide

On Tue, Jul 29, 2008 at 7:15 PM, Caspar Florian Ebeling <[EMAIL PROTECTED]> wrote: > On Tue, Jul 29, 2008 at 7:09 PM, Joshua Root <[EMAIL PROTECTED]> wrote: >> Caspar Florian Ebeling wrote: >>> >>> So am I. That's when I whish I had strace on macs as

Re: [38646] trunk/doc-new/guide

On Tue, Jul 29, 2008 at 7:09 PM, Joshua Root <[EMAIL PROTECTED]> wrote: > Caspar Florian Ebeling wrote: >> >> So am I. That's when I whish I had strace on macs as well... > > Are you aware of dtruss (10.5) and ktrace (earlier)? yeah, only for dtrace I need to l

Re: [38646] trunk/doc-new/guide

>>> Building the guide with docbook takes very long in my opinion. There is >>> also >>> a quicker 'make validate' which just checks for syntax errors before >>> building. >> >> make guide takes 6.5 seconds on my machine, which is quick enough for me, >> but the make validate takes only 2, so for j

Re: [38646] trunk/doc-new/guide

>> make guide takes 6.5 seconds on my machine, which is quick enough >> for me, >> but the make validate takes only 2, so for just verifying while >> editing this is >> even better, of course. >> > > If it takes significantly longer than this for anyone, check to see if > you have XML_CATALOG_FILES

Re: [38646] trunk/doc-new/guide

>>> Thanks for catching that. Is there some script I'm meant to run before >>> committing changes to the documentation, to make sure I'm not breaking >>> something? >> >> Just do a "make guide" or "make guide-chunked" in doc-new/. If it runs >> without errors it should be ok, but you can visually c

Re: [38646] trunk/doc-new/guide

> Thanks for catching that. Is there some script I'm meant to run before > committing changes to the documentation, to make sure I'm not breaking > something? Just do a "make guide" or "make guide-chunked" in doc-new/. If it runs without errors it should be ok, but you can visually check in the su

Re: [38646] trunk/doc-new/guide

This change broke the build. Fixed it in r38687. On Sun, Jul 27, 2008 at 6:37 AM, <[EMAIL PROTECTED]> wrote: > Revision 38646 Author [EMAIL PROTECTED] Date 2008-07-26 21:37:31 -0700 > (Sat, 26 Jul 2008) > > Log Message > > Our Trac now shows a text box instead of a menu of ticket assignees; updat

Re: erlang category

> software based on it. Though about yaws: > > $ port search yaws > yaws @1.76 (www) > Webserver for dynamic content written in Erlang Hm. I don't know what i have been looking at yesterday. Thanks for catching that. -- Florian Ebeling [EMAIL PROTECTED] _

erlang category

Hi, I want to add the erlang web server yaws as a port and I wonder if it makes sense to create a new priamary category "erlang" for this. In fact I think so because I see an increase in interest in this platform in general. The New Committers Guide in the wiki says such a thing needs approval. Sh

rb-criteria

While looking a bit closer at all the broken ruby ports which my regression testing turned up, I encountered some real cruft. Some of the libraries are really quite abandoned, like Criteria. This particular one has no active web site any longer, and can only be found on mirror servers. The unit tes

Re: [34218] trunk/dports/lang

>>> Please don't use the "cd" command. It does not exist in MacPorts >>> trunk and will not exist in MacPorts 1.7.0 and later. >> >> What is the whole story to this change? Does "cd" work in 1.6 but >> not in trunk? Why was it necessary and is no longer? Is this documented >> somewhere maybe? Just

Re: [34218] trunk/dports/lang

On Mon, Feb 18, 2008 at 11:48 AM, Ryan Schmidt <[EMAIL PROTECTED]> wrote: > On Feb 18, 2008, at 03:13, [EMAIL PROTECTED] wrote: >> +post-destroot { >> + cd ${destroot}${prefix} > > Please don't use the "cd" command. It does not exist in MacPorts > trunk and will not exist in MacPorts 1.7.0 and lat

Re: Ruby ports and 1.9

> It's a very interesting plan! > But I think that is better to separate rb-* and rb19-* for some reasons. > > * Ruby 1.9 is not stable version. I think 1.8 is still needed > for daily work on 1.9 installed environment. > * So, it is important we can install, upgrade, uninstall rb-* and rb19-* >

Re: Ruby ports and 1.9

>>> I have other issues myself. It is not entirely convincing to install >>> ruby libraries >>> via a generic package manager like mp, given that ruby has it's own in >>> the >>> form of Rubygems, which even comes builtin with 1.9. >> >> The same thing applies to Perl. There is CPAN which distribut

Re: Ticket resolved status

On Tue, Jul 8, 2008 at 11:46 PM, Ryan Schmidt <[EMAIL PROTECTED]> wrote: > When closing a ticket in Trac, I can select from the following > resolutions: > > fixed > invalid > wontfix > duplicate > worksforme > > More often than I would like, I find myself unsure which to select. > > The Guide does

Ruby ports and 1.9

Hi, Yesterday, I have put a patch for ruby group into the trac, which changes the ruby.setup command so that it accepts an additional parameter. With it applied ports for ruby19 can be installed using the port group. These would get a prefix of rb19 instead of rb, following the python example. Fin

Re: [MacPorts] #15891: Undefined symbols: _xmlTextReaderSchemaValidate _xmlTextReaderSchemaValidate

>> I am now running without the DYLD_LIBRARY_PATH changed for MAMP and >> MacPorts and it all works. >> >> I guess the moral of the story is to keep the .profile as clean as >> possible. >> >> And I will probably move from MAMP to MacPorts too. >> >> But it all works at the moment so I am reluctant

Re: lang/ruby: ignore minor system version for archdir, like Apple's Ruby

Hi Kimuraw, welcome from my side as well! > I'm planning to change the Portfile of lang/ruby to ignore minor > system version for "archdir", like Apple's Ruby. > > Ruby uses "archdir" to define install destination of extension > modules, such as "RMagick.bundle". I think it is not convenient > to

Re: Ticket #15563 - can someone verify this?

> I submitted this ticket two weeks ago, it is an update to the groovy > port --- moves it from version 1.0 to 1.5.6. > > Could a committer please take a look at this? Thanks. I had a look at it and updated the ticket. It didn't build successfully because of Antlr not being in the view (or classpa

Re: doc and doc-new in svn

> Quick question: in macports svn, is doc obsolete and only doc-new in > use anylonger? I would say yes. As you can see in the repository browser [1] doc >>hasn't gotten any commits in 9 months, which is when doc-new was created. >>> >>> so should we maybe get rid of it? >> >>+1,

Re: doc and doc-new in svn

>> Quick question: in macports svn, is doc obsolete and only doc-new in >> use anylonger? > > I would say yes. As you can see in the repository browser [1] doc hasn't > gotten any commits in 9 months, which is when doc-new was created. so should we maybe get rid of it? -- Florian Ebeling [EMAIL

Error __THE_PROCESS_HAS_FORKED... in test case for pextlib, idea anyone?

I'm playing with the commands from pextlib in plain small test-case like scripts to figure out things. I ran across an odd error message I don't really understand. The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on __THE_PROCESS_HAS_FORKE

Re: documentation of pextlib1.0 commands

Is there documentation of the mp-specific commands somewhere, that I overlooked? Things like "system"? >> >> I think this should be documented in this section in the guide, but it is >> not. >> >> >> MacPorts adds its own commands for

doc and doc-new in svn

Quick question: in macports svn, is doc obsolete and only doc-new in use anylonger? Florian -- Florian Ebeling [EMAIL PROTECTED] ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-d

Re: documentation of pextlib1.0 commands

>>> Is there documentation of the mp-specific commands >>> somewhere, that I overlooked? Things like "system"? >>> I found the definition in macports/base/src/pextlib1.0/Pextlib.c, >>> eventually, but it is still a bit uncomfortable. In this case e.g. >>> I wanted to see if it returns output from s

documentation of pextlib1.0 commands

Is there documentation of the mp-specific commands somewhere, that I overlooked? Things like "system"? I found the definition in macports/base/src/pextlib1.0/Pextlib.c, eventually, but it is still a bit uncomfortable. In this case e.g. I wanted to see if it returns output from stdout and exit code.

Re: Merging to the release_1_6 branch

> I think the amount of work to use a branch is overestimated. It's not hard > and > very easy and safer then having everything in trunk and then having to do code > freezes. I think the amount of time passed since the 1.6.0 release and the amount of time since 1.6.1 is vaporware, combined with

Re: Ruby 1.9 port

>> And this "not production-ready" is not clear either. My webhoster provides >> 1.9 >> in the standard basic web plan already. Of course, Matz has not announced >> it to be stable release, but it is features-frozen quite a while. > > Right, that's more what I meant. It's not supposed to be a drop

Re: Ruby 1.9 port

>>> * Name: I tend to call it ruby19. Another option would be ruby-devel, >>> but 1.9 is mildly incompatible, >> >> I'd say more than mildly! And 1.9.0, at least, is explicitly NOT >> production-ready. ruby19 sounds logical. >> >> I don't know if there's a naming standard on macports, but "-dev"

Re: Merging to the release_1_6 branch

> Git is just another version control system and does not decide if we make > feature branches or not. Yes, merging in Subversion is not the best, but > this will become a lot better with Subversion 1.5. I don't think we have to > discuss different version control systems and their advantages here.

Merging to the release_1_6 branch (was: Re: Fwd: http://trac.macports.org/ticket/15109)

> This is why I think that releases should be tags on trunk, with a > convergence period before each release. This project is not big > enough and does not have the manpower or written guidelines and a > release engineer driving the process on a daily basis which are > necessary to really do a two

Ruby 1.9 port

Hi, I have prepared port for Ruby 1.9. I could just commit it, but I wanted to hear your opinion on a few things, before these become facts, on which users might rely. * Name: I tend to call it ruby19. Another option would be ruby-devel, but 1.9 is mildly incompatible, and Python ports use a simi