what to use as source for libss?
Hi all, I'm looking to make a port for libss, so that I can make another port (the zephyr IM library) that depends on it. FreeBSD used to have a libss, but kris removed it 7 years ago because it was not getting used. NetBSD still installs a libss, and they use the source from Heimdal (which is in lib/sl, interestingly enough). I asked around here at MIT, and people indicated that the most current version of a libss would be in the e2fsprogs package, and, in fact, that source package is used for the Debian libss package. It seems kind of sad to pull in another tarball when there is probably somethin good enough in the base system source, but my understanding is that we want to keep the ports system useable even when there is no source present for the base system. Could someone with more experience than me please confirm (or contradict) my reasoning that the e2fsprogs tarball is the right thing to use as a source package, here? Thanks, Ben Kaduk ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Help needed: 8-CURRENT
Dnia piątek, 20 marca 2009, Cezary Morga napisał: > Hi there. > > I've got a build problem with my net/wol port on amd64-8 (though it's > not architecture specific, so it will most probably appear on i386 as > well). > > I'm looking for someone running 8-CURRENT who could try building the > port with patch that I'll supply. If anyone's willing to help, please > contact my on priv. > > Thanks. Thanks all for your offers and help. The patch worked and it's going to be comitted soon. Again thanks! -- Pozdrawiam, Cezary Morga "But the fact that some geniuses were laughed at does not imply that all who are laughed at are geniuses." (Carl Sagan) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
HEADS UP multi processor compilations for everyone
Two days ago, I have checked in probably most requested feature of last few years. Ports framework now systematically supports building ports on multiple processing cores. It is achieved by passing -jX flag to make(1) running on vendor code. Of course not all ports handle this well, experimental run on pointyhat with this flag globally enabled turned up shy of 400 failures. Because of that, the feature was designed as a whitelist. Individual ports need to be enabled, and indeed, fellow developers took on and already started adding required declarations to popular ports like Firefox and others. If you are FreeBSD ports user: You don't need to do anything to enable the new feature. Whitelisted ports will automatically make use of all processors available in your computer. If you want, for some reasons, to disable this feature, put DISABLE_MAKE_JOBS=yes to your /etc/make.conf. By default, the level of parallelization will be equal to a number of processing cores in your machine. If you want to override this number, use for example MAKE_JOBS_NUMBER=6, again in /etc/make.conf. And if you are extra brave, or you want to check out all the yet unmarked ports, if they will build, you can define FORCE_MAKE_JOBS=yes in /etc/make.conf. If you are FreeBSD port maintainer: Nothing changes for you, if you don't want. If you want to enable the use of multiple cores in your port, add MAKE_JOBS_SAFE=yes to a block somewhere below dependency declarations. If you know your port does not handle -jX well, and want to disable it from using -jX even when user forces this feature, use MAKE_JOBS_UNSAFE=yes. And that's all to it. -- Pav Lucistnik What do we know about love? Love is like a pear. Pear is sweet and have a specific shape. Try to exactly define the shape of a pear. -- Marigold: 50 Years Of Poetry signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: HEADS UP multi processor compilations for everyone
Pav Lucistnik wrote: > Two days ago, I have checked in probably most requested feature of last > few years. Ports framework now systematically supports building ports on > multiple processing cores. It is achieved by passing -jX flag to make(1) > running on vendor code. Thanks for this very useful addition! To clarify: this is about making individual ports in parallel (make -j on each), not building multiple ports in parallel? signature.asc Description: OpenPGP digital signature
bgpctl (openbgp) dies when reloading
hello all machine is freebsd/amd64, 7.1-REL bgpctl reload dies with: bgpd[12853]: imsg_get: imsg hdr len 0 out of bounds, type=0 bgpd[12853]: fatal in SE: session_dispatch_imsg: imsg_get error: Broken pipe bgpd[12852]: fatal in RDE: rde_dispatch_imsg_session: pipe closed bgpd[12851]: dispatch_imsg in main: pipe closed more specifically, it works fine (reloading the config) up to 17 sessions, and dies as soon as an 18th one is added does that ring any bell to somebody ? thanks ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: HEADS UP multi processor compilations for everyone
Great work! Pav Lucistnik wrote: Two days ago, I have checked in probably most requested feature of last few years. Ports framework now systematically supports building ports on multiple processing cores. It is achieved by passing -jX flag to make(1) running on vendor code. Of course not all ports handle this well, experimental run on pointyhat with this flag globally enabled turned up shy of 400 failures. Because of that, the feature was designed as a whitelist. Individual ports need to be enabled, and indeed, fellow developers took on and already started adding required declarations to popular ports like Firefox and others. If you are FreeBSD ports user: You don't need to do anything to enable the new feature. Whitelisted ports will automatically make use of all processors available in your computer. If you want, for some reasons, to disable this feature, put DISABLE_MAKE_JOBS=yes to your /etc/make.conf. By default, the level of parallelization will be equal to a number of processing cores in your machine. If you want to override this number, use for example MAKE_JOBS_NUMBER=6, again in /etc/make.conf. And if you are extra brave, or you want to check out all the yet unmarked ports, if they will build, you can define FORCE_MAKE_JOBS=yes in /etc/make.conf. Not to nitpick or be an annoyance, but you might want to document this in ports(7) or make.conf(5) (or both) so it doesn't get lost in the mail-lists or if people are not reading ports@ If you are FreeBSD port maintainer: Nothing changes for you, if you don't want. If you want to enable the use of multiple cores in your port, add MAKE_JOBS_SAFE=yes to a block somewhere below dependency declarations. If you know your port does not handle -jX well, and want to disable it from using -jX even when user forces this feature, use MAKE_JOBS_UNSAFE=yes. And that's all to it. Regards! //Niclas ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: HEADS UP multi processor compilations for everyone
On Tue, Mar 24, 2009 at 10:28 AM, Niclas Zeising wrote: > Great work! Indeed. > > Not to nitpick or be an annoyance, but you might want to document this in > ports(7) or make.conf(5) (or both) so it doesn't get lost in the mail-lists > or if people are not reading ports@ > Can it be added to UPDATING as well? -- Glen Barber 570.328.0318 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: HEADS UP multi processor compilations for everyone
Niclas Zeising píše v út 24. 03. 2009 v 15:28 +0100: > Not to nitpick or be an annoyance, but you might want to document this > in ports(7) or make.conf(5) (or both) so it doesn't get lost in the > mail-lists or if people are not reading ports@ I will document it soon, thinking The Handbook would be best place. -- Pav Lucistnik East or west, ~ is best. signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: HEADS UP multi processor compilations for everyone
On Tue, Mar 24, 2009 at 03:04:41PM +0100, Ivan Voras wrote: > Pav Lucistnik wrote: > > Two days ago, I have checked in probably most requested feature of last > > few years. Ports framework now systematically supports building ports on > > multiple processing cores. It is achieved by passing -jX flag to make(1) > > running on vendor code. > > Thanks for this very useful addition! > > To clarify: this is about making individual ports in parallel (make -j > on each), not building multiple ports in parallel? Correct. The latter was being worked on in last years SoC. The author of that (David Forsythe) recently posted something about it. The subject of his post is "Parallel builds, PKG_DBDIR locks". -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: HEADS UP multi processor compilations for everyone
On Tue, 2009-03-24 at 15:54 +0100, Pav Lucistnik wrote: > Niclas Zeising píše v út 24. 03. 2009 v 15:28 +0100: > > > Not to nitpick or be an annoyance, but you might want to document this > > in ports(7) or make.conf(5) (or both) so it doesn't get lost in the > > mail-lists or if people are not reading ports@ > > I will document it soon, thinking The Handbook would be best place. > Definitely add it to UPDATING too. This will allow people who typically do something like "make configure && make -j3" to now know that they don't have to. It will also allow others to know why ports compilation on their multi-core boxes suddenly uses a lot more CPU time. BTW, Good work, Pav! Thank you for taking the time to do what so many of us wanted but wouldn't do. -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: HEADS UP multi processor compilations for everyone
Coleman Kane píše v út 24. 03. 2009 v 10:58 -0400: > On Tue, 2009-03-24 at 15:54 +0100, Pav Lucistnik wrote: > > Niclas Zeising píše v út 24. 03. 2009 v 15:28 +0100: > > > > > Not to nitpick or be an annoyance, but you might want to document this > > > in ports(7) or make.conf(5) (or both) so it doesn't get lost in the > > > mail-lists or if people are not reading ports@ > > > > I will document it soon, thinking The Handbook would be best place. > > > > Definitely add it to UPDATING too. This will allow people who typically > do something like "make configure && make -j3" to now know that they This would break very fast -- it's passing -j3 to port Makefile instead of vendor Makefile. > don't have to. It will also allow others to know why ports compilation > on their multi-core boxes suddenly uses a lot more CPU time. Same CPU time, less wall time, more CPU utilization :) -- Pav Lucistnik If God didn't mean for us to juggle, tennis balls wouldn't come three to a can. signature.asc Description: Toto je digitálně podepsaná část zprávy
[FreeBSD] / ports / net-p2p / deluge
Hi, Today I tried to compile "deluge" . I had a stop in the make process . The error I discovered is the same as : https://bugzilla.novell.com/show_bug.cgi?id=353897 . I applied the same suggested temporary fix . Would you need me to open a PR with details ? Thanks dan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: HEADS UP multi processor compilations for everyone
On Tue, 2009-03-24 at 16:19 +0100, Pav Lucistnik wrote: > Coleman Kane píše v út 24. 03. 2009 v 10:58 -0400: > > On Tue, 2009-03-24 at 15:54 +0100, Pav Lucistnik wrote: > > > Niclas Zeising píše v út 24. 03. 2009 v 15:28 +0100: > > > > > > > Not to nitpick or be an annoyance, but you might want to document this > > > > in ports(7) or make.conf(5) (or both) so it doesn't get lost in the > > > > mail-lists or if people are not reading ports@ > > > > > > I will document it soon, thinking The Handbook would be best place. > > > > > > > Definitely add it to UPDATING too. This will allow people who typically > > do something like "make configure && make -j3" to now know that they > > This would break very fast -- it's passing -j3 to port Makefile instead > of vendor Makefile. This has worked fine for me for countless years, except where the vendor's Makefiles were not parallel-safe. This has been my trick to get larger things (like mysql or xorg-server) to make in parallel. It *did* work. If this has changed, then it definitely warrants mention in UPDATING. > > > don't have to. It will also allow others to know why ports compilation > > on their multi-core boxes suddenly uses a lot more CPU time. > > Same CPU time, less wall time, more CPU utilization :) > Thanks for the clarification... that's what I meant :) -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: HEADS UP multi processor compilations for everyone
Coleman Kane píše v út 24. 03. 2009 v 12:28 -0400: > On Tue, 2009-03-24 at 16:19 +0100, Pav Lucistnik wrote: > > Coleman Kane píše v út 24. 03. 2009 v 10:58 -0400: > > > On Tue, 2009-03-24 at 15:54 +0100, Pav Lucistnik wrote: > > > > Niclas Zeising píše v út 24. 03. 2009 v 15:28 +0100: > > > > > > > > > Not to nitpick or be an annoyance, but you might want to document > > > > > this > > > > > in ports(7) or make.conf(5) (or both) so it doesn't get lost in the > > > > > mail-lists or if people are not reading ports@ > > > > > > > > I will document it soon, thinking The Handbook would be best place. > > > > > > > > > > Definitely add it to UPDATING too. This will allow people who typically > > > do something like "make configure && make -j3" to now know that they > > > > This would break very fast -- it's passing -j3 to port Makefile instead > > of vendor Makefile. > > This has worked fine for me for countless years, except where the > vendor's Makefiles were not parallel-safe. This has been my trick to get > larger things (like mysql or xorg-server) to make in parallel. It *did* > work. If this has changed, then it definitely warrants mention in > UPDATING. Then it must have worked all these years by pure chance :) -- Pav Lucistnik 94 outdated ports on the box, 94 outdated ports. Portupgrade one, an hour 'til done, 82 outdated ports on the box. signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: [FreeBSD] / ports / net-p2p / deluge
On Tue, Mar 24, 2009 at 05:11:02PM +0100, dan wrote: > Hi, > > Today I tried to compile "deluge" . I had a stop in the make process . > The error I discovered is the same as : > https://bugzilla.novell.com/show_bug.cgi?id=353897 . I applied the same > suggested temporary fix . > > Would you need me to open a PR with details ? There is no maintainer for this port. Please file a PR with the details so it doesn't get lost in the noise. As there is currently no maintainer are you willing to maintain it? -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Dspace - Digital asset Management
Hi Has anyone had a go at porting DSpace to freebsd? www.dspace.org Software is BSD open licence - MIT in Colloaboration with HP David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Digital Asset Management Software
Hi I am looking for a port of a Digital Asset Management tool to catalogue a large (100,000 plus) collection of image files stored in a variety of common file formats. Mainly CR2, CRW, psd, jpg & tiff. File sizes range from small <50k to very large (up to 6GB) . A hierarchical and random Key word search ability would be ideal and thumbnail display & selectivity. A web interface is needed. Are there any suitable tools in the freebsd ports collection and is anyone working on one? Thanks in advance ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[FreeBSD] / ports / net-p2p / deluge
dan writes: > Today I tried to compile "deluge". I had a stop in the make > process. The error I discovered is the same as : > https://bugzilla.novell.com/show_bug.cgi?id=353897 . I applied > the same suggested temporary fix . > > Would you need me to open a PR with details ? For the record: I built deluge-1.1.5 three days ago without problems, with a dependency on boost-python-1.34.1. It's currently chugging away Robert Huff ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: HEADS UP multi processor compilations for everyone
Pav Lucistnik wrote: > Ports framework now systematically supports building ports on > multiple processing cores. It is achieved by passing -jX flag to make(1) > running on vendor code. Of course not all ports handle this well, A word of caution: It is quite possible for a port to build fine with -jN and still fail with -jM, where N < M. If it builds fine on a 64-core sparc64, it will build anywhere, but I expect some ports will work fine for, say, -j2 and fail for -j4. Or only fail *sometimes* due to a race. > If you are FreeBSD port maintainer: > > Nothing changes for you, if you don't want. If you want to enable the > use of multiple cores in your port, add MAKE_JOBS_SAFE=yes to a block > somewhere below dependency declarations. What is the goal here? Should all ports that can be safely built in parallel eventually have MAKE_JOBS_SAFE=yes? Or should we not bother with ports where the gain is likely to be minimal? -- Christian "naddy" Weisgerber na...@mips.inka.de ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
qt4 ports descriptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 someone's being very lazy here. I decided to learn a bit of qt4, so I went looking at the dozen different ports of qt4-* in ports/devel. Whoever did those ports copied the description of the entire qt (not even noting what version it is) to every single one of the ports, although they AREN'T all the same thing. At least some care, even 30 seconds, should have been given to allow at least a vague hint as to what the ports do. The ports diagnostic tools really ought to be made to detect when someone's decided they didn't need to give any kind of desciption at all, I would think that things which source in the same bsd.n.mk files, they could be checked to see if they all have identical, useless pkg-descr files. OTOH, the KDE folks deserve an attaboy for NOT doing this to folks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknJJWwACgkQz62J6PPcoOmYfwCgm2NyOFXKVOXuwQMmlZMwUMAO h1MAoJJrHDcYr09IIUwfx+bZ4SxIKn6g =fSDJ -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: HEADS UP multi processor compilations and packages
Pav Lucistnik wrote: Two days ago, I have checked in probably most requested feature of last few years. Ports framework now systematically supports building ports on multiple processing cores. It is achieved by passing -jX flag to make(1) running on vendor code. Of course not all ports handle this well, experimental run on pointyhat with this flag globally enabled turned up shy of 400 failures. Because of that, the feature was designed as a whitelist. Individual ports need to be enabled, and indeed, fellow developers took on and already started adding required declarations to popular ports like Firefox and others. On a related topic, I wonder what the cost would be of acquiring enough hardware so that the probability of actually getting a package with portupgrade -aP would go up substantially. I imagine the time required for the build servers to build packages with the above mod would go down substantially. Brian ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: HEADS UP multi processor compilations for everyone
Christian Weisgerber píše v út 24. 03. 2009 v 18:09 +: > > If you are FreeBSD port maintainer: > > > > Nothing changes for you, if you don't want. If you want to enable the > > use of multiple cores in your port, add MAKE_JOBS_SAFE=yes to a block > > somewhere below dependency declarations. > > What is the goal here? Should all ports that can be safely built > in parallel eventually have MAKE_JOBS_SAFE=yes? Ideally yes. > Or should we not > bother with ports where the gain is likely to be minimal? That would be sensible. -- Pav Lucistnik As to floating eyes, let them float :). - r.g.r.a signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: HEADS UP multi processor compilations and packages
Brian Whalen píše v út 24. 03. 2009 v 12:08 -0700: > Pav Lucistnik wrote: > > Two days ago, I have checked in probably most requested feature of last > > few years. Ports framework now systematically supports building ports on > > multiple processing cores. It is achieved by passing -jX flag to make(1) > > running on vendor code. Of course not all ports handle this well, > > experimental run on pointyhat with this flag globally enabled turned up > > shy of 400 failures. Because of that, the feature was designed as a > > whitelist. Individual ports need to be enabled, and indeed, fellow > > developers took on and already started adding required declarations to > > popular ports like Firefox and others. > > > > > > > On a related topic, I wonder what the cost would be of acquiring enough > hardware so that the probability of actually getting a package with > portupgrade -aP would go up substantially. I imagine the time required > for the build servers to build packages with the above mod would go down > substantially. It's more a question of creating a new delivery platform, because the currently used ftp mirrorring is useless for packages. The whole process of synchronizing from upstream server introduces _days_ of delay into the process, and there is no guarantee that you don't catch an upload in progress, which renders whole mirror useless for a time period. -- Pav Lucistnik Do not meddle in the fashions of wizards, for they are seasonal and quick to fall out of style! signature.asc Description: Toto je digitálně podepsaná část zprávy
MAKE_JOBS_SAFE with gmake
Question, I'm testing my ports for MAKE_JOBS_SAFE-ness, and came across this message when building xscreensaver (which uses gmake): gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. I have zero gmake fu, can anyone help me make sense of that? The good news is that the build finished successfully ... 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 "freebsd-ports-unsubscr...@freebsd.org"
Re: MAKE_JOBS_SAFE with gmake
On Tue, 2009-03-24 at 12:43 -0700, Doug Barton wrote: > Question, > > I'm testing my ports for MAKE_JOBS_SAFE-ness, and came across this > message when building xscreensaver (which uses gmake): > > gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to > parent make rule. > > I have zero gmake fu, can anyone help me make sense of that? The good > news is that the build finished successfully ... > > > Doug > I'll give it a stab, as I've dealt with this when trying to write a "one makefile to rule them all" build system recently (in other words, I maintain a collection of 200+ packages and my makefile attempts to call $(MAKE) within those subdirectories). The GNU make process for some reason was not able to determine the type of your "make" that was used for building a target of the following flavor: mytarget: deps dep2 ... $(MAKE) -C $(mytargetdir) mytarget Supposedly, GNU make is supposed to recognize that $(MAKE) above is a "make program" and not a "normal program" (such as install, BSD make, sed, etc). In the event that it is calling a compatible GNU make program, it can (through some means I don't fully understand) provide access to its job pool to the "child" (the make process that will be executed in the target above). This allows, for instance, you to pass -j 4 to the parent make process, and it will guarantee that no more than four jobs get run, even if there are subdirs-within-subdirs, etc Something is preventing this detection from succeeding in your case. I see this a lot as well (in my own make system), but I've chosen to ignore it in my environment. I think, in my case, that I am using $(MAKE) within an $(eval ...) block and the $(MAKE) gets expanded before the $(eval ...) does, making the GNU make program actually see something like this, before it actually builds the target list: mytarget: deps dep2 ... /usr/local/bin/gmake -C $(mytargetdir) mytarget Which may confuse it. Here's a link to the ambiguous description on the GNU make website: http://www.gnu.org/software/automake/manual/make/Error-Messages.html -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: MAKE_JOBS_SAFE with gmake
On Tue, 2009-03-24 at 16:02 -0400, Coleman Kane wrote: > On Tue, 2009-03-24 at 12:43 -0700, Doug Barton wrote: > > Question, > > > > I'm testing my ports for MAKE_JOBS_SAFE-ness, and came across this > > message when building xscreensaver (which uses gmake): > > > > gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to > > parent make rule. > > > > I have zero gmake fu, can anyone help me make sense of that? The good > > news is that the build finished successfully ... > > > > > > Doug > > > > I'll give it a stab, as I've dealt with this when trying to write a "one > makefile to rule them all" build system recently (in other words, I > maintain a collection of 200+ packages and my makefile attempts to call > $(MAKE) within those subdirectories). > > The GNU make process for some reason was not able to determine the type > of your "make" that was used for building a target of the following > flavor: > > mytarget: deps dep2 ... > $(MAKE) -C $(mytargetdir) mytarget > > Supposedly, GNU make is supposed to recognize that $(MAKE) above is a > "make program" and not a "normal program" (such as install, BSD make, > sed, etc). In the event that it is calling a compatible GNU make > program, it can (through some means I don't fully understand) provide > access to its job pool to the "child" (the make process that will be > executed in the target above). This allows, for instance, you to pass -j > 4 to the parent make process, and it will guarantee that no more than > four jobs get run, even if there are subdirs-within-subdirs, etc > > Something is preventing this detection from succeeding in your case. I > see this a lot as well (in my own make system), but I've chosen to > ignore it in my environment. I think, in my case, that I am using > $(MAKE) within an $(eval ...) block and the $(MAKE) gets expanded before > the $(eval ...) does, making the GNU make program actually see something > like this, before it actually builds the target list: > mytarget: deps dep2 ... > /usr/local/bin/gmake -C $(mytargetdir) mytarget > > Which may confuse it. > > Here's a link to the ambiguous description on the GNU make website: > http://www.gnu.org/software/automake/manual/make/Error-Messages.html > > Additionally: http://lists.samba.org/archive/distcc/2004q1/002160.html -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: qt4 ports descriptions
On Tue March 24 2009 19:24:44 Chuck Robey wrote: > OTOH, the KDE folks deserve an attaboy for NOT doing this to folks. Please post your insults somewhere else but not here! Do not spam the mailing lists with such a nonsense! You do not have the right to judge the kde@ people! You actually have a very annoying and insulting attitude in several of your mails! This time I cannot ignore it anymore because such an attitude makes me very angry ... :-( > someone's being very lazy here. Yes, you are the one who is lazy! Do the work and submit patches! If done right no one from kde@ will reject those. Otherwise please do not spam the mailing lists! It is extremely annoying if someone writes unqualified rants about something but actually do not contribute anything or even have any clue at all about it. You make a lot of noise - especially at kde-free...@kde.org mailing list - you do strange things, ask people about your problems which only occurred because you do things in strange fashion and you also demand a lot. Especially kde@ people do not have the time for your unsupported experiments. Do not steel their time! They have a lot of other things to do. It is a horribly intensive task to maintain the QT4 and KDE stuff. Max and Martin and several other volunteers do a very good job and actually do not deserve such a poor statement of you! It looks like you know nothing about the actual work and time needed to port and maintain those beasts. If something is not done yet then nobody had the time to do it yet. It is that simple. There are many things which need some love or even need to be done at all. But if nobody does something nothing gets done at all. If that sounds rude - sorry, but it is the truth! -- Regards, Marco Bröder OpenPGP key fingerprint: 5615 106E 031A F3D3 64CC 0F9E 4DCE 6524 F595 082F signature.asc Description: This is a digitally signed message part.
Re: qt4 ports descriptions
Marco Bröder wrote: > On Tue March 24 2009 19:24:44 Chuck Robey wrote: > >> OTOH, the KDE folks deserve an attaboy for NOT doing this to folks. > > Please post your insults somewhere else but not here! Do not spam the > mailing lists with such a nonsense! Marco, I think you misunderstood what Chuck said. The term "attaboy" is an English colloquialism that means roughly "congratulations for a job well done." What Chuck is saying is that the kde maintainers should be congratulated for adding appropriate pkg-descr files to the ports they maintain. > You actually have a very annoying and insulting attitude in several of your > mails! This time I cannot ignore it anymore because such an attitude makes > me very angry ... :-( While you certainly have the right to your opinion, it's probably better if personal problems are handled personally, rather than on the lists. > Otherwise please do not spam the mailing lists! It is extremely annoying if > someone writes unqualified rants about something but actually do not > contribute anything or even have any clue at all about it. There is a fine line here between a user identifying a problem and reporting it to the list (which is totally legitimate) and someone who is asking others to do work they are unwilling to do. I don't know the situation here well enough to judge, but if it's true that there are a large number of ports with duplicate and/or inappropriate pkg-descr files then reporting it is reasonable; if for no other reason than because it may spur someone who does have time to pick up the project. It's also worthwhile to point out problems (especially widespread ones) so that those who are learning to write/maintain ports themselves don't pick up on bad habits. Like I said above, there is a fine line here, but it doesn't appear to me that Chuck has crossed it. (At least not this time.) :) hope this helps, Doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: qt4 ports descriptions
On Tue March 24 2009 22:47:28 Doug Barton wrote:
> Marco, I think you misunderstood what Chuck said. The term "attaboy"
> is an English colloquialism that means roughly "congratulations for a
> job well done." What Chuck is saying is that the kde maintainers
> should be congratulated for adding appropriate pkg-descr files to the
> ports they maintain.
Well, English is not my native language. If your description is what he
actually means then I totally misunderstood it and I am sorry. :-)
> hope this helps,
Sure it does! Thanks!
There are too many people who demand and complain a lot but do not
contribute anything. Instead they attack the folks who actually do the work.
This is especially true for KDE. It will be even more true for QT 4.5,
because FreeBSD is now an officially unsupported platform ('thanks' to Nokia).
So it will be even more hard to port and maintain this stuff in the future.
Many users want everything right now but nobody but very few actually do the
jobs. And THIS is extremely frustrating and annoying.
That is the message I intended to say. ;-)
--
Regards,
Marco Bröder
OpenPGP key fingerprint: 5615 106E 031A F3D3 64CC 0F9E 4DCE 6524 F595 082F
signature.asc
Description: This is a digitally signed message part.
Re: www / p5-HTML-Embperl
Well, I've been slacking a bit lately with this so this is what I've got so far. It build against mod_perl2+Apache2, libxml2 and libxslt. Xalan is not supported. http://therek.net/freebsd/ports/www/p5-Embperl/ -- Cezary Morga "If you live to be one hundred, you've got it made. Very few people die past that age." (George Burns) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: qt4 ports descriptions
On Tue, Mar 24, 2009 at 6:22 PM, Marco Bröder wrote:
> On Tue March 24 2009 22:47:28 Doug Barton wrote:
> > Marco, I think you misunderstood what Chuck said. The term "attaboy"
> > is an English colloquialism that means roughly "congratulations for a
> > job well done." What Chuck is saying is that the kde maintainers
> > should be congratulated for adding appropriate pkg-descr files to the
> > ports they maintain.
>
> Well, English is not my native language. If your description is what he
> actually means then I totally misunderstood it and I am sorry. :-)
>
> > hope this helps,
>
> Sure it does! Thanks!
>
> There are too many people who demand and complain a lot but do not
> contribute anything. Instead they attack the folks who actually do the
> work.
> This is especially true for KDE. It will be even more true for QT 4.5,
> because FreeBSD is now an officially unsupported platform ('thanks' to
> Nokia).
> So it will be even more hard to port and maintain this stuff in the future.
>
> Many users want everything right now but nobody but very few actually do
> the
> jobs. And THIS is extremely frustrating and annoying.
>
> That is the message I intended to say. ;-)
>
> --
> Regards,
> Marco Bröder
> OpenPGP key fingerprint: 5615 106E 031A F3D3 64CC 0F9E 4DCE 6524 F595 082F
>
Chuck is more complaining about the QT4 ports descriptions since he does not
get it that all of it is required to program in QT4. so of course it will
all have the same description since it all comes from one tarball think
freebsd just breaks some of it up though but I could be wrong
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: qt4 ports descriptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Doug Barton wrote: > Marco Bröder wrote: >> On Tue March 24 2009 19:24:44 Chuck Robey wrote: >> >>> OTOH, the KDE folks deserve an attaboy for NOT doing this to folks. >> Please post your insults somewhere else but not here! Do not spam the >> mailing lists with such a nonsense! > > Marco, I think you misunderstood what Chuck said. The term "attaboy" > is an English colloquialism that means roughly "congratulations for a > job well done." What Chuck is saying is that the kde maintainers > should be congratulated for adding appropriate pkg-descr files to the > ports they maintain. > >> You actually have a very annoying and insulting attitude in several of your >> mails! This time I cannot ignore it anymore because such an attitude makes >> me very angry ... :-( > > While you certainly have the right to your opinion, it's probably > better if personal problems are handled personally, rather than on the > lists. > >> Otherwise please do not spam the mailing lists! It is extremely annoying if >> someone writes unqualified rants about something but actually do not >> contribute anything or even have any clue at all about it. > > There is a fine line here between a user identifying a problem and > reporting it to the list (which is totally legitimate) and someone who > is asking others to do work they are unwilling to do. I don't know the > situation here well enough to judge, but if it's true that there are a > large number of ports with duplicate and/or inappropriate pkg-descr > files then reporting it is reasonable; if for no other reason than > because it may spur someone who does have time to pick up the project. > > It's also worthwhile to point out problems (especially widespread > ones) so that those who are learning to write/maintain ports > themselves don't pick up on bad habits. > > Like I said above, there is a fine line here, but it doesn't appear to > me that Chuck has crossed it. (At least not this time.) :) (thanks for that, Doug) Sure didn't mean to say *anything* derogatory about the FreeBSD-KDE group. Their doing all this works saves me a ton of work myself, and no mistake. Heck, not being personally that hot a C++ coder, I might not even be able to completely port it, no matter how much time I take. I just felt that some of the pkg-descr's have been skimped. And, NOT in KDE, either. I used to do a LOT of FreeBSD committing, but stopped when I developed disagreements with the strategy that FreeBSD-ports moved towards some time back. I had a perfectly good chance (back then) to comment, so I don't feel right about ever bringing that up, again, but I don't agree, so I don't do it anymore. That's fair, isn't it? I used to do a ton of ports, often picking just the biggest ones (as fair challenges). The best way to disagree is to have your fair say, then shut up, right? If things had gone differently, I might still be committing. I still really like FreeBSD, just have a bone about implementation strategy with ports. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknJijgACgkQz62J6PPcoOllYQCfSSlxWJFxh9Z2Rjmvx/Ivpbk4 Fi8AoJNWMCvbpfjaUyHkaxXF0+xQz1dC =9yj8 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: qt4 ports descriptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 matt donovan wrote: > > Chuck is more complaining about the QT4 ports descriptions since he does > not get it that all of it is required to program in QT4. so of course it > will all have the same description since it all comes from one tarball > think freebsd just breaks some of it up though but I could be wrong > Well, let me offer an example: qt4-core versus qt4-qtdemo. They are very, very different ports, but they have precisely the same descriptions. Is this correct, from your viewpoint?? I did a find for all pkgs starting with qt4, and found they all have the same descriptions. Seeing as just how different they are (most certainly from a user perspective), it seems easily justifiable to require different descr strings, most certainly given the small work involved. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknJi+EACgkQz62J6PPcoOneugCgl+lFgZzBliebkEtfMJE+fOJV EwEAoJw4nyBCaTeqsZ2X2NUtexwEzJDb =G15G -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Inline definition problem in current
On Tue, Mar 24, 2009, Doug Barton wrote: > David Schultz wrote: > > On Mon, Mar 23, 2009, Gustau Perez wrote: > >> a few time ago I switched to current, right now I've it updated to > >> yesterday. While compiling some ports (in fact, building x11/gnome2) I > >> found that some of them (written in C) are using some inline functions > >> (I guess it is because the compiler will replace the call to the > >> function with the function itself). The problem is that gcc fails with > >> the following message : > >> > >>error: nested function 'XXX' declared but never defined > >> > >> checking the code, the function is declared and then implemented in a > >> header file which is included in the offending .c file. The function is > >> declared as 'inline'. The only solution I found is to change the > >> definition to static. > >> > >> Checking pontyhat shows me that many ports are failing because of > >> this problem. What I can understand is why is this happening, because > >> the same ports compiles fine in STABLE and the compilers's version in > >> base seems to be the same (gcc (GCC) 4.2.1 20070719 [FreeBSD], the same > >> in current) > > > > Which other ports were broken for this reason? > > I am trying to compile gimp on -current right now and x11/babl and > graphics/gegl both have this problem. Take a look at > http://pointyhat.freebsd.org/errorlogs/i386-8-failure.html for more > examples (click on the link on the right under Package to see the > logs). There are currently over 600 broken ports in -current, all the > ones I clicked on in a completely bogus sample had this same problem. My bug; I missed an important line when merging from gcc trunk 122565. Instead of reporting: error: nested function 'foo' declared but never defined gcc should have been reporting: warning: inline function 'foo' declared but never defined I'll check in a fix as soon as I run a buildworld. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: HEADS UP multi processor compilations for everyone
Pav Lucistnik writes:
> If you are FreeBSD port maintainer:
I'm not one.
>
> Nothing changes for you, if you don't want. If you want to enable the
> use of multiple cores in your port, add MAKE_JOBS_SAFE=yes to a block
> somewhere below dependency declarations. If you know your port does not
> handle -jX well, and want to disable it from using -jX even when user
> forces this feature, use MAKE_JOBS_UNSAFE=yes. And that's all to it.
Not all ports build using make/gmake. Wouldn't it be better to export
the number of parallel processes so maintainer can decide whether to use
it in his port build system? For example
Index: devel/boost/Makefile
===
RCS file: /home/csup/ports/devel/boost/Makefile,v
retrieving revision 1.42
diff -u -p -r1.42 Makefile
--- devel/boost/Makefile 20 Feb 2009 01:13:49 - 1.42
+++ devel/boost/Makefile 25 Mar 2009 06:12:06 -
@@ -17,6 +17,7 @@ COMMENT= Free peer-reviewed portable C++
USE_BZIP2= yes
USE_LDCONFIG= yes
+MAKE_JOBS_SAFE= yes
WRKSRC= ${WRKDIR}/${PORTNAME}_${PORTVERSION:S/./_/g}
.if defined(WITH_PYTHON) || defined (WITH_PYSTE)
@@ -87,6 +88,7 @@ PLIST_SUB+= BOOST_PYSTE="@comment "
BOOST_TOOLS= gcc
BJAM_OPTIONS= --layout=system
+BJAM_OPTIONS+= -j${_MAKE_JOBS:S/-j//}
.if defined (WITH_VERBOSE_BUILD)
BJAM_OPTIONS+= -d2
.endif
Is this completely discouraged?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
