Re: Unable to upgrade ports (snapshot) since several weeks
a pkg_check fixed the issues. Altought it reported some really strange things like reverse depencies on "??" Thanks for the help. On Tue, Jan 24, 2012 at 3:16 PM, Stuart Henderson wrote: > On 2012/01/24 14:43, viq wrote: >> On Tue, Jan 24, 2012 at 02:07:26PM +0100, Auclair Vincent wrote: >> > Hello, >> > >> > I've been uable to upgrade ports. >> > I though it was a problem in the snapshots but it's been happening >> > since the last three updates I did. >> > I followed the instructions since 4.8 to update in case I had missed >> > something but to no avail. >> > If you need more information I'll be happy to give it to you. >> > >> > pkg_add -ui gives me : >> > >> > # pkg_add -ui >> > quirks-1.57->quirks-1.58: ok >> > ImageMagick-6.6.6.10p5:.libs1-jpeg-6bp5+.libs1-jpeg-7+jpeg-8c->jpeg-8c: ok >> > ImageMagick-6.6.6.10p5:tiff-3.9.5->tiff-3.9.5: ok >> > ImageMagick-6.6.6.10p5:lcms-1.18a->lcms-1.18a: ok >> > Read shared items: ok >> > OpenBSD::Requiring: writing /var/db/pkg//+REQUIRING: Is a directory at >> > /usr/libdata/perl5/OpenBSD/OldLibs.pm line 155 >> > # pkg_add -ui >> > ImageMagick-6.6.6.10p5:libiconv-1.14->libiconv-1.14: ok >> > Read shared items: ok >> > OpenBSD::Requiring: writing /var/db/pkg//+REQUIRING: Is a directory at >> > /usr/libdata/perl5/OpenBSD/OldLibs.pm line 155 >> > # pkg_add -ui >> > ImageMagick-6.6.6.10p5:lcms2-2.2->lcms2-2.2: ok >> > ImageMagick-6.6.6.10p5:.libs1-libxml-2.6.32p3+.libs1-libxml-2.7.6p1+libxml-2.7.8p3->libxml-2.7.8p3: >> > ok >> > Read shared items: ok >> > --- -libxml-2.7.8p3 --- >> > Remember to update /var/db/xmlcatalog >> > OpenBSD::Requiring: writing /var/db/pkg//+REQUIRING: Is a directory at >> >> >> Sounds like what you need is fsck of whatever hosts your /var, and then >> maybe some manual intervention. pkg_check might help a bit. > > tar up a copy of /var/db/pkg before you start... > -- Vincent Auclair - auclair.vincent[ at ]gmail.com (+33) 6 71 55 02 37
Unable to upgrade ports (snapshot) since several weeks
Hello, I've been uable to upgrade ports. I though it was a problem in the snapshots but it's been happening since the last three updates I did. I followed the instructions since 4.8 to update in case I had missed something but to no avail. If you need more information I'll be happy to give it to you. pkg_add -ui gives me : # pkg_add -ui quirks-1.57->quirks-1.58: ok ImageMagick-6.6.6.10p5:.libs1-jpeg-6bp5+.libs1-jpeg-7+jpeg-8c->jpeg-8c: ok ImageMagick-6.6.6.10p5:tiff-3.9.5->tiff-3.9.5: ok ImageMagick-6.6.6.10p5:lcms-1.18a->lcms-1.18a: ok Read shared items: ok OpenBSD::Requiring: writing /var/db/pkg//+REQUIRING: Is a directory at /usr/libdata/perl5/OpenBSD/OldLibs.pm line 155 # pkg_add -ui ImageMagick-6.6.6.10p5:libiconv-1.14->libiconv-1.14: ok Read shared items: ok OpenBSD::Requiring: writing /var/db/pkg//+REQUIRING: Is a directory at /usr/libdata/perl5/OpenBSD/OldLibs.pm line 155 # pkg_add -ui ImageMagick-6.6.6.10p5:lcms2-2.2->lcms2-2.2: ok ImageMagick-6.6.6.10p5:.libs1-libxml-2.6.32p3+.libs1-libxml-2.7.6p1+libxml-2.7.8p3->libxml-2.7.8p3: ok Read shared items: ok --- -libxml-2.7.8p3 --- Remember to update /var/db/xmlcatalog OpenBSD::Requiring: writing /var/db/pkg//+REQUIRING: Is a directory at /usr/libdata/perl5/OpenBSD/OldLibs.pm line 155 I can continue on and it will upgrade one package than error out again. # env | grep PKG_PATH PKG_PATH=http://ftp2.fr.openbsd.org/pub/OpenBSD/snapshots/packages/i386/ # pkg_info ImageMagick-6.6.6.10p3 image processing tools ORBit2-2.14.19p1high-performance CORBA Object Request Broker aalib-1.4p3 ascii art library amsn-0.98.4 open source MSN Messenger clone apr-1.2.11p5Apache Portable Runtime apr-util-1.2.10p8 companion library to APR aria2-1.12.1p0 lightweight multi-protocol & multi-source download utility aspell-0.60.6p4 spell checker designed to eventually replace Ispell aspell-fr-0.50_3p1 aspell dictionary for French atk-2.2.0 accessibility toolkit used by gtk+ atk2mm-2.22.6 C++ binding for the ATK library autoconf-2.13p2 automatically configure source code on many Un*x platforms autoconf-2.59p3 automatically configure source code on many Un*x platforms autoconf-2.61p3 automatically configure source code on many Un*x platforms autoconf-2.62p0 automatically configure source code on many Un*x platforms automake-1.9.6p8GNU standards-compliant Makefile generator avahi-0.6.30p5 framework for Multicast DNS Service Discovery avahi-gtk-0.6.30p4 gtk+2 avahi-ui libraries avahi-ui-0.6.30p1 common avahi-ui header for gtk+2 and gtk+3 babl-0.1.4p0dynamic pixel format conversion library bash-4.2.10 GNU Bourne Again Shell bison-2.3 GNU parser generator blas-1.0p5 Basic Linear Algebra Subprograms boost-1.42.0p10 free peer-reviewed portable C++ source libraries bwidget-1.9.5 high-level widget set for Tcl/Tk bzip2-1.0.6 block-sorting file compressor, unencumbered cairo-1.10.2p3 vector graphics library cairomm-1.9.8p1 C++ interface for cairo cdparanoia-3.a9.8p0 CDDA reading utility with extra data verification features celt-0.10.0v0 ultra-low delay audio codec chromium-15.0.874.102 Chromium browser clisp-2.48p2ANSI Common Lisp implementation cmake-2.8.6 portable build system coherence-0.6.6.2p2 uPnP/DLNA media server colord-0.1.14p0 device color profile management daemon consolekit-0.4.5p2 framework for defining and tracking users cups-1.5.0p3Common Unix Printing System curl-7.22.0 get files from FTP, Gopher, HTTP or HTTPS servers cvsps-2.1 generate patchsets from CVS repositories cyrus-sasl-2.1.25p0 RFC SASL (Simple Authentication and Security Layer) dante-1.1.19p0 SOCKS client and server db-4.6.21v0 Berkeley DB package, revision 4 dbus-1.4.16p1v0 message bus system dbus-glib-0.98v0glib bindings for dbus message system dbus-python-0.84.0p1 dbus bindings for Python dconf-0.10.0p0 configuration backend system desktop-file-utils-0.19 utilities for dot.desktop entries detex-2.8p0 strip TeX/LaTeX codes from a file djvulibre-3.5.24p2 view, decode and encode DjVu files dmenu-4.4.1 dynamic menu for X11 docbook-4.5p0 technical documentation XML/SGML definitions docbook-dsssl-1.72p0 modular DSSSL stylesheets for the DocBook DTD doxygen-1.7.2 source code documentation generator tool dvi2tty-5.3.1 converts .dvi files to plain text e2fsprogs-1.41.4p7 utilities to manipulate ext2 filesystems ectags-5.8 multilanguage implementation of ctags eggdbus-0.6p1 D-Bus binding for GObject ekiga-3.2.7p5 SIP and H.323 compatible conferencing application emacs-22.3p11-no_x11 GNU editor: extensible, customizable, self-documenting enca-1.13p0 detect character set and encoding of text files enchant-1.6.0p0 generic spell checking library/wrapper esound-0.2.41p0v0 sound library for Enlightenment evolu
Re: keepassx [was: Re: qmake anyone?]
>From what I saw, you need to run cmake and not just qmake. The X include path is not correct and that is why is doesn't work. On Wed, Jun 23, 2010 at 2:12 PM, Jiri B. wrote: > On Sat, 16 Jan 2010 18:35:30 +0100 > frantisek holop wrote: > >> hmm, on Sat, Jan 16, 2010 at 06:16:10PM +0100, Matthieu Herrb said >> that >> > Xtst >> >> thanks. >> >> i am trying to port keepassx, but i am hitting a wall: > > Hi, > > were you successfull to build keepassx on OpenBSD? Before I searched > @ports I tried to create my own port and I have reached same problems as > you :( > > keepassx would be very useful as I use that everyday (on Linux) and I > don't know any other password manager. > > jirib > > > -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67
Re: diff for audio/mp3gain
Since I was able to sync and do cvs diffs fives minutes ago, and that
the codeworker
diffs has been commited, here's another one.
do-configure: @true is not required maybee it can be removed ?
builds fine without it.
Index: audio/mp3gain//Makefile
===
RCS file: /cvs/openbsd/ports/audio/mp3gain/Makefile,v
retrieving revision 1.2
diff -u -r1.2 Makefile
--- audio/mp3gain//Makefile 15 Sep 2007 21:26:02 - 1.2
+++ audio/mp3gain//Makefile 19 May 2010 11:02:06 -
@@ -25,9 +25,6 @@
WRKSRC=$(WRKDIR)
-do-configure:
- @true
-
do-install:
${INSTALL_PROGRAM} ${WRKDIR}/mp3gain ${PREFIX}/bin
--
Vincent Auclair- auclair.vincent[ at ]gmail.com
(+33) 6 80 77 59 67
Re: CVS: cvs.openbsd.org: ports (fwd)
On Wed, May 19, 2010 at 9:56 AM, Antoine Jacoutot wrote: > ping yes sorry for the late message. I saw this yesterday and had modified the makefile and plist to what you had brought up. But I have since then been unable to update my tree to do a diff and/or do a cvs diff due to networking problems in the laboratory network. Here is an update tarball even if I know I should have sent you a diff, but a least you have the changes now, instead of when the network works back again. > -- Forwarded message -- > Date: Tue, 18 May 2010 12:45:13 +0200 (CEST) > From: Antoine Jacoutot > To: Landry Breuil > Cc: ports-chan...@cvs.openbsd.org > Subject: Re: CVS: cvs.openbsd.org: ports > > On Tue, 18 May 2010, Landry Breuil wrote: > >> CVSROOT: /cvs >> Module name: ports >> Changes by: lan...@cvs.openbsd.org 2010/05/18 04:28:48 >> >> Log message: >> Import codeworker 4.5.4 from MAINTAINER Vincent Auclair >> >> CodeWorker is a versatile Open Source parsing tool and a source code >> generator devoted to generative programming. Generative programming is a >> software engineering approach interested in automating the production of >> reusable, tailor-made, adaptable and reliable IT systems. >> >> Status: >> >> Vendor Tag: vauclair >> Release Tags: landry_20100518 >> >> N ports/devel/codeworker/Makefile >> N ports/devel/codeworker/distinfo >> N ports/devel/codeworker/patches/patch-Makefile >> N ports/devel/codeworker/pkg/DESCR >> N ports/devel/codeworker/pkg/PLIST >> >> No conflicts created by this import > > Any reason you are installing documentation under examples ? > > If these are indeed examples, imho it would make more sense to install > them directly under examples/codeworker/, not > examples/codeworker/documentation. > > -- > Antoine > -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67 codeworker.tar.gz Description: GNU Zip compressed data
Re: [NEW] deve/codeworker
On Fri, May 14, 2010 at 6:45 PM, Landry Breuil wrote: > On Fri, May 14, 2010 at 04:48:20PM +0100, Stuart Henderson wrote: >> On 2010/05/14 17:22, Landry Breuil wrote: >> > >> > The warnings are not really important per se, lots of ports build fine >> > with TONS of warnings, but at least -Wall makes sure they are shown. >> >> It depends on exactly what they are of course. For example, if there are >> implicit declarations (for functions returning pointers) or warnings about >> pointer conversions you can expect some problems on LP64 arch... > > Just to make things clear.. _some_ warnings are not important, some like > you mention are to be fixed. Here for codeworker, it's tons of c++ > warnings about variables initialized after/before a superclass member or > smth like that, and tons of #pragma warning. > New tarball with the Makefile patched. I changed CC to CXX and LFLAGS to LDFLAGS Patches for the warnings are being sent upstream. -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67 codeworker.tar.gz Description: GNU Zip compressed data
Re: [NEW] deve/codeworker
On Thu, May 13, 2010 at 1:04 PM, Landry Breuil wrote:
> On Tue, May 11, 2010 at 12:13:46PM +0200, Auclair Vincent wrote:
>> On Fri, May 7, 2010 at 1:56 PM, Landry Breuil wrote:
>> > do-configure:
>> > �...@true
>> > oh my.. CONFIGURE_STYLE is here for something, set it to an empty value
>> > and it will just work :)
>> > - COMMENT shouldn't start by a capital article, remove it
>> > - why installing the static lib ? is it needed by the binary ?
>> > - the DISTNAME/DISTFILES dance is a bit wrong, NAME is useless here as
>> > used only once. Instead, we usually set DISTNAME to the name of the
>> > zip/tarball (minus EXTRACT_SUFX) and set the real PKGNAME by hand (ie
>> > codeworkers-${V}.
>>
>> Thought I had sent this on Friday. Anyways here is the updated version.
>>
>> I corrected the issues you mentioned.
>>
>> You can generate code with codeworker, the generated code needs the
>> static library.
>> There aren't any dynamic library shipped yet.
>> The static library is also used when you want to use codeworker in a
>> c++ program.
>
> Strip the 'a' from COMMENT, they're useless..
> It doesn't respect CXXFLAGS (ie try $CFLAGS=-DFOO CXXFLAGS=-DBAR
> make). it will turn on -Wall which will show tons of interesting
> warnings.. MAKE_FLAGS is not ok, you add $(INCDIRS) as bindly done in the
> Makefile but it is not set at this point (and it's useless). CC/CXX should
> be honored too, as it should be c++ and not g++ as gmakes uses CXX
> for the objects that don't have an explicit target.
>
> Atm, i have
> MAKE_FLAGS = CXXFLAGS='${CXXFLAGS}' LFLAGS='-lm' CC='$CXX}' CXX='${CXX}'
> which correctly uses CXXFLAGS and makes a correct use of CC/CXX without
> patching Makefile. Well, it overrides CC with CXX as it's used in the
> Makefile when building generator.cpp/codeworker binary.. so in the end
> the makefile shouldbe patched too so that it respects
> CXXFLAGS/LDFLAGS for the explicit codeworker target.
>
Okay, so I patched the makefile, removed the a in the comment and
changed the MAKE_FLAGS.
But, there are way to many warnings with -W and -Wall. I already have
a few dozen patches which is too much. I've send some patches upstream
already. For now, I only saw initialisation list order warnings and
unused variables. But I haven't checked everything yet.
Should I repost the tarball without the patches for the warnings or
wait until it has been dealt upstream. (Should be fast enough)
Thanks for your help!
--
Vincent Auclair- auclair.vincent[ at ]gmail.com
(+33) 6 80 77 59 67
Re: [NEW] deve/codeworker
On Fri, May 7, 2010 at 1:56 PM, Landry Breuil wrote:
> do-configure:
> �...@true
> oh my.. CONFIGURE_STYLE is here for something, set it to an empty value
> and it will just work :)
> - COMMENT shouldn't start by a capital article, remove it
> - why installing the static lib ? is it needed by the binary ?
> - the DISTNAME/DISTFILES dance is a bit wrong, NAME is useless here as
> used only once. Instead, we usually set DISTNAME to the name of the
> zip/tarball (minus EXTRACT_SUFX) and set the real PKGNAME by hand (ie
> codeworkers-${V}.
Thought I had sent this on Friday. Anyways here is the updated version.
I corrected the issues you mentioned.
You can generate code with codeworker, the generated code needs the
static library.
There aren't any dynamic library shipped yet.
The static library is also used when you want to use codeworker in a
c++ program.
--
Vincent Auclair- auclair.vincent[ at ]gmail.com
(+33) 6 80 77 59 67
codeworker.tar.gz
Description: GNU Zip compressed data
Re: [NEW] deve/codeworker
On Fri, May 7, 2010 at 11:47 AM, Auclair Vincent wrote: > Information for inst:CodeWorker-4.5.4 > > Comment: > A universal parsing tool & a source code generator > > Description: > CodeWorker is a versatile Open Source parsing tool and a source code > generator devoted to generative programming. Generative programming is a > software engineering approach interested in automating the production of > reusable, tailor-made, adaptable and reliable IT systems. > > Maintainer: Vincent Auclair > > WWW: http://codeworker.free.fr/ > > Tested on i386 > Comments ? > And I forgot the tarball... -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67 codeworker.tar.gz Description: GNU Zip compressed data
[NEW] deve/codeworker
Information for inst:CodeWorker-4.5.4 Comment: A universal parsing tool & a source code generator Description: CodeWorker is a versatile Open Source parsing tool and a source code generator devoted to generative programming. Generative programming is a software engineering approach interested in automating the production of reusable, tailor-made, adaptable and reliable IT systems. Maintainer: Vincent Auclair WWW: http://codeworker.free.fr/ Tested on i386 Comments ? -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67
Re: chromium port update
>> >> Well it's instant on my desktop machine. >> Will fidle with it a bit. > > Eeepcs usually have a slow ssd for user files (depending on how you > configured the partitions). It may be that chrome is touching/reading > a lot of stuff to load the options pane. > > But I haven't looked into it so it's just a thought. Well, on this one it's a harddrive. But! everything except /home is directly on the harddrive. But /home is a encrypted softraid disk of a partition of the real harddrive. I do have softdep on that partition. That may be the cause. But since, on my desktop I have exactly the same setup, it also should be slow on the desktop. Maybee missing some raw cpu power. I do get a strange bug where the tab freezes or kinda desynchronizes (the view of the page doesn't move even if I browse the page). Reloading the tab fixes the problem sometimes with more or less time. I do get it less frequently with the new version. As for the proxy, it works with `--proxy-server=XXX` only if the auth isn't in the XXX. It will then ask me for authentification when I load a page. But doesn't work either way (with or without authentification) in the env (http_proxy & ftp_proxy). -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67
Re: chromium port update
>> Tested on an i386 eeepc. >> Works fine, some quirks when moving a tab : a square that is not drawn >> back until I drop the tab. (it follows the cursor) > > Hmm, actually tab dragging is totally busted with fvwm2, I just > noticed - it always pops it out. So I imagine this is window manager > specific, what are you using out of curiosity? I am using wmii. There are also problems in the browser windows. (see the end of the mail) If I drag a window out of the tab bar and drop it immediatly it spawns a new window. If I turn it arround an play with it enough it make the chrome crash when I drop it. >> html 5 videos in youtube don't work. (probably expected, I just tested >> for the fun) > > This should be doable though, if someone wanted to play with it/ I can definitly work on that, since I would like to have html5 videos. :) >> Options takes a heck of time to load, that nornal ? > > No.. it's instantaneous here Well it's instant on my desktop machine. Will fidle with it a bit. >> Browser themes works. >> Used gmail and reader. >> >> Thanks for the update :) So I was thinking on how to test the browser, I remembered http://www.chromeexperiments.com/ Some of them work, some don't. HTML5 videos obviously. But there are some that use canvas that don't work either. It may be a good place to stress test the browser. The `ping' test doesn't work long here, so window handling doesn't work completly. The acid 3 test (acid3.acidtests.org/) says it get's 100% altough I do get an error/warning. It also works on my desktop except for proxy. Proxies seems to be broken. I set it in the environement and still doesn't use it. That normal ? -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67
Re: chromium port update
On Thu, Apr 1, 2010 at 5:24 PM, Peter Valchev wrote: > On Wed, Mar 31, 2010 at 11:50 PM, Antoine Jacoutot > wrote: >> On Wed, 31 Mar 2010, Peter Valchev wrote: >> >>> After a long battle with various issues that cropped up, and thanks to >>> huge help from the guy working on the FreeBSD port (linked from my >>> page), I have an update to chromium-5.0.539.0 >>> >>> 4.7ish packages for i386 & amd64 are available here: >>> http://sightly.net/peter/openbsd/chromium/ >>> >>> As well as the port - if you want to build yourself. >>> http://sightly.net/peter/openbsd/chromium/chromium.tar.gz >>> >>> I'd appreciate tests on amd64, especially, as I don't have one locally >>> - I tested that it starts up and renders google.com, but anything more >>> is too much of a pain over ssh X forwarding :-) I know the old port >>> had V8 issues on amd64, so curious if this works better. >> >> Thanks Peter. >> >> Small thing I noticed is that the buttons and window flicker like hell >> when clicking on "Clear browing data". >> That is under current with cwm, not sure whether this is a local issue. > > buttons and windows flicker... that's probably just network churn > while it's sending your browsing data to google (sorry, couldn't > resist the joke) > > i can't reproduce on fvwm2 :) Tested on an i386 eeepc. Works fine, some quirks when moving a tab : a square that is not drawn back until I drop the tab. (it follows the cursor) html 5 videos in youtube don't work. (probably expected, I just tested for the fun) Options takes a heck of time to load, that nornal ? Browser themes works. Used gmail and reader. Thanks for the update :) -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67
Re: [NEW] protobuf
Hello,
Now that the port tree has been completely unlocked,
I am resubmitting the protobuf port.
The last tarball contained the fixes for the errors that Landry Breuil had.
Hope this can go in.
On Wed, Jan 13, 2010 at 8:02 PM, Auclair Vincent
wrote:
> On Tue, Jan 12, 2010 at 8:55 PM, Landry Breuil wrote:
>> On Tue, Jan 12, 2010 at 11:56:27AM +0100, Auclair Vincent wrote:
>>> Update version from 2.2.0 to 2.3.0
>>>
>>> Tarball is attached.
>>
>> Comments portswise :
>>
>> - SHARED_LIBS usually start at 0.0
>> - as CONFIGURE_STYLE is set to gnu, automake won't be run, so
>> *Makefile.am won't be read, so patching them is useless.
>> patches/patch-src_Makefile_am and patches/patch-Makefile_am can go away.
>> regress fails with:
>> gmake[3]: *** No rule to make target `/usr/local/libgtest.la', needed by
>> `protobuf-test'. Stop.
>> -> your patch-src_Makefile_in is are wrong. (missing /lib/ after
>> ${LOCALBASE} for libgtest*.la.)
>>
>> Other than that, looks good. Builds fine @amd64/ppc.
>
> Updated tarball which corrects the problems
>
>
> --
> Vincent Auclair - auclair.vincent[ at ]gmail.com
> (+33) 6 80 77 59 67
>
--
Vincent Auclair- auclair.vincent[ at ]gmail.com
(+33) 6 80 77 59 67
protobuf.tar.gz
Description: GNU Zip compressed data
Re: UPDATE: devel/boost
On Mon, Mar 22, 2010 at 12:45 AM, Federico G. Schwindt wrote:
> On Tue, Jan 12, 2010 at 03:46:03PM +0100, Auclair Vincent wrote:
>> On Mon, Jan 11, 2010 at 6:25 PM, Auclair Vincent
>> wrote: > > Compiled ok :)
>> >
>> > regress didn't work
>> >
>> > # make regress
>> > ===> ?Regression check for boost-1.41.0p0
>> > make: cannot open Makefile.
>> > *** Error code 2
>> >
>> > Stop in /yellowstone/workbox/git/ports/devel/boost (line 2226 of
>> > /usr/ports/infrastructure/mk/bsd.port.mk).
>> >
>> > tested on i386 using mainly boost::asio
>>
>>
>> Well actually I stumbled on a problem :)
>> When using the -W warning flag it get these warnings
>>
>> In file included from /usr/local/include/boost/smart_ptr/shared_ptr.hpp:31,
>> from /usr/local/include/boost/shared_ptr.hpp:17,
>> from ../ags/module/module.hpp:14,
>> from ../ags/module/modulemanager.h:10,
>> from module/modulemanager.cpp:5:
>> /usr/local/include/boost/throw_exception.hpp:57: warning: `inline' is not at
>> beginning of declaration
>>
>> this issue is from this line
>> template BOOST_ATTRIBUTE_NORETURN inline void
>> throw_exception( E const & e )
>>
>> We can find the define in boost/exception/detail/attribute_noreturn.hpp
>> #define BOOST_ATTRIBUTE_NORETURN __attribute__((noreturn))
>>
>> So it doens't like
>> template __attribute__((noreturn)) inline void
>> throw_exception( E const & e )
>>
>> @
>>
>> In file included from
>> /usr/local/include/boost/date_time/gregorian/gregorian.hpp:21,
>> from
>> /usr/local/include/boost/date_time/posix_time/time_formatters.hpp:12,
>> from
>> /usr/local/include/boost/date_time/posix_time/posix_time.hpp:24,
>> from ../ags/network/timer.ipp:13,
>> from plugins/arch/OpenBSD/arenamanager.cpp:6:
>> /usr/local/include/boost/date_time/gregorian/conversion.hpp: In function `tm
>> boost::gregorian::to_tm(const boost::gregorian::date&)':
>> /usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning:
>> missing
>> initializer for member `tm::tm_sec'
>> /usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning:
>> missing
>> initializer for member `tm::tm_min'
>> /usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning:
>> missing
>> initializer for member `tm::tm_hour'
>> /usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning:
>> missing
>> initializer for member `tm::tm_mday'
>> /usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning:
>> missing
>> initializer for member `tm::tm_mon'
>> /usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning:
>> missing
>> initializer for member `tm::tm_year'
>> /usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning:
>> missing
>> initializer for member `tm::tm_wday'
>> /usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning:
>> missing
>> initializer for member `tm::tm_yday'
>> /usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning:
>> missing
>> initializer for member `tm::tm_isdst'
>> /usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning:
>> missing
>> initializer for member `tm::tm_gmtoff'
>> /usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning:
>> missing
>> initializer for member `tm::tm_zone'
>> In file included from
>> /usr/local/include/boost/date_time/posix_time/posix_time_io.hpp:21,
>> from
>> /usr/local/include/boost/date_time/posix_time/posix_time.hpp:31,
>> from ../ags/network/timer.ipp:13,
>> from plugins/arch/OpenBSD/arenamanager.cpp:6:
>>
>> Here tm innitialized like this
>> std::tm timetm = {};
>>
>> @
>>
>> /usr/local/include/boost/tuple/detail/tuple_basic.hpp:119: warning: `static'
>> is
>> not at beginning of declaration
>>
>> here the issue is this
>>
>> inline static RET get(const cons& t)
>> {
>> return t.head;
>> }
>>
>> It want's static inline and not inline static.
>>
>> @
>>
>> In file included from /usr/local/include/b
Re: Moovida error
On Fri, Jan 29, 2010 at 8:19 PM, Auclair Vincent wrote: > Hello, > > After installing moovida on a recent snapshot I get this error > An loader appears and then crashes > Did anyone else get this error ? -- newton
Moovida error
Hello,
After installing moovida on a recent snapshot I get this error
An loader appears and then crashes
new...@cerberus ~ $ elisa
\Launcher core version: 1.0.7
Current core version: 1.0.7
Traceback (most recent call last):
File "/usr/local/lib/python2.5/site-packages/twisted/internet/gtk2reactor.py",
line 225, in simulate
self.runUntilCurrent()
File "/usr/local/lib/python2.5/site-packages/twisted/internet/base.py",
line 757, in runUntilCurrent
call.func(*call.args, **call.kw)
File "/usr/local/lib/python2.5/site-packages/twisted/internet/task.py",
line 251, in _tick
result = iterator.next()
File
"/usr/local/lib/python2.5/site-packages/elisa/core/interface_controller.py",
line 104, in load_frontends_iter
frontend_section)
--- ---
File "/usr/local/lib/python2.5/site-packages/elisa/core/plugin_registry.py",
line 1106, in create_component
component_class = reflect.namedAny('%s.%s' % (module, klass))
File "/usr/local/lib/python2.5/site-packages/twisted/python/reflect.py",
line 467, in namedAny
obj = getattr(obj, n)
exceptions.AttributeError: 'module' object has no attribute 'pigment'
WARN MainThread interface_controllerJan 29 20:05:04
creating frontend frontend1 failed. A full traceback can be found at
[Failure instance: Traceback: :
'module' object has no attribute 'pigment'
/usr/local/lib/python2.5/site-packages/twisted/internet/gtk2reactor.py:225:simulate
/usr/local/lib/python2.5/site-packages/twisted/internet/base.py:757:runUntilCurrent
/usr/local/lib/python2.5/site-packages/twisted/internet/task.py:251:_tick
/usr/local/lib/python2.5/site-packages/elisa/core/interface_controller.py:104:load_frontends_iter
--- ---
/usr/local/lib/python2.5/site-packages/elisa/core/plugin_registry.py:1106:create_component
/usr/local/lib/python2.5/site-packages/twisted/python/reflect.py:467:namedAny
] (elisa/core/interface_controller.py:88)
WARN MainThread interface_controllerJan 29 20:05:04
Could not load any frontend (elisa/core/interface_controller.py:123)
^CUnhandled error in Deferred:
Traceback (most recent call last):
File "/usr/local/lib/python2.5/site-packages/twisted/internet/defer.py",
line 328, in _runCallbacks
self.result = callback(self.result, *args, **kw)
File "/usr/local/lib/python2.5/site-packages/twisted/internet/defer.py",
line 536, in _cbDeferred
self.callback(self.resultList)
File "/usr/local/lib/python2.5/site-packages/twisted/internet/defer.py",
line 243, in callback
self._startRunCallbacks(result)
File "/usr/local/lib/python2.5/site-packages/twisted/internet/defer.py",
line 312, in _startRunCallbacks
self._runCallbacks()
--- ---
File "/usr/local/lib/python2.5/site-packages/twisted/internet/defer.py",
line 328, in _runCallbacks
self.result = callback(self.result, *args, **kw)
File "/usr/local/lib/python2.5/site-packages/elisa/core/application.py",
line 567, in managers_stopped
reactor.stop()
File "/usr/local/lib/python2.5/site-packages/twisted/internet/base.py",
line 527, in stop
"Can't stop reactor that isn't running.")
twisted.internet.error.ReactorNotRunning: Can't stop reactor that isn't running.
Here is the snapshot version
kern.version=OpenBSD 4.6-current (GENERIC.MP) #391: Fri Jan 15 14:55:45 MST 2010
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
# pkg_add moovida
moovida-1.0.7p0:py-xdg-0.18p0: ok (17 to go)
moovida-1.0.7p0:py-zopeinterface-3.5.1: ok (20 to go)
moovida-1.0.7p0:py-openssl-0.9: ok (19 to go)
moovida-1.0.7p0:py-twisted-core-8.2.0p0: ok (18 to go)
moovida-1.0.7p0:py-fpconst-0.7.2p2: ok (19 to go)
moovida-1.0.7p0:py-xml-0.8.4p8: ok (18 to go)
moovida-1.0.7p0:py-SOAPpy-0.11.6p4: ok (17 to go)
moovida-1.0.7p0:py-twisted-web-8.2.0p0: ok (16 to go)
moovida-1.0.7p0:pigment-0.3.17: ok (16 to go)
moovida-1.0.7p0:py-libxml-2.7.6: ok (16 to go)
moovida-1.0.7p0:py-gstreamer-0.10.17: ok (15 to go)
moovida-1.0.7p0:py-pigment-0.3.12: ok (14 to go)
moovida-1.0.7p0:libmpeg2-0.5.1p0: ok (15 to go)
moovida-1.0.7p0:liba52-0.7.4p2: ok (14 to go)
moovida-1.0.7p0:gstreamer-plugins-ugly-0.10.13p0: ok (13 to go)
moovida-1.0.7p0:twill-0.9p0: ok (12 to go)
moovida-1.0.7p0:py-simplejson-2.0.9p0: ok (11 to go)
moovida-1.0.7p0:py-gdata-2.0.4: ok (15 to go)
moovida-1.0.7p0:py-configobj-4.5.3p0: ok (14 to go)
moovida-1.0.7p0:py-crypto-2.0.1p6: ok (17 to go)
moovida-1.0.7p0:py-twisted-conch-8.2.0p0: ok (16 to go)
moovida-1.0.7p0:py-epsilon-0.6.0: ok (15 to go)
moovida-1.0.7p0:py-sqlite2-2.5.6: ok (14 to go)
moovida-1.0.7p0:py-axiom-0.6.0: ok (13 to go)
moovida-1.0.7p0:taglib-1.6p0: ok (13 to go)
moovida-1.0.7p0:py-tagpy-0.94.7: ok (12 to go)
moovida-1.0.7p0:py-nevow-0.10.0: ok (11 to go)
moovida-1.0.7p0:coherence-0.6.4: ok (10 to go)
moovida-1.0.7p0:sdl-1.2.13p13: ok (11 to go)
moovida-1.0.7p0:ffmpeg-20080620p12: ok (10 to go)
moovida-1.0.7p0:gstreamer-ffmpeg-0.10.5p6: ok (9 to go)
moovida-1.0.7p0:liberation-fonts-1.04p1: ok (8 to go)
moovida-1.0.7p0:python-2.5.4p2->python-2.5.4p3:
Re: [UPDATE] gflags -> 1.3
On Tue, Jan 12, 2010 at 11:23 AM, Landry Breuil wrote:
> On Tue, Jan 12, 2010 at 11:03:41AM +0100, Auclair Vincent wrote:
>> Here is an update for gflags 1.3
>> Mostly cosmetic changes
>>
>> Mon Jan 4 18:09:30 2010 Google Inc.
>> * google-gflags: version 1.3
>> * PORTABILITY: can now build and run tests under MSVC (csilvers)
>> * Remove the python gflags code, which is now its own package
>> (tansell)
>> * Clarify that "last flag wins" in the docs (csilvers)
>> * Comment danger of using GetAllFlags in validators (wojtekm)
>> * PORTABILITY: Some fixes necessary for c++0x (mboerger)
>> * Makefile fix: $(srcdir) -> $(top_srcdir) in one place (csilvres)
>> * INSTALL: autotools to autoconf v2.64 + automake v1.11 (csilvers)
>>
>>
>> Index: gflags//Makefile
>> ===
>> RCS file: /cvs/openbsd/ports/devel/gflags/Makefile,v
>> retrieving revision 1.2
>> diff -u -r1.2 Makefile
>> --- gflags//Makefile 10 Oct 2009 13:36:14 - 1.2
>> +++ gflags//Makefile 12 Jan 2010 10:02:53 -
>> @@ -3,8 +3,8 @@
>>
>> COMMENT = c++ commandline flags processing library
>>
>> -DISTNAME = gflags-1.2
>> -PKGNAME = ${DISTNAME}p0
>> +DISTNAME = gflags-1.3
>> +PKGNAME = ${DISTNAME}
>
> Not needed, PKGNAME defaults to ${DISTNAME} if not set. (i wonder how
> many times this has been said...)
>
> Other than that looks good.
>
Updated patch
Index: gflags//Makefile
===
RCS file: /cvs/openbsd/ports/devel/gflags/Makefile,v
retrieving revision 1.2
diff -u -r1.2 Makefile
--- gflags//Makefile10 Oct 2009 13:36:14 - 1.2
+++ gflags//Makefile12 Jan 2010 10:02:53 -
@@ -3,8 +3,8 @@
COMMENT = c++ commandline flags processing library
-DISTNAME = gflags-1.2
-PKGNAME = ${DISTNAME}p0
+DISTNAME = gflags-1.3
SHARED_LIBS += gflags 0.0 # .0.0
SHARED_LIBS += gflags_nothreads 0.0 # .0.0
Index: gflags//distinfo
===
RCS file: /cvs/openbsd/ports/devel/gflags/distinfo,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 distinfo
--- gflags//distinfo24 Sep 2009 19:51:44 - 1.1.1.1
+++ gflags//distinfo12 Jan 2010 10:02:53 -
@@ -1,5 +1,5 @@
-MD5 (gflags-1.2.tar.gz) = zxtVdz5JtyH6jh+vAcA4Sw==
-RMD160 (gflags-1.2.tar.gz) = xOSBcxcwi/Q9sbH4EgYUpTrxV8E=
-SHA1 (gflags-1.2.tar.gz) = XygrnXKE5qKuXuL46mBmhLZNkgQ=
-SHA256 (gflags-1.2.tar.gz) = eVVvt+JGTFMYu0MVHDEg0TN+PowNHmjHNPDNbYor7cQ=
-SIZE (gflags-1.2.tar.gz) = 526580
+MD5 (gflags-1.3.tar.gz) = baPTuc2CwiK1Ia5oa2z6iw==
+RMD160 (gflags-1.3.tar.gz) = MXz+H2ngDCJWV/NtLQUhsprbouM=
+SHA1 (gflags-1.3.tar.gz) = wOFIek2KK0LkG/UW89SA7cd/to4=
+SHA256 (gflags-1.3.tar.gz) = eDl7v+bqQAcozb0ExIwStv34pfHGWxoQ5/qe/Bx0+tw=
+SIZE (gflags-1.3.tar.gz) = 501385
--
Vincent Auclair- auclair.vincent[ at ]gmail.com
(+33) 6 80 77 59 67
gflags-patch
Description: Binary data
Re: [NEW] protobuf
On Tue, Jan 12, 2010 at 8:55 PM, Landry Breuil wrote:
> On Tue, Jan 12, 2010 at 11:56:27AM +0100, Auclair Vincent wrote:
>> Update version from 2.2.0 to 2.3.0
>>
>> Tarball is attached.
>
> Comments portswise :
>
> - SHARED_LIBS usually start at 0.0
> - as CONFIGURE_STYLE is set to gnu, automake won't be run, so
> *Makefile.am won't be read, so patching them is useless.
> patches/patch-src_Makefile_am and patches/patch-Makefile_am can go away.
> regress fails with:
> gmake[3]: *** No rule to make target `/usr/local/libgtest.la', needed by
> `protobuf-test'. Stop.
> -> your patch-src_Makefile_in is are wrong. (missing /lib/ after
> ${LOCALBASE} for libgtest*.la.)
>
> Other than that, looks good. Builds fine @amd64/ppc.
Updated tarball which corrects the problems
--
Vincent Auclair- auclair.vincent[ at ]gmail.com
(+33) 6 80 77 59 67
protobuf.tar.gz
Description: GNU Zip compressed data
Re: UPDATE: devel/boost
On Mon, Jan 11, 2010 at 6:25 PM, Auclair Vincent
wrote:
> Compiled ok :)
>
> regress didn't work
>
> # make regress
> ===> Regression check for boost-1.41.0p0
> make: cannot open Makefile.
> *** Error code 2
>
> Stop in /yellowstone/workbox/git/ports/devel/boost (line 2226 of
> /usr/ports/infrastructure/mk/bsd.port.mk).
>
> tested on i386 using mainly boost::asio
Well actually I stumbled on a problem :)
When using the -W warning flag it get these warnings
In file included from /usr/local/include/boost/smart_ptr/shared_ptr.hpp:31,
from /usr/local/include/boost/shared_ptr.hpp:17,
from ../ags/module/module.hpp:14,
from ../ags/module/modulemanager.h:10,
from module/modulemanager.cpp:5:
/usr/local/include/boost/throw_exception.hpp:57: warning: `inline' is not at
beginning of declaration
this issue is from this line
template BOOST_ATTRIBUTE_NORETURN inline void
throw_exception( E const & e )
We can find the define in boost/exception/detail/attribute_noreturn.hpp
#define BOOST_ATTRIBUTE_NORETURN __attribute__((noreturn))
So it doens't like
template __attribute__((noreturn)) inline void
throw_exception( E const & e )
@
In file included from
/usr/local/include/boost/date_time/gregorian/gregorian.hpp:21,
from
/usr/local/include/boost/date_time/posix_time/time_formatters.hpp:12,
from
/usr/local/include/boost/date_time/posix_time/posix_time.hpp:24,
from ../ags/network/timer.ipp:13,
from plugins/arch/OpenBSD/arenamanager.cpp:6:
/usr/local/include/boost/date_time/gregorian/conversion.hpp: In function `tm
boost::gregorian::to_tm(const boost::gregorian::date&)':
/usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning: missing
initializer for member `tm::tm_sec'
/usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning: missing
initializer for member `tm::tm_min'
/usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning: missing
initializer for member `tm::tm_hour'
/usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning: missing
initializer for member `tm::tm_mday'
/usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning: missing
initializer for member `tm::tm_mon'
/usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning: missing
initializer for member `tm::tm_year'
/usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning: missing
initializer for member `tm::tm_wday'
/usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning: missing
initializer for member `tm::tm_yday'
/usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning: missing
initializer for member `tm::tm_isdst'
/usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning: missing
initializer for member `tm::tm_gmtoff'
/usr/local/include/boost/date_time/gregorian/conversion.hpp:44: warning: missing
initializer for member `tm::tm_zone'
In file included from
/usr/local/include/boost/date_time/posix_time/posix_time_io.hpp:21,
from
/usr/local/include/boost/date_time/posix_time/posix_time.hpp:31,
from ../ags/network/timer.ipp:13,
from plugins/arch/OpenBSD/arenamanager.cpp:6:
Here tm innitialized like this
std::tm timetm = {};
@
/usr/local/include/boost/tuple/detail/tuple_basic.hpp:119: warning: `static' is
not at beginning of declaration
here the issue is this
inline static RET get(const cons& t)
{
return t.head;
}
It want's static inline and not inline static.
@
In file included from /usr/local/include/boost/asio/io_service.hpp:26,
from ../ags/common/io_service.h:8,
from common/io_service.cpp:5:
/usr/local/include/boost/system/error_code.hpp:281: warning: `friend' is not at
beginning of declaration
which cooresponds to this function in the boost header
inline friend bool operator==( const error_condition & lhs,
const error_condition & rhs )
{
return lhs.m_cat == rhs.m_cat && lhs.m_val == rhs.m_val;
}
same issue in inline ordering
I have a few other warnings with inlines.
All of them disappear if I don't use the -W flag
--
Vincent Auclair- auclair.vincent[ at ]gmail.com
(+33) 6 80 77 59 67
Re: [NEW] protobuf
Update version from 2.2.0 to 2.3.0
Tarball is attached.
2010-01-08 version 2.3.0:
General
* Parsers for repeated numeric fields now always accept both packed and
unpacked input. The [packed=true] option only affects serializers.
Therefore, it is possible to switch a field to packed format without
breaking backwards-compatibility -- as long as all parties are using
protobuf 2.3.0 or above, at least.
* The generic RPC service code generated by the C++, Java, and Python
generators can be disabled via file options:
option cc_generic_services = false;
option java_generic_services = false;
option py_generic_services = false;
This allows plugins to generate alternative code, possibly specific to some
particular RPC implementation.
protoc
* Now supports a plugin system for code generators. Plugins can generate
code for new languages or inject additional code into the output of other
code generators. Plugins are just binaries which accept a protocol buffer
on stdin and write a protocol buffer to stdout, so they may be written in
any language. See src/google/protobuf/compiler/plugin.proto.
**WARNING**: Plugins are experimental. The interface may change in a
future version.
* If the output location ends in .zip or .jar, protoc will write its output
to a zip/jar archive instead of a directory. For example:
protoc --java_out=myproto_srcs.jar --python_out=myproto.zip myproto.proto
Currently the archive contents are not compressed, though this could change
in the future.
* inf, -inf, and nan can now be used as default values for float and double
fields.
C++
* Various speed and code size optimizations.
* DynamicMessageFactory is now fully thread-safe.
* Message::Utf8DebugString() method is like DebugString() but avoids escaping
UTF-8 bytes.
* Compiled-in message types can now contain dynamic extensions, through use
of CodedInputStream::SetExtensionRegistry().
* Now compiles shared libraries (DLLs) by default on Cygwin and MinGW, to
match other platforms. Use --disable-shared to avoid this.
Java
* parseDelimitedFrom() and mergeDelimitedFrom() now detect EOF and return
false/null instead of throwing an exception.
* Fixed some initialization ordering bugs.
* Fixes for OpenJDK 7.
Python
* 10-25 times faster than 2.2.0, still pure-Python.
* Calling a mutating method on a sub-message always instantiates the message
in its parent even if the mutating method doesn't actually mutate anything
(e.g. parsing from an empty string).
* Expanded descriptors a bit.
On Thu, Dec 31, 2009 at 1:57 PM, Auclair Vincent
wrote:
> attached is a port of google protobuf
>
> Information for inst:protobuf-2.2.0
>
> Comment:
> c++ protocol buffers
>
> Description:
> Protocol buffers are a flexible, efficient, automated mechanism for
> serializing
> structured data - think XML, but smaller, faster, and simpler. You define how
> you want your data to be structured once, then you can use special generated
> source code to easily write and read your structured data to and from a
> variety
> of data streams and using a variety of languages. You can even update your
> data
> structure without breaking deployed programs that are compiled against the
> "old"
> format.
>
> Maintainer: Vincent Auclair
>
> WWW: http://code.google.com/p/protobuf/
>
> It uses the installed gtest instead of the shipped one for regressions tests.
> This is only the c++ part. There are also a java and python part in it.
> Which I am not currently planning to port.
>
> Comments ?
> This was also ported for the ACSEL. (same as gtest, glog) So it would be nice
> if
> it could be mentioned in the commit message. :)
> This is the 2.2.0 version as the 2.2.0a is only a debian fix.
> The 2.3.0 is in release candidate.
>
> I am copying the website example here :
>
> You write a .proto file like this:
>
> message Person {
> required int32 id = 1;
> required string name = 2;
> optional string email = 3;
> }
>
> Then you compile it with protoc, the protocol buffer compiler,
> to produce code in C++, Java, or Python.
>
> Then, if you are using C++, you use that code like this:
>
> Person person;
> person.set_id(123);
> person.set_name("Bob");
> person.set_email("b...@example.com");
>
> fstream out("person.pb", ios::out | ios::binary | ios::trunc);
> person.SerializeToOstream(&out);
> out.close();
>
> Or like this:
>
> Person person;
> fstream in("person.pb", ios::in | ios::binary);
> if (!person.ParseFromIstream(&in)) {
> cerr << "Failed to parse person.pb." << endl;
> exit(1);
> }
>
> cout << "ID: " << person.id() << endl;
> cout << "name: " << person.name() << endl;
> if (person.has_email()) {
> cout << "e-mail: " << person.email() << endl;
> }
>
--
Vincent Auclair- auclair.vincent[ at ]gmail.com
(+33) 6 80 77 59 67
protobuf.tar.gz
Description: GNU Zip compressed data
[UPDATE] gflags -> 1.3
Here is an update for gflags 1.3
Mostly cosmetic changes
Mon Jan 4 18:09:30 2010 Google Inc.
* google-gflags: version 1.3
* PORTABILITY: can now build and run tests under MSVC (csilvers)
* Remove the python gflags code, which is now its own package (tansell)
* Clarify that "last flag wins" in the docs (csilvers)
* Comment danger of using GetAllFlags in validators (wojtekm)
* PORTABILITY: Some fixes necessary for c++0x (mboerger)
* Makefile fix: $(srcdir) -> $(top_srcdir) in one place (csilvres)
* INSTALL: autotools to autoconf v2.64 + automake v1.11 (csilvers)
Index: gflags//Makefile
===
RCS file: /cvs/openbsd/ports/devel/gflags/Makefile,v
retrieving revision 1.2
diff -u -r1.2 Makefile
--- gflags//Makefile10 Oct 2009 13:36:14 - 1.2
+++ gflags//Makefile12 Jan 2010 10:02:53 -
@@ -3,8 +3,8 @@
COMMENT = c++ commandline flags processing library
-DISTNAME = gflags-1.2
-PKGNAME = ${DISTNAME}p0
+DISTNAME = gflags-1.3
+PKGNAME = ${DISTNAME}
SHARED_LIBS += gflags 0.0 # .0.0
SHARED_LIBS += gflags_nothreads 0.0 # .0.0
Index: gflags//distinfo
===
RCS file: /cvs/openbsd/ports/devel/gflags/distinfo,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 distinfo
--- gflags//distinfo24 Sep 2009 19:51:44 - 1.1.1.1
+++ gflags//distinfo12 Jan 2010 10:02:53 -
@@ -1,5 +1,5 @@
-MD5 (gflags-1.2.tar.gz) = zxtVdz5JtyH6jh+vAcA4Sw==
-RMD160 (gflags-1.2.tar.gz) = xOSBcxcwi/Q9sbH4EgYUpTrxV8E=
-SHA1 (gflags-1.2.tar.gz) = XygrnXKE5qKuXuL46mBmhLZNkgQ=
-SHA256 (gflags-1.2.tar.gz) = eVVvt+JGTFMYu0MVHDEg0TN+PowNHmjHNPDNbYor7cQ=
-SIZE (gflags-1.2.tar.gz) = 526580
+MD5 (gflags-1.3.tar.gz) = baPTuc2CwiK1Ia5oa2z6iw==
+RMD160 (gflags-1.3.tar.gz) = MXz+H2ngDCJWV/NtLQUhsprbouM=
+SHA1 (gflags-1.3.tar.gz) = wOFIek2KK0LkG/UW89SA7cd/to4=
+SHA256 (gflags-1.3.tar.gz) = eDl7v+bqQAcozb0ExIwStv34pfHGWxoQ5/qe/Bx0+tw=
+SIZE (gflags-1.3.tar.gz) = 501385
--
Vincent Auclair- auclair.vincent[ at ]gmail.com
(+33) 6 80 77 59 67
gflags-patch
Description: Binary data
Re: UPDATE: devel/boost
Compiled ok :) regress didn't work # make regress ===> Regression check for boost-1.41.0p0 make: cannot open Makefile. *** Error code 2 Stop in /yellowstone/workbox/git/ports/devel/boost (line 2226 of /usr/ports/infrastructure/mk/bsd.port.mk). tested on i386 using mainly boost::asio Thanks for updating boost :) On Mon, Jan 11, 2010 at 2:49 PM, Andrej Elizarov wrote: > Compiled ok. > Tested on i386-current. > > Thank you. > > -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67
Re: [NEW] glog
On Thu, Dec 31, 2009 at 2:28 PM, Landry Breuil wrote:
> On Thu, Dec 31, 2009 at 01:46:44PM +0100, Auclair Vincent wrote:
>> attached is the google-glog port
>>
>> Information for inst:glog-0.3.0
>>
>> Comment:
>> c++ application-level logging
>>
>> Description:
>> The glog library implements application-level logging. This library
>> provides logging APIs based on C++-style streams and various helper
>> macros.
>>
>> Maintainer: Vincent Auclair
>>
>> WWW: http://code.google.com/p/google-glog/
>>
>> It is missing a library to correctly dump the signal handlers.
>> one of these probably : execinfo, libunwind or ucontext
>
> CONFIGURE_ARGS should use --with-gflags=${LOCALBASE}, not ${TRUEPREFIX} :
> - LOCALBASE is for already installed stuff
> - TRUEPREFIX is where the current port will actually install its stuff
>
> fails to build @amd64 here:
> src/logging.cc:1545: warning: comparison between signed and unsigned
> integer
> expressions
> src/logging.cc: In function `int google::posix_strerror_r(int, char*,
> long
> unsigned int)':
> src/logging.cc:1758: error: reinterpret_cast from `char*' to `int' loses
> precision
>
> Builds fine on macppc though.
>
> LIB_DEPENDS should precise the gflags::devel/gflags libspec it depends on.
> $make port-lib-depends-check
> LIB_DEPENDS: gflags.0 from gflags-1.2p0
> (/usr/local/lib/libglog.so.0.0)
>
Updated tarball contains an upstream patch for the
error on amd64. It was trying to fit an adress into an int.
Changed TRUEPREFIX to LOCALBASE
and fixed the LIBDEPENDS.
Since I do not have an amd64 I could not test if
there is another issue. If you see one please tell me.
--
Vincent Auclair- auclair.vincent[ at ]gmail.com
(+33) 6 80 77 59 67
glog.tar.gz
Description: GNU Zip compressed data
[NEW] protobuf
attached is a port of google protobuf
Information for inst:protobuf-2.2.0
Comment:
c++ protocol buffers
Description:
Protocol buffers are a flexible, efficient, automated mechanism for serializing
structured data - think XML, but smaller, faster, and simpler. You define how
you want your data to be structured once, then you can use special generated
source code to easily write and read your structured data to and from a variety
of data streams and using a variety of languages. You can even update your data
structure without breaking deployed programs that are compiled against the "old"
format.
Maintainer: Vincent Auclair
WWW: http://code.google.com/p/protobuf/
It uses the installed gtest instead of the shipped one for regressions tests.
This is only the c++ part. There are also a java and python part in it.
Which I am not currently planning to port.
Comments ?
This was also ported for the ACSEL. (same as gtest, glog) So it would be nice if
it could be mentioned in the commit message. :)
This is the 2.2.0 version as the 2.2.0a is only a debian fix.
The 2.3.0 is in release candidate.
I am copying the website example here :
You write a .proto file like this:
message Person {
required int32 id = 1;
required string name = 2;
optional string email = 3;
}
Then you compile it with protoc, the protocol buffer compiler,
to produce code in C++, Java, or Python.
Then, if you are using C++, you use that code like this:
Person person;
person.set_id(123);
person.set_name("Bob");
person.set_email("b...@example.com");
fstream out("person.pb", ios::out | ios::binary | ios::trunc);
person.SerializeToOstream(&out);
out.close();
Or like this:
Person person;
fstream in("person.pb", ios::in | ios::binary);
if (!person.ParseFromIstream(&in)) {
cerr << "Failed to parse person.pb." << endl;
exit(1);
}
cout << "ID: " << person.id() << endl;
cout << "name: " << person.name() << endl;
if (person.has_email()) {
cout << "e-mail: " << person.email() << endl;
}
--
Vincent Auclair- auclair.vincent[ at ]gmail.com
(+33) 6 80 77 59 67
protobuf.tar.gz
Description: GNU Zip compressed data
[NEW] glog
attached is the google-glog port
Information for inst:glog-0.3.0
Comment:
c++ application-level logging
Description:
The glog library implements application-level logging. This library
provides logging APIs based on C++-style streams and various helper
macros.
Maintainer: Vincent Auclair
WWW: http://code.google.com/p/google-glog/
It is missing a library to correctly dump the signal handlers.
one of these probably : execinfo, libunwind or ucontext
It requires google-gtest and google-gflags.
Comments ?
And same as for gtest, this was ported for the ACSEL, can it be
mentioned in the commit message.
Here is an example file (also attached) :
#include
#include
#include
int main(int ac, char **av) {
// this is for glog
google::InitGoogleLogging(av[0]);
google::InstallFailureSignalHandler();
// now for gflags
google::ParseCommandLineFlags(&ac, &av, true);
// normal log
LOG(INFO) << "test info";
LOG(WARNING) << "this is a warning";
LOG(ERROR) << "this is a error";
//LOG(FATAL) << "this stops the program"
// verbose logging
VLOG(1) << "log at level 1";
VLOG(4) << "log at level 4";
// debug logging
DLOG(INFO) << "log if NDEBUG not defined"; // same for
WARNING,ERROR,FATAL
// conditional logging
{
int num_cookies = 20;
LOG_IF(INFO, num_cookies > 10) << "Got lots of cookies";
// example taken from the website
}
// check macros (not controlled by NDEBUG)
CHECK(true == true) << "or else the world ends";
return EXIT_SUCCESS;
}
new...@glitter-band > g++ test.cpp -I/usr/local/include
-L/usr/local/lib -lglog -lgflags -o glog-test
/usr/lib/libstdc++.so.49.0: warning: strcpy() is almost always
misused, please use strlcpy()
/usr/lib/libstdc++.so.49.0: warning: strcat() is almost always
misused, please use strlcat()
new...@glitter-band > ./glog-test
E1231 13:38:15.125598 2185737216 test.cpp:15] this is a error
new...@glitter-band > ls /tmp/glog-test*
/tmp/glog-test
/tmp/glog-test.ERROR
/tmp/glog-test.INFO
/tmp/glog-test.WARNING
/tmp/glog-test.glitter-band.XXX.newton.log.ERROR.20091231-133815.13306
/tmp/glog-test.glitter-band.XXX.newton.log.INFO.20091231-133815.13306
/tmp/glog-test.glitter-band.XXX.newton.log.WARNING.20091231-133815.13306
new...@glitter-band > ./glog-test --help
// Only including glog flags here
Flags from src/logging.cc:
-alsologtoemail (log messages go to these email addresses in addition to
logfiles) type: string default: ""
-alsologtostderr (log messages go to stderr in addition to logfiles)
type: bool default: false
-log_backtrace_at (Emit a backtrace when logging at file:linenum.)
type: string default: ""
-log_dir (If specified, logfiles are written into this directory instead of
the default logging directory.) type: string default: ""
-log_link (Put additional links to the log files in this directory)
type: string default: ""
-log_prefix (Prepend the log prefix to the start of each log line)
type: bool default: true
-logbuflevel (Buffer log messages logged at this level or lower (-1 means
don't buffer; 0 means buffer INFO only; ...)) type: int32 default: 0
-logbufsecs (Buffer log messages for at most this many seconds) type: int32
default: 30
-logemaillevel (Email log messages logged at this level or higher (0 means
email all; 3 means email FATAL only; ...)) type: int32 default: 999
-logmailer (Mailer used to send logging email) type: string
default: "/bin/mail"
-logtostderr (log messages go to stderr instead of logfiles) type: bool
default: false
-max_log_size (approx. maximum log file size (in MB). A value of 0 will be
silently overridden to 1.) type: int32 default: 1800
-minloglevel (Messages logged at a lower level than this don't actually get
logged anywhere) type: int32 default: 0
-stderrthreshold (log messages at or above this level are copied to stderr
in addition to logfiles. This flag obsoletes --alsologtostderr.)
type: int32 default: 2
-stop_logging_if_full_disk (Stop attempting to log to disk if the disk is
full.) type: bool default: false
Flags from src/utilities.cc:
-symbolize_stacktrace (Symbolize the stack trace in the tombstone)
type: bool default: true
Flags from src/vlog_is_on.cc:
-v (Show all VLOG(m) messages for m <= this. Overridable by --vmodule.)
type: int32 default: 0
-vmodule (per-module verbose level. Argument is a comma-separated list of
=. is a glob pattern, matched
against the filename base (that is, name ignoring .cc/.h./-inl.h). overrides any value given by --v.) type: string default: ""
You can also log to syslog and send mails.
--
Vincent Auclair- auclair.vincent[ at ]gmail.com
(+33) 6 80 77 59 67
glog.tar.gz
Description
Re: GTest, Legal question and OK's
>> > The attached gtest port was from Auclair Vincent. I am OKing this apart >> > from one query. The port was developed at the Advance Computer Science >> > Epitech Lab. The lab master asked for this comment in the Makefile: >> > >> > # Original from auclair.vincent and ACSEL >> > >> > I would rather it goes into the commit message (if atall). What do you >> > guys think? Ofcourse ACSEL must agree to whatever we decide. >> >> I agree, but only if the lab master is espie ;) > > That's not me, actually. I would too prefer that credit goes in the > commit message proper. The lab master has agreed to put it in the commit message and it is indeed better in the commit message. I haven't seen any feedback on this, could another developper please review the gtest port (latest version is the one edd sent) and if their are issues send them to me or else could it be committed ? I have two ports depending on gtest that I would like to propose to @ports. :) gtest is used in the regression parts of the two ports and works well. -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67
Re: [RESUBMIT] gtest & glog
On Wed, Nov 25, 2009 at 6:13 PM, Stuart Henderson wrote: > On 2009/11/25 17:53, Auclair Vincent wrote: >> > * remove duplicate gtest_main SHARED_LIB definition. >> >> It's actually not a duplicate. >> It contains a main. I'll show an example just after. > > SHARED_LIBS += gtest 0.0 # .0.0 > SHARED_LIBS += gtest_main 0.0 # .0.0 > SHARED_LIBS += gtest_main 0.0 # .0.0 > > Oups! I checked PFRAG.shared and not the Makefile for the duplicate. Here's the updated tarball. -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67 gtest.tar.gz Description: GNU Zip compressed data
Re: [RESUBMIT] gtest & glog
Hello,
On Wed, Nov 25, 2009 at 3:08 PM, Edd Barrett wrote:
> Hi,
> Lets look at gtest.
>
> * c++ can become C++ in COMMENT, as it is a name.
Done
> * remove blank line in DESCR.
Done
> * remove duplicate gtest_main SHARED_LIB definition.
It's actually not a duplicate.
It contains a main. I'll show an example just after.
>
> The port builds and installs fine. Libs appear to be configured correctly.
>
> I made a test case:
> --- 8< ---
> #include
> #include
>
> int main(int argc, char **argv) {
> int x = 2;
> int y = 4;
>
> EXPECT_EQ(x, y) << "equal test fails";
> ASSERT_EQ(x, y) << "equal test fails";
>
> return 0;
> }
> --- 8< ---
>
> But it will not build, due to this:
>
> --- 8< ---
> edd% g++ -I/usr/local/include -L/usr/local/lib -lgtest g.c
> g.c: In function `int main(int, char**)':
> g.c:9: error: void value not ignored as it ought to be
> --- 8< ---
>
> EXPACTE_EQ appears to work, as this program builds and works if i comment the
> ASSERT_EQ line.
>
> I am following instructions from this page:
> http://code.google.com/p/googletest/wiki/GoogleTestPrimer
>
> It is likely to be my own mistake, I must admit my C++ is not all that good.
>
The code is actually supposed to look like this.
***
new...@glitter-band > more t.cpp
#include
#include
TEST(test, test1) {
int x = 2;
int y = 4;
EXPECT_EQ(x, y) << "equal test fails";
ASSERT_EQ(x, y) << "equal test fails";
}
int main(int argc, char **argv) {
::testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
***
http://code.google.com/p/googletest/wiki/GoogleTestPrimer#Simple_Tests
The ASSERT_EQ doesn't work in the main, because it expands to a code
that returns a void. I guess g++ tries to get a int from the void.
By putting the tests in the TEST macro (which expands to a class) it
works. (Which is the way to do it)
new...@glitter-band > g++ -I/usr/local/include -L/usr/local/lib
-lgtest t.cpp
/usr/lib/libstdc++.so.49.0: warning: strcpy() is almost always
misused, please use strlcpy()
/usr/lib/libstdc++.so.49.0: warning: strcat() is almost always
misused, please use strlcat()
new...@glitter-band > ./a.out
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from test
[ RUN ] test.test1
t2.cpp:8: Failure
Value of: y
Actual: 4
Expected: x
Which is: 2
equal test fails
t2.cpp:9: Failure
Value of: y
Actual: 4
Expected: x
Which is: 2
equal test fails
[ FAILED ] test.test1 (0 ms)
[--] 1 test from test (1 ms total)
[--] Global test environment tear-down
[==] 1 test from 1 test case ran. (1 ms total)
[ PASSED ] 0 tests.
[ FAILED ] 1 test, listed below:
[ FAILED ] test.test1
1 FAILED TEST
Here's why there is a gtest_main library.
It permits you to not write your main and just write a bunch of files
containing the test and link it directly to gtest_main.
Here's the example :
new...@glitter-band > more t2.cpp
#include
#include
TEST(test, test1) {
int x = 2;
int y = 4;
EXPECT_EQ(x, y) << "equal test fails";
ASSERT_EQ(x, y) << "equal test fails";
}
new...@glitter-band > g++ -I/usr/local/include -L/usr/local/lib
-lgtest_main t2.cpp
/usr/lib/libstdc++.so.49.0: warning: strcpy() is almost always
misused, please use strlcpy()
/usr/lib/libstdc++.so.49.0: warning: strcat() is almost always
misused, please use strlcat()
new...@glitter-band >
I omitted the output of a.out because it's long. But it works.
I also removed PLIST.orig from the new tarball.
Thanks for the comments. :)
--
Vincent Auclair- auclair.vincent[ at ]gmail.com
(+33) 6 80 77 59 67
gtest.tar.gz
Description: GNU Zip compressed data
[RESUBMIT] gtest & glog
Hello Here is a resubmit of the ports. Glog is patched and now correctly finds the gflags library. The new glog does not link with the old one. (link time errors) On Tue, Oct 20, 2009 at 10:46 AM, Auclair Vincent wrote: > Attached are gtest and glog. > gtest has regress disabled because it needs gcc4. > glog only has the gtest regress test enabled since gmock requires gcc4 to > build. > > new...@cerberus > pkg_info gtest > Information for inst:gtest-1.4.0 > > Comment: > c++ unit test framework > > Required by: > glog-0.3.0 > > Description: > Google's framework for writing C++ tests on a variety of platforms (Linux, Mac > OS X, Windows, Cygwin, Windows CE, and Symbian). Based on the xUnit > architecture. Supports automatic test discovery, a rich set of assertions, > user-defined assertions, death tests, fatal and non-fatal failures, value- and > type-parameterized tests, various options for running the tests, and XML test > report generation. > > > Maintainer: Vincent Auclair > > WWW: http://code.google.com/p/googletest/ > > > new...@cerberus > pkg_info glog > Information for inst:glog-0.3.0 > > Comment: > c++ application-level logging > > Description: > The glog library implements application-level logging. This library > provides logging APIs based on C++-style streams and various helper > macros. > > Maintainer: Vincent Auclair > > WWW: http://code.google.com/p/google-glog/ > -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67 gtest.tar.gz Description: GNU Zip compressed data glog.tar.gz Description: GNU Zip compressed data
[NEW] gtest & glog
Attached are gtest and glog. gtest has regress disabled because it needs gcc4. glog only has the gtest regress test enabled since gmock requires gcc4 to build. new...@cerberus > pkg_info gtest Information for inst:gtest-1.4.0 Comment: c++ unit test framework Required by: glog-0.3.0 Description: Google's framework for writing C++ tests on a variety of platforms (Linux, Mac OS X, Windows, Cygwin, Windows CE, and Symbian). Based on the xUnit architecture. Supports automatic test discovery, a rich set of assertions, user-defined assertions, death tests, fatal and non-fatal failures, value- and type-parameterized tests, various options for running the tests, and XML test report generation. Maintainer: Vincent Auclair WWW: http://code.google.com/p/googletest/ new...@cerberus > pkg_info glog Information for inst:glog-0.3.0 Comment: c++ application-level logging Description: The glog library implements application-level logging. This library provides logging APIs based on C++-style streams and various helper macros. Maintainer: Vincent Auclair WWW: http://code.google.com/p/google-glog/ -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67 gtest.tar.gz Description: GNU Zip compressed data glog.tar.gz Description: GNU Zip compressed data
Re: NEW: devel/gflags, updated to version 1.2
Always better with a tarball attached. On Fri, Sep 11, 2009 at 1:32 PM, Auclair Vincent wrote: > Tested on i386. Make regress works > Comments? OK? > > new...@cerberus > pkg_info gflags > Information for inst:gflags-1.2 > > Comment: > c++ commandline flags processing library > > Description: > The gflags package contains a library that implements commandline flags > processing. As such it's a replacement for getopt(). It has increased > flexibility, including built-in support for C++ types like string, and > the ability to define flags in the source file in which they're used. > > Maintainer: Vincent Auclair > > WWW: http://code.google.com/p/google-gflags/ > > -- > Vincent Auclair - auclair.vincent[ at ]gmail.com > (+33) 6 80 77 59 67 > -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67 gflags.tar.gz Description: GNU Zip compressed data
NEW: devel/gflags, updated to version 1.2
Tested on i386. Make regress works Comments? OK? new...@cerberus > pkg_info gflags Information for inst:gflags-1.2 Comment: c++ commandline flags processing library Description: The gflags package contains a library that implements commandline flags processing. As such it's a replacement for getopt(). It has increased flexibility, including built-in support for C++ types like string, and the ability to define flags in the source file in which they're used. Maintainer: Vincent Auclair WWW: http://code.google.com/p/google-gflags/ -- Vincent Auclair- auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67
NEW: devel/gflags
c++ commandline flags processing library from google -- Auclair Vincent - auclair.vincent[ at ]gmail.com (+33) 6 80 77 59 67 gflags.tar.gz Description: GNU Zip compressed data
