Re: GIMP 2.4 - better ui usability
> Maybe someone has similar feeling, so I thought maybe > its not that bad idea to create GIMP 2.4 port that keep all of the > nice features destroyed by a new design team in GIMP 2.6? Haven't you tried to take in contact with GIMP developers? -- Regards, Konstantin ___ 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: ossec-hids-server-2.4.1
Hello, I understand there were a few bugs with ossec v2.5... v2.5.1 has now been released. Where are we at with maintenance for this port? Would it be better if I submitted a patch? Many Thanks Jake On Tue, 2010-10-05 at 21:47 +0100, Jake Smith wrote: > Hi, > > When can we expect security/ossec-hids-* port to be updated from v2.4.1 > to v2.5 released 2010-09-28. > > Many thanks! > > Regards > Jake > ___ > 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"
unable to build net-im/ejabberd 2.1.5
Good day! I'm trying to build ejabberd but to not avail: In file included from sha_drv.c:23: /usr/include/openssl/md2.h:64:2: error: #error MD2 is disabled. gmake[1]: *** [../sha_drv.so] Ошибка 1 gmake[1]: Leaving directory `/usr/ports/net-im/ejabberd/work/ejabberd-2.1.5/src/tls' gmake: *** [all-recursive] Ошибка 1 *** Error code 1 I've tried both base system openssl and port openssl (using WITH_OPENSSL_PORT knob in make.conf). # pkg_info | grep erlang erlang-r14b,1 A functional programming language from Ericsson # uname -srp FreeBSD 8.1-STABLE i386 How to fix this error? -- Regards, Ruslan ___ 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"
DRI build failing on 8.1-STABLE
Hello, Seeing this on an amd64 box when doing a fresh Xorg build: ===> Building for dri-7.6.1,2 gmake[1]: Entering directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src' Making sources for autoconf gmake[2]: Entering directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' rm -f depend touch depend /usr/local/bin/makedepend -fdepend -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa -I../../../src/mesa/glapi -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include glcontextmodes.c clientattrib.c compsize.c eval.c glxcmds.c glxcurrent.c glxext.c glxextensions.c indirect.c indirect_init.c indirect_size.c indirect_window_pos.c indirect_texture_compression.c indirect_transpose_matrix.c indirect_vertex_array.c indirect_vertex_program.c pixel.c pixelstore.c render2.c renderpix.c single2.c singlepix.c vertarr.c xfont.c glx_pbuffer.c glx_query.c drisw_glx.c dri_common.c dri_glx.c XF86dri.c glxhash.c dri2_glx.c dri2.c \ ../../../src/mesa/main/dispatch.c ../../../src/mesa/glapi/glapi.c ../../../src/mesa/glapi/glapi_getproc.c ../../../src/mesa/glapi/glthread.c ../../../src/mesa/x86-64/glapi_x86-64.S gmake[2]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' gmake[2]: Entering directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' cc -L/usr/local/lib -I/usr/local/include -c -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa -I../../../src/mesa/glapi -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include -O2 -pipe -march=native -fno-strict-aliasing -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER -DDEFAULT_DRIVER_DIR=\"/usr/local/lib/dri\" glcontextmodes.c -o glcontextmodes.o glcontextmodes.c: In function '_gl_copy_visual_to_context_mode': glcontextmodes.c:193: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:194: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:196: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:197: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:200: error: '__GLcontextModes' has no member named 'yInverted' glcontextmodes.c: In function '_gl_get_context_mode_data': glcontextmodes.c:333: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:336: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:339: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:343: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:346: error: '__GLcontextModes' has no member named 'yInverted' glcontextmodes.c: In function '_gl_context_modes_create': glcontextmodes.c:418: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:419: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:420: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:421: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:422: error: '__GLcontextModes' has no member named 'yInverted' glcontextmodes.c: In function '_gl_context_modes_are_same': glcontextmodes.c:539: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:539: error: '__GLcontextModes' has no member named 'bindToTextureRgb' glcontextmodes.c:540: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:540: error: '__GLcontextModes' has no member named 'bindToTextureRgba' glcontextmodes.c:541: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:541: error: '__GLcontextModes' has no member named 'bindToMipmapTexture' glcontextmodes.c:542: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:542: error: '__GLcontextModes' has no member named 'bindToTextureTargets' glcontextmodes.c:543: error: '__GLcontextModes' has no member named 'yInverted' glcontextmodes.c:543: error: '__GLcontextModes' has no member named 'yInverted' gmake[2]: *** [glcontextmodes.o] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/glx/x11' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src' gmake: *** [default] Error 1 *** Error code 1 Stop in /usr/ports/graphics/dri. *** Error code 1 Stop in /usr/ports/x11/xorg. It looks like a boo-boo in the code. This is from a freshly pulled down ports tree from this morning and with "WITHOUT_NOUVEAU=yes" in /etc/make.conf. Is there a p
Re: unable to build net-im/ejabberd 2.1.5
22.10.2010 23:07, Chuck Swiger пишет: On Oct 22, 2010, at 11:44 AM, Ruslan Mahmatkhanov wrote: In file included from sha_drv.c:23: /usr/include/openssl/md2.h:64:2: error: #error MD2 is disabled. gmake[1]: *** [../sha_drv.so] Ошибка 1 gmake[1]: Leaving directory `/usr/ports/net-im/ejabberd/work/ejabberd-2.1.5/src/tls' gmake: *** [all-recursive] Ошибка 1 *** Error code 1 I've tried both base system openssl and port openssl (using WITH_OPENSSL_PORT knob in make.conf). # pkg_info | grep erlang erlang-r14b,1 A functional programming language from Ericsson # uname -srp FreeBSD 8.1-STABLE i386 How to fix this error? cd /usr/ports/security/openssl make config [ ...ensure that the MD2 option is checked... ] rebuild and reinstall the openssl port rebuild and reinstall ejabberd port Regards, It works. Thanks! -- Regards, Ruslan ___ 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: unable to build net-im/ejabberd 2.1.5
On Oct 22, 2010, at 12:19 PM, Ruslan Mahmatkhanov wrote: > It works. Thanks! Very good; you're most welcome Regards, -- -Chuck ___ 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"
VirtualBox and nullfs
This is a heads-up for those who might configure their systems in this way. First some background. I normally build ports in a jail, then copy them ($LOCALBASE, package databases, etc) to the various systems in my infrastructure -- it's all scripted (differences in config files are maintained through symlinks). So far so good. The previous time I performed a port upgrade I placed /usr/local and friends onto ZFS. This time in a subdirectory of /usr, using nullfs (and in some cases NFS) to make the final mounts. An example would be /usr/local would be a nullfs mount from /usr/pkg/local and /var/db/pkg would be mounted from /usr/pkg/var/db/pkg. So far so good, everything worked, until... The problem began when I tried to run VirtualBox. It came back with a sysctl failure. Executing it from it's actual location resolved that issue but I still could not run any VMs. Ultimately I removed the nullfs mounts and moved /usr/pkg/local back to /usr/local and VirtualBox worked again. If /usr/local is mounted from a ZFS filesystem, it works. (Not sure about NFS but I suspect it might work too,) However if /usr/local is mounted using a nullfs mount VirtualBox fails to run properly. I don't know why yet. Hopefully if anyone has the same configuration this email should be of assistance. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org e**(i*pi)+1=0 ___ 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"
Virtualbox UI and remote X clients
Folks, It would appear that ever since 3.2.8_1 of virtualbox-ose, a number of additions were made to unconditionally enable some kind of hardware acceleration in the UI. This completely breaks the UI with a variety of QT errors, when running on a remote X11 displays, so far I've tested X11.app and XQuartz.app on OSX, cygwin/X on Windows 7/XP, and even an Xvnc server running on a FreeBSD/amd64 box. It looks like it was this commit: revision 1.27 date: 2010/09/30 12:51:00; author: decke; state: Exp; lines: +2 -0 - Add 2D acceleration support for Windows Guests - Bump PORTREVISION This needs to be made into an OPTION (default on or off, I don't care), but as it stands, the UI is unusable on apparently anything but a local X11 display -- which most machines, holding a number of vbox images, are unlikely to have. -aDe ___ 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: unable to build net-im/ejabberd 2.1.5
On Oct 22, 2010, at 11:44 AM, Ruslan Mahmatkhanov wrote: > In file included from sha_drv.c:23: > /usr/include/openssl/md2.h:64:2: error: #error MD2 is disabled. > gmake[1]: *** [../sha_drv.so] Ошибка 1 > gmake[1]: Leaving directory > `/usr/ports/net-im/ejabberd/work/ejabberd-2.1.5/src/tls' > gmake: *** [all-recursive] Ошибка 1 > *** Error code 1 > > I've tried both base system openssl and port openssl (using WITH_OPENSSL_PORT > knob in make.conf). > > # pkg_info | grep erlang > erlang-r14b,1 A functional programming language from Ericsson > # uname -srp > FreeBSD 8.1-STABLE i386 > > How to fix this error? cd /usr/ports/security/openssl make config [ ...ensure that the MD2 option is checked... ] rebuild and reinstall the openssl port rebuild and reinstall ejabberd port Regards, -- -Chuck ___ 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: Virtualbox UI and remote X clients
On Fri, 22 Oct 2010 15:02:20 -0500, Ade Lovett wrote: > Folks, > > It would appear that ever since 3.2.8_1 of virtualbox-ose, a number > of additions were made to unconditionally enable some kind of hardware > acceleration in the UI. > > This completely breaks the UI with a variety of QT errors, when > running on a remote X11 displays, so far I've tested X11.app and > XQuartz.app on OSX, cygwin/X on Windows 7/XP, and even an Xvnc server > running on a FreeBSD/amd64 box. Could you please post that errors? It sounds like an upstream bug so it would be good to collect a few details like why it happens on your system bug I cannot reproduce it here with Intel graphics. Do you probably have nvidia graphics or anything special? Maybe the bug you are hitting was already fixed upstream so could you test the virtualbox-ose-devel port [1] and see if the problem persists? Sure we could make an option for that patch or revert it but that won't fix the underlying problem that it uncovered. So I would really like to get it at least analyzed first and if it cannot get fixed we can always disable it. [1] http://svn.bluelife.at/nightlies/virtualbox-port.tar.gz -- Bernhard Fröhlich http://www.bluelife.at/ ___ 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: Virtualbox UI and remote X clients
On Oct 22, 2010, at 16:21 , Bernhard Froehlich wrote: > Could you please post that errors? freebsd% setenv DISPLAY remote:0 freebsd% VirtualBox Wait for UI to pop up, click on 'Settings' for any virtual host, VirtualBox crashes with: Qt WARNING: QGLContext::makeCurrent(): Cannot make invalid context current. Segmentation fault (remote) in this case has been (so far): MacOSX 10.6 with Apple's X11.app MacOSX 10.6 with XQuartz.app Windows XP with cygwin/X Windows 7 with cygwin/X Xvnc on the FreeBSD box, then using either the Mac or Windows box to fire up a vnc client to get to the Xvnc. > It sounds like an upstream bug so it > would be good to collect a few details like why it happens on your > system bug I cannot reproduce it here with Intel graphics. Please re-read what I said. The host machine (running the virtualboxes) has NO graphics of any kind. It's FreeBSD 8.1-STABLE/amd64 hooked up to a VT320 terminal as a serial console. It has X11 libraries and the various toolkits (QT etc) installed, but no Xorg server (other than Xvnc), no X11 drivers (graphics/keyboard/mouse). 3.2.8 was fine 3.2.8_1 broke things 3.2.10 (unsurprisingly) hasn't changed -aDe ___ 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: VirtualBox and nullfs
On Fri, 22 Oct 2010 12:42:19 -0700 Cy Schubert wrote: [ .. ] > If > /usr/local is mounted from a ZFS filesystem, it works. (Not sure > about NFS but I suspect it might work too,) [ .. ] Yep.. I run mine with /usr.local being on ZFS. -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: Virtualbox UI and remote X clients
On Fri, Oct 22, 2010 at 5:04 PM, Ade Lovett wrote: > > On Oct 22, 2010, at 16:21 , Bernhard Froehlich wrote: > > Could you please post that errors? > > freebsd% setenv DISPLAY remote:0 > freebsd% VirtualBox > > Wait for UI to pop up, click on 'Settings' for any virtual host, VirtualBox > crashes with: > > Qt WARNING: QGLContext::makeCurrent(): Cannot make invalid context current. > Segmentation fault > > > (remote) in this case has been (so far): > > MacOSX 10.6 with Apple's X11.app > MacOSX 10.6 with XQuartz.app > Windows XP with cygwin/X > Windows 7 with cygwin/X > Xvnc on the FreeBSD box, then using either the Mac or Windows box to fire > up a vnc client to get to the Xvnc. > > > > It sounds like an upstream bug so it > > would be good to collect a few details like why it happens on your > > system bug I cannot reproduce it here with Intel graphics. > > Please re-read what I said. The host machine (running the virtualboxes) > has NO graphics of any kind. It's FreeBSD 8.1-STABLE/amd64 hooked up to a > VT320 terminal as a serial console. It has X11 libraries and the various > toolkits (QT etc) installed, but no Xorg server (other than Xvnc), no X11 > drivers (graphics/keyboard/mouse). > > 3.2.8 was fine > 3.2.8_1 broke things > 3.2.10 (unsurprisingly) hasn't changed > I can confirm this issue, I reported it on the emulation mailing list a few days ago. Thanks for finding the exact breakage point. -- Adam Vande More ___ 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: transmission-daemon-2.04_1
2010/10/21 Вадим Петряев : > Hello! > > > > Transmission was two times released after version 2.04 > https://trac.transmissionbt.com/roadmap?show=completed > > 10 October released 2.10 and 17 October released 2.11 > > May be you need some help for port maintenance? > > As I understand, this port require only one patch changes - because patched > libtransmission/fdlimit.c changed. I am not commit the update yet. Transmission have a bad history of release version that isn't stable enough as you can see they already have 2.11 in a very short peroid. I am able to reproduce a few of problems in 2.10 and 2.11. The 2.12 might be released sometimes soon (just a guess), so I will see how it goes. Cheers, Mezz > Good luck, Vadim -- mezz.free...@gmail.com - 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"
legacy code in bsd.ports.mk
I was going through bsd.port.mk to learn how the ports system works. It seems quite complex - partly due to all the different configurations that need to be supported. 1) I noticed some hacks that were in place in 2004 and I was curious if they were fixed by now, and if so if the hacks should be changed. The attached patch just follows the comments - although I don't know if the specific bug in question is fixed yet 2) revision 1.618 adds code to drop bsd.port.options.mk into /usr/share/mk if it's missing - which seems to be supporting users using 6.2 and before. Since these versions are already EOL now - is it worth it to clutter bsd.port.mk with code to support them? I'm not saying that we should drop support just because they are EOL - but I think that bsd.port.mk is quite complicated already - and the less code the better. 3) revision 1.581 added the following code # XXX to remain undefined until all ports that require Perl are fixed # to set one of the conditionals that force the inclusion of bsd.perl.mk .if !defined(_PERL_REFACTORING_COMPLETE) Is this complete yet? If so could we just remove the .if !defined code? 4) The code that converts from USE_BISON=yes to USE_BISON=build seems to only affect two ports (based on my grepping) and could be fixed using the attached patch 5) I'm sure there is more that could be done to clean up the ports system. These are only things that I found going through bsd.port.mk - if I look at some of the other files I think I'll find more :-( remove-2004-hack.patch Description: Binary data remove-use-bison-yes.patch Description: Binary data ___ 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"
legacy code in bsd.port.mk
I was going through bsd.port.mk to learn how the ports system works. ... Sorry - my initial subject was wrong - I had an extra s. -- Eitan Adler ___ 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"
