qtbase do_install broken after update to recent oe-core

[schnitzeltony]

Updated my oe-core yesterday (was so happy my patched made it into warror..).

Now I get dozens of errors at qt install:

log)_do_install.txt

Have no idea what's going wrong except that pseudo was updated and maybe qtbase tries something that pseudo does't accept...

[shr-project]

Is it reproducible in clean build (after removing tmp-glibc)?

I've updated oe-core yesterday as well and haven't seen this issue in my jenkins builds yet.

[schnitzeltony]

Yes I started build from scratch and cleansstate qtbase does not help - it looks 100% reproducible for me.

In my desperation, I have now updated build host (Fedora 29) and a new glibc was installed. Started another build from scratch - oh this project will drive me insane some day...

[alistair23]

This is 100% reproducible for me as well. This is a recent change (in the last few days).

[shr-project]

My builds are on Ubuntu 18.04 and e.g. http://jenkins.nas-admin.org/job/LuneOS/view/unstable/job/luneos-unstable_qemux86/191/consoleFull just finished with this oe-core revision from today: http://git.openembedded.org/openembedded-core/commit/?id=7469c2a5595337fc4407fa7a2ad06b5bf2347545 and latest meta-qt5 revision a4bf240

…

On Fri, Apr 12, 2019 at 7:43 PM Andreas Müller ***@***.***> wrote: Yes I started build from scratch and cleansstate qtbase does not help - it looks 100% reproducible for me. In my desperation, I have now updated build host (Fedora 29) and a new glibc was installed. Started another build from scratch - oh this project will drive me insane some day... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#187 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABLW0pjEXmAo167iSa93oTnsk4GWgXGkks5vgMWtgaJpZM4csfgW> .

[schnitzeltony]

meta-qt5: same a4bf240
oe-core now warrior master from today b5f493078335a77dea2f229d36629399d897a528

And the worst: After update and restart of host as mentioned and building from scratch I now get an error at do_compile!!

I'll come back with log later - am working on other issues currently (there are lots - not OE specific only)...

[alistair23]

I'm bisecting the breakage in meta, I'll let you know when I have a commit.

[schnitzeltony]

We'll see - my glass ball says [1]

[1] https://git.openembedded.org/openembedded-core/commit/?id=0fb257121b68f38b40c078150db8f7d0979b7ea5

[alistair23]

I suspect so, I have gotten this far. I don't think I'll get a chance to finish it today:

• 5958938313 (refs/bisect/bad) gobject-introspection: auto-enable/-disable gobject-introspection for meson (by Andreas Müller 8 days ago)
• 88188807a6 elfutils: remove Elfutils-Exception and include GPLv2 for shared libraries (by Mikko Rapeli 33 hours ago)
• d70c77e4d5 python3: Fix ptest output parsing (by Richard Purdie 4 days ago)
• 2a48df02a2 python3: Avoid hanging tests (by Richard Purdie 5 days ago)
• 0fb257121b pseudo: Update to gain key bugfixes (by Richard Purdie 2 days ago)
• a3923085d1 (refs/bisect/good-a3923085d1cad7de7e644ff57d05c4a8955b5b00) busybox: Use PTEST binary directory (by Mariano Lopez 4 days ago)

[alistair23]

Yeah, pseudo: Update to gain key bugfixes is the first bad commit in meta.

[seebs]

Well, that's concerning.

/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-neon-vfpv4-mortsgna-linux-gnueabi/qtbase/5.12.2+gitAUTOINC+856fb1ab44-r0/recipe-sysroot-native/usr/bin/qmake -install qinstall -exe /home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-neon-vfpv4-mortsgna-linux-gnueabi/qtbase/5.12.2+gitAUTOINC+856fb1ab44-r0/git/bin/syncqt.pl /home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-neon-vfpv4-mortsgna-linux-gnueabi/qtbase/5.12.2+gitAUTOINC+856fb1ab44-r0/image/usr/bin/syncqt.pl
Error copying /home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-neon-vfpv4-mortsgna-linux-gnueabi/qtbase/5.12.2+gitAUTOINC+856fb1ab44-r0/git/bin/syncqt.pl to /home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-neon-vfpv4-mortsgna-linux-gnueabi/qtbase/5.12.2+gitAUTOINC+856fb1ab44-r0/image/usr/bin/syncqt.pl: Cannot create /home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-neon-vfpv4-mortsgna-linux-gnueabi/qtbase/5.12.2+gitAUTOINC+856fb1ab44-r0/image/usr/bin/syncqt.pl for output

This seems to be the root actual error.

The actual changes are (1) on systems that have renameat2 wrappers in glibc, block access to renameat2 through the wrapper, not just through the generic syscall wrapper, (2) handle blocking opens of pipes differently.

I'm guessing it isn't the pipe thing, so this could be a change with renameat2 handling. If that means that qmake actually needs renameat2, and hasn't got a way to fall back if renameat2 doesn't work, then we definitely have a serious problem, because renameat2 is surprisingly hard to implement in pseudo, which is why it's just being blocked right now.

[schnitzeltony]

I think with this background a solution might be simple: We have already a patch deciding to use renameat2 or not (LOL the author has lost his brain - can't remember) [1].

If I am not mistaken is just needs adjustment. Will play around a bit and get back then.

[1] https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/qtbase/0013-Check-glibc-version-for-renameat2-statx-on-non-boots.patch

[seebs]

That would explain it, yeah! Sorry about this -- the underlying problem is that it turns out pseudo's IPC and database code doesn't have a good way to handle atomic exchange renames, and while I could in theory just ENOSYS on those, I thought it would be safer if the renameat2 code just errored out unconditionally, because that's more likely to result in code concluding that it's unsupported.

I might try to actually implement the support some day, but it's a much larger thing, and it'll probably still stay broken for the syscall wrapper case -- syscall parameters are more magic than I'm comfortable trying to handle on code that might need to run on multiple architectures.

[schnitzeltony]

I start to remember [1]: Since then renameat2 got mandatory to avoid direct syscalls by coreutils (and that's why I did the patch for - I guess).

Wonder what qmake does when disabling renamat2 these days...

Ahh and - I think people not seeing breakages have glibc < 2.28 and elder coreutils - right?

[1] http://lists.openembedded.org/pipermail/openembedded-core/2018-March/267587.html

[seebs]

Yup, the glibc wrapper got added in glibc 2.28. We already did ENOSYS for direct syscalls using the RENAMEAT2 syscall, because it's hard to translate safely.

It's a lovely system call, it just violates assumptions I made designing pseudo's original protocol.

[schnitzeltony]

Looked through meta-qt5 git log:

• @shr-project introduced 539e4f0 to fix build with glibc 2.28.
• I followed with 2d1d807

Martin's patch is gone - so my first approach is to remove mine either. Build from scratch is running....

[schnitzeltony]

Nope - just remove https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/qtbase/0013-Check-glibc-version-for-renameat2-statx-on-non-boots.patch does not do the job - zzz

[rpurdie]

Can you just try unconditionally defining # define QT_FEATURE_renameat2 -1 ? I'm hoping that means it uses a fallback!

[schnitzeltony]

Yes that's the next step

[schnitzeltony]

After fixing all typos in commit message (hopefully) patch is ready for test [1].

@alistair23: Maybe you want to give it a try

[1] #189

[alistair23]

Yep, that fixes the install failure for me.

[rpurdie]

There is probably a more advanced patch where you could catch ENOSYS as well as EINVAL and just fall through that function FWIW...

[shr-project]

On Ubuntu 18.04 with:
ii libc6:amd64 2.27-3ubuntu1 amd64
ii coreutils 8.28-1ubuntu1 amd64
it's not reproducible (so 8.28 coreutils alone isn't the issue only in combination with glibc 2.28). Or depends on coreutils patches as mentioned by Peter in oe-core ML:
http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281343.html

With Ubuntu 19.04 beta with:
ii libc6:amd64 2.29-0ubuntu2 amd64
ii coreutils 8.30-1ubuntu1 amd64
and Ubuntu 18.10 with:
ii libc6:amd64 2.28-0ubuntu1 amd64
ii coreutils 8.28-1ubuntu2 amd64

I was able to reproduce it, but only with qt 5.12 (not with 5.11 from meta-qt5/thud).

Now when I can reproduce, I'll test your PR on Ubuntu and if it fixes the issue there as well I'll merge it to warrior and master (probably together with 5.12.3 upgrade). Thanks

[shr-project]

I'm going to merge these patches soon, but still something isn't right.

I was going to report on oe-core ML, that new pseudo finally really resolved the issue with host-user-contamination as often triggered in glibc-locale (one of my builders already finished 1700 rebuilds of glibc-locale without any host-user-contamination error).

But then when testing the PR for this issue (together with 5.12.3 upgrade on top of it) I already got few host-user-contamination issues there:

ERROR: qtwebengine-5.12.3+gitAUTOINC+c7b8d6d878_4c7ecce300-r0 do_package_qa: QA Issue: qtwebengine: /qtwebengine-qmlplugins/usr/lib/qml/QtWebEngine/Controls1Delegates/MenuItem.qml is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated]

ERROR: qtquickcontrols-5.12.3+gitAUTOINC+3a5ac4885b-r0 do_package_qa: QA Issue: qtquickcontrols: /qtquickcontrols-qmlplugins/usr/lib/qml/QtQuick/Dialogs/qml/DefaultWindowDecoration.qml is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination

So maybe the 0013-Check-glibc-version-for-renameat2-statx-on-non-boots.patch patch was still useful to prevent host-user-contamination with pseudo which I haven't seen with qt5* recipes for quite long time possibly since 5.9* where I'm still using host-user-contamination issues as well even with the latest revision from pseudo (3fa7c853e0bcd6fe23f7524c2a3c9e3af90901c3 ERROR: QA Issue: lib32-qtquickcontrols: /lib32-qtquickcontrols-qmlplugins/usr/lib/qml/QtQuick/Dialogs/DefaultColorDialog.qmlc is owned by uid 1101, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated])

And these host-user-contaminated issues happen with Ubuntu 18.04 already.

[seebs]

I'm guessing that the addition of the glibc renameat2 patch is going to break some things that were previously working, although I'm not totally sure how. We may need to try to catch more cases, or possibly even implement some of them. (As noted elsewhere, actually handling renameat2 is going to be really ugly in pseudo, which is why it hasn't happened yet, but we might be able to handle some subset of cases reasonably.)

The obvious question would be: Can you find specific renameat2 calls, especially their flags, that are happening but failing, so I can develop a better plan for this?

[schnitzeltony]

Haven't had the time to look into pseudo sources yet but if I understood @seebs correctly, actual pseudo returns ENOSYS on renameeat2 for glibc wrapper or direct system call.

• Old 0013-Check-glibc-version-for-renameat2-statx-on-non-boots.patch did check glibc version and in case of >= 2.28 it enabled renameat2 calls. This does not work any more with current pseudo and host glibc >= 2.28
• New 0018-Avoid-renameeat2-for-native-sdk-builds.patch disables renameat2 independent of host glibc version and - to ensure there was nothing overseen - removes code using renameat2. The code below the area removed supplies a fallback.

Both host-contamination share that they are on installation of qml-files (and that they seem to occure unreproducible).

Don't know for 'qml-file' installation:

• if the 2 cases are enough to create some rule out of it
• is special - means using other tool than qmake for installation

[shr-project]

I've added https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434#c48 with a bit more information about this issue.