A different forum for discussing ports matters
Hello again porters, Ok. Email--although nice for documented information--seems a bit kludgy for faster-paced discussion. I've finally setup xchat again and I'm at #bsdports on EFNET. I'll be there from now on, but will also post results via email. I'll toss some ideas off other people, then come back with a more formal / well-thought out proposal. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overly restrictive checks in the make process
On Friday 20 July 2007, Mark Linimon wrote: > On Fri, Jul 20, 2007 at 04:07:49PM -0400, Bill Moran wrote: > > Even better would be for make to realize that it's only doing the > > fetching, and do it anyway. > > That still doesn't help with the problem of a user who starts a 10MB > download that won't work on his architecture or OS release. The code > is all the same. This is the aggravation we are trying to prevent. > That still doesn't address the concern or improve the system downtime that a pkg_delete, make install allows. If you can't run something, you don't have any downtime but to have to pkg_delete before you start the tarball fetch can be really long on some ports. Kent -- Kent Stewart Richland, WA http://www.soyandina.com/ "I am Andean project". http://users.owt.com/kstewart/index.html ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overly restrictive checks in the make process
On Fri, Jul 20, 2007 at 04:07:49PM -0400, Bill Moran wrote: > Even better would be for make to realize that it's only doing the > fetching, and do it anyway. That still doesn't help with the problem of a user who starts a 10MB download that won't work on his architecture or OS release. The code is all the same. This is the aggravation we are trying to prevent. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "make index" on 4.10-STABLE
> > RELENG_4 isn't supported, period. You should probably start > researching what it will take to do a fresh install of 7-stable when > it comes out "soonish." That way you'll be future-proofed for the next > couple years anyway. > > hth, > > Doug > Part of my concern is the hardware platform. I know a few machines I have couldn't go past 5.3 without locking during boot. Tried posting to the list and got silence, so I have to keep those machines at 5.3 . So will have to schedule time to see if I can boot some recent install CD's on the 4.10-STABLE server and see if it works... My post was worth a try to get other than the "isn't supported" reply. Tuc ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Ports depending on FORBIDDEN ports
The following three ports are currently FORBIDDEN due to security vulnerabilities but are listed as dependencies by a number of other ports: misc/compat3x: FreeBSD-SA-03:05.xdr, FreeBSD-SA-03:08.realpath - not fixed / no lib available sysutils/eject: Setuid root and has security issues www/zope: contains cross-site scripting vulnerability http://VuXML.FreeBSD.org/34414a1e-e377-11db-b8ab-000c76189c4c.html The misc/compat3x port is unlikely to ever be fixed and therefore it would seem reasonable to deprecate both it and the following ports that depend on it: audio/mbrola MBROLA voice synthesizer databases/java-sqlrelay Java classes to access to SQL Relay emulators/vmware-guestd3 VMware time synchronization daemon for FreeBSD guest OS (for VMware 3.x) emulators/vmware-tools3 VMware tools for guest OS (for VMware 3.x, FreeBSD version) japanese/vje30 Modern intelligent Japanese input engine (purchase version) java/collections JDK1.2 Collections' API for JDK1.1 environments java/gj-jdk11Extension of the Java programming language that supports generic types java/infobus Enables dynamic exchange of data between JavaBeans(TM) java/jdk11 Java Development Kit 1.1 java/jdk12 Java Development Kit 1.2 java/jfc Java Foundation Classes (JFC)/Swing java/jre Standard Java Platform for running Java programs java/tya A ``100% unofficial'' JIT-compiler for java lang/fesiFree EcmaScript Interpreter written in Java mail/pop3vscan A transparent POP3-Proxy with virus-scanning capabilities mail/yuzuA nicer mail user agent powered by JavaMail and JFC/Swing print/acrobatviewer Viewer for the PDF files written in Java(TM) security/amavis-perl Mail Virus Scanner (uses external antivirus) security/amavisd The daemonized version of amavis-perl security/vscan Evaluation version of a DOS/Windows/Linux file virus scanner www/hotjava Sun's Hotjava web browser www/mapedit A WWW authoring tool to create clickable maps www/ssserver Adds the search capability to a Web site I'm particularly concerned about the existence of 'java/jre' and it's description as the 'Standard Java Platform for running Java programs'. This appears to occasionally trap people who are looking for a current JRE and attempt to install java/jre. sysutils/eject only has one port depending on it. eject-1.5 is nearly 7 years old and appears to be abandonware. It would therefore seem reasonable to deprecate both it and the following port that depends on it: sysutils/cdbkup Simple but full-featured backup/restore perl scripts (uses gnu tar) www/zope has a significant number of ports depending on it. This is a very old version of zope (2.7.9) and some of these ports may be able to be adapted to a newer version of zope (2.9, 2.10 or 3.3 - all of which are in ports). www/zope and any of the following ports that can't be adapted to a later version of zope should probably be deprecated: japanese/zope-ejsplitter A Japanese word splitter for searching text in Zope Products japanese/zope-jamailhost A Zope hotfix Product to send mail in Japanese www/knowledgekit A mechanism for the automatic creation/maintenance of Knowledge Bases www/squishdot A web-based news publishing and discussion product for Zope www/znavigatorA Zope product to simplify the construction of navigation bars www/zope-FileSystemSite Enable file system based sites within Zope www/zope-annotations A generic way to add information to arbitrary Zope objects www/zope-archetypes Framework for the development of new Content Types in Zope/CMF/Plone www/zope-btreefolder2 Zope product that can store many items www/zope-calendaring Calendar product for Plone www/zope-cmf The Zope Content Management Framework (CMF) www/zope-cmfactionicons CMFActionIcons product for Zope/CMF www/zope-cmfformcontrollerCMFFormController product for Zope/CMF www/zope-cmfforum A forum for ZOPE CMF with file attachments www/zope-cmfphoto CMFPhoto product for Zope/CMF www/zope-cmfphotoalbumCMFPhotoAlbum product for Zope/CMF www/zope-cmfquickinstallerCMFQuickInstaller is a product for Zope/CMF www/zope-coreblog A Zope Blog/Weblog/Web-nikki Product www/zope-epoz A cross-browser-wysiwyg-editor for Zope/CMF www/zope-exuserfolder Extensible User Folder - Custom & database authenticatoin for Zope www/zope-formulator HTML form generatation and validation system for Zope www/zope-generatorGenerator product fo
Re: "make index" on 4.10-STABLE
RELENG_4 isn't supported, period. You should probably start researching what it will take to do a fresh install of 7-stable when it comes out "soonish." That way you'll be future-proofed for the next couple years anyway. hth, 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: Proposal for another category in INDEX: common_deps
On Fri, 20 Jul 2007 12:01:30 -0700 Doug Barton <[EMAIL PROTECTED]> wrote: > FWIW, the -r option for portmaster only rebuilds those ports that > depend directly on the new version, not things that depend on the > things that depend on it. When portmanager was changed to work this way it seemed sensible. I've become a bit sceptical about it since I saw a post in this list that went something like: X always depends on A, B and C, so don't bother having your port depend on these if it depends on X. I wonder how many direct dependencies are omitted in this way. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "make index" on 4.10-STABLE
On Fri, Jul 20, 2007 at 08:10:58PM -0400, Tuc at T-B-O-H.NET wrote: > > vjofn# mv /etc/make.conf /etc/make.conf.hold > vjofn# make index > Generating INDEX - please wait..===> arabic/ae_fonts_mono failed > *** Error code 1 > ===> accessibility/at-poke failed > *** Error code 1 > 2 errors > You're probably not going to get very far with this. Many ports have had the 4.x compatibility code ripped out now. If you install devel/make (you'll need the 4.x EOL branch) over the make in base you might have a chance of building an INDEX. The above error is actually likely to be due to the recent Xorg checks... try 'make describe' from arabic/ae_fonts_mono. -- Shaun Amott // PGP: 0x6B387A9A "A foolish consistency is the hobgoblin of little minds." - Ralph Waldo Emerson ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
"make index" fails if EMACS_PORT_NAME=emacs21
According to /usr/ports/UPDATING:
If you want to keep using Emacs 21.3, please add EMACS_PORT_NAME=emacs21
to /etc/make.conf and reinstall Emacs from editors/emacs21 port:
After doing this, "make index" fails with:
Generating INDEX-6 - please wait..pcl-cvs-emacs21-2.9.9_2:
"/usr/ports/devel/elib-emacs21" non-existent -- dependency list incomplete
===> devel/pcl-cvs-emacs20 failed
The problem is that pcl-cvs-emacs20 includes EMACS_PORT_NAME?=emacs20
and assumes that there is a port devel/elib-${EMACS_PORT_NAME}. The
version of elib for emacs21 has no suffix (which suggests it may also
need updating for emacs22).
In this particular case, the following would probably work:
.if ${EMACS_PORT_NAME} != "emacs20"
IGNORE="Only for Emacs 20"
.endif
I notice that there are a total of 140 ports that set EMACS_PORT_NAME
so a more general solution is probably desirable. Does anyone have
any suggestions?
--
Peter Jeremy
pgp6bezcx3U98.pgp
Description: PGP signature
"make index" on 4.10-STABLE
Hi,
(Yea, yea, I know... Its my personal machine and I've got so
much rigged up that I don't know it would upgrade well to 5, let along
past that)
I cvsup the ports-all as of 2 minutes before attempting. Running
4.10-STABLE, x86, standard env.
When I run it with my full make.conf, I get :
Generating INDEX - please wait.."/usr/ports/audio/gstreamer-plugins-esound/../..
/multimedia/gstreamer-plugins/Makefile.common", line 391: Malformed conditional
(${gst_${GST_PLUGIN}_GCONF_SCHEMAS}!="")
"/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/gstreamer-plugins/Ma
kefile.common", line 395: Malformed conditional (${gst_${GST_PLUGIN}_USE_SDL}!="
")
"/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/gstreamer-plugins/Ma
kefile.common", line 397: if-less endif
"/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/gstreamer-plugins/Ma
kefile.common", line 397: Need an operator
"/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/gstreamer-plugins/Ma
kefile.common", line 418: if-less endif
"/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/gstreamer-plugins/Ma
kefile.common", line 418: Need an operator
make: fatal errors encountered -- cannot continue
===> audio/gstreamer-plugins-esound failed
*** Error code 1
1 error
When I move it out of the way :
vjofn# mv /etc/make.conf /etc/make.conf.hold
vjofn# make index
Generating INDEX - please wait..===> arabic/ae_fonts_mono failed
*** Error code 1
===> accessibility/at-poke failed
*** Error code 1
2 errors
Thanks, Tuc
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overly restrictive checks in the make process
In response to [EMAIL PROTECTED] (Mark Linimon): > On Fri, Jul 20, 2007 at 08:58:55AM -0400, Bill Moran wrote: > > Why? Is there a legitimate reason why the fetch process refuses to > > download this? > > The intention of the logic is to warn a user, as soon as possible, that > they are spending time on something that will wind up being IGNOREd if > it is installed. There is no logic there to try to figure out "later > version of port"; it simply looks for "is IGNORE set?" > > Since some downloads take a long time, this does not seem too unreasonable > to me. > > If we moved the check later, the process of trying to install a port that > would be IGNOREd would be: spend time fetching and checksumming it, and > only then tell the user that they had wasted their time. I suspected there was some reasoning along that line. > I think the best we could do is add something analagous to how > DISABLE_VULNERABILITIES factors into it, and allow foot-shooting only > if demanded, but turn it off by default. That would be less annoying than having to constantly hack files in /usr/ports/Mk ... :) Even better would be for make to realize that it's only doing the fetching, and do it anyway. I don't know if this is possible, though. Sooner or later, the person running the system is going to pull out the foot-gun (you can only protect them so much) and waiting for a download that can't install is a comparatively small bullet ... -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overly restrictive checks in the make process
On Fri, Jul 20, 2007 at 08:58:55AM -0400, Bill Moran wrote: > Why? Is there a legitimate reason why the fetch process refuses to > download this? The intention of the logic is to warn a user, as soon as possible, that they are spending time on something that will wind up being IGNOREd if it is installed. There is no logic there to try to figure out "later version of port"; it simply looks for "is IGNORE set?" Since some downloads take a long time, this does not seem too unreasonable to me. If we moved the check later, the process of trying to install a port that would be IGNOREd would be: spend time fetching and checksumming it, and only then tell the user that they had wasted their time. I think the best we could do is add something analagous to how DISABLE_VULNERABILITIES factors into it, and allow foot-shooting only if demanded, but turn it off by default. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposal for another category in INDEX: common_deps
On Fri, Jul 20, 2007 at 12:40:02PM -0700, [EMAIL PROTECTED] wrote: > >> the INDEX files -- so many that I think that items common to both > >> build_deps and run_deps should be isolated and put into a new category > >> called 'common_deps': > > > >How will this benefit us? > > > >Doug > > Reduce amount of processed text. If you read the log I posted there are a > large number of what I refer to as 'excess characters'. These are the > duplicate characters in both BUILD_DEPENDS and RUN_DEPENDS. IMHO the change in file format (and resulting POLA problems) outweighs the benefits of the faster scan. I'd rather see us audit the ports and try to eliminate unneeded entries in each. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposal for another category in INDEX: common_deps
On Fri, 20 Jul 2007, Mark Linimon wrote: On Fri, Jul 20, 2007 at 12:40:02PM -0700, [EMAIL PROTECTED] wrote: the INDEX files -- so many that I think that items common to both build_deps and run_deps should be isolated and put into a new category called 'common_deps': How will this benefit us? Doug Reduce amount of processed text. If you read the log I posted there are a large number of what I refer to as 'excess characters'. These are the duplicate characters in both BUILD_DEPENDS and RUN_DEPENDS. IMHO the change in file format (and resulting POLA problems) outweighs the benefits of the faster scan. I'd rather see us audit the ports and try to eliminate unneeded entries in each. mcl I agree in most cases, but what if the view of the initial problem is not correct or the conditions have evolved? -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposal for another category in INDEX: common_deps
On Fri, Jul 20, 2007 at 05:11:27PM +0200, Michel Talon wrote: > The only relevant info for determining what to install or build > previously is RUN_DEPENDS and BUILD_DEPENDS. Everything else is garbage. The pointyhat error logs would tend to indicate that this isn't correct. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with +CONTENTS being messed up by pkg_delete -f
On Fri, 20 Jul 2007, Doug Barton wrote: Garrett Cooper wrote: Personally I think that: 1. Versions shouldn't matter when calculating absolute dependencies (i.e. net/samba may depend on popt). Can you give some kind of context for this comment? 2. If versions do change for a dependent package, the packages dependent on the changed package should also be rebuilt. N, that should definitely not be the default, as it's hardly ever necessary to actually do that, and when it is we have more than enough ports management tools nowadays to handle it. Doug I've been digesting other comments lately and this thinking isn't the best. I'll kill my other email thread and re-propose another idea after a little more consideration. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposal for another category in INDEX: common_deps
On Fri, 20 Jul 2007, Doug Barton wrote: Garrett Cooper wrote: >I just ran a quick analysis with a Perl script and found that there > are a number of similarities in the build_deps and run_deps fields in > the INDEX files -- so many that I think that items common to both > build_deps and run_deps should be isolated and put into a new category > called 'common_deps': How will this benefit us? Doug Reduce amount of processed text. If you read the log I posted there are a large number of what I refer to as 'excess characters'. These are the duplicate characters in both BUILD_DEPENDS and RUN_DEPENDS. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with +CONTENTS being messed up by pkg_delete -f
Garrett Cooper wrote: > Personally I think that: >1. Versions shouldn't matter when calculating absolute dependencies > (i.e. net/samba may depend on popt). Can you give some kind of context for this comment? >2. If versions do change for a dependent package, the packages > dependent on the changed package should also be rebuilt. N, that should definitely not be the default, as it's hardly ever necessary to actually do that, and when it is we have more than enough ports management tools nowadays to handle it. 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: Proposal for another category in INDEX: common_deps
Garrett Cooper wrote: >I just ran a quick analysis with a Perl script and found that there > are a number of similarities in the build_deps and run_deps fields in > the INDEX files -- so many that I think that items common to both > build_deps and run_deps should be isolated and put into a new category > called 'common_deps': How will this benefit us? 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: Proposal for another category in INDEX: common_deps
Matthew Seaman wrote: > In many ways it would be more useful to delete from the > EXTRACT_DEPENDS, FETCH_DEPENDS, PATCH_DEPENDS, BUILD_DEPENDS[*] > lists in the INDEX any package that also appears in the RUN_DEPENDS > list. This leaves the four listed fields with just the extra > packages that need to be present at build/install time. Everything that is needed to build the port must be in BUILD_DEPENDS. Everything necessary to run the port must be in RUN_DEPENDS. This is needed to support building packages on one machine, and running them on another. I do agree however that that the other categories should be coalesced into BUILD_DEPENDS. I also agree that a lot of maintainers seem to blindly copy dependencies into both categories without understanding why. > Take for example the effect of the devel/gettext port. At the > moment, the usual advice when there's a shlib version bump for > gettext is to force a rebuild of everything that depends on it: > >portupgrade -fr gettext-0.16.1_3 > > This however means that anything that uses a tool that is linked > against gettext is forcibly recompiled FWIW, the -r option for portmaster only rebuilds those ports that depend directly on the new version, not things that depend on the things that depend on it. > -- and as gmake depends on > gettext that means a very large fraction of the ports most people > have installed. However, if the only way an application depends on > gettext is via gmake /at build time/ then rebuilding that > application is really not necessary. Using LIB_DEPENDS to > distinguish ports that are linked against any particular shlib > versus those that inherit a dependency against a shlib for other > reasons could save rather a lot of wasted CPU cycles. I don't see how we need a separate LIB_DEPENDS to achieve this. Can you describe in more detail the mechanism you have in mind? 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: Problems with +CONTENTS being messed up by pkg_delete -f
* Alexander Leidinger <[EMAIL PROTECTED]> [gmane.os.freebsd.devel.ports]: > Quoting Robert Noland <[EMAIL PROTECTED]> (Thu, 19 Jul 2007 13:31:42 -0400): > >> Ok, so the issue that I hope to address is not really a "portmanager" >> issue. The original version of package-depends always listed the >> current version (from ports) in the +CONTENTS file. When that list was >> passed to sort -u, you ended up with a single dependency for each >> origin. >> >> The new way it takes each direct dependency and adds those, then >> recursively parses the +CONTENTS file of each of those and adds those >> entries and finally passes the whole thing to sort -u. This allows for >> multiple dependencies with the same origin to be listed in the +CONTENTS >> file. >> >> As an example... port a depends on b and c. Port c has a version bump >> and is updated but technically b doesn't require an update. Now if port >> a is updated it will get the current version of c and also the old >> version of c from b. > > Ok, I see the problem (in case b depends on c too). This is only an > issue if you do this by hand instead of using portupgrade (or something > else), as those tools should correct the dependency in port b to the > new version of c. If they don't do it, it's a bug in those tools. Oh not at all. This will also happen if you install dependencies via packages when these packages' dependencies do not exactly match what you have presently installed. Example: package a-1.0 has a recorded dependency on b-1.0. Meanwhile, b got upgraded to 1.0_1. You have b-1.0_1 installed locally and then install port c which depends on a and use a's package in order to save build time (imagine a being something in the firefox/xorg-libs range with USE_PACKAGE_DEPENDS set in your make environment). Hilarity ensues. The old algorithm could recover from this I guess. It looks like one is forced to repair the package db with external tools everytime one does not install from source and from scratch. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Port: ntop-3.3
On Wed, Jul 11, 2007 at 09:50:04AM +0200, [EMAIL PROTECTED] wrote: > Hi, > I've got a question, when do you plan to release port to the new version > of ntop 3.3 ? http://www.freebsd.org/cgi/query-pr.cgi?pr=114681 I'm sure it will be handled whenever possible by a committer. -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overly restrictive checks in the make process
In response to Jeremy Chadwick <[EMAIL PROTECTED]>: > On Fri, Jul 20, 2007 at 09:14:32AM -0700, Garrett Cooper wrote: > > Sounds like a +CONFLICTS type of issue (the MySQL client and server files > > for instance install some libs in the same spot, so they conflict IIRC). > > Not as far as I know. "make install" in databases/mysql50-server > will cause databases/mysql50-client to get installed. Verification > of the results: > > (09:32:40 [EMAIL PROTECTED]) ~ $ pkg_info | grep ^mysql > mysql-client-5.0.41 Multithreaded SQL database (client) > mysql-server-5.0.41 Multithreaded SQL database (server) > > I think what Bill was asking about, though, was why the IGNORE in > the port is getting hit for "make fetch". For "make" or "make install" > or other such things, it seems valid, but for fetching distdata it > seems erroneous. That is correct. I apologize if I was unclear earlier. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overly restrictive checks in the make process
On Fri, Jul 20, 2007 at 09:14:32AM -0700, Garrett Cooper wrote: > Sounds like a +CONFLICTS type of issue (the MySQL client and server files > for instance install some libs in the same spot, so they conflict IIRC). Not as far as I know. "make install" in databases/mysql50-server will cause databases/mysql50-client to get installed. Verification of the results: (09:32:40 [EMAIL PROTECTED]) ~ $ pkg_info | grep ^mysql mysql-client-5.0.41 Multithreaded SQL database (client) mysql-server-5.0.41 Multithreaded SQL database (server) I think what Bill was asking about, though, was why the IGNORE in the port is getting hit for "make fetch". For "make" or "make install" or other such things, it seems valid, but for fetching distdata it seems erroneous. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overly restrictive checks in the make process
In response to Garrett Cooper <[EMAIL PROTECTED]>:
> Bill Moran wrote:
> > [EMAIL PROTECTED] /usr/ports/databases/postgresql82-server]# make
> > fetch-recursive
> > ===> Fetching all distfiles for postgresql-server-8.2.4_1 and dependencies
> > ===> postgresql-server-8.2.4_1 cannot install: the port wants
> > postgresql82-client but you have postgresql81-client installed.
> > *** Error code 1
> >
> > Why? Is there a legitimate reason why the fetch process refuses to
> > download this? I know I've got an older version installed, but why
> > is it preventing me from downloading a newer one? Seems like the
> > IGNORE= check is either being checked too aggressively or that the
> > logic is less sophisticated than it should be.
> >
> > Does anyone know of a reason why this couldn't be changed to allow
> > fetching of conflicting ports distfiles?
>
> Sounds like a +CONFLICTS type of issue (the MySQL client and server
> files for instance install some libs in the same spot, so they conflict
> IIRC).
Actually, it's IGNORE, as I stated earlier:
.if defined(WANT_PGSQL_VER) && defined(_PGSQL_VER) && ${WANT_PGSQL_VER} !=
${_PGSQL_VER}
IGNORE= cannot install: the port wants
postgresql${WANT_PGSQL_VER}-client but you have postgresql${_PGSQL_VER}-client
installed
.endif
and the same behaviour is used all through the ports collection ...
php4/php5 is another example.
But that's nit-picky details. My question is _why_ is that check run
for fetch? I can see no reason why it's taboo to fetch multiple port
versions, and in the case of an upgrade where time is short, having
the package fetched prior to the outage window can be a huge time-
saver.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overly restrictive checks in the make process
Bill Moran wrote: [EMAIL PROTECTED] /usr/ports/databases/postgresql82-server]# make fetch-recursive ===> Fetching all distfiles for postgresql-server-8.2.4_1 and dependencies ===> postgresql-server-8.2.4_1 cannot install: the port wants postgresql82-client but you have postgresql81-client installed. *** Error code 1 Why? Is there a legitimate reason why the fetch process refuses to download this? I know I've got an older version installed, but why is it preventing me from downloading a newer one? Seems like the IGNORE= check is either being checked too aggressively or that the logic is less sophisticated than it should be. Does anyone know of a reason why this couldn't be changed to allow fetching of conflicting ports distfiles? Sounds like a +CONFLICTS type of issue (the MySQL client and server files for instance install some libs in the same spot, so they conflict IIRC). -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Port: print/ghostscript-gpl
Hi, in the actual version ljet4d does not do duplex printing. The hardware duplexer is used but simplex (every page is printed on one physical sheet of paper) printing is done. Printer is a HP Laserjet 4 Plus. I've tested the old ghostscript-gnu (7.07) and ljet4d works well. So it seems to be a bug in actual ghostscript-gpl versions. It wouls be nice if someone can fix this issue. best regards -Stefan -- GPG-encrypted mail welcome! --> ID:E970FCBE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposal for another category in INDEX: common_deps
Matthew Seaman wrote: > Another interesting idea would be to separate out the LIB_DEPENDS > data. At the moment there is a separate LIB_DEPENDS variable that > can be used in Makefiles, but the INDEX processing includes the > LIB_DEPENDS data with both the BUILD_DEPENDS and the RUN_DEPENDS > fields. Keeping LIB_DEPENDS separate should allow a useful > optimization in the case of shlib ABI version number bumps. > Clear that you are the author of http://www.infracaninophile.co.uk/portindex/ and so know the state of the Index stuff from inside out! Personnally i think there are far too many totally useless categories here, as you are saying, only RUN_DEPENDS and BUILD_DEPENDS have any usefulness, the first if you install from packages, the second if you install from ports. It is totally irrelevant to know if a dependency is FETCH, EXTRACT or whatever, since you need it anyway to build the port. Merging LIB_DEPENDS in both BUILD and RUN is justified since you need the libraries both for compiling and for running the port. Introducing a lot of dependency categories renders writing an upgrade mechanism very complicated. Either you coalesce everything into one big category, voiding the distinctions of their content, or you have to introduce an infinitely complicated logic to take care of them. For example you explain that knowing only LIB_DEPENDS would help knowing what to upgrade when gettext is bumped. But other ports may have important dependencies not going through LIB_DEPENDS. You need a crystal ball to disentangle all the cases. An upgrade mechanism can proceed with a mixture of packages and ports, for example portupgrade -P. The only relevant info for determining what to install or build previously is RUN_DEPENDS and BUILD_DEPENDS. Everything else is garbage. The Debian people have a simpler situation with apt-get, they have only one sort of dependency to consider, the equivalent of RUN_DEPENDS. Hence they can build a reliable sorted graph of dependencies. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Port: samba-3.0.25a_1,1
Hi! I've noticed a bug in this recent version of Samba which forced me to downgrade to version 3.0.24,1. It has something to do with fusefs-unionfs, but I don't know how. (The port fusefs-unionfs does only work if you install fusefs-libs version <2.7.0, if you want to test this out. I had to use portdowngrade. This has been reported to the unionfs port maintainer.) 1: install fusefs-unionfs, do fusefs_enable=YES in rc.conf, reboot 2: Mount up a unionfs-folder using something like: /root% unionfs -o ro,allow_other /disk/disk1:/disk/disk2 /alldisk 3: Share /alldisk with samba. Point 3 doesn't work with samba-3.0.25a_1,1, but it works just fine with 3.0.24,1. With 25a_1,1, panic action occurs every time a machine tries to access /alldisk through samba, and smbd restarts itself. Any more info needed? - Mads ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Overly restrictive checks in the make process
[EMAIL PROTECTED] /usr/ports/databases/postgresql82-server]# make fetch-recursive ===> Fetching all distfiles for postgresql-server-8.2.4_1 and dependencies ===> postgresql-server-8.2.4_1 cannot install: the port wants postgresql82-client but you have postgresql81-client installed. *** Error code 1 Why? Is there a legitimate reason why the fetch process refuses to download this? I know I've got an older version installed, but why is it preventing me from downloading a newer one? Seems like the IGNORE= check is either being checked too aggressively or that the logic is less sophisticated than it should be. Does anyone know of a reason why this couldn't be changed to allow fetching of conflicting ports distfiles? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with +CONTENTS being messed up by pkg_delete -f
Quoting Robert Noland <[EMAIL PROTECTED]> (Thu, 19 Jul 2007 13:31:42 -0400): > On Wed, 2007-07-18 at 21:18 -0700, Garrett Cooper wrote: > > > Stephen, > > I admire your willingness to help, but I believe that Robert should > > be the one detailing the problem not you. That way too much confusion > > doesn't get aroused on the list(s). > > I'm going to remove hackers@ from the CC list because this almost > > exclusively pertains to [EMAIL PROTECTED] > > -Garrett > > Ok, so the issue that I hope to address is not really a "portmanager" > issue. The original version of package-depends always listed the > current version (from ports) in the +CONTENTS file. When that list was > passed to sort -u, you ended up with a single dependency for each > origin. > > The new way it takes each direct dependency and adds those, then > recursively parses the +CONTENTS file of each of those and adds those > entries and finally passes the whole thing to sort -u. This allows for > multiple dependencies with the same origin to be listed in the +CONTENTS > file. > > As an example... port a depends on b and c. Port c has a version bump > and is updated but technically b doesn't require an update. Now if port > a is updated it will get the current version of c and also the old > version of c from b. Ok, I see the problem (in case b depends on c too). This is only an issue if you do this by hand instead of using portupgrade (or something else), as those tools should correct the dependency in port b to the new version of c. If they don't do it, it's a bug in those tools. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposal for another category in INDEX: common_deps
On Friday, 2007-07-20 at 01:18:02 -0700, Garrett Cooper wrote: > %cat /dev/zero 2> /dev/null > /dev/null > Ambiguous output redirect. You're trying to use Bourne Shell Syntax with the csh. With csh, you can only redirect stdout and stderr together like this: %cat /dev/zero >& /dev/null Lupe Christoph -- | You know we're sitting on four million pounds of fuel, one nuclear | | weapon and a thing that has 270,000 moving parts built by the lowest | | bidder. Makes you feel good, doesn't it? | | Rockhound in "Armageddon", 1998, about the Space Shuttle | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposal for another category in INDEX: common_deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Garrett Cooper wrote: >I just ran a quick analysis with a Perl script and found that there > are a number of similarities in the build_deps and run_deps fields in > the INDEX files -- so many that I think that items common to both > build_deps and run_deps should be isolated and put into a new category > called 'common_deps': Of all the *_DEPENDS fields in the INDEX, RUN_DEPENDS is the big deal. The other *_DEPENDS fields only apply at certain stages of building and installing the package. If you install from pre-compiled pkgs many of those other dependencies would be unnecessary to have installed. In many ways it would be more useful to delete from the EXTRACT_DEPENDS, FETCH_DEPENDS, PATCH_DEPENDS, BUILD_DEPENDS[*] lists in the INDEX any package that also appears in the RUN_DEPENDS list. This leaves the four listed fields with just the extra packages that need to be present at build/install time. Another interesting idea would be to separate out the LIB_DEPENDS data. At the moment there is a separate LIB_DEPENDS variable that can be used in Makefiles, but the INDEX processing includes the LIB_DEPENDS data with both the BUILD_DEPENDS and the RUN_DEPENDS fields. Keeping LIB_DEPENDS separate should allow a useful optimization in the case of shlib ABI version number bumps. Take for example the effect of the devel/gettext port. At the moment, the usual advice when there's a shlib version bump for gettext is to force a rebuild of everything that depends on it: portupgrade -fr gettext-0.16.1_3 This however means that anything that uses a tool that is linked against gettext is forcibly recompiled -- and as gmake depends on gettext that means a very large fraction of the ports most people have installed. However, if the only way an application depends on gettext is via gmake /at build time/ then rebuilding that application is really not necessary. Using LIB_DEPENDS to distinguish ports that are linked against any particular shlib versus those that inherit a dependency against a shlib for other reasons could save rather a lot of wasted CPU cycles. Cheers, Matthew [*] One thing that has puzzled me: why there is no 'INSTALL_DEPENDS' variable? Given there are variables to cover all of the other principal stages in building a port, it seems an odd omission. - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGoHEf8Mjk52CukIwRCGXYAJ9aFO3BAWJU+HKWhx3fMJ4ZjnI5lgCeJ/Bl hULiTPawL83GYKEP5hgm0Zk= =DNH/ -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: Proposal for another category in INDEX: common_deps
Garrett Cooper wrote: Lupe Christoph wrote: On Thursday, 2007-07-19 at 23:55:14 -0700, Garrett Cooper wrote: redirecting input in and out doesn't work for (t)csh Huh?!? [EMAIL PROTECTED]:~$ csh %cat > /tmp/aaa Some garbage text %cat < /tmp/aaa > /tmp/bbb %cat /tmp/bbb Some garbage text Lupe Christoph Ok, the document I was reading must have been outdated, or about the original csh. The current csh points tcsh, which is a lot more vamped up than the original Berkeley csh I believe: [EMAIL PROTECTED] ~]$ csh --help | grep tcsh tcsh 6.15.00 (Astron) 2007-03-03 (i386-intel-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec See the tcsh(1) manual page for detailed information. -Garrett Sorry, this is what I meant: %cat /dev/zero 2> /dev/null > /dev/null Ambiguous output redirect. Since I only output to STDOUT, it isn't a problem. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposal for another category in INDEX: common_deps
Lupe Christoph wrote: On Thursday, 2007-07-19 at 23:55:14 -0700, Garrett Cooper wrote: redirecting input in and out doesn't work for (t)csh Huh?!? [EMAIL PROTECTED]:~$ csh %cat > /tmp/aaa Some garbage text %cat < /tmp/aaa > /tmp/bbb %cat /tmp/bbb Some garbage text Lupe Christoph Ok, the document I was reading must have been outdated, or about the original csh. The current csh points tcsh, which is a lot more vamped up than the original Berkeley csh I believe: [EMAIL PROTECTED] ~]$ csh --help | grep tcsh tcsh 6.15.00 (Astron) 2007-03-03 (i386-intel-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec See the tcsh(1) manual page for detailed information. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
