APseudoUtopia 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 plac
On Feb 17, 2012 5:41 PM, "Mikhail T." 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, declar
On Feb 17, 2012 5:17 PM, "Mikhail T." wrote:
>
> On 17.02.2012 17:05, Zhihao Yuan wrote:
>>
>> On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T.
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 L
On 02/17/2012 15:41, Mikhail T. wrote:
> 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, require
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
On 17.02.2012 17:05, Zhihao Yuan wrote:
On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T. 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
On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T. 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-
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
CC: Oliver Hartmann
On 2/15/12, Eric McCorkle 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
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
On Fri, Feb 17, 2012 at 7:59 AM, Mikhail T. 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-plu
I'd be willing to try building it on the Power(PC) platform.
On Wed, Feb 15, 2012 at 4:45 PM, Eric McCorkle 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 so
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
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
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@fre
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
___
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, critic
APseudoUtopia 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/c
On 17 February 2012 13:59, Mikhail T. 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-v
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), no
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 wid
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 -
2012/2/17 Andriy Gapon :
> on 17/02/2012 13:04 Olivier Smedts said the following:
>> 2012/2/17 Doug Barton :
>>> 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 aggressi
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/p
on 17/02/2012 13:04 Olivier Smedts said the following:
> 2012/2/17 Doug Barton :
>> 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 dep
Quoting Alex Dupre (from Fri, 17 Feb 2012 12:08:39 +0100):
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 ca
2012/2/17 Carmel :
> 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
>
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 us
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
_
Quoting Alex Dupre (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 whic
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 su
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 do
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-li
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
2012/2/17 Doug Barton :
> 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
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 bu
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
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 de
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 seriou
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
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
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.
Bread
42 matches
Mail list logo
