config.txt for Raspberry Pi

Bizarre, Steve. I just updated fr. 2.9 to 3.0 this evening, and wrote the earlier-evening messages on NetSurf. No problems.

Looks like it is using cURL with OpenSSL. http://git.netsurf-browser.org/netsurf.git/tree/content/fetchers/curl.c

When you reinstalled, did you replace/remove everything (inc. in !System and Choices)? I wonder if there is a list of good certificates that has become corrupted?

Is your firewall hyperactive? TLS/https uses port 443.

Martin wrote:

This is one of NetSurf’s most frequently asked questions. Here’s the last time I answered it: http://vlists.pepperfish.net/pipermail/netsurf-users-netsurf-browser.org/2012-September/010912.html

That issue was fixed before NetSurf 3.0 was released.

Steve wrote:

Sadly, that both isn’t the error I’m getting nor is it the solution. I’ve tried the latest dev build and the 3.0 stable build and still cannot shift this message…

That implies:

• corrupt or non-existent ca-bundle, or
• Choices file pointing at something other than NetSurf:Resources.ca-bundle or
• system date is wrong or
• something else

Please check the ca-bundle path in Choices is correct. You can use about:config to check, and do F4 “ca_bundle”.

In case your ca-bundle is corrupt, try replacing it.

If not, try setting suppress_curl_debug:0 in the Choices file, and sending us the Log file for an attempt to visit an https site.

Finally, does NetSurf 2.9 exhibit the same behaviour?

Cheers for all the feedback.

I basically took the existing (RC11) ROPi image and installed NS3 onto it (Boot merge, Sys merge, replace !NetSurf). I variously left the Choices.WWW.NetSurf folder alone and deleted it. Also tried with flushing out !Scrap. I’m not sure what other bits might be lurking somewhere but I’ll take your advice and do some more fiddling tonight.

It’s bound to boil down to being something trivial – especially as I don’t see this issue on the Iyonix when installing from the exact same NetSurf zipfile and using the exact same installation procedure.

OK. Note that if you do try NetSurf 2.9, then that does have the bug Martin mentioned. You’ll need to go to iconbar menu Choices, save, and restart NetSurf 2.9 before it will visit https sites.

I have a feeling 2.9 was the version already in ROPi RC11 and we had to do that work-around before release. I’ll see what happens if I downgrade NS in the current RC12 development image that’s showing up these issues in NS 3.0.

A log file with the curl debug suppression off should throw some light on it anyway.

Michael: NetSurf’s handling of 64K modes on RISC OS 5 seems to not be good either – at least the Netsurf homepage seems to be wrongly coloured on the Pi with latest firmware (couple of days old, with Netsurf being a bleeding edge build too as I wanted to see if this had gone).

Not tested Netsurf 2.9 in this regard. Haven’t yet had chance to go to the Netsurf group with it.

Michael: NetSurf’s handling of 64K modes on RISC OS 5 seems to not be good either

I believe the problem there is that Tinct doesn’t understand any of the new screen modes. 64K &BGR modes work fine, but red-blue swapped modes (like the 64K mode on the Pi) and 4K colour modes will be wrong.

Indeed, it’s a Tinct issue. I’ve not heard from its developer (Richard Wilson) for a few years.

Great support work guys. The issue was due to a build error which meant we didn’t have the NetTime module in our disc image, which in turn meant the system thought it was 2013, which in turn meant NetSurf was quite correctly suspicious of SSL certificates. Sorted.

OK, good. Glad that’s sorted. :)

If you’re shipping 3.0 or later, please don’t include a Choices file on the disc image. :)

Indeed, it’s a Tinct issue. I’ve not heard from its developer (Richard Wilson) for a few years.

I thought it was widely known that Tinct isn’t compatible and that appropriate settings to avoid its use were the only answer.

IIRC the OwlArt site is a good test of the correct settings – set them wrong and NS crashes.

IIRC the OwlArt site is a good test of the correct settings – set them wrong and NS crashes.

Which probably means I should apologise for the seriously old design of the site!

Which probably means I should apologise for the seriously old design of the site!

If you change it I need to go searching for a new test target. You could perhaps check what specifically causes the crash and then deliberately create a NetSurf test page set then pass on the info to the NetSurf developers.
At work I complain that non-reproducible errors are awkward to fix and when someone gives me a solid reproducible error I’m happy. They think I’m strange.

We are aiming for a stable download but it will take iterative betas to arrive there. And there’s no correct beta release on our site; they are just snapshots of the head of the development tree.

This approach is sensible for all those platforms for which a stable, earlier release is available (all but the Pi and the Pandaboard) and sensible for the Pi (where there is a separate recommended beta RC11 release).

In the case of the Pandaboard, a new user is presented with a lottery. You either pays your money (to RComp for a PandaLand SD card) or takes your choice (whatever beta release is there that day with no (or little) hint as to when BOTH a milestone is reached with useful new features AND tinkering with prospective new things is harmless). This makes a no-cost option for the Pandaboard much more difficult than it need be. Even if experienced users tell you things like ‘the rom on [some particvular date] was a good one’.

You are, in principle, encouraging unofficial distribution channels to appear for Pandaboard rom images.

I think that the Panda situation is fair game.

If someone else wishes to host a free support and download resource for OMAP4 ROMS etc., then they can do so. The closest option today is the RComp commercial route.

Frankly, anyone downloading from here should almost expect issues. If you are interested in cutting-edge OS images, then you really do need to know what you’re doing etc.