Re: who do I report this to?
On Nov 20, 2007 5:11 PM, Aryeh M. Friedman <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Who do I report the following issue to (it falls into at least 3 camps)? > > If I am downloading a torrent in deluge 0.5.6.2_1 *AND* am logged into > gmail (*WITH* a chat open) my network connection looses about 90% of > it's capacity (for all applications), re(4) with the following: > > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > > After some experimenting this problem *only* occurs under the above > conditions. > > Addtional info: > --snip-- The first thing to do is to make sure it is not your ISP inflicting you with some slowdown. Connect a second node to the re interface (put a switch between you and the modem, and connect something else to it) and see if your connection speed to that local machine is affected. If not, then it is your isp that is the problem. Change ISPs to a legitimate one. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: stlport
On Wed, Nov 21, 2007 at 09:23:24PM +0100, Thierry Thomas wrote: > Le Mer 21 nov 07 ? 1:44:33 +0100, Stephen Montgomery-Smith <[EMAIL > PROTECTED]> > ?crivait?: > > > >It didn't build at all on my system. I am sure it is a problem with > > >stlport/config/stl_gcc.h. > > > > > >What version of FreeBSD are you using? Did you build it with gcc or icc? > > > > Adding this attached file to stlport/files made it work for my system. > > Could you please check that my patch provided you the file > files/patch-stlport_stl_config_host.h? This config/host.h is the way to > handle this kind of specificities and should give the same result that > your patch. > Now that you mention it, I can see it in the diff file that you sent me. How do you get patch to behave properly when the file it diffs against doesn't already exist? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
Gergely CZUCZY wrote: > echo 'sevice_enable="YES"' >> /etc/rc.conf.local Yes, I think we all know how to go about this manually. The question at hand is whether or not it's possible or desirable to create the possibility of doing it for the user at port install time. If what you're trying to say here is that you don't find such a facility interesting or necessary, thanks for stating your opinion. 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: octave-forge on FreeBSD 7.0
From: Mark Linimon <[EMAIL PROTECTED]> Subject: Re: octave-forge on FreeBSD 7.0 Date: Wed, 21 Nov 2007 07:59:56 -0600 > I'd rather see USE_GCC set unconditionally, so that INDEX will > be the same on 6 and 7. Me too. > Is there any hope of the software being updated? My concern is > that once we set this, we'll tend to forget about it later. Yes. IMHO, octave-forge should be merged into octave itself, and relese version of octave and corrsponding octave-forge is old. I think this is a temporal situation. Once octave will be updated octave-forge will also be updated, and I believe octave-forge will be built with gcc42. Thanks, -- Nakata Maho ([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: Package Building in the Large
On Mon, 19 Nov 2007, Jason C. Wells wrote: What I am trying to do is to build 30 or so packages including the big ones like X, kde, gnome, plus all of their dependencies on a build host and then use pkg_add on various machines. I have had a variety of difficulties with all of the methods I have used thus far (portmaster, portupgrade, homegrown). What problems did you have with portmaster? Did the backup package creation fail in some way? 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: ports modifying system setups
On Wed, Nov 21, 2007 at 11:43:35PM -0800, Doug Barton wrote: > Gergely CZUCZY wrote: > > > echo 'sevice_enable="YES"' >> /etc/rc.conf.local > > Yes, I think we all know how to go about this manually. The question > at hand is whether or not it's possible or desirable to create the > possibility of doing it for the user at port install time. > > If what you're trying to say here is that you don't find such a > facility interesting or necessary, thanks for stating your opinion. I said, that this can be done from the Makefile as well, if that OPTIONS of yours is enabled. Sincerely, Gergely Czuczy mailto: [EMAIL PROTECTED] -- Weenies test. Geniuses solve problems that arise. pgpzKVaQ9eqzE.pgp Description: PGP signature
Re: ports modifying system setups
On Thu, Nov 22, 2007 at 12:43:50AM -0800, Doug Barton wrote: > On Thu, 22 Nov 2007, Gergely CZUCZY wrote: > > >>Gergely CZUCZY wrote: > >> > >>>echo 'sevice_enable="YES"' >> /etc/rc.conf.local > > >I said, that this can be done from the Makefile as well, if that OPTIONS > >of yours is enabled. > > But that would violate the principle that ports shouldn't touch files in /etc. from rc.conf(5): first: The file /etc/rc.conf.local is used to override settings in /etc/rc.conf for historical reasons. See the rc_conf_files variable below. second: rc_conf_files (str) This option is used to specify a list of files that will override the settings in /etc/defaults/rc.conf. The files will be read in the order in which they are specified and should include the full path to the file. By default, the files specified are /etc/rc.conf and /etc/rc.conf.local So, extend rc_conf_files with /usr/local/etc/rc.conf, that's an acceptable extension IMO, and you're done. ports can touch that. Though, IMO ports could touch the .local files, regardless it's in /etc/. That's why it's rc.conf_.local_ . Anyways, I'm not a core member, it was just a point of view. Sincerely, Gergely Czuczy mailto: [EMAIL PROTECTED] -- Weenies test. Geniuses solve problems that arise. pgp5bW7Rj7e6k.pgp Description: PGP signature
Re: octave-forge on FreeBSD 7.0
> IMHO, octave-forge should be merged into octave itself, > and relese version of octave and corrsponding octave-forge is old. > I think this is a temporal situation. Once octave will be updated > octave-forge will also be updated, and I believe octave-forge > will be built with gcc42. OK, in that case, approved. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
On Thu, 22 Nov 2007, Gergely CZUCZY wrote: Gergely CZUCZY wrote: echo 'sevice_enable="YES"' >> /etc/rc.conf.local I said, that this can be done from the Makefile as well, if that OPTIONS of yours is enabled. But that would violate the principle that ports shouldn't touch files in /etc. 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: stlport
Selon Stephen Montgomery-Smith <[EMAIL PROTECTED]> le Mer 21 nov 22:52:53 2007 : Now that you mention it, I can see it in the diff file that you sent me. How do you get patch to behave properly when the file it diffs against doesn't already exist? If you `cd /usr/ports', patch -p0 < /tmp/stlport.diff should apply everything. Ajust -p0 (-p1, etc.) if you run it from another dir. Regards, -- Th. Thomas. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Please help me update extmail/extman ports
Hi, committer boss. I sent 2 PRs: http://www.freebsd.org/cgi/query-pr.cgi?pr=118181 http://www.freebsd.org/cgi/query-pr.cgi?pr=118180 Please help me commit. Thanks ! -- regards. chifeng ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: stlport
Thierry Thomas wrote: Selon Stephen Montgomery-Smith <[EMAIL PROTECTED]> le Mer 21 nov 22:52:53 2007 : Now that you mention it, I can see it in the diff file that you sent me. How do you get patch to behave properly when the file it diffs against doesn't already exist? If you `cd /usr/ports', patch -p0 < /tmp/stlport.diff should apply everything. Ajust -p0 (-p1, etc.) if you run it from another dir. Regards, It seems to be working. Sorry for the noise. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
if you see undefined symbol '__mb_sb_limit' on 6.x
The ctype fix for UTF-8 locale unfortunately introduced some new symbols to libc. Therefore, binaries built on system with that fix can not be used on older system. For that sake, the fix is back-out for 6-STABLE. If you see undefined symbols '__mb_sb_limit', please rebuild the affected binary. Everything will be fine then. Binaries built between 20071025 and 20071030 will be affected by this. Sorry for the inconvenience. Regards, Rong-En Fan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Package Building in the Large
Doug Barton wrote: On Mon, 19 Nov 2007, Jason C. Wells wrote: What I am trying to do is to build 30 or so packages including the big ones like X, kde, gnome, plus all of their dependencies on a build host and then use pkg_add on various machines. I have had a variety of difficulties with all of the methods I have used thus far (portmaster, portupgrade, homegrown). What problems did you have with portmaster? Did the backup package creation fail in some way? Not all dependencies had a package built for them. For my list of 31 ports that I actually desired to build there was a dependency list (make all-depends-list) of 758 ports. Of those 758 ports there were 427 packages built. I also ended up with shared a library version problem in at least one port (grip) in spite of having started my build with a completely vacant /usr/local. It seems that portmaster is intended to be run on the host where the existing ports are currently installed and where the new ports will be eventually installed. It looks to have good port upgrading abilities, but that is not what I am after. What I am trying to do is operate a build host and distribute packages from there. Not all hosts run the same set of packages. Add the fact that I am finicky about customizing the kerberos dependencies. I am trying to find a good method to build my ports at every minor release (7.0 upcoming) with little user intervention. Perhaps I misunderstand the -g and -b switches. I don't want backup packages of old ports. I already have those. I do want packages for all new ports that are built during a run. I used 'portmaster -GgDt -p /usr/ports/ports $pmarg' for my run where $pmarg was the list of 31 ports. I think portmaster worked as expected. It just didn't do what I desired. Hence my original question to the list. The tinderbox port looks like the right functionality. It also looks heavyweight requiring apache+mysql. I am trying to avoid dealing with extra databases. I spent a lot of time messing around with the database under portupgrade. I have come to the opinion (like the idea behind portmaster) that there are already databases built into the port system. I'd rather just use them in place. I would also like the portmanagers to know that I think they do a bang-up job. I just have my ultra narrow fussy roll your own way of doing things. I am looking for the right method _for me_. All of the above is no criticism. Thanks, Jason C. Wells ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Please help me update extmail/extman ports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Nov 22, 2007 at 11:24:56AM +0800, chifeng wrote: > Hi, committer boss. > > I sent 2 PRs: > http://www.freebsd.org/cgi/query-pr.cgi?pr=118181 > http://www.freebsd.org/cgi/query-pr.cgi?pr=118180 > > Please help me commit. Thanks ! We have Portsfreeze. > > > -- > regards. > chifeng > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > - -- +---+---+ | PGP: 0x05682353 | Jabber : miwi(at)BSDCrew.de | | ICQ: 169139903 | Mail : miwi(at)FreeBSD.org | +---+---+ | Mess with the Best, Die like the Rest! | +---+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHRbTnFwpycAVoI1MRAh8vAJ0c3hUJq26C6lcoOuhqfEn/Pugj0gCcCh/n uvsGvkQ5DCkeLjf6iPDQrr0= =Jdsa -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: ports modifying system setups
On Wed, 21 Nov 2007 22:48:59 -0800 Doug Barton <[EMAIL PROTECTED]> wrote: > RW wrote: > > On Wed, 21 Nov 2007 12:14:17 -0800 > > Doug Barton <[EMAIL PROTECTED]> wrote: > > > >> ... I have for some time wanted to add > >> support to rc.subr for a /usr/local/etc/rc.conf.d so that ports > >> could install sensible defaults for rc.conf, > > > > What's the advantage of doing that over having the the defaults > > in the rc.d script, > > I thought I explained that. The point of this thread was that services > installed by ports are not (any longer?) on by default. What I'm > proposing is a way to allow the user to choose to enable the service > using an OPTION (amongst other things). You wrote defaults (plural), I thought you might want to handle other thing apart from yes/no. Having the port options determine whether a port should be off or on by default sounds like a nightmare. You wouldn't know what the packager or previous administrator had set as the default without checking the files. People would still end-up putting settings in rc.conf just to be sure - except that then you wouldn't be able to rely on a comment to turn something off. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Package Building in the Large
Jason C. Wells wrote: > Doug Barton wrote: >> On Mon, 19 Nov 2007, Jason C. Wells wrote: >> >>> What I am trying to do is to build 30 or so packages including the >>> big ones like X, kde, gnome, plus all of their dependencies on a >>> build host and then use pkg_add on various machines. I have had a >>> variety of difficulties with all of the methods I have used thus far >>> (portmaster, portupgrade, homegrown). >> >> What problems did you have with portmaster? Did the backup package >> creation fail in some way? >> > Not all dependencies had a package built for them. For my list of 31 > ports that I actually desired to build there was a dependency list (make > all-depends-list) of 758 ports. Of those 758 ports there were 427 > packages built. That's disturbing, but I think I know why it happened, see below. > I also ended up with shared a library version problem > in at least one port (grip) in spite of having started my build with a > completely vacant /usr/local. That sounds like a problem with the ports. I can't think of any way that portmaster would cause that. > It seems that portmaster is intended to be run on the host where the > existing ports are currently installed and where the new ports will be > eventually installed. That is its primary purpose, yes. > It looks to have good port upgrading abilities, > but that is not what I am after. What I am trying to do is operate a > build host and distribute packages from there. That is not its primary purpose, but assuming that your systems are similarly configured, and running an OS version that's fairly close in age, there is no reason that portmaster shouldn't be able to at least create the packages that you can then distribute manually. > Not all hosts run the same set of packages. That shouldn't matter as long as different hosts aren't running different versions of the same package. > Perhaps I misunderstand the -g and -b switches. I don't want backup > packages of old ports. That's what -b does. > I do want packages for all new ports that are built during a run. That is what -g does. > I used 'portmaster -GgDt -p /usr/ports/ports $pmarg' for my run > where $pmarg was the list of 31 ports. That's definitely not going to work, for several reasons. The -G switch should only be used _after_ you've already run portmaster without it for a given port build. The OPTIONS are there for a reason, and when they are changed it can (and often does) change the dependency tree. Also, since the OPTIONS framework has been fixed, if the options in the Makefile haven't changed, portmaster won't prompt you to reset options you've already set, so you get all the benefits with very little of the cost. This flag should be used primarily when you have to restart a build of a given port because the first build failed. If you're starting with a clean /usr/local then the -t option is not needed, but it probably won't hurt anything. You do misunderstand what the -p switch is for, and specifying the list of ports in the manner you did is probably not the best way to go about it. I'm also unsure what /usr/ports/ports is supposed to be, unless that's a local path issue. Assuming that your list of ports is relative to the /usr/ports directory (e.g., 'archivers/unzip astro/planets', etc.), what I would do is: for dir in $pmarg; do portmaster -BgD -p /usr/ports/$dir done Replace the literal "/usr/ports/" in that string with the actual location of your ports tree if its different. You probably also want to add the -v switch in there for the first few runs to familiarize yourself with what's going on, and review the man page. > I think portmaster worked as expected. If you invoked it the way you described, I'm pretty sure it didn't do what you expected it to do. :) > It just didn't do what I > desired. Hence my original question to the list. Please note, I am not saying that portmaster will definitely be the right solution for you. However, I do think it's worth pointing out that if used properly it should at least be able to do what it says it can do. > The tinderbox port looks like the right functionality. It also looks > heavyweight requiring apache+mysql. I am trying to avoid dealing with > extra databases. I spent a lot of time messing around with the database > under portupgrade. I have come to the opinion (like the idea behind > portmaster) that there are already databases built into the port > system. I'd rather just use them in place. > > I would also like the portmanagers to know that I think they do a > bang-up job. I just have my ultra narrow fussy roll your own way of > doing things. I am looking for the right method _for me_. All of the > above is no criticism. I certainly don't take it that way, and I appreciate both your kind words and the amount of thought that you put into this. Best of luck to you. Doug -- This .signature sanitized for your protection ___ freebsd-po
Re: Package Building in the Large
Jason C. Wells wrote: > Most of the message below is just rounding out the discussion. There is > one significant question on recursion though. Sounds good, I'll snip the bits that don't require comment. > Doug Barton wrote: > >>> I also ended up with shared a library version problem >>> in at least one port (grip) in spite of having started my build with a >>> completely vacant /usr/local. >> That sounds like a problem with the ports. I can't think of any way >> that portmaster would cause that. > > It might be due to a non-clean /usr/local on the target install host. It > was a foo.so.3 is required but foo.so.2 is installed sort of error. I > haven't dealt with the installation step in a meaningful way yet. Don't > worry about responding to this bit. I think you're on the right track there. >>> I used 'portmaster -GgDt -p /usr/ports/ports $pmarg' for my run >>> where $pmarg was the list of 31 ports. >> That's definitely not going to work, for several reasons. The -G >> switch should only be used _after_ you've already run portmaster >> without it for a given port build. > > I had manually run 'make config-recursive' previously. I'll do as > advised at any rate. The config-recursive target does most of what portmaster does, but not all. Most significantly, it's not adaptive to changing an OPTION that results in a new dependency graph. What probably happened (and this is just a WAG) is that because portmaster didn't "see" some of the dependencies further down the tree they were installed by the ports infrastructure, so portmaster made no packages for them. In version 1.24 I added the -DNO_DEPENDS flag to 'make install' so that this problem can't happen. >> I'm also unsure >> what /usr/ports/ports is supposed to be, unless that's a local path >> issue. > > It's a local hierarchy issue. I pushed the ports tree up one level and > therein lie 6.2, -current, and the soon to be 7.0 trees. Ok, you might want to take a look at the PORTSDIR variable in ports/Mk/bsd.port.mk, and set that in your environment accordingly. >> Assuming that your list of ports is relative to the /usr/ports >> directory (e.g., 'archivers/unzip astro/planets', etc.), what I would >> do is: >> for dir in $pmarg; do >> portmaster -BgD -p /usr/ports/$dir >> done > > Aha! I had an error (don't recall exactly) without using -p where the > complaint had something to do with not finding something in /usr/ports. Yeah, that makes sense. If you set PORTSDIR in your environment you should be able to just specify the list of ports (astro/planets, etc.) without the -p option. > But what about recursion? I held the notion the portmaster did > magically delicious recursion Heh, I like that phrase. > and so I thought that providing the list > of ports to a single invocation of portmaster would allow portmaster to > sort the build order correctly. Well, yes and no. If you give the whole long list of ports to build it will save the information about which ports are already up to date between builds, but that feature has only been tested for "a few" ports at a time. In theory what you're proposing should work, but I haven't tested it. In fact, if you do that I'd be interested in your results. :) There is one other issue that I think would help you understand the process; the concept of root, trunk, branch, and leaf ports. If you do 'portmaster -l' on a system that has the stuff you want installed on it already, you'll get a good idea what I'm talking about. To start from scratch on a clean system you want to extract the list of root (no dependencies, not depended on) and leaf (have dependencies, not depended on) ports from a working system (add any additional ports you want of course), and then use that list to build on your clean system. This will allow portmaster to handle the recursion through the dependencies (trunk and branch ports). > The code snippet you show would cause > portmaster to _forget_ recursion information during each iteration of > the loop. My concern was that some dependencies would be built more > than once. Well good news there, if the installed version of the port is up to date it won't be rebuilt. The version check is pretty light weight, and only occurs once during the config phase. After that it's cached. Like I said above, specifying the whole list of ports on the command line _should_ work, and would avoid even having to do the check more than once, but doing the roots and leaves one by one shouldn't add very much of a performance penalty either. hope this helps, 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: Package Building in the Large
Most of the message below is just rounding out the discussion. There is one significant question on recursion though. Doug Barton wrote: >> I also ended up with shared a library version problem >> in at least one port (grip) in spite of having started my build with a >> completely vacant /usr/local. > > That sounds like a problem with the ports. I can't think of any way > that portmaster would cause that. It might be due to a non-clean /usr/local on the target install host. It was a foo.so.3 is required but foo.so.2 is installed sort of error. I haven't dealt with the installation step in a meaningful way yet. Don't worry about responding to this bit. >> It looks to have good port upgrading abilities, >> but that is not what I am after. What I am trying to do is operate a >> build host and distribute packages from there. > > That is not its primary purpose, but assuming that your systems are > similarly configured, and running an OS version that's fairly close in > age, there is no reason that portmaster shouldn't be able to at least > create the packages that you can then distribute manually. All my systems run a -release and all ports are tagged with the same -release. (With a few odd cases when security issues demand.) A few years ago I decided to stop tracking -stable and just run pure releases. I now spend less time administering my five or so systems. By what you claim, portmaster should suffice. >> I used 'portmaster -GgDt -p /usr/ports/ports $pmarg' for my run >> where $pmarg was the list of 31 ports. > > That's definitely not going to work, for several reasons. The -G > switch should only be used _after_ you've already run portmaster > without it for a given port build. I had manually run 'make config-recursive' previously. I'll do as advised at any rate. > I'm also unsure > what /usr/ports/ports is supposed to be, unless that's a local path > issue. It's a local hierarchy issue. I pushed the ports tree up one level and therein lie 6.2, -current, and the soon to be 7.0 trees. /usr/ports/ports is a link to the tree I was working on in which is /usr/ports/ports-current. Once the FreeBSD portmanager pulls the trigger I will be dealing with 7.0 exclusively. > Assuming that your list of ports is relative to the /usr/ports > directory (e.g., 'archivers/unzip astro/planets', etc.), what I would > do is: > for dir in $pmarg; do > portmaster -BgD -p /usr/ports/$dir > done Aha! I had an error (don't recall exactly) without using -p where the complaint had something to do with not finding something in /usr/ports. So I fired up the manual and then found the -p switch and assumed that was how I told portmaster where the ports tree was stored. I think this is the ticket. I don't have my manpages handy right now but I'll take a closer look. But what about recursion? I held the notion the portmaster did magically delicious recursion and so I thought that providing the list of ports to a single invocation of portmaster would allow portmaster to sort the build order correctly. The code snippet you show would cause portmaster to _forget_ recursion information during each iteration of the loop. My concern was that some dependencies would be built more than once. That's dog slow. > Replace the literal "/usr/ports/" in that string with the actual > location of your ports tree if its different. You probably also want > to add the -v switch in there for the first few runs to familiarize > yourself with what's going on, and review the man page. > Please note, I am not saying that portmaster will definitely be the > right solution for you. However, I do think it's worth pointing out > that if used properly it should at least be able to do what it says it > can do. I'll give it another go. Later, Jason ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Package Building in the Large
On Thu, Nov 22, 2007 at 07:13:04AM -0800, Jason C. Wells wrote: > ... > Not all dependencies had a package built for them. For my list of 31 ports > that I actually desired to build there was a dependency list (make > all-depends-list) of 758 ports. Of those 758 ports there were 427 packages > built. I also ended up with shared a library version problem in at least > one port (grip) in spite of having started my build with a completely > vacant /usr/local. > ... > I would also like the portmanagers to know that I think they do a bang-up > job. I just have my ultra narrow fussy roll your own way of doing things. > I am looking for the right method _for me_. All of the above is no > criticism. I usually just use "pkg_create -b" within simple shell scripts. It's as simple as it gets and works every time. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if you see undefined symbol '__mb_sb_limit' on 6.x
On Thu, Nov 22, 2007 at 10:38:29PM +0800, Rong-en Fan wrote: > The ctype fix for UTF-8 locale unfortunately introduced some > new symbols to libc. Therefore, binaries built on system with > that fix can not be used on older system. For that sake, the > fix is back-out for 6-STABLE. If you see undefined symbols > '__mb_sb_limit', please rebuild the affected binary. Everything > will be fine then. Binaries built between 20071025 and 20071030 > will be affected by this. Can this symbol be actually leaved in the libc ? If not used by the ctype.h, it would provide binary compatibility with all RELENG_6 systems in existence, not only the ones before 20071025 ? pgpFoVuxBUwKG.pgp Description: PGP signature
Re: Newbie: problem using SUB_LIST in Makefile
* Rainer Schwarze ([EMAIL PROTECTED]) wrote: > 1) What could be the reason that even XWRAPPER is not handled when the > replacement is performed? On my system similar stuff works without problems. First check all variable names in both SUB_LIST and *.in (i.e. WRAPER or something like that, seems to be copypaste problem of 2 vars). If it doesn't help try to simplify the makefile until the case is fixed (i.e. leave only XWRAPPER in SUB_LIST, set all substitude vars manually to something simple like test e.t.c. Watch for spaces or quotes in variables (though those are unlikely). > 2) Is my approach of adding entries to SUB_LIST based on > WITH_.../WITHOUT_... correct? (Or is that impossible after including > bsd.port.pre.mk? As far as I understand, the WITH_.../WITHOUT_... are > available only after bsd.port.[*.]mk is included...?) Pretty correct. Actually, in generic case it _should_ be done after pre.mk, becausee options are often used (btw, you should think of using OPTIONS too): ... OPTIONS=CWRAPPER"Use C wrapper" on .include .if !defined(WITHOUT_CWRAPPER) SUB_LIST+= CWRAPPER=yes .else SUB_LIST+= CWRAPPER=no .endif ... -- Dmitry A. Marakasov| jabber: [EMAIL PROTECTED] [EMAIL PROTECTED] | http://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Please help me update extmail/extman ports
all right, thank you for your remind. :-) chifeng. On Nov 23, 2007 12:57 AM, Martin Wilke <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thu, Nov 22, 2007 at 11:24:56AM +0800, chifeng wrote: > > Hi, committer boss. > > > > I sent 2 PRs: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=118181 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=118180 > > > > Please help me commit. Thanks ! > > We have Portsfreeze. > > > > > > > -- > > regards. > > chifeng > > ___ > > freebsd-ports@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > > - -- > > +---+---+ > | PGP: 0x05682353 | Jabber : miwi(at)BSDCrew.de | > | ICQ: 169139903 | Mail : miwi(at)FreeBSD.org | > +---+---+ > | Mess with the Best, Die like the Rest! | > +---+---+ > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.4 (FreeBSD) > > iD8DBQFHRbTnFwpycAVoI1MRAh8vAJ0c3hUJq26C6lcoOuhqfEn/Pugj0gCcCh/n > uvsGvkQ5DCkeLjf6iPDQrr0= > =Jdsa > -END PGP SIGNATURE- > > -- regards. chifeng ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
