Activity for porg

Ookaze posted a comment on ticket #17

Ookaze — Sun, 25 Jan 2026 16:02:10 -0000

Good thing, I never got the time to get back to it in a streamlined way. I see the usual suspects are still there. Thanks Leandro for your fixes, I've used them for my local repository. My use of porg goes back to the paco days actually, I'm still using it for my package management.

Leandro Nini posted a comment on ticket #17

Leandro Nini — Mon, 29 Dec 2025 19:14:29 -0000

Cool! I have some (mostly build system) fixes in my fork here: https://github.com/drfiemost/porg/commits/master/

Pierre Labastie posted a comment on ticket #17

Pierre Labastie — Sun, 07 Dec 2025 15:11:09 -0000

That's really good news! I've been using porg for almost ten years now, but to make it work until now, I needed the patch I proposed in ticket 15. Actually, I was planning to fork porg to github, but fortunately I saw this post first. Note that I'd be happy to help for code. Regards Pierre

David Ricart created ticket #17

David Ricart — Mon, 24 Feb 2025 08:29:17 -0000

Back on duty

Jean-Michel Pollion posted a comment on ticket #16

Jean-Michel Pollion — Wed, 30 Aug 2023 11:21:48 -0000

I made a proposal to David more than 1 year ago but I made little progress, apart from creating a fork too. I need to streamline several processes before seriously taking the project back, I'm still interested but if someone else wants to revive this project, that's not a problem for me.

Leandro Nini posted a comment on ticket #16

Leandro Nini — Thu, 24 Aug 2023 08:33:47 -0000

Still any interest in reviving the project? I have my own clone on github with a bunch of fixes, but it would be good to have an official release.

David Ricart posted a comment on ticket #16

David Ricart — Wed, 08 Jun 2022 12:01:02 -0000

Hello "Ookaze" (your name?). Yes, I remember you being quite active in porg / paco issues since long time ago. So in principle I am willing to consider your kind offer to take over the project. But you'd have to meet certain conditions, like keeping it free, simple, and give credit to the original author. Also, since I am no longer familiar with the sourceforge process, you'd have to make the transition to other code hosting platforms yourself. Also, you'd have to establish some contact with the...

Ookaze posted a comment on ticket #16

Ookaze — Tue, 07 Jun 2022 19:04:57 -0000

Hi David, I've used porg constantly since paco as I compile my own OS for all my servers and clients for 20+ y now. I can take back the development, though I'm not familiar with the sourceforge process yet. If it's allowed, I would like to put the code on github too. I won't be especially active after the initial cleanup, but if noone else wants to take the dev back, I'm ready to manage this.

David Ricart posted a comment on ticket #16

David Ricart — Thu, 26 May 2022 17:25:05 -0000

Hello everybody. I am David, the creator and maintainer of porg. I wanted you to know that my life has led me far from computer programming lately, so I don't have the time and energy to keep maintaining this project anymore. I am willing to listen to any candidate to take it over. Cheers, ~David. 2022-05-26 16:44 GMT+02:00, Ookaze ookaze0@users.sourceforge.net: You're right, iirc this was David's patch back in 2016. I haven't done anything but correct the bug that was very annoying and bit me hard...

Ookaze posted a comment on ticket #16

Ookaze — Thu, 26 May 2022 14:44:47 -0000

You're right, iirc this was David's patch back in 2016. I haven't done anything but correct the bug that was very annoying and bit me hard recently with the release of coreutils 9.1 where the bug made porg not work anymore. Now that you talk about buffer overflows, it reminds me that even if at functions are more secure, we still have no control over the actual directory name, and that I have to check that I didn't forget to add another fix because the code sometimes puts directory names starting...

Leandro Nini posted a comment on ticket #16

Leandro Nini — Thu, 26 May 2022 05:57:54 -0000

Ignoring the warnings looks more like an hack than a fix. I'd better null terminate the string after strncpy to prevent possible buffer overflows: --- a/lib/porg-log/log.c +++ b/lib/porg-log/log.c @@ -102,12 +102,14 @@ static void porg_get_absolute_path(int fd, const char* path, char* abs_path) /* relative to CWD */ else if (fd < 0) { strncpy(abs_path, cwd, PORG_BUFSIZE - 1); + abs_path[PORG_BUFSIZE - 1] = 0; strncat(abs_path, "/", PORG_BUFSIZE - strlen(abs_path) - 1); strncat(abs_path, path, PORG_BUFSIZE...

Ookaze posted a comment on ticket #16

Ookaze — Wed, 25 May 2022 10:58:35 -0000

This bug was corrected in a previous ticket in 2016. The patch was wrong though, the pragma added introduced a bug that prevents logging of some files. I finally tackled the problem yesterday. Here is my patch from 0.10 for these bugs. I've made a tarball for my 0.10.2 version as the autotools are outdated too in 0.10. I think the tool is ripe for a minor version release.

Leandro Nini created ticket #16

Leandro Nini — Fri, 22 Apr 2022 09:12:42 -0000

build error (stringop-truncation)

Pierre Labastie posted a comment on ticket #15

Pierre Labastie — Tue, 23 Jun 2020 09:26:31 -0000

I think the reason is that mv uses the new function renameat2, which has been introduced in glibc-2.28, if available. I attach a patch that fixes the testcase for me. Note: run autoreconf -fi after applying the patch.

Takao Magoori created ticket #15

Takao Magoori — Wed, 24 Oct 2018 01:43:35 -0000

porg does not handle mv event

Matsuand created ticket #14

Matsuand — Thu, 13 Sep 2018 07:01:56 -0000

Handling local ".porgrc" file

David Ricart posted a comment on ticket #11

David Ricart — Thu, 31 Aug 2017 10:51:16 -0000

Great. Thanks for helping.

Bat Guano posted a comment on ticket #11

Bat Guano — Thu, 31 Aug 2017 09:14:12 -0000

Compiles out of the box (:wq)

David Ricart posted a comment on ticket #11

David Ricart — Thu, 31 Aug 2017 07:46:46 -0000

I think a simple break after die_help() would do the job. There's no need to call assert(0), because die_help() terminates the program anyway. Done in r189. BTW: I do not react to failed assertions, because they're disabled on stable releases of porg. I just use them on development versions, to help detect errors.

David Ricart committed [r189]

David Ricart — Thu, 31 Aug 2017 07:46:34 -0000

Added break statement on switch, to fix compilation errors

Bat Guano modified a comment on ticket #11

Bat Guano — Thu, 31 Aug 2017 07:14:21 -0000

opt.cc: In constructor ‘Porg::Opt::Opt(int, char**)’: opt.cc:208:22: error: this statement may fall through [-Werror=implicit-fallthrough=] case '?': die_help(); ~~~~~~~~^~ opt.cc:212:4: note: here default: assert(0); break; ^~~~~~~ I just duplicated the “assert(0);break;” after the call to “die_help()”; I ignore, though, if and where you react to the failed assertion. An explicit fall through may be better or not...

Bat Guano modified a comment on ticket #11

Bat Guano — Thu, 31 Aug 2017 07:13:52 -0000

opt.cc: In constructor ‘Porg::Opt::Opt(int, char**)’: opt.cc:208:22: error: this statement may fall through [-Werror=implicit-fallthrough=] case '?': die_help(); ~~~~~~~~^~ opt.cc:212:4: note: here default: assert(0); break; ^~~~~~~ I just duplicated the “assert(0)” after the call to “die_help()”; I ignore, though, if and where you react to the failed assertion. An explicit fall through may be better or not...

Bat Guano modified a comment on ticket #11

Bat Guano — Thu, 31 Aug 2017 07:13:33 -0000

opt.cc: In constructor ‘Porg::Opt::Opt(int, char**)’: opt.cc:208:22: error: this statement may fall through [-Werror=implicit-fallthrough=] case '?': die_help(); ~~~~~~~~^~ opt.cc:212:4: note: here default: assert(0); break; ^~~~~~~ I just duplicated the “assert(0)” after the call to “diehelp()”; I ignore, though, if and where you react to the failed assertion. An explicit fall through may be better or not...

Bat Guano posted a comment on ticket #11

Bat Guano — Thu, 31 Aug 2017 07:12:43 -0000

opt.cc: In constructor ‘Porg::Opt::Opt(int, char**)’: opt.cc:208:22: error: this statement may fall through [-Werror=implicit-fallthrough=] case '?': die_help(); ~~~~~~~~^~ opt.cc:212:4: note: here default: assert(0); break; ^~~~~~~ I just duplicated the assert(0) after the call to die_help(); I ignore, though, if and where you react to the failed assertion. An explicit fall through may be better or not...

David Ricart modified a comment on ticket #11

David Ricart — Wed, 30 Aug 2017 20:58:19 -0000

OK. log.c is compiled with gcc, not g++. So we have to add the '-Wno-nonnull-compare' flag to MY_CFLAGS as well. Done in r188.

David Ricart posted a comment on ticket #11

David Ricart — Wed, 30 Aug 2017 19:04:31 -0000

OK. log.c is compiled with gcc, not g++. So we have to add the '-Wno-nonnull-compare' flag to MY_CFLAGS as well. Done in r188. 2017-08-30 19:46 GMT+02:00, Bat Guano patguano@users.sf.net: Thank you for keeping this up. Even after make distclean/make clean and autoreconf, compilation ends with the error when log.c is processed. The Makefile in porg-log contains, though: ~~~ cat lib/porg-log/Makefile | grep CXXFLAGS CXXFLAGS = -g -O2 MY_CXXFLAGS = -W -ansi -pedantic -Wall -fno-operator-names -std=c++11...

David Ricart committed [r188]

David Ricart — Wed, 30 Aug 2017 18:33:30 -0000

Added flag '-Wno-nonnull-compare' to gcc as well

Bat Guano modified a comment on ticket #11

Bat Guano — Wed, 30 Aug 2017 17:47:22 -0000

Thank you for keeping this up. Even after make clean/distclean and autoreconf, then ./configure, compilation ends with the error when log.c is processed. The Makefile in porg-log contains, though: cat lib/porg-log/Makefile | grep CXXFLAGS CXXFLAGS = -g -O2 MY_CXXFLAGS = -W -ansi -pedantic -Wall -fno-operator-names -std=c++11 -Wno-deprecated-declarations -Wno-nonnull-compare -Werror I do not know... (,a lot of things, apparently and) if the order of individual values has an impact. How are CXXFLAGS...

Bat Guano modified a comment on ticket #11

Bat Guano — Wed, 30 Aug 2017 17:46:56 -0000

Thank you for keeping this up. Even after make distclean/make clean and autoreconf, then ./configure, compilation ends with the error when log.c is processed. The Makefile in porg-log contains, though: cat lib/porg-log/Makefile | grep CXXFLAGS CXXFLAGS = -g -O2 MY_CXXFLAGS = -W -ansi -pedantic -Wall -fno-operator-names -std=c++11 -Wno-deprecated-declarations -Wno-nonnull-compare -Werror I do not know... (,a lot of things, apparently and) if the order of individual values has an impact. How are CXXFLAGS...

Bat Guano posted a comment on ticket #11

Bat Guano — Wed, 30 Aug 2017 17:46:25 -0000

Thank you for keeping this up. Even after make distclean/make clean and autoreconf, compilation ends with the error when log.c is processed. The Makefile in porg-log contains, though: cat lib/porg-log/Makefile | grep CXXFLAGS CXXFLAGS = -g -O2 MY_CXXFLAGS = -W -ansi -pedantic -Wall -fno-operator-names -std=c++11 -Wno-deprecated-declarations -Wno-nonnull-compare -Werror I do not know... (,a lot of things, apparently and) if the order of individual values has an impact. How are CXXFLAGS read, anyway......

David Ricart modified a comment on ticket #11

David Ricart — Wed, 30 Aug 2017 14:31:18 -0000

Did you run 'autoreconf' after updating to revision 187? It is needed to recreate the configure script. The -Werror flag it's enabled only in the development version, to help me fix compilation warnings. But I think I would remove it completely, as it may be annoying to anyone else than me. As of the if (!this), I use it to check for successful creation of a fstream derived object, inside of its own constructor. If you know of a better way to achieve it, I'd be happy to know it. Thanks.

David Ricart posted a comment on ticket #11

David Ricart — Wed, 30 Aug 2017 14:28:54 -0000

Did you run 'autoreconf' after updating to revision 187? It is needed to recreate the configure script. The -Werror flag it's enabled only in the development version, to help me fix compilation warnings. But I think I would remove it completely, as it may be annoying to anyone else than me. As of the if (!this), I use it to check for successful creation of a fstream derived object, inside of its own constructor. I haven't found any better way to achieve that. Thanks.

Bat Guano modified a comment on ticket #11

Bat Guano — Tue, 29 Aug 2017 16:15:21 -0000

The only way I was able to compile revision 187 was by replacing in all the Makefiles in the source-tree -Werror by -Wno-error. Trying to set flags outside the Makefile did apparently not affect each Makefile in the way I needed. And I guess I understand now, why you choose to code if (!this). I have seen precompiler macros used in the same way and would not do it like that, myself. But I understand now.

Bat Guano posted a comment on ticket #11

Bat Guano — Tue, 29 Aug 2017 16:13:16 -0000

Bat Guano modified a comment on ticket #11

Bat Guano — Tue, 29 Aug 2017 12:14:27 -0000

Thanks I saw the ChangeLog before I saw the comment, above. Alas, now it bails out at a different position, so the flag has certainly “done something”. The new error, however, is much less esoteric. Could it be of importance that there are 6 Makefiles in the trunk? log.c: In function ‘open’: log.c:281:20: error: nonnull argument ‘path’ compared to NULL [-Werror=nonnull-compare] if (!porg_tmpfile && path && !strncmp(path, "/proc/", 6)) ~~~~~~~~~~~~~~^~~~~~~ log.c: In function ‘open64’: log.c:385:20:...

Bat Guano posted a comment on ticket #11

Bat Guano — Tue, 29 Aug 2017 12:07:38 -0000

Thanks I saw the ChangeLog before I saw the comment, above. Alas, now it bails out at a different position, so the flag has certainly “done something”. The new error, however, is much less esoteric: log.c: In function ‘open’: log.c:281:20: error: nonnull argument ‘path’ compared to NULL [-Werror=nonnull-compare] if (!porg_tmpfile && path && !strncmp(path, "/proc/", 6)) ~~~~~~~~~~~~~~^~~~~~~ log.c: In function ‘open64’: log.c:385:20: error: nonnull argument ‘path’ compared to NULL [-Werror=nonnull-compare]...

David Ricart committed [r187]

David Ricart — Tue, 29 Aug 2017 11:03:40 -0000

Added flag '-Wno-nonnull-compare' to C++ compiler, to avoid

David Ricart posted a comment on ticket #11

David Ricart — Tue, 29 Aug 2017 10:59:43 -0000

Hi Bat. Try setting the flag '-Wno-nonnull-compare' to the compiler at configure time. Like this: CXXFLAGS='-Wno-nonnull-compare' ./configure --prefix=/usr Also, I'll add it to the configure script, to make it permanent.

Bat Guano posted a comment on ticket #11

Bat Guano — Tue, 29 Aug 2017 05:59:08 -0000

Okay, then. How can I deactivate the compiler option "-Werror=nonnull-compare" when running make? gcc (Debian 7.2.0-1) 7.2.0 libc-2.24

shevy created ticket #13

shevy — Sun, 27 Aug 2017 06:39:58 -0000

grop - minor display problem, widget seems to be too small

shevy posted a comment on ticket #11

shevy — Sat, 26 Aug 2017 15:16:12 -0000

I was able to compile all of porg + the GUI part as well, which runs. I have an up-to-date system though, gcc 7.2.0 and a somewhat ok glibc version.

shevy created ticket #12

shevy — Sat, 26 Aug 2017 15:15:02 -0000

Have grop periodically scan for new updates

Bat Guano posted a comment on ticket #11

Bat Guano — Thu, 20 Jul 2017 08:18:43 -0000

I am sorry for the late response but have been (deliberately) without acces to the Internet for a while. Today I have tried to compile the revision 186 and get new compile errors with g++ (Debian 6.4.0-1) 6.4.0 20170704: In file included from basepkg.h:13:0, from basepkg.cc:10: common.h: In constructor ‘Porg::FileStream::FileStream(const string&) [with T = std::basic_ifstream]’: common.h:43:4: error: nonnull argument ‘this’ compared to NULL [-Werror=nonnull-compare] if (this == NULL) ^~...

David Ricart committed [r186]

David Ricart — Mon, 05 Jun 2017 06:12:14 -0000

Function get_digits(): Return 1 when input number is 0

David Ricart posted a comment on ticket #11

David Ricart — Tue, 17 Jan 2017 15:39:57 -0000

Hi. Thanks for the ticket. The changes made in revision 184 were a "quick and dirty"...

David Ricart committed [r185]

David Ricart — Tue, 17 Jan 2017 15:26:20 -0000

Undone change in r184

Bat Guano created ticket #11

Bat Guano — Sat, 17 Dec 2016 07:26:40 -0000

Compile errors

David Ricart committed [r184]

David Ricart — Wed, 29 Jun 2016 08:59:24 -0000

Added SVN revision number to version of develop...

David Ricart committed [r183]

David Ricart — Mon, 30 May 2016 21:53:59 -0000

grop: ask for confirmation when cancelling porg...

David Ricart committed [r182]

David Ricart — Mon, 30 May 2016 20:42:30 -0000

Removed ChangeLog.paco from the distribution

David Ricart committed [r181]

David Ricart — Mon, 30 May 2016 20:37:31 -0000

Make gzip dist tarballs by default (was xz)

David Ricart committed [r180]

David Ricart — Mon, 30 May 2016 20:31:10 -0000

Removed faq.txt. Improved porg(8) man page

David Ricart committed [r179]

David Ricart — Thu, 19 May 2016 06:39:42 -0000

added sudo to logme-really commands

porg released /ChangeLog

porg — Tue, 17 May 2016 20:05:03 -0000

David Ricart committed [r178]

David Ricart — Tue, 17 May 2016 20:02:39 -0000

back to svn

porg released /porg-0.10.tar.gz

porg — Tue, 17 May 2016 20:00:05 -0000

David Ricart committed [r177]

David Ricart — Tue, 17 May 2016 19:58:30 -0000

Created tag 0.10

David Ricart committed [r176]

David Ricart — Tue, 17 May 2016 19:57:24 -0000

Release of 0.10

David Ricart committed [r175]

David Ricart — Sat, 16 Apr 2016 14:42:29 -0000

Fixed svn related tags in Makefile

porg released /ChangeLog

porg — Sat, 16 Apr 2016 14:17:02 -0000

porg released /porg-0.9.tar.gz

porg — Sat, 16 Apr 2016 14:15:03 -0000

David Ricart committed [r174]

David Ricart — Sat, 16 Apr 2016 14:12:12 -0000

back to svn

David Ricart committed [r173]

David Ricart — Sat, 16 Apr 2016 14:10:38 -0000

Created tag 0.9

David Ricart committed [r172]

David Ricart — Sat, 16 Apr 2016 14:02:16 -0000

VERSION 0.9

David Ricart posted a comment on ticket #10

David Ricart — Wed, 06 Jan 2016 12:10:11 -0000

Thanks for reporting. Have you tried to build the latest SVN version of porg?

shevegen modified a comment on ticket #10

shevegen — Sat, 26 Dec 2015 23:04:51 -0000

The above is quite awful to read - this here is simpler to read: http://pastie.o...

shevegen posted a comment on ticket #10

shevegen — Sat, 26 Dec 2015 23:04:40 -0000

The aove is quite awful to read - this here is simpler to read: http://pastie.or...

shevegen created ticket #10

shevegen — Sat, 26 Dec 2015 23:03:44 -0000

Some problem with latest porg 0.8 and glibmm

David Ricart posted a comment on ticket #8

David Ricart — Sun, 06 Dec 2015 05:54:11 -0000

Great! Thanks for packaging porg.

TIM posted a comment on ticket #8

TIM — Sat, 05 Dec 2015 21:39:44 -0000

Nice catch, manually compiling the code seems to work. (yaaa ) Seems like I didn't...

David Ricart posted a comment on ticket #8

David Ricart — Sat, 05 Dec 2015 21:11:18 -0000

BTW Can you compile porg-0.8 "by hand" in the same system? I mean, without all the...

David Ricart posted a comment on discussion General Discussion

David Ricart — Sat, 05 Dec 2015 21:01:06 -0000

FIXED in SVN. Thanks.

David Ricart committed [r171]

David Ricart — Sat, 05 Dec 2015 21:00:46 -0000

grop: fixed porgball hang bug

TIM posted a comment on ticket #8

TIM — Sat, 05 Dec 2015 20:51:28 -0000

Still no go, (I have included the build log).

David Ricart committed [r170]

David Ricart — Sat, 05 Dec 2015 06:25:07 -0000

Added cxxflags to fix compilation errors with l...

David Ricart posted a comment on ticket #8

David Ricart — Sat, 05 Dec 2015 06:08:18 -0000

Please forget about my previous message, and apply the attached patch instead.

TIM created ticket #9

TIM — Fri, 04 Dec 2015 11:27:03 -0000

spec file to build porg on fedora

TIM posted a comment on ticket #8

TIM — Fri, 04 Dec 2015 11:20:35 -0000

I have added the obove options to the spec file, like this %configure CXXFLAGS="-Wno-deprecated-declarations...

David Ricart posted a comment on ticket #8

David Ricart — Fri, 04 Dec 2015 07:37:21 -0000

Please, try again adding "-Wno-deprecated-declarations -Wno-variadic-macros" to CXXFLAGS...

TIM posted a comment on ticket #4

TIM — Thu, 03 Dec 2015 23:52:35 -0000

This one works for me.

TIM posted a comment on ticket #8

TIM — Thu, 03 Dec 2015 23:51:35 -0000

$ pkg-config --modversion glibmm-2.4 gtkmm-3.0 2.46.2 3.18.0 compiling with --disable-grop...

David Ricart posted a comment on ticket #8

David Ricart — Thu, 03 Dec 2015 17:42:49 -0000

Hi Tim. Thanks for reporting. It seems like the errors come from glibmm code. Would...

TIM created ticket #8

TIM — Wed, 02 Dec 2015 12:15:38 -0000

Can't compile under Fedora 23.

David Ricart posted a comment on discussion General Discussion

David Ricart — Tue, 03 Nov 2015 17:12:01 -0000

Hi. Running "autoreconf --force --install --symlink" from the sources directory should...

Bat Guano posted a comment on discussion General Discussion

Bat Guano — Tue, 03 Nov 2015 11:30:09 -0000

Current SVN-Version (3/11/2015) porg-svn (25 September 2015). An attempt to create...

Bat Guano modified a comment on discussion General Discussion

Bat Guano — Tue, 03 Nov 2015 11:21:14 -0000

Disregard, as the changes to the build-system have been noted. Even by myself, now....

Bat Guano modified a comment on discussion General Discussion

Bat Guano — Fri, 25 Sep 2015 07:52:03 -0000

Hi, being confronted for the first time to libtoolize, I had not immediately been...

Bat Guano modified a comment on discussion General Discussion

Bat Guano — Fri, 25 Sep 2015 07:51:15 -0000

Hi, being confronted for the first time to libtoolize, I had not immediately been...

Bat Guano modified a comment on discussion General Discussion

Bat Guano — Fri, 25 Sep 2015 07:50:39 -0000

Hi, being confronted for the first time to libtoolize, I had not immediately been...

Bat Guano posted a comment on discussion General Discussion

Bat Guano — Fri, 25 Sep 2015 07:50:17 -0000

Hi, being confronted for the first time with libtoolize, I had not immediately been...

David Ricart committed [r169]

David Ricart — Wed, 16 Sep 2015 04:55:14 -0000

document the case-insensitiveness of variable n...

David Ricart committed [r168]

David Ricart — Wed, 16 Sep 2015 04:35:13 -0000

changed g++ flags

David Ricart posted a comment on ticket #7

David Ricart — Thu, 10 Sep 2015 10:20:55 -0000

Fixed in SVN. Hope it compiles fine on OSX. Thanks.

David Ricart committed [r167]

David Ricart — Thu, 10 Sep 2015 10:15:21 -0000

Replace mode_t by int when calling va_arg() so ...

Tomoaki Nishiyama posted a comment on ticket #7

Tomoaki Nishiyama — Thu, 10 Sep 2015 07:45:18 -0000

Since the diff doesn't look nice on the board, the file is attached. By the way,...

Tomoaki Nishiyama created ticket #7

Tomoaki Nishiyama — Thu, 10 Sep 2015 07:41:59 -0000

mode_t size incompatibility on OS X 10.6

David Ricart committed [r166]

David Ricart — Thu, 27 Aug 2015 19:38:33 -0000

libporg-log: explicitly #define RTLD_NEXT for s...

David Ricart committed [r165]

David Ricart — Wed, 26 Aug 2015 21:38:45 -0000

removed spurious comment

David Ricart committed [r164]

David Ricart — Sun, 23 Aug 2015 05:17:07 -0000

cleanup

David Ricart committed [r163]

David Ricart — Sun, 23 Aug 2015 05:10:06 -0000

Added #include