FreeBSD ports you maintain which are out of date

Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated,

НОВЫЙ ГОД В ГОРАХ АЛТАЯ, 5 или 7 дней со скидкой 20%

Через весь Алтай, к самой границе с Монголией! Елка, наряженная прямо в лесу, теплый кедровый дом, ароматный глинтвейн, треск костра, сотни падающих звезд, поездка к ледяным водопадам, конное восхождение на перевал, незамерзающие озера, где зимуют лебеди, горнолыжный курорт. Настоящее

The ports collection has some serious issues

Hello guys! First of all, it's not a hate mail, I appreciate all the work done on the system and I enjoy using FreeBSD every day. But after some recent experience I'd like to point out some problems that make using the ports collection uncomfortable and painful. Some overview before we start: *

Re: Is there possible run a MacOS X binary

Em Wed, 07 Dec 2016 18:57:36 +, K. Macy escreveu > > > > > > > A MachO activator is indeed not useful without an OSX install. > > But let's be honest, Mach IPC is a loadable kernel module requiring > no real kernel changes. It's not upstreamable because of a general poor > understanding of

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

On 07 Dec 2016, at 10:42, O. Hartmann wrote: > > I try my first steps in cross compiling ports with poudriere and therefore I > try to setup > an appropriate jail and QEMU environment. > > Well, I'm failing at the jail setup due to the non-exitence of any suitable >

Re: Is there possible run a MacOS X binary

> > > A MachO activator is indeed not useful without an OSX install. But let's be honest, Mach IPC is a loadable kernel module requiring no real kernel changes. It's not upstreamable because of a general poor understanding of IPC by noisy commentators and a religious aversion to a technology

Re: Is there possible run a MacOS X binary

On 5 Dec 2016, at 19:31, Kevin P. Neal wrote: > >> Is there any emulator like linuxator to run Mac OS X binaries, or >> is ther any licensing problem? > > It may be possible to make an emulator for Darwin (the OS that Mac OS sits > on top of), but an emulator for Mac OS

Re: Is there possible run a MacOS X binary

On Mon, Dec 5, 2016 at 12:31 PM, Kevin P. Neal wrote: > On Mon, Dec 05, 2016 at 02:49:07PM -0300, Nilton Jose Rizzo wrote: >> >> >> Sorry for cross posting (-current and -ports) >> >> >> Is there any emulator like linuxator to run Mac OS X binaries, or >> is ther any

Re: Is there possible run a MacOS X binary

On Mon, 5 Dec 2016 14:31:06 -0500 "Kevin P. Neal" wrote: > On Mon, Dec 05, 2016 at 02:49:07PM -0300, Nilton Jose Rizzo wrote: > > > > > > Sorry for cross posting (-current and -ports) > > > > > > Is there any emulator like linuxator to run Mac OS X binaries, or > > is

Re: what is the purpose of the quarterly ports branches?

On 12/06/16 21:59, Jason Unovitch wrote: > On Mon, Dec 05, 2016 at 10:48:20PM +, Ben Woods wrote: >> On Tue., 6 Dec. 2016 at 4:44 am, Julian Elischer wrote: >> >>> they are effectively useless because the results are not archived, and >>> the quarterly pkg branch actually

emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

Hello out there. I try my first steps in cross compiling ports with poudriere and therefore I try to setup an appropriate jail and QEMU environment. Well, I'm failing at the jail setup due to the non-exitence of any suitable QEMU environment and for that I tried to figure out to find some

Re: making ICONV default net/rsync option (was: Re: rsync port)

Hi! > I agree that the ICONV options is indeed very useful. I wouldn't mind > turning it on by default rather than creating an extra slave port. > After all it is a standard configure option and not a third party patch. > > I'm cc'ing ports@ for discussion. I have ICONV ON for our repos, too.

making ICONV default net/rsync option (was: Re: rsync port)

Alan Braslau wrote: > Hello, > > The iconv option of the rsync port is extremely useful, indeed > necessary when exchanging files with systems that have different > encoding (such as MacOS). > > It might be useful to create a dependent port, net/rsync-iconv, that >