Installation of haiku ports fails

[eanyx]

haiku ports install fail

On real hardware (intel haswell core i3-4330) with : Haiku shredder 1 hrev47606 Jul 31 2014 02:03:23 BePC x86 Haiku

When wanting to install haiku ports,

the git clone fails and displays :

git clone ​https://bitbucket.org/haikuports/haikuports.git Cloning into 'haikuports'... fatal: unable to access '​https://bitbucket.org/haikuports/haikuports.git/': error setting certificate verify locations:

CAfile: /packages/curl-7.35.0-1/ca_root_certificates/data/ssl/CARootCertificates.pem CApath: none

the file /boot/system/data/ssl/CARootCertificates.pem is present,

cd /packages/curl-7.35.0-1

ls -al

lr-xr-xr-x 1 user root 5 2014-07-31 12:11 .self -> ../.. lr-xr-xr-x 1 user root 24 2014-07-31 12:11 .settings -> ../../../system/settings lr-xr-xr-x 1 user root 1 2014-07-31 12:11 ca_root_certificates -> ? lr-xr-xr-x 1 user root 5 2014-07-31 12:11 haiku -> ../.. lr-xr-xr-x 1 user root 5 2014-07-31 12:11 lib~libssl -> ../.. lr-xr-xr-x 1 user root 5 2014-07-31 12:11 lib~libz -> ../..

the ca_root_certificates symbolic point to ? and seems to be corrupted.

As /packages/curl-7.35.0-1 directory is read-only, this cannot be manually corrected.

[eanyx]

installation of haiku ports fails

[waddlesplash]

What version of ca_root_certificates do you have installed?

[eanyx]

ca_root_certificates-2014_04_08-1 bundled with hrev47606 gcc2-hybrid nightly (installed this morning 31 july 2014 (fresh install from scratch)).

[waddlesplash]

Not sure what's going on here, as I have 08-1 installed as well and this works just fine for me. That problem happened on an earlier version of the recipe, but I though I'd fixed that...

bonefish/Ingo: any idea why *updating* a package would work but installing it from scrathc would not?

[eanyx]

Seems that curl package is not installed with the same symbolic links.

Working configuration (hrev47569) installed from scratch last week.

/packages/curl-7.35.0-1> ls -al total 3 dr-xr-xr-x 1 user root 0 2014-07-31 17:49 . dr-xr-xr-x 1 user root 0 2014-07-31 17:49 .. lr-xr-xr-x 1 user root 5 2014-07-31 17:49 .self -> ../.. lr-xr-xr-x 1 user root 24 2014-07-31 17:49 .settings -> ../../../system/settings lr-xr-xr-x 1 user root 5 2014-07-31 17:49 ca_root_certificates -> ../.. lr-xr-xr-x 1 user root 5 2014-07-31 17:49 haiku -> ../.. lr-xr-xr-x 1 user root 20 2014-07-31 17:49 lib~libssl -> ../../../home/config lr-xr-xr-x 1 user root 5 2014-07-31 17:49 lib~libz -> ../..

not working configuration :

Haiku shredder 1 hrev47606 Jul 31 2014 02:03:23 BePC x86 Haiku

/packages/curl-7.35.0-1> ls -al total 3 dr-xr-xr-x 1 user root 0 2014-07-31 18:17 . dr-xr-xr-x 1 user root 0 2014-07-31 18:17 .. lr-xr-xr-x 1 user root 5 2014-07-31 18:17 .self -> ../.. lr-xr-xr-x 1 user root 24 2014-07-31 18:17 .settings -> ../../../system/settings lr-xr-xr-x 1 user root 1 2014-07-31 18:17 ca_root_certificates -> ? lr-xr-xr-x 1 user root 5 2014-07-31 18:17 haiku -> ../.. lr-xr-xr-x 1 user root 5 2014-07-31 18:17 lib~libssl -> ../.. lr-xr-xr-x 1 user root 5 2014-07-31 18:17 lib~libz -> ../..

[bonefish]

The symlinks in /packages/ are automatically generated by packagefs at run-time. If a dependency symlink points to "?" it means that packagefs doesn't know an active package that satisfies the requires entry of the requesting package. That means the packages state of the packagefs volume is not consistent (the package daemon will probably also note that in the syslog (which you forgot to attach)) -- not all of the dependencies of the curl package are satisfied.

You can verify the theory by printing the package infos for the curl and the ca_root_certificates package (package list -i <path-to-package>).

I haven't followed the HaikuPorts package changes too closely lately, but IIRC the version format for the ca_root_certificates package changed recently. That would be an excellent reason why a previously built package would now be broken.

That being said, the Haiku built system makes sure that the packages state for the built images is consistent (or at least all packages' requirements are satisfied). It would be worth investigating why that didn't work in this case.

[zooey]

I had a cursory look at the problem today and, according to package list -i, the ca_root_certificate package does not declare a compatibility version.

In the ca_root_certificate recipe, there is a compat >= 0 clause, maybe that is interpreted as no compatibility at all?

[bonefish]

That does indeed sound like an issue. According to the syslog the initial verification package daemon performs considers the system volume consistent. So packagefs and the solver (and the package kit?) might interpret the compat >= 0 value differently.

[waddlesplash]

The problem describe here should be fixed in hrev47610, however, the underlying provlem this ticket expresses has not been resolved and so the ticket should remain open.

[modeenf]

I'm getting this in a x86. Can this be the same problem?

/Haiku_data/work/haiku> git fetch upstream fatal: unable to access '​https://github.com/haiku/haiku.git/': error setting certificate verify locations:

CAfile: /packages/curl-7.36.0-1/ca_root_certificates/data/ssl/CARootCertificates.pem CApath: none

/Haiku_data/work/haiku>

(the file /boot/system/data/ssl/CARootCertificates.pem is present)

/Haiku_data/work/haiku> git remote -v origin ​https://github.com/ModeenF/haiku.git (fetch) origin ​https://github.com/ModeenF/haiku.git (push) upstream ​https://github.com/haiku/haiku.git (fetch) upstream ​https://github.com/haiku/haiku.git (push) /Haiku_data/work/haiku>