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
We had a new Power & CCT adjustable LED Flood Light Launched. Please
kindly check below for details.
This is a great solution to reduce your stock and still meet various
customer needs.
Product Feature:
* Remote control support live operation
* CCT adjustable (3000K, 4000K & 6500K)
* Up to 150lm/w @ 4000K
* 100%, 80% & 60% Power Adjustable
Kindly check the detailed product image in this Email.
Let me know if you are interested to have a sample.
Thank you and best regards,
If you would prefer not to receive our emails, please Unsubscribe
http://ris.eventbay.net/lists/lj392depvd577/unsubscribe/zn90451fdv210/fo600…