Re: CFT: pkgng support for tinderbox
On 02/15/2012 15:23, Chuck Swiger wrote: especially if you consider packages/ports to be external to the FreeBSD operating system itself. Good thing the ports are an integral part of the operating SYSTEM. :) -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
recent portrevision bump for libvpx
Speaking about FreeBSD ports' current way of recording dependencies and overzealous portrevision bumping. On my system: - with libchk's help: Binaries that are linked with: /usr/local/lib/libvpx.so.0 /usr/local/bin/mencoder /usr/local/bin/mplayer /usr/local/bin/vpxdec /usr/local/bin/vpxenc /usr/local/lib/libavcodec.so.52.123.0 - and then $ pkg_info -R libvpx-0.9.7 Information for libvpx-0.9.7: Required by: digikam-1.9.0_1,1 dvdrip-0.98.11_3 ffmpeg2theora-0.28_1 gtk-qt4-engine-1.1_5 kdepim-4.4.11.1_1 kino-1.3.4_10 kio-upnp-ms-1.0.0.g20110808 knemo-0.7.2_1 kplayer-0.7_1 libalkimia-4.3.1 polkit-kde-0.99.0_1 ffmpegthumbnailer-2.0.7 plasma-applet-icontasks-0.9.2 libktorrent-1.1.3 ktorrent-4.1.3 sox-14.3.2_2 amarok-2.5.0 opencv-2.3.1_3 transcode-1.1.7_3 kchmviewer-6.0 libxine-1.1.19_9 amule-2.3.1_2 audacious-plugins-3.1.1_1 kmymoney-4.6.1_1 subtitleripper-0.3.4_5 kipi-plugins-1.9.0_1,1 libreoffice-3.4.5 kate-4.7.4 konsole-4.7.4 kde-baseapps-4.7.4 blinken-4.7.4 libkdeedu-4.7.4 kalgebra-4.7.4 cantor-4.7.4 ffmpeg-0.7.11_2,1 filelight-4.7.4 libkipi-4.7.4 gwenview-4.7.4 ja-kiten-4.7.4 kalzium-4.7.4 kamera-4.7.4 kanagram-4.7.4 kbruch-4.7.4 kcolorchooser-4.7.4 kde-runtime-4.7.4 kde-wallpapers-4.7.4 kdepimlibs-4.7.4 okular-4.7.4 py27-kdebindings-pykde4-4.7.4 plasma-scriptengine-python-4.7.4 kdebindings-smoke-smokekde-4.7.4 ruby19-kdebindings-korundum-4.7.4 plasma-scriptengine-ruby-4.7.4 kde-workspace-4.7.4 kdeadmin-4.7.4 libkexiv2-4.7.4 kdeartwork-4.7.4 py27-kdebindings-krosspython-4.7.4 py27-kdebindings-pykdeuic4-4.7.4 py27-kdebindings-4.7.4 ruby19-kdebindings-4.7.4 kdebindings-4.7.4 kstars-4.7.4 marble-4.7.4 khangman-4.7.4 kturtle-4.7.4 kig-4.7.4 kmplot-4.7.4 rocs-4.7.4 kgeography-4.7.4 klettres-4.7.4 ktouch-4.7.4 kwordquiz-4.7.4 parley-4.7.4 step-4.7.4 kdeedu-4.7.4 kdegames-4.7.4 kruler-4.7.4 kdegraphics-mobipocket-4.7.4 kdegraphics-strigi-analyzer-4.7.4 kdegraphics-svgpart-4.7.4 libkdcraw-4.7.4 kdegraphics-thumbnailers-4.7.4 kolourpaint-4.7.4 libksane-4.7.4 ksaneplugin-4.7.4 ksnapshot-4.7.4 kgamma-4.7.4 kdegraphics-4.7.4 kdemultimedia-4.7.4 kdenetwork-4.7.4 kdeplasma-addons-4.7.4 kdetoys-4.7.4 kdeutils-4.7.4 libquicktime-1.2.3_3 mencoder-1.0.r20111218_1 kde-4.7.4 kdeutils-printer-applet-4.7.4 ru-kde-l10n-4.7.4 system-config-printer-kde-4.7.4 uk-kde-l10n-4.7.4 vlc-1.1.13_4,3 strigi-0.7.7 freerdp-1.0.0 mplayer-1.0.r20111218_3 k3b-2.0.2_6 kdelibs-4.7.4_1 xbmc-11.0.b2_1 Needless to say that all these ports got their port revisions bumped. Was there a good reason for that? I don't know. I just know that now I need to needlessly reinstall/rebuild about a hundred ports, many of which are not quite light-weight. -- Andriy Gapon ___ 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: recent portrevision bump for libvpx
On 02/17/2012 02:14, Andriy Gapon wrote: Speaking about FreeBSD ports' current way of recording dependencies and overzealous portrevision bumping. We're way to aggressive about recording grandchild dependencies. Repeated calls for this to be addressed have been ignored. Meanwhile you can put EXPLICIT_PACKAGE_DEPENDS= true in make.conf which helps quite a bit for keeping your local /var/db/pkg tidy. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: recent portrevision bump for libvpx
Andriy Gapon wrote:
Needless to say that all these ports got their port revisions bumped.
Was there a good reason for that? I don't know.
I just know that now I need to needlessly reinstall/rebuild about a hundred
ports, many of which are not quite light-weight.
It's time to experiment seriously with ${EXPLICIT_PACKAGE_DEPENDS} and
libtool patch to not link to indirect dependencies (ports/104877).
Ideally a port should include in LIB_DEPENDS all the direct dependencies.
--
Alex Dupre
___
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: recent portrevision bump for libvpx
Alex Dupre wrote: Ideally a port should include in LIB_DEPENDS all the direct dependencies. And consequentially it should be bumped *only if* a direct dependency has a library version bump. With the current link to all attitude, we are never sure what need to be bumped, because of hidden dependencies, and so portmaster -r and similar approaches are always recommended in addition to probabilistic portrevision bumps. -- Alex Dupre ___ 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: recent portrevision bump for libvpx
on 17/02/2012 12:23 Doug Barton said the following: Meanwhile you can put EXPLICIT_PACKAGE_DEPENDS= true in make.conf which helps quite a bit for keeping your local /var/db/pkg tidy. Thank you for this good advice! Unfortunately, it can't help with the gratuitous revision bumps, but it should improve e.g. portmaster -r. -- Andriy Gapon ___ 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
tinderbox question (Was: Re: recent portrevision bump for libvpx)
Alex Dupre wrote: And consequentially it should be bumped *only if* a direct dependency has a library version bump. This doesn't solve the fact that in 3 days my tinderbox has rebuilt nearly all ports 4 times. Is there a way to say tinderbox to not rebuild every ports (without portrevision bump) that depends on a just rebuilt port? -- Alex Dupre ___ 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: recent portrevision bump for libvpx
2012/2/17 Doug Barton do...@freebsd.org: On 02/17/2012 02:14, Andriy Gapon wrote: Speaking about FreeBSD ports' current way of recording dependencies and overzealous portrevision bumping. We're way to aggressive about recording grandchild dependencies. Repeated calls for this to be addressed have been ignored. Meanwhile you can put EXPLICIT_PACKAGE_DEPENDS= true in make.conf which helps quite a bit for keeping your local /var/db/pkg tidy. For me (526 ports installed, KDE4 and a long time EXPLICIT_PACKAGE_DEPENDS user), I only had to portmaster libvpx and ffmpeg. # cat /var/db/pkg/libvpx-1.0.0/+REQUIRED_BY ffmpeg-0.7.11_3,1 pkg_libchk reports nothing else needing libvpx... -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: recent portrevision bump for libvpx
Alexander Leidinger wrote: When I made the EXPLICIT_PACKAGE_DEPENDS patch, I noticed that there is not only libtool at fault (reaction of the libtool developers was IIRC: it's not trivial to fix known problems for the cross-building case (for libtool-1.x?)), but also pkg-config and similar things Yes, I know, it's correct what you say, but this doesn't prevent to improve things. I'm not saying that tomorrow we'll have a perfect ports tree where all and only direct dependencies will be listed, but if we don't even start... Currently we have exactly the opposite case: ports that have direct (maybe not needed) dependencies to libraries that are not recorded in Makefiles. This is the root cause of portmaster -r or aggressive bumps. -- Alex Dupre ___ 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: recent portrevision bump for libvpx
Speaking of recent libvpx update, some ports explicitly look for libvpx.so.0, and fail to update trying to install again libvpx which is already installed. e.g. multimedia/gstreamer-plugins-vp8 -- View this message in context: http://freebsd.1045724.n5.nabble.com/recent-portrevision-bump-for-libvpx-tp5492060p5492205.html Sent from the freebsd-ports mailing list archive at Nabble.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: recent portrevision bump for libvpx
On Fri, 17 Feb 2012 02:23:24 -0800 Doug Barton articulated: Meanwhile you can put EXPLICIT_PACKAGE_DEPENDS= true in make.conf which helps quite a bit for keeping your local /var/db/pkg tidy. Where is that knob documented? I have not come across it before. Is it localized to portmaster or does it work with any package management program? -- Carmel ✌ carmel...@hotmail.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: recent portrevision bump for libvpx
On 17/02/2012 10:38, Alex Dupre wrote: Alex Dupre wrote: Ideally a port should include in LIB_DEPENDS all the direct dependencies. And consequentially it should be bumped *only if* a direct dependency has a library version bump. With the current link to all attitude, we are never sure what need to be bumped, because of hidden dependencies, and so portmaster -r and similar approaches are always recommended in addition to probabilistic portrevision bumps. You could record all the shared libraries used by a port as comments in the +CONTENTS list when it is packaged. Adding code to run ldd(1) against the files installed by the port and processing the results shouldn't be too hard. Then portmaster(8) et al could have a way of telling precisely what needed to be rebuilt for this sort of shlib version bump. 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 signature.asc Description: OpenPGP digital signature
Re: recent portrevision bump for libvpx
Quoting Alex Dupre a...@freebsd.org (from Fri, 17 Feb 2012 11:33:17 +0100):
Andriy Gapon wrote:
Needless to say that all these ports got their port revisions bumped.
Was there a good reason for that? I don't know.
I just know that now I need to needlessly reinstall/rebuild about a hundred
ports, many of which are not quite light-weight.
It's time to experiment seriously with ${EXPLICIT_PACKAGE_DEPENDS}
and libtool patch to not link to indirect dependencies
(ports/104877). Ideally a port should include in LIB_DEPENDS all the
direct dependencies.
When I made the EXPLICIT_PACKAGE_DEPENDS patch, I noticed that there
is not only libtool at fault (reaction of the libtool developers was
IIRC: it's not trivial to fix known problems for the cross-building
case (for libtool-1.x?)), but also pkg-config and similar things
(dependencies of dependencies where specified, e.g. your port links
against liba, the pkg-config for liba also told to link against libb
which liba depends upon but for which the ABI was not exposed to your
port by liba, but this caused a record of libb to show up in binaries
of your port). I do not know if the situation improved in _all_ ports,
but some look more sane.
You can also have a look at
/usr/ports/Tools/scripts/explicit_lib_depends.sh, thats a script which
analyzes the recorded dependencies in binaries for a given port (this
may be different from what is recorded in LIB_DEPENDS, and it can be
different from it even if LIB_DEPENDS is 100% correct). So if a lib
which is listed in the output changes the soversion, you _have_ to
recompile this port, no matter if the binary has his hands in the ABI
of the changed lib or not (that's the port-liba-libb case from the
paragraph above).
Bye,
Alexander.
--
There must be at least 500,000,000 rats in the United
States; of course, I never heard the story before.
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
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: recent portrevision bump for libvpx
Matthew Seaman wrote: Adding code to run ldd(1) against the files installed by the port and processing the results shouldn't be too hard. This could be an idea for ports maintainers, to verify if LIB_DEPENDS is set correctly, but cannot be used as its generic replacement. -- Alex Dupre ___ 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: recent portrevision bump for libvpx
On 17/02/2012 13:05, Alex Dupre wrote: Matthew Seaman wrote: Adding code to run ldd(1) against the files installed by the port and processing the results shouldn't be too hard. This could be an idea for ports maintainers, to verify if LIB_DEPENDS is set correctly, but cannot be used as its generic replacement. Quite so, but that's not the principal benefit. It's a way of efficiently answering the question which of my installed ports need to be re-built as a result of this shlib change? For the end users primarily. Having this data recorded in /var/db/pkg/foo-9.99/+CONTENTS makes answering that question something like: grep -l '@comment SHLIB:libwhatever' /var/db/pkg/*/+CONTENTS | \ cut -d '/' -f 5 Ideally a ports management tool would notice if any port updated a shlib to a different ABI version and suggest to the user which ports to rebuild. I assume something similar could be done for the new pkg tools, but I really have no idea how hard that would be. 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 signature.asc Description: OpenPGP digital signature
Re: recent portrevision bump for libvpx
on 17/02/2012 13:04 Olivier Smedts said the following: 2012/2/17 Doug Barton do...@freebsd.org: On 02/17/2012 02:14, Andriy Gapon wrote: Speaking about FreeBSD ports' current way of recording dependencies and overzealous portrevision bumping. We're way to aggressive about recording grandchild dependencies. Repeated calls for this to be addressed have been ignored. Meanwhile you can put EXPLICIT_PACKAGE_DEPENDS= true in make.conf which helps quite a bit for keeping your local /var/db/pkg tidy. For me (526 ports installed, KDE4 and a long time EXPLICIT_PACKAGE_DEPENDS user), I only had to portmaster libvpx and ffmpeg. I assume you report what you had to do before all the revisions were bumped? # cat /var/db/pkg/libvpx-1.0.0/+REQUIRED_BY ffmpeg-0.7.11_3,1 pkg_libchk reports nothing else needing libvpx... -- Andriy Gapon ___ 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
Viewing port changelogs
Hello, Before upgrading ports, I have made it a habit to check the changes in the ports Makefile from the previous version. I've been using the web-interface located at www.freebsd.org/ports/ For example, this page shows the change commit message, http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/postfix/Makefile and then I view the preferred diff for the Makefile itself. I was wondering if there is any method to doing this from command line? I often don't have a web-browser available to me when working on the console. I'd be willing to write a script to display a changelog, but I'm not even sure where to get it from in the first place, other than that website. Any suggestions? Thank you! ___ 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: recent portrevision bump for libvpx
2012/2/17 Andriy Gapon a...@freebsd.org: on 17/02/2012 13:04 Olivier Smedts said the following: 2012/2/17 Doug Barton do...@freebsd.org: On 02/17/2012 02:14, Andriy Gapon wrote: Speaking about FreeBSD ports' current way of recording dependencies and overzealous portrevision bumping. We're way to aggressive about recording grandchild dependencies. Repeated calls for this to be addressed have been ignored. Meanwhile you can put EXPLICIT_PACKAGE_DEPENDS= true in make.conf which helps quite a bit for keeping your local /var/db/pkg tidy. For me (526 ports installed, KDE4 and a long time EXPLICIT_PACKAGE_DEPENDS user), I only had to portmaster libvpx and ffmpeg. I assume you report what you had to do before all the revisions were bumped? I report what I had to do to have a working system, with working software and an up-to-date libvpx. I didn't update all the ports that were bumped (54 for me, and they're all quite big, mostly kde-related). But now I can't portmaster -a if I don't want to clog my computer for hours... and all those bumps are useless in my case, pkg_libchk confirms that nothing on my system was using libvpx except ffmpeg. # cat /var/db/pkg/libvpx-1.0.0/+REQUIRED_BY ffmpeg-0.7.11_3,1 pkg_libchk reports nothing else needing libvpx... -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: recent portrevision bump for libvpx
on 17/02/2012 18:02 Olivier Smedts said the following: I report what I had to do to have a working system, with working software and an up-to-date libvpx. I didn't update all the ports that were bumped (54 for me, and they're all quite big, mostly kde-related). But now I can't portmaster -a if I don't want to clog my computer for hours... and all those bumps are useless in my case, pkg_libchk confirms that nothing on my system was using libvpx except ffmpeg. Right. So we are on the same page. -- Andriy Gapon ___ 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: Re: recent portrevision bump for libvpx
On -10.01.-28163 14:59, Jakub Lach wrote: Speaking of recent libvpx update, some ports explicitly look for libvpx.so.0, and fail to update trying to install again libvpx which is already installed. e.g. multimedia/gstreamer-plugins-vp8 Yet again I'd like to point out, that -- contrary to the wide-spread practice -- ports should not, by default, list a particular shlib major number in LIB_DEPENDS. Only in cases, when a wrong version of some libfoo is known to cause problems, should the correct version be explicitly given in LIB_DEPENDS. -mi ___ 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: nspluginwrapper (was Re: linux-f10-flashplugin11 not works for 9-stable (Linuxulator?))
On Thursday 16 February 2012 04:26 pm, Andrey Chernov wrote:
It seems part of the bug is already noticed by maintainer (Jung-uk
Kim) but nothing is done to fix it:
http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/06
4067.html BTW, the bug is in native FreeBSD code (rpc.c), not in
linux code.
Jung-uk, could you fix/hack it somehow, please?
Linuxulator does not support abstract namespace yet and it is hard
problem. However, nspluginwrapper does not use abstract namespace
when it is built for non-Linux platform, i.e., --enable-generic
configure option unsets USE_ANONYMOUS_SOCKETS for both Linux and
FreeBSD.
OTH, FreeBSD-SA-11:05.unix broke Linuxulator but it was quickly
patched by cperciva and refined by me *before* 9.0-RELEASE.
Jung-uk Kim
On Fri, Feb 17, 2012 at 12:31:08AM +0400, Andrey Chernov wrote:
On Thu, Feb 16, 2012 at 11:47:05AM +0200, Volodymyr Kostyrko
wrote:
Andrey Chernov wrote:
Having 9-stable and ports from Feb 14, all builded from
sources, I get this commonly looking error attempting to view
flash in FF 10.0.1:
*** NSPlugin Wrapper *** ERROR: failed to initialize
plugin-side RPC client connection
NOTE: child process received `Goodbye', closing down
Looking into ktrace I found error reason:
82037 plugin-container CALL connect(0x16,0x2c04f9d4,0x42)
82037 plugin-container STRU struct sockaddr { AF_LOCAL,
invalid } 82037 plugin-container NAMI
/tmp/_org_wrapper_NSPlugins_libflashplayer.so_82037-2_180428
9383 82037 plugin-container RET connect -1 errno 2 No such
file or directory
(repeated several times).
This invalid in sockaddr looks familiar as for some time
ago added sockaddr length checks our kernel, but as bz@ says
this should be already fixed.
Does anybody runs flash successfly on 9-stable? If yes, where
else the problem can be?
Am running flash successfully on 9-stable (daily rebuild).
Works for me under chromium/seamonkey.
Just filed a patch for the latest flash version... Works for me
also.
Do you have recently-builded nspluginwrapper from sources? It
seems the bug is there, since even that does not work:
# nspluginplayer --verbose type=application/x-shockwave-flash
src=some.swf
*** NSPlugin Player *** swf application/x-shockwave-flash
Shockwave Flash *** NSPlugin Player *** spl
application/futuresplash
FutureSplash Player *** NSPlugin Wrapper *** ERROR: failed to
initialize plugin-side RPC client connection *** NSPlugin Player
*** ERROR: could not execute: NPERR_MODULE_LOAD_FAILED_ERROR
And I see very suspicious socket_addr_len size related code
(which recent SA-fixes address) in rpc.c there:
connection-socket_addr_len =
_rpc_socket_path(connection-socket_path, ident);
memcpy(connection-socket_addr.sun_path[0],
connection-socket_path, connection-socket_addr_len);
connection-socket_addr_len += offsetof(struct sockaddr_un,
sun_path); /* though POSIX says size of the actual sockaddr
structure */ #ifdef HAVE_SOCKADDR_UN_SUN_LEN
connection-socket_addr.sun_len = connection-socket_addr_len;
#endif
___
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: Re: recent portrevision bump for libvpx
On 17 February 2012 13:59, Mikhail T. mi+t...@aldan.algebra.com wrote: On -10.01.-28163 14:59, Jakub Lach wrote: Speaking of recent libvpx update, some ports explicitly look for libvpx.so.0, and fail to update trying to install again libvpx which is already installed. e.g. multimedia/gstreamer-plugins-vp8 Yet again I'd like to point out, that -- contrary to the wide-spread practice -- ports should not, by default, list a particular shlib major number in LIB_DEPENDS. Only in cases, when a wrong version of some libfoo is known to cause problems, should the correct version be explicitly given in LIB_DEPENDS. Perhaps someone could make a patch for the Porter's Handbook. 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: Viewing port changelogs
APseudoUtopia apseudouto...@gmail.com writes: Before upgrading ports, I have made it a habit to check the changes in the ports Makefile from the previous version. I've been using the web-interface located at www.freebsd.org/ports/ For example, this page shows the change commit message, http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/postfix/Makefile and then I view the preferred diff for the Makefile itself. I was wondering if there is any method to doing this from command line? I often don't have a web-browser available to me when working on the console. I'd be willing to write a script to display a changelog, but I'm not even sure where to get it from in the first place, other than that website. You can query cvs yourself, which is all that webpage is doing. If you're already downloading the whole CVS (ports) repository for some other reason, that's quite simple. If not, anonymous cvs is explained in the handbook. Or you could install a text-mode web browser. In any case, I'd recommend scripting the process. ___ 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: Please test your commits
On Sun, Feb 12, 2012 at 08:35:05PM +, Michael Scheidell wrote: Public flogging seems to be more enjoyable than a private email to the developer, the maintainer, and a committer. I know we are all a little frustrated with some of the local commits, but remember: praise in public, criticize in private. This is a good management dictum. I try to follow it and though I often fail, I try. Let's all keep in mind that the only reward most ports maintainers/committers do indeed get is the occasional bit of praise. Thanks. mcl ___ 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: Please test your commits
On Sun, Feb 12, 2012 at 03:22:38PM -0600, Stephen Montgomery-Smith wrote: Also, if everyone starts using [redports], isn't the backlog going to become huge? We're working on getting more hardware. Having something become too successful is a problem we should be happy to have :) mcl ___ 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: Duplicate INDEX entries of long standing
Normally duplicate INDEX entries in the default config annoy one of us portmgrs and we go try to figure them out. On my own system I usually see this as a result of previously installed dependencies e.g. cvsup_without_gui IIRC. mcl ___ 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: linux-f10-flashplugin11 not works for 9-stable (Linuxulator?)
On Wednesday 15 February 2012 11:47 am, Andrey Chernov wrote:
Having 9-stable and ports from Feb 14, all builded from sources, I
get this commonly looking error attempting to view flash in FF
10.0.1:
*** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side
RPC client connection
NOTE: child process received `Goodbye', closing down
Looking into ktrace I found error reason:
82037 plugin-container CALL connect(0x16,0x2c04f9d4,0x42)
82037 plugin-container STRU struct sockaddr { AF_LOCAL, invalid }
82037 plugin-container NAMI
/tmp/_org_wrapper_NSPlugins_libflashplayer.so_82037-2_1804289383
82037 plugin-container RET connect -1 errno 2 No such file or
directory
(repeated several times).
This invalid in sockaddr looks familiar as for some time ago
added sockaddr length checks our kernel, but as bz@ says this
should be already fixed.
Yes, it should be fixed *before* 9.0-RELEASE.
Please try make configure and send me config-host.h from
work/nspluginwrapper-1.4.4 directory.
Jung-uk Kim
___
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: recent portrevision bump for libvpx
On 17.02.2012 12:36, Chris Rees wrote: Yet again I'd like to point out, that -- contrary to the wide-spread practice -- ports should not, by default, list a particular shlib major number in LIB_DEPENDS. Only in cases, when a wrong version of some libfoo is known to cause problems, should the correct version be explicitly given in LIB_DEPENDS. Perhaps someone could make a patch for the Porter's Handbook. Last time I broached the subject, I could not get my argument through... I even once made a patch, which would've allowed the user (at their own risk) to tell bsd.port.mk to ignore all explicitly-specified shlib-major numbers -- and portmgr@ shut it down, even though the new flag would not be on by default. If the consensus has changed over the years, coming up with the new text for the manual would not be a problem... -mi ___ 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: CUDA porting effort?
I'd be willing to try building it on the Power(PC) platform. On Wed, Feb 15, 2012 at 4:45 PM, Eric McCorkle e...@shadowsun.net wrote: Given that NVidia is releasing the CUDA platform source on a limited basis, is anyone actively working to port it to FreeBSD? The reason I ask is that to get access to the source, you have to submit a request explaining what you intend to use it for. It might be a good idea to get ahold of the source on behalf of FreeBSD, so that interested people could work on porting it. I could devote a small amount of time to such an effort; I'm wondering if there's interest from anyone else. ___ 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: Re: recent portrevision bump for libvpx
On Fri, Feb 17, 2012 at 7:59 AM, Mikhail T. mi+t...@aldan.algebra.com wrote: On -10.01.-28163 14:59, Jakub Lach wrote: Speaking of recent libvpx update, some ports explicitly look for libvpx.so.0, and fail to update trying to install again libvpx which is already installed. e.g. multimedia/gstreamer-plugins-vp8 Yet again I'd like to point out, that -- contrary to the wide-spread practice -- ports should not, by default, list a particular shlib major number in LIB_DEPENDS. Only in cases, when a wrong version of some libfoo is known to cause problems, should the correct version be explicitly given in LIB_DEPENDS. I regard this as a wrong practice. Here is why: 1. The way you specify the version in LIB_DEPENDS has NO relation with how the port link to the lib. The port can link to the major version (pkg-config), or the .so, etc. 2. One responsibility of the ports system is to protect the user from suffering from running a software which links to a ABI incompatible, hence, wrong shared library. A software runs incorrectly is a disaster, and the shared library version is to prevent this, and the ports system is to protect the versioned shared libraries. Thus -- A port fails to find its depends better than it does not link, a software does not link is better than it does not run correctly. And your practice is trying to remove such protection. 3. Known to cause problem? Can I infer you can predict the future from that? So, to link to a version explicitly should be the default. Only a library behaviors good in its development history can be considered to use it's libname only in LIB_DEPENDS. -mi ___ 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 -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ 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: recent portrevision bump for libvpx
On 17.02.2012 14:24, Zhihao Yuan wrote: I regard this as a wrong practice. Here is why: 1. The way you specify the version in LIB_DEPENDS has NO relation with how the port link to the lib. The port can link to the major version (pkg-config), or the .so, etc. I'm sorry, I can not parse the above part. Perhaps, a live example is in order. 2. One responsibility of the ports system is to protect the user from suffering from running a software which links to a ABI incompatible, hence, wrong shared library. This is a made-up non-reason, sorry. The only way to get into an ABI incompatibility is to have -- at the time of the port building -- header-files declarations from one version of a library and implementation(s) from another. Avoiding such situations is out of the scope of the ports-system and this discussion. Again, try to come up with a real-life example of how my proposal would break ABI for an actual user... You can not. 3. Known to cause problem? Can I infer you can predict the future from that? Yes, you can. Well-knowing the past 15 or so years of the ports-system, I can predict some aspects of the future. For example: * committers will continue to forget to update some of the umpteen instances of LIB_DEPENDS=foo.X in various ports, when bumping up major version of foo. * committers will continue to /mindlessly/ bump-up these umpteen instances -- without actually verifying, that the new version of foo is still acceptable to all of those dependants. * port-building will remain unduly difficult because of the wide-spread mindless (mis)use of the major shlib-number in LIB_DEPENDS. Consider the following scenario (substitute any of png, jpeg, xml, etc. for foo): 1. You build a shiny new machine -- with the desktop of your choice (KDE, Gnome, Xfce - whatever) from ports. Hours of build-time interrupted by occasional `config' screens... 2. A week later you update your ports tree -- which sees version-bump of libfoo. 3. You try to add a foo-using program bar to your computer -- and fail, because the bar-port now insists on the very latest version of libfoo. Not because the maintainer of bar determined, that the earlier versions are bad -- simply because the maintainer of foo went through all dependents and updated the LIB_DEPENDS lines in all of them, as is the current sad practice. 4. You now have to either portupgrade libfoo -- which means, your desktop will be using libfoo.N and the newly-built bar will be using libfoo.N+1 (inefficient and sometimes a source of problems in its own), or go through rebuilding all of the foo-using ports again... So, to link to a version explicitly should be the default. Only a library behaviors good in its development history can be considered to use it's libname only in LIB_DEPENDS. I'm not sure, what you mean by link to a version. Once again, I beg you to offer a live example. Yours, -mi ___ 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: CUDA porting effort?
CC: Oliver Hartmann On 2/15/12, Eric McCorkle e...@shadowsun.net wrote: Given that NVidia is releasing the CUDA platform source on a limited basis, is anyone actively working to port it to FreeBSD? The reason I ask is that to get access to the source, you have to submit a request explaining what you intend to use it for. It might be a good idea to get ahold of the source on behalf of FreeBSD, so that interested people could work on porting it. I could devote a small amount of time to such an effort; I'm wondering if there's interest from anyone else. ___ 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: linux-f10-flashplugin11 not works for 9-stable (Linuxulator?)
On Friday 17 February 2012 01:32 pm, Jung-uk Kim wrote: This invalid in sockaddr looks familiar as for some time ago added sockaddr length checks our kernel, but as bz@ says this should be already fixed. Yes, it should be fixed *before* 9.0-RELEASE. I meant 9.0 was released with the fix. Sorry if I caused confusion. Jung-uk Kim ___ 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: recent portrevision bump for libvpx
On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: On 17.02.2012 14:24, Zhihao Yuan wrote: I regard this as a wrong practice. Here is why: 1. The way you specify the version in LIB_DEPENDS has NO relation with how the port link to the lib. The port can link to the major version (pkg-config), or the .so, etc. I'm sorry, I can not parse the above part. Perhaps, a live example is in order. LIB_DEPENDS= png.6: or =png: does not affect how the lib got linked. It always links to the latest libpng the time you compile the port. 2. One responsibility of the ports system is to protect the user from suffering from running a software which links to a ABI incompatible, hence, wrong shared library. This is a made-up non-reason, sorry. The only way to get into an ABI incompatibility is to have -- at the time of the port building -- header-files declarations from one version of a library and implementation(s) from another. Avoiding such situations is out of the scope of the ports-system and this discussion. Again, try to come up with a real-life example of how my proposal would break ABI for an actual user... You can not. This only happens when a minor version of a library is not compatible with another one. OK, that's out of the scope. 3. Known to cause problem? Can I infer you can predict the future from that? Yes, you can. Well-knowing the past 15 or so years of the ports-system, I can predict some aspects of the future. For example: committers will continue to forget to update some of the umpteen instances of LIB_DEPENDS=foo.X in various ports, when bumping up major version of foo. committers will continue to mindlessly bump-up these umpteen instances -- without actually verifying, that the new version of foo is still acceptable to all of those dependants. My opinion is that, fails to build is not a big trouble, at least we notified the through portsnap/pkg_version; The user surprisingly finds that his software fails to run is a bigger trouble. port-building will remain unduly difficult because of the wide-spread mindless (mis)use of the major shlib-number in LIB_DEPENDS. Consider the following scenario (substitute any of png, jpeg, xml, etc. for foo): The updates to major libs always bind to a larger updates in the ports tree. You have to upgrade all of the ports depend on them no matter how you use LIB_DEPENDS. You build a shiny new machine -- with the desktop of your choice (KDE, Gnome, Xfce - whatever) from ports. Hours of build-time interrupted by occasional `config' screens... A week later you update your ports tree -- which sees version-bump of libfoo. You try to add a foo-using program bar to your computer -- and fail, because the bar-port now insists on the very latest version of libfoo. Not because the maintainer of bar determined, that the earlier versions are bad -- simply because the maintainer of foo went through all dependents and updated the LIB_DEPENDS lines in all of them, as is the current sad practice. You now have to either portupgrade libfoo -- which means, your desktop will be using libfoo.N and the newly-built bar will be using libfoo.N+1 (inefficient and sometimes a source of problems in its own), or go through rebuilding all of the foo-using ports again... I regards what you said above as the regular routine, and I can't see how your practice can improve such a routine. So, to link to a version explicitly should be the default. Only a library behaviors good in its development history can be considered to use it's libname only in LIB_DEPENDS. I'm not sure, what you mean by link to a version. Once again, I beg you to offer a live example. Yours, I mean LIB_DEPENDS= png.6 -mi -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ 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: recent portrevision bump for libvpx
On 17.02.2012 17:05, Zhihao Yuan wrote: On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T.mi+t...@aldan.algebra.com wrote: On 17.02.2012 14:24, Zhihao Yuan wrote: I regard this as a wrong practice. Here is why: 1. The way you specify the version in LIB_DEPENDS has NO relation with how the port link to the lib. The port can link to the major version (pkg-config), or the .so, etc. I'm sorry, I can not parse the above part. Perhaps, a live example is in order. LIB_DEPENDS= png.6: or =png: does not affect how the lib got linked. It always links to the latest libpng the time you compile the port. Yes, this is correct. But irrelevant, really -- this will remain true, whether or not LIB_DEPENDS lines contain explicit library numbers. 2. One responsibility of the ports system is to protect the user from suffering from running a software which links to a ABI incompatible, hence, wrong shared library. This is a made-up non-reason, sorry. The only way to get into an ABI incompatibility is to have -- at the time of the port building -- header-files declarations from one version of a library and implementation(s) from another. Avoiding such situations is out of the scope of the ports-system and this discussion. Again, try to come up with a real-life example of how my proposal would break ABI for an actual user... You can not. This only happens when a minor version of a library is not compatible with another one. OK, that's out of the scope. We have not used minor library versions since switch-over to ELF... I do not understand, what you are talking about. 3. Known to cause problem? Can I infer you can predict the future from that? Yes, you can. Well-knowing the past 15 or so years of the ports-system, I can predict some aspects of the future. For example: committers will continue to forget to update some of the umpteen instances of LIB_DEPENDS=foo.X in various ports, when bumping up major version of foo. committers will continue to mindlessly bump-up these umpteen instances -- without actually verifying, that the new version of foo is still acceptable to all of those dependants. My opinion is that, fails to build is not a big trouble, at least we notified the through portsnap/pkg_version; The user surprisingly finds that his software fails to run is a bigger trouble. The existing practice does not protect against this bigger trouble either -- whenever port installing libfoo.so is updated, all of the ports LIB_DEPENDing on foo.X are matter-of-factly updated to LIB_DEPEND on foo.(X+1). At best, these updates are verified to continue to /build/ -- but they are never verified to continue to /work/ -- although they usually do work, of course. `cvs log' shows thousands of commit messages matching the pattern chas.*bump (libvpx included, of course) -- I'd be surprised to learn, the usability test was conducted in 1% of these cases... port-building will remain unduly difficult because of the wide-spread mindless (mis)use of the major shlib-number in LIB_DEPENDS. Consider the following scenario (substitute any of png, jpeg, xml, etc. for foo): The updates to major libs always bind to a larger updates in the ports tree. You have to upgrade all of the ports depend on them no matter how you use LIB_DEPENDS. No, I should not have to. I might prefer to, but I should not be forced to do it. And what's a major lib anyway? Does x264 qualify? If I want to add vlc, for example, do you want to /force/ me to rebuild mplayer as well -- because x264 went from 137 to 171 since I last built it? You build a shiny new machine -- with the desktop of your choice (KDE, Gnome, Xfce - whatever) from ports. Hours of build-time interrupted by occasional `config' screens... A week later you update your ports tree -- which sees version-bump of libfoo. You try to add a foo-using program bar to your computer -- and fail, because the bar-port now insists on the very latest version of libfoo. Not because the maintainer of bar determined, that the earlier versions are bad -- simply because the maintainer of foo went through all dependents and updated the LIB_DEPENDS lines in all of them, as is the current sad practice. You now have to either portupgrade libfoo -- which means, your desktop will be using libfoo.N and the newly-built bar will be using libfoo.N+1 (inefficient and sometimes a source of problems in its own), or go through rebuilding all of the foo-using ports again... I regards what you said above as the regular routine, and I can't see how your practice can improve such a routine. If the port bar is willing to compile against /any/ version of libfoo (and the vast majority of ports are), then the problem I described will not strike anyone -- bar will built against whatever libfoo is already installed on the building computer, and that's it. The user still has an option to upgrade everything to the latest, but he is no longer forced to do it just to add one more port to an existing install. My proposal
Library numbers in LIB_DEPENDS considered harmful (Re: recent portrevision bump for libvpx)
On 17.02.2012 17:05, Zhihao Yuan wrote:
LIB_DEPENDS= png.6: or =png: does not affect how the lib got linked.
Allow me to rephrase my argument from a different perspective...
The language used in our ports' Makefiles is, largely, /declarative/ -- various
things are declared and then bsd.port.mk (and friends) interpret them to do the
right thing.
Each declaration is meant to say something, so let's examine, what a LIB_DEPENDS
entry declares:
LIB_DEPENDS=foo.V:${PORTSDIR}/cat/libfoo
The above line says, that this port needs a shared library libfoo.so.V to be
installed. It also says, how to install it, if it is not already present at
build-time.
If, in fact, the current port does not care, which version of libfoo is uses --
and most software does not -- then declaring an explicit V is wrong: it
/gratuitously/ tightens the build-time requirements. Unless a particular version
is, indeed, required, the above line should read simply:
LIB_DEPENDS=foo:${PORTSDIR}/cat/libfoo
Let's say, you sent someone to buy a bottle of dry red wine in a store. Wouldn't
you be (unpleasantly) surprised, if he returned empty-handed, because the store
did not have any Californian Pinot Noir of the 2003 vintage? Huh? You did not
ask for Pinot Noir. You did not specify the origin nor the year either -- why
did not he get something else that matched your much wider and easier-to-satisfy
requirement: dry red wine?
A similar thing happens here: if the, say, vlc software needs libx264 to be
available at build time, the FreeBSD port of vlc should not add a requirement of
a particular version to that.
-mi
___
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: recent portrevision bump for libvpx
On Feb 17, 2012 5:17 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: On 17.02.2012 17:05, Zhihao Yuan wrote: On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: On 17.02.2012 14:24, Zhihao Yuan wrote: I regard this as a wrong practice. Here is why: 1. The way you specify the version in LIB_DEPENDS has NO relation with how the port link to the lib. The port can link to the major version (pkg-config), or the .so, etc. I'm sorry, I can not parse the above part. Perhaps, a live example is in order. LIB_DEPENDS= png.6: or =png: does not affect how the lib got linked. It always links to the latest libpng the time you compile the port. Yes, this is correct. But irrelevant, really -- this will remain true, whether or not LIB_DEPENDS lines contain explicit library numbers. 2. One responsibility of the ports system is to protect the user from suffering from running a software which links to a ABI incompatible, hence, wrong shared library. This is a made-up non-reason, sorry. The only way to get into an ABI incompatibility is to have -- at the time of the port building -- header-files declarations from one version of a library and implementation(s) from another. Avoiding such situations is out of the scope of the ports-system and this discussion. Again, try to come up with a real-life example of how my proposal would break ABI for an actual user... You can not. This only happens when a minor version of a library is not compatible with another one. OK, that's out of the scope. We have not used minor library versions since switch-over to ELF... I do not understand, what you are talking about. 3. Known to cause problem? Can I infer you can predict the future from that? Yes, you can. Well-knowing the past 15 or so years of the ports-system, I can predict some aspects of the future. For example: committers will continue to forget to update some of the umpteen instances of LIB_DEPENDS=foo.X in various ports, when bumping up major version of foo. committers will continue to mindlessly bump-up these umpteen instances -- without actually verifying, that the new version of foo is still acceptable to all of those dependants. My opinion is that, fails to build is not a big trouble, at least we notified the through portsnap/pkg_version; The user surprisingly finds that his software fails to run is a bigger trouble. The existing practice does not protect against this bigger trouble either -- whenever port installing libfoo.so is updated, all of the ports LIB_DEPENDing on foo.X are matter-of-factly updated to LIB_DEPEND on foo.(X+1). At best, these updates are verified to continue to build -- but they are never verified to continue to work -- although they usually do work, of course. `cvs log' shows thousands of commit messages matching the pattern chas.*bump (libvpx included, of course) -- I'd be surprised to learn, the usability test was conducted in 1% of these cases... port-building will remain unduly difficult because of the wide-spread mindless (mis)use of the major shlib-number in LIB_DEPENDS. Consider the following scenario (substitute any of png, jpeg, xml, etc. for foo): The updates to major libs always bind to a larger updates in the ports tree. You have to upgrade all of the ports depend on them no matter how you use LIB_DEPENDS. No, I should not have to. I might prefer to, but I should not be forced to do it. And what's a major lib anyway? Does x264 qualify? If I want to add vlc, for example, do you want to force me to rebuild mplayer as well -- because x264 went from 137 to 171 since I last built it? You build a shiny new machine -- with the desktop of your choice (KDE, Gnome, Xfce - whatever) from ports. Hours of build-time interrupted by occasional `config' screens... A week later you update your ports tree -- which sees version-bump of libfoo. You try to add a foo-using program bar to your computer -- and fail, because the bar-port now insists on the very latest version of libfoo. Not because the maintainer of bar determined, that the earlier versions are bad -- simply because the maintainer of foo went through all dependents and updated the LIB_DEPENDS lines in all of them, as is the current sad practice. You now have to either portupgrade libfoo -- which means, your desktop will be using libfoo.N and the newly-built bar will be using libfoo.N+1 (inefficient and sometimes a source of problems in its own), or go through rebuilding all of the foo-using ports again... I regards what you said above as the regular routine, and I can't see how your practice can improve such a routine. If the port bar is willing to compile against any version of libfoo (and the vast majority of ports are), then the problem I described will not strike anyone -- bar will built against whatever libfoo is already installed on the building computer, and that's it. The user still has an option to upgrade everything to
Re: Library numbers in LIB_DEPENDS considered harmful (Re: recent portrevision bump for libvpx)
On Feb 17, 2012 5:41 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
On 17.02.2012 17:05, Zhihao Yuan wrote:
LIB_DEPENDS= png.6: or =png: does not affect how the lib got linked.
Allow me to rephrase my argument from a different perspective...
The language used in our ports' Makefiles is, largely, declarative --
various things are declared and then bsd.port.mk (and friends) interpret
them to do the right thing.
Each declaration is meant to say something, so let's examine, what a
LIB_DEPENDS entry declares:
LIB_DEPENDS=foo.V:${PORTSDIR}/cat/libfoo
The above line says, that this port needs a shared library libfoo.so.V to
be installed. It also says, how to install it, if it is not already present
at build-time.
If, in fact, the current port does not care, which version of libfoo is
uses -- and most software does not -- then declaring an explicit V is
wrong: it gratuitously tightens the build-time requirements. Unless a
particular version is, indeed, required, the above line should read simply:
LIB_DEPENDS=foo:${PORTSDIR}/cat/libfoo
Let's say, you sent someone to buy a bottle of dry red wine in a store.
Wouldn't you be (unpleasantly) surprised, if he returned empty-handed,
because the store did not have any Californian Pinot Noir of the 2003
vintage? Huh? You did not ask for Pinot Noir. You did not specify the
origin nor the year either -- why did not he get something else that
matched your much wider and easier-to-satisfy requirement: dry red wine?
So what, I come to your bar and say 10 year red wine in1998, you give me
a 1988 one. And I went your place again in 2008, and say same wine, and
you give me a 1998 one?
A similar thing happens here: if the, say, vlc software needs libx264 to
be available at build time, the FreeBSD port of vlc should not add a
requirement of a particular version to that.
-mi
___
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: Viewing port changelogs
APseudoUtopia apseudouto...@gmail.com writes: I was wondering if there is any method to doing this from command line? I often don't have a web-browser available to me when working on the console. I'd be willing to write a script to display a changelog, but I'm not even sure where to get it from in the first place, other than that website. I generally use ports-mgmt/bpkg's `bpkg -F port` -- it launches freshports.org's entry for the given port in w3m in the console (assuming console browsers are OK for your case). ___ 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
