I've invited you to fill in the following form:
QQ：2890057524，微信：13247602337（手机同号）在线体验测试效果！
To fill it in, visit:
https://docs.google.com/forms/d/e/1FAIpQLScIta2A_VwoZ50Or7N1TM3di6LZjYjTro-…
您好，冒昧打扰您了，
我司帮助外贸企业拓展全球业务，全球220多个国家，全球几百亿条客户信息，根据您
的需求，精准推荐给您，采购负责人马上就能联系。
微信：13247602337
QQ：2890057524
欢迎前来咨询体验
Google Forms: Create and analyse surveys.
Greetings from Amazon.com
The Bill of Lading document on your inbound shipment (FBAVHM3RS83L)
For your convenience, we have also attached a copy of the initial Bill of Lading to this email.
Your carrier contact information:
CENTRAL TRANSPORT INTERNATIONAL INC
You can track the status of all inbound shipments, online by visiting Seller Central at:
https://sellercentral.amazon.com/gp/ssof/shipping-queue.html
If you've examined your shipment, but still need assistance,
please contact Seller Support.
Thank you for using Fulfillment by Amazon.
Sincerely,
Amazon Services
--------------------------------------------------------------------------
This email was sent from a notification-only address that
cannot accept incoming email. Please do not reply to this message.
--------------------------------------------------------------------------
Your new invoice is now available.Please view/download your invoice.For questions about your invoice, or invoice payment, please call (800) 811-1648 Monday through Friday 8:00 am to 9:00 pm Eastern Time.For technical support questions regarding your electronic invoicing, please call 877-289-6418.Thank you for using UPS.This is a post only email; please do not respond to this message.Notice: This email message and all attachments transmitted with it may contain proprietary information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by electronic mail at customer.service(a)ups.com and delete this message and all copies and backups thereof. Thank you.
Attached you will find Invoice 4248403
Please use this document for processing your payment to Buyers Products Company.
For inquiries regarding this invoice, call our accounting department at (440) 752-5346.
Thank you for your valued business.
unsubscribe privacy policy
On Mon, Aug 17, 2020 at 03:00:24PM +0000, Roosen Henri wrote:
> On Mon, 2020-08-17 at 16:35 +0200, gregkh(a)linuxfoundation.org wrote:
> > On Mon, Aug 17, 2020 at 02:15:16PM +0000, Roosen Henri wrote:
> > > On Tue, 2020-06-09 at 16:18 +0200, Arnd Bergmann wrote:
> > > > On Tue, Jun 9, 2020 at 2:36 PM Roosen Henri <
> > > > Henri.Roosen(a)ginzinger.com> wrote:
> > > > > Hi Arnd,
> > > > >
> > > > > I hope you are well and could answer me a quick question.
> > > > >
> > > > > I've read on the kernel mailing-list that initially there was
> > > > > an
> > > > > intention to backport the final y2038 patches to v5.4. We're
> > > > > currently targeting to use the v5.4 LTS kernel for a project
> > > > > which
> > > > > should be y2038 compliant.
> > > > >
> > > > > I couldn't find all of the y2038-endgame patches in the current
> > > > > v5.4-stable branch. Are there any patches still required to be
> > > > > backported in order for v5.4 to be y2038 compliant, or can the
> > > > > remaining patches be ignored (because of only cleanup?)? Else,
> > > > > is
> > > > > there still an intention to get the v5.4 LTS kernel y2038
> > > > > compliant?
> > > >
> > > > I don't think there are currently any plans to merge my y2038-
> > > > endgame
> > > > branch
> > > > into the official linux-5.4 lts kernel, but you should be able to
> > > > just pull from
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=…
> > > >
> > > > and get the same results. If you see any problems with that,
> > > > please
> > > > report
> > > > that to me with Cc to the mailing list and perhaps gregkh, so I
> > > > can
> > > > see if
> > > > I can resolve it by rebasing my patches, or if he would like to
> > > > merge
> > > > the
> > > > patches.
> > >
> > > Pulling the y2038-endgame branch does lead to some conflicts, which
> > > are
> > > currently still kinda staightforward to solve.
> > >
> > > However I'd be very interested in getting this branch merged to
> > > v5.4,
> > > so we don't run into more difficult merge conflicts the coming
> > > years
> > > where the v5.4-LTS still gets stable updates (Dec, 2025) and
> > > possibly
> > > to get any related fixes from upstream.
> > >
> > > @Greg: any chance to get the y2038-endgame merged into v5.4.y?
> >
> > I have no idea what this really means, and what it entails, but odds
> > are, no :)
>
> I fully understand, thanks for your statement on this.
>
> >
> > Why not just use a newer kernel? Why are you stuck using a 5.4
> > kernel
> > for a device that has to live in 2038? That feels very foolish to
> > me...
>
> Oh I agree on that :) It's just that these are currently customer
> requirements.
Are you sure that customers really understand what they want?
Usually they want a well-supported, stable, system. Why do they care
about a specific kernel version? That feels odd.
Good luck!
greg k-h
On Mon, Aug 17, 2020 at 02:15:16PM +0000, Roosen Henri wrote:
> On Tue, 2020-06-09 at 16:18 +0200, Arnd Bergmann wrote:
> > On Tue, Jun 9, 2020 at 2:36 PM Roosen Henri <
> > Henri.Roosen(a)ginzinger.com> wrote:
> > > Hi Arnd,
> > >
> > > I hope you are well and could answer me a quick question.
> > >
> > > I've read on the kernel mailing-list that initially there was an
> > > intention to backport the final y2038 patches to v5.4. We're
> > > currently targeting to use the v5.4 LTS kernel for a project which
> > > should be y2038 compliant.
> > >
> > > I couldn't find all of the y2038-endgame patches in the current
> > > v5.4-stable branch. Are there any patches still required to be
> > > backported in order for v5.4 to be y2038 compliant, or can the
> > > remaining patches be ignored (because of only cleanup?)? Else, is
> > > there still an intention to get the v5.4 LTS kernel y2038
> > > compliant?
> >
> > I don't think there are currently any plans to merge my y2038-endgame
> > branch
> > into the official linux-5.4 lts kernel, but you should be able to
> > just pull from
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=…
> >
> > and get the same results. If you see any problems with that, please
> > report
> > that to me with Cc to the mailing list and perhaps gregkh, so I can
> > see if
> > I can resolve it by rebasing my patches, or if he would like to merge
> > the
> > patches.
>
> Pulling the y2038-endgame branch does lead to some conflicts, which are
> currently still kinda staightforward to solve.
>
> However I'd be very interested in getting this branch merged to v5.4,
> so we don't run into more difficult merge conflicts the coming years
> where the v5.4-LTS still gets stable updates (Dec, 2025) and possibly
> to get any related fixes from upstream.
>
> @Greg: any chance to get the y2038-endgame merged into v5.4.y?
I have no idea what this really means, and what it entails, but odds
are, no :)
Why not just use a newer kernel? Why are you stuck using a 5.4 kernel
for a device that has to live in 2038? That feels very foolish to me...
thanks,
greg k-h
Hi,
Worried about the event got cancelled/ Postponed?
You can still purchase the pre registered attendees list of Drive World
Conference & Expo. These contacts are permission based and the recipients
have agreed to be solicited.
Each record will contain details like: Contact Name, Title, Phone Number,
Physical address, State/City, Company Name, Company URL, and most
importantly verified email addresses.
Let me know if you are interested.
Regards,
Katie Davis | Inside Sales, USA & Europe|
Email : <mailto:katied@globaltradevisitors.com>
katied(a)globaltradevisitors.com
"If you don't wish to receive emails from us reply back with LEAVE OUT"
--------------------------------------------------------------------------------
This email newsletter was sent to you in graphical HTML format.
If you're seeing this version, your email program prefers plain text emails.
You can read the original version online:
https://ymlptr9.net/zxMlt3
--------------------------------------------------------------------------------
Greetings
Many organizations fail to respond to external and internal
environment which in turn affect the well-being of the organization
and may cause total shutdown and loss of business such as Nokia case.
Other organizations are considering the Marketing Mix along with the
change best practices to insure continued prosperity and revenues.The
study will also conclude the best leadership style that should be
associated with a change. This research is done to investigates the
best practices of organizational change and the best leadership theory
that could be used to implement change. It aims at helping
organizations in implementing a successful change, as well as the
marketing and leadership strategies of change adopted to insure
successful implantation of the change. This study seeks to identify
the most recurrent factors that drives organizational change, and to
illustrate methodologies for an effective change.
We kindly ask you to complete this quick 12 Questons Suervy in this
regard.
https://www.smartsurvey.co.uk/s/ChangeManagementleadershipstyle/
Many Thanks
_____________________________
Unsubscribe / Change Profile: https://ymlptr9.net/ugwhmwyqgsguqhjhbsgessyggemyse
Powered by YourMailingListProvider
As discussed before, I tried using the rebootstrap tool [1] to see what
problems come up once the entire distro gets rebuilt. Based on Lukasz'
recommendation, I tried the 'y2038_edge' branch with his experimental
glibc patches [2], using commit c2de7ee9461 dated 2020-02-17.
Here is a rough summary of what I tried, what worked, and what problems
I ran into:
* Building a Debian package from this was fairly straightforward, using
the 2.31 branch in the package git repository[3] after replacing the
debian/patches/git-updates.diff file with one generated from [2] and
disabling the hurd patches because of conflicts.
* After installing the modified x86 glibc package, I ran into a runtime
bug in [4], which needs to pass AT_FDCWD instead of 0 to avoid
ENOTDIR errors.
* Bootstrapping a regular time32 Debian armhf with this libc took me
a few days to get right, but that was mostly for getting familiar
with rebootstrap and running into known issues unrelated to time64
or the glibc changes.
* Actually building a time64 version of glibc turned out to be
harder, including some issues discussed on the libc mailing list[5]:
- Always setting -D_TIME_BITS=64 in the global compiler flags for
the distro breaks both the native 64-bit (x86_64) build and the
32-bit build, as glibc itself expects to be built without this.
- Removing the time32 symbols from the glibc shared object did not
work as they are still used (a lot) internally, and by the testsuite.
- I tried converting all the internal symbols to use the time64
variants with the correct types (e.g. __clock_gettime64() instead
of __clock_gettime()), but then ran into a lot of APIs that take
timespec/timeval/... arguments and pass them down into internal
functions. These seem to all be bugs that require adding a time64
version of the external ABI.
- After I abandoned that approach, I continued with a simple
patch to features.h that sets _TIME_BITS/_FILE_OFFSET_BITS based on
'#if !defined _LIBC && __TIMESIZE == 32', which ignores the bugs I
found earlier but got me a lot further.
- Building the i386 glibc with that patch, I ran into over 150
testsuite failures [6]. This looked like there was a fundamental
mistake on my side, but after I looked into a few of the failures,
most seemed to be either glibc or testsuite bugs that have to be
addressed individually. I considered giving up at this point,
but as Lukasz has said that he had successfully built a working
system using Yocto, I kept going anyway and marked these all as
expected failures in the debian package.
* There are a couple of noteworthy issues in glibc-y2038 I'd like to
point out in particular, though I'm sure these are not the only
important ones:
- The clock_nanosleep() prototype needed a '__THROW' annotation
to complete the build.
- The nptl and sunrpc portions have numerous interfaces with
'timeval' or 'timespec' arguments that each cause an ABI break.
- stat()/fstat()/lstat(), nanosleep(), wait3()/wait4(), ppoll_chk()
are some of the other interfaces that take a time_t based
argument and need to grow a time64 version to avoid an ABI mismatch.
- The timeval prototype appears to be broken, as it's missing
padding on architectures without native alignment of __time64
(e.g. i386) and on all big-endian architectures.
- some testcases hang in futex_wait() or clock_nanosleep()
because of incorrect timeout arguments, presumably from type
mismatches.
* There is an open question regarding the name of the Debian
architecture. For my experiments, I kept using the 'armhf' name
unmodified, though there seems to be a general feeling that using a
different name would be required to address the broad incompatibilities
between time32 and time64 versions of all the libraries in the
distro. Gradually changing them won't work because of the timeline and
the number of affected libraries. However, the new name of the distro
also implies having a distinct target triplet, which must then be known
by glibc along with everything else using config.guess/config.sub. I
expect this topic to require a lot more discussion.
* Continuing with the rebootstrap build despite the known glibc issues
and the open question on the architecture name went surprisingly
well, only two out of the 152 source packages I built had
compile-time problems:
- building the final gcc failed in libsanitizer, which has
compile-time checks to ensure some libc data structures have the
expected layout. It noticed that 'struct timeb' and 'struct dirent'
are different based on _TIME_BITS and _FILE_OFFSET_BITS. I disabled
the checks to be able to continue. To this properly, the library
has to learn about the new data structures as well. I opened a
bug report against the library[7].
- libpreludecpp12 failed to build because of checks for changes
in the exported functions, which are different with time64.
I disabled the checks. Once we have agreed on a new debian
architecture name, the symbols can be made arch specific.
* After everything was built, I tried installing the packages into
a chroot with qemu-debootstrap, which failed because I had
configured the glibc to assume it's running on a new kernel
while the qemu-user binary I had lacks the new syscalls.
I believe this is fixed in upstream qemu, but did not try that.
* Trying to install again I used a clean debian-arm64 installation
running in qemu-system-aarch64, and attempted installing the
armhf packages using a regular debootstrap, running the 32-bit
binaries in compat mode of a recent arm64 kernel. This partially
worked and I could chroot into the system and use a shell, but
ultimately the debootstrap did not complete because of errors.
I saw that 'tar' had failed because of the stat() glibc ABI mismatch
breaking its private gnulib fdutimens() implementation, and this is
where I gave up.
I have spent more time on this now than I had planned, and don't expect
to do further work on it anytime soon, but I hope my summary is useful
to others that are going to need this later. I can obviously share
my patches and build artifacts if anyone needs them. There are two
additional approaches that would likely get a Debian bootstrap further,
but that I have not tried as they were previously dismissed:
* Adding a time64 armhf as a separate (incompatible) target in glibc
that defines __TIMESIZE==64 and a 64-bit __time_t would avoid
most of the remaining ABI issues and put armhf-time64 in the same
category as riscv32 and arc, but this idea was so far rejected by the
glibc maintainers. Depending on how hard this turns out to be,
it could be used to get to the point of self-hosting though, and
help find time64 related bugs in the rest of the distro.
* Doing the bootstrap using a musleabihf target instead of gnueabihf
would avoid the current issues internal to glibc-y2038, but instead
lead to new problems with packages that do not currently work with
musl. Adelie Linux has shown that it's already possible to build
a useful distro using musl and time64[8], and this would
sidestep the question of the target triplet. While it would also
help find and fix additional bugs in packages, and make an
interesting unoffical Debian target, I don't see it replacing
the existing armhf port any time soon.
For additional information about the Debian plans, see the
article on LWN[9] that summarizes the discussion started by
Steve McIntyre [10].
Arnd
[1] https://wiki.debian.org/HelmutGrohne/rebootstrap
[2] https://github.com/lmajewski/y2038_glibc/tree/y2038_edge
[3] https://salsa.debian.org/glibc-team/glibc/-/tree/glibc-2.31
[4] https://github.com/lmajewski/y2038_glibc/commit/2f72ea2b6f6ee
[5] https://sourceware.org/pipermail/libc-alpha/2020-February/111375.html
[6] https://pastebin.com/fJYV2stF
[7] https://bugs.llvm.org/show_bug.cgi?id=45138
[8] https://wiki.adelielinux.org/wiki/Project:Time64
[9] https://lwn.net/Articles/812767/
[10] https://lwn.net/ml/debian-devel/20200204131410.GF3043@tack.einval.com/
