Dear Sir/Madam,
We are writing in to express our business interest in your company’s products. Please send us the information on all products available. It would be appreciated if you can send brochures and price lists for the entire range of products.
Thank you in advance, and i look forward to receive the requested details from you.
Sincerely,
Kent Creek
Raymond E Frost & Associates
39510 Paseo Padre Pkwy
Fremont, CA 94538
251-225-6117
Dear Beneficiary,
After signing the Giving Pledge in 2019, I decided I was going to give away at least half of my fortune to charity and towards improving the lives of those in dire need of immediate support as a result of the Covid-19 pandemic. So far I have been able to give out $12 billion USD in donations to charities, schools, churches, businesses and individuals across the globe through The Scott Foundation. I'm currently donating another $4 billion.
An online polling was conducted by The Scott Foundation from which your email emerged as one of the lucky winners of $6,850,000.00 USD donation grant from me. You are to contact THE SCOTT FOUNDATION by replying to this email for more information if you're interested in receiving this donation.
Congratulations.
Yours Sincerely
Mackenzie Scott.
On Thu, Sep 1, 2022, at 1:31 PM, Reinier Kuipers wrote:
>
> I'm working to fix the y2038 issue for an existing sama5d3-based
> product. This involves updating the kernel and glibc to appropriate
> versions (5.10 and 2.35.1 respectively) and I got things running up to
> a state where, from userspace, both date and hwclock commands have no
> issue accepting dates beyond 2038. However, even with the RTC_HCTOSYS
> and RTC_HCTOSYS_DEVICE options configured correctly, the RTC driver
> fails to initialize the system clock at bootup.
>
> Some digging in rtc/class.c::rtc_hctosys() indicates that
> do_settimeofday64() is deliberately not executed on systems with
> BITS_PER_LONG==32 and a second counter higher than INT_MAX. I assumed
> that the work on 64-bits timestamps was already fully implemented for
> 32-bit systems as well, so my gut feel is that this
> BITS_PER_LONG/INT_MAX check has become unnecessary. A test build with
> these checks disabled results in correct time initialization at bootup
> with, at a glance, no adverse effects. Does anybody here know whether
> do_settimeofday64() is robust on 32-bit systems or that the checks
> are still required to prevent further breakage?
Please see commit b3a5ac42ab18 ("rtc: hctosys: Ensure system time
doesn't overflow time_t") and https://github.com/systemd/systemd/issues/1143
for the problem that originally caused this to be added.
Removing this check would probably break systemd again for machines
that return a post-y2038 time with systemd built on 32-bit time_t.
The only reliable fix I can see would be to disable
CONFIG_RTC_HCTOSYS_DEVICE. I think this is Alexandre's plan
for the long run anyway, but I don't know if there has been any
progress in convincing distros to turn it off.
Arnd
