Re: About games/flightgear-aircrafts
On Fri, Oct 14, 2011 at 09:14:46AM +0200, Ganael LAPLANCHE wrote: On Thu, 6 Oct 2011 10:29:32 +0200 (CEST), Ganael LAPLANCHE wrote Hi Everyone, I've established a first selection by following the main aircraft page : http://www.flightgear.org/download/aircraft-v2-4/ and removing alpha/beta/experimental/early-production planes. I'll try to shorten this list one way or another and come back with a limited aircraft list. If somebody wants a plane to be added to it, just tell me : I'll update it. I'll try to work on that ASAP, but I am currently very busy, so don't expect any change before a few weeks. Following my previous post, here is a selection of planes I've made. They will remain available in the flightgear-aircrafts port, any other plane will be removed and will have to be installed manually : * 737-200_20110713.zip : Boeing 737-200 * A-10_20110629.zip : Fairchild A-10 * A300_20101217.zip : Airbus A300 * Alouette-II_20110523.zip : Alouette II * Alphajet_20110228.zip : Dassault/Dornier Alphajet * B-17_20110516.zip : Boeing B17 * Breguet-XIX_20101217.zip : Breguet XIX * C130_20101217.zip : C130 Hercules * Caravelle_20101217.zip : Caravelle * Caudron-G3_20101217.zip : Caudron G.III * F80C_20101217.zip : Lockheed F-80C Shooting Star * Hurricane_20110815.zip : Hawker Hurricane IIb * Lightning_20110705.zip : English Electric Lightning F.1A * Lockheed1049h_1.0.zip : Lockheed 1049H Super Constellation * Messerschmitt-P1101_20101217.zip : Messerschmitt Me P1101 * MirageIII_20110124.zip : Mirage IIING * PaperAirplane_20110103.zip : Paper airplane * Pond-Racer_20101217.zip : Rutan Pond Racer * R44_20110523.zip : Robinson R44 * Spitfire_20110705.zip : Supermarine Spitfire * Stieglitz_20101217.zip : Focke Wulf FW44 Stiegltz * Super-Etendard_20110324.zip : Dassault-Breguet Super Etendard * Supermarine-S.6B_20110118.zip : Supermarine S6B * Superwal_20101217.zip : Dornier Superwal * airwaveXtreme150_20101217.zip : Airwave Xtreme 150 hang glider * asw20_20101217.zip : ASW-20 sailplane * bf109_20110629.zip : Messerschmitt BF-109 G14 * c310_20110113.zip : Cessna 310 * dhc3_20110411.zip : DHC 3 Otter * f16_20110629.zip : General Dynamics F-16 * pa24-250_20110222.zip : Piper Comanche 250 * tu154_20101217.zip : Tupolev 154 This (now very limited) list includes every plane in the 'production' state, as well as well-known or seemingly interesting ones (no devel, beta, alpha, or pre-production ones). I have also tried to keep a wide variety of planes available. This list will make the port maintainable again. Anyway, it is far from perfect ; also, if a plane is missing, do not hesitate to contact me : I'll just add it. I don't know which aircraft are in the base package (flightgear-data), but IMHO: * harrier : British Aerospace Harrier is something known and interesting (vertical takeoff/landing), * il2 : Ilyoushin IL-2 is also quite famous WWII attack plane and * wrightFlyer1903 : 1903 Wright Flyer is must have :) I'll commit the changes within 15 days if there is no complaint about this list. Thanks for taking care if the port! Alexey (with 0.03 air$). ___ 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: About games/flightgear-aircrafts
As for me, I have played fgfs some time ago (5 years?), so... On Thu, Sep 22, 2011 at 08:21:24PM +0200, Ganael LAPLANCHE wrote: On Thu, 22 Sep 2011 09:38:33 -0400, Greg Larkin wrote You can also break them by first letter of the distfile names, combining where appropriate. [...] This would not solve any problems with the port, only add troubles for the end-user. On Thu, 22 Sep 2011 09:57:58 -0400, Robert Huff wrote my first reaction was to break it into broad categories. For example: aircraft-required aircraft-25-most-popular aircraft-civilian-prop [...] On Thu, 22 Sep 2011 16:58:03 +0200, Guido Falsi wrote A civialian-aerobatic category could be sensible. [...] Greg, Robert, Guido, thanks for your suggestions ; anyway, this would not solve one of the problems : maintainability of the port :/ Well, this depends, how many aircraft would go into each of categories. See below... On Thu, 22 Sep 2011 08:11:39 -0600 (MDT), Warren Block wrote #2 is reasonable, IMO. Other options, like breaking it up into multiple ports, would not make it easier to maintain and might be more difficult for users. Warren, I agree with you : it would make the port even more complex. From a maintainer port of view, we will still have to keep up-to-date with those 350+ zip files which regularly change upstream, but will now have to deal with sorting them and updating several different ports. From a user point of view, it would also be a pain : users would have to browse into each category ports to be able to get all the planes they need. I am not sure this is the right way to go :/ I would also vote for #2, or, if we can get a limited list of good airplanes, option #1. I will try to find if I can get a list of top planes on FLightGear website, but I have not seen such a page so far. I have not looked what is needed to install new aircraft as a user, but it it would be something against the habbits of a typical FreeBSD user. At least I would certainly forget to update an aircraft installed this way... (Note: aircraft is both singular and plural, so the port name really should be just flightgear-aircraft.) Thanks, I'll fix its name if we can manage to keep this port alive :) From my experiency a while ago, the quality of the aircraft models varied greatly from model to model. I remember, there was some transition from one simulation engine to another more advanced one (JSBsim - YASim or vice versa?). For example, some WW II planes were able to perfom back loop in the simulator, which is a non-sense... So, my 0.02$ is if you are somewhat familiar with at least some of aircraft, you can chose those which are mature enough (such as default Cessna 172). From another point of view, you are the maintainer of the port, so it is up to you to decide (according to your personal prefereces) which aircraft to include in the port. If somebody lacks his favorite aircraft, he is free to create another aircraft add-on port, after all... HTH, Alexey. ___ 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: tinderbox question
On Fri, Jun 17, 2011 at 06:24:57PM +0400, Ruslan Mahmatkhanov wrote: 17.06.2011 18:14, Ruslan Mahmatkhanov пишет: Good day. How can i `inject` updated (or new) port into tinderbox Build to test it for correctness? I mean i have not any troubles to build any existing port, but what should i do to place updated or new port into the tinderbox portstree? Ok, it seems i got it. I have /usr/local/tinderbox/8.2-FreeBSD/usr/ports/ that is symlinked to /usr/local/tinderbox/8.2-FreeBSD/a/ports/. It's nullfs mounted fs and it's read-only. I realise that i can just patch /usr/local/tinderbox/portstrees/FreeBSD/ports to achive this goal, but i'm not sure if this is Right Thing or there is some another correct way. This procedure isn't mentioned in Tinderbox Users Guide (maybe it should be too obvious) so i ask there. Thanks. Well, I think it is too obvious. Or, to say better, there are too many ways to do it. Personally, I build official ports in tinderbox. So, I null-mount /usr/ports to whatever tinderbox wants it to. If I want to test updated port I move original category/port to caterogy/port.orig and place the new port into category/port (all under /usr/ports). After testing I remove category/port and move original port back. This way csup/portsnap works as usual, keeping /usr/ports up-to-date. The big changes like marcuscom or area51 repos are handled the same way, but globally. So mv /usr/ports /usr/ports.orig, then copy/patch/fetch/... the new ports tree into /usr/ports, test the things, and move back at the end. I find this strategy optimal for occasional ports testing, if you are continiously working with the side repos like above, adding multiple ports trees into tinderbox is (IMHO) the way to go. This is described in tinderbox README. HTH, Alexey. ___ 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: 2nd deprecation campaign
On Thu, Jun 16, 2011 at 05:05:31PM +0200, Baptiste Daroussin wrote: 2011/6/16 Baptiste Daroussin b...@freebsd.org: Hi all, I am in the middle of a new deprecation campaign, to remove ports where no more distfiles are publicly available (no other OS mirrors doesn't count except if they are the upstream of course). Maybe some will be false positive (I will try to not have too much of them). Do not hesitate to manifest and undeprecate ports that would have deprecated by mistake. Even better do not hesitate to propose yourself to maintain them. Thanks, Bapt The list of deprecated ports can be find there: http://www.freshports.org/ports-expiration-date.php I think you can add java/jai-imageio to the list. I have not managed to find the distfile even google-ing. 0.02$, Alexey. ___ 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: 2nd deprecation campaign
On Thu, Jun 16, 2011 at 09:24:42PM +0400, Ruslan Mahmatkhanov wrote: 16.06.2011 20:45, Alexey Shuvaev пишет: On Thu, Jun 16, 2011 at 05:05:31PM +0200, Baptiste Daroussin wrote: 2011/6/16 Baptiste Daroussinb...@freebsd.org: Hi all, I am in the middle of a new deprecation campaign, to remove ports where no more distfiles are publicly available (no other OS mirrors doesn't count except if they are the upstream of course). Maybe some will be false positive (I will try to not have too much of them). Do not hesitate to manifest and undeprecate ports that would have deprecated by mistake. Even better do not hesitate to propose yourself to maintain them. Thanks, Bapt The list of deprecated ports can be find there: http://www.freshports.org/ports-expiration-date.php I think you can add java/jai-imageio to the list. I have not managed to find the distfile even google-ing. 0.02$, Alexey. It should be downloaded manually from here: http://java.sun.com/products/java-media/jai/downloads/download-iio.html That would be too easy :) Have you actually opened this page? For me, it is empty. As I have stated: I have not managed to find the distfile even google-ing. So, I still think the port is quite dead. ___ 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: 2nd deprecation campaign
On Thu, Jun 16, 2011 at 10:38:34PM +0400, Ruslan Mahmatkhanov wrote: 16.06.2011 22:33, Alexey Shuvaev пишет: On Thu, Jun 16, 2011 at 09:24:42PM +0400, Ruslan Mahmatkhanov wrote: 16.06.2011 20:45, Alexey Shuvaev пишет: On Thu, Jun 16, 2011 at 05:05:31PM +0200, Baptiste Daroussin wrote: 2011/6/16 Baptiste Daroussinb...@freebsd.org: Hi all, I am in the middle of a new deprecation campaign, to remove ports where no more distfiles are publicly available (no other OS mirrors doesn't count except if they are the upstream of course). Maybe some will be false positive (I will try to not have too much of them). Do not hesitate to manifest and undeprecate ports that would have deprecated by mistake. Even better do not hesitate to propose yourself to maintain them. Thanks, Bapt The list of deprecated ports can be find there: http://www.freshports.org/ports-expiration-date.php I think you can add java/jai-imageio to the list. I have not managed to find the distfile even google-ing. 0.02$, Alexey. It should be downloaded manually from here: http://java.sun.com/products/java-media/jai/downloads/download-iio.html That would be too easy :) Have you actually opened this page? For me, it is empty. As I have stated: I have not managed to find the distfile even google-ing. So, I still think the port is quite dead. I just downloaded distfile using procedure mentioned before w/o any problems and place it into /usr/ports/distfiles: smeshariki2# make extract === License check disabled, port has not defined LICENSE === Extracting for jai-imageio-1.0_2 = SHA256 Checksum OK for jai_imageio-1_0-lib-linux-i586.tar.gz. So it looks like your local problem. Ok, examining the page source I have found the right download link. Seems Oracle is doing something that my seamonkey does not like :( The case is closed, java/jai_imageio is OK. ___ 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: OO 3.3.0 fails to build moz module on amd64 8-STABLE
On Sun, May 08, 2011 at 10:12:35PM +0900, Maho NAKATA wrote:
Hi
Thanks for your report. I'm aware of this issue, since my OOo build
is broken at the same place. Sorry and I don't have a clue yet, but,
I guess from folllowing error message, somehow moz module
invoke make instead gmake.
Makefile:83: *** missing separator. Stop.
thanks,
Nakata Maho
From: Lawrence Stewart lstew...@freebsd.org
Subject: OO 3.3.0 fails to build moz module on amd64 8-STABLE
Date: Sun, 08 May 2011 13:51:36 +1000
Hi,
I've attempted to build OO 3.3.0 on two separate machines set up from
scratch recently and both are unable to complete the OO build.
My most recent attempt to build is with a ports tree cvsup'd yesterday
(2011-05-07) and all my installed ports were built from the ports tree
and are up to date. Some details about the system:
lstewart@lstewart-laptop uname -a
FreeBSD lstewart-laptop 8.2-STABLE FreeBSD 8.2-STABLE #0 r221492: Fri
May 6 00:41:20 EST 2011
lstewart@lstewart-laptop:/usr/obj/usr/src/sys/GENERIC amd64
Relevant lines from /etc/make.conf:
.if ${.CURDIR:M*/editors/openoffice.org-3}
WITH_KDE4=1
LOCALIZED_LANG=en-GB
The workaround could be to add
WITHOUT_MOZILLA=yes
here.
.endif
I'm running KDE 4.6.2.
The problem stems from the moz build module. Here are the last few
lines of console output when the make dies:
HTH,
Alexey.
___
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: graphics/simpleviewer doesn't build on head(?)
On Fri, Apr 08, 2011 at 07:07:02AM +, Alexey Dokuchaev wrote: On Fri, Apr 08, 2011 at 01:50:27AM -0500, Zhihao Yuan wrote: Whatever... I don't like this image viewer. While this viewer is far from perfect, I find that it at least works (contrary to gliv which dumps core on me both now and many years ago when I first discovered it) and performs scaling correctly (unlike pho, which is currently my viewer of choice). I'd happily switch to anything at least as good as default viewer in windoze xp, but have not seen anything decent so far. Maybe you can recommend something which is not part of Gnome or KDE? graphics/geeqie, it uses gtk but not gnome 0.02$, Alexey. ___ 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: [WORKAROUND] www/seamonkey2 on CURRENT
On Fri, Jan 28, 2011 at 05:37:51PM -0800, Garrett Cooper wrote:
On Fri, Jan 28, 2011 at 3:58 PM, Alexey Shuvaev
shuv...@physik.uni-wuerzburg.de wrote:
Hello!
It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
Examining build log and reproducing it locally, the problem is in the
usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
produce libxpcom_core.so although -L/usr/local/lib and -liconv
are specified [2]. Examining this further I found that
nsNativeCharsetUtils.o
produced with [3] fails to link with libiconv alone too [4] (note
still unresolved libiconv references).
I'm not a compiler/linker guru and do not understand what is happening
here. As a workaroud I use the attached patch which disables the usage
of libiconv in nsNativeCharsetUtils.cpp.
ls /usr/local/lib/libiconv*so* ?
~ ll /usr/local/lib/libiconv*so*
lrwxr-xr-x 1 root wheel 13 Jan 27 13:14 /usr/local/lib/libiconv.so -
libiconv.so.3
-r--r--r-- 1 root wheel 1078567 Jan 27 13:14 /usr/local/lib/libiconv.so.3
I'm not so lame :)
On Sat, Jan 29, 2011 at 01:39:15PM -0500, Alexander Kabaev wrote:
On Sat, 29 Jan 2011 13:21:44 -0500
Alexander Kabaev kab...@gmail.com wrote:
On Sat, 29 Jan 2011 13:02:24 -0500 (EST)
Daniel Eischen deisc...@freebsd.org wrote:
On Sat, 29 Jan 2011, Alexey Shuvaev wrote:
Hello!
It seems www/seamonkey2 is broken on CURRENT for at least 1 month
now [1]. Examining build log and reproducing it locally, the
problem is in the usage of libiconv in nsNativeCharsetUtils.cpp.
The linker fails to produce libxpcom_core.so although
-L/usr/local/lib and -liconv are specified [2]. Examining this
further I found that nsNativeCharsetUtils.o produced with [3]
fails to link with libiconv alone too [4] (note still unresolved
libiconv references). I'm not a compiler/linker guru and do not
understand what is happening here. As a workaroud I use the
attached patch which disables the usage of libiconv in
nsNativeCharsetUtils.cpp.
Yes, I had this problem also on -current. Does seamonkey build
on recent 8.x?
libxpcomio_s.a is a static library that has unresolved references
to libiconv. I guess I'd expect those references to be resolved
with a later -L/usr/local/lib -liconv when building the shared
library (libxpcom_core.so), but they are not.
My wild guess: seamonkey tries to hide symbols that are coming from
different .o file (this time one from libiconv.a) and that fails with
our toolchain.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
--
Alexander Kabaev
Follow-up to myself: Nope, the fix to said bug appears in our compiler.
Can you make amd64 version of nsNativeCharsetUtils.
--
Alexander Kabaev
??? (It is already on amd64)
Well, I have fogotten to put my environment:
~ uname -a
FreeBSD lexx.ifp.tuwien.ac.at 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r217884: Wed
Jan 26 17:00:37 CET 2011
r...@lexx.ifp.tuwien.ac.at:/usr/obj/usr/src/sys/GENERIC amd64
And here is the winner:
On Sat, Jan 29, 2011 at 08:32:07AM +0300, Anonymous wrote:
Alexey Shuvaev shuv...@physik.uni-wuerzburg.de writes:
Hello!
It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
Examining build log and reproducing it locally, the problem is in the
usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
produce libxpcom_core.so although -L/usr/local/lib and -liconv
are specified [2]. Examining this further I found that
nsNativeCharsetUtils.o
produced with [3] fails to link with libiconv alone too [4] (note
still unresolved libiconv references).
I'm not a compiler/linker guru and do not understand what is happening
here. As a workaroud I use the attached patch which disables the usage
of libiconv in nsNativeCharsetUtils.cpp.
[...]
/usr/bin/ld: aaa: hidden symbol `libiconv_open' isn't defined
/head per r215840 has working -fvisibility=hidden, i.e. config/gcc_hidden.h.
Try following diff, it should enable patching iconv.h wrapper in bsd.gecko.mk
@${ECHO_CMD} #pragma GCC system_header ${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} #pragma GCC visibility push(default)
${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} #include \${LOCALBASE}/include/iconv.h\
${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} #pragma GCC visibility pop ${MOZSRC}/${subdir}/iconv.h
%%
Index: www/seamonkey2/Makefile
===
RCS file: /a/.cvsup/ports/www/seamonkey2/Makefile,v
retrieving revision 1.315
diff -u -p -r1.315 Makefile
--- www/seamonkey2/Makefile 10 Dec 2010 13:31:12 - 1.315
+++ www/seamonkey2/Makefile 29 Jan 2011 05:22:11 -
@@ -28,11 +28,10 @@ ALL_TARGET= default
MAKE_JOBS_SAFE= yes
MOZ_PIS_SCRIPTS= moz_pis_S50cleanhome
MAKE_ENV=LD_LIBRARY_PATH=${WRKSRC}/dist/bin
-CONFIGURE_ENV
Re: [CFT] cpu stresser^W libreoffice 3.3.0 final
On Fri, Jan 28, 2011 at 03:09:24PM -0800, Chip Camden wrote:
Quoth Baptiste Daroussin on Friday, 28 January 2011:
Hi all
I ported libreoffice 3.3.0, you can find it here:
http://people.freebsd.org/~bapt/libreoffice.shar or
http://git.etoilebsd.net/ports/tree/libreoffice
Can you please test it?
by default it builds without java. it only lacks kde and gnome
integration. (sorry but my poor CPU already hates enough :))
All languages supported are build.
I try to avoid as much as possible bundled libraries which gives a
pretty fast compiling libreoffice (on a Q6600: ~2h without java, ~3h30
with java)
at this points :
there is (I guess) only one remaining problem :
which launching libreoffice it can't find it libraries, I haven't
decided yet wether to add LD_LIBRARY_PATH to the wrapper script or to
add ldconfig -m ${PREFIX}/lib/libreoffice/ure/lib and ldconfig -m
${PREFIX}/lib/libreoffice/base3.3/program
maybe it conflicts with openoffice I haven't checked yet.
to test it you will need a fresh ports tree (the needed libtextcat
modification was committed yesterday thanks thierry@)
the mandatory screenshot :
http://people.freebsd.org/~bapt/libreoffice-3.3.0-final.png
I expect to be able to push it in the tree during next week (after
finding a good way to deal with the libraries and checked if it
conflicts with openoffice)
I would like to thanks Robert Nagy from openbsd, he has made all the
hard work :), he was also very helpful.
regards,
Bapt
___
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'm getting the following on a make. Followed the instructions, and
sdext seemed to build OK, but the make in the top-level still gets the
same error:
sw deliver
Module 'sw' delivered successfully. 0 files copied, 281 files unchanged
Module 'scp2' delivered successfully. 89 files copied, 12 files unchanged
---
Oh dear - something failed during the build - sorry !
For more help with debugging build errors, please see the section in:
http://wiki.documentfoundation.org/Development
internal build errors:
ERROR: error 65280 occurred while making
/usr/home/sterling/src/ports/libreoffice/work/libreoffice-build-3.3.0.4/build/libreoffice/sdext/source/presenter
ERROR: error 65280 occurred while making
/usr/home/sterling/src/ports/libreoffice/work/libreoffice-build-3.3.0.4/build/libreoffice/lingucomponent/source/languageguessing
it seems you are using a threaded build, which means that the
actual compile error is probably hidden far above, and could be
inside any of these other modules:
lingucomponent
please re-run build inside each one to isolate the problem.
---
/usr/local/bin/bash
cd
/usr/home/sterling/src/ports/libreoffice/work/libreoffice-build-3.3.0.4/build/libreoffice
source ./FreeBSDAMDEnv.Set.sh
cd sdext
build
when the problem is isolated and fixed exit and re-run 'make' from the
top-level
sometimes (sadly) it is necessary to rm -Rf unxfbsdx.pro in a module.
gmake: *** [stamp/build] Error 1
*** Error code 1
Stop in /usr/home/sterling/src/ports/libreoffice.
*** Error code 1
Stop in /usr/home/sterling/src/ports/libreoffice.
[root@libertas /usr/home/sterling/src/ports/libreoffice]#
FYI, the build of 'stock' openoffice.org-3 is broken in multijob mode
on recent CURRENT (quad-core):
~ uname -a
FreeBSD lexx.ifp.tuwien.ac.at 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r217884: Wed
Jan 26 17:00:37 CET 2011
r...@lexx.ifp.tuwien.ac.at:/usr/obj/usr/src/sys/GENERIC amd64
I'm working this around with this in make.conf:
.if ${.CURDIR:M*/editors/openoffice.org-*}
#WITH_SYSTEM_FREETYPE= yes
WITHOUT_GNOME= yes
WITHOUT_MOZILLA=yes
DISABLE_MAKE_JOBS= 1
.endif
Is LibreOffice really MAKE_JOBS_SAFE?
0.02$,
Alexey.
___
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
[WORKAROUND] www/seamonkey2 on CURRENT
Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that nsNativeCharsetUtils.o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. My little more than 0.02$, Alexey. [1]: http://portsmon.freebsd.org/portoverview.py?category=wwwportname=seamonkey2wildcard= [2]: c++ -I/usr/local/include/nss -I/usr/local/include/nss/nss -I/usr/local/include -I/usr/local/include -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -O2 -pipe -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -fPIC -shared -Wl,-z,defs -Wl,-h,libxpcom_core.so -o libxpcom_core.so pldhash.o nsArrayEnumerator.o nsArrayUtils.o nsCategoryCache.o nsCOMPtr.o nsCOMArray.o nsCRTGlue.o nsComponentManagerUtils.o nsEnumeratorUtils.o nsID.o nsIInterfaceRequestorUtils.o nsINIParser.o nsISupportsImpl.o nsMemory.o nsWeakReference.o nsGREGlue.o nsVersionComparator.o nsTHashtable.o nsQuickSort.o nsVoidArray.o nsTArray.o nsThreadUtils.o nsTObserverArray.o nsCycleCollectionParticipant.o nsDeque.o nsAutoLock.o nsGenericFactory.o nsProxyRelease.o nsTextFormatter.o nsXPComInit.o nsXPCOMStrings.o -pthread -L/usr/local/lib/nss -Wl,-rpath,/usr/local/lib/seamonkey -lc -Wl,-rpath-link,/work/a/ports/www/seamonkey2/work/comm-1.9.1/mozilla/dist/bin -Wl,-rpath-link,/work/a/ports/www/seamonkey2/work/fake/lib -Wl,--whole-archive ../ds/libxpcomds_s.a ../io/libxpcomio_s.a ../components/libxpcomcomponents_s.a ../threads/libxpcomthreads_s.a ../proxy/src/libxpcomproxy_s.a ../base/libxpcombase_s.a ../reflect/xptcall/src/libxptcall.a ../reflect/xptcall/src/libxptcmd.a ../reflect/xptinfo/src/libxptinfo.a ../../dist/lib/libxpt.a ../string/src/libstring_s.a -Wl,--no-whole-archive -L/usr/local/lib -lplds4 -lplc4 -lnspr4 -pthread -pthread -L/usr/local/lib -lgtk-x11-2.0 -latk-1.0 -lgdk-x11-2.0 -lpangocairo-1.0 -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lgdk_pixbuf-2.0 -lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lgio-2.0 -lXfixes -lgobject-2.0 -lgmodule-2.0 -lpng -lz -lm -lgthread-2.0 -lglib-2.0 -lcairo -lX11 -lm -pthread -lm -pthread -pthread -L/usr/local/lib -liconv ../io/libxpcomio_s.a(nsNativeCharsetUtils.o)(.text+0x32): In function `xp_iconv(void*, char const**, unsigned int*, char**, unsigned int*)': : undefined reference to `libiconv' [3]: c++ -o nsNativeCharsetUtils.o -c -I../../dist/include/system_wrappers -include ../../config/gcc_hidden.h -DMOZILLA_INTERNAL_API -DMOZ_SUITE=1 -DOSTYPE=\FreeBSD9\ -DOSARCH=FreeBSD -D_IMPL_NS_COM -I.. -I. -I. -I../../dist/include/string -I../../dist/include -I../../dist/include/xpcom -I/usr/local/include/nspr -I/usr/include -I/usr/local/include -fPIC -I/usr/local/include/nss -I/usr/local/include/nss/nss -I/usr/local/include -I/usr/local/include -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -O2 -pipe -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -Os -fno-strict-aliasing -I/usr/local/include/nss -I/usr/local/include/nss/nss -I/usr/local/include -I/usr/local/include -DMOZILLA_CLIENT -include ../../mozilla-config.h nsNativeCharsetUtils.cpp [4]: c++ -o aaa nsNativeCharsetUtils.o -L/usr/local/lib -liconv /usr/lib/crt1.o(.text+0x8a): In function `_start': : undefined reference to `main' nsNativeCharsetUtils.o(.text+0x16): In function `xp_iconv(void*, char const**, unsigned long*, char**, unsigned long*)': : undefined reference to `libiconv' nsNativeCharsetUtils.o(.text+0x571): In function `nsNativeCharsetConverter::GlobalShutdown()': : undefined reference to `PR_DestroyLock' nsNativeCharsetUtils.o(.text+0x58e): In function `nsNativeCharsetConverter::GlobalShutdown()': : undefined reference to `libiconv_close' nsNativeCharsetUtils.o(.text+0x5ab): In function `nsNativeCharsetConverter::GlobalShutdown()': : undefined reference to `libiconv_close' nsNativeCharsetUtils.o(.text+0x5c8): In function `nsNativeCharsetConverter::GlobalShutdown()': : undefined reference to `libiconv_close' nsNativeCharsetUtils.o(.text+0x5e5): In function `nsNativeCharsetConverter::GlobalShutdown()': : undefined reference to `libiconv_close' nsNativeCharsetUtils.o(.text+0x602): In function `nsNativeCharsetConverter::GlobalShutdown()': :
Re: Suggestions on getting compiz working?
On Sun, Nov 21, 2010 at 05:35:20PM -0800, Doug Barton wrote: Any ideas? I've tried the suggestions at http://www.freebsd.org/doc/en/articles/compiz-fusion/index.html and they don't work for me. Original Message Subject: Suggestions on getting compiz working? Date: Wed, 10 Nov 2010 22:21:28 -0800 From: Doug Barton do...@dougbarton.us Organization: http://SupersetSolutions.com/ To: freebsd-gn...@freebsd.org I've been multi-booting FreeBSD, Windows, and Ubuntu linux, and the default window manager for Ubuntu is compiz (with gnome of course). It works well, and I was hoping to get it working in FreeBSD. I tried several different configuration options that I found from searching on line, but didn't have any success, not even trying to run it all by itself (using startx). So does anyone have compiz working with gnome on FreeBSD? The CPU and RAM on this system are pretty beefy, even though the Intel GPU is fairly run of the mill. OTOH, it works in linux ... Mmm... Error messages, back traces, etc.? I think, you know, doesn't work would not bring you much :) As a general note, composite + opengl always was a troublesome combination. And the state of the intel graphics driver on freebsd is also not the best. 0.02$, Alexey. ___ 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: Combining several upgrades using portmaster
On Tue, Nov 09, 2010 at 09:19:21AM -0800, Doug Barton wrote: On 11/09/2010 06:09, Dmitry Pryanishnikov wrote: Hello! I wonder whether it's possible to automatically combine several upgrades using portmaster. Suppose one have to handle both ports/UPDATING entries: 20100530: suggests portmaster -w -r gettext 20100328: suggests portmaster -r png- It would be nice to combine them as ' portmaster -w -r gettext -r png-' to prevent double upgrade of relevant packages; however '-r' can be specified only once according to manpage. I've handled this by running both commands, replying 'n' to 'Proceed?' question, merging resulting origin list with sort|uniq and feeding it back to portmaster, but maybe there is a simpler way to solve the problem? The number of times that -r is actually required is (thankfully) quite small, and the number of times that there is a need to do 2 -r's of ports that are heavily depended on is very very small. In fact I can only remember a few such instances over 15+ years. OTOH, the code to handle the -r feature is unfortunately quite complex, and I'm a little hesitant to mess with it (to be honest, mostly because it's working right now, so I don't want to tempt fate). :) I will, however, add this idea to my big list o' portmaster ideas and see if it's something I could tackle at a future date. In the case that you catch 2 or more sweeping updates it is very likely that you are updating across rather large time interval (half of a year or more). In this case I usually ignore all '-r' UPDATING entries and do just portmaster -a. The idea is that almost all ports have got updated in this large period of time too. Of course, you shold keep an eye on the system after such upgrade, manualy reinstalling ports that fail to find old shared library. But normally there are very few of them. (From my experience, freetype2 is regulary one of them.) 0.02$, Alexey. ___ 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: xorg-server 1.7.7
On Mon, Nov 08, 2010 at 11:22:37AM +0200, Andriy Gapon wrote: Can we update xorg-server to 1.7.7, the latest version on 1.7 branch? It looks like that would require only changing the version and regenerating the checksums. Seems to be not so trivial. Look at this thread: http://lists.freebsd.org/pipermail/freebsd-ports/2010-May/061141.html Since miwi@ and rnoland@ seem to be busy at moment there is a need for the maintainer of ALL of the xorg-* ports (and not only the single ones, like xorg-server, etc.). Someone with enough time, motivation (hardware, programming foo in this area...) Just 0.02$, :-( Alexey. ___ 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: xorg-server 1.7.7
On Mon, Nov 08, 2010 at 05:11:41PM +0200, Andriy Gapon wrote: on 08/11/2010 17:03 Alexey Shuvaev said the following: On Mon, Nov 08, 2010 at 11:22:37AM +0200, Andriy Gapon wrote: Can we update xorg-server to 1.7.7, the latest version on 1.7 branch? It looks like that would require only changing the version and regenerating the checksums. Seems to be not so trivial. Look at this thread: http://lists.freebsd.org/pipermail/freebsd-ports/2010-May/061141.html Since miwi@ and rnoland@ seem to be busy at moment there is a need for the maintainer of ALL of the xorg-* ports (and not only the single ones, like xorg-server, etc.). Someone with enough time, motivation (hardware, programming foo in this area...) Oh, forgot a need to simply bump port revisions of all xorg driver ports. That's perhaps a little bit laborious, but doesn't require any special skills. Or did you have something else in mind? Well, I'm successfully running xorg-server-1.7.7 since May without doing anything else to other xorg-related ports: xorg-server-1.7.7,1succeeds index (index has 1.7.5,1) but it could be just a matter of luck :) I mean this (from rnolad): I have an update to 1.7.7 queued up in my tree along with an updated pixman. It is a little tedious as all of the server based ports need to be updated and drivers need PORTREVISION bumps. I'll try and get it committed in the next couple of days though. He mentions update (not just PORTREVISION bump) of pixman and other server-based ports. I have some vague insight into what he means, but I'd say it should be done by a person more familiar (than me) with xorg infrastucture with all its interdependencies. Alexey. ___ 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: Crash using OSS when trying to rewind html5 video
On Tue, Oct 26, 2010 at 10:02:10AM +0200, Beat Gaetzi wrote: On 25.10.2010 23:03, Ilya A. Arhipov wrote: Crash using OSS when trying to rewind html5 video. You can look here: https://bugzilla.mozilla.org/show_bug.cgi?id=605861 Also i create pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=151728 Committed. Thanks! www/seamonkey2 is also affected. TIA, Alexey. ___ 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: ptlib build failure - breaks pwlib - hence also asterisk - opal - openh323
On Tue, Sep 21, 2010 at 12:29:50PM -0400, Mikhail T. wrote: 21.09.2010 12:05, David Southwell написав(ла): Problem is opal does not compile due to failure which was in original posting: According to: http://pointyhat.freebsd.org/errorlogs/i386-8-latest-logs/opal-2.2.11_2.log.bz2 Opal builds just fine -- in the clean environment... As does ptlib: http://pointyhat.freebsd.org/errorlogs/i386-8-latest-logs/ptlib-2.4.4.log.bz2 Which means, there is something about your configuration, that interferes with the build. I'm not blaming you -- ports (unlike packages) ought to be flexible and build properly in a variety of configurations. The price for that flexibility, however, is having to deal with an occasional breakage, when your setup deviates too far from the mainstream. But you need to, at least, diagnose the problem yourself. Does the presence of some unusual package break the build? Any other unexpected setting/configuration option? Include that info in a PR, so that the problem can be reproduced... Thanks! Yours, To OP (David Southwell): Do you have openssl installed from ports (so it shows up in pkg_info output)? That might be the cause of your build failures while pointyhat cluster builds affected ports without errors. To port maintainers: Could you try to build your ports in the presence of openssl installed from ports? 0.02$, Alexey. ___ 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-mgmt/tinderbox: fix i386 jail on amd64 host on 9-CURRENT
Hello!
I've recently bumped into the issue which was already discussed
on current@:
http://lists.freebsd.org/pipermail/freebsd-current/2010-July/018638.html
In short, in the ports' tinderbox, i386 jail fails on the amd64 host
during make distribution step. This configuration, while
not strictly supported, is rather usefull.
It looks like it hasn't been fixed in the repository or in ports.
I can confirm that the proposed patch:
http://lists.freebsd.org/pipermail/freebsd-current/2010-July/018676.html
fixes the build of i386 jail on amd64 host.
Attached is an updated patch-lib-tc_command.sh.new which could be
dropped into the files directory of ports-mgmt/tinderbox port
instead of the current file.
Could interested people (cc-ed) check it on other releases and
propagate it upstream?
Thanks,
Alexey.
--- lib/tc_command.sh.orig 2009-11-27 18:32:31.0 +0100
+++ lib/tc_command.sh 2010-09-07 16:50:24.0 +0200
@@ -223,7 +223,7 @@
#---
Setup () {
-MAN_PREREQS=lang/perl5.[81]
+MAN_PREREQS=lang/perl5.[81]*
OPT_PREREQS=lang/php[45] databases/pear-MDB2 www/php[45]-session
PREF_FILES=tinderbox.ph
README=$(tinderLoc scripts README)
@@ -774,10 +774,10 @@
# determine if we're cross-building world
crossEnv=
if [ ${jailArch} != ${myArch} ]; then
- crossEnv=TARGET_ARCH=${jailArch} MACHINE_ARCH=${jailArch}
MAKEOBJDIRPREFIX=${J_OBJDIR}/${jailArch} MACHINE=${jailArch}
+ crossEnv=TARGET_ARCH=${jailArch}
fi
-cd ${SRCBASE}/etc env DESTDIR=${J_TMPDIR} ${crossEnv} \
- make -m ${J_TMPDIR}/usr/share/mk distribution
${jailBase}/distribution.tmp 21
+cd ${SRCBASE} env DESTDIR=${J_TMPDIR} ${crossEnv} \
+ make distribution ${jailBase}/distribution.tmp 21
if [ $? -ne 0 ]; then
echo ERROR: distribution failed - see ${jailBase}/distribution.tmp
buildJailCleanup 1 ${jailName} ${J_SRCDIR}
___
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: Testing editors/emacs-devel on 9-CURRENT
On Mon, Sep 06, 2010 at 09:52:18AM +0530, Ashish SHUKLA wrote: Hi everyone, Could some running 9-CURRENT try building a package of editors/emacs-devel port (latest version available in the tree) with default OPTIONS ? Something like: #v+ % script emacs-devel.log sudo make -C /usr/ports/editors/emacs-devel build deinstall package #v- And after building the package, could you paste the generated log (emacs-devel.log) at some pastebin[1] and post a link here, irrespective of any errors you received ? Here is the tinderbox log on amd64 9-CURRENT: http://pastebin.com/h1P2V41r The build for i386 9-CURRENT is underway. The ports tree is from 3 Sep, but the base used for the tinderbox is rather old, it is from ~18 May. I can rebuild it to the host sources which are at r212182 from 3 Sep, but it will take some time :) HTH, Alexey. ___ 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: replacing audio/libmpcdec by audio/musepack
On Sat, May 29, 2010 at 12:50:30PM +0200, Stefan Ehmann wrote:
Hi,
I'm the maintainer of audio/musepack. With the last update, it now provides
libmpdec.so. About 15 ports currently use the older shared library provided
by
audio/libmpcdec (maintained by multimedia@, CCed).
For now, mutual CONFLICTS are registered.
What I'm planning to do is update all depending ports to use audio/musepack,
thus making audio/libmpcdec obsolete.
I have some questions before I'll start working on this task:
- Are there any objections to deprecating libmpcdec and replacing it by
musepack? According to the website, libmpcdec version is Old. Refer to above
SV8 lib (compatible with SV7).
After creating a patch for updating and testing:
- Should I ask the maintainers of the affected ports for approval?
I've tested musicpd and vlc so far and update was pretty straight-forward:
replace
LIB_DEPENDS+= mpcdec.5:${PORTSDIR}/audio/libmpcdec
by
LIB_DEPENDS+= mpcdec.7:${PORTSDIR}/audio/musepack
and bump the port revision.
Because both ports conflict, upgrading needs manual intervention. I guess I
should prepare an entry for UPDATING?
Anything I forgot or other thoughts?
Not that I am using either of them but... libmpcdec is a stand-alone library
while musepack depends on audio/esound. Is this dependency non-avoidable?
0.02$,
Alexey.
___
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: Xorg 7.5 and Openmotif applications.
On Fri, May 28, 2010 at 07:16:28PM +, Christian Weisgerber wrote: Alexey Shuvaev shuv...@physik.uni-wuerzburg.de wrote: Alas, this does not address the problem with mwm(1). Hmmm... This is something new. I am successfully running math/grace with xorg-server 1.7.7. Could you describe what problems with mwm do you see? As soon as you have multiple windows on the screen (two xterms are enough) and switch between them, all input is ignored. You can move the pointer, but mouse clicks are ignored, as are keystrokes. Ok, reproduced. Note that in order to get this hang you should click on the text area of xterm. Switching by clicking on the window's titles seems to work. ___ 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: Xorg 7.5 and Openmotif applications.
On Thu, May 27, 2010 at 08:33:12PM +, Christian Weisgerber wrote: Alexey Shuvaev shuv...@physik.uni-wuerzburg.de wrote: Since there was no activity on this issue I have updated xorg-server to 1.7.7. I have not seen any problems so far. Any objections against updating xorg-server from 1.7.5 to 1.7.7? Alas, this does not address the problem with mwm(1). Hmmm... This is something new. I am successfully running math/grace with xorg-server 1.7.7. Could you describe what problems with mwm do you see? Alexey. ___ 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: Xorg 7.5 and Openmotif applications.
On Thu, May 27, 2010 at 11:17:28PM +0200, Alexey Shuvaev wrote: On Thu, May 27, 2010 at 08:33:12PM +, Christian Weisgerber wrote: Alexey Shuvaev shuv...@physik.uni-wuerzburg.de wrote: Since there was no activity on this issue I have updated xorg-server to 1.7.7. I have not seen any problems so far. Any objections against updating xorg-server from 1.7.5 to 1.7.7? Alas, this does not address the problem with mwm(1). Hmmm... This is something new. I am successfully running math/grace with xorg-server 1.7.7. Could you describe what problems with mwm do you see? I have tried mwm now and don't see any problems. On the other hand I am not that familiar with mwm to say for sure. Alexey. ___ 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: Xorg 7.5 and Openmotif applications.
On Tue, May 11, 2010 at 08:21:19PM +0200, Alexey Shuvaev wrote: On Tue, May 11, 2010 at 09:03:08AM -0500, Robert Noland wrote: Alexey Shuvaev wrote: Hello list! There seems to be a known/fixed bug in new xserver that leads to (many|all?) motif-based applications to malfunction: https://bugs.freedesktop.org/show_bug.cgi?id=25400 There are already at least 2 PRs opened against individual ports: http://www.freebsd.org/cgi/query-pr.cgi?pr=146383 http://www.freebsd.org/cgi/query-pr.cgi?pr=146380 I think it is wrong to patch applications when the fault seems to be in the server. Now I am running patched xserver with the patch pulled from the upstream git master: http://cgit.freedesktop.org/xorg/xserver/commit/?id=1c612acca8568fcdf9761d23f112adaf4d496f1b I confirm that math/grace now works OK (PR 141383). I'll watch if the patch causes any side effects (nothing so far). What about dropping attached patch to x11-servers/xorg-server/files? Cross-posting to ports@ as the bug already leaked in the individual ports' PRs. Let's look at updating to 1.7.7 or 1.8.0. I need to poke the commit logs for 1.7.7 and see if it is included. Even better so. Just downloaded xorg-server-1.7.7.tar.gz and the patch is already there: [snip] |--- dix/events.c.orig |+++ dix/events.c -- Patching file dix/events.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] n Since there was no activity on this issue I have updated xorg-server to 1.7.7. I have not seen any problems so far. Any objections against updating xorg-server from 1.7.5 to 1.7.7? Should I file PR? Alexey. diff -ruN xorg-server.orig/Makefile xorg-server/Makefile --- xorg-server.orig/Makefile 2010-05-10 15:16:42.0 +0200 +++ xorg-server/Makefile2010-05-26 15:10:16.0 +0200 @@ -6,7 +6,7 @@ # PORTNAME= xorg-server -PORTVERSION= 1.7.5 +PORTVERSION= 1.7.7 PORTEPOCH= 1 CATEGORIES=x11-servers MASTER_SITES= http://xorg.freedesktop.org/releases/individual/xserver/ diff -ruN xorg-server.orig/distinfo xorg-server/distinfo --- xorg-server.orig/distinfo 2010-05-10 15:16:42.0 +0200 +++ xorg-server/distinfo2010-05-26 15:14:10.0 +0200 @@ -1,3 +1,3 @@ -MD5 (xorg/xserver/xorg-server-1.7.5.tar.bz2) = 2856130aebf56e3df7b7d9be419bfb28 -SHA256 (xorg/xserver/xorg-server-1.7.5.tar.bz2) = 91e5f3d05c3e7270f4122235b6ab071210cc79579dcb842ffd4e71199b6bb7aa -SIZE (xorg/xserver/xorg-server-1.7.5.tar.bz2) = 4926990 +MD5 (xorg/xserver/xorg-server-1.7.7.tar.bz2) = 8c0146330fb155c23d947ac37d431d4b +SHA256 (xorg/xserver/xorg-server-1.7.7.tar.bz2) = 54c4d32bfeb8852adbea3ddae6981f3bc2eadb330124d9b35226c617c01926ff +SIZE (xorg/xserver/xorg-server-1.7.7.tar.bz2) = 4939257 ___ 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: Porting SANE backend 1.0.21 to FreeBSD 7.2
On Sun, May 23, 2010 at 02:00:46PM -0700, Mark Terribile wrote:
Thanks to help from Warren Block and Lowell Gilbert,
I now have the offical ported version of sane-backends-1.0.21 running.
Unfortunately, it's behaving the same way as before,
apparently not properly recognizing the USB device. It
Does anyone have experience using this?
I have zero experience using SANE, but...
Or better yet, some sense of what it needs from the USB side?
I think the right answer is 'nothing'.
A clue on enabling the internal debugging would also be welcome.
I have added
product CANON CS8800F0x1901CanoScan 8800F
to /usr/src/sys/dev/usb/usbdevs. I have also added
{{ USB_VENDOR_CANON, USB_PRODUCT_CANON_CS8800F }, 0 },
to /usr/src/sys/dev/usb/uscanner.c
I think this is wrong and may cause all of your problems. I have heard
somewhere that the right way of accessing USB scanners on FreeBSD
is through libusb.
That is, your scanner *should not be recognized* by uscanner driver and
*should not appear* in /dev/.
When I run scanimage -L I get
-
device `pixma:04A91901' is a CANON Canoscan 8800F multi-function peripheral
---
When I run scanimage -d pixma:04A9101 I get
scanimage: sane_read: Invalid argument
Which I have traced to a defaulted fill routine in a table.
scanimage --help gives me a message ending with
---
Options specific to device `pixma:04A91901':
Scan mode:
--resolution auto||75|150|300|600|1200|2400|4800dpi [75]
Sets the resolution of the scanned image.
--mode auto|Color|Gray [Color]
Selects the scan mode (e.g., lineart, monochrome, or color).
--source Flatbed|Transparency Unit [Flatbed]
Selects the scan source (such as a document-feeder).
--button-controlled[=(yes|no)] [no]
When enabled, scan process will not start immediately. To proceed,
press SCAN button (for MP150) or COLOR button (for other models).
To cancel, press GRAY button.
Gamma:
--custom-gamma[=(auto|yes|no)] [yes]
Determines whether a builtin or a custom gamma-table should be used.
--gamma-table auto|0..255,...
Gamma-correction table. In color mode this option equally affects the
red, green, and blue channels simultaneously (i.e., it is an intensity
gamma table).
Geometry:
-l auto|0..216.069mm [0]
Top-left x position of scan area.
-t auto|0..297.011mm [0]
Top-left y position of scan area.
-x auto|0..216.069mm [216.069]
Width of scan-area.
-y auto|0..297.011mm [297.011]
Height of scan-area.
Buttons:
--button-update
Update button state
--button-1 int [0]
Button 1
--button-2 int [0]
Button 2
Type ``scanimage --help -d DEVICE'' to get list of all options for DEVICE.
List of available devices:
There is a /dev/usb/uscanner .
I haven't figured out how to turn on the internal debugging system, so my
first question to someone who may have ported an earlier version is how to do
that.
My second question is whether I have the USB entries right,
and whether I need to do anything else to make this work.
Try reverting all your changes and look how it goes with
stock sane from ports.
And finally, I ask for any general wisdom or hints in dealing with SANE and
SANE with USB devices.
HTH,
Alexey.
___
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
Xorg 7.5 and Openmotif applications.
Hello list!
There seems to be a known/fixed bug in new xserver that leads to
(many|all?) motif-based applications to malfunction:
https://bugs.freedesktop.org/show_bug.cgi?id=25400
There are already at least 2 PRs opened against individual ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=146383
http://www.freebsd.org/cgi/query-pr.cgi?pr=146380
I think it is wrong to patch applications when the fault seems to be
in the server. Now I am running patched xserver with the patch pulled
from the upstream git master:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=1c612acca8568fcdf9761d23f112adaf4d496f1b
I confirm that math/grace now works OK (PR 141383).
I'll watch if the patch causes any side effects (nothing so far).
What about dropping attached patch to x11-servers/xorg-server/files?
Cross-posting to ports@ as the bug already leaked in the individual
ports' PRs.
Thanks,
Alexey.
From 1c612acca8568fcdf9761d23f112adaf4d496f1b Mon Sep 17 00:00:00 2001
From: Peter Hutterer peter.hutte...@who-t.net
Date: Wed, 17 Mar 2010 04:32:38 +
Subject: dix: if owner-events is true for passive grabs, add the window mask
(#25400)
A client requesting a GrabModeSync button grab, owner-events true, with only
the ButtonRelease mask set would never receive the press event even if the
grab window had the ButtonPress mask set.
The protocol requires that if owner-events is true, then the delivery mask
is the combination of the grab mask + the window event mask.
X.Org Bug 25400 http://bugs.freedesktop.org/show_bug.cgi?id=25400
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Tested-by: Jim Ramsay i...@jimramsay.com
Signed-off-by: Keith Packard kei...@keithp.com
---
diff --git a/dix/events.c b/dix/events.c
index 0e9bc31..6541652 100644
--- dix/events.c.orig
+++ dix/events.c
@@ -3552,6 +3552,8 @@ CheckPassiveGrabsOnWindow(
xE = core;
count = 1;
mask = grab-eventMask;
+if (grab-ownerEvents)
+mask |= pWin-eventMask;
} else if (match XI2_MATCH)
{
rc = EventToXI2((InternalEvent*)event, xE);
@@ -3573,6 +3575,24 @@ CheckPassiveGrabsOnWindow(
mask =
grab-xi2mask[device-id][((xGenericEvent*)xE)-evtype/8];
else if (event-type == XI_Enter || event-type == XI_FocusIn)
mask = grab-xi2mask[device-id][event-type/8];
+
+if (grab-ownerEvents wOtherInputMasks(grab-window))
+{
+InputClientsPtr icp =
+wOtherInputMasks(grab-window)-inputClients;
+
+while(icp)
+{
+if (rClient(icp) == rClient(grab))
+{
+int evtype = (xE) ? ((xGenericEvent*)xE)-evtype :
event-type;
+mask |= icp-xi2mask[device-id][evtype/8];
+break;
+}
+
+icp = icp-next;
+}
+}
} else
{
rc = EventToXI((InternalEvent*)event, xE, count);
@@ -3584,6 +3604,22 @@ CheckPassiveGrabsOnWindow(
continue;
}
mask = grab-eventMask;
+if (grab-ownerEvents wOtherInputMasks(grab-window))
+{
+InputClientsPtr icp =
+wOtherInputMasks(grab-window)-inputClients;
+
+while(icp)
+{
+if (rClient(icp) == rClient(grab))
+{
+mask |= icp-mask[device-id];
+break;
+}
+
+icp = icp-next;
+}
+}
}
(*grabinfo-ActivateGrab)(device, grab, currentTime, TRUE);
___
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: Xorg 7.5 and Openmotif applications.
On Tue, May 11, 2010 at 09:03:08AM -0500, Robert Noland wrote: Alexey Shuvaev wrote: Hello list! There seems to be a known/fixed bug in new xserver that leads to (many|all?) motif-based applications to malfunction: https://bugs.freedesktop.org/show_bug.cgi?id=25400 There are already at least 2 PRs opened against individual ports: http://www.freebsd.org/cgi/query-pr.cgi?pr=146383 http://www.freebsd.org/cgi/query-pr.cgi?pr=146380 I think it is wrong to patch applications when the fault seems to be in the server. Now I am running patched xserver with the patch pulled from the upstream git master: http://cgit.freedesktop.org/xorg/xserver/commit/?id=1c612acca8568fcdf9761d23f112adaf4d496f1b I confirm that math/grace now works OK (PR 141383). I'll watch if the patch causes any side effects (nothing so far). What about dropping attached patch to x11-servers/xorg-server/files? Cross-posting to ports@ as the bug already leaked in the individual ports' PRs. Let's look at updating to 1.7.7 or 1.8.0. I need to poke the commit logs for 1.7.7 and see if it is included. Even better so. Just downloaded xorg-server-1.7.7.tar.gz and the patch is already there: ~/xorg-server-1.7.7 patch ../patch-dix-events.c Hmm... Looks like a unified diff to me... The text leading up to this was: -- |From 1c612acca8568fcdf9761d23f112adaf4d496f1b Mon Sep 17 00:00:00 2001 |From: Peter Hutterer peter.hutte...@who-t.net [snip] |--- dix/events.c.orig |+++ dix/events.c -- Patching file dix/events.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] n Thanks for takiing care of it! Alexey. ___ 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: databases/sqlite3 build fails
On Fri, Apr 23, 2010 at 11:58:18AM -0700, Doug Barton wrote: On 04/23/10 11:52, Sean McAfee wrote: I can confirm this behavior on multiple installs of 8.0Rp2 amd64. I don't use (or want) TCL, but tried to build it with TCL 8.4, 8.5, and 8.6 installed with no luck. I just gave up and pkg_add -r'ed it. I run -current, so: === The newest available package (sqlite3-3.6.19) is older than the version in ports (sqlite3-3.6.23.1_1) I don't use tcl either, so I just let sqlite install the default as a dependency: tcl-8.5.8 Not sure, if I ran into the same problem, but I recall that sqlite3 needs an option TCL_MODULES turned on in lang/tcl85. Or, better, try to install tcl-modules by hand and see, if it helps. If it does, should sqlite3 port directly depend on tcl-modules? The problem doesn't manifest itself on the package clusters as TCL_MODULES turned on by default. HTH, Alexey. ___ 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: looking for simple 3d plotting program
On Thu, Apr 08, 2010 at 11:05:15AM -0400, Robert Huff wrote:
Robert Huff writes:
I have a project for which I need to produce a {gif, jpg, png}
of a 3d space, with labled axes, and plot a small number (25 ??) of
points within it, either with labels or as icons.
Two constraints:
Current code is written in C.
I expressed myself badly. What I should have said was:
It must be usable via C function calls.
Not the best and the most elegant way to achieve this, but...
you can try math/gnuplot. It can do 3d.
CC=gcc
CCFLAGS= -g -Wall
LDFLAGS= -lm -lpthread
target= testgnuplot
objects= testgnuplot.o gnuplot.o
all: $(target)
$(target): $(objects)
$(CC) $(LDFLAGS) $(objects) -o $@
%.o: %.c
$(CC) $(CCFLAGS) -c $ -o $@
clean:
rm -f $(objects)
rm -f $(target)
gnuplot.c implements a helper function that invokes gnuplot
to display the acquired data.
You need to have the gnuplot package installed to take advantage
of this function.
You can reuse it in your program by adding the gnuplot.c and
gnuplot.h files to your project and calling the function:
int sendDataToGnuplot(int handle, float x0, float dX,
double *buffer, int nbOfPointsPerCh,
int nbOfCh);
handle is the handle of the acquisition session returned by _PdAquireSubsystem.
x0 is the origin of the x axis
dX is the increment between each points on the x axis
buffer contains the acquired data
nbOfPointsPerCh contains the number of sampels acquired for each channel
nbOfCh contains the number of channels
___
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: Old ports bugs analyzis
On Tue, Mar 30, 2010 at 01:05:39AM +0400, Eir Nym wrote:
I work on creating system for system and ports autobuilder with custom
settings for my FreeBSD machines. I know about many programs, which do
same, but I don't like strange depends, which are not controlled by
OPTIONS and some another
I've analyse ports tree and want to say about.
There're lot problems with ports to create per-port PRs
manually.Common types of problems are listed here:
0) Main part of problems in tons of ports, which has hidden options
(WITH WITHOUT checking), but not using OPTIONS for them.
1) There many libraries added with BUILDRUN dependencies, not as LIB-DEPENDS.
2) Some ports has only BUILD depends to libraries, but links them dynamicly.
3) All(?) samba33 slaves define dependency as samba33, and make
warning me about master target redefinition when do something on them.
4) many ports define dependencies as
${.CURDIR}/../../category/dep-port-name
5) And some adds trailing slash.
I want fix these problems, but I have no much time to fix several
thousands of ports. This work (include PR sending) needs about is 1-2
month per 8-10 hours a day.
If the problems are so common, maybe there are not so many problems
at all? :)
I put my analysys in several work files:
I've removed ${PORTSDIR} from paths for readability in index files.
http://freebsd.eroese.org/bsd.local.mk - different describe target
(clean and simple)
http://freebsd.eroese.org/portInfo.py - py-IDX maker. old, but enough version.
http://freebsd.eroese.org/tag - portsnap(8) tag
http://freebsd.eroese.org/IDX - special maked IDX
http://freebsd.eroese.org/py-IDX - human readable format of IDX, see
py program for comments about types.
I have tried to understand what is in these files but have not managed
it completely.
The file py-IDX lists 2 of my ports, devel/slglade and
x11-toolkits/gtkdatabox as being fixed:
fix devel/slglade
fix x11-toolkits/gtkdatabox
Could you elaborate more what was 'fixed' in these 2 examples?
Thanks,
Alexey.
___
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
Silent distfiles conflict between graphics/xface.el and mail/x-face-e21.
Hello! Could please someone with emacs knowledge (preferably ports commiter) look into issue http://www.freebsd.org/cgi/query-pr.cgi?pr=141839 Both ports refer distfiles with the same name but of different sizes (and checksums). It looks like one port is a subset of another, but I am not familiar with emacs to say for sure. Both maintainers, yoichi@ and ume@ haven't responded to private mails yet. Thanks, Alexey. ___ 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/syslog-ng3 processes
On Fri, Feb 26, 2010 at 04:51:25PM +0200, Marin Atanasov wrote: Hello, I've noticed that when I start syslog-ng3 daemon it starts two processes. I haven't seen this when running syslog-ng. Here are the processes: root 554 0.0 0.1 5320 2092 ?? I 4:46PM 0:00.00 /usr/local/sbin/syslog-ng -p /var/run/syslog.pid root 555 0.0 0.1 5320 2456 ?? Ss4:46PM 0:00.02 /usr/local/sbin/syslog-ng -p /var/run/syslog.pid I was wondering why it actually start two (identical?) processes? Anyone has an idea? Is this normal? I think this would happen if you have two different scripts in /usr/local/etr/rc.d that launch the same daemon. I think the names of the scripts do not matter here. Do you have any stale rc.d scripts in /usr/local/etr/rc.d? HTH, Alexey. ___ 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/xfce4-netload-plugin - why is it marked as broken on 8?
On Wed, Feb 10, 2010 at 10:33:35PM +0100, Torfinn Ingolfsen wrote:
Hello,
On Fri, Jan 15, 2010 at 7:41 PM, Greg Larkin glar...@freebsd.org wrote:
This commit log refers to the fact that the value of __FreeBSD_version
was bumped to 800045 due to the removal of the if_ppp(4) driver. You
can find all of the historical values of that variable here:
http://www.freebsd.org/doc/en/books/porters-handbook/freebsd-versions.html
In this case, the port Makefile should be patched like so:
- --- Makefile.orig 2010-01-15 13:37:50.374330422 -0500
+++ Makefile2010-01-15 13:38:04.101133409 -0500
@@ -24,7 +24,7 @@
.include bsd.port.pre.mk
- -.if ${OSVERSION} = 80
+.if ${OSVERSION} = 800045
Well, that value doesn't work anymore. Here's the rub:
r...@kg-v2# uname -a
FreeBSD kg-v2.kg4.no 8.0-STABLE FreeBSD 8.0-STABLE #1: Wed Jan 6 21:21:40
CET 2010 r...@kg-v2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64
r...@kg-v2# pwd
/usr/ports/sysutils/xfce4-netload-plugin
r...@kg-v2# make
=== xfce4-netload-plugin-0.4.0_10 is marked as broken: does not compile:
error: net/if_ppp.h: No such file or directory.
*** Error code 1
Stop in /usr/ports/sysutils/xfce4-netload-plugin.
According to param.h, the value is now 800108. if_ppp.h is still present,
and the port compiles fine if I comment out the three lines reagarding the
BROKEN meaasge.
You have stale files in your system. From /usr/src/ObsoleteFiles.inc:
# 20090406: usb_sw_transfer.h removed
OLD_FILES+=usr/include/dev/usb/usb_sw_transfer.h
# 20090405: removal of if_ppp(4) and if_sl(4)
OLD_FILES+=sbin/slattach rescue/slattach
OLD_FILES+=sbin/startslip rescue/startslip
OLD_FILES+=usr/include/net/if_ppp.h
OLD_FILES+=usr/include/net/if_pppvar.h
OLD_FILES+=usr/include/net/if_slvar.h
OLD_FILES+=usr/include/net/ppp_comp.h
OLD_FILES+=usr/include/net/slip.h
OLD_FILES+=usr/sbin/sliplogin
You should do 'make delete-old' and 'make delete-old-libs' during upgades.
A better fix might be to port the code from using if_ppp(4) to the
replacement ppp(8), as noted in the commit log.
Probably. I don't know how to do that. Sorry.
___
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: Puzzled about gettext dependencies
On Thu, Feb 11, 2010 at 09:08:08PM +0100, Andrea Venturoli wrote: Il 02/10/10 13:21, Alexey Shuvaev ha scritto: The port autodetects the presence of these libraries and drags them in. Taking a closer look at this it turned out that aDe@ has dropped maintainership of what is referred to as 'autotools'. Not good :( What follows is just an attempt to fix the problem, however it doesn't :) and it seems that the port deserves more attention. A little bit more than 0.02$, Alexey. Thanks Alexey. I admit I didn't try your patch, since you said in advance it doesn't work. I really haven't understood whether this is a bug (or feature) in gettext or autotools (autoconf?). Should I fill a PR in? Yes, it is non-critical bug in devel/gettext. ___ 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: Puzzled about gettext dependencies
On Tue, Feb 09, 2010 at 04:01:01PM -0800, Chuck Swiger wrote:
Hi--
On Feb 9, 2010, at 3:53 PM, Andrea Venturoli wrote:
# pkg_which /usr/local/bin/msgcat
gettext-0.17_1
# ldd /usr/local/bin/msgcat
/usr/local/bin/msgcat:
libgettextsrc-0.17.so = /usr/local/lib/libgettextsrc-0.17.so
(0x33c7f000)
libgettextlib-0.17.so = /usr/local/lib/libgettextlib-0.17.so
(0x33cb4000)
libcroco-0.6.so.3 = /usr/local/lib/libcroco-0.6.so.3 (0x33d91000)
libxml2.so.5 = /usr/local/lib/libxml2.so.5 (0x33dc6000)
libz.so.4 = /lib/libz.so.4 (0x33ef2000)
libm.so.5 = /lib/libm.so.5 (0x33f04000)
libglib-2.0.so.0 = /usr/local/lib/libglib-2.0.so.0 (0x33f19000)
libintl.so.8 = /usr/local/lib/libintl.so.8 (0x33fc8000)
libpcre.so.0 = /usr/local/lib/libpcre.so.0 (0x33fd1000)
libncurses.so.7 = /lib/libncurses.so.7 (0x34004000)
libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x34043000)
libc.so.7 = /lib/libc.so.7 (0x3413a000)
libz.so.3 = /lib/libz.so.3 (0x3423c000)
libm.so.4 = /lib/libm.so.4 (0x3424d000)
Is it me or the output of the latter command contraddicts the dependency
database?
It seems to me libcroco, libglib, libpcre, and libxml2 are additional
dependencies...
Have I done something wrong?
It doesn't do that here:
# pkg_which /usr/local/bin/msgcat
gettext-0.17_1
# ldd /usr/local/bin/msgcat
/usr/local/bin/msgcat:
libgettextsrc-0.17.so = /usr/local/lib/libgettextsrc-0.17.so
(0x2807e000)
libgettextlib-0.17.so = /usr/local/lib/libgettextlib-0.17.so
(0x280b2000)
libncurses.so.6 = /lib/libncurses.so.6 (0x281b2000)
libintl.so.8 = /usr/local/lib/libintl.so.8 (0x281f1000)
libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x281fa000)
libc.so.6 = /lib/libc.so.6 (0x282d9000)
I wonder why it's dragged in all of those...?
The port autodetects the presence of these libraries and drags them in.
Taking a closer look at this it turned out that aDe@ has dropped
maintainership of what is referred to as 'autotools'. Not good :(
What follows is just an attempt to fix the problem, however it doesn't :)
and it seems that the port deserves more attention.
A little bit more than 0.02$,
Alexey.
diff -ruN /usr/ports/devel/gettext/Makefile gettext/Makefile
--- /usr/ports/devel/gettext/Makefile 2009-12-19 19:54:28.0 +0100
+++ gettext/Makefile2010-02-10 13:14:41.0 +0100
@@ -30,7 +30,10 @@
CPPFLAGS=-I${LOCALBASE}/include \
LDFLAGS=-L${LOCALBASE}/lib \
EMACS=no
-CONFIGURE_ARGS=--disable-csharp --disable-threads --disable-openmp
+CONFIGURE_ARGS=--disable-csharp --disable-threads --disable-openmp \
+ --without-libintl-prefix --with-included-glib \
+ --with-included-libcroco --with-included-libxml \
+ --disable-java
USE_LDCONFIG= yes
PLIST_SUB= VERSION=${PORTVERSION}
@@ -53,15 +56,6 @@
EXTRA_PATCHES+=${FILESDIR}/extra-patch-nodocs
.endif
-pre-extract:
-.if exists(${PREFIX}/bin/kaffe)
- @${ECHO_MSG} Gettext won't build with Kaffe's jar utility. Doing:
- -${MV} ${PREFIX}/bin/jar ${PREFIX}/bin/jar.backup
- @${ECHO_MSG} Be sure to mv ${PREFIX}/bin/jar.backup ${PREFIX}/bin/jar
- @${ECHO_MSG} if you abandon your attempt to build gettext.
- @sleep 5
-.endif
-
post-patch:
@${FIND} ${WRKSRC} -name configure -print | ${XARGS} \
${REINPLACE_CMD} -e 's|mkdir gmkdir|mkdir|'
@@ -72,14 +66,6 @@
.endfor
.endif
-post-build:
-.if exists(${PREFIX}/bin/kaffe)
- -${MV} ${PREFIX}/bin/jar.backup ${PREFIX}/bin/jar
- @${ECHO_MSG}
- @${ECHO_MSG} Your ${PREFIX}/bin/jar has been restored.
- @sleep 5
-.endif
-
post-install:
.for f in po-compat.el po-mode.el
@${INSTALL_DATA} ${WRKSRC}/gettext-tools/misc/${f} \
___
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: [SDL-1.2.14] Build fails on the libvlg checking
On Sun, Jan 31, 2010 at 05:40:22PM +0100, Marcus von Appen wrote: On, Sun Jan 31, 2010, David Marec wrote: Le dimanche 31 janvier 2010 14:27:19, Marcus von Appen a écrit : /usr/lib/libvgl.* should not be available on RELENG_8, amd64 - instead it should reside in /usr/lib32 only. Did you upgrade from i386 to amd64 or did you manually link the libvgl.* to /usr/lib? Neither of them. The system is amd64 from the begining. If so, please remove them or run make config and disable the VGL knob (or add 'WITHOUT_VGL=true' to the make invocation). That s what i did. And it still does not work for you? But, if, for example, svgalib is tagged i386 only, svgl is not. If I manually link libvgl.* from /usr/lib32 to /usr/lib and rebuild SDL with VGL enabled, anything links properly. I am not sure, what's wrong on your side. If it still fails for you after disabling the VGL knob, could you please send me the config.log from /usr/ports/devel/sdl12/work/SDL-1.2.14 as well as the tee'd output from your make invocation: make | tee sdlbuild.log btw, should i remove these libs ? I do not recommend to do that manually. Which shared library versions of libvgl are installed (output of find /usr/lib -name *vgl*) on your side? Did you ever run make delete-old or make delete-old-libs after updating the system? Just FYI, libvgl is built natively on amd64 now: Revision 197025 - (view) (annotate) - [select for diffs] Modified Wed Sep 9 09:50:31 2009 UTC (4 months, 3 weeks ago) by delphij File length: 3386 byte(s) Diff to previous 194869 - Teach vesa(4) and dpms(4) about x86emu. [1] - Add vesa kernel options for amd64. - Connect libvgl library and splash kernel modules to amd64 build. - Connect manual page dpms(4) to amd64 build. - Remove old vesa/dpms files. Submitted by: paradox ddkprog yahoo com [1], swell k at gmail.com (with some minor tweaks) Alexey. ___ 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] Experimental 3D HW accel support for Radeon HD 2xxx, 3xxx and 4xxx, 2nd!
On Tue, Dec 22, 2009 at 12:26:38AM -0600, Robert Noland wrote: On Mon, 2009-12-21 at 04:58 +0900, Norikatsu Shigemura wrote: On Mon, 21 Dec 2009 00:34:22 +0900 Norikatsu Shigemura n...@ninth-nine.com wrote: I'm ready to update ports related Mesa3D to 7.6 base, graphics/dri, graphics/libGL*, graphics/libglut, graphics/mesa-demos and graphics/libdrm. Please see also my attached patch file. I'll update these as soon as tomorrow. Reworking for 7.6.1-rc4. Please test attached patch. I've put a patch of 7.6.1 release at: http://people.freebsd.org/~rnoland/mesa-7.6.1-release.patch As much as I don't want to, I need to request a repo copy of libdrm in order to keep nouveau working... The bits needed for r600 were added just after 2.4.12 and the bits that broke nouveau were just before 2.4.13... +1 for keeping nouveau working. Alexey. ___ 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: Ports marked as IGNORE - (cups-pdf) (urlview) why - how long?
On Tue, Dec 22, 2009 at 11:23:58AM +, David Southwell wrote: David Southwell wrote: Hi just curious about: - print/cups-pdf (marked as IGNORE) - textproc/urlview (marked as IGNORE) Anyone know what is happening with these? Get IGNORE with portupgrade -a. $ cd /usr/ports/print/cups-pdf $ make === cups-pdf-2.5.0 is marked as broken: does not install. *** Error code 1 Stop in /usr/local/ports/print/cups-pdf. $ portmaster . === Port directory: /usr/ports/print/cups-pdf === This port is marked BROKEN === does not install === If you are sure you can build it, remove the BROKEN line in the Makefile and try again. hth, Doug PS, Josh, if this e-mail address still works for you, howdy! :) I am wondering what changes have taken place to change this from a functioning port to one that justifies it being labelled as broken. It must have compiled OK for me as I already have cups-pdf-2.5.0 installed which appears to be the same version. I heard some rumour that it was failing on ubuntu but not on freebsd. Is there any truth in that? Is there any provision to ensure that something which should be marked as broken for ubuntu is not, in consequence,automatically marked as broken when on freebsd? dns1# pkg_info |grep cups cups-base-1.4.2_3 Common UNIX Printing System: Server cups-client-1.4.2_3 Common UNIX Printing System: Library cups cups-image-1.4.2_3 Common UNIX Printing System: Library cupsimage cups-pdf-2.5.0 A virtual printer for CUPS to produce PDF files cups-pstoraster-8.15.4_4 Postscript interpreter for CUPS printing to non-PS printers cups-samba-6.0_2The Common UNIX Printing System: MS Windows client drivers cups-smb-backend-1.0_2 A CUPS backend for printing to Windows servers gnome-cups-manager-0.31_10,1 Admistration tool for cups gutenprint-cups-5.2.4 GutenPrint Printer Driver libgnomecups-0.2.3_2,1 Support library for gnome cups admistration py26-cups-1.9.46CUPS bindings for Python dns1# Strange, but you can try to figure out what happening at pointyhat: http://people.freebsd.org/~fenner/errorlogs/si...@olofsson.de-date.html 0.02$, Alexey. ___ 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: Newbie question about additional documentation
On Mon, Nov 23, 2009 at 09:23:18PM +0100, dave wrote: On Mon, 2009-11-23 at 12:21 +, Matthew Seaman wrote: David Fries wrote: Hi everybody I started working on my first port (a Haskell cabal package) over the last weekend. I read the porter's handbook and then began by looking at similar ports that already existed in the ports collection (e.g. archivers/hs-zlib) to get a basic idea of what the port should look like. I noticed that the only documentation listed in pkg-plist of these ports is the LICENSE file. So pkg-plist looks something like this: ... other files.. %%PORTDOCSDOCSDIR%%/LICENSE %%portdoc...@dirrm %%DOCSDIR%% ... @exec/@unexec... However, when you install the port (assuming NOPORTDOCS is not set), a HTML documentation will also be generated by the Haskell compiler and put into %%PORTDOCSDOCSDIR%%/html/*. So my question is, is it ok to omit these html files in the pkg-plist? I thought, you should list those too... It's not OK to install files without any record in the pkgdb. If you do things like that, firstly any committer working on the port should bounce it back to you as not fulfilling the required standards, and secondly, if the port does somehow get committed you'll be getting irate e-mails from various QA systems that spend all their time looking for such problems. Now, explicitly listing all of the files that get installed in pkg-plist in the port directory is one way of dealing with this. There are alternatives though, which might suit your port better. Check out the PLIST_FILES and PORTDOCS variables in /usr/ports/Mk/bsd.port.mk -- in short these are: PLIST_FILES a way of listing a short pkg_plist entirely from within the port Makefile, which helps avoid using up inodes for tiny little files PORTDOCS a way of automatically adding a whole directory tree of documentation to the pkg pretty much automatically. This is particularly useful if your docco is generated automatically and you can't always know exactly what files there will be beforehand. Cheers, Matthew Thanks for the hints. In section 5.14.4 of Porter's Handbook it says: [snip] After looking at the Makefile again, I noticed that the maintainer of hs-zlib defined PORTDOCS= * . If I understand correctly, that means you can put as many files in DOCSDIR as you want. The asterisk will match everything and you always end up with everything registered in the final packing list. Right? If so, the line %%PORTDOCSDOCSDIR%%/LICENSE in pkg-plist would be redundant, wouldn't it? Seems to be so... There is one bad thing about PORTDOCS method: you don't have static list of files the port is going to install. Some commiters here don't like it. This is of course up to you but if it is not hard it is better to manually list all of the installed files in static pkg-plist. Just 0.02$, Alexey. ___ 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: qtcreator-1.2.1: Not installable
On Wed, Oct 28, 2009 at 01:56:25PM +0100, Adrian Glaubitz wrote: Hi, On Wed, Oct 28, 2009 at 1:46 PM, Gary Jennejohn gary.jennej...@freenet.de wrote: The qtcreator port was created on May 7, 2009. Seems to me that 7.2R is older than that. Obviously, qtcreator can't exist for 7.2R if the port didn't exist when it was released. Well, ok. Seems another case of different systems, different philosophies here for me. My idea was that I was downloading the latest STABLE release of FreeBSD and I assumed that the ports directory always applies to the current STABLE version, noone should use a development version for daily use, should one. The base system (more or less what consists a RELEASE) and ports are mostly independent of each other. Normal FreeBSD user will have some RELEASE (say 7.2R) and up-to-date version of ports. There is no separate STABLE or CURRENT versions of ports, there is only one. (Well, there are marcuscom and area51 for testing new gnome and kde releases, respectively, but you don't need to mess with them). This explains the following: Besides, the ports website doesn't list at all what versions of FreeBSD include this port as opposed to Debian, for example; I don't want to start a flamewar though. It's not really user-friendly, is it. I guess the minimum for my project will be FreeBSD 8.0 then. FreeBSD 7 will be ok too. You can add some phrase like Before the software can be built, the following ports/packages have to be installed: devel/qtcreator audio/taglib devel/glib20 audio/sox audio/libmad security/libmcrypt. Note that ports tree newer than 7 May 2009 is needed to build qtcreator. This is FreeBSD-user friendly. HTH, Alexey. ___ 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: qtcreator-1.2.1: Not installable
On Wed, Oct 28, 2009 at 02:51:29PM +0100, Adrian Glaubitz wrote: Hi Alexey, On Wed, Oct 28, 2009 at 2:25 PM, Alexey Shuvaev shuv...@physik.uni-wuerzburg.de wrote: The base system (more or less what consists a RELEASE) and ports are mostly independent of each other. Normal FreeBSD user will have some RELEASE (say 7.2R) and up-to-date version of ports. There is no separate STABLE or CURRENT versions of ports, there is only one. (Well, there are marcuscom and area51 for testing new gnome and kde releases, respectively, but you don't need to mess with them). Ok, thanks alot for shedding some light here. I am not really into FreeBSD but long term Linux user, so consider me being a noob here ;-). FreeBSD 7 will be ok too. You can add some phrase like Before the software can be built, the following ports/packages have to be installed: devel/qtcreator audio/taglib devel/glib20 audio/sox audio/libmad security/libmcrypt. Note that ports tree newer than 7 May 2009 is needed to build qtcreator. This is FreeBSD-user friendly. Thanks alot, I will put into our wiki like this. Is there actually a command to upgrade the ports tree, so that I can use the latest ports with FreeBSD 7.2? What would be the proper instructions to install the necessary ports, I want to try compiling our software on FreeBSD. See http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html It covers pretty much of what you want. You can also get better overview by going up one level: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html BTW: Whom should I contact to get our project into the ports? I guess a fully fledged MiniDisc transfer software could be interesting for alot of FreeBSD users as well ;-). Mmmm... Well, I think the best bet is yourself! The MAINTAINER variable in ports' Makefiles points to the person responsible for the given port. Everybody can become FreeBSD port maintainer. If you search for my email address at http://www.freebsd.org/ports/index.html in 'maintainer' category you'll find the ports I'm maintaining. Creating FreeBSD port is not so difficult. And your companions here are 1) Porter's Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook 2) Other ports as examples and 3) this mailing list if you have some specific problems. However you'll find that it is better to roll some distribution of your software to use it in the port (so to be possible to download tarball with sources and not to use git directly). Good luck! Alexey. ___ 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: Problem building Openoffice 3.1.1 at -current
On Mon, Sep 21, 2009 at 12:15:09PM -0700, Steve Kargl wrote:
On Mon, Sep 21, 2009 at 02:39:44PM +0300, Andriy Gapon wrote:
on 20/09/2009 14:38 Sam Fourman Jr. said the following:
On Sun, Sep 20, 2009 at 6:26 AM, Vinicius Abrahao vinnix@gmail.com
wrote:
Hello dear fellows,
I'm trying to upgrade my openoffice.org3 from 3.1.0 to 3.1.1, but I'm
getting an strange error (associated with python).
This is the error that appears many hours after I start the upgrade:
I am getting this same error on FreeBSD 8.0 Beta4
any idea how to fix the build?
I also had a compilation problem like this.
Perhaps this is related to having python 2.6 installed on a system?
Anyway, I was able to continue the build by doing the following (adjust the
paths
to your environment):
$ ln -s
/usr/obj/usr/ports/editors/openoffice.org-3/work/OOO310_m19/solver/310/unxfbsdx.pro/lib/python
/usr/obj/usr/ports/editors/openoffice.org-3/work/OOO310_m19/solver/310/unxfbsdx.pro/lib/python2.6
$ cp
/usr/obj/usr/ports/editors/openoffice.org-3/work/OOO310_m19/python/unxfbsdx.pro/misc/build/Python-2.6.1/build/lib.freebsd-9.0-CURRENT-amd64-2.6/*.so
/usr/obj/usr/ports/editors/openoffice.org-3/work/OOO310_m19/solver/310/unxfbsdx.pro/lib/python2.6/
Maybe something else, it was a while ago.
The above ln and cp were sufficient to complete my build.
I haven't tested the resulting exectuables.
Thanks, Andriy
Rrrr
The openoffice guys are trying to bundle every piece of code under
the sun into their tarball in attempt to not depend upon system libraries...
... and are getting away from what they want to achieve (IMHO).
OOO is as fragile as porcelain plate and
still as complex to repair as nuclear u-boot.
I hate OOO...
With the attached patch I was able to complete the build on
amd64 9-CURRENT. Will charge 9-amd64-Ports and 9-i386-Ports tinderboxes
to test in a clean environment. Testing on 8-RC is still welcome.
Just drop patch-OOO_XXX_CURRENT into files/ and try to rebuild.
Alexey.
--- python/Python-2.6.1.patch.orig 2009-10-03 22:08:45.0 +0200
+++ python/Python-2.6.1.patch 2009-10-03 23:00:22.0 +0200
@@ -127,7 +127,7 @@
# Skip platforms with known problems forking from a worker thread.
# See http://bugs.python.org/issue3863.
-if sys.platform in ('freebsd4', 'freebsd5', 'freebsd6', 'os2emx'):
-+if sys.platform in ('freebsd4', 'freebsd5', 'freebsd6', 'freebsd7',
'os2emx'):
++if sys.platform in ('freebsd4', 'freebsd5', 'freebsd6', 'freebsd7',
'freebsd8', 'freebsd9', 'os2emx'):
print sys.stderr, ('Skipping test_3_join_in_forked_from_thread'
' due to known OS bugs on'), sys.platform
return
@@ -230,3 +230,603 @@
RUNSHARED=LD_LIBRARY_PATH=`pwd`:${LD_LIBRARY_PATH}
INSTSONAME=$LDLIBRARY.$SOVERSION
;;
+--- misc/Python-2.6.1/Lib/plat-freebsd9/IN.py 1970-01-01 01:00:00.0
+0100
misc/build/Python-2.6.1/Lib/plat-freebsd9/IN.py2009-10-03
22:43:13.0 +0200
+@@ -0,0 +1,571 @@
++# Generated by h2py from /usr/include/netinet/in.h
++
++# Included from sys/cdefs.h
++__GNUCLIKE_ASM = 3
++__GNUCLIKE_ASM = 2
++__GNUCLIKE___TYPEOF = 1
++__GNUCLIKE___OFFSETOF = 1
++__GNUCLIKE___SECTION = 1
++__GNUCLIKE_ATTRIBUTE_MODE_DI = 1
++__GNUCLIKE_CTOR_SECTION_HANDLING = 1
++__GNUCLIKE_BUILTIN_CONSTANT_P = 1
++__GNUCLIKE_BUILTIN_VARARGS = 1
++__GNUCLIKE_BUILTIN_STDARG = 1
++__GNUCLIKE_BUILTIN_VAALIST = 1
++__GNUC_VA_LIST_COMPATIBILITY = 1
++__GNUCLIKE_BUILTIN_NEXT_ARG = 1
++__GNUCLIKE_BUILTIN_MEMCPY = 1
++__CC_SUPPORTS_INLINE = 1
++__CC_SUPPORTS___INLINE = 1
++__CC_SUPPORTS___INLINE__ = 1
++__CC_SUPPORTS___FUNC__ = 1
++__CC_SUPPORTS_WARNING = 1
++__CC_SUPPORTS_VARADIC_XXX = 1
++__CC_SUPPORTS_DYNAMIC_ARRAY_INIT = 1
++__CC_INT_IS_32BIT = 1
++def __P(protos): return protos
++
++def __STRING(x): return #x
++
++def __XSTRING(x): return __STRING(x)
++
++def __P(protos): return ()
++
++def __STRING(x): return x
++
++def __aligned(x): return __attribute__((__aligned__(x)))
++
++def __section(x): return __attribute__((__section__(x)))
++
++def __aligned(x): return __attribute__((__aligned__(x)))
++
++def __section(x): return __attribute__((__section__(x)))
++
++def __nonnull(x): return __attribute__((__nonnull__(x)))
++
++def __predict_true(exp): return __builtin_expect((exp), 1)
++
++def __predict_false(exp): return __builtin_expect((exp), 0)
++
++def __predict_true(exp): return (exp)
++
++def __predict_false(exp): return (exp)
++
++def __format_arg(fmtarg): return __attribute__((__format_arg__ (fmtarg)))
++
++def __FBSDID(s): return __IDSTRING(__CONCAT(__rcsid_,__LINE__),s)
++
++def __RCSID(s): return __IDSTRING(__CONCAT(__rcsid_,__LINE__),s)
++
++def __RCSID_SOURCE(s): return __IDSTRING(__CONCAT(__rcsid_source_,__LINE__),s)
++
++def __SCCSID(s): return __IDSTRING(__CONCAT(__sccsid_,__LINE__),s)
++
++def
Re: Tinderbox + perl5.10?
On Mon, Sep 28, 2009 at 11:27:50PM +0300, Ion-Mihai Tetcu wrote:
On Mon, 28 Sep 2009 21:46:06 +0200
Alexey Shuvaev shuv...@physik.uni-wuerzburg.de wrote:
Hello all!
After about one month of playing with ports-mgmt/tinderbox (thanks to
all for the tool!) I realized I've applied the following in order to
get it working in my environment (amd64 9-CURRENT with perl5.10):
--- tc_command.sh.orig 2009-09-28 21:35:34.0 +0200
+++ tc_command.sh 2009-09-28 21:35:43.0 +0200
@@ -190,7 +190,7 @@
#---
Setup () {
-MAN_PREREQS=lang/perl5.8
+MAN_PREREQS=lang/perl5.10
OPT_PREREQS=lang/php[45] databases/pear-DB www/php[45]-session
PREF_FILES=tinderbox.ph
README=$(tinderLoc scripts README)
I'm not very good at shell patters. Is there any way to depend on
perl5.8 or perl5.10?
BTW, this issue is seen only on fresh installations.
It should be already fixed in the port, I think I did that.
If not, it's fixed in marcus' CVS
FYI, it is indeed fixed in marcus' CVS 2 months ago, but it is not
in the ports yet (neither tinderbox nor tinderbox-devel).
Thanks,
Alexey.
___
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
Tinderbox + perl5.10?
Hello all!
After about one month of playing with ports-mgmt/tinderbox (thanks to all
for the tool!) I realized I've applied the following in order to get it
working in my environment (amd64 9-CURRENT with perl5.10):
--- tc_command.sh.orig 2009-09-28 21:35:34.0 +0200
+++ tc_command.sh 2009-09-28 21:35:43.0 +0200
@@ -190,7 +190,7 @@
#---
Setup () {
-MAN_PREREQS=lang/perl5.8
+MAN_PREREQS=lang/perl5.10
OPT_PREREQS=lang/php[45] databases/pear-DB www/php[45]-session
PREF_FILES=tinderbox.ph
README=$(tinderLoc scripts README)
I'm not very good at shell patters. Is there any way to depend on perl5.8 or
perl5.10?
BTW, this issue is seen only on fresh installations.
Thanks,
Alexey.
___
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: Script configure failed unexpectedly
On Thu, Sep 03, 2009 at 07:23:40PM +0200, Stephan Sann wrote: Hello, while trying: /usr/ports/graphics/xsane - make -DFORCE_PKG_REGISTER install clean I got: updating cache ./config.cache ltconfig: `/usr/local/share/libtool/config/ltmain.sh' does not exist Try `ltconfig --help' for more information. configure: error: libtool configure failed === Script configure failed unexpectedly. Please report the problem to po...@freebsd.org [maintainer] and attach the /usr/ports/graphics/aalib/work/aalib-1.4.0/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). [snip] libtool-1.5.26 ushare-1.1a ports/UPDATING 20090802 ___ 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: Stop in /usr/ports/graphics/aalib
On Tue, Aug 11, 2009 at 09:44:11PM +0200, Jörgen Nilsson wrote:
bastion# uname -a
FreeBSD bastion.mordvap.net 7.2-RELEASE-p3 FreeBSD 7.2-RELEASE-p3 #1: Tue
Aug 11 19:19:21 CEST 2009
u...@bastion.host.net:/usr/obj/usr/src/sys/BASTION i386
checking whether ln -s works... (cached) yes
ltconfig: `/usr/local/share/libtool/config/ltmain.sh' does not exist
Try `ltconfig --help' for more information.
configure: error: libtool configure failed
=== Script configure failed unexpectedly.
[snip]
isc-dhcp30-server-3.0.7_4 libtool-1.5.26 pftop-0.7_1
^^
yasm-0.8.0
#
On Wed, Aug 12, 2009 at 07:45:53PM +0700, karfagen wrote:
Hi!
There is /usr/ports/graphics/aalib installation process log:
# make
=== Vulnerability check disabled, database not found
=== Extracting for aalib-1.4.r5_4
= MD5 Checksum OK for aalib-1.4rc5.tar.gz.
= SHA256 Checksum OK for aalib-1.4rc5.tar.gz.
=== Patching for aalib-1.4.r5_4
=== Applying FreeBSD patches for aalib-1.4.r5_4
=== aalib-1.4.r5_4 depends on file: /usr/local/libdata/pkgconfig/x11.pc -
found
=== aalib-1.4.r5_4 depends on file: /usr/local/bin/libtool - found
=== Configuring for aalib-1.4.r5_4
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c -o root -g
wheel
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking host system type... i386-portbld-freebsd7.2
checking target system type... i386-portbld-freebsd7.2
checking for gcc... cc
checking whether the C compiler (cc -O2 -fno-strict-aliasing -pipe )
works... yes
checking whether the C compiler (cc -O2 -fno-strict-aliasing -pipe ) is a
cross-compiler... no
checking whether we are using GNU C... yes
checking whether cc accepts -g... yes
checking build system type... i386-portbld-freebsd7.2
checking for ranlib... ranlib
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
updating cache ./config.cache
ltconfig: `/usr/local/share/libtool/config/ltmain.sh' does not exist
Try `ltconfig --help' for more information.
configure: error: libtool configure failed
=== Script configure failed unexpectedly.
[snip]
Have you guys read entry 20090802 in /usr/ports/UPDATING?
HTH,
Alexey.
___
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: needing install OpenOffice.org without messing up perl
On Wed, Jul 22, 2009 at 07:52:11AM -0500, Scott Bennett wrote: I wrote: Sure, but OOo is so huge and requires so much other stuff that there is almost certainly something it wants installed that I do not already have installed. Why wouldn't OOo, once installed, simply use whatever were installed as /usr/local/bin/perl? It seems to me that the bigger worry it that portmaster may try to rebuild it whenever a -a option is used. portmanager, OTOH, has a -u option that might do the job. portupgrade, of course, My mistake. portmanager -u is supposed to accomplish roughly what portmaster -a or portupgrade -a accomplishes. I meant to write portmanager -u -ip packagename rather than what I wrote before. can have all sorts of things blocked from upgrading by putting the proper magic into /etc/portupgrade.conf. If only portmaster had a similar way of doing things. Since so many people now advocate using either portmanager or portmaster to do general upgrades (-a), rather than portupgrade -a, I guess portmanager is the only method available to keep OOo from being rebuilt whenever one of its dependencies gets upgraded. If only you have RTFM %) From man portmaster: /var/db/pkg/*/+IGNOREME If this file exists, several things will happen: 1. The port will be ignored for all purposes, including dependency updates, if there is no directory for it in /usr/ports, and there is no entry for it in /usr/ports/MOVED. If the -v option is used, the fact that the port is being ignored will be mentioned. 2. If using the -L option, and a new version exists, the existence of the +IGNOREME file will be mentioned. 3. If you do a regular update of the port, or if the -a option is being used, you will be asked if you want to update the port anyway; unless the -u option is being used, in which case the port will be ignored. So, touch /var/db/pkg/openoffice.org-/+IGNOREME would do the trick. ___ 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: [RFC] New category proposal, i18n
On Tue, Jun 23, 2009 at 10:13:48AM -0400, Thomas Abthorpe wrote: 2009/6/23 Chris Rees utis...@googlemail.com: 2009/6/23 Doug Barton do...@freebsd.org: Thomas Abthorpe wrote: To have localization, you need internationalization, so from this, I stand by my original proposal of i18n. I have no objection to your reasoning, but continue to object to the specific string. If you're going to go down this road then internationalization would be the better choice. Doug I would agree with Doug. We're in the days of tab-completion, and typing 'inTAB' will suffice to get there. I for one *hate* numbers in paths; it takes one's hand off the letters. Also, I had to look up i18n to find out what it was... Categories should be immediately descriptive. Hard to achive... x11-wm, x11-fm, audio vs. multimedia, ... Also, the French have to use Shift to type numbers; it's even more of a pain for them! Unrelated problem. head -50 test.c kill -s KILL 46129 man 3 printf mount /dev/da0a mnt/ I think you can't avoid using numbers in command-line. BTW, numbers are much better than spaces or localized characters: 'Мои документы' ( == 'My Documents') Chris You have struck a chord with numbers in the path, reminds me of the pre-Xorg days with /usr/X11R6, not sure what I disliked more, the capital letters or the numbers! I hereby relent, and yield to the logic of the arguments placed before me, I now agree that using internationalization for the category name is a better idea. Well, if the new category supposed to be real, I don't like 'internationalization' name. The reason? Very simple. For now I get: ~ ls /usr/ports/ CHANGES archivers finance misc shells COPYRIGHT astro frenchmultimediasysutils GIDs audio ftp net textproc INDEX-8 benchmarksgames net-imukrainian KNOBS biology germannet-mgmt vietnamese LEGAL cad graphics net-p2p www MOVED chinese hebrewnews x11 Makefile comms hungarian packages x11-clocks Mkconvertersirc palm x11-drivers READMEdatabases japanese polishx11-fm Templates deskutils java ports-mgmtx11-fonts Tools devel koreanportuguesex11-servers UIDs distfiles lang print x11-themes UPDATING dns mail russian x11-toolkits accessibility editors math science x11-wm arabicemulators mbone security which fits fine in one 80x25 terminal window. With the new category: ~ ls /usr/ports/ CHANGES develnet-p2p COPYRIGHTdistfilesnews GIDs dns packages INDEX-8 editors palm KNOBSemulatorspolish LEGALfinance ports-mgmt MOVEDfrench portuguese Makefile ftp print Mk gamesrussian README german science Templatesgraphics security Toolshebrew shells UIDs hungariansysutils UPDATING internationalization textproc accessibilityirc ukrainian arabic japanese vietnamese archiversjava www astrokorean x11 audiolang x11-clocks benchmarks mail x11-drivers biology math x11-fm cad mbonex11-fonts chinese misc x11-servers commsmultimedia x11-themes converters net x11-toolkits databasesnet-im x11-wm deskutilsnet-mgmt which is too long. You need to scroll to see the whole content of the folder. About the topic: from http://lists.freebsd.org/pipermail/freebsd-ports/2009-June/055424.html It is my intention for ports that do localization related work would remain in their existing category, and if appropriate we could add the new name to CATEGORIES. from: http://lists.freebsd.org/pipermail/freebsd-ports/2009-June/055463.html To paraphrase a couple of key points Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale). ... Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language. To
Re: [REPOST] problem upgrading perl
On Mon, Jun 15, 2009 at 10:25:59PM -0500, Scott Bennett wrote: I got no responses when I posted this a few days ago, so I'm reposting it now. I'd really like to finish the perl upgrade process, so I could move on to installing/updating other ports safely, but could use some advice. Following the instructions in /usr/ports/UPDATING for upgrading from lang/perl5.8 to lang/perl5.10 using portmaster, the first part seems to go well. The last line of that process is where the excerpt below begins. The second step, as you will see, fails with the error message shown. /usr/ports/UPDATING neglects to mention what to do next, and the process looks incomplete at this point. If someone could offer instructions for completing the process, I would be grateful. === Upgrade of perl-5.8.9_2 to perl-threaded-5.10.0_3 complete hellas# nice +18 portmaster -v -r perl\* === No ORIGIN in /var/db/pkg/perl-threaded-5.10.0_3/+CONTENTS:@comment ORIGIN:lang/perl5.10 /var/db/pkg/perltidy-20071205/+CONTENTS:@comment ORIGIN:devel/perltidy/+CONTENTS === Aborting update The something is wrong with packages database in /var/db/pkg or portmaster doesn't like it. Please, show the output from the following commands to start: head /var/db/pkg/perl-threaded-5.10.0_3/+CONTENTS head /var/db/pkg/perltidy-20071205/+CONTENTS Mine is (no perltidy though): ~ head /var/db/pkg/perl-5.10.0_3/+CONTENTS @comment PKG_FORMAT_REVISION:1.1 @name perl-5.10.0_3 @comment ORIGIN:lang/perl5.10 @cwd /usr/local @conflicts perl-5.6.* @conflicts perl-5.8.* @conflicts perl-threaded-5.8.* man/man1/a2p.1.gz @comment MD5:41051bd143f495e113fa136ac0e9cb6f man/man1/c2ph.1.gz Hmmm... Looking at portmaster sources I've got one idea. Can you try more precise command to upgrade everything depending on perl? nice +18 portmaster -v -r perl-threaded-5.10.0_3 The point is that perl\* wildcard gives you both perl-threaded-XXX and perltidy- which might be bad idea. If this is the case I think UPDATING entry should be improved to use perl-\* wildcard. hellas# Please copy me in on any responses. I'm subscribed to the digest form of this list, so responses sent only to the list may take up to a day to be sent to me as part of the digest. Thanks in advance for any assistance in proceeding with the perl upgrade. Just 0.02$, Alexey. ___ 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 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. ___ 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: Python 2.6 update with portmaster
On Wed, Jun 10, 2009 at 09:26:47AM -0400, Wesley Shields wrote: Here's a patch[1] that allows you to use portmaster when doing the python upgrade. I intend to commit this tomorrow morning unless someone speaks up. I'll also be adding the instructions to the UPDATING entry. Once applied you should be able to use: cd /usr/ports/lang/python make upgrade-site-packages -DUSE_PORTMASTER It will be quite slow compared to using pkg_which (the normal method) so be patient. I've used this patch to upgrade one lightly used machine and I know at least one other person has survived an upgrade of a machine with over 1000 ports installed. [1]: http://people.freebsd.org/~wxs/python26-portmaster.diff I think using -f switch with portmaster is not correct as it will unconditionally rebuild all dependencies also (often up to perl :). 0.02$, Alexey. ___ 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: [RFC] NO_INSTALL in meta-ports considered harmful
On Mon, May 11, 2009 at 09:17:00AM -0400, Wesley Shields wrote:
On Sun, May 10, 2009 at 09:28:34PM +, Marcin Wisnicki wrote:
On Sun, 10 May 2009 15:22:04 -0400, Glen Barber wrote:
On Sun, May 10, 2009 at 2:51 PM, Marcin Wisnicki
mwisnicki+free...@gmail.com wrote:
They will be installed since they are run dependencies.
From what I can tell (from several metaports) -- they, themselves, are
not installed. The ports defined in the metaport are installed.
That's the point. The metaports should be installed as well (reasons given
in my original mail).
There is no source code for, using your example, CUPS[1]. CUPS (in the
FreeBSD ports tree) is, for lack of a better explanation, a pointer to
which specific ports you need to have in order to get a fully operation
CUPS system running. Looking at the Makefile for print/cups [2] you can
see the dependencies and that CUPS is not actually built (which in
definition is what makes this a metaport).
I know this.
The proper way to make a metaport is to:
1. use only RUN_DEPENDS
2. set NO_BUILD
3. do *NOT* set NO_INSTALL
4. provide empty do-install target
There are several metaports that get it right, like for example x11/gnome2:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11/gnome2/Makefile?rev=1.155
Based upon your description I think this is a bug in the CUPS port. I'd
suggest you file a PR so that it can be tracked and (hopefully)
addressed.
FWIW, the following gives not so many hits:
/usr/ports grep -R NO_INSTALL * | grep -v NO_INSTALL_MANPAGES
Mk/bsd.port.mk:# NO_INSTALL - Use a dummy (do-nothing) install target.
Mk/bsd.port.mk:.if defined(NO_INSTALL) !target(install)
Tools/scripts/mkptools/mkpextr: $cap{NO_INSTALL} = YES;
devel/gnustep/Makefile:NO_INSTALL= yes
graphics/backfract/Makefile:NO_INSTALL_MANPAGE= yes
misc/posixtestsuite/Makefile:NO_INSTALL=YES
misc/kde4-l10n/Makefile:NO_INSTALL= yes
ports-mgmt/portmk/Mk/bsd.port.mk:# NO_INSTALL - Use a dummy (do-nothing)
install target.
ports-mgmt/portmk/Mk/bsd.port.mk:.if defined(NO_INSTALL) !target(install)
print/cups/Makefile:NO_INSTALL= yes
x11/etoile/Makefile:NO_INSTALL= yes
x11/gnustep-app/Makefile:NO_INSTALL=yes
Ruling out *.mk scipts there is only 1 port that uses NO_INTSTALL correctly:
misc/posixtestsuite
These should be fixed (well, I'm not 100% sure):
devel/gnustep
misc/kde4-l10n
print/cups
x11/etoile
x11/gnustep-app
Not so many too :)
My 0.02$,
Alexey.
___
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: generate index file which respects non default environment
On Thu, May 07, 2009 at 08:24:07PM +0400, Boris Samorodov wrote: Hello List, is there any possibility to generate an index file which respects environment, non default OPTIONS? I mean if for example OVERRIDE_LINUX_BASE_PORT is defined as f8, then I expect the INDEX should reflect it. I always thought that everything put into /etc/make.conf (or include derivatives) would be accounted for during make index in /usr/ports. Is it not true for OVERRIDE_LINUX_BASE_PORT=f8? Alexey. ___ 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] call for assistance with ports broken on -current
On Sat, Feb 28, 2009 at 08:02:14PM -0600, Mark Linimon wrote: With 8.0 coming up, it's time to take a look at the ports that have been broken by some recent changes to freebsd-current. I have put a list of these ports, categorized by which change, on the wiki at http://wiki.freebsd.org/PortsBrokenOnCurrent. These changes are: tty changes, jail changes, import of strndup(3), ARP v2, libusb20. (The latter has not yet been run through pointyhat, and is probably incomplete.) Any help fixing these will be appreciated. palm/uppc-kmod too (it is using usb stack directly, not via libusb). Alexey. ___ 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: Possibly unbuildable ports reminder
On Sat, Feb 28, 2009 at 10:00:07AM +, Bill Fenner wrote: Dear porters, This is just a reminder to please periodically check the list of unbuildable ports at http://pointyhat.freebsd.org/errorlogs/ . A list by MAINTAINER is http://people.freebsd.org/~fenner/errorlogs/ so you can easily check the status of ports that you maintain. In addition, the list of ports with no MAINTAINER with build problems is http://people.freebsd.org/~fenner/errorlogs/po...@freebsd.org.html I would say that this run: i386-6-exp-latest Fri Feb 27 00:30:39 2009gtkdatabox-0.9.0.0.log 1 56k x11-toolkits/gtkdatabox ld tried to do something bad. In this case it tried to build the old version of gtkdatabox (0.9.0.0) with the new version of gtk (2.14.7). The ports tree was never in this state. Just FYI, Alexey. ___ 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: lyx 1.6 upgrade?
On Mon, Feb 16, 2009 at 11:16:26AM +0100, Giuseppe Pagnoni wrote: Dear port developers, is there a plan to upgrade the lyx15 port in the short term? The version in the stable port tree (1.5.6) is not compatible anymore with the later 1.6 version, which creates difficulties for opening the same document under different system. thanks for the great work Have you tried contacting print/lyx port maintainer (CC-ed)? Alexey. ___ 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: Determining if Nvidia graphics card supports widescreen modes
On Mon, Feb 16, 2009 at 01:50:25PM +, RW wrote: On Mon, 16 Feb 2009 13:29:38 + RW rwmailli...@googlemail.com wrote: I need to replace my old CRT monitor. I suspect that my nvidia GeForce FX 5700LE wont support a widescreen monitor, but is there any way of finding-out what modes are supported. I don't really want to replace the card as it's agp, and they seem to be relatively expensive these days. I think video cards today support almost anything. I remeber I have played with my GeForce4 420 Go (NV17 chipset) with manual Modeline-s in xorg.conf. I was able to activate some totally crazy modes like 2048x4 :) My 0.02$, Alexey. ___ 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: Call for potential ports maintainers
Thomas Abthorpe (Thu 02/12/09 12:32): This topic came up in IRC, and I was encouraged to go out, and find some new maintainers. At any given time, approximately 20 - 25% of all ports are unmaintained. Not all unmaintained ports need updating, but some do. That is where you folks come in. There are a bunch of you out there who are subscribers to this list (and other FreeBSD related lists too, I am sure), you have FreeBSD installed and likely have quite an array of ports installed on this system of yours. You are subscribed as a means of keeping up with the world of FreeBSD. But you have been holding back, thinking I really would like to do something to contribute to the success of FreeBSD, but I am not sure what. How do I know this? I was one, a silent observer on the mailing lists, and in on IRC. Then one day, I answered a similar plea, http://lists.freebsd.org/pipermail/freebsd-announce/2006-May/001065.html. I have summarised some details on the wiki on Adopting Ports, http://wiki.freebsd.org/PortsTasks#head-f018f566bce2ff96ec13fabd536d7cc6dc6f4275. The gauntlet has been thrown down, who among you is prepared to pick it up? Well, if we go so far, could someone (you???) look at net/acx100 and net/gacxtool ports. The related PR 129977 (2 months, still unassigned). The port formally has a maintainer but its current state: BROKEN= Does not compile on FreeBSD = 6.x DEPRECATED= Has been broken for more than 6 months EXPIRATION_DATE=2008-09-19 says for itself. Related discussion on -CURRENT: http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001666.html This is the message from developer saying the driver should work on 7.0: http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001709.html More details are in the PR description. Thanks, Alexey. ___ 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: A plea or sanity in port options menu
On Mon, Feb 02, 2009 at 03:39:25PM -0500, Bill Moran wrote: In response to Warren Block wbl...@wonkity.com: On Mon, 2 Feb 2009, Bill Moran wrote: How about: Options for port-fu [ ] BRG Bernstein Riggs Guillotine parsing [X] QFZ Quantum Freeze Zulu rending At least that one gives me _some_ idea what those TLAs mean. This particular example is nonexistent and thus too far from reality. [snip] I don't think there's any need for any new features in the ports infrastructure. I think it's just a matter of Makefile authors taking the time to describe their options. A quick test of some ports turns up this one: [ ] OPENGL OpenGL support True but useless. How about: [ ] OPENGL Use OpenGL graphics library ...which, at least give the user _some_ idea what they're doing. I don't see any difference here. OpenGL = Open Graphics Library, so your description is redundunt (Use Open Graphics Library graphics library). Well, you can write 'Use Open Graphics Library', but it is again not so much different from 'OpenGL support'. OpenGL probably isn't a good example, however. It's pretty easy to Google OpenGL and figure out what it is. As quite a number of other 'bad' option descriptions. Here's some more bizarre options: [X] EPUB Epub modules [X] EXTENSIONSExtensions [X] TEMPLATE Templates [X] TOOLS Tools I mean, if I enable Extensions, what happens? How do I figure out what happens? I have to read the Makefile, at which point having these options on a menu is pretty pointless. I mean, I can't even come up with a Google search to help me figure out what tools are involved here. There are some ports that do this very well. For example: [ ] NLS Use internationalized messages [ ] PAM Build with PAM support (server only) ^^ Exactly what you are fighting against. [ ] LDAP Build with LDAP authentication support [ ] MIT_KRB5 Build with MIT's kerberos support [ ] HEIMDAL_KRB5 Builds with Heimdal kerberos support ^^^ The above 2 also. [ ] OPTIMIZED_CFLAGS Builds with compiler optimizations (-O3) [X] XML Build with XML data type (server) [X] TZDATAUse internal timezone database (server) [ ] DEBUG Builds with debugging symbols [ ] ICU Use ICU for unicode collation (server) [ ] INTDATE Builds with 64-bit date/time type (server) I mean, a Google on ICU is liable to bring up all sorts of medical drama websites, but I can do a search for ICU unicode and find my answer on the first result. Not only am I told that optimized compiler flags are an option, but I'm told the exact one that will be used (-O3) The porters handbook doesn't seem to offer any helpful advice on these: http://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html In fact, the examples it provides are excellent examples of doing it WRONG. Let me see about making a patch to the porters handbook to provide some advice ... Ok let's examine my 4 ports 3 of which do use OPTIONS. x11-toolkits/gtkdatabox: OPTIONS=GLADE Enable libglade2 support off \ GLADEUI Enable glade3 support off /usr/ports/devel/libglade2 cat pkg-descr LibGlade allows GLADE interfaces to be handled at runtime, freeing GUI development from code development. This allows an interface to be changed without requiring a re-compilation. /usr/ports/devel/glade3 cat pkg-descr Glade is a RAD tool to enable quick easy development of user interfaces for GTK+/GNOME. It can generate the C source code needed to create the interfaces designed within Glade's interface editor. Any idea here how to put all these into small line of description field? [RAD = Rapid Application Development, hope you know what GUI is] Do these long descriptions help you? x11-toolkits/slgtkdatabox: OPTIONS=SLGLADE Enable slglade support (run-time) off /usr/ports/devel/slglade cat pkg-descr SLglade is a S-Lang module that provides S-Lang bindings for the libglade library. Used in conjunction with SLgtk, it allows you to design your GUI with Glade (a GTK+ user interface builder), save the interface description in a Glade XML file, and then generate your S-Lang script's graphical interface directly from the XML at runtime. This should reduce the time spent developing SLgtk applications considerably, as it eliminates the tedious job of writing interface-creation code by hand. This is an update for Christopher Stawarz's SLglade module. WWW: http://laurent.perez2.free.fr/comp/slang/modules/modules.html Same here, short version of pkg-descr for slglade??? x11-toolkits/slgtk: OPTIONS=FITS Install gdk-pixbuf FITS image loader off
Re: Contact for assistance
On Fri, Jan 30, 2009 at 06:56:17PM -0500, V. M. Tame-Reyes wrote:
Hello,
I live in a place where the internet connection is
very, very slow, and i feel very enthusiastic about
freeBSD (i'm currently using Linux), therefore i
had a friend download about 16 GB of ports from
the official ports site, and i have them now in my
local network.
We are working on projects related to molecular
dynamics, and other physics related topics, so we
kind need trustworthy, robust servers to do the
calculations, and we decided to try this OS,
could you provide some info/howto create a ports
server for my intranet, so i can move some servers
devoted to do calculations to this OS ?
On the machine which will serve ports' distfiles you enable the ftp server
with ports' distfiles directory. This is done with this lines in /etc/rc.conf:
ftpd_enable=YES
ftpd_flags=-Ar
and adding user ftp (via adduser command). Home directory of ftp user
should be /usr/ports/distfiles and nologin shell. The entry in /etc/passwd
should look like:
ftp:*:1002:14:FTP anonymous user:/usr/ports/distfiles:/usr/sbin/nologin
On the machines which will build (and download) ports you put the following
in /etc/make.conf:
MASTER_SITE_OVERRIDE+=ftp://your_ports_sevrer/${DIST_SUBDIR}/
If you populate /usr/ports/distfiles on the ftp server with actual
tarballs you should be able to build ports on clients as usual with
cd /usr/ports/category/portname ; make install clean.
Of course, this is only one of the possible methods...
I apologize if this is the wrong contact to reach
while looking for the assistance i need, but actually
was one that i found.
Thanks in advance,
Good luck,
Alexey.
___
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: libX11 dependencies
On Tue, Jan 27, 2009 at 10:35:12AM +, Andrew Hotlab wrote: I'm so sorry to annoy you with a question that might be stupid, but I'm not yet very experienced in managing software on the FreeBSD platform. During my weekly ports maintainance (I'm using the ports-mgmt/portmaster) I've noticed that the www/drupal port seems to require the lang/python25 now, and this dependency is due to the latest x11/libX11 version, which wants x11/xcb-proto and x11/libxcb ports, which bring me lang/python25. Since I read that the XCB option should have been removed from r1.8 of the pkg-plist file (http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11/libX11/pkg-plist), I'm wondering if such dependency is still really needed. That was an option, now it is mandatory. So you can't avoid lang/python25 :) Thanks you very much for your invaluable commitment in maintaing this great operating 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: (no subject)
On Mon, Jan 26, 2009 at 04:58:23PM -0300, Arthur Melo wrote: Dear Srs. The error ocurred when I enter in my gmail. [supo...@bsdteste /usr/home/suporte]$ firefox --sync :1: error: unexpected character `\1', expected keyword - e.g. `style' NP_Initialize New open dsp: No such file or directory SetWindow SetWindow NewStream WriteReady Write decoding... shmget: Cannot allocate memory ^^^ Size = 547 x 225 shmat: Invalid argument The program 'firefox-bin' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAccess (attempt to access private resource denied)'. (Details: serial 33 error_code 10 request_code 146 minor_code 1) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) [supo...@bsdteste /usr/home/suporte]$ uname -a FreeBSD bsdteste.grupoatemde.com.br 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 [supo...@bsdteste /usr/home/suporte]$ Any chance you have running postgresql server on this machine? Seems you are running out of kernel's limits on SysV shared memory resources. You could try doing what is in postgresql's pkg-message: [snip] To allow many simultaneous connections to your PostgreSQL server, you should raise the SystemV shared memory limits in your kernel. Here are example values for allowing up to 180 clients (configurations in postgresql.conf also needed, of course): options SYSVSHM options SYSVSEM options SYSVMSG options SHMMAXPGS=65536 options SEMMNI=40 options SEMMNS=240 options SEMUME=40 options SEMMNU=120 [snip] My 0.02$, Alexey. ___ 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: how to install a port without install: in the Makefile
On Fri, Jan 23, 2009 at 08:46:32AM -0700, Steve Franks wrote:
I presume Florent's preferred method is INSTALL_PROGRAM? So far,
the only doc I've found is that it exists. So I put INSTALL_PROGRAM
$(WORKDIR)/$(PORTNAME) (portname just happens to be the name of the
^
WRKDIR or WRKSRC? See below.
executable) in the port Makefile, or what? I've never been able to
'read' makefiles, so I'm not sure a look at ports.mk is going to cause
anything but frustration. We've spent minutes arguing philisophy, can
I get a couple seconds of example? :) Otherwise, PLIST_FILES looks
like it will work to me...
As suggested by Oliver you do in the Makefile:
[...]
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/${PORTNAME} ${PREFIX}/bin/
[...]
Here you should decide yourself what is appropriate here:
WRKDIR is for example:
[wep4035] /usr/ports/x11-toolkits/slgtk make -V WRKDIR
/usr/ports/x11-toolkits/slgtk/work
while WRKSRC is:
[wep4035] /usr/ports/x11-toolkits/slgtk make -V WRKSRC
/usr/ports/x11-toolkits/slgtk/work/slgtk-0.7.3
So you should check in which directory your port extracts itself
(after make extract).
And you write in the pkg-plist:
bin/program_name
Here it is better not to bother with PORTNAME substitution and write
actual name of the program.
The documentation about internals of FreeBSD ports is available online:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html
or, if you have installed (or built yourself) it, offline too:
file:///usr/share/doc/en_US.ISO8859-1/books/porters-handbook/index.html
Hope this helps,
Alexey.
___
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: TeXLive
On Wed, Dec 24, 2008 at 02:10:12PM +0100, Romain Tartière wrote:
Hi!
There have been numerous mails about adding ports for TeXLive to FreeBSD
[1,2,3,4], unfortunately, nothing is available so far.
Since I really think TeXLive can be a plus for FreeBSD, and because I
use TeXLive on another system, I started another effort to bring it to
the ports tree. In order to avoid loosing everything if I run out of
time, I created a Google code project for working:
http://code.google.com/p/freebsd-texlive/
Nice!
Some of the distfiles are sort of meta-packages, this helps grouping
[5, Categories]. Here are some ports organisation possibilities:
1. One port per Scheme (10 ports)
+ very few ports;
- low granularity;
- each port conflict with others.
2. One port per Collection (84 ports) + One meta-port per Scheme (10
Meta-ports)
+ no conflict (AFAIK);
- low granularity.
3. One port per Package, grouping related packages (e.g. foo,
foo.source and foo.doc) (/[0-9]{4}/ ports) + meta-port for
Collections (84 meta-ports) + meta-port for Scheme (10 meta-ports)
+ high granularity;
+ no conflict;
- many ports.
4. Same as #3 without grouping packages
+ highest granularity;
- many many ports.
I am in favor of #3 since it allows TeXLive users to install a basic set
that fit their needs (a beginner will install the full scheme
meta-package and have everything, another will choose a minimal scheme,
another will directory install the collections he wants, it is possible
to install a particular package without installing loads of other
packages (say you have a document that use svninfo for example and you
don't have / want collection-latexextra)).
I would however be pleased to read what teTeX/TeXLive [future] users
think about all this.
As a current teTeX and Xorg user, I like your choice #3.
As a little note, you can consider sub-splitting Package port into 'meat' part
(always installed), documentation, examples, etc. (controlled by
NOPORTDOCS, NOPORTEXAMPLES, etc. variables set by the end user).
So, it is still one FreeBSD port, but user can choose whether to install
doc and so on, or not.
Just FYI, debian seems to have chosen something between #1 and #2:
~ grep ^texlive allpackages | wc
93 7757736
Just my 0.02$,
Alexey.
___
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: PYTHON_SITELIBDIR gets parsed incorrectly
Hello!
On Wed, Dec 10, 2008 at 12:57:52AM -0800, Silver Salonen wrote:
Hello.
I'm creating a port that uses python. I've set in Makefile:
USE_PYTHON= yes
PYTHON_SITELIBDIR=${PYTHON_SITELIBDIR:S|^${PREFIX}/||g}
PLIST_SUB+= PYTHON_SITELIBDIR=${PYTHON_SITELIBDIR}
And pkg-plist has entries a'la:
%%BINDINGSPYTHON_SITELIBDIR%%/
This %%BINDINGS%% gets replaced with , so that should not be an issue.
Anyway, when I install port, +CONTENTS contains lines a'la:
/usr/local/lib/python2.5/site-packages/museek/__init__.py
This is wrong. They should be relative to ${LOCALBASE},
lib/python2.5/site-packages/bla-bla-bla
in this case.
Can't say why %) Examine the behavior of PYTHON_SITELIBDIR variable
in the Makefile.
And when I try deinstalling it, I get errors a'la:
pkg_delete: file
'/usr/local//usr/local/lib/python2.5/site-packages/museek/__init__.py'
doesn't exist
Why do these files get prefixed with $LOCALBASE (or $PREFIX)?
0.02$,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/128754: [port infrastructure] implement master sites randomization
On Tue, Nov 11, 2008 at 03:23:50AM +, RW wrote: On Mon, 10 Nov 2008 18:56:16 +0300 (MSK) Eygene Ryabinkin [EMAIL PROTECTED] wrote: Today I was hit by the very bad connectivity with twaren.net and nchc.dl.sourceforge.net (the first site in the SF mirrors list in the FreeBSD ports .mk files) is hosted by Taiwan REN. So, I decided to implement simple randomization that will enable to evenly distribute the downloads between SF mirrors. ... +# Need to drop a couple of initial rand() values: they tend +# to be around 0.8 - 0.9, so for fairly small array lenght +# they will produce identical values at the beginning. + srand(); rand(); rand(); rand(); rand(); I think it would be sensible to seed srand from a hash of something reproducible to make better use of caches - maybe DISTNAME+DISTVERSION. Maybe I don't understand something, but is RANDOMIZE_MASTER_SITES (see bsd.port.mk for details) not enough? It affects though all sites, not only SF. Just my 0.02$, Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: open-vm-tools fails on a recent sup to CURRENT
On Tue, Oct 14, 2008 at 07:17:29PM -0400, Michael Proto wrote: Has anyone started seeing failures of ports/emulators/open-vm-tools builds with a recent current? I csup-ed my source recently (as of 20080926), rebuilt world and my kernel, and open-vm-tools builds fail in the vmhgfs module with the following: ... cc1: warnings being treated as errors vfsops.c: In function 'HgfsVfsMount': vfsops.c:142: warning: implicit declaration of function 'suser' vfsops.c:142: warning: nested extern declaration of 'suser' *** Error code 1 ... I've tried setting CFLAGS optimizations to -Os (my default), -O, -O2 and no optimizations and it fails with the same error every time. Has anyone else using CURRENT in VMware seen this error recently? Any ideas? This is due to API change suser() - priv_check(). Have a look at http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11/nvidia-driver/Makefile (revision 1.81) for example. I am not sure about PRIV_DRIVER argument, but you can try to replace suser(CURTHREAD) to priv_check(CURTHREAD, PRIV_DRIVER) in the open-vm-tools sources. Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
x11-wm/fluxbox fluxbox-generate_menu lists all available programs.
Hello!
The script fluxbox-generate_menu shipped with current versions of
fluxbox (fluxbox-1.1.0.1_1 and 1.1.1 too, I think) produces
menu with all known programs. The reason for it is find_it* family
of functions used to determine if the program exists (see attached test.sh).
It expects that 'hash' will return non-zero exit code when it cannot find
the command and it is true on linix (some Ubuntu with 'dash', surprisingly
enough, man says it is BSD sh), but not here:
~ uname -a
FreeBSD wep4035.physik.uni-wuerzburg.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun
Sep 21 18:51:53 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
amd64
~ ./test.sh ls
Found ls
~ ./test.sh bla-bla-non-existent
Found bla-bla-non-existent
Substituting 'hash' with 'which' solves the problem more or less,
but I am not a sh guru to claim it is 100% correct.
It could be also a sh(1) bug...
Alexey.
#!/bin/sh
find_it() {
[ -n $1 ] hash $1 2 /dev/null shift $@
}
find_it $1 echo Found $1
exit 0
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: x11-wm/fluxbox fluxbox-generate_menu lists all available programs.
On Mon, Sep 22, 2008 at 06:35:20PM -0400, Randy Pratt wrote: On Mon, 22 Sep 2008 14:16:35 -0500 Jeremy Messenger [EMAIL PROTECTED] wrote: I agree for 'which' is best thing to do. Not all shells (csh, see in builtin(1)) have 'hash' stuff. I have bring all of hash - which stuff from 1.0.0, so let me know patches work for you. http://people.freebsd.org/~mezz/diff/patch-util%3a%3afluxbox-generate_menu.in http://people.freebsd.org/~mezz/diff/patch-util_fbsetbg Put those files in x11-wm/fluxbox/files/ and reinstall fluxbox. Everything seems to be fine now. The patch-util_fbsetbg fixed the inability to set backgrounds. I had almost forgotten about this minor problem. The fluxbox-generate_menu.in patch results in an improved function but I recommend users backup their ~/.fluxbox in case it does something odd (I have a highly customized menu). This function gives some (not so bad) starting point for those who have never used fluxbox before. Thanks again for fluxbox patches ;-) Me too :) Alexey. ___ 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: clamav-0.94_1
On Fri, Sep 19, 2008 at 12:40:35PM +0800, Snopy Land wrote: Hi, My server version is freebsd6.2 amd64. I have installed clamav to scan my ^^^ According to http://www.freebsd.org/security/ it is not supported any more. Consider upgrading your base system (as opposed to ports) as well. incoming mail. Everything works smoothly for several years. Recently, I need to upgrade clamav version from 0.92 to 0.94 (latest version). The procedure used (from the original mail): 1. run make deinstall to deinstall the clamav version of 0.92 2. Modify /usr/ports-supfile (to make sure security port can be download from a correct default host) *default host=ftp.tw.freebsd.org ports-security --- remark ports-all, and enable the ports-security only ^^ That is not a good idea, I think. 3. cd /usr ; run cvsup -g -L 2 ports-supfile 4. check /usr/port/security/clamav port is updated 5. cd /usr/port/security/clamav 6. run make install clean There is no error message found in the whole process, however, I cannot find the file of clamd, clamscan freshclam. The previous version of these file can be found in /usr/local/sbin and /usr/local/bin After redo the upgrade process, I find there are some files under /usr/local/bin and /usr/local/sbin but the file name is differenet. ls -ltr /usr/local/bin -r-xr-xr-x 1 root wheel80624 Sep 19 11:07 amd64-portbld-freebsd6.2-sigtool -r-xr-xr-x 1 root wheel87944 Sep 19 11:07 amd64-portbld-freebsd6.2-freshclam -r-xr-xr-x 1 root wheel51968 Sep 19 11:07 amd64-portbld-freebsd6.2-clamscan -r-xr-xr-x 1 root wheel52592 Sep 19 11:07 amd64-portbld-freebsd6.2-clamdscan -r-xr-xr-x 1 root wheel28272 Sep 19 11:07 amd64-portbld-freebsd6.2-clamconf -r-xr-xr-x 1 root wheel 1103 Sep 19 11:07 amd64-portbld-freebsd6.2-clamav-config ls -ltr /usr/local/sbin -r-xr-xr-x 1 root wheel67536 Sep 19 11:07 amd64-portbld-freebsd6.2-clamd Are these files are the same as the file of clamd, freshclam and clamscan. If yes, can I create symbolic link for these file so that I can keep my old setting? (i.e run /usr/local/sbin/clamd -c /usr/local/etc/clamd.conf, and run /usr/local/bin/freshclam --quiet in the cronjob). How many configuration files location should I change ? Yes, these files are the same. You have run into this problem because you have not updated the whole tree, namely ports/Mk* directory. There was a change which is responsible for fixing these ugly names. FWIW, from the /usr/share/examples/cvsup/ports-supfile: # These are the individual collections that make up ports-all. If you # use these, be sure to comment out ports-all above. # # Be sure to ALWAYS cvsup the ports-base collection if you use any of the # other individual collections below. ports-base is a mandatory collection # for the ports collection, and your ports may not build correctly if it # is not kept up to date. #ports-base Good luck! Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: teTeX/TeXLive: powerdot still missing ...
On Thu, Sep 18, 2008 at 02:03:01PM +, O. Hartmann wrote: Still using teTeX, but as we all know, development has been canceld by Thomas Esser. I'm looking for a working 'powerdot' which is part of TeXLive now, but there is no TeXLive-port available for FreeBSD. Searching for that matter brings up some informations released a year ago and I'm wondering about the fact that there is no support for FreeBSD. Is there a workaround or 'master plan' how to bring TeXLive to a FreeBSD bx in a clean way? Can TeXLive coexists with teTeX. Not about porting TeXLive to FreeBSD actually. After a quick look at 'powerdot' class I can suggest you using 'beamer' as a workaround. It is in the teTeX. Porting of TeXLive is a todo anyway, I think. Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devel/libtool15 unconditionally hardcodes autodetected textproc/gsed
On Tue, Sep 09, 2008 at 06:11:44PM +0400, Dmitry Marakasov wrote: * Peter Pentchev ([EMAIL PROTECTED]) wrote: This is definitely a bug, so better send-pr for this issue not to be lost while we're in freeze. What I mean is the following scenario: - libfoo uses libtool for its build - libfoo depends on libbar which depends on GNU sed - during libfoo's build, libbar is built, thus gsed is installed - during libfoo's build, libtool detects gsed installed and remembers it No, as previously built libtool package will be used, which doesn't use gsed for sure. - in libfoo's binary package, there is a shell script that uses gsed, because libtool knows gsed is present on the system - an unsuspecting user installs the libfoo binary package without previously building libbar - the unsuspecting user gets a shell script that tries to run gsed and fails. ... If libtool may put gsed into libfoo's binary package, this should be fixed before the freeze. If libtool only uses gsed during libfoo's build, then it is not a critical problem. Neither seem to be the case for package building. Of course, if Dmitry is more familiar with libtool than I am, and he I am most likely not, knows that libtool does not leave any such files, then I've just wasted everybody's time with unneeded idle speculation, for which I apologize :) but my vision is that the problem will only show itself if you build libtool with gsed installed and then deinstall gsed. Thus, you'll end up with defunct libtool and all ports which have USE_AUTOTOOLS=libtool:15 will fail to build. I have encountered this with x11/libX11, FWIW. The error was 'gsed not found' or something similar. Since this doesn't affect package builds, I don't this this is serious enough to fix duing freeze. But still to be fixed :) Yes, but the releases will be bundled with a 'broken' devel/libtool15 port. Many [new] users could be using this port tree for a rather long time... I have filed PR with the proposed patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=127256 Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
devel/libtool15 unconditionally hardcodes autodetected textproc/gsed
Hello all! While the ports are in freeze just want to point to the problem I have encountered. Not sure if this is a critical bug, just a bug or not a bug at all (so, no PR yet). If one installs/rebuilds devel/libtool15 while textproc/gsed is installed, libtool autodetects it and hardcodes gsed in itself. If later one removes gsed (and nothing prevents him from doing this), libtool is left in a broken state. FWIW, textproc/gsed is a BUILD_DEPENDS of some ports. Ideally, I think, one should hack libtool's configure framework to not detect gsed at all. Sorry, no patch here. Attached is the diff between unpacked libtool packages, one built with system sed and one - with gsed. Alexey. diff -ruN libtool-good/+CONTENTS libtool-bad/+CONTENTS --- libtool-good/+CONTENTS 2008-09-08 10:29:34.0 +0200 +++ libtool-bad/+CONTENTS 2008-09-08 20:50:41.0 +0200 @@ -4,7 +4,7 @@ @cwd /usr/local @comment $FreeBSD: ports/devel/libtool15/pkg-plist,v 1.13 2006/02/23 10:36:03 ade Exp $ bin/libtool [EMAIL PROTECTED] MD5:d82d18482a1bdb6a66b4a88e5f6af477 [EMAIL PROTECTED] MD5:553962c30b1587c8cd17cd90a252a8f2 bin/libtoolize @comment MD5:efbc69981145a9fac91f0f875ba11c3e share/aclocal/libtool.m4 diff -ruN libtool-good/bin/libtool libtool-bad/bin/libtool --- libtool-good/bin/libtool2008-09-08 10:29:29.0 +0200 +++ libtool-bad/bin/libtool 2008-09-08 20:50:36.0 +0200 @@ -30,10 +30,10 @@ # the same distribution terms that you use for the rest of that program. # A sed program that does not truncate output. -SED=/usr/bin/sed +SED=/usr/local/bin/gsed # Sed that helps us avoid accidentally triggering echo(1) options like -n. -Xsed=/usr/bin/sed -e 1s/^X// +Xsed=/usr/local/bin/gsed -e 1s/^X// # The HP-UX ksh and POSIX shell print the target directory to stdout # if CDPATH is set. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amule 2 port - trying an upgrade
On Mon, Aug 18, 2008 at 10:31:21PM +0200, Torfinn Ingolfsen wrote: As a first try, I have come up with the following diff[1]. The port compiles fine, but the installation step fails, because most of the man pages doesn't get installed. Here is the relevant part of the 'make install': === Compressing manual pages for aMule-2.2.2_1 gzip: can't stat: /usr/local/man/man1/cas.1: No such file or directory [snip] gzip: can't stat: /usr/local/man/hu/man1/amule.1: No such file or directory === Registering installation for aMule-2.2.2_1 Any hnts on how I fix this? I have read the man pages[2] chapter in the Porter's Handbook, but it didn't help me. AFAICT, the Makefile.man should work as is. Port system does not install man pages for you. This should be done by the build scripts in the distribution tarball. You should probably look at various Makefiles* and/or configure script. FYI, the port failed to patch with your diff: === Applying FreeBSD patches for aMule-2.2.2_1 1 out of 2 hunks failed--saving rejects to src/amuleDlg.cpp.rej = Patch patch-amuleDlg.cpp failed to apply cleanly. *** Error code 1 Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
unBREAK cad/brlcad on CURRENT.
Hello list! After recent commit of MPSAFE TTY layer cad/brlcad builds and runs successfully on CURRENT: uname -a FreeBSD wep4017.physik.uni-wuerzburg.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Aug 20 17:15:25 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 However, it is marken as BROKEN= does not compile. The relevant PR, when it was marked BROKEN is http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/124733 The reason for this was not the changes in TTY layer (namely, in termios.h), but rather some white space problem on tinderbox. From brlcad-7.12.4.log: [snip] configure: configuring in misc/enigma [snip] configure: loading cache ../../config.cache.freebsd8.0.regis.goodking.ca configure: error: `CFLAGS' has changed since the previous run: configure: former value: -O2 -pipe -fno-strict-aliasing configure: current value: -O2 -pipe -fno-strict-aliasing configure: error: changes in the environment can compromise the build configure: error: run `make distclean' and/or `rm ../../config.cache.freebsd8.0.regis.goodking.ca' and start over configure: error: /bin/sh './configure' failed for misc/enigma [snip] I cannot reproduce this error during normal build. Could someone familiar with tinderbox environment unBREAK the port? Should I file a PR? Thanks, Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible copyright problems in some games [Fwd: Removal of illegal packages]
On Mon, Aug 18, 2008 at 02:11:35PM +0400, Dmitry Marakasov wrote: - Forwarded message from Stephen Sweeney [EMAIL PROTECTED] - Date: Sat, 16 Aug 2008 19:02:15 +0100 From: Stephen Sweeney [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Removal of illegal packages Hi there, It is with much regret that I have to ask you to remove the following packages from your repositories, blobwars (Blob Wars : Metal Blob Solid) starfighter (Project: Starfighter) blobAndConquer (Blob Wars : Blob And Conquer) viruskiller (Virus Killer) It has been brought to my attention by a Happy Penguin regular, leileilol, that the packages contain resources that are non-free and, in some cases, ripped from other games and still copyrighted. They should all be removed immediately to avoid any legal issues. It would be within the interests of all if we could get these games removed ASAP so that your distributions are not affected by any legal issues. Please could you forward this email along to any one else you may know who is a package maintainer. Thank you, Stephen Sweeney From http://www.parallelrealities.co.uk/virusKiller.php: License Source code is distributed under the GNU General Public License. Resources are Non Free. This game should not be added to Linux distributions or respositories. From porters-handbook: RESTRICTED should be set to a string describing the reason why the port cannot be redistributed. Typically, this indicates that the port contains proprietary software and that the user will need to manually download the DISTFILES, possibly after registering for the software or agreeing to accept the terms of an EULA. I think RESTRICTED is quite enough. Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ruby18 won't upgrade - Patch error
On Sun, Aug 17, 2008 at 09:45:38AM -0400, Eduardo Cerejo wrote: === Patching for ruby-1.8.6.287,1 === Applying FreeBSD patches for ruby-1.8.6.287,1 Ignoring previously applied (or reversed) patch. 3 out of 3 hunks ignored--saving rejects to lib/cgi.rb.rej = Patch patch-lib_cgi.rb failed to apply cleanly. This was fixed 8 hours after initial commit. Update your ports tree and try again. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: www/commonist BROKEN: No ${JAR} even if USE_JAVA=1.5+ defined?
On Sun, Aug 17, 2008 at 04:41:37PM +0200, Marcin Cieslak wrote:
One of my ports breaks badly on the tinderbox:
The error message is:
=== commonist-0.3.28 depends on executable: unzip - found
(cd /work/a/ports/www/commonist/work/commonist-0.3.28
/usr/local/diablo-jdk1.5.0/bin/jar xf lib/lib-util-src.jar src)
/usr/local/diablo-jdk1.5.0/bin/jar: not found
The port defines
USE_JAVA=1.5+
and uses ${JAR} to get the proper location of the tool.
What's wrong?
Not 100% sure, you should define JAVA_EXTRACT in your port also:
JAVA_EXTRACT= yes
Look at ports/Mk/bsd.java.mk and some ports too
(cd /usr/ports ; grep -R JAVA_EXTRACT):
finance/venice
games/robocode
games/sbfol
java/eclipse-pmd
print/arobatviewer
...
Seems to be not well documented and rarely used variable.
Just my 0.02$,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ruby port broken? SOLVED
On Sun, Aug 17, 2008 at 08:42:52AM -0600, hideo wrote: Apparently, whatever worked for you hasn't done me any good: === Patching for ruby-1.8.6.287,1 === Applying FreeBSD patches for ruby-1.8.6.287,1 Ignoring previously applied (or reversed) patch. 3 out of 3 hunks ignored--saving rejects to lib/cgi.rb.rej = Patch patch-lib_cgi.rb failed to apply cleanly. = Patch(es) patch-ext_tk_tkutil_extconf.rb patch-io.c applied cleanly. *** Error code 1 Stop in /usr/ports/lang/ruby18. *** Error code 1 Stop in /usr/ports/lang/ruby18. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade.20719.0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=ruby-1.8.6.111_5,1 UPGRADE_PORT_VER=1.8.6.111_5,1 make ** Fix the problem and try again. Just update ports at around 8:30 MDT and it's still broken on stable. You can manually remove offending files in ports/lang/ruby18/files: patch-lib_cgi.rb patch-lib_ipaddr.rb patch-lib_optparse.rb patch-lib_resolv-replace.rb patch-lib_resolv.rb patch-lib_webrick_httputils.rb Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't seem to build mplayer on up to date (today) current i386
On Sun, Aug 17, 2008 at 10:21:30AM -0500, eculp wrote: I've been trying to build multimedia/mplayer for a couple of days now and end with the following error: In file included from ../libavutil/bswap.h:30, from ../mpbswap.h:4, from ao_pcm.c:8: ../libavutil/common.h:98: error: redefinition of 'av_log2' /usr/local/include/libavutil/common.h:124: error: previous definition of 'av_log2' was here [snip] gmake[1]: *** [ao_pcm.o] Error 1 gmake[1]: Leaving directory `/usr/ports/multimedia/mplayer/work/MPlayer-1.0rc2/libao2' gmake: *** [libao2/libao2.a] Error 2 Any suggestions appreciated. Thanks. http://lists.freebsd.org/pipermail/freebsd-multimedia/2008-July/008856.html already pointed out on this list earlier by Mezz. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
[x11-toolkits/gtkdatabox[2]]: Kind request to commit an update
Hello dear commiters :-
There is a
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/123937
laying around for about 1.5 month. It is just a little bit non-trivial
update to the port (see the notes in the PR).
As for the maintainership claim one can see the beginning of the history at
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/116120
I belive one should not wait another maintainer timeout?
It would be nice if someone can commit this somewhere around weekend so I can
finish the trilogy x11-toolkits/{slgtk,gtkdatabox,slgtkdatabox}.
Here, the latest version of slgtkdatabox (not in the tree) is built
upon the latest version of gtkdatabox (not updated yet).
Thanks in advance,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 8-current/kde3 stty defaults incorrect under konsole
On Wed, Jun 25, 2008 at 04:51:02PM +0200, Alexey Shuvaev wrote: Hello! On Wed, Jun 25, 2008 at 07:10:14AM -0700, Mark Atkinson wrote: Hi, Is anyone else running freebsd-current with kde3 (and has rebuilt both recently)? I can only suspect this is related to recent changes in current in prep for mpsafe tty, but in konsole, the defaults turn out to be this (note the missing '^' on intr and quit): cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = undef; eol2 = undef; erase = ^?; erase2 = ^H; intr = C; kill = ^U; lnext = ^V; min = 1; quit = \; reprint = ^R; start = ^Q; status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W; xterm and the freebsd console are fine. I have noticed that cursor key (right, forward direction) does not work as expected. By pressing it cancels the current command line and prompts with the empty one again. [snip] On Wed, Jun 25, 2008 at 04:34:28PM +0200, Ed Schouten wrote: Blegh. I always hate those applications using non-documented extensions in a non-standard way. ;-) Anyway, could you store this patch in the files/ dir of the kdelibs3 port and see what happens? Thanks! :) %%% --- kdecore/kpty.cpp +++ kdecore/kpty.cpp @@ -128,9 +128,8 @@ #include kstandarddirs.h // locate // not defined on HP-UX for example -#ifndef CTRL -# define CTRL(x) ((x) 037) -#endif +#undef CTRL +#define CTRL(x) ((x) 037) #define TTY_GROUP tty %%% Thanks, I will try this but it takes a while, it is 800MHz Pentium3 :-) Alexey. I have rebuilt kdelibs with this patch and now both wrong stty -a values and issues with cursor keys are gone. Thanks! Any chance to have this patch in the ports tree? Alexey. --- kdecore/kpty.cpp +++ kdecore/kpty.cpp @@ -128,9 +128,8 @@ #include kstandarddirs.h // locate // not defined on HP-UX for example -#ifndef CTRL -# define CTRL(x) ((x) 037) -#endif +#undef CTRL +#define CTRL(x) ((x) 037) #define TTY_GROUP tty ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Issues with portmaster
Hello!
On Mon, Jun 23, 2008 at 12:49:22AM -0700, Doug Barton wrote:
Alex Dupre wrote:
Doug Barton ha scritto:
Portmaster uses CONFLICTS to avoid this issue.
I can't see how CONFLICTS could solve this issue: we can install all
the JDKs together without problems
It seems I don't understand something here. Can someone explain why
jdk ports need to set BUILD_DEPENDS on diablo-jdk15 unconditionally?
Why it is not possible to define it inside 'if !defined(BOOTSTRAPJDKDIR)'?
(See attached patch.)
Just curious,
Alexey.
--- Makefile.orig 2008-06-23 10:33:59.0 +0200
+++ Makefile2008-06-23 10:34:36.0 +0200
@@ -108,9 +108,8 @@
# if no valid jdk found, set dependency
.if !defined(BOOTSTRAPJDKDIR)
BOOTSTRAPJDKDIR?= ${LOCALBASE}/diablo-jdk1.5.0
-.endif
-
BUILD_DEPENDS+=
${BOOTSTRAPJDKDIR}/bin/javac:${PORTSDIR}/java/diablo-jdk15
+.endif
.if defined(WITHOUT_WEB)
MAKE_ENV+= DONT_BUILD_DEPLOY=YES
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Issues with portmaster
On Mon, Jun 23, 2008 at 10:57:41AM +0200, Alex Dupre wrote: Alexey Shuvaev ha scritto: It seems I don't understand something here. Can someone explain why jdk ports need to set BUILD_DEPENDS on diablo-jdk15 unconditionally? (nearly) every JDK port needs an already usable/installed JDK to bootstrap the compilation. This is the reason of the BUILD_DEPENDS on javac that you cannot remove. But the port providing the javac binary ^ could not be the diablo-jdk. Mmmm... why not??? In a nutshell, from the user point of view the reason to set BUILD_DEPENDS is to ensure that some port (java here) is installed prior to build. However, if the port checks against installed java in a more complicated manner than BUILD_DEPENDS mechanism can provide, I see no reason to set BUILD_DEPENDS to something just for its own sake. And from the build cluster point of view, the port will be built in a clean environment, so port will not detect any installed java and will set BUILD_DEPENDS *conditionally* (.if !defiend(BOOTSTRAPJDKDIR)). I have a feeling that the way BUILD_DEPENDS is set now is overkill, and one can put it under .if !defined(BOOTSTRAPJDKDIR) without any functional change. Of course, the Right Way To Do This would be to set the whole correct BUILD_DEPENDS line based on detected java. Maybe this is even not so complicated. Or I miss something? Just 0.02$, Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Building enlightenment-devel fails
On Thu, May 29, 2008 at 07:52:18AM +0200, [EMAIL PROTECTED] wrote: Hi All, I'm running a FreeBSD 6.3-PRERELEASE and after a portupgrade building enlightenment-devel fails with following error. --snip-- libtool: link: cannot find the library `/usr/local/lib/libecore_dbus.la' or unhandled argument `/usr/local/lib/libecore_dbus.la' gmake[3]: *** [enlightenment] Error 1 --snip-- I googled this problem an found this --snip-- This removes the DBUS check for ecore. Since ecore does not appear to link against any other DBUS port, it is not necessary. In addition enlightenment-devel will not build if ecore does not have DBUS enabled due to a dependency on Ecore_DBus.h in e.h. A better way is welcome. --snip-- The attached patch doesn't solve the problem as I dunno know which Makefile to patch. /usr/ports/x11/ecore/Makefile doesn't exist on my machine, only /usr/ports/x11/ecore-desktop. This was not the first problem with the upgrade. As ports/UPDATING said on 20080312 ecore and evas have been splitted. After uninstalling and clean reinstalling all e-related packages now problems with libcore_dbus.la occure. Please excuse my probably stupid questions here, but I'm relatively new to FreeBSD and try to fix most of my problems by myself. But in here im stuck. Any help will be highly appreciated. Could you check that you have up-to-date and consistent ports? Or, otherwise, is it possible that there are some stale files laying around in your system? I have just installed x11-wm/enlightenment-devel without any problems and it runs too. I have no libecore_dbus.* library. The dbus binding is in devel/e_dbus now and installed as libedbus.*. BTW, ecore is in devel/ecore and friends (deve/ecore-*), if it matters. My system (amd64 FreeBSD-CURRENT) was updated yesterday (both base and ports): -rw-r--r-- 1 root wheel 16507539 May 28 12:16 /usr/ports/INDEX-8 I would suggest removing ALL enlightenment-related ports first and starting from scratch then. To locate which package has installed libecore_dbus, you can run, for example: ~ grep -R libecore_dbus /var/db/pkg/ On my system this command produces no output, but: ~ grep -R libedbus /var/db/pkg/ /var/db/pkg/e_dbus-20080223/+CONTENTS:lib/libedbus.a /var/db/pkg/e_dbus-20080223/+CONTENTS:lib/libedbus.la /var/db/pkg/e_dbus-20080223/+CONTENTS:lib/libedbus.so /var/db/pkg/e_dbus-20080223/+CONTENTS:lib/libedbus.so.1 shows that libedbus is inside e_dbus-20080223 package. Hope this helps, Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Gnome reference framework bsd.gnome-reference.mk VS [NO]PORTDOCS
Hello list! I am working on update to x11-toolkits/gtkdatabox2 and it has recently got an html reference (built using gtk-doc). The gtkdatabox2 is a rather rarely used port and its reference consists of app. 25 files (for now). What is better, - to create separate gtkdatabox-reference port, or - to intstall documentation from the existing port, under the control of NOPORTDOCS variable? The second question is about bsd.gnome-reference.mk framework discussed recently[1]. Althoug gtkdatabox is not an official part of gnome, it uses the same structure and therefore could be handled in the same way as other official gnome components. Are there any reasons to use one of: - devel/glib20-reference/bsd.gnome-reference.mk framework - handling docs on one's own? Thanks, Alexey. 1. http://lists.freebsd.org/pipermail/freebsd-ports/2008-May/048645.html http://lists.freebsd.org/pipermail/freebsd-ports/2008-May/048647.html ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FBSD 7, Gnome2-lite port broken
On Sun, Apr 20, 2008 at 05:16:43AM +1000, Da Rock wrote: I've tried checking as far as my knowledge will allow the reason for this error, but its got me beat. I was installing the above port, and the config screen came up for one of its dependencies surrounding ghostscript I believe where it said don't be stingy on the options selected as another port might need it later. So I checked them all as I probably will need them all at some point in the future. Also to note here there was a majority already selected to begin with. Unfortunately, I can't find that screen again to uncheck some options, and I think its ghostscript-gpl which is failing. It errors on not finding vga.h and lvga.h files. So I installed all src's from sysinstall, but NG. It seems that you have checked lvga256 and vgalib options in ghostscript-gpl configuration dialog. This dialog is not the standart port's OPTIONS dialog and it doesn't remember the options you have choosen between builds. So, to fix the build: cd /usr/ports/print/ghostscript-gpl make clean make install Once you are in this dialog again, just go on with the defaults. BTW, can someone more experienced comment on reasons to have non-standard configure script? Possibly related: are there any non-trivial reasons to have ghostscript (rather significant for many other ports) maintained by ports@ ? Or are there just no volunteers? Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: what is gio-fam?
On Mon, Apr 14, 2008 at 10:31:18AM -0500, Jeremy Messenger wrote: On Mon, 14 Apr 2008 10:09:06 -0500, Jeremy Messenger [EMAIL PROTECTED] wrote: On Mon, 14 Apr 2008 03:50:09 -0500, Alexey Shuvaev [EMAIL PROTECTED] wrote: snip IMHO gio-fam-backend should not be implicit dependency. Otherwise why not to install all existing non-conflicting libraries just to ease maintainer's life :- FWIW x11-toolkits/gtkdatabox2 (PR 116120) do not need gio-fam-backend. Well, all ports should depend on gio-fam-backend. The gio is included and part of glib20. marcus had to split gio out of glib20 package to avoid circle dependency of glib20 - gamin (FAM replacement) - glib20. If marcus doesn't split and you guys will have that gio library anyway. Thanks, somewhat much clearer now. I had some feeling that gio-fam-backend is freebsd specific. How many chances are there to account for existence of gamin upstream? (So to avoid glib - gamin - glib circular dependency) Uh, I should have check in glib20 and gio-fam-backend before I made that comment. I thought that gio (libgio-2.0.so) is in gio-fam-backend, but not it's in glib20. The gio-fam-backend only installs libgiofam.so and FAM support is option in glib configure. I don't think it will be easy to make optional (maybe I am wrong) with that split. Remove gio-fam-backend dependency is going to hurt some users if they want some missing fuction(s) of it. So configure option is not enough. Does separating gio-fam-backend by original developers solve the problem better? Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: what is gio-fam?
On Sun, Apr 13, 2008 at 05:59:09PM +0200, Henrik Brix Andersen wrote: On Tue, Apr 08, 2008 at 10:17:56PM -0400, Joe Marcus Clarke wrote: gio-fam-backend is a new piece of glib which provides a wrapper around FAM to allow applications to monitor file objects using a glib API. But this is optional, right? Any reason for making gio-fam-backend an implicit dependency for all software, that depends on glib20? On my systems, this means I will get gio-fam-backend installed even though I don't have FAM installed at all. Hello! Just another vote against gio-fam-backend. I had have a quick look at mailing lists archives and hadn't found any discussion about it prior to commit. The point is thas gtk != gnome. Even more so glib != gnome. Introducing gio-fam-backend as a dependency to glib automatically adds it to the dependency lists of too many other (not gnome related) ports. Personally I don't use neither gnome nor kde but I use gtk apps (gqview, gimp, beep-media-player, mplayer, seamonkey, ...) and for now I have no FAM system installed and I don't want any at all. I had some experience with FAM some time ago when it was non-optional requirement for samba. Since then I don't like FAM systems due to their 'viral' nature: many ports will auto-detect and uncoditionally link with them. Sweeping FAM out of the system after that is not straightforward process. Another aspect is that FAM is not so critical for most apps (I believe). With samba it is clear: samba wants to monitor its conf files in order to apply changes immediately. And what is the use of FAM for typical gui-user-application? Any example of such app that really will not properly function without gio-fam-backend? (Well, I am sure there are such and gio-fam-backend was made a dependency for glib not just for fun. But some examples would not hurt anyone.) Joe Marcus Clarke at Mon Mar 24 20:27:23 PDT 2008: Glib 2.16 (with GIO) was designed to support pluggable file monitor backends. Without one such backend, any libgio consumer would be severely handicapped. The only reason gio-fam-backend is broken out as a separate port is that we have one FAM provider that requires glib. If this was not the case, we'd just have glib20 depend on FAM. ^^^ why glib? Recompiling alone is not sufficient. Ports will happily build without this backend, but may not run correctly if they require libgio. The cost of the FAM dependency is minimal (most GNOME apps already had this as part of gnome-vfs), ^^^ ^^^ ^^^ Well, gnome-vfs can really need FAM support. But then why not to add gio-fam-backend as a dependency to gnome-vfs instead of glib? If I understand things correctly one can install gio-fam-backend (which is pluggable module) at any point provided glib is already installed. So moving gio from glib to gnome-vfs will not only make gio-fam-backend more gnome specific but also possibly remove the hack with _glib20. and it just makes things easier for developers not to have to worry about adding the gio-fam-backend dependency. IMHO gio-fam-backend should not be implicit dependency. Otherwise why not to install all existing non-conflicting libraries just to ease maintainer's life :- FWIW x11-toolkits/gtkdatabox2 (PR 116120) do not need gio-fam-backend. Just my 0.02$, Alexey. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
