On 2011-1-22 09:31 , Rainer Müller wrote:
> On 2011-01-21 21:41 , Bradley Giesbrecht wrote:
>> Why are the effects of -R not the default behavior?
>
> -R causes a forced rebuild of *all* dependents recursively and will
> cause lots of unnecessary builds. There is currently no way to tell if
> an u
On Jan 21, 2011, at 23:54, l...@macports.org wrote:
> Revision: 75335
> http://trac.macports.org/changeset/75335
> Author: l...@macports.org
> Date: 2011-01-21 21:54:09 -0800 (Fri, 21 Jan 2011)
> Log Message:
> ---
> p5-uri: adding overlooked lib dependency on p5-mime-base6
On Fri, Jan 21, 2011 at 05:25:46PM -0800, Bradley Giesbrecht wrote:
>
> On Jan 21, 2011, at 5:09 PM, Jeremy Lavergne wrote:
>
>>> Well it is there at...
>>>
>>> http://guide.macports.org/#development.local-repositories
>>>
>>> however that note should be enhanced to make the second point that
>>>
On Jan 21, 2011, at 5:09 PM, Jeremy Lavergne wrote:
Well it is there at...
http://guide.macports.org/#development.local-repositories
however that note should be enhanced to make the second point that
retention of local portfiles will
block the proper updating from the rsync.
What is the
On Fri, Jan 21, 2011 at 05:10:20PM -0800, Bradley Giesbrecht wrote:
>
> On Jan 21, 2011, at 4:49 PM, Jack Howarth wrote:
>
>> On Fri, Jan 21, 2011 at 07:40:10PM -0500, Jeremy Lavergne wrote:
Ugh. I never imagined port would behave in that way. Guess I'll
have to
constantly purge ou
On Jan 21, 2011, at 4:49 PM, Jack Howarth wrote:
On Fri, Jan 21, 2011 at 07:40:10PM -0500, Jeremy Lavergne wrote:
Ugh. I never imagined port would behave in that way. Guess I'll
have to
constantly purge out my local ports directory. Fink properly looks
in
each directory listed in its tree
> Well it is there at...
>
> http://guide.macports.org/#development.local-repositories
>
> however that note should be enhanced to make the second point that retention
> of local portfiles will
> block the proper updating from the rsync.
What is the intended behavior? Some may want their local
On Fri, Jan 21, 2011 at 07:40:10PM -0500, Jeremy Lavergne wrote:
> > Ugh. I never imagined port would behave in that way. Guess I'll have to
> > constantly purge out my local ports directory. Fink properly looks in
> > each directory listed in its tree list.
>
> I'd tongue-in-cheekly say RTFM, but
> Ugh. I never imagined port would behave in that way. Guess I'll have to
> constantly purge out my local ports directory. Fink properly looks in
> each directory listed in its tree list.
I'd tongue-in-cheekly say RTFM, but there are so many places that information
might be .. there really is no
On Jan 21, 2011, at 4:34 PM, Jack Howarth wrote:
> Ugh. I never imagined port would behave in that way. Guess I'll have to
> constantly purge out my local ports directory. Fink properly looks in
> each directory listed in its tree list.
s/properly/differently/
Please don't troll.
- Toby
___
On Sat, Jan 22, 2011 at 01:30:33AM +0100, Rainer Müller wrote:
> On 2011-01-22 01:21 , Jack Howarth wrote:
> > Your argument doesn't make sense. According to...
> >
> > http://trac.macports.org/changeset/74954
> >
> > the revision 1 change was committed on Jan 9th, whereas according to...
> >
> Why would revision 1 in /Users/howarth/ports override revision 2 in the
> rsync of portfiles in /opt/local? I can't imagine port was designed to behave
> in that fashion.
/Users/howarth/ports has higher priority than the
/opt/local/var/macports/source/.../ports/
Is there not documentation a
On Fri, Jan 21, 2011 at 04:27:07PM -0800, Toby Peterson wrote:
> On Jan 21, 2011, at 4:21 PM, Jack Howarth wrote:
>
> > On Fri, Jan 21, 2011 at 04:07:43PM -0800, Toby Peterson wrote:
> >> On Jan 21, 2011, at 3:14 PM, Jack Howarth wrote:
> >>
> >>> Does port leave an audit trail ala yum.log? I dou
On 2011-01-22 01:21 , Jack Howarth wrote:
> Your argument doesn't make sense. According to...
>
> http://trac.macports.org/changeset/74954
>
> the revision 1 change was committed on Jan 9th, whereas according to...
>
> http://trac.macports.org/changeset/75159
>
> The bump to revision 2 was do
On Jan 21, 2011, at 4:21 PM, Jack Howarth wrote:
> On Fri, Jan 21, 2011 at 04:07:43PM -0800, Toby Peterson wrote:
>> On Jan 21, 2011, at 3:14 PM, Jack Howarth wrote:
>>
>>> Does port leave an audit trail ala yum.log? I double checked and my local
>>> port directory for pymol had revision 1
>>> s
On Jan 21, 2011, at 7:02 PM, Jack Howarth wrote:
>
> I have a standard install with appears to use rsync. According to
> http://www.macports.org/install.php#svn
> the svn option is oriented towards developers. So what you are telling me is
> that the dependency
> mechanism of port is fragile fo
On Fri, Jan 21, 2011 at 04:07:43PM -0800, Toby Peterson wrote:
> On Jan 21, 2011, at 3:14 PM, Jack Howarth wrote:
>
> > Does port leave an audit trail ala yum.log? I double checked and my local
> > port directory for pymol had revision 1
> > so any previous builds of pymol would not have superced
On Fri, Jan 21, 2011 at 06:45:20PM -0500, Daniel J. Luke wrote:
> On Jan 21, 2011, at 6:43 PM, Jack Howarth wrote:
> >
> >> So then one of thee things happened:
> >>
> >> - There is some bug in port where pymol was rebuilt before libpng
> >> - pymol didn't have a dependency on libpng listed (whic
On Jan 21, 2011, at 6:37 PM, Jack Howarth wrote:
>
> I see from a google search that MacPorts lacks logging.
there are some logs, they may or may not provide the detail you want.
> Would it be that difficult to add
> a very simple logging facility (instead of the complex proposal from
> https
On Jan 21, 2011, at 6:43 PM, Jack Howarth wrote:
>
>> So then one of thee things happened:
>>
>> - There is some bug in port where pymol was rebuilt before libpng
>> - pymol didn't have a dependency on libpng listed (which would be a bug in
>> the pymol port)
>> - pymol wasn't rev-bumped (or was
On Fri, Jan 21, 2011 at 06:34:56PM -0500, Daniel J. Luke wrote:
> On Jan 21, 2011, at 6:21 PM, Jack Howarth wrote:
> >
> >>> Well if it does, the code must be buggy. When I did a 'sudo port
> >>> selfupdate'
> >>> and 'sudo port outdated', pymol ended up still linked against
> >>> libpng12.dyl
On Fri, Jan 21, 2011 at 06:14:49PM -0500, Jack Howarth wrote:
> On Fri, Jan 21, 2011 at 06:00:52PM -0500, Daniel J. Luke wrote:
> > On Jan 21, 2011, at 5:57 PM, Jack Howarth wrote:
> > >
> > > On Fri, Jan 21, 2011 at 05:06:45PM -0500, Daniel J. Luke wrote:
> > >> On Jan 21, 2011, at 4:09 PM, Jack
On Jan 21, 2011, at 6:21 PM, Jack Howarth wrote:
>
>>> Well if it does, the code must be buggy. When I did a 'sudo port
>>> selfupdate'
>>> and 'sudo port outdated', pymol ended up still linked against
>>> libpng12.dylib.
>>> I had to manually uninstall, clean, build and install pymol again
On Fri, Jan 21, 2011 at 03:04:26PM -0800, Bradley Giesbrecht wrote:
>
> On Jan 21, 2011, at 2:57 PM, Jack Howarth wrote:
>
>> On Fri, Jan 21, 2011 at 05:06:45PM -0500, Daniel J. Luke wrote:
>>> On Jan 21, 2011, at 4:09 PM, Jack Howarth wrote:
What insures that libpng is built before packa
On Fri, Jan 21, 2011 at 06:00:52PM -0500, Daniel J. Luke wrote:
> On Jan 21, 2011, at 5:57 PM, Jack Howarth wrote:
> >
> > On Fri, Jan 21, 2011 at 05:06:45PM -0500, Daniel J. Luke wrote:
> >> On Jan 21, 2011, at 4:09 PM, Jack Howarth wrote:
> >>>
> >>> What insures that libpng is built before pac
On Jan 21, 2011, at 2:57 PM, Jack Howarth wrote:
On Fri, Jan 21, 2011 at 05:06:45PM -0500, Daniel J. Luke wrote:
On Jan 21, 2011, at 4:09 PM, Jack Howarth wrote:
What insures that libpng is built before packages which depends-lib
on port:libpng if both are currently installed (at older versi
On Jan 21, 2011, at 5:57 PM, Jack Howarth wrote:
>
> On Fri, Jan 21, 2011 at 05:06:45PM -0500, Daniel J. Luke wrote:
>> On Jan 21, 2011, at 4:09 PM, Jack Howarth wrote:
>>>
>>> What insures that libpng is built before packages which depends-lib
>>> on port:libpng if both are currently installed (
On Fri, Jan 21, 2011 at 05:06:45PM -0500, Daniel J. Luke wrote:
> On Jan 21, 2011, at 4:09 PM, Jack Howarth wrote:
> >
> > What insures that libpng is built before packages which depends-lib
> > on port:libpng if both are currently installed (at older versions
> > or revisions) when 'port outdated
On Jan 21, 2011, at 2:31 PM, Rainer Müller wrote:
On 2011-01-21 21:41 , Bradley Giesbrecht wrote:
Why are the effects of -R not the default behavior?
-R causes a forced rebuild of *all* dependents recursively and will
cause lots of unnecessary builds. There is currently no way to tell if
an
On 2011-01-21 21:41 , Bradley Giesbrecht wrote:
> Why are the effects of -R not the default behavior?
-R causes a forced rebuild of *all* dependents recursively and will
cause lots of unnecessary builds. There is currently no way to tell if
an upgrade of a dependent is required.
Note also, a 'por
On Jan 21, 2011, at 12:46 PM, Dan Ports wrote:
On Fri, Jan 21, 2011 at 12:41:57PM -0800, Bradley Giesbrecht wrote:
Why would we have a different default behavior "port upgrade
outdated"
then for "port upgrade port1"?
It's no different. The piece you're probably missing is that `port
upgrade
On Jan 21, 2011, at 4:09 PM, Jack Howarth wrote:
>
> What insures that libpng is built before packages which depends-lib
> on port:libpng if both are currently installed (at older versions
> or revisions) when 'port outdated' is executed.
you've been told several times.
I suggest you read the co
On Fri, Jan 21, 2011 at 03:20:53PM -0500, Daniel J. Luke wrote:
> On Jan 21, 2011, at 3:04 PM, Bradley Giesbrecht wrote:
> >
> > On Jan 21, 2011, at 10:45 AM, Dan Ports wrote:
> >> Implicit in here is the assumption that you're always upgrading all of
> >> your outdated ports at once -- `port upgr
On Fri, Jan 21, 2011 at 12:41:57PM -0800, Bradley Giesbrecht wrote:
> Why would we have a different default behavior "port upgrade outdated"
> then for "port upgrade port1"?
It's no different. The piece you're probably missing is that `port
upgrade port1` also upgrades any of port1's dependencie
On Jan 21, 2011, at 12:20 PM, Daniel J. Luke wrote:
On Jan 21, 2011, at 3:04 PM, Bradley Giesbrecht wrote:
On Jan 21, 2011, at 10:45 AM, Dan Ports wrote:
Implicit in here is the assumption that you're always upgrading
all of
your outdated ports at once -- `port upgrade outdated`.
If you s
On Jan 21, 2011, at 3:04 PM, Bradley Giesbrecht wrote:
>
> On Jan 21, 2011, at 10:45 AM, Dan Ports wrote:
>> Implicit in here is the assumption that you're always upgrading all of
>> your outdated ports at once -- `port upgrade outdated`.
>>
>> If you saw a new version of libpng and decided you w
On Jan 21, 2011, at 10:45 AM, Dan Ports wrote:
Implicit in here is the assumption that you're always upgrading all of
your outdated ports at once -- `port upgrade outdated`.
If you saw a new version of libpng and decided you wanted to upgrade
it (for all of the exciting new features a graphics
On Fri, Jan 21, 2011 at 02:10:08PM -0500, Jack Howarth wrote:
>I not referring to that. Rather I am concerned about the case where
> libpng and a number of packages that require it are already installed.
> If the user does a 'sudo port selfupdate' and 'sudo port outdated', what
> insures that n
> I not referring to that. Rather I am concerned about the case where
> libpng and a number of packages that require it are already installed.
> If the user does a 'sudo port selfupdate' and 'sudo port outdated', what
> insures that none of the packages being upgraded aren't built before the
> ne
On Fri, Jan 21, 2011 at 10:45:36AM -0800, Dan Ports wrote:
> Implicit in here is the assumption that you're always upgrading all of
> your outdated ports at once -- `port upgrade outdated`.
>
> If you saw a new version of libpng and decided you wanted to upgrade
> it (for all of the exciting new f
Implicit in here is the assumption that you're always upgrading all of
your outdated ports at once -- `port upgrade outdated`.
If you saw a new version of libpng and decided you wanted to upgrade
it (for all of the exciting new features a graphics library can offer?)
but not all your other ports,
> All you need to do is 'make guide' in the doc-new directory. There is
> also a README.
>
> The Makefile expects the MacPorts installation in /opt/local to use
> xsltproc and for the docbook files. If you use a different prefix, use
> 'make PREFIX=/opt/path/to/macports guide'.
Perfect.
These ar
On 2011-01-21 18:44 , Jeremy Lavergne wrote:
> Is this available on the site somewhere, or will each person trying to make
> changes be left guessing how to do it properly?
All you need to do is 'make guide' in the doc-new directory. There is
also a README.
The Makefile expects the MacPorts inst
On 2011-1-22 04:44 , Jeremy Lavergne wrote:
> Is this available on the site somewhere, or will each person trying to make
> changes be left guessing how to do it properly?
Is what available?
___
macports-dev mailing list
macports-dev@lists.macosforge.or
> % make
> /bin/mkdir -p guide/html
> /bin/cp guide/resources/docbook.css guide/html/docbook.css
> /bin/cp guide/resources/images/* guide/html/
> /bin/ln -sfh /opt/local/share/xsl/docbook-xsl guide/resources/xsl
> /opt/local/bin/xsltproc --xinclude \
> --output guide/html/index.html \
>
On 2011-01-21 15:02 , Jack Howarth wrote:
>When I did a 'sudo port selfupdate' and 'sudo port outdated", the libpng
> and other packages
> were updated but the pymol wasn't. I am still unclear on how this mechanism
> can be certain to
> sequence properly. Since MacPorts lacks the ability to d
On Jan 21, 2011, at 9:02 AM, Jack Howarth wrote:
>
> When I did a 'sudo port selfupdate' and 'sudo port outdated", the libpng
> and other packages
> were updated but the pymol wasn't. I am still unclear on how this mechanism
> can be certain to
> sequence properly.
upgrade follows the depende
> Revision: 75235
> http://trac.macports.org/changeset/75235
> Author: snc at macports.org
> Date: 2011-01-18 10:43:45 -0800 (Tue, 18 Jan 2011)
> Log Message:
> ---
> guide: add extract.asroot
>
> Modified Paths:
> --
> trunk/doc-new/guide/xml/portfile-phase
On 2011-1-22 01:42 , Michael Dickens wrote:
> The variant +universal seems to have a special status among variants: If
> +universal is specified for building then 'port' will check all dependencies
> to make sure they are already installed as +universal (or cannot be) and if
> not try to upgrade
I haven't checked the dev list, but I'm sure this topic must have been
discussed before. So, apologies ... but, maybe it's time to re-discuss anyway?
The variant +universal seems to have a special status among variants: If
+universal is specified for building then 'port' will check all dependen
On Fri, Jan 21, 2011 at 01:53:04AM -0600, Ryan Schmidt wrote:
>
> On Jan 20, 2011, at 20:54, Jack Howarth wrote:
>
> > Is the current transition from png 1.2.x to 1.4.x the
> > conventional approach that MacPorts uses to handle soversion bumps?
>
> Yes, the current libpng 1.4 transition is rep
On 21 Ιαν 2011, at 10:34 π.μ., Joshua Root wrote:
> On 2011-1-21 19:11 , Panayotis Katsaloulis wrote:
>> Hello list!
>>
>> I am using a TK-based application (namely the mercurial "hg view" or, in
>> other words "hgk" application) for my everyday work.
>> In the past this application was using
On 2011-1-21 19:11 , Panayotis Katsaloulis wrote:
> Hello list!
>
> I am using a TK-based application (namely the mercurial "hg view" or, in
> other words "hgk" application) for my everyday work.
> In the past this application was using the X11 backend to present the
> graphics.
>
> Since a co
Hello list!
I am using a TK-based application (namely the mercurial "hg view" or, in other
words "hgk" application) for my everyday work.
In the past this application was using the X11 backend to present the graphics.
Since a couple of months this has changed and it is using the native graphics
54 matches
Mail list logo
