Re: FreeBSD Port: php5-mhash-5.2.11_1
On Wed, Dec 16, 2009 at 7:53 PM, Raphael Becker wrote:
>
> I disabled those:
> #extension=openssl.so
> #extension=pdo_mysql.so
> #extension=ldap.so
> #extension=imap.so
> #extension=mhash.so
> #extension=ftp.so
> #extension=curl.so
> #extension=mysqli.so
>
>
> If i enable any of those php will segfault again!
>
> Looking at the referenced libraries from the ports (usr/local) shows a
> hot candidate:
>
> [r...@freebsd ~]# for SO in $(grep ^[#] /usr/local/etc/php/extensions.ini |
> cut -f 2 -d "="); do ldd /usr/local/lib/php/20060613/$SO; done |
> grep usr/local | awk '{ print $1 " => " $3 ; }' | sort | uniq -c | sort -n
>
> [snip]
> 2 libmysqlclient.so.15 => /usr/local/lib/mysql/libmysqlclient.so.15
> 7 libcrypto.so.5 => /usr/local/lib/libcrypto.so.5
> 7 libssl.so.5 => /usr/local/lib/libssl.so.5
>
> 7 out of 8 disabled extensions depend on libcrypto.so.5 and libssl.so.5
> which come from openssl-0.9.8l
>
You might want to check out this thread:
http://lists.freebsd.org/pipermail/freebsd-ports/2009-December/058256.html
Perhaps your issues are related.
Matt
___
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: ports/ and 10.0-CURRENT
On 09/28/11 15:41, Hartmann, O. wrote: On 09/28/11 22:18, Doug Barton wrote: On 09/28/2011 12:39, Hartmann, O. wrote: The mess started to happen when I tried to "repair" a non CLANG compiling port math/gotoblas with portmaster -vf amth/gotoblas. Since this build binutils and even gettext and libiconv, I guess they got broken. Last I saw was a successful installation report from portmaster. But the libiconv.so.3 wasn't there anymore when I checked! This is a catastrophy ... I'm on FreeBSD 10.0-CURRENT r225844 It's been widely reported on the ports list that you can't do fresh ports compiles on 10-current, and won't be able to until well after 9.0-RELEASE. The primary reason is that auto* stuff doesn't understand the 2-digit release version. Solutions are to set UNAME_r=9.0-CURRENT in your environment, and/or twiddle the version in newvers.sh and rebuild/reinstall your kernel. hth, Doug Yes, it has been discussed. But I was too dumb to realise that the phenomenon I experienced was triggered by this. I'll stay tuned and watch when a solution is at hand. Regards, Oliver I also was apparently too dumb! Making progress with UNAME_r and newvers.sh as we speak. I was unable to compile neon29 properly with UNAME_r alone... buildkernel underway. At least it's never boring! Thanks all Matt ___ 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: New X.Org
On 04/23/12 05:59, Warren Block wrote: > On Mon, 23 Apr 2012, Andrea Venturoli wrote: > >> I have a Radeon card, so, does this mean I will get xorg-server? Any >> way to get 1.10? Any advantage into this? > > A Radeon 4650 is working fine here with xorg-server 1.10.6 and mesa > 7.11. So far there are no Firefox title bar artifacts like there were > occasionally with the earlier version. > >> Also, I have WITHOUT_NOUVEAU in /etc/make.conf. Should I remove it? > > Yes, replace it with WITH_NEW_XORG=yes. Then rebuild graphics/libdrm, > xorg-server, xf86-input-*, xf86-video-*, and... a few other things I > should have taken notes on. > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" Interesting. Another Radeon 4650 (rv730) is not working here, giving Bus Errors at the same address whenever certain applications are launched. Failing examples: Firefox, gedit, qt4-designer Successful: xfce4-terminal, ioquake3, compiz I just completed recompiling all ports dependent on libGL with no luck. I had "WITHOUT_NOUVEAU" in make.conf at the same time as "WITH_NEW_XORG", is that the problem? Does this sound like an Xorg problem or a ports/ld problem? Matt ___ 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: New X.Org
On 04/23/12 07:40, Zhihao Yuan wrote: > On Mon, Apr 23, 2012 at 9:28 AM, matt wrote: >> On 04/23/12 05:59, Warren Block wrote: >>> On Mon, 23 Apr 2012, Andrea Venturoli wrote: >>> >>>> I have a Radeon card, so, does this mean I will get xorg-server? Any >>>> way to get 1.10? Any advantage into this? >>> A Radeon 4650 is working fine here with xorg-server 1.10.6 and mesa >>> 7.11. So far there are no Firefox title bar artifacts like there were >>> occasionally with the earlier version. >>> >>>> Also, I have WITHOUT_NOUVEAU in /etc/make.conf. Should I remove it? >>> Yes, replace it with WITH_NEW_XORG=yes. Then rebuild graphics/libdrm, >>> xorg-server, xf86-input-*, xf86-video-*, and... a few other things I >>> should have taken notes on. >>> ___ >>> freebsd-...@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-x11 >>> To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" >> Interesting. Another Radeon 4650 (rv730) is not working here, giving Bus >> Errors at the same address whenever certain applications are launched. >> Failing examples: Firefox, gedit, qt4-designer >> Successful: xfce4-terminal, ioquake3, compiz >> >> I just completed recompiling all ports dependent on libGL with no luck. >> I had "WITHOUT_NOUVEAU" in make.conf at the same time as >> "WITH_NEW_XORG", is that the problem? > WITHOUT_NOUVEAU has no effect; only WITH_NEW_XORG has. > Any crash log? Xorg.0.log? > >> Does this sound like an Xorg problem or a ports/ld problem? >> >> Matt >> ___ >> 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" > > Partially truncated, but here's the last couple kilobytes of Xorg.0.log. http://pastebin.com/7JHyXYH1 Short version is " [ 36202.557] Bus error: 10 at address 0x803bc24e2 " The address never changes, whenever Xorg crashes since the update. System compiled with base cc (gcc), ports are a mix of gcc & gcc47...I did my recompile with gcc only in case it was a gcc47/libmap.conf issue. Matt ___ 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: New X.Org
On 04/23/12 09:37, Warren Block wrote: > On Mon, 23 Apr 2012, matt wrote: > >> On 04/23/12 05:59, Warren Block wrote: >>> On Mon, 23 Apr 2012, Andrea Venturoli wrote: >>> >>>> I have a Radeon card, so, does this mean I will get xorg-server? Any >>>> way to get 1.10? Any advantage into this? >>> >>> A Radeon 4650 is working fine here with xorg-server 1.10.6 and mesa >>> 7.11. So far there are no Firefox title bar artifacts like there were >>> occasionally with the earlier version. >>> >>>> Also, I have WITHOUT_NOUVEAU in /etc/make.conf. Should I remove it? >>> >>> Yes, replace it with WITH_NEW_XORG=yes. Then rebuild graphics/libdrm, >>> xorg-server, xf86-input-*, xf86-video-*, and... a few other things I >>> should have taken notes on. > >> Interesting. Another Radeon 4650 (rv730) is not working here, giving Bus >> Errors at the same address whenever certain applications are launched. >> Failing examples: Firefox, gedit, qt4-designer >> Successful: xfce4-terminal, ioquake3, compiz >> >> I just completed recompiling all ports dependent on libGL with no luck. >> I had "WITHOUT_NOUVEAU" in make.conf at the same time as >> "WITH_NEW_XORG", is that the problem? >> Does this sound like an Xorg problem or a ports/ld problem? > > I also did 'portmaster driconf', which rebuilt libglut and libGLU. > Run pkg_libchk from sysutils/bsdadminscripts to check for missing > libraries. Definitely rebuilt libglut and driconf, I'm pretty sure I saw libGLU. Haven't run pkg_libchk yet, great idea. I did run pkgdb -F and rebuild a few hundred ports hoping to shotgun fix it. I was experimenting with wine 3d acceleration a week or so ago, it's possible something broken happened as a result of mounting ports dir inside the chroot...or /usr/local/lib32 stuff? I also have AIGLX on in Xorg.conf from that adventure. Problem arose on first startx after the update, however, so it's not clear. Matt ___ 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: New X.Org
On 04/23/12 09:37, Warren Block wrote: > On Mon, 23 Apr 2012, matt wrote: > >> On 04/23/12 05:59, Warren Block wrote: >>> On Mon, 23 Apr 2012, Andrea Venturoli wrote: >>> >>>> I have a Radeon card, so, does this mean I will get xorg-server? Any >>>> way to get 1.10? Any advantage into this? >>> >>> A Radeon 4650 is working fine here with xorg-server 1.10.6 and mesa >>> 7.11. So far there are no Firefox title bar artifacts like there were >>> occasionally with the earlier version. >>> >>>> Also, I have WITHOUT_NOUVEAU in /etc/make.conf. Should I remove it? >>> >>> Yes, replace it with WITH_NEW_XORG=yes. Then rebuild graphics/libdrm, >>> xorg-server, xf86-input-*, xf86-video-*, and... a few other things I >>> should have taken notes on. > >> Interesting. Another Radeon 4650 (rv730) is not working here, giving Bus >> Errors at the same address whenever certain applications are launched. >> Failing examples: Firefox, gedit, qt4-designer >> Successful: xfce4-terminal, ioquake3, compiz >> >> I just completed recompiling all ports dependent on libGL with no luck. >> I had "WITHOUT_NOUVEAU" in make.conf at the same time as >> "WITH_NEW_XORG", is that the problem? >> Does this sound like an Xorg problem or a ports/ld problem? > > I also did 'portmaster driconf', which rebuilt libglut and libGLU. > Run pkg_libchk from sysutils/bsdadminscripts to check for missing > libraries. Unfortunately no good missing libs: # pkg_libchk opera-11.62_1: /usr/local/lib/opera/liboperakde4.so misses libkdecore.so.7 opera-11.62_1: /usr/local/lib/opera/liboperakde4.so misses libkdeui.so.7 opera-11.62_1: /usr/local/lib/opera/liboperakde4.so misses libkio.so.7 I removed all of /usr/local/lib32 beforehand, just in case... I will rebuild glut & GLU and anything else. Is there anyway to get a backtrace on X? Is it as easy as gdb startx? Matt ___ 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: New X.Org
On 04/23/12 09:37, Warren Block wrote: On Mon, 23 Apr 2012, matt wrote: On 04/23/12 05:59, Warren Block wrote: On Mon, 23 Apr 2012, Andrea Venturoli wrote: I have a Radeon card, so, does this mean I will get xorg-server? Any way to get 1.10? Any advantage into this? A Radeon 4650 is working fine here with xorg-server 1.10.6 and mesa 7.11. So far there are no Firefox title bar artifacts like there were occasionally with the earlier version. Also, I have WITHOUT_NOUVEAU in /etc/make.conf. Should I remove it? Yes, replace it with WITH_NEW_XORG=yes. Then rebuild graphics/libdrm, xorg-server, xf86-input-*, xf86-video-*, and... a few other things I should have taken notes on. Interesting. Another Radeon 4650 (rv730) is not working here, giving Bus Errors at the same address whenever certain applications are launched. Failing examples: Firefox, gedit, qt4-designer Successful: xfce4-terminal, ioquake3, compiz I just completed recompiling all ports dependent on libGL with no luck. I had "WITHOUT_NOUVEAU" in make.conf at the same time as "WITH_NEW_XORG", is that the problem? Does this sound like an Xorg problem or a ports/ld problem? I also did 'portmaster driconf', which rebuilt libglut and libGLU. Run pkg_libchk from sysutils/bsdadminscripts to check for missing libraries. I rebuilt most ports, the rest are rebuilding now. The problem can be excluded by not running my normal xinitrc, however I do think this may be either an X or base system bug? Test case for creating this involves starting with my normal xinitrc, desktop appears, then launching Thunar. Closing a window also causes the crash. Here is a complete backtrace...can anyone make any sense of this? Is this related to the libthr.so.3 issues recently on CURRENT? Program received signal SIGBUS, Bus error. 0x000803bc8bb2 in glxGetScreen () from /usr/local/lib/xorg/modules/extensions/libglx.so (gdb) Continuing. Program received signal SIGABRT, Aborted. 0x000803254bbc in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x000803254bbc in thr_kill () from /lib/libc.so.7 #1 0x0008032fee9b in abort () from /lib/libc.so.7 #2 0x0046ceff in OsAbort () #3 0x00479bfc in ddxGiveUp () #4 0x000a in ?? () #5 0x7d25c10fe5bd6725 in ?? () #6 0x00593830 in ?? () #7 0x004694ee in LogSetParameter () #8 0x00469743 in FatalError () #9 0x0046a703 in OsLookupColor () #10 0x01116c00 in ?? () #11 0x7d25c10fe5bd6725 in ?? () #12 0x7fffd3a0 in ?? () #13 0x0100e400 in ?? () #14 0x7fffd780 in ?? () #15 0x000802fdf1be in pthread_sigmask () from /lib/libthr.so.3 #16 0x000802fdf34b in pthread_sigmask () from /lib/libthr.so.3 #17 0x7043 in ?? () #18 0x000802fdf270 in pthread_sigmask () from /lib/libthr.so.3 #19 0x in ?? () #20 0x in ?? () #21 0x in ?? () #22 0x in ?? () ---Type to continue, or q to quit--- #23 0x5a5a5a5a5a5a5a5a in ?? () #24 0x03380100 in ?? () #25 0x0008035454a0 in __des_crypt_LOCAL () from /lib/libc.so.7 #26 0x0001 in ?? () #27 0x in ?? () #28 0x000a8008 in ?? () #29 0x0118 in ?? () #30 0x0001 in ?? () #31 0x0080ccf8 in screenInfo () #32 0x04c00dc0 in ?? () #33 0x04c97000 in ?? () #34 0x03380100 in ?? () #35 0x0080ccc0 in ScreenSaverBlanking () #36 0x0008035454a0 in __des_crypt_LOCAL () from /lib/libc.so.7 #37 0x008026c0 in RegionEmptyBox () #38 0x001b00130009 in ?? () #39 0x in ?? () #40 0x003b003b0001 in ?? () #41 0x in ?? () #42 0x000803bc8bb2 in glxGetScreen () from /usr/local/lib/xorg/modules/extensions/libglx.so #43 0x0043 in ?? () #44 0x00013202 in ?? () ---Type to continue, or q to quit--- #45 0x7fffd850 in ?? () #46 0x003b in ?? () #47 0x0320 in ?? () #48 0x00010002 in ?? () #49 0x00020002 in ?? () #50 0x037f in ?? () #51 0x in ?? () #52 0x in ?? () #53 0x00021fa0 in ?? () #54 0x68741582 in ?? () #55 0x in ?? () #56 0x in ?? () #57 0x in ?? () #58 0x in ?? () #59 0x in ?? () #60 0x in ?? () #61 0x in ?? () #62 0x in ?? () #63 0x in ?? () #64 0x191b in ?? () #65 0x in ?? () #66 0x in ?? () #67 0x in ?? () ---Type to continue, or q to quit--- #68 0x in ?? () #69 0x in ?? () #70 0x47012f00 in ?? () #71 0x in ?? () #72 0x4b7f in ?? () #73 0x in ?? () #74 0x44d3 in ?? () #75 0x in ?? () #76 0
Re: New X.Org
On 04/24/12 23:38, matt wrote: > On 04/23/12 09:37, Warren Block wrote: >> On Mon, 23 Apr 2012, matt wrote: >> >>> On 04/23/12 05:59, Warren Block wrote: >>>> On Mon, 23 Apr 2012, Andrea Venturoli wrote: >>>> >>>>> I have a Radeon card, so, does this mean I will get xorg-server? Any >>>>> way to get 1.10? Any advantage into this? >>>> >>>> A Radeon 4650 is working fine here with xorg-server 1.10.6 and mesa >>>> 7.11. So far there are no Firefox title bar artifacts like there were >>>> occasionally with the earlier version. >>>> >>>>> Also, I have WITHOUT_NOUVEAU in /etc/make.conf. Should I remove it? >>>> >>>> Yes, replace it with WITH_NEW_XORG=yes. Then rebuild graphics/libdrm, >>>> xorg-server, xf86-input-*, xf86-video-*, and... a few other things I >>>> should have taken notes on. >> >>> Interesting. Another Radeon 4650 (rv730) is not working here, giving >>> Bus >>> Errors at the same address whenever certain applications are launched. >>> Failing examples: Firefox, gedit, qt4-designer >>> Successful: xfce4-terminal, ioquake3, compiz >>> >>> I just completed recompiling all ports dependent on libGL with no luck. >>> I had "WITHOUT_NOUVEAU" in make.conf at the same time as >>> "WITH_NEW_XORG", is that the problem? >>> Does this sound like an Xorg problem or a ports/ld problem? >> >> I also did 'portmaster driconf', which rebuilt libglut and libGLU. >> Run pkg_libchk from sysutils/bsdadminscripts to check for missing >> libraries. >> > I rebuilt most ports, the rest are rebuilding now. > The problem can be excluded by not running my normal xinitrc, however > I do think this may be either an X or base system bug? > Test case for creating this involves starting with my normal xinitrc, > desktop appears, then launching Thunar. Closing a window also causes > the crash. > > Here is a complete backtrace...can anyone make any sense of this? Is > this related to the libthr.so.3 issues recently on CURRENT? > > > Program received signal SIGBUS, Bus error. > 0x000803bc8bb2 in glxGetScreen () >from /usr/local/lib/xorg/modules/extensions/libglx.so > (gdb) > Continuing. > > Program received signal SIGABRT, Aborted. > 0x000803254bbc in thr_kill () from /lib/libc.so.7 > (gdb) bt > #0 0x000803254bbc in thr_kill () from /lib/libc.so.7 > #1 0x0008032fee9b in abort () from /lib/libc.so.7 > #2 0x0046ceff in OsAbort () > #3 0x00479bfc in ddxGiveUp () > #4 0x000a in ?? () > #5 0x7d25c10fe5bd6725 in ?? () > #6 0x00593830 in ?? () > #7 0x004694ee in LogSetParameter () > #8 0x00469743 in FatalError () > #9 0x0046a703 in OsLookupColor () > #10 0x01116c00 in ?? () > #11 0x7d25c10fe5bd6725 in ?? () > #12 0x7fffd3a0 in ?? () > #13 0x0100e400 in ?? () > #14 0x7fffd780 in ?? () > #15 0x000802fdf1be in pthread_sigmask () from /lib/libthr.so.3 > #16 0x000802fdf34b in pthread_sigmask () from /lib/libthr.so.3 > #17 0x7043 in ?? () > #18 0x000802fdf270 in pthread_sigmask () from /lib/libthr.so.3 > #19 0x in ?? () > #20 0x in ?? () > #21 0x in ?? () > #22 0x in ?? () > ---Type to continue, or q to quit--- > #23 0x5a5a5a5a5a5a5a5a in ?? () > #24 0x03380100 in ?? () > #25 0x0008035454a0 in __des_crypt_LOCAL () from /lib/libc.so.7 > #26 0x0001 in ?? () > #27 0x in ?? () > #28 0x000a8008 in ?? () > #29 0x0118 in ?? () > #30 0x0001 in ?? () > #31 0x0080ccf8 in screenInfo () > #32 0x04c00dc0 in ?? () > #33 0x04c97000 in ?? () > #34 0x03380100 in ?? () > #35 0x0080ccc0 in ScreenSaverBlanking () > #36 0x0008035454a0 in __des_crypt_LOCAL () from /lib/libc.so.7 > #37 0x008026c0 in RegionEmptyBox () > #38 0x001b00130009 in ?? () > #39 0x in ?? () > #40 0x003b003b0001 in ?? () > #41 0x in ?? () > #42 0x000803bc8bb2 in glxGetScreen () >from /usr/local/lib/xorg/modules/extensions/libglx.so > #43 0x0043 in ?? () > #44 0x00013202 in ?? () > ---Type to continue, or q to quit--- > #45 0x7fffd850 in ?? () > #46 0x003b in ?? () > #47 0x0320 in ?? () > #48 0x00010002 in ?? () > #49 0x00020002 in ?? () > #50 0x037f in ?? () > #51
Re: New X.Org
On 04/27/12 10:03, Andriy Gapon wrote:
on 26/04/2012 18:45 Warren Block said the following:
On Thu, 26 Apr 2012, matt wrote:
Interesting. Another Radeon 4650 (rv730) is not working here, giving Bus
Errors at the same address whenever certain applications are launched.
Failing examples: Firefox, gedit, qt4-designer Successful: xfce4-terminal,
ioquake3, compiz
Fixed this issue using the changes indicated in the below patch, which
solved my issue with x bus errors. It looks like glxGetScreen was
choking. This may help users with similar problems in compiz or Kwin.
FYI I manually applied changes in the patch to x11-servers/xorg-server,
not sure if the patch below would apply cleanly.
diff --git a/glx/glxdri.c b/glx/glxdri.c
index 326f539..f6ef784 100644
--- a/glx/glxdri.c
+++ b/glx/glxdri.c
@@ -230,7 +230,7 @@ __glXDRIdrawableDestroy(__GLXdrawable *drawable)
/* If the X window was destroyed, the dri DestroyWindow hook will
* aready have taken care of this, so only call if pDraw isn't NULL. */
-if (drawable->pDraw != NULL) {
+if (drawable->pDraw != NULL&& drawable->pDraw->type == DRAWABLE_WINDOW) {
screen = (__GLXDRIscreen *) glxGetScreen(drawable->pDraw->pScreen);
(*screen->core->destroyDrawable)(private->driDrawable);
Good catch! Please enter a PR for this!
Just double-check that this change doesn't introduce any memory/resource leaks
:-)
Verifying this may be beyond my xorg-fu...what's the best way to examine
this?
Matt
___
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"
Netatalk 2.2.2 disconnection
Hi there, I was fighting the same issue all day as well; the only solution I had found was to downgrade netatalk back to 2.2.1. A new version of the port, netatalk-2.2.2_1,1 , was pushed out just a little while ago and this appears to fix this issue (or at least for me). The new version disables sendfile() by default and makes it optional because apparently it causes issues with ZFS (which does apply in my case). Anyway, I switched to 2.2.2_1,1, making sure that sendfile support was disabled, and now everything works great once again. Cheers, Matt___ 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: TrueCrypt 5.0 - Built, short test result: Ok.
On Feb 10, 2008 2:27 PM, Michael Ross <[EMAIL PROTECTED]> wrote: > Am 10.02.2008, 20:05 Uhr, schrieb Sergey Matveychuk <[EMAIL PROTECTED]>: > > > You should patch the file to include ucontext.h > > But even if it'll be build, nobody guarantee it works. > > Done. Builds. On 7.0-PRERELEASE, by the way. Builds fine on 7.0-RC2 too. [snip] > > Maybe someone would download > http://www.triplefork.net/test.tc (64K) > and try with password "test" on a different platform. > I've noticed what looks like a problem when creating a file-based volume (could be for all volume types - I haven't tried creating a device volume). If I select password AND keyfile during the volume creation, the creation process finishes without throwing any errors, but the volume that is created does not require the keyfile to open/mount. In fact, it fails to open/mount if I try to use the keyfile and password use during creation, but works fine if I just use the password. Anyone else seeing this behavior? I will attempt to reproduce on the Linux-build of this version as well to check and see if it has the same problem. > Michael ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Port: KeePassX-0.2.2_2
Hello. It looks like the KeePassX folks have recently updated to the 0.3.x branch. I've looked at trying to build a local port from the updated version but it fails with multiple build errors (I'm running 7.0-RELEASE and all qt4 ports are at version 4.3.4). Can someone take a look and see if there are obvious changes needed to make it compile? Thanks, Matt ___ 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: KeePassX-0.2.2_2
On Tue, Mar 18, 2008 at 11:26 AM, Steven Kreuzer <[EMAIL PROTECTED]> wrote: > > On Tue, Mar 18, 2008 at 10:53:24AM -0500, Matt wrote: > > Hello. > > > > It looks like the KeePassX folks have recently updated to the 0.3.x > > branch. I've looked at trying to build a local port from the updated > > version but it fails with multiple build errors (I'm running > > 7.0-RELEASE and all qt4 ports are at version 4.3.4). Can someone take > > a look and see if there are obvious changes needed to make it compile? > > > > Thanks, > > Matt > > ___ > > freebsd-ports@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > Cut and paste the errors you are getting. It might be something fairly > trivial, > or it might be related to a specific setting on your machine. > -- > Steven Kreuzer > http://www.exit2shell.com/~skreuzer > The first build error is: # make ===> Building for KeePassX-0.3.1 cd src/ && make -f Makefile all c++ -c -pipe -O2 -fno-strict-aliasing -pipe -w -DAUTOTYPE -DGLOBAL_AUTOTYPE -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I/usr/local/include/QtCore -I/usr/local/include/QtCore -I/usr/local/include/QtGui -I/usr/local/include/QtGui -I/usr/local/include/QtXml -I/usr/local/include/QtXml -I/usr/local/include -I/usr/local/include -I. -Ilib -Icrypto -Iplugins/interfaces -Iexport -Iimport -Idialogs -I../build/ui -I../build/moc -I/usr/local/include -o ../build/HelperX11.o lib/HelperX11.cpp In file included from lib/HelperX11.h:23, from lib/HelperX11.cpp:21: lib/AutoType.h:27: error: 'quint32' does not name a type lib/AutoType.h:37: error: 'IEntryHandle' has not been declared lib/AutoType.h:37: error: 'QString' has not been declared In file included from /usr/local/include/QtGui/qx11info_x11.h:47, from /usr/local/include/QtGui/QX11Info:1, from lib/HelperX11.cpp:22: /usr/local/include/QtCore/qnamespace.h:1035: error: expected identifier before numeric constant /usr/local/include/QtCore/qnamespace.h:1035: error: expected unqualified-id before numeric constant *** Error code 1 Stop in /usr/ports/security/keepassx/work/KeePassX-0.3.1/src. *** Error code 1 Stop in /usr/ports/security/keepassx/work/KeePassX-0.3.1. *** Error code 1 Stop in /usr/ports/security/keepassx. This one is apparently being caused by conflicting definitions of "CursorShape" in the files /usr/local/include/X11/X.h and /usr/local/include/QtCore/qnamespace.h - with the definition in qnamespace.h being the one that is required. Hacking around this with a sloppy "#undef CursorShape" "work/KeePassX-0.3.1/src/lib/HelperX11.h" still yields the error: # make ===> Building for KeePassX-0.3.1 cd src/ && make -f Makefile all c++ -c -pipe -O2 -fno-strict-aliasing -pipe -w -DAUTOTYPE -DGLOBAL_AUTOTYPE -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I/usr/local/include/QtCore -I/usr/local/include/QtCore -I/usr/local/include/QtGui -I/usr/local/include/QtGui -I/usr/local/include/QtXml -I/usr/local/include/QtXml -I/usr/local/include -I/usr/local/include -I. -Ilib -Icrypto -Iplugins/interfaces -Iexport -Iimport -Idialogs -I../build/ui -I../build/moc -I/usr/local/include -o ../build/HelperX11.o lib/HelperX11.cpp In file included from lib/HelperX11.h:23, from lib/HelperX11.cpp:21: lib/AutoType.h:27: error: 'quint32' does not name a type lib/AutoType.h:37: error: 'IEntryHandle' has not been declared lib/AutoType.h:37: error: 'QString' has not been declared *** Error code 1 Stop in /usr/ports/security/keepassx/work/KeePassX-0.3.1/src. *** Error code 1 Stop in /usr/ports/security/keepassx/work/KeePassX-0.3.1. *** Error code 1 Stop in /usr/ports/security/keepassx. Adding an include for "qglobal.h" in "work/KeePassX-0.3.1/src/lib/AutoType.h" handles two more of the errors but I am still left with: # make ===> Building for KeePassX-0.3.1 cd src/ && make -f Makefile all c++ -c -pipe -O2 -fno-strict-aliasing -pipe -w -DAUTOTYPE -DGLOBAL_AUTOTYPE -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I/usr/local/include/QtCore -I/usr/local/include/QtCore -I/usr/local/include/QtGui -I/usr/local/include/QtGui -I/usr/local/include/QtXml -I/usr/local/include/QtXml -I/usr/local/include -I/usr/local/include -I. -Ilib -Icrypto -Iplugins/interfaces -Iexport -Iimport -Idialogs -I../build/ui -I../build/moc -I/usr/local/include -o ../build/HelperX11.o lib/HelperX11.cpp In file included from lib/HelperX11.h:23,
Re: FreeBSD Port: KeePassX-0.2.2_2
On Tue, Mar 18, 2008 at 12:18 PM, Matt <[EMAIL PROTECTED]> wrote: > > On Tue, Mar 18, 2008 at 11:26 AM, Steven Kreuzer > <[EMAIL PROTECTED]> wrote: > > > > On Tue, Mar 18, 2008 at 10:53:24AM -0500, Matt wrote: > > > Hello. > > > > > > It looks like the KeePassX folks have recently updated to the 0.3.x > > > branch. I've looked at trying to build a local port from the updated > > > version but it fails with multiple build errors (I'm running > > > 7.0-RELEASE and all qt4 ports are at version 4.3.4). Can someone take > > > a look and see if there are obvious changes needed to make it compile? > > > > > > Thanks, > > > Matt > > > ___ > > > freebsd-ports@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > > Cut and paste the errors you are getting. It might be something fairly > trivial, > > or it might be related to a specific setting on your machine. > > -- > > Steven Kreuzer > > http://www.exit2shell.com/~skreuzer > > > > The first build error is: > I hate to reply to myself on this one, but I've managed to get the new version to compile and wanted to give an update and see if there is any feedback available from others as to the root cause of the problem. The errors were being caused (apparently) by a missing element in the Makefile under the "src" directory. Under the "### Compile" section, almost all of the files (everything except the ones in the crypto sub-dir) needed an "-include ../build/keepassx" added after the "-c". As this Makefile was generated by qmake, could there be something in the qmake configuration that caused the omission? > Thank you for the help, > Matt > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: port: truecrypt 5.1a, need some testers
On Thu, May 1, 2008 at 4:56 PM, Stephan Fiebrandt <[EMAIL PROTECTED]> wrote: > This updated port should build the latest truecrypt 5.1a on freebsd. It > depends on wxgtk28 with unicode. The NOGUI version dpes also require wx base > libraries. So wxgtk28-unicode is marked as dependency. > > I have done some load test on today's 7-STABLE amd64, however it needs more > testing also under i386 as my machine is heavy patched and my i386 is > 8-CURRENT right now (there it works too). > Don't forget to start fuse before running truecrypt. > Port can be found at: http://nsx.de/truecrypt-5.1a.tar.gz > Port builds cleanly on 7-RELEASE i386 and runs as expected. Seems there are still some stability issues that I remember hearing about before. Copying many small files to a truecrypt-mounted volume appears to deadlock the system (I seem to remember this used to cause a panic...) that I can't break out of by any apparent means. I don't think that's a problem with the port though. Matt > Stephan > > ___ > 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]"
FreeBSD Port: fusefs-libs-2.7.2_1 - gvfs-fuse-daemon process(es) stuck
Hello. I am seeing gvfs-fuse-daemon processes remain stuck in memory after logging out of the system, and it appears that it may have something to do with the fuse libraries. I asked about this on the FreeBSD GNOME mailing list and it was suggested that I get the information to the fusefs-libs maintainer for review. The symptom is as described above - the gvfs-fuse-daemon processes do not exit cleanly and more processes continue to build-up whenever I complete an X-session. The processes do exit when I send them a manual kill signal. The only info I have at this point is a backtrace from a "stuck" process. Hopefully it will be useful in identifying the issue. Thanks, Matt GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Attaching to program: /usr/local/libexec/gvfs-fuse-daemon, process 9655 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/libgvfscommon.so.0...done. Loaded symbols for /usr/local/lib/libgvfscommon.so.0 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libgio-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgio-2.0.so.0 Reading symbols from /usr/local/lib/libgobject-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgobject-2.0.so.0 Reading symbols from /usr/local/lib/libgmodule-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgmodule-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/libintl.so.8...done. Loaded symbols for /usr/local/lib/libintl.so.8 Reading symbols from /usr/local/lib/libpcre.so.0...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /usr/local/lib/libdbus-1.so.3...done. Loaded symbols for /usr/local/lib/libdbus-1.so.3 Reading symbols from /usr/local/lib/libfuse.so.2...done. Loaded symbols for /usr/local/lib/libfuse.so.2 Reading symbols from /lib/libutil.so.7...done. Loaded symbols for /lib/libutil.so.7 Reading symbols from /lib/libthr.so.3...done. [New Thread 0x10502000 (LWP 100172)] [New Thread 0x10501100 (LWP 100064)] Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 [Switching to Thread 0x10502000 (LWP 100172)] 0x1045d3d1 in read () from /lib/libc.so.7 (gdb) bt #0 0x1045d3d1 in read () from /lib/libc.so.7 #1 0x10379792 in read () from /lib/libthr.so.3 #2 0x1035a67b in fuse_kern_chan_receive (chp=0xbf9fef8c, buf=0x1055c000 "", size=135168) at fuse_kern_chan.c:28 #3 0x1035fb13 in fuse_chan_recv (chp=0xbf9fef8c, buf=0x1055c000 "", size=135168) at fuse_session.c:184 #4 0x1035aac6 in fuse_do_work (data=0x10517580) at fuse_loop_mt.c:70 #5 0x1037ab1f in pthread_getprio () from /lib/libthr.so.3 #6 0x in ?? () (gdb) ___ 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: fusefs-libs-2.7.2_1 - gvfs-fuse-daemon process(es) stuck
On Tue, May 6, 2008 at 12:32 AM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > On Tue, May 06, 2008 at 12:20:17AM -0500, Matt wrote: > > The symptom is as described above - the gvfs-fuse-daemon processes do > > not exit cleanly and more processes continue to build-up whenever I > > complete an X-session. The processes do exit when I send them a > > manual kill signal. The only info I have at this point is a backtrace > > from a "stuck" process. Hopefully it will be useful in identifying > > the issue. > > What makes it "stuck?" What state is the process in? ps or top output > would've been helpful, ditto with truss or ktrace output. Is it eating > 100% CPU (e.g. read() is continually being called without handling error > conditions), or does it just sit there idling? > Sorry - should have been more specific than the generic "stuck" description. Top shows the process state as "fu_msg" and it is not consuming any processor resources, just seemingly sits there idling. Output from ps is: UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 1000 4019 1 0 44 0 6324 2528 - Ts??0:00.00 /usr/local/libexec//gvfs-fuse-daemon /home/mtosto Attaching the process with truss when it enters this state (which happens after I end an X-session) yields no data. Are there any truss command line switches that I should try? I've tried -f, -a and -e. Attaching the process with ktrace yields very minimal data. The only time I can get the process to show something in the trace is when I attach it with gdb while the trace is running. When I do that, kdump shows this: [EMAIL PROTECTED] ~]$ kdump 4019 gvfs-fuse-daemon CALL read(0x3,0x1055c000,0x21000) 4019 gvfs-fuse-daemon RET read RESTART 4019 gvfs-fuse-daemon CALL read(0x3,0x1055c000,0x21000) 4019 gvfs-fuse-daemon RET read RESTART 4019 gvfs-fuse-daemon CALL read(0x3,0x1055c000,0x21000) 4019 gvfs-fuse-daemon RET read RESTART [EMAIL PROTECTED] ~]$ Each pair of CALL and RET lines represents one attaching of the process via gdb and executing the bt command within gdb. The system is a dual-core Opteron running 7.0-RELEASE i386 with the ULE scheduler. There does not appear to be any detrimental side effects to the system with the gvfs-fuse-daemon processes hanging around. They just keep stacking up (one for each X-session, so usually one per day) until I manually kill them off. > > > > (gdb) bt > > #0 0x1045d3d1 in read () from /lib/libc.so.7 > > #1 0x10379792 in read () from /lib/libthr.so.3 > > #2 0x1035a67b in fuse_kern_chan_receive (chp=0xbf9fef8c, > > buf=0x1055c000 "", size=135168) at fuse_kern_chan.c:28 > > #3 0x1035fb13 in fuse_chan_recv (chp=0xbf9fef8c, buf=0x1055c000 "", > > size=135168) at fuse_session.c:184 > > #4 0x1035aac6 in fuse_do_work (data=0x10517580) at fuse_loop_mt.c:70 > > #5 0x1037ab1f in pthread_getprio () from /lib/libthr.so.3 > > #6 0x in ?? () > ___ 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: fusefs-libs-2.7.2_1 - gvfs-fuse-daemon process(es) stuck
On Wed, May 7, 2008 at 9:48 AM, Robert Noland <[EMAIL PROTECTED]> wrote: > On Wed, 2008-05-07 at 07:30 -0700, Jeremy Chadwick wrote: > > On Wed, May 07, 2008 at 09:19:24AM -0500, Matt wrote: > > > Sorry - should have been more specific than the generic "stuck" > > > description. Top shows the process state as "fu_msg" and it is not > > > consuming any processor resources, just seemingly sits there idling. > > > Output from ps is: > > > > > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME > COMMAND > > > 1000 4019 1 0 44 0 6324 2528 - Ts??0:00.00 > > > /usr/local/libexec//gvfs-fuse-daemon /home/mtosto > > > > The "T" flag under State says that the process is stopped. It's as if > > the process was running in the foreground, and was ^Z'd -- same > > behaviour. > > I don't want to state the obvious, but attaching to the process with gdb > will produce the stopped state. Was this ps snap taken before or after > attaching with gdb? > My fault - bad order of info gathering. Here's a ps snap after sending the process -CONT signal: [EMAIL PROTECTED] ~]$ ps -axlH | grep vfs 1000 4019 1 0 46 0 6324 2412 uwait Ts??0:00.00 /usr/local/libexec//gvfs-fuse-daemon /home/mtosto/.gvfs 1000 4019 1 0 44 0 6324 2412 - Ts??0:00.00 /usr/local/libexec//gvfs-fuse-daemon /home/mtosto/.gvfs > robert. > > > > > The part which confuses me (I'm sure others can explain this part) is > > that the parent PID is 1, which is init. This would indicate that the > > process is actually a zombie whose parent has been killed off, and the > > child's parent has been assigned to init. > > > > You might try doing a "kill -CONT" on the process to see what happens. > > > > I don't think truss or ktrace are going to help here, because something > > is explicitly stopping the process (SIGSTOP or some other means). > > > > ___ 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: fusefs-libs-2.7.2_1 - gvfs-fuse-daemon process(es) stuck
On Wed, May 7, 2008 at 9:53 AM, Matt <[EMAIL PROTECTED]> wrote: > On Wed, May 7, 2008 at 9:48 AM, Robert Noland <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-05-07 at 07:30 -0700, Jeremy Chadwick wrote: > > > On Wed, May 07, 2008 at 09:19:24AM -0500, Matt wrote: > > > > Sorry - should have been more specific than the generic "stuck" > > > > description. Top shows the process state as "fu_msg" and it is not > > > > consuming any processor resources, just seemingly sits there idling. > > > > Output from ps is: > > > > > > > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME > COMMAND > > > > 1000 4019 1 0 44 0 6324 2528 - Ts??0:00.00 > > > > /usr/local/libexec//gvfs-fuse-daemon /home/mtosto > > > > > > The "T" flag under State says that the process is stopped. It's as if > > > the process was running in the foreground, and was ^Z'd -- same > > > behaviour. > > > > I don't want to state the obvious, but attaching to the process with gdb > > will produce the stopped state. Was this ps snap taken before or after > > attaching with gdb? > > > My fault - bad order of info gathering. Here's a ps snap after > sending the process -CONT signal: > > [EMAIL PROTECTED] ~]$ ps -axlH | grep vfs > 1000 4019 1 0 46 0 6324 2412 uwait Ts??0:00.00 > /usr/local/libexec//gvfs-fuse-daemon /home/mtosto/.gvfs > 1000 4019 1 0 44 0 6324 2412 - Ts??0:00.00 > /usr/local/libexec//gvfs-fuse-daemon /home/mtosto/.gvfs > Darn it - bad paste. Trying again: [EMAIL PROTECTED] ~]$ ps -axlH | grep vfs 1000 4019 1 0 46 0 6324 2412 uwait Is??0:00.00 /usr/local/libexec//gvfs-fuse-daemon /home/mtosto/.gvfs 1000 4019 1 0 44 0 6324 2412 fu_msg Is??0:00.00 /usr/local/libexec//gvfs-fuse-daemon /home/mtosto/.gvfs > > > > robert. > > > > > > > > > The part which confuses me (I'm sure others can explain this part) is > > > that the parent PID is 1, which is init. This would indicate that the > > > process is actually a zombie whose parent has been killed off, and the > > > child's parent has been assigned to init. > > > > > > You might try doing a "kill -CONT" on the process to see what happens. > > > > > > I don't think truss or ktrace are going to help here, because something > > > is explicitly stopping the process (SIGSTOP or some other means). > > > > > > > > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Clang as default compiler November 4th
On 09/10/12 14:22, Daniel Eischen wrote:
On Mon, 10 Sep 2012, Brooks Davis wrote:
[Please confine your replies to toolch...@freebsd.org to keep the thread
on the most relevant list.]
For the past several years we've been working towards migrating from
GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD
10.0 with Clang as the default compiler on i386 and amd64 platforms. To
this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64
platforms on November 4th.
What does the mean to you?
* When you build world after the default is changed /usr/bin/cc, cpp,
and
c++ will be links to clang.
* This means the initial phase of buildworld and "old style" kernel
compilation will use clang instead of gcc. This is known to work.
* It also means that ports will build with clang by default. A major
of ports work, but a significant number are broken or blocked by
broken ports. For more information see:
http://wiki.freebsd.org/PortsAndClang
What issues remain?
* The gcc->clang transition currently requires setting CC, CXX, and CPP
in addition to WITH_CLANG_IS_CC. I will post a patch to toolchain@
to address this shortly.
I assume this will be done, tested and committed before 2012-11-04
(or whenever the switchover date is).
* Ports compiler selection infrastructure is still under development.
This should be a prerequisite before making the switch, given
that ports will be broken without a work-around for building
them with gcc.
I've been using a somewhat dirty method of doing this by checking the
presence of a file in the port's main directory, e.g. if "basegcc" is
present, build with that, if "clang" is present use it, otherwise
default to gcc47. Obviously that configuration is system specific, but
the fundamental idea is look for a file in the ports directory that
dictates the compiler. Perhaps even add a make ccconfig. It works quite
nicely because you can resume a portmaster spree without having to
suspend and change CC manually, or build all clang ports first etc.
Further csup doesn't touch files it doesn't no about, so updating the
tree (without wiping it out) preserves the fact you'd prefer or need to
build a given port with something else.
There are definitely some ports that have been ignoring libmap.conf,
which tends to require me to build some of their dependencies with base
gcc, but otherwise I've been running this system for a few months and it
works quite well...portmaster can upgrade without user intervention, and
it's quite easy to add cflags logic.
Granted this works for me and is probably not the ideal solution...also
hacked on it to post, so probably typos :)
Something like this in make.conf (with fstack-protector-all for all
ports which works great)
.if !empty(.CURDIR:M/usr/ports/*)
CFLAGS+= -fstack-protector-all
.endif
.if empty(.CURDIR:M/usr/ports/*) && exists(/usr/local/bin/gcc47) &&
!exists(basegcc) && !exists(clang)
# this was occasionally necessary
#LDFLAGS+=-lintl
# custom cflags if desired
#CFLAGS+=-custom cflags for gcc47
#custom cputype if desired
CPUTYPE=amdfam10
CC=gcc47
CPP=cpp47
CXX=g++47
.endif
.if empty(.CURDIR:M/usr/ports/*) && exists(/usr/bin/clang) && exists(clang)
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang-cpp
.endif
NO_WERROR=
WERROR=
.endif
Usage is as simple as "touch basegcc" in the port dir or "touch clang"
etc. to select appropriate compiler
Matt
___
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: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of "USE_GCC=any" to a port's Makefile, and then committed that change to various ports. In most (but not all!) cases this will tell the port "build with gcc instead of clang" (*) . Why not USE_GCC ?= any for the poor guys like me who build (some) ports with USE_GCC=4.6 ? For those users with CC installed as gcc (including -stable), this patch should have no effect. Variations of combinations have been heavily tested on pointyhat-west. If there are any regressions, please contact me. Does this override setting CC explicitly in make.conf? Sorry if it's a dumb question, not sure exactly the hierarchy of USE_GCC vs CC in the make system. Matt ___ 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: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
On 10/12/12 00:54, Claude Buisson wrote:
On 10/12/2012 05:00, matt wrote:
I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of
"USE_GCC=any" to a port's Makefile, and then committed that change to
various ports. In most (but not all!) cases this will tell the port
"build with gcc instead of clang" (*) .
Why not USE_GCC ?= any for the poor guys like me who build (some)
ports with
USE_GCC=4.6 ?
For those users with CC installed as gcc (including -stable), this
patch should have no effect. Variations of combinations have been
heavily tested on pointyhat-west. If there are any regressions,
please
contact me.
Does this override setting CC explicitly in make.conf?
Sorry if it's a dumb question, not sure exactly the hierarchy of USE_GCC
vs CC in the make system.
Dumb as I am, I also wonder when I see that in multimedia/x264:
...
USE_GCC=any
...
.if ${PORT_OPTIONS:MGCC44}
USE_GCC?=4.4+
.endif
...
which seems to deny the intent of the GCC44 option
Sorry but I can not make the test at this present time
Matt
Claude Buisson
I tested, and can confirm two things. CC is overpowered by USE_GCC=any,
which means that I end up with no sse4a and limited support for my arch
(Opteron 4xxx) because I can't set a better -march/cputype than
opteron-sse3. As far as I know base gcc doesn't even support sse4a. This
is really perhaps an issue with me setting CC in make.conf moreso than
ports, however this was the approved method of using clang by default as
well as the approved method of using ports gcc in the ports system. Is
there a new approved method?
M. Buisson's test case also fails, with base gcc being used even though
the gcc44 option is chosen. This may not break as many ports as it
might, but it will certainly create low performing editions of many
multimedia ports given the CPU features supported by either later clang
or gcc. Some will probably break?
If I missed something, please let me know, or if my testing is somehow
compromised. I removed make.conf (as mine is customized) for Claude's
test case, but it's possible something else may have affected my test
results. USE_GCC=any was manually added to the ports makefiles (test
case was editors/nano and multimedia/x264).
Matt
___
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: FreeBSD Port: fusefs-libs-2.7.2_1 - gvfs-fuse-daemon process(es) stuck
On Wed, May 7, 2008 at 10:33 AM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > On Wed, May 07, 2008 at 10:22:09AM -0500, Matt wrote: > > On Wed, May 7, 2008 at 9:53 AM, Matt <[EMAIL PROTECTED]> wrote: > > > On Wed, May 7, 2008 at 9:48 AM, Robert Noland <[EMAIL PROTECTED]> wrote: > > > > On Wed, 2008-05-07 at 07:30 -0700, Jeremy Chadwick wrote: > > > > > On Wed, May 07, 2008 at 09:19:24AM -0500, Matt wrote: > > > > > > Sorry - should have been more specific than the generic "stuck" > > > > > > description. Top shows the process state as "fu_msg" and it is > not > > > > > > consuming any processor resources, just seemingly sits there > idling. > > > > > > Output from ps is: > > > > > > > > > > > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT > TIME COMMAND > > > > > > 1000 4019 1 0 44 0 6324 2528 - Ts?? > 0:00.00 > > > > > > /usr/local/libexec//gvfs-fuse-daemon /home/mtosto > > > > > > > > > > The "T" flag under State says that the process is stopped. It's > as if > > > > > the process was running in the foreground, and was ^Z'd -- same > > > > > behaviour. > As a (very) late follow-up to this issue, looks like the latest Gnome ports have eliminated this issue. I haven't seen it for the last few weeks after doing a full portupgrade on Gnome. Thanks, Matt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [kde-freebsd] [CFT] KDE 4.2 BETA 2 testers wanted
On Fri, Jan 9, 2009 at 5:33 AM, Phil Oleson wrote: > I did run into a linking issue with the build of...errr kdebase, > kdebase-runtime, or kdebase-workspace.. I cant remember now.. but the > issue was with hspell. I had to rebuild it with this patch: > > --- Makefile.orig 2009-01-04 05:20:09.0 + > +++ Makefile2009-01-04 05:20:01.0 + > @@ -16,6 +16,7 @@ > USE_PERL5_BUILD= yes > USE_GMAKE= yes > GNU_CONFIGURE= yes > +CFLAGS+= -fPIC > > MAN1= hspell.1 > MAN3= hspell.3 > The problem appears to be manifested in kdelibs4, but only on amd64 and not i386. I received the same linker error in my amd64 tinderbox, but not in my i386 tinderbox. The specific error states: /opt/c++ -fPIC -pipe -g -Woverloaded-virtual -fvisibility=hidden -fvisibility-inlines-hidden -g -O2 -fno-reorder-blocks -fno-schedule-insns -fno-inline -rpath=/usr/lib:/usr/local/lib -lc -shared -Wl,-soname,kspell_hspell.so -o ../../../lib/kspell_hspell.so CMakeFiles/kspell_hspell.dir/kspell_hspell_automoc.o CMakeFiles/kspell_hspell.dir/kspell_hspellclient.o CMakeFiles/kspell_hspell.dir/kspell_hspelldict.o -L/usr/local/lib/qt4 -L/work/a/ports/x11/kdelibs4/work/kdelibs-4.1.85/build/lib -L/usr/local/lib /usr/local/lib/qt4/libQtCore.so -lpthread ../../../lib/libkdecore.so.7.0.0 /usr/local/lib/libhspell.a -lz /usr/local/lib/qt4/libQtDBus.so /usr/local/lib/qt4/libQtCore.so -lpthread -Wl,-rpath,/usr/local/lib/qt4:/work/a/ports/x11/kdelibs4/work/kdelibs-4.1.85/build/lib /usr/bin/ld: /usr/local/lib/libhspell.a(gimatria.o): relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libhspell.a: could not read symbols: Bad value Does this help determine if there is a possible fix on the kdelibs end or is it something that has to be changed in hspell? Matt ___ 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: kipi-plugins-kde4 and digikam-kde4 picks up qt3 headers from qt-copy-3.3.8_9
On Wed, Feb 18, 2009 at 2:22 PM, Goran Lowkrantz wrote:
> --On Wednesday, February 18, 2009 2:13 PM -0600 Matt
> wrote:
>
>> On Wed, Feb 18, 2009 at 12:58 PM, Goran Lowkrantz
>> wrote:
>>>
>>> Trying to build the KDE4 versions of these ports fails as the build pick
>>> up old headers from qt3 through qt-copy-3.3.8_9.
>>>
>>>
>>> [ 0%] Building CXX object
>>> common/libkipiplugins/CMakeFiles/kipiplugins.dir/kpaboutdata.o
>>> In file included from
>>> /var/ports/usr/ports/graphics/kipi-plugins-kde4/work/kipi-plugins-0.2.0-
>>> beta6/common/libkipiplugins/kpaboutdata.cpp:23:
>>> /var/ports/usr/ports/graphics/kipi-plugins-kde4/work/kipi-plugins-0.2.0-
>>> beta6/common/libkipiplugins/kpaboutdata.h:42: error: expected ',' or
>>> '...' before '&' token
>>> /var/ports/usr/ports/graphics/kipi-plugins-kde4/work/kipi-plugins-0.2.0-
>>> beta6/common/libkipiplugins/kpaboutdata.h:46: error: ISO C++ forbids
>>> declaration of 'KLocalizedString' with no type
>>>
>>>
>>> /usr/local/include/qtextstream.h:298: error: expected initializer before
>>> '&' token
>>> /usr/local/include/qtextstream.h:301: error: expected initializer before
>>> '&' token
>>> /usr/local/include/qtextstream.h:304: error: expected initializer before
>>> '&' token
>>> /usr/local/include/qtextstream.h:307: error: expected initializer before
>>> '&' token
>>> /usr/local/include/qtextstream.h:308: error: expected initializer before
>>> '&' token
>>> /usr/local/include/qtextstream.h:309: error: expected initializer before
>>> '&' token
>>> /usr/local/include/qtextstream.h:310: error: expected initializer before
>>> '&' token
>>> /usr/local/include/qtextstream.h:311: error: expected initializer before
>>> '&' token
>>> /usr/local/include/qtextstream.h:312: error: expected initializer before
>>> '&' token
>>> /usr/local/include/qtextstream.h:313: error: expected initializer before
>>> '&' token
>>> /usr/local/include/qtextstream.h:314: error: expected initializer before
>>> '&' token
>>> /usr/local/include/qtextstream.h:316: error: expected initializer before
>>> 'qSetW'
>>> /usr/local/include/qtextstream.h:322: error: expected initializer before
>>> 'qSetFill'
>>> /usr/local/include/qtextstream.h:328: error: expected initializer before
>>> 'qSetPrecision'
>>> In file included from /usr/local/include/qvaluelist.h:42,
>>> from /usr/local/include/qtranslator.h:44,
>>> from /usr/local/include/qapplication.h:45,
>>> from
>>> /var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/libs/
>>> threadimageio/loadsavetask.cpp:29:
>>>
>>> # pkg_info -W /usr/local/include/qvaluelist.h
>>> /usr/local/include/qvaluelist.h was installed by package qt-copy-3.3.8_9
>>
>> After issuing "make configure" for the port, what value do you see in
>> the CMakeCache.txt file (located in ${WRKSRC} ) for the QT_INCLUDE_DIR
>> variable?
>>
>> What version of cmake do you have installed? My version of cmake
>> 2.6.2 includes a block in the FindQt4.cmake file that reads:
>>
>> # Set QT_QT_INCLUDE_DIR
>> FIND_PATH(QT_QT_INCLUDE_DIR qglobal.h
>>PATHS
>>${QT_INCLUDE_DIR}/Qt
>> ${QT_LIBRARY_DIR}/QtCore.framework/Headers
>>NO_DEFAULT_PATH
>>)
>>
>> And if I'm reading that correctly, it shouldn't be looking for the
>> include headers in the base /usr/local/include directory at all.
>>
>> Matt
>
> # pkg_info -Ix cmake
> cmake-2.6.2 A cross-platform make
>
> QT_INCLUDE_DIR:PATH=/usr/local/include/qt4
>
> # ls /usr/local/include/qt4/
> QsciQtAssistant QtDesigner QtNetwork QtSql
> QtUiTools QtXmlPatterns
> Qt QtCore QtGui QtOpenGLQtSvg
> QtWebKit
> Qt3Support QtDBus QtHelp QtScriptQtTest QtXml
>
> /glz
That looks like what I would expect to see. I can't reproduce this
problem on my local machine, even with the qt33 port installed.
Sorry - I'm not sure what else to check.
Matt
___
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: kipi-plugins-kde4 and digikam-kde4 picks up qt3 headers from qt-copy-3.3.8_9
On Wed, Feb 18, 2009 at 12:58 PM, Goran Lowkrantz
wrote:
> Trying to build the KDE4 versions of these ports fails as the build pick up
> old headers from qt3 through qt-copy-3.3.8_9.
>
>
> [ 0%] Building CXX object
> common/libkipiplugins/CMakeFiles/kipiplugins.dir/kpaboutdata.o
> In file included from
> /var/ports/usr/ports/graphics/kipi-plugins-kde4/work/kipi-plugins-0.2.0-beta6/common/libkipiplugins/kpaboutdata.cpp:23:
> /var/ports/usr/ports/graphics/kipi-plugins-kde4/work/kipi-plugins-0.2.0-beta6/common/libkipiplugins/kpaboutdata.h:42:
> error: expected ',' or '...' before '&' token
> /var/ports/usr/ports/graphics/kipi-plugins-kde4/work/kipi-plugins-0.2.0-beta6/common/libkipiplugins/kpaboutdata.h:46:
> error: ISO C++ forbids declaration of 'KLocalizedString' with no type
>
>
> /usr/local/include/qtextstream.h:298: error: expected initializer before '&'
> token
> /usr/local/include/qtextstream.h:301: error: expected initializer before '&'
> token
> /usr/local/include/qtextstream.h:304: error: expected initializer before '&'
> token
> /usr/local/include/qtextstream.h:307: error: expected initializer before '&'
> token
> /usr/local/include/qtextstream.h:308: error: expected initializer before '&'
> token
> /usr/local/include/qtextstream.h:309: error: expected initializer before '&'
> token
> /usr/local/include/qtextstream.h:310: error: expected initializer before '&'
> token
> /usr/local/include/qtextstream.h:311: error: expected initializer before '&'
> token
> /usr/local/include/qtextstream.h:312: error: expected initializer before '&'
> token
> /usr/local/include/qtextstream.h:313: error: expected initializer before '&'
> token
> /usr/local/include/qtextstream.h:314: error: expected initializer before '&'
> token
> /usr/local/include/qtextstream.h:316: error: expected initializer before
> 'qSetW'
> /usr/local/include/qtextstream.h:322: error: expected initializer before
> 'qSetFill'
> /usr/local/include/qtextstream.h:328: error: expected initializer before
> 'qSetPrecision'
> In file included from /usr/local/include/qvaluelist.h:42,
>from /usr/local/include/qtranslator.h:44,
>from /usr/local/include/qapplication.h:45,
>from
> /var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/libs/threadimageio/loadsavetask.cpp:29:
>
> # pkg_info -W /usr/local/include/qvaluelist.h
> /usr/local/include/qvaluelist.h was installed by package qt-copy-3.3.8_9
After issuing "make configure" for the port, what value do you see in
the CMakeCache.txt file (located in ${WRKSRC} ) for the QT_INCLUDE_DIR
variable?
What version of cmake do you have installed? My version of cmake
2.6.2 includes a block in the FindQt4.cmake file that reads:
# Set QT_QT_INCLUDE_DIR
FIND_PATH(QT_QT_INCLUDE_DIR qglobal.h
PATHS
${QT_INCLUDE_DIR}/Qt
${QT_LIBRARY_DIR}/QtCore.framework/Headers
NO_DEFAULT_PATH
)
And if I'm reading that correctly, it shouldn't be looking for the
include headers in the base /usr/local/include directory at all.
Matt
___
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: kipi-plugins-kde4 and digikam-kde4 picks up qt3 headers from qt-copy-3.3.8_9
On Wed, Feb 18, 2009 at 3:30 PM, Goran Lowkrantz wrote: > --On Wednesday, February 18, 2009 2:34 PM -0600 Matt > wrote: > >> On Wed, Feb 18, 2009 at 2:22 PM, Goran Lowkrantz >> wrote: >>> >>> --On Wednesday, February 18, 2009 2:13 PM -0600 Matt >>> wrote: >>> >>>> On Wed, Feb 18, 2009 at 12:58 PM, Goran Lowkrantz >>>> wrote: >>>>> >>>>> Trying to build the KDE4 versions of these ports fails as the build >>>>> pick up old headers from qt3 through qt-copy-3.3.8_9. [snip] > > Here is the first time we get the error and -I/usr/local/include occurs > before the Qt4 paths. > > [ 9%] ^[[32mBuilding CXX object > digikam/CMakeFiles/digikamcore.dir/__/libs/threadimageio/loadsavetask.o^M > ^[[0mcd > /var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam > && /usr/bin/c++ -D_GNU_SOURCE -DQT_NO_STL -D > QT_NO_CAST_TO_ASCII -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DQT3_SUPPORT > -DQT3_SUPPORT_WARNINGS -DMAKE_DIGIKAMCORE_LIB -O2 -pipe > -fno-strict-aliasing -Woverloaded-virtual -fvisibility=hidden > -fvisibility-inlines-hidden -O2 -g -fPIC -I/var/ports/usr/ports/gra > phics/digikam-kde4/work/digikam-0.10.0-rc2/digikam > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/. > ./libs/dimg > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../libs/dimg/loaders > -I/var/ports/usr/po > rts/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../libs/dimg/filters > -I/var/ports/usr/ports/graphics/digikam-kde4/work/ > digikam-0.10.0-rc2/digikam/../libs/whitebalance > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../l > ibs/dmetadata > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../libs/histogram > -I/var/ports/usr/por > ts/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../libs/curves > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam > -0.10.0-rc2/digikam/../libs/levels > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../libs/lprof > -I/ > var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../libs/jpegutils > -I/var/ports/usr/ports/graphics/digik > am-kde4/work/digikam-0.10.0-rc2/digikam/../libs/greycstoration > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-r > c2/digikam/../libs/threadimageio > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../libs/widgets/com > mon > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../libs/widgets/imageplugins > -I/var/ports/usr/po > rts/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../libs/widgets/metadata > -I/var/ports/usr/ports/graphics/digikam-kde4/w > ork/digikam-0.10.0-rc2/digikam/../libs/widgets/iccprofiles > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/d > igikam/../libs/imageproperties > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../libs/dialogs > -I/va > r/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../libs/database > -I/var/ports/usr/ports/graphics/digikam- > kde4/work/digikam-0.10.0-rc2/digikam/../libs/database/sqlite2 > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc > 2/digikam/../libs/database/haar > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../utilities/slidesh > ow > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../utilities/imageeditor/editor > -I/var/ports/usr/ > ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../utilities/imageeditor/canvas > -I/var/ports/usr/ports/graphics/digik > am-kde4/work/digikam-0.10.0-rc2/digikam/../utilities/imageeditor/tools > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam- > 0.10.0-rc2/digikam/../utilities/imageeditor/rawimport > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digika > m/../libs/themeengine > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../utilities/kipiiface > -I/var/ > ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../utilities/cameragui > -I/var/ports/usr/ports/graphics/digi > kam-kde4/work/digikam-0.10.0-rc2/digikam/../utilities/setup > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/ > digikam/../utilities/batch > -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../utilities/lighttable > - > I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../utilities/searchwindow > -I/var/ports/usr/ports/grap > hics/digikam-kde4/work/digikam-0.10.0-rc2/
Re: kipi-plugins-kde4 and digikam-kde4 picks up qt3 headers from qt-copy-3.3.8_9
On Wed, Feb 18, 2009 at 4:34 PM, Goran Lowkrantz wrote: > --On Wednesday, February 18, 2009 3:55 PM -0600 Matt > wrote: > [snip] >>> [ 9%] ^[[32mBuilding CXX object >>> digikam/CMakeFiles/digikamcore.dir/__/libs/threadimageio/loadsavetask.o^M >>> ^[[0mcd >>> /var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digik >>> am && /usr/bin/c++ -D_GNU_SOURCE -DQT_NO_STL -D >>> QT_NO_CAST_TO_ASCII -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DQT3_SUPPORT >>> -DQT3_SUPPORT_WARNINGS -DMAKE_DIGIKAMCORE_LIB -O2 -pipe >>> -fno-strict-aliasing -Woverloaded-virtual -fvisibility=hidden >>> -fvisibility-inlines-hidden -O2 -g -fPIC -I/var/ports/usr/ports/gra >>> phics/digikam-kde4/work/digikam-0.10.0-rc2/digikam >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/dig >>> ikam/. ./libs/dimg >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/dig >>> ikam/../libs/dimg/loaders -I/var/ports/usr/po >>> rts/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../libs/dimg/f >>> ilters -I/var/ports/usr/ports/graphics/digikam-kde4/work/ >>> digikam-0.10.0-rc2/digikam/../libs/whitebalance >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/dig >>> ikam/../l ibs/dmetadata >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/dig >>> ikam/../libs/histogram -I/var/ports/usr/por >>> ts/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../libs/curves >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam >>> -0.10.0-rc2/digikam/../libs/levels >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/dig >>> ikam/../libs/lprof -I/ >>> var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digika >>> m/../libs/jpegutils -I/var/ports/usr/ports/graphics/digik >>> am-kde4/work/digikam-0.10.0-rc2/digikam/../libs/greycstoration >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-r >>> c2/digikam/../libs/threadimageio >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/dig >>> ikam/../libs/widgets/com mon >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/dig >>> ikam/../libs/widgets/imageplugins -I/var/ports/usr/po >>> rts/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../libs/widget >>> s/metadata -I/var/ports/usr/ports/graphics/digikam-kde4/w >>> ork/digikam-0.10.0-rc2/digikam/../libs/widgets/iccprofiles >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/d >>> igikam/../libs/imageproperties >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/dig >>> ikam/../libs/dialogs -I/va >>> r/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/ >>> ../libs/database -I/var/ports/usr/ports/graphics/digikam- >>> kde4/work/digikam-0.10.0-rc2/digikam/../libs/database/sqlite2 >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc >>> 2/digikam/../libs/database/haar >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/dig >>> ikam/../utilities/slidesh ow >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/dig >>> ikam/../utilities/imageeditor/editor -I/var/ports/usr/ >>> ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/../utilities >>> /imageeditor/canvas -I/var/ports/usr/ports/graphics/digik >>> am-kde4/work/digikam-0.10.0-rc2/digikam/../utilities/imageeditor/tools >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam- >>> 0.10.0-rc2/digikam/../utilities/imageeditor/rawimport >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/dig >>> ika m/../libs/themeengine >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/dig >>> ikam/../utilities/kipiiface -I/var/ >>> ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digikam/.. >>> /utilities/cameragui -I/var/ports/usr/ports/graphics/digi >>> kam-kde4/work/digikam-0.10.0-rc2/digikam/../utilities/setup >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/ >>> digikam/../utilities/batch >>> -I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/dig >>> ikam/../utilities/lighttable - >>> I/var/ports/usr/ports/graphics/digikam-kde4/work/digikam-0.10.0-rc2/digi >>> kam/../utilities/searchwindow -I/var/ports/usr/ports/grap >>> hics/digikam-kde4/work/digikam-0.10.0-rc
Re: [CFT] Firefox-3.1-Beta3
On Fri, Apr 10, 2009 at 6:45 AM, Martin Wilke wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Howdy, > > If someone want to play with firefox 3.1 beta3 here, is a patch for marcuscom > portstree: > > http://miwi.homeunix.com/patches/firefox31_b3.diff > > and here a tarball :) > > http://miwi.homeunix.com/firefox3-devel.tgz > Build works well for me on i386 and 7-STABLE. You'll need the patch mentioned at: https://bugzilla.mozilla.org/show_bug.cgi?id=478871 if you're attempting to build with the version of pango currently in ports (1.24.0). Matt ___ 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: [CFT] QT-4.5.1 testers wanted
On Sun, Apr 26, 2009 at 5:35 PM, Martin Wilke wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Howdy, > > The KDE Team is happy to announce the first public Call for Testing > with QT-4.5.1. Recently, we focused on the complex and very time > consuming task of getting the QT4.5 ports into much better shape > so we can now go on the next step: much wider public testing. > I noticed a recent posting on the Amarok mailing list discussing a serious regression issue in Qt 4.5.1 svg. There is a patch in the KDE SVN at: http://websvn.kde.org/trunk/qt-copy/patches/0279-svg-rendering-regression.diff?view=log Should this be added to our QT4.5 or is it already addressed elsewhere? Matt ___ 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"
metamail requires xclock?
http://www.freebsd.org/cgi/ports.cgi?query=metamail shows all the bells and whistles the mail processing utility metamail now requires. Is there any way to avoid all those X stuff on a headless mail server? Setting "USE_XLIB=no" didn't help. Thanks! Matt Grimes ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: qemu-devel 20070731 port update - please test!
On 7/31/07, Juergen Lock <[EMAIL PROTECTED]> wrote: > Hi! > > Again I want to update the qemu-devel port (mainly because I played > with arm terrier/akita emulation as you can read on the qemu list, > but there are also other fixes) and need your help with testing. > It now also should respect ifname=tapX with -net tap (modified patch > after matthieu morel, Cc'd, I hope I didn't break it... :) > > Enjoy, > Juergen New snapshot version compiled cleanly for me this morning with you patches and appears to be running well with my WinXP hosts. Thanks! Matt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Eclipse 3.2.2 on 7.0-CURRENT
On 8/26/07, Indigo 23 <[EMAIL PROTECTED]> wrote: > > Do you know if there is there any way to choose which JDK to use when > building/running things like Eclipse? > > I have both JDK16 and diablo-jdk15 installed. > I have this accomplished by adding the following lines to my /usr/local/etc/javavm_opts.conf file: JAVA_HOME=/usr/local/jdk1.6.0 JAVA_OS=native JAVA_VENDOR=freebsd JAVA_VERSION=1.6 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ruby-bdb broken somehow?
[EMAIL PROTECTED]:/usr/ports/databases/ruby-bdb$ portupgrade -f ruby-bdb /usr/libexec/ld-elf.so.1: /usr/local/lib/ruby/site_ruby/1.8/i386-freebsd4/bdb.so: Undefined symbol "db_version_4002" This happened during an upgrade to clamav, and now portupgrade is broken (and won't.. upgrade..) We use bdb 4.2 on the system, which works with everything else.. but Ruby seems to have dragged in db 4.3 too. I have no idea what happened here. All my make.conf flags specify 42. -- Matt Sealey <[EMAIL PROTECTED]> Manager, Genesi, Developer Relations ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: ruby-bdb broken somehow?
Great so it's known but how can I fix it? -- Matt Sealey <[EMAIL PROTECTED]> Manager, Genesi, Developer Relations > -Original Message- > From: Sergey Matveychuk [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 05, 2006 9:39 AM > To: Riemer Palstra > Cc: Matt Sealey; freebsd-ports@freebsd.org > Subject: Re: ruby-bdb broken somehow? > > Riemer Palstra wrote: > > On Wed, Jul 05, 2006 at 09:18:57AM -0500, Matt Sealey wrote: > >> [EMAIL PROTECTED]:/usr/ports/databases/ruby-bdb$ portupgrade -f > >> ruby-bdb > >> /usr/libexec/ld-elf.so.1: > >> /usr/local/lib/ruby/site_ruby/1.8/i386-freebsd4/bdb.so: Undefined > >> symbol "db_version_4002" > > > > I had a similar issue on one of my systems once, and as a > quick fix I > > had to install databases/db41 too, and rebuild ruby-bdb > against it. I > > haven't had time yet to research it any further yet, but you might > > want to give it a try... > > > > ports/99697 > > -- > Dixi. > Sem. > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: ruby-bdb broken somehow?
(that is to say I applied the patch from the bugtracker and it rebuilds but it still does the same error.. what exactly am I meant to rebuild as in dependencies and so to make it work?) -- Matt Sealey <[EMAIL PROTECTED]> Manager, Genesi, Developer Relations > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sealey > Sent: Wednesday, July 05, 2006 10:25 AM > To: 'Sergey Matveychuk'; 'Riemer Palstra' > Cc: freebsd-ports@freebsd.org > Subject: RE: ruby-bdb broken somehow? > > > Great so it's known but how can I fix it? > > -- > Matt Sealey <[EMAIL PROTECTED]> > Manager, Genesi, Developer Relations > > > > -Original Message- > > From: Sergey Matveychuk [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, July 05, 2006 9:39 AM > > To: Riemer Palstra > > Cc: Matt Sealey; freebsd-ports@freebsd.org > > Subject: Re: ruby-bdb broken somehow? > > > > Riemer Palstra wrote: > > > On Wed, Jul 05, 2006 at 09:18:57AM -0500, Matt Sealey wrote: > > >> [EMAIL PROTECTED]:/usr/ports/databases/ruby-bdb$ portupgrade -f > > >> ruby-bdb > > >> /usr/libexec/ld-elf.so.1: > > >> /usr/local/lib/ruby/site_ruby/1.8/i386-freebsd4/bdb.so: > Undefined > > >> symbol "db_version_4002" > > > > > > I had a similar issue on one of my systems once, and as a > > quick fix I > > > had to install databases/db41 too, and rebuild ruby-bdb > > against it. I > > > haven't had time yet to research it any further yet, but > you might > > > want to give it a try... > > > > > > > ports/99697 > > > > -- > > Dixi. > > Sem. > > > > ___ > 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: ruby-bdb broken somehow?
Mrff. Okay I rebuuilt from scratch. First run of portupgrade complained that the DB was not the required format and completely rebuilt the package database. It makes me wonder what else broke that used Ruby and put databases on my disk somewhere.. and is going to explode because it was using a 1.8x bdb database and not a 4.3? -- Matt Sealey <[EMAIL PROTECTED]> Manager, Genesi, Developer Relations > -Original Message- > From: Sergey Matveychuk [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 05, 2006 12:49 PM > To: [EMAIL PROTECTED] > Cc: 'Riemer Palstra'; freebsd-ports@freebsd.org > Subject: Re: ruby-bdb broken somehow? > > Matt Sealey wrote: > > (that is to say I applied the patch from the bugtracker and it > > rebuilds but it still does the same error.. what exactly am > I meant to > > rebuild as in dependencies and so to make it work?) > > > > After the patch applied, make sure you set WITH_BDB_VER to > version you want and type `portupgrade ruby-bdb'. > You should have ruby18-bdb-0.5.9_1 after that. It should be > fixed. If not, remove portupgrade and ruby-bdb ports and > reinstall them from scratch. > > -- > Dixi. > Sem. > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: graphics/linux-dri on 4.11
Odd! The tar in FreeBSD 4.9 (tar (GNU tar) 1.13.25) supports .bz2 files. Archive format selection: -V, --label=NAME create archive with volume name NAME PATTERNat list/extract time, a globbing PATTERN -o, --old-archive, --portability write a V7 format archive --posixwrite a POSIX format archive -j, -y, --bzip, --bzip2, --bunzip2 filter the archive through bzip2 -z, --gzip, --ungzip filter the archive through gzip -Z, --compress, --uncompress filter the archive through compress --use-compress-program=PROGfilter through PROG (must accept -d) Maybe it's not tar, maybe the file is broken? -- Matt Sealey <[EMAIL PROTECTED]> Manager, Genesi, Developer Relations > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bill Milford > Sent: Friday, July 07, 2006 9:31 AM > To: [EMAIL PROTECTED] > Subject: graphics/linux-dri on 4.11 > > I am trying to build graphics/linux_dri on 4.11. I get > errors because the tar in 4.11 does not support .bz2 > distfiles. Any suggestions on how to get port to extract the > .bz2 distfiles correctly? > > Bill > > ___ > 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: graphics/linux-dri on 4.11
> On 6.1, the bsdtar will figure out that a file is .gz or .bz2 > and still extract, however, the GNU tar does not. Conclusion, GNU tar sucks :) > It seems that this port has distfile in two different formats > and the the port structure cannot handle it. Definitely. USE_BZIP2 (see docs in Mk/bsd.port.mk) and so on is set which sets the tarball format for all of them. Which is kind of dumb. Couldn't it be some kind of clever heuristic (match .tar.gz or .tgz or .tar.bz2 or .tbz2 and pick on each extract) rather than requiring ALL of the distfiles to be one format (which is never ever the case when you have more than one coder :) I guess this has been completely looked over since BSD tar got very clever about it. The worry is.. isn't 4.x totally obselete, unsupported now, and therefore not worth coding that fix for? :D *begs the port maintainers, offers a small child for bloody sacrifice* -- Matt Sealey <[EMAIL PROTECTED]> Manager, Genesi, Developer Relations ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: graphics/linux-dri on 4.11
> The policy is that we no longer require committers to make > sure things work on 4.X before they commit. To the extent > that people send patches, things will keep running. Well this is a kind of internal-to-ports thing that needs a small change, not really a "fix linux-dri" thing. It could happen with plenty of packages, so who deals with that? > The security team support for RELENG_4 is currently scheduled > to end on 20070131. After that point, ports support on 4 is > going to be especially problematic; I am currently trying to > determine _exactly_ how bad the bitrot on 4 is. It's worse > than people think. It's terrible. Nothing works properly day-to-day, but we manage to survive. I curse the day I decided I would leave this server at 4.9. > Anyone running a desktop needs to be on 6.1 or RELENG_6 now, > unless they are one of the few people affected by one of the > bugs, or for some reason are staying on 5.5 for now. Ah well. Good luck :) -- Matt Sealey <[EMAIL PROTECTED]> Manager, Genesi, Developer Relations ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: graphics/linux-dri on 4.11
Yeah wouldn't a solution be to have bsdtar have a PORT_REPLACES_BASE kind of thing? Or a use.tar like use.perl? -- Matt Sealey <[EMAIL PROTECTED]> Manager, Genesi, Developer Relations > -Original Message- > From: Mark Linimon [mailto:[EMAIL PROTECTED] > Sent: Friday, July 07, 2006 1:43 PM > To: Matt Sealey > Cc: 'Mark Linimon'; [EMAIL PROTECTED]; 'Bill Milford' > Subject: Re: graphics/linux-dri on 4.11 > > On Fri, Jul 07, 2006 at 01:33:55PM -0500, Matt Sealey wrote: > > Well this is a kind of internal-to-ports thing that needs a small > > change, not really a "fix linux-dri" thing. It could happen with > > plenty of packages, so who deals with that? > > There is no individual who's on the hook for that, exactly. > > What happens if you try to add a dependency on > archivers/libarchive and change tar to bsdtar? > > mcl > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vim7 broken or not broken or?
[EMAIL PROTECTED]:/usr/ports$ portupgrade -f vim ** Port marked as IGNORE: editors/vim: is marked as broken: does not compile on 4.X; use editors/vim6 instead [EMAIL PROTECTED]:/usr/ports$ vim --version VIM - Vi IMproved 7.0 (2006 May 7, compiled Jul 5 2006 15:35:44) Included patches: 1-4, 6-26, 29-31, 33-35 Compiled by [EMAIL PROTECTED] [EMAIL PROTECTED]:/usr/ports$ uname -a FreeBSD mithrandir.softwarenexus.net 4.9-RELEASE FreeBSD 4.9-RELEASE #0: Mon Oct 27 17:51:09 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 I got this version from ports the day it hit the tree, an upgrade from vim6 (using the "vim" port directory). How come if it doesn't compile on 4.X, I am running it now, compiled from the port? A bunch of other stuff I have compiled is marked as broken too and no major updates were posted. They just get marked as broken for 4.X or "does not compile at all". However I am having insane libtool problems with mod_python3 and mod_auth_pam2 which I cannot resolve. Does anyone actually check if these things really do work or are they just being marked to close down the ports bug list as fast as possible? -- Matt Sealey <[EMAIL PROTECTED]> Manager, Genesi, Developer Relations ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: vim7 broken or not broken or?
What's the "latest toolchain" for 4.9? All my ports are at the latest versions, including gmake and stuff where relevant. Is there a set of ports I should be using to bring it up to a current spec (that uhh. won't rely on me recompiling 400 ports..) or am I okay with what I have? I am having libtool problems right now I'd love to solve, related to Apache modules. If there is some favourable tool or lib that replaces a base package I needed to optionally compile to make this work, I am guessing that I just don't know about them? (it complains about tagged something or other: see well below) > The cluster environment attempts to install each port from > scratch, including its dependencies as packages. This will > catch many marginal cases that installing the port on a > fully- (or nearly fully-) populated system will not catch. So it could be a weird dependency bug (some include from another port never got installed or so) and not vim itself? libtool crap [EMAIL PROTECTED]:/usr/ports$ sudo portupgrade -f mod_auth_pam-1.1.1_1 Password: ---> Upgrading 'mod_auth_pam-1.1.1_1' to 'mod_auth_pam-1.1.1_2' (www/mod_auth_pam2) ---> Building '/usr/ports/www/mod_auth_pam2' ===> Cleaning for pkg_install-20060113 ===> Cleaning for apache-2.2.2 ===> Cleaning for gmake-3.81_1 ===> Cleaning for perl-5.8.8 ===> Cleaning for python-2.4.3 ===> Cleaning for openssl-stable-0.9.7j ===> Cleaning for autoconf-2.59_2 ===> Cleaning for libtool-1.5.22_2 ===> Cleaning for expat-2.0.0_1 ===> Cleaning for db42-4.2.52_4 ===> Cleaning for apr-db42-1.2.7_1 ===> Cleaning for libiconv-1.9.2_2 ===> Cleaning for mysql-client-4.1.20 ===> Cleaning for rc_subr-1.31_1 ===> Cleaning for gettext-0.14.5_2 ===> Cleaning for m4-1.4.4 ===> Cleaning for help2man-1.36.4_1 ===> Cleaning for automake-1.9.6 ===> Cleaning for linuxthreads-2.2.3_21 ===> Cleaning for readline-5.1 ===> Cleaning for ldconfig_compat-1.0_8 ===> Cleaning for p5-gettext-1.05_1 ===> Cleaning for mod_auth_pam-1.1.1_2 ===> Extracting for mod_auth_pam-1.1.1_2 => MD5 Checksum OK for mod_auth_pam-2.0-1.1.1.tar.gz. ===> mod_auth_pam-1.1.1_2 depends on file: /usr/local/sbin/pkg_info - found ===> Patching for mod_auth_pam-1.1.1_2 ===> Applying FreeBSD patches for mod_auth_pam-1.1.1_2 ===> mod_auth_pam-1.1.1_2 depends on file: /usr/local/sbin/apxs - found ===> mod_auth_pam-1.1.1_2 depends on executable: gmake - found ===> mod_auth_pam-1.1.1_2 depends on file: /usr/local/sbin/apxs - found ===> Configuring for mod_auth_pam-1.1.1_2 ===> Building for mod_auth_pam-1.1.1_2 /usr/local/sbin/apxs -c mod_auth_pam.c -lpam /usr/local/build-1/libtool --silent --mode=compile cc -prefer-pic -O -pipe -I/usr/local/include/mysql -D_THRE AD_SAFE -D_THREAD_SAFE -D_REENTRANT -O -pipe -I/usr/local/include/mysql -D_THREAD_SAFE -g -O2 -pthread -I/us r/local/include/apache22 -I/usr/local/include/apr-1 -I/usr/local/include/apr-1 -I/usr/local/include/db42 - I/usr/local/include -c -o mod_auth_pam.lo mod_auth_pam.c && touch mod_auth_pam.slo libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' apxs:Error: Command failed with rc=65536 . gmake: *** [mod_auth_pam.la] Error 1 *** Error code 2 Stop in /usr/ports/www/mod_auth_pam2. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade35201.0 env PORT_UPGRADE=yes make PORT_U PGRADE=yes ** Fix the problem and try again. ** Listing the failed packages (*:skipped / !:failed) ! www/mod_auth_pam2 (mod_auth_pam-1.1.1_1) (unknown build error) ---> Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed -- Matt Sealey <[EMAIL PROTECTED]> Manager, Genesi, Developer Relations ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
libtool not happy building apache modules
===> Generating apache plist /usr/local/build-1/libtool --silent --mode=compile cc -prefer-pic -O -pipe -I/usr/local/include/mysql -D_THRE AD_SAFE -D_THREAD_SAFE -D_REENTRANT -O -pipe -I/usr/local/include/mysql -D_THREAD_SAFE -g -O2 -pthread -I/us r/local/include/apache22 -I/usr/local/include/apr-1 -I/usr/local/include/apr-1 -I/usr/local/include/db42 - I/usr/local/include -c -o fcgi_buf.lo fcgi_buf.c && touch fcgi_buf.slo libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' apxs:Error: Command failed with rc=65536 I am getting this ALL of the time now. I haven't changed a thing; from what I remember this is libtool getting confused about my compiler settings and so on, but I have no definitions set for CC, I didn't change the compiler ever, I just don't understand why it spontaneously broke for everything. Previously I was having trouble with the mod_python port which did this, but all my other modules worked fine. Any clues on what I can rebuild/reconfigure in order to get this to work? It's important that we install some new modules this week. -- Matt Sealey <[EMAIL PROTECTED]> Manager, Genesi, Developer Relations ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: libtool not happy building apache modules
But this is the libtool from APR (/usr/local/build-1/libtool). And I've rebuilt APR and libtool15, all day, testing the modules I want to install, to no avail. -- Matt Sealey <[EMAIL PROTECTED]> Manager, Genesi, Developer Relations _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of michael johnson Sent: Thursday, July 20, 2006 11:31 AM To: [EMAIL PROTECTED] Cc: freebsd-ports@freebsd.org Subject: Re: libtool not happy building apache modules On 7/20/06, Matt Sealey <[EMAIL PROTECTED]> wrote: ===> Generating apache plist /usr/local/build-1/libtool --silent --mode=compile cc -prefer-pic -O -pipe -I/usr/local/include/mysql -D_THRE AD_SAFE -D_THREAD_SAFE -D_REENTRANT -O -pipe -I/usr/local/include/mysql -D_THREAD_SAFE -g -O2 -pthread -I/us r/local/include/apache22 -I/usr/local/include/apr-1 -I/usr/local/include/apr-1 -I/usr/local/include/db42 - I/usr/local/include -c -o fcgi_buf.lo fcgi_buf.c && touch fcgi_buf.slo libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' apxs:Error: Command failed with rc=65536 I am getting this ALL of the time now. I haven't changed a thing; from what I remember this is libtool getting confused about my compiler settings and so on, but I have no definitions set for CC, I didn't change the compiler ever, I just don't understand why it spontaneously broke for everything. Previously I was having trouble with the mod_python port which did this, but all my other modules worked fine. Any clues on what I can rebuild/reconfigure in order to get this to work? It's important that we install some new modules this week. reinstall or update libtool -- Matt Sealey <[EMAIL PROTECTED]> Manager, Genesi, Developer Relations ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to " <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
munin-node install problems
FreeBSD 6.1 STABLE Installing munin-node from packages using portupgrade does not successfully install. I have one of my FreeBSD servers set up as a NFS server serving some FreeBSD NFS clients. The NFS server exports the usr/src/, usr/obj, and usr/ports directories to the NFS clients. This way, I only need to recompile the src on one machine. It also allows me to build packages using portupgrade on the NFS server and install them on the NFS clients, so I don't have to download the src for each package on each separate machine. When I install the munin-node on the NFS server, I get no problems and everything works. However, when I install munin-node on the NFS clients, not even one install works. It doesn't install the munin-node.sh in /usr/local/etc/rc.d, and the process will not start. Below are the details of the install. I copy pasted from "You need a group "munin"." to "Would you like me to set up log rotation [y]? y" for both installs. As you can see, they are quite different. Note the "./+INSTALL: /usr/local/etc/rc.d/munin-node.sh: not found" from the install on the NFS Client. Using portupgrade -NfPP on a NFS client. - You need a group "munin". Would you like me to create it [y]? y Done. Initializing new plugins..done. ./+INSTALL: /usr/local/etc/rc.d/munin-node.sh: not found Would you like me to set up log rotation [y]? y - Using portupgrade -Nfp on NFS server. Also saw same install when you do a make install. - You need a group "munin". Would you like me to create it [y]? y Done. ===> Generating temporary packing list mkdir -p /usr/local/etc/munin/plugins mkdir -p /usr/local/etc/munin/plugin-conf.d mkdir -p /usr/local/share/munin/plugins mkdir -p /usr/local/sbin mkdir -p /usr/local/lib/perl5/site_perl/5.8.8/Munin/Plugin mkdir -p /var/log mkdir -p /var/run/munin mkdir -p /usr/local/var/munin/plugin-state chgrp munin /usr/local/var/munin/plugin-state chmod 775 /usr/local/var/munin/plugin-state chmod 755 /usr/local/etc/munin/plugin-conf.d ./install-sh -m 0755 build/node/munin-node /usr/local/sbin/ ./install-sh -m 0755 build/node/munin-node-configure /usr/local/sbin/ test -f "/usr/local/etc/munin/munin-node.conf" || ./install-sh -m 0644 build/node/munin-node.conf /usr/local/etc/munin/ ./install-sh -m 0755 build/node/munin-run /usr/local/sbin/ ./install-sh -m 0755 build/node/munin-node-configure-snmp /usr/local/sbin/ echo Done. Done. for p in build/node/node.d.freebsd/* build/node/node.d/*; do\ if test -f "$p" ; then \ family=`sed -n 's/^#%# family=\(.*\)$/\1/p' $p`;\ test "$family" || family=contrib; \ if echo "auto manual contrib snmpauto" | grep $family >/dev/null; then \ test -f "/usr/local/share/munin/plugins/`basename $p`" \ || ./install-sh -m 0755 $p /usr/local/share/munin/plugins/; \ fi; \ fi \ done ./install-sh -m 0644 build/node/plugins.history /usr/local/share/munin/plugins/ #TODO: #configure plugins. install -o root -g wheel -m 555 /usr/ports/sysutils/munin-node/work/munin-node.sh /usr/local/etc/rc.d/munin-node.sh install -o root -g wheel -m 444 /usr/ports/sysutils/munin-node/work/munin-1.2.4/build/node/munin-node.conf /usr/local/etc/munin/munin-node.conf.sample install -o root -g wheel -m 444 files/plugins.conf /usr/local/etc/munin/plugin-conf.d/plugins.conf.sample Unless this file already existed, a sample configuration file has been placed in /usr/local/etc/munin/munin-node.conf. Please edit it according to your needs. The Munin client will *not* be started automatically. To allow it to start, put this line in /etc/rc.conf: munin_node_enable="YES" Then, it will be started on the next boot. If this line is already present, the client will be started now. Otherwise, edit /etc/rc.conf and execute this command: /usr/local/etc/rc.d/munin-node.sh start Initializing new plugins..done. Starting munin_node. Would you like me to set up log rotation [y]? y
Re: screen and tmux should be listed under the same category
On Sat, May 16, 2009 at 5:53 PM, Philip M. Gollucci wrote: > Josh Rickmar wrote: > > GNU screen is listed under sysutils, while tmux is listed under misc. > > Shouldn't the two at least be in the same category, since they both do > > the exact same thing? (tmux is even designed to be a BSD-licensed > > replacement for screen.) > > > Does anyone have any thoughts on tmux vs screen ? the NO_PACKAGE in > screen has been annoying me for years now if I can find a good > replacement I'm so there. > > > tmux does not work inside the shell due to sc. But in X it works wonders. ___ 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: screen and tmux should be listed under the same category
On Sun, May 17, 2009 at 2:37 AM, Freddie Cash wrote: > On Sat, May 16, 2009 at 4:38 PM, matt donovan > wrote: > > On Sat, May 16, 2009 at 5:53 PM, Philip M. Gollucci < > pgollu...@p6m7g8.com>wrote: > > > >> Josh Rickmar wrote: > >> > GNU screen is listed under sysutils, while tmux is listed under misc. > >> > Shouldn't the two at least be in the same category, since they both do > >> > the exact same thing? (tmux is even designed to be a BSD-licensed > >> > replacement for screen.) > >> > > >> Does anyone have any thoughts on tmux vs screen ? the NO_PACKAGE in > >> screen has been annoying me for years now if I can find a good > >> replacement I'm so there. > >> > > tmux does not work inside the shell due to sc. But in X it works > wonders. > > tmux works just fine at a console without X running. > > > hmm odd since last time I asked about it it did not since I m the one that brought it up, since I had an error and was told that the sc does not support that feature what freebsd are you running since I tired it in 7.x. ___ 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: screen and tmux should be listed under the same category
On Sun, May 17, 2009 at 7:43 PM, matt donovan wrote: > > > On Sun, May 17, 2009 at 2:37 AM, Freddie Cash wrote: > >> On Sat, May 16, 2009 at 4:38 PM, matt donovan >> wrote: >> > On Sat, May 16, 2009 at 5:53 PM, Philip M. Gollucci < >> pgollu...@p6m7g8.com>wrote: >> > >> >> Josh Rickmar wrote: >> >> > GNU screen is listed under sysutils, while tmux is listed under misc. >> >> > Shouldn't the two at least be in the same category, since they both >> do >> >> > the exact same thing? (tmux is even designed to be a BSD-licensed >> >> > replacement for screen.) >> >> > >> >> Does anyone have any thoughts on tmux vs screen ? the NO_PACKAGE in >> >> screen has been annoying me for years now if I can find a good >> >> replacement I'm so there. >> >> >> > tmux does not work inside the shell due to sc. But in X it works >> wonders. >> >> tmux works just fine at a console without X running. >> >> >> > hmm odd since last time I asked about it it did not since I m the one that > brought it up, since I had an error and was told that the sc does not > support that feature what freebsd are you running since I tired it in 7.x. > forgot something unless of coruse your using a term change trick that I suggested to the author of tmux. ___ 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"
Make package-recursive problem
Hi all, I've started noticing more and more that packages I build are missing files after they are rebuilt. I've tested this time and time again, and seem to be able to show that about 10 ports (gettext, apache, net-snmp, some php modules, etc.) are built correctly the first time, but when later re-packaged, do not contain all the files they need. For instance, I have a build box (named atlantis for the sake of this email): on atlantis, I build all packages with make package-recursive, and then install them on all boxes via NFS. This works fine, except that over time, as I compile more packages, the ports system re-generates packages for existing built packages (for instance, if I make a nagios package, it recreates the apache package since that's a dependency. If I then install cacti, it recreates the apache package again). This is normally no big deal, as I haven't touched my source tree, config options, or anything like that. 99% of the time the packages are rebuilt consistently. However, since this point, I've had some php modules come up empty (as in my original email), and now, I'm having some other flukes as well. If you'll see below, somehow, fontconfig, mysql-client, and python25 got out of whack between my build box and a production webserver. Yet these are packages built from the same environment - same box, same config, same tree, etc. - I didn't change a thing, other than install them at different times. But my build tree on atlantis has not been updated or changed in any manor. This obviously occured because make package-recursive rebuilt these packages at some point because they were dependencies for other packages being installed. Except that, obviously, it didn't build the packages 100% identically to the time before: local$ sh check2.sh barfy -> fontconfig-2.6.0,1 isn't right barfy -> mysql-client-5.0.77_1 isn't right barfy -> python25-2.5.4_1 isn't right local$ sh check3.sh Server 1: atlantis Server 2: barfy Package: fontconfig Password: Password: 65,67d64 < /usr/local/share/doc/fontconfig/fontconfig-user.html < /usr/local/share/doc/fontconfig/fontconfig-user.pdf < /usr/local/share/doc/fontconfig/fontconfig-user.txt Here's an example of how to replicate: - Create and install net-snmp package on box1 and box2 - Set make.conf options for apache2 - Create a nagios package (cd /usr/ports/.../nagios && make package-recursive) - Install the nagios package on box1 - Create a cacti package (cd /usr/ports/.../cacti && make package-recursive) - Install the cacti package on box2 What you'll now most likely find is that there are package differences between the two boxes in the SNMP and apache package. One of the boxes (most likely box2) will be missing startup scripts for snmp because, when you created the cacti package, it re-created an apache package too, except that it didn't have all of the files. pkg_info -xL net-snmp will show two different result sets from each box, even though the net-snmp package was built from the same box. If you need me to, I can replicate this issue in actuality by pasting a command output showing the differences. Please let me know if that's needed. Thanks! -Matt ___ 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: Make package-recursive problem
I have no clue as to what is causing this, but this is probably the reason why people use the tinderbox or roll their own system to build consistent packages. I feel like I am though? I have a dedicated box just for building packages. make package creates a tbz file of all packages, and is supposed to be reliable. Another approach had even the package dependency inside a Makefile, so rebuilding the gettext package would trigger all dependent packages to get rebuilt too (I haven't tackled the problem of *reinstalling* them on the target hosts, though) Doesn't this already occur with the default tools in the port system? ___ 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: Make package-recursive problem
It should be under the following circumstances: - You don't update /usr/ports I haven't. - You don't change /etc/make.conf I haven't. - You don't deinstall packages I haven't. =) The "bug" I'm describing would make sense if SOMETHING changed. But I haven't changed a thing. ___ 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: what does this mean?
On Sat, Jun 6, 2009 at 10:03 AM, dan hirsch wrote: > 1. > > Running the csup(1)< > http://www.freebsd.org/cgi/man.cgi?query=csup&sektion=1>command > later will download and apply all the recent changes to your Ports > Collection, except actually rebuilding the ports for your own system. > > > > -- > regards, > Dan Hirsch > Linked-In: http://www.linkedin.com/in/danhirsch1 > ___ > 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" > exactly as it states it will update your port tree but will not rebuild and install ports that need updating. ___ 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: FreeBSD Port: nessus-2.2.9_1
On Tue, Jun 16, 2009 at 1:39 PM, Schweigert, Udo CERT < udo.schweig...@siemens.com> wrote: > No, there are no further updates as 2.2.9 is the last open source version. > > Udo > > On Tue, Jun 16, 2009 at 12:16:54 -0500, phillip.gonza...@metavante.comwrote: > > > > hi, > > > > i'm looking at the nessus port on one of my FreeBSD boxes(recently > updated > > ports tree) and it looks like it's at version 2.2.9. has this port not > > been updated or am i missing something? > > > > thanks for your time, > > > > Phillip P Gonzalez > > Information Security Analyst Sr. > > Security Analysis and Testing > > Metavante Corporation > > tel: 414.357.3156 > > > > > You have to go to the nessus website to grab the package now since it's no longer open source ___ 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: FreeBSD Port: nessus-2.2.9_1
On Tue, Jun 16, 2009 at 7:21 PM, Alexey Shuvaev < shuv...@physik.uni-wuerzburg.de> wrote: > On Tue, Jun 16, 2009 at 07:07:12PM -0400, matt donovan wrote: > > On Tue, Jun 16, 2009 at 1:39 PM, Schweigert, Udo CERT < > > udo.schweig...@siemens.com> wrote: > > > > > No, there are no further updates as 2.2.9 is the last open source > version. > > > > > > Udo > > > > > > On Tue, Jun 16, 2009 at 12:16:54 -0500, > phillip.gonza...@metavante.comwrote: > > > > > > > > hi, > > > > > > > > i'm looking at the nessus port on one of my FreeBSD boxes(recently > > > updated > > > > ports tree) and it looks like it's at version 2.2.9. has this port > not > > > > been updated or am i missing something? > > > > > > > > thanks for your time, > > > > > > > > Phillip P Gonzalez > > > > Information Security Analyst Sr. > > > > Security Analysis and Testing > > > > Metavante Corporation > > > > tel: 414.357.3156 > > > > > > > > > > > > > > > You have to go to the nessus website to grab the package now since it's > no > > longer open source > > > I don't use nessus myself but just checking their website I see 2.2.11 > as the latest open source version. > > Just 0.02$, > Alexey. yes which is out of date anyways might as well just grab the freebsd package ___ 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: vim ports broken.
On Fri, Jun 19, 2009 at 5:37 AM, Albert Shih wrote:
> Hi all
>
> I think the vim ports is broken.
>
> When I try to compile I've got :
>
> [root@ vim]# make
> ===> Vulnerability check disabled, database not found
> => 7.2.041% doesn't seem to exist in /usr/ports/distfiles/vim.
> => Attempting to fetch from http://ftp.vim.org/pub/vim/patches/7.2/.
> fetch: http://ftp.vim.org/pub/vim/patches/7.2/7.2.041%: Bad Request
> => Attempting to fetch from
> http://mirrors.24-7-solutions.net/pub/vim/patches/7.2/.
> fetch: http://mirrors.24-7-solutions.net/pub/vim/patches/7.2/7.2.041%: Bad
> Request
> => Attempting to fetch from http://ftp.tw.vim.org/pub/vim/patches/7.2/.
> fetch: http://ftp.tw.vim.org/pub/vim/patches/7.2/7.2.041%: Bad Request
> => Attempting to fetch from http://vim.stu.edu.tw/patches/7.2/.
> fetch: http://vim.stu.edu.tw/patches/7.2/7.2.041%: Not Found
> => Attempting to fetch from http://gd.tuwien.ac.at/pub/vim/patches/7.2/.
> fetch: http://gd.tuwien.ac.at/pub/vim/patches/7.2/7.2.041%: Bad Request
> => Attempting to fetch from
> http://www.etsimo.uniovi.es/pub/vim/patches/7.2/.
> fetch: http://www.etsimo.uniovi.es/pub/vim/patches/7.2/7.2.041%: Bad
> Request
> => Attempting to fetch from http://www.pt.vim.org/pub/vim/patches/7.2/.
> fetch: http://www.pt.vim.org/pub/vim/patches/7.2/7.2.041%: Bad Request
> => Attempting to fetch from
> http://www.pangora.org/vim.org/pub/vim/patches/7.2/.
>
> I don't known the purpose of last line of
>
># bits to remove
>BADPATCHES= 007 036 049 071 072 074 088 089 093 101 138 150 172
> 191 194
>204 205
>#.if !defined(WITH_LANG)
>#BADPATCHES+=
>#.endif
>.for p in ${BADPATCHES}
>PATCHFILES:=${PATCHFILES:N7.2.${p}}
>.endfor
>PATCHFILES:=${PATCHFILES:S/041/041%/}
>
> but it seem strange for me...
>
> Thanks the work.
>
> Regards.
>
>
>
> --
>
Nope not broken just takes a long time to grab that patch since it pulls
from FreeBSD ftp localdistfiles mirror under obrien
___
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: vim ports broken.
On Fri, Jun 19, 2009 at 6:59 PM, matt donovan wrote:
>
>
> On Fri, Jun 19, 2009 at 5:37 AM, Albert Shih wrote:
>
>> Hi all
>>
>> I think the vim ports is broken.
>>
>> When I try to compile I've got :
>>
>> [root@ vim]# make
>> ===> Vulnerability check disabled, database not found
>> => 7.2.041% doesn't seem to exist in /usr/ports/distfiles/vim.
>> => Attempting to fetch from http://ftp.vim.org/pub/vim/patches/7.2/.
>> fetch: http://ftp.vim.org/pub/vim/patches/7.2/7.2.041%: Bad Request
>> => Attempting to fetch from
>> http://mirrors.24-7-solutions.net/pub/vim/patches/7.2/.
>> fetch: http://mirrors.24-7-solutions.net/pub/vim/patches/7.2/7.2.041%:
>> Bad
>> Request
>> => Attempting to fetch from http://ftp.tw.vim.org/pub/vim/patches/7.2/.
>> fetch: http://ftp.tw.vim.org/pub/vim/patches/7.2/7.2.041%: Bad Request
>> => Attempting to fetch from http://vim.stu.edu.tw/patches/7.2/.
>> fetch: http://vim.stu.edu.tw/patches/7.2/7.2.041%: Not Found
>> => Attempting to fetch from http://gd.tuwien.ac.at/pub/vim/patches/7.2/.
>> fetch: http://gd.tuwien.ac.at/pub/vim/patches/7.2/7.2.041%: Bad Request
>> => Attempting to fetch from
>> http://www.etsimo.uniovi.es/pub/vim/patches/7.2/.
>> fetch: http://www.etsimo.uniovi.es/pub/vim/patches/7.2/7.2.041%: Bad
>> Request
>> => Attempting to fetch from http://www.pt.vim.org/pub/vim/patches/7.2/.
>> fetch: http://www.pt.vim.org/pub/vim/patches/7.2/7.2.041%: Bad Request
>> => Attempting to fetch from
>> http://www.pangora.org/vim.org/pub/vim/patches/7.2/.
>>
>> I don't known the purpose of last line of
>>
>># bits to remove
>>BADPATCHES= 007 036 049 071 072 074 088 089 093 101 138 150 172
>> 191 194
>>204 205
>>#.if !defined(WITH_LANG)
>>#BADPATCHES+=
>>#.endif
>>.for p in ${BADPATCHES}
>>PATCHFILES:=${PATCHFILES:N7.2.${p}}
>>.endfor
>>PATCHFILES:=${PATCHFILES:S/041/041%/}
>>
>> but it seem strange for me...
>>
>> Thanks the work.
>>
>> Regards.
>>
>
Here is the path to the patch file
ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/obrien/7.2.041%
___
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: vim ports broken.
On Mon, Jun 22, 2009 at 6:23 PM, Carlos A. M. dos Santos < unixma...@gmail.com> wrote: > On Mon, Jun 22, 2009 at 4:58 PM, Philip M. Gollucci > wrote: > > Helmut Schneider wrote: > >> > >> matt donovan wrote: > >>> > >>> On Fri, Jun 19, 2009 at 5:37 AM, Albert Shih > >>> wrote: > >>>> > >>>> I think the vim ports is broken. > >>> > >>> Nope not broken just takes a long time to grab that patch since it > pulls > >>> from FreeBSD ftp localdistfiles mirror under obrien > >> > >> The port *is* broken: > >> > >> # fetch > >> ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/obrien/7.2.041% > >> fetch: > >> ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/obrien/7.2.041%: > Bad > >> Request > >> # > >> > >> as fetch cannot handle "%" correctly. > > > > sure it can, it just needs '' around the url. > > The distinfo file is wrong. Edit it and put the correct data for that > patch: > > MD5 (vim/7.2.041) = 66bde35426c09d9c666e23215f9a19c9 > SHA256 (vim/7.2.041) = > 524aa9aeb9f8729fb91289f40a4c5fecf5d0d07d3655c4a38a65abc98f7cd71b > SIZE (vim/7.2.041) = 22993 > > Be warned that your mail agent (or mine) may break the second line > after the equal sign. > > David, could you please commit this fix? > > -- > My preferred quotation of Robert Louis Stevenson is "You cannot > make an omelette without breaking eggs". Not because I like the > omelettes, but because I like the sound of eggs being broken. > ___ > 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" > I have had no problem grabbing the patch from the local-distfiles. just takes a very long time of course though to get to the right mirror ___ 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: FreeBSD Port: mplayer-0.99.11_14
On Tue, Jul 21, 2009 at 12:51 PM, Michael D. Stackhouse < mstackho...@samsa.com> wrote: > Is there an update available for mplayer? The current version at > http://www.mplayerhq.hu seems to imply a 1.0 version. > > We're having problems with this error, that is likely corrected in a > version greater than 0.99.11_14: > vmbsd02# /usr/local/bin/mencoder > rtsp://root:p...@172.28.10.65/mpeg4/media.amp -ovc copy -o > /tmp/mike.mpeg4 > MEncoder 1.0rc2-4.2.1 (C) 2000-2007 MPlayer Team > CPU: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz (Family: 6, Model: > 26, Stepping: 8) > CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 > Compiled with runtime CPU detection. > Connecting to server 172.28.10.65[172.28.10.65]: 554... > librtsp: server responds: 'RTSP/1.0 401 Unauthorized' > rtsp_session: unsupported RTSP server. Server type is 'unknown'. > STREAM_LIVE555, URL: rtsp://root:p...@172.28.10.65/mpeg4/media.amp > success: format: 21 data: 0x0 - 0x0 > Stream not seekable! > file format detected. > Initiated "video/MP4V-ES" RTP subsession on port 51198 > VIDEO: [mp4v] 0x0 0bpp 6.000 fps0.0 kbps ( 0.0 kbyte/s) > [V] filefmt:21 fourcc:0x7634706D size:0x0 fps: 6.00 ftime:=0.1667 > videocodec: framecopy (0x0 0bpp fourcc=7634706d) > MultiFramedRTPSource::doGetNextFrame1(): The total received frame size > exceeds the client's buffer size (5). 1100 bytes of trailing data > will be dropped! > Saw an input frame too large (>=5). Increase MAX_RTP_FRAME_SIZE in > "demux_rtp.cpp". > Writing header... > ODML: Aspect information not (yet?) available or unspecified, not > writing vprp header. > Writing header... > ODML: Aspect information not (yet?) available or unspecified, not > writing vprp header. > MultiFramedRTPSource::doGetNextFrame1(): The total received frame size > exceeds the client's buffer size (5). 1100 bytes of trailing data > will be dropped! > Saw an input frame too large (>=5). Increase MAX_RTP_FRAME_SIZE in > "demux_rtp.cpp". > MultiFramedRTPSource::doGetNextFrame1(): The total received frame size > exceeds the client's buffer size (5). 1100 bytes of trailing data > will be dropped! > Saw an input frame too large (>=5). Increase MAX_RTP_FRAME_SIZE in > "demux_rtp.cpp". > MultiFramedRTPSource::doGetNextFrame1(): The total received frame size > exceeds the client's buffer size (5). 1100 bytes of trailing data > will be dropped! > Saw an input frame too large (>=5). Increase MAX_RTP_FRAME_SIZE in > "demux_rtp.cpp". > MultiFramedRTPSource::doGetNextFrame1(): The total received frame size > exceeds the client's buffer size (5). 1100 bytes of trailing data > will be dropped! > Saw an input frame too large (>=5). Increase MAX_RTP_FRAME_SIZE in > "demux_rtp.cpp". > > Any suggestions would be appreciated. > > Thanks! > > Michael D. Stackhouse > SAMSA, Inc. > 989-790-0507 > Saginaw, MI USA > www.samsa.com > > > > > samsaisgreat > > > ___ > 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" Considering that mplayer no longer does stable releases you would have to switch the makefile to use svn to get an updated mplayer ___ 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: What does py25 mean?
On Tue, Aug 4, 2009 at 4:48 PM, Lars Eighner wrote: > What does py25 mean? > > I can't seem to upgrade about 40 ports (the old versions of which now seem > to be broken) evidently because the build of > > py25-gtk-2.13.1 fails with the message > >py25-cairo-1.8.6 needs Python 2.6 at least. But you specified 2.5. > > Well, of *I* did not specify 2.5. > > But howcome something called py25-cairo needs Python 2.6? What does that > py25 on the front mean? Doesn't it mean python 2.5? If it doesn't mean > that, what does it mean? If it does mean that, then howcome it needs > python > 2.6? > > > -- > Lars Eighner > http://www.larseighner.com/index.html > 8800 N IH35 APT 1191 AUSTIN TX 78753-5266 > > ___ > 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" > yes it means python 2.5 most likely for cairo the py25 was not bumped to py26 ___ 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: make package broken for multimedia/gstreamer
On Sun, Aug 9, 2009 at 1:20 PM, Koop Mast wrote: > On Sun, 2009-08-09 at 18:19 +0200, Raphael Becker wrote: > > Hi there, > > > > is this just a local problem (cvsup failed) or is this a general > > problem with multimedia/gstreamer? > > > > TIA > > Raphael Becker > > Check your libtool and libltdl. You should have version 2.2.6(a) > installed. Read ports/UPDATING for more info about the libtool update. > > -Koop > > > > > [r...@freebsd /usr/ports/multimedia/gstreamer]# ls -la > > total 26 > > drwxr-xr-x3 root wheel 512 Aug 5 17:41 . > > drwxr-xr-x 307 root wheel 6656 Aug 7 21:41 .. > > -rw-r--r--1 root wheel 1746 Aug 5 17:41 Makefile > > -rw-r--r--1 root wheel 212 Aug 5 17:41 distinfo > > drwxr-xr-x2 root wheel 512 Aug 5 17:41 files > > -rw-r--r--1 root wheel 1057 Jul 15 2002 pkg-descr > > -rw-r--r--1 root wheel 7656 Aug 5 17:41 pkg-plist > > > > > > # make package > > [...] > > ===> Registering installation for gstreamer-0.10.24 > > ===> Building package for gstreamer-0.10.24 > > Creating package /usr/ports/packages/All/gstreamer-0.10.24.tbz > > Registering depends: gio-fam-backend-2.20.4 gamin-0.1.10_3 glib-2.20.4 > popt-1.14 gettext-0.17_1 libxml2-2.7.3 libiconv-1.13.1 libcheck-0.9.6 > libXv-1.0.4,1 libXext-1.0.5,1 libX11-1.2.1_1,1 libxcb-1.4 > libpthread-stubs-0.1 pcre-7.9 libXau-1.0.4 libXdmcp-1.0.2_1 xproto-7.0.15 > pkg-config-0.23_1 perl-threaded-5.8.9_3 xcb-proto-1.5 python26-2.6.2_1 > kbproto-1.0.3 videoproto-2.2.2 xextproto-7.0.5. > > Creating bzip'd tar ball in > '/usr/ports/packages/All/gstreamer-0.10.24.tbz' > > tar: lib/libgstbase-0.10.so.0: Cannot stat: No such file or directory > > tar: lib/libgstcheck-0.10.so.0: Cannot stat: No such file or directory > > tar: lib/libgstcontroller-0.10.so.0: Cannot stat: No such file or > directory > > tar: lib/libgstdataprotocol-0.10.so.0: Cannot stat: No such file or > directory > > tar: lib/libgstnet-0.10.so.0: Cannot stat: No such file or directory > > tar: lib/libgstreamer-0.10.so.0: Cannot stat: No such file or directory > > tar: Error exit delayed from previous errors. > > pkg_create: make_dist: tar command failed with code 256 > > *** Error code 1 > > > > Stop in /usr/ports/multimedia/gstreamer. > > > > > > # ls -la /usr/local/lib/libgst* > > -rw-r--r-- 1 root wheel 797764 Aug 9 18:11 > /usr/local/lib/libgstbase-0.10.a > > -rwxr-xr-x 1 root wheel 1167 Aug 9 18:11 /usr/local/lib/ > libgstbase-0.10.la > > lrwxr-xr-x 1 root wheel 21 Aug 9 18:11 /usr/local/lib/ > libgstbase-0.10.so -> libgstbase-0.10.so.21 > > -rwxr-xr-x 1 root wheel 562108 Aug 9 18:11 > /usr/local/lib/libgstbase-0.10.so.21 > > -rw-r--r-- 1 root wheel 103482 Aug 9 18:11 > /usr/local/lib/libgstcheck-0.10.a > > -rwxr-xr-x 1 root wheel 1201 Aug 9 18:11 /usr/local/lib/ > libgstcheck-0.10.la > > lrwxr-xr-x 1 root wheel 22 Aug 9 18:11 /usr/local/lib/ > libgstcheck-0.10.so -> libgstcheck-0.10.so.21 > > -rwxr-xr-x 1 root wheel75151 Aug 9 18:11 > /usr/local/lib/libgstcheck-0.10.so.21 > > -rw-r--r-- 1 root wheel 520480 Aug 9 18:11 > /usr/local/lib/libgstcontroller-0.10.a > > -rwxr-xr-x 1 root wheel 1209 Aug 9 18:11 /usr/local/lib/ > libgstcontroller-0.10.la > > lrwxr-xr-x 1 root wheel 27 Aug 9 18:11 /usr/local/lib/ > libgstcontroller-0.10.so -> libgstcontroller-0.10.so.21 > > -rwxr-xr-x 1 root wheel 398526 Aug 9 18:11 > /usr/local/lib/libgstcontroller-0.10.so.21 > > -rw-r--r-- 1 root wheel42652 Aug 9 18:11 > /usr/local/lib/libgstdataprotocol-0.10.a > > -rwxr-xr-x 1 root wheel 1223 Aug 9 18:11 /usr/local/lib/ > libgstdataprotocol-0.10.la > > lrwxr-xr-x 1 root wheel 29 Aug 9 18:11 /usr/local/lib/ > libgstdataprotocol-0.10.so -> libgstdataprotocol-0.10.so.21 > > -rwxr-xr-x 1 root wheel38512 Aug 9 18:11 > /usr/local/lib/libgstdataprotocol-0.10.so.21 > > -rw-r--r-- 1 root wheel88106 Aug 9 18:11 > /usr/local/lib/libgstnet-0.10.a > > -rwxr-xr-x 1 root wheel 1160 Aug 9 18:11 /usr/local/lib/ > libgstnet-0.10.la > > lrwxr-xr-x 1 root wheel 20 Aug 9 18:11 /usr/local/lib/ > libgstnet-0.10.so -> libgstnet-0.10.so.21 > > -rwxr-xr-x 1 root wheel64612 Aug 9 18:11 > /usr/local/lib/libgstnet-0.10.so.21 > > -rw-r--r-- 1 root wheel 3242574 Aug 9 18:11 > /usr/local/lib/libgstreamer-0.10.a > > -rwxr-xr-x 1 root wheel 1145 Aug 9 18:11 /usr/local/lib/ > libgstreamer-0.10.la > > lrwxr-xr-x 1 root wheel 23 Aug 9 18:11 /usr/local/lib/ > libgstreamer-0.10.so -> libgstreamer-0.10.so.21 > > -rwxr-xr-x 1 root wheel 2130698 Aug 9 18:11 > /usr/local/lib/libgstreamer-0.10.so.21 > > > > > > -- > > Raphael Beckerhttp://rabe.uugrn.org/ > > https://www.xing.com/profile/Raphael_Becker > > GnuPG:E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D > > .|.|.|.|.|.|.|.. > > > __
Re: [HEADUP] FreeBSD Gecko's TODO and plan for future
On Sat, Aug 22, 2009 at 2:22 PM, Martin Wilke wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Howdy Guys, > > The FreeBSD Gecko Team will let you know what the plans for > the future are and on what we are currently working. > > Goals: > * Removal of mozilla, nvu, xulrunner and firefox2. > * www/firefox35 should be moved to www/firefox. > * The options USE_GECKO mozilla nvu xulrunner and firefox will be also > removed. > > Background: > We have a lot of old stuff on the portstree and it's time to cleanup old > stuff. > * www/mozilla is 5 year old now, no longer supported by upstream, and > has many many vulnerabilities. We can use www/seamonkey. > > * www/nvu last official release was in 2005, no longer supported, and > also some vulnerabilities. We have www/kompozer which also need an > update to get this unbroken. > > * www/xulrunner is old and was replaced by www/libxul. We should not > hold any old Gecko stuff. Also it's not longer supported by upstream: > https://wiki.mozilla.org/XULRunner:Roadmap > > Problems which we have to solve: > Some Gnome ports need www/firefox to build and work, but unfortunately > firefox2 isn't longer supported by the Mozilla Foundation. Also > www/firefox has a lot of vulnerabilities. We should www/firefox > mark FORBIDDEN at this time gives no fixes for the latest securtiy > reports. > > We see here 2 ways: > 1) The Gnome Team (not the FreeBSD Gnome Team) take time and move all > his > stuff to libxul. > 2) or we the FreeBSD Team have to remove all these ports. We know > that's > really hard but we should not hold vulnerabilities stuff. > > We hope to get here a bit help from the FreeBSD Gnome Team to make it > possible to get some stuff to work with the current libxul version. > > Current Status: >We working currently on Firefox 3.6 (alpha1) [2], Thunderbird 3.0 > (beta3) [1], >new libxul 1.9.1.2. All 3 are already committed to our repo. > > [1] a screenshot from tb3 under FreeBSD > http://tmp.chruetertee.ch/tb3.0b3.png > [2] a screenshot from ff36 under FreeBSD > http://tmp.chruetertee.ch/ff36.png > > A current status can you find here: >https://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO > > > So that's all at the moment, Feedback, Comments are welcome. > > - - Martin for the FreeBSD Gecko Team > > > - -- > > +---+---+ > | PGP: 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | > | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | > +---+---+ > | Mess with the Best, Die like the Rest! | > +---+---+ > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.11 (FreeBSD) > > iEYEARECAAYFAkqQN08ACgkQdLJIhLHm/OlZ7wCgk6xG3ymevRMf1D/0e9LpEqZ4 > vF8An200XdohvNq3nptL4NCBIom+vgPN > =SlKU > -END PGP SIGNATURE- > ___ > freebsd-gn...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-gnome > To unsubscribe, send any mail to "freebsd-gnome-unsubscr...@freebsd.org" I just have one question when has xulrunner been unsupported upstream considering that xulrunner 1.9.1 was released when firefox 3.5.2 was teh last release of xulrunner 1.9.x alpha was august 22end yes it's development but it's still supported. upstream ___ 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: [HEADUP] FreeBSD Gecko's TODO and plan for future
On Sat, Aug 22, 2009 at 3:12 PM, J.-P. Klodzinski wrote: > matt donovan wrote: > > On Sat, Aug 22, 2009 at 2:22 PM, Martin Wilke wrote: > > > > Howdy Guys, > > > > The FreeBSD Gecko Team will let you know what the plans for > > the future are and on what we are currently working. > > > > Goals: > > * Removal of mozilla, nvu, xulrunner and firefox2. > > * www/firefox35 should be moved to www/firefox. > > * The options USE_GECKO mozilla nvu xulrunner and firefox will be also > > removed. > > > > Background: > > We have a lot of old stuff on the portstree and it's time to cleanup old > > stuff. > > * www/mozilla is 5 year old now, no longer supported by upstream, and > > has many many vulnerabilities. We can use www/seamonkey. > > > > * www/nvu last official release was in 2005, no longer supported, and > > also some vulnerabilities. We have www/kompozer which also need an > > update to get this unbroken. > > > > * www/xulrunner is old and was replaced by www/libxul. We should not > > hold any old Gecko stuff. Also it's not longer supported by > > upstream: > > https://wiki.mozilla.org/XULRunner:Roadmap > > > > Problems which we have to solve: > > Some Gnome ports need www/firefox to build and work, but unfortunately > > firefox2 isn't longer supported by the Mozilla Foundation. Also > > www/firefox has a lot of vulnerabilities. We should www/firefox > > mark FORBIDDEN at this time gives no fixes for the latest securtiy > > reports. > > > > We see here 2 ways: > > 1) The Gnome Team (not the FreeBSD Gnome Team) take time and move > all > > his > > stuff to libxul. > > 2) or we the FreeBSD Team have to remove all these ports. We know > > that's > > really hard but we should not hold vulnerabilities stuff. > > > > We hope to get here a bit help from the FreeBSD Gnome Team to make it > > possible to get some stuff to work with the current libxul version. > > > > Current Status: > >We working currently on Firefox 3.6 (alpha1) [2], Thunderbird 3.0 > > (beta3) [1], > >new libxul 1.9.1.2. All 3 are already committed to our repo. > > > > [1] a screenshot from tb3 under FreeBSD > > http://tmp.chruetertee.ch/tb3.0b3.png > > [2] a screenshot from ff36 under FreeBSD > > http://tmp.chruetertee.ch/ff36.png > > > > A current status can you find here: > >https://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO > > > > > > So that's all at the moment, Feedback, Comments are welcome. > > > > - Martin for the FreeBSD Gecko Team > > > > > ___ > freebsd-gn...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-gnome > To unsubscribe, send any mail to "freebsd-gnome-unsubscr...@freebsd.org" > > > I just have one question when has xulrunner been unsupported upstream > > considering that xulrunner 1.9.1 was released when firefox 3.5.2 was teh > > last release of xulrunner 1.9.x alpha was august 22end yes it's > development > > but it's still supported. upstream > > ___ > > 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" > > > Hi, > > I think he means www/xulrunner, based on 1.8.0 > (http://www.freshports.org/www/xulrunner/) is no longer supported und > should get removed from the tree. > Your mentioned xulrunner 1.9.x is still supported and inside the > ports-tree under www/libxul, which will not get removed. > (http://www.freshports.org/www/libxul/) > > /BR > > Ah ok since I know that libxul is a single library. hence why I got a bit confused since I knew xulrunner is still supported jsut not 1.8.x ___ 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: [HEADUP] FreeBSD Gecko's TODO and plan for future
On Sat, Aug 22, 2009 at 5:35 PM, Jeremy Messenger wrote: > On Sat, 22 Aug 2009 15:52:43 -0500, wrote: > > Martin Wilke wrote: >> >>> Background: >>> We have a lot of old stuff on the portstree and it's time >>> to cleanup old stuff. >>> >> ... >> >>> * www/nvu last official release was in 2005, no longer >>> supported, and also some vulnerabilities. We have >>> www/kompozer which also need an update to get this >>> unbroken. >>> >> ... >> >>> Problems which we have to solve: >>> Some Gnome ports need www/firefox to build and work, >>> but unfortunately firefox2 isn't longer supported by >>> the Mozilla Foundation. >>> >> >> So, if I am understanding this correctly, it's proposed to >> replace nvu with an updated kompozer, which to judge from >> the name is part of KDE. Thus Gnome acquires a dependency >> on KDE by way of firefox/gecko? This does not seem like a >> Good Thing (TM). >> > > Why don't you check what kompozer is first? ;-) > > Cheers, > Mezz > > > -- > me...@cox.net - m...@freebsd.org > FreeBSD GNOME Team > http://www.FreeBSD.org/gnome/ - gn...@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" > kompozer is NVU KompoZer is an unoffical bugfix/update aka a fork ___ 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: freebsd-ports Digest, Vol 341, Issue 7
On Sunday 06 Dec 2009 00:00:03 freebsd-ports-requ...@freebsd.org wrote:
> > An option WITH_LIBUSB was added to the cups-base/Makefile. That's
> > probably what Dirk meant.
>
> Thanks for the explanation, Gary. I have it set with make config but
> just hardcoded it into the Makefile and am recompiling but I doubt it
> will change but there is still hope. ;)
The attached patch works on 8.0-RELEASE for me, restoring the non-libusb
functionality. Leave the libusb option disabled and just compile as normal.
--
Matt Dawson
MTD15-RIPE
m...@chronos.org.uk
--- ./ports/print/cups-base/Makefile.orig 2009-12-06 11:02:46.0 +
+++ ./ports/print/cups-base/Makefile 2009-12-06 11:09:36.0 +
@@ -175,6 +175,8 @@
.if !defined(CUPS_CLIENT) && !defined(CUPS_IMAGE) && defined(WITH_LIBUSB)
LIB_DEPENDS+= usb:${PORTSDIR}/devel/libusb
+.else
+CONFIGURE_ARGS+= --disable-libusb
.endif
.if defined(CUPS_CLIENT)
___
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: The new cups ports seem to not recognize usb printers on FreeBSD 7.2-STABLE
On Sunday 06 Dec 2009 11:17:52 you wrote: > On Sunday 06 Dec 2009 00:00:03 freebsd-ports-requ...@freebsd.org wrote: > > > An option WITH_LIBUSB was added to the cups-base/Makefile. That's > > > probably what Dirk meant. > > > > Thanks for the explanation, Gary. I have it set with make config but > > just hardcoded it into the Makefile and am recompiling but I doubt it > > will change but there is still hope. ;) > > The attached patch works on 8.0-RELEASE for me, restoring the non-libusb > functionality. Leave the libusb option disabled and just compile as > normal. > Gah, sorry about the subject line. Won't happen again. -- Matt Dawson MTD15-RIPE m...@chronos.org.uk signature.asc Description: This is a digitally signed message part.
Re: The new cups ports seem to not recognize usb printers on FreeBSD 7.2-STABLE
On Sunday 06 Dec 2009 12:00:23 freebsd-ports-requ...@freebsd.org wrote:
> On Sunday 06 Dec 2009 00:00:03 freebsd-ports-requ...@freebsd.org wrote:
> > > An option WITH_LIBUSB was added to the cups-base/Makefile. That's
> > > probably what Dirk meant.
> >
> >
> > Thanks for the explanation, Gary. I have it set with make config
> > but just hardcoded it into the Makefile and am recompiling but I
> > doubt it will change but there is still hope. ;)
>
> The attached patch works on 8.0-RELEASE for me, restoring the
> non-libusb functionality. Leave the libusb option disabled and just
> compile as normal.
The attached couple of patches fix this port in all cases, tested with
tinderbox. Since libusb is in base for FBSD>8 it needs handling
differently. Note well that if you use libusb, you need to NOT attach the
ulpt* driver to the device, i.e. remove ulpt from your kernel or don't load
it at boot.
Also fixed is the CUPS_OVERWRITE_BASE case deinstall, restoring the correct
permissions to lp and friends.
--
Matt Dawson
MTD15-RIPE
m...@chronos.org.uk
--- ./ports/print/cups-base/Makefile.orig 2009-12-06 11:02:46.0 +
+++ ./ports/print/cups-base/Makefile 2009-12-06 12:21:21.0 +
@@ -173,8 +173,13 @@
RUN_DEPENDS+= xdg-open:${PORTSDIR}/devel/xdg-utils
.endif
-.if !defined(CUPS_CLIENT) && !defined(CUPS_IMAGE) && defined(WITH_LIBUSB)
+.if !defined(CUPS_CLIENT) && !defined(CUPS_IMAGE) && defined(WITH_LIBUSB) && ${OSVERSION}>80
+CPPFLAGS+= -I/usr/include
+LDFLAGS+= -L/usr/lib
+.elif !defined(CUPS_CLIENT) && !defined(CUPS_IMAGE) && defined(WITH_LIBUSB) && ${OSVERSION}<79
LIB_DEPENDS+= usb:${PORTSDIR}/devel/libusb
+.else
+CONFIGURE_ARGS+= --disable-libusb
.endif
.if defined(CUPS_CLIENT)
--- ./ports/print/cups-base/pkg-plist.orig 2009-12-06 12:23:00.0 +
+++ ./ports/print/cups-base/pkg-plist 2009-12-06 12:24:18.0 +
@@ -20,6 +20,11 @@
%%overwrit...@exec if test -e /usr/bin/lpr; then chmod -h 0 /usr/bin/lpr; fi
%%overwrit...@exec if test -e /usr/bin/lprm; then chmod -h 0 /usr/bin/lprm; fi
%%overwrit...@exec if test -e /usr/sbin/lpc; then chmod -h 0 /usr/sbin/lpc; fi
+%%overwrit...@unexec if test -e /usr/bin/lp; then chmod -h 0555 /usr/bin/lp; fi
+%%overwrit...@unexec if test -e /usr/bin/lpq; then chmod -h 06555 /usr/bin/lpq; fi
+%%overwrit...@unexec if test -e /usr/bin/lpr; then chmod -h 06555 /usr/bin/lpr; fi
+%%overwrit...@unexec if test -e /usr/bin/lprm; then chmod -h 06555 /usr/bin/lprm; fi
+%%overwrit...@unexec if test -e /usr/sbin/lpc; then chmod -h 02555 /usr/sbin/lpc; fi
@unexec if cmp -s %D/etc/cups/cupsd.conf.N %D/etc/cups/cupsd.conf; then rm -f %D/etc/cups/cupsd.conf; fi
etc/cups/cupsd.conf.N
@exec if test ! -f %D/etc/cups/cupsd.conf; then cp -p %D/etc/cups/cupsd.conf.N %D/etc/cups/cupsd.conf; fi
signature.asc
Description: This is a digitally signed message part.
Re: security/openssl BROKEN, DEPRECATED, and EXPIRED?
On Wednesday 13 Jan 2010 12:00:23 Trix Farrar wrote: > What happened? I haven't been able to find any discussion about this > on either freebsd-ports, freebsd-ports-bugs, or freebsd-security. > There doesn't seem to be a PR, either. > > Am I just being overly sensitive or does this present a POLA problem? > My ports tree is up to date, but OpenSSL can't be upgraded, and > neither can anything that depends on it. If you have a look at the last commit for Mk/bsd.openssl.mk, you'll see the libcrypto versions have been bumped, too. 8.0-RELEASE has 0.9.8k in base, but this .mk looks for libcrypto.so.7 and the version conditional has been dropped (not that it would have made any difference set to 800105) so dropping back to the version in the base system is going to be no help either. Even HEAD is still on 0.9.8k (libcrypto.so.6). http://bit.ly/7h5PpU (CVSweb) I suspect that there's an update on its way, although that doesn't help the rest of us using ports in the meantime. For now, I'd personally recommend to use a date=2010.01.12.15.42.00 definition in your ports supfile until all of this shakes out. As for POLA, I can think of nothing more astonishing than finding that my systems cannot, under any circumstances, meet the requirements of bsd.openssl.mk, thus breaking nearly everything important. That sort of snuck up on me without warning... -- Matt Dawson MTD15-RIPE m...@chronos.org.uk signature.asc Description: This is a digitally signed message part.
Re: security/openssl BROKEN, DEPRECATED, and EXPIRED?
On Wednesday 13 Jan 2010 13:34:29 I wrote: > I suspect that there's an update on its way, although that doesn't help > the rest of us using ports in the meantime. For now, I'd personally > recommend to use a date=2010.01.12.15.42.00 definition in your ports > supfile until all of this shakes out. And, just like magic, it's fixed with a commit at 13:30 UTC. Disregard the above. -- Matt Dawson MTD15-RIPE m...@chronos.org.uk signature.asc Description: This is a digitally signed message part.
Re: postfix-2.6.5 on freebsd 8.0-release
On Mon, Jan 18, 2010 at 2:17 PM, Lucas Reddinger wrote: > Hello, > > Upon the installation (``pkg_add -r'') of postfix, I was asked, as > usual, to disable some daily routines. > > > And you can disable some sendmail specific daily maintenance routines in > your > > /etc/periodic.conf file: > > > > daily_clean_hoststat_enable="NO" > > daily_status_mail_rejects_enable="NO" > > daily_status_include_submit_mailq="NO" > > daily_submit_queuerun="NO" > > However, on Freebsd 8.0 release, ``/etc/periodic.conf'' does not > exist. I believe that the contents of ``/etc/periodic/daily'' are > relevant here. > > What is the preferred method of performing these actions now? Create the file /etc/periodic.conf and add those assignments to it. Matt > ___ 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: sysutils/cfs
On 09/07/11 17:04, Chris Rees wrote: >> The /new/ policy of removing ports for much lighter offenses, such as > having vulnerabilities, has already caused so many objections, that it is > time to abolish it. > > I consider the argument here dead; portmgr is reviewing the policy as Erwin > has said. > > However... I find it deeply troubling that you consider buildability more > important than security fixes. Are you actually serious? Changing to a hypothetical example, why would an Apache vulnerability in mod_rewrite in the least bit bother a person who doesn't have the module enabled, which I believe is the standard configuration? Would you prefer Apache be deleted from ports if it took longer than expected to fix it? I've still got non-networked FreeBSD 4.x laptops running with a version of Minicom that for a year or so was FORBIDDEN because it had a local root vulnerability. What's so wrong about that? I'm glad the port wasn't deleted because I still install and use Minicom today. What the current FreeBSD policy of actively deleting perfectly usable ports instead of putting a mild hurdle in the way is saying, is that FreeBSD will stop me doing what I may want to do because FreeBSD knows best. I want machines, tools, to do as *I* say not the other way round, whether it's good for me or not. If I wanted nannying and interference, I'd install Ubuntu. ___ 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: sysutils/cfs
On 09/08/11 17:54, Matthias Andree wrote: > The port isn't perfectly usable (because that would mean it's usable in > all circumstances for all advertised purposes, which is explicitly not > the case in the light of known vulnerabilities). In British Engligh at least, "perfectly" can mean "adequately" e.g. A scaffold pole and a short wall is a perfectly usable jack for changing a car tyre. Apologies. However, it is still the case that software with known security vulnerabilities is almost always still usable for the most part. If the kernel had a flaw which took someone with a username exactly 17 characters long to have UID 0, would you refuse to, or be unable to use the operating system until it's fixed? What if I mentioned FreeBSD has a 16-character hard-coded limit on usernames? > Nobody stands there pointing a gun at your head and forces you to > uninstall a port that got removed from the ports/ tree. If someone deletes a package I use from ports, they are FORCING me to jump through an awful load of hoops to get what I want/need. Let's look at the subject of this thread: What happens if I'm a CFS user and my hard disk dies? I install the latest release, pull my backups back in, and find that the FreeBSD people have decided they don't want me to be able to access my encrypted data any more. What do I do? Attempt to compile CFS from vendor source? Waste time trying to re-make a port? Install the ports tree from a FreeBSD6.1 CD I have lying around? Just install some other OS? What exactly is the administrative overhead of having a FORBIDDEN, etc port in the tree if it compiles, works, and people are happy to use it regardless of its flaws? ___ 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: Update on ports on 10.0
On Oct 11, 2011 5:07 PM, "Erwin Lansing" wrote: > > Since the release has been pushed back some more since the last mail, we > do have some time to test a possible fix for the issues we're seeing > with libtool on FreeBSD 10.0. [snip] > to move forward. Other options include the big find/grep/awk solution > that has been posted several times and fiddling with uname to go to > FreeBSD 9.99 for a while, while ports can be fixed. I would vote for a prominent message in the places people who run -CURRENT are meant to pay attention to (this mailing list and UPDATING and the ports equivalents). The message should point people to a web site (wiki?) with the latest news on how to report and provide patches for fixes with guidance on typical solutions. After all, this is -CURRENT and it's users are meant to be contributing fixes and are not expected to require their hands to be held. This I believe would be a good method to leverage the community so as to distribute the fixup problem. In particular the hack of 9.99 is likely to cause more problems and should be avoided. My 2¢ ___ 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: Can't compile kde4 and kdelibs4 with an uptodate amd64 Releng machine. (
On Monday 21 Nov 2011 16:09:45 Conrad J. Sabatier wrote: > On Mon, 21 Nov 2011 07:42:43 -0600 > > eculp wrote: > > I have tried building both from the different ports and even more > > using portmaster and all stop ate similar locations in kdelabs4. > > Maybe there is something that I should or could build first. > > > > Thanks, > > > > ed > > > > errors follow: > > > > kdelibs stops here: > > > > Generating kurlnavigator.moc > > Generating moc_kdiroperatordetailview_p.cpp > > [ 1%] Built target kfile_automoc > > Scanning dependencies of target kdeinit_kconf_update_automoc > > Scanning dependencies of target docbookl10nhelper_automoc > > [ 1%] Built target kdeinit_kconf_update_automoc > > [ 1%] Built target docbookl10nhelper_automoc > > Scanning dependencies of target genshortcutents_automoc > > Scanning dependencies of target kio_ghelp_automoc > > [ 1%] Built target genshortcutents_automoc > > [ 1%] Built target kio_ghelp_automoc > > Scanning dependencies of target kio_help_automoc > > Scanning dependencies of target meinproc4_automoc > > [ 1%] Built target kio_help_automoc > > [ 1%] Built target meinproc4_automoc > > Scanning dependencies of target meinproc4_simple_automoc > > Scanning dependencies of target kio_file_automoc > > [ 1%] Built target meinproc4_simple_automoc > > > > kdepimlibs4 stops here: > > > > Scanning dependencies of target kimg_pcx_automoc > > Scanning dependencies of target kimg_pic_automoc > > [ 1%] Built target kimg_pcx_automoc > > [ 1%] Built target kimg_pic_automoc > > Scanning dependencies of target kimg_psd_automoc > > Scanning dependencies of target kimg_ras_automoc > > [ 1%] Built target kimg_psd_automoc > > [ 1%] Built target kimg_ras_automoc > > Scanning dependencies of target kimg_rgb_automoc > > Scanning dependencies of target kimg_tga_automoc > > [ 1%] Built target kimg_rgb_automoc > > [ 1%] Built target kimg_tga_automoc > > Scanning dependencies of target kimg_xcf_automoc > > Scanning dependencies of target kimg_xview_automoc > > [ 1%] Built target kimg_xview_automoc > > [ 1%] Built target kimg_xcf_automoc > > Scanning dependencies of target kdnssd_automoc > > Scanning dependencies of target krosscore_automoc > > Generating interpreter.moc > > Generating script.moc > > Generating action.moc > > Generating actioncollection.moc > > Generating manager.moc > > [ 1%] Built target krosscore_automoc > > So where are the errors? There are none in the output you posted. Tinderbox logs of the same problem: https://chronos.org.uk/tb/errors/8-amd64-Desktop/kdelibs-4.7.3.log By selectively changing MAKE_JOBS_SAFE to MAKE_JOBS_UNSAFE in the Makefiles I can compile most of KDE-SC barring kdeplasma-addons. This is from a pristine ports tree updated yesterday with no modifications. Fails consistently on kdelibs4, but in different places each time. @eculp: Is your machine SMP? This tinderbox is a quad core MP box. -- Matt Dawson MTD15-RIPE m...@chronos.org.uk ___ 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: test
sorry ignore this wrong email address On Fri, Jun 17, 2011 at 8:33 PM, matt donovan wrote: > test > > -- > Technological progress is like an ax in the hands of a pathological > criminal. > -*Albert Einstein > > Breadth of Unix experience and depth of knowledge in the world of servers. > > * > > -- Technological progress is like an ax in the hands of a pathological criminal. -*Albert Einstein Breadth of Unix experience and depth of knowledge in the world of servers. * ___ 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: Limitations of Ports System
On Friday 14 Dec 2007, [EMAIL PROTECTED] wrote: > I was not planning to skimp on the requirements at all but the test > case is xorg. A far better test case, IMHO, would be to run a similar build to the pointyhat cluster if you're serious about *replacing* the ports system. Unless a new system can do this, as well as being able to produce packages for a centralised port build system for multiple machines (yes, you can do this with NFS and a little thought), the metaphor "snowball in hell" springs to mind. The job you've given yourself is an elephant. I'll leave it up to others to decide if it's white or just too large to eat on your own all at once. Furthermore, if said elephant isn't consumed in its entirety, expect some resistance to your proof of concept code from some unexpected sources since the ports system isn't just the package management system some people seem to think it is. Looking at all this from a user's perspective is fine and dandy until you have a release to do. The ports are tied into bits of the base system in various ways, for example, make release or USE_OPENSSL=base. The current system, although appearing to drip with legacy methods and what look like arcane rituals to appease the make god (until you understand how it all fits together), is very powerful - perhaps more so than any other package managment system I've ever used - and is structured to work for end users, the release engineering and ports management teams. I suspect this is why so many @FreeBSD.org replies were negative. I don't wish to rock the boat and start another 8 kids 1 toy discourse and there is certainly no malice or insult intended, but the ports system is so much more than getting X installed on a desktop box. First and foremost, release engineering depends on it. Change can be good, but always remember the alternate definition of progress: Taking the best of what you have. And ruining it. -- Matt Dawson. [EMAIL PROTECTED] MTD15-RIPE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
palm/pdbc
I've just tried to fix the checksum error but for some reason the SHA256 sum does no match even though the MD5 one does. But since this is no longer being developed that I have found since the author's site can no longer be found. you can probably remove this or I can keep trying to fix the checksum problem. Since the port is a bit out of date at least by time ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD not so free anymore ? Long live FreeBSD...
On Sat, 16 Jun 2012 12:00:47 + (UTC) Jerry wrote: > So, are you implying that ALSA (Advanced Linux Sound Architecture) > is never going to happen on a FreeBSD system? Our OSS sound subsystem works (and allows multiple access) without twenty different sound servers, mixers, shim layers and much faffing about, which is how we like it. So no, it's very unlikely we the users are going to put up with some putz wanting to swap that for something that only works when the planets are in the correct alignment after the use of some mystical incantation and the ritual sacrifice of a gnu just to get Skype (which is now owned by MS and is also now a conduit for yet more advertising) going. Sound is one of the things FreeBSD gets very right and most reasonably portable applications are just fine with our implementation of it. There's a compat port for those who want/need the ALSA API. -- Matt Dawson MTD15-RIPE GW0VNR signature.asc Description: PGP signature
Re: sysutils/conky Configure Options in Makefile
On 08/28/12 21:41, Jamie Paul Griffin wrote: > I have installed conky for use with my wm which is Spectrwm. However, > looking in the conky Makefile one of the configure options has been > disabled, tcp monitoring (--disable-portmon), which is a feature i'd > quite like to have available. Is there a reason the maintainer has > disabled this option, perhaps due to security or incompatibility, etc., > that anyone knows of? It appears to be disabled in the port Makefile because Conky's configure script says it's not supported on FreeBSD. cd /usr/ports/*/conky make clean patch vi Makefile - remove the --disable-portmon vi work/conky*/configure - change xLinux to xFreeBSD at line 14043 make Dunno if it actually works, but it does build, albeit with a warning for me: cc -DHAVE_CONFIG_H -I. -DSYSTEM_CONFIG_FILE=\"/usr/local/etc/conky/conky.conf\" -DPACKAGE_LIBDIR=\"/usr/local/lib/conky\" -I/usr/local/include -I/usr/local/include -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -I/usr/local/include/glib-2.0 -D_REENTRANT -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/freetype2-I/usr/local/include/lua51 -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include/freetype2 -I/usr/local/include/glib-2.0 -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include -Wall -W -O2 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -MT conky-llua.o -MD -MP -MF .deps/conky-llua.Tpo -c -o conky-llua.o `test -f 'llua.c' || echo './'`llua.c llua.c:43:1: warning: "MIN" redefined In file included from /usr/local/include/glib-2.0/glibconfig.h:9, from /usr/local/include/glib-2.0/glib/gtypes.h:34, from /usr/local/include/glib-2.0/glib/galloca.h:34, from /usr/local/include/glib-2.0/glib.h:32, from libtcp-portmon.h:38, from tcp-portmon.h:25, from conky.h:112, from llua.c:25: /usr/local/include/glib-2.0/glib/gmacros.h:201:1: warning: this is the location of the previous definition The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.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"
pkgng questions
1. How do I get pkg to use packages built against 9.1-RC1? VirtualBox is playing up (no ethernet, unkillable crashes, etc) and I suspect it's the kernel module... 2. Is there a list of ports like nvidia-driver, nspluginwrapper, linux-f10-flashplugin, sampleicc (dependency of libreoffice!) which aren't in pkgng? 2a. How do I install libreoffice when a dependency isn't in pkgng? 3. How do I force pkg to install/upgrade a single package, regardless of dependencies being out of date? 4. How do I get poudiere to build against a local src/obj tree, or a zfs snapshot of a pre-built jail, instead of 9.0-RELEASE? 5. How do I get poudiere to build against the packages a pkgng client will use instead of building everything for itself? It might help to reduce the discrepancy between the 30 secs it takes to rebuild sysutils/conky from ports on my desktop, and the >1hour it takes poudiere on a hefty server to download+build X and all its dependencies 6. Is pkgng really replacing base when poudiere requires ZFS? How will ports work if pkg_* are gone? Seriously, shouldn't ports at least be able to work with pkgng, and the default FreeBSD install be to a ZFS root before people are stuffed with the "wrong" choices (UFS) they made? 7. How do I configure pkg to use packages from a certain historical release? I need my servers to be identical software-wise regardless of when I install them. In other words, I DON'T want the latest versions. 8. Is there a pkgng equivalent of 'ls -lt /var/db/pkg' without firing up sqlite? 9. Why didn't pkg upgrade tell me it replaced my custom-built packages? I'd have liked for it to not break stuff when /var/db/ports/*/options differed from the options I can see pkgng keeps in its metadata... -- The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.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: pkgng questions
On 08/30/12 13:01, Mark Felder wrote: > I think you're very confused about what pkgng is for. At this time, ports > are STILL the recommended way to install things and keep them up to date. Really? I think the last time I compiled X or a web browser (until using poudriere) was about 10 years ago. > Pkgng is the first step required for us to get a better package management > system so we can shift the community towards primarily using packages. I like packages - they save me compiling massive things on my desktop and they let me keep my servers running exactly the same software built from our CI setup. 'make package' is so quick and easy, it'd be hard to beat. So I thought I'd get a grip on pkgng before pkg_* disappears from base. I had a couple of questions I wanted to answer - 1) How easy does it make keeping my desktop (currently releng/9.1 built with dtrace) up-to-date 2) How much easier will it be to maintain production and testing servers? The answer has made me start downloading an OpenIndiana iso. >> 2. Is there a list of ports like nvidia-driver, nspluginwrapper, >> linux-f10-flashplugin, sampleicc (dependency of libreoffice!) which aren't >> in pkgng? > > Everything can be built into the pkgng format except a few ports that need > workarounds. There's a list on the wiki. > > http://wiki.freebsd.org/pkgng > > Go to the bottom "Known Failures" section. I don't see any of the examples I gave listed, apart from nvidia-driver >> 3. How do I force pkg to install/upgrade a single package, regardless of >> dependencies being out of date? > > You should never try to do this anyway; you'll end up with packages built > against the wrong versions of libraries. You're suggesting that I should upgrade an entire machine which may have proven itself over a period of years to be perfectly stable, just because I need a small utility which really doesn't care about the man page typo which caused gettext-0.1.2_3 to change to gettext-0.1.2_4? >> 4. How do I get poudiere to build against a local src/obj tree, or a zfs >> snapshot of a pre-built jail, instead of 9.0-RELEASE? > > The poudriere man page has all the instructions needed to create jails of > any release version to be used for building packages. No, the man page doesn't mention anything about specifying where to pull the distribution from, only what method of access to use. > You don't do it this way. You build everything on your poudriere server and > push all of your packages to the client. You do this every single time. If > you decide you want a new package on your client, you build it on your > poudriere server and have your client request it. If you're using > poudriere/pkgng, your clients should NEVER be compiling ports or installing > packages outside of what your poudriere server is providing. Poudriere is > giving you a "cleanroom" environment where it can guarantee that all the > packages and their required packages/libraries are sane. > Pkgng doesn't require ZFS -- poudriere does. Your clients should never have > poudriere. I am confused. If pkg_* are removed, how is a person with a single desktop machine (worst case, a netbook) expected to operate if they need a specific port build? Are they to spend a week compiling 1000+ ports themselves in a poudriere VM? Or is the flexibility of FreeBSD ports just not deemed to be useful to the end user (or person unable to provide a dedicated any more? >> 8. Is there a pkgng equivalent of 'ls -lt /var/db/pkg' without firing up >> sqlite? > > Are you looking for the date column (not sure why that's useful as it can > change due to many things)? Doesn't "pkg info -a" suffice? 'ls -lt /var/db/pkg' will show me what packages were installed sorted by day. It is very useful on servers which aren't routinely upgraded to the latest and greatest untested versions >> 9. Why didn't pkg upgrade tell me it replaced my custom-built packages? I'd >> have liked for it to not break stuff when /var/db/ports/*/options differed >> from the options I can see pkgng keeps in its metadata... > > Your poudriere server can use you preferred options when it builds > packages. Check the man page. pkg2ng doesn't tell you that you're about to need another machine $ man pkg2ng No manual entry for pkg2ng > Long story short: poudriere is a tool for you to build your OWN private > package repositories (which is really handy!). It is handy IF you have the resources to maintain a poudriere machine. It is handy IF you really enjoy waiting for x.org and web browsers to compile It is NOT handy if you just want to build one package to be built with different options. In fact it makes a mockery of FreeBSD's ease of use. > Pkgng is just the first step towards a large goal of greatly improving > the enduser experience with FreeBSD. By "improving", you mean "removing flexibility from"? > I don't believe pkgng is default on any release yet, so you > shouldn't be using public pkgng repositories for anythi
[NEW PORT] net-p2p/lidarr: Music collection manager for Usenet and BitTorrent users
Hi all, My apologies if this is not the correct place to post this. Would a committer be available to review this New Port request? portlint and testport are OK. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234233 Regards, Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
devel/lua-sysctl broken with clang (patch)
===> Building for lua-sysctl-0.2
install -m 755 -d sysctl
cc -shared -soname lua_sysctl -O2 -pipe -fno-omit-frame-pointer
-fno-strict-aliasing -fno-omit-frame-pointer -Wall -Wextra -fPIC
`pkg-config --cflags lua-5.1` -o sysctl/core.so src/lua_sysctl.c
cc: error: no such file or directory: 'lua_sysctl'
*** [sysctl/core.so] Error code 1
Stop in /usr/ports/devel/lua-sysctl/work/lua-syscl-0.2.
*** [do-build] Error code 1
This fixes it:
--- Makefile.orig 2013-01-23 12:05:52.459795869 +
+++ Makefile2013-01-23 12:08:13.371029152 +
@@ -2,7 +2,7 @@
SODIR = sysctl
SOLIB = ${SODIR}/core.so
-LDFLAGS += -shared -soname ${SONAME}
+LDFLAGS += -shared -Wl,-soname,${SONAME}
CFLAGS += -Wall -Wextra -fPIC `pkg-config --cflags lua-5.1`
all: ${SOLIB}
--
Sorry for the following...
The information contained in this message is confidential and intended for the
addressee only. If you have received this message in error, or there are any
problems with its content, please contact the sender.
iCritical is a trading name of Critical Software Ltd. Registered in England:
04909220.
Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH.
This message has been scanned for security threats by iCritical.
www.icritical.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"
No Response to Port Submission
Hello, I have submitted http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174620 to update the Postgis port from version 1.5.3 to 2.0.2 to work with Postgres 9.2. The original port maintainer has been unresponsive and I have tried to contact the person that was assigned this from FreeBSD and he has also been unresponsive. This port as it stands is slated to be deleted from the ports tree at the end of this month. I understand that there is a 3 month timeout on port maintainers, but with it being slated for removal from the ports tree and the unresponsiveness from the original maintainer if someone could take a look at this and move it along in the process or provide me the feedback that I need to get this moving forward. I would also like to note that there are several other PRs that are awaiting feedback from the original maintainer that are older than the one I submitted. Other PRs Awaiting original Maintainer Feedback http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/167955 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/171849 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174764 Thanks, Matthew Trisoline, System Engineer matt.trisol...@intermedix.com http://www.intermedix.com The information contained in this message is confidential and may be privileged and/or protected under law. If you received this message in error, please notify us immediately by forwarding a copy to complia...@intermedix.com and then deleting the original message and any attachments. ___ 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: No Response to Port Submission
Hi Olli, I have updated the PR with an updated diff in the appropriate formate. I would also be interested in becoming a maintainer of the port. Thanks, Matthew Trisoline, System Engineer matt.trisol...@intermedix.com http://www.intermedix.com The information contained in this message is confidential and may be privileged and/or protected under law. If you received this message in error, please notify us immediately by forwarding a copy to complia...@intermedix.com and then deleting the original message and any attachments. From: owner-freebsd-po...@freebsd.org [owner-freebsd-po...@freebsd.org] On Behalf Of Michael Gmelin [free...@grem.de] Sent: Wednesday, January 23, 2013 14:09 To: freebsd-ports@freebsd.org Subject: Re: No Response to Port Submission On Wed, 23 Jan 2013 19:56:20 +0100 olli hauer wrote: > On 2013-01-23 17:34, Trisoline, Matt wrote: > > Hello, > > > > I have submitted > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174620 to update > > the Postgis port from version 1.5.3 to 2.0.2 to work with Postgres > > 9.2. The original port maintainer has been unresponsive and I have > > tried to contact the person that was assigned this from FreeBSD and > > he has also been unresponsive. This port as it stands is slated to > > be deleted from the ports tree at the end of this month. I > > understand that there is a 3 month timeout on port maintainers, but > > with it being slated for removal from the ports tree and the > > unresponsiveness from the original maintainer if someone could take > > a look at this and move it along in the process or provide me the > > feedback that I need to get this moving forward. I would also like > > to note that there are several other PRs that are awaiting feedback > > from the original maintainer that are older than the one I > > submitted. > > > > Other PRs Awaiting original Maintainer Feedback > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/167955 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/171849 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174764 > > > > Thanks, > > > > Hi Matthew, > > Are you interested in become the maintainer for postgis? > I think this can be arranged. > > Also could you please update your PR 174620 with a patch taken in the > opposite order diff -u $orig $new (instead $new $orig) > else it is hard handwork to apply your patch. By "hard work" you mean using "patch -R" when applying it? (see man patch) and look for reverse Just sayin'... ;) > > -- > Regards, > olli > ___ > 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" -- Michael Gmelin ___ 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: SPAM: Re: No Response to Port Submission
I updated the PR with the pkg-plist diff Matthew Trisoline, System Engineer matt.trisol...@intermedix.com http://www.intermedix.com The information contained in this message is confidential and may be privileged and/or protected under law. If you received this message in error, please notify us immediately by forwarding a copy to complia...@intermedix.com and then deleting the original message and any attachments. From: olli hauer [oha...@gmx.de] Sent: Wednesday, January 23, 2013 14:45 To: freebsd-ports@freebsd.org Cc: Trisoline, Matt Subject: SPAM: Re: No Response to Port Submission On 2013-01-23 20:21, Trisoline, Matt wrote: > Hi Olli, > > I have updated the PR with an updated diff in the appropriate formate. I > would also be interested in becoming a maintainer of the port. > > Thanks, Hi Matthew, can you also provide your patches against the files dir? I just recognize your patch was shaped against a portsnap tree, therfore my first try against a svn tree failed. I can try to build the port on 8.3/9.1 (amd64) and if it builds commit your work and transfer maintainer to you. -- Regards, olli > > Matthew Trisoline, System Engineer > matt.trisol...@intermedix.com > http://www.intermedix.com > > The information contained in this message is confidential and may be > privileged and/or protected under law. If you received this message in > error, please notify us immediately by forwarding a copy to > complia...@intermedix.com and then deleting the original message and > any attachments. > > From: owner-freebsd-po...@freebsd.org [owner-freebsd-po...@freebsd.org] On > Behalf Of Michael Gmelin [free...@grem.de] > Sent: Wednesday, January 23, 2013 14:09 > To: freebsd-ports@freebsd.org > Subject: Re: No Response to Port Submission > > On Wed, 23 Jan 2013 19:56:20 +0100 > olli hauer wrote: > >> On 2013-01-23 17:34, Trisoline, Matt wrote: >>> Hello, >>> >>> I have submitted >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174620 to update >>> the Postgis port from version 1.5.3 to 2.0.2 to work with Postgres >>> 9.2. The original port maintainer has been unresponsive and I have >>> tried to contact the person that was assigned this from FreeBSD and >>> he has also been unresponsive. This port as it stands is slated to >>> be deleted from the ports tree at the end of this month. I >>> understand that there is a 3 month timeout on port maintainers, but >>> with it being slated for removal from the ports tree and the >>> unresponsiveness from the original maintainer if someone could take >>> a look at this and move it along in the process or provide me the >>> feedback that I need to get this moving forward. I would also like >>> to note that there are several other PRs that are awaiting feedback >>> from the original maintainer that are older than the one I >>> submitted. >>> >>> Other PRs Awaiting original Maintainer Feedback >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/167955 >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/171849 >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174764 >>> >>> Thanks, >>> >> >> Hi Matthew, >> >> Are you interested in become the maintainer for postgis? >> I think this can be arranged. >> >> Also could you please update your PR 174620 with a patch taken in the >> opposite order diff -u $orig $new (instead $new $orig) >> else it is hard handwork to apply your patch. > > By "hard work" you mean using "patch -R" when applying it? > (see man patch) and look for reverse > > Just sayin'... ;) > >> >> -- >> Regards, >> olli >> ___ >> 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"
Strange Package Configuration?
I recently was upgrading my FreeBSD systems, both host systems and jails, and all of a sudden came across a problem in the jail environments where it was attempting to create a package from the port. My jail environments have always had PACKAGE=/var/ports/packages in the /etc/make.conf file, but I just checked and none of my jail systems have ever had a /var/ports/packages. I'm trying to figure out what changed all of a sudden so I can make sure I'm accounting for it in my procedures... An example of the original error can be found at: http://resources.rock-pond.com/build.log /basejail/usr/ports is my R/O global ports tree for all jails, so I was confused as to why it wasn't using /var/ports/packages which was set in make.conf, then I noticed the directory wasn't there. I've been able to fix this, but I've never seen this in all my years, so just wondering what may have changed. Thanks for any info! Matt Lager -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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"
Broken port: handbrake
Hello, I'm having a problem with the port "handbrake". >From the Makefile: # Created by: Andrew Thompson # $FreeBSD: head/multimedia/handbrake/Makefile 374303 2014-12-08 16:48:38Z tijl $ The build and install of the port succeeds, but the resulting installation is broken. Attempting to read a DVD leads to this error: # HandBrakeCLI -t 1 -f mp4 -e x264 -q 20 -E faac -B 160 -i /dev/cd0 -o /tmp/out.mp4 [21:03:28] hb_init: starting libhb thread HandBrake rev5474 (2015032199) - FreeBSD amd64 - http://handbrake.fr 4 CPUs detected Opening /dev/cd0... [21:03:28] hb_scan: path=/dev/cd0, title_index=4 libbluray/bdnav/index_parse.c:162: indx_parse(): error opening /dev/cd0/BDMV/index.bdmv libbluray/bdnav/index_parse.c:162: indx_parse(): error opening /dev/cd0/BDMV/BACKUP/index.bdmv libbluray/bluray.c:1725: nav_get_title_list(/dev/cd0) failed (0x8048b3000) [21:03:28] bd: not a bd - trying as a stream/file instead libdvdnav: Using dvdnav version 4.1.3 libdvdread: Missing symbols in libdvdcss.so.2, this shouldn't happen ! libdvdread: Using libdvdcss version for DVD access Segmentation fault >From these links: https://bbs.archlinux.org/viewtopic.php?id=187410 http://www.linuxquestions.org/questions/slackware-14/handbrake-and-current-4175528049/ It looks this is due to a handbrake bug that was fixed in version 0.9.9-8; I'm guessing that the version installed by the port is earlier than this, but I don't know enough about how the ports system works to be able to say definitively or to fix it myself. I'm using FreeNAS version 9.3. # uname -i -K -r -U -v 9.3-RELEASE-p10 FreeBSD 9.3-RELEASE-p10 #0 r275790+c9242cc: Mon Mar 16 12:46:11 PDT 2015 r...@build3.ixsystems.com:/tank/home/nightlies/FN93/objs/os-base/amd64/tank/home/nightlies/FN93/FreeBSD/src/sys/FREENAS.amd64 FREENAS64 903000 903000 Any assistance would be greatly appreciated! Thanks, Matt Klein ___ 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: Broken port: handbrake
Thanks for the response. I did just run "portsnap fetch && portsnap extract" right before trying. Why wouldn't I be at the latest version of the ports tree? Also, do I understand you correctly that even if I were using the latest ports, the handbrake port would still be broken? Any suggestions for how I could fix it manually? Thanks, Matt > On Mar 21, 2015, at 9:28 PM, Matthew Donovan wrote: > > > On Mar 21, 2015 8:21 PM, "Matt Klein" wrote: > > > > Hello, > > > > I'm having a problem with the port "handbrake". > > > > From the Makefile: > > # Created by: Andrew Thompson > > # $FreeBSD: head/multimedia/handbrake/Makefile 374303 2014-12-08 16:48:38Z > > tijl $ > > > > The build and install of the port succeeds, but the resulting installation > > is broken. Attempting to read a DVD leads to this error: > > > > # HandBrakeCLI -t 1 -f mp4 -e x264 -q 20 -E faac -B 160 -i /dev/cd0 -o > > /tmp/out.mp4 > > [21:03:28] hb_init: starting libhb thread > > HandBrake rev5474 (2015032199) - FreeBSD amd64 - http://handbrake.fr > > 4 CPUs detected > > Opening /dev/cd0... > > [21:03:28] hb_scan: path=/dev/cd0, title_index=4 > > libbluray/bdnav/index_parse.c:162: indx_parse(): error opening > > /dev/cd0/BDMV/index.bdmv > > libbluray/bdnav/index_parse.c:162: indx_parse(): error opening > > /dev/cd0/BDMV/BACKUP/index.bdmv > > libbluray/bluray.c:1725: nav_get_title_list(/dev/cd0) failed (0x8048b3000) > > [21:03:28] bd: not a bd - trying as a stream/file instead > > libdvdnav: Using dvdnav version 4.1.3 > > libdvdread: Missing symbols in libdvdcss.so.2, this shouldn't happen ! > > libdvdread: Using libdvdcss version for DVD access > > Segmentation fault > > > > From these links: > > > > https://bbs.archlinux.org/viewtopic.php?id=187410 > > http://www.linuxquestions.org/questions/slackware-14/handbrake-and-current-4175528049/ > > > > It looks this is due to a handbrake bug that was fixed in version 0.9.9-8; > > I'm guessing that the version installed by the port is earlier than this, > > but I don't know enough about how the ports system works to be able to say > > definitively or to fix it myself. > > > > I'm using FreeNAS version 9.3. > > # uname -i -K -r -U -v > > 9.3-RELEASE-p10 FreeBSD 9.3-RELEASE-p10 #0 r275790+c9242cc: Mon Mar 16 > > 12:46:11 PDT 2015 > > r...@build3.ixsystems.com:/tank/home/nightlies/FN93/objs/os-base/amd64/tank/home/nightlies/FN93/FreeBSD/src/sys/FREENAS.amd64 > > FREENAS64 903000 903000 > > > > Any assistance would be greatly appreciated! > > > > Thanks, > > Matt Klein > > ___ > > 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" > > Your ports are out of date the lastest port is 9.9.3. The port does need to > be updated to the latest however. Which I cant do currently as not near a > FreeBSD system currently ___ 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"
ports/base ntpd rc.d script with WITHOUT_NTP=yes
Hi, I just upgraded my server to 10.1-STABLE r281264 and when I ran mergemaster it told me that /etc/rc.d/ntpd was stale and would I like to delete it. It's never done this before. I've figured out it's because I have WITHOUT_NTP=yes in /etc/src.conf. I did this because I use the ports version of ntpd and thus wanted to remove the base installed version so that when I run commands like ntpq it's using my possibly newer port installed version and not the older one. However, the port version doesn't have its own rc script. It usually uses the base version with ntpd_program and ntpd_config set. With this latest change it means I have to have the base version installed again. Is it possible to get the port version to have its own rc script? -- Matt ___ 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: OpenSSL Security Advisory [11 Jun 2015]
On Jun 13 13:13, Michelle Sullivan wrote: Don Lewis wrote: On 13 Jun, Michelle Sullivan wrote: SSH would be the biggie that most security departments are scared of... Well, ssh is available in ports, though I haven't checked to see that it picks up the correct version of openssl. Problem is it doesn't have 'overwrite base' anymore - and openssh-portable66 which does have overwrite base is now marked depreciated... which means one would have to be very careful about how they use SSH in production as both server and client... Server is easier as it has a different _enable identifier... but the client is not distinguishable so unless one puts /usr/local/bin in their permanent path as a priority over /usr/bin one will use the wrong version. I put WITHOUT_OPENSSH=yes in /etc/src.conf. Then run make delete-old and make delete-old-libs in /usr/src. This removes the base version which means you don't have this issue any longer. I do the same thing with NTP and Unbound as well. Obviously this makes more sense if like me you do source based stuff rather than using freebsd-update. I'm not sure if you can do similar with binary based upgrades? The other alternatives are as you say, put /usr/local/bin before /usr/bin in the $PATH. Or add an alias for commands like ssh to point to the ports version. These methods aren't quite as clean though. -- Matt ___ 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: Removal of $UNIQUENAME
On Aug 18 22:49, Kimmo Paasiala wrote: It would have been nice to have some kind of announcement about the removal of $UNIQUENAME. I for example was depending on it in my make.conf with declarations like these: vim_SET= CONSOLE vim_UNSET= GTK2 RUBY TCL I can of course rewrite those now using $OPTIONS_NAME (editors_vim prefix instead of vim) after reading bsd.option.mk and figuring out the way that works... -Kimmo There was. "pkg updating UNIQUENAME" will show you the announcement. Or just look at the top of /usr/ports/UPDATING. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)
On Feb 11 22:25, Lev Serebryakov wrote: On 07.02.2016 17:28, John Marino wrote: ports-mgmt/synth. I would love to hear what signficant thing portmaster can do that Synth can't. (honestly) Be installed FROM PORTS without all this build-one-more-gcc stuff. Ada? For *port*management* tool? Are you joking? -- // Lev Serebryakov Remember that before portmaster we had cvsup which was written in Modula-3 and portupgrade which is written in Ruby. Whilst it is nice that portmaster is just a simple shell script with no dependancies that's a relatively new thing. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
PHP7 + Synth issue
Hi guys, I'm using the ports-mgmt/synth package builder to build my packages. I just tried to build all of the packages for PHP7 from the new ports and came across an issue. If I set php=7.0 in DEFAULT_VERSIONS in the LiveSystem-make.conf (make.conf) then Synth bails out and refuses to build the repository. It does this: Scanning entire ports tree. progress: 5.93% culprit: comms/atslog Scan aborted because dependency could not be located. databases/php70-mysql (required dependency of comms/atslog) does not exist. It looks like it scans the port tree, come across a port that has USE_PHP=mysql in it and then bails because the port databases/php70-mysql does not exist. Obviously because mysql was removed from PHP7 in favour of mysqli. Is this a problem with the ports infrastructure or should I just not declare php=7.0 in the DEFAULT_VERSIONS? If I do this then it builds fine, but I guess that might cause other issues elsewhere. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP7 + Synth issue
On Feb 17 14:16, John Marino wrote: It seems like a problem with comms/atslog to me. You can work around it now by removing MYSQL as a default option for that port (either modifying the port itself or adding something in -make.conf to change it) atslog is not maintained. Another option is hiding the option if php>=7. Probably the easiest thing to do is turn off the option by default though. The problem is that it isn't just that port. I've also seen it on databases/mysqldumper for example. It's going to affect all ports which have USE_PHP=mysql within them of which I suspect there are quite a lot. It might be impractical to do what you suggest with them all and I'm wondering if miwi as the maintainer of PHP7 has any thoughts of an official way of solving it. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP7 + Synth issue
On Feb 17 15:05, Kurt Jaeger wrote: Hi! > The long term solution will be switching to mysqli or pdo_mysql which is > provided by php70 (and php55/56), I am working right now on cleaning up > the pecl ports, after that I'll go and check which port can switch already. The problem with that approach is that his tree is broken now. His choice is don't build at all or don't use php 7.0. I think it's something that needs attention now unless the intent is to say, "don't use php7 yet, it is not ready for prime time" (which is possible) The PHP eco-system is so huge that one can say that even php56 is not yet ready for prime time 8-) So: Everyone knows that php70 has open issues, miwi and others are tracking them down, and if users/testers submit problem reports via bugzilla, it helps enormously. It will settle the next few weeks. I'll search bugzilla to see if there are any bug reports for this and if not I'll raise one then. I know php70 is very new so I was expecting problems. Synth is pretty new as well though so I thought I would let people know in case they were not aware of this type of breakage. Thanks, -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: mail/postfix and mail/postfix-current need upgrading
On Feb 26 18:48, olli hauer wrote: In some weeks 3.1.x will become the default postfix, and 3.0.x will be removed from the tree, postfix211 will stay as the last postfix 2.x releases and current will become again current. There are some users using VDA patches, only available for postfix 2.8 but it also works on 2.11, there is no support from the VDA project for 3.x and it seems the VDA project is no longer alive. I saw this in the updates that you made yesterday, thanks! However it looks like VDA is still in the Makefile for postfix-current which seems weird if you say that you have removed VDA support? -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
GNOME port removing mtree files?
I have just run a tinderbuild on 6.3 with a portstree csupped 2008-08-09 23:08:58. There seems to be an inordinate amount of leftovers in the statistics and all seem to be related to GNOME, although I cannot pin it down to any particular port. All the logs end with (gnome-desktop picked at random): === Checking filesystem state after all packages deleted list of files present on clean system but missing after everything was deinstalled) ./usr/local/share/locale/de_AT missing ./usr/local/share/locale/de_AT/LC_MESSAGES missing ./usr/local/share/locale/fa_IR missing ./usr/local/share/locale/fa_IR/LC_MESSAGES missing ./usr/local/share/locale/fr_FR missing ./usr/local/share/locale/fr_FR/LC_MESSAGES missing ./usr/local/share/locale/no missing ./usr/local/share/locale/no/LC_MESSAGES missing build of /usr/ports/x11/gnome-desktop ended at Sun Aug 10 14:04:49 UTC 2008 All of these files exist in /etc/mtree/BSD.x11-4.dist in the jail in question. Apologies for the noise if this has already been traced and fixed. I have had a scan through FreshPorts for entries since last night, but can't see anything obvious. It's also possible that I have a corrupt portstree on the tinderbox. Is anyone else seeing this? -- Matt Dawson. [EMAIL PROTECTED] MTD15-RIPE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Does anyone know nginx's www path
Since I am trying to get this setup for a developer machine and I can't get to the default index.html. and it seems that the pid file is not created either with the port. All I get with a default nginx install is a 404 error ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: pkg_trans progress
I have tried building this and it fails at two places one is the libinstall.a compiling which make buildworld creates. and the other part is at main.o but when I build this outside the source tree it does seem to compile and install just fine. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
