Re: [rsyslog] unit tests: linking problem - help requested
I spent an hour looking at this today. This: gcc -std=gnu99 -g3 -ggdb -export-dynamic -o rt_init ../tools/rsyslogd-smtradfile.o ../tools/rsyslogd-pidfile.o ../tools/rsyslogd-iminternal.o ../tools/rsyslogd-omfile.o ../tools/rsyslogd-pmrfc3164.o ../tools/rsyslogd-omfwd.o ../tools/rsyslogd-omshell.o ../tools/rsyslogd-omdiscard.o ../tools/rsyslogd-syslogd.o ../tools/rsyslogd-smfwd.o ../tools/rsyslogd-smfile.o ../tools/rsyslogd-omusrmsg.o ../tools/rsyslogd-smtradfwd.o ../tools/rsyslogd-ompipe.o ../tools/rsyslogd-pmrfc5424.o rt_init-rt-init.o rt_init-runtime-dummy.o -lz -lpthread -L../grammar/.libs -lgrammar -L/home/janmejay/projects/flipkart/rsyslog/liblogging/../install.dir/lib -llogging-stdlog -L../runtime/.libs -lrsyslog -L/home/janmejay/projects/flipkart/rsyslog/install.dir/lib -lestr -ljson-c -luuid -L../runtime/.libs -lrsyslog -L../grammar/.libs -lgrammar -ldl run from tests dir, seems to do fine except for symbols defined in tools/rsyslogd.c. I basically took what make was running, and started running it myself directly using gcc to decrease the time required to test my changes (modifying automake file and running was too long for quickly iterating on this). But the basic change I did was reorderd to bring rsyslog and grammer to the end. At that point it wanted functions such as modInitFile, modInitPipe etc, which were defined by various files in tools dir. So I just picked up all *.o files except rsyslogd-rsyslogd.o (which has another main, which messes up the linker. Also added -ldl for dl* functions. Now rsyslogd-syslogd.o wants symbols like forkRsyslog, which are defined in rsyslogd.c, so we basically need to separate main (and other functions that only main will want) out to a separate file, so we can make syslogd.o happy. On Mon, Nov 3, 2014 at 2:38 PM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: Hi all, after the discussion on unit tests I tried to add some. Some years ago, we had a very small set of unit tests. These (two actually) were really almost nothing, BUT a skeleton to build better ones. And this skeleton I wanted to use, as it covers the initialization of the runtime (test rt_init). Unfortunately, I don't get them even to link. IIRC, that was also the reason why they were removed from the testbench some time ago. I've tried for several hours now and googled a lot, but I can't find a solution to make them build. So any help would be appreciated. The code is available in branch https://github.com/rsyslog/rsyslog/tree/master-unittests When I try to build the rt_init test, I get this: rger@ubuntu1404esp:~/proj/rsyslog/tests$ make rt_init CCLD rt_init /usr/bin/ld: ../runtime/.libs/librsyslog.a(librsyslog_la-msg.o): undefined reference to symbol 'pthread_rwlock_wrlock@@GLIBC_2.2.5' /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make: *** [rt_init] Error 1 After what I could find out, this seems to be related to the order of -lpthread in the linker options. That's because the gnu linker is order-dependent. In theory, this should be fixable by moving -lpthread to the end of the linker libs. If I do that, I get a myriad of unresolved externals for the rsyslog runtime library. I than begun putting libs in different orders in the linker call, but I always get one error or the other. The interesting thing is that rsyslogd itself builds **successfully** with the **same** linker options in the **same** order. I even tried to move rt_init out of the tests directory into tools, where syslogd resides, and add rt_init to that Makefile. Again, rsyslogd builds, but rt_init fails. Quite honestly, I don't have any more idea. And the bad thing is that if I can't get rt_init to build, I probably cannot write any unit test at all (because most, especially those that do notable work, require the rsyslog runtime to be initialized). Help with this problem would be deeply appreciated. Again, it's a blocker for any unit test. Thanks, Rainer ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. -- Regards, Janmejay http://codehunk.wordpress.com ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: [rsyslog] unit tests: linking problem - help requested
2014-11-07 10:51 GMT+01:00 singh.janmejay singh.janme...@gmail.com: I spent an hour looking at this today. This: gcc -std=gnu99 -g3 -ggdb -export-dynamic -o rt_init ../tools/rsyslogd-smtradfile.o ../tools/rsyslogd-pidfile.o ../tools/rsyslogd-iminternal.o ../tools/rsyslogd-omfile.o ../tools/rsyslogd-pmrfc3164.o ../tools/rsyslogd-omfwd.o ../tools/rsyslogd-omshell.o ../tools/rsyslogd-omdiscard.o ../tools/rsyslogd-syslogd.o ../tools/rsyslogd-smfwd.o ../tools/rsyslogd-smfile.o ../tools/rsyslogd-omusrmsg.o ../tools/rsyslogd-smtradfwd.o ../tools/rsyslogd-ompipe.o ../tools/rsyslogd-pmrfc5424.o rt_init-rt-init.o rt_init-runtime-dummy.o -lz -lpthread -L../grammar/.libs -lgrammar -L/home/janmejay/projects/flipkart/rsyslog/liblogging/../install.dir/lib -llogging-stdlog -L../runtime/.libs -lrsyslog -L/home/janmejay/projects/flipkart/rsyslog/install.dir/lib -lestr -ljson-c -luuid -L../runtime/.libs -lrsyslog -L../grammar/.libs -lgrammar -ldl run from tests dir, seems to do fine except for symbols defined in tools/rsyslogd.c. I basically took what make was running, and started running it myself directly using gcc to decrease the time required to test my changes (modifying automake file and running was too long for quickly iterating on this). thanks But the basic change I did was reorderd to bring rsyslog and grammer to the end. At that point it wanted functions such as modInitFile, modInitPipe etc, which were defined by various files in tools dir. So I just picked up all *.o files except rsyslogd-rsyslogd.o (which has another main, which messes up the linker. Also added -ldl for dl* functions. do you have any idea how I can do this in autoconf so that I can integrate it into the build system? Rainer Now rsyslogd-syslogd.o wants symbols like forkRsyslog, which are defined in rsyslogd.c, so we basically need to separate main (and other functions that only main will want) out to a separate file, so we can make syslogd.o happy. On Mon, Nov 3, 2014 at 2:38 PM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: Hi all, after the discussion on unit tests I tried to add some. Some years ago, we had a very small set of unit tests. These (two actually) were really almost nothing, BUT a skeleton to build better ones. And this skeleton I wanted to use, as it covers the initialization of the runtime (test rt_init). Unfortunately, I don't get them even to link. IIRC, that was also the reason why they were removed from the testbench some time ago. I've tried for several hours now and googled a lot, but I can't find a solution to make them build. So any help would be appreciated. The code is available in branch https://github.com/rsyslog/rsyslog/tree/master-unittests When I try to build the rt_init test, I get this: rger@ubuntu1404esp:~/proj/rsyslog/tests$ make rt_init CCLD rt_init /usr/bin/ld: ../runtime/.libs/librsyslog.a(librsyslog_la-msg.o): undefined reference to symbol 'pthread_rwlock_wrlock@@GLIBC_2.2.5' /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make: *** [rt_init] Error 1 After what I could find out, this seems to be related to the order of -lpthread in the linker options. That's because the gnu linker is order-dependent. In theory, this should be fixable by moving -lpthread to the end of the linker libs. If I do that, I get a myriad of unresolved externals for the rsyslog runtime library. I than begun putting libs in different orders in the linker call, but I always get one error or the other. The interesting thing is that rsyslogd itself builds **successfully** with the **same** linker options in the **same** order. I even tried to move rt_init out of the tests directory into tools, where syslogd resides, and add rt_init to that Makefile. Again, rsyslogd builds, but rt_init fails. Quite honestly, I don't have any more idea. And the bad thing is that if I can't get rt_init to build, I probably cannot write any unit test at all (because most, especially those that do notable work, require the rsyslog runtime to be initialized). Help with this problem would be deeply appreciated. Again, it's a blocker for any unit test. Thanks, Rainer ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. -- Regards, Janmejay http://codehunk.wordpress.com ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog?
[rsyslog] can someone lend me a hand on git procedure
Hi all, based on recent discussion ([1] is a good entry point), it looks like there is consensus that feature-branch commits shall be squashed before merging them into master. This is a bit bad for me because in almost all cases I like the ability to see the interim steps that lead to a feature in question (for bisect, but also to better understand what was going on). I have also discussed this with my peers in Adiscon and they also prefer the way it currently is. To satisfy both requirements, we have now setup an internal git for Adiscon use. Our plan is to have a parallel adiscon-master branch inside that repo, which will contain every detail. Its master branch will mirror the public git and contain squashed commits. We now have contributions from Adiscon (including me) and others. Those from Adiscon will be done in feature branches, with detail commits and be merged into the adiscon-master branch (so that it contains all details). Then, I will squash the feature branch into a single commit and merge that into master. So far, so good. But now we also have non-Adiscon contributions. A current example is [2]. One question is if they must be squashed as well? Let's assume this is not the case for whatever reason. So I merge them directly into master. Then, to keep my actual working tree up to date, I need to cherry-pick them into adiscon-master. This is where I am a bit hesitant, because of the manual action. I fear that the master and adiscon-master branches may begin to diverge, and be it through a simple mistake. So maybe it is better to merge pull requests into new feature branches, and then work as usual: merge feature branch into adiscon-master, squash feature branch, then merge it as single commit into master. To sum up: I would like to have two branches, the private one with all detail information, the public one minus those commits that are considered distracting. What is the best way to achieve this goal? Feedback appreciated, Rainer [1] http://lists.adiscon.net/pipermail/rsyslog/2014-November/038883.html [2] https://github.com/rsyslog/rsyslog/pull/147 ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: [rsyslog] can someone lend me a hand on git procedure
Rainer, Do we really need to squash? Why not just keep it simple and merge changes as they come? Its so much better for looking at exactly how/why things are the way they are. No rebase, no rewrites of history etc, just the simple commit and merge. -- Regards, Janmejay PS: Please blame the typos in this mail on my phone's uncivilized soft keyboard sporting it's not-so-smart-assist technology. On Nov 7, 2014 4:57 PM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: Hi all, based on recent discussion ([1] is a good entry point), it looks like there is consensus that feature-branch commits shall be squashed before merging them into master. This is a bit bad for me because in almost all cases I like the ability to see the interim steps that lead to a feature in question (for bisect, but also to better understand what was going on). I have also discussed this with my peers in Adiscon and they also prefer the way it currently is. To satisfy both requirements, we have now setup an internal git for Adiscon use. Our plan is to have a parallel adiscon-master branch inside that repo, which will contain every detail. Its master branch will mirror the public git and contain squashed commits. We now have contributions from Adiscon (including me) and others. Those from Adiscon will be done in feature branches, with detail commits and be merged into the adiscon-master branch (so that it contains all details). Then, I will squash the feature branch into a single commit and merge that into master. So far, so good. But now we also have non-Adiscon contributions. A current example is [2]. One question is if they must be squashed as well? Let's assume this is not the case for whatever reason. So I merge them directly into master. Then, to keep my actual working tree up to date, I need to cherry-pick them into adiscon-master. This is where I am a bit hesitant, because of the manual action. I fear that the master and adiscon-master branches may begin to diverge, and be it through a simple mistake. So maybe it is better to merge pull requests into new feature branches, and then work as usual: merge feature branch into adiscon-master, squash feature branch, then merge it as single commit into master. To sum up: I would like to have two branches, the private one with all detail information, the public one minus those commits that are considered distracting. What is the best way to achieve this goal? Feedback appreciated, Rainer [1] http://lists.adiscon.net/pipermail/rsyslog/2014-November/038883.html [2] https://github.com/rsyslog/rsyslog/pull/147 ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: [rsyslog] can someone lend me a hand on git procedure
2014-11-07 12:35 GMT+01:00 singh.janmejay singh.janme...@gmail.com: Rainer, Do we really need to squash? Why not just keep it simple and merge changes as they come? Its so much better for looking at exactly how/why things are the way they are. No rebase, no rewrites of history etc, just the simple commit and merge. well, I don't need all of that overhead. But from the other thread it looked like folks wanted it and nobody said anything else... Rainer -- Regards, Janmejay PS: Please blame the typos in this mail on my phone's uncivilized soft keyboard sporting it's not-so-smart-assist technology. On Nov 7, 2014 4:57 PM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: Hi all, based on recent discussion ([1] is a good entry point), it looks like there is consensus that feature-branch commits shall be squashed before merging them into master. This is a bit bad for me because in almost all cases I like the ability to see the interim steps that lead to a feature in question (for bisect, but also to better understand what was going on). I have also discussed this with my peers in Adiscon and they also prefer the way it currently is. To satisfy both requirements, we have now setup an internal git for Adiscon use. Our plan is to have a parallel adiscon-master branch inside that repo, which will contain every detail. Its master branch will mirror the public git and contain squashed commits. We now have contributions from Adiscon (including me) and others. Those from Adiscon will be done in feature branches, with detail commits and be merged into the adiscon-master branch (so that it contains all details). Then, I will squash the feature branch into a single commit and merge that into master. So far, so good. But now we also have non-Adiscon contributions. A current example is [2]. One question is if they must be squashed as well? Let's assume this is not the case for whatever reason. So I merge them directly into master. Then, to keep my actual working tree up to date, I need to cherry-pick them into adiscon-master. This is where I am a bit hesitant, because of the manual action. I fear that the master and adiscon-master branches may begin to diverge, and be it through a simple mistake. So maybe it is better to merge pull requests into new feature branches, and then work as usual: merge feature branch into adiscon-master, squash feature branch, then merge it as single commit into master. To sum up: I would like to have two branches, the private one with all detail information, the public one minus those commits that are considered distracting. What is the best way to achieve this goal? Feedback appreciated, Rainer [1] http://lists.adiscon.net/pipermail/rsyslog/2014-November/038883.html [2] https://github.com/rsyslog/rsyslog/pull/147 ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: [rsyslog] Feedback Request: do we still need -devel versions?
I don't think squashing is a good idea. Feature branches are good for keeping half baked work away from release ready branch. But feature-branch + merge is good enough for that. History is kept for a reason, disturbing it, even within a feature kills detailed information about why things are the way they are. Atleast personally, I never felt any pain because of merge commits. I find it all the more useful because it gives out exactly how commits were formed, what has been tried, what bugs have been fixed, which patch broke something etc. Can we please keep the tree as is? -- Regards, Janmejay PS: Please blame the typos in this mail on my phone's uncivilized soft keyboard sporting it's not-so-smart-assist technology. On Nov 7, 2014 3:05 AM, Michael Biebl mbi...@gmail.com wrote: 2014-11-06 14:02 GMT+01:00 Thomas D. whi...@whissi.de: What's my problem: Reading a commit log like - Merge branch 'v8-stable' - Merge branch 'v8-stable' - Merge branch 'v7-stable' into v8-stable - Merge branch 'v8-stable' - Merge branch 'v8-stable' - Merge branch 'v8-stable' - Merge branch 'master' of https://github.com/rsyslog/rsyslog - Merge branch 'v8-stable' - Merge branch 'v8-stable' - Merge branch 'v7-stable' - Merge branch 'v8-stable' is not very helpful. Nobody understands what's going on. Wouldn't git log --no-merges solve your problem? ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: [rsyslog] can someone lend me a hand on git procedure
I'm in favor of the process being as simple as possible. The more work and thought that has to be put into dealing with pull requests, the more likely either work will get slowed down, or someone will make a mistake. I feel like if I want to squash, etc I can just do that on branches on my own fork, and then send the cleaned up version back to you. I don't feel like you should have to deal with squashing my commits. I also don't have a problem personally with seeing the merge messages. On Fri, Nov 7, 2014 at 6:39 AM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: 2014-11-07 12:35 GMT+01:00 singh.janmejay singh.janme...@gmail.com: Rainer, Do we really need to squash? Why not just keep it simple and merge changes as they come? Its so much better for looking at exactly how/why things are the way they are. No rebase, no rewrites of history etc, just the simple commit and merge. well, I don't need all of that overhead. But from the other thread it looked like folks wanted it and nobody said anything else... Rainer -- Regards, Janmejay PS: Please blame the typos in this mail on my phone's uncivilized soft keyboard sporting it's not-so-smart-assist technology. On Nov 7, 2014 4:57 PM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: Hi all, based on recent discussion ([1] is a good entry point), it looks like there is consensus that feature-branch commits shall be squashed before merging them into master. This is a bit bad for me because in almost all cases I like the ability to see the interim steps that lead to a feature in question (for bisect, but also to better understand what was going on). I have also discussed this with my peers in Adiscon and they also prefer the way it currently is. To satisfy both requirements, we have now setup an internal git for Adiscon use. Our plan is to have a parallel adiscon-master branch inside that repo, which will contain every detail. Its master branch will mirror the public git and contain squashed commits. We now have contributions from Adiscon (including me) and others. Those from Adiscon will be done in feature branches, with detail commits and be merged into the adiscon-master branch (so that it contains all details). Then, I will squash the feature branch into a single commit and merge that into master. So far, so good. But now we also have non-Adiscon contributions. A current example is [2]. One question is if they must be squashed as well? Let's assume this is not the case for whatever reason. So I merge them directly into master. Then, to keep my actual working tree up to date, I need to cherry-pick them into adiscon-master. This is where I am a bit hesitant, because of the manual action. I fear that the master and adiscon-master branches may begin to diverge, and be it through a simple mistake. So maybe it is better to merge pull requests into new feature branches, and then work as usual: merge feature branch into adiscon-master, squash feature branch, then merge it as single commit into master. To sum up: I would like to have two branches, the private one with all detail information, the public one minus those commits that are considered distracting. What is the best way to achieve this goal? Feedback appreciated, Rainer [1] http://lists.adiscon.net/pipermail/rsyslog/2014-November/038883.html [2] https://github.com/rsyslog/rsyslog/pull/147 ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE
Re: [rsyslog] can someone lend me a hand on git procedure
On 2014-11-07 12:21, Brian Knox wrote: I'm in favor of the process being as simple as possible. indeed I feel like if I want to squash, etc I can just do that on branches on my own fork, and then send the cleaned up version back to you. I don't feel like you should have to deal with squashing my commits. +1 to that :) ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: [rsyslog] can someone lend me a hand on git procedure
On 11/07/14 12:27, Rainer Gerhards wrote: Hi all, Hello Rainer, based on recent discussion ([1] is a good entry point), it looks like there is consensus that feature-branch commits shall be squashed before merging them into master. Before implementing such a change, please give it some more time for people to comment and think it through. This is a big change and shouldn't be rushed. This is a bit bad for me because in almost all cases I like the ability to see the interim steps that lead to a feature in question (for bisect, but also to better understand what was going on). I have also discussed this with my peers in Adiscon and they also prefer the way it currently is. I think it's better to have changes split up into smaller cohesive chunks (that also don't break compilation, functionality, are well documented in the commit message and are generally tidied up). Having the history more granular helps understanding why what happened where - I personally do that _a lot_. Squashing makes for tidier history but also obfuscates it. Having smaller commits makes reverting changes easier. That said, I also do a lot of git-blame-ing and getting through the thick graph of merges isn't fun either. To satisfy both requirements, we have now setup an internal git for Adiscon use. Our plan is to have a parallel adiscon-master branch inside that repo, which will contain every detail. Its master branch will mirror the public git and contain squashed commits. Please don't. :] Having multiple branches with the same content but different histories would bring confusion; directly or indirectly. We now have contributions from Adiscon (including me) and others. Those from Adiscon will be done in feature branches, with detail commits and be merged into the adiscon-master branch (so that it contains all details). Then, I will squash the feature branch into a single commit and merge that into master. So far, so good. But now we also have non-Adiscon contributions. A current example is [2]. One question is if they must be squashed as well? As Brian similarly noted in a previous email, I don't think it's a good idea to squash on the receiving side. I edit and rebase commits all the time before submitting them for inclusion. If I've dissected the change into couple of patches, It's because I think there's a reason for it. If we'll decide to make it a policy to squash everything before inclusion, I'll send a single patch - no need for upstream to do that. I have this luxury of rewriting my changes because I work in a private branch. Since you push your changes early and often, rebasing (editing, squashing) might be problematic - unless it is made a policy that there are no guaranties about what happens in a feature branch. Tomas ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: [rsyslog] can someone lend me a hand on git procedure
2014-11-07 15:55 GMT+01:00 Tomas Heinrich thein...@redhat.com: On 11/07/14 12:27, Rainer Gerhards wrote: Hi all, Hello Rainer, based on recent discussion ([1] is a good entry point), it looks like there is consensus that feature-branch commits shall be squashed before merging them into master. Before implementing such a change, please give it some more time for people to comment and think it through. This is a big change and shouldn't be rushed. Thanks. I had the (obviously wrong) idea that no voices meant people were happy with it -- especially as that other thread received a lot of comments initially. But probably most folks got bored when it got longer and longer (understandable now that I think about it), so this probably didn't mean many are fine with the direction. My bad not to think about this. I'll post another pending policy change from that thread (not yet finalized), but I'll do that with a fresh posting so that it doesn't get buried in this thread ;) This is a bit bad for me because in almost all cases I like the ability to see the interim steps that lead to a feature in question (for bisect, but also to better understand what was going on). I have also discussed this with my peers in Adiscon and they also prefer the way it currently is. I think it's better to have changes split up into smaller cohesive chunks (that also don't break compilation, functionality, are well documented in the commit message and are generally tidied up). Having the history more granular helps understanding why what happened where - I personally do that _a lot_. Squashing makes for tidier history but also obfuscates it. That's my prime concern. Having smaller commits makes reverting changes easier. That said, I also do a lot of git-blame-ing and getting through the thick graph of merges isn't fun either. more on that in the upcoming thread (not necessarily today, have some appointments soon). To satisfy both requirements, we have now setup an internal git for Adiscon use. Our plan is to have a parallel adiscon-master branch inside that repo, which will contain every detail. Its master branch will mirror the public git and contain squashed commits. Please don't. :] Having multiple branches with the same content but different histories would bring confusion; directly or indirectly. We now have contributions from Adiscon (including me) and others. Those from Adiscon will be done in feature branches, with detail commits and be merged into the adiscon-master branch (so that it contains all details). Then, I will squash the feature branch into a single commit and merge that into master. So far, so good. But now we also have non-Adiscon contributions. A current example is [2]. One question is if they must be squashed as well? As Brian similarly noted in a previous email, I don't think it's a good idea to squash on the receiving side. I edit and rebase commits all the time before submitting them for inclusion. If I've dissected the change into couple of patches, It's because I think there's a reason for it. If we'll decide to make it a policy to squash everything before inclusion, I'll send a single patch - no need for upstream to do that. Yeah, that was along the lines that we used successfully for many years. I appreciate that extra information as it helps me understand what's going on (thus at least I don't wanted to loose it). From that other thread, I got the strong impression that features requiring more than one commit are no longer preferred. I have this luxury of rewriting my changes because I work in a private branch. Since you push your changes early and often, rebasing (editing, squashing) might be problematic - unless it is made a policy that there are no guaranties about what happens in a feature branch. Well, I now also have the Adiscon private repository and e.g. the testbench changes are now only in there (it was my testbed to see which problems come up with that approach). But I've already seen how this affects my workflow, as I am no longer able to point people to the code as it develops (there was a concrete case yesterday with a broken testbench test). So far, I tried to do everything in public and not be ashamed of the sometimes dumb errors I made and that manifest in git history. I admit that I make trivial changes directly to master and every now and then (seldom, but happend), I screwed up and got master to fail building. Not sure, though, if that would have been any better if I create a new branch, apply change, merge new branch, delete it - all within 5 minutes. This sounds a little bit overboard to me. From what I got in this thread it looks like more people are in favor of granular commits than the fat ones. I am still listening to voices, but giving the current state, I won't change the way I do commits. Rainer ___ rsyslog mailing list
[rsyslog] potential policy change: fixes for unsupported versions
Hi, just to bring out another potential policy change to the full bright light: There was discussion that in order to tidy up commit log, I should no longer merge up branches. As I don't have the time to do manually what currently git does for me, this means I will stop providing fixes for versions other than the currently supported one (8.4.2 at the moment). When I discussed this in Adiscon internally, we saw quite some advantage for us as well: if the unsupported versions are really unsupported, people hopefully would be more likely to update to the current versions. Also, it means a bit of less work for me, which frees up a little bit of resources. I honestly do not know how many folks at all really depend on e.g. v7-stable. My impression is that many, if not most, distros tend to base on a then-current version and apply patches to this baseline. So my question is: do we need to keep fixing the old stuff ... or can we really abandon that? Feedback is highly appreciated. Thanks, Rainer ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
[rsyslog] Using TLS to send remote logs on v7
Hello, I'm attempting to get remote logging using TLS to work on my RHEL 6.6 systems using the new rsyslog7 packages. Currently, I can't seem to get the client to send it's logs encrypted. This is probably just an error in my rsyslog.conf file, but I also tried installing rsyslog 8.4.2 on the client and everything works fine. Also note that these are the same certificates that were being used when doing remote TLS logging using rsyslog v5 so I don't think it's a certificate problem. Below is my client config file. Does anyone see any syntax problems with why this would work on v8 but not v7. # rsyslog v7 configuration file (client) GLOBAL DIRECTIVES $umask # Use default timestamp format $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # Include all config files in /etc/rsyslog.d/ $IncludeConfig /etc/rsyslog.d/*.conf # Working directory for spooling and file monitoring $WorkDirectory /var/lib/rsyslog # Create files with proper permissions $FileCreateMode 0600 # Set the message size to 32k (up from 2k default) $MaxMessageSize 32768 MODULES module( load=imuxsock ) # provides support for local system logging (e.g. via logger command) module( load=imklog ) # provides kernel logging support (previously done by rklogd) NETSTREAM DRIVER # Use gtls for ssl, ptcp for non ssl $DefaultNetstreamDriver gtls $DefaultNetstreamDriverCAFile /etc/pki/rsyslog/trust.pem $DefaultNetstreamDriverCertFile /etc/pki/rsyslog/cert.pem $DefaultNetstreamDriverKeyFile /etc/pki/rsyslog/key.pem RULES # All info and Auditd messages *.info;local0.* action( template=RSYSLOG_SyslogProtocol23Format name=localfwd type=omfwd action.resumeRetryCount=-1 target=172.16.0.201 port=10514 protocol=tcp TCP_Framing=octet-counted queue.filename=localfwd queue.size=100 queue.type=Disk queue.saveonshutdown=on StreamDriver=gtls StreamDriverMode=1 StreamDriverAuthMode=x509/certvalid ) # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;local0.none;mail.none;authpriv.none;cron.none action(type=omfile file=/var/log/messages) # The authpriv file has restricted access. authpriv.* action(type=omfile file=/var/log/secure) # Log all the mail messages in one place. mail.* action(type=omfile file=/var/log/maillog) # Log cron stuff cron.* action(type=omfile file=/var/log/cron) # Everybody gets emergency messages *.emerg;local0.none action(type=omusrmsg users=*) # Save news errors of level crit and higher in a special file. uucp,news.crit action(type=omfile file=/var/log/spooler) # Save boot messages also to boot.log local7.* action(type=omfile file=/var/log/boot.log) Thanks, Andrew Ruch ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: [rsyslog] can someone lend me a hand on git procedure
I feel the same way, feature branches should not be squashed. David Lang On Fri, 7 Nov 2014, singh.janmejay wrote: Rainer, Do we really need to squash? Why not just keep it simple and merge changes as they come? Its so much better for looking at exactly how/why things are the way they are. No rebase, no rewrites of history etc, just the simple commit and merge. -- Regards, Janmejay PS: Please blame the typos in this mail on my phone's uncivilized soft keyboard sporting it's not-so-smart-assist technology. On Nov 7, 2014 4:57 PM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: Hi all, based on recent discussion ([1] is a good entry point), it looks like there is consensus that feature-branch commits shall be squashed before merging them into master. This is a bit bad for me because in almost all cases I like the ability to see the interim steps that lead to a feature in question (for bisect, but also to better understand what was going on). I have also discussed this with my peers in Adiscon and they also prefer the way it currently is. To satisfy both requirements, we have now setup an internal git for Adiscon use. Our plan is to have a parallel adiscon-master branch inside that repo, which will contain every detail. Its master branch will mirror the public git and contain squashed commits. We now have contributions from Adiscon (including me) and others. Those from Adiscon will be done in feature branches, with detail commits and be merged into the adiscon-master branch (so that it contains all details). Then, I will squash the feature branch into a single commit and merge that into master. So far, so good. But now we also have non-Adiscon contributions. A current example is [2]. One question is if they must be squashed as well? Let's assume this is not the case for whatever reason. So I merge them directly into master. Then, to keep my actual working tree up to date, I need to cherry-pick them into adiscon-master. This is where I am a bit hesitant, because of the manual action. I fear that the master and adiscon-master branches may begin to diverge, and be it through a simple mistake. So maybe it is better to merge pull requests into new feature branches, and then work as usual: merge feature branch into adiscon-master, squash feature branch, then merge it as single commit into master. To sum up: I would like to have two branches, the private one with all detail information, the public one minus those commits that are considered distracting. What is the best way to achieve this goal? Feedback appreciated, Rainer [1] http://lists.adiscon.net/pipermail/rsyslog/2014-November/038883.html [2] https://github.com/rsyslog/rsyslog/pull/147 ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: [rsyslog] can someone lend me a hand on git procedure
I'm in favor of the process being as simple as possible. The more work and thought that has to be put into dealing with pull requests, the more likely either work will get slowed down, or someone will make a mistake. I feel like if I want to squash, etc I can just do that on branches on my own fork, and then send the cleaned up version back to you. I don't feel like you should have to deal with squashing my commits. I also don't have a problem personally with seeing the merge messages. I think that the patch creator (in the feature branch) should do whatever squashing, rebaseing, etc is desired before the patch is sent upstream. If it's a small change, it may make sense to go ahead and alter the history before it's merged, but this shouldn't be a matter of make it one branch, but rather with 20-20 hindsight, this is the ideal series of patches to implement this feature where you trim out false starts, bugs that you later fix, etc. Especially if there is a large change, it's valuable to see the steps in the change individually rather than just having everything combined into one massive patch. David Lang On Fri, Nov 7, 2014 at 6:39 AM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: 2014-11-07 12:35 GMT+01:00 singh.janmejay singh.janme...@gmail.com: Rainer, Do we really need to squash? Why not just keep it simple and merge changes as they come? Its so much better for looking at exactly how/why things are the way they are. No rebase, no rewrites of history etc, just the simple commit and merge. well, I don't need all of that overhead. But from the other thread it looked like folks wanted it and nobody said anything else... Rainer -- Regards, Janmejay PS: Please blame the typos in this mail on my phone's uncivilized soft keyboard sporting it's not-so-smart-assist technology. On Nov 7, 2014 4:57 PM, Rainer Gerhards rgerha...@hq.adiscon.com wrote: Hi all, based on recent discussion ([1] is a good entry point), it looks like there is consensus that feature-branch commits shall be squashed before merging them into master. This is a bit bad for me because in almost all cases I like the ability to see the interim steps that lead to a feature in question (for bisect, but also to better understand what was going on). I have also discussed this with my peers in Adiscon and they also prefer the way it currently is. To satisfy both requirements, we have now setup an internal git for Adiscon use. Our plan is to have a parallel adiscon-master branch inside that repo, which will contain every detail. Its master branch will mirror the public git and contain squashed commits. We now have contributions from Adiscon (including me) and others. Those from Adiscon will be done in feature branches, with detail commits and be merged into the adiscon-master branch (so that it contains all details). Then, I will squash the feature branch into a single commit and merge that into master. So far, so good. But now we also have non-Adiscon contributions. A current example is [2]. One question is if they must be squashed as well? Let's assume this is not the case for whatever reason. So I merge them directly into master. Then, to keep my actual working tree up to date, I need to cherry-pick them into adiscon-master. This is where I am a bit hesitant, because of the manual action. I fear that the master and adiscon-master branches may begin to diverge, and be it through a simple mistake. So maybe it is better to merge pull requests into new feature branches, and then work as usual: merge feature branch into adiscon-master, squash feature branch, then merge it as single commit into master. To sum up: I would like to have two branches, the private one with all detail information, the public one minus those commits that are considered distracting. What is the best way to achieve this goal? Feedback appreciated, Rainer [1] http://lists.adiscon.net/pipermail/rsyslog/2014-November/038883.html [2] https://github.com/rsyslog/rsyslog/pull/147 ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
Re: [rsyslog] potential policy change: fixes for unsupported versions
On Fri, 7 Nov 2014, Rainer Gerhards wrote: Hi, just to bring out another potential policy change to the full bright light: There was discussion that in order to tidy up commit log, I should no longer merge up branches. As I don't have the time to do manually what currently git does for me, this means I will stop providing fixes for versions other than the currently supported one (8.4.2 at the moment). When I discussed this in Adiscon internally, we saw quite some advantage for us as well: if the unsupported versions are really unsupported, people hopefully would be more likely to update to the current versions. Also, it means a bit of less work for me, which frees up a little bit of resources. I honestly do not know how many folks at all really depend on e.g. v7-stable. My impression is that many, if not most, distros tend to base on a then-current version and apply patches to this baseline. So my question is: do we need to keep fixing the old stuff ... or can we really abandon that? My opinion. bugfixes that have no work-around may be reasonable to add to the last version before the current one, but going back further than that, or including fixes for bugs that can be worked around is doing too much work. maintaining an old version with the idea of only incorporating bugfixes to it over time is a lot of work, and it's fairly error prone (not to mention the ongoing debate as to what types of changes are safe to backport). Maintinance of such trees should be handed off from the main maintainer to someone who has interest in doing all this work. In the cae of rsyslog, the distros are doing some version of this. It may be reasonable for the distro maintainers to step up and maintain offical 'stable' versions for a while (hopefully getting some standardization beween the distros so they can share the work) But for this we really need feedback from the distro maintainers. David Lang ___ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
