replacing audio/libmpcdec by audio/musepack
Hi,
I'm the maintainer of audio/musepack. With the last update, it now provides
libmpdec.so. About 15 ports currently use the older shared library provided by
audio/libmpcdec (maintained by multimedia@, CCed).
For now, mutual CONFLICTS are registered.
What I'm planning to do is update all depending ports to use audio/musepack,
thus making audio/libmpcdec obsolete.
I have some questions before I'll start working on this task:
- Are there any objections to deprecating libmpcdec and replacing it by
musepack? According to the website, libmpcdec version is "Old. Refer to above
SV8 lib (compatible with SV7)".
After creating a patch for updating and testing:
- Should I ask the maintainers of the affected ports for approval?
I've tested musicpd and vlc so far and update was pretty straight-forward:
replace
LIB_DEPENDS+= mpcdec.5:${PORTSDIR}/audio/libmpcdec
by
LIB_DEPENDS+= mpcdec.7:${PORTSDIR}/audio/musepack
and bump the port revision.
Because both ports conflict, upgrading needs manual intervention. I guess I
should prepare an entry for UPDATING?
Anything I forgot or other thoughts?
--
Stefan
___
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"
LPRng installation error using PORT_REPLACES_BASE_LPR
Hi! I tried to install the port /usr/ports/sysutils/LPRng by executing the command: "make PORT_REPLACES_BASE_LPR=yes clean all install" based on the Makefile suggestion. However, I receive the following error which occurs after installing the /usr/lib: ===> Installing rc.d startup script(s) install: /usr/etc/rc.d/lprng: No such file or directory *** Error code 71 It seems like it cannot find the directory /usr/etc. Should it be using the directory /etc or do I need to create a new directory /usr/etc/rc.d? Thanks for your help _ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 ___ 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: replacing audio/libmpcdec by audio/musepack
On Sat, May 29, 2010 at 12:50:30PM +0200, Stefan Ehmann wrote:
> Hi,
>
> I'm the maintainer of audio/musepack. With the last update, it now provides
> libmpdec.so. About 15 ports currently use the older shared library provided
> by
> audio/libmpcdec (maintained by multimedia@, CCed).
>
> For now, mutual CONFLICTS are registered.
>
> What I'm planning to do is update all depending ports to use audio/musepack,
> thus making audio/libmpcdec obsolete.
>
>
> I have some questions before I'll start working on this task:
>
> - Are there any objections to deprecating libmpcdec and replacing it by
> musepack? According to the website, libmpcdec version is "Old. Refer to above
> SV8 lib (compatible with SV7)".
>
> After creating a patch for updating and testing:
> - Should I ask the maintainers of the affected ports for approval?
>
> I've tested musicpd and vlc so far and update was pretty straight-forward:
> replace
> LIB_DEPENDS+= mpcdec.5:${PORTSDIR}/audio/libmpcdec
> by
> LIB_DEPENDS+= mpcdec.7:${PORTSDIR}/audio/musepack
> and bump the port revision.
>
>
> Because both ports conflict, upgrading needs manual intervention. I guess I
> should prepare an entry for UPDATING?
>
> Anything I forgot or other thoughts?
>
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?
0.02$,
Alexey.
___
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: games/oneko-sakura conflicts with games/oneko
On Fri, May 28, 2010 at 07:05:42PM +0200, Demelier David wrote: > >Just a little issue to fix with games/oneko-sakura, the both ports install >the same binary and man, you can install both on your machine but only one >/usr/local/bin/oneko will appears. > >I propose to add a little CONFLICTS entry, what do you think? > >1. install games/oneko >2. install games/oneko-sakura >3. pkg_delete oneko-1\* (games/oneko) >4. pkg_delete oneko\* >pkg_delete: file '/usr/local/man/man6/oneko.6.gz' doesn't exist >pkg_delete: file '/usr/local/bin/oneko' doesn't exist >^ Good catch. I've added mutual CONFLICTS. -- Shaun Amott // PGP: 0x6B387A9A "A foolish consistency is the hobgoblin of little minds." - Ralph Waldo Emerson ___ 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"
Building ports with stack-protector
Hi, Big thanks to the folks who made "make buildworld" to use -fstack-protector by default since 8.0. This should make FreeBSD more secure. How about the ports system? I tried to re-build all my ports some time ago with the stack-protector enabled by adding -fstack-protector in CFLAGS in /etc/make.conf. Most ports build & work fine with this enabled, but there are several exceptions. Some libraries cannot be compiled with this (either the build fails or linking other programs which use the library later fail). Also some programs that do strange things fail to build or run. IMHO it would make sense to make some sort of framework in the ports system to support this. I think there should be a port Makefile knob which tells if the port can be built with the stack-protector or not. Now it is difficult to determine on port-by-port basis if it can be enabled or not. Is there any work or plans to accomplish this? It would be great to compile at least all the network facing server programs with this enabled. I have an impression that more than 90% of programs can be compiled with the stack-protector. For libraries the percentage might be less. What do you think? Best Regards, -- 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"
Re: Building ports with stack-protector
On Sat, May 29, 2010 at 7:19 PM, Janne Snabb wrote: > Hi, > > Big thanks to the folks who made "make buildworld" to use > -fstack-protector by default since 8.0. This should make FreeBSD > more secure. > > How about the ports system? > > I tried to re-build all my ports some time ago with the stack-protector > enabled by adding -fstack-protector in CFLAGS in /etc/make.conf. > Most ports build & work fine with this enabled, but there are several > exceptions. Some libraries cannot be compiled with this (either the > build fails or linking other programs which use the library later > fail). Also some programs that do strange things fail to build or > run. > > IMHO it would make sense to make some sort of framework in the ports > system to support this. I think there should be a port Makefile > knob which tells if the port can be built with the stack-protector > or not. Now it is difficult to determine on port-by-port basis if > it can be enabled or not. > > Is there any work or plans to accomplish this? > > It would be great to compile at least all the network facing server > programs with this enabled. I have an impression that more than 90% > of programs can be compiled with the stack-protector. For libraries > the percentage might be less. > > What do you think? 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. Check and see whether or not a similar feature exists in other compilers. If so, then I'd start noting which ports are and which aren't usable with this feature, and maybe approach the portmgr folks to see what they think. 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. Cheers, -Garrett ___ 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
> Hi! > > > I tried to install the port /usr/ports/sysutils/LPRng by executing the > command: > > > "make PORT_REPLACES_BASE_LPR=yes clean all install" > > > based on the Makefile suggestion.? > > > However, I receive the following error which occurs after installing the > /usr/lib: > > > ===> Installing rc.d startup script(s) > install: /usr/etc/rc.d/lprng: No such file or directory > *** Error code 71 > > > It seems like it cannot find the directory /usr/etc. Should it be using the > directory /etc or do I need to create a new directory /usr/etc/rc.d? > > > Thanks for your help 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"? Thank you for your help _ Hotmail: Powerful Free email with security by Microsoft. https://signup.live.com/signup.aspx?id=60969 ___ 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: 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"
