FreeBSD ports you maintain which are out of date

[portscout]

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, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
textproc/py-Chameleon   | 2.25| 3.0
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Большой Алтай via freebsd-ports]

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

ДАТЫ ПУТЕШЕСТВИЙ: 30 декабря-03 января, 30 декабря-05 января, 03-08  января, 
04-08 января, 04-10 января. ПОДРОБНОСТИ по тел. +79130669965, 8 (383)239-63-90

Что входит в стоимость тура 5 дней:

1.Проживание на турбазе + завтраки

2.Трансфер

3.Экскурсия на конях к ледяным водопадам

4.Внедорожник поездка в горы

5.Фотоохота на горных архаров

6.Тематическая вечеринка + квест

7.Путешествие по Чуйскому тракту (входит в 10-ку самых красивых дорог мира)

8.Баня+купание в незамерзающих озерах

СТОИМОСТЬ: 29900 руб. при оплате до 15 декабря – 24400 руб.

Что входит в стоимость тура 7 дней:

1.Проживание на турбазе + завтраки

2.Трансфер

3.Экскурсия на конях к ледяным водопадам

4.Внедорожник поездка в горы

5.Фотоохота на горных архаров

6.Тематическая вечеринка + квест

7.Путешествие по Чуйскому тракту (входит в 10-ку самых красивых дорог мира)

8. Баня + купание в незамерзающих озерах

9. + Поездка на озеро, где зимуют дикие лебеди-кликуны

10. + 2 дня горнолыжном комплексе

СТОИМОСТЬ: 31900 руб. при оплате до 15 декабря – 28600 руб.

Мы проводим путешествия круглогодично, туры на 5,7,10,11,15 и 17 дней. Вышлем 
по запросу программы на зиму, весну, лето и осень со скидками раннего 
бронирования.

Получить подробную программу консультацию можно здесь: 8 (383) 239-63-90, 
+79130669965 (WAP)

Пишите: altai3...@gmail.com

Пожалуйста, не отвечайте на это письмо по адресу, откуда оно пришло. Его 
рассылка была произведена через генератор писем, и мы не сможем прочитать Ваше 
письмо. Пишите, либо звоните на адреса, указанные выше.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

The ports collection has some serious issues

[Daniil Berendeev]

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:
* Why I use ports over pkg?
Because, generally, packages are built with poor default options, for
example moc isn't able to play .alac/.mod and that's frustrating.

* Why pkg is still nice?
It is able to update packages with broken ABI, it's fast and easy to
use. Some packages/ports don't have options and can be used via pkg by a
ports user.

I want to contribute to FreeBSD development, so, long story short, I've
decided to move to -CURRENT. Everything went fine except the ports upgrade.

Is it possible to upgrade the ports by hand? Well, it is, but it is not
too comfortable. Ports collection by itself doesn't provide a nice way
to work with port management, so a user needs to use something for port
management. As the handbook advised, I picked portmaster.

And here begin the problems.

1) portmaster is not nice for the user.
If it comes over an error even in one little tiny port that is a
dependency for something bigger , it will abort its work and leave all
the other ports not updated. So, if you try to to do `portmaster -af`,
you should not forget `-m DISABLE_VULNERABILITIES=yes` (we will return
to this one later) and you must pray to God for not coming around a
circular dependency or some port that would fail to deinstall its older
version. You can't leave portmaster for a night to update all the needed
ports and deal with broken ones in the morning, you need to cherry pick
the broken ports and ignore them, and then try to deal with them.

Although portmaster is not releated to the FreeBSD project and is an
outside tool, there aren't any alternatives from the project itself. So
use it or die. Not a nice situation.

2) pkg and ports are not in sync.
pkg appeals to build ports that are from 2xxxQx branches. The promoted
tool for syncing ports (portsnap) always fetches from head. And there is
no way to choose. That gives us the next problem:

3) no integration between ports and packages
There is no clear, easy way to use ports and packages simultaneously. If
I'd like to use some built packages to speed up port updates, I have to
ignore by hand all the packages that I want to be built as ports. It's
easier to stick to only ports or only packages.

4) uncomfortable way of rollback
If I want to rollback, or just choose the branch from where the packages
are built (to stay in sync with pkg), I have to pull the whole svn
repository.

5) svn repository.
I don't want to spark a holy war and I don't belong to those type of
people who are always obsessed that something isn't done in their way.
But guys, svn is not a good tool for ports. Just for one reason,
actually (as for me, I could tolerate anything else, but not this one)
-- size. The size of repository is 20G+ and growing. I don't want to
pull 20G+ in /usr/ports just because I need to use ports. It's just
sick. The repository is so big because, as all ya know, svn is expensive
in branch operations. Since you've began to do those 2xxxQx branches the
size of the repository began to grow rapidly. It's inefficient and
uncomfortable. For such a work something like git or mercurial should be
used, they'd fit in 3-4G.

6) broken ports are pushed to head
Why do we have such a situation, when head contains a handful of broken
ports? Why commit a port that won't build? It's sick.
Ports are broken in a different way. Some fail to build. Some fail to
uninstall their older version (like rust), so that you need to do
`pkg remove -f portname; portmaster portname`. Some have a circular
dependency (d-bus) and will try build until the heat death of the
universe. I just don't get it, why broken ports are pushed to head, if
head is then used by portsnap to update /usr/ports? You leave tons of
users with a broken setup. And there is always a bunch of ports that
won't build. It's not just one, or two, it's a handful of ports.
pkg-fall...@freebsd.org is overwhelmed with build fails.

7) No way to update ports with broken ABI.
I need to run `pkg update` and then pick the broken ports by hand. Or do
`portmaster -af`.

8) ports with vulnerabilities.
They exist in the tree and on build attempt they shout that they won't
build without DISABLE_VULNERABILITIES=yes. The catch is that there is
always a bunch of ports with vulnerabilities. So if you are doing a
fresh install, you have to install those nasty vulnerable ports anyways.
It causes you to do extra moves and doesn't add no security or safety.
There is no way to pick the latest safe version.

I hope that my mail will produce a productive discussion that will lead
to some good decisions for fixing these problems.

Make ports great again :).
-- 
Cheers~

PGP key fingerprint:
07B3 2177 3E27 BF41 DC65  CC95 BDA8 88F1 E9F9 CEEF

You can 

Re: Is there possible run a MacOS X binary

[Nilton Jose Rizzo]

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 IPC by noisy commentators and a religious aversion 
> to a technology perceived as having failed in the marketplace of ideas.
> 
> On Wed, Dec 7, 2016 at 10:45 Warner Losh  wrote:
> 
> > 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 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 would probably require a legal
> > copy
> >
> > > of Mac OS.
> >
> > >
> >
> > > So, no, there is no Mac OS emulator for FreeBSD. And I'd be surprised if
> >
> > > it ever happened.
> >
> >
> >
> > NetBSD has (or had) a macho image activator, which is the first step
> >
> > in this process. But Kevin is right that most of the functionality of
> >
> > MacOS isn't in the kernel, and you'd need a copy of MacOS to run it in
> >
> > emulation. Plus there's a lot of Mach code that MacOS depends on that
> >
> > has no simple counterparts in FreeBSD, and that would be a lot of work
> >
> > to make happen. It's one of the things that's a barrier to entry for a
> >
> > simple, straight forward launchd port, for example.
> >
> >
> >
> >
> >
> >
> >
> ___
> freebsd-curr...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


   Thankx for all comments.  I know and understood all difficult.
   
   I'll have to spend my money on the purchase a Machintosh machine.

---
/*
**Nilton José RizzoUFRRJ
**http://www.rizzo.eng.br  http://www.ufrrj.br
**http://lattes.cnpq.br/0079460703536198
**/

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Dimitry Andric]

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 
> QEMU
> environment and for that I tried to figure out to find some proper HOWTO.
> Searching via google ave some hints, but in questions which QEMU from ports 
> should be
> used, all leave me alone, so I tried
> 
> emulators/qemu
> emulators/qemu-devel
> emulators/qemu-static
> 
> emulators/qemu is known for me to fail since months and the days of 
> 11-CURRENT, there is a
> compiler error spit out with clang 3.8 and now 3.9. The very same for 
> qemu-devel (both
> ports used with standard options, no extras). See also Bug 214873
> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214873) and Bug 215100
> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215100).

I couldn't reproduce the compilation errors, it builds fine for me until
the link phase.


> I tried also emulators/qemu-static, but it also fails compiling on most 
> recent 12-CURRENT
> (as the others, too, also my poudriere environment, which has also CURRENT 
> jails) with
> 
> [...]
> /usr/bin/ld:../config-host.ld:14: syntax error
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> [...]

But this I *can* reproduce.  It appears qemu wants to set the text
segment start address, using the -Ttext-segment=0x6000 option to ld.

However, our base ld does not yet support this option, and then the
configure script tries to patch the default linker script using the
following construct:

  $ld --verbose | sed \
-e '1,/==/d' \
-e '/==/,$d' \
-e "s/[.] = [0-9a-fx]* [+] SIZEOF_HEADERS/. = $textseg_addr + 
SIZEOF_HEADERS/" \
-e "s/__executable_start = [0-9a-fx]*/__executable_start = 
$textseg_addr/" > config-host.ld

Unfortunately, it seems to run /usr/local/bin/ld in this case, and this
results in the following busted linker script line, which cannot be
parsed:

  PROVIDE (__executable_start = 0x6000SEGMENT_START("text-segment", 
0x08048000)); . = SEGMENT_START("text-segment", 0x08048000) + SIZEOF_HEADERS;

If it would use /usr/bin/ld instead, the patching would succeed, and
the line would become:

  PROVIDE (__executable_start = 0x6000); . = 0x6000 + SIZEOF_HEADERS;

which is probably what was intended.

Probably, the configure script needs to be patched to run base ld,
or use the same ld invocation for both checking the -Ttext-segment
option support and patching the linker script.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Is there possible run a MacOS X binary

[K. Macy]

>
>
>
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 perceived as having failed in the marketplace of ideas.



On Wed, Dec 7, 2016 at 10:45 Warner Losh  wrote:

> 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 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 would probably require a legal
> copy
>
> > of Mac OS.
>
> >
>
> > So, no, there is no Mac OS emulator for FreeBSD. And I'd be surprised if
>
> > it ever happened.
>
>
>
> NetBSD has (or had) a macho image activator, which is the first step
>
> in this process. But Kevin is right that most of the functionality of
>
> MacOS isn't in the kernel, and you'd need a copy of MacOS to run it in
>
> emulation. Plus there's a lot of Mach code that MacOS depends on that
>
> has no simple counterparts in FreeBSD, and that would be a lot of work
>
> to make happen. It's one of the things that's a barrier to entry for a
>
> simple, straight forward launchd port, for example.
>
>
>
>
>
>
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Is there possible run a MacOS X binary

[David Chisnall]

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 would probably require a legal copy
> of Mac OS.
> 

NetBSD started working on one, and had it at a state where it could run the 
Darwin version of XFree86 (which should give you some idea of how old it was), 
but it couldn’t run the Mac Window Server and I don’t think it’s maintained. 
It’s not very interesting, because you need all of the frameworks and programs 
from OS X for it to be useful, and the license prohibits using them in such a 
way (and even if you did get it to work, you wouldn’t be able to run Mac apps 
at the same time as X apps without running XQuartz, and at that point you may 
as well just run macOS).

There is a more recent project called Darling (https://www.darlinghq.org) that 
tries to run Mac apps on Linux using a custom Mach-O loader, bits of GNUstep, 
and some of their own stuff.  No one has ever tried using it on FreeBSD, to the 
best of my knowledge.  It’s GPLv3, so I’m not motivated to contribute to it 
(though it does incorporate some of my code in various places).

David



smime.p7s
Description: S/MIME cryptographic signature

Re: Is there possible run a MacOS X binary

[Warner Losh]

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 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 would probably require a legal copy
> of Mac OS.
>
> So, no, there is no Mac OS emulator for FreeBSD. And I'd be surprised if
> it ever happened.

NetBSD has (or had) a macho image activator, which is the first step
in this process. But Kevin is right that most of the functionality of
MacOS isn't in the kernel, and you'd need a copy of MacOS to run it in
emulation. Plus there's a lot of Mach code that MacOS depends on that
has no simple counterparts in FreeBSD, and that would be a lot of work
to make happen. It's one of the things that's a barrier to entry for a
simple, straight forward launchd port, for example.

Warner
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Is there possible run a MacOS X binary

[Matthieu Volat]

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 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 would probably require a legal copy
> of Mac OS.
> 
> So, no, there is no Mac OS emulator for FreeBSD. And I'd be surprised if
> it ever happened.
> 

You can have a look at darling  which aim to 
provide the macos(x) equivalent to wine (so, no kernel bits?), but given how 
I'm currently struggling with wine on FreeBSD, I would not bet this will work 
without some porting.

(Note that lots of parts of macos are closed source (frameworks, and aqua), so 
unlike linux, you can't just grab their libraries like that, and there's the 
problem of the display)

-- Matthieu


pgpIkKJUDSChk.pgp
Description: OpenPGP digital signature

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

[George Mitchell]

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 changes day by day, so making two
>>> machines from the same quarterly branch can give you different
>>> machines (making it useless for paying work)
>>>
>>> not to mention that if you use the quarterly pkg branch you run he
>>> risk of it completely changing if you happen to be unlucky enough to
>>> be doing it across a quarterly boundary. then you end up with a
>>> completely messed up system. (from experience).
>>>
> 
> If you are handling the burden of support for a customer then perhaps
> Poudriere and building internally is the best option. Then if you want
> to stay on an older quarterly because none of what you deploy to
> customers is impacted by security issues you can roll them at your own
> pace.
> 
>>> But the big question still remains..
>>>
>>> What do you think you are solving and why are they changing? shouldn't
>>> a snapshot be stable?
> 
> 
> Think releng compared to stable in the src repo rather than
> release/stable.  They change in the same fashion to get SA (in the form
> of VuXML) and errata worthy fixes.
> [...]

If only!  At least the current base releng does not arbitrarily
disappear every three months. -- George
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[O. Hartmann]

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 proper HOWTO. 
Searching via google ave some hints, but in questions which QEMU from ports 
should be
used, all leave me alone, so I tried

emulators/qemu
emulators/qemu-devel
emulators/qemu-static

emulators/qemu is known for me to fail since months and the days of 11-CURRENT, 
there is a
compiler error spit out with clang 3.8 and now 3.9. The very same for 
qemu-devel (both
ports used with standard options, no extras). See also Bug 214873
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214873) and Bug 215100
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215100).

I tried also emulators/qemu-static, but it also fails compiling on most recent 
12-CURRENT
(as the others, too, also my poudriere environment, which has also CURRENT 
jails) with 

[...]
/usr/bin/ld:../config-host.ld:14: syntax error
c++: error: linker command failed with exit code 1 (use -v to see invocation)
[...]

in several occurences.

At the moment I feel lost at this point, since the likelyhood of all ports 
failing is
either incompatibility with CURRENT/clang 3.9 or something is weird with my 
setup. But on
the other hand, my poudriere environment is setup a kind of "vanilla" - no 
extras, just
straight forward compiler options.

I need some advice here how to build QEMU on my on.

Pleas CC me, I do not subscribe "freebsd-ports" list. And please apoligize for
crossposting, but I didn't really know to which list this might could belong 
to. 

Thanks in advance for patience and advice,

Oliver


-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpQbTCiEPoXL.pgp
Description: OpenPGP digital signature

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

[Kurt Jaeger]

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.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Emanuel Haupt]

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
> would include this option by default. This way, one could use binary
> packages without compiling from /usr/ports.
> 
> Currently, I install in jails a binary package in that I created
> locally. However, updating always proposes to replace this package
> with the standard one due to changed options. I do not know of a way
> to avoid this other than through the creation of the dependent port
> as suggested here. If this not be a good idea, might you have any
> other suggestions?
> 
> Thank you, in advance.
> 
> -- 
> Alan Braslau
> 

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.

Emanuel
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"