Hi,
The buildbot seems to misbehave when force-building ports. See the
following example:
https://build.macports.org/builders/buildports-lion-x86_64/builds/26453
It says
The web-page 'force build' button was pressed by 'mojca
': force build ,
The web-page 'force build' button was pressed by 'dl
On Jan 19, 2015, at 5:17 AM, René J.V. Bertin wrote:
> I've asked this in the past because I also have run into this. It seems
> there's the idea that `port install -f` should do what we want, but it's
> never done that to me.
"sudo port -n upgrade --force" is the invocation you're looking for
On Jan 19, 2015, at 6:14 AM, René J.V. Bertin wrote:
> Is there or could we have an option to disable (or ask confirmation before)
> the automatic port clean when a portfile has changed?
There isn't such an option today. It seems like a bad idea to add such an
option.
> I know there's the -o
On 2015-1-20 04:05 , Mojca Miklavec wrote:
> On Mon, Jan 19, 2015 at 2:21 AM, Joshua Root wrote:
>> Hmm, that's unfortunate. Shree, could you clean up any stray ncurses
>> port contents please?
>
> It took me a couple of attempts, but I believe that I managed to
> remove the leftovers from the bui
On Jan 16, 2015, at 11:40 AM, Vincent Habchi wrote:
>>> -master_siteshttps://gforge.inria.fr/frs/download.php/34150
>>> +master_sites
>>> https://gforge.inria.fr/frs/download.php/file/34403/CGAL-4.5.1.tar.bz2
>>
>> master_sites should be the directory the distfile is in, and shou
> On Jan 19, 2015, at 1:26 PM, m...@macports.org wrote:
>
> Revision
> 131841
> Author
> m...@macports.org
> Date
> 2015-01-19 11:26:09 -0800 (Mon, 19 Jan 2015)
> Log Message
>
> charm(-qt5): new port for qt[45] (Thanks, Rene: see issue #46575)
> Added Paths
>
> • trunk/dports/office/char
> On Jan 19, 2015, at 11:32 AM, ebori...@macports.org wrote:
>
> Revision
> 131831
> Author
> ebori...@macports.org
> Date
> 2015-01-19 09:32:11 -0800 (Mon, 19 Jan 2015)
> Log Message
>
> py-h5py: Update to 2.4.0.
> Modified: trunk/dports/python/py-h5py/Portfile (131830 => 131831)
> # Support
On 1/19/15 9:42 AM, Jeremy Huddleston Sequoia wrote:
Don't we need to set destroot-args as well, or was the bug that necessitated
that (rebuilding the gir during destroot phase) fixed?
Index: gobject_introspection-1.0.tcl
===
--- g
On Monday January 19 2015 15:41:13 Lawrence Velázquez wrote:
> What purpose does it serve to include target header paths while compiling?
Beats me too.
Well, not entirely. Qt has been moving away from a single monolithic build to
separate components, and indeed if you look at the Debian packagi
On Jan 19, 2015, at 6:01 AM, René J.V. Bertin wrote:
> As I mentioned before, Qt 5.4.0 has an issue building if Qt 5.3.2 is present
> in the destination: one of its components includes the target header path in
> the compiler header search path list, and then chokes when it includes a
> header
On Monday January 19 2015 12:22:13 Brandon Allbery wrote:
> On Mon, Jan 19, 2015 at 12:14 PM, Mojca Miklavec wrote:
>
> > Does one need the server edition of 10.5 to be able to install it in a
> > virtual machine?
> >
>
> Yes.
No. To have the right, yes. ;)
R.
Don't we need to set destroot-args as well, or was the bug that necessitated
that (rebuilding the gir during destroot phase) fixed?
Index: gobject_introspection-1.0.tcl
===
--- gobject_introspection-1.0.tcl (revision 131831)
++
On Mon, Jan 19, 2015 at 12:14 PM, Mojca Miklavec wrote:
> Does one need the server edition of 10.5 to be able to install it in a
> virtual machine?
>
Yes.
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb.
On Mon, Jan 19, 2015 at 4:55 PM, Mihai Moldovan wrote:
> On 19.01.2015 04:37 PM, Thibaut Paumard wrote:
>> Le 15/01/2015 20:24, René J.V. Bertin a écrit :
>>> On Thursday January 15 2015 19:25:38 Mojca Miklavec wrote:
>>>
So I'm still stuck with gcc-4.2-only at the moment.
I'm not as
On Mon, Jan 19, 2015 at 2:21 AM, Joshua Root wrote:
> Hmm, that's unfortunate. Shree, could you clean up any stray ncurses
> port contents please?
It took me a couple of attempts, but I believe that I managed to
remove the leftovers from the buildbot for Lion, so there should be no
need for any im
Le 19/01/2015 16:55, Mihai Moldovan a écrit :
> On 19.01.2015 04:37 PM, Thibaut Paumard wrote:
>> Le 15/01/2015 20:24, René J.V. Bertin a écrit :
>>> On Thursday January 15 2015 19:25:38 Mojca Miklavec wrote:
>>>
So I'm still stuck with gcc-4.2-only at the moment.
I'm not asking for
On Monday January 19 2015 16:55:13 Mihai Moldovan wrote:
> > Debian's default on powerpc is gcc 4.9.2:
>
> What about Minix? FreeBSD? GNU HURD?
What about them?
> Seriously, the FSF compiler won't cut it on OS X. Just as one example,
> it can't produce fat binaries (i.e., binaries with multiple
On 19.01.2015 04:37 PM, Thibaut Paumard wrote:
> Le 15/01/2015 20:24, René J.V. Bertin a écrit :
>> On Thursday January 15 2015 19:25:38 Mojca Miklavec wrote:
>>
>>> So I'm still stuck with gcc-4.2-only at the moment.
>>>
>>> I'm not asking for libc++ on PPC. I know that this might require quite
>>
On 2015-01-18 12:22, jerryy...@gmail.com wrote:
> Okay, thanks Ryan and Josh for clarifying. I was confused by two
> separate issues which led me to a wrong conclusion. I can use
> autoreconf though it seems like overkill in this situation.
autoreconf is just running a few more tools such as aut
On Monday January 19 2015 09:24:21 Daniel J. Luke wrote:
> > I know there's the -o option, but the times I tried it it's often given me
> > hard-to-describe side-effects.
>
> maybe it would make sense to describe/debug/fix these side effects?
It would, if I could. I'd have to start using -o aga
Le 15/01/2015 20:24, René J.V. Bertin a écrit :
> On Thursday January 15 2015 19:25:38 Mojca Miklavec wrote:
>
>> So I'm still stuck with gcc-4.2-only at the moment.
>>
>> I'm not asking for libc++ on PPC. I know that this might require quite
>> a bit of effort, but I would like to know if *any* s
On 1/18/15 5:35 PM, Ryan Schmidt wrote:
On Jan 18, 2015, at 5:22 AM, jerryy...@gmail.com wrote:
On 1/18/15 1:15 AM, Joshua Root wrote:
On 2015-1-18 18:37 , jerryy...@gmail.com wrote:
I am working on a portfile for libressl. I set some options like so:
use_autoconfyes
use_automakeye
> On Jan 19, 2015, at 7:14 AM, René J.V. Bertin wrote:
> Is there or could we have an option to disable (or ask confirmation before)
> the automatic port clean when a portfile has changed?
> I know there's the -o option, but the times I tried it it's often given me
> hard-to-describe side-effect
> On Jan 18, 2015, at 8:21 PM, Joshua Root wrote:
> I don't think there's any easy way to maintain consistency between the
> registry and the filesystem in the face of rebooting at just the wrong time.
if we record some sort of 'activate in progress' marker somewhere before we
start activate, an
Hi,
Since we're discussing the way MacPorts does its stuff internally ... :)
Is there or could we have an option to disable (or ask confirmation before) the
automatic port clean when a portfile has changed?
I know there's the -o option, but the times I tried it it's often given me
hard-to-descr
On 2015-1-19 20:41 , Jeremy Huddleston Sequoia wrote:
> In the past, if I've needed to rebuild a port with different settings, I've
> just uninstalled it first and then re-installed. For instance, the ppc
> section of my libc++ guide has the user take the following steps to uninstall
> the inte
Hi,
I believe that we are ready to make the transition to 5.20 as the
default version of Perl in MacPorts.
There is a small number of ports that still lack support for 5.20. But
that's about 1-2% of all ports only, and many of them are lacking
support just because they are broken under 5.16 anywa
In the past, if I've needed to rebuild a port with different settings, I've
just uninstalled it first and then re-installed. For instance, the ppc section
of my libc++ guide has the user take the following steps to uninstall the
intel-only ports that were required to bootstrap the compiler and
28 matches
Mail list logo
