diff for duplicates of <4B0BE935.1050708@ladisch.de>

diff --git a/a/1.txt b/N1/1.txt
index 3d8ce0a..3072f3b 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,7 +1,7 @@
 Jean Delvare wrote:
 > On Tue, 24 Nov 2009 09:43:29 +0100, Clemens Ladisch wrote:
 > > In any case, it might make more sense to show such values as something
-> > like "20 째C below maximum".
+> > like "20 °C below maximum".
 > 
 > I think so, yes. Now the difficulty is to come up with a suitable sysfs
 > interface. Dropping the current interface altogether doesn't sound
@@ -27,8 +27,8 @@ We could add this in parallel with the old interface.  If we wanted to.
 > temp1_input: 46000
 > temp1_relative: 70000
 > 
-> Old applications would display this as 46째C while new ones would
-> display "24째C below the limit".
+> Old applications would display this as 46°C while new ones would
+> display "24°C below the limit".
 
 In this case, temp1_relative is identical with temp1_max.  In the
 general case, there always must be some kind of limit (whether "max" or
@@ -46,7 +46,7 @@ relative anyway, so we could just define that temp#_max is the base;
 so we'd have "temp1_relative: true").
 
 > It may not be considered flexible enough though... For example it does
-> not support sensors with totally arbitrary scales (where 1000 != 1째C.)
+> not support sensors with totally arbitrary scales (where 1000 != 1°C.)
 
 When the scale differs but is _known_, the driver can just rescale its
 internal register values to millidegrees.
@@ -57,8 +57,3 @@ exported as "pwm#_target" or something like that.
 
 Best regards,
 Clemens
-
-_______________________________________________
-lm-sensors mailing list
-lm-sensors@lm-sensors.org
-http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
diff --git a/a/content_digest b/N1/content_digest
index fb52da8..a6f17e5 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -12,8 +12,8 @@
  "ref\04B0B9CB1.3090808@ladisch.de\0"
  "ref\020091124142654.76f4d166@hyperion.delvare\0"
  "From\0Clemens Ladisch <clemens@ladisch.de>\0"
- "Subject\0Re: [lm-sensors] [PATCH v3] k10temp: temperature sensor for AMD\0"
- "Date\0Tue, 24 Nov 2009 14:09:57 +0000\0"
+ "Subject\0Re: [PATCH v3] k10temp: temperature sensor for AMD Family 10h/11h CPUs\0"
+ "Date\0Tue, 24 Nov 2009 15:09:57 +0100\0"
  "To\0Jean Delvare <khali@linux-fr.org>\0"
  "Cc\0Serge Belyshev <belyshev@depni.sinp.msu.ru>"
   linux-kernel@vger.kernel.org
@@ -23,7 +23,7 @@
  "Jean Delvare wrote:\n"
  "> On Tue, 24 Nov 2009 09:43:29 +0100, Clemens Ladisch wrote:\n"
  "> > In any case, it might make more sense to show such values as something\n"
- "> > like \"20 \354\247\270C below maximum\".\n"
+ "> > like \"20 \302\260C below maximum\".\n"
  "> \n"
  "> I think so, yes. Now the difficulty is to come up with a suitable sysfs\n"
  "> interface. Dropping the current interface altogether doesn't sound\n"
@@ -49,8 +49,8 @@
  "> temp1_input: 46000\n"
  "> temp1_relative: 70000\n"
  "> \n"
- "> Old applications would display this as 46\354\247\270C while new ones would\n"
- "> display \"24\354\247\270C below the limit\".\n"
+ "> Old applications would display this as 46\302\260C while new ones would\n"
+ "> display \"24\302\260C below the limit\".\n"
  "\n"
  "In this case, temp1_relative is identical with temp1_max.  In the\n"
  "general case, there always must be some kind of limit (whether \"max\" or\n"
@@ -68,7 +68,7 @@
  "so we'd have \"temp1_relative: true\").\n"
  "\n"
  "> It may not be considered flexible enough though... For example it does\n"
- "> not support sensors with totally arbitrary scales (where 1000 != 1\354\247\270C.)\n"
+ "> not support sensors with totally arbitrary scales (where 1000 != 1\302\260C.)\n"
  "\n"
  "When the scale differs but is _known_, the driver can just rescale its\n"
  "internal register values to millidegrees.\n"
@@ -78,11 +78,6 @@
  "\n"
  "\n"
  "Best regards,\n"
- "Clemens\n"
- "\n"
- "_______________________________________________\n"
- "lm-sensors mailing list\n"
- "lm-sensors@lm-sensors.org\n"
- http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
+ Clemens
 
-1d2ba649e9fe9f47b67e2c9280b9fd65a15f10dc8109762e7a14ecd5d902c7d2
+f34cee384c51be1c23abb97d81f8ecf98f95b1c5fd56a031feeac82e454b1f74
