On Thu, Sep 26, 2013 at 01:02:20AM +0200, Juan Francisco Cantero Hurtado wrote:
> On Wed, Sep 25, 2013 at 08:22:00AM +0100, Stuart Henderson wrote:
> > On 2013/09/25 03:48, Juan Francisco Cantero Hurtado wrote:
> > > On Wed, Sep 25, 2013 at 03:25:25AM +0200, Juan Francisco Cantero Hurtado
> > > wr
On Sun, Sep 22, 2013 at 10:49:14PM +0200, Juan Francisco Cantero Hurtado wrote:
> On 09/22/13 22:27, Stuart Henderson wrote:
> >On 2013/09/22 18:13, Juan Francisco Cantero Hurtado wrote:
> >>Makefile without ${V}, as requested by bcallah@, sthen@ and kirby@.
> >>
> >>I think the port is ready. I've
Hi Matthieu,
Matthieu Herrb wrote on Mon, Oct 07, 2013 at 10:25:36PM +0200:
> git 1.8.4 likes to put colors in its output, especially in 'git log'.
> But for historical reasons, I've LESS="-e -P%f (%pB\%)" in my
> environment. With those setups and TERM=xterm in an xterm, git log
> shows the con
David Hill [2013-09-24, 11:37:59]:
> Hello -
>
> This patch replaces rand() calls with arc4random(), which happens to fix
> a regress test. I also added --without-libnet to stop an ugly
> libnet-config not found on ./configure. Maybe we want to add it?
makes sense, i'll add your patches with th
David Hill [2013-09-24, 11:33:42]:
> update devel/libivykis to 0.39. Tested with syslog-ng.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/libivykis/Makefile,v
> retrieving revision 1.5
> diff -u -p -r1.5 Makefile
> --- Makef
Hi,
git 1.8.4 likes to put colors in its output, especially in 'git log'.
But for historical reasons, I've LESS="-e -P%f (%pB\%)" in my
environment. With those setups and TERM=xterm in an xterm, git log
shows the control sequences used to set colors instead.
Even setting LESS="" still produces
yes, so please mention sem_open in the patch file so grep can find it.
David Coppa wrote:
>On Mon, Oct 7, 2013 at 5:49 PM, Alexandr Shadchin
> wrote:
>
>> ImportError: This platform lacks a functioning sem_open
>implementation, therefore, the required synchronization primitives
>needed will not f
On 2013/10/07 13:26, Gabriel Guzman wrote:
>
> I'm working on a port of phabricator (phabricator.org), facebook's bug
> tracking, code review, wiki, etc software. They don't release any versions
> at the
> moment, or have any tags so I can't get a version number for my
> Makefile. I'm looking
results in make fetch-all creating a file called
> master.tar.gz, which is less than useful.
>
> I'm going to try the filename{url} approach to see if that works better,
> but then I'm not sure what to use as a number scheme for the version of
> phabricator... do I just make
I'm working on a port of phabricator (phabricator.org), facebook's bug
tracking, code review, wiki, etc software. They don't release any versions at
the
moment, or have any tags so I can't get a version number for my
Makefile. I'm looking for other examples of software like this in the
ports t
On Mon, Oct 7, 2013 at 5:49 PM, Alexandr Shadchin
wrote:
> ImportError: This platform lacks a functioning sem_open implementation,
> therefore, the required synchronization primitives needed will not function,
> see issue 3770.
as a side note, sem_open() will eventually hit openbsd in a
not-so
Hi!
After update to 1.8.0, meld does not work, because our python does not support
multiprocessing.Pool:
>>> import multiprocessing
>>> multiprocessing.Pool()
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.7/multiprocessing/__init__.py", line 232, in Pool
Has Jim moved address/on holiday/other?
On 2013-09-28 Sat 10:40 AM |, wrote:
> ping
>
> On 2013-09-21 Sat 12:47 PM |, wrote:
> > Jim,
> >
> > There's a minor mod of greyscanner on bitbucket.
> >
> > I'm totally new to bitbucket, mercurial & git, so don't know if you've
> > visability/aware of
* Tino Bonaccorso [2013-10-05 18:46:21 +]:
> Thanks much for tips and for writing pkg_check, problem resolved. And
> package was from ftp.openbsd.org .
>
It's a cool program isn't it. I was very impressed after it fixed loads of
problem in one run.
14 matches
Mail list logo
