Re: replacing audio/libmpcdec by audio/musepack
On Saturday 29 May 2010 21:48:12 Alexey Shuvaev wrote: Not that I am using either of them but... libmpcdec is a stand-alone library while musepack depends on audio/esound. Is this dependency non-avoidable? Fortunately, the latest version doesn't depend on esound any longer. It installs some additional binaries, but I don't think that's a big issue. But your comment gave me a different idea that might be worthwile. If both ports are kept (i.e., libmpcdec containing the updated library, musepack just the tools), the upgrade path would be easier. Ports could be upgraded without manual intervention. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LPRng installation error using PORT_REPLACES_BASE_LPR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/05/2010 05:13:59, Wei Yang Tan wrote: Just to add on, next time if I want to deinstall (assuming make PORT_REPLACES_BASE_LPR=yes clean all install is successful), do I execute make PORT_REPLACES_BASE_LPR=yes deinstall? Yes. 'make deinstall' specifically checks that the current setting of $PREFIX matches the one with which the port was installed before it will run pkg_delete(1). Or you can run pkg_delete(1) outside the ports system, when it will delete the port you tell it to without such checks. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwCA4cACgkQ8Mjk52CukIxbKQCdHk6jCX+DVF9nzBCz6+vMmH/4 q/YAn2lItz6A7wWtBdULYuIOcuPGjvll =V3ji -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Building ports with stack-protector
On Sat, 29 May 2010, Garrett Cooper wrote: While this might be an interesting feature, I think that there must be a line drawn at what is and what isn't acceptable to maintain. Certainly so. Check and see whether or not a similar feature exists in other compilers. Based on a quick web search for clang stack-protector clang seems to have this feature. Maintaining this feature would be a pain though because it would require a lot more QA work beyond just seeing whether or not things build. I am not proposing that a switch from the current situation to having most ports build with stack-protector should be done overnight or quickly. This is simply not possible. It is very different from /usr/src. I am rather proposing that the port framework would have support for this feature so that individual port maintainers could enable it in their ports if they are confident that the port works fine with the stack-protector. This should be initially entirely optional, some time later it should be recommended for new/updated ports, and maybe after couple of years it could be made mandatory for ports to specify this. This would work as follows: 1. A port maintainer could specify USE_STACK_PROTECTOR=yes in their Makefile if they are confident that the port works with it. If they know that the port does not work with it, they could specify USE_STACK_PROTECTOR=no. If they do not know or care, they would not need to do anything. 2. An overly paranoid user could specify WITH_STACK_PROTECTOR=yes or WITH_STACK_PROTECTOR=no in /etc/make.conf according to their wishes (depending if they are paranoid about security or paranoid about port breakage). There should be a warning that WITH_STACK_PROTECTOR=yes is not supported and should be avoided by general users and that the knob should be left undefined before sending any problem reports. Based on these variables the port infrastructure would decide whether to add -fstack-protector to CFLAGS or not: Port Makefile USE_STACK_PROTECTOR yes undef no In /etc/make.conf: + WITH_STACK_PROTECTOR yes | yes yes no undef | yes no no no| no no no I hope that the above table displays somewhat correctly. Anyway the point is that no should be stronger in the decision logic than yes to avoid sudden breakage of a huge amount of ports. The example variable names in this post come just quickly from the top of my head, so please do not flame me for that at this point. I am just trying to illustrate how this logic could be made, instead of proposing the exact way how this should be implemented. Obviously more thought should be put in this before it could be implemented. That is the reason for my original post: to start thinking and discussing about it. This way some port maintainers could decide to introduce USE_STACK_PROTECTOR in their ports when they have time or interest in the issue. The decision yes/no would impose a bit more QA work on the port maintainers, but as it would be entirely optional, it should not be a real burden to anyone. The required changes in the port infrastructure (files in /usr/ports/Mk) would be quite trivial. I think the long term security benefits would far outweigh the burden of implementing this in the port infrastructure. In the long run this should also reduce the amount of existing but previously undiscovered stack overflow bugs in software in general because the bugs would be spotted more easily. I think a supported selection mechanism for this would be better than just sticking CFLAGS+= -fstack-protector in port Makefiles or make.conf. -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
DosBox upgrade failed.
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-aliasing -MT callback.o -MD -MP -MF .deps/callback.Tpo -c -o callback.o callback.cpp mv -f .deps/callback.Tpo .deps/callback.Po 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-aliasing -MT cpu.o -MD -MP -MF .deps/cpu.Tpo - c -o cpu.o cpu.cpp In file included from cpu.cpp:29: ../../include/setup.h:247: error: 'FILE' has not been declared ../../include/setup.h:280: error: 'FILE' has not been declared ../../include/setup.h:315: error: 'FILE' has not been declared *** Error code 1 Stop in /usr/ports/emulators/dosbox/work/dosbox-0.74/src/cpu. *** Error code 1 Stop in /usr/ports/emulators/dosbox/work/dosbox-0.74/src/cpu. *** Error code 1 Stop in /usr/ports/emulators/dosbox/work/dosbox-0.74/src. *** Error code 1 Stop in /usr/ports/emulators/dosbox/work/dosbox-0.74. *** Error code 1 Stop in /usr/ports/emulators/dosbox/work/dosbox-0.74. *** Error code 1 Stop in /usr/ports/emulators/dosbox. === make failed for emulators/dosbox === Aborting update === Update for dosbox-0.73_1 failed === Aborting update === Any idea to solve this ? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: DosBox upgrade failed.
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_SOURCE=1 -D_REENTRANT -O2 -pipe -march=native -fno-strict-aliasing -MT callback.o -MD -MP -MF .deps/callback.Tpo -c -o callback.o callback.cpp mv -f .deps/callback.Tpo .deps/callback.Po 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-aliasing -MT cpu.o -MD -MP -MF .deps/cpu.Tpo - c -o cpu.o cpu.cpp In file included from cpu.cpp:29: ../../include/setup.h:247: error: 'FILE' has not been declared ../../include/setup.h:280: error: 'FILE' has not been declared ../../include/setup.h:315: error: 'FILE' has not been declared *** Error code 1 Any idea to solve this ? Try to add 'include cstdio', if it's not help, use base gcc (4.2.1) instead of lang/gcc44. -- Adios ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: DosBox upgrade failed.
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/include - I/usr/local/include/SDL -I/usr/local/include -D_GNU_SOURCE=1 -D_REENTRANT -O2 -pipe -march=native -fno-strict-aliasing -MT callback.o -MD -MP -MF .deps/callback.Tpo -c -o callback.o callback.cpp mv -f .deps/callback.Tpo .deps/callback.Po 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-aliasing -MT cpu.o -MD -MP -MF .deps/cpu.Tpo - c -o cpu.o cpu.cpp In file included from cpu.cpp:29: ../../include/setup.h:247: error: 'FILE' has not been declared ../../include/setup.h:280: error: 'FILE' has not been declared ../../include/setup.h:315: error: 'FILE' has not been declared *** Error code 1 Any idea to solve this ? Try to add 'include cstdio', if it's not help, use base gcc (4.2.1) instead of lang/gcc44. My bad. I did not pay attention that gcc4 was installed buy another port. As Gcc4 knobs were still activated in /etc/make.conf: - .if exists(/usr/local/bin/gcc44) - Gcc4 was the the default compiler. disabling it did the trick. Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
On Sun, 30 May 2010 14:58:05 +0300, Volodymyr Kostyrko c.kw...@gmail.com
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-vesa x11-drivers/xf86-video-ati, everything else
compiles and works.
Assembler errors often aren't similar to each other, so fixing them may
be very easy or difficult. Hopefully we will fix them for big stuff like
xorg (not really as part of this GSoC project).
3. Big bunch of compile errors or config errors. This means incorrectly
written code, like not correctly declaring variables. This also means
some automake stupidities like testing c++ compiler with c style code -
for example clang++ refuses to compile int main(void) {}.
$ cat main.cc
int main(void) {}
$ clang main.cc -o test ./test echo No, it works.
No, it works.
Other than that, yes, many problems are related to insane configure
scripts.
4. Some ports specify that thay need at least gcc 3.3.
This is another of those insane configure scripts, testing for specific
version of specific compiler, rather than testing if it can compile
anything.
5. Some ports needs --dumpspecs.
It's a bit uglier than some ports:
$ grep dumpspecs /usr/ports/Mk/bsd.gecko.mk
GECKO_PTHREAD_LIBS!=${CC} -dumpspecs | ${GREP} -m 1 pthread: | ${SED} -e
's|^.*%{\!pg: %{pthread:|| ; s|}.*$$||' || ${TRUE}
audio/libmad - distorted sound
lang/python26 - compiling any gir dumps core
textproc/expat2 - dbus dumps core at launch
Python and expat shout i386 in my face, clang/llvm tends to not like
i386 too much. But I think few miscompilations were fixed recently,
so some of these may already be working fine.
And this all data is not current. It's one month old. Since then
dumpspecs was implemented. And maybe some other problems begone - I just
have not enough time to look at this thoroughly.
Some problems from a month ago are definitely gone, but I don't think
dumpspecs is one of them.
--
Andrius
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
Den 30/05/2010 kl. 14.51 skrev Andrius Morkūnas:
On Sun, 30 May 2010 14:58:05 +0300, Volodymyr Kostyrko c.kw...@gmail.com
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-vesa x11-drivers/xf86-video-ati, everything else
compiles and works.
Assembler errors often aren't similar to each other, so fixing them may
be very easy or difficult. Hopefully we will fix them for big stuff like
xorg (not really as part of this GSoC project).
3. Big bunch of compile errors or config errors. This means incorrectly
written code, like not correctly declaring variables. This also means
some automake stupidities like testing c++ compiler with c style code -
for example clang++ refuses to compile int main(void) {}.
$ cat main.cc
int main(void) {}
$ clang main.cc -o test ./test echo No, it works.
No, it works.
Other than that, yes, many problems are related to insane configure
scripts.
4. Some ports specify that thay need at least gcc 3.3.
This is another of those insane configure scripts, testing for specific
version of specific compiler, rather than testing if it can compile
anything.
5. Some ports needs --dumpspecs.
It's a bit uglier than some ports:
$ grep dumpspecs /usr/ports/Mk/bsd.gecko.mk
GECKO_PTHREAD_LIBS!=${CC} -dumpspecs | ${GREP} -m 1 pthread: | ${SED} -e
's|^.*%{\!pg: %{pthread:|| ; s|}.*$$||' || ${TRUE}
audio/libmad - distorted sound
lang/python26 - compiling any gir dumps core
textproc/expat2 - dbus dumps core at launch
Python and expat shout i386 in my face, clang/llvm tends to not like
i386 too much. But I think few miscompilations were fixed recently,
so some of these may already be working fine.
And this all data is not current. It's one month old. Since then
dumpspecs was implemented. And maybe some other problems begone - I just
have not enough time to look at this thoroughly.
Some problems from a month ago are definitely gone, but I don't think
dumpspecs is one of them.
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.
I think it would make it easier for lurkers to jump in and test things, and
help whittle away at the problems.
Thanks,
Erik
Ports on Clang
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.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
On Sun, 30 May 2010 16:36:45 +0300, Erik Cederstrand e...@cederstrand.dk 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 have all the known problems, just some of them. I think it would make it easier for lurkers to jump in and test things, and help whittle away at the problems. We will probably put some info there how we compile ports with clang in the near future. -- Andrius ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports on Clang [SOLVED]
On 30 May 2010 14:36, Chris Rees utis...@gmail.com 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 email: Andrius cmjrees, we'll probably update this page with the right way later today: http://wiki.freebsd.org/PortsAndClang So thanks Andrius, Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: RFT: netatalk-2.1
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 testing looks promising. There's one outstanding issue: upgrading from 2.0.5 to 2.1 appears to fail because of the wrong order of include paths. You can work around this by deinstalling 2.0.5 before building the new version. This work is also being tracked in PR#146576. I've uploaded new version which I believe to be committable: http://www.lassitu.de/freebsd/netatalk/netatalk_2.1.1-1.tar.bz2 I have not tested Kerberos support since I'm lacking the environment. If your system has IPv6 configured, you will need to configure a server each for IPv4 and IPv6. Note that both afpd and cnid_metad will by default bind to IPv6 addresses. The newest tarball 2.1.1-2 contains a patch to fix a segfault when having more than one afpd configured, thanks to Frank Lahm. To have afpd listen to both IPv4 and IPv6, you need to either have two server entries in afpd.conf, i.e.: - -tcp -noddp -ipaddr 0.0.0.0 -unixcodepage UTF8 -signature user:freebsd8 -cnid_server ::1 ipv6 -tcp -noddp -ipaddr :: -unixcodepage UTF8 -signature user:freebsd8 -cnid_server ::1 or set the sysctl net.inet6.ip6.v6only=0. Note that the latter might have negative security implications. Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
ports licenses
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 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. Regards, Rene -- http://www.rene-ladan.nl/ GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC (subkeys.pgp.net) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports licenses
On Sun, May 30, 2010 at 11:20 PM, Rene Ladan r...@freebsd.org 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.licenses.mk
# Case 2: license only known by the port (aka unknown).
#
# In this case LICENSE_{PERMS,NAME} are mandatory, in addition to
# either LICENSE_FILE or LICENSE_TEXT. Optional variables are
# LICENSE_{GROUPS,NOTES}.
--
Eitan Adler
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports licenses
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 LICENSE not being defined. I also see that there's now a bsd.licenses.mk and a bsd.licenses.db.mk in /usr/ports/Mk. I don't recall seeing those before, and don't know how long they've been there. Anyway, it looks like we're going ahead with this infrastructure, and I think that's a good thing. What actions do you need from me as a maintainer? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports licenses
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? Yesterday, while upgrading my installed ports, I noticed a message in the output about LICENSE not being defined. I also see that there's now a bsd.licenses.mk and a bsd.licenses.db.mk in /usr/ports/Mk. I don't recall seeing those before, and don't know how long they've been there. Anyway, it looks like we're going ahead with this infrastructure, and I think that's a good thing. What actions do you need from me as a maintainer? They are both fairly new constructs. I don't recall exact dates but they are new enough that the documentation for them has not caught up yet that I'm aware of. I'd wait until the Porter's Handbook is updated for further clarification on what to do. I'd also say that if you have a regular update planned for a port that you submit the license information with that. -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports licenses
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 info ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Issue with recent license infrastructure.
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 another name, say COPYING, post-extraction, and mentioning COPYING as LICENSE_FILE (in port Makefile), which then causes LICENSE file to be correctly generated and COPYING to be correctly copied. Thanks Ashish SHUKLA -- Sent via Gnus from GNU Emacs They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. -- Benjamin Franklin, Memoirs of the life and writings of Benjamin Franklin pgp8H2fFWUUfu.pgp Description: PGP signature
