openembedded-architecture@lists.openembedded.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: [OE-core] Y2038 proposal

That is really interesting data as it confirmed there are real world issues which changing the compiler flags is going to break. Thanks for sharing. What you describe is relatively easy for a

By Richard Purdie · #1689 ·

Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal

That works for me. I've started preparing a patch for oe-core. -- Ola x Nilsson

By Ola x Nilsson <ola.x.nilsson@...> · #1688 ·

Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal

That does sound useful, perhaps sharing it as an RFC patch might be a good place to start? We might be able to run one of the autobuilder world targets against it, see how it looks for our core

By Richard Purdie · #1687 ·

Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal

I have a working sanity checker that checks for any glibc functions affected by -D_FILE_OFFSET_BITS=64 or -D_TIME_BITS=64. The INSANE_SKIP functionality needs some more polish but I'd be happy

By Ola x Nilsson <ola.x.nilsson@...> · #1686 ·

Re: [OE-core] Y2038 proposal

Your email prompted me to check my own software (Dropbear) and it showed a few y2038 issues to fix. Those bugs wouldn't be noticed from a quick test - it "only" prevented auth and idle timeouts from

By Matt Johnston <matt@...> · #1685 ·

OEDvM and OpenEmbedded Workshop

Hello fellow OpenEmbeddeders! Less than 24 hours until we kick off the OpenEmbedded Developers virtual Meeting 2022.11! For more details, please see https://www.openembedded.org/wiki/OEDvM_2022.11 You

By Josef Holzmayr · #1684 ·

Re: Y2038 proposal

I think we should fix those and we should add the target to the autobuilder but I'm reluctant to add a long test to a-full. The fact it is relatively clean suggests it doesn't regress that often. We

By Richard Purdie · #1683 ·

Re: Y2038 proposal

<richard.purdie@...> wrote: I just ran qemux86 full ptest locally. It took 4h:10m (same as qemuarm64 ptest on an arm worker). The fails were: {'python3': ['test_deterministic_sets'],

By Alexander Kanavin · #1682 ·

Re: [yocto] Y2038 proposal

Hi Alexander, Yes. You need to run them with adjusted date: date +'%Y-%m-%d %T' -s "2038-01-19 03:14:07" ptest-runner glibc-tests More

By ?ukasz Majewski <lukma@...> · #1681 ·

Re: [yocto] Y2038 proposal

I just ran these tests in (32 bit) qemux86 on top of poky master (e.g. no magic glibc flags), and they all passed. Do they need to be ran after setting the date to the 'post-2038 future' to reveal the

By Alexander Kanavin · #1680 ·

Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal

That sounds interesting and something we should probably look into for both issues... That would cause runtime issues but not build time linking ones? Cheers, Richard

By Richard Purdie · #1679 ·

Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal

We can simply disable COMPAT_32BIT_TIME in the kernel config. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com

By Alexandre Belloni <alexandre.belloni@...> · #1678 ·

Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal

Some time ago I filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian has a nice sanity check where it warns if non-LFS glibc functions are used. I imagine the same logic could be

By Ross Burton · #1677 ·

Re: Y2038 proposal

<alex.kanavin@...> wrote: I have something like this on yoe/mut branch on contrib repo ( due to musl removing the LFS hacks). However there are packages which need to be fixed at build

By Khem Raj · #1676 ·

Re: [OE-core] [Openembedded-architecture] Y2038 proposal

Perhaps, yes. I'm meaning disabling the 32 bit glibc time functions. Right, but the 32 bit time functions/symbols are still available for older binaries. My point is that anything using those older

By Richard Purdie · #1675 ·

Re: [OE-core] [Openembedded-architecture] Y2038 proposal

Hi Richard, Y2038 ptests maybe? Here is the list of integrated tests to ptests: https://github.com/lmajewski/y2038-tests Could you be more specific here? Would you like to disable

By ?ukasz Majewski <lukma@...> · #1674 ·

Re: Y2038 proposal

Others have made some good comments. My thoughts: * We need to add some runtime tests to oeqa for this (in addition to the ptests) * We need to have a 32 bit ptest run on the autobuilder (qemux86

By Richard Purdie · #1673 ·

Re: [OE-core] [yocto] Y2038 proposal

For x86, yes. For arm, it varies and I know at least one of our arm hosts doesn't support it, I don't know about the newer ones. In general I think it shouldn't be too bad but we really do need

By Richard Purdie · #1672 ·

Re: [OE-core] [yocto] Y2038 proposal

"Alexander Kanavin" <alex.kanavin@...> wrote: +1 IIRC the MACH=qemux86 was working correctly... Maybe only subset of ptests - i.e. those related to Y2038 could be run? Best regards, Lukasz

By ?ukasz Majewski <lukma@...> · #1671 ·

Re: [OE-core] [yocto] Y2038 proposal

<richard.purdie@...> wrote: I think kvm does allow 32 bit guest on a 64 bit host. But I can imagine making full ptests work on 32 bit guests would be a struggle for reasons unrelated

By Alexander Kanavin · #1670 ·

21 - 40 of 1709

Home Hashtags Subgroups Terms