Re: xfce-4.4.0: Unable to contact the Xfce Trash service
Dmitry Pryanishnikov wrote: Well, after some experiments I've apparently found the problem: I didn't select PLUG_TPA option of the x11-fm/thunar. With PLUG_TPA=on my trash folder works. It seems to me that the overall number of selectable options (and their uncoordinated default values) in all xfce4 components makes its correct installation somewhat tricky ;) tz... thanks for the kudos ;) I'll enable the plugins now if its better -- 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 [EMAIL PROTECTED]
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://beta.inerd.com/portscout/[EMAIL PROTECTED] Port| Current version | New version +-+ deskutils/genius| 0.7.6.1 | 0.7.7 +-+ deskutils/taskjuggler | 2.3.0 | 2.3.1 +-+ devel/aap | 1.088 | 1.089 +-+ devel/agide | 0.121 | 0.124 +-+ devel/gaphor| 0.7.1 | 0.9.1 +-+ devel/gwenhywfar| 1.13.2 | 2.5.2 +-+ devel/jakarta-commons-io| 1.2 | 1.3 +-+ devel/py-ll-core| 1.4 | 1.7.2 +-+ devel/rubygem-daemons | 1.0.1 | 1.0.4 +-+ devel/rubygem-gem_plugin| 0.2.1 | 0.2.2 +-+ devel/rubygem-tzinfo| 0.3.1 | 0.3.3 +-+ devel/sourcenav | 5.1.4 | 5.2b2 +-+ finance/aqbanking | 1.0.11 | 2.2.6 +-+ games/robocode | 1.0.7 | 1.2.4 +-+ games/xarchon | 0.50| 0.60 +-+ graphics/djvulibre-nox11| 3.5.17 | 3.5.18 +-+ japanese/lookup | 1.4 | 1.4.1 +-+ japanese/lookup-emacs20 | 1.4 | 1.4.1 +-+ japanese/lookup-xemacs | 1.4 | 1.4.1 +-+ lang/bigloo | 2.6b| 2.9a +-+ lang/osb-jscore | 0.5.0 | 0.5.1 +-+ lang/smalltalk | 2.3.1 | 2.3.2 +-+ math/gambit | 0.2006.01.20| 0.2007.01.30 +-+ misc/afbackup | 3.3.5 | 3.5.1pl2 +-+ misc/afbackup-client| 3.3.5 | 3.5.1pl2 +-+ misc/afbackup-server| 3.3.5 | 3.5.1pl2 +-+ multimedia/ogmrip | 0.10.0-rc4 | 0.10.1 +-+ multimedia/pitivi | 0.10.0 | 0.10.1.2 +-+
Re: X.org, dlopen and -current problem
Same here with two boxes unter CURRENT after update from yesterday. Hope we'll find it soon, because both boxes are desktop systems, now without graphics. xorg-server-6.9.0_5 works well, -6.9.0_6 doesn't. The description of the newest patches gives me no hints what is going wrong: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/107733 Perhaps Eygene Ryabinkin has any idea? Thanks, Rainer Jiawei Ye schrieb: I am running X on a -current machine (kernel/world of 07/2/3). startx produces the following result: xauth: creating new authority file /home/leafy/.serverauth.1271 X Window System Version 6.9.0 Release Date: 21 December 2005 X Protocol Version 11, Revision 0, Release 6.9 Build Operating System: FreeBSD 7.0 i386 [ELF] Current Operating System: FreeBSD sh-mail.moderntimes.com.cn 7.0-CURRENT FreeBSD 7.0-CURRENT #40: Fri Feb 2 20:00:36 CST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MAIL i386 Build Date: 02 February 2007 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Fri Feb 2 23:53:48 2007 (==) Using config file: /etc/X11/xorg.conf dlopen: /usr/X11R6/lib/modules/fonts/libbitmap.so: Undefined symbol FontFileBitmapSources (EE) Failed to load /usr/X11R6/lib/modules/fonts/libbitmap.so (EE) Failed to load module bitmap (loader failed, 7) Fatal server error: Unable to load required base modules, Exiting... Please consult the The X.Org Foundation support at http://wiki.X.Org for help. Please also check the log file at /var/log/Xorg.0.log for additional information. X connection to :0.0 broken (explicit kill or server shutdown). This happened after the latest Xorg-server update. Does anyone have any idea how to debug this problem? Thanks, Jiawei Ye ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X.org, dlopen and -current problem
Eygene,
thank you for answering.
Eygene Ryabinkin schrieb:
Gentlemen, good day!
Same here with two boxes unter CURRENT after update from yesterday. Hope we'll
find it soon, because both boxes are desktop systems, now without graphics.
xorg-server-6.9.0_5 works well, -6.9.0_6 doesn't.
First I should ask some simple questions:
- I assume that xorg-server and xorg-libraries were recompiled for the
version 6.9.0_6?
- How you updated the xorg? Via portupgrade, by hands, some other way?
yes, both libraries were recompiled with newest portupgrade, no error
message was given.
The description of the newest patches gives me no hints what is going wrong:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/107733
I will try to build the 6.9.0_6 both on 6.x and 7-current, but I expect
that it will be done on Monday. I've tested my patches only for 6.2
as PR says. Meanwhile you can restore Makefiles, remove patches and
downgrade xorg-{server,libraries}. This is not an ideal option, but
if you're really in a great need for graphics -- give it a try, But
systems will be vulnerable then.
Perhaps I will downgrade tomorrow and see what happens ...
Perhaps Eygene Ryabinkin has any idea?
I have no idea now. But the output from the 'nm /usr/X11R6/lib/libXfont.so'
and 'nm /usr/X11R6/lib/modules/fonts/libbitmap.so' will be appreciated.
And the contents of /etc/X11/xorg.conf -- too.
Thanks for your report!
There should be three files in attachment. The described behaviour
happens even without an existing /etc/X11/xorg.conf.
Thanks again,
Rainer
# File generated by xorgconfig.
#
# Copyright 2004 The X.Org Foundation
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the Software),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
# The X.Org Foundation BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
# OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
#
# Except as contained in this notice, the name of The X.Org Foundation shall
# not be used in advertising or otherwise to promote the sale, use or other
# dealings in this Software without prior written authorization from
# The X.Org Foundation.
#
# **
# Refer to the xorg.conf(5) man page for details about the format of
# this file.
# **
# **
# Module section -- this section is used to specify
# which dynamically loadable modules to load.
# **
#
# **
# Files section. This allows default font and rgb paths to be set
# **
# **
# Server flags section.
# **
# **
# Input devices
# **
# **
# Core keyboard's InputDevice section
# **
# **
# Core Pointer's InputDevice section
# **
# **
# Other input device sections
# this is optional and is required only if you
# are using extended input devices. This is for example only. Refer
# to the xorg.conf man page for a description of the options.
# **
#
# Section InputDevice
#Identifier Mouse2
#Driver mouse
#Option Protocol MouseMan
#Option Device/dev/mouse2
# EndSection
#
# Section InputDevice
#Identifier spaceball
#Driver magellan
#Option Device/dev/cua0
# EndSection
#
# Section
Re: icc9
Alexander Leidinger wrote: Quoting fred [EMAIL PROTECTED] (from Fri, 02 Feb 2007 19:12:11 +0100): Hi there, Has somebody tried to port intel compiler 9.1 to freebsd ? Have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/103979 It may or may not work for you. Hmm, fails applying patches, again :-( === Extracting for icc-9.1.043_1 = MD5 Checksum OK for l_cc_c_9.1.043.tar.gz. = SHA256 Checksum OK for l_cc_c_9.1.043.tar.gz. === icc-9.1.043_1 depends on executable in : rpm2cpio.pl - found === Patching for icc-9.1.043_1 === Applying FreeBSD patches for icc-9.1.043_1 1 out of 4 hunks failed--saving rejects to include/c++/yvals.h.rej = Patch patch-include::c++::yvals.h failed to apply cleanly. = Patch(es) patch-bin::icc patch-bin::icpc patch-include::c++::cstdio patch-include::c++::cstdlib p atch-include::c++::cwchar applied cleanly. *** Error code 1 Stop in /usr/ports/lang/icc9. Thanks anyway. -- http://scipy.org/FredericPetit ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CONFIGURE_ARGS+
Hello Umar,
This thread is more suitable on freebsd-port Mailinglist.
On Feb 3, 2007, at 8:42, Umar Draz wrote:
Fewdays ago I have installed mysql50-server through ports. During
install I haved edited Makefile and add --disable-shared in
CONFIGURE_ARGS=
Now today I updated my ports tree. and mysql50-server Makefile is
also changeed due to new version so my changing is destroy I want
to upgrade mysql50-server with portupgrade so please help me what
is the best way to add extra CONFIGURE_ARGS in /etc/make.file or /
usr/local/etc/pkgtools.conf that whenever I upgrade my mysql50-
server my configuration not destroy.
This is the default Makefile of databases/mysql50-server
CONFIGURE_ARGS= --localstatedir=/var/db/mysql \
--without-debug \
--without-readline \
--without-libedit \
--without-bench \
--without-extra-tools \
--with-libwrap \
--with-mysqlfs \
--with-low-memory \
--with-comment='FreeBSD port: ${PKGNAME}' \
--enable-thread-safe-client
I don't want to change these default paraments just want to add
extra CONFIGUR_ARGS --disable-shared --with-mysql-user=mysql etc.
Why do want to add --disable-shared?
Beware, if you change the CONFIGURE_ARGS, you are also changing the
plist.
If it would be useful to more people to build mysql with --disable-
shared, you can write a patch to the port and submit it with send-pr.
You can also try to do it in pkgtools.conf.
regards
tilman
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X.org, dlopen and -current problem
Rainer, thank you for answering. No problems. First I should ask some simple questions: - I assume that xorg-server and xorg-libraries were recompiled for the version 6.9.0_6? - How you updated the xorg? Via portupgrade, by hands, some other way? yes, both libraries were recompiled with newest portupgrade, no error message was given. You meant 'both ports'. Fine. And the last simple question: what is the output from 'ldconfig -r| grep libXfont'? Installation should invoke ldconfig, but may be something went wrong. -- Eygene ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Beryl/Compiz ports looking for a maintainer
Hey list, As you know, (at some point) we're working on X.org 7.2 in a different repository. At the moment I have (almost) working ports for compiz and beryl. I currently maintain them but it's taking more time than I want to allow it. Furthermore, I don't want to maintain them when it's going to hit the FreeBSD ports collection and I'm not going to add it without a maintainer set. I first thought I would add it to the list of ports maintained by x11@ but we/they have enough work to do with the current set. So, I'm looking for a maintainer who is responsive, careful, and I guess it's better if he's a committer (but that's not mandatory). If you're interested and already using my git tree, that's a big plus. I'm working at updating beryl ports to 0.1.99.2 (and will probably work on the 0.2.0 update) but I hope this is the last one, cause time spent on beryl ports isn't spent on something else. -- Florent Thoumie [EMAIL PROTECTED] FreeBSD Committer signature.asc Description: OpenPGP digital signature
Re: mc not execute after portupgrading pkg-config\*
On Sat, 3 Feb 2007 01:13:40 +0100 Daniel Dvořák [EMAIL PROTECTED] wrote: Hi all, Please do us all a favor and format your emails w/o all this black lines. Please read http://www.lemis.com/questions.html and pages linked there to help us help you. [EMAIL PROTECTED] is just the list for GNATS, no use to port on it. Thanks, -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect Ferengi Rule of Acquisition #79: Beware of the Vulcan greed for knowledge. -- ST: Legends of the Ferengi signature.asc Description: PGP signature
Re: ports/102499: lftp asc file checksum mismatch
Kris Kennaway wrote: On Thu, Jan 25, 2007 at 01:48:02AM +0300, Roman Kurakin wrote: that lftp gets a corrupted distfile when fetching through a squid proxy. This is because in the default configuration squid fetches all plain text files in ftp ascii mode, which does CR/LF translation and botches up the checksum. IIRC this is not a bug and squid do not translate in all cases Any way the file is marked as a text and any such translation do not look like a violation. I guess it was done for convenience of M$ users. Bug in the sense of broken behaviour. IMO it is broken behaviour for squid to force a non-default translation policy on the client. If a FTP client really wants a non-default translation mode the protocol allows them to specify it. IIRC it is impossible to switch this off in squid (this is the only thing they was wrong). It can be corrected by editing squid's mime.conf. My point of view that we should not blame the squid, this wouldn't help. Now I know that there is such problem, you know, a couple of peoples who will read this. But for the rest the project would look in the bad way. More over not all peoples can control which proxy in front of them even if they know about this problem. My idea was to tech a fetch to request a binary mode for all files despite of their mime type. This may not be hard to do, can you look into it? I've made a patch but it was ugly and was broken by update of libfetch. I'll try to check the current state of libfetch and update my patch. rik The other option would be for the squid port to install a fixed mime.conf. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Beryl/Compiz ports looking for a maintainer
2007. February 3. 19.42 dátummal Florent Thoumie ezt írta: Hey list, As you know, (at some point) we're working on X.org 7.2 in a different repository. At the moment I have (almost) working ports for compiz and beryl. I currently maintain them but it's taking more time than I want to allow it. Furthermore, I don't want to maintain them when it's going to hit the FreeBSD ports collection and I'm not going to add it without a maintainer set. I first thought I would add it to the list of ports maintained by x11@ but we/they have enough work to do with the current set. So, I'm looking for a maintainer who is responsive, careful, and I guess it's better if he's a committer (but that's not mandatory). If you're interested and already using my git tree, that's a big plus. I'm working at updating beryl ports to 0.1.99.2 (and will probably work on the 0.2.0 update) but I hope this is the last one, cause time spent on beryl ports isn't spent on something else. I just want to thank you for your work for bringing this amazing technology to FreeBSD. I also browsed their forums, and noticed that 0.2.0 rc1 is seriously broken for many users, so its probably better to wait for final (if you were going to update it to rc1). http://forum.beryl-project.org/viewtopic.php?f=36t=3002 As to your request - I'm neither a commiter, nor qualified (I'm not a programmer) to help you with maintaining beryl (only tried porting little things like kde styles or windecos - stuff that don't debugging code skills). Unfortunately. Thanks again for your efforts (and the x11 team)! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: /usr/bin/objformat fallout
THE PROBLEM Recently the /usr/bin/objformat binary was finally removed from FreeBSD 7.0. This binary only existed to report the default system binary format (elf or aout) and was introduced during the a.out/ELF transition back in the 3.x days. Ever since FreeBSD 3.x it defaulted to elf, and FreeBSD 4.x and above removed all support for running an a.out-based system. The plan was always to remove this transition aid once the ELF conversion was complete. For various reasons this was overlooked until recently, and unfortunately in the meantime it has migrated into numerous upstream applications with incorrect usage. There are a large number of third party ported software which interprets the lack of an /usr/bin/objformat binary to mean we are running on a pre-FreeBSD 3.x a.out system, and fails to build or install correctly on modern FreeBSD systems. THE GOOD NEWS Most of these problems are localized in the internal (outdated) copy of libtool which many ports use. Fortunately, modern versions of libtool have apparently fixed their incorrect use of objformat, and the quick fix for many ports is to USE_AUTOTOOLS=libtool:15 to force the use of the libtool port instead of their broken old internal copy. THE BAD NEWS Some ports have more extensive problems that cannot be fixed with this strategy (or it creates other problems like creating lib.a files for plugin libraries which makes no sense). They are still easy to fix though, it's just a matter of locating the objformat check(s) and making sure that they work correctly without objformat present (i.e. fall back to elf instead of aout). FREQUENTLY ASKED QUESTIONS Q. I'm not running FreeBSD 7, how will this affect me? A. It won't. Q. What is portmgr doing about it??! A. Since I bear some degree of responsibility for this problem coming to light [1] I've been working on testing and committing fixes to those ports which can be fixed using the libtool workaround. By now almost all ports are fixed, except for some ports which are waiting on maintainers to act, and some parts of gnome which are taking longer to work through because there are many layers of libraries involved, requiring repeated iterations of testing. Q. Oh my god I cannot handle a few broken ports on my system! A. First, that's not a question. Second, relax :) If you don't want to deal with this situation on FreeBSD 7.0, then either just don't delete your copy of /usr/bin/objformat or put it back (and then consider dropping back to running 6.x, because there are worse problems on the horizon, e.g. the gcc 4.x import). Unless you are maintainer of an affected port, in which case: suck it up, soldier! Q. But can't you make some kind of wonderful bsd.port.mk hack that will fix this problem invisibly? A. Yes, but we don't want to do that. This problem has been allowed to persist and propagate for too long, and unless we involve individual port maintainers and get them to push the fixes back upstream, it's only going to keep propagating out in the wild as the various Linux-centric projects out there copy from one another about how to properly add FreeBSD support. Q. What can I do to help? A. If you get an email from me about a problem with your port, follow the instructions and make the relevant fixes. If you find a problem with a port I have already committed a fix to, let me know. Other than that there's not much more you can do for now - I'm still running repeated builds pushing out the USE_AUTOTOOLS deployment, and having others also trying to work on those affected ports at the same time will hinder me more than it will help. In a few days I will send email about the remaining few unmaintained ports that need to be fixed. I will also be contacting the maintainers of ports for which I added the libtool15 dependency, so they can contact the upstream authors about deploying a corresponding fix. Kris [1] http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/objformat/Attic/objformat.c?hideattic=0 pgpxVqQAizvVa.pgp Description: PGP signature
Re: FreeBSD Port: devel/libtool15 doesn't build in 2 of my servers
On 2 Feb, Abdullah Ibn Hamad Al-Marri wrote: Hello, I have 2 servers, and libtool wont upgrade on both of them. configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands === Building for libtool-1.5.22_3 Making all in . CONFIG_FILES=libtoolize CONFIG_HEADERS= /bin/sh ./config.status config.status: creating libtoolize config.status: executing depfiles commands chmod +x libtoolize Making all in libltdl cd . /bin/sh /usr/ports/devel/libtool15/work/libtool-1.5.22/libltdl/missing --run aclocal-1.9a aclocal-1.9a: not found WARNING: `aclocal-1.9a' is missing on your system. You should only need it if you modified `acinclude.m4' or `configure.ac'. You might want to install the `Automake' and `Perl' packages. Grab them from any GNU archive site. cd . /bin/sh /usr/ports/devel/libtool15/work/libtool-1.5.22/libltdl/missing --run autoheader /usr/local/bin/gm4:configure.ac:43: bad regular expression: `AS_ESCAPE([$as_me:$LINENO: WARNING: *** The top-level configure must select either], [`])': Invalid range end /usr/local/bin/gm4:configure.ac:43: bad regular expression: `AS_ESCAPE([$as_me: WARNING: *** The top-level configure must select either], [`])': Invalid range end /usr/local/bin/gm4:configure.ac:45: bad regular expression: `AS_ESCAPE([$as_me:$LINENO: error: *** Maybe you want to --enable-ltdl-install?], [`])': Invalid range end /usr/local/bin/gm4:configure.ac:45: bad regular expression: `AS_ESCAPE([$as_me: error: *** Maybe you want to --enable-ltdl-install?], [`])': Invalid range end configure.ac:53: error: Autoconf version 2.59c or higher is required aclocal.m4:387: AM_INIT_AUTOMAKE is expanded from... configure.ac:53: the top level autoheader: autom4te failed with exit status: 1 at /usr/local/bin/autoheader line 163 *** Error code 1 Stop in /usr/ports/devel/libtool15/work/libtool-1.5.22/libltdl. I just ran into this same problem. I tracked the cause to some old copies of the auto* tools installed under /usr/local/bin without any version suffix. These files were unclaimed by any currently installed port. The libtool build was using these older executables instead of the newer ones with the version suffix and running into problems because the tools were too old. I deleted these old files and now the libtool build succeeds. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X.org, dlopen and -current problem
On 2/4/07, Eygene Ryabinkin [EMAIL PROTECTED] wrote: yes, both libraries were recompiled with newest portupgrade, no error message was given. You meant 'both ports'. Fine. And the last simple question: what is the output from 'ldconfig -r| grep libXfont'? Installation should invoke ldconfig, but may be something went wrong. -- Eygene I have mine here: [ [EMAIL PROTECTED] ~] $ ldconfig -r| grep libXfont 110:-lXfont.1 = /usr/X11R6/lib/libXfont.so.1 Both ports were recompiled when the issue first came up. Jiawei Ye -- If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
