You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(11) |
|
2
(5) |
3
(11) |
4
(13) |
5
(1) |
6
(15) |
7
(1) |
8
(1) |
|
9
(2) |
10
(4) |
11
(15) |
12
(2) |
13
(12) |
14
(2) |
15
(3) |
|
16
(1) |
17
(16) |
18
(1) |
19
(32) |
20
(19) |
21
(3) |
22
|
|
23
|
24
(4) |
25
|
26
(1) |
27
(19) |
28
(4) |
29
(2) |
|
30
(3) |
|
|
|
|
|
|
|
From: Robert W. <rj...@ke...> - 2003-11-17 17:46:50
|
CVS commit by rjwalsh: Add a facility for tracking open file descriptors. Information about still open files is dumped out exit. Enabled using the --track-fds switch. A corecheck/tests/fdleak_cmsg.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright] A corecheck/tests/fdleak_cmsg.stderr.exp 1.1 A corecheck/tests/fdleak_cmsg.vgtest 1.1 A corecheck/tests/fdleak_creat.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright] A corecheck/tests/fdleak_creat.stderr.exp 1.1 A corecheck/tests/fdleak_creat.vgtest 1.1 A corecheck/tests/fdleak_dup.c 1.1 [no copyright] A corecheck/tests/fdleak_dup.stderr.exp 1.1 A corecheck/tests/fdleak_dup.vgtest 1.1 A corecheck/tests/fdleak_dup2.c 1.1 [no copyright] A corecheck/tests/fdleak_dup2.stderr.exp 1.1 A corecheck/tests/fdleak_dup2.vgtest 1.1 A corecheck/tests/fdleak_fcntl.c 1.1 [no copyright] A corecheck/tests/fdleak_fcntl.stderr.exp 1.1 A corecheck/tests/fdleak_fcntl.vgtest 1.1 A corecheck/tests/fdleak_ipv4.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright] A corecheck/tests/fdleak_ipv4.stderr.exp 1.1 A corecheck/tests/fdleak_ipv4.stdout.exp 1.1 A corecheck/tests/fdleak_ipv4.vgtest 1.1 A corecheck/tests/fdleak_open.c 1.1 [no copyright] A corecheck/tests/fdleak_open.stderr.exp 1.1 A corecheck/tests/fdleak_open.vgtest 1.1 A corecheck/tests/fdleak_pipe.c 1.1 [no copyright] A corecheck/tests/fdleak_pipe.stderr.exp 1.1 A corecheck/tests/fdleak_pipe.vgtest 1.1 A corecheck/tests/fdleak_socketpair.c 1.1 [no copyright] A corecheck/tests/fdleak_socketpair.stderr.exp 1.1 A corecheck/tests/fdleak_socketpair.vgtest 1.1 A corecheck/tests/filter_fdleak 1.1 M +23 -3 corecheck/tests/Makefile.am 1.14 M +7 -0 coregrind/vg_include.h 1.155 M +16 -0 coregrind/vg_main.c 1.122 M +88 -4 coregrind/vg_mylibc.c 1.57 M +356 -7 coregrind/vg_syscalls.c 1.56 M +9 -0 coregrind/docs/coregrind_core.html 1.17 M +39 -0 include/vg_kerneliface.h 1.6 M +14 -0 include/vg_skin.h 1.100 |
|
From: Ashley P. <as...@pi...> - 2003-11-17 13:02:21
|
On Mon, 2003-11-17 at 12:24, Dirk Mueller wrote: > On Monday 17 November 2003 13:11, Ashley Pittman wrote: > > > I like it (roughly) as it is but it would be nice if the 'trimmed' > > messages contained a link to the full commit so I could read them if I > > wanted to. > > Well, the commit logs still have the information which files were modified and > which revisions there are. we have a script to generate a diff from that. You might have a script to do that but I don't, I *could* write a script to grok the email for me but it would be easier if I didn't have to. If this can't be done then I vote for a larger trim threshold. Ashley, |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 12:40:13
|
On Mon, 17 Nov 2003, Dirk Mueller wrote: > > Fair enough if you're getting commit logs for all of KDE. (People really > > do that? Wow.) > > Sure, thats the point of commit logs anyway (peer review and all that). Yeah, but particular individuals getting all logs for all of KDE? > Anyway, if you don't like the atomic commit logs at all we can just switch to > the sourceforge-style script (which exists for a far longer time than sf but > anyway). I have no complaints about the atomicity of the logs, that is a clear improvement over the SF-style logs; I just want to see all of each diff :) N |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 12:30:01
|
On Monday 17 November 2003 13:15, Nicholas Nethercote wrote: > Fair enough if you're getting commit logs for all of KDE. (People really > do that? Wow.) Sure, thats the point of commit logs anyway (peer review and all that). > Assuming this is just for Valgrind commits, I say the higher the better; > the bigger it is, the more likely I want to look at it, and we don't have > many big commits. Trimming isn't important. Others may disagree. Yeah. like those complaining that they get commit logs at all :) Anyway, if you don't like the atomic commit logs at all we can just switch to the sourceforge-style script (which exists for a far longer time than sf but anyway). |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 12:25:40
|
On Monday 17 November 2003 13:11, Ashley Pittman wrote: > I like it (roughly) as it is but it would be nice if the 'trimmed' > messages contained a link to the full commit so I could read them if I > wanted to. Well, the commit logs still have the information which files were modified and which revisions there are. we have a script to generate a diff from that. |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 12:16:38
|
On Mon, 17 Nov 2003, Dirk Mueller wrote: > Yeah.. The main point is that we want people involved in KDE development to be > subscribed on kde-cvs. And many claimed that they're not going to subscribe > if there are 500kb diffs appended to each mail, which is understandable, > because there is not one commit per day, or ten commits per day or even a > hundred commits per day but actually many many more. Fair enough if you're getting commit logs for all of KDE. (People really do that? Wow.) > Anyway, so I should raise the limit.. to 16kb? 160kb? 1600kb ? Assuming this is just for Valgrind commits, I say the higher the better; the bigger it is, the more likely I want to look at it, and we don't have many big commits. Trimming isn't important. Others may disagree. N |
|
From: Ashley P. <as...@pi...> - 2003-11-17 12:12:18
|
On Mon, 2003-11-17 at 11:58, Dirk Mueller wrote: > Yeah.. The main point is that we want people involved in KDE development to be > subscribed on kde-cvs. And many claimed that they're not going to subscribe > if there are 500kb diffs appended to each mail, which is understandable, > because there is not one commit per day, or ten commits per day or even a > hundred commits per day but actually many many more. But I'm not subscribed to kde-cvs, I'm subscribed to valgrind-developers so that argument is largely bogus. > Anyway, so I should raise the limit.. to 16kb? 160kb? 1600kb ? I like it (roughly) as it is but it would be nice if the 'trimmed' messages contained a link to the full commit so I could read them if I wanted to. Ashley, |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 11:59:13
|
On Monday 17 November 2003 12:45, Nicholas Nethercote wrote: > see, where the commit log message isn't sufficient to understand what just > happened. Any chance of this being changed, or is it a KDE-wide thing? Sure, it can be changed when I know how it should behave.. :) > is fine. The SF.net messages did this sometimes, I think; but they never > omitted changes completely. Yeah.. The main point is that we want people involved in KDE development to be subscribed on kde-cvs. And many claimed that they're not going to subscribe if there are 500kb diffs appended to each mail, which is understandable, because there is not one commit per day, or ten commits per day or even a hundred commits per day but actually many many more. Anyway, so I should raise the limit.. to 16kb? 160kb? 1600kb ? |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 11:57:34
|
CVS commit by nethercote: Added links to the new Bugzilla page from bugs.html and features.html. M +13 -10 bugs.html 1.6 M +11 -7 features.html 1.3 --- devel-home/valgrind/bugs.html #1.5:1.6 @@ -14,8 +14,14 @@ failures people seem to encounter in practice. <p> -If that fails, send it to the valgrind-users -<a href="lists.html">mailing list</a>. We try to respond to most bug -reports, but if we don't, it doesn't mean we are ignoring you; it may -well be that the bug has been reported before. +If that fails, please file a report using our +<a href="http://bugs.kde.org/enter_valgrind_bug.cgi">Bugzilla page</a>. +Patches for bugs are particularly welcome. Please note that this +Bugzilla page is new, and there may be some teething troubles. +<p> +If you have trouble with Bugzilla, or for some reason you don't think +Bugzilla is appropriate for your report (although it probably is), +contact the valgrind-users <a href="lists.html">mailing list</a>. We +try to respond to most bug reports, but if we don't, it doesn't mean we +are ignoring you; it may well be that the bug has been reported before. <p> When you report a bug, <i>please</i> give the following information: @@ -25,11 +31,8 @@ <li>The output of <code>valgrind -v</code>. </ul> -It may also be useful to include your Linux version, kernel version, and glibc -version. If you include all this information, you are much more likely to get -a useful response. -<p> -Patches for bugs are particularly welcome. +It may also be useful to include your Linux version, kernel version, and +glibc version. If you include all this information, you are much more +likely to get a useful response. <p> -We hope to have Bugzilla set up soon to deal with bug reports. <?php --- devel-home/valgrind/features.html #1.2:1.3 @@ -9,8 +9,15 @@ <center><h2>Feature Requests</h2></center> -To request a feature, please email the valgrind-users <a -href="lists.html">mailing list</a>. We try to respond to most feature -requests, but if we don't, it doesn't mean we are ignoring you, rather -that we don't have any particular comments. +If that fails, please use our +<a href="http://bugs.kde.org/enter_valgrind_bug.cgi">Bugzilla page</a>; +make an entry with the severity "wishlist". Please note that this +Bugzilla page is new, and there may be some teething troubles. +<p> +If you have trouble with Bugzilla, or for some reason you don't think +Bugzilla is appropriate for your request (although it probably is), +contact the valgrind-users <a href="lists.html">mailing list</a>. We +try to respond to most feature requests, but if we don't, it doesn't +mean we are ignoring you, rather that we don't have any particular +comments. <p> Please note that we cannot satisfy many feature requests. A feature @@ -19,7 +26,4 @@ implementing a feature, that will help your chances too. <p> -We hope to have Bugzilla set up soon to deal with feature requests. -<p> - <?php |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 11:46:01
|
On Mon, 17 Nov 2003, Dirk Mueller wrote: > > Sometimes these log messages contain the diff, and sometimes they don't. > > Is there a reason why/why not? > > there is a diff when it is < 3kb. > > > I like seeing diffs (although I don't mind > > it if really big ones are trimmed a bit). > > Thats what it does :) We have different interpretations of "big" and "trimmed" :) 3kb is pretty small. That commit I just made was quite trivial, and it didn't make it. Changes bigger than 3kb are really the ones you want to see, where the commit log message isn't sufficient to understand what just happened. Any chance of this being changed, or is it a KDE-wide thing? As for trimming, I meant if you have 1000 removed lines, and 1000 new lines, having something like [500 removed lines skipped] is fine. The SF.net messages did this sometimes, I think; but they never omitted changes completely. N |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 11:19:23
|
On Monday 17 November 2003 12:03, Nicholas Nethercote wrote: > Sometimes these log messages contain the diff, and sometimes they don't. > Is there a reason why/why not? there is a diff when it is < 3kb. > I like seeing diffs (although I don't mind > it if really big ones are trimmed a bit). Thats what it does :) |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 11:19:23
|
On Monday 17 November 2003 04:00, Robert Walsh wrote: > Any idea why gcc (version 3.3.2-1) is spitting this warning out when I > compile on Fedora Core 1 (I haven't tried on anything else, btw): Because we compile with -Winline. Its not a compile error though, merely a warning. . |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 11:04:35
|
On Mon, 17 Nov 2003, Nicholas Nethercote wrote: > Made the warning clearer when you try to catch SIGKILL/SIGSTOP. Also made it > clearer what's wrong if you try to catch signals 32 and 33; they're not bad > signals, just used internally. Updated one regtest accordingly. > > > M +10 -6 corecheck/tests/sigkill.stderr.exp 1.4 > M +17 -4 coregrind/vg_signals.c 1.50 Sometimes these log messages contain the diff, and sometimes they don't. Is there a reason why/why not? I like seeing diffs (although I don't mind it if really big ones are trimmed a bit). N |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 10:38:44
|
CVS commit by nethercote: Made the warning clearer when you try to catch SIGKILL/SIGSTOP. Also made it clearer what's wrong if you try to catch signals 32 and 33; they're not bad signals, just used internally. Updated one regtest accordingly. M +10 -6 corecheck/tests/sigkill.stderr.exp 1.4 M +17 -4 coregrind/vg_signals.c 1.50 |
|
From: Robert W. <rj...@du...> - 2003-11-17 03:00:32
|
Any idea why gcc (version 3.3.2-1) is spitting this warning out when I compile on Fedora Core 1 (I haven't tried on anything else, btw): vg_stabs.c: In function `atoi': vg_stabs.c:304: warning: inlining failed in call to `isdigit' vg_stabs.c:368: warning: called from here vg_stabs.c: In function `atou': vg_stabs.c:304: warning: inlining failed in call to `isdigit' vg_stabs.c:389: warning: called from here Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 00:17:50
|
On Sunday 16 November 2003 12:32, Johan Rydberg wrote: > > Has this list turned into just a CVS commit list? Why not create a > separate valgrind-commit or valgrind-cvs list? It kinda PITA to > filter out all these messages from the normal discussions. Its very easy: filter or delete all messages containing the message header X-Commit-Directories: |