Hello, I wanted to install cgit on Backtrack Linux, during the process it turned out that the GIT_URL variable in the Makefile isn't correct anymore, now it should be GIT_URL = http://download.openpkg.org/components/cache/git/git-$(GIT_VER).tar.gz and thus to decompress it *tar -xjf* becomes *tar -xzf.* * * Thank you for you software and good luck, Konstantin Tcholokachvili
--- shared.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/shared.c b/shared.c index 699c362..0d2a295 100644 --- a/shared.c +++ b/shared.c <at> <at> -8,7 +8,7 <at> <at> #include "cgit.h" #include <stdio.h> -#include <linux/limits.h> +#include <limits.h> struct cgit_repolist cgit_repolist; struct cgit_context ctx; -- -- 1.7.7.3
On Wed, Dec 14, 2011 at 09:50:48AM -0800, Norberto Lopes wrote: > --- > shared.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > Removing the include altogether is the right thing to here. I already submitted a patch [1] almost 5 months ago... No reply yet. Is it time to start a fork? :) > diff --git a/shared.c b/shared.c > index 699c362..0d2a295 100644 > --- a/shared.c > +++ b/shared.c > <at> <at> -8,7 +8,7 <at> <at> > > #include "cgit.h" > #include <stdio.h> > -#include <linux/limits.h> > +#include <limits.h> > > struct cgit_repolist cgit_repolist; > struct cgit_context ctx; > -- > 1.7.7.3 > > > _______________________________________________ > cgit mailing list > cgit@...(Continue reading)
On 12/14/2011 09:44 PM, Lukas Fleischer wrote: > On Wed, Dec 14, 2011 at 09:50:48AM -0800, Norberto Lopes wrote: >> --- >> shared.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> > > Removing the include altogether is the right thing to here. I already > submitted a patch [1] almost 5 months ago... No reply yet. Is it time to > start a fork? :) > yeah my thinking exactly. lars is extremely slow in responding, I already asked him to be faster and more interactive but that appearently didn't work. -- -- Ferry Huberts
+1 I actually have been applying the various patches in the one I build privately. It shouldn't be too hard to just commit them and have them available in github. I would rather not fork though as that would make one of us the decision makers for stuff that sometimes is not really easy to decide on (As an example, I just saw the discussion related to the ABI change for the nonset variable vs empty string). Instead I would gladly give a helping hand to Lars even though I am new around here.
On Fri, Dec 16, 2011 at 05:17:30PM -0800, Norberto Lopes wrote: > +1 > > I actually have been applying the various patches in the one I build > privately. It shouldn't be too hard to just commit them and have them > available in github. I would rather not fork though as that would make > one of us the decision makers for stuff that sometimes is not really > easy to decide on (As an example, I just saw the discussion related to > the ABI change for the nonset variable vs empty string). Instead I > would gladly give a helping hand to Lars even though I am new around > here. Committing patches you consider to be appropriate and publishing these in a public branch *is* forking. The other problem is that Lars didn't even reply to this list for ~3 months and didn't reply to private mails, also, so I'm not sure what to do apart from creating a fork... > > _______________________________________________ > cgit mailing list > cgit@... > http://hjemli.net/mailman/listinfo/cgit
Likewise. I too can lend a hand applying / testing submissions. I have done so already with a few that apply properly - some patches need to be re-submitted. I'm not sure if a fork is necessary yet; rather, someone Lars trusts to pull changes from. Also, tags haven't been signed since 0.8.1 (not sure if people care about that one). On 12/16/2011 08:17 PM, Norberto Lopes wrote: > +1 > > I actually have been applying the various patches in the one I build > privately. It shouldn't be too hard to just commit them and have them > available in github. I would rather not fork though as that would make > one of us the decision makers for stuff that sometimes is not really > easy to decide on (As an example, I just saw the discussion related to > the ABI change for the nonset variable vs empty string). Instead I > would gladly give a helping hand to Lars even though I am new around > here. > > _______________________________________________ > cgit mailing list > cgit@... > http://hjemli.net/mailman/listinfo/cgit -- -- Jamie Couture(Continue reading)
On Fri, Dec 16, 2011 at 09:01:23PM -0500, Jamie Couture wrote: > Likewise. I too can lend a hand applying / testing submissions. > I have done so already with a few that apply properly - some patches > need to be re-submitted. > > I'm not sure if a fork is necessary yet; rather, someone Lars trusts > to pull changes from. So, that means that *you* will decide which patches are ready for mainline inclusion and Lars only merges your branch from time to time? What's the difference to creating a fork then? Having one maintainer and several developers that the maintainer pulls from makes sense if there are loads of patches and/or different subsystems - it allows for sharing work efficiently. Or if there's a lot of patches that need to be rebased on each other and you want to assist with doing all the conflict resolution (which obviously isn't the case here). If you really want to help, what I'd suggest is: * Review and test patches. Reply to mails, give feedback and tell contributors if there's anything that should probably be fixed. The more people review, the better it helps Lars. * Try to contact Lars and ask him if there's anything else you can do to improve his response time. If he doesn't react for another 4 weeks or says that he won't be able to spend any time on developing cgit in the near future, we should find a new maintainer or start off a fork... > > Also, tags haven't been signed since 0.8.1 (not sure if people care(Continue reading)
On 12/17/2011 06:24 AM, Lukas Fleischer wrote: > On Fri, Dec 16, 2011 at 09:01:23PM -0500, Jamie Couture wrote: >> Likewise. I too can lend a hand applying / testing submissions. >> I have done so already with a few that apply properly - some patches >> need to be re-submitted. >> >> I'm not sure if a fork is necessary yet; rather, someone Lars trusts >> to pull changes from. > So, that means that *you* will decide which patches are ready for > mainline inclusion and Lars only merges your branch from time to time? No, I'm not self serving - I wasn't referring to myself at all; it was merely a suggestion. > What's the difference to creating a fork then? Having one maintainer and > several developers that the maintainer pulls from makes sense if there > are loads of patches and/or different subsystems - it allows for sharing > work efficiently. Or if there's a lot of patches that need to be rebased > on each other and you want to assist with doing all the conflict > resolution (which obviously isn't the case here). > > If you really want to help, what I'd suggest is: > > * Review and test patches. Reply to mails, give feedback and tell > contributors if there's anything that should probably be fixed. The > more people review, the better it helps Lars. > > * Try to contact Lars and ask him if there's anything else you can do to > improve his response time. If he doesn't react for another 4 weeks or > says that he won't be able to spend any time on developing cgit in the > near future, we should find a new maintainer or start off a fork...(Continue reading)
RSS Feed43 | |
|---|---|
246 | |
179 | |
20 | |
21 | |
7 | |
42 | |
147 | |
29 | |
4 | |
7 | |
6 | |
4 | |
20 | |
83 | |
34 | |
39 | |
14 | |
36 | |
20 | |
30 | |
37 | |
60 | |
85 | |
32 | |
38 | |
75 |
