Re: ports and PBIs
On 4/10/10 10:06 PM, Garrett Cooper wrote: It's more than just diskspace though. Consider the fact that now you're going to lose a lot of the memory sharing between shared libs and what-not, and now you'd have to be running N number of daemons . Take PCBSD for instance -- do they really revision packages with unshared dependencies, or are all of the dependencies updated at once? This becomes a big issue as you can't have dissimilar applications like dbus, gamin, openssh, etc running on the same system at one time. How does the PBI layout plan to deal with this kind of conflict -- apart from jails, which would greatly increase the required footprint...? It's a pitty that you didn't read the original post where it was stated that doing this would depend on a scheme that is under discussion for common components to be shared WHEN POSSIBLE. If you can do this with package code, Maybe you will supply the packages.. Not quite sure what you meant here. I meant. get involved and do some of the work if you can see such an easy answer. why? As people have said before.. embedded folks usually want to compile everyrthing for themselves anyhow. Not necessarily. You have folks in embedded rolling their own stuff, sure, but then you have groups like Montavista (now owned by Cavium Networks) repackaging Linux for customers, providing a nominal fee for the packages, support, and the tools, and there are large companies (like Cisco) buying into this. It's not to say that people are going to not roll their own solution, but many [intelligent] folks are going towards an externally supported model instead of rolling their own stuff. Thus, whatever the community decides is sane is what gets adopted (unless the developers or management for the group are really foolhardy / ignorant of what exists in the outside world, they're steeped in existing methods that can't be easily transitioned to the new model, or they have expendable resources to toss towards a custom solution for specific needs). If you guys think PBIs are so great... tell ya what -- make me and other folks believers: You know young fellow, your attitude is kind of annoying for a topic that is just up for discussion. 1. Produce a port with the magic PBI producing tool. I hope to be able to do this soon. 2. Produce directions on how to use said tool. the goal is: cd /usr/ports/misc/cowsay (or whereever cowsay is) make pbi 3. Make sure said tool and install method doesn't conflict with what exists in base. PBIs already don't conflict. Hav eyou ever tried PC-BSD? 4. Capture statistics of how many people download this stuff and use well we would start with the number of people using PC-BSD because if we did this they would use our stuff. 5. Come back when you have data proving how many people care for your solution so portmgr and core can make an informed decision on whether or not it should be a part of base. that's not how it's ever worked and I doubt it's going to start now. Oh, and think about this too: whoever produces the tool, eats the support costs. The project shouldn't eat the support costs until it's a part of base, if that ever happens. Definitely take this point into consideration because good support is not only `my package/port/PBI is broken .. help me!' -- it's also having QA engineers on hand and staffed to validate that the packages or PBIs are valid and functional -- in the very least from a DoA / smoke test perspective. I realize that this is lacking in packages / ports today, but it's something that many folks volunteering in the project (cross-functional in bugs area and also in ports) have wanted for a long time. Sorry, but you've really pissed me off and as most people will tell you. that's not easy to do. This all has the ring of a desperate person looking for excuses to complain about something. Every thing you have mentioned occurred to those of us having the original discussion in about the oh, say FIRST 10 SECONDS of the conversation. Might I suggest that when you have been in the project another decade or so you might learn some manners and stop trying to teach you grandmother to suck eggs. If you are trying to tell me about project dynamics or how things work of need to work I put it to you that I've been doing this when you were about minus 10 years old. I do Not need a lecture from a wet behind the ears puppy about how I should handle a discussion with interested parties on possibly improving FreeBSD's user experience. When you were born I was decoding network traces. When you were giving you mother heart attacks by eating the crayons I was writing disk and network drivers for BSD and long haul protocols. When you were learning to read I was playing with the MACH VM system and kerle build process. When you were learning to do multiplication of small numbers I trying to forget the Windows NT internals classes I had been sent to. Do you think we are so stupid that we
Re: ports and PBIs
On Sat, Apr 10, 2010 at 03:45:20PM -0700, Tim Kientzle wrote: Julian Elischer wrote: On 4/10/10 12:07 PM, Tim Kientzle wrote: [1] Actually, PBI might work just fine even for embedded if we address the disk bloat issue. One approach would be to make /Package/Bar/libfoo-2.8.7.so a symlink or hardlink to /Package/Shared/libfoo-2.8.7.so-MD5-hash This gives easy sharing of identical files. yeah that's more or less what we were thinking.. hardlinks allow you to garbage collect when the last pbi that needs something is replaced/removed. The point of /Package/Shared in this design is basically that it provides a list of all of the files that can be shared, so you avoid doing a full disk search to identify other places that might have this file. You could accomplish the same goal by building and storing a database of sharable files somewhere, of course. (Curiously, no one has mentioned filesystem-level deduping yet as the big hammer solution... ;-) The LD_LIBRARY_PATH issue is the most interesting problem here. I don't immediately see a solution that doesn't include teaching ld-elf.so.1 about some form of per-application library path. I already pointed in the other reply in this thread, $ORIGIN dynamic token should solve the issue. See http://docs.sun.com/app/docs/doc/817-1984/chapter3-13312?l=ena=view pgp8kblV37kSh.pgp Description: PGP signature
Re: ports and PBIs
On Sunday, April 11, 2010, Tim Kientzle kient...@freebsd.org wrote: Garrett Cooper wrote: If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. I'm not convinced that the simple update command you mention is actually feasible, much less desirable. (If I want to try out the new Firefox, why does that imply that my year-old Gimp has to be upgraded?) As for feasibility, here's the easy problem: A2.7 requires B3.6 ... one year passes ... A4.8 now requires B7.2 But A4.8 is incompatible with B3.6 and A2.7 is incompatible with B7.2. So neither A nor B can be updated separately without breaking the system. Here's the hard problem: A2.7 requires B3.6 ... one year passes ... I want to install C1.0 which requires B7.2 but there hasn't been a new release of A that works with B7.2. So I now simply cannot have both C1.0 and A2.7 installed at the same time because they require different versions of B. PBI avoids both of these problems. It may be unsuitable for embedded systems[1], but I see no reason we should not extend the existing ports/packages system with additional tools that target certain use cases, and PBI seems a good fit for the desktop case. Tim Genuine (possibly stupid) question -in PBI land, what happens if package B is, say, CUPS? Does one need versioned rc.d scripts to start one or the other? Which one gets to claim port 631? -James Butler [1] Actually, PBI might work just fine even for embedded if we address the disk bloat issue. One approach would be to make /Package/Bar/libfoo-2.8.7.so a symlink or hardlink to /Package/Shared/libfoo-2.8.7.so-MD5-hash This gives easy sharing of identical files. It's even easy to handle at install time: * Installer writes libfoo-2.8.7.so to /Package/Shared/libfoo-2.8.7.so-temp-PID of installer * Installer computes hash of file as it's written * Installer renames file (delete if rename fails with EEXIST) * Installer writes symlink or hardlink into /Package/Bar ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ 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
portmaster failing with build dependencies recognition
hi doug and ports@ i'm installing a system from scratch in a jail with portmaster 2.21, with the build/packages options enabled: `-- cat /usr/local/etc/portmaster.rc ALWAYS_SCRUB_DISTFILES=dopt LOCAL_PACKAGEDIR=/usr/ports/packages MAKE_PACKAGE=gopt PM_DEL_BUILD_ONLY=pm_dbo PM_INDEX=pm_index PM_PACKAGES_BUILD=pmp_build while having only six ports installed (ccache, zsh, portmaster, pkg_cutleaves, subversion-freebsd and sudo), the command `sudo portmaster www/nspluginwrapper www/linux-f10-flashplugin` installed ALL the dependencies (with the exception of pkg-config) from a package, and removed them at the end (with pkg_delete obviously complaining about them being required packages) commenting PM_DEL_BUILD_ONLY and PM_PACKAGES_BUILD completely fixed the issue, so there must be something wrong with the recognition of build dependencies. i remember that you did something to that algorithm some time ago (logs say that), and i'm sure that it was working correctly before... btw, thanks for the work you're doing on this tool, it's greater at every release :) -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla It is your concern when your neighbor's wall is on fire. -- Quintus Horatius Flaccus (Horace) signature.asc Description: This is a digitally signed message part.
Re: postgres and CVE-2010-0442
On 03/25/10 17:28, Mark Linimon wrote: On Thu, Mar 25, 2010 at 03:44:20PM +0100, Gary Jennejohn wrote: It's only been a week since it was assigned to the maintainer (girgen@) to look at. It's too soon for a maintainer timeout, although I suppose if this is considered to be an enormous security risk it could be committed without waiting. I'd say go ahead and commit it. We often waive the two-week period for security problems. Sorry to step in. 8.4 has been corrected since a while, but what about 8.2 and 8.3? Is the new (non vulnerable) version going to arrive in the port tree anytime soon or should we plan a version upgrade? bye Thanks av. ___ 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: ports and PBIs
On 4/11/10 3:27 AM, Kostik Belousov wrote: I already pointed in the other reply in this thread, $ORIGIN dynamic token should solve the issue. See http://docs.sun.com/app/docs/doc/817-1984/chapter3-13312?l=ena=view yes, teh question I have since I am not alinker expert is do we support it? the link you give is for Solaris I think.. ___ 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
Rarian, Scrollkeeper, gucharmap
I was going to install gucharmap so I didn't have to worry about figuring out what file I need to map a compose key in for it to work in WindowMaker (yeah yeah, lazy me), but I ran into a problem I didn't cause (haha, keep the comments to yourself): scrollkeeper-config: not found scrollkeeper-config: not found The file '/Templates/C/scrollkeeper_cl.xml' does not exist. Please check your ScrollKeeper installation. --- Above two lines are the important ones gmake[2]: *** [gucharmap-C.omf] Error 1 gmake[2]: Leaving directory `/usr/ports/deskutils/gucharmap/work/gucharmap-2.28.2/help' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/deskutils/gucharmap/work/gucharmap-2.28.2' gmake: *** [all] Error 2 *** Error code 1 Stop in /usr/ports/deskutils/gucharmap. So I look to see where scrollkeeper is and where I would find it: [r...@heaven]whereis scrollkeeper scrollkeeper: /usr/ports/textproc/scrollkeeper Apparently it's not installed. [r...@heaven]make install clean [I already ran make depends to make sure I had dependencies taken care of] === scrollkeeper-0.3.14_11,1 conflicts with installed package(s): rarian-0.8.1 They install files into the same place. Please remove them first with pkg_delete(1). *** Error code 1 Stop in /usr/ports/textproc/scrollkeeper. So I go find rarian to see where and what it is. [r...@heaven]cd ../rarian/ [r...@heaven]less pkg-descr Rarian is designed to be a replacement for scrollkeeper. It is --- Um really? currently undergoing heavy development. As of writing, rarian can be installed in place of scrollkeeper and everything will work okay. --- Really? Is gucharmap just an anomoly or is anyone else having this problem with other apps that used to rely on scrollkeeper? I updated my local ports collection on 9 April. I'm going to install regular charmap (or at least try to) as an alternative. Just thought I'd at least let you guys know about the issue. -- Yours In Christ, PIT Emails are not formal business letters, whatever businesses may want. Original content copyright under the OWL http://owl.apotheon.org Please do not CC me. If I'm posting to a list it is because I am subscribed. signature.asc Description: OpenPGP digital signature
Re: ports and PBIs
On Sun, Apr 11, 2010 at 11:23:33AM -0700, Julian Elischer wrote: On 4/11/10 3:27 AM, Kostik Belousov wrote: I already pointed in the other reply in this thread, $ORIGIN dynamic token should solve the issue. See http://docs.sun.com/app/docs/doc/817-1984/chapter3-13312?l=ena=view yes, teh question I have since I am not alinker expert is do we support it? the link you give is for Solaris I think.. It is in three for HEAD, RELENG_8 and RELENG_7. pgpam1Yk4Iu1q.pgp Description: PGP signature
Re: Rarian, Scrollkeeper, gucharmap
On 2010-Apr-11 13:41:09 -0500, Programmer In Training p...@joseph-a-nagy-jr.us wrote: scrollkeeper-config: not found scrollkeeper-config: not found The file '/Templates/C/scrollkeeper_cl.xml' does not exist. Please check your ScrollKeeper installation. --- Above two lines are the important ones ... So I look to see where scrollkeeper is and where I would find it: [r...@heaven]whereis scrollkeeper scrollkeeper: /usr/ports/textproc/scrollkeeper ... === scrollkeeper-0.3.14_11,1 conflicts with installed package(s): rarian-0.8.1 They install files into the same place. Please remove them first with pkg_delete(1). *** Error code 1 Whilst I don't have it installed, according to the pkg-plist for rarian, it should install $LOCALBASE/bin/scrollkeeper-config (note that you looked for 'scrollkeeper' rather than 'scrollkeeper-config' Does pkg_info -g rarian-0.8.1 report any anomolies? -- Peter Jeremy pgpryKgmcjSQc.pgp Description: PGP signature
Re: Rarian, Scrollkeeper, gucharmap
On 04/11/10 13:59, Peter Jeremy wrote: snip Whilst I don't have it installed, according to the pkg-plist for rarian, it should install $LOCALBASE/bin/scrollkeeper-config (note that you looked for 'scrollkeeper' rather than 'scrollkeeper-config' Ah. Well no worries. Apparently charmap was already installed. I guess I should look over pkg-plist too instead of just pkg-desc Does pkg_info -g rarian-0.8.1 report any anomolies? Nada. -- Yours In Christ, PIT Emails are not formal business letters, whatever businesses may want. Original content copyright under the OWL http://owl.apotheon.org Please do not CC me. If I'm posting to a list it is because I am subscribed. signature.asc Description: OpenPGP digital signature
Re: ports and PBIs
On 4/11/10 11:44 AM, Kostik Belousov wrote: On Sun, Apr 11, 2010 at 11:23:33AM -0700, Julian Elischer wrote: On 4/11/10 3:27 AM, Kostik Belousov wrote: I already pointed in the other reply in this thread, $ORIGIN dynamic token should solve the issue. See http://docs.sun.com/app/docs/doc/817-1984/chapter3-13312?l=ena=view yes, teh question I have since I am not alinker expert is do we support it? the link you give is for Solaris I think.. It is in three for HEAD, RELENG_8 and RELENG_7. thank you. This will I think as you suggest, make a significant difference. the question I have is is it re-evaluated for each library? So, to recap: what we were thinking is something along the lines of the following: an example with 2 PBI apps created at the same time (part of the same set) application 1 libraryA - - (originally) - - -library B | / | |link / |link | /---(y)---/ | v / v common area dd-mm-yy library A --(x)library B ^^ |link|link || || application 1 libraryA - - (originally) - - - -library B library A and B in app 2 are deleted the idea that all the PBIs developed as part of a release set (labeled as set dd-mm-yy in this example, would have identical libraries in them and would thus be candidates for library consolidation. The question is and I guess it's not really that important, whether satisfaying a dependency in library A due to application 1 will use path (x) or path (y). certainly we would need to label the versions of the libraries in the common area with a hash or something, or maybe some other unique label. (port sequence number plus build args?) so that we don't use a copy of the library that is not really suitable for that app. A really top class effort would be ab;e to know hte set of build options on a library that would make the outcome acceptable. but I doubt that we want to go that far. if a person takes PBIS from set 01-01-2011 hey will tend to find common libraries. butit for some reason they need to take something from set 01-01-2009 (i.e. an old PBI, for some compatibility reason) it is guaranteed to work, despite the fact that there may well be collisions between library versions, because it will not be linked with those in the common area that do not match and will instead be linked with its own copies. Julian ___ 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: ports and PBIs
On Sun, Apr 11, 2010 at 12:13:12PM -0700, Julian Elischer wrote: On 4/11/10 11:44 AM, Kostik Belousov wrote: On Sun, Apr 11, 2010 at 11:23:33AM -0700, Julian Elischer wrote: On 4/11/10 3:27 AM, Kostik Belousov wrote: I already pointed in the other reply in this thread, $ORIGIN dynamic token should solve the issue. See http://docs.sun.com/app/docs/doc/817-1984/chapter3-13312?l=ena=view yes, teh question I have since I am not alinker expert is do we support it? the link you give is for Solaris I think.. It is in three for HEAD, RELENG_8 and RELENG_7. thank you. This will I think as you suggest, make a significant difference. the question I have is is it re-evaluated for each library? I am not sure what exactly you are asking there. $ORIGIN is substituted for each object invividually, taking the object path as a substitution target. That is, if main executable A references dso $ORIGIN/X/libA.so, then libA.so is looked up in the subdirectory X of directory containing A. If libA.so references $ORIGIN/Y/libB.so, then libB.so is looked up in X/Y subdirectory of directory containing A. So, to recap: what we were thinking is something along the lines of the following: an example with 2 PBI apps created at the same time (part of the same set) application 1 libraryA - - (originally) - - -library B | / | |link / |link | /---(y)---/ | v / v common area dd-mm-yy library A --(x)library B ^^ |link|link || || application 1 libraryA - - (originally) - - - -library B library A and B in app 2 are deleted the idea that all the PBIs developed as part of a release set (labeled as set dd-mm-yy in this example, would have identical libraries in them and would thus be candidates for library consolidation. The question is and I guess it's not really that important, whether satisfaying a dependency in library A due to application 1 will use path (x) or path (y). certainly we would need to label the versions of the libraries in the common area with a hash or something, or maybe some other unique label. (port sequence number plus build args?) so that we don't use a copy of the library that is not really suitable for that app. A really top class effort would be ab;e to know hte set of build options on a library that would make the outcome acceptable. but I doubt that we want to go that far. if a person takes PBIS from set 01-01-2011 hey will tend to find common libraries. butit for some reason they need to take something from set 01-01-2009 (i.e. an old PBI, for some compatibility reason) it is guaranteed to work, despite the fact that there may well be collisions between library versions, because it will not be linked with those in the common area that do not match and will instead be linked with its own copies. Julian pgpch2cIiNqfy.pgp Description: PGP signature
Re: portmaster failing with build dependencies recognition
On 04/11/10 06:33, Alberto Villa wrote:
hi doug and ports@
i'm installing a system from scratch in a jail with portmaster 2.21, with the
build/packages options enabled:
`-- cat /usr/local/etc/portmaster.rc
ALWAYS_SCRUB_DISTFILES=dopt
LOCAL_PACKAGEDIR=/usr/ports/packages
MAKE_PACKAGE=gopt
PM_DEL_BUILD_ONLY=pm_dbo
PM_INDEX=pm_index
PM_PACKAGES_BUILD=pmp_build
while having only six ports installed (ccache, zsh, portmaster,
pkg_cutleaves,
subversion-freebsd and sudo), the command `sudo portmaster
www/nspluginwrapper www/linux-f10-flashplugin`
No need to do 'sudo portmaster.' Check out the man page for how to
configure automatic sudo support.
installed ALL the dependencies (with the exception of pkg-config) from a
package,
Hmmm, so even the run dependencies were installed from a package? That's
bad.
and removed them at the end
Ok, I'm pretty sure I see the problem. Please test the attached patch
and let me know how it goes.
In case anyone cares the bug is that I tested the heck out of the
--index-only option and made a slight change to how the list of build
dependencies is compared to the list of run dependencies as a result. It
worked with --index-only, but I obviously neglected to test it again
without --index-only. Mea culpa.
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/
Index: portmaster
===
--- portmaster (revision 206442)
+++ portmaster (working copy)
@@ -1998,6 +1998,8 @@
for l in $temp_list ; do
list=$list `grep -m1 ^${l}\| $PM_INDEX | cut -f 2 -d
\|`
done
+
+ list= $list
fi
echo $list
@@ -2031,11 +2033,11 @@
if [ $PM_BUILD_ONLY_LIST = pmp_doing_build_deps ]; then
local rundeps dep varname run_dl build_only_dl
- rundeps= `gen_dep_list run-depends-list`
+ rundeps=`gen_dep_list run-depends-list`
for dep in $d_port_list; do
case $rundeps in
- * ${dep} *)
+ * ${dep} *|*${dep}*)
varname=`echo ${dep#$pd/} | sed 's#[-+/\.]#_#g'`
rundep_list=$rundep_list $varname
eval $varname=\$portdir \$$varname\
___
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: portmaster failing with build dependencies recognition
On Sunday 11 April 2010 22:35:02 Doug Barton wrote: No need to do 'sudo portmaster.' Check out the man page for how to configure automatic sudo support. i know that option, but i prefer the way `sudo portmaster` works. it's ok, anyway ;) Ok, I'm pretty sure I see the problem. Please test the attached patch and let me know how it goes. it works! thank you! :D In case anyone cares the bug is that I tested the heck out of the --index-only option and made a slight change to how the list of build dependencies is compared to the list of run dependencies as a result. It worked with --index-only, but I obviously neglected to test it again without --index-only. Mea culpa. while i'm here, let me say that the --index flag is making updates really faster! -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla The greatest of faults is to be conscious of none. signature.asc Description: This is a digitally signed message part.
Re: ports and PBIs
On 4/11/10 12:20 PM, Kostik Belousov wrote: On Sun, Apr 11, 2010 at 12:13:12PM -0700, Julian Elischer wrote: On 4/11/10 11:44 AM, Kostik Belousov wrote: On Sun, Apr 11, 2010 at 11:23:33AM -0700, Julian Elischer wrote: On 4/11/10 3:27 AM, Kostik Belousov wrote: I already pointed in the other reply in this thread, $ORIGIN dynamic token should solve the issue. See http://docs.sun.com/app/docs/doc/817-1984/chapter3-13312?l=ena=view yes, teh question I have since I am not alinker expert is do we support it? the link you give is for Solaris I think.. It is in three for HEAD, RELENG_8 and RELENG_7. thank you. This will I think as you suggest, make a significant difference. the question I have is is it re-evaluated for each library? You interpreted the question correctly. I am not sure what exactly you are asking there. $ORIGIN is substituted for each object invividually, taking the object path as a substitution target. That is, if main executable A references dso $ORIGIN/X/libA.so, then libA.so is looked up in the subdirectory X of directory containing A. If libA.so references $ORIGIN/Y/libB.so, then libB.so is looked up in X/Y subdirectory of directory containing A. If there is an LDPATH set then if the library A is to be found at $SOMEWHERE-ELSE which is in the LDPATH, rather than in $ORIGIN/X, will it still be found? if the answer to the above is yes, then If it is then found in $SOMEWHERE-ELSE/X somewhere, will it then look for libB.so in $ORIGIN(A) or in $SOMEWHERE-ELSE ? If the library is actually somewhere else (via symlink) is $origin reevaluated to the actual destination? (that would be cool). So, to recap: what we were thinking is something along the lines of the following: an example with 2 PBI apps created at the same time (part of the same set) application 1 libraryA - - (originally) - - -library B | / | |link / |link | /---(y)---/ | v / v common area dd-mm-yy library A --(x)library B ^^ |link|link || || application 1 libraryA - - (originally) - - - -library B library A and B in app 2 are deleted and libraries A and B in common area can be updated for security reasons by a special kind of PBI or package should it be required. It sounds to me that link 'y' is followed, i.e. the linker continues to think it is working in $ORIGIN(A). either way this is sounding very doable.. Kris is thinking about a single sysutils/pbimanager port and a /mk diff that would allow make pbi (once the port was installed). I think it actually looks quite feasible. Is there someone out there in ports-land who really inderstands the ports mk framework who could help us (because we'll need a local guide to make sure we don't dig inn any local burial grounds) and who can help with testing etc? Similarly if we need to do anything funny with regards to hashing parts of .so files, or deciding how to version things, is there an elf specialist in the house who can help? Kris said can do the pbi tools part if he has help with these two areas Julian ___ 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: Removal of RC_SUBR and RC_SUBR_SUFFIX
On Mon, 29 Mar 2010, Christian Weisgerber wrote:
Doug Barton do...@freebsd.org wrote:
As should be obvious by now I'm following through on my previously
stated plans to remove the no longer necessary %%RC_SUBR%% and
%%RC_SUBR_SUFFIX%% from the ports tree.
Does it still make sense to use
rcvar=`set_rcvar`
as recommended by rc.subr(8) or should we just use
rcvar=${name}_enable
as shown in the Porter's Handbook example?
Either one is fine. I've always regarded set_rcvar as a little bit too
much abstraction, but that doesn't mean it's wrong to use it.
Doug
--
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/
Computers are useless. They can only give you answers.
-- Pablo Picasso
___
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
Samba 34 + LDAP = hang?
Hi, I tried updating Samba to 3.4 (from 3.3) as libsmbclient uses it and that pulls in talloc which conflicts with 3.3.. Unfortunately when I tried it, it hung when I tried to use the ldap passdb backend. I could not really get any useful debugging out of it :( The stack trace is junk (even after enabling max debug) and running with.. sudo /usr/local/sbin/smbd -d 10 -F -S Showed stuff but nothing related to LDAP (except mentioning the line in the config) and it still hung after saying it was going to daemonise itself. It hung not using any CPU but it hadn't yet opened any TCP listen sockets - however it did have a socket to the LDAP server open. Does anyone actually use this combination on FreeBSD? I have had various annoying issues with LDAP (eg slapd crashing when it's not shut down cleanly, various frustrations getting it setup etc) but I haven't come across this bug before. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
