Gnucash slow startup on FreeBSD 7.1
Hi, I recently installed GnuCash 2.2.7, guile 1.8.5, slib 3a4, and libtool 1.5.26, libltdl ? (all the latest ports cvsup) on FreeBSD 7.1 on an Acer Aspire 1680 (laptop). When I start gnucash, it then takes a VERY long time (~2 minutes) before I see the gnucash tip of the day and intro image. The tip of the day then takes another ~1 minute before it will respond to a mouse-click. If I remove my network connection, it takes an as yet undetermined amount of time to start (>6 minutes). After a little googling, it seems that slow startup was a known problem on earlier versions of FreeBSD, but one which should have been fixed with the patches that came with the port. When I run tross -o gnucash_startup gnucash cat gnucash_startup | grep ERR with the network attached, I see that gnucash runs through a list of directories several times (around 30), looking for the files libswigrun.so, libswigrun.la, swigrun, and swigrun.scm, none of which exist on my system according to locate (with a new locate.database). Could this be the source of my problem? Any help would be heartily appreciated. Thanks, Tony ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
> As a general note, this is the second time in a row that an X.org > upgrade broke X for a significant number of people. IMO, this > suggests that our approach to X.org upgrades needs significant changes > (see below). X11 is a critical component for anyone who is using > FreeBSD as a desktop and having upgrades fail or come with significant > POLA violations and regressions for significant numbers of people is > not acceptable. > you took the words out of my mouth! Some days ago, I compiled wine from ports, among its dependencies was cups(why in the name of G_D?), and x11-xcb (which did not ring any special bells - stupidly I thought it meant some x11 cut buffer gizmo :-) Anyways, next day, I couldn't open windows (x11 not MS) from some hosts, some debuging later, it was xauth failing. Now xcb did ring bells! A year ago we found a bug in libxcb, where the treatment of xauth was broken, we sent a patch, but it is still waiting. BTW, I opend a PR, http://www.freebsd.org/cgi/query-pr.cgi?pr=131120, where it's now going the way the salmon, up stream, waiting for some kind sole to apply it. > On 2009-Jan-29 08:40:11 -0500, Robert Noland wrote: > >I've had patches available for probably a couple of months now posted to > >freebsd-...@. For the few people who tested it, I had no real issues > >reported. > > I didn't recall seeing any reference to patches so I went looking. > All I could find is a couple of references to a patchset existing > buried inside threads discussing specific problems with X. The > majority of people who didn't have those specific problems probably > skipped the thread and never saw that a patchset was available. > > When the X.org 7.0 upgrade was planned, a heads-up went out on a > number of mailing lists, together with a pointer to the patchset and > upgrade instructions and the upgrade did not proceed until both a > reasonable number of people reported success and reported problems had > been ironed out. Given the ongoing problems with code provided by > X.org, I suggest that this approach needs to be followed for every > future release of X.org until (if) the X.org Project demonstrates that > they can provide release-quality code. > > > This update also brings in support for a > >lot of people who are running newer hardware. > > And breaks support for lots of people who used to have functional > X servers. > merging /usr/X11R6 into /usr/local was a bad idea! cheers, danny > --=20 > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > > --+1TulI7fc0PCHNy3 > Content-Type: application/pgp-signature > Content-Disposition: inline > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.10 (FreeBSD) > > iEYEARECAAYFAkmDWqcACgkQ/opHv/APuIdisQCgogeNZ8aXPDJ3gcZ/23Gyp/CV > bmsAn0efyI9cS6TWGFkofoYh6oFmtc5l > =i2p0 > -END PGP SIGNATURE- > > --+1TulI7fc0PCHNy3-- > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
firefox[2,3] will not start after recent ports upgrade
Hi, after recent port upgrade firefox2 and firefox3 do not work anymore. When I start any of them nothing happens, no error message or window appears. # ps -aux|grep firefox USER 36787 0.0 0.1 7060 1388 ?? I12:02PM 0:00.00 /bin/sh -c firefox3 USER 36788 0.0 0.1 7060 1468 ?? I12:02PM 0:00.00 /bin/sh /usr/local/bin/firefox3 USER 36792 0.0 0.1 7060 1508 ?? I12:02PM 0:00.00 /bin/sh /usr/local/lib/firefox3/run-mozilla.sh /usr/local/lib/firefox3/firefox-bin USER 36797 0.0 0.9 120932 17732 ?? I12:02PM 0:00.07 /usr/local/lib/firefox3/firefox-bin Seem something is hanging, so "killall firefox-bin" will clean memory quietly. I have this effect on two amd64 machines (FreeBSD 7.1-PRERELEAS). One machine has almost all ports up to date, on another just few are updated. At the same time linux-firefox works fine. Recompilation/reinstall of firefox2,3 couple of times did not solved problem. I removed .mozilla/ from home folder hoping that there is a problem with profile, but still no luck. I tried to debug with ktrace but last wait4 (0x,0x7fffe1ac,WUNTRACED,0) call does not say much to me, please see ktraces for both firefox 2 & 3 respectively: http://daemon.nanophys.kth.se/~kono/ktrace_ff2.txt http://daemon.nanophys.kth.se/~kono/ktrace_ff3.txt ... and list of installed ports (from machine with almost all ports updated): http://daemon.nanophys.kth.se/~kono/ports.list I wonder if only me got this trouble, any suggestions? /Alexander Konovalenko ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: firefox[2,3] will not start after recent ports upgrade
Alexander Konovalenko wrote: > Hi, > > after recent port upgrade firefox2 and firefox3 do not work anymore. > When I start any of them nothing happens, no error message or window > appears. Is it only Firefox or maybe other GTK2 apps are also affected? I've run into similar problem after January 14th Gnome/GTK+ update, which was acutally my fault, as I haven't upgraded it properly. Recompiling Firefox along with the ports it depends on did the trick: portupgrade -Rf firefox -- Cezary Morga "Dreams age faster than dreamers" (Stephen King) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
x11/nvidia-driver does not compile on current
On FreeBSD 8.0-CURRENT from today with up to date Xorg I am not able to compile x11/nvidia-driver any more: - /usr/ports/x11/nvidia-driver#make ===> Vulnerability check disabled, database not found ===> Found saved configuration for nvidia-driver-177.80 ===> Extracting for nvidia-driver-177.80 => MD5 Checksum OK for NVIDIA-FreeBSD-x86-177.80.tar.gz. => SHA256 Checksum OK for NVIDIA-FreeBSD-x86-177.80.tar.gz. ===> Patching for nvidia-driver-177.80 ===> Applying FreeBSD patches for nvidia-driver-177.80 ===> nvidia-driver-177.80 depends on shared library: X11.6 - found ===> nvidia-driver-177.80 depends on shared library: m.3 - found ===> nvidia-driver-177.80 depends on shared library: GL.1 - found ===> Configuring for nvidia-driver-177.80 ===> Building for nvidia-driver-177.80 ===> src (all) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"177.80\" -D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c nvidia_ctl.c cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"177.80\" -D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c nvidia_dev.c nvidia_dev.c: In function 'nvidia_dev_open': nvidia_dev.c:43: error: invalid operands to binary & nvidia_dev.c: In function 'nvidia_dev_close': nvidia_dev.c:68: error: invalid operands to binary & nvidia_dev.c: In function 'nvidia_dev_ioctl': nvidia_dev.c:91: error: invalid operands to binary & nvidia_dev.c: In function 'nvidia_dev_poll': nvidia_dev.c:115: error: invalid operands to binary & nvidia_dev.c: In function 'nvidia_dev_mmap': nvidia_dev.c:149: error: invalid operands to binary & *** Error code 1 Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-177.80/src. *** Error code 1 Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-177.80. *** Error code 1 Stop in /usr/ports/x11/nvidia-driver. *** Error code 1 Stop in /usr/ports/x11/nvidia-driver. - Obviously there is something wrong with nvidia_dev.c, perhaps a header file has to adapt on newest current or xorg? Let me know, if I can send more information or test something. Any help is appreciated. Many thanks, Rainer Hurling ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Xorg upgrade desaster: Xlib: extension "Generic Event Extension" missing on display ":0.0".
On Fri, 2009-01-30 at 18:23 -0500, Alex Goncharov wrote: > ,--- You/O. (Fri, 30 Jan 2009 23:19:41 +0100) * > | After upgrading one of my FreeBSD 8.0-CUR/amd64 boxes to new xorg-7.4 > | and having done hurting recompiling nearly everything/package twice now > | firefox3 still doesn't work properly and hits me when starting with this > | error message: > | > | Xlib: extension "Generic Event Extension" missing on display ":0.0". > > Interesting -- I just did my comprehensive upgrade, as a part of which > xorg-server went from 1.5.3_1,1 to 1.5.3_2,1. > > And this is what I see now, for the first time, and consistently: > > > $ xterm& > [3] 12585 > > $ emacs & > [4] 12644 > Xlib: extension "Generic Event Extension" missing on display ":0.0". > Xlib: extension "Generic Event Extension" missing on display ":0.0". > Xlib: extension "Generic Event Extension" missing on display ":0.0". > Xlib: extension "Generic Event Extension" missing on display ":0.0". > Xlib: extension "Generic Event Extension" missing on display ":0.0". > Xlib: extension "Generic Event Extension" missing on display ":0.0". This is harmless, it indicates that libXext has support for generic events, but the server does not yet. robert. > > > The garbage still pollutes my windows periodically, so, I guess, my > next xorg-server will be 1.4. > > For reference, my system is: > >i386 FreeBSD 7.1-STABLE Sun Jan 25 06:28:38 EST 2009 > > It not being CURRENT, I took the liberty of cc: freebsd-po...@freebsd.org. > > -- Alex -- alex-goncha...@comcast.net -- > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: firefox[2,3] will not start after recent ports upgrade
Alexander Konovalenko 2009-01-31: > after recent port upgrade firefox2 and firefox3 do not work anymore. When I > start any of them nothing happens, no error message or window appears. > > # ps -aux|grep firefox > USER 36787 0.0 0.1 7060 1388 ?? I12:02PM 0:00.00 /bin/sh -c > firefox3 > USER 36788 0.0 0.1 7060 1468 ?? I12:02PM > 0:00.00 /bin/sh /usr/local/bin/firefox3 > USER 36792 0.0 0.1 7060 1508 ?? I12:02PM > 0:00.00 /bin/sh /usr/local/lib/firefox3/run-mozilla.sh > /usr/local/lib/firefox3/firefox-bin > USER 36797 0.0 0.9 120932 17732 ?? I12:02PM > 0:00.07 /usr/local/lib/firefox3/firefox-bin > > Seem something is hanging, so "killall firefox-bin" will clean memory quietly. Could it be the case that firefox-bin hangs in umtxn state? (Check using ps -laux instead of -aux) > I have this effect on two amd64 machines (FreeBSD 7.1-PRERELEAS). One > machine > has almost all ports up to date, on another just few are updated. At the same > time linux-firefox works fine. > > Recompilation/reinstall of firefox2,3 couple of times did not solved problem. > I removed .mozilla/ from home folder hoping that there is a problem with > profile, but still no luck. > > I tried to debug with ktrace but last wait4 > (0x,0x7fffe1ac,WUNTRACED,0) call does not say much to me, please > see ktraces for both firefox 2 & 3 respectively: > > http://daemon.nanophys.kth.se/~kono/ktrace_ff2.txt > http://daemon.nanophys.kth.se/~kono/ktrace_ff3.txt These trace the wrong process: the wrapper shell script (sh). The actual hanging process would be firefox-bin, not sh. Try ktracing with child processes (-i). > ... and list of installed ports (from machine with almost all ports updated): > http://daemon.nanophys.kth.se/~kono/ports.list > > I wonder if only me got this trouble, any suggestions? -- Daniel Roethlisberger http://daniel.roe.ch/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
libssh2 upgrade error
While portupgrading libssh2, sources csuped immediately before this error a few minutes ago: configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating include/libssh2_config.h ===> Building for libssh2-0.2,1 cc -o channel.o channel.c -c -O2 -fno-strict-aliasing -pipe -I/usr/include -I/usr/include -Wall -g -I../include/ -fPIC In file included from channel.c:38: ../include/libssh2_priv.h:181: error: 'MD5_DIGEST_LENGTH' undeclared here (not in a function) ../include/libssh2_priv.h:184: error: 'SHA_DIGEST_LENGTH' undeclared here (not in a function) channel.c: In function 'libssh2_channel_direct_tcpip_ex': channel.c:230: warning: pointer targets in passing argument 6 of 'libssh2_channel_open_ex' differ in signedness *** Error code 1 Nothing relevant that I saw in /usr/ports/UPDATING # uname -a FreeBSD www 7.1-STABLE FreeBSD 7.1-STABLE #2: Tue Jan 6 19:24:57 EST 2009 r...@www:/usr/obj/usr/src/sys/DELL64 amd64 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
sane-backends and hplip broken on -current
Seems that both are trying to reference something that's been recently removed :-( cc -c -O2 -pipe -march=prescott -fno-strict-aliasing -W -Wall -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I/usr/local/include -D_REENTRANT -DPATH_SANE_CONFIG_DIR=/usr/local/etc/sane.d -DPATH_SANE_DATA_DIR=/usr/local/share -DPATH_SANE_LOCK_DIR=/usr/local/var/lock/sane -DV_MAJOR=1 -DV_MINOR=0 -DBACKEND_NAME=umax_pp_low -DLIBDIR=/usr/local/lib/sane umax_pp_low.c -fPIC -DPIC -o .libs/umax_pp_low.o In file included from umax_pp_low.c:74: /usr/include/dev/ppbus/ppbconf.h:202: error: expected specifier-qualifier-list before 'driver_intr_t' /usr/include/dev/ppbus/ppbconf.h:244: error: expected specifier-qualifier-list before 'device_t' umax_pp_low.c: In function 'sanei_umax_pp_initPort': umax_pp_low.c:956: warning: unused variable 'rc' umax_pp_low.c:956: warning: unused variable 'modes' umax_pp_low.c:956: warning: unused variable 'mode' umax_pp_low.c:953: warning: unused variable 'ectr' gmake[1]: *** [umax_pp_low.lo] Error 1 gmake[1]: Leaving directory `/usr/ports/graphics/sane-backends/work/sane-backends-1.0.19/backend' gmake: *** [all-recursive] Error 1 *** Error code 2 Stop in /usr/ports/graphics/sane-backends. *** Error code 1 Stop in /usr/ports/graphics/sane-backends. *** Error code 1 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
libssh2 upgrade error
Tim Kellers writes: > While portupgrading libssh2, sources csuped immediately before this > error a few minutes ago: > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating src/Makefile > config.status: creating include/libssh2_config.h > ===> Building for libssh2-0.2,1 > cc -o channel.o channel.c -c -O2 -fno-strict-aliasing -pipe > -I/usr/include -I/usr/include -Wall -g -I../include/ -fPIC > In file included from channel.c:38: > ../include/libssh2_priv.h:181: error: 'MD5_DIGEST_LENGTH' undeclared > here (not in a function) > ../include/libssh2_priv.h:184: error: 'SHA_DIGEST_LENGTH' undeclared > here (not in a function) > channel.c: In function 'libssh2_channel_direct_tcpip_ex': > channel.c:230: warning: pointer targets in passing argument 6 of > 'libssh2_channel_open_ex' differ in signedness > *** Error code 1 I'm getting: ===> Building for libssh2-0.2,1 cc -o channel.o channel.c -c -O -pipe -g -march=pentium4 -I/usr/local/include -I/usr/include -Wall -g -I../include/ -fPIC In file included from channel.c:38: ../include/libssh2_priv.h:181: error: 'MD5_DIGEST_LENGTH' undeclared here (not in a function) ../include/libssh2_priv.h:184: error: 'SHA_DIGEST_LENGTH' undeclared here (not in a function) channel.c: In function 'libssh2_channel_direct_tcpip_ex': channel.c:230: warning: pointer targets in passing argument 6 of 'libssh2_channel_open_ex' differ in signedness *** Error code 1 Robert Huff ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: libssh2 upgrade error
On 01/31/2009 02:35 PM Tim Kellers wrote: While portupgrading libssh2, sources csuped immediately before this error a few minutes ago: configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating include/libssh2_config.h ===> Building for libssh2-0.2,1 cc -o channel.o channel.c -c -O2 -fno-strict-aliasing -pipe -I/usr/include -I/usr/include -Wall -g -I../include/ -fPIC In file included from channel.c:38: ../include/libssh2_priv.h:181: error: 'MD5_DIGEST_LENGTH' undeclared here (not in a function) ../include/libssh2_priv.h:184: error: 'SHA_DIGEST_LENGTH' undeclared here (not in a function) channel.c: In function 'libssh2_channel_direct_tcpip_ex': channel.c:230: warning: pointer targets in passing argument 6 of 'libssh2_channel_open_ex' differ in signedness *** Error code 1 Nothing relevant that I saw in /usr/ports/UPDATING I had the same error. The patch-libssh2_priv.h file didn't make it into my ports tree yet - at least via portsnap. http://www.freebsd.org/cgi/cvsweb.cgi/ports/security/libssh2/files/?f=h#dirlist If you add the files directory and that file, it builds and upgrades with no errors. Ron Wilhoite ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
On Fri Jan 30 11:53:16 PST 2009, Peter Jeremy wrote: >As a general note, this is the second time in a row that an X.org >upgrade broke X for a significant number of people. IMO, this >suggests that our approach to X.org upgrades needs significant changes >(see below). X11 is a critical component for anyone who is using >FreeBSD as a desktop and having upgrades fail or come with significant >POLA violations and regressions for significant numbers of people is >not acceptable. The problem isn't so much as a problem with xorg updates as it is with the overall port approach. Not having a stable versus current ports approach is probably the biggest cause of the problems seen here. The port freezes don't help either. In general when upgrading, you take your chances. If a port upgrade fails, you should fall back to what worked. Trying to partial rebuild ports versus rebuilding from scratch after a major update is just asking for problems. There probably needs to be a more incremental approach when upgrading major ports. For example, I updated my system a piece at a time over the last several months, and had no significant problems with the offical x11 upgrade as the changes were small. And last, many of the video drivers have little if any support. If you have something other then ati/intel/nivdia, you should expect problems. Input drivers are in a similar state. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- You/vehemens (Sat, 31 Jan 2009 11:53:58 -0800) * | In general when upgrading, you take your chances. If a port upgrade | fails, you should fall back to what worked. So, a *fundamental* (practically an OS component) port is brought in -- and it disables my system. What is my way of action? Right -- install the old packages, taken from an FTP site (is there a way to get the previous "source", that is all the ports/*/*/Makefile files? Csup can only go forward -- or can it go back?) When I install the old packages, I can no longer rebuild and install new (say `csup'ed on 2009-03-01) port components, as one whole -- I can only do it selectively, excluding from the upgrade most X-dependent things. That sucks and will lead to a problem earlier or later. | Trying to partial rebuild ports versus rebuilding from scratch after | a major update is just asking for problems. Exactly -- but I haven't done this -- and I have big problems with the new X. | There probably needs to be a more incremental approach when | upgrading major ports. For example, I updated my system a piece at | a time over the last several months, and had no significant problems | with the offical x11 upgrade as the changes were small. I've been rebuilding and reinstalling ports every weekend, for about 1.5 years -- with no problem until the last one, when the new X was in. | And last, many of the video drivers have little if any support. If | you have something other then ati/intel/nivdia, you should expect | problems. Input drivers are in a similar state. Both my systems I've been reporting problems with are using the `nv' driver: $ grep /modules/drivers /var/log/Xorg.0.log (II) Loading /usr/local/lib/xorg/modules/drivers//nv_drv.so One system (Dell Latitude) could not be made operational with the new X at all; the other has garbage in the windows and the "captive mouse pointer" -- both issues new in the new X. -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
On Saturday 31 January 2009 01:25:21 pm Alex Goncharov wrote: > ,--- You/vehemens (Sat, 31 Jan 2009 11:53:58 -0800) * > > | In general when upgrading, you take your chances. If a port upgrade > | fails, you should fall back to what worked. > > So, a *fundamental* (practically an OS component) port is brought in > -- and it disables my system. What is my way of action? Right -- > install the old packages, taken from an FTP site (is there a way to > get the previous "source", that is all the ports/*/*/Makefile files? > Csup can only go forward -- or can it go back?) You ignored the first part of the email which is that the ports system is flawed due to the lack of a stable versus current branch. It seems to me that you want to run a stable branch, while the ports tree is effectively a current branch. > When I install the old packages, I can no longer rebuild and install > new (say `csup'ed on 2009-03-01) port components, as one whole -- I > can only do it selectively, excluding from the upgrade most > X-dependent things. That sucks and will lead to a problem earlier or > later. I never update /usr/ports directly. I have a separate csup ports area. When I update, I save the old ports tree and replace it with a new one. If a problem occurs, I can fall back to the old tree or pieces of it. > | Trying to partial rebuild ports versus rebuilding from scratch after > | a major update is just asking for problems. > > Exactly -- but I haven't done this -- and I have big problems with the > new X. > > | There probably needs to be a more incremental approach when > | upgrading major ports. For example, I updated my system a piece at > | a time over the last several months, and had no significant problems > | with the offical x11 upgrade as the changes were small. > > I've been rebuilding and reinstalling ports every weekend, for about > 1.5 years -- with no problem until the last one, when the new X was > in. Well, it depends on which ports you are updating. If you only run X, then I would expect your statement to be correct. > | And last, many of the video drivers have little if any support. If > | you have something other then ati/intel/nivdia, you should expect > | problems. Input drivers are in a similar state. > > Both my systems I've been reporting problems with are using the `nv' > driver: > > $ grep /modules/drivers /var/log/Xorg.0.log > (II) Loading /usr/local/lib/xorg/modules/drivers//nv_drv.so > > One system (Dell Latitude) could not be made operational with the new > X at all; the other has garbage in the windows and the "captive mouse > pointer" -- both issues new in the new X. See above :) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: libssh2 upgrade error
Ron Wilhoite wrote: On 01/31/2009 02:35 PM Tim Kellers wrote: While portupgrading libssh2, sources csuped immediately before this error a few minutes ago: configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating include/libssh2_config.h ===> Building for libssh2-0.2,1 cc -o channel.o channel.c -c -O2 -fno-strict-aliasing -pipe -I/usr/include -I/usr/include -Wall -g -I../include/ -fPIC In file included from channel.c:38: ../include/libssh2_priv.h:181: error: 'MD5_DIGEST_LENGTH' undeclared here (not in a function) ../include/libssh2_priv.h:184: error: 'SHA_DIGEST_LENGTH' undeclared here (not in a function) channel.c: In function 'libssh2_channel_direct_tcpip_ex': channel.c:230: warning: pointer targets in passing argument 6 of 'libssh2_channel_open_ex' differ in signedness *** Error code 1 Nothing relevant that I saw in /usr/ports/UPDATING I had the same error. The patch-libssh2_priv.h file didn't make it into my ports tree yet - at least via portsnap. http://www.freebsd.org/cgi/cvsweb.cgi/ports/security/libssh2/files/?f=h#dirlist If you add the files directory and that file, it builds and upgrades with no errors. Ron Wilhoite Thank you. That absolutely was it. I just re-csuped and that was the only file added: www# csup -L 2 /etc/cvsupfile & [1] 657 www# Parsing supfile "/etc/cvsupfile" Connecting to cvsup8.FreeBSD.org Connected to 128.205.32.21 Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Updating collection ports-all/cvs Checkout ports/security/libssh2/files/patch-libssh2_priv.h Updating collection doc-all/cvs Shutting down connection to server Finished successfully ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
trying out xfce 4.6 RC1?
Hi, If someone wants to try out xfce 4.6 RC1 here are my patches: http://people.freebsd.org/~oliver/xfce/xfce-4.5.99.1.diff This one needs to be applied below /usr/ports. With xfce 4.6 there are also 3 new ports. You will find them here: http://people.freebsd.org/~oliver/xfce/xfce-4.5.99.1.tar.gz Please extract this tarball also below /usr/ports. Then deinstall your xfce 4.4 ports, cd into /usr/ports/x11-wm/xfce4 and "make install". Any comments welcome.. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
how remove old lib in "portupgrade -fr libxcb"
hi, I've portupgrade my system and as said in UPDATING I launched the portupgrade -rf libxcb. I did it twice and my applications still are linked to libxcb.so.1 and libxcb.so.2 I found out that libxcb.so.1 is in /usr/local/lib/compat/pkg/ and libxcb.so.2 is in /usr/local/lib/ I don't know how remove this old lib and despite lot of portupgrade -f xxx it's still there. How can I solve this issue? Regards -- [] [][][] Sebastien Chassot - Geneva (Switzerland) || ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Unhappy Xorg upgrade
Alex: I can understand your frustration. The Xorg update, although it helps a lot of people, is inevitably going to cause problems for some, because it is run by so many people in different ways with a wide variety of hardware. It's comparable in some ways to updating the OS, and despite the hard work by the FreeBSD Xorg team (and they did put in a lot of work), there are bound to be some difficulties. But all is not lost, even though you will have to spend some time recovering: Yes, you can get the old versions of the ports: you can use cvs (in the base system) or the port ports-mgmt/portdowngrade (which is basically a wrapper for cvs) to checkout the old versions, which are still present in the cvs repository. You can resume your automatic port updates, and then just copy the old versions of the Xorg ports over the new ones (having saved them in some other directory tree where they won't be overwritten by csup), or just not checkout the newer versions in the first place (for example, place all of the xorg ports in your refuse file, or just use cvs to checkout a list of individual installed ports that are not part of Xorg, rather than using csup collections). Alternatively, you could download the entire cvs repository (both cvs and the latest versions of csup can do this) and checkout the versions you want from your local copy of the repository. If you write a script to do this, the whole process won't take much longer than a normal csup update. For more on this, read the cvs manual ( http://ximbiot.com/cvs/manual/ ) or the relevant parts of the FreeBSD handbook ( http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/anoncvs.html ). In addition to the individual Xorg ports and metaports that you use, you will have to either use older versions of Mk/bsd.port.mk and Mk/bsd.xorg.mk, or use libmap.conf(5) to fool your ports into thinking that you have the new gl and xaw libraries installed. Remember also that one or two of the old ports have disappeared (xorg-protos, for example). For what it's worth, I used similar methods to use the new Xorg when it was still in Florent's git repository with the regular ports tree for several months. Also, for some time I used the old xorg-server (1.4.x) with the other new Xorg ports without any obvious problems. And if the Xorg nv(4x) driver is giving you problems, you can try the Xorg vesa(4x) driver, or the nvidia drivers from ports (x11/nvidia-driver). Good luck, b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: how remove old lib in "portupgrade -fr libxcb"
On Sat, Jan 31, 2009 at 4:12 PM, Sebastien Chassot wrote: > > hi, > > I've portupgrade my system and as said in UPDATING I launched the > portupgrade -rf libxcb. > > I did it twice and my applications still are linked to libxcb.so.1 and > libxcb.so.2 > > I found out that libxcb.so.1 is in /usr/local/lib/compat/pkg/ and > libxcb.so.2 is in /usr/local/lib/ > > I don't know how remove this old lib and despite lot of portupgrade -f > xxx it's still there. > > How can I solve this issue? > Sounds like several of the libraries that your applications require are still linked to the old libxcb.so.1. Use this to find all libraries that are still depending on libxcb.so.1 (for i in /usr/local/lib/lib*.so ; do echo -n "$i:" ; ldd $i | grep "libxcb.so.1" ; echo ; done) | grep libxcb > libxcb.log Then rebuild all ports that contain these libraries. Scot ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD Port: iwi-firmware-2.4_8
Dear Florent Thoumie, I recently installed freeBSD 7.1 on an IBM Thinkpad T42 (types 2378) equipped with an Intel 2200 Pro Wireless card. When the system attempts to load the bss driver (for iwi) the process times out before the driver loads. As a result, the wireless card does not function. Is there a way to ask iwi to use a longer timeout than the default, so that the card has time to respond to the driver's request? (The card functions fine with windows XP and linux.) If they are of interest, the error message and my loader.boot file follows. Thanks. Best Regards, John from /var/log/messages: (system response to the command "ifconfig iwi0 up scan") Jan 30 01:39:02 JohnsThinkpad kernel: iwi0: timeout processing command blocks for iwi_bss firmware Jan 30 01:39:02 JohnsThinkpad kernel: iwi0: could not load main firmware iwi_bss --- from /boot/loader.conf: #WiFi Config if_iwi_load="YES" wlan_load="YES" firmware_load="YES" iwi_bss_load="YES" iwi_ibss_load="YES" iwi_monitor_load="YES" legal.intel_iwi.license_ack=1 John Curley.vcf Description: Binary data ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
boinc-client fails
Seems like something broke boinc-client: r...@kg-vm# make install ===> Vulnerability check disabled, database not found ===> Found saved configuration for boinc-client-5.10.32_1 ===> Extracting for boinc-client-6.4.5_2 => MD5 Checksum OK for boinc-client-6.4.5.tar.bz2. => SHA256 Checksum OK for boinc-client-6.4.5.tar.bz2. ===> Patching for boinc-client-6.4.5_2 ===> Applying FreeBSD patches for boinc-client-6.4.5_2 ===> boinc-client-6.4.5_2 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found ===> boinc-client-6.4.5_2 depends on shared library: curl - found ===> boinc-client-6.4.5_2 depends on shared library: jpeg - found ===> boinc-client-6.4.5_2 depends on shared library: glut - found ===> boinc-client-6.4.5_2 depends on shared library: iconv.3 - found ===> boinc-client-6.4.5_2 depends on shared library: wx_base-2.8 - found ===> Configuring for boinc-client-6.4.5_2 --- Configuring BOINC 6.4.5 (Release) --- --- Build Components: (client only) --- checking build system type... amd64-portbld-freebsd7.1 checking host system type... amd64-portbld-freebsd7.1 checking target system type... amd64-portbld-freebsd7.1 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of cc... gcc3 checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking dependency style of c++... gcc3 checking how to run the C preprocessor... cc -E checking whether make sets $(MAKE)... (cached) yes checking for ranlib... ranlib checking for ln... /bin/ln checking whether '/bin/ln' works... yes checking whether ln -s works... yes checking whether 'ln -s' really works or whether I'm deluding myself... it works checking whether cc understands -c and -o together... yes checking for docbook2x-man... no checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether we are compiling for cygwin... no checking windows.h usability... no checking windows.h presence... no checking for windows.h... no checking for winsock2.h... (cached) no checking for winsock.h... (cached) no checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking dependency style of ... none checking for a sed that does not truncate output... /usr/bin/sed checking for ld used by cc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependent libraries... pass_all checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking how to run the C++ preprocessor... c++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... (cached) 262144 checking command to parse /usr/bin/nm -B output from cc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... (cached) ranlib checking for strip... strip checking if cc static flag works... yes checking if cc supports -fno-rtti -fno-exceptions... no checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc supports -c -o file.o... yes checking whether the
Re: trying out xfce 4.6 RC1?
On Sat, 31 Jan 2009, Oliver Lehmann wrote: If someone wants to try out xfce 4.6 RC1 here are my patches: http://people.freebsd.org/~oliver/xfce/xfce-4.5.99.1.diff This one needs to be applied below /usr/ports. With xfce 4.6 there are also 3 new ports. You will find them here: http://people.freebsd.org/~oliver/xfce/xfce-4.5.99.1.tar.gz Please extract this tarball also below /usr/ports. Then deinstall your xfce 4.4 ports, cd into /usr/ports/x11-wm/xfce4 and "make install". Nifty! Seems to work on a test system. The only problem I see is some missing icons in the panels and menus. For example, in the panel menu from the xfce icon, there's no icon for Settings. Possibly I just had a goofy ports situation on the test system, or maybe a missing theme. Looks good otherwise. -Warren Block * Rapid City, South Dakota USA ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
boinc-client fails
Torfinn Ingolfsen writes: > Seems like something broke boinc-client: Re-install/upgrade ftp/curl? Robert Huff ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- You/vehemens (Sat, 31 Jan 2009 13:54:42 -0800) * | On Saturday 31 January 2009 01:25:21 pm Alex Goncharov wrote: | > So, a *fundamental* (practically an OS component) port is brought in | > -- and it disables my system. What is my way of action? Right -- | > install the old packages, taken from an FTP site (is there a way to | > get the previous "source", that is all the ports/*/*/Makefile files? | > Csup can only go forward -- or can it go back?) | | You ignored the first part of the email which is that the ports | system is flawed due to the lack of a stable versus current branch. The FreeBSD model as what it is and I, for one, prefer it to Linux distros' models. In other words what you call a flaw, I call a virtue. | It seems to me that you want to run a stable branch, while the ports | tree is effectively a current branch. If somebody tells me that running the new X on my computers will be better if I switch the base system from STABLE to CURRENT, I'll do it in a heartbeat. (In fact one of my other systems does run CURRENT, only I never installed X there -- I don't use that system as a front end.) | > When I install the old packages, I can no longer rebuild and install | > new (say `csup'ed on 2009-03-01) port components, as one whole -- I | > can only do it selectively, excluding from the upgrade most | > X-dependent things. That sucks and will lead to a problem earlier or | > later. | | I never update /usr/ports directly. I have a separate csup ports | area. When I update, I save the old ports tree and replace it with | a new one. If a problem occurs, I can fall back to the old tree or | pieces of it. An interesting model -- but how would you be better off falling back to the old ports tree in case of a bad (for you) new X? Yes, you could rebuild and return to using the old X. Then what? Would you be able to keep up with ports upgrades. You may assume that X is going to be fixed -- but what if not, in, say a year? | Well, it depends on which ports you are updating. All. | If you only run X, then I would expect your statement to be correct. Not sure what you mean here: nobody "runs only X". It's impossible. | > | And last, many of the video drivers have little if any support. If | > | you have something other then ati/intel/nivdia, you should expect | > | problems. Input drivers are in a similar state. | > | > Both my systems I've been reporting problems with are using the `nv' | > driver: | > | > $ grep /modules/drivers /var/log/Xorg.0.log | > (II) Loading /usr/local/lib/xorg/modules/drivers//nv_drv.so | > | > One system (Dell Latitude) could not be made operational with the new | > X at all; the other has garbage in the windows and the "captive mouse | > pointer" -- both issues new in the new X. | | See above :) Which point? :-) -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: boinc-client fails
Hi, On Sun, Feb 1, 2009 at 1:01 AM, Robert Huff wrote: > > Torfinn Ingolfsen writes: > >> Seems like something broke boinc-client: > >Re-install/upgrade ftp/curl? As curl was upgraded in the same "run", I thought it was good. However, when I now try to do 'portupgrade -f curl, it fails: ---> Installing the new version via the port ===> curl-7.19.2 depends on file: /usr/local/bin/perl5.8.9 - found ===> curl-7.19.2 depends on shared library: idn.16 - found ===> curl-7.19.2 depends on shared library: ssh2.1 - not found ===>Verifying reinstall for ssh2.1 in /usr/ports/security/libssh2 ===> Installing for libssh2-0.2,1 ===> Generating temporary packing list ===> Checking if security/libssh2 already installed ===> libssh2-0.2,1 is already installed You may wish to ``make deinstall'' and install this port again by ``make reinstall'' to upgrade it properly. If you really wish to overwrite the old port of security/libssh2 without deleting it first, set the variable "FORCE_PKG_REGISTER" in your environment or the "make install" command line. *** Error code 1 Stop in /usr/ports/security/libssh2. *** Error code 1 Stop in /usr/ports/security/libssh2. *** Error code 1 Stop in /usr/ports/ftp/curl. *** Error code 1 Stop in /usr/ports/ftp/curl. *** Error code 1 Stop in /usr/ports/ftp/curl. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portinstall.58262.0 env make reinstall ** Fix the installation problem and try again. ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! ftp/curl (install error) And yes, I tried to reinstall libssh2 also. -- Regards, Torfinn ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- You/bf2006a (Sat, 31 Jan 2009 14:43:59 -0800 (PST)) * | Alex: | | I can understand your frustration. The Xorg update, although it | helps a lot of people, is inevitably going to cause problems for | some, because it is run by so many people in different ways with a | wide variety of hardware. It's comparable in some ways to updating | the OS, and despite the hard work by the FreeBSD Xorg team (and they | did put in a lot of work), there are bound to be some difficulties. | But all is not lost, even though you will have to spend some time | recovering: | | Yes, you can get the old versions of the ports: you can use cvs (in the | base system) or the port ports-mgmt/portdowngrade (which is basically | a wrapper for cvs) to checkout the old versions, which are still present | in the cvs repository. That's useful -- I didn't know about ports-mgmt/portdowngrade. Thank you! | You can resume your automatic port updates, and then just copy the | old versions of the Xorg ports over the new ones (having saved them | in some other directory tree where they won't be overwritten by | csup), or just not checkout the newer versions in the first place | (for example, place all of the xorg ports in your refuse file, or | just use cvs to checkout a list of individual installed ports that | are not part of Xorg, rather than using csup collections). Thank you again. Makes sense. | Alternatively, you could download the entire cvs repository (both cvs and | the latest versions of csup can do this) and checkout the versions you want | from your local copy of the repository. | | If you write a script to do this, the whole process won't take much longer | than a normal csup update. | | For more on this, read the cvs manual ( http://ximbiot.com/cvs/manual/ ) | or the relevant parts of the FreeBSD handbook ( | http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/anoncvs.html ). And again -- I'll explore this. | In addition to the individual Xorg ports and metaports that you use, you | will have to either use older versions of Mk/bsd.port.mk and | Mk/bsd.xorg.mk, or use libmap.conf(5) to fool your ports into thinking | that you have the new gl and xaw libraries installed. Remember also that | one or two of the old ports have disappeared (xorg-protos, for example). | | For what it's worth, I used similar methods to use the new Xorg when | it was still in Florent's git repository with the regular ports tree | for several months. Also, for some time I used the old xorg-server | (1.4.x) with the other new Xorg ports without any obvious problems. | And if the Xorg nv(4x) driver is giving you problems, you can try | the Xorg vesa(4x) driver, or the nvidia drivers from ports | (x11/nvidia-driver). I think the most severe problem that I've had -- the keyboard key codes read wrong on Dell Latitude -- is not related to a video driver. But for the other issues, especially the noise in windows, trying another driver makes sense. A year ago I had a similar issue on a different system with the `radeonhd' driver. The the new driver was released, it eliminated the noise completely. | Good luck, Thanks a lot -- I'll slowly try all the things you suggested. And I wish your instructions about the CVS and csup options were in /usr/ports/DOWNGRADING :-) -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
Alex Goncharov wrote: ,--- You/Peter (Sat, 31 Jan 2009 06:53:11 +1100) * | X11 is a critical component for anyone who is using FreeBSD as a | desktop and having upgrades fail or come with significant POLA | violations and regressions for significant numbers of people is not | acceptable. Fully agree with this. | I suggest that this approach needs to be followed for every future | release of X.org until (if) the X.org Project demonstrates that they | can provide release-quality code. And agree with this, as far as the future is concerned -- but this leaves out the issue of what is going to be done for people whose systems became practically incapacitated in a matter of one day. Screw us? I realize that personally I haven't contributed much (hey, a simple port's maintainer!) to FreeBSD, so a disregard to my situation may be well deserved. But "you" (whoever this "you" is: the "ports manager", the X port maintainers) have to be aware that leaving the things in the state they are now, you are screwing somebody. | > This update also brings in support for a lot of people who are | >running newer hardware. | | And breaks support for lots of people who used to have functional X | servers. Just so. ,--- Kostik Belousov (Fri, 30 Jan 2009 22:25:09 +0200) * | Just to give a different view on *this* update. I have exactly opposing | experience. | | So far 1.5.3 + updated DRM works good on all my Radeons. | And, I did not have a problem with i945GM on 1.4.2 and 1.5.3. `--* Well, glad for you -- meanwhile I will be reverting my desktop to the old X this weekend: the garbage on the screen is ugly, but the fact that in the new X "opera" can grab a pointer for about a minute makes the combined use of the browser and xterms/Emacses plain intolerable. After I do this, as I did with my laptop already, I think I am completely cut off from the ports automated upgrade cycle. -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" To add my experience, I have been using X on intel hardware since the late eighties when you had to calculate your modeline by hand. But I guess I have gotten spoiled by how easily it now is to normally configure X. Run X -configure and you normally are good to go. Well at work I had a dual head matrox card that would not configure after the upgrade, so I took it out of the machine to use the built in via graphics controller that worked fine under 1.4 but when I ran X -configure there was an error trying to load the via driver, because it didn't compile ( and as I later found out has been replaced by the openchrome driver - didn't see anything about that in UPDATING ) so the automatic config fell back to using the vesa driver. But when I tried to run X -config /root/xorg.conf.new X reported it couldn't find any screens for vesa driver no matter how I changed the config. After fighting with this for half a day I reverted back to 1.4 because I needed my machine operational to get some work done. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
Alex Goncharov wrote: That's useful -- I didn't know about ports-mgmt/portdowngrade. Thank you! It's not that useful because very few ports mirrors allow anon-cvs access, mostly just cvsup/csup. The last time I had to use it, I found a mirror in Germany that worked, after a long search. The Xorg update was a minor disaster, and it's nobody's fault. More testing was needed on lots more systems and that can only really happen after committal. -- James Bailie http://www.mammothcheese.ca ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: unreasonable amount of memory used in openoffice build
On Thu, 27 Nov 2008, Maho NAKATA wrote:
Sorry for delay.
Please try attached patch. If it works for you, I'll commit it.
Will this patch be committed soon? I can confirm that with this patch it
builds on i386. Without this patch, it will not build for me on any i386
system no matter how much RAM and/or swap is available. Thanks for your
fine work on this port.
--
Greg Rivers? diff
? work
? work_
? files/patch-iX
Index: Makefile
===
RCS file: /home/pcvs/ports/editors/openoffice.org-3/Makefile,v
retrieving revision 1.312
diff -u -r1.312 Makefile
--- Makefile16 Oct 2008 12:30:24 - 1.312
+++ Makefile27 Nov 2008 01:16:40 -
@@ -149,9 +149,6 @@
WITHOUT_MOZILLA= yes
LIB_DEPENDS+= boost_regex:${PORTSDIR}/devel/boost
CONFIGURE_ARGS+= --with-system-boost=yes #i58343#
-.if (${OSVERSION} >= 700042)
-EXTRA_PATCHES+=${FILESDIR}/amd64-gcc42-workaround
-.endif
.endif
.if (${OSVERSION} <= 602102)
EXTRA_PATCHES+=${FILESDIR}/rtld-workaround-i7
--- /dev/null 2008-11-27 10:17:03.0 +0900
+++ files/patch-iX 2008-11-27 10:04:41.0 +0900
@@ -0,0 +1,13 @@
+--- writerfilter/source/resourcemodel/makefile.mk.orig 2008-07-22
08:53:57.0 -0400
writerfilter/source/resourcemodel/makefile.mk 2008-09-03
12:26:09.0 -0400
+@@ -56,8 +56,8 @@
+ $(SLO)$/TagLogger.obj \
+ $(SLO)$/WW8Analyzer.obj
+
+-# linux 64 bit: compiler (gcc 4.2.3) fails with 'out of memory'
+-.IF "$(OUTPATH)"=="unxlngx6"
++# FreeBSD/Linux 64-bit: compiler (gcc 4.2.x) fails with 'out of memory'
++.IF "$(OUTPATH)"=="unxfbsdx" || "$(OUTPATH)"=="unxfbsdi" ||
"$(OUTPATH)"=="unxlngx6"
+ NOOPTFILES= \
+ $(SLO)$/qnametostr.obj
+ .ENDIF
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?)
>Pedro F. Giffuni wrote: >> if FreeBSD moves to a GPL3'd toolchain without an extremely compelling >> >reason then I would consider a move to another OS. > >This would be a big loss for the Project, I have no doubt about that! :) > >-Maxim S. Don't antagonize who's willing to do as much work in Ports as Pedro has. He's been virtually maintaining one of my ports. ;) b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- You/James (Sat, 31 Jan 2009 19:50:15 -0500) * | Alex Goncharov wrote: | | > That's useful -- I didn't know about ports-mgmt/portdowngrade. Thank | > you! | | It's not that useful because very few ports mirrors allow anon-cvs | access, mostly just cvsup/csup. The last time I had to use it, I | found a mirror in Germany that worked, after a long search. Thanks for this info, too -- now I'll be prepared to at least some failures on my way. | The Xorg update was a minor disaster, and it's nobody's fault. Fault or not fault, but it seems to me that this upgrade should have been actively warned about and discussed at least two weeks before it happened. In one of my earlier messages, I mentioned that when I had tried to bring X on my laptop to life, I did plenty of Web searching and reading. The number of problems with xorg-server 1.5 reported by Linux users stunned me -- I remember one Debian user had to get the old X from a different release of Debian in order to make his system operational. What was expected to happen on FreeBSD with this X? A smooth fly for everybody -- or some "acceptable" number of hardware configurations allowing the use of the new X? | More testing was needed on lots more systems Yes. | and that can only really happen after committal. No -- a patch might (*should*, for this kind of a disruptive change) be put together: I'd install it on my systems, I'd try it and report problems, I'd revert back -- easily. This is for many "I"s willing to be the testers -- we'd repeat this again as many times as necessary, before the commit. -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
On Fri, Jan 30, 2009 at 10:25:09PM +0200, Kostik Belousov wrote: > In contrast, 1.5.3 upgraded and I observed two issues, one was the > Xorg sleeping in "ttyin", that was promptly fixed. What was this one about? I just had the weird experience (after upgrading with much manual intervention) of X ignoring all keyboard input until it received a mouse interrupt. I rebuilt hal (even though it claimed not to be out of date) and rebooted and everything seems to be working again... Cheers, -- Andrew ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
