textproc/uni2ascii build failure on FreeBSD 7.3
Hi, uni2ascii no longer builds on FreeBSD 7.3: cc -DNEWSUMMARY -O2 -fno-strict-aliasing -pipe -o ascii2uni ascii2uni.o enttbl.o GetWord.o putu8.o SetFormat.o ascii2uni.o(.text+0xb23): In function main': : undefined reference to getline' Quoting the ChangeLog: 2010-08-29 Bill Poser po...@khunekcho.khunek * ascii2uni.c: Removed getline.c dependent on GNU_SOURCE since getline is standard as of POSIX2008. Relying on POSIX2008 support may be a bit ambitious. Thanks, Regards Andrew ___ 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: i7z for FreeBSD
jhell jh...@dataix.net wrote: On 08/27/2010 09:30, Emanuel Haupt wrote: How hard would it be to port i7z to FreeBSD? Seems like a very useful tool. http://code.google.com/p/i7z/ This seems a little like ports/misc/cpuid, is it ? Not quite. i7z is primarily for dumping i7, i3, i5 CPU features. Emanuel ___ 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: textproc/uni2ascii build failure on FreeBSD 7.3
On Tue, Aug 31, 2010 at 04:27:59PM +1000, andrew clarke wrote: uni2ascii no longer builds on FreeBSD 7.3: cc -DNEWSUMMARY -O2 -fno-strict-aliasing -pipe -o ascii2uni ascii2uni.o enttbl.o GetWord.o putu8.o SetFormat.o ascii2uni.o(.text+0xb23): In function main': : undefined reference to getline' FreeBSD 7.x's libc does not include getline(3). The port will have to be modified to probably bring in devel/libgetline and custom patches made to work when built on that OS. Alternatively, one could try and get the author (CC'd) to restore getline.c in the official source but only build it/make use of it when a specific configure or make flag is specified. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: textproc/uni2ascii build failure on FreeBSD 7.3
andrew clarke m...@ozzmosis.com wrote: Hi, uni2ascii no longer builds on FreeBSD 7.3: cc -DNEWSUMMARY -O2 -fno-strict-aliasing -pipe -o ascii2uni ascii2uni.o enttbl.o GetWord.o putu8.o SetFormat.o ascii2uni.o(.text +0xb23): In function main': : undefined reference to getline' Quoting the ChangeLog: 2010-08-29 Bill Poser po...@khunekcho.khunek * ascii2uni.c: Removed getline.c dependent on GNU_SOURCE since getline is standard as of POSIX2008. Relying on POSIX2008 support may be a bit ambitious. According to [1] getline wasn't introduced before OSREVISION prior to 800067. I've just commited a patch that pulls in devel/libgetline on those versions. [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd-versions.html#AEN4754 Thanks for the notification. Emanuel ___ 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: textproc/uni2ascii build failure on FreeBSD 7.3
Alternatively, one could try and get the author (CC'd) to restore getline.c in the official source but only build it/make use of it when a specific configure or make flag is specified. Hi. I think that's the best solution. I'll restore the internal copy and test for the library version in the configure file. ___ 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: textproc/uni2ascii build failure on FreeBSD 7.3
Bill Poser billpos...@gmail.com wrote: Alternatively, one could try and get the author (CC'd) to restore getline.c in the official source but only build it/make use of it when a specific configure or make flag is specified. Hi. I think that's the best solution. I'll restore the internal copy and test for the library version in the configure file. I've just fixed the port for the current version a few minutes ago. So there is no hurry. I'd rather have the port use the system internal version so I'm in favor or Bill's removal. Emanuel ___ 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
devel/sdl12 and gcc -m32
Hi, I was trying to build the future port games/avp-demo (ports/138806) on my 9.0-amd64 laptop with system gcc, but this failed because of SDL errors: gcc -m32 -g -Wall -pipe -Isrc -Isrc/include -Isrc/win95 -Isrc/avp -Isrc/avp/win95 -Isrc/avp/support -Isrc/avp/win95/frontend -Isrc/avp/win95/gadgets -I/usr/local/include/SDL -I/usr/local/include -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/local/include -c -o src/main.o src/main.c In file included from /usr/local/include/SDL/SDL_main.h:26, from /usr/local/include/SDL/SDL.h:30, from src/main.c:6: /usr/local/include/SDL/SDL_stdinc.h:131: error: size of array 'SDL_dummy_uint64' is negative /usr/local/include/SDL/SDL_stdinc.h:132: error: size of array 'SDL_dummy_sint64' is negative Note the -m32 flag passed to gcc, which is used to force generating 32-bit code on 64-bit platforms. The flag is set in the Makefile of the game itself. When I removed the flag I ran into code snippets which would need a rewrite for 64-bit platforms (typecasting, extending hash functions on pointers, etc). I guess SDL is tellng that I cannot have 64-bit values on a 32-bit target when I have devel/sdl12 compiled as the native 64-bit version. Is this a limitation of SDL itself? Regards, Rene -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) ___ 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: devel/sdl12 and gcc -m32
René Ladan r.c.la...@gmail.com writes: Hi, I was trying to build the future port games/avp-demo (ports/138806) on my 9.0-amd64 laptop with system gcc, but this failed because of SDL errors: gcc -m32 -g -Wall -pipe -Isrc -Isrc/include -Isrc/win95 -Isrc/avp -Isrc/avp/win95 -Isrc/avp/support -Isrc/avp/win95/frontend -Isrc/avp/win95/gadgets -I/usr/local/include/SDL -I/usr/local/include -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/local/include -c -o src/main.o src/main.c In file included from /usr/local/include/SDL/SDL_main.h:26, from /usr/local/include/SDL/SDL.h:30, from src/main.c:6: /usr/local/include/SDL/SDL_stdinc.h:131: error: size of array 'SDL_dummy_uint64' is negative /usr/local/include/SDL/SDL_stdinc.h:132: error: size of array 'SDL_dummy_sint64' is negative -m32 is not supported yet, especially not by the ports tree. And even if you manage to compile sources it wouldn't link against 64bit libs. There is a way to compile 32bit ports on amd64 but it involves either using chroot() or different LOCALBASE. Note the -m32 flag passed to gcc, which is used to force generating 32-bit code on 64-bit platforms. The flag is set in the Makefile of the game itself. When I removed the flag I ran into code snippets which would need a rewrite for 64-bit platforms (typecasting, extending hash functions on pointers, etc). This just means the port is BROKEN on amd64. I guess SDL is tellng that I cannot have 64-bit values on a 32-bit target when I have devel/sdl12 compiled as the native 64-bit version. Is this a limitation of SDL itself? I guess SDL inherits some values from machine/*.h headers. BTW, the port doesn't respect CC/CXX and LDFLAGS in make.conf/environ as well as overrides CXXFLAGS. Also audio/openal is pretty ancient. Does the port not support audio/openal-soft? %% --- avp_git/Makefile~ +++ avp_git/Makefile @@ -1,15 +1,8 @@ -CC = gcc -CXX = g++ - -CFLAGS = -m32 -g -Wall -pipe -#CFLAGS += -O2 -#CFLAGS += -DNDEBUG -O6 -ffast-math -fomit-frame-pointer -march=pentium3 -mtune=pentium4 - CFLAGS += -Isrc -Isrc/include -Isrc/win95 -Isrc/avp -Isrc/avp/win95 -Isrc/avp/support -Isrc/avp/win95/frontend -Isrc/avp/win95/gadgets CFLAGS += $(shell sdl-config --cflags) $(shell openal-config --cflags) -CXXFLAGS = $(CFLAGS) +CXXFLAGS += $(CFLAGS) -LDLIBS = -m32 $(shell sdl-config --libs) $(shell openal-config --libs) +LDLIBS = $(shell sdl-config --libs) $(shell openal-config --libs) ROOT = main.c files.c winapi.c stubs.c version.c mathline.c opengl.c fmv.c oglfunc.c openal.c cdplayer.c menus.c net.c frustum.c kshape.c map.c maths.c md5.c mem3dc.c mem3dcpp.cpp module.c morph.c object.c shpanim.c sphere.c tables.c vdb.c AVP = ai_sight.c avpview.c bh_agun.c bh_ais.c bh_alien.c bh_binsw.c bh_cable.c bh_corpse.c bh_deathvol.c bh_debri.c bh_dummy.c bh_fan.c bh_far.c bh_fhug.c bh_gener.c bh_ldoor.c bh_lift.c bh_light.c bh_lnksw.c bh_ltfx.c bh_marin.c bh_mission.c bh_near.c bh_pargen.c bh_plachier.c bh_plift.c bh_pred.c bh_queen.c bh_rubberduck.c bh_selfdest.c bh_snds.c bh_spcl.c bh_swdor.c bh_track.c bh_types.c bh_videoscreen.c bh_waypt.c bh_weap.c bh_xeno.c bonusabilities.c cconvars.cpp cdtrackselection.cpp cheatmodes.c comp_map.c comp_shp.c consolelog.cpp davehook.cpp deaths.c decal.c detaillevels.c dynamics.c dynblock.c equipmnt.c extents.c game.c game_statistics.c gamecmds.cpp gamevars.cpp hmodel.c hud.c inventry.c language.c lighting.c load_shp.c los.c mempool.c messagehistory.c missions.cpp movement.c paintball.c particle.c pfarlocs.c pheromon.c player.c pmove.c psnd.c psndproj.c pvisible.c savegame.c scream.cpp secstats.c sfx.c stratdef.c targeting.c track.c triggers.c weapons.c @@ -48,7 +41,7 @@ OBJ = $(ROOTOBJ) $(AVPOBJ) $(SHAPESOBJ) all: avp avp: $(OBJ) - $(CXX) -o avp $(OBJ) $(LDLIBS) + $(CXX) -o avp $(OBJ) $(LDLIBS) $(LDFLAGS) clean: -rm -rf $(OBJ) avp %% ___ 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: devel/sdl12 and gcc -m32
(cc'ing submitter of the port) 2010/8/31 Anonymous swel...@gmail.com: René Ladan r.c.la...@gmail.com writes: Hi, I was trying to build the future port games/avp-demo (ports/138806) on my 9.0-amd64 laptop with system gcc, but this failed because of SDL errors: gcc -m32 -g -Wall -pipe -Isrc -Isrc/include -Isrc/win95 -Isrc/avp -Isrc/avp/win95 -Isrc/avp/support -Isrc/avp/win95/frontend -Isrc/avp/win95/gadgets -I/usr/local/include/SDL -I/usr/local/include -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/local/include -c -o src/main.o src/main.c In file included from /usr/local/include/SDL/SDL_main.h:26, from /usr/local/include/SDL/SDL.h:30, from src/main.c:6: /usr/local/include/SDL/SDL_stdinc.h:131: error: size of array 'SDL_dummy_uint64' is negative /usr/local/include/SDL/SDL_stdinc.h:132: error: size of array 'SDL_dummy_sint64' is negative -m32 is not supported yet, especially not by the ports tree. And even if you manage to compile sources it wouldn't link against 64bit libs. Hmm ok, I'll add a NOT_FOR_ARCH / ONLY_FOR_ARCH to the port. There is a way to compile 32bit ports on amd64 but it involves either using chroot() or different LOCALBASE. The wine approach. Note the -m32 flag passed to gcc, which is used to force generating 32-bit code on 64-bit platforms. The flag is set in the Makefile of the game itself. When I removed the flag I ran into code snippets which would need a rewrite for 64-bit platforms (typecasting, extending hash functions on pointers, etc). This just means the port is BROKEN on amd64. I guess SDL is tellng that I cannot have 64-bit values on a 32-bit target when I have devel/sdl12 compiled as the native 64-bit version. Is this a limitation of SDL itself? I guess SDL inherits some values from machine/*.h headers. BTW, the port doesn't respect CC/CXX and LDFLAGS in make.conf/environ as well as overrides CXXFLAGS. Also audio/openal is pretty ancient. Does the port not support audio/openal-soft? I've replaced this with USE_OPENAL=yes in my local copy of the Makefile, as well using the DOCSDIR and DATADIR macros. I'll change the port to also respect the above flags. %% --- avp_git/Makefile~ +++ avp_git/Makefile @@ -1,15 +1,8 @@ -CC = gcc -CXX = g++ - -CFLAGS = -m32 -g -Wall -pipe -#CFLAGS += -O2 -#CFLAGS += -DNDEBUG -O6 -ffast-math -fomit-frame-pointer -march=pentium3 -mtune=pentium4 - CFLAGS += -Isrc -Isrc/include -Isrc/win95 -Isrc/avp -Isrc/avp/win95 -Isrc/avp/support -Isrc/avp/win95/frontend -Isrc/avp/win95/gadgets CFLAGS += $(shell sdl-config --cflags) $(shell openal-config --cflags) -CXXFLAGS = $(CFLAGS) +CXXFLAGS += $(CFLAGS) -LDLIBS = -m32 $(shell sdl-config --libs) $(shell openal-config --libs) +LDLIBS = $(shell sdl-config --libs) $(shell openal-config --libs) ROOT = main.c files.c winapi.c stubs.c version.c mathline.c opengl.c fmv.c oglfunc.c openal.c cdplayer.c menus.c net.c frustum.c kshape.c map.c maths.c md5.c mem3dc.c mem3dcpp.cpp module.c morph.c object.c shpanim.c sphere.c tables.c vdb.c AVP = ai_sight.c avpview.c bh_agun.c bh_ais.c bh_alien.c bh_binsw.c bh_cable.c bh_corpse.c bh_deathvol.c bh_debri.c bh_dummy.c bh_fan.c bh_far.c bh_fhug.c bh_gener.c bh_ldoor.c bh_lift.c bh_light.c bh_lnksw.c bh_ltfx.c bh_marin.c bh_mission.c bh_near.c bh_pargen.c bh_plachier.c bh_plift.c bh_pred.c bh_queen.c bh_rubberduck.c bh_selfdest.c bh_snds.c bh_spcl.c bh_swdor.c bh_track.c bh_types.c bh_videoscreen.c bh_waypt.c bh_weap.c bh_xeno.c bonusabilities.c cconvars.cpp cdtrackselection.cpp cheatmodes.c comp_map.c comp_shp.c consolelog.cpp davehook.cpp deaths.c decal.c detaillevels.c dynamics.c dynblock.c equipmnt.c extents.c game.c game_statistics.c gamecmds.cpp gamevars.cpp hmodel.c hud.c inventry.c language.c lighting.c load_shp.c los.c mempool.c messagehistory.c missions.cpp movement.c paintball.c particle.c pfarlocs.c pheromon.c player.c pmove.c psnd.c psndproj.c pvisible.c savegame.c scream.cpp secstats.c sfx.c stratdef.c targeting.c track.c triggers.c weapons.c @@ -48,7 +41,7 @@ OBJ = $(ROOTOBJ) $(AVPOBJ) $(SHAPESOBJ) all: avp avp: $(OBJ) - $(CXX) -o avp $(OBJ) $(LDLIBS) + $(CXX) -o avp $(OBJ) $(LDLIBS) $(LDFLAGS) clean: -rm -rf $(OBJ) avp %% Note that openal-config is replaced by pkg-config openal, I've also patched that. Thanks, Rene ___ 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: devel/sdl12 and gcc -m32
René Ladan r.c.la...@gmail.com writes: -m32 is not supported yet, especially not by the ports tree. And even if you manage to compile sources it wouldn't link against 64bit libs. Hmm ok, I'll add a NOT_FOR_ARCH / ONLY_FOR_ARCH to the port. ONLY_FOR_ARCHS/NOT_FOR_ARCHS set IGNORE, not BROKEN for the port. IIRC, tinderbox has -trybroken option in order to test whether the ports is *still* broken or not. There is a way to compile 32bit ports on amd64 but it involves either using chroot() or different LOCALBASE. The wine approach. Nah, wine is mostly useful for running 32bit apps. And wine64 for running 64bit apps is still experimental. It's only makes sense for it to have IGNORE for non-i386 archs. ___ 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: RFT: deskutils/sciplore-mindmapping
On Tue, Aug 31, 2010 at 6:44 AM, Matthias Andree mand...@freebsd.org wrote: Greetings, I have create a new port for SciPlore Mind Mapping, a mind mapper/manager with reference and PDF management (to integrate with JabRef, Mendeley, BibTeX). The port requires Java 1.6. Since this is my first Java-related port, and I haven't all the related tools installed, I'd like to request testing and feedback on the port. Please let me know if it works for you, what reference and/or PDF software you've used, or if it fails, or if you spot something I can improve before making this an official port. URL: http://home.pages.de/~mandree/freebsd/ - grab the .shar file and the GnuPG signature, make sure the file wasn't tampered with, then type: cd /var/tmp sh /path/to/sciplore-mindmapping.shar cd sciplore-mindmapping make install clean Thanks a lot. I works OK on my 8.0-RELEASE. ___ 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
INDEX build failed for 6.x
INDEX build failed with errors: Generating INDEX-6 - please wait..pkg_info: not found pkg_info: not found Done. make_index: btpeer-0.2.1: no entry for /usr/ports/net/Sockets-devel Committers on the hook: avilla avl garga jadawin lth olgeni sylvio Most recent CVS update was: U MOVED U accessibility/ktts/Makefile U accessibility/ktts/pkg-message U accessibility/speech-dispatcher/Makefile U accessibility/speech-dispatcher/distinfo U accessibility/speech-dispatcher/pkg-plist U accessibility/speech-dispatcher/files/patch-config-Makefile.in U accessibility/speech-dispatcher/files/patch-config-clients-Makefile.in U accessibility/speech-dispatcher/files/patch-config-modules-Makefile.in U accessibility/speech-dispatcher/files/patch-configure U accessibility/speech-dispatcher/files/patch-src-server-speechd.h U audio/mhwaveedit/Makefile U audio/mhwaveedit/distinfo U chinese/Makefile U devel/p5-Log-Log4perl/Makefile U devel/p5-Log-Log4perl/distinfo U editors/rox-edit/Makefile U editors/rox-edit/distinfo U graphics/Makefile U misc/Makefile U net/Makefile U net/freerdp/Makefile U net/freerdp/distinfo U net/p5-POE-Component-Client-Keepalive/Makefile U net/p5-POE-Component-Client-Keepalive/distinfo U net/p5-POE-Component-Server-Twirc/Makefile U net/p5-POE-Component-Server-Twirc/distinfo U net/remmina/Makefile U net/remmina/distinfo U net/remmina/pkg-plist U net/remmina-applet/Makefile U net/remmina-applet/distinfo U net/remmina-applet/pkg-plist U net/remmina-plugin-i18n/pkg-plist U net/remmina-plugins/Makefile U net/remmina-plugins/distinfo U security/vuxml/vuln.xml U sysutils/usermin/Makefile U sysutils/usermin/distinfo U sysutils/webmin/Makefile U sysutils/webmin/distinfo U sysutils/webmin/files/patch-fsdump_freebsd-lib.pl U www/p5-POE-Component-Client-HTTP/Makefile U www/p5-POE-Component-Client-HTTP/distinfo ___ 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: RFT: deskutils/sciplore-mindmapping
On 08/31/2010 06:14, Sutra Zhou wrote: On Tue, Aug 31, 2010 at 6:44 AM, Matthias Andree mand...@freebsd.org wrote: Greetings, I have create a new port for SciPlore Mind Mapping, a mind mapper/manager with reference and PDF management (to integrate with JabRef, Mendeley, BibTeX). The port requires Java 1.6. Since this is my first Java-related port, and I haven't all the related tools installed, I'd like to request testing and feedback on the port. Please let me know if it works for you, what reference and/or PDF software you've used, or if it fails, or if you spot something I can improve before making this an official port. URL: http://home.pages.de/~mandree/freebsd/ - grab the .shar file and the GnuPG signature, make sure the file wasn't tampered with, then type: cd /var/tmp sh /path/to/sciplore-mindmapping.shar cd sciplore-mindmapping make install clean Thanks a lot. I works OK on my 8.0-RELEASE. Runs as expected on FreeBSD 8.1-STABLE. Java runs like shit, menu's for me have been wacked for some time with no seen fix in the future. I am starting to think its my minimal approach to X using Xmonad as a window manager but the last time I tried to get anyone to test and see if things worked! properly I had no replies. Would be nice to get software like this working but who knows. Other than the above, nice job... Submit Commit! -- jhell,v ___ 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
net/freeswitch-core
Hello, When building/installing net/freeswitch-core on an amd64 8.1-RELEASE, only the following modules are installed in /usr/local/lib/freeswitch/mod : e...@srvbsdfenssv:~ ll /usr/local/lib/freeswitch/mod/ total 288 -rwxr-xr-x 1 root wheel1239 31 aoû 16:24 mod_amr.la -rwxr-xr-x 1 root wheel 41228 31 aoû 16:24 mod_amr.so -rwxr-xr-x 1 root wheel1251 31 aoû 16:24 mod_amrwb.la -rwxr-xr-x 1 root wheel 41208 31 aoû 16:24 mod_amrwb.so -rwxr-xr-x 1 root wheel1233 31 aoû 16:24 mod_bv.la -rwxr-xr-x 1 root wheel 139239 31 aoû 16:24 mod_bv.so -rwxr-xr-x 1 root wheel1263 31 aoû 16:24 mod_cdr_csv.la -rwxr-xr-x 1 root wheel 61225 31 aoû 16:24 mod_cdr_csv.so Modules like mod_sofia, mod_console and many others are missing (on i386, they're available, as tested on a i386 8.1-RELEASE). Has anyone an idea regarding this problem, please ? Script of the build is available here : http://emss.free.fr/contents/informatique/FreeBSD-amd64-FreeSWITCH/fs_build.7z Regards Éric Masson -- Pourriez vous me dire comment réaliser un fichier autoexecutable ou plus presisement le fichier .exe que l'on met dedans ! -+- T in Guide du Neuneu Usenet : autoexécution de neuneu -+- ___ 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: RFT: deskutils/sciplore-mindmapping
Am 31.08.2010 17:47, schrieb J. Hellenthal: Runs as expected on FreeBSD 8.1-STABLE. Java runs like shit, menu's for me have been wacked for some time with no seen fix in the future. I am starting to think its my minimal approach to X using Xmonad as a window manager but the last time I tried to get anyone to test and see if things worked! properly I had no replies. Would be nice to get software like this working but who knows. Hi J, java/jdk16 seems to work reasonably well for me, where the Xorg stuff was automatically installed as part of a gnome2 desktop dependency for me, menus work seemingly OK (AMD Radeon HD 3300 two-generations-past chipset graphics here). Java is not blazingly fast (compared to Ubuntu Linux on the same hardware, I'M using FreeBSD 8.1-STABLE amd64), but then again ZFS is the bigger hog on performance currently. Other than the above, nice job... Submit Commit! Thanks. I'm a ports committer though, so you won't see an ephemeral PR - and I am still awaiting a bit more feedback (I got test promises in private mail) but might commit Thursday night (European time) then. I'd also appreciate if some of the java@ team could comment on the coding style of the port's Makefile/pkg-* files (unless someone already did and I didn't reckon that). Best regards Matthias ___ 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
current ports Mk make fetch calls wget fails to support schemes
Submitter-Id: current-users
Originator:Julian H. Stacey
Organization: http://berklix.com BSD Linux Unix Consultancy, Munich/Muenchen.
Confidential: no
Synopsis: current ports Mk make fetch calls wget fails to support schemes
Severity: serious
Priority: high
Category: ports
Class: sw-bug
Release: current
Environment:
System: FreeBSD fire.js.berklix.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Mon Jul
12 00:59:43 CEST 2010
j...@fire.js.berklix.net:/usr1/src/sys/amd64/compile/FIRE64.small amd64
Description:
Using a base of 8.0-RELEASE
cd /pri/FreeBSD/branches/-current/ports
setenv PORTSDIR `/bin/pwd`
cd sysutils/tarsnap
make fetch
Mk/ has regressed in current now fails to fetch URLS of type
file:///usr/bla/
/usr/bla/
with error:
/usr/home/jhs/tmp/tarsnap-autoconf-1.0.27.tgz: Unsupported scheme.
file:///host/gate/usr/home/jhs/tmp/tarsnap-autoconf-1.0.27.tgz: \
Unsupported scheme.
From make.conf fragment:
DIS_LOCAL+= /usr/home/jhs/tmp/distfiles/
DIS_LOCAL+= file:///usr/home/jhs/tmp/distfiles/
MASTER_SITE_OVERRIDE= ${DIS_LOCAL}
make fetch used to call src/ BSD licensed fetch
it now calls FSF GNU licensed wget,
You can see why it fails with
cd sysutils/tarsnap ; make fetch-list
Even after one has found where
Unsupported scheme
comes from tried to work round it with make.conf assertion of
FETCH_BINARY=/usr/bin/fetch
as shown in bsd.port.mk
/usr/src/usr.bin/fetch is still not used.
How-To-Repeat:
See above
Fix:
Revert Mk invocation back to longer invoke FSF/GNU licensed
wget instead again invoke BSD licensed src/ provided fetch,
until such time as wget might be capable of offering all
schemes BSD fetch already does.
___
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: RFT: deskutils/sciplore-mindmapping
On 08/31/2010 13:01, Matthias Andree wrote: Am 31.08.2010 17:47, schrieb J. Hellenthal: Runs as expected on FreeBSD 8.1-STABLE. Java runs like shit, menu's for me have been wacked for some time with no seen fix in the future. I am starting to think its my minimal approach to X using Xmonad as a window manager but the last time I tried to get anyone to test and see if things worked! properly I had no replies. Would be nice to get software like this working but who knows. Hi J, java/jdk16 seems to work reasonably well for me, where the Xorg stuff was automatically installed as part of a gnome2 desktop dependency for me, menus work seemingly OK (AMD Radeon HD 3300 two-generations-past chipset graphics here). Java is not blazingly fast (compared to Ubuntu Linux on the same hardware, I'M using FreeBSD 8.1-STABLE amd64), but then again ZFS is the bigger hog on performance currently. Other than the above, nice job... Submit Commit! Thanks. I'm a ports committer though, so you won't see an ephemeral PR - and I am still awaiting a bit more feedback (I got test promises in private mail) but might commit Thursday night (European time) then. I'd also appreciate if some of the java@ team could comment on the coding style of the port's Makefile/pkg-* files (unless someone already did and I didn't reckon that). Best regards Matthias I just patched up my xmonad. Just for reference the referring URL to the fix is here: http://bit.ly/cZt3UX to make Java act correctly in a non-re-parenting Window Manager. I am in a way shocked that they knew about this back at 0.8 and were up to 0.9 now with no fix... Sigh... I have not looked into this until now that I saw that you were working on SCIPlore very useful utility small and faster than Freemind in a lot of ways. Anyway... Thanks! Regards, -- jhell,v ___ 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: current ports Mk make fetch calls wget fails to support schemes
On Tue, Aug 31, 2010 at 07:39:32PM +0200, Julian H. Stacey wrote:
Submitter-Id:current-users
Originator: Julian H. Stacey
Organization:http://berklix.com BSD Linux Unix Consultancy,
Munich/Muenchen.
Confidential:no
Synopsis:current ports Mk make fetch calls wget fails to support schemes
Severity:serious
Priority:high
Category:ports
Class: sw-bug
Release: current
Environment:
System: FreeBSD fire.js.berklix.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Mon
Jul 12 00:59:43 CEST 2010
j...@fire.js.berklix.net:/usr1/src/sys/amd64/compile/FIRE64.small amd64
Description:
Using a base of 8.0-RELEASE
cd /pri/FreeBSD/branches/-current/ports
setenv PORTSDIR `/bin/pwd`
cd sysutils/tarsnap
make fetch
Mk/ has regressed in current now fails to fetch URLS of type
file:///usr/bla/
/usr/bla/
with error:
/usr/home/jhs/tmp/tarsnap-autoconf-1.0.27.tgz: Unsupported scheme.
file:///host/gate/usr/home/jhs/tmp/tarsnap-autoconf-1.0.27.tgz: \
Unsupported scheme.
From make.conf fragment:
DIS_LOCAL+= /usr/home/jhs/tmp/distfiles/
DIS_LOCAL+= file:///usr/home/jhs/tmp/distfiles/
MASTER_SITE_OVERRIDE= ${DIS_LOCAL}
make fetch used to call src/ BSD licensed fetch
it now calls FSF GNU licensed wget,
You can see why it fails with
cd sysutils/tarsnap ; make fetch-list
Even after one has found where
Unsupported scheme
comes from tried to work round it with make.conf assertion of
FETCH_BINARY=/usr/bin/fetch
as shown in bsd.port.mk
/usr/src/usr.bin/fetch is still not used.
How-To-Repeat:
See above
Fix:
Revert Mk invocation back to longer invoke FSF/GNU licensed
wget instead again invoke BSD licensed src/ provided fetch,
until such time as wget might be capable of offering all
schemes BSD fetch already does.
Hmm... Can't reproduce it here, but this is now the 2nd report of this
problem to hit -ports.
# uname -a
FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Mon Aug 2 07:35:23
PDT 2010 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64
amd64
# cd /usr/ports/sysutils/tarsnap
# make fetch
=== License check disabled, port has not defined LICENSE
=== tarsnap-1.0.27 depends on file: /usr/local/bin/wget - found
= tarsnap-autoconf-1.0.27.tgz doesn't seem to exist in /usr/ports/distfiles/.
= Attempting to fetch from https://www.tarsnap.com/download/.
--2010-08-31 10:54:32--
https://www.tarsnap.com/download/tarsnap-autoconf-1.0.27.tgz
Resolving www.tarsnap.com... 208.79.82.75
Connecting to www.tarsnap.com|208.79.82.75|:443... connected.
WARNING: cannot verify www.tarsnap.com's certificate, issued by
`/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
Certification Authority/serialNumber=07969287':
Self-signed certificate encountered.
HTTP request sent, awaiting response... 200 OK
Length: 587420 (574K) [application/x-gzip]
Saving to: `tarsnap-autoconf-1.0.27.tgz'
100%[==]
587,420 596K/s in 1.0s
2010-08-31 10:54:34 (596 KB/s) - `tarsnap-autoconf-1.0.27.tgz' saved
[587420/587420]
# grep -ri wget /usr/ports/Mk
#
My ports tree was last updated a couple hours ago.
I can confirm that GNU wget doesn't support the file:/// URI and does
return unsupported scheme.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
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: net/freeswitch-core
Jeremy Chadwick free...@jdc.parodius.com writes: Hi Jeremy, Looks like the entire build, and installation, bombs out once it tries to deal with something called celt-0.7.1.tar.gz (mod_celt). Taken from the build script: Ok, I can reproduce the problem in fs source tree on my box, gmake -d in mod_celt directory does bomb the same way (locale settings removed to get vanilla error messages) file:///vol0/ports/distfiles/celt-0.7.1.tar.gz: Unsupported scheme `file'. cannot find celt-0.7.1.tar.gz Running gmake -d doesn't enlighten me about the possible cause of the problem (output attached), maybe I'm missing something obvious... Regards Éric Masson Script started on Tue Aug 31 20:08:56 201 GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for amd64-portbld-freebsd8.1 Reading makefiles... Reading makefile `Makefile'... Reading makefile `../../../../build/modmake.rules' (search path) (no ~ expansion)... Updating makefiles Considering target file `../../../../build/modmake.rules'. Looking for an implicit rule for `../../../../build/modmake.rules'. Trying pattern rule with stem `modmake.rules'. Trying implicit prerequisite `../../../../build/modmake.rules.c'. Trying pattern rule with stem `modmake.rules'. Trying implicit prerequisite `../../../../build/modmake.rules.lo'. Trying pattern rule with stem `modmake.rules'. Trying implicit prerequisite `../../../../build/modmake.rules.o'. Trying pattern rule with stem `modmake.rules'. Trying implicit prerequisite `../../../../build/modmake.rules.cpp'. Trying pattern rule with stem `modmake.rules'. Trying implicit prerequisite `../../../../build/modmake.rules,v'. Trying pattern rule with stem `modmake.rules'. Trying implicit prerequisite `../../../../build/RCS/modmake.rules,v'. Trying pattern rule with stem `modmake.rules'. Trying implicit prerequisite `../../../../build/RCS/modmake.rules'. Trying pattern rule with stem `modmake.rules'. Trying implicit prerequisite `../../../../build/s.modmake.rules'. Trying pattern rule with stem `modmake.rules'. Trying implicit prerequisite `../../../../build/SCCS/s.modmake.rules'. Trying pattern rule with stem `modmake.rules'. Trying implicit prerequisite `../../../../build/modmake.rules.c'. Looking for a rule with intermediate file `../../../../build/modmake.rules.c'. Avoiding implicit rule recursion. Trying pattern rule with stem `modmake.rules'. Trying implicit prerequisite `../../../../build/modmake.rules.w'. Trying pattern rule with stem `modmake.rules.c'. Trying implicit prerequisite `../../../../build/modmake.rules.c,v'. Trying pattern rule with stem `modmake.rules.c'. Trying implicit prerequisite `../../../../build/RCS/modmake.rules.c,v'. Trying pattern rule with stem `modmake.rules.c'. Trying implicit prerequisite `../../../../build/RCS/modmake.rules.c'. Trying pattern rule with stem `modmake.rules.c'. Trying implicit prerequisite `../../../../build/s.modmake.rules.c'. Trying pattern rule with stem `modmake.rules.c'. Trying implicit prerequisite `../../../../build/SCCS/s.modmake.rules.c'. Trying pattern rule with stem `modmake.rules'. Trying implicit prerequisite `../../../../build/modmake.rules.w'. Looking for a rule with intermediate file `../../../../build/modmake.rules.w'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `modmake.rules.w'. Trying implicit prerequisite `../../../../build/modmake.rules.w,v'. Trying pattern rule with stem `modmake.rules.w'. Trying implicit prerequisite `../../../../build/RCS/modmake.rules.w,v'. Trying pattern rule with stem `modmake.rules.w'. Trying implicit prerequisite `../../../../build/RCS/modmake.rules.w'. Trying pattern rule with stem `modmake.rules.w'. Trying implicit prerequisite `../../../../build/s.modmake.rules.w'. Trying pattern rule with stem `modmake.rules.w'. Trying implicit prerequisite `../../../../build/SCCS/s.modmake.rules.w'. Trying pattern rule with stem `modmake.rules'. Trying implicit prerequisite `../../../../build/modmake.rules.lo'. Looking for a rule with intermediate file `../../../../build/modmake.rules.lo'. Avoiding implicit rule recursion. Trying pattern rule with stem `modmake.rules'. Rejecting impossible implicit prerequisite `../../../../build/modmake.rules.c'. Trying pattern rule with stem `modmake.rules'. Trying implicit prerequisite `../../../../build/modmake.rules.cpp'. Trying pattern rule with stem `modmake.rules.lo'. Trying implicit prerequisite `../../../../build/modmake.rules.lo,v'. Trying pattern rule with stem `modmake.rules.lo'. Trying implicit prerequisite `../../../../build/RCS/modmake.rules.lo,v'. Trying pattern rule with
Re: ports/146754: [patch] new port: add devel/atf framework to ports
On Tue, Aug 31, 2010 at 10:17 AM, Ade Lovett a...@freebsd.org wrote:
On Aug 29, 2010, at 20:00 , Garrett Cooper wrote:
Found the reference. The stuff that gets installed under
${PREFIX}/tests (to some degree) are actually executables
($(execdir)), and some are data files ($(datarootdir)).
Woo. Lots of fun there. :)
As much as I hate committing a port that has known issues (in this case
hier(7) breakage), I can certainly see the value in having it in the tree.
So. Here's the deal. I'll go ahead and commit it, adding a note that it
currently isn't hier(7) safe (just a note, not an IGNORE/BROKEN/whatever).
However, if in 6 months, or two version jumps, whichever comes first, it is
still not heir(7) safe, then I _will_ mark it BROKEN.
Unless anyone else can thing of an utter show-stopper, this would seem to be
the best compromise.
Understood.
Thanks,
-Garrett
___
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
INDEX build failed for 6.x
INDEX build failed with errors: Generating INDEX-6 - please wait..pkg_info: not found pkg_info: not found Done. make_index: btpeer-0.2.1: no entry for /usr/ports/net/Sockets-devel Committers on the hook: avilla avl bapt garga jadawin lth olgeni rene sylvio Most recent CVS update was: U MOVED U comms/Makefile U comms/spandsp/Makefile U comms/spandsp/distinfo U comms/spandsp/pkg-descr U comms/spandsp/pkg-plist U devel/libs11n/Makefile U devel/libs11n/distinfo U french/Makefile U graphics/Makefile U mail/Makefile U sysutils/Makefile U sysutils/ddrescue/Makefile U sysutils/ddrescue/distinfo U textproc/Makefile ___ 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: current ports Mk make fetch calls wget fails to support schemes
Jeremy Chadwick free...@jdc.parodius.com writes: Hi, Hmm... Can't reproduce it here, but this is now the 2nd report of this problem to hit -ports. Removing wget from path solves the issue faced when building mod_celt in net/freeswitch. Thanks for you help diagnosing the problem. Éric Masson -- Il vaut mieux de dormir pendant 6 mois que vivant dans constante culturelle l'obscurité -+- Pelle in http://www.le-gnu.net Pelle le con quérant -+- ___ 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: math/blas linking to gfortran with LDADD?= -lgfortran
The subject listed port fails to link during an upgrade from the previous version. Looking into this further libblas.so.2 without being Would you elaborate, please? Where is a transcript showing the linking failure? Would you mail it to me off-list? linked to gfortran is correct as in the already installed previous version installed inspected with ldd(1) shows the same linking as the new version without the -lgfortran linker flags. I don't find this to be the case. Perhaps you could provide listings for `ldd -a /usr/local/lib/libblas.so.2`, `objdump -x /usr/local/lib/libblas.so.2`, and `make -C /usr/ports/math/blas -v -d l deinstall clean all`, with and without your change, off-list? Attached is the patch that solves the linking problem. I do not see any dependents listed for this port for any of the gcc* ports that can be installed so therefore I have removed the -lgfortran from LDADD. ? USE_FORTRAN=yes == USE_GCC=4.4 You don't see any relevant undefined symbols in the blas libraries? With regards to your statements about math/lapack and profiling: it has been the case for some time that this port has built and installed these libraries by default, perhaps because this port has mainly been used by people concerned about numerical linear algebra and concrete measures of performance. I recently added the statement you quoted to allow users to avoid these libraries -- it intentionally mirrors the similar statement in the allied port math/blas, where the form is is dictated by the use of bsd.lib.mk to build the libraries. Given the typical use of these ports, I don't think it is unreasonable to enable profiling libraries by default. But if you don't like it, you can now easily opt out. Regards, b. ___ 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: current ports Mk make fetch calls wget fails to support schemes
Jeremy Chadwick wrote: ... Hmm... Can't reproduce it here, but this is now the 2nd report of this problem to hit -ports. ... Thanks for looking, I'll send you more of my env. by private mail off list Eric Masson wrote: Jeremy Chadwick free...@jdc.parodius.com writes: Hi, Hmm... Can't reproduce it here, but this is now the 2nd report of this problem to hit -ports. Removing wget from path solves the issue faced when building mod_celt in net/freeswitch. Thanks for you help diagnosing the problem. Éric Masson Removing wget didnt avoid the problem here: mv /usr/local/bin/wget /usr/local/bin/wgetMV ; rehash cd /pri/FreeBSD/branches/-current/ports setenv PORTSDIR /pri/FreeBSD/branches/-current/ports cd sysutils/tarsnap make fetch === tarsnap-1.0.27 depends on file: /usr/local/bin/wget \ - not found ===Verifying install for /usr/local/bin/wget in \ /pri/FreeBSD/branches/-current/ports/ftp/wget === Extracting for wget-1.12_1 Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML, quoted-printable base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. ___ 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: math/blas linking to gfortran with LDADD?= -lgfortran
On 08/31/2010 15:06, b. f. wrote: Would you elaborate, please? Where is a transcript showing the linking failure? Would you mail it to me off-list? Simply -lgfortran by it self should not work. Since lib directories gcc44 gcc45 gcc46 and such are not in the standard path -L/usr/local/lib/gcc44 would have to be passed to LDFLAGS in order for it to be found. Off list should not be necessary. I don't find this to be the case. Perhaps you could provide listings for `ldd -a /usr/local/lib/libblas.so.2`, `objdump -x /usr/local/lib/libblas.so.2`, and `make -C /usr/ports/math/blas -v -d l deinstall clean all`, with and without your change, off-list? With my change in objdump the only thing listed in objdump -x that is relevant to -lgfortran is the RPATH=/usr/local/lib/gcc44 and there is no undefined symbols. Without my change it simply will not build unless I either a) remove -lgfortran or b) add -L/usr/local/lib/gcc44 ? USE_FORTRAN=yes == USE_GCC=4.4 You don't see any relevant undefined symbols in the blas libraries? With regards to your statements about math/lapack and profiling: it has been the case for some time that this port has built and installed these libraries by default, perhaps because this port has mainly been used by people concerned about numerical linear algebra and concrete measures of performance. I recently added the statement you quoted to allow users to avoid these libraries -- it intentionally mirrors the similar statement in the allied port math/blas, where the form is is dictated by the use of bsd.lib.mk to build the libraries. Given the typical use of these ports, I don't think it is unreasonable to enable profiling libraries by default. But if you don't like it, you can now easily opt out. Would it be possible with this to check for the existence of -lc_p before and opt out automatically while warning the user that the profiled libc was not found so profiling will be unavailable. ? Specifically this port is making a blind assumptions that profiled libraries are installed on the system it is being installed on, I do not find that to be correct. Something like this would best be handled by options that default off. gfortran44 -O -pg -c dsecndtst.f -o dsecndtst.o gfortran44 -O -pg -c tstiee.f -o tstiee.o gfortran44 -O -pg -c ilaver.f -o ilaver.o gfortran44 -O -pg -c LAPACK_version.f -o LAPACK_version.o gfortran44 -Wl,-rpath=/usr/local/lib/gcc44 -pg -o testlsame lsame.o lsametst.o /usr/local/bin/ld: cannot find -lc_p collect2: ld returned 1 exit status *** Error code 1 -- jhell,v ___ 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
INDEX build failed for 6.x
INDEX build failed with errors: Generating INDEX-6 - please wait..pkg_info: not found pkg_info: not found Done. make_index: btpeer-0.2.1: no entry for /usr/ports/net/Sockets-devel Committers on the hook: avilla avl bapt brooks cy fjoe garga jacula jadawin lth olgeni pav pgollucci rene sylvio Most recent CVS update was: U deskutils/plans/Makefile U deskutils/plans/distinfo U devel/google-perftools/Makefile U devel/google-perftools/distinfo U devel/google-perftools/pkg-plist U devel/google-perftools/files/patch-Makefile.in U devel/google-perftools/files/patch-pprof U devel/llvm-devel/files/patch-tools_clang_include_clang_Analysis_Analyses_FormatString.h U misc/dahdi/Makefile U misc/dahdi/distinfo U misc/dahdi/pkg-plist U misc/dahdi/files/patch-bchan U misc/dahdi/files/patch-freebsd-freebsd-Makefile U misc/dahdi/files/patch-oslec U misc/dahdi/files/patch-zaphfc U sysutils/doinkd/Makefile U sysutils/doinkd/distinfo U sysutils/doinkd/pkg-descr U sysutils/doinkd/pkg-message U textproc/rubygem-liquid/Makefile U textproc/rubygem-liquid/distinfo U www/bricolage/Makefile ___ 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: math/blas linking to gfortran with LDADD?= -lgfortran
Looking closer at the math/blas math/lapack ports: This statement does not make any sense. The logic is backwards for every instance. And WITH_PROFILE would do. .if !(defined(NOPROFILE) || defined(NO_PROFILE) || defined(WITHOUT_PROFILE)) PLIST_FILES+= lib/libblas_p.a .endif Which is basically saying: Add that profile lib if NOPROFILE is not defined _p is a profiled lib why would you want to install this if the admin has NOT defined NOPROFILE? Second add that lib if NO_PROFILE is defined ? see previous question still doing the wrong thing here. Third add that lib if WITHOUT_PROFILE is defined ? see previous two question still not doing the right thing here. Simple following would do. .if (defined(WITH_PROFILE) PLIST_FILES+= lib/libblas_p.a ,endif Then if it is really a concern that this has to default to on, then use the options framework to present that to the user. At least in this instance the user will at least know whats going on. Regards, -- jhell,v ___ 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
comms/spandsp compile failure on upgrade
Hi On amd64 freebsd 7.1 Compile failure: spandsp/dc_restore.h:151: warning: incompatible implicit declaration of built- in function 'rintl' libtool: compile: cc -DHAVE_CONFIG_H -I. -I. -I. -I.. -I/usr/local/include - I/usr/local/include/libxml2 -DNDEBUG -std=gnu99 -ffast-math -Wall -Wunused- variable -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -O2 -fno- strict-aliasing -pipe -march=nocona -MT tone_generate.lo -MD -MP -MF .deps/tone_generate.Tpo -c tone_generate.c -o tone_generate.o /dev/null 21 cc -I/usr/local/include -I/usr/local/include/libxml2 -I. -o make_modem_filter make_modem_filter.c filter_tools.c -lm In file included from spandsp.h:93, from make_modem_filter.c:47: ./spandsp/t30_api.h:451: error: conflicting types for 't30_set_ecm_capability' /usr/local/include/spandsp/t30.h:803: error: previous declaration of 't30_set_ecm_capability' was here ./spandsp/t30_api.h:468: error: conflicting types for 't30_set_supported_modems' /usr/local/include/spandsp/t30.h:779: error: previous declaration of 't30_set_supported_modems' was here ./spandsp/t30_api.h:475: error: conflicting types for 't30_set_supported_compressions' /usr/local/include/spandsp/t30.h:785: error: previous declaration of 't30_set_supported_compressions' was here ./spandsp/t30_api.h:482: error: conflicting types for 't30_set_supported_resolutions' /usr/local/include/spandsp/t30.h:791: error: previous declaration of 't30_set_supported_resolutions' was here ./spandsp/t30_api.h:489: error: conflicting types for 't30_set_supported_image_sizes' /usr/local/include/spandsp/t30.h:797: error: previous declaration of 't30_set_supported_image_sizes' was here In file included from spandsp.h:93, from filter_tools.c:49: ./spandsp/t30_api.h:451: error: conflicting types for 't30_set_ecm_capability' /usr/local/include/spandsp/t30.h:803: error: previous declaration of 't30_set_ecm_capability' was here ./spandsp/t30_api.h:468: error: conflicting types for 't30_set_supported_modems' /usr/local/include/spandsp/t30.h:779: error: previous declaration of 't30_set_supported_modems' was here ./spandsp/t30_api.h:475: error: conflicting types for 't30_set_supported_compressions' /usr/local/include/spandsp/t30.h:785: error: previous declaration of 't30_set_supported_compressions' was here ./spandsp/t30_api.h:482: error: conflicting types for 't30_set_supported_resolutions' /usr/local/include/spandsp/t30.h:791: error: previous declaration of 't30_set_supported_resolutions' was here ./spandsp/t30_api.h:489: error: conflicting types for 't30_set_supported_image_sizes' /usr/local/include/spandsp/t30.h:797: error: previous declaration of 't30_set_supported_image_sizes' was here gmake[2]: *** [make_modem_filter] Error 1 gmake[2]: Leaving directory `/usr/ports/comms/spandsp/work/spandsp-0.0.5/src' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/ports/comms/spandsp/work/spandsp-0.0.5/src' gmake: *** [all-recursive] Error 1 *** Error code 1 Stop in /usr/ports/comms/spandsp. Photographic Artist Permanent Installations Design Creative Imagery and Advanced Digital Techniques High Dynamic Range Photography Official Portraiture Combined darkroom digital creations Systems Adminstrator for the vizion2000.net network ___ 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: comms/spandsp compile failure on upgrade
On Tue, Aug 31, 2010 at 7:13 PM, David Southwell da...@vizion2000.net wrote: Hi On amd64 freebsd 7.1 Strange, i tested it on 7.2-RELEASE amd64 and it built without any problem. All your other ports are up-to-date? -- Renato Botelho ___ 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: math/blas linking to gfortran with LDADD?= -lgfortran
On 8/31/10, jhell jh...@dataix.net wrote: On 08/31/2010 15:06, b. f. wrote: Would you elaborate, please? Where is a transcript showing the linking failure? Would you mail it to me off-list? Simply -lgfortran by it self should not work. Since lib directories gcc44 gcc45 gcc46 and such are not in the standard path -L/usr/local/lib/gcc44 would have to be passed to LDFLAGS in order for it to be found. Off list should not be necessary. ? gfortran44 builds the object files, and gcc44 performs the linking for the shared library. Their default search directories normally allow them to find libgfortran at compile- and link-time. And afterwards, at run-time, the appropriate rpath is inscribed in the binary (see bsd.gcc.mk: this has been done for some time now), if the system linker hints aren't sufficient. So this does not seem to explain your problem, and that's why I asked for more complete information. Since I don't want to spam the list with that volume of material, that's why I asked for it to be sent via private email. With my change in objdump the only thing listed in objdump -x that is relevant to -lgfortran is the RPATH=/usr/local/lib/gcc44 and there is no undefined symbols. As I said before, I cannot account for this -- I really need to see the complete information I requested earlier. Since gfortran44 is used to build the library components, there should be undefined symbols relating to libgfortran in all of the libraries, and the rpath should be present in both cases, if all you did was remove the explicit libgfortran from LDADD. The only difference should be the presence or absence of a DT_NEEDED tag for libgfortran. Would it be possible with this to check for the existence of -lc_p before and opt out automatically while warning the user that the profiled libc was not found so profiling will be unavailable. ? I'll look into this. There is a dichotomy here: when building from source, base system profiling libraries are built and installed by default. The same may not be true if the user installs a binary distribution, using something like systinstall(8). It should be possible to handle both cases. On your subsequent question about the form of the statement: for math/lapack, yes, the statement could be changed to fit into the OPTIONS framework. But, as I wrote before, I put it in that form to mimic the similar statements in math/blas. The statements in math/blas must take into account the NO* variables, and WITHOUT_PROFILE, because the presence of these variables in the build environment or an included makefile is what actually controls whether the profiling libraries are built, via the relevant base system makefiles in /usr/share/mk, regardless of WITH_PROFILE. I will look into using the OPTIONS framework -- in the base system makefiles, unlike in Ports, there is a sanity check on the simultaneous use of WITH_FOO and WITHOUT_FOO. So there are some added safeguards, not normally available for Ports, that may make it possible to integrate this with OPTIONS. b. ___ 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
INDEX now builds successfully on 6.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: math/blas linking to gfortran with LDADD?= -lgfortran
On 8/31/10, jhell jh...@dataix.net wrote: Looking closer at the math/blas math/lapack ports: This statement does not make any sense. The logic is backwards for every instance. And WITH_PROFILE would do. .if !(defined(NOPROFILE) || defined(NO_PROFILE) || defined(WITHOUT_PROFILE)) PLIST_FILES+= lib/libblas_p.a .endif Which is basically saying: Add that profile lib if NOPROFILE is not defined _p is a profiled lib why would you want to install this if the admin has NOT defined NOPROFILE? Er, I'm not sure what you're getting at here. No means no. Really. The default, as I explained, is to build and install the profiling libraries, unless one or more of three disabling variables has been defined. And that's the default because users of these ports often use the profiled libraries when analyzing performance of their programs, which are usually computationally-intensive. Why the three variables? Because they control whether the profiling libraries are actually built via bsd.compat.mk and bsd.lib.mk. Simple following would do. .if (defined(WITH_PROFILE) PLIST_FILES+= lib/libblas_p.a ,endif Then if it is really a concern that this has to default to on, then use the options framework to present that to the user. At least in this instance the user will at least know whats going on. As I wrote earlier, there needs to be some additional logic here, at least warnings about NO*, and maybe some other steps. There is a confluence of base system options with port options here. I will discuss it with the maintainer. b. ___ 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: math/blas linking to gfortran with LDADD?= -lgfortran
On 08/31/2010 20:06, b. f. wrote: ? gfortran44 builds the object files, and gcc44 performs the linking for the shared library. Their default search directories normally allow them to find libgfortran at compile- and link-time. And afterwards, at run-time, the appropriate rpath is inscribed in the binary (see bsd.gcc.mk: this has been done for some time now), if the system linker hints aren't sufficient. So this does not seem to explain your problem, and that's why I asked for more complete information. Since I don't want to spam the list with that volume of material, that's why I asked for it to be sent via private email. My apologies I did not mean to infer that off-list mailing of those were a problem I just did not see it as needed, technically because math/blas will simply not build without a path to the gcc44 directory i.e -L/usr/local/lib/gcc44. Mailing you separately the contents what you asked for. Everything except the build errors as those are your standard linking errors for file not found. and can be reproduced by adding garbage to LDFLAGS i.e. -lslkdfksjdhf As I said before, I cannot account for this -- I really need to see the complete information I requested earlier. Since gfortran44 is used to build the library components, there should be undefined symbols relating to libgfortran in all of the libraries, and the rpath should be present in both cases, if all you did was remove the explicit libgfortran from LDADD. The only difference should be the presence or absence of a DT_NEEDED tag for libgfortran. I'll look into this. There is a dichotomy here: when building from source, base system profiling libraries are built and installed by default. The same may not be true if the user installs a binary distribution, using something like systinstall(8). It should be possible to handle both cases. Specifically I use WITHOUT_PROFILE in src.conf(5) to ensure that those libraries do not exist on the system in question due to cases like this one. If I had not put that in there then I probably would not have been called to attention with this upgrade error and blindly would have had profiled libraries installed. I do have the libraries on hand if I should ever need profiling with the system libraries but I do not. I install these in a separate location for ease of use on testbeds. One example that I have of prevention in this case is the re-entrant version of libc. I once had to recompile libc and somehow ended up in the libc_r directory instead and after installing this lib manually for some reason or another it was being found first by every program on the system causing a slow down. Not knowing what caused that slowdown I began recompiling ports which I might add was terribly slow and after compiling 50 or so ports and having them then directly linked to libc_r I found the root cause of the problem ``libc_r'' not thinking twice about this I removed libc_r, crashed the system and had to SU in and edit libmap.conf to temporarily fix the problem until I could get all those ports recompiled again. So in short. To make sure this does not happen again on a client system re-entrant profiling are disabled on a larger scale. The side effect is I find ports that blindly link to profiled libraries. So far I can only account for these two ports in ~1.5 years of use that is about the time that the above problem arose and I decided to tend to it. On your subsequent question about the form of the statement: for math/lapack, yes, the statement could be changed to fit into the OPTIONS framework. But, as I wrote before, I put it in that form to mimic the similar statements in math/blas. The statements in math/blas must take into account the NO* variables, and WITHOUT_PROFILE, because the presence of these variables in the build environment or an included makefile is what actually controls whether the profiling libraries are built, via the relevant base system makefiles in /usr/share/mk, regardless of WITH_PROFILE. I will look into using the OPTIONS framework -- in the base system makefiles, unlike in Ports, there is a sanity check on the simultaneous use of WITH_FOO and WITHOUT_FOO. So there are some added safeguards, not normally available for Ports, that may make it possible to integrate this with OPTIONS. Here I did not define anything: pkg_delete -d blas-\* pkg_delete: file '/usr/local/lib/libblas_p.a' doesn't exist pkg_delete: couldn't entirely delete package (perhaps the packing list is incorrectly specified?) WITHOUT_PROFILE appears to work as it is supposed to by not adding that _p.a. Anyway I think Ive come to a better understanding of the issue that is really at hand with this case. It seems to me and I praise you guys/gals for being able to deal with it but there is simply to many knobs to account for things that could be handled by fewer knobs. The way I see it is WITH_ means use this and WITHOUT_ means do not use and can be contorted
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On Tue, Aug 31, 2010 at 10:06 PM, b. f. bf1...@googlemail.com wrote: On 8/31/10, jhell jh...@dataix.net wrote: Looking closer at the math/blas math/lapack ports: This statement does not make any sense. The logic is backwards for every instance. And WITH_PROFILE would do. .if !(defined(NOPROFILE) || defined(NO_PROFILE) || defined(WITHOUT_PROFILE)) PLIST_FILES+= lib/libblas_p.a .endif Which is basically saying: Add that profile lib if NOPROFILE is not defined _p is a profiled lib why would you want to install this if the admin has NOT defined NOPROFILE? Er, I'm not sure what you're getting at here. No means no. Really. The default, as I explained, is to build and install the profiling libraries, unless one or more of three disabling variables has been defined. And that's the default because users of these ports often use the profiled libraries when analyzing performance of their programs, which are usually computationally-intensive. Why the three variables? Because they control whether the profiling libraries are actually built via bsd.compat.mk and bsd.lib.mk. Actually there are only 2 *_PROFILE variables (WITH_PROFILE and WITHOUT_PROFILE) that are user visible for the FreeBSD sources. The NOPROFILE variable is depreceiated, and the NO_PROFILE variable is only supposed to be used in Makefiles according to bsd.own.mk: # Define MK_* variables (which are either yes or no) for users # to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the # make(1) environment. # These should be tested with `== no' or `!= no' in makefiles. # The NO_* variables should only be set by makefiles. So according to bsd.own.mk, this is the correct test for the math/blas port to determine if profiling libraries should be built: .if !defined(WITHOUT_PROFILE) PLIST_FILES+= lib/libblas_p.a .endif I also tested how these variables responded: vbox# cd /usr/src/lib/libcam vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE yes vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE WITH_PROFILE=yes yes yes vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE NO_PROFILE=yes no yes vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE WITHOUT_PROFILE=yes no yes vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE NOPROFILE=yes /usr/share/mk/bsd.compat.mk, line 35: warning: NOPROFILE is deprecated in favour of NO_PROFILE no yes As can be seen, NOPROFILE is deprecated. NOTE: WITHOUT_PROFILE would need to be set in /etc/make.conf (instead of /etc/src.conf) to disable building profiled libraries in the FreeBSD sources and the math/blas port. Scot ___ 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: math/blas linking to gfortran with LDADD?= -lgfortran
On 09/01/2010 00:10, Scot Hetzel wrote: On Tue, Aug 31, 2010 at 10:06 PM, b. f. bf1...@googlemail.com wrote: On 8/31/10, jhell jh...@dataix.net wrote: Looking closer at the math/blas math/lapack ports: This statement does not make any sense. The logic is backwards for every instance. And WITH_PROFILE would do. .if !(defined(NOPROFILE) || defined(NO_PROFILE) || defined(WITHOUT_PROFILE)) PLIST_FILES+= lib/libblas_p.a .endif Which is basically saying: Add that profile lib if NOPROFILE is not defined _p is a profiled lib why would you want to install this if the admin has NOT defined NOPROFILE? Er, I'm not sure what you're getting at here. No means no. Really. The default, as I explained, is to build and install the profiling libraries, unless one or more of three disabling variables has been defined. And that's the default because users of these ports often use the profiled libraries when analyzing performance of their programs, which are usually computationally-intensive. Why the three variables? Because they control whether the profiling libraries are actually built via bsd.compat.mk and bsd.lib.mk. Actually there are only 2 *_PROFILE variables (WITH_PROFILE and WITHOUT_PROFILE) that are user visible for the FreeBSD sources. The NOPROFILE variable is depreceiated, and the NO_PROFILE variable is only supposed to be used in Makefiles according to bsd.own.mk: # Define MK_* variables (which are either yes or no) for users # to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the # make(1) environment. # These should be tested with `== no' or `!= no' in makefiles. # The NO_* variables should only be set by makefiles. So according to bsd.own.mk, this is the correct test for the math/blas port to determine if profiling libraries should be built: .if !defined(WITHOUT_PROFILE) PLIST_FILES+= lib/libblas_p.a .endif I also tested how these variables responded: vbox# cd /usr/src/lib/libcam vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE yes vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE WITH_PROFILE=yes yes yes vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE NO_PROFILE=yes no yes vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE WITHOUT_PROFILE=yes no yes vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE NOPROFILE=yes /usr/share/mk/bsd.compat.mk, line 35: warning: NOPROFILE is deprecated in favour of NO_PROFILE no yes As can be seen, NOPROFILE is deprecated. NOTE: WITHOUT_PROFILE would need to be set in /etc/make.conf (instead of /etc/src.conf) to disable building profiled libraries in the FreeBSD sources and the math/blas port. Scot Thank you Scot As for src.conf Yes I know it would need to be defined in make.conf globally to effect src ports. But to my belief at the time I did not believe that anything in ports would blindly assume that setting something with profiling would be acceptable which is why I suggested the if defined(WITH_PROFILE) instead. Things that enable options like profiling usually used for debugging that is not used in general usually lead to an infestation of other targets and programs that link against them and in some cases like the -PIE instance a while back with samba and cups where something in one of the source files was configured in a way that lead to global profiling of anything that had enabled -PIE during their builds resulting in *.gprof files being created in /. This is just one of the reasons why I don't like profiling enabled without the user knowing that its going to happen. For reference PR/143924 MFC commit r205567 that happened during releng/7.2 days. Regards Thank you again. -- jhell,v ___ 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: math/blas linking to gfortran with LDADD?= -lgfortran
On 9/1/10, Scot Hetzel swhet...@gmail.com wrote: On Tue, Aug 31, 2010 at 10:06 PM, b. f. bf1...@googlemail.com wrote: On 8/31/10, jhell jh...@dataix.net wrote: So according to bsd.own.mk, this is the correct test for the math/blas port to determine if profiling libraries should be built: .if !defined(WITHOUT_PROFILE) PLIST_FILES+= lib/libblas_p.a .endif No, you are leaving the order out of account. Apart from local and custom makefiles, the makefiles are included so: /usr/share/mk/sys.mk /etc/make.conf /usr/share/mk/bsd.compat.mk usr/share/mk/bsd.cpu.mk Makefile(for math/blas) /usr/share/mk/bsd.port.mk /usr/share/mk/bsd.own.mk /usr/ports/Mk/bsd.port.mk /usr/ports/Mk/bsd.commands.mk /usr/ports/Mk/bsd.perl.mk /usr/ports/Mk/bsd.gcc.mk /usr/ports/Mk/bsd.perl.mk /usr/ports/Mk/bsd.licenses.mk /usr/ports/Mk/bsd.sites.mk ... So if NO_PROFILE or NOPROFILE is defined, a test for WITHOUT_PROFILE in Makefile will still fail because NO_PROFILE is not mapped to WITHOUT_PROFILE until bsd.own.mk, after the test. Just be patient and we'll sort it out. As can be seen, NOPROFILE is deprecated. It may be deprecated, but it will still take effect without BURN_BRIDGES, and so still must be accounted for. NOTE: WITHOUT_PROFILE would need to be set in /etc/make.conf (instead of /etc/src.conf) to disable building profiled libraries in the FreeBSD sources and the math/blas port. No, it will still take effect, after the math/blas Makefile is parsed, unless _WITHOUT_SRCCONF is defined. See bsd.own.mk. b. ___ 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: math/blas linking to gfortran with LDADD?= -lgfortran
On 09/01/2010 00:58, b. f. wrote: No, it will still take effect, after the math/blas Makefile is parsed, unless _WITHOUT_SRCCONF is defined. See bsd.own.mk. ports(7) pulls in src.conf ??? I hope I am not understanding this right... -- jhell,v ___ 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: math/blas linking to gfortran with LDADD?= -lgfortran
On 09/01/2010 01:14, jhell wrote: On 09/01/2010 00:58, b. f. wrote: No, it will still take effect, after the math/blas Makefile is parsed, unless _WITHOUT_SRCCONF is defined. See bsd.own.mk. ports(7) pulls in src.conf ??? I hope I am not understanding this right... No wonder why some of my ports are fricking ticking my counters with ccache! (!...@#!%#$%#@!$...@# !...@#!$@#...@% @$...@$@%...@#^) Now that I know I can burn that bridge right now by adding that to make.conf in a .if (.CURDIR:M/usr/ports*) FF Sakes. Thank you. -- jhell,v ___ 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
