Re: "Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4" [really: list interface replacement generates bad textual content]

From: Mark Millard via freebsd-bugs <freebsd-bugs_at_freebsd.org>
Date: Tue, 18 May 2021 01:55:26 -0700
On 2021-May-18, at 01:39, Baptiste Daroussin <bapt at FreeBSD.org> wrote:

> On Tue, May 18, 2021 at 12:08:36AM -0700, Mark Millard wrote:
>> On 2021-May-18, at 00:03, Mark Millard <marklmi at yahoo.com> wrote:
>> 
>>> 
>>> On 2021-May-17, at 23:55, Mark Millard <marklmi at yahoo.com> wrote:
>>> 
>>>> On 2021-May-17, at 23:37, Baptiste Daroussin <bapt at FreeBSD.org> wrote:
>>>>> 
>>>>> 
>>>>> 18 mai 2021 06:50:03 Mark Millard <marklmi_at_yahoo.com>:
>>>>> 
>>>>>> On 2021-May-15, at 22:22, Baptiste Daroussin <bapt_at_FreeBSD.org> wrote:
>>>>>> 
>>>>>> 
>>>>>>> 16 mai 2021 05:29:07 Mark Millard <marklmi_at_yahoo.com>:
>>>>>>> 
>>>>>>>> In exploring I've seen various web-page presentation of
>>>>>>>> freebsd-bugs messages that seem to be messed up. An
>>>>>>>> example is:
>>>>>>>> 
>>>>>>>> . . .
>>>>>>> 
>>>>>>> Nice catch, I will fix it
>>>>>>> 
>>>>>> 
>>>>>> The extra text disappeared when I later looked at the
>>>>>> pages via the URLs.
>>>>>> 
>>>>>> But I've run into another oddity. I did a google
>>>>>> search for:
>>>>>> 
>>>>>> "Comparing the OverDrive 1000 (A57) vs. MACCHIATObin"
>>>>>> 
>>>>>> and then used the 1st link shown, the one from the text:
>>>>>> 
>>>>>> QUOTE
>>>>>> https://lists.freebsd.org › freebsd-arm › 2019-December
>>>>>> Comparing the OverDrive 1000 (A57) vs. MACCHIATObin ...
>>>>>> Dec 2, 2019 — Comparing the OverDrive 1000 (A57) vs. MACCHIATObin Double Shot (A72) for buildworld and via a CPU/cache/RAM tradeoff-exploring ...
>>>>>> END QUOTE
>>>>>> 
>>>>>> which has the link (it is for one of my old messages):
>>>>>> 
>>>>>> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwiPhp3OtdLwAhVH6Z4KHaXQC68QFjAAegQIAxAD&url=https%3A%2F%2Flists.freebsd.org%2Fpipermail%2Ffreebsd-arm%2F2019-December%2F020854.html&usg=AOvVaw2VHrNUGc-Vce4CjAmTufxq
>>>>>> 
>>>>>> Or, extracting/converting the relevant part of that text:
>>>>>> 
>>>>>> https://lists.freebsd.org/pipermail/freebsd-arm/2019-December/020854.html
>>>>>> 
>>>>>> This now takes me to the wrong message on the list, one titled:
>>>>>> 
>>>>>> Re: 64 bit ARM systems with more than four cores Ed Maste
>>>>>> 
>>>>>> Turns out that the my old message now shows up as 2 later
>>>>>> by number (020854 -> 020856):
>>>>>> 
>>>>>> https://lists.freebsd.org/pipermail/freebsd-arm/2019-December/020856.html
>>>>>> 
>>>>>> gets to the message with the correct title.
>>>>>> 
>>>>>> It appears that the numbering has not been preserved
>>>>>> in the conversion. This can make google search results
>>>>>> that point into the (older) freebsd lists
>>>>>> problematical.
>>>>>> 
>>>>>> 
>>>>>> ===
>>>>>> Mark Millard
>>>>>> marklmi at yahoo.com
>>>>>> ( dsl-only.net went
>>>>>> away in early 2018-Mar)
>>>>> 
>>>>> 99.9% of the tume the numbering is preserved, sometimes it is not given the weirdness of the things that happened in the past. i will dig into this specific case to see what I can do. But don t expect much here.
>>>>> 
>>>> 
>>>> FYI:
>>>> 
>>>> In my "binary search inspired" looking around everything
>>>> I looked at that was old but more recent than 2014-Dec-23
>>>> had the offset of 2. Everything older than 2014-Dec-10
>>>> worked. Those dates are as close together as I got.
>>>> 
>>>> (Finding things that have useful google search matches in
>>>> a time frame is messy so the results are limited. It
>>>> would be nice to find a better way to looking up old
>>>> references.)
>>>> 
>>>> Example:
>>>> 
>>>> "lsof on FreeBSD/arm" goggle search click through to page
>>>> 
>>>> vs.:
>>>> 
>>>> Tuesday, 23 December 2014
>>>> . . . 
>>>> 	• Re: lsof on FreeBSD/arm Larry Rosenman 
>>>> 	• [Differential] [Commented On] D1317: Build gperf as a dependency before gcc for arm releases emaste (Ed Maste) 
>>>> 	• [Differential] [Updated, 8 lines] D1317: Build gperf as a dependency before gcc for arm releases emaste (Ed Maste) 
>>>> 
>>>> It gets on to the message for last line (still off by two for the
>>>> number, like what I reported already):
>>>> 
>>>> By contrast:
>>>> 
>>>> "watchdogd not working anymore (since r273154+)" google search click through
>>>> 
>>>> vs.:
>>>> 
>>>> Wednesday, 10 December 2014
>>>> . . .
>>>> 	• Re: RPi - watchdogd not working anymore (since r273154+) Andreas Schwarz 
>>>> 
>>>> worked.
>>> 
>>> A different possible oddity that I just noticed is that
>>> the old system used UTC dates/times, such as:
>>> 
>>> Mark Millard marklmi at yahoo.com 
>>> Sat May 1 19:50:18 UTC 2021
>>> 
>>> (from freebsd-git).
>>> 
>>> But the new one uses various time zones (the
>>> senders time zone?), such as:
>>> 
>>> From: Mark Millard via freebsd-arm <freebsd-arm_at_freebsd.org> 
>>> Date: Sat, 15 May 2021 14:43:45 -0700
>>> 
>>> (from freebsd-arm).
>>> 
>> 
>> Well . . .
>> 
>> freebsd-arm's messages have a UTC time after the message, such as:
>> 
>> Received on Sat May 15 2021 - 21:43:45 UTC
>> 
>> so both time zones are available. It might be deliberate.
> 
> After analysis, freebsd-bugs mailing list archives have been edited manually
> multiple times in the last 18 years, making it impossible to regenerates in a
> reliable manner archive with compatible URL.
> 
> This happenned too often to be able to be easily fixed.

Good to know. Thanks for checking.

Just for the record: I've also discovered that the:

"watchdogd not working anymore (since r273154+)"

is not a match and still has the difference of 2:

Wednesday, 10 December 2014
. . .
	• Re: RPi - watchdogd not working anymore (since r273154+) Ian Lepore 
	• Re: latest VM images fail to compile for ARM Ed Maste 
	• Re: RPi - watchdogd not working anymore (since r273154+) Andreas Schwarz 

The text on the google webpage before clicking on the
link matches material from the Ian L. message (such
as "15:23:07 UTC") but goes to the Andreas S. message
when clicked.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Received on Tue May 18 2021 - 08:55:26 UTC

Original text of this message