Re: RFC: Merging X11BASE to LOCALBASE
What's the gain? Transition will be a really big PITA for most existing
users. Everybody who would be trying to install a KDE/GNOME or even a
general X11 port after a switchover still having all X11 bits in
/usr/X11R6 is likely to be screwed on build time, due to mismatching
includes/libraries search paths. And I am not even telling about
run-time problems with datafiles in KDE/GNOME.
The only way to handle such a merge for ordinary Joe User would be to
remove all X11 bits and pieces and compile/install everything from
scratch. And despite what X11 maintainers may believe (due to the nature
of their position they
compile/install/remove/compile/install/remove/.../ad infinite all X11
bits and pieces every day), ordinary Joe User doesn't like such gross
upgrades, since even with the best packaging system in the world
virtually any such upgrade will bring new unanticipated problems to the
system that otherwise has been working before upgrade just fine.
Therefore, I doubt that such "pull the trigger" approach is really going
to work in this case. Some more gradual course is in due: with X11R6
being banned as a target for a new ports, with new GNOME version moving
to the LOCALBASE and so on.
-Maxim
Dejan Lesjak wrote:
Hello,
There were a couple of debates already concerning /usr/X11R6 as prefix for X11
ports and a bunch of other ports that currently by default install there.
Quite some people were, when creating a new port that depends on X11,
wandering whether to put it in X11BASE or LOCALBASE. More than once a
question of whether the prefix /usr/X11R6 should be just dropped or at least
only retained for core X11 distribution. With the upcoming X.org 7.x ports
there is perhaps the opportunity to do the prefix merger along that.
Moving X11 prefix to LOCALBASE would simplify above dilemma. It would be also
more similar to where linux distributions are going (at least Gentoo, Debian
and Fedora deprecated /usr/X11R6 in favour of /usr which, while
not /usr/local is the location of where all packages install - depending on
X11 or not). If I remember correctly from previous discussions, it would be
more convenient to people with separate mounts for installed packages as
well. /usr/local is also the default value for --prefix configure option for
X.org packages.
So it is general intention to go with /usr/local or rather ${LOCALBASE} as
prefix for X11 ports. If anyone feels that this is horribly wrong, please
speak up.
On behalf of x11 team,
Dejan
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
On Thu, 2006-07-13 at 23:58 -0700, Maxim Sobolev wrote:
> What's the gain? Transition will be a really big PITA for most existing
> users. Everybody who would be trying to install a KDE/GNOME or even a
> general X11 port after a switchover still having all X11 bits in
> /usr/X11R6 is likely to be screwed on build time, due to mismatching
> includes/libraries search paths. And I am not even telling about
> run-time problems with datafiles in KDE/GNOME.
>
> The only way to handle such a merge for ordinary Joe User would be to
> remove all X11 bits and pieces and compile/install everything from
> scratch. And despite what X11 maintainers may believe (due to the nature
> of their position they
> compile/install/remove/compile/install/remove/.../ad infinite all X11
> bits and pieces every day), ordinary Joe User doesn't like such gross
> upgrades, since even with the best packaging system in the world
> virtually any such upgrade will bring new unanticipated problems to the
> system that otherwise has been working before upgrade just fine.
>
> Therefore, I doubt that such "pull the trigger" approach is really going
> to work in this case. Some more gradual course is in due: with X11R6
> being banned as a target for a new ports, with new GNOME version moving
> to the LOCALBASE and so on.
We (the FreeBSD GNOME Team) are discussing such an approach for the
upcoming GNOME 2.16 release. We will be transitioning to LOCALBASE
following the 2.15.4 development release.
Joe
>
> -Maxim
>
> Dejan Lesjak wrote:
> > Hello,
> >
> > There were a couple of debates already concerning /usr/X11R6 as prefix for
> > X11
> > ports and a bunch of other ports that currently by default install there.
> > Quite some people were, when creating a new port that depends on X11,
> > wandering whether to put it in X11BASE or LOCALBASE. More than once a
> > question of whether the prefix /usr/X11R6 should be just dropped or at
> > least
> > only retained for core X11 distribution. With the upcoming X.org 7.x ports
> > there is perhaps the opportunity to do the prefix merger along that.
> > Moving X11 prefix to LOCALBASE would simplify above dilemma. It would be
> > also
> > more similar to where linux distributions are going (at least Gentoo,
> > Debian
> > and Fedora deprecated /usr/X11R6 in favour of /usr which, while
> > not /usr/local is the location of where all packages install - depending on
> > X11 or not). If I remember correctly from previous discussions, it would be
> > more convenient to people with separate mounts for installed packages as
> > well. /usr/local is also the default value for --prefix configure option
> > for
> > X.org packages.
> > So it is general intention to go with /usr/local or rather ${LOCALBASE} as
> > prefix for X11 ports. If anyone feels that this is horribly wrong, please
> > speak up.
> >
> > On behalf of x11 team,
> > Dejan
>
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
--
PGP Key : http://www.marcuscom.com/pgp.asc
signature.asc
Description: This is a digitally signed message part
Re: emulators/wine - linker error
Gerald Pfeifer wrote: > On Tue, 11 Jul 2006, [LoN]Kamikaze wrote: >> The latest version of the port fails with the following output on my >> system (FBSD 6.1): >> >> cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT >> -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ >> -Wdeclaration-after-statement -Wpointer-arith -I/usr/local/include -O2 -pipe >> -march=pentium-m -o parse.o parse.c >> parse.c: In function `ldap_parse_sort_controlW': >> parse.c:238: warning: implicit declaration of function >> `ldap_parse_sort_control' >> parse.c: In function `ldap_parse_vlv_controlW': >> parse.c:292: warning: implicit declaration of function >> `ldap_parse_vlv_control' > > My guess is you have some packages installed, which make Wine's > configure detect support for LDAP, but the implementation is not > sufficient to really build. > > One of the weaknesses of the FreeBSD Ports Collection is that building > on your local machine may find packages, and change the behavior of the > build, which the package maintainer never has seen nor tested against. > > I believe that if you do a > > % pkg_info | grep ldap > > you will find packages different from openldap-client, and if you remove > all (or some) of these, the Wine build will succeed. > > Looking at upstream changes, it looks as if some things have changed > in the meantime. > > Gerald > Thanks, that did the trick! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: emulators/wine - linker error
On Fri, 14 Jul 2006, [LoN]Kamikaze wrote: >> I believe that if you do a >> >> % pkg_info | grep ldap >> >> you will find packages different from openldap-client, and if you remove >> all (or some) of these, the Wine build will succeed. >> >> Looking at upstream changes, it looks as if some things have changed >> in the meantime. > Thanks, that did the trick! Good. If you also see that same issue with the next release of Wine (that is, it hasn't been fixed as I believe), please let me know which LDAP-related packages you've had to remove, and I'll see whether I can reproduce it on my side and work on a fix together with upstream. Gerald ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Possibly unbuildable ports reminder
Dear porters, This is just a reminder to please periodically check the list of unbuildable ports at http://pointyhat.freebsd.org/errorlogs/ . A list by MAINTAINER is http://people.freebsd.org/~fenner/errorlogs/ so you can easily check the status of ports that you maintain. In addition, the list of ports with no MAINTAINER with build problems is http://people.freebsd.org/~fenner/errorlogs/[EMAIL PROTECTED] Since no one is responsible for these ports, the problem won't get fixed unless someone on this list takes the initiative. Thanks for your help! Bill "annoying port email" Fenner ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
On Friday 14 July 2006 08:58, Maxim Sobolev wrote: > What's the gain? I believe I mentioned some of gains in first mail. There is also the benefit of less divergence to upstreams as ./configure scripts of various ports use /usr/local as default prefix, but more importantly as modular X.org is becoming more widespread there is tendency of various packagers (for example Linux distributions already mentioned) to install all packages under same prefix. We expect that if we follow that trend, we would make maintainers and users' lives a bit easier in the long run. > Transition will be a really big PITA for most existing > users. Everybody who would be trying to install a KDE/GNOME or even a > general X11 port after a switchover still having all X11 bits in > /usr/X11R6 is likely to be screwed on build time, due to mismatching > includes/libraries search paths. And I am not even telling about > run-time problems with datafiles in KDE/GNOME. Having two prefixes we could also be just papering over some of the conflicts that could result in mysterious, hard to detect errors that could perhaps be detected sooner if we had only one prefix and thus easier to find if two ports conflict by installing file with same name. Message http://lists.freebsd.org/pipermail/freebsd-ports/2006-July/033956.html could be example of such case. As for KDE/GNOME, it was thought that converting GNOME would present one of major hurdles at transition. With responses so far, perhaps things are not so horrible as I feared though. GNOME team is already planning the transition and we'll see how it fares. If it is indeed found out that the pain of transition overweights gains then it can still be decided to keep /usr/X11R6 prefix. The X11 team is rather hoping this will cause less pain in the long run for everybody - as far as X.org 7 ports themselves go, they right now already happily build and install under /usr/X11R6 prefix so going with it would save us some time, but we think we would loose the opportunity to handle PREFIX transition that way. > The only way to handle such a merge for ordinary Joe User would be to > remove all X11 bits and pieces and compile/install everything from > scratch. That would be exactly the reason I believe the upgrade to X.org 7.x would be the best time to do that with X.org ports - all X11 bits and pieces would have to be upgraded at that time anyway with a good chance that at least some of dependencies on X11 would have to be upgraded as well. If it is agreed upon that /usr/X11R6 -> /usr/local as default is the way to go, then it would be better to do it at that time, rather than doing it sometime later and cause pain for users twice. > And despite what X11 maintainers may believe (due to the nature > of their position they > compile/install/remove/compile/install/remove/.../ad infinite all X11 > bits and pieces every day), ordinary Joe User doesn't like such gross > upgrades, since even with the best packaging system in the world > virtually any such upgrade will bring new unanticipated problems to the > system that otherwise has been working before upgrade just fine. Due to the change in X.org 7.x, namely the switch to modular packages, there will already be a bit of pain for users to upgrade. If we generally agree upon /usr/local prefix then perhaps doing it at the same time might mean a bit more concentrated pain at one time, but at the same time make transition shorter than doing the two transitions at separate times. > Therefore, I doubt that such "pull the trigger" approach is really going > to work in this case. Some more gradual course is in due: with X11R6 > being banned as a target for a new ports, with new GNOME version moving > to the LOCALBASE and so on. I seem to have phrased my mail a bit weird. There's no intention of "pulling the trigger", say tomorrow and pull the rug from under users' and maintainers' feet. Of course we would like to do things gradually so to hurt users and maintainers the least as possible. The mail was meant to indicate the general direction of where we would like to go with X.org ports as far as PREFIX is concerned, to prompt people to voice their disagreements/agreements, and to find out how we can do it so as to cause as little pain as possible. It should certainly not be viewed as "we plan to import X.org 7 into ports next week and make /usr/local default prefix so deal with it". If it sounded like that I do apologize. Dejan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
On Friday 14 July 2006 01:59, [EMAIL PROTECTED] wrote:
> Hi;
>
> Just here mumbling...
>
> It would be interesting to set
>
> X11BASE=/usr/X11 when using XFree86 and
> X11BASE=${LOCALBASE} when using XOrg.
>
> Not only due to historical consistency (/usr/X11 is the path recommended in
> XFree86 manpages), but as a way to be able to use XFree86 and keep the
> system somewhat cleaner.
Well, I was planing XFree86 would move to LOCALBASE as well - if it doesn't,
ports depending on X11 would have to special case XFree86 libraries and
includes and such, which would make system a bit less clean. Why do you think
using /usr/X11 would make things cleaner?
Dejan
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
Hello;
--- Dejan Lesjak <[EMAIL PROTECTED]> ha scritto:
> On Friday 14 July 2006 01:59, [EMAIL PROTECTED] wrote:
> > Hi;
> >
> > Just here mumbling...
> >
> > It would be interesting to set
> >
> > X11BASE=/usr/X11 when using XFree86 and
> > X11BASE=${LOCALBASE} when using XOrg.
> >
> > Not only due to historical consistency (/usr/X11 is the path recommended in
> > XFree86 manpages), but as a way to be able to use XFree86 and keep the
> > system somewhat cleaner.
>
> Well, I was planing XFree86 would move to LOCALBASE as well - if it doesn't,
> ports depending on X11 would have to special case XFree86 libraries and
> includes and such, which would make system a bit less clean. Why do you think
>
Hmm.. there should be no need to have special cases for ports that properly
respect X11BASE. Ports that don't respect X11BASE (those that have /usr/X11R6
hard coded) should be cleaned/fixed anyways.
> using /usr/X11 would make things cleaner?
>
I haven't checked lately but XFree86 and XOrg are currently in conflict aren't
they? One has to deinstall and rebuild all the packages built with XOrg and
start a fresh build to use XFree86. Having XFree86 on it's own prefix would
avoid the problem of having packages built with the wrong version of X and it
also make an eventual clean up easier.
I think the user perceived default wouldn't change, with most people using XOrg
in LOCALBASE, and some people using XFree86 in X11BASE. Of course if eventually
X11BASE disappears is another matter, but at least for backwards compatibility
(4.x?) it's good to have it for a while.
just my 0.02$
Pedro.
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vmware server now is free,can anyone bring it to ports?
On Jul 13, 2006, at 4:51 PM, Benjamin Lutz wrote: On Thursday 13 July 2006 04:29, lveax wrote: vmware server 1.0 was released and free for download,there are windows and linux version,would anyone bring the linux version to freebsd ports? Unlikely to happen, since VMWare uses a linux kernel module. The VMWare workstation product was ported for older versions, so it is possible to back-hack the kernel module into freebsd.
Problems creating port, pkg_info?
I'm working on porting libdssialsacompat to FreeBSD so that the dssi plugin distribution might compile (this should open up the possibility of quite a lot more audio software being ported to FreeBSD) but I'm having trouble. I've never created a port before, so bare with me... --Makefile-- # New ports collection makefile for: libdssialsacompat # Date created: 14 July 2006 # Whom: # # $FreeBSD$ # PORTNAME= libdssialsacompat PORTVERSION= 1.0.8a CATEGORIES= audio MASTER_SITES= http://home.jps.net/~musound/ MAINTAINER= COMMENT= Alsa compatibility library to build DSSI .include -- (Whom and MAINTAINER left blank for now as I'm not sure what'll go here yet). --pkg-plist-- @dirrm include/dssi @dirrm include/dssi/alsa include/dssi/alsa/asoundef.h include/dssi/alsa/asoundlib.h include/dssi/alsa/seq.h include/dssi/alsa/seq_event.h include/dssi/alsa/seq_midi_event.h include/dssi/alsa/sound/asequencer.h lib/libdssialsacompat.so.0 lib/libdssialsacompat.so.0 lib/libdssialsacompat.a lib/libdssialsacompat.so lib/libdssialsacompat.la -- --pkg-desc-- libdssialsacompat is simply an extraction from and repackaging of the code from alsa-lib 1.0.8, necessary to support DSSI on non-ALSA systems. http://home.jps.net/~musound/ More information on DSSI can be found at: http://dssi.sourceforge.net/ -- I've set up a directory to put the port together in and: $ export DISTDIR="/home/mc/src/libdssialsacompat_port/tempdist" Now: $ make makesum $ make ===> Extracting for libdssialsacompat-1.0.8a => MD5 Checksum OK for libdssialsacompat-1.0.8a.tar.gz. => SHA256 Checksum OK for libdssialsacompat-1.0.8a.tar.gz. ===> libdssialsacompat-1.0.8a depends on file: /usr/local/sbin/pkg_info - not found ===>Verifying install for /usr/local/sbin/pkg_info in /usr/ports/sysutils/pkg_install ===> Extracting for pkg_install-20060113 => MD5 Checksum OK for pkg_install-20060113.tar.gz. => SHA256 Checksum OK for pkg_install-20060113.tar.gz. mkdir: /usr/ports/sysutils/pkg_install/work: Permission denied *** Error code 1 Stop in /usr/ports/sysutils/pkg_install. *** Error code 1 Stop in /usr/home/markzero/src/libdssialsacompat_port. On my system, pkg_info is in /usr/sbin. Why is the ports system looking in /usr/local/sbin? Of course, this results in a permission error as I'm working as a regular user. MC ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports/100042: [PATCH] lang/tolua++: update to 1.0.92
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When testing this patch I get the following error: ===> Registering installation for lua-5.0.2_1 ===> Returning to build of tolua++-1.0.92 ===> Configuring for tolua++-1.0.92 ===> Building for tolua++-1.0.92 scons: Reading SConscript files ... TypeError: can only concatenate list (not "str") to list: *** Error code 2 Stop in /usr/ports/lang/tolua++. File "SConstruct", line 131: env['LIBPATH'] = ['#/lib'] + env['LIBPATH'] Seems like an error in the more general USE_SCONS framework. - -- Aaron Dalton [EMAIL PROTECTED] FreeBSD Ports Committer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEt8EtvlYKTYgR0qQRAtmuAJ9LBbn10LhBUdsuBXlmzoFaHlToWwCg1Xj4 Azy4e+P7Eg+7m/5x/sbME9A= =5jHF -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
On Fri, 14 Jul 2006 09:09:27 -0500, <[EMAIL PROTECTED]> wrote:
Hello;
--- Dejan Lesjak <[EMAIL PROTECTED]> ha scritto:
On Friday 14 July 2006 01:59, [EMAIL PROTECTED] wrote:
> Hi;
>
> Just here mumbling...
>
> It would be interesting to set
>
> X11BASE=/usr/X11 when using XFree86 and
> X11BASE=${LOCALBASE} when using XOrg.
>
> Not only due to historical consistency (/usr/X11 is the path
recommended in
> XFree86 manpages), but as a way to be able to use XFree86 and keep the
> system somewhat cleaner.
Well, I was planing XFree86 would move to LOCALBASE as well - if it
doesn't,
ports depending on X11 would have to special case XFree86 libraries and
includes and such, which would make system a bit less clean. Why do you
think
Hmm.. there should be no need to have special cases for ports that
properly
respect X11BASE. Ports that don't respect X11BASE (those that have
/usr/X11R6
hard coded) should be cleaned/fixed anyways.
using /usr/X11 would make things cleaner?
I haven't checked lately but XFree86 and XOrg are currently in conflict
aren't
they? One has to deinstall and rebuild all the packages built with XOrg
and
start a fresh build to use XFree86. Having XFree86 on it's own prefix
would
avoid the problem of having packages built with the wrong version of X
and it
also make an eventual clean up easier.
Nobody should install both xorg and xfree86 at the same time. It's pretty
pointless and it would cause more messy when you try to build other ports
that depend on either of it. Move everything in LOCALBASE, nothing more
and nothing less, is much cleaner.
Cheers,
Mezz
I think the user perceived default wouldn't change, with most people
using XOrg
in LOCALBASE, and some people using XFree86 in X11BASE. Of course if
eventually
X11BASE disappears is another matter, but at least for backwards
compatibility
(4.x?) it's good to have it for a while.
just my 0.02$
Pedro.
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
--
[EMAIL PROTECTED] - [EMAIL PROTECTED]
FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src)
http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED]
http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: print/cups-base 1.2.0_2 and locally connected printer
Heino Tiedemann wrote: > I found 2 Solutions fpr the permissions: > > > Solution a) > > , > | I've added the following to /etc/devfs.conf: > | own lpt0root:cups > | permlpt00660 > ` > > > > Solution b) > , > | Add following lines to /etc/devfs.rules: > | > | [system=10] > | add path 'lpt*' mode 0660 group cups > | > | And following to /etc/rc.conf: > | > | devfs_system_ruleset="system" > ` > > > Is there one way to prefer? Solution a) only works for devices which are present when the system boots up. It is fine for parallel port. Solution b) works for devices that come and go, too. It is required for ulpt devices. Ulrich Spoerlein -- PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. pgp0ltpPz2fBJ.pgp Description: PGP signature
Re: RFC: Merging X11BASE to LOCALBASE
--- Jeremy Messenger <[EMAIL PROTECTED]> ha scritto: > > Nobody should install both xorg and xfree86 at the same time. It's pretty > pointless and it would cause more messy when you try to build other ports > that depend on either of it. Move everything in LOCALBASE, nothing more > and nothing less, is much cleaner. > Consider the following scenario: Happy owner of an (lets say) ATI card wants to use FreeBSD but he REALLY needs OpenGL. He decides to give XFree86 a try since he has heard on XOrg the accelerated OpenGL doesn't work very well yet. Happy owner installs some non-X packages and then installs XFree86. He then goes throught the work of setting up his build for building everything with XFree86. When a "working" XOrg release comes he'll have to massively deinstall packages including XFree86 (and his configuration files) just to check if XOrg now works. Having it's own prefix, he still has to remove packages, but at least now he knows most of the conflicting packages will be in /usr/X11, and if there is "garbage" left he can still do rm -rf /usr/X11 without fear of removing non-X stuff. If POLA is important here, I guess leaving X11BASE as it is now (/usr/X11R6) for XFree86 is the way to go. I'm not saying we should be able to run different Xservers in the same box (although that is not a bad idea altogether), but that we could, and should, alleviate the issues of people wanting to run XFree86, especially since it comes at no cost. Pedro Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
On 7/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: --- Jeremy Messenger <[EMAIL PROTECTED]> ha scritto: > > Nobody should install both xorg and xfree86 at the same time. It's pretty > pointless and it would cause more messy when you try to build other ports > that depend on either of it. Move everything in LOCALBASE, nothing more > and nothing less, is much cleaner. > Consider the following scenario: Happy owner of an (lets say) ATI card wants to use FreeBSD but he REALLY needs OpenGL. He decides to give XFree86 a try since he has heard on XOrg the accelerated OpenGL doesn't work very well yet. Happy owner installs some non-X packages and then installs XFree86. He then goes throught the work of setting up his build for building everything with XFree86. When a "working" XOrg release comes he'll have to massively deinstall packages including XFree86 (and his configuration files) just to check if XOrg now works. Having it's own prefix, he still has to remove packages, but at least now he knows most of the conflicting packages will be in /usr/X11, and if there is "garbage" left he can still do rm -rf /usr/X11 without fear of removing non-X stuff. If POLA is important here, I guess leaving X11BASE as it is now (/usr/X11R6) for XFree86 is the way to go. I'm not saying we should be able to run different Xservers in the same box (although that is not a bad idea altogether), but that we could, and should, alleviate the issues of people wanting to run XFree86, especially since it comes at no cost. for the few people this would apply to they could always add something to make.conf to install Xfree86 in /usr/X11R6 or xorg or what ever and have both installed. Pedro Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
--- michael johnson <[EMAIL PROTECTED]> ha scritto: ... > > > for the few people this would apply to they could always add something to > make.conf to install Xfree86 in /usr/X11R6 or xorg or what ever and have > both installed. > Of course X11BASE can still be more documented in the section where setting XFree86 is explained, but life is already pretty hard for people wanting to use XFree86 (no packages for KDE, GNOME, etc...), why make it harder? cheers, Pedro. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
Dejan Lesjak wrote: > On Friday 14 July 2006 08:58, Maxim Sobolev wrote: >> What's the gain? > > I believe I mentioned some of gains in first mail. There is also the benefit > of less divergence to upstreams as ./configure scripts of various ports > use /usr/local as default prefix, but more importantly as modular X.org is > becoming more widespread there is tendency of various packagers (for example > Linux distributions already mentioned) to install all packages under same > prefix. We expect that if we follow that trend, we would make maintainers and > users' lives a bit easier in the long run. Note, I am still making up my mind about whether what you're proposing is a good idea or not, so I'm not intending this as a criticism. However, the argument you propose above as a benefit for the move is completely specious. Our ports are supposed to be prefix-clean no matter what the defaults in the distributed software are, and no matter what prefix the user chooses. Thus (other than ports which are broken now which need fixing anyway), the only thing this move will do is ADD work for maintainers (at least in the short run), it will not make anyone's life easier in this area. I would also like to reinforce Maxim's point here, since I think it's getting lost in the shuffle. The burden to the users is NOT just reinstalling, which with modern tools like portmaster or portupgrade should be pretty painless, if not time consuming. There is also the burden to our users of editing config files, firefox app preferences, etc. etc. Some of these can be handled automatically by the ports, many of them cannot. Frankly, I'm still waiting to hear some really good reasons to make this change, but my mind is still open. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
On Fri, Jul 14, 2006 at 09:17:56PM +0200, [EMAIL PROTECTED] wrote: > but life is already pretty hard for people wanting to use > XFree86 (no packages for KDE, GNOME, etc...) We simply don't have the horsepower on the build cluster, or disk space on the mirrors, to support this. It takes 5 days to build i386 sources as it is, and nearly a month to build the others. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
On Fri, Jul 14, 2006 at 12:33:22PM -0700, Doug Barton wrote: > Dejan Lesjak wrote: > > On Friday 14 July 2006 08:58, Maxim Sobolev wrote: > >> What's the gain? > > > > I believe I mentioned some of gains in first mail. There is also the > > benefit > > of less divergence to upstreams as ./configure scripts of various ports > > use /usr/local as default prefix, but more importantly as modular X.org is > > becoming more widespread there is tendency of various packagers (for > > example > > Linux distributions already mentioned) to install all packages under same > > prefix. We expect that if we follow that trend, we would make maintainers > > and > > users' lives a bit easier in the long run. > > Note, I am still making up my mind about whether what you're proposing is a > good idea or not, so I'm not intending this as a criticism. However, the > argument you propose above as a benefit for the move is completely specious. > Our ports are supposed to be prefix-clean no matter what the defaults in the > distributed software are, and no matter what prefix the user chooses. Thus > (other than ports which are broken now which need fixing anyway), the only > thing this move will do is ADD work for maintainers (at least in the short > run), it will not make anyone's life easier in this area. > > I would also like to reinforce Maxim's point here, since I think it's > getting lost in the shuffle. The burden to the users is NOT just > reinstalling, which with modern tools like portmaster or portupgrade should > be pretty painless, if not time consuming. There is also the burden to our > users of editing config files, firefox app preferences, etc. etc. Some of > these can be handled automatically by the ports, many of them cannot. Assuming we deal with all the conflicting ports in the first round I don't fully buy this argument. If most people can simply upgrade the ports in question then "rm -rf /usr/X11RC && ln -s /usr/local /usr/X11R6" will take care of config files. That's admittedly a large assumption, but I don't think it's all that unreasonable. I think the argument for this change is that the use of X11BASE is pretty much random so it's no longer serving any useful purpose and the lack of consistency is a minor negative since you never know where an X related port will end up without reading the Makefile. -- Brooks pgpMApltmypaI.pgp Description: PGP signature
Re: RFC: Merging X11BASE to LOCALBASE
On Friday 14 July 2006 21:33, Doug Barton wrote: > Dejan Lesjak wrote: > > On Friday 14 July 2006 08:58, Maxim Sobolev wrote: > >> What's the gain? > > > > I believe I mentioned some of gains in first mail. There is also the > > benefit of less divergence to upstreams as ./configure scripts of various > > ports use /usr/local as default prefix, but more importantly as modular > > X.org is becoming more widespread there is tendency of various packagers > > (for example Linux distributions already mentioned) to install all > > packages under same prefix. We expect that if we follow that trend, we > > would make maintainers and users' lives a bit easier in the long run. > > Note, I am still making up my mind about whether what you're proposing is a > good idea or not, so I'm not intending this as a criticism. However, the > argument you propose above as a benefit for the move is completely > specious. Our ports are supposed to be prefix-clean no matter what the > defaults in the distributed software are, and no matter what prefix the > user chooses. Thus (other than ports which are broken now which need fixing > anyway), the only thing this move will do is ADD work for maintainers (at > least in the short run), it will not make anyone's life easier in this > area. Actually, I didn't mean the prefix that some port installs into would be the truble, rather where given port looks for includes, libraries and other files from ports that it depends upon. Dejan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
Dejan Lesjak wrote: > Actually, I didn't mean the prefix that some port installs into would be the > truble, rather where given port looks for includes, libraries and other files > from ports that it depends upon. But that's all part of the same issue. If the port is prefix-clean, than this won't matter. If it's not, it needs to be fixed, regardless of what the default values of *BASE are. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
Brooks Davis wrote: > Assuming we deal with all the conflicting ports in the first round > I don't fully buy this argument. If most people can simply upgrade > the ports in question then "rm -rf /usr/X11RC && ln -s /usr/local > /usr/X11R6" will take care of config files. That's admittedly a large > assumption, but I don't think it's all that unreasonable. That might add confusion for ports that are still have hidden dependencies on /usr/X11R6, and also won't work at all if the decision is made to keep the xorg/XFree bits in that directory. > I think the argument for this change is that the use of X11BASE is > pretty much random so it's no longer serving any useful purpose and the > lack of consistency is a minor negative since you never know where an X > related port will end up without reading the Makefile. In my mind that's a good argument for making and enforcing consistent policies, not for changing the defaults. But reasonable minds can differ on this issue. Like I said, my mind is not made up yet one way or another, but I have yet to see a very good reason for making the change. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
--- Mark Linimon <[EMAIL PROTECTED]> ha scritto: > On Fri, Jul 14, 2006 at 09:17:56PM +0200, [EMAIL PROTECTED] wrote: > > but life is already pretty hard for people wanting to use > > XFree86 (no packages for KDE, GNOME, etc...) > > We simply don't have the horsepower on the build cluster, or disk space on > the mirrors, to support this. It takes 5 days to build i386 sources as it > is, and nearly a month to build the others. > I know.. and I was not suggesting to fix that :(. I'm not really endorsing the BASE merger either, I just think that if it's going to be done it would be nice to have XFree86 in it's own prefix. At least for 4.x keeping two prefixes seems to be better: I wonder if binary packages will still work properly or not when changing X11BASE and I guess /usr/X11R6 or a symlink will have to be kept in the path for several releases anyway. Pedro. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Merging X11BASE to LOCALBASE
On Thu, 2006-07-13 at 23:58 -0700, Maxim Sobolev wrote: > What's the gain? Transition will be a really big PITA for most existing > users. Everybody who would be trying to install a KDE/GNOME or even a > general X11 port after a switchover still having all X11 bits in > /usr/X11R6 is likely to be screwed on build time, due to mismatching > includes/libraries search paths. And I am not even telling about > run-time problems with datafiles in KDE/GNOME. > > The only way to handle such a merge for ordinary Joe User would be to > remove all X11 bits and pieces and compile/install everything from > scratch. And despite what X11 maintainers may believe (due to the nature > of their position they > compile/install/remove/compile/install/remove/.../ad infinite all X11 > bits and pieces every day), ordinary Joe User doesn't like such gross > upgrades, since even with the best packaging system in the world > virtually any such upgrade will bring new unanticipated problems to the > system that otherwise has been working before upgrade just fine. > > Therefore, I doubt that such "pull the trigger" approach is really going > to work in this case. Some more gradual course is in due: with X11R6 > being banned as a target for a new ports, with new GNOME version moving > to the LOCALBASE and so on. Somehow other distributions have managed to do the transition in a rather painless way. I didn't even know that debian had made the switch, but I dist-upgraded one day and a bit later noticed "oh, hey, /usr/X11R6 is now a couple of symlinks". I personally don't see us making this switch without leaving compat symlinks in for some amount of time either. I think that would deal with the "but all my scripts/preferences/etc.!" complaints, while still giving us the wins of not having to maintain the X11BASE absurdity in ports and people not having to look in both prefixes to find their programs when they're setting up firefox prefs, along with all the other things that we've brought up before. I think we should be able come up with something to do the transition without having to recompile all X11BASE ports. Sure seems to me like that ought to be doable. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: What the hell is going on with mplayer?
On Thu, 13 Jul 2006 18:43:01 +0200 Heino Tiedemann <[EMAIL PROTECTED]> wrote: > Alexander Leidinger <[EMAIL PROTECTED]> wrote: > > > Quoting Heino Tiedemann <[EMAIL PROTECTED]> (from Thu, 13 Jul > > 2006 15:23:07 +0200): > > > >> I just wanted to so a simple »portupgrade mplayer-gtk«, and see what > >> habens: > >> > >> > >> ** Detected a package name change: mplayer-gtk (multimedia/mplayer) > >> -> 'mplayer-gtk2-esound' (multimedia/mplayer) > >> ^^^ > >> What a surprise, name change. Not mentioned in UPDATING > > > > Does it needs to be mentioned? portupgrade is able to handle it > > without *special* instructions in UPDATING. > > Well, okay. this is not necessary. > > But all the new kobs (specially the new defaults!) should be > mentioned. [ ... ] > All the stuff is configurable with "make config". But how should > someone know, that this is specially this time necessary. I 've > mplayer installed, a long time ago. All portupgrades were trouble-free, > since now. > > It COULD be trouble-free, if any information about the new knobs will > be transfered to the users (e.g. in UPDATING). > > A Tip that it is better to run "make config", would be enough. Maybe. The new version of the port was posted for testing here a since a few weeks back. I believe it received 2 or 3 feedback emails (one of which mine). The PR stayed in the queue more that a week. I received exactly one feedback email (from a fellow commiter fixing mostly a few style things). Maybe the maintainer got more feedback on private. I will check the OPTIONS handling and commit the needed fixes, thanks for reporting. This being said, the tone of your emails could be better. -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" BOFH excuse #323: Your processor has processed too many instructions. Turn it off immediately, do not type any commands!! signature.asc Description: PGP signature
Re: RFC: Merging X11BASE to LOCALBASE
Dejan Lesjak wrote: Therefore, I doubt that such "pull the trigger" approach is really going to work in this case. Some more gradual course is in due: with X11R6 being banned as a target for a new ports, with new GNOME version moving to the LOCALBASE and so on. I seem to have phrased my mail a bit weird. There's no intention of "pulling the trigger", say tomorrow and pull the rug from under users' and maintainers' feet. Of course we would like to do things gradually so to hurt users and maintainers the least as possible. The mail was meant to indicate the general direction of where we would like to go with X.org ports as far as PREFIX is concerned, to prompt people to voice their disagreements/agreements, and to find out how we can do it so as to cause as little pain as possible. It should certainly not be viewed as "we plan to import X.org 7 into ports next week and make /usr/local default prefix so deal with it". If it sounded like that I do apologize. Yes, probably "Merging X11BASE to LOCALBASE" is not very good subject after all, seemingly what you are talking about is merely moving x.org 7.x bits and pieces from X11BASE into LOCALBASE, which should be fine. :) You should have mentioned that merging those two is a long term goal and it's not going to happen overnight, since that's what my first impression from the thread was. -Maxim ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Port: mail/postfix
Please see the attached port updated to 2.3.0 - of course up-to-date patches are not yet avaiable for SPF and VDA so it won't compile with those options, and these options should be removed to prevent accidental use from scripts/configure.postfix and distinfo for official distribution. Working for me since yesterday with CYRUS-SASL2, TLS/SSL, DB43 and PGSQL (latest versions of PostgreSQL are required, mine is 7.4.13) options. Regards. This message including all attachments have been scanned for viruses and other malicious content, and are certified as safe by BITNETS.CA ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Lyx is broken on current
The port lyx-1.4.2 is broken on current and has been for awhile: In file included from /usr/local/include/boost/test/utils/nullstream.hpp:23, from ../../src/support/debugstream.h:17, from ../../src/debug.h:16, from math_extern.C:34: /usr/local/include/boost/utility/base_from_member.hpp:73: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. gmake[4]: *** [math_extern.lo] Error 1 gmake[4]: Leaving directory `/usr/ports/print/lyx/work/lyx-1.4.2/src/mathed' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/usr/ports/print/lyx/work/lyx-1.4.2/src/mathed' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/print/lyx/work/lyx-1.4.2/src' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/ports/print/lyx/work/lyx-1.4.2/src' gmake: *** [all-recursive] Error 1 *** Error code 2 Stop in /usr/ports/print/lyx. == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
