Re: mingw32-binutils
Max Brazhnikov wrote: > On Tuesday 11 December 2007, Sean McNeil wrote: > >> I was wondering if and when this port will be fixed. It is obvious that >> there was a faulty archive that was used when creating the distinfo. The >> following path will resolve the issue and the port build/works just fine: >> >> > > there are two open PR already: > ports/115782 > ports/117807 > > Could someone commit one of them? > Please. > I don't think that this port should reference 2.17.50. This archive is updated regularly as the 2.17 branch is hacked on. You can commit whatever you want to the distinfo file, but next time they upgrade that particular archive with the nightly build, it will be wrong once again. I recommend moving to the latest stable release of version 2.18. -- Coleman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Port: sdl-1.2.11_2,2
Chris Whitehouse wrote: > hi, > > [please could you cc me as I'm not subscribed, thanks] > > I'm trying to install projectm (http://projectm.sourceforge.net/). > Instructions say install sdl-1.3 due to some feature being necessary. > Can I keep sdl-1.2 and install sdl-1.3 without them conflicting? Any > pointers for how to do it, or an alternative approach? > > Thanks > > Chris > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > Chris, You could get sdl-1.3 from www.libsdl.org (I think you need to use SVN to get it). Then, when you configure make sure you specify a special prefix, such as: cd sdl-1.3 ./configure --prefix=/usr/local/libsdl13-root ...other args... make make install Then, when you build mproject, make sure that you add "--with-sdl-prefix=/usr/local/libsdl13-root" to the configure arguments, to tell it where SDL 1.3 is located. When you run the program, make sure that you set the LD_LIBRARY_PATH environment variable to /usr/local/libsdl13-root/lib, so that it looks for the SDL libraries there before looking in the normal library path. HTH, -- Coleman Kane ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Thunderbird, enigmail, and GCC 3.4
Hi, I'd like to call your attention to ports/117285: http://www.freebsd.org/cgi/query-pr.cgi?pr=117285 There seems to be some trouble when thunderbird is compiled with GCC 4.x. The current manifestation of this problem is a segfault on the registration (when thunderbird restarts) of the enigmail extension, which causes the install to fail to register the internal enigmime service. The above PR suggests downgrading thunderbird to GCC 3.4 until the problem is fixed. I don't know how many other extensions are affected by this. Either that, or the security/enigmail-thunderbird port should be modified so that it displays a message warning the user that it won't work after it is installed. AFAICT, it only affects amd64. Maybe USE_GCC can be 3.4 on amd64, and 3.4+ elsewhere? Thoughts? Comments? -- Coleman Kane ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Thunderbird, enigmail, and GCC 3.4
Xin LI wrote: > Coleman Kane wrote: >> Hi, >> >> I'd like to call your attention to ports/117285: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=117285 >> >> There seems to be some trouble when thunderbird is compiled with GCC >> 4.x. The current manifestation of this problem is a segfault on the >> registration (when thunderbird restarts) of the enigmail extension, >> which causes the install to fail to register the internal enigmime >> service. >> >> The above PR suggests downgrading thunderbird to GCC 3.4 until the >> problem is fixed. I don't know how many other extensions are affected >> by this. >> >> Either that, or the security/enigmail-thunderbird port should be >> modified so that it displays a message warning the user that it won't >> work after it is installed. >> >> AFAICT, it only affects amd64. Maybe USE_GCC can be 3.4 on amd64, and >> 3.4+ elsewhere? >> >> Thoughts? Comments? > > It seems that latest thunderbird gives me signal 8 (SIGFPE) upon > extension registration. I am busy at work right now and have no time > to investigate this, but building with gcc 3.4 did not worked for me > (I've modified both USE_GCC to 3.4, using -CURRENT as of today) :( > > Cheers, Neither way seems to be working for me now either, by the way... the enigmail bunch keeps blaming the problems on "using unofficial builds of thunderbird", but I don't really find that a fair excuse for an architecture that isn't supported by the mozilla people. Obviously the thing shouldn't be breaking here. I'm getting SIGFPE too btw, not SIGSEGV. -- Coleman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Thunderbird, enigmail, and GCC 3.4
Marcin Cieslak wrote: > Yuri Pankov wrote: > >>> AFAICT, it only affects amd64. Maybe USE_GCC can be 3.4 on amd64, and 3.4+ >>> elsewhere? >>> > > Don't know if it helps at all, but seamonkey works with enigmail very > nice, using gcc version 4.2.1 20070719 on amd64 (7.0-PRERELEASE, > seamonkey 1.1.8). > > --Marcin > How does seamonkey compare to Thunderbird? Is it really bloated? -- Coleman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Port: xorg-7.3_1
Laurent Grangeau wrote: > Hi there ! > > I've been using FreeBSD now for 4 months and it's a great OS. But is there a > way to install minimal Xorg server without installing the meta-port (and > thus, without all of the drivers) ? > > I'm using portinstall as the installer and I've been able to install > completely xorg-xserver and nvidia-driver until now, but I'm not able tu > launch the "startx" script. Where is that damned script (I mean, in which > package) ? > > I'm running minimal install of FreeBSD 7.0. > > Regards, > Do this: cd /usr/ports/x11-drivers/xorg-drivers make config (select the drivers you want installed) pkg_delete -f xf86-\* make deinstall clean install -- Coleman Kane ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CFT: Fix crashing in security/seahorse port
Hello ports people,
I'm attaching a patch that I've been working on to solve the problem of
the latest GNOME 2.22.x seahorse crashing (seahorse-agent,
seahorse-daemon, etc...) when the user is trying to use the keyring. The
problem arises because gnome-keyring attempts to use mlock() to
lock-down some secure memory for password storage, but this requires
superuser privileges on FreeBSD. Because of this, gnome-keyring returns
a NULL pointer when the alloc returns, but seahorse doesn't check this
value. It proceeds, instead, to attempt to use this pointer.
The patch will correct this behavior by checking the return value of a
small memory allocation to gnome_keyring_memory_try_alloc, during
process initialization. If the result is no a NULL pointer, then it
performs the desired remapping of the g_malloc, g_free, and other
functions so that they may use secure memory. If the return value is
NULL, then the remappings aren't performed and a warning is issued with
g_warning that informs the user that their seahorse system is using
unsecured memory for password storage.
I'd like to have some testers to ensure that it works fine in a more
general case, so send me your reports (and maybe copy gnome@ as well).
Unless it breaks something more, I'll commit it in the next couple days.
--
Coleman Kane
diff --git a/security/seahorse/Makefile b/security/seahorse/Makefile
index a065a09..d5d417f 100644
--- a/security/seahorse/Makefile
+++ b/security/seahorse/Makefile
@@ -8,6 +8,7 @@
PORTNAME= seahorse
PORTVERSION= 2.22.1
+PORTREVISION= 1
CATEGORIES= security gnome
MASTER_SITES= GNOME
DIST_SUBDIR= gnome2
diff --git a/security/seahorse/files/patch-libseahorse_seahorse-secure-memory.c b/security/seahorse/files/patch-libseahorse_seahorse-secure-memory.c
new file mode 100644
index 000..4a6300b
--- /dev/null
+++ b/security/seahorse/files/patch-libseahorse_seahorse-secure-memory.c
@@ -0,0 +1,42 @@
+--- libseahorse/seahorse-secure-memory.c.orig 2008-04-12 12:09:58.0 -0400
libseahorse/seahorse-secure-memory.c 2008-04-12 12:10:05.0 -0400
+@@ -97,13 +97,31 @@
+ void
+ seahorse_secure_memory_init ()
+ {
+-GMemVTable vtable;
+-
+-memset (&vtable, 0, sizeof (vtable));
+-vtable.malloc = switch_malloc;
+-vtable.realloc = switch_realloc;
+-vtable.free = switch_free;
+-vtable.calloc = switch_calloc;
+-g_mem_set_vtable (&vtable);
++if (seahorse_try_gk_secure_memory() == TRUE) {
++GMemVTable vtable;
++
++memset (&vtable, 0, sizeof (vtable));
++vtable.malloc = switch_malloc;
++vtable.realloc = switch_realloc;
++vtable.free = switch_free;
++vtable.calloc = switch_calloc;
++g_mem_set_vtable (&vtable);
++} else {
++g_warning ("Unable to allocate secure memory from gnome-keyring.\n");
++g_warning ("Proceeding with insecure password memory instead.\n");
++}
+ }
+
++gboolean
++seahorse_try_gk_secure_memory ()
++{
++gpointer p;
++
++p = gnome_keyring_memory_try_alloc (10);
++if (p != NULL) {
++gnome_keyring_memory_free (p);
++return TRUE;
++}
++
++return FALSE;
++}
diff --git a/security/seahorse/files/patch-libseahorse_seahorse-secure-memory.h b/security/seahorse/files/patch-libseahorse_seahorse-secure-memory.h
new file mode 100644
index 000..354b563
--- /dev/null
+++ b/security/seahorse/files/patch-libseahorse_seahorse-secure-memory.h
@@ -0,0 +1,11 @@
+--- libseahorse/seahorse-secure-memory.h.orig 2008-04-11 09:33:34.0 -0400
libseahorse/seahorse-secure-memory.h 2008-04-11 09:34:12.0 -0400
+@@ -34,6 +34,7 @@
+ } while (0)
+
+ /* This must be called before any glib/gtk/gnome functions */
+-voidseahorse_secure_memory_init (void);
++void seahorse_secure_memory_init (void);
++gboolean seahorse_try_gk_secure_memory (void);
+
+ #endif /* _SEAHORSE_SECURE_MEMORY_H_ */
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Latest OpenOffice and diable-jdk15 errors was Re: openoffice and java
On Sat, 2008-04-05 at 08:14 -0500, eculp wrote:
> Quoting Robert Huff <[EMAIL PROTECTED]>:
>
> >
> > David Booth writes:
> >
> >> I do not have a suggested fix, but I found similar behavior when
> >> I tried to compile it with JDK 1.6. Diablo 1.5 worked fine for
> >> me though.
> >
> > From the Makefile:
> >
> > USE_JAVA= yes
> > JAVA_BUILD= jdk
> > JAVA_VENDOR=freebsd bsdjava
> > .if (${OSVERSION} >= 70)
> > JAVA_VERSION= 1.5
> > .else
> > JAVA_VERSION= 1.4 1.5
> > .endif
> >
> > OOv2 is not rated for JDK-1.6.
>
> Interesting. Could it be that I am the only that gets the message
> with diablo?
>
> It would appear that I need to follow the instructions which include
> the config.log http://encontacto.net/Share/amd64/config.log and the
> pkg list http://encontacto.net/Share/amd64/ls_var-db-pkg.txt for the
> AMD64 and the same for the
> i386.http://encontacto.net/Share/i386/config.log and
> http://encontacto.net/Share/i386/ls_var-db-pkg.txt
>
> I have a couple of other machines doing the same with i386 with intel
> processors but hopefully these 2 will be enough for someone who
> understands the configuration to give some suggestions.
>
> Thanks for any and all help,
>
> ed
I may have some insight into your woes. Try removing "freebsd" from the
JAVA_VENDOR line. The "freebsd" vendor indicates the "diablo" release (I
think this should read "diablo", IMO). The "bsdjava" vendor indicates
the sun java from ports (ports/java/jdk15, etc.).
I am attaching a patch that applies this change nicely to the Makefile
(only doing this switch-up on 8.0+), as well as offers another knob to
allow building against the ports version of libicu (instead of using the
shipped version in OO.o, which has been causing other problems).
Cheers,
--
Coleman Kane
diff --git a/editors/openoffice.org-2-RC/Makefile b/editors/openoffice.org-2-RC/Makefile
index c870dc7..5655df5 100644
--- a/editors/openoffice.org-2-RC/Makefile
+++ b/editors/openoffice.org-2-RC/Makefile
@@ -7,6 +7,7 @@
PORTNAME?= openoffice.org
PORTVERSION?= 2.4.${SNAPDATE}
+PORTREVISION?= 1
CATEGORIES+= editors java
MASTER_SITES+= http://ooopackages.good-day.net/pub/OpenOffice.org/sources/ \
http://openoffice.lunarshells.com/sources/ \
@@ -53,7 +54,11 @@ WITHOUT_CPU_CFLAGS= true
USE_JAVA= yes
JAVA_BUILD= jdk
+.if (${OSVERSION} >= 80)
+JAVA_VENDOR= bsdjava
+.else
JAVA_VENDOR= freebsd bsdjava
+.endif
.if (${OSVERSION} >= 70)
JAVA_VERSION= 1.5
.else
diff --git a/editors/openoffice.org-2-RC/files/Makefile.knobs b/editors/openoffice.org-2-RC/files/Makefile.knobs
index c0c76e9..a5a9644 100644
--- a/editors/openoffice.org-2-RC/files/Makefile.knobs
+++ b/editors/openoffice.org-2-RC/files/Makefile.knobs
@@ -54,6 +54,13 @@ CONFIGURE_ARGS+= --enable-debug --enable-symbols=TRUE --enable-dbgutil
CONFIGURE_ARGS+= --enable-symbols=SMALL
.endif
+.if defined(WITH_SYSTEM_ICU)
+LIB_DEPENDS+= icule:${PORTSDIR}/devel/icu
+CONFIGURE_ARGS+= --with-system-icu=yes
+.else
+CONFIGURE_ARGS+= --with-system-icu=no
+.endif
+
pre-fetch:
.if (${OSVERSION} < 503001 && ${OSVERSION} >= 50) || (${OSVERSION} < 492000)
@${ECHO}
@@ -86,6 +93,11 @@ pre-fetch:
@${ECHO} "You can compile OOo without gnome VFS support with"
@${ECHO} "make -DWITHOUT_GNOMEVFS"
.endif
+.if !defined(WITH_SYSTEM_ICU)
+ @${ECHO}
+ @${ECHO} "You can compile OOo with devel/icu from ports with"
+ @${ECHO} "make -DWITH_SYSTEM_ICU"
+.endif
.if !defined(WITH_SYSTEM_FREETYPE)
@${ECHO}
@${ECHO} "You can compile OOo with freetype2 from ports with"
signature.asc
Description: This is a digitally signed message part
CFT: Patch for OpenOffice.org to fix icu-3.8 breakage, as well as -CURRENT diablo-jdk breakage
Hello everyone,
I've got a two-in-one patch I'd like to know if any volunteers would
like to test to get ports/editors/openoffice.org-2-RC built and
installed under the following circumstances where it may be failing:
1. You've installed the devel/icu 3.8+ port, and the build gives you
an undefined symbol named
"_ZN7icu_3_814LEFontInstance16getStaticClassIDEv" error
2. You're running 8.0-CURRENT and the KSE stuff has been removed and
you installed diablo-jdk. This may be crashing when it tries to run the
java stuff during the OO.o build, causing the build to fail with obscure
error messages.
My fix for #1, above, is to provide a new knob WITH_SYSTEM_ICU that
tells configure to use the local-system's installed icu library, rather
than the one that was shipped with the OO.o tarball. It seems that
during the build, the include path unwittingly brings in your system
headers, but then attempts to link against the shipped library. Both of
these are incompatible APIs, and the result is an inability to resolve a
symbol that is public in the OO.o version, but protected in the ports
version. I am also attaching a patch for devel/icu that applies this
permission change.
My fix for #2, above, is to set the build jdk to "bsdjava" for FreeBSD
8.0+, which results in having Mk/bsd.java.mk look for the ports
source-build rather than using the diablo-jdk for doing java compiles.
For other versions of FreeBSD, the default is left at what it was before
(diablo, then ports).
--
Coleman Kane
diff --git a/editors/openoffice.org-2-RC/Makefile b/editors/openoffice.org-2-RC/Makefile
index c870dc7..5655df5 100644
--- a/editors/openoffice.org-2-RC/Makefile
+++ b/editors/openoffice.org-2-RC/Makefile
@@ -7,6 +7,7 @@
PORTNAME?= openoffice.org
PORTVERSION?= 2.4.${SNAPDATE}
+PORTREVISION?= 1
CATEGORIES+= editors java
MASTER_SITES+= http://ooopackages.good-day.net/pub/OpenOffice.org/sources/ \
http://openoffice.lunarshells.com/sources/ \
@@ -53,7 +54,11 @@ WITHOUT_CPU_CFLAGS= true
USE_JAVA= yes
JAVA_BUILD= jdk
+.if (${OSVERSION} >= 80)
+JAVA_VENDOR= bsdjava
+.else
JAVA_VENDOR= freebsd bsdjava
+.endif
.if (${OSVERSION} >= 70)
JAVA_VERSION= 1.5
.else
diff --git a/editors/openoffice.org-2-RC/files/Makefile.knobs b/editors/openoffice.org-2-RC/files/Makefile.knobs
index c0c76e9..a5a9644 100644
--- a/editors/openoffice.org-2-RC/files/Makefile.knobs
+++ b/editors/openoffice.org-2-RC/files/Makefile.knobs
@@ -54,6 +54,13 @@ CONFIGURE_ARGS+= --enable-debug --enable-symbols=TRUE --enable-dbgutil
CONFIGURE_ARGS+= --enable-symbols=SMALL
.endif
+.if defined(WITH_SYSTEM_ICU)
+LIB_DEPENDS+= icule:${PORTSDIR}/devel/icu
+CONFIGURE_ARGS+= --with-system-icu=yes
+.else
+CONFIGURE_ARGS+= --with-system-icu=no
+.endif
+
pre-fetch:
.if (${OSVERSION} < 503001 && ${OSVERSION} >= 50) || (${OSVERSION} < 492000)
@${ECHO}
@@ -86,6 +93,11 @@ pre-fetch:
@${ECHO} "You can compile OOo without gnome VFS support with"
@${ECHO} "make -DWITHOUT_GNOMEVFS"
.endif
+.if !defined(WITH_SYSTEM_ICU)
+ @${ECHO}
+ @${ECHO} "You can compile OOo with devel/icu from ports with"
+ @${ECHO} "make -DWITH_SYSTEM_ICU"
+.endif
.if !defined(WITH_SYSTEM_FREETYPE)
@${ECHO}
@${ECHO} "You can compile OOo with freetype2 from ports with"
diff --git a/devel/icu/Makefile b/devel/icu/Makefile
index bc367b3..78edecb 100644
--- a/devel/icu/Makefile
+++ b/devel/icu/Makefile
@@ -7,7 +7,7 @@
PORTNAME= icu
PORTVERSION= 3.8.1
-PORTREVISION= 1
+PORTREVISION= 2
CATEGORIES= devel
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE}
MASTER_SITE_SUBDIR=${PORTNAME}
diff --git a/devel/icu/files/patch-common_unicode_rbbi.h b/devel/icu/files/patch-common_unicode_rbbi.h
new file mode 100644
index 000..68f2fc2
--- /dev/null
+++ b/devel/icu/files/patch-common_unicode_rbbi.h
@@ -0,0 +1,17 @@
+--- common/unicode/rbbi.h.orig 2008-04-16 09:58:20.0 -0400
common/unicode/rbbi.h 2008-04-16 09:59:00.0 -0400
+@@ -611,12 +611,14 @@
+ virtual int32_t getBreakType() const;
+ #endif
+
++public:
+ /**
+ * Set the type of the break iterator.
+ * @internal
+ */
+ virtual void setBreakType(int32_t type);
+
++protected:
+ /**
+ * Common initialization function, used by constructors and bufferClone.
+ * (Also used by DictionaryBasedBreakIterator::createBufferClone().)
signature.asc
Description: This is a digitally signed message part
Re: Thunderbird, enigmail, and GCC 3.4
On Mon, 2008-04-21 at 15:05 -0700, Xin LI wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi, Coleman,
>
> Finally I caught the issue for thunderbird. It was due to the
> difference between our floating point handling and Linux's counterpart.
> ~ The patch attached would fix the problem at thunderbird part.
>
> Unfortunately enigmail plugin compiled with gcc 4.x as shipped with
> FreeBSD 7.0+ would still crash with Signal 11, but with gcc 3.4 it would
> work fine. I have not yet figured out why this would happen...
>
> Cheers,
> - --
> Xin LI <[EMAIL PROTECTED]>http://www.delphij.net/
> FreeBSD - The Power to Serve!
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.8 (FreeBSD)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEUEARECAAYFAkgND6wACgkQi+vbBBjt66D0awCY4lzwwwmAaOLuoGEVo9OEHI8u
> ZwCfUi2KfOWUR3GFFCSiba6g5YK/sjg=
> =wLNg
> -END PGP SIGNATURE-
> plain text document attachment (thunderbird.diff)
> Index: Makefile
> ===
> RCS file: /home/ncvs/ports/mail/thunderbird/Makefile,v
> retrieving revision 1.90
> diff -u -p -r1.90 Makefile
> --- Makefile 19 Apr 2008 17:51:46 - 1.90
> +++ Makefile 21 Apr 2008 21:58:18 -
> @@ -8,7 +8,7 @@
>
> PORTNAME=thunderbird
> DISTVERSION= 2.0.0.12
> -PORTREVISION=2
> +PORTREVISION=3
> CATEGORIES= mail ipv6
> MASTER_SITES=${MASTER_SITE_MOZILLA_EXTENDED}
> MASTER_SITE_SUBDIR= thunderbird/releases/${DISTVERSION}/source
> Index: files/patch-Double.cpp
> ===
> RCS file: /home/ncvs/ports/mail/thunderbird/files/patch-Double.cpp,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-Double.cpp
> --- files/patch-Double.cpp16 Nov 2003 18:55:33 - 1.2
> +++ files/patch-Double.cpp21 Apr 2008 21:05:06 -
> @@ -1,20 +1,20 @@
> extensions/transformiix/source/base/Double.cpp.orig Thu Jan 30
> 09:26:46 2003
> -+++ extensions/transformiix/source/base/Double.cpp Sun Nov 16 01:46:42 2003
> -@@ -51,10 +51,10 @@
> +--- extensions/transformiix/source/base/Double.cpp.orig 2006-06-22
> 12:13:00.0 -0700
> extensions/transformiix/source/base/Double.cpp 2008-04-21
> 14:04:37.540570448 -0700
> +@@ -52,10 +52,10 @@
> //A trick to handle IEEE floating point exceptions on FreeBSD - E.D.
> #ifdef __FreeBSD__
> #include
> -#ifdef __alpha__
> -fp_except_t allmask = FP_X_INV|FP_X_OFL|FP_X_UFL|FP_X_DZ|FP_X_IMP;
> -#else
> -+#if defined(__i386__)
> ++#if defined(__i386__) || defined(__amd64__)
> fp_except_t allmask = FP_X_INV|FP_X_OFL|FP_X_UFL|FP_X_DZ|FP_X_IMP|FP_X_DNML;
> +#else
> +fp_except_t allmask = FP_X_INV|FP_X_OFL|FP_X_UFL|FP_X_DZ|FP_X_IMP;
> #endif
> fp_except_t oldmask = fpsetmask(~allmask);
> #endif
> -@@ -75,22 +75,31 @@
> +@@ -115,22 +115,31 @@
> #define TX_DOUBLE_HI32_EXPMASK 0x7ff0
> #define TX_DOUBLE_HI32_MANTMASK 0x000f
Hi Xin Li,
I am only now coming into this (and it seems that a significant number
of people have already reported on it). I can confirm that I've tried TB
and Enigmail from ports, and ever since around the time that 2.0.0.12
was brought in, I cannot get enigmail to work no matter what combination
of USE_GCC I have between mail/thunderbird and
mail/enigmail-thunderbird. I am using 8.0-CURRENT as of about four days
ago (just after sos@ imported the last of the sys/dev/ata fixes).
Since that time, I have managed to bring in some fixes to devel/glib20
that fix the shared-object module loading that used to make evolution
take 10 minutes to start up (seriously!). In addition, I sent some fixes
over to the seahorse crowd (and committed them to our seahorse port) to
fix breakage when using seahorse-agent w/ GnuPG. This allowed me to
finally use Evolution+GnuPG together.
I'll try the patch below on enigmail w/ TB to see if it fixes the
breakage in enigmail-tb for me now... but I may take a couple days time
getting reports back to you.
--
Coleman Kane
signature.asc
Description: This is a digitally signed message part
Update to net/gnome-netstatus to support new wlan system in -CURRENT
Hi,
I put together some changes to the net/gnome-netstatus applet to allow
it to detect and work with the new wlan interface system that was just
introduced in CURRENT.
This new code doesn't identify non-wlanN interfaces as wifi anymore.
I think it may need some help in getting signal-strength detection
properly using the if_ndis driver. Mine keeps telling me that the signal
strength is always 100% no matter where I walk in my apt.
--
Coleman Kane
diff --git a/net/gnome-netstatus/Makefile b/net/gnome-netstatus/Makefile
index 2e6c3f0..08be832 100644
--- a/net/gnome-netstatus/Makefile
+++ b/net/gnome-netstatus/Makefile
@@ -8,7 +8,7 @@
PORTNAME= gnome-netstatus
PORTVERSION= 2.12.1
-PORTREVISION= 5
+PORTREVISION= 6
CATEGORIES= net gnome
MASTER_SITES= ${MASTER_SITE_GNOME}
MASTER_SITE_SUBDIR= sources/${PORTNAME}/${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}
diff --git a/net/gnome-netstatus/files/patch-src_netstatus-sysdeps.c b/net/gnome-netstatus/files/patch-src_netstatus-sysdeps.c
index 5ffcd32..dca1903 100644
--- a/net/gnome-netstatus/files/patch-src_netstatus-sysdeps.c
+++ b/net/gnome-netstatus/files/patch-src_netstatus-sysdeps.c
@@ -1,5 +1,5 @@
--- src/netstatus-sysdeps.c.orig 2007-02-13 04:39:19.0 -0500
-+++ src/netstatus-sysdeps.c 2007-07-29 13:14:34.0 -0400
src/netstatus-sysdeps.c 2008-04-23 13:07:24.0 -0400
@@ -37,13 +37,26 @@
#ifdef __FreeBSD__
@@ -157,7 +157,12 @@
char *
netstatus_sysdeps_read_iface_wireless_details (const char *iface,
-@@ -548,21 +633,44 @@ netstatus_sysdeps_read_iface_wireless_de
+@@ -544,25 +629,52 @@ netstatus_sysdeps_read_iface_wireless_de
+ if (signal_strength)
+ *signal_strength = 0;
+
++#if __FreeBSD_version < 800036
+ if (g_strncasecmp (iface, "an", 2) &&
g_strncasecmp (iface, "wi", 2) &&
g_strncasecmp (iface, "ath", 3) &&
g_strncasecmp (iface, "ndis", 4) &&
@@ -168,6 +173,9 @@
+ g_strncasecmp (iface, "rum", 3) &&
+ g_strncasecmp (iface, "ray", 3) &&
g_strncasecmp (iface, "acx", 3))
++#else
++ if (g_strncasecmp (iface, "wlan", 4))
++#endif
return error_message;
+#if __FreeBSD_version < 700046
signature.asc
Description: This is a digitally signed message part
devel/subversion* ports and www/neon26
Hello, Since www/neon28 was moved into ports, subversion still depends upon www/neon26 (which conflicts w/ 2.8). I have been able to tell subversion to use neon 2.8 by modifying the subversion Makefile appropriately. Is there any specific reason to not move subversion to default to use www/neon28 instead of www/neon26 ? -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: FreeBSD Port: xf86-video-radeonhd-1.2.1_1
On Mon, 2008-06-16 at 18:41 +0200, jean-christophe wrote: > hello, > > i would like know if a new version of radeonhd port is prevu. > > i read in the xorg wiki that the 3D support for my carte was bear with a > latest version of radeonhd and there dependances. > > i am not enough any experiences in freebsd for modify him self the port. > > i am with freebsd-current and it isn't with the actualy version of > radeonhd. > > i am waiting for install blender for working in my project. > > if not updating this port soon i must try to update him self but i am > not your experience and i was need more time as you to get a fonctionnal > port. > > thanks for your reply. > best regard > jean-christophe. Probably not until they release a new driver. However, I've just been following their git tree directly and that works pretty well for me. -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: avahi-gtk
On Wed, 2008-07-02 at 15:57 -0400, Chuck Robey wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I'm having problems building this, it dpoesn't see it's own defintion for > symbol > avahi_init_i18n (it's defined it it's own code but I guess not linked in). I > went and googled it, it's apparently been spotted as a problem with all > avahi-gtk versions at 6.22.2 and earlier, and it seems that our port is at > 6.22.1. it was fixed for sure in .4. Myu problem is, I can't for the life of > me see where the damn minor version is set. All i can see is, it's set to > 6.22, and no hint of a trailing .1. > > So, either, if anyone knows what the fix is, OR if anyone knows where the > minor > is being set, I'd be happy enough. > > You know, just as an aside, one of my problems with today's ports are the huge > reliance on sub-makefiles. It nearly always makes things more difficult to > trace out errors. Yes, it's more elegant, but I just don't believe that > selling > out for elegance is a good idea; I would rather have it easier to see and fix, > that just seems so obvious to me. > > Don't get me wrong, I very much like things like bsd.port.mk, it's things like > hiding the names, version numbers, things like that about the ports that I > dislike, like the bsd.gnome.mk, and all the masterdirs. I just personally > don't > see the gain it making references unobvious. It isn't in any of the sub-makefiles. Port net/avahi-gtk is a slave of net/avahi-app (according to MASTERDIR). Your answer is in net/avahi-app/Makefile. BTW, avahi (and slaves) is versioned 0.6.22, not 6.22. You want to change it to 0.6.22.4 I guess... > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.9 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkhr3aoACgkQz62J6PPcoOnT+wCgnMNr2jxKd3TVfsdAJnTWsDCO > 1G8Anivr6mIL0xX4brtR5PkwBAv/q0dy > =wrL7 > -END PGP SIGNATURE- > _______ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Coleman Kane signature.asc Description: This is a digitally signed message part
APNG patch for graphics/png port
Hello,
I recently played with building Thunderbird 3.0b1 from source (it works
pretty well, btw). I was playing with some of the options to enable
using the system versions of a number of libraries, rather than relying
upon statically linking them into the project.
One thing that I noticed was the APNG patch from here:
* http://littlesvr.ca/apng/.
This seems to be expected by Thunderbird and is part of the latest
source tree. Mozilla has been maintaining a format spec here:
* https://wiki.mozilla.org/APNG_Specification
Sadly the patch has lagged behind the latest releases of libpng. I
merged the patch into the latest version (1.2.33) that we use, and have
made an appropriate change to the port files of graphics/png. I think
that APNG support from libpng may be useful in other software as well.
I am attaching the patch, to apply in /usr/ports, for anyone to test. So
far it doesn't seem to regress anything for me, and I can use
thunderbird 3 with --with-system-png=/usr/local in my .mozconfig. I'd
like to see some other testers, and get a comment from the graphics/png
maintainer.
--
Coleman Kane
--- graphics/png/Makefile
+++ graphics/png/Makefile
@@ -7,6 +7,7 @@
PORTNAME= png
PORTVERSION= 1.2.33
+PORTREVISION= 1
CATEGORIES= graphics
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE}
MASTER_SITE_SUBDIR= lib${PORTNAME}
@@ -34,8 +35,15 @@ MAN3= libpng.3 libpngpf.3
MAN5= png.5
MANCOMPRESSED= maybe
+OPTIONS= APNG "Enable APNG Support" on
+
.include
+.if defined(WITH_APNG)
+PATCH_SITES= http://people.FreeBSD.org/~cokane/patches/
+PATCHFILES+= libpng-apng.patch
+.endif
+
post-extract:
# Please don't delete the following line - this link used by ghostscript* ports
@${LN} -sf ${WRKSRC} ${WRKDIR}/libpng
--- graphics/png/distinfo
+++ graphics/png/distinfo
@@ -1,3 +1,6 @@
MD5 (libpng-1.2.33.tar.bz2) = 0532c28ba1b17ee2095ad50731c2c75c
SHA256 (libpng-1.2.33.tar.bz2) = af3a8150fedaf3ea561c10c59fa828f71f732ade06e3f3d13fa453629c470800
SIZE (libpng-1.2.33.tar.bz2) = 651555
+MD5 (libpng-apng.patch) = fb1696d9e16d7813a1e7410ad1649612
+SHA256 (libpng-apng.patch) = f406d7899aeac2d3e634b14b98dbb53f2b671265d711f564eaf380ae37048fbc
+SIZE (libpng-apng.patch) = 54713
signature.asc
Description: This is a digitally signed message part
Re: APNG patch for graphics/png port
On Mon, 2008-12-15 at 02:28 +0300, Andrey Chernov wrote: > On Sun, Dec 14, 2008 at 01:22:34PM -0500, Coleman Kane wrote: > > One thing that I noticed was the APNG patch from here: > > * http://littlesvr.ca/apng/. > > This seems to be expected by Thunderbird and is part of the latest > > source tree. Mozilla has been maintaining a format spec here: > > * https://wiki.mozilla.org/APNG_Specification > > It should be either accepted by libpng developers (and this way appears in > the png port automatically) or separate slave apng port should be made. > Porter is poor replacement for developer, especially considering lots of > security holes libpng long history. > That is a good point, though the author of libpng suggests the MNG format for animated graphics (and JNG as a jpeg version). This leads me to believe that he's probably uninterested in actually incorporating the APNG patch into libpng. Honestly, I don't understand why the mozilla people have decided to push this APNG standard now. Maybe I'll just go and post into that mozilla issue a complain about wasting development time on an unfinished spec that seems like a reimplementation of MNG. I'll write to Greg (author) and see what he says. This is one of those annoying points in software evolution where big entity A begins spreading around a patched version of Author B's software, which may end up rivaling Author B's implementation of the patch's functionality. -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: APNG patch for graphics/png port
On Sun, 2008-12-14 at 22:54 -0600, Jeremy Messenger wrote: > On Sun, 14 Dec 2008 12:22:34 -0600, Coleman Kane > wrote: > > > Hello, > > > > I recently played with building Thunderbird 3.0b1 from source (it works > > pretty well, btw). I was playing with some of the options to enable > > using the system versions of a number of libraries, rather than relying > > upon statically linking them into the project. > > We should keep compile static link, because PNG folks disapprove Mozilla's > APNG patch. It's what we did with Firefox 3. > > Cheers, > Mezz > Any idea why the mozilla folk jumped on further developing APNG, rather than just using (much more mature) MNG for the same purpose? -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: APNG patch for graphics/png port
On Mon, 2008-12-15 at 23:02 -0600, Jeremy Messenger wrote: > On Mon, 15 Dec 2008 16:38:56 -0600, Coleman Kane > wrote: > > > On Sun, 2008-12-14 at 22:54 -0600, Jeremy Messenger wrote: > >> On Sun, 14 Dec 2008 12:22:34 -0600, Coleman Kane > >> wrote: > >> > >> > Hello, > >> > > >> > I recently played with building Thunderbird 3.0b1 from source (it > >> works > >> > pretty well, btw). I was playing with some of the options to enable > >> > using the system versions of a number of libraries, rather than > >> relying > >> > upon statically linking them into the project. > >> > >> We should keep compile static link, because PNG folks disapprove > >> Mozilla's > >> APNG patch. It's what we did with Firefox 3. > >> > >> Cheers, > >> Mezz > >> > > > > Any idea why the mozilla folk jumped on further developing APNG, rather > > than just using (much more mature) MNG for the same purpose? > > I have no idea. The google has found useful links and I think two URLs > might help you. I didn't read there as I have no interest with and don't > care about APNG vs MNG. > > http://mozilla.wikia.com/wiki/APNG_vs_MNG > http://en.wikipedia.org/wiki/APNG#History > > Cheers, > Mezz > Short version: whatwg.org and Mozilla people seemed to think that an "Animated PNG" specification would work best (quickest adoption) if they piggy-backed it on top of the already supported PNG file format. Due to the political implications of such things, the hill was much steeper to climb to get everyone to agree to use MNG than it was to get them to use APNG, even though the latter is basically a reimplementation of the former (actually MNG is a superset of APNG functionality). One key component was that a non-APNG viewer will still view the first image in an APNG, while an MNG file would come up with a "broken image" placeholder. Another key component was that IE would be more likely to adopt it (we remember how long it took them to adopt PNG, right?) if it was based on PNG rather than MNG. The PNG maintainers, coming at it from a pure maintainability standpoint stood their ground and said that they didn't want to absorb the burden of maintaining an "Animated" feature within libpng, they would rather that be handled by the separate libmng. So now we basically have an unofficial fork of libpng that I'd call "mozilla-libpng", which implements the desired features from WHATWG, but makes a very liberal interpretation of the PNG specification. Oh yeah, and it also is based upon a Specification started by an SoC'er, and a patchset which is no longer maintained by him, and instead is maintained by mozilla.org at their discretion (read: whenever they update their png dependency). Again it is unofficial, and Mozilla.org's specification is unfinished as of now. And, from the bug report linked in one of the articles above, it doesn't seem like the two camps are getting along very well. PNG maintainers won't accept APNG, and WHATWG and Mozilla.org won't replace it with MNG. Especially now that APNG is pretty much out of the bag, my opinion is that the libpng people should either adopt APNG into their tree, or yield control over PNG to Mozilla.org. It's not about being the "right" thing to do, it is about avoiding a highly user-confusing feature-based fork of a file format. Okay. So that was actually still kinda long. -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: HEADS UP multi processor compilations for everyone
On Tue, 2009-03-24 at 15:54 +0100, Pav Lucistnik wrote: > Niclas Zeising píše v út 24. 03. 2009 v 15:28 +0100: > > > Not to nitpick or be an annoyance, but you might want to document this > > in ports(7) or make.conf(5) (or both) so it doesn't get lost in the > > mail-lists or if people are not reading ports@ > > I will document it soon, thinking The Handbook would be best place. > Definitely add it to UPDATING too. This will allow people who typically do something like "make configure && make -j3" to now know that they don't have to. It will also allow others to know why ports compilation on their multi-core boxes suddenly uses a lot more CPU time. BTW, Good work, Pav! Thank you for taking the time to do what so many of us wanted but wouldn't do. -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: HEADS UP multi processor compilations for everyone
On Tue, 2009-03-24 at 16:19 +0100, Pav Lucistnik wrote: > Coleman Kane píše v út 24. 03. 2009 v 10:58 -0400: > > On Tue, 2009-03-24 at 15:54 +0100, Pav Lucistnik wrote: > > > Niclas Zeising píše v út 24. 03. 2009 v 15:28 +0100: > > > > > > > Not to nitpick or be an annoyance, but you might want to document this > > > > in ports(7) or make.conf(5) (or both) so it doesn't get lost in the > > > > mail-lists or if people are not reading ports@ > > > > > > I will document it soon, thinking The Handbook would be best place. > > > > > > > Definitely add it to UPDATING too. This will allow people who typically > > do something like "make configure && make -j3" to now know that they > > This would break very fast -- it's passing -j3 to port Makefile instead > of vendor Makefile. This has worked fine for me for countless years, except where the vendor's Makefiles were not parallel-safe. This has been my trick to get larger things (like mysql or xorg-server) to make in parallel. It *did* work. If this has changed, then it definitely warrants mention in UPDATING. > > > don't have to. It will also allow others to know why ports compilation > > on their multi-core boxes suddenly uses a lot more CPU time. > > Same CPU time, less wall time, more CPU utilization :) > Thanks for the clarification... that's what I meant :) -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: MAKE_JOBS_SAFE with gmake
On Tue, 2009-03-24 at 12:43 -0700, Doug Barton wrote: > Question, > > I'm testing my ports for MAKE_JOBS_SAFE-ness, and came across this > message when building xscreensaver (which uses gmake): > > gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to > parent make rule. > > I have zero gmake fu, can anyone help me make sense of that? The good > news is that the build finished successfully ... > > > Doug > I'll give it a stab, as I've dealt with this when trying to write a "one makefile to rule them all" build system recently (in other words, I maintain a collection of 200+ packages and my makefile attempts to call $(MAKE) within those subdirectories). The GNU make process for some reason was not able to determine the type of your "make" that was used for building a target of the following flavor: mytarget: deps dep2 ... $(MAKE) -C $(mytargetdir) mytarget Supposedly, GNU make is supposed to recognize that $(MAKE) above is a "make program" and not a "normal program" (such as install, BSD make, sed, etc). In the event that it is calling a compatible GNU make program, it can (through some means I don't fully understand) provide access to its job pool to the "child" (the make process that will be executed in the target above). This allows, for instance, you to pass -j 4 to the parent make process, and it will guarantee that no more than four jobs get run, even if there are subdirs-within-subdirs, etc Something is preventing this detection from succeeding in your case. I see this a lot as well (in my own make system), but I've chosen to ignore it in my environment. I think, in my case, that I am using $(MAKE) within an $(eval ...) block and the $(MAKE) gets expanded before the $(eval ...) does, making the GNU make program actually see something like this, before it actually builds the target list: mytarget: deps dep2 ... /usr/local/bin/gmake -C $(mytargetdir) mytarget Which may confuse it. Here's a link to the ambiguous description on the GNU make website: http://www.gnu.org/software/automake/manual/make/Error-Messages.html -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: MAKE_JOBS_SAFE with gmake
On Tue, 2009-03-24 at 16:02 -0400, Coleman Kane wrote: > On Tue, 2009-03-24 at 12:43 -0700, Doug Barton wrote: > > Question, > > > > I'm testing my ports for MAKE_JOBS_SAFE-ness, and came across this > > message when building xscreensaver (which uses gmake): > > > > gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to > > parent make rule. > > > > I have zero gmake fu, can anyone help me make sense of that? The good > > news is that the build finished successfully ... > > > > > > Doug > > > > I'll give it a stab, as I've dealt with this when trying to write a "one > makefile to rule them all" build system recently (in other words, I > maintain a collection of 200+ packages and my makefile attempts to call > $(MAKE) within those subdirectories). > > The GNU make process for some reason was not able to determine the type > of your "make" that was used for building a target of the following > flavor: > > mytarget: deps dep2 ... > $(MAKE) -C $(mytargetdir) mytarget > > Supposedly, GNU make is supposed to recognize that $(MAKE) above is a > "make program" and not a "normal program" (such as install, BSD make, > sed, etc). In the event that it is calling a compatible GNU make > program, it can (through some means I don't fully understand) provide > access to its job pool to the "child" (the make process that will be > executed in the target above). This allows, for instance, you to pass -j > 4 to the parent make process, and it will guarantee that no more than > four jobs get run, even if there are subdirs-within-subdirs, etc > > Something is preventing this detection from succeeding in your case. I > see this a lot as well (in my own make system), but I've chosen to > ignore it in my environment. I think, in my case, that I am using > $(MAKE) within an $(eval ...) block and the $(MAKE) gets expanded before > the $(eval ...) does, making the GNU make program actually see something > like this, before it actually builds the target list: > mytarget: deps dep2 ... > /usr/local/bin/gmake -C $(mytargetdir) mytarget > > Which may confuse it. > > Here's a link to the ambiguous description on the GNU make website: > http://www.gnu.org/software/automake/manual/make/Error-Messages.html > > Additionally: http://lists.samba.org/archive/distcc/2004q1/002160.html -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: HEADS UP multi processor compilations for everyone
On Wed, 2009-03-25 at 19:30 +0300, Dmitry Marakasov wrote: > * Pav Lucistnik (p...@freebsd.org) wrote: > > > > > This would break very fast -- it's passing -j3 to port Makefile instead > > > > of vendor Makefile. > > > > > > This has worked fine for me for countless years, except where the > > > vendor's Makefiles were not parallel-safe. This has been my trick to get > > > larger things (like mysql or xorg-server) to make in parallel. It *did* > > > work. If this has changed, then it definitely warrants mention in > > > UPDATING. > > > > Then it must have worked all these years by pure chance :) > > Be the way, could anyone clarify how this works? My idea was that > passing -j to port Makefile does nothing, as make/gmake on vendor's > Makefile is ran without any -j flags -> you get usual singlethreaded > build. However, I have a broken port, which uses gmake and something > like that: > > sometarget: > (cd xxx; make) > > and that fails with -j (make: illegal option -- -). So is there > some magic with recursive make calls and -j? > When processing a Makefile, make's that support concurrent operation look for targets that will execute the $(MAKE) program. Whenever a compliant make is run (make or gmake), if it detects $(MAKE) in a rule then it will automatically expand that rule into a child process that has some sort of magical connection to the parent process. The connection allows the different make processes to share the same pool of "process count" resources amongst each other. I am not sure what the implementation is, but this communication mechanism allows child "make" processes called with "$(MAKE) ..." from inside a Makefile to globally only use N children (from -j N), and otherwise block until more "free jobs" are available amongst their shared job pool. I hope that's clear... Probably more so than the explanation given on GNU make's manual. -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: REQUEST FOR TESTERS: `devel/mingw32-gcc'
Coleman Kane wrote: Lev Serebryakov wrote: Hello ports, Latest versions of `mingw32-binutils' and `mingw32-bin-msvcrt' were committed. `mingw32-gcc' is on pipeline. But it is BIG update: new version is 4.2.0 I ask you to test this `almost new' port before commit. http://lev.serebryakov.spb.ru/download/port-mingw32-gcc-4.2.0.tar.gz Many thanks to Coleman Kane , who helps me to prepare this update. I'd like to know what everyone else's experience with these new mingw32- ports are. So far I have been building Win32 applications from my FreeBSD box with these versions quite successfully. I think that the binutils and GCC are actually newer than the ones currently shipping with the MinGW32 binary distribution too. -- Coleman Kane I haven't seen any activity on the above email, and I am curious if: 1) It was missed (and this really does affect people) 2) Nobody cross-compiles using the mingw32-* ports (it is really very handy!) 3) Nobody really cares that mingw32-gcc will move from 3.4.5 --> 4.2.0 Please, if this affects you test out the above port tarball! Otherwise, this will end up going in and not take into account any problems that might arise in your environment. -- Coleman Kane ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-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: REQUEST FOR TESTERS: `devel/mingw32-gcc'
On Sat, 2009-03-28 at 20:37 -0500, Stephen Montgomery-Smith wrote: > Coleman Kane wrote: > > > I haven't seen any activity on the above email, and I am curious if: > > 1) It was missed (and this really does affect people) > > 2) Nobody cross-compiles using the mingw32-* ports (it is really very > > handy!) > > 3) Nobody really cares that mingw32-gcc will move from 3.4.5 --> 4.2.0 > > > > Please, if this affects you test out the above port tarball! Otherwise, > > this will end up going in and not take into account any problems that > > might arise in your environment. > > > > -- > > Coleman Kane > > > I just saw that this message is about two years old, and that the commit > must have been made years ago. > > Sorry for the noise. Thanks. It was handled off-line and we did the upgrade. -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: parallel builds revisited
On Thu, 2007-04-12 at 21:07 +0200, Benjamin Lutz wrote: > On Thursday 12 April 2007 11:06, Garrett Cooper wrote: > > I dunno how you want to approach this, but gmake does recommend 2 > > jobs be run in parallel for HTT enabled chips, and 3 or 4 jobs for a > > dual core machines. > > -Garrett > > So far the approach is one job per CPU. I'll do some benchmarks lateron > to determine wether it really helps to run more jobs. For the KDE > ports, my gut feeling is that the improvement would be negligible. I'll > have to evaluate non-C++ ports like gnome-*, where the compilation time > per file is shorter. > > Of course, to make proper use of distcc, at least #cores + 1 jobs are > required. I'll keep that in mind. > > Cheers > Benjamin I have always seen that NCPUS+1 was a good heuristic. -- Coleman Kane ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: xorg upgrade plans
On Wed, 2007-05-02 at 15:43 -0400, Kris Kennaway wrote: > On Wed, May 02, 2007 at 02:40:26PM -0500, Stephen Montgomery-Smith wrote: > > > > > > On Wed, 2 May 2007, Kris Kennaway wrote: > > > > >Hi all, > > > > > >After many months of hard work (mostly by flz@, as well as others) we > > >are approaching readiness of the xorg 7.2 upgrade. Because this is a > > >huge and disruptive change, we're going to approach it very carefully. > > > > I tried X 7.2 about a week ago, and I can report some minor problems. > > I've been following the xorg 7.2 tree for some time, and recently around the time of either the move to /usr/local or the ruby18 update (they happened pretty close together for me) portupgrade -na seems to have broken for me. It just hangs there forever, seemingly doing something in the background and never actually starts checking for updated ports. Tried rebuilding INDEX, INDEX.db, and pkgdb.db to no avail... Once I let it go overnight and the process died with an Illegal Instruction signal... > > First, "pkg_delete -a" took far too long. X7.2 has so many dependencies, > > that I sense that it is beginning to overload the ports structure. My > > guess is that "pkg_delete -a" spends a huge amount of time just checking > > out all the dependencies before it even starts. > > To some extent this is true. It's not something we can fix now though. > > > Secondly, X7.2 as I tried it wouldn't "startx" if some other login had > > created a .Xauthority file. While "rm .Xauthority" solved the problem > > completely, I don't think this is user friendly. > > I think I ran into this once a while back, I don't know what is the > correct solution. > > Kris -- Coleman Kane ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: xorg upgrade plans
On Thu, 2007-05-03 at 15:37 -0400, Robert Huff wrote: > Danny Pansters writes: > > > /usr/X11R6 was a long standing bug about to be fixed once and for > > all. IIRC it originated from fixed paths in the old XFree. It > > won't be missed or mourned :) > > While I understand why this is going to happen, I've been of > the opinion it ought to be retained with contents limited to the > installed X Windows distribution. > > > Robert Huff This move was also already done on a number of Linux distros... -- Coleman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Xorg 7.2 index problem
On Fri, 2007-05-11 at 03:16 -0400, Kris Kennaway wrote: > On Fri, May 11, 2007 at 09:12:05AM +0200, [LoN]Kamikaze wrote: > > Kris Kennaway wrote: > > > On Fri, May 11, 2007 at 08:45:56AM +0200, [LoN]Kamikaze wrote: > > >> # make index > > >> Generating INDEX-6 - please wait..cut: stdin: Illegal byte sequence > > >> "Makefile", line 32: warning: "/usr/bin/cut -f 1 -d '|' < > > >> /usr/ports/audio/mbrolavox/voices.conf" returned non-zero status > > >> > > >> Does anyone else have this problem? > > > > > > Do you have a nonstandard locale set, and does this warning also occur > > > with CVS index? > > > > > > Kris > > > > My locale is en_GB.UTF-8. > > Probably the cause, I bet it would also give the warning with a CVS index. > > Kris I have the same error using en_US.UTF-8 -- Coleman Kane ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: REQUEST FOR TESTERS: `devel/mingw32-gcc'
Lev Serebryakov wrote: Hello ports, Latest versions of `mingw32-binutils' and `mingw32-bin-msvcrt' were committed. `mingw32-gcc' is on pipeline. But it is BIG update: new version is 4.2.0 I ask you to test this `almost new' port before commit. http://lev.serebryakov.spb.ru/download/port-mingw32-gcc-4.2.0.tar.gz Many thanks to Coleman Kane <[EMAIL PROTECTED]>, who helps me to prepare this update. I'd like to know what everyone else's experience with these new mingw32- ports are. So far I have been building Win32 applications from my FreeBSD box with these versions quite successfully. I think that the binutils and GCC are actually newer than the ones currently shipping with the MinGW32 binary distribution too. -- Coleman Kane ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: REQUEST FOR TESTERS: `devel/mingw32-gcc'
Coleman Kane wrote: Lev Serebryakov wrote: Hello ports, Latest versions of `mingw32-binutils' and `mingw32-bin-msvcrt' were committed. `mingw32-gcc' is on pipeline. But it is BIG update: new version is 4.2.0 I ask you to test this `almost new' port before commit. http://lev.serebryakov.spb.ru/download/port-mingw32-gcc-4.2.0.tar.gz Many thanks to Coleman Kane <[EMAIL PROTECTED]>, who helps me to prepare this update. I'd like to know what everyone else's experience with these new mingw32- ports are. So far I have been building Win32 applications from my FreeBSD box with these versions quite successfully. I think that the binutils and GCC are actually newer than the ones currently shipping with the MinGW32 binary distribution too. -- Coleman Kane I haven't seen any activity on the above email, and I am curious if: 1) It was missed (and this really does affect people) 2) Nobody cross-compiles using the mingw32-* ports (it is really very handy!) 3) Nobody really cares that mingw32-gcc will move from 3.4.5 --> 4.2.0 Please, if this affects you test out the above port tarball! Otherwise, this will end up going in and not take into account any problems that might arise in your environment. -- Coleman Kane ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: xorg 7.3: ati card comes up blank
Mathias Picker wrote: After my upgrade on -current to xorg 7.3 the ATI Radeon RV350 Mobility 9600 M10 NP in my travelmate 290 comes up blank. I'm now using the vesa driver. Has anyone else experienced this? my sytem: FreeBSD mp.virtual-earth.de 7.0-CURRENT FreeBSD 7.0-CURRENT #3: Fri Sep 14 xorg.conf: happens also without xorg.conf one additional data point: if I try to disable one of the other outputs (e.g. monitor-vga, monitor-S-video) the X server does not start at all but says there are no usable screens configured...? Thanks for any help, Mathias Maybe you had WITHOUT_AIGLX enabled when you built Xorg 7.2, and then this flag was not set for Xorg 7.3. Your video hardware is identical to mine, and it is working now after some effort on my part. Start here: http://bugs.freedesktop.org/show_bug.cgi?id=11870 Apply the patch into /usr/src/sys/dev/drm and then rebuild and reinstall your drm kernel modules. This should allow Xorg to work with your rv350 and have AIGLX support. You will probably then end up in a situation where the new radeon_drv.so breaks your GLX support. I downloaded the latest xf86-video-ati driver from git://anongit.freedesktop.org/ and built/installed it over the top of the one that is gotten from /usr/ports/x11-drivers/xf86-video-ati. -- Coleman Kane ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Regression in evolution-data-server 2.8.1 import
Hello, I am a user of the amd64 platform and I have noticed a
regression that was introduced with GNOME 2.16.1, and specifically
databases/evolution-data-server 2.8.1.
The bug fixed by ports pr-93215 had its patch removed, but the bug
was never addressed by GNOME. The source has been slightly altered, but
the large memory allocation still occurs.
I am attaching a new patch to the camel/camel-object.c file that was
originally patched by:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/databases/evolution-data-server/files/Attic/patch-camel_camel-object.c
--
Coleman Kane
--- camel-object.c.orig Wed Oct 18 15:53:34 2006
+++ camel-object.c Wed Oct 18 15:55:01 2006
@@ -457,7 +457,7 @@
}
/* we batch up the properties and set them in one go */
- if (!(argv = g_try_malloc ((gulong)(sizeof (*argv) + (count -
CAMEL_ARGV_MAX) * sizeof (argv->argv[0])
+ if (!(argv = g_try_malloc ((guint32)(sizeof (*argv) + (count -
CAMEL_ARGV_MAX) * sizeof (argv->argv[0])
return -1;
argv->argc = 0;
@@ -537,8 +537,8 @@
count = g_slist_length(props);
- arggetv = g_malloc0(sizeof(*arggetv) + (count - CAMEL_ARGV_MAX) *
sizeof(arggetv->argv[0]));
- argv = g_malloc0(sizeof(*argv) + (count - CAMEL_ARGV_MAX) *
sizeof(argv->argv[0]));
+ arggetv = g_malloc0((guint32)(sizeof(*arggetv) + (count -
CAMEL_ARGV_MAX) * sizeof(arggetv->argv[0])));
+ argv = g_malloc0((guint32)(sizeof(*argv) + (count - CAMEL_ARGV_MAX) *
sizeof(argv->argv[0])));
l = props;
i = 0;
while (l) {
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade O(n^m)?
hink of better solutions (more people
> can help in thinking out of the box, the larger the group).
>
> Thanks,
> -Garrett
>
> PS Please reply on the @hackers list, if possible.
>
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "
[EMAIL PROTECTED]"
Honestly I'd be more interested in a package building system. Maybe be a
little bit more liberal in the default building of ports. It doesn't
need to build a package of every port just common ones. That way its
easier to get up and running with things. Things like xorg, gnome and
KDE take ages to build and would be awesome if there was a decent
package fetching system. Something like apt-get where you could add some
kind of repository. and you could just pull down a list of packages and
choose what you want. This can be emulated in a way using portupgrade -P
and changing the pkgtools.conf to have some more mirrors to fetch from a
pointyhat macro is there but probably shouldn't be abused as its there
to look for problems not build us consumers packages it just a side
effect or at least this is how it was explained to me. A neat thing
might be a distributed package building project. Where packages are
picked apart and pieces are built all over the place get enough places
to donate CPU and package building might be a thing of the past, but
those are just pipe dreams right now.
The slowness affects me after a mass upgrade, after that I'm fine. Maybe
someone can look into profiling portupgrade and seeing if its with
portupgrade or the pkg_* tools.
One of FreeBSD's strengths, from my POV, is the power it affords you from
the ports system. One of my biggest beefs w/ Linux has always been the
prebuilt-binary-centric package systems. In addition to performance, this
was one other thing that drove me to The Beastie. With the newer, faster
processors, my personal bottleneck (and I think this is true for many others
in this thread) has moved from the compilation stage of ports into the
meta-data management. It can be disheartening for a geek to see that the
process of "registering package", or updating the "information repository to
get/build packages" seems to take significantly longer than the process of
actually building and installing the software.
I have worked on other projects where "splitting up" the work has been
meritorious. I am looking at the pkgdb/portsdb BDB files on my system right
now, and I see the following:
usr/ports/INDEX-7.db: 36658176 bytes (~35MB)
var/db/pkg/pkgdb.db: 34974720 (~33.3MB)
What if we were to divide up the pkgdb.db and the INDEX-7.db files into
multiple .db files (perhaps one file for each category directory in ports),
and then force the package names to be
"{category}/{packagename}-{versioninfo}" everywhere they are referenced? I
do not know if currently packages record the category name for their
dependencies, but it seems that if they did we could reduce the search space
down to only the ports in the same category as the port in question.
While we're at it, adding some more meta-information to package .tbz files
would be nice. I don't know if any of this is packaged up, but it would be
useful for FreeBSD binary package distributors to have some of the make
environment variables ($CFLAGS, $CC, $CXX, $CPP, etc...) embedded in the
package metadata as well as any defined WITH_* option variables or other
port-knobs. If it can/has be(en) done, then a package system could take
these things into account and perhaps offer the user a screen similar to
"make config" for which toggles to get with the desired port-package.
Let me know how all of this sounds, if I am on the right track or just
blowing smoke. Of course, I have no time, just like everybody else...
--
Coleman Kane
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
