Tracking Ticket for alpha3 OptionalPackages that have problems

[taos]

If you find any problems with OptionalPackages for alpha3 add a comment to this tracking ticket.

Original Summary: Expander no longer extracts xz archives - wrong path for tar (OptionalPackages)

Using r1a3-rc-hrev41594.

Expander is no longer able to preview or extract *.xz archives, *.zip archives can be extracted. Used to work with r1a3-rc-hrev41552.

My guess: One of the OptionalPackages changed for Alpha 3 (rc hrev41594) is tar. "tar" is now stored in /boot/common/bin/bin (current alpha3) instead of /boot/common/bin (pre-alpha3) and thus not found by expander. When moving tar to /boot/common/bin everything works again.

This should be changed for alpha 3.

Also subversion was built without the patch that cleans up it's directories, and expat was built with incorrect mandir setting, these have been updated now.

[scottmc]

Looks like tar, subversion and expat need to be fixed and rebuilt. Perhaps more? If you spot any of the newly rebuilt OptionalPackages not working as expected, post a comment on this ticket. Same goes for the OptionalLibPackages which will get the first wave for rebuilds today.

[scottmc]

fixed expat and subversion in hrev41605.

[taos]

Does the needed clean-up of subversion's directories refer to having - at the moment - a directory /boot/home/.subversion (reminds me of linux) instead of /boot/home/config/settings/subversion (more haiku-like)?

[scottmc]

Replying to taos:

Does the needed clean-up of subversion's directories refer to having - at the moment - a directory /boot/home/.subversion (reminds me of linux) instead of /boot/home/config/settings/subversion (more haiku-like)?

Correct, that's how I noticed it. I cleaned that up last year, but when updating to 1.6.15 forgot to update the patch as well. It's fixed now.

Also tar is now fixed in hrev41606.

Let's keep this ticket open as a tracking ticket until all of the OptionalPackages and OptionalLibPackages have been rebuilts for alpha3 and checked for issues. Reports any new issues here.

[anevilyak]

(In #7545) Indeed.

[stippi]

I don't know if this affects a GCC2 based hybrid, but on a GCC4 based hybried of hrev41650, svn is broken because it can't find "libexpat.so.0". Copying the link "libexpat.so.1" and naming it "libexpat.so.0" in common/lib allows svn to run. However trying to update the Haiku tree still does not work, since apparently svn has been built without the UTF-8 fix applied:

svn: Error converting entry in directory 'src/data/keymaps' to UTF-8
svn: Safe data 'French (B' was followed by non-ASCII byte 233: unable to convert to/from UTF-8

[axeld]

I wonder why problems like this creep in so often when rebuilding the tools; I thought the .bep files were created to solve these things?

[scottmc]

Replying to axeld:

I wonder why problems like this creep in so often when rebuilding the tools; I thought the .bep files were created to solve these things?

Part of this is due to gcc4 packages being such a pain to build. I tried building them on an Alpha3 RC build with setgcc set to gcc4 but that seems to be yielding mixed results, so I am now trying it on a gcc4 only alpha3 build, but it took 6+ hours for my PC to run that build after cleaning out the generated directory first. I reran the gcc4 package bep last night and regenerated most of the gcc4 packages. I still need to do further testing before I add them to the build though. So progress is being made, just slower than I'd like.

The subversion issue was due to me adding an alpha3 gcc4 build of expat, without a matching subversion and several other packages that seem to need to be dropped into the image at the same time, otherwise we'll have the same type of error. So once I verify that adding them all don't result in missing libs, then I will add them in.

[mmadia]

Replying to scottmc:

Replying to axeld:

I wonder why problems like this creep in so often when rebuilding the tools; I thought the .bep files were created to solve these things?

Part of this is due to gcc4 packages being such a pain to build. ..... I still need to do further testing before I add them to the build though. So progress is being made, just slower than I'd like.

Maybe giving another HaikuPorts member commit access will help reduce scott's workload?

[scottmc]

as of hrev41748 the expat/subversion issue should be resolved. Note that the ssl directory has moved to B_COMMON_DATA_DIRECTORY/ssl, instead of B_COMMON_DIRECTORY/ssl, this should be rechecked when rebuilding web+ and others to make sure they account for this.

It looks like I need to fix the directories for perl and it's still putting things in /boot/common/share.

[mmadia]

Replying to scottmc:

as of hrev41748 the expat/subversion issue should be resolved. Note that the ssl directory has moved to B_COMMON_DATA_DIRECTORY/ssl, instead of B_COMMON_DIRECTORY/ssl, this should be rechecked when rebuilding web+ and others to make sure they account for this.

I reverted OpenSSL - gcc4 in hrev41767.

It looks like I need to fix the directories for perl and it's still putting things in /boot/common/share.

Please -- for now stop updating the directory structures of the optional packages. This can always be done after the hrev1 alpha 3 release. There simply is no reason to risk breaking Haiku (and more importantly the software already built for Haiku), especially during a release cycle.

There will always be another release, another chance to improve things, another chance to introduce more bugs.

[scottmc]

I have now completed as much as I can complete of the OptionalPackages rebuild for alpha3. If there's any new issues, please open a new ticket for them.

[luroh]

Today's (2011-05-31) FRiSS package puts a shortcut in Menu->Desktop->applets, instead of in Menu->Desktop applets.

[scottmc]

WebPositive is giving this error when I try to click on an html link in programs such as bepdf and yab. I suspect a fresh WebPositive build will clear this up?

runtime_loader: /boot/common/lib/libxml2.so.2.7.8: No version information available (required by /boot/apps/WebPositive/lib/libwebcore.so)
runtime_loader: /boot/common/lib/libxml2.so.2.7.8: No version information available (required by /boot/apps/WebPositive/lib/libwebcore.so)
runtime_loader: /boot/common/lib/libxml2.so.2.7.8: No version information available (required by /boot/apps/WebPositive/lib/libwebcore.so)

[bonefish]

Replying to scottmc:

WebPositive is giving this error when I try to click on an html link in programs such as bepdf and yab. I suspect a fresh WebPositive build will clear this up?

It might, but the problem is on libxml2's side.

runtime_loader: /boot/common/lib/libxml2.so.2.7.8: No version information available (required by /boot/apps/WebPositive/lib/libwebcore.so)

Barring a possible bug in the runtime loader, the error means that libwebcore had been built against a libxml2 that provided version information, while the libxml2 that is tried to be loaded here does not do that. It might have been built incorrectly. A readelf --version-info <file> for it should verify the suspicion.

[scottmc]

Replying to luroh:

Today's (2011-05-31) FRiSS package puts a shortcut in Menu->Desktop->applets, instead of in Menu->Desktop applets.

I have commented this out in OptionalPackages, which just leaves out a symlink for friss like it was before.

[scottmc]

Barring a possible bug in the runtime loader, the error means that libwebcore had been built against a libxml2 that provided version information, while the libxml2 that is tried to be loaded here does not do that. It might have been built incorrectly. A readelf --version-info <file> for it should verify the suspicion.

The fresh build of webpositive did in fact make the libxml2 message go away. I tried running readelf --version-info on the libxml2.so file but not sure what to look for in that output. I compared it with the output of some of the other libs and some mostly the same things on those.

[scottmc]

The alpha3 OptionalPackage seem to be stable now. So closing this ticket. If anything else pops up before the alpha3 release, please post it here and reopen the ticket.