Opened 13 years ago

Closed 13 years ago

#7286 closed bug (fixed)

webpositive has broken https

Reported by: mmadia Owned by: scottmc
Priority: blocker Milestone: R1/alpha3
Component: Applications/WebPositive Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

There have been reports on IRC that https no longer works on webpositv in the newest nightly images. Possibly due to the recently updated sqlite package in hrev40681?

Attachments (1)

curl-libpcre-fix.patch (1.7 KB ) - added by scottmc 13 years ago.
patch that should fix the webpositive and pe issues with the updated libpcre and curl builds

Download all attachments as: .zip

Change History (14)

comment:1 by scottmc, 13 years ago

Component: - GeneralApplications/WebPositive
Milestone: R1R1/alpha3

Which libs does webpostive depend on? Does it use libevent? Perhaps this could be fixed by a fresh build of Webpositive? I don't see a .bep for webpositive on HaikuPorts, so I guess we may have to wait on someone else to make a fresh build?

comment:2 by mmadia, 13 years ago

According to the OptionalPackageDependencies

OptionalPackageDependencies WebPositive : Curl LibXML2 SQLite ;
...
OptionalPackageDependencies Curl : OpenSSL ;

So, my guess is SQLite.

comment:3 by mmadia, 13 years ago

It's been suggested that the gcc4 build of cURL was built without ssl support.

comment:4 by mmadia, 13 years ago

Resolution: fixed
Status: newclosed

Fixed in hrev40725, by reverting some optional packages.

comment:5 by scottmc, 13 years ago

Resolution: fixed
Status: closedreopened

Reverting doesn't fix this issue, it only masks it. We need to understand which one of those package updated broke this. I am making new build now and will post links here when they are ready for testing.

comment:6 by anevilyak, 13 years ago

It was libcurl FYI.

comment:7 by scottmc, 13 years ago

yeah, I just tried rebuilding curl and it's not detecting openssl (at least on gcc4), have to investigate why not.

comment:8 by scottmc, 13 years ago

Blocked By: 7203 added
Priority: highblocker

I just checked this with a build of Haiku hrev39567 and it builds fine with that and includes openssl, but it fails to build correctly with recent Haiku builds. So marking this as being blocked by #7203.

comment:9 by scottmc, 13 years ago

Blocked By: 7203 removed

Ok, I removed the installed pcre and curl files from my gcc2h Haiku and installed fresh builds of each using the latest .bep files. Seems the problem is using gcc4 libs when they aren't needed and don't currently build correctly anyways. After the removal of the old pcre and curl files I verified that both Pe/lpe and WebPositive broke as was reported on this ticket. I then installed the new gcc2 builds and then tested both Pe/lpe and WebPositive and both are now working, the way they should. Even https is working. I have attached a patch to re-add them to OptionalPackages. I've also inserted a note to remind anyone updating these two in the near term that the gcc2 libs should work for gcc4 needs. Can someone who is setup to do gcc4 builds and/or gcc2h and gcc4h build apply this patch and verify that it's correct? It's building fine for me with plain gcc2.

I've removed the blocked by on this as if this works it shouldn't be a blocker for alpha3 anymore.

by scottmc, 13 years ago

Attachment: curl-libpcre-fix.patch added

patch that should fix the webpositive and pe issues with the updated libpcre and curl builds

comment:11 by scottmc, 13 years ago

patch: 01

comment:12 by mmadia, 13 years ago

This patch doesn't set the correct flags in InstallOptionalHaikuImage.

Here is the rule from ImageRules, with different whitespace formatting for clarity

rule InstallOptionalHaikuImagePackage 
	package 
	: url 
	: dirTokens 
	: isCDPackage
	: isGCCAgnostic

To clarify, isCDPackage affect's the ISO (not anyboot) targets. The flag will instruct the build system to store the optionalpackage as it's original zip in _packages_/ . Installer will then automatically extract that zip (CAUTION: i'm not sure if Installer is capable of automatically extracting other archive formats). This flag exists, to make booting the ISO faster, at the expense of a more limited LiveCD experience. IIRC, WebPositive and it's dependencies should not set this flag.

isGCCAgnostic shall be used on optionalpackages containing shared libraries, when there is only one archive, which can be used on either gcc2 or gcc4. (eg, cURL, SSL, and more than likely many others) The isGCCAgnostic flag will instruct the build system to create symlinks in the respective gcc-sub-directory (eg, lib/gcc4 or lib/gcc2 depending on the host system).

Building and mounting @alpha-cd will confirm that many packages are stored in _packages_/.

Below is my original script for checking whether or not a library can utilize isGCCAgnostic. It's been a while since I looked at it. The most significant line of code is nm $lib | grep "\w _Z" .

#!/bin/bash

cd common/lib
ls -1
objdump -x *.so* | grep NEEDED | sort -u
for lib in *.so*; do
	echo $lib
	#objdump -x $lib | grep NEEDED
	nm $lib | grep "\w _Z"
done

in reply to:  12 comment:13 by bonefish, 13 years ago

Replying to mmadia:

To clarify, isCDPackage affect's the ISO (not anyboot) targets. The flag will instruct the build system to store the optionalpackage as it's original zip in _packages_/ . Installer will then automatically extract that zip (CAUTION: i'm not sure if Installer is capable of automatically extracting other archive formats). This flag exists, to make booting the ISO faster, at the expense of a more limited LiveCD experience. IIRC, WebPositive and it's dependencies should not set this flag.

I believe the purpose of the flag is to speed up the installation process, since extracting a single zip is much faster than copying individual files from the CD. The flag will become completely superfluous once packagefs is used.

isGCCAgnostic shall be used on optionalpackages containing shared libraries, when there is only one archive, which can be used on either gcc2 or gcc4. (eg, cURL, SSL, and more than likely many others) The isGCCAgnostic flag will instruct the build system to create symlinks in the respective gcc-sub-directory (eg, lib/gcc4 or lib/gcc2 depending on the host system).

This flag should be phased out. There should be separate gcc 2 and gcc 4 packages instead.

comment:14 by scottmc, 13 years ago

Resolution: fixed
Status: reopenedclosed

All of the gcc4 packages in question have now been rebuilt on a gcc4 only system, and re-added to Haiku, this has cleared up the reports regressions. Pe and WebPositive are both working fine with the updated curl and libpcre packages in place on gcc4, tested with hrev40756.

Note: See TracTickets for help on using tickets.