Re: [kde-freebsd] kdenetwork-4.8.4_2 and libotr
On Friday 05 October 2012 14:12:29 joaoBR wrote:
On 23/09/2012 18:36, Christopher Dawkins wrote:
I am sorry to bring this to your attention: you all do a lot of work
that considerably benefits me and many others.
But I cannot compile kdenetwork-4.8.4_2 because it seems to need libotr3.
The advice in 20120908 seems irrelevant because I am not using
pidgin-otr, anyway, it cannot work because there is no libotr3 port or
directory.
... somebody else wrote
If you look at the current Makefile, it has
otr.4:${PORTSDIR}/security/libotr3 \
I don't see how you all have been making it build with that setup..
seems you're not getting what's the deal
otr.4 is from libotr3, the Makefile is ok
You have it backwards. Libotr3 is for the version 3.x
# $FreeBSD: ports/security/libotr/Makefile,v 1.30 2012/09/08 07:03:21 dougb
Exp $
PORTNAME= libotr
PORTVERSION=4.0.0
there is now libotr3 and libotr4, the former is needed by kde4
it is not an upgrade of libotr even if it is described as so, it is a
new additional version
libotr4 unfortunately assumed the ports dir from the older port, it
could have been much more stressless and smarter making it
security/libotr4 but they did it the spaghetti way ...
so now the old port and actual kde dependency is in security/libotr3
in order to make it work you first need to run like explained in UPDATE
portugrade -o security/libotr3 security/libotr
now you can upgrade kdenetwork and eventually any other port which
depends on libotr3
[]s
___
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
Facile-1.1 PORTREVISION
I just encountered a problem with kdeedu-4. The response is use search Luke; however, facile needs to be rebuilt. It should be PORTREVISION so that a rebuild is forced. I have been waiting for the massive changes to settle down and only facile and mplayer have presented problems. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ 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
Libxine Error
I have been trying to get a traceback for kscd in kde4, which sig-11 aborts everytime I try to run it. I am running 7-stable. In the process, the kde people told me to rebuild everying in kde4 with WITH_DEBUG=YES in /etc/make.conf. Each time it failed to give me a traceback and the portupgrade got wider. It has not gone smoothly. I finally did a portupgrade -fR kde4. I am now stopped at the point of building multimedia/libxine where I get the following error libtool: compile: cc -DHAVE_CONFIG_H -I. -I../../include -I../.. - I../../include -I../../include -I../../src -I../../src/xine-engine - I../../src/xine-engine -I../../src/xine-utils -I../../src/input - I../../src/input -I../../lib -I../../lib -I/usr/local/include - fvisibility=hidden -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DXINE_COMPILE - mtune=i386 -O3 -pipe -fomit-frame-pointer -falign-functions=4 -falign-loops=4 -falign-jumps=4 -fexpensive-optimizations -fschedule-insns2 -ffast-math - finline-functions -Wpointer-arith -pipe -g -fno-force-addr - I/usr/local/include -I/usr/local/include/dvdread -Wall -Wchar-subscripts - Wnested-externs -Wcast-align -Wmissing-declarations -Wmissing-prototypes - Wmissing-format-attribute -Wno-pointer-sign -Wformat=2 -Wno-format-zero-length -Wstrict-aliasing=2 -Werror=implicit-function-declaration -DNDEBUG -MT xineplug_decode_real_la-xine_real_video_decoder.lo -MD -MP -MF .deps/xineplug_decode_real_la-xine_real_video_decoder.Tpo -c xine_real_video_decoder.c -fPIC -DPIC -o .libs/xineplug_decode_real_la- xine_real_video_decoder.o In file included from xine_real_video_decoder.c:49: real_common.h:49: error: '__environ' defined both normally and as an alias real_common.h:59: error: 'stderr' defined both normally and as an alias gmake[2]: *** [xineplug_decode_real_la-xine_real_video_decoder.lo] Error 1 gmake[2]: Leaving directory `/usr/ports/multimedia/libxine/work/xine- lib-1.1.16.3/src/libreal' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/multimedia/libxine/work/xine- lib-1.1.16.3/src' gmake: *** [all-recursive] Error 1 *** Error code 1 The old rule of building everything used by libxine didn't help. I also get the same error on a 7-stable system that was not changed in order to get a traceback. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ 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: Libxine Error
On Thursday 04 February 2010 04:24:43 pm Kent Stewart wrote: I have been trying to get a traceback for kscd in kde4, which sig-11 aborts everytime I try to run it. I am running 7-stable. In the process, the kde people told me to rebuild everying in kde4 with WITH_DEBUG=YES in /etc/make.conf. Each time it failed to give me a traceback and the portupgrade got wider. It has not gone smoothly. I finally did a portupgrade -fR kde4. I am now stopped at the point of building multimedia/libxine where I get the following error libtool: compile: cc -DHAVE_CONFIG_H -I. -I../../include -I../.. - I../../include -I../../include -I../../src -I../../src/xine-engine - I../../src/xine-engine -I../../src/xine-utils -I../../src/input - I../../src/input -I../../lib -I../../lib -I/usr/local/include - fvisibility=hidden -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DXINE_COMPILE - mtune=i386 -O3 -pipe -fomit-frame-pointer -falign-functions=4 -falign-loops=4 -falign-jumps=4 -fexpensive-optimizations -fschedule-insns2 -ffast-math - finline-functions -Wpointer-arith -pipe -g -fno-force-addr - I/usr/local/include -I/usr/local/include/dvdread -Wall -Wchar-subscripts - Wnested-externs -Wcast-align -Wmissing-declarations -Wmissing-prototypes - Wmissing-format-attribute -Wno-pointer-sign -Wformat=2 -Wno-format-zero-length -Wstrict-aliasing=2 -Werror=implicit-function-declaration -DNDEBUG -MT xineplug_decode_real_la-xine_real_video_decoder.lo -MD -MP -MF .deps/xineplug_decode_real_la-xine_real_video_decoder.Tpo -c xine_real_video_decoder.c -fPIC -DPIC -o .libs/xineplug_decode_real_la- xine_real_video_decoder.o In file included from xine_real_video_decoder.c:49: real_common.h:49: error: '__environ' defined both normally and as an alias real_common.h:59: error: 'stderr' defined both normally and as an alias gmake[2]: *** [xineplug_decode_real_la-xine_real_video_decoder.lo] Error 1 gmake[2]: Leaving directory `/usr/ports/multimedia/libxine/work/xine- lib-1.1.16.3/src/libreal' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/multimedia/libxine/work/xine- lib-1.1.16.3/src' gmake: *** [all-recursive] Error 1 *** Error code 1 The old rule of building everything used by libxine didn't help. I also get the same error on a 7-stable system that was not changed in order to get a traceback. The last sentence is not correct. I was ssh'ed to the broken machine and didn't notice. The other machine is still running kde3 and didn't have any problem building libxine. It also hasn't been port updated since 22 Jan. Kent -- Kent Stewart Richland, WA ___ 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: [kde-freebsd] devel/qt4-designer fails on -current
to `qdesigner_internal::QDesignerFormWindowManager::staticMetaObject' .obj/release-shared/qdesigner_actions.o(.text+0x96d6): In function `QDesignerActions::QDesignerActions(QDesignerWorkbench*)': ../../../../include/QtCore/../../src/corelib/kernel/qobject.h:443: undefined reference to `qdesigner_internal::QDesignerFormWindowManager::staticMetaObject' .obj/release-shared/qdesigner_actions.o(.text+0xb8fe): In function `QDesignerActions::writeOutForm(QDesignerFormWindowInterface*, QString const)': /usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-sr c-4.5.2/tools/designer/src/designer/qdesigner_actions.cpp:828: undefined reference to `qdesigner_internal::FormWindowBase::lineTerminatorMode() const' .obj/release-shared/saveformastemplate.o(.text+0xbbb): In function `SaveFormAsTemplate::accept()': /usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-sr c-4.5.2/tools/designer/src/designer/saveformastemplate.cpp:134: undefined reference to `qdesigner_internal::QDesignerSharedSettings::setFormTemplatePaths(QStringL ist const)' .obj/release-shared/saveformastemplate.o(.text+0x103d): In function `SaveFormAsTemplate::SaveFormAsTemplate(QDesignerFormEditorInterface*, QDesignerFormWindowInterface*, QWidget*)': /usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-sr c-4.5.2/tools/designer/src/designer/saveformastemplate.cpp:70: undefined reference to `qdesigner_internal::QDesignerSharedSettings::formTemplatePaths() const' .obj/release-shared/saveformastemplate.o(.text+0x12ed): In function `SaveFormAsTemplate::SaveFormAsTemplate(QDesignerFormEditorInterface*, QDesignerFormWindowInterface*, QWidget*)': /usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-sr c-4.5.2/tools/designer/src/designer/saveformastemplate.cpp:70: undefined reference to `qdesigner_internal::QDesignerSharedSettings::formTemplatePaths() const' .obj/release-shared/newform.o(.text+0x2a): In function `NewForm::grabForm(QDesignerFormEditorInterface*, QIODevice, QString const, qdesigner_internal::DeviceProfile const)': ../../../../include/QtCore/../../src/corelib/tools/qlist.h:562: undefined reference to `qdesigner_internal::NewFormWidget::grabForm(QDesignerFormEditorInterface*, QIODevice, QString const, qdesigner_internal::DeviceProfile const)' .obj/release-shared/newform.o(.text+0xdbb): In function `NewForm::NewForm(QDesignerWorkbench*, QWidget*, QString const)': /usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-sr c-4.5.2/tools/designer/src/designer/newform.cpp:81: undefined reference to `QDesignerNewFormWidgetInterface::createNewFormWidget(QDesignerFormEditorIn terface*, QWidget*)' .obj/release-shared/newform.o(.text+0x127b): In function `NewForm::NewForm(QDesignerWorkbench*, QWidget*, QString const)': /usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-sr c-4.5.2/tools/designer/src/designer/newform.cpp:81: undefined reference to `QDesignerNewFormWidgetInterface::createNewFormWidget(QDesignerFormEditorIn terface*, QWidget*)' .obj/release-shared/preferencesdialog.o(.text+0x24e): In function `PreferencesDialog::PreferencesDialog(QDesignerFormEditorInterface*, QWidget*)': /usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-sr c-4.5.2/tools/designer/src/designer/preferencesdialog.cpp:62: undefined reference to `QDesignerFormEditorInterface::optionsPages() const' .obj/release-shared/preferencesdialog.o(.text+0x63e): In function `PreferencesDialog::PreferencesDialog(QDesignerFormEditorInterface*, QWidget*)': /usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-sr c-4.5.2/tools/designer/src/designer/preferencesdialog.cpp:62: undefined reference to `QDesignerFormEditorInterface::optionsPages() const' /usr/local/lib/qt4/libQtDesigner.so: undefined reference to `QCss::Parser::parse(QCss::StyleSheet*)' *** Error code 1 I had the same problem. It was fixed in a later update. You need to cvsup again or what ever you use. You may hit problem with phonon, which the current UPDATING tells you to delete. Using portupgrade, kdepim was updated after kdepimlibs and kdepim-runtime were created and that deleted files in both that are needed by *-workspace. You should delete kdepim before you continue. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ 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: Unable to build graphics/gd
On Sunday 19 July 2009 11:08:31 am Greg Lewis wrote: On Sun, Jul 19, 2009 at 02:23:27PM +0200, Marcus von Appen wrote: On, Sun Jul 19, 2009, Jerry wrote: On Sun, 19 Jul 2009 13:00:30 +0200 Marcus von Appen m...@freebsd.org wrote: [snip] Looks like it tries to link against the older version that's still installed. Try to deinstall gd first, then build and install it again. Thanks, that fixed it. Strange, but I have not had that problem before. Just for informational purposes: It is a problem with how the FreeBSD upgrade tools work and how a port (read: application, library, whatever) manages its own build. Usually a port, in case it links to one of its own components, should do that by using the just built component in its build directory. Some of them however do not do that but use the complete system environment, thus it can happen that they link to e.g. an older version of themselves or so, causing anything to fail as you just noticed. In this case, the port was trying to link against the just built version of its shared library, it just also tries to link against some other libraries from other ports and puts -L/usr/local/lib earlier in the search path than the path to the newly built libgd.so so the linker picks up libgd.so from /usr/local/lib and uses that, hence the failure above. I saw the same problem. So just a little variant on what you said. Its trying to do the right thing but just getting the ordering wrong. I did the recursive pkg_delete as specified in UPDATING and now I have an unworkable KDE. Everything wants to reinstall jpeg-6, which fails because it is already installed. That left me with around 20 modules required by KDE that wouldn't build. When the current portupgrade fails, I will do the PKG_FORCE thing but I shouldn't have to do that. GD not building is just a small piece of the problem. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ 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: fftw3
On Sunday 17 May 2009 07:21:17 am eculp wrote: Quoting ajtiM lum...@gmail.com: On Sunday 17 May 2009 03:14:12 Chris Rees wrote: 2009/5/17 ajtiM lum...@gmail.com: On Friday 15 May 2009 19:48:23 Sahil Tandon wrote: On Fri, 15 May 2009, ajtiM wrote: pkgdb -F --- Checking the package registry database Stale dependency: akode-2.0.2,1 - fftw3-3.1.3 (math/fftw3): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] yes [Gathering depends for math/fftw3 .. done] --- Installing 'gcc-4.3.4_20090503' from a port (lang/gcc43) --- Building '/usr/ports/lang/gcc43' === Cleaning for gcc-4.3.4_20090503 Making GCC 4.3.4 for FreeBSD 7.2 target=i386-portbld-freebsd7.2 You need to increase the datasize limit to at least 70 (and set kern.maxdsiz=734003200 in /boot/loader.conf) to build with Java support. Did you try increasing the datasize limit? *** Error code 1 Stop in /usr/ports/lang/gcc43. If you don't need Java: % grep -C 1 WITHOUT_JAVA lang/gcc43/pkg-descr (Building the Java frontend and the associated libgcj library will consume more than 512MB of main memory. Set WITHOUT_JAVA=yes in the environment when building this port to avoid that.) I have WITHOUT_JAVA= yes and it doesn't work. As in WITHOUT_JAVA=yes or WITHOUT_JAVA= yes ? You can't just stick random whitespace in the middle of things like that Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Thank you very much but I didn't change Makefil. It was originaly in (default). I'm using today's current and just tried the following in lang/gcc43 to hopefully be able to build ffw3 with the following made and resulting errors. # make WITHOUT_JAVA=yes You really needed to man make. I did a setenv WITHOUT_JAVA yes in my .cshrc, brought up a new konsole and everything built. For make, I think it would have to be make -D WITHOUT_JAVA=yes. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ 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: fftw3
On Sunday 17 May 2009 11:15:21 am Sahil Tandon wrote: On Sun, 17 May 2009, Kent Stewart wrote: I'm using today's current and just tried the following in lang/gcc43 to hopefully be able to build ffw3 with the following made and resulting errors. # make WITHOUT_JAVA=yes You really needed to man make. I did a setenv WITHOUT_JAVA yes in my .cshrc, brought up a new konsole and everything built. For make, I think it would have to be make -D WITHOUT_JAVA=yes. No, passing variable overrides to make(1) on the command line works without the -D flag. Why do you believe it is necessary? Because I always had to do it in the past. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ 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: fftw3
On Sunday 17 May 2009 11:38:34 am Kent Stewart wrote: On Sunday 17 May 2009 11:15:21 am Sahil Tandon wrote: On Sun, 17 May 2009, Kent Stewart wrote: I'm using today's current and just tried the following in lang/gcc43 to hopefully be able to build ffw3 with the following made and resulting errors. # make WITHOUT_JAVA=yes You really needed to man make. I did a setenv WITHOUT_JAVA yes in my .cshrc, brought up a new konsole and everything built. For make, I think it would have to be make -D WITHOUT_JAVA=yes. No, passing variable overrides to make(1) on the command line works without the -D flag. Why do you believe it is necessary? Because I always had to do it in the past. I tried the update today, and the make WITHOUT_JAVA=yes worked. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ 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: Portupgrade still broken?
On Thursday 09 April 2009 09:37:49 am Parv wrote: in message b79ecaef0904080551x74c80227h1a4ba5d2adcca...@mail.gmail.com, wrote Chris Rees thusly... I recall from http://lists.freebsd.org/pipermail/freebsd-ports/2008-March/047319.html that there was a bug in portupgrade last year, causing it to break when a port is recursively (-R) upgraded; it's surfacing for me too :( [ch...@amnesiac]/usr/ports/ports-mgmt/portupgrade% portupgrade --version portupgrade 2.4.6 Is this a 'fixed' version, or not? I think it's the most recent... [ch...@amnesiac]/usr/ports/ports-mgmt/portupgrade% sudo portupgrade -rR emacs xterm curl php5-mbstring otp-md5 488 am9338 ext Password: [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 263 packages found (-3 +3) (...)... done] [Gathering depends for editors/emacs . .. .. .. done] [Exclude up-to-date packages . .. done] /usr/local/lib/ruby/site_ruby/1.8/pkginfo.rb:74:in `initialize': : Not in due form: name-version (ArgumentError) from /usr/local/sbin/portupgrade:614:in `new' from /usr/local/sbin/portupgrade:614:in `main' ... Does this Perl (5.8 onwards) program ... http://www103.pair.com/parv/comp/src/perl/check-portupgrade-00 ... produces anything when run *without any arguments*? It doesn't produce any messages. Purpose of the program is to find a port name (based on directory name in /var/db/pkg) which fails to match the regular expression /^(.+)-([^-]+)$/ used in pkginfo.rb, among other files of portupgrade. If the Perl program is run with any arguments, then a sorted list of matched names will be printed, something like ... aalib-1.4.r5_4 : aalib 1.4.r5_4 acroread8-8.1.2_2 : acroread8 8.1.2_2 acroreadwrapper-0.0.20080906 : acroreadwrapper 0.0.20080906 agg-2.5_5 : agg 2.5_5 aircrack-ng-1.0.r1 : aircrack-ng 1.0.r1 amspsfnt-1.0_5 : amspsfnt 1.0_5 ... check-portupgrade p5 produced a list of 632 names, which is about what I have installed. I ran portupgrade -rR libxcb recently and it failed with the same pkginfo.rb error you are listing. Kent -- kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ 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: Portupgrade still broken?
On Wednesday 08 April 2009 05:51:48 am Chris Rees wrote: Dear all on freebsd-ports@, I recall from http://lists.freebsd.org/pipermail/freebsd-ports/2008-March/047319.html that there was a bug in portupgrade last year, causing it to break when a port is recursively (-R) upgraded; it's surfacing for me too :( [ch...@amnesiac]/usr/ports/ports-mgmt/portupgrade% portupgrade --version portupgrade 2.4.6 Is this a 'fixed' version, or not? I think it's the most recent... [ch...@amnesiac]/usr/ports/ports-mgmt/portupgrade% sudo portupgrade -rR emacs xterm curl php5-mbstring otp-md5 488 am9338 ext Password: [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 263 packages found (-3 +3) (...)... done] [Gathering depends for editors/emacs ... done] [Exclude up-to-date packages ... done] /usr/local/lib/ruby/site_ruby/1.8/pkginfo.rb:74:in `initialize': : Not in due form: name-version (ArgumentError) from /usr/local/sbin/portupgrade:614:in `new' from /usr/local/sbin/portupgrade:614:in `main' from /usr/local/sbin/portupgrade:613:in `each' from /usr/local/sbin/portupgrade:613:in `main' from /usr/local/sbin/portupgrade:588:in `catch' from /usr/local/sbin/portupgrade:588:in `main' from /usr/local/lib/ruby/1.8/optparse.rb:1305:in `call' from /usr/local/lib/ruby/1.8/optparse.rb:1305:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1301:in `catch' from /usr/local/lib/ruby/1.8/optparse.rb:1301:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1249:in `catch' from /usr/local/lib/ruby/1.8/optparse.rb:1249:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1243:in `order!' from /usr/local/lib/ruby/1.8/optparse.rb:1236:in `order' from /usr/local/sbin/portupgrade:565:in `main' from /usr/local/lib/ruby/1.8/optparse.rb:787:in `initialize' from /usr/local/sbin/portupgrade:229:in `new' from /usr/local/sbin/portupgrade:229:in `main' from /usr/local/sbin/portupgrade:2208 Is the bug still there, or is my pkgdb hosed? If so, how do I fix it? I still get the optparse.rb:787:in stop. It seems to happen quicker, when you have a larger number of ports in the rR tree. I hadn't updated my ports since 4 Apr. I did a cvsup update and and checked to see how many needed updating. There were 15 ports. I then did a portupgrade -rRp libxcb and it died fairly quickly. Libxcb on my system, has 173 ports that depend on it. I find that portupgrade -pa works for me. Kent Chris -- kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ 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 and /etc/ttys regression
On Thursday 29 January 2009 05:23:01 am Robert Noland wrote: On Thu, 2009-01-29 at 10:55 +0100, Oliver Fromme wrote: Just to be clear ... Am I understanding things right that the new X server requires hald and dbus running? It won't work anymore without them? (That would be a good reason for me not to update.) It will work without it. you need to specify Option AutoAddDevices off in the ServerLayout section of your xorg.conf. It actually goes in the ServerFlags section. I have a clean 7.1-p2 machine. It was built a few days ago and 7.1-release was the first OS on the HD. The release has only 7.3 and that was installed. It ran without an xorg.conf file. When I upgraded to 7.4, X and KDE quit working. I could altf1 or altf2 but the rest of the keyboard was mostly dead along with the mouse. For example, I couldn't ctrlaltbackspace to kill X but I could altf2 and do a shutdown now. I ran xorgconfig. It wouldn't work out of the box because xorgconfig added # Identifier and driver Identifier Mouse1 Driver mouse Option ProtocolAuto # Auto detect Option Device /dev/sysmouse When I added your AutoAddDevices line to my xorg.conf in the ServerFlags section, X and KDE started running. I shifts the screen a little bit to the left compared to my 6-stable machine, which is running 7.3 and a Windows XP Pro system that all share a kvm switch. After I made this machine work, I upgraded two others and they all had the same problem and solution. Kent You can also disable the HAL option when building the server, but you still need the above I believe. I think it has been fixed in git so that if HAL is not configured that the defaults revert to the old behavior. robert. Best regards Oliver ___ 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: Overly restrictive checks in the make process
On Friday 20 July 2007, Mark Linimon wrote: On Fri, Jul 20, 2007 at 04:07:49PM -0400, Bill Moran wrote: Even better would be for make to realize that it's only doing the fetching, and do it anyway. That still doesn't help with the problem of a user who starts a 10MB download that won't work on his architecture or OS release. The code is all the same. This is the aggravation we are trying to prevent. That still doesn't address the concern or improve the system downtime that a pkg_delete, make install allows. If you can't run something, you don't have any downtime but to have to pkg_delete before you start the tarball fetch can be really long on some ports. Kent -- Kent Stewart Richland, WA http://www.soyandina.com/ I am Andean project. http://users.owt.com/kstewart/index.html ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
