Nabble - MacPorts - Developer

Re: Combined build and destroot

2009-12-22T23:36:55Z

On Sat, Dec 19, 2009 at 10:20:05AM -0600, Ryan Schmidt wrote:
> Note that the destroot directory doesn't exist until the destroot phase begins, so if you wanted to install into it during the build phase, you'd have to create the destroot directory yourself. I'm not sure if this will impede MacPorts' own attempts to create the destroot directory (and the dozens of other directories inside it) but it might work ok, and I'd give it a try.

This turns out not to be a problem -- MacPorts just skips over any
directories that already exist in the destroot when populating it at
the beginning of the destroot phase.

So this is likely the way to go if anyone finds themselves with a
similar problem. Obviously the port's build script needs to create any
missing directories in the destroot, but anything with a non-trivial
build script probably knows how to do that.

Dan

--
Dan R. K. Ports <dports@...>
Research Henchman
Massachusetts Institute of Technology <drkp@...>
Computer Science and Artificial Intelligence Lab <drkp@...>
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: dovecot-sieve

2009-12-22T12:34:20Z

On Dec 22, 2009, at 10:07 AM, Bradley Giesbrecht wrote:

> Hi,
>
>
> I'm building a Portfile for dovecot-sieve and to get the dovecot-
> sieve command line tools I also need to download the dovecot sources.
>
> How do I add an additional download to my Portfile so the sources
> end up in the work directory?
>
> Also, I'd prefer to grab the same version that 'port download
> dovecot' would download. In my situation I'm building a newer
> version of dovecot then is in MacPorts.
>
>
> So this is what the work dir would look like:
>
> ./work/dovecot-1.2-sieve-0.1.14
> ./work/dovecot-1.2.9

I know there is a desire to reduce variants in MacPorts but dovecot-
sieve seems a prime candidate for a variant.

To get the command line tools of dovecot-sieve you need the dovecot
compiled sources dir and pass that to configure.

http://wiki.dovecot.org/LDA/Sieve/Dovecot
Compiling
Compilation is identical among the CMUSieve and the new Sieve plugin.
Use --with-dovecot=<path> to point to dovecot-config file's directory.
There are two possibilities where this could exist:
•
If you configured Dovecot with --enable-header-install, you'll have
dovecot-config installed in $prefix/lib/dovecot/ directory. For example:
./configure --with-dovecot=/usr/local/lib/dovecot make sudo make install
• Compiled Dovecot sources' root directory. For example:
./configure --with-dovecot=../dovecot-1.2.0/ make make install
If you downloaded the sources using Mercurial, you will need to
execute ./autogen.sh first to build the automake structure in your
source tree. This process requires autotools and libtool to be
installed.
Dovecot Sieve includes several command line tools to perform tasks
such as compile, verify and debug Sieve scripts (refer to the README
file for more information). These are built only if you use method 2,
because they need to link Dovecot's .a libraries, which can only be
found from Dovecot's source tree (make install doesn't install them).

Currently I'm downloading the dovecot sources, doing an extract.only
for dovecot-sieve and then this in post-extract:

post-extract {
system "cd ${workpath} && tar xzf ${distpath}/dovecot-$
{dovecot_minor_version}.tar.gz"
system "cd ${workpath}/dovecot-${dovecot_minor_version} && ./
configure --prefix=${prefix} && make"
}

I borrowed this from the i386-elf-gcc port.

I submitted a new port for dovecot-sieve and dovecot which appears to
build clean on my system. I am currently using the new dovecot 1.2.9
port and it seems to be working fine.

I have not worked with teh dovecot-sieve tools but as I said they
build clean and the command line tools I checked out execute without
error other then complaining for lack of input. I haven't actually
tested any sieve-scripts yet.

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

launch4j port

2009-12-22T10:41:50Z

Hello
I have created a new port for launch4j a week ago, but there is no feedback.
The ticket is here
http://trac.macports.org/ticket/22914

Could you have a look?

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

dovecot-sieve

2009-12-22T10:07:58Z

Hi,

I'm building a Portfile for dovecot-sieve and to get the dovecot-sieve
command line tools I also need to download the dovecot sources.

How do I add an additional download to my Portfile so the sources end
up in the work directory?

Also, I'd prefer to grab the same version that 'port download dovecot'
would download. In my situation I'm building a newer version of
dovecot then is in MacPorts.

So this is what the work dir would look like:

./work/dovecot-1.2-sieve-0.1.14
./work/dovecot-1.2.9

and dovecot-sieve configure args would be:

./configure --with-dovecot=${workpath}/dovecot-1.2.9/

So from the configure line you see I either need to know the full
dovecot version or need to extract it to:

./work/dovecot

Any tips on doing this would be groovy.

Thanks,
Brad
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [61822] trunk/dports/net

2009-12-21T12:32:19Z

On Dec 21, 2009, at 2:40 PM, Ryan Schmidt wrote:

>
> On Dec 21, 2009, at 12:59, ecronin@... wrote:
>
>> Revision: 61822
>> http://trac.macports.org/changeset/61822
>> Author: ecronin@...
>> Date: 2009-12-21 10:59:51 -0800 (Mon, 21 Dec 2009)
>> Log Message:
>> -----------
>> new port: net/py26-scapy (clone of py25's net/scapy)
>
> But is scapy a python module, or software that just happens to use python? If the former, then scapy should be renamed py25-scapy. If the latter, then scapy should be updated to use python 2.6 and py26-scapy should be deleted.
>

It is (largely) software written in python. I based the name on py26-markdown which is also a tool written in python that can be installed against py25 or py26. I didn't want to step on pmq's port or force current users to have to update to py26, but I have a py25-free install and so it seemed useful to have in dports...

Thanks,
Eric

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

Re: [61822] trunk/dports/net

2009-12-21T11:40:06Z

On Dec 21, 2009, at 12:59, ecronin@... wrote:

> Revision: 61822
> http://trac.macports.org/changeset/61822
> Author: ecronin@...
> Date: 2009-12-21 10:59:51 -0800 (Mon, 21 Dec 2009)
> Log Message:
> -----------
> new port: net/py26-scapy (clone of py25's net/scapy)

But is scapy a python module, or software that just happens to use python? If the former, then scapy should be renamed py25-scapy. If the latter, then scapy should be updated to use python 2.6 and py26-scapy should be deleted.

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

Re: [61786] trunk/dports/www

2009-12-21T10:41:59Z

On Dec 21, 2009, at 12:13, Frank Schima wrote:

>> +maintainers chuck@...
>
> The email address should be obfuscated like this - acquia.com:chuck

It does not need to be, but it is probably better to do so, to avoid being harvested by some spambots. I made this change in r61813.

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

Re: [61786] trunk/dports/www

2009-12-21T10:13:37Z

On Dec 21, 2009, at 9:10 AM, jann@... wrote:

Revision

61786

Author

jann@...

Date

2009-12-21 08:10:10 -0800 (Mon, 21 Dec 2009)

Log Message
New port: #21712
Added Paths

trunk/dports/www/drush/

trunk/dports/www/drush/Portfile
Diff
Added: trunk/dports/www/drush/Portfile (0 => 61786)
--- trunk/dports/www/drush/Portfile	                        (rev 0)
+++ trunk/dports/www/drush/Portfile	2009-12-21 16:10:10 UTC (rev 61786)
@@ -0,0 +1,41 @@
+# $Id$
+
+PortSystem          1.0
+
+name                drush
+version             2.1
+categories          www php
+platforms           darwin
+
+maintainers         chuck@...

The email address should be obfuscated like this - acquia.com:chuck

+description         The DRUpal SHell
+long_description    drush is a command line shell and Unix scripting interface for Drupal, a veritable Swiss Army \
+                    knife designed to make life easier for those of us who spend some of our working hours hacking \
+                    away at the command prompt.
+
+homepage            http://drupal.org/project/drush
+distfiles           drush-All-Versions-$version.tar.gz
+master_sites        http://ftp.drupal.org/files/projects/ \
+                    http://ftp.osuosl.org/pub/drupal/files/projects/
+checksums           md5     dd4b55c7d1e98f35c51c69788d6dffee \
+                    sha1    d49d05baa26d8ce7aa7f0250c6f0e01ba2f5aebb \
+                    rmd160  5d78cd177ae53d4844ca8f6cdb427ec286393881
+depends_lib         port:php52
+
+variant drupal5 description "use with Drupal 5 port" {
+  depends_lib-append      port:drupal5
+}
+
+variant drupal6 description "use with Drupal 6 port" {
+  depends_lib-append      port:drupal6
+}
+
+worksrcdir          drush
+use_configure       no
+build { }
+
+destroot {
+  xinstall -d -m 0755 ${destroot}/${prefix}/libexec/drush
+  eval file copy [glob ${worksrcpath}/*] ${destroot}/${prefix}/libexec/drush
+  ln -s ${prefix}/libexec/drush/drush ${destroot}/${prefix}/bin/drush  
+}

_______________________________________________
macports-changes mailing list
macports-changes@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes

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

Re: [61770] trunk/base/src/pextlib1.0/filemap.c

2009-12-20T22:45:00Z

On 2009-12-21 17:31 , Ryan Schmidt wrote:

>
> On Dec 21, 2009, at 00:21, jmr@... wrote:
>
>> Revision: 61770
>> http://trac.macports.org/changeset/61770
>> Author: jmr@...
>> Date: 2009-12-20 22:21:07 -0800 (Sun, 20 Dec 2009)
>> Log Message:
>> -----------
>> fix fd leak (#22959)
>
> I'm impressed you were able to find this! How'd you do that? :) And why does this change fix the problem?

The existing variable with the same name declared outside the loop is
what is closed later on.

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

Re: [61770] trunk/base/src/pextlib1.0/filemap.c

2009-12-20T22:31:33Z

On Dec 21, 2009, at 00:21, jmr@... wrote:

> Revision: 61770
> http://trac.macports.org/changeset/61770
> Author: jmr@...
> Date: 2009-12-20 22:21:07 -0800 (Sun, 20 Dec 2009)
> Log Message:
> -----------
> fix fd leak (#22959)

I'm impressed you were able to find this! How'd you do that? :) And why does this change fix the problem?

> Modified Paths:
> --------------
> trunk/base/src/pextlib1.0/filemap.c
>
> Modified: trunk/base/src/pextlib1.0/filemap.c
> ===================================================================
> --- trunk/base/src/pextlib1.0/filemap.c 2009-12-21 05:14:02 UTC (rev 61769)
> +++ trunk/base/src/pextlib1.0/filemap.c 2009-12-21 06:21:07 UTC (rev 61770)
> @@ -210,7 +210,7 @@
> ssize_t theFileSize;
>
> /* Open the file for reading, creating it if necessary. */
> - int theFD = open(inDatabasePath, O_RDONLY | O_CREAT, 0664);
> + theFD = open(inDatabasePath, O_RDONLY | O_CREAT, 0664);
> if (theFD < 0)
> {
> theErr = errno;

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

Re: Ticket #22512

2009-12-20T13:41:44Z

On Dec 18, 2009, at 10:50, Mark Anderson wrote:

> Can someone please commit ticket 22512? I have a diff attached that
> should fix geda-gaf's problem.

Jann committed it. Thanks.

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

Re: Combined build and destroot

2009-12-19T08:20:05Z

On Dec 19, 2009, at 03:56, Dan Ports wrote:

> I'm working on packaging MacFUSE 2.0 (ref: ticket #18671). This process
> is made rather painful by the fact that MacFUSE includes its own
> (surprisingly complicated) build script.
>
> One complication is that the script essentially does the build and
> destroot phases together (because it's trying to create a .pkg).
>
> The easiest way to get it working would be to patch the build script to
> install into ${destpath}. But then it would populate ${destpath} during
> the build phase rather than destroot -- how egregious of an offense is
> this?

Not an offense, I think. Most autoconf software is simply designed to build in the source directory and then install to a final directory, so MacPorts mirrors this method by default.

Note that the destroot directory doesn't exist until the destroot phase begins, so if you wanted to install into it during the build phase, you'd have to create the destroot directory yourself. I'm not sure if this will impede MacPorts' own attempts to create the destroot directory (and the dozens of other directories inside it) but it might work ok, and I'd give it a try.

> (Alternatively we could do both the compilation and installation
> during destroot, but that doesn't seem a lot better)

Yeah, that's probably worse.

> Properly separating the build and destroot phases would require a
> fairly intrusive patch to macfuse's build script, which I would like to
> avoid.

Agreed.

> Another option is to have the build phase stage everything
> somewhere in ${workpath} and then copy all of its contents directly to
> ${destpath} during destroot, but that feels a little silly.

Yes, this would probably just serve to introduce extra delays for the user while things are copied.

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

Combined build and destroot

2009-12-19T01:56:28Z

I'm working on packaging MacFUSE 2.0 (ref: ticket #18671). This process
is made rather painful by the fact that MacFUSE includes its own
(surprisingly complicated) build script.

One complication is that the script essentially does the build and
destroot phases together (because it's trying to create a .pkg).

The easiest way to get it working would be to patch the build script to
install into ${destpath}. But then it would populate ${destpath} during
the build phase rather than destroot -- how egregious of an offense is
this? (Alternatively we could do both the compilation and installation
during destroot, but that doesn't seem a lot better)

Properly separating the build and destroot phases would require a
fairly intrusive patch to macfuse's build script, which I would like to
avoid. Another option is to have the build phase stage everything
somewhere in ${workpath} and then copy all of its contents directly to
${destpath} during destroot, but that feels a little silly.

Has this come up for other ports? Is there a best practice for dealing
with it?

Thanks,

Dan

--
Dan R. K. Ports <dports@...>
Research Henchman
Massachusetts Institute of Technology <drkp@...>
Computer Science and Artificial Intelligence Lab <drkp@...>
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Ticket #22512

2009-12-18T08:50:01Z

Can someone please commit ticket 22512? I have a diff attached that
should fix geda-gaf's problem.

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

Re: [61662] trunk/dports/net/libpcapnav/

2009-12-17T20:29:27Z

Eric,

You appear to have committed only three empty directories, without Portfiles inside. :)

On Dec 17, 2009, at 17:06, ecronin@... wrote:

> Revision: 61662
> http://trac.macports.org/changeset/61662
> Author: ecronin@...
> Date: 2009-12-17 15:06:21 -0800 (Thu, 17 Dec 2009)
> Log Message:
> -----------
> net/libpcapnav: New port
>
> Added Paths:
> -----------
> trunk/dports/net/libpcapnav/

On Dec 17, 2009, at 17:21, ecronin@... wrote:

> Revision: 61663
> http://trac.macports.org/changeset/61663
> Author: ecronin@...
> Date: 2009-12-17 15:21:03 -0800 (Thu, 17 Dec 2009)
> Log Message:
> -----------
> net/libnetdude: New port
>
> Added Paths:
> -----------
> trunk/dports/net/libnetdude/

On Dec 17, 2009, at 17:39, ecronin@... wrote:

> Revision: 61664
> http://trac.macports.org/changeset/61664
> Author: ecronin@...
> Date: 2009-12-17 15:38:57 -0800 (Thu, 17 Dec 2009)
> Log Message:
> -----------
> net/netdude: New port
>
> Added Paths:
> -----------
> trunk/dports/net/netdude/

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

Re: macports dovecot sieve

2009-12-17T00:28:21Z

On Dec 17, 2009, at 02:20, Bradley Giesbrecht wrote:

> On Dec 16, 2009, at 11:59 PM, Ryan Schmidt wrote:
>
>> On Dec 17, 2009, at 01:26, Bradley Giesbrecht wrote:
>>
>>> Should I bother submitting dovecot sieve and if so what should I name it?
>>
>> Maybe dovecot-sieve? There is an open request to add a +sieve variant to dovecot; maybe your separate port would satisfy this request. A separate port is probably better for usability than a variant anyway.
>>
>> http://trac.macports.org/ticket/11810
>
> There are two sieve options for dovecot, Dovecot Sieve for Dovecot 1.2 and newer and CMU Sieve for Dovecot 1.0 through 1.2.
>
> So dovecot-sieve and later if someone wants the other they could create dovecot-cmu-sieve?

Oh, I see. Well that sounds ok. In any case it will be good to have any sieve option for dovecot in MacPorts.

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

Re: macports dovecot sieve

2009-12-17T00:20:46Z

On Dec 16, 2009, at 11:59 PM, Ryan Schmidt wrote:

On Dec 17, 2009, at 01:26, Bradley Giesbrecht wrote:

I'm building the dovecot-1.2-sieve plugin and am doing a portfile while I'm at it.

The file download is dovecot-1.2-sieve-0.1.13.tar.gz.

Later I will also be building dovecot-1.2-managesieve-0.11.9.tar.gz.

It looks like the authors add the dovecot version in the name because there are different versions of the plugin depending on the version of dovecot.

I'm using my own dovecot Portfile and I'm at the most recent 1.2 version while ports has 1.1.16.

Should I bother submitting dovecot sieve and if so what should I name it?

Maybe dovecot-sieve? There is an open request to add a +sieve variant to dovecot; maybe your separate port would satisfy this request. A separate port is probably better for usability than a variant anyway.

http://trac.macports.org/ticket/11810

There are two sieve options for dovecot, Dovecot Sieve for Dovecot 1.2 and newer and CMU Sieve for Dovecot 1.0 through 1.2.

So dovecot-sieve and later if someone wants the other they could create dovecot-cmu-sieve?

Should I also submit my dovecot 1.2 Portfile?

That would be great.

If so should I trac it to the current dovecot or rename it to dovecot12 or something?

My instinct would be no. Is there any reason someone would still want dovecot 1.1? You could ask the maintainer of dovecot for guidance if you're unsure.

When I have this working on my production server, hopefully tonight, I'll send my Portfile to the maintainer.

Also, dovecot v2 is in beta, I won't be building it real soon but thought I'd mention.

BTW, the dovecot 1.1 branch is at 1.1.20. 1.1.16 was release June 1st 2009.

I'm only moving to dovecot 1.2 because dovecot-sieve is for dovecot 1.2 or newer.

As far as I can tell, 1.2.9 is the stable version of dovecot, so I would assume the port should be updated to that version. It looks like the maintainer last touched the port the month before 1.2.0 was released.

// Brad

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

Re: /opt/local/lib/libgcc_s.1.dylib, binutils, llvm-gcc42

2009-12-16T23:12:01Z

On Dec 16, 2009, at 22:37, Dan Ports wrote:

> On Wed, Dec 16, 2009 at 09:04:13PM -0600, Ryan Schmidt wrote:
>> My recommendation is to not install llvm-gcc42 until this issue is resolved. If anyone can assist in resolving this issue, it would be appreciated.
>
> Isn't the solution to both of these problems (libiberty & libgcc_s) just a
> matter of adding
> --libdir=${prefix}/lib/${name}
> --libexecdir=${prefix}/libexec/${name}
> --includedir=${prefix}/include/${name}
> to configure.args?
>
> (I don't use llvm-gcc at all myself, but in my experience this is
> typically the answer to such problems with gcc.)

It's possible that's all that's needed. I haven't tried it. What we need is for someone to try it and attach to the ticket a patch that works. I would say that ports that use llvm-gcc42 should also be tested to ensure they still work with this change, but fortunately there aren't any such ports.

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

Re: /opt/local/lib/libgcc_s.1.dylib, binutils, llvm-gcc42

2009-12-16T20:37:34Z

On Wed, Dec 16, 2009 at 09:04:13PM -0600, Ryan Schmidt wrote:
> My recommendation is to not install llvm-gcc42 until this issue is resolved. If anyone can assist in resolving this issue, it would be appreciated.

Isn't the solution to both of these problems (libiberty & libgcc_s) just a
matter of adding
--libdir=${prefix}/lib/${name}
--libexecdir=${prefix}/libexec/${name}
--includedir=${prefix}/include/${name}
to configure.args?

(I don't use llvm-gcc at all myself, but in my experience this is
typically the answer to such problems with gcc.)

Dan

--
Dan R. K. Ports <dports@...>
Research Henchman
Massachusetts Institute of Technology <drkp@...>
Computer Science and Artificial Intelligence Lab <drkp@...>
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [61596] trunk/dports/graphics/wxWidgets/Portfile

2009-12-16T19:42:42Z

On Dec 16, 2009, at 13:24, jwa@... wrote:

> Revision: 61596
> http://trac.macports.org/changeset/61596
> Author: jwa@...
> Date: 2009-12-16 11:24:42 -0800 (Wed, 16 Dec 2009)
> Log Message:
> -----------
> make wxWidgets build on 10.6, hopefully nothing else breaks
>
> Modified Paths:
> --------------
> trunk/dports/graphics/wxWidgets/Portfile
>
> Modified: trunk/dports/graphics/wxWidgets/Portfile
> ===================================================================
> --- trunk/dports/graphics/wxWidgets/Portfile 2009-12-16 18:54:45 UTC (rev 61595)
> +++ trunk/dports/graphics/wxWidgets/Portfile 2009-12-16 19:24:42 UTC (rev 61596)
> @@ -1,6 +1,7 @@
> # $Id$
>
> PortSystem 1.0
> +PortGroup archcheck 1.0

There is no reason to add the archcheck portgroup unless you use the archcheck.files directive to check the architectures of the dependencies. However...

On Dec 16, 2009, at 13:24, jwa@... wrote:

> +universal_variant no
> use_parallel_build no
>
> +platform darwin 10 {
> + configure.build_arch i386
> +# configure.cflags "-arch i386"
> + configure.cppflags "-arch i386"
> +# configure.cxxflags "-arch i386"
> +# configure.objcflags "-arch i386"
> + configure.ldflags "-arch i386"
> +}

...since you are forcing a 32-bit build, checking the architectures of the dependencies would be an excellent idea.

But why are you forcing a 32-bit build only on Snow Leopard? Wouldn't it also be necessary on Leopard if the user has set build_arch to x86_64 or ppc64?

Attached is a patch for wxWidgets to address these issues.

Unfortunately, the only way this will really be useful for anyone on Snow Leopard is if every port that depends on wxWidgets (I count 20 ports), and every port that depends on those ports (no idea how many), and so on, also forces itself to 32-bit and checks dependencies' architectures. Not pretty.

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

wxWidgets.diff (1K) Download Attachment

Re: [61602] branches/release_1_8/base

2009-12-16T19:06:36Z

On Dec 16, 2009, at 14:05, jmr@... wrote:

> Revision: 61602
> http://trac.macports.org/changeset/61602
> Author: jmr@...
> Date: 2009-12-16 12:05:20 -0800 (Wed, 16 Dec 2009)
> Log Message:
> -----------
> bump branch version to 1.8.2

I guess I should test those 1.8.2 fixes you've been bugging me about, and merge back those other changes from trunk I've been meaning to do, real soon now, huh? :)

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

Re: /opt/local/lib/libgcc_s.1.dylib, binutils, llvm-gcc42

2009-12-16T19:04:13Z

On Dec 16, 2009, at 18:43, Dan Ports wrote:

> On Wed, Dec 16, 2009 at 04:10:50PM -0800, Darren Weber wrote:
>> Is it possible and desirable to have a single port to control the
>> libiberty.a and have all other ports depend on it?

I don't believe it's desirable.

>> (This probably requires
>> ways to switch off the build of libiberty.a in the config for various ports
>> like binutils, gcc stuff, etc.).
>
> I don't think so -- as far as I can tell, and for reasons I have never quite
> grasped, libiberty isn't distributed separately, or even really
> versioned; its source is directly included in the gcc sources.
>
> I think the right solution here is for each port to install its own
> version of libiberty in a separate place. It look like some ports
> already do this (gcc43, for one). Maybe the actual problem you're
> running into is that llvm-gcc doesn't do this?
>
> It's possible that it isn't even necessary to install libiberty.a in
> the first place. (isn't it typically linked in to gcc and friends
> statically?) But I'm less sure about this.

I filed the bug report about llvm-gcc42's /opt/local/lib/libgcc_s.1.dylib here:

http://trac.macports.org/ticket/20889

Unfortunately the maintainer has not reacted to the problem.

My recommendation is to not install llvm-gcc42 until this issue is resolved. If anyone can assist in resolving this issue, it would be appreciated.

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

Re: /opt/local/lib/libgcc_s.1.dylib, binutils, llvm-gcc42

2009-12-16T16:43:22Z

On Wed, Dec 16, 2009 at 04:10:50PM -0800, Darren Weber wrote:
> Is it possible and desirable to have a single port to control the
> libiberty.a and have all other ports depend on it? (This probably requires
> ways to switch off the build of libiberty.a in the config for various ports
> like binutils, gcc stuff, etc.).

I don't think so -- as far as I can tell, and for reasons I have never quite
grasped, libiberty isn't distributed separately, or even really
versioned; its source is directly included in the gcc sources.

I think the right solution here is for each port to install its own
version of libiberty in a separate place. It look like some ports
already do this (gcc43, for one). Maybe the actual problem you're
running into is that llvm-gcc doesn't do this?

It's possible that it isn't even necessary to install libiberty.a in
the first place. (isn't it typically linked in to gcc and friends
statically?) But I'm less sure about this.

Dan

--
Dan R. K. Ports <dports@...>
Research Henchman
Massachusetts Institute of Technology <drkp@...>
Computer Science and Artificial Intelligence Lab <drkp@...>
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

/opt/local/lib/libgcc_s.1.dylib, binutils, llvm-gcc42

2009-12-16T16:10:50Z

There seem to be many ports that build and install

/opt/local/lib/libiberty.a

One potential consequence is failure for installations or upgrades. For example,

$ sudo port install llvm-gcc42
---> Computing dependencies for llvm-gcc42
---> Activating llvm-gcc42 @2.6_0+darwin+darwin_i386
Error: Unable to execute port: Image error: /opt/local/lib/libiberty.a is being used by the active binutils port. Please deactivate this port first, or use 'port -f activate llvm-gcc42' to force the activation.

Is it possible and desirable to have a single port to control the libiberty.a and have all other ports depend on it? (This probably requires ways to switch off the build of libiberty.a in the config for various ports like binutils, gcc stuff, etc.).

Take care,
Darren

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

Re: submit a port for launch4j

2009-12-16T09:54:07Z

Make a submission ticket at trac.macports.org

On Dec 16, 2009, at 12:53 PM, Panayotis Katsaloulis wrote:

> I have created a new port (actually for launch4j)
>
> What should I do to send it to macports?
> _______________________________________________
> macports-dev mailing list
> macports-dev@...
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>

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

smime.p7s (3K) Download Attachment

submit a port for launch4j

2009-12-16T09:53:25Z

I have created a new port (actually for launch4j)

What should I do to send it to macports?
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

PortIndex2MySQL.tcl should be atomic

2009-12-15T05:11:42Z

PortIndex2MySQL.tcl seems to have some odd behavior.

It seems to DROP and re-CREATE all the tables every time it runs. It has a --create-tables command line option, but it seems to recreate the tables whether or not that option is given.

Partly as a consequence of that, I think, if something causes the update to fail partway through (like a duplicate port, like we just had with box2d) then the database is left in an incomplete state (for example, right now the web site claims we have 1571 ports, when of course we really have over 6400 ports.

It seems to me that the tables should only be recreated when needed (i.e. only when the schema changes, which should be rare), and that the update should occur inside a transaction, so that if anything fails, the transaction is automatically rolled back and there will no longer be a way for the database to exist in an incomplete state.

Is there any reason you can think of why we should not make these changes?

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

Re: PortIndex2MySQL run failure on Monday 2009-12-14 at 16:10:00

2009-12-15T04:58:11Z

Forgive me, Anthony, but I deleted your Box2D. Ordinarily I would have sent you an email, but I didn't know if you were around, and as it stands, the PortIndex2MySQL failure means our web site only had 1/4 of our ports in its database.

Your files are of course still available in the repository history if you need to access them, and if you have any improvements to make to the existing box2d port, please do so.

-Ryan

On Dec 14, 2009, at 18:26, William Siegrist wrote:

> There are now 2 box2d ports.
>
> https://trac.macports.org/changeset/60951
> https://trac.macports.org/changeset/61558
>
> -Bill
>
>
> Begin forwarded message:
>
>> From: macports-mgr@...
>> Date: December 14, 2009 4:10:13 PM PST
>> To: wms@...
>> Subject: PortIndex2MySQL run failure on Monday 2009-12-14 at 16:10:00
>>
>>
>> Synchronizing local ports tree from file:///rsync/macports-san/release/ports/
>> Error: CHILDSTATUS 64449 1: ERROR 1062 (23000) at line 13457: Duplicate entry 'Box2D' for key 1

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

Re: [61530] trunk/dports/gnome/liferea/Portfile

2009-12-15T04:21:02Z

On 2009-12-13 19:52:12 -0600, Ryan Schmidt wrote:
> I put the epoch line back in the portfile, because the epoch line
> can never be removed from a portfile; the epoch can only ever
> increase, otherwise MacPorts will not report the port as being
> outdated. I put the epoch line above the version line now, to better
> indicate that the epoch takes precedence over the version.

OK. This is a bit strange that "port -v upgrade liferea" worked.
I think it should do nothing in such a case (perhaps except if -f
is given).

--
Vincent Lefèvre <vincent@...> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Fwd: PortIndex2MySQL run failure on Monday 2009-12-14 at 16:10:00

2009-12-14T16:26:38Z

There are now 2 box2d ports.

https://trac.macports.org/changeset/60951
https://trac.macports.org/changeset/61558

-Bill

Begin forwarded message:

> From: macports-mgr@...
> Date: December 14, 2009 4:10:13 PM PST
> To: wms@...
> Subject: PortIndex2MySQL run failure on Monday 2009-12-14 at 16:10:00
>
>
> Synchronizing local ports tree from file:///rsync/macports-san/release/ports/
> Error: CHILDSTATUS 64449 1: ERROR 1062 (23000) at line 13457: Duplicate entry 'Box2D' for key 1

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

Re: [61551] trunk/dports/devel/apr-util/Portfile

2009-12-14T15:53:33Z

On Dec 14, 2009, at 10:32, dluke@... wrote:

> Revision: 61551
> http://trac.macports.org/changeset/61551
> Author: dluke@...
> Date: 2009-12-14 08:32:12 -0800 (Mon, 14 Dec 2009)
> Log Message:
> -----------
> Remove trailing whitespace (that lint missed).

If you use "port lint --nitpick" it does catch the whitespace issues, but I agree it should have caught that line without --nitpick, since whitespace after a backslash is not a nitpick, it's a functional problem.

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

Remaining tickets for 1.8.2 release

2009-12-14T12:47:36Z

The only remaining obstacles to a 1.8.2 release are these two tickets:

<http://trac.macports.org/ticket/20896>
<http://trac.macports.org/ticket/21713>

Both may already be fixed in trunk, but someone affected by the problems
described needs to confirm this.

#18736 is currently in the 1.8.2 milestone as well, but as no working
patch has been forthcoming we really have no choice but to kick it out
into MacPorts Future.

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

Re: [61539] trunk/dports/security/cyrus-sasl2/Portfile

2009-12-13T21:24:01Z

On Dec 13, 2009, at 22:37, jeremyhu@... wrote:

> Modified: trunk/dports/security/cyrus-sasl2/Portfile
> ===================================================================
> --- trunk/dports/security/cyrus-sasl2/Portfile 2009-12-14 03:54:27 UTC (rev 61538)
> +++ trunk/dports/security/cyrus-sasl2/Portfile 2009-12-14 04:37:05 UTC (rev 61539)
> @@ -1,9 +1,12 @@
> # $Id$
>
> PortSystem 1.0
> +PortGroup muniversal 1.0
> +PortGroup archcheck 1.0

The only reason to use the archcheck portgroup is if you plan to check the architecture of dependencies using the archcheck.files directive.

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

Re: [61530] trunk/dports/gnome/liferea/Portfile

2009-12-13T17:52:12Z

On Dec 13, 2009, at 19:39, vinc17@... wrote:

> Revision: 61530
> http://trac.macports.org/changeset/61530
> Author: vinc17@...
> Date: 2009-12-13 17:38:58 -0800 (Sun, 13 Dec 2009)
> Log Message:
> -----------
> Bump to 1.6.1. Fixed livecheck.
>
> Modified Paths:
> --------------
> trunk/dports/gnome/liferea/Portfile
>
> Modified: trunk/dports/gnome/liferea/Portfile
> ===================================================================
> --- trunk/dports/gnome/liferea/Portfile 2009-12-14 00:54:15 UTC (rev 61529)
> +++ trunk/dports/gnome/liferea/Portfile 2009-12-14 01:38:58 UTC (rev 61530)
> @@ -3,8 +3,7 @@
> PortSystem 1.0
>
> name liferea
> -version 1.6.0
> -epoch 20090731
> +version 1.6.1

I put the epoch line back in the portfile, because the epoch line can never be removed from a portfile; the epoch can only ever increase, otherwise MacPorts will not report the port as being outdated. I put the epoch line above the version line now, to better indicate that the epoch takes precedence over the version.

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

Re: [61506] trunk/dports/www/webdot/Portfile

2009-12-13T14:34:44Z

On Dec 13, 2009, at 11:28, Joshua Root wrote:

> Wouldn't this be more appropriate?

> - ui_msg " sudo port -n upgrade --force ${graphviz_port} +tcl"
> + ui_msg " sudo port upgrade --enforce-variants
> ${graphviz_port} +tcl"

Thanks, I agree; changed in r61523.

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