Hi all,
I got the following issue, upgrading Dosbox to the 0.74 release:
===
Making all in core_dynrec
g++44 -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/usr/local/include -
I/usr/local/include/SDL -I/usr/local/include -D_GNU_SOURCE=1 -D_REENTRANT -O2
-pipe -march=native -fno-strict-alias
On Sun, May 30, 2010 at 10:58:42AM +0200, David Marec wrote:
> I got the following issue, upgrading Dosbox to the 0.74 release:
>
> ===
> Making all in core_dynrec
> g++44 -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/usr/local/include -
> I/usr/local/include/SDL -I/usr/local/include -D_GNU_SOU
Le dimanche 30 mai 2010 12:21:13, Alex Kozlov a écrit :
> On Sun, May 30, 2010 at 10:58:42AM +0200, David Marec wrote:
> > I got the following issue, upgrading Dosbox to the 0.74 release:
> >
> > ===
> > Making all in core_dynrec
> > g++44 -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/usr/local
On Sun, 30 May 2010 14:58:05 +0300, Volodymyr Kostyrko
wrote:
1. __dso not found after link. Some symbols seems to be omitted from
libraries and linking of plugins fails badly.
Known problem with known fix.
2. Assembler errors. Xorg has some in x11-servers/xorg-server
x11-drivers/xf86-video-
Den 30/05/2010 kl. 14.51 skrev Andrius Morkūnas:
> On Sun, 30 May 2010 14:58:05 +0300, Volodymyr Kostyrko
> wrote:
>> 1. __dso not found after link. Some symbols seems to be omitted from
>> libraries and linking of plugins fails badly.
> Known problem with known fix.
>
>> 2. Assembler errors.
Dear All,
I'm following the Clang discussions with interest; is there a 'proper'
way to test and mark a port as Clang compatible? I'd love to do that
with my ports at least...
Thanks,
Chris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebs
On Sun, 30 May 2010 16:36:45 +0300, Erik Cederstrand
wrote:
Andrius, would it make sense to create e.g. a wiki page tracking the status and
current known problems with compiling ports with clang? Just like there's a
wiki page ClangBSD status.
http://wiki.freebsd.org/PortsAndClang
It doesn't
On 30 May 2010 14:36, Chris Rees wrote:
> Dear All,
>
> I'm following the Clang discussions with interest; is there a 'proper'
> way to test and mark a port as Clang compatible? I'd love to do that
> with my ports at least...
>
> Thanks,
>
> Chris
>
>From an IRC discussion minutes after this emai
Am 28.05.2010 um 08:27 schrieb Stefan Bethke:
> Am 22.05.2010 um 19:08 schrieb Stefan Bethke:
>
>> Hi,
>>
>> I'm working on updating the net/netatalk port from 2.0.5 to 2.1. You can
>> find the most current version of my work at
>> http://www.lassitu.de/freebsd/netatalk/
>>
>> Initial testin
Hi,
While adding license information to my ports (to be committed), I
stumbled upon the following:
* devel/argouml uses Eclipse Public License (EPL) 1.0, but this one is
not in bsd.licenses.db.mk
* lang/bas2tap uses some homebrew license, but it has no formal name, so
LICENSE_NAME cannot be forma
On Sun, May 30, 2010 at 11:20 PM, Rene Ladan wrote:
...
> * lang/bas2tap uses some homebrew license, but it has no formal name, so
> LICENSE_NAME cannot be formally set.
>
> I think the first one can be added to bsd.license.db.mk, but I'm not
> sure what to do about the second one.
from bsd.licen
On Sun 30 May 2010 at 13:20:55 PDT Rene Ladan wrote:
Hi,
While adding license information to my ports (to be committed), I
stumbled upon the following:
Is this something all maintainers should be doing?
Yesterday, while upgrading my installed ports, I noticed a message in
the output about
On Sun, May 30, 2010 at 02:29:45PM -0700, Charlie Kester wrote:
> On Sun 30 May 2010 at 13:20:55 PDT Rene Ladan wrote:
> >Hi,
> >
> >While adding license information to my ports (to be committed), I
> >stumbled upon the following:
>
> Is this something all maintainers should be doing?
>
> Yeste
On Sun 30 May 2010 at 14:40:38 PDT Wesley Shields wrote:
I'd also say that if you have a regular update planned for a port that
you submit the license information with that.
Yeah, phasing it in along with other work makes sense.
/visions of 20,000+ new PR's doing nothing but adding LICENSE in
Hi,
I noticed there is an issue with the license infrastructure recently
introduced in the ports tree. If the LICENSE_FILE (in port Makefile) points to
a file named LICENSE, then package generation fails, and also correct license
file fails to copy.
As a workaround, I've to copy LICENSE file to a
15 matches
Mail list logo