I am soliciting opinions about the "safety" of py-pip package
management system. I am using Python primarily for scientific
computing/prototyping. Many of standard scientific python modules in our
ports tree are a bit outdated (trying to update some of those ports is
on my todo list as I am sure it
On Thu, Dec 13, 2012 at 02:52:52PM +0100, MERIGHI Marcus wrote:
> Hello Landry,
>
> while installing/configuring davical on a recent snapshot:
>
> OpenBSD 5.2-current (GENERIC) #93: Sun Dec 2 20:25:47 MST 2012
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
>
> I had to app
This fixes the pty handling and switches Eterm from setuid root to
setgid utmp.
The extent of my testing was limited to running Eterm and
"ls -l `tty`", "w", and "id" inside, so if anybody uses this,
please give it a try.
Index: Makefile
===
This diff updates Wordpress to 3.5. Tested an upgrade from the previous
version on amd64 with no issues.
Testers? oks?
-ME
Index: Makefile
===
RCS file: /cvs/ports/www/wordpress/Makefile,v
retrieving revision 1.42
diff -u -p -r1.42
This updates cyphertite to 1.4.3.
Please review and commit.
Thanks,
David
Index: Makefile
===
RCS file: /cvs/ports/sysutils/cyphertite/Makefile,v
retrieving revision 1.22
diff -N -u -p Makefile
--- Makefile7 Nov 2012 08:24:23 -0
On Thu, Dec 13, 2012 at 4:21 PM, Jasper Lievisse Adriaanse
wrote:
> If you're using i3, you're better of staying with 4.3p5 and not upgrade to
> 4.4. There are some serious issues with i3status and the statusbar icons.
>
> David, unless this gets fixed soon, revert the update?
>
I'll further inve
If you're using i3, you're better of staying with 4.3p5 and not upgrade to
4.4. There are some serious issues with i3status and the statusbar icons.
David, unless this gets fixed soon, revert the update?
On Thu, Dec 13, 2012 at 3:39 PM, Amit Kulkarni wrote:
>> No, our make is not ignoring -j, and it's passed to submakes. Using standard
>> posix mechanisms. That is, it's passed through the environment, using
>> MAKEFLAGS.
>>
>> There are two ways to defeat that mechanism: either by explicitly wipin
> No, our make is not ignoring -j, and it's passed to submakes. Using standard
> posix mechanisms. That is, it's passed through the environment, using
> MAKEFLAGS.
>
> There are two ways to defeat that mechanism: either by explicitly wiping
> out the environment, or by passing another -j somewhere.
On Thu, Dec 13, 2012 at 02:52:52PM +0100, MERIGHI Marcus wrote:
> Hello Landry,
>
> while installing/configuring davical on a recent snapshot:
>
> OpenBSD 5.2-current (GENERIC) #93: Sun Dec 2 20:25:47 MST 2012
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Is it with the c
Hello Landry,
while installing/configuring davical on a recent snapshot:
OpenBSD 5.2-current (GENERIC) #93: Sun Dec 2 20:25:47 MST 2012
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
I had to apply davical/dba/caldav_functions.sql as well to get any
functionality with thunde
Stuart Henderson writes:
> On 2012/12/04 22:38, Dennis Herrmann wrote:
> > [03] "warning: sprintf() is often misused, please use snprintf()"
>
> We're not patching these in ports unless there's a serious
> bug - feeding this type of fix upstream is usually the best course
> of actionhowever
>
>
On 12/12/2012 11:49 PM, Stuart Henderson wrote:
> anyone reading still using nagios on OpenBSD? please test and
> report back. "it compiles" ;)
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/nagios/nagios/Makefile,v
> retrievi
On Wed, Dec 12, 2012 at 09:32:23AM -0600, Kent R. Spillner wrote:
> Hey, dude-
>
> On Dec 12, 2012, at 7:51, David Coppa wrote:
> > Thanks.
> > I'll wait for useful pointers...
>
> I don't think CMake does anything specifically to handle parallel recursive
> builds. It works with GNU make beca
On Wed, Dec 12, 2012 at 06:21:43PM -0600, Amit Kulkarni wrote:
> >> > I thought you guys were talking about building cmake proper in parallel.
> >>
> >> We did. cmake proper first builds a minimal bootstrap cmake, then
> >> rebuilds itself with it, so getting cmake proper to build in parallel
> >>
I think we now have the critical path to libreoffice building quickly enough
that it's not going to reduce the overall dpb build time (the problem
DPB_PROPERTIES=parallel intends to solve is waiting for libreoffice to finish
when everything else is done. Moving to gmake may actually increase the
16 matches
Mail list logo
