From kaber at trash.net Thu Sep 8 09:37:26 2011 From: kaber at trash.net (Patrick McHardy) Date: Thu, 08 Sep 2011 11:37:26 +0200 Subject: can we please make spammers harder to post new tickets? In-Reply-To: <20110828185111.GE23789@prithivi.gnumonks.org> References: <20110828185111.GE23789@prithivi.gnumonks.org> Message-ID: <4E688CD6.1080706@trash.net> Am 28.08.2011 20:51, schrieb Harald Welte: > Hi all, > > On Sun, Aug 28, 2011 at 05:08:34PM +0200, Allard Dijk wrote: >> On avg. we get 2 spam tickets a day on Trac. Can you add some level of >> spam protection to add a ticket? > > as Patrick is currently busy with the netfilter workshop, I have removed > TICKET_{CREATE,APPEND} for anonymous users. > > I've also deleted tickets 22-75 as well as 77-84 Thanks. > In the process I also discovered that the trac.db is _very_ large > (5.1GB) since it contains all the changes of a linux kernel .git tree > going back to when Linus started to use git. I guess this might > experience some of the performance problems I'm sometimes experiencing > on the machine... Yes, its very slow interacting with git. Do you any hints how to avoid this except disabling trac<->git interaction entirely? From laforge at gnumonks.org Thu Sep 8 10:53:26 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 8 Sep 2011 12:53:26 +0200 Subject: can we please make spammers harder to post new tickets? In-Reply-To: <4E688CD6.1080706@trash.net> References: <20110828185111.GE23789@prithivi.gnumonks.org> <4E688CD6.1080706@trash.net> Message-ID: <20110908105326.GF30888@prithivi.gnumonks.org> Hi Patrick, On Thu, Sep 08, 2011 at 11:37:26AM +0200, Patrick McHardy wrote: > Yes, its very slow interacting with git. Do you any hints how to > avoid this except disabling trac<->git interaction entirely? I think for something as large as the linux kernel tree it might make sense to disable it completely. Unfortunately the support for 'inceremntal repositories' was never fully implemented in git. This way you could have a small repo on dect.osmocom.org containing only those few commits that relate to DECT. Another option would be to go for mysql or postgresql as database backend. But even then, the load on the system (hosting dozens of virtual machines for various projects) is probably still going to be quite big... Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kaber at trash.net Thu Sep 8 16:37:34 2011 From: kaber at trash.net (Patrick McHardy) Date: Thu, 08 Sep 2011 18:37:34 +0200 Subject: can we please make spammers harder to post new tickets? In-Reply-To: <20110908105326.GF30888@prithivi.gnumonks.org> References: <20110828185111.GE23789@prithivi.gnumonks.org> <4E688CD6.1080706@trash.net> <20110908105326.GF30888@prithivi.gnumonks.org> Message-ID: <4E68EF4E.9020703@trash.net> Am 08.09.2011 12:53, schrieb Harald Welte: > Hi Patrick, > > On Thu, Sep 08, 2011 at 11:37:26AM +0200, Patrick McHardy wrote: > >> Yes, its very slow interacting with git. Do you any hints how to >> avoid this except disabling trac<->git interaction entirely? > > I think for something as large as the linux kernel tree it might make > sense to disable it completely. Unfortunately the support for > 'inceremntal repositories' was never fully implemented in git. This way > you could have a small repo on dect.osmocom.org containing only those > few commits that relate to DECT. > > Another option would be to go for mysql or postgresql as database > backend. But even then, the load on the system (hosting dozens of > virtual machines for various projects) is probably still going to be > quite big... I don't think I need that, the gitweb interface should be enough, I'll just disable it completely. Thanks! From jfreeman at peacecom.net Sat Sep 3 02:05:49 2011 From: jfreeman at peacecom.net (Joe Freeman) Date: Sat, 3 Sep 2011 02:05:49 +0000 Subject: compile failure Message-ID: <26B5F8A3CDAD0B4BBFD8F2ED973E370C0B0B33@MB1.inbox01.com> Greetings- I'm trying to compile from the git sources, based on the 2.6 kernel included on the website. This is an an x86_64 install (originally CentOS 6, but I've got kernel 3.0.4 running on it now)... I'm having a heck of a time getting the DECT stuff to compile in the kernel. my make keeps failing- In file included from /home/jfreeman/linux-2.6/include/net/dect/dect.h:147, from /home/jfreeman/linux-2.6/drivers/dect/coa/sc1442x.c:19: /home/jfreeman/linux-2.6/include/net/dect/identities.h:55: error: field ?arc? has incomplete type make[4]: *** [drivers/dect/coa/sc1442x.o] Error 1 make[3]: *** [drivers/dect/coa] Error 2 make[2]: *** [drivers/dect] Error 2 make[1]: *** [drivers] Error 2 make: *** [sub-make] Error 2 That's the most recent failure, after I removed the enum dect_ari_classes from dect_netlink.h Anyone have any thoughts or suggestions? Thanks- Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaber at trash.net Thu Sep 8 09:36:41 2011 From: kaber at trash.net (Patrick McHardy) Date: Thu, 08 Sep 2011 11:36:41 +0200 Subject: compile failure In-Reply-To: <26B5F8A3CDAD0B4BBFD8F2ED973E370C0B0B33@MB1.inbox01.com> References: <26B5F8A3CDAD0B4BBFD8F2ED973E370C0B0B33@MB1.inbox01.com> Message-ID: <4E688CA9.7050607@trash.net> Am 03.09.2011 04:05, schrieb Joe Freeman: > Greetings- > > I'm trying to compile from the git sources, based on the 2.6 kernel > included on the website. This is an an x86_64 install (originally CentOS > 6, but I've got kernel 3.0.4 running on it now)... > > I'm having a heck of a time getting the DECT stuff to compile in the > kernel. my make keeps failing- > > In file included from /home/jfreeman/linux-2.6/include/net/dect/dect.h:147, > from > /home/jfreeman/linux-2.6/drivers/dect/coa/sc1442x.c:19: > /home/jfreeman/linux-2.6/include/net/dect/identities.h:55: error: field > ?arc? has incomplete type > make[4]: *** [drivers/dect/coa/sc1442x.o] Error 1 > make[3]: *** [drivers/dect/coa] Error 2 > make[2]: *** [drivers/dect] Error 2 > make[1]: *** [drivers] Error 2 > make: *** [sub-make] Error 2 > > > That's the most recent failure, after I removed the enum > dect_ari_classes from dect_netlink.h > > Anyone have any thoughts or suggestions? You shouldn't remove it from the file in the kernel itself, just from the headers installed for userspace in /usr/include/linux. I'll probably look into fixing this properly by removing it from the kernel entirely soon.