Re: (Very) bogus package dependencies
Andriy Gapon wrote: And a practical thought: it seems that in recent FreeBSD versions system tar can work rather well with the ISO CD9660 FS, so it should be enough to list directories in an image. What I am trying to say: before adding a dependency examine your options and choose the best one. Sorry to interrupt your interesting discussion guys. Is it okay with you that issue you talking about was resolved more than week ago? :-) Cheers, Alexander. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pkg-config and library dependencies
Ed Schouten wrote: Hello everyone, This morning I ran a `readelf -d' on an application that I maintain ... I've added a bunch of patches for the ports I use for audio/herrie. I didn't file any PR's yet, because I'd like to hear your opinions on this matter. Are my findings correct? Roger that. Those bugs must be fixed. Please submit your patches to the software authors. They will resist with some sort of "such change will break a lot of software builds" but may be are the lucky one. Just try ;-) However there is one thing which is more complicated than it seems to be. On FreeBSD pthead library still must be linked directly to program binary. And this is what we handle locally. Cheers, Alexander. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] glib20, UTF-8 and string collation
Alexandre,
The problem you exposed have its roots in Evo code. g_utf8_* stuff
defined to work on *utf-8* strings only and have undefined behaviour on
MBCS strings. It may sound stupid but crashes are allowed in this case
:-) Even we apply your latest patch the true problem solution will be
only postponed. We have to continue with Evo source. Find subject parser
part and ensure that it will be utf-8 encoded string at the end.
All the best,
Alexander.
Alexandre "Sunny" Kovalenko wrote:
On Wed, 2008-01-09 at 20:16 -0500, Joe Marcus Clarke wrote:
On Wed, 2008-01-09 at 19:40 -0500, Alexandre "Sunny" Kovalenko wrote:
On Wed, 2008-01-09 at 12:35 -0500, Joe Marcus Clarke wrote:
On Wed, 2008-01-09 at 10:53 -0500, Alexandre "Sunny" Kovalenko wrote:
I have seen recent commit WRT string collation in devel/glib20 by
marcus, so I have decided to check if there is an interest to fix SEGV
in g_utf8_collate when it is given 8-bit non-UTF-8 string(s) to collate.
Any commits I have made in the area of UTF-8 are completely accidental.
I am not the UTF-8 guy. Both bland and jylefort have expressed interest
in this. Perhaps one of them will comment.
I hope so. Just in case, they would decide to, I have reduced the
situation to the small program below. I get
GLib-CRITICAL **: g_convert: assertion `str != NULL' failed
and no core dump from this simple program, whereas Evolution manages to
pass NULL to strcoll further down in g_utf8_collate and get SEGV for its
pains.
That sounds like a no-no for Evolution to be dereferencing a NULL
pointer. Hopefully they'd fix this to prevent the problem.
It's not Evolution, it is glib, specifically g_utf8_collate, which would
call strcoll(3) blindly on the return of g_utf8_normalize inside
gunicollate.c. And now, I can get core dumped out of this simple program
as well, merely by setting CHARSET=en_US.UTF-8 (I had it is ASCII in the
terminal window, which would trigger different path within
g_utf8_collate).
Conversely, if the answer still is "Evolution should not have done
that", I will happily crawl back under my rock and keep my patch
locally.
I can't imagine you're alone in this. But then again, any Cyrillic mail
that comes my way is always spam, so what do I know.
More importantly, it is UTF-8 spam -- in order to trigger this, you need
KOI8-R or CP1251, and in the sorted column to boot. I suspect that
Latin1 or ShiftJIS would do the trick too.
Now, how about this: would you be amenable to this Really Harmless(tm)
patch, which merely adds error checking along the lines used in the same
function, about dozen lines up ;)
--- glib/gunicollate.c.B 2008-01-09 20:48:25.0 -0500
+++ glib/gunicollate.c 2008-01-09 20:49:35.0 -0500
@@ -166,6 +166,9 @@
str1_norm = g_utf8_normalize (str1, -1, G_NORMALIZE_ALL_COMPOSE);
str2_norm = g_utf8_normalize (str2, -1, G_NORMALIZE_ALL_COMPOSE);
+ g_return_val_if_fail (str1_norm != NULL, 0);
+ g_return_val_if_fail (str2_norm != NULL, 0);
+
if (g_get_charset (&charset))
{
result = strcoll (str1_norm, str2_norm);
I can add it to your files/extra-patch-glib_gunicollate.c, or package
it separately -- I really hate it when I start Evolution after portupgrade
to write some E-mails real quick, only to find out that I have forgotten
to patch glib... again.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] glib20, UTF-8 and string collation
Alexandre "Sunny" Kovalenko wrote: On Thu, 2008-01-10 at 13:18 +0900, Alexander Nedotsukov wrote: Alexandre, The problem you exposed have its roots in Evo code. g_utf8_* stuff defined to work on *utf-8* strings only and have undefined behaviour on MBCS strings. It may sound stupid but crashes are allowed in this case :-) Even we apply your latest patch the true problem solution will be only postponed. We have to continue with Evo source. Find subject parser part and ensure that it will be utf-8 encoded string at the end. While I see this as the noble goal, I fail to understand why asserts are OK 10 lines above my latest patch, but not in this specific place. Nor does this latest patch mask any issues in Evo -- you still get Glib-CRITICAL assert. Hell, you even get assert without the patch if your CHARSET is ASCII, but core dump if your CHARSET is xx_YY.UTF-8. If we are talking noble goals here, how about some consistency in the error handling? Those asserts does trivial arguments validation. Yours are slightly more than trivial which may be against existing glib practice. In any case I am against introducing such change locally. It lead to different execution paths in callers compared to other platforms. Also in a current form it suffer form potential memory leaks (guess where). Please save your energy for debates with glib developers if you want to. Even you convince hundredths like me it still will not make a valid argument for them ;-) On the more productive note: I have picked up more glib programming today than I had before (or cared to) -- it's easy to improve when you started from the veritable zero ;) However, it might not be sufficient to do what needs to be done to Evolution. One thing you can help me with, is to suggest glib function, I can feed arbitrary string of bytes (either counted or zero-terminated) and it will tell me whether this is valid UTF-8. g_print() apparently does this somehow, so there must be a way. See g_utf8_validate(). As promised, I'll crawl back under my rock and wait for rainy weekend to read some Evolution code. You better kick Evo authors into $some_painful_part_of_the_body :-) All the best, Alexander. BTW: What happened to "no top posting" rule? Alexandre "Sunny" Kovalenko wrote: On Wed, 2008-01-09 at 20:16 -0500, Joe Marcus Clarke wrote: On Wed, 2008-01-09 at 19:40 -0500, Alexandre "Sunny" Kovalenko wrote: On Wed, 2008-01-09 at 12:35 -0500, Joe Marcus Clarke wrote: On Wed, 2008-01-09 at 10:53 -0500, Alexandre "Sunny" Kovalenko wrote: I have seen recent commit WRT string collation in devel/glib20 by marcus, so I have decided to check if there is an interest to fix SEGV in g_utf8_collate when it is given 8-bit non-UTF-8 string(s) to collate. Any commits I have made in the area of UTF-8 are completely accidental. I am not the UTF-8 guy. Both bland and jylefort have expressed interest in this. Perhaps one of them will comment. I hope so. Just in case, they would decide to, I have reduced the situation to the small program below. I get GLib-CRITICAL **: g_convert: assertion `str != NULL' failed and no core dump from this simple program, whereas Evolution manages to pass NULL to strcoll further down in g_utf8_collate and get SEGV for its pains. That sounds like a no-no for Evolution to be dereferencing a NULL pointer. Hopefully they'd fix this to prevent the problem. It's not Evolution, it is glib, specifically g_utf8_collate, which would call strcoll(3) blindly on the return of g_utf8_normalize inside gunicollate.c. And now, I can get core dumped out of this simple program as well, merely by setting CHARSET=en_US.UTF-8 (I had it is ASCII in the terminal window, which would trigger different path within g_utf8_collate). Conversely, if the answer still is "Evolution should not have done that", I will happily crawl back under my rock and keep my patch locally. I can't imagine you're alone in this. But then again, any Cyrillic mail that comes my way is always spam, so what do I know. More importantly, it is UTF-8 spam -- in order to trigger this, you need KOI8-R or CP1251, and in the sorted column to boot. I suspect that Latin1 or ShiftJIS would do the trick too. Now, how about this: would you be amenable to this Really Harmless(tm) patch, which merely adds error checking along the lines used in the same function, about dozen lines up ;) --- glib/gunicollate.c.B 2008-01-09 20:48:25.0 -0500 +++ glib/gunicollate.c 2008-01-09 20:49:35.0 -0500 @@ -166,6 +166,9 @@ str1_norm = g_utf8_normalize (str1, -1, G_NORMALIZE_ALL_COMPOSE); str2_norm = g_utf8_normalize (str2, -1, G_NORMALIZE_ALL_COMPOSE);
Re: Darwin Calendar Server
This is not quite correct statement. ATM all required packages are present in the ports tree. ./run script fetched from the trunk may need a quick lobotomy course though. When I checked it out last time whole thing just works (well it still works :-) On 13.03.2009, at 12:31, 葉佳威 Jiawei Ye wrote: On Fri, Mar 13, 2009 at 12:49 AM, Paul Henrich wrote: Are there any efforts under way to port the Darwin Calendar Server (apple's apache-licensed CalDav server)? I searched the list archive and found no references to it. I have never ported anything to FreeBSD before, and I was thinking that this could be a good first project, so long as no one is already working on it. It seems like it would be a pretty simple package to port, being mainly python scripts with dependencies that are mostly already in the ports tree. Paul Henrich Henrich Interactive You may want to start with this: http://blog.royhooper.ca/2007/07/07/installing-the-darwin-calendar-server-on-freebsd There are some required packages not present in the ports tree. Cheers, Jiawei -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." ___ 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 " ___ 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: HEADS UP: GNOME 2.26 available for FreeBSD
On Tue, 21 Apr 2009 16:19:30 +0400 (MSD), Dmitry Morozovsky wrote: > JMC> Actually, I have always shied away from such things. We regularly get > JMC> requests to change the meta-port, but we long ago took the philosophy to > JMC> keep the Desktop meta-port as close to the official set of GNOME Desktop > JMC> components as possible. If we add an option for this, then we slide > JMC> down the slope of making everything optional. > JMC> > JMC> In the past I've simply prompted people to create their own local > JMC> meta-ports, or install x11/gnome2-lite (no user-share there), then build > JMC> on that for what they need. > > Well, then I suppose we should at least say something about this in release > notes, because in 7.2 one of *major* desktop application sets conflicts with > one of the *widest* server component. What do you propose to write in the release notes which could help Apache 1.3+ lovers? And may I in turn quote a bit of another release notes: http://www.apache.org/dist/httpd/Announcement1.3.html "We strongly recommend that users of all earlier versions, including 1.3 family release, upgrade to to the current 2.2 version as soon as possible." :-^) ___ 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: HEADS UP: GNOME 2.26 available for FreeBSD
On Wed, 22 Apr 2009 10:22:41 +0400 (MSD), Dmitry Morozovsky wrote: > On Wed, 22 Apr 2009, Alexander Nedotsukov wrote: > > AN> > Well, then I suppose we should at least say something about this in release > AN> > notes, because in 7.2 one of *major* desktop application sets conflicts with > AN> > one of the *widest* server component. > AN> > AN> What do you propose to write in the release notes which could help Apache > AN> 1.3+ lovers? > > Something like > > Full GNOME 2.26 installation is incompatible with Apache HTTP Server 1.3 > due to user-share GNOME component dependency on apache22. To resolve the issue, > either install gnome2-lite package or upgrade apache13 to apache22. This seems to be almost obvious to me. But surely can be stressed out. Am I right to assume we are talking about entry in ports/UPDATING? > > > AN> And may I in turn quote a bit of another release notes: > AN> > AN> http://www.apache.org/dist/httpd/Announcement1.3.html > AN> > AN> "We strongly recommend that users of all earlier versions, including 1.3 > AN> family release, upgrade to to the current 2.2 version as soon as possible." > AN> > AN> :-^) > > Please note that this recommendation is not located on HTTP server home page, > and 1.3 releases are still listed there, and not marked as "legacy" http://httpd.apache.org/ "The Apache Group is pleased to announce the *legacy* release of the 1.3.41 version of the Apache HTTP Server." > > Also, there are still rather wide set of httpd modules which are written for > 1.3 only :( ___ 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: Undefine WITH_DEBUG?
Thomas Zander wrote:
Hi,
I am trying to track down a problem with building mplayer with debug
symbols. The problem is that this seems possible (at least on my
machine) only if it is compiled with
-O{1|2|3} -fomit-frame-pointer
due to one of its incredibly smart inline-asm sections.
Now, when using WITH_DEBUG in a port, "-O" expressions are stripped
from the CFLAGS by the port build environment.
The actual issue is that users who define WITH_DEBUG globally for
their ports will probably run into this.
Is there an elegant solution to circumvent this and undefine WITH_DEBUG?
I think you need to add DEBUG_FLAGS="-g -O2 -fomit-frame-pointer".
Riggs
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for speed increases in "make index" and pkg_version for ports
Correct me if I wrong. Don't you missed the fact that chdir(2) changes process wide attribute? Though it's easy to fix with -C option. Stephen Montgomery-Smith wrote: Jeremy Chadwick wrote: On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote: I have been thinking a lot about looking for speed increases for "make index" and pkg_version and things like that. So for example, in pkg_version, it calls "make -V PKGNAME" for every installed package. Now "make -V PKGNAME" should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. I have a related question, pertaining to "make all-depends-list" and the utter atrocity that is the make variable ALL-DEPENDS-LIST. If you don't know what it is, look for ^ALL-DEPENDS-LIST around line 5175, in bsd.ports.mk. I posted this to [EMAIL PROTECTED], but now I am realizing that it is [EMAIL PROTECTED] that gets more responses. Anyway, here is a multithreaded program "all-depends-list" that can get you double the speed on dual processor systems, and even some small speed gains on single processor systems. E.g. all-depends-list /usr/ports/x11/xorg http://www.math.missouri.edu/~stephen/all-depends-list.c ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
