Re: [ports/databases/sqlite3] WITH_GCOV breaks ports/security/nss
Hello all. Sorry for such a long wait. Yes, you are right. Error really manifests itself when using sqlite is compiled with the profiling. Determine the cause of falls, me have not yet succeeded. At the same time, profiling can be used for most sqlite. I propose to remove options enable debugging and profiling from a list of available options, but leave to call them from the command line for the public. Pay attention to PR #153498. Thanks. On Fri, Dec 10, 2010 at 20:46, Norikatsu Shigemura wrote: > Hi sqlite3 maintainer. > > I confirmed that I couldn't compile security/nss by databases/sqlite3 > WITH_GCOV. So I suggest that it should be BROKEN. How about > do you think? > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > --- Makefile.orig 2010-11-14 01:21:33.499802000 +0900 > +++ Makefile 2010-12-11 02:45:34.073992291 +0900 > @@ -53,7 +53,7 @@ > EXTENSION "Allow loadable extensions" on \ > TCLWRAPPER "Enable TCL wrapper" off \ > DEBUG "Enable debugging & verbose explain" off \ > - GCOV "Enable coverage testing using gcov" off \ > + GCOV "Enable coverage testing using gcov (broken)" > off \ > > .include > > @@ -78,6 +78,7 @@ > .if defined(WITH_GCOV) > CONFIGURE_ARGS+= --enable-gcov > LDFLAGS+= -fstack-protector > +BROEKN= WITH_GCOV breaks security/nss. > .endif > > .if defined(WITH_MEMMAN) > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > -- > Norikatsu Shigemura > ___ 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"
[SOLVED] Re: ImageMagick, Djvu, and Perl-threaded - marked as IGNORE when updating
On 12/28/10 21:55, David Southwell wrote: > > > On 12/27/10, David Southwell wrote: > > > >> On 12/27/10, David Southwell wrote: > > > > Agreed - but following Doug's commit I can vouch that the > > > > PERL_THREADED hack > > > > was still needed for 7.2 p3 systems on amd64. > > > > > > It shouldn't be needed. Can you remove this definition from any > > > locally-modified Makefiles, and provide the same information that was > > > requested from Da Rock? (Why do I feel like a WWE announcer when I > > > type that? ...) > > > > > > b. > > > > I do not want to rebuild WITHOUT_IMAGEMAGICK_PERL on a running system > > with active user access which needs perl. > > > > Have you got the replies from Da Rock? > > Before going any further I would suggest that Da Rock be advised to update > his ports tree followed by > > # pkgdb -F > Fix any problems then. If there are any problems he cannot fix at this > stage then report those. Then: > > # portmaster -a or portupgrade -a > > > If he gets any failure which may possibly be linked to a Perl problem he > should rebuild perl with upward and downward recursion. e.g > #portupgrade -rR lang/perl5.8 I dare say I'd come back with an error given I have 5.10 installed on the system. > > Until that is completed any other report could send us off on a wild goose > chase. > > My twopennorth > I can do what you suggested when we have a report from Da Rock with his results from a system with thoroughly updated ports. My guess is that his probs will be solved by the above. Ok, so it took a while and I'm still reviewing some other issues. The real problem is that the error msg sends all on a wild goose chase. I got it updated but the problem had absolutely nothing to do with perl, djvu, and their threads. After some scratching about with configs and Makefiles, I discover there is an option not selected (not sure why) dealing with ImageMagick's threads- not perls or djvus! Now, IF those options are selected (and remember this is an upgrade) why not assume threads and print an info msg saying so? And why does the error msg not even allude to this instead of sending everyone on a chase after a mythical error that is not even the fault of the dependency? Thanks for the hints guys, but I'm now trying to figure a method that may resolve this type of issue in the future- I remember using dialog boxes in extremely old installs of linux (and BSD packages I think) that automatically selects or deselects based on a selections required/incompatible dependencies. That would save hours of fart-arsing about for many- even searching for known answers takes time, easily resolved if something stable can be figured this way. Thanks again. ___ 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"
no compiler detected to compile 'src/LangBulgarianModel.cpp
I'm trying to upgrade this perl port and I'm getting the following error: Error: no compiler detected to compile 'src/LangBulgarianModel.cpp'. Aborting Anyone know how to correct this? ===> p5-Encode-Detect-1.01 depends on file: /usr/local/bin/perl5.8.9 - found ===> Patching for p5-Encode-Detect-1.01 ===> p5-Encode-Detect-1.01 depends on file: /usr/local/bin/perl5.8.9 - found ===> p5-Encode-Detect-1.01 depends on file: /usr/local/lib/perl5/site_perl/5.8.9/ExtUtils/CBuilder.pm - found ===> p5-Encode-Detect-1.01 depends on file: /usr/local/lib/perl5/site_perl/5.8.9/Module/Build.pm - found ===> p5-Encode-Detect-1.01 depends on file: /usr/local/bin/perl5.8.9 - found ===> Configuring for p5-Encode-Detect-1.01 Warning: ExtUtils::CBuilder not installed or no compiler detected Proceeding with configuration, but compilation may fail during Build Creating new 'MYMETA.yml' with configuration results Creating new 'Build' script for 'Encode-Detect' version '1.01' ===> Building for p5-Encode-Detect-1.01 Building Encode-Detect Error: no compiler detected to compile 'src/LangBulgarianModel.cpp'. Aborting *** Error code 2 Stop in /usr/ports/converters/p5-Encode-Detect. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20101228-1340-1ixmwrk-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=p5-Encode-Detect-1.01 UPGRADE_PORT_VER=1.01 make ** Fix the problem and try again. ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! converters/p5-Encode-Detect (p5-Encode-Detect-1.01) (unknown build error) ___ 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: print /usr/ports/UPDATING on update
On Tue, 28 Dec 2010 16:38:57 -0800 Doug Barton wrote: > On 12/28/2010 15:10, RW wrote: > > On Tue, 28 Dec 2010 10:55:04 -0800 > > Doug Barton wrote: > > on perl). At the moment, I read it once, make a mental note, and > > come back to it when I need it. I don't think a portaudit style > > tool could handle it as well. > > Sure it could, you just have to use a little imagination. :) You'd > need categories of entries. Eygene touched on this in his post, but > you'd want things that are relevant pre- and post-upgrade, optional > elements (like the one you pointed out), etc. It's not really a question of classification, the issue is that some entries will cause ports to be permanantly noteworthy. At the moment I see that perl entry once (I diff UPDATING). What if I don't want to switch for months? Is it going to show me that information over and over again until I do? Is it going to recorded that I read it, do I have to manually acknowledge it? > > What I think would make it worthwhile is it it could abstract all > > those simple update recipes like recursive updates, deleting > > packages, moving origins, so that a build tool could roll them up > > and handle them automatically. > > For the most part this wouldn't be hard to do, > especially for the -o and -r type entries. For the more complex stuff > it may be necessary to have separate entries per-tool, but once again > that's not particularly hard to do. I was thinking in terms of abstracting it, so that it describes what need to be done, rather than how. ___ 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: print /usr/ports/UPDATING on update
On 12/28/2010 15:10, RW wrote: On Tue, 28 Dec 2010 10:55:04 -0800 Doug Barton wrote: When I wrote, "we need a tool with striking similarities to portaudit" without providing the details I was assuming that people are already familiar with it, how it works, etc. I don't think it's quite as simple as dealing with vulnerabilities. For example 20100715, the announcement of lang/perl5.12. This affects all version of lang/perl5.10 (and IMO any ports that depend on perl). At the moment, I read it once, make a mental note, and come back to it when I need it. I don't think a portaudit style tool could handle it as well. Sure it could, you just have to use a little imagination. :) You'd need categories of entries. Eygene touched on this in his post, but you'd want things that are relevant pre- and post-upgrade, optional elements (like the one you pointed out), etc. If you update ports regularly, UPDATING is a non-issue. I can skip the irrelevant entries in seconds. To me the chief problems are delayed entries and incomplete entries. Good point you're making #1, I'm looking at this from the standpoint of, "I just inherited this system that hasn't had ports updated in 14 months. Where do I start in order to not make a complete mess?" Now the obvious/flippant answer is, "You start over from scratch," but that's not always possible. What I think would make it worthwhile is it it could abstract all those simple update recipes like recursive updates, deleting packages, moving origins, so that a build tool could roll them up and handle them automatically. ... and this is good point #2. There are a lot of entries in UPDATING of the form, "If you use tool X, do Y; if you use tool A, do B. I'd like to see a standardized form of representing that kind of thing so that users of portmaster would see just the instructions relevant to them, for example. For the most part this wouldn't be hard to do, especially for the -o and -r type entries. For the more complex stuff it may be necessary to have separate entries per-tool, but once again that's not particularly hard to do. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: print /usr/ports/UPDATING on update
On 12/28/2010 12:31, Eygene Ryabinkin wrote: Doug, good day. Tue, Dec 28, 2010 at 10:55:04AM -0800, Doug Barton wrote: Do either of you actually have any familiarity at all with how portaudit works, and/or how it is integrated into the ports infrastructure? Based on what you've written today my guess is "no." I am sorry, but you're wrong here: I am familiar with portaudit and its internals: Excellent! But the portaudit has very precise semantics: "if you have the port X with versions in, then it is vulnerable, here is the link to the advisory". Please note, I did not say "Must be exactly like portaudit." Obviously we need to think about the requirements, and design accordingly. Let me explain my worries again. What I meant is the following: one can use XML/JSON/SomeOtherMarkup for the UPDATING.ng. But why bother if the current UPDATING format can be slightly extended and semantics can be attached to it without using the new fancy languages that will need some specific ports to be installed in order to process them? First, from the user side we're talking about one port, the one to display the information. Users of portaudit do not need to have xml installed. Second, the "why?" is so that we can make it easier to deal with programmatically, and hopefully as a result to extend its functionality. I read your argument about reusing the VuXML machinery; it is addressed below. You write that From the user side, we're not really losing anything by not having "human readable" output readily available, since 99% of users will just want to be able to know what entries are relevant to their installation anyway. but do you know how many users rely on the current UPDATING format? Humorous answer, "not enough." Hopefully useful answer, at this point, 100% of them, since that's the only alternative. Hopefully _more_ useful answer, I think very very few (as in, single digit percentages) would even bother to look at a text UPDATING file if they could get the answer to "is there anything in there that affects me?" with one quick command line. Personally, I -- don't, so I can't make such assertions with confidence. Surely, we can have a tool that will output all entries in the current UPDATING format -- it will save everyone who relies on the current state of this file. Not to belabor the point, but I specifically said that I believe having this ability would be a requirement for the new tool. The XML in VuXML (that is used to create the portaudit database and entries at http://www.vuxml.org/freebsd/) is mainly needed because VuXML entries use HTML markup, so it is just easier to allow the whole tag to contain XHTML, because it can contain links, references, lists and other markup. So, the nested structure of XML fits here rather good. But, if you will suppress the complex structure, you can reformat the VuXML into the pseudo-RFC822 format and write a simple validator for it. XML has XSLT that can be used for transform into HTML, so it is another reason why VuXML should be XML, but again, mainly the body content plays its role here. The structure can be expressed via the RFC822-like headers -- there is no problem to parse and validate it. You bring up a very good point here that someone in #bsdports also mentioned, that having UPDATING in xml would allow us to easily produce an HTML version of the file for use on the web site. Current UPDATING is a lot simpler: it already has the pseudo-RFC822 form and it is perfectly human-readable. What we need is the good AFFECTS structure with clear semantics and validator for it. I am not saying that we can't XML here, I am just pointing out that it can be done without XML and, thus, we don't need the dependencies on the XML/DTD/XSLT stuff at all. And I'm saying that even with the current, limited functionality that we expect from UPDATING that a text version parser is a non-starter. So, if we're going to need to create both a structure and a parser then we are much better off re-using existing tools, knowledge, and infrastructure to do that. So, in my opinion, if I'll weight the pros (existing tools, standard validation) and cons (throws a lot of tags to the reader, unsure how to keep the current form of UPDATING's distribution) Both of those "cons" are totally invalid. The consumers of the portaudit data never look at the xml form, nor would the consumers of the data for the tool I'm proposing. I've also specified that the tool should be able to output a text format of the file. Thinking about portaudit, UPDATING in this form will be more-or-less equal to the auditfile. And currently, UPDATING has all important properties of an auditfile, but one: AFFECTS have no clear syntax and semantics (and UPDATING has slightly other format, but it is consistent throughout the whole file, so it really doesn't matter). About reusing the current VuXML machinery for UPDATING: - there will be just another schema f
Re: portmaster: print /usr/ports/UPDATING on update
On Tue, 28 Dec 2010 10:55:04 -0800 Doug Barton wrote: > When I wrote, "we need a tool with striking similarities to > portaudit" without providing the details I was assuming that people > are already familiar with it, how it works, etc. I don't think it's quite as simple as dealing with vulnerabilities. For example 20100715, the announcement of lang/perl5.12. This affects all version of lang/perl5.10 (and IMO any ports that depend on perl). At the moment, I read it once, make a mental note, and come back to it when I need it. I don't think a portaudit style tool could handle it as well. If you update ports regularly, UPDATING is a non-issue. I can skip the irrelevant entries in seconds. To me the chief problems are delayed entries and incomplete entries. What I think would make it worthwhile is it it could abstract all those simple update recipes like recursive updates, deleting packages, moving origins, so that a build tool could roll them up and handle them automatically. ___ 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: print /usr/ports/UPDATING on update
Tue, Dec 28, 2010 at 11:31:13PM +0300, Eygene Ryabinkin wrote: > But in order to move this activity any further, I'll need for a > constructive feedback. I think that I'll try to summarize the current > thoughts at the FreeBSD Wiki, will post the link once I'll do that. http://wiki.freebsd.org/EygeneRyabinkin/PortsUpdatingNg -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpjt9HApPp7h.pgp Description: PGP signature
qt4-pixeltool4.7.1 build error
Tried to build qt4-pixeltool and ran into the following error. ===> Building for qt4-pixeltool-4.7.1 "/usr/ports/graphics/qt4-pixeltool/work/qt-everywhere-opensource-src-4.7.1/bin/qmake" -spec /usr/local/share/qt4/mkspecs/freebsd-g++ -o "/usr/ports/graphics/qt4-pixeltool/work/qt-everywhere-opensource-src-4.7.1/./tools/pixeltool" "/usr/ports/graphics/qt4-pixeltool/work/qt-everywhere-opensource-src-4.7.1/tools/pixeltool/pixeltool.pro" cd "/usr/ports/graphics/qt4-pixeltool/work/qt-everywhere-opensource-src-4.7.1/./tools/pixeltool" make first /usr/ports/graphics/qt4-pixeltool/work/qt-everywhere-opensource-src-4.7.1/bin/moc -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../include/QtCore -I../../include/QtNetwork -I../../include/QtGui -I../../include -I. -I.moc/release-shared -I/usr/local/include qpixeltool.h -o .moc/release-shared/moc_qpixeltool.cpp g++ -c -O2 -pipe -fno-strict-aliasing -O2 -Wall -W -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../include/QtCore -I../../include/QtNetwork -I../../include/QtGui -I../../include -I. -I.moc/release-shared -I/usr/local/include -o .obj/release-shared/main.o main.cpp g++ -c -O2 -pipe -fno-strict-aliasing -O2 -Wall -W -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../include/QtCore -I../../include/QtNetwork -I../../include/QtGui -I../../include -I. -I.moc/release-shared -I/usr/local/include -o .obj/release-shared/qpixeltool.o qpixeltool.cpp g++ -c -O2 -pipe -fno-strict-aliasing -O2 -Wall -W -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../include/QtCore -I../../include/QtNetwork -I../../include/QtGui -I../../include -I. -I.moc/release-shared -I/usr/local/include -o .obj/release-shared/moc_qpixeltool.o .moc/release-shared/moc_qpixeltool.cpp g++ -Wl,-rpath-link,/usr/ports/graphics/qt4-pixeltool/work/qt-everywhere-opensource-src-4.7.1/lib -Wl,-O1 -pthread -Wl,-rpath,/usr/local/lib/qt4 -Wl,-rpath,/usr/local/lib/qt4 -o ../../bin/pixeltool .obj/release-shared/main.o .obj/release-shared/qpixeltool.o .obj/release-shared/moc_qpixeltool.o-L/usr/local/lib/qt4 -L/usr/ports/graphics/qt4-pixeltool/work/qt-everywhere-opensource-src-4.7.1/lib -L/usr/local/lib -lQtGui -L/usr/local/lib/qt4 -L/usr/local/lib -lQtNetwork -lQtCore /usr/local/lib/qt4/libQtNetwork.so: undefined reference to `QListData::detach_grow(int*, int)' /usr/local/lib/qt4/libQtNetwork.so: undefined reference to `QListData::detach(int)' /usr/local/lib/qt4/libQtNetwork.so: undefined reference to `QIODevicePrivate::peek(char*, long long)' /usr/local/lib/qt4/libQtNetwork.so: undefined reference to `QIODevicePrivate::peek(long long)' /usr/local/lib/qt4/libQtNetwork.so: undefined reference to `QElapsedTimer::elapsed() const' /usr/local/lib/qt4/libQtNetwork.so: undefined reference to `QMetaType::registerTypedef(char const*, int)' /usr/local/lib/qt4/libQtNetwork.so: undefined reference to `qDecodeDataUrl(QUrl const&)' /usr/local/lib/qt4/libQtNetwork.so: undefined reference to `QElapsedTimer::start()' /usr/local/lib/qt4/libQtNetwork.so: undefined reference to `QElapsedTimer::hasExpired(long long) const' *** Error code 1 1 error *** Error code 2 1 error *** Error code 1 Stop in /usr/ports/graphics/qt4-pixeltool. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20101228-72604-1b9ni8p-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=qt4-pixeltool-4.6.3 UPGRADE_PORT_VER=4.6.3 make ** Fix the problem and try again. ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! graphics/qt4-pixeltool (qt4-pixeltool-4.6.3) (linker error) ___ 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: print /usr/ports/UPDATING on update
Doug, good day. Tue, Dec 28, 2010 at 10:55:04AM -0800, Doug Barton wrote: > Do either of you actually have any familiarity at all with how portaudit > works, and/or how it is integrated into the ports infrastructure? Based > on what you've written today my guess is "no." I am sorry, but you're wrong here: I am familiar with portaudit and its internals: http://www.freebsd.org/cgi/query-pr.cgi?pr=126853 But the portaudit has very precise semantics: "if you have the port X with versions in , then it is vulnerable, here is the link to the advisory". UPDATING entries are slightly more complex beasts, see below. > When I wrote, "we need a tool with striking similarities to > portaudit" without providing the details I was assuming that people > are already familiar with it, how it works, etc. If you're not, then > you really need to be before you can respond intelligently to my > post. Prerequisites are met from my side. > If you take the time to become familiar with portaudit and > subsequently need me to expand on my thoughts I'm happy to do that > of course. Let me explain my worries again. What I meant is the following: one can use XML/JSON/SomeOtherMarkup for the UPDATING.ng. But why bother if the current UPDATING format can be slightly extended and semantics can be attached to it without using the new fancy languages that will need some specific ports to be installed in order to process them? I read your argument about reusing the VuXML machinery; it is addressed below. You write that > From the user side, we're not really losing anything by not having > "human readable" output readily available, since 99% of users will > just want to be able to know what entries are relevant to their > installation anyway. but do you know how many users rely on the current UPDATING format? Personally, I -- don't, so I can't make such assertions with confidence. Surely, we can have a tool that will output all entries in the current UPDATING format -- it will save everyone who relies on the current state of this file. The XML in VuXML (that is used to create the portaudit database and entries at http://www.vuxml.org/freebsd/) is mainly needed because VuXML entries use HTML markup, so it is just easier to allow the whole tag to contain XHTML, because it can contain links, references, lists and other markup. So, the nested structure of XML fits here rather good. But, if you will suppress the complex structure, you can reformat the VuXML into the pseudo-RFC822 format and write a simple validator for it. XML has XSLT that can be used for transform into HTML, so it is another reason why VuXML should be XML, but again, mainly the body content plays its role here. The structure can be expressed via the RFC822-like headers -- there is no problem to parse and validate it. Current UPDATING is a lot simpler: it already has the pseudo-RFC822 form and it is perfectly human-readable. What we need is the good AFFECTS structure with clear semantics and validator for it. I am not saying that we can't XML here, I am just pointing out that it can be done without XML and, thus, we don't need the dependencies on the XML/DTD/XSLT stuff at all. So, in my opinion, if I'll weight the pros (existing tools, standard validation) and cons (throws a lot of tags to the reader, unsure how to keep the current form of UPDATING's distribution) of the XML _for UPDATING_, then I'd say that XML is redundant here. But that's only my opinion and it isn't neccessarily the right one; but if someone has the other view -- it should be explained. Thinking about portaudit, UPDATING in this form will be more-or-less equal to the auditfile. And currently, UPDATING has all important properties of an auditfile, but one: AFFECTS have no clear syntax and semantics (and UPDATING has slightly other format, but it is consistent throughout the whole file, so it really doesn't matter). About reusing the current VuXML machinery for UPDATING: - there will be just another schema for UPDATING, because VuXML is created for security vulnerabilities; - auditfile format isn't well-suited for the UPDATING, just because auditfile delegates the entry themselves to the Web server hosting the HTML'ized entries, but UPDATING should have the entry bodies available locally; - semantics of the UPDATING entries is different, so existing portaudit machinery should be rewritten: we can either create the complex tool to handle VuXML and UPDATING or to have two distinct tools that, perhaps, will share some code via the libpkg. And here comes the next question: what syntax of AFFECTS we will need and what semantics we will apply here. There are at least two cases: a) port X starting from version N requires user to make some actions before or after its installation; b) there were some infrastructural changes that touch big parts of the ports tree (or the whole tree). Type-"a" entries should have port name and version; user sh
Re: problem with port gobject-introspection on 9.0-CURRENT
Ok, just to confirm that after today change to head/libexec/rtld-eld this problem no longer exists.. so after all it was not port related.. gg. On Mon, 27 Dec 2010, Eygene Ryabinkin wrote: Sun, Dec 26, 2010 at 02:49:40PM +0100, Goran Gajic wrote: I am using glib-2.26.1_1 built from ports too as I have started with complete fresh 9.0-CURRENT (removed all previously installed ports and with no ports installed at all in chroot environment).. OK. Can you show the contents of your /usr/local/share/gir-1.0 directory? I can't reproduce your problem on the fresh i386/9-CURRENT box, so I suspect that something in your current configuration breaks g-ir stuff. 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"
Portupgrade of qt4-corelib broken
Trying to portupgrade qt4-corelib-4.6.3_1 and received the following compile error # -*-mode: makefile-*- # New ports collection makefile for: qt40 # Date created:Wed Jun 29 11:49:42 CEST 2005 # Whom: l...@freebsd.org # # $FreeBSD: ports/devel/qt4-corelib/Makefile,v 1.24 2010/12/02 19:47:07 makc Exp $ # qfsfileengine_unix.o io/qfsfileengine_unix.cpp g++ -c -O2 -pipe -fno-strict-aliasing -D_REENTRANT -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION -DHB_EXPORT=Q_CORE_EXPORT -DGNU_LIBICONV -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../include -I../../include/QtCore -I.rcc/release-shared -Iglobal -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I.moc/release-shared -I/usr/local/include -o .obj/release-shared/qfsfileengine_iterator_unix.o io/qfsfileengine_iterator_unix.cpp io/qfsfileengine_iterator_unix.cpp:61: error: ISO C++ forbids declaration of 'QT_DIR' with no type io/qfsfileengine_iterator_unix.cpp:61: error: expected ';' before '*' token io/qfsfileengine_iterator_unix.cpp:62: error: ISO C++ forbids declaration of 'QT_DIRENT' with no type io/qfsfileengine_iterator_unix.cpp:62: error: expected ';' before '*' token io/qfsfileengine_iterator_unix.cpp:67: error: ISO C++ forbids declaration of 'QT_DIRENT' with no type io/qfsfileengine_iterator_unix.cpp:67: error: expected ';' before '*' token io/qfsfileengine_iterator_unix.cpp: In constructor 'QFSFileEngineIteratorPlatformSpecificData::QFSFileEngineIteratorPlatformSpecificData()': io/qfsfileengine_iterator_unix.cpp:55: error: class 'QFSFileEngineIteratorPlatformSpecificData' does not have any field named 'dir' io/qfsfileengine_iterator_unix.cpp:55: error: class 'QFSFileEngineIteratorPlatformSpecificData' does not have any field named 'dirEntry' io/qfsfileengine_iterator_unix.cpp:57: error: class 'QFSFileEngineIteratorPlatformSpecificData' does not have any field named 'mt_file' io/qfsfileengine_iterator_unix.cpp: In member function 'void QFSFileEngineIterator::advance()': io/qfsfileengine_iterator_unix.cpp:73: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dirEntry' io/qfsfileengine_iterator_unix.cpp:73: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dirEntry' io/qfsfileengine_iterator_unix.cpp:75: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfileengine_iterator_unix.cpp:79: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfileengine_iterator_unix.cpp:79: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'mt_file' io/qfsfileengine_iterator_unix.cpp:79: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dirEntry' io/qfsfileengine_iterator_unix.cpp:79: error: 'QT_READDIR_R' was not declared in this scope io/qfsfileengine_iterator_unix.cpp:85: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dirEntry' io/qfsfileengine_iterator_unix.cpp:86: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfileengine_iterator_unix.cpp:86: error: 'QT_CLOSEDIR' was not declared in this scope io/qfsfileengine_iterator_unix.cpp:87: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfileengine_iterator_unix.cpp:90: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'mt_file' io/qfsfileengine_iterator_unix.cpp:91: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'mt_file' io/qfsfileengine_iterator_unix.cpp: In member function 'void QFSFileEngineIterator::deletePlatformSpecifics()': io/qfsfileengine_iterator_unix.cpp:103: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfileengine_iterator_unix.cpp:104: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfileengine_iterator_unix.cpp:104: error: 'QT_CLOSEDIR' was not declared in this scope io/qfsfileengine_iterator_unix.cpp:106: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'mt_file' io/qfsfileengine_iterator_unix.cpp:107: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'mt_file' io/qfsfileengine_iterator_unix.cpp: In member function 'virtual bool QFSFileEngineIterator::hasNext() const': io/qfsfileengine_iterator_unix.cpp:116: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfileengine_iterator_unix.cpp:118: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named '
qt4-qdbusviewer port broken
Trying to build this port and ran into the following stop. # New ports collection makefile for: qt40 # Date created:Wed Jun 29 11:49:42 CEST 2005 # Whom: l...@freebsd.org # # $FreeBSD: ports/devel/qt4-qdbusviewer/Makefile,v 1.12 2010/12/02 19:47:09 makc Exp $ # ===> Building for qt4-qdbusviewer-4.7.1 "/usr/ports/devel/qt4-qdbusviewer/work/qt-everywhere-opensource-src-4.7.1/bin/qmake" -spec /usr/local/share/qt4/mkspecs/freebsd-g++ -o "/usr/ports/devel/qt4-qdbusviewer/work/qt-everywhere-opensource-src-4.7.1/./tools/qdbus/qdbusviewer" "/usr/ports/devel/qt4-qdbusviewer/work/qt-everywhere-opensource-src-4.7.1/tools/qdbus/qdbusviewer/qdbusviewer.pro" cd "/usr/ports/devel/qt4-qdbusviewer/work/qt-everywhere-opensource-src-4.7.1/./tools/qdbus/qdbusviewer" make first /usr/ports/devel/qt4-qdbusviewer/work/qt-everywhere-opensource-src-4.7.1/bin/moc -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../../include/QtCore -I../../../include/QtGui -I../../../include/QtXml -I../../../include -I../../../include/QtDBus -I.moc/release-shared -I/usr/local/include qdbusviewer.h -o .moc/release-shared/moc_qdbusviewer.cpp /usr/ports/devel/qt4-qdbusviewer/work/qt-everywhere-opensource-src-4.7.1/bin/moc -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../../include/QtCore -I../../../include/QtGui -I../../../include/QtXml -I../../../include -I../../../include/QtDBus -I.moc/release-shared -I/usr/local/include qdbusmodel.h -o .moc/release-shared/moc_qdbusmodel.cpp /usr/ports/devel/qt4-qdbusviewer/work/qt-everywhere-opensource-src-4.7.1/bin/moc -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../../include/QtCore -I../../../include/QtGui -I../../../include/QtXml -I../../../include -I../../../include/QtDBus -I.moc/release-shared -I/usr/local/include propertydialog.h -o .moc/release-shared/moc_propertydialog.cpp g++ -c -O2 -pipe -fno-strict-aliasing -O2 -Wall -W -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../../include/QtCore -I../../../include/QtGui -I../../../include/QtXml -I../../../include -I../../../include/QtDBus -I.moc/release-shared -I/usr/local/include -o .obj/release-shared/qdbusviewer.o qdbusviewer.cpp g++ -c -O2 -pipe -fno-strict-aliasing -O2 -Wall -W -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../../include/QtCore -I../../../include/QtGui -I../../../include/QtXml -I../../../include -I../../../include/QtDBus -I.moc/release-shared -I/usr/local/include -o .obj/release-shared/qdbusmodel.o qdbusmodel.cpp g++ -c -O2 -pipe -fno-strict-aliasing -O2 -Wall -W -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../../include/QtCore -I../../../include/QtGui -I../../../include/QtXml -I../../../include -I../../../include/QtDBus -I.moc/release-shared -I/usr/local/include -o .obj/release-shared/propertydialog.o propertydialog.cpp g++ -c -O2 -pipe -fno-strict-aliasing -O2 -Wall -W -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../../include/QtCore -I../../../include/QtGui -I../../../include/QtXml -I../../../include -I../../../include/QtDBus -I.moc/release-shared -I/usr/local/include -o .obj/release-shared/main.o main.cpp /usr/ports/devel/qt4-qdbusviewer/work/qt-everywhere-opensource-src-4.7.1/bin/rcc -name qdbusviewer qdbusviewer.qrc -o .rcc/release-shared/qrc_qdbusviewer.cpp g++ -c -O2 -pipe -fno-strict-aliasing -O2 -Wall -W -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../../include/QtCore -I../../../include/QtGui -I../../../include/QtXml -I../../../include -I../../../include/QtDBus -I.moc/release-shared -I/usr/local/include -o .obj/release-shared/moc_qdbusmodel.o .moc/release-shared/moc_qdbusmodel.cpp g++ -c -O2 -pipe -fno-strict-aliasing -O2 -Wall -W -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../../include/QtCore -I../../../include/QtGui -I../../../include/QtXml -I../../../include -I../../../include/QtDBus -I.moc/release-shared -I/usr/local/include -o .obj/release-sha
Portupgrade of qt4-corelib broken
Trying to portupgrade qt4-corelib-4.6.3_1 and received the following compile error # -*-mode: makefile-*- # New ports collection makefile for: qt40 # Date created:Wed Jun 29 11:49:42 CEST 2005 # Whom: l...@freebsd.org # # $FreeBSD: ports/devel/qt4-corelib/Makefile,v 1.24 2010/12/02 19:47:07 makc Exp $ # qfsfileengine_unix.o io/qfsfileengine_unix.cpp g++ -c -O2 -pipe -fno-strict-aliasing -D_REENTRANT -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION -DHB_EXPORT=Q_CORE_EXPORT -DGNU_LIBICONV -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../include -I../../include/QtCore -I.rcc/release-shared -Iglobal -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I.moc/release-shared -I/usr/local/include -o .obj/release-shared/qfsfileengine_iterator_unix.o io/qfsfileengine_iterator_unix.cpp io/qfsfileengine_iterator_unix.cpp:61: error: ISO C++ forbids declaration of 'QT_DIR' with no type io/qfsfileengine_iterator_unix.cpp:61: error: expected ';' before '*' token io/qfsfileengine_iterator_unix.cpp:62: error: ISO C++ forbids declaration of 'QT_DIRENT' with no type io/qfsfileengine_iterator_unix.cpp:62: error: expected ';' before '*' token io/qfsfileengine_iterator_unix.cpp:67: error: ISO C++ forbids declaration of 'QT_DIRENT' with no type io/qfsfileengine_iterator_unix.cpp:67: error: expected ';' before '*' token io/qfsfileengine_iterator_unix.cpp: In constructor 'QFSFileEngineIteratorPlatformSpecificData::QFSFileEngineIteratorPlatformSpecificData()': io/qfsfileengine_iterator_unix.cpp:55: error: class 'QFSFileEngineIteratorPlatformSpecificData' does not have any field named 'dir' io/qfsfileengine_iterator_unix.cpp:55: error: class 'QFSFileEngineIteratorPlatformSpecificData' does not have any field named 'dirEntry' io/qfsfileengine_iterator_unix.cpp:57: error: class 'QFSFileEngineIteratorPlatformSpecificData' does not have any field named 'mt_file' io/qfsfileengine_iterator_unix.cpp: In member function 'void QFSFileEngineIterator::advance()': io/qfsfileengine_iterator_unix.cpp:73: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dirEntry' io/qfsfileengine_iterator_unix.cpp:73: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dirEntry' io/qfsfileengine_iterator_unix.cpp:75: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfileengine_iterator_unix.cpp:79: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfileengine_iterator_unix.cpp:79: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'mt_file' io/qfsfileengine_iterator_unix.cpp:79: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dirEntry' io/qfsfileengine_iterator_unix.cpp:79: error: 'QT_READDIR_R' was not declared in this scope io/qfsfileengine_iterator_unix.cpp:85: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dirEntry' io/qfsfileengine_iterator_unix.cpp:86: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfileengine_iterator_unix.cpp:86: error: 'QT_CLOSEDIR' was not declared in this scope io/qfsfileengine_iterator_unix.cpp:87: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfileengine_iterator_unix.cpp:90: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'mt_file' io/qfsfileengine_iterator_unix.cpp:91: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'mt_file' io/qfsfileengine_iterator_unix.cpp: In member function 'void QFSFileEngineIterator::deletePlatformSpecifics()': io/qfsfileengine_iterator_unix.cpp:103: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfileengine_iterator_unix.cpp:104: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfileengine_iterator_unix.cpp:104: error: 'QT_CLOSEDIR' was not declared in this scope io/qfsfileengine_iterator_unix.cpp:106: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'mt_file' io/qfsfileengine_iterator_unix.cpp:107: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'mt_file' io/qfsfileengine_iterator_unix.cpp: In member function 'virtual bool QFSFileEngineIterator::hasNext() const': io/qfsfileengine_iterator_unix.cpp:116: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfileengine_iterator_unix.cpp:118: error: 'class QFSFileEngineIteratorPlatformSpecificData' has no member named 'dir' io/qfsfi
Re: portmaster: print /usr/ports/UPDATING on update
On 12/27/2010 23:07, Eygene Ryabinkin wrote: I had shown the simple shell script that will parse the UPDATING and present the entries for the given port if the fall into the "last N days" category. If you had missed it -- ping me, I'll show it to you once again. Did you even read my post? I specifically stated that I had caught up with the thread (which implies that I saw your script). I also said that trying to write a parser for the UPDATING text file is a bad idea, and not something I'm interested in pursuing. I was taking pains to avoid having to specifically delineate all the reasons your suggestion is a bad idea because I'd rather focus on moving in a more useful direction. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: print /usr/ports/UPDATING on update
Eygene, Peter, jhell, Do either of you actually have any familiarity at all with how portaudit works, and/or how it is integrated into the ports infrastructure? Based on what you've written today my guess is "no." When I wrote, "we need a tool with striking similarities to portaudit" without providing the details I was assuming that people are already familiar with it, how it works, etc. If you're not, then you really need to be before you can respond intelligently to my post. If you take the time to become familiar with portaudit and subsequently need me to expand on my thoughts I'm happy to do that of course. Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: print /usr/ports/UPDATING on update
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/27/2010 20:57, Doug Barton wrote:
> On 12/25/2010 03:16, David Demelier wrote:
> | Hi,
> |
> | A lot of people always forget to read UPDATING (that's normal we'll are
> | humans).
> |
> | Each entry in UPDATING is like "AFFECTS: users of net-mgmt/flowd" so if
> | an update of net-mgmt/flowd is available and a *recent* entry in
> | UPDATING talks about then print the message.
> |
> | This can prevent a lot of breakage and useless noise on lists. What do
> | you think ?
>
> I've caught up on this thread now, kicked it around with the cool cats
> in #bsdpo...@efnet, and here is my opinion, to the extent I have
> anything to say about it. :)
>
> The Real AnswerTM is that we need a tool with striking similarities to
> portaudit. The basic idea would be that UPDATING entries would be done
> in xml, and then the user can either run portupdating (or whatever the
> name ends up being, that's a really bad name but I suck at naming tools)
> either by default for their whole system, or vs. a specific port. I
> would strongly recommend that the behavior, command line options, etc.
> be consistent with portaudit. Download it and check the man page if
> there are any questions. :)
>
> This is not really as hard as it sounds, as the entries for UPDATING
> would not have to be very complex xml-wise, and there is already
> existing infrastructure that we can leverage to make things easy for the
> committers. Also having this information in XML format will make it
> easier for other programmatic solutions down the road.
>
> ~From the user side, we're not really losing anything by not having
> "human readable" output readily available, since 99% of users will just
> want to be able to know what entries are relevant to their installation
> anyway. Of course one useful option for the portupdating script would be
> "print all of the entries since X date" so that if someone had a purpose
> for reading the plain text it could be dumped to a file, parsed, or what
> have you. Meanwhile, all of the ports management tools could benefit
> from having _a_ common tool to do this, similar to how we've all
> benefited from portaudit.
>
> But since that's not likely to happen tomorrow, what I do anticipate
> adding to portmaster is a "thingy" to stat the update time on
> $PORTSDIR/UPDATING and then notify you if you have not viewed the file
> since the last time it was updated. The code to compare/store timestamps
> I already have, but this also entails adding an option to turn off that
> behavior, etc. etc. I'm currently debating whether to try to get this
> into the version of portmaster I release soon'ish, or wait till after
> the upcoming base releases.
>
> The other thing this entails is portmaster actually storing information
> of its own completely aside from /var/db/{pkg|ports}. I'm really sort of
> nauseous about that whole idea since it's a slippery slope that I don't
> want to travel down. But I'm not seeing any other way to accomplish the
> task of "make sure that the user knows that they should read UPDATING"
> without doing something very much like this. Of course, if someone else
> has a better idea, I'm all ears. :)
>
> What I do _not_ want to do is write an "UPDATING text file parser"
> myself. Not only do I think that's a bad idea generally, it's not a
> project that I am at all interested in, and I don't see it as something
> that should be part of portmaster to start with. I could be talked into
> the UPDATING.xml project if someone were to come up with funding for it,
> but (just being frank and honest) it's too big a project for me to
> tackle on a volunteer basis atm.
>
>
>
> | Merry Christmas and happy holidays !
>
> Same to you. :)
>
>
> Doug
>
In a way I sort of agree with this but on the other hand I look at it in
this way.
1). The only time UPDATING affects you is if you are building from
ports, in a sense
2). When upgrading a port you only need the entry that effects that port
and the ports that depend on it.
3). Also when upgrading a port you only need the entries that is only
relevant up-to that version of the port you would be upgrading to.
4). Also UPDATING is only useful if you have a ports tree installed and
will be upgrading using the ports tree.
So with the above said,
1). Why should there be a tool in user-land(world) if this matter deals
directly with upgrading ports via a ports tree.
2-3). If the entry is only relevant to the version of port being
upgraded to and the ports it depends on then there should be something
available that is more local to the port being developed rather than an
outside tool.
4). If this is only relevant to when a ports tree is available and
binary packages are not being used then there is no sense in injecting
user-land tools into the world.
Conclusion & with all due respect XML & JSON along with user-land tools
are a lame temporary solution to a longer standing problem and there is
a lack of fram
mysql-client-5.58 breaks postfix, dovecot
Just a quick warning since I just spent an hour figuring out why my mail server broke: with the upgrade to mysql-client-5.5.8, postfix and dovecot stop working. This is: FreeBSD gilb.zs64.net 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #32: Mon Nov 29 23:10:07 UTC 2010 r...@lokschuppen.zs64.net:/usr/obj/usr/src/sys/EISENBOOT amd64 Dovecot has trouble running the auth process: Dec 28 12:40:13 gilb dovecot: dovecot: Fatal: Auth process died too early - shutting down and lots of Dec 28 12:49:23 gilb dovecot: child 57253 (auth-worker) killed with signal 11 (core not dumped) postfix emitted messages like: Dec 28 12:36:51 gilb postfix/trivial-rewrite[44173]: fatal: proxy:mysql:/usr/local/etc/postfix/mysql_virtual_alias_maps.cf(0,lock|fold_fix): table lookup problem Dec 28 12:40:04 gilb postfix/cleanup[45936]: warning: 7F9BC680E: virtual_alias_maps map lookup problem for ad...@zs64.net I've downgraded to mysql-client-5.5.7 (but left the server at 5.5.8, since I had mysql_upgrade'd it already). Things appear to be back in working order. Here's the relevant packages currently installed: dovecot-managesieve-0.11.12 Dovecot ManageSieve Server daemon dovecot-sieve-1.2+0.1.18 A Sieve plugin for the Dovecot 'deliver' LDA mysql-client-5.5.7 Multithreaded SQL database (client) mysql-server-5.5.8 Multithreaded SQL database (server) postfix-2.7.2,1 A secure alternative to widely-used Sendmail -- Stefan BethkeFon +49 151 14070811 ___ 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: ImageMagick, Djvu, and Perl-threaded - marked as IGNORE when updating
> > > On 12/27/10, David Southwell wrote: > > > >> On 12/27/10, David Southwell wrote: > > > > Agreed - but following Doug's commit I can vouch that the > > > > PERL_THREADED hack > > > > was still needed for 7.2 p3 systems on amd64. > > > > > > It shouldn't be needed. Can you remove this definition from any > > > locally-modified Makefiles, and provide the same information that was > > > requested from Da Rock? (Why do I feel like a WWE announcer when I > > > type that? ...) > > > > > > b. > > > > I do not want to rebuild WITHOUT_IMAGEMAGICK_PERL on a running system > > with active user access which needs perl. > > > > Have you got the replies from Da Rock? > > Before going any further I would suggest that Da Rock be advised to update > his ports tree followed by > > # pkgdb -F > Fix any problems then. If there are any problems he cannot fix at this > stage then report those. Then: > > # portmaster -a or portupgrade -a > > > If he gets any failure which may possibly be linked to a Perl problem he > should rebuild perl with upward and downward recursion. e.g > #portupgrade -rR lang/perl5.8 > > Until that is completed any other report could send us off on a wild goose > chase. > > My twopennorth > I can do what you suggested when we have a report from Da Rock with his results from a system with thoroughly updated ports. My guess is that his probs will be solved by the above. David Photographic Artist Permanent Installations & Design Creative Imagery and Advanced Digital Techniques High Dynamic Range Photography & Official Portraiture Combined darkroom & digital creations & Systems Adminstrator for the vizion2000.net network ___ 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: ImageMagick, Djvu, and Perl-threaded - marked as IGNORE when updating
On 12/28/10, David Southwell wrote: >> On 12/27/10, David Southwell wrote: >> >> On 12/27/10, David Southwell wrote: >> > Agreed - but following Doug's commit I can vouch that the >> > PERL_THREADED >> > hack >> > was still needed for 7.2 p3 systems on amd64. >> >> It shouldn't be needed. Can you remove this definition from any >> locally-modified Makefiles, and provide the same information that was >> requested from Da Rock? (Why do I feel like a WWE announcer when I >> type that? ...) >> >> b. > I do not want to rebuild WITHOUT_IMAGEMAGICK_PERL on a running system with > active user access which needs perl. Oh, I didn't intend for you to do that. (This particular problem shouldn't arise if perl support is disabled.) I meant to show the output of 'make -C $PORTSDIR/graphics/ImageMagick -V PERL_THREADED', 'make -C $PORTSDIR/graphics/ImageMagick showconfig', and 'perl --version' on a system where the build failed if you didn't define PERL_THREADED manually. (A transcript of a failed build would also be helpful.) You needn't (de)install anything. > Have you got the replies from Da Rock? Not yet. b. ___ 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: ImageMagick, Djvu, and Perl-threaded - marked as IGNORE when updating
> > On 12/27/10, David Southwell wrote: > > >> On 12/27/10, David Southwell wrote: > > > Agreed - but following Doug's commit I can vouch that the > > > PERL_THREADED hack > > > was still needed for 7.2 p3 systems on amd64. > > > > It shouldn't be needed. Can you remove this definition from any > > locally-modified Makefiles, and provide the same information that was > > requested from Da Rock? (Why do I feel like a WWE announcer when I > > type that? ...) > > > > b. > > I do not want to rebuild WITHOUT_IMAGEMAGICK_PERL on a running system with > active user access which needs perl. > > Have you got the replies from Da Rock? > Before going any further I would suggest that Da Rock be advised to update his ports tree followed by # pkgdb -F Fix any problems then. If there are any problems he cannot fix at this stage then report those. Then: # portmaster -a or portupgrade -a If he gets any failure which may possibly be linked to a Perl problem he should rebuild perl with upward and downward recursion. e.g #portupgrade -rR lang/perl5.8 Until that is completed any other report could send us off on a wild goose chase. My twopennorth David Photographic Artist Permanent Installations & Design Creative Imagery and Advanced Digital Techniques High Dynamic Range Photography & Official Portraiture Combined darkroom & digital creations & Systems Adminstrator for the vizion2000.net network ___ 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: ImageMagick, Djvu, and Perl-threaded - marked as IGNORE when updating
> On 12/27/10, David Southwell wrote: > >> On 12/27/10, David Southwell wrote: > > Agreed - but following Doug's commit I can vouch that the PERL_THREADED > > hack > > was still needed for 7.2 p3 systems on amd64. > > It shouldn't be needed. Can you remove this definition from any > locally-modified Makefiles, and provide the same information that was > requested from Da Rock? (Why do I feel like a WWE announcer when I > type that? ...) > > b. I do not want to rebuild WITHOUT_IMAGEMAGICK_PERL on a running system with active user access which needs perl. Have you got the replies from Da Rock? David Photographic Artist Permanent Installations & Design Creative Imagery and Advanced Digital Techniques High Dynamic Range Photography & Official Portraiture Combined darkroom & digital creations & Systems Adminstrator for the vizion2000.net network ___ 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: ImageMagick, Djvu, and Perl-threaded - marked as IGNORE when updating
On 12/27/10, David Southwell wrote: >> On 12/27/10, David Southwell wrote: > Agreed - but following Doug's commit I can vouch that the PERL_THREADED > hack > was still needed for 7.2 p3 systems on amd64. It shouldn't be needed. Can you remove this definition from any locally-modified Makefiles, and provide the same information that was requested from Da Rock? (Why do I feel like a WWE announcer when I type that? ...) b. ___ 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: print /usr/ports/UPDATING on update
Peter, good day.
Tue, Dec 28, 2010 at 10:27:55AM +0200, Peter Pentchev wrote:
> - I personally would prefer a human-readable file (and yes, I *can*
> read XML; that doesn't mean it's easy or I *want* to :)
> ...so how about a JSON representation? Human-readable, human-editable,
> but still capable of being formalized and validated
JSON is a bit better (it has no tag overwhelming), but why not just
adopt the current mail-like entry format with each entry idented at two
spaces and preceded by a timestamp in format 'MMDD:'?
It is fairly easy to write a validator for such entries, since it is
rather simple to parse it and the validation logics will be programmed
in any way if we will still lean toward the human-readable format.
There is JSON Schema, but this way we will need something like
{{{
{"date": 20100101,
"affected":{
"category":"www",
"name":"elinks",
"version":"blah"
}
"body":"a long body comes here"
}
}}}
to validate the individual "category", "name", "version" and others.
Such entries are human-readable, but not as pretty as the current
UPDATING entries, in my opinion.
> - ...and as for an implementation, there is a mini-JSON library in
> NetBSD's netpgp implementation -
> src/crypto/external/bsd/netpgp/dist/src/libmj/ in NetBSD CVS
Does it has the schema validation? From what I seen at the NetBSD
CVS, there is not XML Schema implementation yet.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | 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"
Re: portmaster: print /usr/ports/UPDATING on update
On Tue, Dec 28, 2010 at 10:07:18AM +0300, Eygene Ryabinkin wrote:
> Mon, Dec 27, 2010 at 05:57:53PM -0800, Doug Barton wrote:
> > The Real AnswerTM is that we need a tool with striking similarities to
> > portaudit. The basic idea would be that UPDATING entries would be done
> > in xml, and then the user can either run portupdating (or whatever the
> > name ends up being, that's a really bad name but I suck at naming tools)
> > either by default for their whole system, or vs. a specific port. I
> > would strongly recommend that the behavior, command line options, etc.
> > be consistent with portaudit. Download it and check the man page if
> > there are any questions. :)
>
> There are two questions that arise with this approach:
>
> - we should find a way to keep an old UPDATING file in place;
>obviously, it can be easily created from the XML file, but
>currently UPDATING is delivered via CVS and it will be good
>to allow this behaviour even with the XML'ized version;
>but keeping the plain-text UPDATING in CVS while UPDATING.xml
>will be used is a bad idea -- UPDATING will be non-master
>file, so its history will be redundant. From the other hand,
>we have no XML tools in the base tree, so UPDATING can't be
>easily created from the XML version at the user machine;
Two quick thoughts here:
- I personally would prefer a human-readable file (and yes, I *can*
read XML; that doesn't mean it's easy or I *want* to :)
...so how about a JSON representation? Human-readable, human-editable,
but still capable of being formalized and validated
- ...and as for an implementation, there is a mini-JSON library in
NetBSD's netpgp implementation -
src/crypto/external/bsd/netpgp/dist/src/libmj/ in NetBSD CVS
> - currently, UPDATING has only port names, but not their versions;
>one takes the entry timestamp and if he had not yet upgraded
>the relevant port(s) after this timestamp, then the corresponding
>entry is for him. I see there two cases:
>a) there is a specific port version at which some crucial change
> that demands the UPDATING entry had happened; if the version
> specification will be included in UPDATING, then we won't
> even need the timestamp -- one should just take the currently
> installed version and the version to be installed; the the
> entry's version lies between those two, user will surely need
> to read the UPDATING entry;
>b) there is a infrastructural changes that affect all or some ports
> that will be built after some date; again, the logics of choosing
> the entry to be presented is the same as above, but one should use
> timestamps, not ports versions.
>
> But having thinked about this a bit, now I am favoring another approach:
> one should not rely on the portmaster/portupgrade/OtherTool to present
> the UPDATING entries: the best place is the ports infrastructure itself
> (or pkg_install suite). This way, any tool that will do upgrades will
> receive the UPDATING stuff for free.
>
> Currently I am trying to figure out if it will be sufficient to have the
> appropriate machinery in the pkg_delete tool: the old port version and
> timestamp are already there; the new timestamp is more-or-less the
> current date; the only needed piece is the new port version. It can be
> provided via the environment variable by the portmaster-like tool; such
> variable will trigger the processing of the UPDATING file. This is
> rather rough plan, feel free to correct/criticize it or show why it is
> not doable using such approach.
>
> > The other thing this entails is portmaster actually storing
> > information of its own completely aside from /var/db/{pkg|ports}. I'm
> > really sort of nauseous about that whole idea since it's a slippery
> > slope that I don't want to travel down. But I'm not seeing any other
> > way to accomplish the task of "make sure that the user knows that they
> > should read UPDATING" without doing something very much like this. Of
> > course, if someone else has a better idea, I'm all ears. :)
> >
> > What I do _not_ want to do is write an "UPDATING text file parser"
> > myself. Not only do I think that's a bad idea generally, it's not a
> > project that I am at all interested in, and I don't see it as
> > something that should be part of portmaster to start with. I could be
> > talked into the UPDATING.xml project if someone were to come up with
> > funding for it, but (just being frank and honest) it's too big a
> > project for me to tackle on a volunteer basis atm.
>
> I had shown the simple shell script that will parse the UPDATING and
> present the entries for the given port if the fall into the "last N
> days" category. If you had missed it -- ping me, I'll show it to you
> once again.
G'luck,
Peter
--
Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDB
