Activity for porg
-
Ookaze posted a comment on ticket #17
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
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
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
Back on duty
-
Jean-Michel Pollion posted a comment on ticket #16
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.
-
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.
-
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...
-
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.
-
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...
-
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...
-
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...
-
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.
-
build error (stringop-truncation)
-
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
porg does not handle mv event
-
Matsuand created ticket #14
Handling local ".porgrc" file
-
Great. Thanks for helping.
-
Bat Guano posted a comment on ticket #11
Compiles out of the box (:wq)
-
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.
-
Added break statement on switch, to fix compilation errors
-
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...
-
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...
-
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...
-
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...
-
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.
-
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...
-
Added flag '-Wno-nonnull-compare' to gcc as well
-
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...
-
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...
-
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......
-
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.
-
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.
-
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.
-
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.
-
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:...
-
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]...
-
Added flag '-Wno-nonnull-compare' to C++ compiler, to avoid
-
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.
-
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
grop - minor display problem, widget seems to be too small
-
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.
-
Have grop periodically scan for new updates
-
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<T>::FileStream(const string&) [with T = std::basic_ifstream<char>]’: common.h:43:4: error: nonnull argument ‘this’ compared to NULL [-Werror=nonnull-compare] if (this == NULL) ^~...
-
Function get_digits(): Return 1 when input number is 0
-
Hi. Thanks for the ticket. The changes made in revision 184 were a "quick and dirty"...
-
Undone change in r184
-
Compile errors
-
Added SVN revision number to version of develop...
-
grop: ask for confirmation when cancelling porg...
-
Removed ChangeLog.paco from the distribution
-
Make gzip dist tarballs by default (was xz)
-
Removed faq.txt. Improved porg(8) man page
-
added sudo to logme-really commands
-
porg released /ChangeLog
-
back to svn
-
-
Created tag 0.10
-
Release of 0.10
-
Fixed svn related tags in Makefile
-
-
-
back to svn
-
Created tag 0.9
-
VERSION 0.9
-
Thanks for reporting. Have you tried to build the latest SVN version of porg?
-
The above is quite awful to read - this here is simpler to read: http://pastie.o...
-
The aove is quite awful to read - this here is simpler to read: http://pastie.or...
-
Some problem with latest porg 0.8 and glibmm
-
Great! Thanks for packaging porg.
-
TIM posted a comment on ticket #8
Nice catch, manually compiling the code seems to work. (yaaa ) Seems like I didn't...
-
BTW Can you compile porg-0.8 "by hand" in the same system? I mean, without all the...
-
FIXED in SVN. Thanks.
-
grop: fixed porgball hang bug
-
Still no go, (I have included the build log).
-
Added cxxflags to fix compilation errors with l...
-
Please forget about my previous message, and apply the attached patch instead.
-
spec file to build porg on fedora
-
I have added the obove options to the spec file, like this %configure CXXFLAGS="-Wno-deprecated-declarations...
-
Please, try again adding "-Wno-deprecated-declarations -Wno-variadic-macros" to CXXFLAGS...
-
This one works for me.
-
$ pkg-config --modversion glibmm-2.4 gtkmm-3.0 2.46.2 3.18.0 compiling with --disable-grop...
-
Hi Tim. Thanks for reporting. It seems like the errors come from glibmm code. Would...
-
Can't compile under Fedora 23.
-
Hi. Running "autoreconf --force --install --symlink" from the sources directory should...
-
Current SVN-Version (3/11/2015) porg-svn (25 September 2015). An attempt to create...
-
Disregard, as the changes to the build-system have been noted. Even by myself, now....
-
Hi, being confronted for the first time to libtoolize, I had not immediately been...
-
Hi, being confronted for the first time to libtoolize, I had not immediately been...
-
Hi, being confronted for the first time to libtoolize, I had not immediately been...
-
Hi, being confronted for the first time with libtoolize, I had not immediately been...
-
document the case-insensitiveness of variable n...
-
changed g++ flags
-
Fixed in SVN. Hope it compiles fine on OSX. Thanks.
-
Replace mode_t by int when calling va_arg() so ...
-
Tomoaki Nishiyama posted a comment on ticket #7
Since the diff doesn't look nice on the board, the file is attached. By the way,...
-
mode_t size incompatibility on OS X 10.6
-
libporg-log: explicitly #define RTLD_NEXT for s...
-
removed spurious comment
-
cleanup
-
Added #include <csignal>
1 >
