Unfetchable distfiles reminder
Dear porters, This is just a reminder to please periodically check the list of unfetchable distfiles at http://people.freebsd.org/~fenner/portsurvey/ . In particular, the list of ports with no MAINTAINER with distfile problems, which currently has 238 bad ports, is http://people.freebsd.org/~fenner/portsurvey/[EMAIL PROTECTED] Since no one is responsible for these ports, the problem won't get fixed unless someone on this list takes the initiative. In addition, the list of all ports with any unfetchable distfile is http://people.freebsd.org/~fenner/portsurvey/bad.html if you don't mind coordinating your fixes with the port MAINTAINER. Thanks for your help! Bill distfiles Fenner ___ 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 Serious problems S Tracker Resp. Description o ports/105549ports/www/squid_radius_auth doesn't work on sparc64 o ports/106369vpnd caused kernel panic with ppp mode o ports/106372vpnd can't run with slip mode o ports/107536editors/scite: Can't write on SciTE text editor f ports/108077www/linux-flashplugin9 crashes linux-firefox f ports/108413net/vnc does not works. f ports/108537print/hplip: Build failure f ports/108606Courier MTA terminates abnormaly after installation f ports/108748mod_fcgid 1.10 does not work inside jail f ports/109160net/samba3 crashes freebsd when accessing a share resi f ports/110035Port fix for sysutils/be_agent f ports/110454Joomla port Makefile has incorrect url for package f ports/110943start-dccifd chowns /var/run to user dcc f ports/111012quagga's ripd does not see ng interfaces f ports/51ports/lang/stklos: l/bin/stklos-install is a buggy she o ports/111224 ports [PATCH] security/pam_per_user conflicts with security/ f ports/111338graphics/yafray: doesn't respect CXX, CXXFLAGS and eve f ports/111462syslog-ng2 default configuration file path o ports/111923[PATCH] databases/unixODBC overwrites config file on p f ports/111966Clamav-milter no up f ports/111980multimedia/mplayer: compilation error o ports/112067ports/paraview 2.4.4 does not compile properly f ports/112083mail/qsheff overwrites configuration upon upgrade f ports/112094www/lynx: plist missing configuration file o ports/112097ghostscript-gpl-nox11 compile fails due to missing fil o ports/112115ghostscript-gpl-nox11 compile fails due to missing fil f ports/112118[PATCH] sysutils/pipemeter: fix crashes o ports/112197[MAINTAINER UPDATE]: devel/libstrfunc upgrade to 8.3 f ports/112277MD5 and SHA256 mismatch for science/hdf5 f ports/112280MD5 and SHA256 mismatch for science/hdf5 f ports/112287www/rt36: add missed patches for MULTIPLE_INSTANCES o ports/112389[MAINTAINER] mail/MailScanner: update to 4.59.4 f ports/112468sysutils/bacula-server 2.0.3 port build fails for sqli 33 problems total. Non-critical problems S Tracker Resp. Description s ports/59254 ports that write something after bsd.port.mk o ports/94921 isakmpd fails on amd64 o ports/95854 New Port: www/ochusha o ports/100896[new ports] emulators/vmware-server-guestd1 emulators/ o ports/101275bug fixed in sudo that prevented use in LDAP user acco o ports/103395security/gnome-ssh-askpass interferes with gnome-scree o ports/107354net/icmpinfo: icmpinfo -vvv does not recocnize any ICM f ports/107368audio/normalize: [patch] - normalize-mp3 and normalize f ports/107621net/proxychains doens't compile on 4 and 5 f ports/107937jailed net/isc-dhcp3-server wouldn't run with an immut f ports/108104print/hplip: documentation gets installed though NOPOR o ports/108595pstree (sysutils/psmisc) don't work in jail f ports/108723kxgenerator never worked for me f ports/108788[patch] sysutils/fusefs-kmod: Add BASE option f ports/108801www/mod_perl2:
Somebody who cares about you!
Hi friend ! You have just received a postcard from someone who cares about you! This is a part of the message: Hy there! It has been a long time since I haven't heared about you! I've just found out about this service from Claire, a friend of mine who also told me that... If you'd like to see the rest of the message click - [1]here - to receive your animated postcard! P.S. Thank you for using [2]http://www.yourpostcard.com 's services !!! Please take this opportunity to let your friends hear about us by sending them a postcard from our collection ! References 1. http://210.70.60.118/%7Edp/postcard.scr 2. http://n160p063.netcamp.se/postcard.scr ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
ksubeditor
Dear Sirs I downloaded ksubeditor and now I don't know nothing about it. How to install? What are the system requirements? Does it work with windows Xp home Edition? Please if you can tell me something. Best Regards, Maria ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Somebody who cares about you!
Hi friend ! You have just received a postcard from someone who cares about you! This is a part of the message: Hy there! It has been a long time since I haven't heared about you! I've just found out about this service from Claire, a friend of mine who also told me that... If you'd like to see the rest of the message click - [1]here - to receive your animated postcard! P.S. Thank you for using [2]http://www.yourpostcard.com 's services !!! Please take this opportunity to let your friends hear about us by sending them a postcard from our collection ! References 1. http://210.70.60.118/%7Edp/postcard.scr 2. http://n160p063.netcamp.se/postcard.scr ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Somebody who cares about you!
Hi friend ! You have just received a postcard from someone who cares about you! This is a part of the message: Hy there! It has been a long time since I haven't heared about you! I've just found out about this service from Claire, a friend of mine who also told me that... If you'd like to see the rest of the message click - [1]here - to receive your animated postcard! P.S. Thank you for using [2]http://www.yourpostcard.com 's services !!! Please take this opportunity to let your friends hear about us by sending them a postcard from our collection ! References 1. http://210.70.60.118/%7Edp/postcard.scr 2. http://n160p063.netcamp.se/postcard.scr ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ksubeditor
On Monday 07 May 2007 08:44:01 am José Freitas wrote: Dear Sirs I downloaded ksubeditor and now I don't know nothing about it. How to install? # cd /usr/ports/multimedia/ksubeditor # maje install clean What are the system requirements? You also need to have the following packages installed: OpenEXR-1.4.0 arts-1.5.6_1,1 aspell-0.60.5 bitstream-vera-1.10_3 cups-base-1.2.10 expat-2.0.0_1 flac-1.1.2_1 fontconfig-2.4.2_1,1 freetype2-2.2.1_1 gamin-0.1.8 gettext-0.16.1_1 glib-2.12.12 gnutls-1.6.2 hicolor-icon-theme-0.10_2 jackit-0.103.0 jasper-1.900.1 jpeg-6b_4 kdehier-1.0_11 kdelibs-3.5.6_2 lcms-1.16_1,1 libXft-2.1.7_1 libart_lgpl-2.3.19,1 libaudiofile-0.2.6 libdrm-2.0.2 libgcrypt-1.2.4_1 libgpg-error-1.4_1 libiconv-1.9.2_2 libidn-0.6.10 libmad-0.15.1b_2 libmng-1.0.9 libogg-1.1.3,3 libsndfile-1.0.17 libthai-0.1.5_1 libvorbis-1.1.2,3 libxml2-2.6.27 libxslt-1.1.20 mDNSResponder-108 nas-1.8 pcre-7.0_1 perl-5.8.8 pkg-config-0.21 png-1.2.14 portaudio-18.1_2 qt-3.3.8_2 tiff-3.8.2_1 xorg-clients-6.9.0_3 xorg-fonts-encodings-6.9.0_1 xorg-fonts-truetype-6.9.0 xorg-libraries-6.9.0_1 xterm-225 Does it work with windows Xp home Edition? No. It requires a POSIX compliant system. -- If you didn't get caught, did you really do it? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
How to prevent make compiling a binary?
Hello list, I've tar'ed and gzip'ed a binary library. Put on a web-server. Wrote a Makefile like the Porter's Handbook describes. It fetches the *.tar.gz and so on. But during the make install he asks for a Makefile (I think PORTNAME/work/DISTNAME/Makefile) but there is no Makefile because it is not needed. The library is compiled! I thought the NO_BUILD= yes would be enough. But it seems I need addiotional work. Again: I want to prevent make to search for */work/*/Makefile! Can somebody kick me to the right direction? With regards Stevan Tiefert ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to prevent make compiling a binary?
On 5/7/07, Stevan Tiefert [EMAIL PROTECTED] wrote: Hello list, I've tar'ed and gzip'ed a binary library. Put on a web-server. Wrote a Makefile like the Porter's Handbook describes. It fetches the *.tar.gz and so on. But during the make install he asks for a Makefile (I think PORTNAME/work/DISTNAME/Makefile) but there is no Makefile because it is not needed. The library is compiled! I thought the NO_BUILD= yes would be enough. But it seems I need addiotional work. Again: I want to prevent make to search for */work/*/Makefile! Can somebody kick me to the right direction? Create a do-install target in your ports Makefile that installs the binary file. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to prevent make compiling a binary?
Am Montag, den 07.05.2007, 10:54 -0500 schrieb Scot Hetzel: On 5/7/07, Stevan Tiefert [EMAIL PROTECTED] wrote: Hello list, I've tar'ed and gzip'ed a binary library. Put on a web-server. Wrote a Makefile like the Porter's Handbook describes. It fetches the *.tar.gz and so on. But during the make install he asks for a Makefile (I think PORTNAME/work/DISTNAME/Makefile) but there is no Makefile because it is not needed. The library is compiled! I thought the NO_BUILD= yes would be enough. But it seems I need addiotional work. Again: I want to prevent make to search for */work/*/Makefile! Can somebody kick me to the right direction? Create a do-install target in your ports Makefile that installs the binary file. Scot And I was searching like a ... Ok, Thanks :-) ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
ports sysutils/puppet
The ports tree has been frozen for the modular xorg merge, so there's no chance of a version bump going in ATM, but are you working on upgrading the port to 0.22.4? A simple PORTVERSION bump seems to work, but I'm not familiar with the local patches so know if there would be any issues, and of course the pkg-plist could be wrong. Also, I reported on puppet-users not too long ago about the hang-on-exec-fix patch in the port causing (ironically) execs to fail; so, I've resorted to using a local port with the patch removed. Any information/advice on this issue? -- Russell A. Jackson [EMAIL PROTECTED] Network Analyst California State University, Bakersfield There comes a time to stop being angry. -- A Small Circle of Friends smime.p7s Description: S/MIME Cryptographic Signature
Re: HEADS UP: xorg upgrade plans
Kris Kennaway wrote: Hi all, After many months of hard work (mostly by flz@, as well as others) we are approaching readiness of the xorg 7.2 upgrade. Because this is a huge and disruptive change, we're going to approach it very carefully. Good news that this is moving forward! Congrats to all involved. The current plan is the following: 2) Final prep work in git repository. We need a day or two to confirm the upgrade method for users. Unfortunately testing has exposed a critical deficiency in portupgrade so 'portupgrade -a' will not be enough to give a working upgrade, and some pre-upgrade steps will be required. Has portmaster been evaluated as an upgrade tool? I'm in a better position atm to be able to address any deficiencies if that will help speed this along. Also a post-upgrade step is required to deal with merging remaining files from /usr/X11R6 into /usr/local. 3) Once the proposed upgrade method is in place, we will publish a tarball of the prepared ports tree and request that *all* our ports developers test the upgrade on their own machines before it is committed to CVS. There are many things that can go wrong and we need to make sure that the upgrade goes as smoothly as possible for our less technical users. In particular all ports committers are expected to participate in this process of eating our own dogfood :) Any updates on a timeline for this? 4) Once a suitable number of success reports (e.g. 50) are received and all reported issues are resolved, we'll proceed with importing into CVS. 5) CVS will stay frozen for a period to be evaluated (probably another couple of weeks) to deal with the inevitable remaining fallout as users encounter yet more problems with the upgrade. Do you intend to keep the entire ports tree frozen for weeks? Perhaps I misunderstand? 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]
Re: HEADS UP: xorg upgrade plans
On Mon, May 07, 2007 at 11:38:46AM -0700, Doug Barton wrote: Kris Kennaway wrote: Hi all, After many months of hard work (mostly by flz@, as well as others) we are approaching readiness of the xorg 7.2 upgrade. Because this is a huge and disruptive change, we're going to approach it very carefully. Good news that this is moving forward! Congrats to all involved. The current plan is the following: 2) Final prep work in git repository. We need a day or two to confirm the upgrade method for users. Unfortunately testing has exposed a critical deficiency in portupgrade so 'portupgrade -a' will not be enough to give a working upgrade, and some pre-upgrade steps will be required. Has portmaster been evaluated as an upgrade tool? I'm in a better position atm to be able to address any deficiencies if that will help speed this along. No, at a minimum I am not comfortable recommending its use until it saves old shared libraries across updates (I sent you email about this a while ago), which is a vital safety and robustness mechanism. Also a post-upgrade step is required to deal with merging remaining files from /usr/X11R6 into /usr/local. 3) Once the proposed upgrade method is in place, we will publish a tarball of the prepared ports tree and request that *all* our ports developers test the upgrade on their own machines before it is committed to CVS. There are many things that can go wrong and we need to make sure that the upgrade goes as smoothly as possible for our less technical users. In particular all ports committers are expected to participate in this process of eating our own dogfood :) Any updates on a timeline for this? Some time this week 4) Once a suitable number of success reports (e.g. 50) are received and all reported issues are resolved, we'll proceed with importing into CVS. 5) CVS will stay frozen for a period to be evaluated (probably another couple of weeks) to deal with the inevitable remaining fallout as users encounter yet more problems with the upgrade. Do you intend to keep the entire ports tree frozen for weeks? Perhaps I misunderstand? Yes, that is the plan. This is an all hands event, and keeping it frozen is the best way to focus developers onto those tasks. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to prevent make compiling a binary?
On Mon, 07 May 2007 17:05:26 +0200 Stevan Tiefert [EMAIL PROTECTED] mentioned: Hello list, I've tar'ed and gzip'ed a binary library. Put on a web-server. Wrote a Makefile like the Porter's Handbook describes. It fetches the *.tar.gz and so on. But during the make install he asks for a Makefile (I think PORTNAME/work/DISTNAME/Makefile) but there is no Makefile because it is not needed. The library is compiled! I thought the NO_BUILD= yes would be enough. But it seems I need addiotional work. Again: I want to prevent make to search for */work/*/Makefile! Can somebody kick me to the right direction? NO_BUILD should generally work. Could you, please, post the entire Makefile here for us to help you? -- Stanislav Sedov ST4096-RIPE pgpGNOLo4SKnK.pgp Description: PGP signature
irc/unreal won't compile
I'm getting the following when trying to compile unrealircd: Building src /usr/local/bin/ccache gcc -I../include -I/usr/ports/irc/unreal/work/ Unreal3.2/extras/regexp/include -pipe -I/usr/local/include -O2 -pipe -DNO_IDEA -funsigned-char -fno-strict-aliasing -DZIP_LINKS -export- dynamic -L/usr/local/lib -rpath=/usr/lib:/usr/local/lib -c timesynch.c /usr/local/bin/ccache gcc -I../include -I/usr/ports/irc/unreal/work/ Unreal3.2/extras/regexp/include -pipe -I/usr/local/include -O2 -pipe -DNO_IDEA -funsigned-char -fno-strict-aliasing -DZIP_LINKS -export- dynamic -L/usr/local/lib -rpath=/usr/lib:/usr/local/lib -c res.c res.c: In function `m_dns': res.c:718: error: storage size of 'inf' isn't known *** Error code 1 It compiles fine when I untar to my home directory and run the exact same configure as reported by config.log in the ports work directory: ./configure --with-listen=5 --with-dpath=/usr/local/etc/Unreal --with- spath=/usr/local/libexec/ircd --with-nick-history=2000 --with- sendq=300 --with-bufferpool=18 --with-permissions=0600 --with-fd- setsize=1024 --enable-dynamic-linking --enable-hub --enable-ziplinks --enable-ssl I attempted to submit a pr on this with send-pr, but never got a reply back... -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
[FreeBSD port lapack-3.0_2] fails to install libblas.a
I tried to use port 'lapack' and found that many symbols are only in libblas.a that isn't installed. So it should be installed along with libblas.so. Thanx, Yuri ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: irc/unreal won't compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 7 May 2007 14:00:10 -0500 Jim Nasby [EMAIL PROTECTED] wrote: |I'm getting the following when trying to compile unrealircd: | | |I attempted to submit a pr on this with send-pr, but never got a |reply back... not quite correct :). From: Martin Wilke [EMAIL PROTECTED] To: Martin Wilke [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Jim C.Nasby [EMAIL PROTECTED] Subject: Re: ports/112221: irc/unreal won't compile Date: Sun, 29 Apr 2007 08:59:39 +0200 User-Agent: [EMAIL PROTECTED] X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.11; i386-portbld-freebsd7.0) - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jim and Gerrit, ./configure --with-listen=5 --with-dpath=/usr/local/etc/Unreal - - --with-spath=/usr/local/libexec/ircd --with-nick-history=2000 - - --with-sendq=300 --with-bufferpool=18 --with-permissions=0600 - - --with-fd-setsize=1024 --enable-dynamic-linking --enable-hub - --enable-ziplinks --enable-ssl === Building for Unreal-3.2.6 Building src cc -I../include - - -I/usr/ports/irc/unreal/work/Unreal3.2/extras/regexp/include -pipe - - -I/usr/local/include -O2 -pipe -DNO_IDEA -funsigned-char - - -fno-strict-aliasing -DZIP_LINKS -export-dynamic -L/usr/local/lib - -rpath=/usr/lib:/usr/local/lib -c timesynch.c cc -I../include - - -I/usr/ports/irc/unreal/work/Unreal3.2/extras/regexp/include -pipe - - -I/usr/local/include -O2 -pipe -DNO_IDEA -funsigned-char - - -fno-strict-aliasing -DZIP_LINKS -export-dynamic -L/usr/local/lib - -rpath=/usr/lib:/usr/local/lib -c res.c res.c: In function `m_dns': res.c:718: error: storage size of 'inf' isn't known *** Error code 1 Jim we now this problem. Please take a look in the Discussion [1]. This should solved your compielier error. [1] http://lists.freebsd.org/pipermail/freebsd-ports/2007-March/039619.html - - Martin - -- Martin Wilke| irc.unixfreunde.de #bsd [EMAIL PROTECTED] | [EMAIL PROTECTED] FreeBSD Committer | Power to Serve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGP360FwpycAVoI1MRAj8HAJ41zd0yvoHKf7Az4JIqYAg+jqVgWgCdF/iO whC3yoXdg3eR6cZcN8LOLq0= =7H8O -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: irc/unreal won't compile
On Mon, May 07, 2007 at 02:00:10PM -0500, Jim Nasby wrote: I'm getting the following when trying to compile unrealircd: This has been discussed before. Please see the below thread: http://www.mail-archive.com/freebsd-ports@freebsd.org/msg05997.html -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to prevent make compiling a binary?
Am Montag, den 07.05.2007, 20:12 +0400 schrieb Stanislav Sedov: On Mon, 07 May 2007 17:05:26 +0200 Stevan Tiefert [EMAIL PROTECTED] mentioned: Hello list, I've tar'ed and gzip'ed a binary library. Put on a web-server. Wrote a Makefile like the Porter's Handbook describes. It fetches the *.tar.gz and so on. But during the make install he asks for a Makefile (I think PORTNAME/work/DISTNAME/Makefile) but there is no Makefile because it is not needed. The library is compiled! I thought the NO_BUILD= yes would be enough. But it seems I need addiotional work. Again: I want to prevent make to search for */work/*/Makefile! Can somebody kick me to the right direction? NO_BUILD should generally work. Could you, please, post the entire Makefile here for us to help you? -- Stanislav Sedov ST4096-RIPE Thank you for trying helping me. I am very thankfully but with the do-install: -thing is it working!!! :-) I have already posted my port via send-pr. ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Mon, 07 May 2007 13:42:31 -0500, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, May 07, 2007 at 11:38:46AM -0700, Doug Barton wrote: Kris Kennaway wrote: Hi all, After many months of hard work (mostly by flz@, as well as others) we are approaching readiness of the xorg 7.2 upgrade. Because this is a huge and disruptive change, we're going to approach it very carefully. Good news that this is moving forward! Congrats to all involved. The current plan is the following: 2) Final prep work in git repository. We need a day or two to confirm the upgrade method for users. Unfortunately testing has exposed a critical deficiency in portupgrade so 'portupgrade -a' will not be enough to give a working upgrade, and some pre-upgrade steps will be required. Has portmaster been evaluated as an upgrade tool? I'm in a better position atm to be able to address any deficiencies if that will help speed this along. My plan is to run 'portmaster -r pkg-config\*'. I think it should do fine as 'portmaster -r' will do it in order very well. No, at a minimum I am not comfortable recommending its use until it saves old shared libraries across updates (I sent you email about this a while ago), which is a vital safety and robustness mechanism. I am one of people that dislike this and it is not required to get build function. ;-) I think this option should be disable by default, because put stuff in lib/compat/pkg hides the problems. Also: http://www.freebsd.org/gnome/docs/faq2.html#q2 == [...] Prevent two versions of the same library. A common source of build failures is the existence of multiple versions of the same library. This can happen if you have two different versions of a port installed, or can even happen through normal portupgrade use. You can back up the libraries in /usr/local/lib/compat/pkg and remove them, and then run portupgrade -u -rf pkg-config. This will force a rebuild of all GNOME-related apps (and a fair number of other apps) without retaining old versions of libraries in /usr/local/lib/compat/pkg. == Cheers, Mezz Also a post-upgrade step is required to deal with merging remaining files from /usr/X11R6 into /usr/local. 3) Once the proposed upgrade method is in place, we will publish a tarball of the prepared ports tree and request that *all* our ports developers test the upgrade on their own machines before it is committed to CVS. There are many things that can go wrong and we need to make sure that the upgrade goes as smoothly as possible for our less technical users. In particular all ports committers are expected to participate in this process of eating our own dogfood :) Any updates on a timeline for this? Some time this week 4) Once a suitable number of success reports (e.g. 50) are received and all reported issues are resolved, we'll proceed with importing into CVS. 5) CVS will stay frozen for a period to be evaluated (probably another couple of weeks) to deal with the inevitable remaining fallout as users encounter yet more problems with the upgrade. Do you intend to keep the entire ports tree frozen for weeks? Perhaps I misunderstand? Yes, that is the plan. This is an all hands event, and keeping it frozen is the best way to focus developers onto those tasks. Kris -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [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: HEADS UP: xorg upgrade plans
On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote: No, at a minimum I am not comfortable recommending its use until it saves old shared libraries across updates (I sent you email about this a while ago), which is a vital safety and robustness mechanism. I am one of people that dislike this and it is not required to get build function. ;-) I think this option should be disable by default, because put stuff in lib/compat/pkg hides the problems. Also: No, it is required when dealing with shared library bumps (which happen about once a week). Otherwise all of the installed ports using the library break if the new library build fails. Talk to Brooks about how annoying this is with e.g. gettext. http://www.freebsd.org/gnome/docs/faq2.html#q2 == [...] Prevent two versions of the same library. A common source of build failures is the existence of multiple versions of the same library. This can happen if you have two different versions of a port installed, or can even happen through normal portupgrade use. You can back up the libraries in /usr/local/lib/compat/pkg and remove them, and then run portupgrade -u -rf pkg-config. This will force a rebuild of all GNOME-related apps (and a fair number of other apps) without retaining old versions of libraries in /usr/local/lib/compat/pkg. == I dispute the correctness of this entry. The old libraries in lib/compat/pkg are not linked to directly by new builds. The only situation in which something might end up being linked to 2 versions of the library is if it pulls in a library dependency from an existing port that is still linked to the old library. In this situation the build would be broken with or without lib/compat/pkg (in the latter case, you have an installed port linked to a library that is entirely missing, so that port will be nonfunctional). Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Mon, 07 May 2007 15:14:48 -0500, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote: No, at a minimum I am not comfortable recommending its use until it saves old shared libraries across updates (I sent you email about this a while ago), which is a vital safety and robustness mechanism. I am one of people that dislike this and it is not required to get build function. ;-) I think this option should be disable by default, because put stuff in lib/compat/pkg hides the problems. Also: No, it is required when dealing with shared library bumps (which happen about once a week). Otherwise all of the installed ports using the library break if the new library build fails. Talk to Brooks about how annoying this is with e.g. gettext. portmaster has a feature to backup the old package before the upgrade. I think it is better than put in lib/compat/pkg. When I used portupgrade and I always have lib/compat/pkg disabled until I switched to portmaster. I never have that problem when ports tree is flexible enough to downgrade and wait until someone fix it. Cheers, Mezz http://www.freebsd.org/gnome/docs/faq2.html#q2 == [...] Prevent two versions of the same library. A common source of build failures is the existence of multiple versions of the same library. This can happen if you have two different versions of a port installed, or can even happen through normal portupgrade use. You can back up the libraries in /usr/local/lib/compat/pkg and remove them, and then run portupgrade -u -rf pkg-config. This will force a rebuild of all GNOME-related apps (and a fair number of other apps) without retaining old versions of libraries in /usr/local/lib/compat/pkg. == I dispute the correctness of this entry. The old libraries in lib/compat/pkg are not linked to directly by new builds. The only situation in which something might end up being linked to 2 versions of the library is if it pulls in a library dependency from an existing port that is still linked to the old library. In this situation the build would be broken with or without lib/compat/pkg (in the latter case, you have an installed port linked to a library that is entirely missing, so that port will be nonfunctional). Kris -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [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: HEADS UP: xorg upgrade plans
On Mon, May 07, 2007 at 03:35:48PM -0500, Jeremy Messenger wrote: On Mon, 07 May 2007 15:14:48 -0500, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote: No, at a minimum I am not comfortable recommending its use until it saves old shared libraries across updates (I sent you email about this a while ago), which is a vital safety and robustness mechanism. I am one of people that dislike this and it is not required to get build function. ;-) I think this option should be disable by default, because put stuff in lib/compat/pkg hides the problems. Also: No, it is required when dealing with shared library bumps (which happen about once a week). Otherwise all of the installed ports using the library break if the new library build fails. Talk to Brooks about how annoying this is with e.g. gettext. portmaster has a feature to backup the old package before the upgrade. I think it is better than put in lib/compat/pkg. When I used portupgrade and I always have lib/compat/pkg disabled until I switched to portmaster. I never have that problem when ports tree is flexible enough to downgrade and wait until someone fix it. Well, is this feature enabled by default and does it completely back out the upgrade if it fails? I may be wrong, but I doubt it is going to do a complete recursive backout of the upgrade if e.g. one of the ports depending on the new library fails to build after the library was updated. If it just restores the old version of this port then it will be restoring a nonfunctional port, since it links to the version of the library that was already deleted. The issue is about providing seat-belts for our users who just want failed upgrades not to destroy their system. Even if you think that backing up the package is a better solution than preserving the shared libraries, it seems to me that portmaster still falls short here because it doesn't provide a rollback mechanism to restore the system to a working state when an upgrade fails. I dispute the correctness of this entry. The old libraries in lib/compat/pkg are not linked to directly by new builds. The only situation in which something might end up being linked to 2 versions of the library is if it pulls in a library dependency from an existing port that is still linked to the old library. In this situation the build would be broken with or without lib/compat/pkg (in the latter case, you have an installed port linked to a library that is entirely missing, so that port will be nonfunctional). Kris I guess your silence means you agree with me here :) Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Mon, May 07, 2007 at 04:44:14PM -0400, Kris Kennaway wrote: On Mon, May 07, 2007 at 03:35:48PM -0500, Jeremy Messenger wrote: On Mon, 07 May 2007 15:14:48 -0500, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote: No, at a minimum I am not comfortable recommending its use until it saves old shared libraries across updates (I sent you email about this a while ago), which is a vital safety and robustness mechanism. I am one of people that dislike this and it is not required to get build function. ;-) I think this option should be disable by default, because put stuff in lib/compat/pkg hides the problems. Also: No, it is required when dealing with shared library bumps (which happen about once a week). Otherwise all of the installed ports using the library break if the new library build fails. Talk to Brooks about how annoying this is with e.g. gettext. portmaster has a feature to backup the old package before the upgrade. I think it is better than put in lib/compat/pkg. When I used portupgrade and I always have lib/compat/pkg disabled until I switched to portmaster. I never have that problem when ports tree is flexible enough to downgrade and wait until someone fix it. Well, is this feature enabled by default and does it completely back out the upgrade if it fails? I may be wrong, but I doubt it is going to do a complete recursive backout of the upgrade if e.g. one of the ports depending on the new library fails to build after the library was updated. If it just restores the old version of this port then it will be restoring a nonfunctional port, since it links to the version of the library that was already deleted. The issue is about providing seat-belts for our users who just want failed upgrades not to destroy their system. Even if you think that backing up the package is a better solution than preserving the shared libraries, it seems to me that portmaster still falls short here because it doesn't provide a rollback mechanism to restore the system to a working state when an upgrade fails. For a number of failure modes, the use of pkg_create -b can't do this. In particularly, pkg_create -b can't ignore missing files (because tar can't in turn) so you can't make a package of anything with a missing file. The latest versions of portmaster allow you to ignore this error by default since it's not as if there's anything else you could do, but in that situation there's no backing out. Fixing pkg_create would help here. The other problem is that if you're going to automatically update all the dependencies for a port, you need to upgrade all the stuff that depends on them as well. For example the gettext upgrade got triggered on my laptop by upgrading something the used gmake. The result was that virtually nothing outside the base worked any more. Saving the shared library would have prevented this and allowed a more graceful upgrade over a few weeks. The fact that a basic desktop setup takes days to build on fairly fast hardware seems to be an indication that we need a workaround here. There are other possible solutions, but saving copied of libraries seems to be the accepted one at the moment. -- Brooks pgpW9BCsehkrk.pgp Description: PGP signature
Problem running acroread7 on 6.2
I just installed acroread7-7.0.9,1 from ports on a new FreeBSD 6.2-p3 system. It will not run, when I attempt to run it from the command line, I get the following error: :~ acroread ELF binary type 3 not known. ldconfig: illegal option -- p usage: ldconfig [-32] [-aout | -elf] [-Rimrsv] [-f hints_file] [directory | file ...] ELF binary type 3 not known. /usr/X11R6/Adobe/Acrobat7.0/ENU/Reader/intellinux/bin/acroread: 1: Syntax error: ( unexpected :~ Any ideas? did I miss a compile time option during the install? Thanks Jeff ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem running acroread7 on 6.2
On Mon 07 May 2007 13:05, Jeffrey Williams wrote: I just installed acroread7-7.0.9,1 from ports on a new FreeBSD 6.2-p3 system. It will not run, when I attempt to run it from the command line, I get the following error: :~ acroread ELF binary type 3 not known. ldconfig: illegal option -- p usage: ldconfig [-32] [-aout | -elf] [-Rimrsv] [-f hints_file] [directory | file ...] ELF binary type 3 not known. /usr/X11R6/Adobe/Acrobat7.0/ENU/Reader/intellinux/bin/acroread: 1: Syntax error: ( unexpected :~ Any ideas? did I miss a compile time option during the install? Thanks Jeff Do you have Linux compatibility enabled? To enable it, add this to your /etc/rc.conf: linux_enable=yes And this to your /boot/loader.conf (Create the file if it doesn't exists yet) linux_load=YES To start it manually (without rebooting): kldload linux sh /etc/rc.d/abi start -- Regards, Martin Tournoij ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Mon, 07 May 2007 15:44:14 -0500, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, May 07, 2007 at 03:35:48PM -0500, Jeremy Messenger wrote: On Mon, 07 May 2007 15:14:48 -0500, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote: No, at a minimum I am not comfortable recommending its use until it saves old shared libraries across updates (I sent you email about this a while ago), which is a vital safety and robustness mechanism. I am one of people that dislike this and it is not required to get build function. ;-) I think this option should be disable by default, because put stuff in lib/compat/pkg hides the problems. Also: No, it is required when dealing with shared library bumps (which happen about once a week). Otherwise all of the installed ports using the library break if the new library build fails. Talk to Brooks about how annoying this is with e.g. gettext. portmaster has a feature to backup the old package before the upgrade. I think it is better than put in lib/compat/pkg. When I used portupgrade and I always have lib/compat/pkg disabled until I switched to portmaster. I never have that problem when ports tree is flexible enough to downgrade and wait until someone fix it. Well, is this feature enabled by default and does it completely back out the upgrade if it fails? Default.. I am not sure, but I just know that there has option and I have disable backup in my configure. As for the second question, no, I don't think it doesn't. The users have to do it by manual to reinstall it. Correct me if I am wrong. [read other replied from Brooks] Brooks said that pkg_create has problems that need to be solve. I guess, it has shoot this down. I may be wrong, but I doubt it is going to do a complete recursive backout of the upgrade if e.g. one of the You are right, it doesn't. I don't think it will be easy to add this feature. ports depending on the new library fails to build after the library was updated. If it just restores the old version of this port then it will be restoring a nonfunctional port, since it links to the version of the library that was already deleted. I think it is rare and will get fix quickly (most of time). It shows real problem rather than hide it by using old library. This is what I like it. It helps our package to be more stable in both build and runtime. The issue is about providing seat-belts for our users who just want failed upgrades not to destroy their system. Even if you think that backing up the package is a better solution than preserving the shared libraries, Yes, I think backing up is a better solution. For example, when library has been bumped but also the plugins, format of configure file or whatever have been complete revamp. The lib/compat/pkg won't help and the backup will. As Brooks said, 'There are other possible solutions, but saving copied of libraries seems to be the accepted one at the moment.' The 'accepted' is opposite for me. It's why I am suggesting to disable it by default if someone is going to add it in portmaster for any users that don't want or have time to help. ;-) it seems to me that portmaster still falls short here because it doesn't provide a rollback mechanism to restore the system to a working state when an upgrade fails. I dispute the correctness of this entry. The old libraries in lib/compat/pkg are not linked to directly by new builds. The only situation in which something might end up being linked to 2 versions of the library is if it pulls in a library dependency from an existing port that is still linked to the old library. In this situation the build would be broken with or without lib/compat/pkg (in the latter case, you have an installed port linked to a library that is entirely missing, so that port will be nonfunctional). Kris I guess your silence means you agree with me here :) Yeah, I guess and unsure at the same time since I didn't write this entry. :-) Cheers, Mezz Kris -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [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: HEADS UP: xorg upgrade plans
Le Lun 7 mai 07 à 22:58:50 +0200, Brooks Davis [EMAIL PROTECTED] écrivait : The other problem is that if you're going to automatically update all the dependencies for a port, you need to upgrade all the stuff that depends on them as well. For example the gettext upgrade got triggered on my laptop by upgrading something the used gmake. The result was that virtually nothing outside the base worked any more. Saving the shared library would have prevented this and allowed a more graceful upgrade over a few weeks. The fact that a basic desktop setup takes days to build on fairly fast hardware seems to be an indication that we need a workaround here. There are other possible solutions, but saving copied of libraries seems to be the accepted one at the moment. For this kind of upgrades, it's possible to add libgettextpo.so.1 libgettextpo.so.3 libintl.so.6libintl.so.8 in your /etc/libmap.conf. Just delete these lines after the storm... -- Th. Thomas. pgpcLe3529wST.pgp Description: PGP signature
Re: HEADS UP: xorg upgrade plans
On Tue, May 08, 2007 at 12:06:59AM +0200, Thierry Thomas wrote: Le Lun 7 mai 07 ? 22:58:50 +0200, Brooks Davis [EMAIL PROTECTED] ?crivait?: The other problem is that if you're going to automatically update all the dependencies for a port, you need to upgrade all the stuff that depends on them as well. For example the gettext upgrade got triggered on my laptop by upgrading something the used gmake. The result was that virtually nothing outside the base worked any more. Saving the shared library would have prevented this and allowed a more graceful upgrade over a few weeks. The fact that a basic desktop setup takes days to build on fairly fast hardware seems to be an indication that we need a workaround here. There are other possible solutions, but saving copied of libraries seems to be the accepted one at the moment. For this kind of upgrades, it's possible to add libgettextpo.so.1 libgettextpo.so.3 libintl.so.6 libintl.so.8 in your /etc/libmap.conf. Just delete these lines after the storm... I did found out too late that it works in this case, but it's not a general solution since it only works if the bump was pointless and thus there aren't prototype mismatches. -- Brooks pgpg9rU33rfws.pgp Description: PGP signature
Re: HEADS UP: xorg upgrade plans
On Tue, May 08, 2007 at 12:06:59AM +0200, Thierry Thomas wrote: Le Lun 7 mai 07 ? 22:58:50 +0200, Brooks Davis [EMAIL PROTECTED] ?crivait?: The other problem is that if you're going to automatically update all the dependencies for a port, you need to upgrade all the stuff that depends on them as well. For example the gettext upgrade got triggered on my laptop by upgrading something the used gmake. The result was that virtually nothing outside the base worked any more. Saving the shared library would have prevented this and allowed a more graceful upgrade over a few weeks. The fact that a basic desktop setup takes days to build on fairly fast hardware seems to be an indication that we need a workaround here. There are other possible solutions, but saving copied of libraries seems to be the accepted one at the moment. For this kind of upgrades, it's possible to add libgettextpo.so.1 libgettextpo.so.3 libintl.so.6 libintl.so.8 in your /etc/libmap.conf. Just delete these lines after the storm... It is possible, but this is not something that non-technical users will think of (nor should they have to). The question is whether portmaster is to be considered as a tool for advanced users only (those who are capable of cleaning up and repairing damage themselves when an upgrade fails), or if it is intended as a tool for ordinary users who don't want to (or are not capable of) doing this kind of manual repair work. If the goal is the former, then that's OK, but if it is the latter, then an honest evaluation leads one to conclude that portmaster is still in the process of maturing towards achieving this goal. Kris pgp0Jm7l6IJZa.pgp Description: PGP signature
Re: HEADS UP: xorg upgrade plans
On Mon, 2007-05-07 at 18:26 -0400, Kris Kennaway wrote: I dispute the correctness of this entry. The old libraries in lib/compat/pkg are not linked to directly by new builds. The only situation in which something might end up being linked to 2 versions of the library is if it pulls in a library dependency from an existing port that is still linked to the old library. In this situation the build would be broken with or without lib/compat/pkg (in the latter case, you have an installed port linked to a library that is entirely missing, so that port will be nonfunctional). Kris I guess your silence means you agree with me here :) Yeah, I guess and unsure at the same time since I didn't write this entry. :-) OK. I didn't write it either, but it holds some truth. Yes, not having the library at all would cause a build failure, but having multiple versions of the same library can lead to runtime failures. It's much easier to troubleshoot a missing .so that it is to hunt down strange runtime failures (usually). I'm not arguing for or against portmaster, or the keeping old shared objects functionality. I'm just putting this FAQ entry in context. Yes, perhaps it could be re-worded for clarity. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
HEADS UP: xorg upgrade plans
Ok, no worries then. I have no plans to add that feature at this time, partly because there has been no user demand for it, and mostly because I don't like the idea. I recognize however that reasonable minds may differ on that topic. if you don't like the idea, that's fine, but since you say there's been no user demand, i just thought i should note that I tried portmaster a few months ago. while there were things i like, i ultimately switched back to portupgrade specifically because it lacked old library preservation. /brian Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: games/sauerbraten
Sam Stein wrote: There is a new version out; the port has an old one, the new version works fine; I've emailed the maintainer twice; no reply.. what should I do now? Submit a PR and request a maintainer timeout. This will take a long time, but it's the only way. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
Brian Gruber wrote: Ok, no worries then. I have no plans to add that feature at this time, partly because there has been no user demand for it, and mostly because I don't like the idea. I recognize however that reasonable minds may differ on that topic. if you don't like the idea, that's fine, but since you say there's been no user demand, i just thought i should note that I tried portmaster a few months ago. while there were things i like, i ultimately switched back to portupgrade specifically because it lacked old library preservation. /brian Just a thought, but have people considered pushing nVidia and (gasp), maybe ATI for driver support in 7.2? I would think that AMD would at least consider FreeBSD if we moved to 7.2 because it seems like they want to get on the bandwagon with more recent versions of Linux nowadays with their OpenGL driver support. Cheers, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
