Porting Songbird (how to make a Linux port)
Here is the start of a Makefile for Songbird http://isis.poly.edu/~eitan/files/Songbird-Makefile-v1 The porter's handbook doesn't have a section on the Linux ports (as far as I could tell). I also don't know how I could just mv the files that have to be moved. There is no compiling involved - just running the program. -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen ___ 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"
Automatically generate symlinks for virtual categories.
I made this shell script (portable sh) that will create a bunch of directories for all virtual ports (linux, perl, etc.). It puts a symlink for every port in your tree into the correct categories. For example it will create a kde directory with the akode-audio port pointing to /usr/ports/audio/akode. http://isis.poly.edu/~eitan/files/auto-symlink-virtual.sh At the moment it relies on make to determine what categories each port is in. This is somewhat slow but the only error-proof way I know how. If anyone could improve the script please let me know. It is released under the BSD-2-clause license. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Automatically generate symlinks for virtual categories.
Vitaly Magerya wrote: > And here [1] is a new version that does the same thing, > but uses INDEX file instead of traversing the ports tree. > It's quite faster this way (assuming your INDEX is up to date, > maybe it's better to allow both algorithms?). I'll added your script to mine as a option. > > Disclaimer: I did not test it properly. > > The thing that looks strange to me is that the original script > appends main category to the name of port when symlinking. > I copied that behavior for safety, but are there really > naming conflicts in the ports tree? Yes. A lot of programs have category/name and language/name for localized versions. > > [1] http://tx97.net/pub/files/auto-symlink-virtual.sh > Current version: http://isis.poly.edu/~eitan/files/auto-symlink-virtual-2.sh I'll be making a port of this soon ;) -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen ___ 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 Songbird (how to make a Linux port)
Martin Wilke wrote: > On Thu, Jun 04, 2009 at 06:51:56PM -0400, Eitan Adler wrote: >> Here is the start of a Makefile for Songbird >> http://isis.poly.edu/~eitan/files/Songbird-Makefile-v1 > >> The porter's handbook doesn't have a section on the Linux ports (as far >> as I could tell). > >> I also don't know how I could just mv the files that have to be moved. >> There is no compiling involved - just running the program. > > Gecko Team is working on a nativ port :-) True - but we also have linux versions of Firefox and Thunderbird ;) Plus we still should have some documentation on making a linux-* port. > >> -- >> Eitan Adler >> "Security is increased by designing for the way humans actually behave." >> -Jakob Nielsen >> ___ >> 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" > > -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen ___ 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: Automatically generate symlinks for virtual categories.
Vitaly Magerya wrote: >> I'll added your script to mine as a option. > Yeah, I've done that too in the mean time, take a look: [1]. > In that version both traverse algorithms share common linking code, > it seems more maintainable this way. Interesting - I will play with my version and try to make it more modular like yours. I'm also working on making it a port: ports-mgmt/symports. > (I've added -w and -i to catch up with you, but the code overall > is quite different, sorry about that). No problem - different code == interesting code > > There's a question about the test for main category dir: > if you use -w to specify a directory different than that of -p, > a simlink "$whereto/category/portname-category" will be created. > Maybe "$whereto/category/portname" would be the right thing in this case? No - you still have the issue of languages. For example japanese/xchat and irc/xchat have the same name. This is the issue I was trying to avoid. > > [1] http://tx97.net/pub/files/auto-symlink-virtual.sh > Thanks for the ideas (and code)! -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen ___ 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: Automatically generate symlinks for virtual categories.
I fixed all known problems as well as moving things into maintainable functions: http://isis.poly.edu/~eitan/files/auto-symlink-virtual-3.sh -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen ___ 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: Automatically generate symlinks for virtual categories.
Attached is the Makefile from the port. In order to save space I'm not
attaching pkg-descr, or distinfo.
--
Eitan Adler
"Security is increased by designing for the way humans actually behave."
-Jakob Nielsen
# New ports collection makefile for: symlink
# Date created:Fri Jun 05 2009
# Whom: Eitan Adler
#
# $FreeBSD$
#
PORTNAME= symlink
PORTVERSION=3
CATEGORIES= ports-mgmt
MASTER_SITES= http://isis.poly.edu/~eitan/files/
DISTNAME= auto-symlink-virtual-${PORTVERSION}.sh
EXTRACT_SUFX=
MAINTAINER= eitanadlerl...@gmail.com
COMMENT=Automatically generate symlinks for virtual categories
NO_BUILD= yes
NO_EXTRACT= yes
EXTRACT_CMD=true
PLIST_FILES=bin/${PORTNAME}
do-install:
${INSTALL_SCRIPT} ${DISTDIR}/${DISTNAME} ${PREFIX}/bin/${PORTNAME}
.include
___
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: Automatically generate symlinks for virtual categories.
Newest version's Makefile is attached.
--
Eitan Adler
"Security is increased by designing for the way humans actually behave."
-Jakob Nielsen
# New ports collection makefile for: symlink
# Date created:Fri Jun 05 2009
# Whom: Eitan Adler
#
# $FreeBSD$
#
PORTNAME= symlink
PORTVERSION=4
CATEGORIES= ports-mgmt
MASTER_SITES= http://isis.poly.edu/~eitan/files/
DISTNAME= auto-symlink-virtual-${PORTVERSION}.sh
EXTRACT_SUFX=
MAINTAINER= eitanadlerl...@gmail.com
COMMENT=Automatically generate symlinks for virtual categories
NO_BUILD= yes
EXTRACT_ONLY= # nada
PLIST_FILES=bin/${PORTNAME}
do-install:
${INSTALL_SCRIPT} ${DISTDIR}/${DISTNAME} ${PREFIX}/bin/${PORTNAME}
.include
___
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"
porting dash (the shell)
if gcc -DBSD=1 -DSMALL -DSHELL -DGLOB_BROKEN -DFNMATCH_BROKEN -DIFS_BROKEN -D__COPYRIGHT\(x\)= -D__RCSID\(x\)= -D_DIAGASSERT\(x\)= -I. -I. -I.. -include ../config.h -g -O2 -Wall -MT exec.o -MD -MP -MF ".deps/exec.Tpo" \ -c -o exec.o `test -f 'exec.c' || echo './'`exec.c; \ then mv -f ".deps/exec.Tpo" ".deps/exec.Po"; \ else rm -f ".deps/exec.Tpo"; exit 1; \ fi exec.c: In function 'find_command': exec.c:317: error: storage size of 'statb' isn't known exec.c:326: warning: implicit declaration of function 'stat64' exec.c:317: warning: unused eitan 'statb' gmake[3]: *** [exec.o] Error 1 gmake[3]: Leaving directory `/home/eitan/dash-0.5.1/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/eitan/dash-0.5.1/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/eitan/dash-0.5.1' gmake: *** [all] Error 2 -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen ___ 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 dash (the shell)
Boris Kochergin wrote: > Eitan Adler wrote: >> if gcc -DBSD=1 -DSMALL -DSHELL -DGLOB_BROKEN -DFNMATCH_BROKEN >> -DIFS_BROKEN -D__COPYRIGHT\(x\)= -D__RCSID\(x\)= -D_DIAGASSERT\(x\)= -I. >> -I. -I.. -include ../config.h -g -O2 -Wall -MT exec.o -MD -MP -MF >> ".deps/exec.Tpo" \ >> -c -o exec.o `test -f 'exec.c' || echo './'`exec.c; \ >> then mv -f ".deps/exec.Tpo" ".deps/exec.Po"; \ >> else rm -f ".deps/exec.Tpo"; exit 1; \ >> fi >> exec.c: In function 'find_command': >> exec.c:317: error: storage size of 'statb' isn't known >> exec.c:326: warning: implicit declaration of function 'stat64' >> exec.c:317: warning: unused eitan 'statb' >> gmake[3]: *** [exec.o] Error 1 >> gmake[3]: Leaving directory `/home/eitan/dash-0.5.1/src' >> gmake[2]: *** [all] Error 2 >> gmake[2]: Leaving directory `/home/eitan/dash-0.5.1/src' >> gmake[1]: *** [all-recursive] Error 1 >> gmake[1]: Leaving directory `/home/eitan/dash-0.5.1' >> gmake: *** [all] Error 2 >> >> > stat64() and the statb structure appear to be some kind of Linuxisms. > FreeBSD's stat() doesn't have any trouble with file sizes of over 2 GiB, > so try replacing the stat64() call with stat() and the statb structure > with a stat structure. > > -Boris > After doing a global search and replace of stat64 to stat I get: mystring.c: In function 'single_quote': mystring.c:164: warning: implicit declaration of function 'strchrnul' mystring.c:164: error: invalid operands to binary - mystring.c:169: warning: implicit declaration of function 'mempcpy' mystring.c:169: warning: incompatible implicit declaration of built-in function 'mempcpy' -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen ___ 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"
updating the allegro-devel port
If you download allegro and follow the following steps allegro happily
compiles and installs. I copied and modified the Makefile from the
current allegro-devel port and I'm having some difficulty making it
cooperate. The patches are in the files/ directory.
0) apply (reversed) patches
1) run ./fix.sh unix
2) run gmake depend
3) run gmake
4) run gmake install
5) run gmake install-gzipped-man
instead of #2 and #3 you could also run gmake full-build
If someone could help me fix this Makefile it would really help ;)
--
Eitan Adler
# New ports collection makefile for:allegro
# Date created: 23-Feb-2001
# Whom: Eitan Adler
#
# $FreeBSD$
#
PORTNAME= allegro
DISTVERSION=4.3.10
CATEGORIES= devel
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE}
MASTER_SITE_SUBDIR= alleg
PKGNAMESUFFIX= -devel
MAINTAINER= eitanadlerl...@gmail.com
COMMENT=A cross-platform library for games and multimedia programming
USE_AUTOTOOLS= autoconf:262
USE_GMAKE= yes
USE_XORG= x11 xpm xext xcursor xxf86vm xxf86dga
USE_LDCONFIG= yes
WANT_GNOME= yes
OPTIONS=AL "Enable OpenAL support" off \
ARTS "Enable Arts support" off \
DEBUG "Build debugging library" off \
DEVEL "Build development utilities" on \
ESOUND "Enable Esound support" off \
JACK "Enable JACK support" off \
OPTIMIZED_CFLAGS "Enable compilation optimizations" on \
PROFILE "Build profiling library" off \
THREADS "Enable threads" on
MAKEFILE= makefile
ALL_TARGET= full-build
.include "Makefile.man"
INFO= allegro
CONFLICTS= allegro-[0-9]*
LATEST_LINK=${PORTNAME}${PKGNAMESUFFIX}
PLIST_SUB= SHLIB_VER="${SHLIB_VER}"
DEMO= demo.c demo.dat demo.h music.txt ../readme.txt
SHLIB_VER= 43
.include
.if defined(WITH_AL)
LIB_DEPENDS+= openal.0:${PORTSDIR}/audio/openal
CONFIGURE_ARGS+=--enable-sgialdigi
PLIST_SUB+= AL=""
.else
CONFIGURE_ARGS+=--disable-sgialdigi
PLIST_SUB+= AL="@comment "
.endif
.if defined(WITH_ARTS)
LIB_DEPENDS+= artsc.0:${PORTSDIR}/audio/arts
CONFIGURE_ARGS+=--enable-artsdigi
PLIST_SUB+= ARTS=""
.else
CONFIGURE_ARGS+=--disable-artsdigi
PLIST_SUB+= ARTS="@comment "
.endif
.if defined(WITH_DEBUG)
CONFIGURE_ARGS+=--enable-dbglib
PLIST_SUB+= DEBUG=""
.else
CONFIGURE_ARGS+=--disable-dbglib
PLIST_SUB+= DEBUG="@comment "
.endif
.if !defined(WITHOUT_DEVEL)
INSTALL_TARGET= full-install install-man install-info
PLIST_SUB+= DEVEL=""
.else
INSTALL_TARGET= mini-install install-man install-info
PLIST_SUB+= DEVEL="@comment "
.endif
.if defined(WITH_ESOUND)
USE_GNOME+= esound
CONFIGURE_ARGS+=--enable-esddigi
PLIST_SUB+= ESOUND=""
.else
CONFIGURE_ARGS+=--disable-esddigi
PLIST_SUB+= ESOUND="@comment "
.endif
.if defined(WITH_JACK)
LIB_DEPENDS+= jack.0:${PORTSDIR}/audio/jack
CONFIGURE_ARGS+=--enable-jackdigi
PLIST_SUB+= JACK=""
.else
CONFIGURE_ARGS+=--disable-jackdigi
PLIST_SUB+= JACK="@comment "
.endif
.if defined(WITH_PROFILE)
CONFIGURE_ARGS+=--enable-proflib
PLIST_SUB+= PROFILE=""
.else
CONFIGURE_ARGS+=--disable-proflib
PLIST_SUB+= PROFILE="@comment "
.endif
.if !defined(WITHOUT_THREADS)
CONFIGURE_ARGS+=--enable-pthreads
CONFIGURE_ENV= CPPFLAGS="${PTHREAD_CFLAGS} -DHAVE_LIBPTHREAD" \
LDFLAGS="${PTHREAD_LIBS}"
.else
CONFIGURE_ARGS+=--disable-pthreads
.endif
post-patch:
# Change "x.y.z" into "xy" in the shared library version.
@${REINPLACE_CMD} -e 's|${PORTVERSION}|${SHLIB_VER}|g' \
${WRKSRC}/makefile.ver
# Remove architecture specific optimizations.
@${REINPLACE_CMD} -e 's|$$TARGET_ARCH||g' \
${CONFIGURE_WRKSRC}/configure.in
# Remove "-ffast-math" flag on alpha, because it breaks.
.if ${ARCH} == "alpha"
@${REINPLACE_CMD} -e 's|-ffast-math||g' \
${CONFIGURE_WRKSRC}/configure.in
.endif
# Threading libraries.
@${REINPLACE_CMD} -e 's/-lpthread/${PTHREAD_LIBS}/' ${WRKSRC}/aclocal.m4
# Enable/disable compilation optimizations.
.if defined(WITHOUT_OPTIMIZED_CFLAGS)
@${REINPLACE_CMD} -e 's|-O2||g ; \
s|-ffast-math||g ; \
s|-fomit-frame-pointer||g ; \
s|-funroll-loops||g' \
${CONFIGURE_WRKSRC}/configure.in
.endif
post-install:
# Documentation.
.if !defined(NOPORTDOCS)
@${MKDIR} ${DOCSDIR}
${INSTALL_DATA} ${WRKSRC}/docs/html/*.html ${DOCSDIR}
${INSTALL_DATA} ${WRKSRC}/docs/html/*.css ${DOCSDIR}
# Example
port naming question
One of the ports I maintain (allegro) has three branches 4.2.* == main branch 4.3.* == development branch 4.9.* == the future 5.0 1) I want to make a 4.9 port - but the version number isn't yet 5.0. Is it appropriate to call the port allegro5 and just use the 4.9 version number for now? 2) How do I tell portscout to ignore 4.9.* in the allegro-devel branch? -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen ___ 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
> > I would like for it to be a real category, so we can unclutter the misc/ > folder, and encourage more local/internationalized stuff in the new category. I would like it to be a virtual category. Lets take a random i18n port: misc/koffice-i18n-th The port would get moved to editors/ and i18n would get added as a virtual category. It is more organized this way. A person looking for editors doesn't have to look in both editors/ and misc/ (or i18n/) ___ 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
> I'm constantly involved in a fight between my 'evil' and 'good' side; > I can't stand the usual US spellings as a Brit, but I always end up > admitting to myself that US spellings generally: > >make more sense; Coming from an American: $make more sense; make: don't know how to make more. Stop ___ 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"
Delete a port I maintain
The upstream author no longer maintains this port and I don't have the time to fix it. This port could be removed from the ports tree. portname: hebrew/geresh broken because: needs update for the new fribidi paragraph API build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.6.2009081417/iw-geresh-0.6.3_1.log (_Aug_23_08:41:05_UTC_2009) overview: http://portsmon.FreeBSD.org/portoverview.py?category=hebrew&portname=geresh ___ 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"
Checking for parity of ports conflicts
http://isis.poly.edu/~eitan/files/conflict-partity.sh Is a simple script which checks to make sure that when port A conflicts with port B the reverse is also true. It is not entirely accurate. Any improvements are welcome. ___ 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"
using svn to fetch for ports (yet again!)
I have a small patch to bsd.port.mk which would allow a port to
replace its do-fetch with a svn export of a /specific revision/ of a
remote repo.
I know there have been some attempts at trying this before and from
what I've been reading I addressed some of the major concerns:
1) Past attempts didn't include a basic implementation.
2) Past attempts didn't allow for a specific revision number and thus
possibly causing security issues
3) Subversion does not have to be part of the base system for my patch to work
Allowing the port to fetch from svn is beneficial for a number of
reasons some of which are listed below
1) Many project's only or main means of distribution is svn (I'm
thinking of mplayer)
2) It is easier for the port maintainer to update the port
3) It is easy for a user to quickly switch versions (outside of the
ports system) without the need for lots o knowledge about the ports
system
Some of the problems:
1) Its harder if not impossible for freeBSD to mirror the port's
source (I'm sure I could easily code a svn-to-tarball script but who
knows if the svn build servers want svn)
2) Many users may want the program they are installing but not svn
3) What about SCM's other than svn?
--- bsd.old.port.mk 2009-11-04 19:42:57.0 +0200
+++ bsd.port.mk 2009-11-04 19:59:10.0 +0200
@@ -1694,6 +1694,10 @@
MANCOMPRESSED?=no
.endif
This is a patch to bsd.port.mk which adds support for SVN_REV and SVN_FETCH
+.if defined(SVN_FETCH)
+FETCH_DEPENDS+= svn:${PORTSDIR}/devel/subversion
+.endif
+
.if defined(PATCHFILES)
.if ${PATCHFILES:M*.zip}x != x
PATCH_DEPENDS+=unzip:${PORTSDIR}/archivers/unzip
@@ -3435,6 +3439,10 @@
.if !target(do-fetch)
do-fetch:
+.if defined(SVN_FETCH)
+ ${MKDIR} ${WRKDIR}
+ svn export -r ${SVN_REV} ${SVN_PATH} ${WRKSRC}
+.else
@${MKDIR} ${_DISTDIR}
@cd ${_DISTDIR};\
${_MASTER_SITES_ENV} ; \
@@ -3503,7 +3511,9 @@
${ECHO_MSG} "=> port manually into ${_DISTDIR} and try
again."; \
exit 1; \
fi; \
-done
+ done
+.endif
+
.if defined(PATCHFILES)
@cd ${_DISTDIR};\
${_PATCH_SITES_ENV} ; \
___
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: using svn to fetch for ports (yet again!)
> I'd much rather see this used as something that reduced the amount of
> code required for maintainers to build tarballs from SVN. For example
> something similar in spirit to what I've done in devel/llvm-devel. That
> means mirroring or otherwise transfering the source around is possible.
Would a patch like the one below be what you are looking for?
(Note that I didn't test this patch that much...)
> There will likely be some objections to putting maintainer functionality
> in bsd.port.mk, but I think it would be useful enough in this case.
> Alternativly we could formalize the process a bit and put something
> Tools/scripts.
While I have no trouble writing a script to perform these tasks this
is something that I'd like to see available to end users.
I think it would useful to allow users to do something like
SVN_REV=1436 make install clean
and thus fetch from svn and install newer/older versions.
--- bsd.old.port.mk 2009-11-04 19:42:57.0 +0200
+++ bsd.port.mk 2009-11-05 22:11:51.0 +0200
@@ -3431,6 +3431,19 @@
DIR=${DIST_SUBDIR}; ${AWK} -v alg=$$alg -v file=$${DIR:+$$DIR/}$${file}
\
'$$1 == alg && $$2 == "(" file ")" {print $$4}' ${MD5_FILE}
+# SVN
+
+#vars to set
+# SVN_REV SVN_PATH SVN_USER
+do-svn:
+.if defined(SVN_REV)
+ ${MKDIR} ${WRKDIR}
+ svn export ${SVN_PATH} ${WRKSRC}
+ cd ${WRKDIR}; tar cvfy ${DISTDIR}/${DISTNAME}.tar.bz2 ${DISTNAME}
+.if ${USER} == ${SVN_USER}
+ scp ${DISTDIR}/${DISTNAME}.tar.bz2
freefall.freebsd.org:public_distfiles/
+.endif #are we the right user
+.endif #is svn_rev defined
# Fetch
.if !target(do-fetch)
___
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"
trouble porting dash shell (make errors)
I tried the dash mailing list with no reply. mksignames.c is attached. Here is the output from ./configure && gmake if gcc -DHAVE_CONFIG_H -I. -I. -I.. -include ../config.h -DBSD=1 -DSHELL -DIFS_BROKEN -Wall -g -O2 -MT nodes.o -MD -MP -MF ".deps/nodes.Tpo" -c -o nodes.o nodes.c; \ then mv -f ".deps/nodes.Tpo" ".deps/nodes.Po"; else rm -f ".deps/nodes.Tpo"; exit 1; fi gcc -include ../config.h -DBSD=1 -DSHELL -DIFS_BROKEN -g -O2 -Wall -o mksignames mksignames.c ./mksignames gmake[3]: *** [signames.c] Segmentation fault: 11 (core dumped) gmake[3]: *** Deleting file `signames.c' gmake[3]: Leaving directory `/home/eitan/dash/dash-0.5.5.1/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/eitan/dash/dash-0.5.5.1/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/eitan/dash/dash-0.5.5.1' gmake: *** [all] Error 2 mksignames.c Description: Binary data ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
RFC: svn for make fetch
I was hoping to get a bit more of a response to a recent posting of mine with regard to using svn to fetch files for ports My proposal: http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html A summary of what has been going on: http://wiki.freebsd.org/EitanAdler/ports-svn This is something that more than 2 people should have an input on ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: make config in editors/vim port
> Defining WITH_OPTIONS or WITH_VIM_OPTIONS in /etc/make.conf will enable > the regular dialog configuration screen. Why does the vim port require extra configuration to get the options configuration screen? ___ 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: svn for make fetch
Correct me if I'm wrong but I thought that svn did its own checksumming. If so why do we need to our own? ___ 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: svn for make fetch
Alright - I updated the wiki page to summarize the thread so far. I'd appreciate if people could comment on the "spec" part specifically. I'd like to see that section become much more specific (so that I could use it to unambiguously write something based off of it) I'm holding off on writing any new implementations at the moment to see where things head in terms of how things should be done. http://wiki.freebsd.org/EitanAdler/ports-svn ___ 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: svn for make fetch
Any problems with something like this in bsd.svn.mk
Comments and suggestions welcome...
x-svn-export:
svn export -r${SVN_REV} ${SVN_URL} ${WRKSRC}
x-svn-tar:
${TAR} -cjvf ${DISTNAME}.tar.bz2 ${WRKSRC}
${RM} -rf ${WRKSRC}
x-svn-head:
SVN_REV != svn info ${SVN_URL} | grep "^Last Changed Rev:"|awk
'${print $$4}'
x-svn-all: .ORDER x-svn-head x-svn-export x-svn-tar makesum
x-svn-prebuild: x-svn-export x-svn-tar checksum
___
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: svn for make fetch
Actually I was thinking of eventually adding non-svn support as well The reason I started on this project is because the version of mplayer in ports is severely out of date. When I tried to update to port I noticed that the project wants you to compile and install from svn. I also noticed a few other ports that have hacks to let the maintainers "use his/her custom scripts" stuck into the port's Makefile. I think it would be good if there was some standardized way of solving both of these problems... On Fri, Nov 13, 2009 at 3:10 AM, Wesley Shields wrote: > On Tue, Nov 10, 2009 at 10:28:17PM +0200, Eitan Adler wrote: > > Alright - I updated the wiki page to summarize the thread so far. > > I'd appreciate if people could comment on the "spec" part > > specifically. I'd like to see that section become much more specific > > (so that I could use it to unambiguously write something based off of > > it) > > > > I'm holding off on writing any new implementations at the moment to > > see where things head in terms of how things should be done. > > http://wiki.freebsd.org/EitanAdler/ports-svn > > Why only SVN? I'm not trying to be picky but if we start supporting this > for SVN it's very easy to argue we should support it for some other VCS. > Personally I think this kind of thing is best left up to the maintainer > to use his/her custom scripts and not stuff support for it into the > ports infrastructure. > > -- WXS > ___ 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: svn for make fetch
> Actually, I *had* a patch that got the source from svn, tarred it > and checksummed it, with little modification to the do-fetch target > and abusing FETCH_* variables. > The unsolvable problem I ran in to, is that svn doesn't adjust > timestamps for directories on export, so the checksum for the tar > was always different. Hacking svn export was outside my timeframe > and hacking tar to grow an option that sets all created dirs to > a fixed time stamp, seemed too hackish, so I let it go. Creating deterministic tars (ignoring "metadeta") sounds like it should be a solved problem by now. If it isn't then I will have to make it my next project ;) Anyway lets take your script above modify it so that it uploads the tarball to freebsd mirrors and includes the checksum as of the time the maintainer created the tar. This would be much closer to my proposal. ___ 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: svn for make fetch
On Wed, Nov 18, 2009 at 2:19 AM, Scot Hetzel wrote: > On Tue, Nov 17, 2009 at 3:59 PM, Eitan Adler wrote: >>> Actually, I *had* a patch that got the source from svn, tarred it >>> and checksummed it, with little modification to the do-fetch target >>> and abusing FETCH_* variables. >>> The unsolvable problem I ran in to, is that svn doesn't adjust >>> timestamps for directories on export, so the checksum for the tar >>> was always different. Hacking svn export was outside my timeframe >>> and hacking tar to grow an option that sets all created dirs to >>> a fixed time stamp, seemed too hackish, so I let it go. >> >> Creating deterministic tars (ignoring "metadeta") sounds like it >> should be a solved problem by now. If it isn't then I will have to >> make it my next project ;) >> > Instead of creating tar files, create zip files and then run them > through torrentzip > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/archivers/torrentzip/ > > Torrentzip resets the date/time on the files and directories in the > zip archive so that the checksum of the file will match, no matter who > builds the zip file using the same set of files. > > Scot > Does such a tool exist for tar archives? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
devel/allegro 4.2.2 to 4.2.3.1
I was hoping to get some testing of this patch by people who use allegro (note the last line requires files to be removed). patch-allegro Description: Binary data ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Porting Songbird - what does it depend on?
While attempting to port Songbird to firefox I get /usr/local/lib/linux-songbird/songbird-bin /usr/local/lib/linux-songbird/songbird-bin: error while loading shared libraries: libjemalloc.so: cannot open shared object file: No such file or directory What dependency am I missing? ___ 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 Songbird - what does it depend on?
> Chances are that you just need to specify something like --disable-jemalloc > to Songbird's configure script. FreeBSD's malloc implementation is pretty > much the same as the one embedded in Songbird, so there's no need to > override the system malloc. I'm using the precompiled Linux binary (like linux-firefox) ___ 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"
[RFC] Tools/ script for automatically making a tar out of svn sources
The attached script is designed to work with the 20+ ports that currently have to resort to hacks to automatically figure out the head version, checkout from svn, make a tar file, and then upload the file to freefall. It is based on some my earlier work/proposals (http://wiki.freebsd.org/EitanAdler/ports-svn) to put this directly into ports.*.mk. While that proposal was rejected by a large part of the community making a simple standard script to put into Tools was suggested by a few people as a better solution and one more likely to get accepted by the community and portmgr. This port requires that three values be defined in the ports Makefile. Of these two are already defined for most of the ports that use the hacks mentioned above. USE_SCM="svn" is required as I plan on including support for other common SCMs that might be used in the ports collection already (git and cvs come to mind) SVN_REV=12345 is required unless you use the "-h" option which gets the version from head SVN_URL=svn://goo.com/svn_repo - this is where the source is fetched from. If I could get any comments (1) on the script in particular and (2) if the approach I'm taking now is better than the one I tried a few weeks ago (see wiki page) it would be really good. ___ 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] Tools/ script for automatically making a tar out of svn sources
> I don't see the script. The attachment never made it through (not sure why: in my MUA it looks like it was sent) and after some more looking I decided I was probably a bit to fast. I'll send a repost when I improve it ___ 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"
emulators/wine - failed to build
Here is the end of the wine build output: gmake[1]: Entering directory `/dta/ports/emulators/wine/work/wine-1.1.36/fonts' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/dta/ports/emulators/wine/work/wine-1.1.36/fonts' gmake[1]: Entering directory `/dta/ports/emulators/wine/work/wine-1.1.36/loader' cc -c -I. -I. -I../include -I../include -D__WINESRC__ -Wall -pipe -fno-strict -aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wpo inter-arith -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o main.o main. c wtypes.idl:25: error: syntax error, unexpected aIDENTIFIER, expecting aSTRING or aUUID gmake[1]: *** [activaut.h] Error 1 gmake[1]: Leaving directory `/dta/ports/emulators/wine/work/wine-1.1.36/include' gmake: *** [include] Error 2 LC_ALL=C sed -e 's,@bindir\@,/usr/local/bin,g' -e 's,@dlldir\@,/usr/local/lib/wi ne,g' -e 's,@PACKAGE_STRING\@,Wine 1.1.36,g' wine.man.in >wine.man || (rm -f win e.man && false) gmake: *** Waiting for unfinished jobs LC_ALL=C sed -e 's,@bindir\@,/usr/local/bin,g' -e 's,@dlldir\@,/usr/local/lib/wi ne,g' -e 's,@PACKAGE_STRING\@,Wine 1.1.36,g' wine.de.man.in >wine.de.man || (rm -f wine.de.man && false) LC_ALL=C sed -e 's,@bindir\@,/usr/local/bin,g' -e 's,@dlldir\@,/usr/local/lib/wi ne,g' -e 's,@PACKAGE_STRING\@,Wine 1.1.36,g' wine.fr.man.in >wine.fr.man || (rm -f wine.fr.man && false) cc -o wine -Wl,--export-dynamic -Wl,--section-start,.interp=0x7bf00400 main.o -L ../libs/wine -lwine ../libs/port/libwine_port.a -lpthread -L/usr/local/lib -Wl, --rpath,\$ORIGIN/../libs/wine cc -o wine-installed -Wl,--export-dynamic -Wl,--section-start,.interp=0x7bf00400 main.o -L../libs/wine -lwine ../libs/port/libwine_port.a -lpthread -L/usr/loca l/lib -Wl,--rpath,\$ORIGIN/`../tools/relpath /usr/local/bin /usr/local/lib` -Wl, --enable-new-dtags gmake[1]: Leaving directory `/dta/ports/emulators/wine/work/wine-1.1.36/loader' *** Error code 1 Stop in /dta/ports/emulators/wine. *** Error code 1 Stop in /dta/ports/emulators/wine. ___ 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"
using webcamd
Can anyone point me to instructions for using webcamd? After kldloading video4bsd webcamd still says "can't find USB device" ___ 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: Need help with new port math/ggobi
> > 1. The port needs libraries gtk2 and libxml2. > Is it ok how the port ensures they are installed? > Ports has a predefined method of doing this: USE_GNOME= gtk20 libxml2 > 3. ggobi authors suggest to create /etc/xdg/ggobi/ for resource file. > A better place would be /usr/local/etc/xdg/ggobi/, I think. > What do you think? How could this be coded in the port? > Most programs I've seen are PREFIX safe. It is almost always better to use $PREFIX. The only exception I've ever seen is something like perl which many broken programs use. > > 5. When deinstalling, should we try to remove dirs share/applications > and etc/xdg? (Mostly they are used by other ports, too) > There is a feature "@dirrmtry" which will only remove the directory if no one is using it ___ 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 question
Can't you do something like this?
>
> pre-everything:
>@if [ ! -f /usr/src/sys/conf/newvers.sh ] ; then \
>${ECHO_MSG} "==> Error: Can't find kernel sources" ; \
>${FALSE} ; \
>fi
>
IMHO it is better to use IGNORE= than ${FALSE} due to index building
___
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"
webcamd requires restart after pwcview quits
If I run pwcview with -s vga it works. However if I quit pwcview and try to restart it I just get a green screen. The only way for me to get it to work again is to restart webcamd. Is this a known bug? Is there a way I could avoid this? ___ 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"
testing requested devel/allegro 4.2.2 to 4.2.3.1
I was hoping to get some testing of this patch by people who use allegro (note the last line requires files to be removed). I know that 4.4 is out but it changed build systems so it will take me a bit more time before I can get a port together patch-allegro Description: Binary data ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
better way to handle required rebuild on library bump
The recent change to jpeg required a lot of changes to a lot of ports all just to bump a version number. It is easy to miss things this way and requires a lot of work and downloading. I propose that some kind of MAJORVERSION be stored in /var/db/ports. Then when a library's MAJORVERSION is changed it will prompt a rebuild on any port that relies on it will also get rebuilt. Computer are *designed* handle these types of things ___ 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: better way to handle required rebuild on library bump
On Sun, Feb 7, 2010 at 12:27 AM, Edwin Groothuis wrote: > On Sat, Feb 06, 2010 at 11:48:33PM +0200, Eitan Adler wrote: > > The recent change to jpeg required a lot of changes to a lot of ports all > > just to bump a version number. > > That is true, there is a script for in /usr/ports/Tools/scripts/ > called bump_version.pl which can do most of the magic. > I didn't know that - this solves /most/ of the issue. > > > It is easy to miss things this way and requires a lot of work and > > downloading. > > Oh, you are talking about the user side of things. Please have a > look at portmaster or portupgrade, they can do this magic for you. > > No, I am talking about the committer's side of things. It is easy to miss a port that depends on the library your changing. > > > I propose that some kind of MAJORVERSION be stored in /var/db/ports. Then > > when a library's MAJORVERSION is changed it will prompt a rebuild on any > > port that relies on it will also get rebuilt. > > I like the idea, but it handles the problem from the wrong side: > The person who bumps the port revisions would need to have all ports > installed to make this judgement. > Why? This would be done at the same time that bumping revisions would have been done, ___ 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: better way to handle required rebuild on library bump
> This will accomplish exactly what you want: > >portmanager -u -p > How will portmanager -u -p avoid the need to bump the PORTREVISION (like the recent jpeg change)? > > It is in the port tree. > > -- > Jerry > ges...@yahoo.com > > |=== > |=== > |=== > |=== > | > > We are not a clone. > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: better way to handle required rebuild on library bump
> > Then when a library's MAJORVERSION is changed it will prompt a rebuild on > any > port that relies on it will also get rebuilt. > > I assumed that you were looking for a program that would force an > update of any ports that were dependent upon a changed(updated) port. > The command I posted would do that. Perhaps I am just not fully > comprehending what you are attempting to accomplish. > I've been using portmaster since I started using freeBSD (about 2 and a half years ago) ;) My post was a way to deal with things like the recent jpeg update in a more efficient manner. Instead of the port committer having to bump the portrevision of each port that depeneds on jpeg they could just bump MAJORVERSION in jpeg and have the rest of the work done magically ___ 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: better way to handle required rebuild on library bump
With due respect to the creativity of the OP, the whole conversation is basically moot since in almost all cases a library major version change requires a change to the LIB_DEPENDS line in the port anyway, so a PORTREVISION bump is a very tiny bit of additional work. Ah, I did not realize this. As you said my point is moot anyway. ___ 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: www/firefox: Firefox 3.6 crashes, Firefox 3.5.7 not
I have no idea if this is related but from pkg-message Firefox 3.6 and HTML5 Certain functions used to display HTML5 elements need the sem module. If your Firefox crashes with the following message while viewing a HTML5 page: "Bad system call (core dumped)" you need to load the sem module (kldload sem). To load sem on every boot put the following into your /boot/loader.conf: sem_load="YES" On Mon, Feb 8, 2010 at 9:04 PM, O. Hartmann wrote: > On 02/08/10 16:20, Gary Jennejohn wrote: > >> On Mon, 08 Feb 2010 13:32:25 + >> "O. Hartmann" wrote: >> >> >> >>> Today, I upgraded Firefox 3.5.7 (built yesterday) to Firefox 3.6. After >>> deleting ~/.mozilla (after I did a buckup, of course), I tried a fresh >>> start of 'firefox3'. After firefox showed up, I realized that no >>> option-field (File, Extras etc) can be used, they are dead and after a >>> few seconds I clicked them, firefox3 is crashing. >>> >>> Since I recompiled firefox 3.5.7 yesterday I was wondering if this is >>> due to some 'false' lib or dependency. Since I figured that I have >>> similar trouble with Thunderbird 3.0.1 after I installed it, I suspect a >>> faulty library causing this behaviour. With Thunderbird 3, I never >>> solved the problem although I tried to rebuild everything with >>> thunderbird via 'portmaster -f'. I'll did this with firefox 3.6 also, >>> but with no success. >>> >>> The crashing is observed on two nearly identical SMP FreeBSD 8.0/amd64 >>> STABLE boxes (make world of today), up-to-date ports. The crash is NOT >>> observed on my private oldish UP box, nearly the same setup, OS at the >>> same revision and ports up to date as of yesterday. Maybe this could be >>> a hint. >>> >>> Any hints or suggestions? >>> >>> >>> >> Try doing "ldd /usr/local/lib/firefox3/firefox-bin" and see if anything >> looks weird. >> >> > I did - and there is nothing weird. > > I checked the installed libraries and they are all rebuild when rebuilding > necessary dependencies for firefox3. > > > You can porbably ignore >> /usr/local/lib/firefox3/firefox-bin: >> libxul.so => not found (0x0) >> libmozjs.so => not found (0x0) >> libxpcom.so => not found (0x0) >> because run-mozilla.sh sets LD_LIBRARY_PATH to include >> /usr/local/lib/firefox3 where these libraries are installed. >> >> I merely deleted my old firefox 3.6 and reinstalled from the port (on >> 9-CURRENT AMD64) and haven't seen any problems. But of course, I've >> been running various incarnations of 3.6 for a while and may have gotten >> all the dependencies already correctly installed. >> >> --- >> Gary Jennejohn >> ___ >> freebsd-sta...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> >> > > I tried again, left the 'make config'-options as they were set by default, > delete/backuped .mozilla in my home and they restartet firefox3. Nothing > better than previously seen. Try hitting Button 'Tools' at the top menu bar > gives a menu after several seconds, then firefox crashes/core dumps. > > Oliver > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: My ports.
I'll take these: > sysutils/googlog > textproc/align > x11/xbindkeys ___ 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"
correct location for third party /var files
Are third party tools supposed to use /usr/local/var or /var ? ___ 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"
help with sed for post-patch
I need to change
set(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR}/lib)
to
set(LIBRARY_OUTPUT_PATH libdata/lib)
Here is what I have
${REINPLACE_CMD} -E 's/\$\{CMAKE_BINARY_DIR\}\/lib/libdata\/lib/'
${WRKSRC}/CMakeLists.txt
how could I fix this?
___
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: help with sed for post-patch
> ${REINPLACE_CMD} -e 's,$${CMAKE_BINARY_DIR}/lib,libdata/lib,'
> ${WRKSRC}/CMakeLists.txt
>
This works perfectly - I was missing the double $$ - thanks.
___
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: Update for png14 in test on the cluster
> Current preview of the patchs (roughly 4500 ports). > http://people.freebsd.org/~dinoex/logs/png141-patch3 > I noticed that x11/xorg is modified but not x11/xorg-minimal - is there a reason for this? Index: ports/x11/xorg/Makefile === RCS file: /home/pcvs/ports/x11/xorg/Makefile,v retrieving revision 1.30 diff -u -r1.30 Makefile --- ports/x11/xorg/Makefile 7 Feb 2010 15:25:21 - 1.30 +++ ports/x11/xorg/Makefile 23 Mar 2010 08:32:55 - ___ 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"
help with converting from configure to cmake (devel/allegro)
I'm currently the maintainer of devel/allegro which, due to my lack of time, is very outdated. The allegro team switched to cmake for the recent version. I do not know how to enable/disable specific options with cmake in the ports system. I attached the Makefile I am currently using (which builds perfectly without any options enabled). I'm looking for the correct way to change the configure_args to something that will actually work. If anyone notices anything else of importance please let me know. Portlint finds no problems. Makefile Description: Binary data ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
help with converting from configure to cmake (devel/allegro)
I sent this march 26th with no response and after some more extensive googling I'm still at a loss as what to do. I'm currently the maintainer of devel/allegro which, due to my lack of time, is very outdated. The allegro team switched to cmake for the recent version. I do not know how to enable/disable specific options with cmake in the ports system. I attached the Makefile I am currently using (which builds perfectly without any options enabled). I'm looking for the correct way to change the configure_args to something that will actually work. If anyone notices anything else of importance please let me know. Portlint finds no problems. Makefile Description: Binary data ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
drop devel/allegro and devel/allegro-devel
Since I no longer use allegro and don't have time to update them I'd like to drop maintainership of allegro. If anyone would like to take them feel free... Note to the next maintainer: devel/allegro needs to be updated to 4.4.1.1 and devel/allegro-devel needs to be updated to 4.9.19. ___ 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"
feature request for portmaster: check for permissions on --check-depends and friends
When I run portmaster with --check-depends or --check-port-dbdir as a non-root user portmaster will continue to attempt to write to the db dir. For example ===>>> Checking jpeg-8_1 ===>>> Updating +REQUIRED_BY install: /var/db/pkg/jpeg-8_1/+REQUIRED_BY: Permission denied portmaster should check before it goes through the whole process and see if it has write access to /var/db/ports. ___ 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: GSoC: Making ports work with clang
> Having tried clang++ I have a feeling that it's not quite ready to be a > generic c++ compiler. > It crashes a lot, fails on many quite simple c++ patterns. Very immature. > Don't you feel it's too early to start project like you are going to given > the state of clang with c++? > You will just keep stumbling upon various problems with various ports and > maybe will make 30% of c++ ports build with it at best. Good - and those 30% of ports will help improve clang++ even more. Hopefully over time that number will increase to 100% and we will be able to say goodbye to gcc for good. ___ 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] Xorg 7.5 merge comming tomorrow.
It all seems to work, I'm running iceWM with the new Xorg version. However if I try and run the friendly xeyes I get a segfault which brings down the entire X server - not just xeyes.FreeBSD 8.0-RELEASE-p2 i386 ___ 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"
gcc fails to build: math/gmp does not exist
Debug output: # pwd /usr/ports/lang/gcc46 # make ===> gcc-4.6.0.20100501 depends on file: /usr/local/bin/as - found ===> gcc-4.6.0.20100501 depends on executable: zip - found ===> gcc-4.6.0.20100501 depends on executable: gmake - found ===> gcc-4.6.0.20100501 depends on executable: bison - found ===> gcc-4.6.0.20100501 depends on file: /usr/local/bin/perl5.10.1 - found ===> gcc-4.6.0.20100501 depends on shared library: gmp.10grep: conflicting matchers specified - not found ===>Verifying install for gmp.10 in /usr/ports/math/gmp ===> Returning to build of gcc-4.6.0.20100501 grep: conflicting matchers specified Error: shared library "gmp.10" does not exist *** Error code 1 #pkg_info |grep gmp gmp-5.0.1 A free library for arbitrary precision arithmetic ___ 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: pylint entry in UPDATING?
> personally, I do not think that (incompatibly) changed user options or > configuration settings for this port are 'worth' an entry in UPDATING, > thus I skipped it. UPDATING entries are cheap. It can't hurt to have this as an entry to help users of the port. ___ 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: Depend on ${PORTSDIR}/foo WITH_OPTION
On Wed, May 19, 2010 at 9:11 AM, joris dedieu wrote: > Hi list, > I would like to know if there is a way to tell a port that it depend > on an other port > but build with particulars options. > > Eg : port foo build depend on bar but won't build if bar is not build > with WITH_PARTICULAR. > At this point there isn't a "real" way to require this. One option however is to create a slave port with the options you need set and depend on that. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: GPLv3-licensed ports
> Is ports/LEGAL prominent enough? Should I also add something to the > pkg-descr? I'd rather not. I remember some work about adding licensing support to the ports framework but can't seem to find it now. Perhaps tools like portmaster or portupgrade could be modified to warn the user when installing a GPLv3 port is being installed? -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: GPLv3-licensed ports
>> .if defined(LICENSE) && ${LICENSE} == "GPLV3"
>> .error "GPLv3 licensed ports blocked due to site policy"
>> .endif
>>
>> in make.conf, etc (or ports.conf like some folks have lightly
>> tossed around on #bsdports and elsewhere).
>
> You're right, that's quite a good solution.
>
Don't use .error as it messes up index builds and other such things.
Instead use IGNORE= ;)
Also http://wiki.freebsd.org/PortsLicenseInfrastructure is the project
I was looking for.
This project is about adding a license framework to the ports system
(i.e. bsd.licenses.mk), allowing it to be aware of the license used by
each port. Another part of this project is to find an automated
solution (so maintainers don't have to specify each port's license).
With this information the infrastructure will be able to automate many
tasks such as: restrict licenses, redistribution of files, identifying
GPLv3 ports, etc.
--
Eitan Adler
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portmaster cannot find package
> Thanks for the suggestion, I'll definitely consider that for the next > version. I already have problems with the documentation being long and > detailed, whether it is too much of either is sort of in the eye of the > beholder. :) Detailed documentation is almost never a problem -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports licenses
On Sun, May 30, 2010 at 11:20 PM, Rene Ladan wrote:
...
> * lang/bas2tap uses some homebrew license, but it has no formal name, so
> LICENSE_NAME cannot be formally set.
>
> I think the first one can be added to bsd.license.db.mk, but I'm not
> sure what to do about the second one.
from bsd.licenses.mk
# Case 2: license only known by the port (aka "unknown").
#
# In this case LICENSE_{PERMS,NAME} are mandatory, in addition to
# either LICENSE_FILE or LICENSE_TEXT. Optional variables are
# LICENSE_{GROUPS,NOTES}.
--
Eitan Adler
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Data files and ports
On Fri, Jun 11, 2010 at 4:58 PM, Jesse Smith wrote: ... > I'm trying to port a program which is distributed in two separate > packages from the upstream project. One package contains the executable > program and the other contains data files. The Data package rarely > changes. The idea being packaging them together would use up a lot of > extra bandwidth. > ... > My instinct is to create a separate port for the Data package and list > it as a dependency for the Executable port. I'd appreciate some > guidance. > Others have already mentioned some ways for you to do this. I just want to bring to your attention the games/doom and games/doom-data ports as well as a few others % ls -d /usr/ports/*/*-data|wc -l 31 -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: mail/thunderbird3 does not build with gcc 4.5.1
On Tue, Jun 22, 2010 at 1:04 AM, Doug Barton wrote: > Howdy, > > On to the next victim. :) In my ongoing campaign to build my ports with gcc > 4.5.1 thunderbird was the next to fall. Full log is at > http://people.freebsd.org/~dougb/tbird.txt > I've been doing the same thing but with lang/gcc46. Here are the ports that currently fail for me devel/llvm* develclang devel/icu devel/libexecinfo devel/gobject-introspection www/firefox* www/libxul lang/perl* irc/xchat Maybe it would be a good idea to make a wiki page with a table for which ports fail with which compilers? -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
flag to tell ports that you are only building for yourself
I'd like to add a flag to tell ports that you are building only for
yourself that and optimizations that typically are not enabled could
be turned on.
The first two that come to mind are -mtune=native and -march=native.
Ports would be able to add more flags as needed. This could allow
ports to optimize themselves to the architecture they on without
losing the ability to cross build or have build clusters.
--- old.port.mk 2010-06-27 23:01:04.0 -0400
+++ bsd.port.mk 2010-06-27 23:05:16.0 -0400
@@ -2282,6 +2282,10 @@
.endif
.endif
+.if defined (ONLY_FOR_SELF)
+CFLAGS += -mtune=native -march=native -mcpu=native
+.endif
+
.if defined(USE_CSTD)
CFLAGS:= ${CFLAGS:N-std=*} -std=${USE_CSTD}
.endif
--
Eitan Adler
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: flag to tell ports that you are only building for yourself
> Any case where it would be useful besides -march/-mtune/-mmmx/-msse*? > Not that I could think of at the moment. I think this solution works better. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Confirming a bug in clang++ (freeBSD
Can anyone with FreeBSD 8.1-RC1 i386 or FreeBSD 8.1-RC2 i386 confirm
that the following code compiles and fails with the version of clang++
from ports?
This works with g++ and fails with clang++ for me.
Here is the original code
#include
int main()
{
std::cout << 1;
return 1;
}
My bug report is here: http://llvm.org/bugs/show_bug.cgi?id=7489
I want to know if this is my problem or a clang++ problem or a bug
somewhere else.
--
Eitan Adler
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Confirming a bug in clang++ (freeBSD
>>> My bug report is here: http://llvm.org/bugs/show_bug.cgi?id=7489 >>> >>> I want to know if this is my problem or a clang++ problem or a bug >>> somewhere else. >>> >> >> Works fine here: >> >> # uname -a >> FreeBSD peer 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #2: Mon Feb 22 23:18:53 >> EST 2010 r...@peer:/usr/obj/usr/src/sys/PEER i386 >> >> # clang++ -v >> clang version 1.1 (branches/release_27) >> Target: i386-portbld-freebsd8.0 >> Thread model: posix >> >> I can try it on a recent CURRENT machine tomorrow, but perhaps you'd best >> share your environment. I've compiled non-trivial C++ programs with clang++ >> and they've behaved properly. >> >> -Boris >> > One difference I notice between your environment and mine is that, according > to your bug report, your program links against > /usr/local/lib/gcc46/libstdc++.so.6, while mine links against > /usr/lib/libstdc++.so.6. > > -Boris > I forgot about that. I use gcc46 to build ports and have libstdc++.so.6 gcc46/libstdc++.so.6 in /etc/libmap.conf I guess I should close the bug. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Confirming a bug in clang++ (freeBSD
On Tue, Jun 29, 2010 at 11:00 PM, Anonymous wrote: > Eitan Adler writes: > >>> One difference I notice between your environment and mine is that, according >>> to your bug report, your program links against >>> /usr/local/lib/gcc46/libstdc++.so.6, while mine links against >>> /usr/lib/libstdc++.so.6. >>> >>> -Boris >>> >> I forgot about that. I use gcc46 to build ports and have >> libstdc++.so.6 gcc46/libstdc++.so.6 >> in /etc/libmap.conf > > I have clang++ (devel/llvm-devel) built by g++45 and linked against > gcc45/libstdc++.so.6. It compiles your test case fine. But I'm running > 9-current on amd64 so it may not be that useful. > > IMO, gcc46 being a development branch is prone to miscompile and have bugs. I'm not that familiar with with mapping. Since g++46/* is built with g++46 and my program is compiled by clang++ is it expected that they be compatible? If yes does that mean this is a bug in g++46 or clang++? -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Confirming a bug in clang++ (freeBSD
>>> I have clang++ (devel/llvm-devel) built by g++45 and linked against >>> gcc45/libstdc++.so.6. It compiles your test case fine. But I'm running >>> 9-current on amd64 so it may not be that useful. >>> >>> IMO, gcc46 being a development branch is prone to miscompile and have bugs. >> >> I'm not that familiar with with mapping. > >> Since g++46/* is built with g++46 > > It's more interesting which gcc version you used for compiling clang. I forgot. Most likely it was base gcc as I have an exemption in my /etc/make.conf for it. >> and my program is compiled by clang++ is it expected that they be >> compatible? If yes does that mean this is a bug in g++46 or clang++? > > Either -lstdc++ from gcc46 is buggy or just clang++ doesn't like it. > It's better to use -lstdc++ from same version of gcc by which the > program using it was compiled. Is it possible to determine which one? Is this something that is my fault for playing around too much or did I expose a bug ? -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gap
On Sun, Jul 11, 2010 at 7:39 PM, ajtiM wrote: > Hi! > > I have one question which I asked long time ago (not answered): do we have > > GAP (the GIMP Animation Package) for GIMP 2.6 and above (available at > ftp://ftp.gimp.org/pub/gimp/plug-ins/v2.6/gap) still active on FreeBSD or not > more? > And the other question is the same but for K3b for KDE 4. > % make quicksearch key="gap"|grep -i gimp Port: gimp-gap-2.4.0_5 Path: /usr/ports/graphics/gimp-gap Info: GIMP Animation Package Is this what you mean? -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Installing Ruby suggestion
On Thu, Aug 19, 2010 at 2:30 PM, Paul Hoffman wrote: > Greetings again. When doing a "make install", it takes *forever* in the > "Generating RDoc documentation" step. This isn't a big deal the first time, > but when updating Ruby (such as for the recent security announcement), you > need to do a "make deinstall" before you do a "make reinstall". Having that > second step take a long time means that there is a longer time that there is > no Ruby on the system. > > Could the RDoc step be done during "make" instead of "make install"? > Generally its best to CC the maintainer as well. In this case the maintainer is s...@freebsd.org That being said: I second this request ;) -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: man page style questions
I am not an authority but I think I can help. 1) I think -doc > -questions > -ports 2) see reply inline > - Is "INTERACTIVE MODE" the appropiate term to be used as heading for > the section dealing with the specifics of a ncurses-based user interface ? > This is the label I would expect > - What labels are to be used for keys which usually do not produce a > printable character ? E.g. is the -key to be represented as > "return", "" or "RETURN" (or is it to be named "enter", anyway ?) from the less(1) man page "RETURN" seems to be correct > > - What about the cursor movement and other directional keys like > , , ? See the less(1) man page. > - Are there any preferences for the macros to use for keys to be > pressed, e.g. is the following acceptable: > .Bl -tag -width Fl > .It Ic C > Do the C thing. > .It Ic A > Do the A thing. > .El I think so - from the limited amount of man page writing I've done (and from looking at less's source) -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: porting: Linux to Freebsd
On Sat, Oct 2, 2010 at 2:42 AM, Chetan Shukla wrote: > Hi, > Could someone please outline the steps needed in porting a general > application from > Linux to FreeBSD. > > > Thanks & Regards, > Chetan You may want to have a look at http://wiki.freebsd.org/AvoidingLinuxisms If you ask a more specific question you will probably get more specific answers. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
legacy code in bsd.ports.mk
I was going through bsd.port.mk to learn how the ports system works. It seems quite complex - partly due to all the different configurations that need to be supported. 1) I noticed some hacks that were in place in 2004 and I was curious if they were fixed by now, and if so if the hacks should be changed. The attached patch just follows the comments - although I don't know if the specific bug in question is fixed yet 2) revision 1.618 adds code to drop bsd.port.options.mk into /usr/share/mk if it's missing - which seems to be supporting users using 6.2 and before. Since these versions are already EOL now - is it worth it to clutter bsd.port.mk with code to support them? I'm not saying that we should drop support just because they are EOL - but I think that bsd.port.mk is quite complicated already - and the less code the better. 3) revision 1.581 added the following code # XXX to remain undefined until all ports that require Perl are fixed # to set one of the conditionals that force the inclusion of bsd.perl.mk .if !defined(_PERL_REFACTORING_COMPLETE) Is this complete yet? If so could we just remove the .if !defined code? 4) The code that converts from USE_BISON=yes to USE_BISON=build seems to only affect two ports (based on my grepping) and could be fixed using the attached patch 5) I'm sure there is more that could be done to clean up the ports system. These are only things that I found going through bsd.port.mk - if I look at some of the other files I think I'll find more :-( remove-2004-hack.patch Description: Binary data remove-use-bison-yes.patch Description: Binary data ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
legacy code in bsd.port.mk
I was going through bsd.port.mk to learn how the ports system works. ... Sorry - my initial subject was wrong - I had an extra s. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: port for sysutils/fio update?
On Sun, Oct 24, 2010 at 5:46 PM, Anonymous wrote: > Julian Elischer writes: > >> ports complain about an empty patch file.. >> (not sure how one DOES remove a file using patch) > > patch -E ? cvs wouldn't know to delete the file. cvs rm is still needed. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: sysutils/cfs
> AFAIK there are maybe half a dozen or so developers who have > recently put themselves on record as supporting the current, > agressive deprecation campaign. The number who have posted in > opposition may well be smaller, so you are probably right if "the > community" is defined as consisting only of those two groups :) I'm probably counted as one of the half-dozen developers here. However... >> >>> Better to deprecate such non urgent ports, & wait a while >> >>> after next release is rolled, to give release users a warning >> >>> & some time to volunteer ... If this will help a number of people this sounds like an excellent suggestion! > I somehow doubt that anyone has polled even a modest percentage of > our users -- to find out what they would consider "the best support > possible" -- since AFAIK we have no way of even _identifying_ more > than a tiny fraction of the user base. A) We need better statistics for ports in general B) We need better ways of communicating with our users to find out how people actually use the ports tree. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: x11/xvattr - why exoired?
On Wed, Sep 7, 2011 at 2:57 PM, Heino Tiedemann wrote: > Hi, > > I need the port x11/xvattr. > ... > What can I do? Submit a working port in a PR and assume maintainership. Make sure to fix the reason it was expired in the first place (which may be becoming the upstream maintainer as well). > > Heino > > ___ > 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" > -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The cost of a source based package system
On Thu, Sep 8, 2011 at 12:53 AM, Stefan Schaeckeler wrote: > Hi all, please don't take this posting too serious. I was just curious ... Thanks for the disclaimer. > . Among other things, I measured the "cost of a source based package system", > i.e. I was comparing the energy cost of installing ports from source vs > binary packages (setup, see below). Make sure to measure multiple times, with a cold cache, and calculate α and p values ;) > The number of ports and binary packages varies slightly. I don't know why. > This only introduces a small error. Likely due to "build dependencies" which are not needed when installing via packages. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Standalone mksh
> I wanted to propose the addition of a standalone mksh in shells/, which , of > course, is compiled with -static and installs to /bin . Attached is the > modified Makefile. 1) Please submit unified diffs, not entire files. It makes it easier to see what changed and it makes it easier to actually use when testing 2) We assume that LOCALBASE is read only (except for some very specific hacks like perl's symlink) so such a port will not be committed 3) Don't change PREFIX in the port's Makefile. This is a user specific option which should not be overwritten 4) If anything, the -static should be an OPTION. 5) Your change would require approval by the maintainer (m...@freebsd.org). I would hope he does not approve it based on points 2-4 above. Thanks for your contribution. Please don't take my criticism of this specific patch as reason not to try again! -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: x11/xset needs a direct dependency on xproto
> http://bugs.freebsd.org/160595 I've sent this patch to my mentors. When they approve I'll commit. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Substitute dependencies?
On Sun, Sep 18, 2011 at 1:38 AM, Thomas Mueller wrote: > Is there any way to substitute dependencies, in cases where the substitute > would work as well or better? We do not currently handle this very well. portmaster attempts to emulate this feature by comparing CONFLICTS lines. There have been proposals in the past to deal with this but none have managed to make it into the tree. >Another case I think of is mysql as a dependency when the user might prefer >MariaDB or PostgreSQL. This may not always be possible, but I do understand the point you are trying to make -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Ports with CPPFLAGS in CONFIGURE_(ARGS|ENV)
> So, what would be a good approach? Any suggestions? Prepare a patch and get a committer to ask portmgr@ for approval. I volunteer if you need someone. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Ports with CPPFLAGS in CONFIGURE_(ARGS|ENV)
> Do you mean one gigantic, monolithic patch that would amend all of them, > or a large set of individual patches (last I checked, there were ~1453 > ports in need of this sort of revision)? I could go either way, just > need to know which would be preferred. One monolithic patch (preferably generated with "cvs diff -Nu") -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: problem with port x11/xbitmaps in Current and 7.4 stable.
> Hm... > > Just incidentally, are you randomising the time within the hour to be > kind to the master server, with something like: > > /bin/sleep $(expr \( $(fortune | cksum | cut -f1 -d" ") \% 3600 \) + > 1 ) && /usr/bin/csup _your_supfile /bin/sleep $(/usr/bin/jot -r 1 1 3600) && . -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Upgrade install of x11/bigreqsproto-1.1.1...
Can you please submit a PR with a diff -u of the fix? Otherwise this change will get lost. On Fri, Sep 23, 2011 at 6:17 PM, Dave Males wrote: > On Friday 23 September 2011 21:27:57 Dave Males wrote: >> On Friday 23 September 2011 08:14:58 h h wrote: >> > Dave Males writes: >> > > I am upgrading today and have an abort with bigreqsproto-1.1.1, >> > > What should I do? -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: HEADS UP: ports/ and 10.0-CURRENT
2011/9/27 O. Hartmann : > Now I understand why some OS vendors have choosen the latin 10 'X' for their > tenth version of their operating system ... FreeBSD XP anyone? > ___ > 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" > -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Shared libs problem with ports under 10-CURRENT
On Mon, Sep 26, 2011 at 6:55 AM, Rainer Hurling wrote: > This morning I tried to upgrade my ports after installing the new 10-CURRENT > (amd64). There was a message about this on the list already. > Does anyone else observes this behaviour? I would really appreciate some > help. https://groups.google.com/group/muc.lists.freebsd.ports/msg/10c37925f4ee0341?dmode=source&output=gplain&noredirect -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Instafix for FreeBSD ports brokenness on 10.0?
The ports tree can be very fickle and touching a large class of ports requires multiple exp-runs. Attempting these types of changes just prior to release adds a degree of risk which no one wants to accept. > The question is why we're not going to fiddle with auto* given other > stuff which is being committed to the ports tree right now, which is > unrelated to release as well? Because these commits don't possibly break a large portion of ports. > The fix can be added unconditionaly, > thus having a very low (I'd say negligible) risk of breaking anything. Affecting *every single port* is not a negligible risk. > In the meantime, if we don't fix this we're making it impossible for > any HEAD users to do any kind of productive work in ports. We will fix it, once 9-RELEASE is out the door. In the meantime please see UPDATING 20110928. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: TeXLive
> I updated this page: > http://code.google.com/p/freebsd-texlive/wiki/Installing Are there any plans on getting these committed to the mainline ports tree? I'd be willing to work with you on that. > > You should at least install texlive-scheme-minimal but if you don't know > exactly what you need, you may consider texlive-scheme-full ;-) > > Regards, > Romain > > -- > Romain Tartière http://romain.blogreen.org/ > pgp: 8234 9A78 E7C0 B807 0B59 80FF BA4D 1D95 5112 336F (ID: 0x5112336F) > (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) > -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Current problem reports assigned to po...@freebsd.org
On Mon, Oct 10, 2011 at 3:22 PM, Doug Barton wrote: > It's been quite a few weeks that this empty/pointless message has been > sent to the list, what needs to happen to make it stop? Assign bugs to ports@ - then it won't be empty anymore. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Testing Wacom usb tablet with webcamd svn (and mypaint)
On Tue, Oct 11, 2011 at 3:39 PM, Hans Petter Selasky wrote: > In my talk at EuroBSDcon I said that webcamd might be renamed in the future. > Does anyone have any good suggestions? We even borrow camera and more drivers - webcamd -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Subversion 1.7 and usage of USE_SUBVERSION=16
2011/10/16 Lev Serebryakov : >> Or am I wrong and usage of USE_SUBVERSION outside Makefile is OK? > Maybe, I was wrong in spelling of these variables. But, IMHO, it is > too late to change them, am I right? Or it is Ok to change UPDATING > file (not add new record, but change existing one)? Please change it. Users should be taught to never touch USE_ variables. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [UPDATE] Re: Update on ports on 10.0
On Tue, Oct 18, 2011 at 6:31 PM, Peter Jeremy wrote: > Once hackish work-arounds get committed, it is extremely difficult to > root them out. The last time the project included a temporary hack to > assist with a similar problem (the aout to ELF migration in FreeBSD > 3), it took more than a decade to get the hack out of base and after > 13 years, there are still 71 ports (by my count) with local work-arounds. > Based on the objformat mess, whatever is done will hang around in > the tree for at least a decade so we are far better off spending > some time now to come up with the best solution, rather than quickly > committing a work-around that we spend the next decade regretting. This hack still has remnants in the tree: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/155737 -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Update for x11-toolkits/swt-devel failed
On Mon, Oct 24, 2011 at 3:43 AM, Leslie Jensen wrote: > I've tried to deselect all three choices in the config menu. It doesn't > change anything. It won't build. As the committer who last touched this port I'm somewhat responsible. However, I can not reproduce the problem. Can you please try portdowngrade to see if the old version builds? -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: next clang -exp run, when? (Was: svn commit: r226890 - in stable/9:...)
On Fri, Oct 28, 2011 at 8:24 PM, Nali Toja wrote: > - at least one committer (crees@) is hostile towards PRs about clang > build failures, e.g. ports/161204 was closed with no logs from any > of clang -exp runs Unless you have a patch *fixing* the issue we don't need PRs about ports broken with clang. This is an unsupported option as of now. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gstat collision between sysutils/coreutils and base gstat
On Mon, Oct 31, 2011 at 1:43 PM, Chris Rees wrote: > Would anyone yell too much if I _just_ changed gstat to gnustat? > Probably, but you should ignore them. ;) -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Ports not mentioned in their category's Makefile
On Mon, Oct 31, 2011 at 7:20 PM, Conrad J. Sabatier wrote: > I've generated a list of 57 ports that are not mentioned in the > Makefiles for their respective categories. Before I do anything more > with this information (like submit patches), though, I just wanted to > check to see if there's any interest in correcting this. > Please send the list to po...@freebsd.org. Keep in mind that some ports not listed may have been incomplete or aborted repocopies. There is no need to send patches, the fix is easy enough ;) -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Ports missing in their categories' Makefiles
On Mon, Oct 31, 2011 at 8:56 PM, Conrad J. Sabatier wrote: > OK, the list is actually smaller than I had mentioned earlier. My > first list included ports not mentioned in the categories' README.html > files as well, which of course, generated a bogus list. > > Here's the final list I got: > Other than dvi2tty none of these ports appear to exist in a recent ports tree. Where are you generating this list from? -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
