Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(6) |
Jun
(12) |
Jul
(46) |
Aug
(8) |
Sep
(27) |
Oct
(73) |
Nov
(56) |
Dec
(34) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(36) |
Feb
(33) |
Mar
(50) |
Apr
(66) |
May
(76) |
Jun
(63) |
Jul
(63) |
Aug
(26) |
Sep
(35) |
Oct
(34) |
Nov
(82) |
Dec
(99) |
2003 |
Jan
(152) |
Feb
(76) |
Mar
(146) |
Apr
(156) |
May
(71) |
Jun
(46) |
Jul
(42) |
Aug
(34) |
Sep
(32) |
Oct
(49) |
Nov
(66) |
Dec
(78) |
2004 |
Jan
(76) |
Feb
(48) |
Mar
(25) |
Apr
(78) |
May
(76) |
Jun
(71) |
Jul
(39) |
Aug
(53) |
Sep
(27) |
Oct
(26) |
Nov
(23) |
Dec
(29) |
2005 |
Jan
(53) |
Feb
(41) |
Mar
(48) |
Apr
(36) |
May
(29) |
Jun
(71) |
Jul
(61) |
Aug
(77) |
Sep
(49) |
Oct
(32) |
Nov
(27) |
Dec
(40) |
2006 |
Jan
(23) |
Feb
(48) |
Mar
(24) |
Apr
(31) |
May
(50) |
Jun
(42) |
Jul
(24) |
Aug
(140) |
Sep
(55) |
Oct
(43) |
Nov
(11) |
Dec
(18) |
2007 |
Jan
(15) |
Feb
(20) |
Mar
(99) |
Apr
(110) |
May
(140) |
Jun
(98) |
Jul
(90) |
Aug
(58) |
Sep
(86) |
Oct
(79) |
Nov
(137) |
Dec
(129) |
2008 |
Jan
(277) |
Feb
(321) |
Mar
(285) |
Apr
(373) |
May
(415) |
Jun
(328) |
Jul
(288) |
Aug
(469) |
Sep
(334) |
Oct
(570) |
Nov
(368) |
Dec
(376) |
2009 |
Jan
(401) |
Feb
(317) |
Mar
(373) |
Apr
(309) |
May
(280) |
Jun
(371) |
Jul
(504) |
Aug
(465) |
Sep
(231) |
Oct
(295) |
Nov
(271) |
Dec
(222) |
2010 |
Jan
(313) |
Feb
(231) |
Mar
(251) |
Apr
(166) |
May
(124) |
Jun
(83) |
Jul
(141) |
Aug
(195) |
Sep
(160) |
Oct
(204) |
Nov
(295) |
Dec
(206) |
2011 |
Jan
(262) |
Feb
(176) |
Mar
(168) |
Apr
(217) |
May
(70) |
Jun
(65) |
Jul
(89) |
Aug
(169) |
Sep
(125) |
Oct
(64) |
Nov
(116) |
Dec
(148) |
2012 |
Jan
(343) |
Feb
(352) |
Mar
(205) |
Apr
(151) |
May
(140) |
Jun
(103) |
Jul
(156) |
Aug
(221) |
Sep
(55) |
Oct
(150) |
Nov
(79) |
Dec
(77) |
2013 |
Jan
(95) |
Feb
(78) |
Mar
(157) |
Apr
(213) |
May
(220) |
Jun
(227) |
Jul
(275) |
Aug
(224) |
Sep
(156) |
Oct
(248) |
Nov
(338) |
Dec
(181) |
2014 |
Jan
(165) |
Feb
(299) |
Mar
(338) |
Apr
(315) |
May
(277) |
Jun
(186) |
Jul
(204) |
Aug
(212) |
Sep
(231) |
Oct
(152) |
Nov
(107) |
Dec
(167) |
2015 |
Jan
(197) |
Feb
(182) |
Mar
(135) |
Apr
(167) |
May
(192) |
Jun
(326) |
Jul
(311) |
Aug
(198) |
Sep
(84) |
Oct
(11) |
Nov
(3) |
Dec
(4) |
2016 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
|
1
(16) |
2
(7) |
3
|
4
|
5
(2) |
6
(2) |
7
(3) |
8
(3) |
9
(2) |
10
|
11
|
12
(2) |
13
(2) |
14
(11) |
15
(19) |
16
(9) |
17
|
18
|
19
(2) |
20
(11) |
21
(3) |
22
(3) |
23
(8) |
24
|
25
|
26
(17) |
27
(15) |
28
(21) |
29
(5) |
30
(3) |
|
From: Garrett Cooper <yanegomi@gm...> - 2010-04-07 16:48:02
|
On Wed, Apr 7, 2010 at 6:39 AM, Serge E. Hallyn <serue@...> wrote: > Quoting Mitani (mitani@...): >> Hi, [...] > Agreed, since this is LTP it's not right to expect "sane" > userspace-kernel combos. So we need to check both. Unfortunately > I won't have time to work with that this week. > > Even if I did, I'd have a guidance question for Garrett: Do we > want to assume that people will change kernels, but not libraries, > between compile/install and run of ltp? If so, then we can stick > with the autoconf checks for libraries+includes, and add a check > at runtime (as I believe was there originally) for the requisite > kernel support - file capabilities, bounding sets, and 64-bit > capabilities. Assuming that kernels remain constant between compile and install would be a nice thing to shoot for, but I personally on an embedded project [for instance] have compiled LTP once, not had the major libs change, but the kernel potentially changed, and then dropped in ltp and voila.. it worked perfectly fine. With that in mind, yes.. breaking that assumption would be painful, as many packagers actually compile and distribute one version of ltp as a package (debian for instance is one said example). > OTOH if you're ok with assuming kernel is same at ltp configure > and run, then we can do a test in autoconf which makes for a cleaner > run. Yes, it's fine to have runtime tests. The point that I've tried to make in the past (and partially failed) is that the following needs to be kept in mind: 1. Groups can backport patches from kernel versions; thus using kernel version checks to determine whether or not functionality A exists is dubious. It's better just to compile the functionality in such a way that the test works and let the group executing the test do so without hacking the test. 2. Compiling at runtime is no bueno for almost everything in the source tree. There are a handful of tests in the source tree that do do that, but by and large this is a bad idea as we aren't guaranteed to have a full compile toolchain on the running system -- only the build system. Thanks, -Garrett |
From: Serge E. Hallyn <serue@us...> - 2010-04-07 13:39:26
|
Quoting Mitani (mitani@...): > Hi, > > > -----Original Message----- > > From: Serge E. Hallyn [mailto:serue@...] > > Sent: Monday, April 05, 2010 10:22 PM > > To: Mitani > > Cc: ltp-list@... > > Subject: Re: [LTP] cap_bset_inh_bounds.c build failure > > > > Quoting Mitani (mitani@...): > > > Hi, > > > > > > I tried to build by using yesterday's git in my system (RHEL4.8 x86). > > > (ltp-dev-4837fee8a7c2de6a83c8927a574c792ca6dabe4e.tar.gz) > > > But build failed in "cap_bset_inh_bounds.c" with following message. > > > This is different from "cap_bounds_r.c"'s problem (another thread), > > I think > > > > > > ------------ > > > gcc -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall > > > -I/home/LTP/ltp-dev-20100401-3/testcases/kernel/include > > > -I../../../../include -I../../../../include -L../../../../lib > > > cap_bset_inh_bounds.c -lltp -lcap -o cap_bset_inh_bounds > > > cap_bset_inh_bounds.c:124: error: syntax error before numeric > > constant > > > cap_bset_inh_bounds.c:124: warning: type defaults to `int' in > > declaration of > > > `tst_resm' > > > cap_bset_inh_bounds.c:124: error: conflicting types for 'tst_resm' > > > ../../../../include/test.h:192: error: previous declaration of > > 'tst_resm' > > > was here > > > cap_bset_inh_bounds.c:124: error: conflicting types for 'tst_resm' > > > ../../../../include/test.h:192: error: previous declaration of > > 'tst_resm' > > > was here > > > cap_bset_inh_bounds.c:124: warning: data definition has no type or > > storage > > > class > > > cap_bset_inh_bounds.c:129: warning: type defaults to `int' in > > declaration of > > > `tst_exit' > > > cap_bset_inh_bounds.c:129: error: conflicting types for 'tst_exit' > > > ../../../../include/test.h:203: error: previous declaration of > > 'tst_exit' > > > was here > > > cap_bset_inh_bounds.c:129: error: conflicting types for 'tst_exit' > > > ../../../../include/test.h:203: error: previous declaration of > > 'tst_exit' > > > was here > > > cap_bset_inh_bounds.c:129: warning: data definition has no type or > > storage > > > class > > > cap_bset_inh_bounds.c:130: error: syntax error before '}' token > > > ------------ > > > > > > In this source, the pair of "ifdef" start/end and the pair of > > > main() function's "parenthesis" are alternate, I think. > > > > > > > > > How about following patch? > > > > > > Signed-off-by : Tomonori Mitani <mitani@...> > > > > Yup - although really the #ifdef HAVE_LIBCAP should be redundant as > > the testcases/kernel/security/cap_bound/Makefile shouldn't compile > > cap_bounds at all if HAVE_LIBCAP is not defined. > > > > Yes. - In my system, this source is not problem. Your indication is > right. :-) > But, I manually had updated "libcap2" once. And after "./configure", > HAVE_LIBCAP is defined. Therefore, I noticed this error. > > The system which updated to "libcap2" will need solution of this > problem, I think. Agreed, since this is LTP it's not right to expect "sane" userspace-kernel combos. So we need to check both. Unfortunately I won't have time to work with that this week. Even if I did, I'd have a guidance question for Garrett: Do we want to assume that people will change kernels, but not libraries, between compile/install and run of ltp? If so, then we can stick with the autoconf checks for libraries+includes, and add a check at runtime (as I believe was there originally) for the requisite kernel support - file capabilities, bounding sets, and 64-bit capabilities. OTOH if you're ok with assuming kernel is same at ltp configure and run, then we can do a test in autoconf which makes for a cleaner run. thanks, -serge |
From: Mitani <mitani@ry...> - 2010-04-07 05:31:04
|
Hi, > -----Original Message----- > From: Serge E. Hallyn [mailto:serue@...] > Sent: Monday, April 05, 2010 10:22 PM > To: Mitani > Cc: ltp-list@... > Subject: Re: [LTP] cap_bset_inh_bounds.c build failure > > Quoting Mitani (mitani@...): > > Hi, > > > > I tried to build by using yesterday's git in my system (RHEL4.8 x86). > > (ltp-dev-4837fee8a7c2de6a83c8927a574c792ca6dabe4e.tar.gz) > > But build failed in "cap_bset_inh_bounds.c" with following message. > > This is different from "cap_bounds_r.c"'s problem (another thread), > I think > > > > ------------ > > gcc -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall > > -I/home/LTP/ltp-dev-20100401-3/testcases/kernel/include > > -I../../../../include -I../../../../include -L../../../../lib > > cap_bset_inh_bounds.c -lltp -lcap -o cap_bset_inh_bounds > > cap_bset_inh_bounds.c:124: error: syntax error before numeric > constant > > cap_bset_inh_bounds.c:124: warning: type defaults to `int' in > declaration of > > `tst_resm' > > cap_bset_inh_bounds.c:124: error: conflicting types for 'tst_resm' > > ../../../../include/test.h:192: error: previous declaration of > 'tst_resm' > > was here > > cap_bset_inh_bounds.c:124: error: conflicting types for 'tst_resm' > > ../../../../include/test.h:192: error: previous declaration of > 'tst_resm' > > was here > > cap_bset_inh_bounds.c:124: warning: data definition has no type or > storage > > class > > cap_bset_inh_bounds.c:129: warning: type defaults to `int' in > declaration of > > `tst_exit' > > cap_bset_inh_bounds.c:129: error: conflicting types for 'tst_exit' > > ../../../../include/test.h:203: error: previous declaration of > 'tst_exit' > > was here > > cap_bset_inh_bounds.c:129: error: conflicting types for 'tst_exit' > > ../../../../include/test.h:203: error: previous declaration of > 'tst_exit' > > was here > > cap_bset_inh_bounds.c:129: warning: data definition has no type or > storage > > class > > cap_bset_inh_bounds.c:130: error: syntax error before '}' token > > ------------ > > > > In this source, the pair of "ifdef" start/end and the pair of > > main() function's "parenthesis" are alternate, I think. > > > > > > How about following patch? > > > > Signed-off-by : Tomonori Mitani <mitani@...> > > Yup - although really the #ifdef HAVE_LIBCAP should be redundant as > the testcases/kernel/security/cap_bound/Makefile shouldn't compile > cap_bounds at all if HAVE_LIBCAP is not defined. > Yes. - In my system, this source is not problem. Your indication is right. :-) But, I manually had updated "libcap2" once. And after "./configure", HAVE_LIBCAP is defined. Therefore, I noticed this error. The system which updated to "libcap2" will need solution of this problem, I think. Thank you-- -Tomonori Mitani > Acked-by: Serge Hallyn <serue@...> > > > > > Index: ./testcases/kernel/security/cap_bound/cap_bset_inh_bounds.c > > ============ > > --- ./testcases/kernel/security/cap_bound/cap_bset_inh_bounds.c > 2010-04-01 > > 16:15:00.000000000 +0900 > > > +++ ./testcases/kernel/security/cap_bound/cap_bset_inh_bounds.c.ne > w > > 2010-04-01 17:27:23.000000000 +0900 > > @@ -39,11 +39,11 @@ > > > > int errno; > > > > +int main(int argc, char *argv[]) > > +{ > > #if HAVE_SYS_CAPABILITY_H > > #if HAVE_DECL_PR_CAPBSET_READ && HAVE_DECL_PR_CAPBSET_DROP > > #ifdef HAVE_LIBCAP > > -int main(int argc, char *argv[]) > > -{ > > int ret = 1; > > cap_value_t v[1]; > > cap_flag_value_t f; > > ============ > > > > > > Thank you-- > > > > -Tomonori Mitani > > > > > > > > > ------------------------------------------------------------------ > ------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > > Ltp-list mailing list > > Ltp-list@... > > https://lists.sourceforge.net/lists/listinfo/ltp-list |