userguide stopped working on Haiku 64bit hrev53658

[fotisk]

Says could not find an application to load that kind of file (attached screenshot). Verified that was working in hrev53652. Seems like a very recent regression. Also, verified that html file type has WebPositive as prefered application in FileTypes. Tried to uninstall/reinstall but did not resolve the problem. It's about the English userguide version which is the only one I have installed.

[humdinger]

I installed the 64bit beta1 release and updated to a current nightly. See the same thing.

In fact, it seems pure luck that past userguide packages worked:
The issue seems to be that the en/contents.html file in the userguide package has the type "localex-vnd.Be.locale-catalog.default" instead of "application/xhtml+xml". The filetypes of the files in the userguide are all over the place. Some have a BEOS:APP_VERSION attribute which seems to indicate to the system they were executables, though they don't have the x-bit set.

As we're read-only, the system can't correct the wrong/missing filetypes.

How to fix the build of userguide (and other, I suppose) packages to include files only after they're correctly typed?

[waddlesplash]

Likely the best thing to do is to force a specific mimetype on those files during the build process, then. Or fix the mime-db so they are detected correctly, if you can.

[diver]

Same here, would be nice to fix this before beta2.

[pulkomandy]

The rules to build the userguide do not set the mime type explicitly. So we rely on the MIME ddb and mimeset to do the work, and sniff the files correctly. Did something change in the userguide files or in the MIME sniffing rules that causes this to not work anymore?

[pulkomandy]

I tried mimeset on my Haiku system and it did the right thing (en/contents.html set to the correct MIME type). I looked for "locale/x-vnd.Be.locale-catalog.default" and found only one place where this is used, in DefaultCatalog.cpp. It isn't even in the MIME db source files. How does it end up being used then?

[pulkomandy]

So, the only way I see for this to happen is that there is a bug in the extended attributes emulation, and we end up using the attributes from other files when building these packages. I built the haiku_userguide_fr package locally on Haiku and I got the correct types.

What is the setup on the CI builders? Which filesystem? Is the generated directory cleaned up, including the attribute emulation storage?

[pulkomandy]

From the CI build logs:

../haiku-git/configure: could not find setfattr, assuming host has no extended attributes

Can we fix that?

[waddlesplash]

Buildbot is now fixed, so the next builds should have proper attributes.