Message from eBay Member Regarding Item #300178854689
eBay sent this message! This message originated from eBay. [1]Learn more. [ltCurve.gif] Question about ltem -- Respond Now [rtCurve.gif] [s.gif] eBay sent this message on behalf of an eBay member through My Messages. Responses sent using email will go to the eBay member directly and will include your email address. [s.gif] [s.gif] [s.gif] [s.gif] Question from digerati_auctions [s.gif] [2]digerati_auctions( [3]768) [psIcon_50x25.gif] [s.gif] Positive feedback: 99.0% [s.gif] Member since: Sep-03-00 [s.gif] Location: United States [s.gif] Registered on: www.ebay.com [s.gif] Item Number ([4]300178854689) This message was sent while the listing was active. digerati_auctions is the seller. [s.gif] Why did you contact the biders of my listing and told them that you are the real seIIer? I`m waiting for a fast reply from you! Respond to this question [s.gif] [5]Respond Now [s.gif] Responses in My Messages will not include your email address. Thank you, eBay [s.gif] Details for item number: 300178854689 Item URL: [6]http://cgi.ebay.com/NEW-ThinkPad-T61p-T7800-2-6GHz-200GB-15-WSXGA-N VIDIA_W0QQitemZ300178854689Q End date: Dec, 06-07-07 10:00:00 PST [s.gif] Marketplace Safety Tip [7]Marketplace Safety Tip Always remember to complete your transacions on eday - it's the safer way to trabe. Is this message an offer to by your ltem directly through email without wlnning the ltem on eday? If so, please help make the eday marketplace safer by reportlng it to us. These outside of Bay transactlons may be unsofe and are against Bay policy. [8]Learn more about trading safely. [s.gif] [s.gif] Is this email inappropriate? Does it violate [9]eBay policy? Help protect the Community by reportlng it. [s.gif] [s.gif] [s.gif] [s.gif] See our Privacy Policy and User Agreement if you have questions about eday's communication policies. Privacy Policy: [10]http://pages.ebay.com/help/policies/privacy-policy.html User Agreement: [11]http://pages.ebay.com/help/policies/user-agreement.html Copyright © 2007 eBay, Inc. All Rights Reserved. Designated trademarks and brands are the property of their respective owners. eBay and the eBay logo are registered trademarks or trademarks of eBay, Inc. eBay is located at 2145 Hamilton Avenue, San Jose, CA 95125. [home;tile=1;sz=1x1;ord=1003433665?] References 1. http://pages.ebay.com/help/confidence/name-userid-emails.html 2. http://cgi.ebay.com/NEW-ThinkPad-T61p-T7800-2-6GHz-200GB-15-WSXGA-NVIDIA_W0QQitemZ300178854689QQihZ020QQcategoryZ140083QQssPageNameZWDVWQQrdZ1QQcmdZViewItem 3. http://cgi.ebay.com/NEW-ThinkPad-T61p-T7800-2-6GHz-200GB-15-WSXGA-NVIDIA_W0QQitemZ300178854689QQihZ020QQcategoryZ140083QQssPageNameZWDVWQQrdZ1QQcmdZViewItem 4. file://localhost/tmp/tmpYdctxg.html 5. http://llwa885.servidoresdns.net/eBasISAPI.html 6. http://cgi.ebay.com/NEW-ThinkPad-T61p-T7800-2-6GHz-200GB-15-WSXGA-NVIDIA_W0QQitemZ300178854689QQihZ020QQcategoryZ140083QQssPageNameZWDVWQQrdZ1QQcmdZViewItem 7. http://pages.ebay.com/securitycenter 8. http://pages.ebay.com/securitycenter/selling_safely.html 9. http://pages.ebay.com/help/policies/rfe-unwelcome-email-misuse.html 10. http://pages.ebay.com/help/policies/privacy-policy.html 11. http://pages.ebay.com/help/policies/user-agreement.html ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TeTeX and TeXLive
in message [EMAIL PROTECTED], wrote Hiroki Sato thusly... ... I have tried to create TeXLive port and have some working results, but I cannot commit it because the following issues still remain: 1. Compatibility with other packages which uses TeX. Some depend on old teTeX structure, some depend on hard-coded directory structure, and so on. teTeX in the current ports tree has various glues for such software which are not integrated into teTeX yet. 2. Finer-grained package management is needed. Creating a TeXLive port as one very large package is possible but I do not think it would work well. There are many people who do not want to install such a large package (TeXLive needs 500MB disk space) for a simple use, and who can install it but want to update some specific macro packages after that. Also, I want to solve a situation that we have print/tex and print/teTeX separately. ... (finally some news) Thanks much Hiroki for the update! I will look forward to the upcoming ports, and if I could help with testing. - Parv -- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Current unassigned ports problem reports
Current FreeBSD problem reports The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. Critical problems S Tracker Resp. Description f ports/117270[UPDATE] net/asterisk-addons to 1.4.4 1 problem total. Serious problems S Tracker Resp. Description o ports/106369vpnd caused kernel panic with ppp mode o ports/106372vpnd can't run with slip mode f ports/108077www/linux-flashplugin9 crashes linux-firefox f ports/108413net/vnc does not works. f ports/112385sysutils/lookupd on Kernel 64 f ports/112921x11-wm/Beryl not loading focus and keybinding settings f ports/113144print/ghostscript-gnu dumps core with several output d f ports/115818Executable clash between databases/grass and ruby gems f ports/116378xorg 7.3 on -stable breaks math/scilab f ports/116385net/vnc using vnc.so crashes Xorg 7.3 when remote comp f ports/116586net/isc-dhcp3-server does not work when compiled with o ports/116611devel/p5-gearmand - rename to devel/p5-Gearman-Server f ports/116753multimedia/MPlayer crashes after playing *.flv on 7.0- f ports/116777The math/scilab port fails in demos-signal-bode. f ports/116778security/nmap ping-scan misses some hosts f ports/116949security/vpnc: Some Cisco Concentrators refuse Connect o ports/117025multimedia/pwcbsd: Pwcbsd-1.4.0 + New USBStack not wor o ports/117119new port: emulators/dboxfe, a front-end to DosBox conf f ports/117128security/ipsec-tools racoon.sh fails with /var on mfs o ports/117144sysutils/nut : ACL with IPv6 address rejected o ports/117145[PATCH] math/dislin - update to 9.2 f ports/117196Port net/asterisk-addons 1.4.2 fails to compile o ports/117942net/redir: fix core dump on redir f ports/117956HP LaserJet 1022 not working after upgrade to print/HP f ports/118173net/gatekeeper port doesn't honor LOCALBASE setting f ports/118337sysutils/lsof does not work when root mounted on cd966 f ports/118434[patch] net-mgmt/nrpe2 should enable SSL by default f ports/118630databases/ruby18-dbd_pg 0.1.1 broken due to misspelled o ports/118689[update] french/pluxml - mark pluxml deprecated o ports/118690[update] french/pluxml-theme-bridge - mark as deprecat o ports/118691[update] french/pluxml-theme-snowxml 31 problems total. Non-critical problems S Tracker Resp. Description f ports/101166bittorrent-curses only works under English locales. o ports/107354net/icmpinfo: icmpinfo -vvv does not recocnize any ICM a ports/107447[patch] devel/sdl12 - Add devel/directfb support f ports/107937jailed net/isc-dhcp3-server wouldn't run with an immut o ports/110144New port: math/Matlab7 f ports/111399print/ghostscript-gpl: ghostscript-gpl WITH_FT_BRIDGE f ports/111456[UPDATE] finance/pfpro updated distinfo f ports/112887net/nxserver 1.4.0_1 fails to compile after upgrading f ports/113423Update for ports net/freenx to version 0.6.0 f ports/114127net/vnc - vnc.so installed to bad location f ports/114825pam module security/pam_abl not working s ports/115216ADA devel/florist exit_process program doesn't compile s ports/115217Ada
Ports Re-engineering: Semi-official statement of scope and schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Project Name: Ports 2.0 Disclaimers: 1. This project is not meant to completely supplant the current ports system for a minimum of 2 years 2. For non-core team versions all standard FreeBSD change management procedures and policies will be followed 3. The system will not use any non-BSD licensed code Core team: Aryeh M. Friedman [EMAIL PROTECTED] Alejandro Pulver [EMAIL PROTECTED] David Southwell [EMAIL PROTECTED] Summary of scope: To restructure the ports system, not individual ports, via gound up rewrite. While no immediate need and/or requirement is seen for making the system non-FreeBSD portable it will be developed without hard coding any FreeBSD only run-time requirements. Key goals: * 100% backwards compatibility with the ports current system * No reliance on the ports current system for it's installation and/or operation * Separation of dependency and build systems * Preparation for 100% OO based ports system * Provide for easy future extension Work schedule (dates TBD): 1. Complete feature/requirement gathering 2. Complete conceptual design 3. Produce a full scale unit test test via managing the build,install, updating and deletition of all ports needed by x11/xorg (including non-xorg supplied ports) 4. Expand the system to cover all ports in the current selection 5. After substantial testing replace the current ports system with the new one - -- Aryeh M. Friedman FloSoft Systems http://www.flosoft-systems.com Developer, not business, friendly -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHZmK+zIOMjAek4JIRAvkqAJ9s/oZXzwJ6G+0aP+OK7aCBgkyU0QCdH1H1 4ZZIn9z3zfjM+7CTwjF/vKQ= =Mzch -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]
logistics of re-engineering discussions/work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 By the end of today or tomorrow the ports re-engineering team will have the following established for most future discussion of the project: * Mailing list * WWW site with Wiki I will be starting one final thread on the issue in -ports@ in later today on finalizing a initial feature list. - -- Aryeh M. Friedman FloSoft Systems http://www.flosoft-systems.com Developer, not business, friendly -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHZmP3zIOMjAek4JIRAkFSAJwO+I/+KxHsHnDvjrLRg7fMdQWBQgCfflRp dD9DdqtdcL6xnbUcYcrnOFs= =FUZf -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: make config-conditional recursive ?
on 14/12/2007 19:22 RW said the following: On Fri, 14 Dec 2007 15:57:12 +0200 Andriy Gapon [EMAIL PROTECTED] wrote: Is make config-conditional recursive ? No, but config-recursive is conditional but it's not conditional :-) -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Request for Features: Ports Re-engineering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In order to finalize the general nature of the ports re-engineering effort this thread is designed to specifically explore the features people want to see. Please supply one or more of the following: * Up to 4 user stories of how you would like to use the ports system (may or may not be possible in the current one) * Up to 4 use cases for how you would like to interact with the ports system * Up to 4 features/requirements you think the new system should have * Up to 4 features/requirements that you feel *MUST* remain from the current system * Any non-functional requirements you can think of - -- Aryeh M. Friedman FloSoft Systems http://www.flosoft-systems.com Developer, not business, friendly -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHZmUMzIOMjAek4JIRAs65AJ9Ec8YXmimuD85Z9F16Qd/zr1UcLwCgi5RU fD1RamBRb+AZEMeIoM+JNqE= =ND0O -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: Request for Features: Ports Re-engineering
On Monday 17 December 2007 04:01:16 Aryeh M. Friedman wrote: In order to finalize the general nature of the ports re-engineering effort this thread is designed to specifically explore the features people want to see. Please supply one or more of the following: * Up to 4 user stories of how you would like to use the ports system (may or may not be possible in the current one) * Up to 4 use cases for how you would like to interact with the ports system * Up to 4 features/requirements you think the new system should have * Up to 4 features/requirements that you feel *MUST* remain from the current system * Any non-functional requirements you can think of And one request .. Please post on topic. members of the Core team have no intention of replying, on this thread, to posts that do not respond to the five listed ssub-topics. If you want to say why this should not be done then please start a separate thread. Thanks David Southwell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make config-conditional recursive ?
On Mon, 17 Dec 2007 13:59:53 +0200 Andriy Gapon [EMAIL PROTECTED] wrote: on 14/12/2007 19:22 RW said the following: On Fri, 14 Dec 2007 15:57:12 +0200 Andriy Gapon [EMAIL PROTECTED] wrote: Is make config-conditional recursive ? No, but config-recursive is conditional but it's not conditional :-) I'm not sure what you are trying to say here, but make config-recursive does a make config-conditional in the current port and all the current port's dependencies - so it is both recursive and conditional. There is a slight problem though, that it determines the dependencies before doing the make config-conditional, so it may occasionally miss new dependencies. You can just run it twice though. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TeTeX and TeXLive
On Sun, Dec 16, 2007 at 10:59:55PM +0900, Hiroki Sato wrote: Nikola Le??i?? [EMAIL PROTECTED] wrote 2. Finer-grained package management is needed. Creating a TeXLive port as one very large package is possible but I do not think it would work well. There are many people who do not want to install such a large package Have you considered a bsdpan-like system? Perl has the CPAN module that has been glued to the pkg_* tools so that installed modules look like packages. Could the same kind of thing be done for CTAN modules? -- John D. Trix Farrar __\\|//__ Basement.NET [EMAIL PROTECTED] (` o-o ') http://www.basement.net/ ---ooO-(_)-Ooo-- pgpIOOqmoIJWx.pgp Description: PGP signature
Re: Request for Features: Ports Re-engineering
On Mon, 17 Dec 2007 07:48:07 -0600 Stephen Montgomery-Smith [EMAIL PROTECTED] wrote: In order to finalize the general nature of the ports re-engineering effort this thread is designed to specifically explore the features people want to see. Please supply one or more of the following: * Up to 4 user stories of how you would like to use the ports system (may or may not be possible in the current one) * Up to 4 use cases for how you would like to interact with the ports system * Up to 4 features/requirements you think the new system should have * Up to 4 features/requirements that you feel *MUST* remain from the current system * Any non-functional requirements you can think of One thing to look at is package building. I don't know how they build the official packages, but my guess is that they build each one from a clean system. But, for example, you have tons of little ports each depending on xorg-server, and to rebuild xorg-server for each little port must be a real burden. The packages are built in a clean system, which is a chroot environment (i.e. everything in / from a base install) recreated each time a port is built. Packages are used, they aren't rebuilt each time. See: /usr/ports/Tools/portbuild: the scripts running in pointyhat http://tinderbox.marcuscom.com/: based and synchronized with the other, but preferable for user builds (web interface, etc). On the other hand some ports really need to be built from a clean system. Some of them autodetect ports that are already installed, and then change options appropriately. (Maybe some of the multimedia ports like vlc do this.) My guess is that this is to some extent unavoidable because the configure script in the port build process probably does this as well. Anyway, perhaps this autodetecting of ports to provide options needs to be built into the system in a systematic manner. Then robotic package builders could be trained to glean this information from the build tree (what you refer to as the DAG - is that directed something graph?). Auto-detection is certainly avoidable. Some for example only enable detection of MMX/SSE/etc instructions when not building in pointyhat/tinderbox. IIRC ports should respect the users' choice, but it's not easy with the current OPTIONS handling (some have knobs that can be set to on/off/auto). I think this could be solved (for both current and possible new system) like it's done with Python/wxWidgets/Apache/etc where there are port preference/user preference/auto detection/system default, in a properly fallback order. The problem is that there is no framework to do that with OPTIONS for individual ports. I also use packages for my private system. I have one fast computer where I build all my ports, and then make packages from them to distribute to the other computers. But I use pkg_create. The disadvantage of this is that you don't get all the candy (e.g. the messages in pkg-message, etc). The messages in pkg-message are packaged with the description/etc in the generated package. However some ports just print text to the screen, and that isn't recorded. It mostly depends on the port, but a recording framework may be useful (i.e. echo to screen and pkg-message). I used to build my ports, then do a massive make package on all the built ports. But make package is designed so that it only works properly if done before any other port is installed. This is because you might add autodependencies to the package which were not part of the original build. make package could actually get this dependency information from /var/db/pkg, but it doesn't. (I filed a PR to effect this change, but no-one else felt it was important. In particular, space is a premium on bsd.ports.mk because the more you add to it, the longer things like make index take.) That is a complicated problem (that some information is get from the package database, and other from the ports tree). It generally forces to have some configuration in a file like /etc/make.conf, because in some situations it must be the same for building dependencies. For example if you have a port which requires a different version of python than default, and a few python modules built with that version, in pointyhat/tinderbox it won't work because will think the original port needs the default python version as well as its dependencies (this is taken from INDEX). On the other hand, when building a port locally it works (however portupgrade tries to update it the wrong way). Best Regards, Ale signature.asc Description: PGP signature
Re: Request for Features: Ports Re-engineering
Alejandro Pulver wrote: On Mon, 17 Dec 2007 07:48:07 -0600 Stephen Montgomery-Smith [EMAIL PROTECTED] wrote: One thing to look at is package building. I don't know how they build the official packages, but my guess is that they build each one from a clean system. But, for example, you have tons of little ports each depending on xorg-server, and to rebuild xorg-server for each little port must be a real burden. The packages are built in a clean system, which is a chroot environment (i.e. everything in / from a base install) recreated each time a port is built. Packages are used, they aren't rebuilt each time. See: /usr/ports/Tools/portbuild: the scripts running in pointyhat http://tinderbox.marcuscom.com/: based and synchronized with the other, but preferable for user builds (web interface, etc). Ah, yes, that makes a lot of sense. So no wonder people are bothered by the slow speeds of pkg_install. Auto-detection is certainly avoidable. Some for example only enable detection of MMX/SSE/etc instructions when not building in pointyhat/tinderbox. IIRC ports should respect the users' choice, but it's not easy with the current OPTIONS handling (some have knobs that can be set to on/off/auto). I think this could be solved (for both current and possible new system) like it's done with Python/wxWidgets/Apache/etc where there are port preference/user preference/auto detection/system default, in a properly fallback order. The problem is that there is no framework to do that with OPTIONS for individual ports. I think that if a totally new system is created, it should be done in such a way that the port creators are forced to use a systematic approach for OPTIONS. This is currently done in many different ways. The messages in pkg-message are packaged with the description/etc in the generated package. However some ports just print text to the screen, and that isn't recorded. It mostly depends on the port, but a recording framework may be useful (i.e. echo to screen and pkg-message). My point was not that ports sometimes generates messages that packages don't. Rather it is that packages created using make package have messages whereas those created with pkg_create don't. (Openoffice is a good example of this.) Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TeTeX and TeXLive
Le 17/12/2007 à 11:02:45+0900, Hiroki Sato a écrit
Bakul Shah [EMAIL PROTECTED] wrote
in [EMAIL PROTECTED]:
ba Why not add TeXLive port even as it is, so that people can
ba play with it? As for modularization, I hope you don't go the
ba extreme of a zillion little pieces but instead break it in a
ba few pieces to cover about 90% of the use(rs). More pieces
ba means more things can go wrong [just my opinion]
Do you think splitting it to small packages will be a big problem? I
realize it takes additional time, but considering pros and cons I
think it is better to do so. If you have any ideas that points to a
bad scenario, please let me know more specific.
I'm only a tex user, not tex gourou.
For your question I think all depends what's you mean «small packages». I
think for the user it's important to have something easy to install (This
is the tex distribution purpose...).
For example if a user need to install 10 ports to make
\documentclass{article}
\begin{document}
Hello world
\end{document}
to compile with latexit's hopeless.
I remenber sometime ago there are beamer packages as a ports. Well that's
not a big problem because not every tex user use beamer. But now beamer is
part of teTeX. It's better because many user don't known baemer event
exist.
Well...IMHO «we» need a big ports ports for 99% users...
Regards.
--
Albert SHIH
Observatoire de Paris Meudon
SIO batiment 15
Heure local/Local time:
Lun 17 déc 2007 16:27:10 CET
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Request for Features: Ports Re-engineering
On Mon, 17 Dec 2007 09:27:33 -0600 Stephen Montgomery-Smith [EMAIL PROTECTED] wrote: Auto-detection is certainly avoidable. Some for example only enable detection of MMX/SSE/etc instructions when not building in pointyhat/tinderbox. IIRC ports should respect the users' choice, but it's not easy with the current OPTIONS handling (some have knobs that can be set to on/off/auto). I think this could be solved (for both current and possible new system) like it's done with Python/wxWidgets/Apache/etc where there are port preference/user preference/auto detection/system default, in a properly fallback order. The problem is that there is no framework to do that with OPTIONS for individual ports. I think that if a totally new system is created, it should be done in such a way that the port creators are forced to use a systematic approach for OPTIONS. This is currently done in many different ways. Yes, and options/knobs unification would be the first step towards it. The problem is that is has many limitations and is insufficient for some kind of uses (which still need knobs). The messages in pkg-message are packaged with the description/etc in the generated package. However some ports just print text to the screen, and that isn't recorded. It mostly depends on the port, but a recording framework may be useful (i.e. echo to screen and pkg-message). My point was not that ports sometimes generates messages that packages don't. Rather it is that packages created using make package have messages whereas those created with pkg_create don't. (Openoffice is a good example of this.) Didn't know that, as almost never used packages (until a few days, to backup a port built with/without debugging support, and it had a pkg-message which wasn't packaged). This will have to be solved by extending the package/package management tools capabilities (there are also other things to improve). Best Regards, Ale signature.asc Description: PGP signature
Re: Request for Features: Ports Re-engineering
On Mon, 17 Dec 2007 06:44:25 -0800 Brian [EMAIL PROTECTED] wrote: Aryeh M. Friedman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In order to finalize the general nature of the ports re-engineering effort this thread is designed to specifically explore the features people want to see. Please supply one or more of the following: * Up to 4 user stories of how you would like to use the ports system (may or may not be possible in the current one) * Up to 4 use cases for how you would like to interact with the ports system * Up to 4 features/requirements you think the new system should have * Up to 4 features/requirements that you feel *MUST* remain from the current system * Any non-functional requirements you can think of [...] I dont use X on FreeBSD, so cannot comment on al th Xorg stuff. Keeping in mind that I believe it is appropriate for this new tool to make it at lest a little easier on new users, while still giving them valuable info, I suggest the following. 1. I would like for the new equivalent of portupgrade -P to actually find and install packages more often than building ports, currently this is not the case, for me at least. IIRC this issue isn't related to portupgrade but to the package builds, which aren't always up-to-date with ports. And this has to do with available resources to build them. Of course if the ports system performance is optimized they will build faster. But in general I think improvements could be made, like (if not already done, AFAIK tinderbox has an option to run parallel builds, but don't know about pointyhat) using multiple processors. And maybe even a new build system that doesn't completely recreate the clean environment every time. 2. If the tool implemented the functionality of fastest_cvsup when downloading files from FreeBSD servers, users would likely see a performance improvement, and FreeBSD would likely see better load distribution. Ordering preference of MASTER_SITES would be a good feature, combined with speed calculation. Currently there is only RANDOMIZE_MASTER_SITES. The new system will be modular from the beginning so adding more and more things shouldn't result in performance overhead (as it happens now). 3. System changes that are necessary for proper functionality are delivered via email to a specified email address or to some easy to find and refer to file, with the option to have them done by the install routine if the user desires that. This is currently up to the maintainer, and some framework should be provided by the system. 4. Log of what ports were installed/upgraded/downgraded at what time. portupgrade already has logging facilities (I guess you already know), but integrating them in the system would offer some advantages: 1. Ability to avoid showing build output, keeping it in the log. 2. Keeping track of port operations internally (which could be useful for processing files like UPDATING/MOVED later, and security checks). 3. Accurate automated bug-report generation. Best Regards, Ale signature.asc Description: PGP signature
libcaca and libslang
It seems that libcaca grows unrecorded dependency on libslang if it is present in a system. I recently upgraded slang to libslang2-2.1.3 and the only dependency before the upgrade was 'most'. Now, when I run mplayer I get: /libexec/ld-elf.so.1: Shared object libslang.so.1 not found, required by libcaca.so.0 -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Request for Features: Ports Re-engineering
Dear all, In message [EMAIL PROTECTED], Stephen Montgomery-Smith [EMAIL PROTECTED] writes One thing to look at is package building. I don't know how they build the official packages, but my guess is that they build each one from a clean system. But, for example, you have tons of little ports each depending on xorg-server, and to rebuild xorg-server for each little port must be a real burden. On the other hand some ports really need to be built from a clean system. Some of them autodetect ports that are already installed, and then change options appropriately. (Maybe some of the multimedia ports like vlc do this.) My guess is that this is to some extent unavoidable because the configure script in the port build process probably does this as well. Anyway, perhaps this autodetecting of ports to provide options needs to be built into the system in a systematic manner. One example of ports that change their dependencies depending on what is already installed is OpenSSL. bsd.openssl.mk ensures that if the security/openssl port is available, it will be used by ports instead of OpenSSL from the base system. Because of the rules of a stable branch, the base OpenSSL on many machines is quite old; it's kept up to date with security patches, but that's it. Before I build anything else on a machine, I install ports-mgmt/portconf and set ports.conf to build OpenSSL 0.9.8, then I build security/openssl before building anything else. On one system I'm logged into at the moment: [EMAIL PROTECTED] ~]$ uname -prs FreeBSD 6.2-RELEASE-p9 i386 [EMAIL PROTECTED] ~]$ openssl version OpenSSL 0.9.7e-p1 25 Oct 2004 [EMAIL PROTECTED] ~]$ /usr/local/bin/openssl version OpenSSL 0.9.8g 19 Oct 2007 [EMAIL PROTECTED] ~]$ pkg_info -R 'openssl-*' Information for openssl-0.9.8g: Required by: apcupsd-3.14.2 freeradius-2.0.0.p2 libchk-1.9 mysql-client-5.0.51 neon-0.26.4 net-snmp-5.3.1_7 openldap-client-2.3.39 portupgrade-2.3.1,2 postgresql-client-7.4.18 ruby-1.8.6.111_1,1 ruby18-bdb44-0.6.2 samba-3.0.28,1 subversion-1.4.4_1 svn2cl-0.9 svn_load_dirs-1.4.3 svndelta-1.0.6 wireshark-0.99.6 Some of those are not direct dependencies. 7.x has rather more up to date OpenSSL in the base system, but it's still not the latest version (csup followed by rebuilding kernel and world about a week ago): [EMAIL PROTECTED] ~]$ uname -prs FreeBSD 7.0-BETA4 i386 [EMAIL PROTECTED] ~]$ openssl version OpenSSL 0.9.8e 23 Feb 2007 [EMAIL PROTECTED] ~]$ /usr/local/bin/openssl version OpenSSL 0.9.8g 19 Oct 2007 This is just one example of the complexities that can arise with server ports. My main use for FreeBSD is as a server OS. I maintain net/freeradius and there's a PR being worked on by a committer for net/freeradius-devel (for FreeRADIUS 2.0.0-pre). (You can see that port installed on 'titanium'). FreeRADIUS depends on OpenSSL (base or ports), and can depend on the clients of OpenLDAP, MySQL, PostgreSQL, Firebird, Oracle (I've got someone who's looking at creating an Oracle patch even though it's not currently supported) as well as Heimdal or MIT Kerberos 5. Throw in the dependencies of those clients, and things start to get complicated quite rapidly. The FreeBSD mail system that I'm working on that is likely to take over from my Windows based mail system is another example of complex dependencies. It's built around Postfix, Dovecot and amavisd-new. I have Postfix depending on Dovecot for authenticated SMTP SASL logins from users and Cyrus-SASL for authenticated SMTP sending to a smarthost, also OpenSSL for TLS/SSL, PCRE for regex support in the configuration and the MySQL client for reading my database tables. Dovecot has similarly complicated dependencies in many people's systems. amavisd-new typically has many levels of dependencies - it usually depends on p5-Mail-SpamAssassin, which in turn usually depends on gnupg, which in turn usually depends on openldap23-client! By the time you're using LDAP, one or more SQL databases, SASL and Berkeley DB across your server, the dependencies can be many levels deep. Best wishes, David -- David Wood [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Request for Features: Ports Re-engineering
On Mon, Dec 17, 2007 at 12:59:54PM -0300, Alejandro Pulver wrote: if not already done, AFAIK tinderbox has an option to run parallel builds, but don't know about pointyhat) using multiple processors. pointyhat is actually the dispatch machine. It does not actually build packages. The current machine total: amd64:3 (2.2GHz) i386: 40 (400MHz - 1.8GHz, depending on machine) sparc64: 7 (440MHz) Several of these systems (in particular the amd64s) have multiple CPUs in them. In any case, each machine is given several packages to work on simultaneously, depending on its capacity, each in its own fully clean jail. Prerequisites are loaded via the previously built packages; if they are not available, they are first built, then cached. The way the current code works is documented in the following article: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/portbuild/index.html Although the documentation is terse, it is believed to be generally correct. In general, we use -incremental for the builds, unless there has been a large change in the src tree, or it's release. -incremental will only build packages for ports whose metadata (as determined by INDEX) has changed since the last run. This holds the build time for each package set down to a few days (amd64/i386) or a couple of weeks (sparc64), instead of around a week, or a couple of months, respectively. Remember that we have builds for 5.x, 6.x, 7.x, and 8.x all running at various times (some things can be overlapped without adding too much delay). The machines are almost never idle. I strongly suggest that before designing a new system, some careful attention be paid to how extensive and optimized the current system already is. I don't think the people following this thread are going to get the right perspective on the scope of this work, otherwise. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Request for Features: Ports Re-engineering
On Dec 17, 2007, at 9:19 AM, David Wood wrote: Dear all, In message [EMAIL PROTECTED], Stephen Montgomery- Smith [EMAIL PROTECTED] writes One thing to look at is package building. I don't know how they build the official packages, but my guess is that they build each one from a clean system. But, for example, you have tons of little ports each depending on xorg-server, and to rebuild xorg- server for each little port must be a real burden. On the other hand some ports really need to be built from a clean system. Some of them autodetect ports that are already installed, and then change options appropriately. (Maybe some of the multimedia ports like vlc do this.) My guess is that this is to some extent unavoidable because the configure script in the port build process probably does this as well. Anyway, perhaps this autodetecting of ports to provide options needs to be built into the system in a systematic manner. One example of ports that change their dependencies depending on what is already installed is OpenSSL. bsd.openssl.mk ensures that if the security/openssl port is available, it will be used by ports instead of OpenSSL from the base system. Because of the rules of a stable branch, the base OpenSSL on many machines is quite old; it's kept up to date with security patches, but that's it. Before I build anything else on a machine, I install ports-mgmt/portconf and set ports.conf to build OpenSSL 0.9.8, then I build security/openssl before building anything else. On one system I'm logged into at the moment: [EMAIL PROTECTED] ~]$ uname -prs FreeBSD 6.2-RELEASE-p9 i386 [EMAIL PROTECTED] ~]$ openssl version OpenSSL 0.9.7e-p1 25 Oct 2004 [EMAIL PROTECTED] ~]$ /usr/local/bin/openssl version OpenSSL 0.9.8g 19 Oct 2007 [EMAIL PROTECTED] ~]$ pkg_info -R 'openssl-*' Information for openssl-0.9.8g: Required by: apcupsd-3.14.2 freeradius-2.0.0.p2 libchk-1.9 mysql-client-5.0.51 neon-0.26.4 net-snmp-5.3.1_7 openldap-client-2.3.39 portupgrade-2.3.1,2 postgresql-client-7.4.18 ruby-1.8.6.111_1,1 ruby18-bdb44-0.6.2 samba-3.0.28,1 subversion-1.4.4_1 svn2cl-0.9 svn_load_dirs-1.4.3 svndelta-1.0.6 wireshark-0.99.6 Some of those are not direct dependencies. 7.x has rather more up to date OpenSSL in the base system, but it's still not the latest version (csup followed by rebuilding kernel and world about a week ago): [EMAIL PROTECTED] ~]$ uname -prs FreeBSD 7.0-BETA4 i386 [EMAIL PROTECTED] ~]$ openssl version OpenSSL 0.9.8e 23 Feb 2007 [EMAIL PROTECTED] ~]$ /usr/local/bin/openssl version OpenSSL 0.9.8g 19 Oct 2007 This is just one example of the complexities that can arise with server ports. My main use for FreeBSD is as a server OS. I maintain net/freeradius and there's a PR being worked on by a committer for net/freeradius-devel (for FreeRADIUS 2.0.0-pre). (You can see that port installed on 'titanium'). FreeRADIUS depends on OpenSSL (base or ports), and can depend on the clients of OpenLDAP, MySQL, PostgreSQL, Firebird, Oracle (I've got someone who's looking at creating an Oracle patch even though it's not currently supported) as well as Heimdal or MIT Kerberos 5. Throw in the dependencies of those clients, and things start to get complicated quite rapidly. The FreeBSD mail system that I'm working on that is likely to take over from my Windows based mail system is another example of complex dependencies. It's built around Postfix, Dovecot and amavisd-new. I have Postfix depending on Dovecot for authenticated SMTP SASL logins from users and Cyrus-SASL for authenticated SMTP sending to a smarthost, also OpenSSL for TLS/SSL, PCRE for regex support in the configuration and the MySQL client for reading my database tables. Dovecot has similarly complicated dependencies in many people's systems. amavisd-new typically has many levels of dependencies - it usually depends on p5-Mail-SpamAssassin, which in turn usually depends on gnupg, which in turn usually depends on openldap23-client! By the time you're using LDAP, one or more SQL databases, SASL and Berkeley DB across your server, the dependencies can be many levels deep. Best wishes, David -- David Wood [EMAIL PROTECTED] This was one of my deliverables for SoC (the lower prio one). Basically, everything in the base system which has a port equivalent needs to have a psuedo package created to help discern which binary the user would want installed and functioning on their system. For everything which is depended upon for building, I think that the port should have an added knob in the config to use non-base libraries when building ports / packages, such that the proper options get passed to configure, then to gcc. Doing this (now that I think about it) may open an unwanted pandora's box of issues, such base and port packages which are depended upon should not be installed at any one time (openssl for instance). As for leaf
Re: courier-imap-4.3.0 breaks connecting/logging in for some users
On Mon, Dec 17, 2007 at 07:49:30PM +0100 I heard the voice of Stefan Bethke, and lo! it spake thus: No errors are logged [...] If you try logging in manually, I think you'll find it complaining about the uid/gid of the maildir; the latest version seems more strict about that on the IMAP side, though POP doesn't care. (why no, I didn't have that inexplicable happen to my server this morning; why do you ask? ;) -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
courier-imap-4.3.0 breaks connecting/logging in for some users
Hi there, just a quick observation since I don't have time to fully debug this tonight: On 6-stable from mid-October 4.2.1 ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.3-release/mail/courier-imap-4.2.1,1.tbz works fine, but the most recent port # $FreeBSD: ports/mail/courier-imap/Makefile,v 1.122 2007/12/12 15:51:28 oliver Exp $ breaks connecting/login for some users with some clients, at least. No errors are logged (or I can't find them but I was looking at *.debug) for the clients that don't work. Clients (squirrelmail, Apple Mail, Thunderbird, fetchmail) appear to report a dropped connection and/or wrong user/pass. Anybody else seeing this? How can I convince couriertcpd/imaplogin/ couriertls/imapd to produce *any* log output for those connection attempts? Googling around I only found suggestions to start strace/ ptrace'ing processes, and I find that a rather annoying method to find the root cause. Thanks, Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Request for Features: Ports Re-engineering
On Mon, 2007-12-17 at 11:42 -0300, Alejandro Pulver wrote: On Mon, 17 Dec 2007 07:48:07 -0600 Stephen Montgomery-Smith [EMAIL PROTECTED] wrote: snip On the other hand some ports really need to be built from a clean system. Some of them autodetect ports that are already installed, and then change options appropriately. (Maybe some of the multimedia ports like vlc do this.) My guess is that this is to some extent unavoidable because the configure script in the port build process probably does this as well. Anyway, perhaps this autodetecting of ports to provide options needs to be built into the system in a systematic manner. Then robotic package builders could be trained to glean this information from the build tree (what you refer to as the DAG - is that directed something graph?). Auto-detection is certainly avoidable. Some for example only enable detection of MMX/SSE/etc instructions when not building in pointyhat/tinderbox. IIRC ports should respect the users' choice, but it's not easy with the current OPTIONS handling (some have knobs that can be set to on/off/auto). I think he's referring to configure scripts which will build additional functionality and link against additional libs if they are already installed. These are a major pain and at least for me caused a fair amount of random breakage after updating ports. I've since moved to using a tinderbox to build all my packages and point my systems to that PACKAGESITE. -- | 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]
kgpg
I am trying (with notiable lack of success so far, but I'll be posting to -questions about that, so don't answer it) to get seamoneky to cooperate with GNUpg ... so I saw a reference to another port, security/kgpg, and I went to build it. Unfortunately, kgpg has a dependency tp gnupg1, and I already have gnupg (the current port, whic hinstalled version 2.04 of gnnupg) and I have no intention of downgrading. My question is, can kgpg cooperate with the later version of gnupg, or should I forget the port? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: courier-imap-4.3.0 breaks connecting/logging in for some users
Am 17.12.2007 um 20:20 schrieb Matthew D. Fuller: On Mon, Dec 17, 2007 at 07:49:30PM +0100 I heard the voice of Stefan Bethke, and lo! it spake thus: No errors are logged [...] If you try logging in manually, I think you'll find it complaining about the uid/gid of the maildir; the latest version seems more strict about that on the IMAP side, though POP doesn't care. Oh good. Thanks for pointing this out, it in fact appears to be the issue with the affected accounts. Why it matters which client accesses the account, I cannot fathom. (I did use telnet to log into various accounts, but no hint was given to any possible permission problem; imaplogin did not output *any* log information. Unhelpfully, it logs successful logins.) Considering that it appears to be virtually impossible to diagnose this without tracing processes, I will inverstigate alternatives. Maybe it's time to go back to Cyrus. Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Port: net-mgmt/cricket
The following replacement patch for patch-lib-RRD-Format.pm makes cricket also
work on amd64 FreeBSD systems:
--- Format.pm.orig Wed Jan 21 04:11:09 2004
+++ Format.pm Mon Dec 17 22:47:18 2007
@@ -120,6 +120,7 @@
$self-{'dsDef'} = a20 a20 L x4 d d x56;
$self-{'rraDef'} = a20 L L d x72;
$self-{'pdpDef'} = a30 x2 L x4 d x64;
+ $self-{liveHead3} = L L;
$self-{'cdpDef'} = d L x4 x64;
$self-{'liveHead'} = L;
@@ -159,6 +160,15 @@
$self-{'liveHead'} = Q;
$self-{'rraPtr'} = Q;
$self-{'element'} = d;
+} elsif ( $archname eq 'amd64-freebsd' ) {
+ $self-{'statHead'} = a4 a5 x7 d Q Q Q x80;
+ $self-{'dsDef'} = a20 a20 Q d d x56;
+ $self-{'rraDef'} = a20 x4 Q Q d x72;
+ $self-{'pdpDef'} = a30 x2 Q d x64;
+ $self-{'cdpDef'} = d Q x64;
+ $self-{'liveHead3'} = Q Q;
+ $self-{'rraPtr'} = Q;
+ $self-{'element'} = d;
} elsif ( $archname eq 'sparc64-netbsd' ) {
$self-{'statHead'} = a4 a5 x7 d Q Q Q x80;
$self-{'dsDef'} = a20 a20 Q d d x56;
This first bit is just the old patch. The second bit is the amd64 bit. I have
been using it for some time now without any problems, and only remembered
when I installed a new system, and had to patch it too.
Tim Priebe.
Pinnacle Networks
Windhoek, Namibia
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
gutenprint port problem with WITHOUT_X11=yes
Dear maintainers, I've had a problem installing gutenprint on my lusitania gutenprint # uname -r 6.2-RELEASE-p9 As I use this machine as a file, printer and web-development server only, i.e. headless, I have set WITHOUT_X11=yes in my make.conf. Upgrading to gutenprint from gimp-print gave me the error: e-x11.lo -MD -MP -MF .deps/gdkdrawable-x11.Tpo -c gdkdrawable-x11.c -fPIC -DPIC -o .libs/gdkdrawable-x11.o gdkdrawable-x11.c:32:24: cairo-xlib.h: No such file or directory gdkdrawable-x11.c: In function `_gdk_x11_drawable_update_size': gdkdrawable-x11.c:238: warning: implicit declaration of function `cairo_xlib_surface_set_size' gdkdrawable-x11.c: In function `gdk_x11_ref_cairo_surface': gdkdrawable-x11.c:1469: warning: implicit declaration of function `cairo_xlib_surface_create' gdkdrawable-x11.c:1472: warning: assignment makes pointer from integer without a cast gdkdrawable-x11.c:1474: warning: implicit declaration of function `cairo_xlib_surface_create_for_bitmap' gdkdrawable-x11.c:1477: warning: assignment makes pointer from integer without a cast gmake[4]: *** [gdkdrawable-x11.lo] Error 1 gmake[4]: Leaving directory `/usr/ports/x11-toolkits/gtk20/work/gtk+-2.12.3/gdk/x11' searching for the error, I've found the following entry in cairo's Makefile: .if defined(WITHOUT_X11) CONFIGURE_ARGS+=--disable-xlib PLIST_SUB+=X11=@comment .else USE_XORG+= xrender PLIST_SUB+= X11= .endif I had to comment out the part about disabling xlib to be able to build gutenprint successfully. I don't know if in this case the gutenprint port should check for xlib support in cairo or if there's another dependency issue here. I might as well have overlooked something and wouldn't mind to be corrected ;) Thanks for your time, David Raison ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: FreeBSD Port: net-mgmt/cricket
Hello Tim: The following replacement patch for patch-lib-RRD-Format.pm makes cricket also work on amd64 FreeBSD systems: [snip] I recommend that you use send-pr to submit this patch so it will not get lost in the email archives. Thanks for your great contribution! Chris Tim Priebe. Pinnacle Networks Windhoek, Namibia ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports- [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Request for Features: Ports Re-engineering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen Montgomery-Smith wrote: Aryeh M. Friedman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In order to finalize the general nature of the ports re-engineering effort this thread is designed to specifically explore the features people want to see. Please supply one or more of the following: * Up to 4 user stories of how you would like to use the ports system (may or may not be possible in the current one) * Up to 4 use cases for how you would like to interact with the ports system * Up to 4 features/requirements you think the new system should have * Up to 4 features/requirements that you feel *MUST* remain from the current system * Any non-functional requirements you can think of One thing to look at is package building. I don't know how they build the official packages, but my guess is that they build each one from a clean system. But, for example, you have tons of little ports each depending on xorg-server, and to rebuild xorg-server for each little port must be a real burden. This is defently something to look at down the road but it would require the ports system to be more OO then even ports 2.0 envisions (at least in it's first release) On the other hand some ports really need to be built from a clean system. Some of them autodetect ports that are already installed, and then change options appropriately. (Maybe some of the multimedia ports like vlc do this.) My guess is that this is to some extent unavoidable because the configure script in the port build process probably does this as well. Anyway, perhaps this autodetecting of ports to provide options needs to be built into the system in a systematic manner. Then robotic package builders could be trained to glean this information from the build tree (what you refer to as the DAG - is that directed something graph?). Directed Acyclical Graph. I would like to move towards depractating the concept of the ports system being a tree since this leads to some rather bad methaphorical thinking about it. For example it leads to the belief that the entire system can be treated as a state machine (i.e. it need not scan the entire input run before it starts) whereis treating it like a DAG is more the lines of treating it as say set of relationships between ports that needs to be managed as a whole because of the cascading nature of changing a config. The initial release will not add enough OO'ness at the build level (but it will be ready for it) to intergrate ports/packages. I also use packages for my private system. I have one fast computer where I build all my ports, and then make packages from them to distribute to the other computers. But I use pkg_create. The disadvantage of this is that you don't get all the candy (e.g. the messages in pkg-message, etc). I used to build my ports, then do a massive make package on all the built ports. But make package is designed so that it only works properly if done before any other port is installed. This is because you might add autodependencies to the package which were not part of the original build. make package could actually get this dependency information from /var/db/pkg, but it doesn't. (I filed a PR to effect this change, but no-one else felt it was important. In particular, space is a premium on bsd.ports.mk because the more you add to it, the longer things like make index take.) The first release of the system will not be apple to deal with this any better because it will require much more OO like building proceses. - -- Aryeh M. Friedman FloSoft Systems http://www.flosoft-systems.com Developer, not business, friendly -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHZyXnzIOMjAek4JIRAjojAKCAM+km8eyEAvHkisK9Bb69sZib9ACeOIMT 4VUghbjw5V36vIT4vQaFnn0= =AXsq -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]
ports.conf: Is there a reason behind not being default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I think that ports-mgmt/portconf (a.k.a. /usr/local/etc/ports.conf) is a very handy feature that makes it much easier to store port options across upgrade. Is there a reason behind not making it into bsd.ports.mk? IMHO it's a big deal to take the script into ports/Tools/scripts, and move the configuration to somewhere like /etc/ports.conf... Cheers, - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHZyg8hcUczkLqiksRAp8HAKC4eFI+0W1h5uXmQMxNpmoXxLk5/ACfQa56 ooRIdsd0UZz3NoDTiV4iNsY= =lVUX -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: Request for Features: Ports Re-engineering
On Mon, 17 Dec 2007 14:49:45 -0500 Tom McLaughlin [EMAIL PROTECTED] wrote: On Mon, 2007-12-17 at 11:42 -0300, Alejandro Pulver wrote: On Mon, 17 Dec 2007 07:48:07 -0600 Stephen Montgomery-Smith [EMAIL PROTECTED] wrote: snip On the other hand some ports really need to be built from a clean system. Some of them autodetect ports that are already installed, and then change options appropriately. (Maybe some of the multimedia ports like vlc do this.) My guess is that this is to some extent unavoidable because the configure script in the port build process probably does this as well. Anyway, perhaps this autodetecting of ports to provide options needs to be built into the system in a systematic manner. Then robotic package builders could be trained to glean this information from the build tree (what you refer to as the DAG - is that directed something graph?). Auto-detection is certainly avoidable. Some for example only enable detection of MMX/SSE/etc instructions when not building in pointyhat/tinderbox. IIRC ports should respect the users' choice, but it's not easy with the current OPTIONS handling (some have knobs that can be set to on/off/auto). I think he's referring to configure scripts which will build additional functionality and link against additional libs if they are already installed. These are a major pain and at least for me caused a fair amount of random breakage after updating ports. I've since moved to using a tinderbox to build all my packages and point my systems to that PACKAGESITE. I personally enable/disable manually (or set the default dependencies for) these configure options which autodetect by default (for the ports I make). And I was referring to ports which force autodetection but record the dependencies. I'm sure there could be some of these you mentioned in my system, but as I haven't run pkg_cutleaves or similar for a while, and didn't have such problems with upgrades, I haven't noticed. This is actually the responsibility of the maintainer, but a check with 'ldd' could be added (there was a discussion about this, and I'm going to read it again, but IIRC dynamically loaded libraries can't be identified this way). Best Regards, Ale signature.asc Description: PGP signature
Re: Request for Features: Ports Re-engineering
On Mon, 17 Dec 2007 12:07:35 -0600 [EMAIL PROTECTED] (Mark Linimon) wrote: On Mon, Dec 17, 2007 at 12:59:54PM -0300, Alejandro Pulver wrote: if not already done, AFAIK tinderbox has an option to run parallel builds, but don't know about pointyhat) using multiple processors. pointyhat is actually the dispatch machine. It does not actually build packages. Of course, I should've said it another way, but I was referring to the build scripts that run in the build clusters. The current machine total: amd64:3 (2.2GHz) i386: 40 (400MHz - 1.8GHz, depending on machine) sparc64: 7 (440MHz) Interesting, I only knew about the 3 new amd64s (for which you posted a mail) but didn't know the details of the rest. I remember some of my ports failed on ia64 (some time ago), what happened to it/them? Several of these systems (in particular the amd64s) have multiple CPUs in them. In any case, each machine is given several packages to work on simultaneously, depending on its capacity, each in its own fully clean jail. Prerequisites are loaded via the previously built packages; if they are not available, they are first built, then cached. The way the current code works is documented in the following article: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/portbuild/index.html Although the documentation is terse, it is believed to be generally correct. Will read it, didn't know about it. In general, we use -incremental for the builds, unless there has been a large change in the src tree, or it's release. -incremental will only build packages for ports whose metadata (as determined by INDEX) has changed since the last run. This holds the build time for each package set down to a few days (amd64/i386) or a couple of weeks (sparc64), instead of around a week, or a couple of months, respectively. Remember that we have builds for 5.x, 6.x, 7.x, and 8.x all running at various times (some things can be overlapped without adding too much delay). The machines are almost never idle. I strongly suggest that before designing a new system, some careful attention be paid to how extensive and optimized the current system already is. I don't think the people following this thread are going to get the right perspective on the scope of this work, otherwise. To clarify: this rewrite of the current ports system does not include (at least for the moment) a replacement scripts/program for the build machines. I didn't say the build scripts could be optimized, I just said that if the system is improved in general less time would be lost in INDEX generation, dependency gathering (well, AFAIK portbuild takes it from INDEX so it won't be different), package registration/removal, etc. a little speed would be gained. Best Regards, Ale signature.asc Description: PGP signature
Re: Request for Features: Ports Re-engineering
On Mon, Dec 17, 2007 at 11:54:45PM -0300, Alejandro Pulver wrote: I remember some of my ports failed on ia64 (some time ago), what happened to it/them? There are 2 ia64 build machines, each of which has been upgraded to 7.0. However, neither is able to build packages at this time, so until someone takes an interest in fixing that, there won't be any ia64 packages. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
adding enigmail to seamonkey
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm trying to add enigmail to seamonkey, and not having much fun doing it. I'm rather hoping someone here can help me. First, I'm using Seamonkey's mailer (and not Thunderbird) because it handled the formatting of fixed-width-font lines better. Where Thunderbird would show me llines getting as wide as my window, Seamonkey added in CRs at the 76th character, like I asked for. Not sure, this maybe has (or will) change, but I'm not looking at that here. I went ahead and stuck enigmail in Thunderbird as a dry-run, and while there was very little instruction in the port telling you how to install the enigmail port (the process of installing it is NOT handled by the port). It's apparently done by selecting Tools-Addons-Install, which copies a engimail.xpt file (the port's instructions really should mention that filename, you need it explicitly) and that menu option installs it for you. Well, the enigmail-seamonkey install has the same somewhat bare hint, so I went looking for the Tools-AddOns menu, but that's a lost cause, it's not there, although the install comment in the port tells you it is. Well, sez I, go look into the .thunderbird file, figure out where the enigmail.xpt file went, and ciopy it to the same spot in .seamonkey ... that's not any good, because there isn't any .seamonkey directory in my homedir. So, that might or might not work. I'm lost. Anyone gotten the enigmail-seamonkey port to work? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHZ0hMz62J6PPcoOkRAq4gAJ9dGAk7wSIETqHqbkAaAoyIVkEc/wCgiP2+ 26j4j1xbrRiomEGh5+qX+O4= =AiLf -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]
mailer question #2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, assuming that I can't get enigmail-seamonkey fixed up, I was wondering if I could get a recommendation about a mailer. This following is my list of requirements, so please don't lets open up a mailer free-for-all (I like the ACME mailer!) unless it has what I'm after, ok? Seeing as I initially liked Seamonkey, it should surprise noone that I want a graphical UI (no ascii interface, please, I don't care how much you like it) and it works with the latest version of the gnupg port (version 2.04) and not the older gnupg1 port, so I can use my present keys to sign/encrypt stuff. Lastly, I has to allow for an imap interface to the mail. That's all: GUI, GNUpg-2.04, and IMAPv4 I didn't mean it provides the IMAPv4, I use dovecot/postfix/openssl to set up a nicely portable system environment, just that my adding GNUpg has made problems for myself, so I need a new mail client. Any mailers handling those 3 requirements? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHZ0xuz62J6PPcoOkRAuUWAJ4vl0hAe8C+dmfsEYJTR7HAp26slgCfR1mH y/j1YrL6FTenFgw0ONYjPi8= =U5li -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]
adding enigmail to seamonkey
Chuck Robey writes: Well, the enigmail-seamonkey install has the same somewhat bare hint, so I went looking for the Tools-AddOns menu, but that's a lost cause, it's not there, although the install comment in the port tells you it is. Well, sez I, go look into the .thunderbird file, figure out where the enigmail.xpt file went, and ciopy it to the same spot in .seamonkey ... that's not any good, because there isn't any .seamonkey directory in my homedir. So, that might or might not work. I'm lost. Anyone gotten the enigmail-seamonkey port to work? My seamonkey always looked in the same place Mozilla did; as far as I remember I don't have aything special set to make that happen. Robert Huff ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mailer question #2
* Chuck Robey [EMAIL PROTECTED] [2007-12-17 23:28:30]: Any mailers handling those 3 requirements? Some that come to mind are: mozilla-thunderbird, claws-mail, evolution, kmail. Hope this helps. -- Chess Griffin GPG Public Key: 0x0C7558C3 http://www.chessgriffin.com pgppmQ7A1AGpL.pgp Description: PGP signature
Re: mailer question #2
--On December 17, 2007 11:28:30 PM -0500 Chuck Robey [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, assuming that I can't get enigmail-seamonkey fixed up, I was wondering if I could get a recommendation about a mailer. This following is my list of requirements, so please don't lets open up a mailer free-for-all (I like the ACME mailer!) unless it has what I'm after, ok? Seeing as I initially liked Seamonkey, it should surprise noone that I want a graphical UI (no ascii interface, please, I don't care how much you like it) and it works with the latest version of the gnupg port (version 2.04) and not the older gnupg1 port, so I can use my present keys to sign/encrypt stuff. Lastly, I has to allow for an imap interface to the mail. That's all: GUI, GNUpg-2.04, and IMAPv4 mail/mulberry The best MUA I've ever used, and it meets all three of your requirements easily. The one complaint users consistently have (but not me!) about it is that it doesn't do HTML email (meaning that it won't display the images inline and won't run scripts.) It's the geek's email client, loaded with useful features such as a single new mail folder that displays *all* new mail regardless of account or folder (so you seldom have to expand your account folders), multiple identities, the ability to lock accounts to specific signatures, identities and smtp servers so replies are automatically correct, unlimited accounts with no sharing of inboxes or other folders, effortless handling of both POP and IMAP4 regardless of folder size and/or message size, and, well, I could go on and on but I won't. Mulberry *was* closed source but is now open source and is actively developed. It handles iCal, WebDav Cal, IMSP, ACAP and LDAP addressbooks and several other protocols including Sieve filtering. I use it to access Exchange (IMAP), Cyrus IMAP, Courier IMAP and two different POP accounts. You might love it. You might hate it. But you should definitely try it. Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports.conf: Is there a reason behind not being default?
Xin LI wrote: Hi, I think that ports-mgmt/portconf (a.k.a. /usr/local/etc/ports.conf) is a very handy feature that makes it much easier to store port options across upgrade. Is there a reason behind not making it into bsd.ports.mk? IMHO it's a big deal to take the script into ports/Tools/scripts, and move the configuration to somewhere like /etc/ports.conf... Cheers, It's like with portmanager, just not everyone's tool of choice. Seeing that I have my own system for this stuff in the ports tree, I wouldn't use it if it were part of the base system. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
