Would be nice to be able to:
port echo portgroup:kde4
Also adding portgroup to output of port info.
Bradley Giesbrecht
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
On 2010-10-26 19:52 , Jeremy Lavergne wrote:
Have there been any plans to make use of a `curl -# ...` style
progress bar for the download/configure/install phases? This is for
the normal, non-verbose/non-debug output.
If I remember correctly such a style is not available from libcurl, but
Hi,
help2man upgrade failed, any ideas?
thanks
christof
NeoVIII:~ LPM$ sudo port -v upgrade outdated
Password:
--- Computing dependencies for help2man.
--- Configuring help2man
checking for perl... /opt/local/bin/perl
checking for module Locale::gettext... no
checking for msgfmt...
cd $prefix
grep -l PortGroup.*kde4.*\.[^1] ./*/*/Portfile
./audio/taglib-devel/Portfile
./audio/taglib-extras/Portfile
./graphics/qimageblitz/Portfile
./kde/amarok-devel/Portfile
./kde/amarok/Portfile
./kde/choqok/Portfile
./kde/digikam/Portfile
./kde/kdebase4-runtime/Portfile
On Oct 26, 2010, at 13:01, Rainer Müller wrote:
On 2010-10-26 19:52 , Jeremy Lavergne wrote:
Have there been any plans to make use of a `curl -# ...` style
progress bar for the download/configure/install phases? This is for
the normal, non-verbose/non-debug output.
If I remember correctly
Have there been any plans to make use of a `curl -# ...` style
progress bar for the download/configure/install phases? This is for
the normal, non-verbose/non-debug output.
If I remember correctly such a style is not available from libcurl, but
would have to be written manually using
On Oct 26, 2010, at 13:59, Jeremy Lavergne wrote:
Have there been any plans to make use of a `curl -# ...` style
progress bar for the download/configure/install phases? This is for
the normal, non-verbose/non-debug output.
If I remember correctly such a style is not available from libcurl,
Have there been any plans to make use of a `curl -# ...` style
progress bar for the download/configure/install phases? This is for
the normal, non-verbose/non-debug output.
If I remember correctly such a style is not available from libcurl, but
would have to be written manually using
Does this look like all that's needed to get MacPorts working again in the
[m]dmg phase?
dmg_privs.diff
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
On Oct 26, 2010, at 14:04, Jeremy Lavergne wrote:
You could have make do a dry run where it doesn't build, then compare that
list against where we are in the build output.
I didn't know it was possible to have make do a dry run.
man make:
-n, --just-print, --dry-run, --recon
So that could possibly be used for the build and destroot phases. For the
build phase, some trickery would have to be used when parallel building to
match things up.
On the scale of things I'm not sure there'd be a significant difference.
If there may then the extent of the trickery would
Would it be a good idea to setup functionality like revision so that port will
modify distname (or dist_subdir) to accommodate stealth updates?
stealth_update 1
It seems a little rigid doing everything by hand each time, and no real unified
way of handling it. For example, if you're using a
On Oct 26, 2010, at 14:34, michae...@macports.org wrote:
Revision: 72782
http://trac.macports.org/changeset/72782
Author: michae...@macports.org
Date: 2010-10-26 12:34:05 -0700 (Tue, 26 Oct 2010)
Log Message:
---
root: addresses ticket #26984.
Move qt4 portgroup
On Oct 26, 2010, at 5:34 PM, Ryan Schmidt wrote:
On Oct 26, 2010, at 14:34, michae...@macports.org wrote:
Revision: 72782
http://trac.macports.org/changeset/72782
Author: michae...@macports.org
Date: 2010-10-26 12:34:05 -0700 (Tue, 26 Oct 2010)
Log Message:
---
root:
I'm looking at tickets #23204, #23206, and #23208 -- all dealing with the fact
that ccache or distcc does not play nice with qt4-mac's configure routine. The
attached patches are simple to implement, and I have a version that will play
nice with ccache or distcc during configure. BUT: They
xmlto depends on texlive, which has caused some problems because it
adds annoyingly large dependency chains to some ports (see #26335
#26271) that use it to build documentation. Worse, texlive itself
depends on some ports that use xmlto, meaning that they need to push
documentation into a variant
16 matches
Mail list logo