Re: [rsyslog] rsyslog packaging project - was: rsyslog adiscon packages
2015-06-12 16:26 GMT+02:00 Rainer Gerhards : > Sent from phone, thus brief. > Am 12.06.2015 16:11 schrieb "David Lang" : > > > > On Fri, 12 Jun 2015, Rainer Gerhards wrote: > > > >> 2015-06-11 23:06 GMT+02:00 Brian Knox : > >>> > >>> Florian - plan will probably depend on what we decide we're deploying. > >>> Andre has set up an account already ( Rainer may have the details as > well > >>> ). We gave them access to the beta for the team account features - so > it > >>> should already be set up as a team account. We should make sure any > >>> infrastructure we set up is provisioned from that account since we (DO) > >>> have applied quite a bit of credit to it. > >>> > >>> If we're just working together on how we'd like to automate package > >>> building I'd suggest a small server to start with and if we grow out of > it > >>> we can bump it up.. maybe the 2GB ram / 2 core / 40GB ssd option to > >>> prototype on? Hard to know until we nail down exactly what we're > trying to > >>> stand up. > Sounds fine to me. Even with virtual machines I usually work with a similar setup. I assume it will be sufficient at first. > >> > >> > >> OK, I think I'll simply provision such a machine (so I finally get my > >> hands on your interface as well ;)). Does the NYC datacenter sound > >> good given our collaborator base? > > > > > > I don't think the collaborator base needs to drive the datacenter, we'll > be working via git/ssh/etc anyway. > > Lol, you know I am an old fashioned guy ;) but I was more thinking on > internet closeness ... But agreed that's also yesteryears ;) > At first I thought the same, but really today locations on a global scale are mostly irrelevant for such work. Florian > > Rainer > > > > David Lang > > > >> What do you think makes most sense from a file system structure point > >> of view? I have something along this on my mind: > >> > >> /home/... > >> pkgproject - packaging project user (also for cron jobs) > >> rainer > >> brian > >> andre > >> florian > >> > >> > >> under pkgproject, I'd create subdirs for each git repository. > >> > >> Once done, I'd see that I can migrate my current daily build > >> environment to that machine. That will probably raise questions, it's > >> currently tied to the result of testbench runs. Maybe issues to > >> discuss... Let's assume this works then we can begin to modify it in a > >> way that suits us better. > >> > >> It would probably good to describe the environment I use. I could do a > >> Hangout on that, but I am not sure if I have sufficient time the next > >> days and enough advance notice timeframe to make it fully interactive. > >> > >> Comments? > >> > >> 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 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] rsyslog packaging project - was: rsyslog adiscon packages
Sent from phone, thus brief. Am 12.06.2015 16:11 schrieb "David Lang" : > > On Fri, 12 Jun 2015, Rainer Gerhards wrote: > >> 2015-06-11 23:06 GMT+02:00 Brian Knox : >>> >>> Florian - plan will probably depend on what we decide we're deploying. >>> Andre has set up an account already ( Rainer may have the details as well >>> ). We gave them access to the beta for the team account features - so it >>> should already be set up as a team account. We should make sure any >>> infrastructure we set up is provisioned from that account since we (DO) >>> have applied quite a bit of credit to it. >>> >>> If we're just working together on how we'd like to automate package >>> building I'd suggest a small server to start with and if we grow out of it >>> we can bump it up.. maybe the 2GB ram / 2 core / 40GB ssd option to >>> prototype on? Hard to know until we nail down exactly what we're trying to >>> stand up. >> >> >> OK, I think I'll simply provision such a machine (so I finally get my >> hands on your interface as well ;)). Does the NYC datacenter sound >> good given our collaborator base? > > > I don't think the collaborator base needs to drive the datacenter, we'll be working via git/ssh/etc anyway. Lol, you know I am an old fashioned guy ;) but I was more thinking on internet closeness ... But agreed that's also yesteryears ;) Rainer > > David Lang > >> What do you think makes most sense from a file system structure point >> of view? I have something along this on my mind: >> >> /home/... >> pkgproject - packaging project user (also for cron jobs) >> rainer >> brian >> andre >> florian >> >> >> under pkgproject, I'd create subdirs for each git repository. >> >> Once done, I'd see that I can migrate my current daily build >> environment to that machine. That will probably raise questions, it's >> currently tied to the result of testbench runs. Maybe issues to >> discuss... Let's assume this works then we can begin to modify it in a >> way that suits us better. >> >> It would probably good to describe the environment I use. I could do a >> Hangout on that, but I am not sure if I have sufficient time the next >> days and enough advance notice timeframe to make it fully interactive. >> >> Comments? >> >> 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 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] rsyslog packaging project - was: rsyslog adiscon packages
On Fri, 12 Jun 2015, Rainer Gerhards wrote: 2015-06-11 20:59 GMT+02:00 David Lang : If the package is built from the master git tree, it should be signed by a common project key. I guess that includes packages build from the v8-stable branches. I ask because from master we usually build only the daily builds. Right. Anything built from any branch of the rsyslog git repository is a project package, anything built from a person't repository is a personal testing branch. 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.
Re: [rsyslog] rsyslog packaging project - was: rsyslog adiscon packages
On Fri, 12 Jun 2015, Rainer Gerhards wrote: 2015-06-11 23:06 GMT+02:00 Brian Knox : Florian - plan will probably depend on what we decide we're deploying. Andre has set up an account already ( Rainer may have the details as well ). We gave them access to the beta for the team account features - so it should already be set up as a team account. We should make sure any infrastructure we set up is provisioned from that account since we (DO) have applied quite a bit of credit to it. If we're just working together on how we'd like to automate package building I'd suggest a small server to start with and if we grow out of it we can bump it up.. maybe the 2GB ram / 2 core / 40GB ssd option to prototype on? Hard to know until we nail down exactly what we're trying to stand up. OK, I think I'll simply provision such a machine (so I finally get my hands on your interface as well ;)). Does the NYC datacenter sound good given our collaborator base? I don't think the collaborator base needs to drive the datacenter, we'll be working via git/ssh/etc anyway. David Lang What do you think makes most sense from a file system structure point of view? I have something along this on my mind: /home/... pkgproject - packaging project user (also for cron jobs) rainer brian andre florian under pkgproject, I'd create subdirs for each git repository. Once done, I'd see that I can migrate my current daily build environment to that machine. That will probably raise questions, it's currently tied to the result of testbench runs. Maybe issues to discuss... Let's assume this works then we can begin to modify it in a way that suits us better. It would probably good to describe the environment I use. I could do a Hangout on that, but I am not sure if I have sufficient time the next days and enough advance notice timeframe to make it fully interactive. Comments? 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 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] rsyslog packaging project - was: rsyslog adiscon packages
Let's do it "around the (my) corner" in Frankfurt ;) Sent from phone, thus brief. Am 12.06.2015 14:39 schrieb "Brian Knox" : > Rainer - truth be told the best datacenter we currently have is Frankfurt > :) It just opened recently, and the hypervisors in Germany are on the new > (v2) version of our hardware platform, have 40gbit nics, etc. > > If you wanted to do it in NYC instead, I'd suggest NYC3. > > Brian > > > > On Fri, Jun 12, 2015 at 8:25 AM, Rainer Gerhards > > wrote: > > > 2015-06-11 23:06 GMT+02:00 Brian Knox : > > > Florian - plan will probably depend on what we decide we're deploying. > > > Andre has set up an account already ( Rainer may have the details as > well > > > ). We gave them access to the beta for the team account features - so > it > > > should already be set up as a team account. We should make sure any > > > infrastructure we set up is provisioned from that account since we (DO) > > > have applied quite a bit of credit to it. > > > > > > If we're just working together on how we'd like to automate package > > > building I'd suggest a small server to start with and if we grow out of > > it > > > we can bump it up.. maybe the 2GB ram / 2 core / 40GB ssd option to > > > prototype on? Hard to know until we nail down exactly what we're > trying > > to > > > stand up. > > > > OK, I think I'll simply provision such a machine (so I finally get my > > hands on your interface as well ;)). Does the NYC datacenter sound > > good given our collaborator base? > > > > What do you think makes most sense from a file system structure point > > of view? I have something along this on my mind: > > > > /home/... > > pkgproject - packaging project user (also for cron jobs) > > rainer > > brian > > andre > > florian > > > > > > under pkgproject, I'd create subdirs for each git repository. > > > > Once done, I'd see that I can migrate my current daily build > > environment to that machine. That will probably raise questions, it's > > currently tied to the result of testbench runs. Maybe issues to > > discuss... Let's assume this works then we can begin to modify it in a > > way that suits us better. > > > > It would probably good to describe the environment I use. I could do a > > Hangout on that, but I am not sure if I have sufficient time the next > > days and enough advance notice timeframe to make it fully interactive. > > > > Comments? > > > > 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 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] rsyslog packaging project - was: rsyslog adiscon packages
Rainer - truth be told the best datacenter we currently have is Frankfurt :) It just opened recently, and the hypervisors in Germany are on the new (v2) version of our hardware platform, have 40gbit nics, etc. If you wanted to do it in NYC instead, I'd suggest NYC3. Brian On Fri, Jun 12, 2015 at 8:25 AM, Rainer Gerhards wrote: > 2015-06-11 23:06 GMT+02:00 Brian Knox : > > Florian - plan will probably depend on what we decide we're deploying. > > Andre has set up an account already ( Rainer may have the details as well > > ). We gave them access to the beta for the team account features - so it > > should already be set up as a team account. We should make sure any > > infrastructure we set up is provisioned from that account since we (DO) > > have applied quite a bit of credit to it. > > > > If we're just working together on how we'd like to automate package > > building I'd suggest a small server to start with and if we grow out of > it > > we can bump it up.. maybe the 2GB ram / 2 core / 40GB ssd option to > > prototype on? Hard to know until we nail down exactly what we're trying > to > > stand up. > > OK, I think I'll simply provision such a machine (so I finally get my > hands on your interface as well ;)). Does the NYC datacenter sound > good given our collaborator base? > > What do you think makes most sense from a file system structure point > of view? I have something along this on my mind: > > /home/... > pkgproject - packaging project user (also for cron jobs) > rainer > brian > andre > florian > > > under pkgproject, I'd create subdirs for each git repository. > > Once done, I'd see that I can migrate my current daily build > environment to that machine. That will probably raise questions, it's > currently tied to the result of testbench runs. Maybe issues to > discuss... Let's assume this works then we can begin to modify it in a > way that suits us better. > > It would probably good to describe the environment I use. I could do a > Hangout on that, but I am not sure if I have sufficient time the next > days and enough advance notice timeframe to make it fully interactive. > > Comments? > > 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 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] rsyslog packaging project - was: rsyslog adiscon packages
2015-06-11 23:06 GMT+02:00 Brian Knox : > Florian - plan will probably depend on what we decide we're deploying. > Andre has set up an account already ( Rainer may have the details as well > ). We gave them access to the beta for the team account features - so it > should already be set up as a team account. We should make sure any > infrastructure we set up is provisioned from that account since we (DO) > have applied quite a bit of credit to it. > > If we're just working together on how we'd like to automate package > building I'd suggest a small server to start with and if we grow out of it > we can bump it up.. maybe the 2GB ram / 2 core / 40GB ssd option to > prototype on? Hard to know until we nail down exactly what we're trying to > stand up. OK, I think I'll simply provision such a machine (so I finally get my hands on your interface as well ;)). Does the NYC datacenter sound good given our collaborator base? What do you think makes most sense from a file system structure point of view? I have something along this on my mind: /home/... pkgproject - packaging project user (also for cron jobs) rainer brian andre florian under pkgproject, I'd create subdirs for each git repository. Once done, I'd see that I can migrate my current daily build environment to that machine. That will probably raise questions, it's currently tied to the result of testbench runs. Maybe issues to discuss... Let's assume this works then we can begin to modify it in a way that suits us better. It would probably good to describe the environment I use. I could do a Hangout on that, but I am not sure if I have sufficient time the next days and enough advance notice timeframe to make it fully interactive. Comments? 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.
Re: [rsyslog] rsyslog packaging project - was: rsyslog adiscon packages
2015-06-11 20:59 GMT+02:00 David Lang : > If the package is built from the master git tree, it should be signed by a > common project key. I guess that includes packages build from the v8-stable branches. I ask because from master we usually build only the daily builds. 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.
Re: [rsyslog] rsyslog packaging project - was: rsyslog adiscon packages
Florian - plan will probably depend on what we decide we're deploying. Andre has set up an account already ( Rainer may have the details as well ). We gave them access to the beta for the team account features - so it should already be set up as a team account. We should make sure any infrastructure we set up is provisioned from that account since we (DO) have applied quite a bit of credit to it. If we're just working together on how we'd like to automate package building I'd suggest a small server to start with and if we grow out of it we can bump it up.. maybe the 2GB ram / 2 core / 40GB ssd option to prototype on? Hard to know until we nail down exactly what we're trying to stand up. Cheers! Brian On Thu, Jun 11, 2015 at 12:17 PM, Florian Riedl wrote: > Hi, > > I am very happy, that this project already received some initial drive and > I am looking forward to working with you all. > > +1 for the mailing list as communication device > > I guess we could establish some prefix for the subject, so emails regarding > the packaging project can be easily distinguished from the regular stuff. > Something like [rpp]? > > +1 for the Digital Ocean hosting > > I guess, using the cloud hosting solution by DO might be the best way to > set this up, because it is probably the most accessible solution. No need > to buy Hardware, no need to set up complicated access clutter to internal > networks. Though, I am not sure where to start in that matter or what plan > to choose from the available options. Brian, do you have a suggestion what > could be a good starting point? > > Another question that needs to be discussed is the use of SSH certificates > for the signing of packages. This is not ideally solved for the current > packages. I guess there are two possibilities: > 1. All packages are built and signed with a common project key. > 2. All packages are built and signed with a individual key from each > person. > > Option 1 has some charme, but it is impossible to determine who actually > built the packages, whereas this is possible with option 2, but there every > "builder" needs to have a key. This even applies to logins. > > Opinions and comments anyone? > > Florian > > 2015-06-09 19:32 GMT+02:00 Brian Knox : > > > Rsyslog is very useful and appreciated :) > > > > On Tue, Jun 9, 2015 at 1:28 PM, Rainer Gerhards < > rgerha...@hq.adiscon.com> > > wrote: > > > > > Sent from phone, thus brief. > > > Am 09.06.2015 19:01 schrieb "Brian Knox" : > > > > > > > > Coordinating on the mailing list is fine with me. My employer > > > > (DigitalOcean) has given the rsyslog project a fairly sizeable free > > > hosting > > > > budget so I'd be remiss to not advocate for us ;). > > > > > > I just realize that I slipped something (the Digital Ocean sponsoring) > > that > > > I wanted to announce more formally ... Well that will follow but let me > > say > > > now that it is very useful and appreciated :) > > > > > > Rainer > > > > If another option works > > > > out to be better I certainly understand! > > > > > > > > I totally agree that converging on an agreed upon problem statement > is > > > the > > > > right place to start. > > > > > > > > Cheers, > > > > Brian > > > > > > > > On Tue, Jun 9, 2015 at 12:53 PM, David Lang wrote: > > > > > > > > > On Tue, 9 Jun 2015, Rainer Gerhards wrote: > > > > > > > > > > Hi all, > > > > >> > > > > >> chances are extremely well to get to better packaging projects. We > > had > > > > >> some discussions internally in Adiscon, and I was able to secure > the > > > > >> help of Florian Riedl for getting this in the best possible shape. > > > > >> > > > > >> Our goal is to get > > > > >> > > > > >> - better packages > > > > >> - more timely support for new distro releases > > > > >> - support for a broader set of distros (e.g. Fedora, often > > requested) > > > > >> - more ability for the community to steer this previous > all-Adiscon > > > > >> project > > > > >> > > > > >> The 0mq discussion that started this thread is a good example of > > what > > > > >> this means. > > > > >> > > > > >> With the help of more community involvment we can reach the goals. > > And > > > > >> in order to make it easier to contribute, we need to streamline > the > > > > >> process of how we build, release, test, and announce packages. > > > > >> > > > > >> Thankfully, Brian has offered to become an active team member. It > > > > >> would be great if others would also join in. > > > > >> > > > > >> I currently think that the right path to success is to start with > > > > >> small but sufficiently large project part. So I would propose that > > we > > > > >> focus on Ubuntu initially, get that part organized, learn a couple > > of > > > > >> things and apply the gained experience later to a "final" project > > that > > > > >> covers other distros as well (as mentioned by darix, the use of > OBS > > > > >> sounds very appealing to me). > > > > >> > > > > >> In order to get going, I would like to see some id
Re: [rsyslog] rsyslog packaging project - was: rsyslog adiscon packages
On Thu, 11 Jun 2015, Florian Riedl wrote: Hi, I am very happy, that this project already received some initial drive and I am looking forward to working with you all. +1 for the mailing list as communication device I guess we could establish some prefix for the subject, so emails regarding the packaging project can be easily distinguished from the regular stuff. Something like [rpp]? +1 for the Digital Ocean hosting I guess, using the cloud hosting solution by DO might be the best way to set this up, because it is probably the most accessible solution. No need to buy Hardware, no need to set up complicated access clutter to internal networks. Though, I am not sure where to start in that matter or what plan to choose from the available options. Brian, do you have a suggestion what could be a good starting point? Another question that needs to be discussed is the use of SSH certificates for the signing of packages. This is not ideally solved for the current packages. I guess there are two possibilities: 1. All packages are built and signed with a common project key. 2. All packages are built and signed with a individual key from each person. Option 1 has some charme, but it is impossible to determine who actually built the packages, whereas this is possible with option 2, but there every "builder" needs to have a key. This even applies to logins. Opinions and comments anyone? If the package is built from the master git tree, it should be signed by a common project key. If it's built from someone's personal branch, it should be signed by that person. David Lang Florian 2015-06-09 19:32 GMT+02:00 Brian Knox : Rsyslog is very useful and appreciated :) On Tue, Jun 9, 2015 at 1:28 PM, Rainer Gerhards wrote: Sent from phone, thus brief. Am 09.06.2015 19:01 schrieb "Brian Knox" : Coordinating on the mailing list is fine with me. My employer (DigitalOcean) has given the rsyslog project a fairly sizeable free hosting budget so I'd be remiss to not advocate for us ;). I just realize that I slipped something (the Digital Ocean sponsoring) that I wanted to announce more formally ... Well that will follow but let me say now that it is very useful and appreciated :) Rainer If another option works out to be better I certainly understand! I totally agree that converging on an agreed upon problem statement is the right place to start. Cheers, Brian On Tue, Jun 9, 2015 at 12:53 PM, David Lang wrote: On Tue, 9 Jun 2015, Rainer Gerhards wrote: Hi all, chances are extremely well to get to better packaging projects. We had some discussions internally in Adiscon, and I was able to secure the help of Florian Riedl for getting this in the best possible shape. Our goal is to get - better packages - more timely support for new distro releases - support for a broader set of distros (e.g. Fedora, often requested) - more ability for the community to steer this previous all-Adiscon project The 0mq discussion that started this thread is a good example of what this means. With the help of more community involvment we can reach the goals. And in order to make it easier to contribute, we need to streamline the process of how we build, release, test, and announce packages. Thankfully, Brian has offered to become an active team member. It would be great if others would also join in. I currently think that the right path to success is to start with small but sufficiently large project part. So I would propose that we focus on Ubuntu initially, get that part organized, learn a couple of things and apply the gained experience later to a "final" project that covers other distros as well (as mentioned by darix, the use of OBS sounds very appealing to me). In order to get going, I would like to see some ideas float on: - how should we communicate? (rsyslog mailing list, dedicated mailing list, github issue trackers, IRC, ...) I'd say the rsyslog mailing list, failing that a dedicated mailing list. But I think that the issues we will be working through are useful to people who need to roll their own version (to test something from git, or to enable specific features). - where do we track issues? (I have a strong preferrence for the github issue trackers) - what about doc? - where should we place the build platform (cloud I would guess, could we use Digital Ocean sponsorship for this)? I don't know the details of using it, but the Suse Open Build Platform is already setup to support a whole bunch of target distros. How close does it come to covering everything we need? Can it be used for all the different uses we want from this (distro release builds, nightly builds, other) If we have to roll our own infrastructure, some sort of cloud system is right. Google donates time on their cloud system to opensource projects, I don't know if it would be enough or not. Sponsorship from whoever is good :-) - when do we start ;) Clarification of the prob
Re: [rsyslog] rsyslog packaging project - was: rsyslog adiscon packages
Hi, I am very happy, that this project already received some initial drive and I am looking forward to working with you all. +1 for the mailing list as communication device I guess we could establish some prefix for the subject, so emails regarding the packaging project can be easily distinguished from the regular stuff. Something like [rpp]? +1 for the Digital Ocean hosting I guess, using the cloud hosting solution by DO might be the best way to set this up, because it is probably the most accessible solution. No need to buy Hardware, no need to set up complicated access clutter to internal networks. Though, I am not sure where to start in that matter or what plan to choose from the available options. Brian, do you have a suggestion what could be a good starting point? Another question that needs to be discussed is the use of SSH certificates for the signing of packages. This is not ideally solved for the current packages. I guess there are two possibilities: 1. All packages are built and signed with a common project key. 2. All packages are built and signed with a individual key from each person. Option 1 has some charme, but it is impossible to determine who actually built the packages, whereas this is possible with option 2, but there every "builder" needs to have a key. This even applies to logins. Opinions and comments anyone? Florian 2015-06-09 19:32 GMT+02:00 Brian Knox : > Rsyslog is very useful and appreciated :) > > On Tue, Jun 9, 2015 at 1:28 PM, Rainer Gerhards > wrote: > > > Sent from phone, thus brief. > > Am 09.06.2015 19:01 schrieb "Brian Knox" : > > > > > > Coordinating on the mailing list is fine with me. My employer > > > (DigitalOcean) has given the rsyslog project a fairly sizeable free > > hosting > > > budget so I'd be remiss to not advocate for us ;). > > > > I just realize that I slipped something (the Digital Ocean sponsoring) > that > > I wanted to announce more formally ... Well that will follow but let me > say > > now that it is very useful and appreciated :) > > > > Rainer > > > If another option works > > > out to be better I certainly understand! > > > > > > I totally agree that converging on an agreed upon problem statement is > > the > > > right place to start. > > > > > > Cheers, > > > Brian > > > > > > On Tue, Jun 9, 2015 at 12:53 PM, David Lang wrote: > > > > > > > On Tue, 9 Jun 2015, Rainer Gerhards wrote: > > > > > > > > Hi all, > > > >> > > > >> chances are extremely well to get to better packaging projects. We > had > > > >> some discussions internally in Adiscon, and I was able to secure the > > > >> help of Florian Riedl for getting this in the best possible shape. > > > >> > > > >> Our goal is to get > > > >> > > > >> - better packages > > > >> - more timely support for new distro releases > > > >> - support for a broader set of distros (e.g. Fedora, often > requested) > > > >> - more ability for the community to steer this previous all-Adiscon > > > >> project > > > >> > > > >> The 0mq discussion that started this thread is a good example of > what > > > >> this means. > > > >> > > > >> With the help of more community involvment we can reach the goals. > And > > > >> in order to make it easier to contribute, we need to streamline the > > > >> process of how we build, release, test, and announce packages. > > > >> > > > >> Thankfully, Brian has offered to become an active team member. It > > > >> would be great if others would also join in. > > > >> > > > >> I currently think that the right path to success is to start with > > > >> small but sufficiently large project part. So I would propose that > we > > > >> focus on Ubuntu initially, get that part organized, learn a couple > of > > > >> things and apply the gained experience later to a "final" project > that > > > >> covers other distros as well (as mentioned by darix, the use of OBS > > > >> sounds very appealing to me). > > > >> > > > >> In order to get going, I would like to see some ideas float on: > > > >> > > > >> - how should we communicate? > > > >> (rsyslog mailing list, dedicated mailing list, github issue > > > >> trackers, IRC, ...) > > > >> > > > > > > > > I'd say the rsyslog mailing list, failing that a dedicated mailing > > list. > > > > But I think that the issues we will be working through are useful to > > people > > > > who need to roll their own version (to test something from git, or to > > > > enable specific features). > > > > > > > > - where do we track issues? > > > >> (I have a strong preferrence for the github issue trackers) > > > >> - what about doc? > > > >> - where should we place the build platform > > > >> (cloud I would guess, could we use Digital Ocean sponsorship for > > this)? > > > >> > > > > > > > > I don't know the details of using it, but the Suse Open Build > Platform > > is > > > > already setup to support a whole bunch of target distros. How close > > does it > > > > come to covering everything we need? > > > > > > > > Can it be used for all th
Re: [rsyslog] rsyslog packaging project - was: rsyslog adiscon packages
Rsyslog is very useful and appreciated :) On Tue, Jun 9, 2015 at 1:28 PM, Rainer Gerhards wrote: > Sent from phone, thus brief. > Am 09.06.2015 19:01 schrieb "Brian Knox" : > > > > Coordinating on the mailing list is fine with me. My employer > > (DigitalOcean) has given the rsyslog project a fairly sizeable free > hosting > > budget so I'd be remiss to not advocate for us ;). > > I just realize that I slipped something (the Digital Ocean sponsoring) that > I wanted to announce more formally ... Well that will follow but let me say > now that it is very useful and appreciated :) > > Rainer > > If another option works > > out to be better I certainly understand! > > > > I totally agree that converging on an agreed upon problem statement is > the > > right place to start. > > > > Cheers, > > Brian > > > > On Tue, Jun 9, 2015 at 12:53 PM, David Lang wrote: > > > > > On Tue, 9 Jun 2015, Rainer Gerhards wrote: > > > > > > Hi all, > > >> > > >> chances are extremely well to get to better packaging projects. We had > > >> some discussions internally in Adiscon, and I was able to secure the > > >> help of Florian Riedl for getting this in the best possible shape. > > >> > > >> Our goal is to get > > >> > > >> - better packages > > >> - more timely support for new distro releases > > >> - support for a broader set of distros (e.g. Fedora, often requested) > > >> - more ability for the community to steer this previous all-Adiscon > > >> project > > >> > > >> The 0mq discussion that started this thread is a good example of what > > >> this means. > > >> > > >> With the help of more community involvment we can reach the goals. And > > >> in order to make it easier to contribute, we need to streamline the > > >> process of how we build, release, test, and announce packages. > > >> > > >> Thankfully, Brian has offered to become an active team member. It > > >> would be great if others would also join in. > > >> > > >> I currently think that the right path to success is to start with > > >> small but sufficiently large project part. So I would propose that we > > >> focus on Ubuntu initially, get that part organized, learn a couple of > > >> things and apply the gained experience later to a "final" project that > > >> covers other distros as well (as mentioned by darix, the use of OBS > > >> sounds very appealing to me). > > >> > > >> In order to get going, I would like to see some ideas float on: > > >> > > >> - how should we communicate? > > >> (rsyslog mailing list, dedicated mailing list, github issue > > >> trackers, IRC, ...) > > >> > > > > > > I'd say the rsyslog mailing list, failing that a dedicated mailing > list. > > > But I think that the issues we will be working through are useful to > people > > > who need to roll their own version (to test something from git, or to > > > enable specific features). > > > > > > - where do we track issues? > > >> (I have a strong preferrence for the github issue trackers) > > >> - what about doc? > > >> - where should we place the build platform > > >> (cloud I would guess, could we use Digital Ocean sponsorship for > this)? > > >> > > > > > > I don't know the details of using it, but the Suse Open Build Platform > is > > > already setup to support a whole bunch of target distros. How close > does it > > > come to covering everything we need? > > > > > > Can it be used for all the different uses we want from this (distro > > > release builds, nightly builds, other) > > > > > > If we have to roll our own infrastructure, some sort of cloud system is > > > right. Google donates time on their cloud system to opensource > projects, I > > > don't know if it would be enough or not. Sponsorship from whoever is > good > > > :-) > > > > > > - when do we start ;) > > >> > > > > > > Clarification of the problem statement and where we are starting from > :-) > > > > > > right now there is the rsyslog-pkg-* repos on github that have the > scripts > > > that adiscon uses internally. As I found when I went to use them, there > are > > > a few oddities and too much hard-coded for adiscon internal use. But > there > > > is also a lot of useful stuff there as well. > > > > > > As we look at the build options, let's see how much of the existing > stuff > > > we can re-use. > > > > > > Also, let's try to make this be something that people can use when > > > building from git. > > > > > > David Lang > > > > > > > > > - ... whatever else I haven't yet thought about. > > >> > > >> Please take a moment to voice your preferrences! > > >> > > >> Thanks, > > >> Rainer > > >> > > >> > > >> 2015-06-03 21:08 GMT+02:00 David Lang : > > >> > > >>> take a look at > > >>> > > >>> https://github.com/rsyslog/rsyslog-pkg-ubuntu > > >>> > > >>> to build locally without using the PPA infrastructure I apply the > > >>> attached > > >>> patch (remove the sections for disabling usertools, that's a > debugging > > >>> thing > > >>> I have in place at the moment) > > >>> > > >>> do pbuilder --create to cre
Re: [rsyslog] rsyslog packaging project - was: rsyslog adiscon packages
Sent from phone, thus brief. Am 09.06.2015 19:01 schrieb "Brian Knox" : > > Coordinating on the mailing list is fine with me. My employer > (DigitalOcean) has given the rsyslog project a fairly sizeable free hosting > budget so I'd be remiss to not advocate for us ;). I just realize that I slipped something (the Digital Ocean sponsoring) that I wanted to announce more formally ... Well that will follow but let me say now that it is very useful and appreciated :) Rainer > If another option works > out to be better I certainly understand! > > I totally agree that converging on an agreed upon problem statement is the > right place to start. > > Cheers, > Brian > > On Tue, Jun 9, 2015 at 12:53 PM, David Lang wrote: > > > On Tue, 9 Jun 2015, Rainer Gerhards wrote: > > > > Hi all, > >> > >> chances are extremely well to get to better packaging projects. We had > >> some discussions internally in Adiscon, and I was able to secure the > >> help of Florian Riedl for getting this in the best possible shape. > >> > >> Our goal is to get > >> > >> - better packages > >> - more timely support for new distro releases > >> - support for a broader set of distros (e.g. Fedora, often requested) > >> - more ability for the community to steer this previous all-Adiscon > >> project > >> > >> The 0mq discussion that started this thread is a good example of what > >> this means. > >> > >> With the help of more community involvment we can reach the goals. And > >> in order to make it easier to contribute, we need to streamline the > >> process of how we build, release, test, and announce packages. > >> > >> Thankfully, Brian has offered to become an active team member. It > >> would be great if others would also join in. > >> > >> I currently think that the right path to success is to start with > >> small but sufficiently large project part. So I would propose that we > >> focus on Ubuntu initially, get that part organized, learn a couple of > >> things and apply the gained experience later to a "final" project that > >> covers other distros as well (as mentioned by darix, the use of OBS > >> sounds very appealing to me). > >> > >> In order to get going, I would like to see some ideas float on: > >> > >> - how should we communicate? > >> (rsyslog mailing list, dedicated mailing list, github issue > >> trackers, IRC, ...) > >> > > > > I'd say the rsyslog mailing list, failing that a dedicated mailing list. > > But I think that the issues we will be working through are useful to people > > who need to roll their own version (to test something from git, or to > > enable specific features). > > > > - where do we track issues? > >> (I have a strong preferrence for the github issue trackers) > >> - what about doc? > >> - where should we place the build platform > >> (cloud I would guess, could we use Digital Ocean sponsorship for this)? > >> > > > > I don't know the details of using it, but the Suse Open Build Platform is > > already setup to support a whole bunch of target distros. How close does it > > come to covering everything we need? > > > > Can it be used for all the different uses we want from this (distro > > release builds, nightly builds, other) > > > > If we have to roll our own infrastructure, some sort of cloud system is > > right. Google donates time on their cloud system to opensource projects, I > > don't know if it would be enough or not. Sponsorship from whoever is good > > :-) > > > > - when do we start ;) > >> > > > > Clarification of the problem statement and where we are starting from :-) > > > > right now there is the rsyslog-pkg-* repos on github that have the scripts > > that adiscon uses internally. As I found when I went to use them, there are > > a few oddities and too much hard-coded for adiscon internal use. But there > > is also a lot of useful stuff there as well. > > > > As we look at the build options, let's see how much of the existing stuff > > we can re-use. > > > > Also, let's try to make this be something that people can use when > > building from git. > > > > David Lang > > > > > > - ... whatever else I haven't yet thought about. > >> > >> Please take a moment to voice your preferrences! > >> > >> Thanks, > >> Rainer > >> > >> > >> 2015-06-03 21:08 GMT+02:00 David Lang : > >> > >>> take a look at > >>> > >>> https://github.com/rsyslog/rsyslog-pkg-ubuntu > >>> > >>> to build locally without using the PPA infrastructure I apply the > >>> attached > >>> patch (remove the sections for disabling usertools, that's a debugging > >>> thing > >>> I have in place at the moment) > >>> > >>> do pbuilder --create to create the compile environment, then I use the > >>> following script to pull the latest updates and compile test packages > >>> > >>> find . -name .git |sed s/.git// |while read file > >>> do > >>> echo "$file" > >>> cd $file > >>> /usr/bin/git fetch > >>> /usr/bin/git pull > >>> /usr/bin/git fetch --tags > >>> # /usr/bin/git gc -q --aggressive > >>> autoreconf -fi > >
Re: [rsyslog] rsyslog packaging project - was: rsyslog adiscon packages
Coordinating on the mailing list is fine with me. My employer
(DigitalOcean) has given the rsyslog project a fairly sizeable free hosting
budget so I'd be remiss to not advocate for us ;). If another option works
out to be better I certainly understand!
I totally agree that converging on an agreed upon problem statement is the
right place to start.
Cheers,
Brian
On Tue, Jun 9, 2015 at 12:53 PM, David Lang wrote:
> On Tue, 9 Jun 2015, Rainer Gerhards wrote:
>
> Hi all,
>>
>> chances are extremely well to get to better packaging projects. We had
>> some discussions internally in Adiscon, and I was able to secure the
>> help of Florian Riedl for getting this in the best possible shape.
>>
>> Our goal is to get
>>
>> - better packages
>> - more timely support for new distro releases
>> - support for a broader set of distros (e.g. Fedora, often requested)
>> - more ability for the community to steer this previous all-Adiscon
>> project
>>
>> The 0mq discussion that started this thread is a good example of what
>> this means.
>>
>> With the help of more community involvment we can reach the goals. And
>> in order to make it easier to contribute, we need to streamline the
>> process of how we build, release, test, and announce packages.
>>
>> Thankfully, Brian has offered to become an active team member. It
>> would be great if others would also join in.
>>
>> I currently think that the right path to success is to start with
>> small but sufficiently large project part. So I would propose that we
>> focus on Ubuntu initially, get that part organized, learn a couple of
>> things and apply the gained experience later to a "final" project that
>> covers other distros as well (as mentioned by darix, the use of OBS
>> sounds very appealing to me).
>>
>> In order to get going, I would like to see some ideas float on:
>>
>> - how should we communicate?
>> (rsyslog mailing list, dedicated mailing list, github issue
>> trackers, IRC, ...)
>>
>
> I'd say the rsyslog mailing list, failing that a dedicated mailing list.
> But I think that the issues we will be working through are useful to people
> who need to roll their own version (to test something from git, or to
> enable specific features).
>
> - where do we track issues?
>> (I have a strong preferrence for the github issue trackers)
>> - what about doc?
>> - where should we place the build platform
>> (cloud I would guess, could we use Digital Ocean sponsorship for this)?
>>
>
> I don't know the details of using it, but the Suse Open Build Platform is
> already setup to support a whole bunch of target distros. How close does it
> come to covering everything we need?
>
> Can it be used for all the different uses we want from this (distro
> release builds, nightly builds, other)
>
> If we have to roll our own infrastructure, some sort of cloud system is
> right. Google donates time on their cloud system to opensource projects, I
> don't know if it would be enough or not. Sponsorship from whoever is good
> :-)
>
> - when do we start ;)
>>
>
> Clarification of the problem statement and where we are starting from :-)
>
> right now there is the rsyslog-pkg-* repos on github that have the scripts
> that adiscon uses internally. As I found when I went to use them, there are
> a few oddities and too much hard-coded for adiscon internal use. But there
> is also a lot of useful stuff there as well.
>
> As we look at the build options, let's see how much of the existing stuff
> we can re-use.
>
> Also, let's try to make this be something that people can use when
> building from git.
>
> David Lang
>
>
> - ... whatever else I haven't yet thought about.
>>
>> Please take a moment to voice your preferrences!
>>
>> Thanks,
>> Rainer
>>
>>
>> 2015-06-03 21:08 GMT+02:00 David Lang :
>>
>>> take a look at
>>>
>>> https://github.com/rsyslog/rsyslog-pkg-ubuntu
>>>
>>> to build locally without using the PPA infrastructure I apply the
>>> attached
>>> patch (remove the sections for disabling usertools, that's a debugging
>>> thing
>>> I have in place at the moment)
>>>
>>> do pbuilder --create to create the compile environment, then I use the
>>> following script to pull the latest updates and compile test packages
>>>
>>> find . -name .git |sed s/.git// |while read file
>>> do
>>> echo "$file"
>>> cd $file
>>> /usr/bin/git fetch
>>> /usr/bin/git pull
>>> /usr/bin/git fetch --tags
>>> # /usr/bin/git gc -q --aggressive
>>> autoreconf -fi
>>> ./configure -q
>>> rm *master*
>>> make dist --quiet
>>> cd -
>>> done
>>> echo "finished making source packages"
>>> cd rsyslog-pkg-ubuntu
>>> rm */LAST_VERSION.*
>>> for i in libestr liblogging liblognorm librelp rsyslog
>>> do
>>> cd $i
>>> rm ${i}_*
>>> cp ../../$i/*master* .
>>> ../scripts/auto_daily_project.sh trusty v8-devel master
>>> (
>>> echo '1'
>>> echo '1'
>>> echo '1'
>>> echo '1'
>>> ) |../scripts/build.sh
>>> echo "finished making $i"
>>> cd -
>>> done
>>>
>>> This should
Re: [rsyslog] rsyslog packaging project - was: rsyslog adiscon packages
On Tue, 9 Jun 2015, Rainer Gerhards wrote:
Hi all,
chances are extremely well to get to better packaging projects. We had
some discussions internally in Adiscon, and I was able to secure the
help of Florian Riedl for getting this in the best possible shape.
Our goal is to get
- better packages
- more timely support for new distro releases
- support for a broader set of distros (e.g. Fedora, often requested)
- more ability for the community to steer this previous all-Adiscon project
The 0mq discussion that started this thread is a good example of what
this means.
With the help of more community involvment we can reach the goals. And
in order to make it easier to contribute, we need to streamline the
process of how we build, release, test, and announce packages.
Thankfully, Brian has offered to become an active team member. It
would be great if others would also join in.
I currently think that the right path to success is to start with
small but sufficiently large project part. So I would propose that we
focus on Ubuntu initially, get that part organized, learn a couple of
things and apply the gained experience later to a "final" project that
covers other distros as well (as mentioned by darix, the use of OBS
sounds very appealing to me).
In order to get going, I would like to see some ideas float on:
- how should we communicate?
(rsyslog mailing list, dedicated mailing list, github issue
trackers, IRC, ...)
I'd say the rsyslog mailing list, failing that a dedicated mailing list. But I
think that the issues we will be working through are useful to people who need
to roll their own version (to test something from git, or to enable specific
features).
- where do we track issues?
(I have a strong preferrence for the github issue trackers)
- what about doc?
- where should we place the build platform
(cloud I would guess, could we use Digital Ocean sponsorship for this)?
I don't know the details of using it, but the Suse Open Build Platform is
already setup to support a whole bunch of target distros. How close does it come
to covering everything we need?
Can it be used for all the different uses we want from this (distro release
builds, nightly builds, other)
If we have to roll our own infrastructure, some sort of cloud system is right.
Google donates time on their cloud system to opensource projects, I don't know
if it would be enough or not. Sponsorship from whoever is good :-)
- when do we start ;)
Clarification of the problem statement and where we are starting from :-)
right now there is the rsyslog-pkg-* repos on github that have the scripts that
adiscon uses internally. As I found when I went to use them, there are a few
oddities and too much hard-coded for adiscon internal use. But there is also a
lot of useful stuff there as well.
As we look at the build options, let's see how much of the existing stuff we can
re-use.
Also, let's try to make this be something that people can use when building
from git.
David Lang
- ... whatever else I haven't yet thought about.
Please take a moment to voice your preferrences!
Thanks,
Rainer
2015-06-03 21:08 GMT+02:00 David Lang :
take a look at
https://github.com/rsyslog/rsyslog-pkg-ubuntu
to build locally without using the PPA infrastructure I apply the attached
patch (remove the sections for disabling usertools, that's a debugging thing
I have in place at the moment)
do pbuilder --create to create the compile environment, then I use the
following script to pull the latest updates and compile test packages
find . -name .git |sed s/.git// |while read file
do
echo "$file"
cd $file
/usr/bin/git fetch
/usr/bin/git pull
/usr/bin/git fetch --tags
# /usr/bin/git gc -q --aggressive
autoreconf -fi
./configure -q
rm *master*
make dist --quiet
cd -
done
echo "finished making source packages"
cd rsyslog-pkg-ubuntu
rm */LAST_VERSION.*
for i in libestr liblogging liblognorm librelp rsyslog
do
cd $i
rm ${i}_*
cp ../../$i/*master* .
../scripts/auto_daily_project.sh trusty v8-devel master
(
echo '1'
echo '1'
echo '1'
echo '1'
) |../scripts/build.sh
echo "finished making $i"
cd -
done
This should help get you started :-)
David Lang
On Wed, 3 Jun 2015, Brian Knox wrote:
Date: Wed, 3 Jun 2015 11:48:20 -0400
From: Brian Knox
Reply-To: rsyslog-users
To: rsyslog-users
Subject: Re: [rsyslog] rsyslog adiscon packages
Ubuntu LTS is currently what I'm using so that's advantageous. In
addition, I've built a custom rsyslog package for Ubuntu that includes
omczmq / imczmq along with debs for the dependencies. However, my rsyslog
package is monolithic and I'm using brew2deb, which is kind of a strange
wrapper around fpm and homebrew that probably isn't the best way to do
things.
Ubuntu and Debian pacakge libzmq (but not czmq). Their packages are
behind
current, but maybe their packages would be a good and hopefully easy place
to start, depending on how packages are being b
[rsyslog] rsyslog packaging project - was: rsyslog adiscon packages
Hi all,
chances are extremely well to get to better packaging projects. We had
some discussions internally in Adiscon, and I was able to secure the
help of Florian Riedl for getting this in the best possible shape.
Our goal is to get
- better packages
- more timely support for new distro releases
- support for a broader set of distros (e.g. Fedora, often requested)
- more ability for the community to steer this previous all-Adiscon project
The 0mq discussion that started this thread is a good example of what
this means.
With the help of more community involvment we can reach the goals. And
in order to make it easier to contribute, we need to streamline the
process of how we build, release, test, and announce packages.
Thankfully, Brian has offered to become an active team member. It
would be great if others would also join in.
I currently think that the right path to success is to start with
small but sufficiently large project part. So I would propose that we
focus on Ubuntu initially, get that part organized, learn a couple of
things and apply the gained experience later to a "final" project that
covers other distros as well (as mentioned by darix, the use of OBS
sounds very appealing to me).
In order to get going, I would like to see some ideas float on:
- how should we communicate?
(rsyslog mailing list, dedicated mailing list, github issue
trackers, IRC, ...)
- where do we track issues?
(I have a strong preferrence for the github issue trackers)
- what about doc?
- where should we place the build platform
(cloud I would guess, could we use Digital Ocean sponsorship for this)?
- when do we start ;)
- ... whatever else I haven't yet thought about.
Please take a moment to voice your preferrences!
Thanks,
Rainer
2015-06-03 21:08 GMT+02:00 David Lang :
> take a look at
>
> https://github.com/rsyslog/rsyslog-pkg-ubuntu
>
> to build locally without using the PPA infrastructure I apply the attached
> patch (remove the sections for disabling usertools, that's a debugging thing
> I have in place at the moment)
>
> do pbuilder --create to create the compile environment, then I use the
> following script to pull the latest updates and compile test packages
>
> find . -name .git |sed s/.git// |while read file
> do
> echo "$file"
> cd $file
> /usr/bin/git fetch
> /usr/bin/git pull
> /usr/bin/git fetch --tags
> # /usr/bin/git gc -q --aggressive
> autoreconf -fi
> ./configure -q
> rm *master*
> make dist --quiet
> cd -
> done
> echo "finished making source packages"
> cd rsyslog-pkg-ubuntu
> rm */LAST_VERSION.*
> for i in libestr liblogging liblognorm librelp rsyslog
> do
> cd $i
> rm ${i}_*
> cp ../../$i/*master* .
> ../scripts/auto_daily_project.sh trusty v8-devel master
> (
> echo '1'
> echo '1'
> echo '1'
> echo '1'
> ) |../scripts/build.sh
> echo "finished making $i"
> cd -
> done
>
> This should help get you started :-)
>
> David Lang
>
> On Wed, 3 Jun 2015, Brian Knox wrote:
>
>> Date: Wed, 3 Jun 2015 11:48:20 -0400
>> From: Brian Knox
>> Reply-To: rsyslog-users
>> To: rsyslog-users
>> Subject: Re: [rsyslog] rsyslog adiscon packages
>>
>>
>> Ubuntu LTS is currently what I'm using so that's advantageous. In
>> addition, I've built a custom rsyslog package for Ubuntu that includes
>> omczmq / imczmq along with debs for the dependencies. However, my rsyslog
>> package is monolithic and I'm using brew2deb, which is kind of a strange
>> wrapper around fpm and homebrew that probably isn't the best way to do
>> things.
>>
>> Ubuntu and Debian pacakge libzmq (but not czmq). Their packages are
>> behind
>> current, but maybe their packages would be a good and hopefully easy place
>> to start, depending on how packages are being built currently for the
>> ubuntu repo.
>>
>> If there's build scripts for the current repo now, I'd be happy to work
>> through them and do the work.
>>
>> Brian
>>
>>
>> On Wed, Jun 3, 2015 at 11:38 AM, Rainer Gerhards
>>
>> wrote:
>>
>>> Would it be a good idea to start with Ubuntu?
>>>
>>> Sent from phone, thus brief.
>>> Am 03.06.2015 16:23 schrieb "Brian Knox" :
>>>
I'm on board!
Cheers,
Brian
On Wed, Jun 3, 2015 at 10:07 AM, Rainer Gerhards <
>>>
>>> rgerha...@hq.adiscon.com
>
>
wrote:
> Sent from phone, thus brief.
> Am 03.06.2015 15:58 schrieb "Brian Knox" :
>>
>>
>> I'm a member of the zeromq team :)
>
>
> I know ;)
>
>> What would I need to do?
>
>
> Join the rsyslog release team and keep an eye especially on zmq. As I
wrote
>
> is just something we need to newly setup.
>>
>>
>> Brian
>>
>> On Wed, Jun 3, 2015 at 9:56 AM, Rainer Gerhards <
>
> rgerha...@hq.adiscon.com>
>>
>> wrote:
>>
>>> 2015-06-03 14:50 GMT+02:00 Brian Knox :
I've been working on the new zeromq plugins ( contrib/omczmq and
contrib/imczmq) for a bit, an
