Re: Proposal for another category in INDEX: common_deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Doug Barton wrote: Matthew Seaman wrote: In many ways it would be more useful to delete from the EXTRACT_DEPENDS, FETCH_DEPENDS, PATCH_DEPENDS, BUILD_DEPENDS[*] lists in the INDEX any package that also appears in the RUN_DEPENDS list. This leaves the four listed fields with just the extra packages that need to be present at build/install time. Everything that is needed to build the port must be in BUILD_DEPENDS. Everything necessary to run the port must be in RUN_DEPENDS. This is needed to support building packages on one machine, and running them on another. In terms of what you need in port Makefiles, then yes. In terms of what goes into the INDEX, then no. I was intending only to change the format and content of the INDEX. Calling the INDEX columns by the same names as the Make variables they are (mostly) derived from has now got the the state where it is more confusing than enlightening, so thinking up different column names sounds like a good idea to me. In terms of Makefile variables, BUILD_DEPENDS has a quite specific meaning: it all the extra software that must be present at the time the 'do-build:' target in the port Makefile is reached. Of the others, (which apply analogously to the 'do-fetch:', 'do-extract:', 'do-patch:' targets.) EXTRACT_DEPENDS is used reasonably frequently, generally for ports that need unzip to extract them. Otherwise those variables tend to be empty because the base system supplies all of the necessary functionality. libarchive nowadays can unpack zips so many more of the EXTRACT_DEPENDS variables will eventually end up empty as well. Do I think the whole architecture of the ports system should be changed to eliminate most of the *_DEPENDS targets? No. Too much pain for no gain. Do I think it's worth having a separate column in the INDEX for the contents of those variables? No. -- and as gmake depends on gettext that means a very large fraction of the ports most people have installed. However, if the only way an application depends on gettext is via gmake /at build time/ then rebuilding that application is really not necessary. Using LIB_DEPENDS to distinguish ports that are linked against any particular shlib versus those that inherit a dependency against a shlib for other reasons could save rather a lot of wasted CPU cycles. I don't see how we need a separate LIB_DEPENDS to achieve this. Can you describe in more detail the mechanism you have in mind? The idea was that anything in a LIB_DEPENDS target of a port would a a shared library to be linked against, and it's only the software that links against the shlib that needs to be recompiled if the shlib ABI changes. However I see on reflection that this doesn't go far enough: DSO modules have the same sort of linkage requirement, but don't get mentioned in LIB_DEPENDS Again, the idea here was not to change anything in the ports themselves: just what was presented in the INDEX, and then mainly as a resource to make easier the lives of the people that write ports management software. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGocLJ8Mjk52CukIwRCBeTAJ9YCTbgTWo9N71pssC5ZgqJO1GD/wCfUs4g NitUYwteyQDZnZ1392pAbjQ= =akvP -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proposal for another category in INDEX: common_deps
Matthew Seaman wrote: Again, the idea here was not to change anything in the ports themselves: just what was presented in the INDEX, Ok, then I think it's incumbent on you to explain what the benefit would be. and then mainly as a resource to make easier the lives of the people that write ports management software. Well, I'm one of those people, and portmaster ignores the index file altogether, for whatever that's worth. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
eclipse 3.3.0
Hi Is a port of eclipse 3.3.0 likely soon? Thanks david ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proposal for another category in INDEX: common_deps
Doug Barton wrote: and then mainly as a resource to make easier the lives of the people that write ports management software. Well, I'm one of those people, and portmaster ignores the index file altogether, for whatever that's worth. Me too for pkgupgrade. In my case the rationale is that, if something has to be compiled on the machine, it is best that the information is exactly compatible with the state of the ports tree on the machine. So like portmaster, pkgupgrade recomputes the Index fields for all installed ports and their dependencies. This is no big deal, uses less than a minute on a modern machine, totally negligible compared to the time for downloading distfiles or packages, or running pkg_delete or pkg_add. In pkgupgrade case one needs to deal with both binary packages and ports, so RUN_DEPENDS is used to discover dependencies of packages, and all other fields coalesced to discover dependencies of ports. There is of course a further subtelty: you have to compare old and new ports which may have changed name in between. The rule i have taken is to systematically use the most recent name as it appears in the ports tree, and evolve old names following the MOVED file (perhaps recursively) to be able to compare them with new names. This leaves on the border of the road ports which have disappeared in between, but anyways you cannot upgrade them by source ... I think that portmaster does more or less the same, while, if i don't err, portupgrade doesn't and tries to guess new names using heuristics, which sometimes spectacularly fails. Well, all this to say that, for the purpose of upgrading a port, it is the coalesced values of fetch, extract, etc. which is of interest. Of course, for other purposes, like Mark Linimon says, these fields may have individual interest. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
sudo 1.6.9 segfault
Jul 21 15:12:01 home sudo: admin : TTY=unknown ; PWD=/home/admin ; USER=root ; COMMAND=/sbin/ipfw Jul 21 15:12:36 home kernel: pid 42226 (sudo), uid 0: exited on signal 11 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
Kent Stewart [EMAIL PROTECTED] wrote: On Friday 20 July 2007, Mark Linimon wrote: On Fri, Jul 20, 2007 at 04:07:49PM -0400, Bill Moran wrote: Even better would be for make to realize that it's only doing the fetching, and do it anyway. That still doesn't help with the problem of a user who starts a 10MB download that won't work on his architecture or OS release. The code is all the same. This is the aggravation we are trying to prevent. That still doesn't address the concern or improve the system downtime that a pkg_delete, make install allows. If you can't run something, you don't have any downtime but to have to pkg_delete before you start the tarball fetch can be really long on some ports. It's certainly a tradeoff. Either way you do it, there are practical scenarios where a user is inconvenienced. Perhaps an environmental override is the best route. NO_IGNORE=yes or something similar? -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proposal for another category in INDEX: common_deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Doug Barton wrote: Matthew Seaman wrote: Again, the idea here was not to change anything in the ports themselves: just what was presented in the INDEX, Ok, then I think it's incumbent on you to explain what the benefit would be. * Reduce the size of the INDEX * Make the index data directly answer the sort of questions most likely to come up in general use. The latter is, of course, subjective but I think knowing the answers to both 'what do I need to run this software?' and 'what else do I need to install this software?' is more useful than what we have at the moment. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGod3R8Mjk52CukIwRCKJCAJ0VBzcFxnNK+6aMDCklvwvYvm/YbACePNat QAoADDuGBD2bouGCalW8thw= =JOPb -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports depending on FORBIDDEN ports
G'day Peter, Thanks for summarising this. Responses for some specific ports below. On Sat, Jul 21, 2007 at 10:52:52AM +1000, Peter Jeremy wrote: The misc/compat3x port is unlikely to ever be fixed and therefore it would seem reasonable to deprecate both it and the following ports that depend on it: java/gj-jdk11Extension of the Java programming language that supports generic types Should be removed. Modern versions support generics natively. java/infobus Enables dynamic exchange of data between JavaBeans(TM) Just installs a JAR, can depend on a higher version of the JDK instead. java/jdk11 Java Development Kit 1.1 java/jdk12 Java Development Kit 1.2 Should be removed, as should all JDKs 1.4 except for jdk13. java/jfc Java Foundation Classes (JFC)/Swing Should be removed. java/jre Standard Java Platform for running Java programs Should be removed. java/tya A ``100% unofficial'' JIT-compiler for java Should depend on jdk13 instead of jdk11. I'm particularly concerned about the existence of 'java/jre' and it's description as the 'Standard Java Platform for running Java programs'. This appears to occasionally trap people who are looking for a current JRE and attempt to install java/jre. It and anything that depends on it should be removed. -- Greg Lewis Email : [EMAIL PROTECTED] Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
What to do when the person who takes responsibility for a PR goes non-responsive?
Summited http://www.freebsd.org/cgi/query-pr.cgi?pr=113611 over a month ago, Araujo took responsibility, and has been no sign from him that this is ever going to get committed. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sudo 1.6.9 segfault
On Sat, 2007-07-21 at 16:39 +0600, yarodin wrote: Jul 21 15:12:01 home sudo:admin : TTY=unknown ; PWD=/home/admin ; USER=root ; COMMAND=/sbin/ipfw Jul 21 15:12:36 home kernel: pid 42226 (sudo), uid 0: exited on signal 11 I need a little more information. sudoers: tom LOCAL = NOPASSWD: /sbin/ipfw [EMAIL PROTECTED] tom]$ sudo ipfw Last login: Sat Jul 21 13:09:52 on ttyp0 usage: ipfw [options] do ipfw -h or see ipfw manpage for details What options are you using in the port? What does your sudoers look like? Also, I'm curious why TTY would show up as unknown in the log. tom -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Ports with version numbers going backwards: net-p2p/azureus2
** The following ports have a version number that sorts before a previous one ** For many package tools to work correctly, it is of utmost importance that version numbers of a port form a monotonic increasing sequence over time. Refer to the FreeBSD Porter's Handbook, 'Package Naming Conventions' for more information. Tools that won't work include pkg_version, portupgrade and portaudit. A common error is an accidental deletion of PORTEPOCH. Please fix any errors as soon as possible. The ports tree was updated at Sat Jul 21 2007 16:32:01 UTC. - *net-p2p/azureus2* [EMAIL PROTECTED]: azureus2-2.5.0.4 azureus-3.0.1.6 | revision 1.46 | date: 2007/07/21 03:12:36; author: rafan; state: Exp; lines: +4 -5 | - Downgrade to 2.5.0.4. No PORTEPOCH is required since this port was just | copied from net-p2p/azureus and it's not connected to build yet. | | PR:ports/114486 | Submitted by: Robert Noland rnoland at 2hip.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with version numbers going backwards: net-p2p/azureus2
On Sat, Jul 21, 2007 at 05:31:49PM +, [EMAIL PROTECTED] wrote: ** The following ports have a version number that sorts before a previous one ** For many package tools to work correctly, it is of utmost importance that version numbers of a port form a monotonic increasing sequence over time. Refer to the FreeBSD Porter's Handbook, 'Package Naming Conventions' for more information. Tools that won't work include pkg_version, portupgrade and portaudit. A common error is an accidental deletion of PORTEPOCH. Please fix any errors as soon as possible. As I noted in commit log, this port is just repocopied and not connected to build. The is intentional. Regards, Rong-En Fan The ports tree was updated at Sat Jul 21 2007 16:32:01 UTC. - *net-p2p/azureus2* [EMAIL PROTECTED]: azureus2-2.5.0.4 azureus-3.0.1.6 | revision 1.46 | date: 2007/07/21 03:12:36; author: rafan; state: Exp; lines: +4 -5 | - Downgrade to 2.5.0.4. No PORTEPOCH is required since this port was just | copied from net-p2p/azureus and it's not connected to build yet. | | PR: ports/114486 | Submitted by:Robert Noland rnoland at 2hip.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with +CONTENTS being messed up by pkg_delete -f
Quoting [EMAIL PROTECTED] (Thomas-Martin Seck) (Fri, 20 Jul 2007 19:54:06 +0200
(CEST)):
* Alexander Leidinger [EMAIL PROTECTED] [gmane.os.freebsd.devel.ports]:
Quoting Robert Noland [EMAIL PROTECTED] (Thu, 19 Jul 2007 13:31:42 -0400):
Ok, so the issue that I hope to address is not really a portmanager
issue. The original version of package-depends always listed the
current version (from ports) in the +CONTENTS file. When that list was
passed to sort -u, you ended up with a single dependency for each
origin.
The new way it takes each direct dependency and adds those, then
recursively parses the +CONTENTS file of each of those and adds those
entries and finally passes the whole thing to sort -u. This allows for
multiple dependencies with the same origin to be listed in the +CONTENTS
file.
As an example... port a depends on b and c. Port c has a version bump
and is updated but technically b doesn't require an update. Now if port
a is updated it will get the current version of c and also the old
version of c from b.
Ok, I see the problem (in case b depends on c too). This is only an
issue if you do this by hand instead of using portupgrade (or something
else), as those tools should correct the dependency in port b to the
new version of c. If they don't do it, it's a bug in those tools.
Oh not at all. This will also happen if you install dependencies via
packages when these packages' dependencies do not exactly match what you
have presently installed.
Example:
package a-1.0 has a recorded dependency on b-1.0. Meanwhile, b got
upgraded to 1.0_1.
You have b-1.0_1 installed locally and then install port c which depends
on a and use a's package in order to save build time (imagine a being
something in the firefox/xorg-libs range with USE_PACKAGE_DEPENDS set in
your make environment). Hilarity ensues. The old algorithm could recover
from this I guess.
Sort of. There would still be a wrong dependency in the db (for port a,
but not for port c).
As for the current algorithm this only leads to listing a dependency
more than once. Normally this is catched by the sort in PKG_ARGS, but
as only the origin is the same and not the version number, this fails.
To fix it, we can change the sort invocation to include -t : -k 2.
This does fix this issue, but also changes the final sorting order
(sorted for origin, and not for package name). Is this an issue?
Here's a visualisation.
Old sort invocation:
printf
'png-1.2.18:graphics/png\nperl-5.8.8:lang/perl5.8\nperl-5.8.8_1:lang/perl5.8\n'
| sort -u
Result:
perl-5.8.8:lang/perl5.8
perl-5.8.8_1:lang/perl5.8
png-1.2.18:graphics/png
New sort invocation:
printf
'png-1.2.18:graphics/png\nperl-5.8.8:lang/perl5.8\nperl-5.8.8_1:lang/perl5.8\n'
| sort -u -t : -k 2
Result:
png-1.2.18:graphics/png
perl-5.8.8:lang/perl5.8
Attached is the patch for this and the bug when a port has no origin
recorded (and the fix for the comment regarding the name of the
actual-package-depends target). I haven't tested this much, maybe
someone can give it a try in the case where a port has no origin
recorded and in the case which is discussed in this thread. If
everything is fine and portmgr doesn't object to the change of the
final order of the dependencies as recorded in the package, I will
submit this for an experimental run on the ports build cluster.
It looks like one is forced to repair the package db with external tools
everytime one does not install from source and from scratch.
This was the case before (sort of), but it was not that obvious as now.
Bye,
Alexander.
--
Time is the most valuable thing a man can spend.
-- Theophrastus
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Index: bsd.port.mk
===
RCS file: /import/FreeBSD-CVS/ports/Mk/bsd.port.mk,v
retrieving revision 1.573
diff -u -r1.573 bsd.port.mk
--- bsd.port.mk 29 Jun 2007 14:09:39 - 1.573
+++ bsd.port.mk 21 Jul 2007 18:03:10 -
@@ -732,7 +732,7 @@
# tree as recorded in the Makefiles of the ports
# collection, not as recorded in the currently
# installed ports.
-# actual-package-depends-list
+# actual-package-depends
#- Like package-depends-list but with the difference
# that the dependencies of the currently installed
# ports are used instead of the dependencies as
@@ -2458,7 +2469,7 @@
DISABLE_CONFLICTS= YES
.endif
.if !defined(PKG_ARGS)
-PKG_ARGS= -v -c -${COMMENT:Q} -d ${DESCR} -f ${TMPPLIST} -p ${PREFIX} -P `cd ${.CURDIR} ${MAKE} actual-package-depends | ${GREP} -v -E ${PKG_IGNORE_DEPENDS} | ${SORT} -u` ${EXTRA_PKG_ARGS} $${_LATE_PKG_ARGS}
+PKG_ARGS= -v -c -${COMMENT:Q} -d ${DESCR} -f ${TMPPLIST} -p ${PREFIX} -P `cd ${.CURDIR} ${MAKE} actual-package-depends | ${GREP} -v -E ${PKG_IGNORE_DEPENDS} | ${SORT} -u -t : -k 2`
Re: Ports with version numbers going backwards: net-p2p/azureus2
On Sun, Jul 22, 2007 at 01:34:08AM +0800, Rong-En Fan wrote: On Sat, Jul 21, 2007 at 05:31:49PM +, [EMAIL PROTECTED] wrote: ** The following ports have a version number that sorts before a previous one ** For many package tools to work correctly, it is of utmost importance that version numbers of a port form a monotonic increasing sequence over time. Refer to the FreeBSD Porter's Handbook, 'Package Naming Conventions' for more information. Tools that won't work include pkg_version, portupgrade and portaudit. A common error is an accidental deletion of PORTEPOCH. Please fix any errors as soon as possible. As I noted in commit log, this port is just repocopied and not connected to build. The is intentional. The script has no way of knowing this, so I have to edit it's datafiles by hand afterwards. -erwin -- Erwin Lansing http://droso.org Security is like an onion. (o_ _o) It's made up of several layers \\\_\ /_///[EMAIL PROTECTED] And it makes you cry.) ([EMAIL PROTECTED] pgpaW7Ld4N8LC.pgp Description: PGP signature
Re: What to do when the person who takes responsibility for a PR goes non-responsive?
I assume that you've already emailed the person? If so, sending email to portmgr@ is the right way to go. We'll attempt to find out if the person is busy/on vacation/overloaded/etc. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
emacs upgrade question
Earlier this week, I was not yet ready to commit to the emacs upgrade, but i wanted to upgrade my other ports. So i added EMACS_PORT_NAME=emacs21 to make.conf and did 'portupgrade -f -o editors/emacs21 emacs', followed by my usual 'portupgrade -a'. Now I'm ready to upgrade to emacs 22. What's the correct procedure for this? I'm guessing perhaps it's to set the var in make.conf to emacs22 and then do 'portupgrade -fr emacs'. however, it is important to me that my emacs setup is not borked, so i would appreciate if someone could confirm. thanks, /brian Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
TeXLive for Net/FreeBSD
Hi, Firstly I would like to apologise for the cross-post. I wouldn't usually do this, but as the message for both lists is identical, It would have looked like a cross post (even if it wasn't)... I have just finished porting TeXLive (A modern TeX distribution to replace the old teTeX port) to OpenBSD. During the porting process I documented the how/why and what's of the port; a) So that I can remember how to do it when the next release of texlive comes out and b) So that the other BSD's might find the information useful for a port as our ports (or pkgsrc for NetBSD) systems are similar(ish). Here are the reason I personaly chose to port TeXLive: - No sparc64 binaries on the TeXLive DVD - TeXLive more modern than teTeX - XeteX support - ConTeXt support - More comprehensive macro collection - pkg_add convenience There is a whole load of information and source code relating to the OpenBSD port on my webpage (http://students.dec.bmth.ac.uk/ebarrett/texlive/). Hope it might help. If not, disregard this mail. I am not on list, so if you do want to contact me, you should reply to my personal email address. -- Best Regards Edd --- http://students.dec.bournemouth.ac.uk/ebarrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TeXLive for Net/FreeBSD
Hello Edd, On Sat, 21 Jul 2007 20:07:46 +0100 Edd Barrett [EMAIL PROTECTED] wrote: Hi, Firstly I would like to apologise for the cross-post. I wouldn't usually do this, but as the message for both lists is identical, It would have looked like a cross post (even if it wasn't)... Ok, I'm adding Hiroki Sato (hrs@), AFAIK he is currently doing on porting TeXLive to FreeBSD (according to freebsd-ports@ archive). I have just finished porting TeXLive (A modern TeX distribution to replace the old teTeX port) to OpenBSD. During the porting process I documented the how/why and what's of the port; a) So that I can remember how to do it when the next release of texlive comes out and b) So that the other BSD's might find the information useful for a port as our ports (or pkgsrc for NetBSD) systems are similar(ish). Yes, I saw this on texlive mailing list, excellent job! I'd like to ask Hiroki Sato, you and everyone interested/involved in this (and I'm not fluent in OpenBSD ports interface...) for their opinion regarding to what extent are parts of TeXLive (or are about to be) modularised -- i.e. how the new releases of TeXLive elements (e.g. ConTeXt, XeTeX) can be integrated? I use this opportunity to offer a help; I'm particularly interested in XeTeX-related stuff (xetex, (lib)icu-xetex, (lib)graphite-engine, xdvipdfmx) since I use it. For example, development version of xetex (currently not in TeXLive source) includes support for Graphite. I'd like to see (or maybe to maintain, test, or whatever) a xetex-devel port, that can replace standard xetex port (as it is the case with many other applications). There is a whole load of information and source code relating to the OpenBSD port on my webpage (http://students.dec.bmth.ac.uk/ebarrett/texlive/). Just one more question, why do you call TeXLive LaTeX distribution? I think that LaTeX is just one part, and by no means the central one. I'm now going to read your document more carefully. Nikola Lečić ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TeXLive for Net/FreeBSD
Hi Nikola, On 21/07/07, Nikola Lecic [EMAIL PROTECTED] wrote: Yes, I saw this on texlive mailing list, excellent job! Thankyou. I'd like to ask Hiroki Sato, you and everyone interested/involved in this (and I'm not fluent in OpenBSD ports interface...) for their opinion regarding to what extent are parts of TeXLive (or are about to be) modularised -- i.e. how the new releases of TeXLive elements (e.g. ConTeXt, XeTeX) can be integrated? The project has a dependency infrastructure API, which is being re-written as we speak. In 2007 it was the TPM (TeX package manager) system, which I parsed using a python script - MfSplit (which you may download from my web-page). I use this opportunity to offer a help; I'm particularly interested in XeTeX-related stuff (xetex, (lib)icu-xetex, (lib)graphite-engine, xdvipdfmx) since I use it. Be aware that the icu lib must be static in tl, as they have modified it. What do you do with all of this software, may I ask? For example, development version of xetex (currently not in TeXLive source) includes support for Graphite. I'd like to see (or maybe to maintain, test, or whatever) a xetex-devel port, that can replace standard xetex port (as it is the case with many other applications). Sounds like you are planning on making a far more fine grained port than I have. Be warned it is a massive port that will drive you insane if you get too involved. I have my port in only 4 modules. Read the PDF I linked for more info. Just one more question, why do you call TeXLive LaTeX distribution? I think that LaTeX is just one part, and by no means the central one. Im aware. Quote from the main page of thier site TeX Live is an easy way to get up and running with TeX. Make of it what you will :P I'm now going to read your document more carefully. Hope there are no typo's! Nikola Lečić -- Best Regards Edd --- http://students.dec.bournemouth.ac.uk/ebarrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Do you plan to update...
Hi - I am wondering if you plan to update the gwenhywfar and aqbanking ports, both of which have much more recent versions? - Marc ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TeXLive for Net/FreeBSD
(Hmmm, claws-mail somehow removed hrs@ from CC; I'm re-adding him.) On Sat, 21 Jul 2007 21:27:52 +0100 Edd Barrett [EMAIL PROTECTED] wrote: Hi Nikola, On 21/07/07, Nikola Lecic [EMAIL PROTECTED] wrote: Yes, I saw this on texlive mailing list, excellent job! Thankyou. I'd like to ask Hiroki Sato, you and everyone interested/involved in this (and I'm not fluent in OpenBSD ports interface...) for their opinion regarding to what extent are parts of TeXLive (or are about to be) modularised -- i.e. how the new releases of TeXLive elements (e.g. ConTeXt, XeTeX) can be integrated? The project has a dependency infrastructure API, which is being re-written as we speak. In 2007 it was the TPM (TeX package manager) system, which I parsed using a python script - MfSplit (which you may download from my web-page). I use this opportunity to offer a help; I'm particularly interested in XeTeX-related stuff (xetex, (lib)icu-xetex, (lib)graphite-engine, xdvipdfmx) since I use it. Be aware that the icu lib must be static in tl, as they have modified it. Yes, but it's possible (if necessary) to create a separate icu-xetex port. XeTeX from TL207 and XeTeX-devel use different versions of that lib (3.4 vs. 3.6). What do you do with all of this software, may I ask? This is very fascinating and new field. XeTeX/xdvipdfmx provides you an unforseen possibility to combine strengths of TeX (or LaTeX/ConTeXt) and high quality OTF (and AAT) fonts -- and these fonts come with extensive support for subtle typesetting techniques, support for complex scripts, and all that in Unicode (unknown to original TeX). As far as fonts are concerned, Graphite engine is quite new software; it's a free/libre replacement for ICU, and it seems to be more subtle. [I personally use them for typesetting in my profession (in the field of philosophy) -- and that includes typesetting of Ancient Greek, Sanskrit etc. And the software realm related to complex/ancient scripts, input methods, fonts, etc. is particularly interesting to me.] For example, development version of xetex (currently not in TeXLive source) includes support for Graphite. I'd like to see (or maybe to maintain, test, or whatever) a xetex-devel port, that can replace standard xetex port (as it is the case with many other applications). Sounds like you are planning on making a far more fine grained port than I have. I'm just a FreeBSD user, so I'm actually asking, not planning :) -- and offering help. (There was no public discussion on these matters on FreeBSD lists yet, so I'm interested to hear from Hiroki -- he is a FreeBSD developer). Be warned it is a massive port that will drive you insane if you get too involved. I have my port in only 4 modules. Read the PDF I linked for more info. Yes, since that would mean re-creating TeXLive from scratch. But I'd be happy to see a possibility that new versions of at least ConTeXt, XeTeX and couple of other sophisticated tools can be compiled from ports and integrated with the rest of TL. And again, I'm offering help for XeTeX-devel friends since I regularly compile them inside the old TL environment and XeTeX provides the integration of that kind. (Don't forget that TL only has anual releases.) Just one more question, why do you call TeXLive LaTeX distribution? I think that LaTeX is just one part, and by no means the central one. Im aware. Quote from the main page of thier site TeX Live is an easy way to get up and running with TeX. Make of it what you will :P I'm now going to read your document more carefully. Hope there are no typo's! Nikola Lečić ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TeXLive for Net/FreeBSD
On Sat, 21 Jul 2007 21:27:52 +0100 Edd Barrett [EMAIL PROTECTED] wrote: Sounds like you are planning on making a far more fine grained port than I have. Be warned it is a massive port that will drive you insane if you get too involved. I have my port in only 4 modules. Read the PDF I linked for more info. Ok, I've taken a preliminary look. Let's consider XeTeX. Your base sub-package includes XeTeX. But it can be simply compiled --without-xetex. Then XeTeX (a separate port) can be compiled from its standalone repository (xetex-devel port) or from TL2007 sources (xetex port) and then integrated. If the base (your texmf-minimal) remains unchanged (as it was at the time of TL2007 release) -- it will maybe need some patches for the files outside xetexdir/, but nothing too difficult. (I'm currently experimenting with patches for unified installation of XeTeX-devel with both current TL trunk base and TL2007 base.) The same for other packages with integrated --without-* possibility (pdftex, omega, etex, musixflx..); the only concern is how much patching their sources require and who is willing to maintain that. This can be nicely done with XeTeX since Jonathan Kew always cares of TL integration. So this means that no massive complications must occur. What do you think? Nikola Lečić ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
mulberry mail crashes when using PGP under AMD64 ... ?
Running latest -STABLE of FreeBSD on an 64bit Dual Core, mulberry mail seems to run okay until such a point in time as I try to PGP Sign/Encrypt an email and send it out, then it 'Seg Faults' ... gpg appears to run fine from the command line, using gpg --list-keys ... Anyone running Mulberry + 6-STABLE + AMD64 kernel successfully? Thanks ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mulberry mail crashes when using PGP under AMD64 ... ?
--On July 21, 2007 6:53:23 PM -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: Running latest -STABLE of FreeBSD on an 64bit Dual Core, mulberry mail seems to run okay until such a point in time as I try to PGP Sign/Encrypt an email and send it out, then it 'Seg Faults' ... gpg appears to run fine from the command line, using gpg --list-keys ... Anyone running Mulberry + 6-STABLE + AMD64 kernel successfully? Mark, that's a none problem being discussed on the mullberry lists right now. It's not just amd64. Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: Ports depending on FORBIDDEN ports
Greg Lewis píše v pá 20. 07. 2007 v 23:30 -0600: The misc/compat3x port is unlikely to ever be fixed and therefore it would seem reasonable to deprecate both it and the following ports that depend on it: java/gj-jdk11Extension of the Java programming language that supports generic types Should be removed. Modern versions support generics natively. Only the jdk11 slave, or whole java/gj? java/jdk11 Java Development Kit 1.1 java/jdk12 Java Development Kit 1.2 Should be removed, as should all JDKs 1.4 except for jdk13. So should I axe all the linux-*13 too? -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] Quantum physics was developed in the 1930's, as a result of a bet between Albert Einstein and Niels Bohr, to see who could come up with the most ridiculous theory and still have it published. signature.asc Description: Toto je digitálně podepsaná část zprávy
geography category adoption
Virtual category geography was created some time ago. Is anybody willing to scan the tree and add some ports to that category? -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] Just because you're an angel doesn't mean you have to be a fool. signature.asc Description: Toto je digitálně podepsaná část zprávy
FreeBSD Port: dkim-milter-1.2.0
I have recently installed and am trying to implement dkim-milter-1.2.0 and have found what I believe to be a bug. The file /usr/ports/mail/dkim-milter/work/dkim-milter-1.2.0/INSTALL (line 60) states: the TXT record should be: SELECTOR._domainkey.example.com however running the script /usr/ports/mail/dkim-milter/work/dkim-milter-1.2.0/dkim-filter/gentxt.csh generates a TXT record in a different format: example.com._domainkey From what I have been able to find out, the gentxt.csh script output is incorrect. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mulberry mail crashes when using PGP under AMD64 ... ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Saturday, July 21, 2007 17:13:51 -0500 Paul Schmehl [EMAIL PROTECTED] wrote: --On July 21, 2007 6:53:23 PM -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: Running latest -STABLE of FreeBSD on an 64bit Dual Core, mulberry mail seems to run okay until such a point in time as I try to PGP Sign/Encrypt an email and send it out, then it 'Seg Faults' ... gpg appears to run fine from the command line, using gpg --list-keys ... Anyone running Mulberry + 6-STABLE + AMD64 kernel successfully? Mark, that's a none problem being discussed on the mullberry lists right now. It's not just amd64. Which list? :( I'm on mulberry-discuss ... Hopefully now that he's puttin gout the source code, we can get a FreeBSD Native version in ports ... :) The funny thing is that I'm now running same version off of an i386 box (my old machine) and its running fine *sigh* Thanks ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGoqB74QvfyHIvDvMRAgDHAJ4s/BWQdaKMb2yUEAwacxRaTpeY1wCglqSL jR+fB2XoaNdyEPZhJVQKcKU= =evCl -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Do you plan to update...
Marc Evans wrote: Hi - I am wondering if you plan to update the gwenhywfar and aqbanking ports, both of which have much more recent versions? I think these ports are unmaintained. We would love to see someone to take it over (hint :) Cheers, ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: eclipse 3.3.0
Tom McLaughlin wrote: On Sat, 2007-07-21 at 03:07 -0700, David Southwell wrote: Hi Is a port of eclipse 3.3.0 likely soon? Thanks david [EMAIL PROTECTED], now CC'ed, may be a better place to ask though I don't see anything in their archives about it. On a side note, are any committers associated with [EMAIL PROTECTED] I've had a 3.2.2 update assigned to eclipse@ for a little bit. I use eclipse only minimally and don't feel comfortable committing it myself without comments on it since some of the last updates I've submitted have needed a correction or two for minor things I've missed. I will ask nemoliu@ to see if he has interest. He used to develop some Eclipse bits and use it for his daily work. Cheers, ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What to do when the person who takes responsibility for a PR goes non-responsive?
Zane C.B. [EMAIL PROTECTED] wrote: Summited http://www.freebsd.org/cgi/query-pr.cgi?pr=113611 over a month ago, Araujo took responsibility, and has been no sign from him that this is ever going to get committed. Posting to this list would be a good step. However, the subject title could be better. Something like, Would a committer please look at 113611 then mention in the email what port it relates to and comment that the person responsible seems to be timing out. Have you contacted Araujo directly? -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mulberry mail crashes when using PGP under AMD64 ... ?
--On July 21, 2007 9:10:27 PM -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: Which list? :( I'm on mulberry-discuss ... Oh, sorry. The mulberry-devel list. Hopefully now that he's puttin gout the source code, we can get a FreeBSD Native version in ports ... :) Hopefully. The funny thing is that I'm now running same version off of an i386 box (my old machine) and its running fine *sigh* Including GPG? On my Mac, Mulberry core dumps if I scan past an email with a digital signature in it. On my FreeBSD box it core dumps if I try to encrypt a message. I don't recall what it does on Windows because I almost never use it there. Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: mulberry mail crashes when using PGP under AMD64 ... ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Saturday, July 21, 2007 22:58:40 -0500 Paul Schmehl [EMAIL PROTECTED] wrote: Including GPG? Yes, been using Mulberry for months now *because* of the GPG support, actually ... it was what finally get me off of Pine ... but, again, only on the i386 box ... In fact, on amd64, encrypt or sign causes it to crash ... and notice that this message is sign'd, on my i386 box ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGouo24QvfyHIvDvMRAhhpAKChonjgyqJBzq2n91HTM8ly5c5fTwCginby kPnJn9PXJCnj/IkfygZ7ZoY= =0p4v -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Please test: mplayer/mencoder split
Hi, to be able to make mplayer pkg-add'able and to introduce proper dependencies on the mencoder binary for several frontents, the next major update to our mplayer port will introduce an mencoder slave port. Hence, mencoder can also be built with different OPTIONS than mplayer. A preliminary version (i.e. one that works for me) can be found on http://www.rrr.de/~riggs/mplayer/m20070722.tar.bz2 Please grab a copy and test this port with your specific build options and preferences and report fixes/problems and so on to me. Thank you in advance, Riggs ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
