Re: tetex/texlive dependencies
Vincent Lefevre wrote:
While different python versions are incompatible, different perl
versions should be compatible (there are very few backward
incompatibilities, but modules based on them should be seen as buggy).
So, I'd say that perl5.10 should completely replace perl5.8, i.e. it
should provide ${prefix}/bin/perl, and if some modules ever fail with
5.10[*] and the bug can't easily be fixed, then the perl5.8 port could
provide a variant without ${prefix}/bin/perl.
You are right, although there's a lot of ports that are using
bin:perl:perl5.8 (or port:perl and then ${prefix}/bin/perl)
that would probably be surprised when such a change is made...
--anders
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New port needs commit
On Sat, Jan 12, 2008 at 10:17:15PM -0500, Luis O'Shea wrote: Could someone commit the new port for asymptote? See ticket #13249 (http://trac.macosforge.org/projects/macports/ticket/13249). Thanks, Luis Hi, I just committed it [1] with one minor change. I added a post-activate hook with calls mktexlsr to make sure asymptote is found. Can I add you as maintainer for this port? Thanks, Simon [1]: http://trac.macosforge.org/projects/macports/changeset/32802 -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 pgpjQnFGrwaJN.pgp Description: PGP signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Port Change (gtkglext) needs to get committed
Hi ... the Changes of the Portfile for gtkglext needs to get committed. #13624 http://trac.macports.org/projects/macports/ticket/13624 The Maintainer seems to doesn't respond. After this is done, #13517 (http://trac.macports.org/projects/ macports/ticket/13517) can be closed (dealing with the same issue - gtkglext on leopard) Thanks, Rolf -- Security is an illusion - Datasecurity twice Rolf Würdemann- private: [EMAIL PROTECTED] - office: [EMAIL PROTECTED] GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: [EMAIL PROTECTED] 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932 PGP.sig Description: Signierter Teil der Nachricht ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Port update (qucs) needs to get commited
Hi Could someone commit the update of qucs to 0.0.13? See Ticket: #13826 http://trac.macports.org/projects/macports/ticket/13826 Thanks, Rolf -- Security is an illusion - Datasecurity twice Rolf Würdemann- private: [EMAIL PROTECTED] - office: [EMAIL PROTECTED] GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: [EMAIL PROTECTED] 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932 PGP.sig Description: Signierter Teil der Nachricht ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New port needs commit
On Jan 13, 2008, at 9:30 AM, Simon Ruderich wrote:
On Sat, Jan 12, 2008 at 10:17:15PM -0500, Luis O'Shea wrote:
Could someone commit the new port for asymptote? See ticket #13249
(http://trac.macosforge.org/projects/macports/ticket/13249).
Thanks,
Luis
Hi,
I just committed it [1] with one minor change. I added a post-
activate hook with
calls mktexlsr to make sure asymptote is found.
Thanks.
Now that the port is committed I wanted to make sure it worked, but I
have run into a problem.
After the commit, I uninstalled asymptote, removed the reference to
my local port hierarchy from sources.conf, and did a selfupdate.
However port seemed to not find the new asymptote port:
% port info asymptote
Error: Port asymptote not found
But ${prefix}/var/macports/sources/rsync.macports.org/release/ports/
graphics/asymptote/Portfile does exist. I tried deleting ${prefix}/
var/macports/sources/rsync.macports.org/release/ports/PortIndex and
doing another selfupdate, but that did not help.
What am I doing wrong?
Thanks,
Luis
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New port needs commit
On Jan 13, 2008, at 2:29 PM, Luis O'Shea wrote:
On Jan 13, 2008, at 9:30 AM, Simon Ruderich wrote:
On Sat, Jan 12, 2008 at 10:17:15PM -0500, Luis O'Shea wrote:
Could someone commit the new port for asymptote? See ticket #13249
(http://trac.macosforge.org/projects/macports/ticket/13249).
Thanks,
Luis
Hi,
I just committed it [1] with one minor change. I added a post-
activate hook with
calls mktexlsr to make sure asymptote is found.
Thanks.
Now that the port is committed I wanted to make sure it worked, but
I have run into a problem.
After the commit, I uninstalled asymptote, removed the reference to
my local port hierarchy from sources.conf, and did a selfupdate.
Why did you do that? What did the entry that you removed look like,
and what lead you to the conclusion that you needed to remove it in
the first place?
However port seemed to not find the new asymptote port:
% port info asymptote
Error: Port asymptote not found
But ${prefix}/var/macports/sources/rsync.macports.org/release/ports/
graphics/asymptote/Portfile does exist. I tried deleting ${prefix}/
var/macports/sources/rsync.macports.org/release/ports/PortIndex and
doing another selfupdate, but that did not help.
Entries in sources.conf point MacPorts to a valid PortIndex file,
from which ports and their info are gathered; if there are no entries
in sources.conf, no PortIndex will be found (regardless of the file(s)
actually existing on the local filesystem). In the case of a stock
MacPorts intallation, the rsync://rsync.macports.org/release/ports/
URL is the only entry in the souces.conf file, and it gets mapped
locally to ${prefix}/var/macports/sources/rsync.macports.org/release/
ports/PortIndex as you infer. Nevertheless, again, if you remove the
entry from sources.conf the corresponding index will not be found by
MacPorts.
I'm curious as to what lead you to believe you needed to remove the
entry, in case it's something in our documentation that's misleading
you. In any case, the only thing you need to update your local ports
tree and get fresh search results is put the entry back and issue a
selfupdate regularly, plain and simple.
Regards,...
-jmpp
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Fwd: New port needs commit
Anfang der weitergeleiteten E-Mail:
Von: Rolf Würdemann [EMAIL PROTECTED]
Datum: 13. Januar 2008 20:03:18 MEZ
An: Luis O'Shea [EMAIL PROTECTED]
Betreff: Re: New port needs commit
Am 13.01.2008 um 19:59 schrieb Luis O'Shea:
On Jan 13, 2008, at 9:30 AM, Simon Ruderich wrote:
On Sat, Jan 12, 2008 at 10:17:15PM -0500, Luis O'Shea wrote:
Could someone commit the new port for asymptote? See ticket #13249
(http://trac.macosforge.org/projects/macports/ticket/13249).
Thanks,
Luis
Hi,
I just committed it [1] with one minor change. I added a post-
activate hook with
calls mktexlsr to make sure asymptote is found.
Thanks.
Now that the port is committed I wanted to make sure it worked,
but I have run into a problem.
After the commit, I uninstalled asymptote, removed the reference
to my local port hierarchy from sources.conf, and did a
selfupdate. However port seemed to not find the new asymptote port:
% port info asymptote
Error: Port asymptote not found
But ${prefix}/var/macports/sources/rsync.macports.org/release/
ports/graphics/asymptote/Portfile does exist. I tried deleting $
{prefix}/var/macports/sources/rsync.macports.org/release/ports/
PortIndex and doing another selfupdate, but that did not help.
What am I doing wrong?
The Portindex is updated every 12 Hours,
so it will take a little time to see your Port in Macports ;)
Thanks,
Luis
Reg's
Rolf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
--
Security is an illusion - Datasecurity
twice
Rolf Würdemann- private: [EMAIL PROTECTED] - office:
[EMAIL PROTECTED]
GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3
31B6 67F0 D02F
jabber: [EMAIL PROTECTED] 2F66A061 89BCA1A0 AD654827 6FD037FF
53C3E932
--
Security is an illusion - Datasecurity
twice
Rolf Würdemann- private: [EMAIL PROTECTED] - office:
[EMAIL PROTECTED]
GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3
31B6 67F0 D02F
jabber: [EMAIL PROTECTED] 2F66A061 89BCA1A0 AD654827 6FD037FF
53C3E932
PGP.sig
Description: Signierter Teil der Nachricht
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Subject: [32751] net/dhcp startupitem
Hi Blair,
Executable startupitems are the preferred type. Daemondo can track pids
automatically and reliably restart an application if it quits. See the
guide on this:
http://guide.macports.org/#reference.startupitems
Given how startupitem executables work, I don't see an advantage to
reverting to a script startupitem. Or is there something I am missing
particular to dhcp?
Mark
Log Message:
---
Use a startupitem method that uses dhcpd's PID file.
Modified Paths:
--
trunk/dports/net/dhcp/Portfile
Modified: trunk/dports/net/dhcp/Portfile
===
--- trunk/dports/net/dhcp/Portfile 2008-01-13 03:07:29 UTC (rev
32750)
+++ trunk/dports/net/dhcp/Portfile 2008-01-13 03:35:29 UTC (rev
32751)
@@ -4,7 +4,7 @@
name dhcp
version3.1.0
-revision 1
+revision 2
categories net
descriptionISC dhcpd server
long_description ISC's Dynamic Host Configuration Protocol
Distribution \
@@ -40,8 +40,9 @@
configure.pre_args
startupitem.create yes
-startupitem.name dhcpd
-startupitem.executable ${prefix}/sbin/dhcpd
+startupitem.start ${prefix}/sbin/dhcpd
+startupitem.restart/bin/kill -HUP \$(/bin/cat
${prefix}/var/run/dhcpd.pid)
+startupitem.stop /bin/kill -15 \$(/bin/cat
${prefix}/var/run/dhcpd.pid)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Subject: [32751] net/dhcp startupitem
Hi Mark,
I was seeing the following:
1) One dhcpd would start.
2) Every 10 seconds thereafter, another dhcpd would be started, but it
couldn't bind to the port since the first one was running.
It appears that the startupitem infrastructure wasn't keeping track of
dhcpd running and deamonizing itself.
I haven't read the guide yet. What do you suggest? Putting a -f to
dhcpd so it stays in the foreground?
Regards,
Blair
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
[EMAIL PROTECTED]
Subversion training, consulting and support
http://www.orcaware.com/svn/
On Jan 13, 2008, at 12:11 PM, [EMAIL PROTECTED] wrote:
Hi Blair,
Executable startupitems are the preferred type. Daemondo can track
pids
automatically and reliably restart an application if it quits. See
the
guide on this:
http://guide.macports.org/#reference.startupitems
Given how startupitem executables work, I don't see an advantage to
reverting to a script startupitem. Or is there something I am
missing
particular to dhcp?
Mark
Log Message:
---
Use a startupitem method that uses dhcpd's PID file.
Modified Paths:
--
trunk/dports/net/dhcp/Portfile
Modified: trunk/dports/net/dhcp/Portfile
===
--- trunk/dports/net/dhcp/Portfile 2008-01-13 03:07:29 UTC (rev
32750)
+++ trunk/dports/net/dhcp/Portfile 2008-01-13 03:35:29 UTC (rev
32751)
@@ -4,7 +4,7 @@
name dhcp
version3.1.0
-revision 1
+revision 2
categories net
descriptionISC dhcpd server
long_description ISC's Dynamic Host Configuration Protocol
Distribution \
@@ -40,8 +40,9 @@
configure.pre_args
startupitem.create yes
-startupitem.name dhcpd
-startupitem.executable ${prefix}/sbin/dhcpd
+startupitem.start ${prefix}/sbin/dhcpd
+startupitem.restart/bin/kill -HUP \$(/bin/cat
${prefix}/var/run/dhcpd.pid)
+startupitem.stop /bin/kill -15 \$(/bin/cat
${prefix}/var/run/dhcpd.pid)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New port needs commit
After the commit, I uninstalled asymptote, removed the reference
to my local port hierarchy from sources.conf, and did a selfupdate.
Why did you do that? What did the entry that you removed look
like, and what lead you to the conclusion that you needed to remove
it in the first place?
My goal was to verify that the new asymptote Portfile functioned
correctly. While I was developing the Portfile my sources.conf
looked like
file:///Users/luis/macports/ports
rsync://rsync.macports.org/release/ports/
I assume that while the file:///... line precedes the
rsync:///..., port will pickup my copy of the Portfile rather than
the newly committed one. So I removed the first line and did a
selfupdate.
Two questions:
- What is the best description of the ports referenced by
file:///...? I called it my local port hierarchy, but I now
think this might be confusing. (It might mean my *copy* of rsync://
rsync.macports)
- After developing a new Portfile, what is the best way to pick up
the newly committed Portfile? Should I leave sources.conf as is,
delete my Portfile (the one under file:///...) and re-portindex?
See below for the source of my thick-headedness.
However port seemed to not find the new asymptote port:
% port info asymptote
Error: Port asymptote not found
But ${prefix}/var/macports/sources/rsync.macports.org/release/
ports/graphics/asymptote/Portfile does exist. I tried deleting $
{prefix}/var/macports/sources/rsync.macports.org/release/ports/
PortIndex and doing another selfupdate, but that did not help.
Entries in sources.conf point MacPorts to a valid PortIndex file,
from which ports and their info are gathered; if there are no
entries in sources.conf, no PortIndex will be found (regardless of
the file(s) actually existing on the local filesystem). In the case
of a stock MacPorts intallation, the rsync://rsync.macports.org/
release/ports/ URL is the only entry in the souces.conf file, and
it gets mapped locally to ${prefix}/var/macports/sources/
rsync.macports.org/release/ports/PortIndex as you infer.
Nevertheless, again, if you remove the entry from sources.conf the
corresponding index will not be found by MacPorts.
I'm curious as to what lead you to believe you needed to remove
the entry, in case it's something in our documentation that's
misleading you. In any case, the only thing you need to update your
local ports tree and get fresh search results is put the entry back
and issue a selfupdate regularly, plain and simple.
Duh! PortIndex is under version control -- I thought it was
generated locally after a sync.
Thanks!
Luis
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Subject: [32751] net/dhcp startupitem
Hi Mark,
The guild says this:
startupitem.executable. Specifies the name of the daemon to be run
in the background. It may have multiple arguments, but they must be
appropriate for a call to exec; arbitrary shell code may not be used.
Should the actual daemon remain in the foreground so that the parent
parent process can wait() on it? Should the daemon make a PID file in
a known location?
The guide could expand on this a bit.
Regards,
Blair
On Jan 13, 2008, at 12:11 PM, [EMAIL PROTECTED] wrote:
Hi Blair,
Executable startupitems are the preferred type. Daemondo can track
pids
automatically and reliably restart an application if it quits. See
the
guide on this:
http://guide.macports.org/#reference.startupitems
Given how startupitem executables work, I don't see an advantage to
reverting to a script startupitem. Or is there something I am
missing
particular to dhcp?
Mark
Log Message:
---
Use a startupitem method that uses dhcpd's PID file.
Modified Paths:
--
trunk/dports/net/dhcp/Portfile
Modified: trunk/dports/net/dhcp/Portfile
===
--- trunk/dports/net/dhcp/Portfile 2008-01-13 03:07:29 UTC (rev
32750)
+++ trunk/dports/net/dhcp/Portfile 2008-01-13 03:35:29 UTC (rev
32751)
@@ -4,7 +4,7 @@
name dhcp
version3.1.0
-revision 1
+revision 2
categories net
descriptionISC dhcpd server
long_description ISC's Dynamic Host Configuration Protocol
Distribution \
@@ -40,8 +40,9 @@
configure.pre_args
startupitem.create yes
-startupitem.name dhcpd
-startupitem.executable ${prefix}/sbin/dhcpd
+startupitem.start ${prefix}/sbin/dhcpd
+startupitem.restart/bin/kill -HUP \$(/bin/cat
${prefix}/var/run/dhcpd.pid)
+startupitem.stop /bin/kill -15 \$(/bin/cat
${prefix}/var/run/dhcpd.pid)
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
[EMAIL PROTECTED]
Subversion training, consulting and support
http://www.orcaware.com/svn/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Subject: [32751] net/dhcp startupitem
Mark,
It works fine if I use this:
startupitem.create yes
startupitem.namedhcpd
startupitem.executable ${prefix}/sbin/dhcpd -f
startupitem.netchange yes
How's that?
Regards,
Blair
On Jan 13, 2008, at 12:36 PM, Blair Zajac wrote:
Hi Mark,
The guild says this:
startupitem.executable. Specifies the name of the daemon to be run
in the background. It may have multiple arguments, but they must be
appropriate for a call to exec; arbitrary shell code may not be used.
Should the actual daemon remain in the foreground so that the parent
parent process can wait() on it? Should the daemon make a PID file
in a known location?
The guide could expand on this a bit.
Regards,
Blair
On Jan 13, 2008, at 12:11 PM, [EMAIL PROTECTED] wrote:
Hi Blair,
Executable startupitems are the preferred type. Daemondo can track
pids
automatically and reliably restart an application if it quits. See
the
guide on this:
http://guide.macports.org/#reference.startupitems
Given how startupitem executables work, I don't see an advantage to
reverting to a script startupitem. Or is there something I am
missing
particular to dhcp?
Mark
Log Message:
---
Use a startupitem method that uses dhcpd's PID file.
Modified Paths:
--
trunk/dports/net/dhcp/Portfile
Modified: trunk/dports/net/dhcp/Portfile
===
--- trunk/dports/net/dhcp/Portfile 2008-01-13 03:07:29 UTC (rev
32750)
+++ trunk/dports/net/dhcp/Portfile 2008-01-13 03:35:29 UTC (rev
32751)
@@ -4,7 +4,7 @@
name dhcp
version3.1.0
-revision 1
+revision 2
categories net
descriptionISC dhcpd server
long_description ISC's Dynamic Host Configuration Protocol
Distribution \
@@ -40,8 +40,9 @@
configure.pre_args
startupitem.create yes
-startupitem.name dhcpd
-startupitem.executable ${prefix}/sbin/dhcpd
+startupitem.start ${prefix}/sbin/dhcpd
+startupitem.restart/bin/kill -HUP \$(/bin/cat
${prefix}/var/run/dhcpd.pid)
+startupitem.stop /bin/kill -15 \$(/bin/cat
${prefix}/var/run/dhcpd.pid)
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
[EMAIL PROTECTED]
Subversion training, consulting and support
http://www.orcaware.com/svn/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Subject: [32751] net/dhcp startupitem
Blair, I see. That's fine then. I just wanted to be sure there was a reason for making it a script startupitem and there is. I'm cc'ing James (master of all things startupitem) just in case he knows why the executable startupitem type wasn't adequate in this case. It seems like it should have worked. Thanks for fixing the port. Mark Hi Mark, I was seeing the following: 1) One dhcpd would start. 2) Every 10 seconds thereafter, another dhcpd would be started, but it couldn't bind to the port since the first one was running. It appears that the startupitem infrastructure wasn't keeping track of dhcpd running and deamonizing itself. I haven't read the guide yet. What do you suggest? Putting a -f to dhcpd so it stays in the foreground? Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies [EMAIL PROTECTED] Subversion training, consulting and support [ https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fwww.orcaware.com%2fsvn%2f ]http://www.orcaware.com/svn/ On Jan 13, 2008, at 12:11 PM, [EMAIL PROTECTED] wrote: Hi Blair, Executable startupitems are the preferred type. Daemondo can track pids automatically and reliably restart an application if it quits. See the guide on this: [ https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fguide.macports.org%2f%23reference.startupitems ]http://guide.macports.org/#reference.startupitems Given how startupitem executables work, I don't see an advantage to reverting to a script startupitem. Or is there something I am missing particular to dhcp? ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Subject: [32751] net/dhcp startupitem
Mark,
It works fine if I use this:
startupitem.create yes
startupitem.name dhcpd
startupitem.executable ${prefix}/sbin/dhcpd -f
startupitem.netchange yes
How's that?
The startupitem executable is preferred if it works automatically I think;
but if it doesn't for some reason at that point I see no obligation to
prefer a workaround using the executable type to using the script type
startupitem. So I think leaving it as you had it is fine; I can't comment
on whether starting in foreground mode is a good method, but as I said
under the circumstances your current solution is perfectly fine in my
opinion.
On Jan 13, 2008, at 12:36 PM, Blair Zajac wrote:
Hi Mark,
The guild says this:
startupitem.executable. Specifies the name of the daemon to be run
in the background. It may have multiple arguments, but they must be
appropriate for a call to exec; arbitrary shell code may not be used.
Should the actual daemon remain in the foreground so that the parent
parent process can wait() on it? Should the daemon make a PID file
in a known location?
The guide could expand on this a bit.
I hope James is listening out there and can comment on this. I think if
one really wanted to use an executable startupitem, I think
statupitem.pidfile could be used and that particular use isn't documented,
but probably because I didn't expect the need for it to ever occur, as it
has for dhcp. But as I said, if startupitm executable doesn't work in
default setup, then I see no further advantage in using it as opposed to a
script startupitem. Thanks for giving this attention.
Mark
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Subject: [32751] net/dhcp startupitem
Hi Mark,
So it looks like the bit magic that got this to work is the -f
command, which basically tells dhcpd not to daemonize, which would be
a good thing in our case, as the process of daemonizing would look to
daemondo or launchd as if dhcpd were exiting, which would cause the
constantly restarting behavior Blair described.
The startupitem.name spec should be completely redundant and unneeded;
the name will default to the name of the port, which is dhcpd, right?
Does that answer your question?
James
On Jan 13, 2008, at 1:25 PM, [EMAIL PROTECTED] wrote:
Blair,
I see. That's fine then. I just wanted to be sure there was a
reason for
making it a script startupitem and there is. I'm cc'ing James
(master of
all things startupitem) just in case he knows why the executable
startupitem type wasn't adequate in this case. It seems like it
should
have worked. Thanks for fixing the port.
Mark
On Jan 13, 2008, at 12:42 PM, Blair Zajac wrote:
Mark,
It works fine if I use this:
startupitem.create yes
startupitem.namedhcpd
startupitem.executable ${prefix}/sbin/dhcpd -f
startupitem.netchange yes
How's that?
Hi Mark,
I was seeing the following:
1) One dhcpd would start.
2) Every 10 seconds thereafter, another dhcpd would be started, but
it
couldn't bind to the port since the first one was running.
It appears that the startupitem infrastructure wasn't keeping track
of
dhcpd running and deamonizing itself.
I haven't read the guide yet.† What do you suggest?† Putting a -f to
dhcpd so it stays in the foreground?
Regards,
Blair
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
[EMAIL PROTECTED]
Subversion training, consulting and support
[
https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fwww.orcaware.com%2fsvn%2f
]http://www.orcaware.com/svn/
On Jan 13, 2008, at 12:11 PM, [EMAIL PROTECTED] wrote:
Hi Blair,
Executable startupitems are the preferred type.† Daemondo can track
pids
automatically and reliably restart an application if it quits.† See
the
guide on this:
[
https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fguide.macports.org%2f%23reference.startupitems
]http://guide.macports.org/#reference.startupitems
Given how startupitem executables work, I don't see an advantage to
reverting to a script startupitem.† Or is there something I am
missing
particular to dhcp?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New port needs commit
Luis O'Shea wrote: After the commit, I uninstalled asymptote, removed the reference to my local port hierarchy from sources.conf, and did a selfupdate. However port seemed to not find the new asymptote port: % port info asymptote Error: Port asymptote not found The PortIndex is regenerated and committed every 12 hours. Your port is in the repository, but hasn't made it into PortIndex at that time. As port info takes all infos from the PortIndex, it could not be found. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New port needs commit
Rainer Müller wrote:
Luis O'Shea wrote:
After the commit, I uninstalled asymptote, removed the reference to my
local port hierarchy from sources.conf, and did a selfupdate. However
port seemed to not find the new asymptote port:
% port info asymptote
Error: Port asymptote not found
The PortIndex is regenerated and committed every 12 hours. Your port is
in the repository, but hasn't made it into PortIndex at that time. As
port info takes all infos from the PortIndex, it could not be found.
By the way, one can cd into your
${prefix}/var/macports/sources/rsync.macports.org/release/ports and run
portindex by hand to update the index.
Blair
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
[EMAIL PROTECTED]
Subversion training, consulting and support
http://www.orcaware.com/svn/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New port needs commit
On Jan 13, 2008, at 4:02 PM, Luis O'Shea wrote:
After the commit, I uninstalled asymptote, removed the reference
to my local port hierarchy from sources.conf, and did a selfupdate.
Why did you do that? What did the entry that you removed look
like, and what lead you to the conclusion that you needed to remove
it in the first place?
My goal was to verify that the new asymptote Portfile functioned
correctly. While I was developing the Portfile my sources.conf
looked like
file:///Users/luis/macports/ports
rsync://rsync.macports.org/release/ports/
I see.
I assume that while the file:///... line precedes the
rsync:///..., port will pickup my copy of the Portfile rather than
the newly committed one. So I removed the first line and did a
selfupdate.
My mistake, I replied under the assumption you were working with a
stock MacPorts setup, which is just the rsync URL in sources.conf.
Nevertheless, it's still not necessary to remove (or comment out, for
that matter) your first entry pointing to your local/development ports
tree to test whether or not your submission made it to our rsync
server, since search, info and similar actions parse all
PortIndexes found; say you have nmap in both your local and in the
selfupdate'd tree, then (assuming both trees are in sources.conf, of
course) port search nmap should give you two results for that
particular port and port(1)'s -d flag reveals where each one belongs.
Two questions:
- What is the best description of the ports referenced by
file:///...? I called it my local port hierarchy, but I now
think this might be confusing. (It might mean my *copy* of rsync://
rsync.macports)
It could be whatever. It could be a read-only subversion checkout of
the ports tree, as an alternative to rsync; it could be your local
development tree; it could be both or maybe even something completely
different ;-).
The way I see it, the only two things that differentiate a file:.//
entry from the rsync:// one is that:
1) access to the latter is limited to rsync only, while access to the
former can vary;
2) we, The MacPorts Project, maintain the latter by refreshing it
periodically (every 30 minutes) and even regen'ing its index every 12
hours, while the former is entirely up to you... with one sole
exception: if the path for a file:// URL points to an svn checkout of
subversion's /trunk/dports, then port sync also takes care of
updating it.
- After developing a new Portfile, what is the best way to pick up
the newly committed Portfile? Should I leave sources.conf as is,
delete my Portfile (the one under file:///...) and re-portindex?
Depends on what you mean by pick up. If by that you mean distribute
to other users, then yes, they have to wait until the new index is
passed to the rsync server that feeds the sync selfupdate
operations. If on the other hand you mean local usage, then all you
have to do is cd into your dports dir and regen the index manually. In
short, as you can surely see, seeing the port basically pivots on
the index, so refreshing that is what you have to keep in mind.
See below for the source of my thick-headedness.
However port seemed to not find the new asymptote port:
% port info asymptote
Error: Port asymptote not found
But ${prefix}/var/macports/sources/rsync.macports.org/release/
ports/graphics/asymptote/Portfile does exist. I tried deleting $
{prefix}/var/macports/sources/rsync.macports.org/release/ports/
PortIndex and doing another selfupdate, but that did not help.
Entries in sources.conf point MacPorts to a valid PortIndex file,
from which ports and their info are gathered; if there are no
entries in sources.conf, no PortIndex will be found (regardless of
the file(s) actually existing on the local filesystem). In the case
of a stock MacPorts intallation, the rsync://rsync.macports.org/
release/ports/ URL is the only entry in the souces.conf file, and
it gets mapped locally to ${prefix}/var/macports/sources/
rsync.macports.org/release/ports/PortIndex as you infer.
Nevertheless, again, if you remove the entry from sources.conf the
corresponding index will not be found by MacPorts.
I'm curious as to what lead you to believe you needed to remove
the entry, in case it's something in our documentation that's
misleading you. In any case, the only thing you need to update your
local ports tree and get fresh search results is put the entry back
and issue a selfupdate regularly, plain and simple.
Duh! PortIndex is under version control -- I thought it was
generated locally after a sync.
Yes, every 12 hours on the box of one of our kind committers, Daniel;
from there it is committed to svn and then, on the next half hour,
pushed to the rsync server, from where both sync and selfupdate
will pull it in. Have a look at the /trunk/base/portmgr/jobs dir in
subversion for more info if
Re: [32697] trunk/dports/devel/icu/Portfile
Le 11 janv. 08 à 21:48, Ryan Schmidt a écrit :
On Jan 11, 2008, at 10:25, [EMAIL PROTECTED] wrote:
Revision: 32697
http://trac.macosforge.org/projects/macports/changeset/
32697
Author: [EMAIL PROTECTED]
Date: 2008-01-11 08:25:00 -0800 (Fri, 11 Jan 2008)
Log Message:
---
icu: Updated to 3.8.1.
Modified Paths:
--
trunk/dports/devel/icu/Portfile
Modified: trunk/dports/devel/icu/Portfile
===
--- trunk/dports/devel/icu/Portfile 2008-01-11 16:15:06 UTC (rev
32696)
+++ trunk/dports/devel/icu/Portfile 2008-01-11 16:25:00 UTC (rev
32697)
@@ -4,7 +4,8 @@
nameicu
set my_name icu4c
-version 3.8
+version 3.8.1
+set doc_version[join [lrange [split ${version} .] 0 1] _]
categories devel
platforms darwin freebsd
maintainers nox
@@ -25,20 +26,36 @@
distfiles [suffix ${distname}-src]
checksums [suffix ${distname}-src] \
-sha1 4370becc68eab7a01292db62e1649239b1732a5b \
-md5 67cc2650fbcae4c8e3ba5ce4dda4b072 \
-rmd160
e9a0105477b54e6d3f222bf7741a61058c70665b \
-${distname}-docs.zip \
+md5 a827dbc9d909febd4ec39b90386868ba \
+ sha1 c2b933aee6741c28956f1b87dc514dee49b949aa \
+ rmd160 d297330ff0eb91bff5ac91e59188f1751f899032 \
+ ${my_name}-${doc_version}-docs.zip \
+md5 677b218cbca2acc304b9771c63bd69bf \
sha1 94b47b5dd88bce15dab608719efbbd405d15e912 \
-md5 677b218cbca2acc304b9771c63bd69bf \
rmd160 927f4466758722e958b90a2bae873b11da222e88
worksrcdir ${name}/source
set docdir ${prefix}/share/doc/${name}-${version}
+post-patch {
+reinplace s;install_name ;install_name ${prefix}/lib/; $
{worksrcpath}/config/mh-darwin
+}
+
+configure.cmd ./runConfigureICU MacOSX
The portfile claims to work on the freebsd platform in addition to
darwin. Is this configure.cmd appropriate on FreeBSD?
I don't think so, thank you for noticing. I'll fix that.
configure.args --mandir=${prefix}/share/man \
--disable-samples
+# ICU wants to build with -O3, let's do as it wants.
+configure.cflags-delete -O2
+
+pre-configure {
+# The -delete statement above may lead to configure.cflags
variable being unset
+if {! [info exists configure.cflags]} {
+ configure.cflags
+}
+}
What you're doing here in the pre-configure phase, is this a
MacPorts base bug that needs to be fixed?
I think it is, or maybe not, as I've some uncommited patches
wandering around in my base/ repos.
I'll look into it.
--
Anthony Ramine, the Ports tree cleaning Maestro.
[EMAIL PROTECTED]
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New port needs commit
Luis O'Shea wrote: Two questions: - What is the best description of the ports referenced by file:///...? I called it my local port hierarchy, but I now think this might be confusing. (It might mean my *copy* of rsync://rsync.macports) I would call it an overlay. A term coming from my Gentoo experience. It describes, what it really is. Another ports tree which adds ports (which may lay over ports from the official ports tree). Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [32715] trunk/doc-new/guide/xml/portfile-keywords.xml
On 12/01/2008, at 10:24 AM, Ryan Schmidt wrote: I was led to believe that an epoch should never be decreased, ever, once it has been added to a portfile, even if the port's version is increased. I understood that the epoch takes precedence over the version. I'm pretty sure that that's still true; I haven't seen that part of the code altered. I noticed last year that netpbm failed to upgrade on my machine until I forced it because somebody removed the epoch line in an earlier revision, in which case epoch is assumed to be zero. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms at macports dot org ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Call for help testing 1.6.1 revamped postflight script
Sorry, meant to send this to macports-users ;-) But some testing from this audience wouldn't hurt either :-P -jmpp On Jan 14, 2008, at 1:17 AM, Juan Manuel Palacios wrote: As some of you may have seen, I've been improving the postflight script in the release_1_6 branch with the feedback I've received so far, plus some other relevant fixes/improvements. The final product is what will be in the 1.6.1 pkg installer, which I plan to upload to our website to replace the buggy 1.6.0 installers. I've tested it locally on both virgin and customized accounts, extensively, and have found it to work reliably so far. I'd now like to openly call for some wider testing in case I'm missing bugs that my environment is not surfacing. If you're up for it, please grab the script off this URL [1] and take it for a hard ride on whatever environment you can think of. I've tried to bullet-proof it for straight forward functionality in a default environment and to be as polite and non-disruptive as possible in a non-default one. Standard disclaimer applies about this code potentially having bugs that may disrupt your working environment, so do not use on a production machine/account if you can't afford any errors. For those of you wondering what I'm considering as a default environment, have a read at: http://guide.macports.org/#installing.binary.postflight.details That, plus the fact that I only do it for bash and tcsh shells, and the latter only as legacy support for Jaguar and previous accounts. I'm somewhat considering removing such support because tweaking tcsh configuration file has proven a tad difficult: 1) It's not easy to invoke a non-interactive, login tcsh shell session. In a nutshell, so far it has proven impossible for me. This limits my ability to properly test the environment to figure out what I need to add and what I don't, which takes me onto 2) below 2) It's not entirely clear to me whether I should write to ~/.tchsrc, ~/.cshrc or ~/.login (I've heard solid claims for all of them), barring my inability to properly test the environment; 3) barring 2), the form of the settings to be written varies (set foo = bar Vs. setenv foo bar); 4) I'm by no means a tcsh user, so all I can do is *guess* the best approach in unpleasant tcsh debugging sessions ;-) Various instances of 4), plus very kind help from both Eric Hall and Wilfredo Sanchez at times, have lead me to a combination of ~/.tcshrc with setenv foo bar statements, which I think works fairly well. But still, I'd love some experienced tcsh using eyes if available to shed some more light on this aspect of the script (thinking a bit more about it, resolving 1) above would probably solve this entire problem). So, without any further ado, I'd appreciate as much help I can get in testing this script and, in case of failure, getting detailed reports if possible. Success reports are also of course welcomed! Regards,... -jmpp [1] http://trac.macports.org/projects/macports/browser/branches/release_1_6/base/portmgr/dmg/postflight?format=ra ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Call for help testing 1.6.1 revamped postflight script
As some of you may have seen, I've been improving the postflight script in the release_1_6 branch with the feedback I've received so far, plus some other relevant fixes/improvements. The final product is what will be in the 1.6.1 pkg installer, which I plan to upload to our website to replace the buggy 1.6.0 installers. I've tested it locally on both virgin and customized accounts, extensively, and have found it to work reliably so far. I'd now like to openly call for some wider testing in case I'm missing bugs that my environment is not surfacing. If you're up for it, please grab the script off this URL [1] and take it for a hard ride on whatever environment you can think of. I've tried to bullet-proof it for straight forward functionality in a default environment and to be as polite and non-disruptive as possible in a non-default one. Standard disclaimer applies about this code potentially having bugs that may disrupt your working environment, so do not use on a production machine/account if you can't afford any errors. For those of you wondering what I'm considering as a default environment, have a read at: http://guide.macports.org/#installing.binary.postflight.details That, plus the fact that I only do it for bash and tcsh shells, and the latter only as legacy support for Jaguar and previous accounts. I'm somewhat considering removing such support because tweaking tcsh configuration file has proven a tad difficult: 1) It's not easy to invoke a non-interactive, login tcsh shell session. In a nutshell, so far it has proven impossible for me. This limits my ability to properly test the environment to figure out what I need to add and what I don't, which takes me onto 2) below 2) It's not entirely clear to me whether I should write to ~/.tchsrc, ~/.cshrc or ~/.login (I've heard solid claims for all of them), barring my inability to properly test the environment; 3) barring 2), the form of the settings to be written varies (set foo = bar Vs. setenv foo bar); 4) I'm by no means a tcsh user, so all I can do is *guess* the best approach in unpleasant tcsh debugging sessions ;-) Various instances of 4), plus very kind help from both Eric Hall and Wilfredo Sanchez at times, have lead me to a combination of ~/.tcshrc with setenv foo bar statements, which I think works fairly well. But still, I'd love some experienced tcsh using eyes if available to shed some more light on this aspect of the script (thinking a bit more about it, resolving 1) above would probably solve this entire problem). So, without any further ado, I'd appreciate as much help I can get in testing this script and, in case of failure, getting detailed reports if possible. Success reports are also of course welcomed! Regards,... -jmpp [1] http://trac.macports.org/projects/macports/browser/branches/release_1_6/base/portmgr/dmg/postflight?format=ra ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
