Re: TeXLive
Romain Tartière rom...@freebsd.org wrote in 20111011101902.gb14...@blogreen.org: ro Hello! ro ro On Mon, Oct 10, 2011 at 07:23:48AM -0500, Stephen Montgomery-Smith wrote: ro On 10/10/2011 06:44 AM, Eitan Adler wrote: ro Are there any plans on getting these committed to the mainline ports ro tree? I'd be willing to work with you on that. ro ro I agree with Eitan. ro ro I would also be pleased to see TeXLive in the FreeBSD ports (obviously). ro There are a few issues to sort out before however: ro - The way TeXLive sources are distributed is not convenient: all ro binaries are built and installed from a single sources tarball. ro This leads to the big print/texlive-core but really lacks ro scalability. Back in 2008, Hiroki Sato was working on splitting all ro this AFAICR. Hiroki, I added you in Cc, can you please tell us if ro you had any progress on this topic? I feel guilty about this because although I had/have several prototypes and plans to integrate TeXLive into the ports tree, it have not actually happened so far. There were two obstacles in the work. One was there were technical issues (compatibility-related) that prevented some existing TeX-related software we had in the ports tree from working. This was in around 2007 but solved now. Another one was how many ports we should have for TeX-related software. After testing several prototypes including a single port version, a set of ~2000 ports (one port for one macro), ~150 ports, or ~30 ports, I think it seems good for us to have one of basic utilities, one for basic (stripped-down) macro sets as something like texlive-core + texlive-texmf, and the others for optional macro packages. The basic idea is the same among them regardless of the total number of ports. In practical, 100 would be the maximum number. So, primary issues described above were basically solved. Although there are still trivial issues such as handling of a large distfile, it is not difficult to solve. However, how to handle updating a macro package in the basic port is a problem to me and time passed when I was thinking about that. More specifically, currently we have many latex-* and tex-* ports to install new macro packages or override the default ones. It becomes complex over time. Committing a single large TeXLive port is easy, but I do not want to create the same situation again in the new world and want consistency for updating a macro package in the distribution. So, I wanted some compatibility with TeXLive's package management utility (tlmgr). Unfortunately it was too premature when I first looked into it (around 2007, IIRC). The current version is much better than before, but I still need some investigation about that. If we have or use reliable package catalogs of CTAN including file lists of each macro package via tlmgr or something, we can take an approach like BSDPAN, I think. A version based on TeXLive 2011 with a small number of ports can be committed if we ignore the last concern and clean up the current teTeX-related ports. Any comments about that? I am very sorry for being unresponsive to many people who contacted me about that... -- Hiroki pgpC4zaNhW7Wb.pgp Description: PGP signature
Re: lang/ocaml fails to package without THREADS option (plist error)
Did I miss a response to this issue? Will filing a PR help? Doug On 10/05/2011 15:44, Doug Barton wrote: stas, If I don't choose the THREADS option I get this. Looks like it needs some PLIST_SUB action. Thanks, Doug tar: lib/ocaml/caml/threads.h: Cannot stat: No such file or directory tar: lib/ocaml/condition.mli: Cannot stat: No such file or directory tar: lib/ocaml/event.mli: Cannot stat: No such file or directory tar: lib/ocaml/libthreads.a: Cannot stat: No such file or directory tar: lib/ocaml/libthreadsnat.a: Cannot stat: No such file or directory tar: lib/ocaml/mutex.mli: Cannot stat: No such file or directory tar: lib/ocaml/stublibs/dllthreads.so: Cannot stat: No such file or directory tar: lib/ocaml/thread.mli: Cannot stat: No such file or directory tar: lib/ocaml/threadUnix.mli: Cannot stat: No such file or directory tar: lib/ocaml/threads/condition.cmi: Cannot stat: No such file or directory tar: lib/ocaml/threads/condition.cmx: Cannot stat: No such file or directory tar: lib/ocaml/threads/event.cmi: Cannot stat: No such file or directory tar: lib/ocaml/threads/event.cmx: Cannot stat: No such file or directory tar: lib/ocaml/threads/mutex.cmi: Cannot stat: No such file or directory tar: lib/ocaml/threads/mutex.cmx: Cannot stat: No such file or directory tar: lib/ocaml/threads/thread.cmi: Cannot stat: No such file or directory tar: lib/ocaml/threads/thread.cmx: Cannot stat: No such file or directory tar: lib/ocaml/threads/threadUnix.cmi: Cannot stat: No such file or directory tar: lib/ocaml/threads/threadUnix.cmx: Cannot stat: No such file or directory tar: lib/ocaml/threads/threads.a: Cannot stat: No such file or directory tar: lib/ocaml/threads/threads.cma: Cannot stat: No such file or directory tar: lib/ocaml/threads/threads.cmxa: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: lang/ocaml fails to package without THREADS option (plist error)
On Sat, 22 Oct 2011 00:15:36 -0700 Doug Barton do...@freebsd.org mentioned: Did I miss a response to this issue? Will filing a PR help? Hey, Doug! Sorry for the long response, but I've been cought with ports being broken on 10.x entirely, so it doesn't look like I will be able to work on any my ports issues in the near future. If you know a fix and can test it, please go ahead. I will really appreciate it! Thanks! -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
sysutils/smartmontools: 5.42 tarball re-rolled
= Attempting to fetch http://heanet.dl.sourceforge. net/project/smartmontools/smartmontools/5.42/smartmontools-5.42.tar.gz fetch: http://heanet.dl.sourceforge.net/project/smartmontools/smartmontools/5. 42/smartmontools-5.42.tar.gz: size mismatch: expected 740025, actual 742138 the same message is repeated for every other sf mirror ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: which ports require dialog during update
from kron24 kro...@gmail.com: OP may want to look on 'make config-recursive'. Sometimes, perhaps when selecting options results in subsequent dialogs, 'make config-recursive' doesn't do all the first time, meaning I get subsequent dialogs. I run 'make config-recursive' repeatedly until it just returns to the command prompt with no more dialogs. I like to make package-recursive | tee build.log so as to have a record especially if not all goes well; this applies equally for 'make install clean' I like to have all config dialogs done and out of the way. Tom ___ freebsd-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: postgresql-client-8.2.22_1: Makefile error: you cannot include bsd.port[.pre].mk twice
On 20 October 2011 15:07, Ruslan Mahmatkhanov cvs-...@yandex.ru wrote: Jerry wrote on 20.10.2011 17:10: When attempting to build the postgresql-client-8.2.22_1 port, this error message is being emitted: postgresql-client-8.2.22_1: Makefile error: you cannot include bsd.port[.pre].mk twice Has anyone else noticed it? I filed a PR against it. Yes, it's already known and there is (single?) pr about this in gnats. What i really want to know is how much people actually use pgsql 82 and what the reasons they have to not migrate to more recent versions like 84 or 90 (it's 85 in terms of backward compatibility). Also note that PostgreSQL 8.2 will reach it's EOL on December 2011, so this port will be deprecated in near future with high probability. -- Regards, Ruslan I've committed a fix for this. Thanks for the report. Chris ___ freebsd-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 Fri, 21 Oct 2011, Ion-Mihai Tetcu wrote: Erwin is currently running a build on i386-10 with this and the following patches: - bsd.port.mk patch from beat (based on ed@, jilles@ and stas@ patches) - python patch from beat - python patch from linimon - WITH_FBSD10_FIX in: - textproc/expat2 - devel/pcre - devel/libtool - audio/libogg Results by Monday. If everything goes OK, we'll commit the patch. We're not sure if we'll have enough time for running other -exps to find the broken ports that need the fix before we need to concentrate on building the packages for the release, but we'll try. That's awesome news! Thanks a lot for all the hard work to everyone helping get this issue out of the way. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-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 unmaintained ports which are currently scheduled for deletion
On 21 October 2011 07:31, lini...@freebsd.org wrote: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: databases/postgresql-plpython description: A module for using Python to write SQL functions maintainer: po...@freebsd.org deprecated because: (error in parsing Makefile) expiration date: 2011-04-02 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=postgresql-plpython How did this one get in this email? It was fixed two weeks ago... Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[PATCH] multimedia/libdvdnav
I tried to use vlc to play a dvd on -CURRENT but it fails with libdvdnav: vm: ifoRead_FP_PGC failed Googling, I found a patch from debian bugtracker at http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;filename=05-endian.patch;att=1;bug=531621 Which I adjusted for FreeBSD (changed patch to source file and path to include file) Can this be included in ports? Cheers Rich -- richo || Today's excuse: the xy axis in the trackball is coordinated with the summer solstice Index: src/bswap.h === --- src/bswap.h 2009-06-04 12:32:25.0 -0700 +++ src/bswap.h2009-06-04 12:32:59.0 -0700 @@ -20,6 +20,11 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#include sys/endian.h +#if BYTE_ORDER == BIG_ENDIAN +#define WORDS_BIGENDIAN +#endif + #include config.h #if defined(WORDS_BIGENDIAN) signature.asc Description: Digital signature
Re: TeXLive
On 10/22/2011 01:18 AM, Hiroki Sato wrote: Romain Tartièrerom...@freebsd.org wrote in20111011101902.gb14...@blogreen.org: ro Hello! ro ro On Mon, Oct 10, 2011 at 07:23:48AM -0500, Stephen Montgomery-Smith wrote: roOn 10/10/2011 06:44 AM, Eitan Adler wrote: ro Are there any plans on getting these committed to the mainline ports ro tree? I'd be willing to work with you on that. ro roI agree with Eitan. ro ro I would also be pleased to see TeXLive in the FreeBSD ports (obviously). ro There are a few issues to sort out before however: ro- The way TeXLive sources are distributed is not convenient: all ro binaries are built and installed from a single sources tarball. ro This leads to the big print/texlive-core but really lacks ro scalability. Back in 2008, Hiroki Sato was working on splitting all ro this AFAICR. Hiroki, I added you in Cc, can you please tell us if ro you had any progress on this topic? I feel guilty about this because although I had/have several prototypes and plans to integrate TeXLive into the ports tree, it have not actually happened so far. There were two obstacles in the work. One was there were technical issues (compatibility-related) that prevented some existing TeX-related software we had in the ports tree from working. This was in around 2007 but solved now. Another one was how many ports we should have for TeX-related software. After testing several prototypes including a single port version, a set of ~2000 ports (one port for one macro), ~150 ports, or ~30 ports, I think it seems good for us to have one of basic utilities, one for basic (stripped-down) macro sets as something like texlive-core + texlive-texmf, and the others for optional macro packages. The basic idea is the same among them regardless of the total number of ports. In practical, 100 would be the maximum number. So, primary issues described above were basically solved. Although there are still trivial issues such as handling of a large distfile, it is not difficult to solve. However, how to handle updating a macro package in the basic port is a problem to me and time passed when I was thinking about that. More specifically, currently we have many latex-* and tex-* ports to install new macro packages or override the default ones. It becomes complex over time. Committing a single large TeXLive port is easy, but I do not want to create the same situation again in the new world and want consistency for updating a macro package in the distribution. So, I wanted some compatibility with TeXLive's package management utility (tlmgr). Unfortunately it was too premature when I first looked into it (around 2007, IIRC). The current version is much better than before, but I still need some investigation about that. If we have or use reliable package catalogs of CTAN including file lists of each macro package via tlmgr or something, we can take an approach like BSDPAN, I think. A version based on TeXLive 2011 with a small number of ports can be committed if we ignore the last concern and clean up the current teTeX-related ports. Any comments about that? I wasn't quite sure what you meant by the last concern. One concern that Romain brings up is that CTAN reroll their tarballs without updating the version number. I really like the idea of a few small texlive ports. In particular, this will really cut down on the invocations of mktexlsr. But what about this. Have one TeXlive port that installs installs the texlive installer (after building the binaries), and then it runs the texlive installer. The various options that the texlive installer has can be passed via config flags of the texlive port. Then the texlive port does a dynamic plist creation by doing a find on /usr/local/share/texlive (or whereever it is). And plist can also include an @unexec rm -rf %P/share/texlive. plist also includes links to the binaries in share/texlive/bin/xxx, so that they will be removed upon deinstallation. The current texlive installer on tug.org is not too bad, but it installs pre-made binaries, and on my system xdvi does not work because of dynamic library version conflicts. Also it doesn't delete the links it created in bin when it is deinstalled. The current texlive ports created by Romain have a serious deficiency in that tlmgr doesn't work. And tlmgr is necessary to do things like set the page size. Stephen ___ freebsd-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: [PATCH] multimedia/libdvdnav
On Sun, Oct 23, 2011 at 01:17:05AM +1100, richo wrote: I tried to use vlc to play a dvd on -CURRENT but it fails with libdvdnav: vm: ifoRead_FP_PGC failed Googling, I found a patch from debian bugtracker at http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;filename=05-endian.patch;att=1;bug=531621 Which I adjusted for FreeBSD (changed patch to source file and path to include file) Can this be included in ports? I would suggest notifying maintainer about this patch. Perhaps filing a PR is a right thing to do. ./danfe ___ freebsd-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 Thu, 20 Oct 2011 22:25:55 +0200 Leslie Jensen les...@eskk.nu wrote: 2011-10-20 21:37, Pedro Giffuni skrev: Hi leslie; make rmconfig And disable mozilla. Pedro. It was already disabled. I did make deinstall and the make reinstall and got a different error. Please see below. === Building for swt-devel-3.6.2,1 Buildfile: /usr/ports/x11-toolkits/swt-devel/work/build.xml init: build.classes: [javac] /usr/ports/x11-toolkits/swt-devel/work/build.xml:32: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Compiling 582 source files to /usr/ports/x11-toolkits/swt-devel/work/classes [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. build.nativeLibraries: [exec] make: don't know how to make make_webkit. Stop [exec] Model is amd64 [exec] libgnomeui-2.0 found, compiling SWT program support using GNOME [exec] Cairo found, compiling SWT support for the cairo graphics library. [exec] Using libxul for gecko support [exec] WebKit found, compiling webkit embedded browser support. [exec] libjawt.so found, the SWT/AWT integration library will be compiled. [exec] Building SWT/GTK+ for freebsd amd64 BUILD FAILED /usr/ports/x11-toolkits/swt-devel/work/build.xml:62: exec returned: 2 Total time: 7 seconds *** Error code 1 Stop in /usr/ports/x11-toolkits/swt-devel. *** Error code 1 Stop in /usr/ports/x11-toolkits/swt-devel. *** Error code 1 FWIW, I'm seeing exactly the same thing here, both with and without GECKO enabled. This is on a freshly updated amd64 9.0-RC1. -- Conrad J. Sabatier conr...@cox.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: which ports require dialog during update
On 10/22/2011 01:06, Thomas Mueller wrote: from kron24 kro...@gmail.com: OP may want to look on 'make config-recursive'. Sometimes, perhaps when selecting options results in subsequent dialogs, 'make config-recursive' doesn't do all the first time, meaning I get subsequent dialogs. I run 'make config-recursive' repeatedly until it just returns to the command prompt with no more dialogs. I like to make package-recursive | tee build.log so as to have a record especially if not all goes well; this applies equally for 'make install clean' I like to have all config dialogs done and out of the way. You might want to consider using portmaster, which handles that (and a bunch of other stuff) for you. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD unmaintained ports which are currently scheduled for deletion
Chris Rees wrote on 22.10.2011 18:34: On 21 October 2011 07:31,lini...@freebsd.org wrote: portname: databases/postgresql-plpython description:A module for using Python to write SQL functions maintainer: po...@freebsd.org deprecated because: (error in parsing Makefile) expiration date:2011-04-02 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=postgresql-plpython How did this one get in this email? It was fixed two weeks ago... Chris Looks like that this portsmon working with some outdated ports tree, because it builds? (not sure what the name postgresql-plpython-7.4.30_1 actually mean) with postgresql 7.4, that's marked as deprecated in it's ports tree and doesn't exist in current ports tree. -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-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: pkg_version: corrupted record (pkgdep line without argument), ignoring
Jerry wrote: After attempting unsuccessfully to update KDE4 via portmaster, I found a number of errors printed out when using pkg_version-vIL=. I eventually used portmanager to update the KDE4 port successfully; however, I am still receiving the following error messages. These ports need updating: pkg_version: corrupted record (pkgdep line without argument), ignoring pkg_version: corrupted record (pkgdep line without argument), ignoring pkg_version: corrupted record (pkgdep line without argument), ignoring koffice-kde4-2.3.3_3 needs updating (index has 2.3.3_5) postgresql-client-8.2.21 needs updating (index has 8.2.22_1) I have not found a way to ascertain which ports contain the corrupted records. Originally, there were over a dozen of them but portmanager fixed most of them for me. How can I determine what ports are still damaged so that I might correct them. As the others have written, you could use sed, grep, or visual inspection to examine the pkgdb. Alternatively, you could try testing one port at a time, to see what ports pkg_version chokes on, by using something like: pkg_info -aE | xargs -tI @ pkg_version -vIL= -s @ b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD unmaintained ports which are currently scheduled for deletion
Bitrot on the original portsmon, due to be replaced by a new instance. Feel free to ignore. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
