pkg_add midori ...or dependencies gone wild

[backrow]

Originally Posted by fvgit

If it works for you I must obviously be doing sth. wrong. Did you perform any special configuration steps, any command line options?

It works fine here out of the box.

[fvgit]

Originally Posted by backrow

It works fine here out of the box.

Surprise! Posting with netsurf-fb right now. It works indeed, BUT...

there is a problem with the character encoding. That is why I could not log in yesterday. The browser just wasn~t sending the password I thought I was typing
(for instance slash gives me an ampersand, semi-colon and colon give me < and > respectively, Umlauts are dead as is any combination with the Alt modifier)

I changed my password temporarily to just contain characters I know I can successfully type.

I have these settings

"de.nodead" in kbdtype (in etc)
"de_DE.UTF-8" as LC_CTYPE in .profile (in $HOME)
X11 is started with the startx command

All keys & characters seem to work fine in an xterm, but not in netsurf-fb.

Is there anything I might be overlooking *question mark* (<- gotta be inventive)

[shep]

The FAQ has sections on remapping keyboards and localization.
FAQ

The level of UTF-8 support and the default encoding configuration vary greatly with the program or library. For example, xterm(1) has full UTF-8 support enabled by default, while the regular expression library does not have any UTF-8 support yet.

To use the Unicode character set in UTF-8 encoding whereever supported, set the LC_CTYPE environment variable to the value en_US.UTF-8:

If logging in via xdm(1), add export LC_CTYPE="en_US.UTF-8" to your ~/.xsession before starting the window manager. See customizing X for more details.
If logging in via the text console, add export LC_CTYPE="en_US.UTF-8" to your ~/.profile. The text console's UTF-8 support is a work in progress, and some non-ASCII characters may not display properly.
When logging into remote systems with ssh(1), the LC_CTYPE environment variable is not propagated, and you have to make sure that the local terminal is set to the character encoding used by the remote server before starting the ssh(1) client program. If that encoding is unknown or unsupported by OpenBSD, make sure you use the default xterm(1) configuration and set LC_CTYPE=en_US.UTF-8 in the remote shell after connecting.
The OpenBSD base system completely ignores all locale-related environment variables except LC_CTYPE; even LC_ALL and LANG only affect the character encoding. Some ports may respect other LC_* variables, but using them or setting LC_CTYPE to any value other than C, POSIX or en_US.UTF-8 is not recommended.

[fvgit]

Originally Posted by shep

The FAQ has sections on remapping keyboards and localization.
FAQ

Yes, I had already consulted that part of the FAQ. (I think there's also a recent topic here about german umlauts). Anyway, neither the recommended en_US.UTF-8 nor my alternative de_DE.UTF-8 settings (trying can't hurt) proved successful.

Am I right to assume in this case I will just have to wait for full character support for the time being?

Oh, btw, could the xcb library incompatibility have anything to do with it (see my earlier reply above)?

[backrow]

Originally Posted by fvgit

Am I right to assume in this case I will just have to wait for full character support for the time being?

My first instinct is that SDL is grabbing the keys in a way that ignores the X keyboard settings. Maybe try the XCB frontend? (“netsurf-fb -f x”) That may fix the weird mappings, but I’m not sure it will help with dead keys; I’ve never gotten the compose key (which in X is similar to dead keys) to work even on the GTK frontend.

Originally Posted by fvgit

Oh, btw, could the xcb library incompatibility have anything to do with it (see my earlier reply above)?

No, the SDL frontend doesn’t use XCB at all. By the way, the proper fix for that would be to remove the symlink, build netsurf-fb on your machine, and link it against your existing libraries. Or, alternately, to update your base system and packages to a new snapshot (one that’s in sync).

[fvgit]

Originally Posted by backrow

My first instinct is that SDL is grabbing the keys in a way that ignores the X keyboard settings. Maybe try the XCB frontend? (“netsurf-fb -f x”) That may fix the weird mappings, but I’m not sure it will help with dead keys; I’ve never gotten the compose key (which in X is similar to dead keys) to work even on the GTK frontend.



No, the SDL frontend doesn’t use XCB at all. By the way, the proper fix for that would be to remove the symlink, build netsurf-fb on your machine, and link it against your existing libraries. Or, alternately, to update your base system and packages to a new snapshot (one that’s in sync).

Just updated to a new snapshot (i386, Sep 5). pkg_add went fine and smooth, no errors. Alas:
"netsurf-fb -f x" produces just an empty white window, no reaction/response to any clicks or keys. FWIW i had the same reaction with the old snapshot (with the libxcb symlink) before the upgrade.

"netsurf-fb -f sdl" or plain netsurf-fb (without any options) now just aborts with the error message "Unable to initialise framebuffer".

Here's the full output from "netsurf-fb -v" note the line about libnsfb at the end

(0.000006) utils/log.c:101 nslog_init: NetSurf version '3.5 (6th April 1016)'
(0.005169) utils/log.c:110 nslog_init: NetSurf on <OpenBSD>, node <testbox.testnet.net>, release <6.0>, version <GENERIC#2015>, machine <i386>
(0.011924) utils/messages.c:188 messages_add_from_file: Loading Messages from '/usr/local/share/netsurf-fb/Messages'
(0.095814) image/image_cache.c:378 image_cache_init: Image cache initilised with a limit of 3145728 hysteresis of 629145
(0.100883) render/html_css_fetcher.c:64 html_css_fetcher_initialise: html_css_fetcher_initialise called for x-ns-css
(0.107004) content/fetchers/curl.c:1285 fetch_curl_register: curl_version libcurl/7.50.1 LibreSSL/2.0.0 zlib/1.2.3 libidn/1.33 nghttp2/1.14.0
(0.153610) utils/useragent.c:68 user_agent_build_string: Built user agent "NetSurf/3.5 (OpenBSD)"
(0.157979) content/fetchers/curl.c:1371 fetch_curl_register: cURL linked against openssl
(0.161678) content/fetchers/curl.c:115 fetch_curl_initialise: Initialise cURL fetcher for http
(0.167289) content/fetchers/curl.c:115 fetch_curl_initialise: Initialise cURL fetcher for https
(0.171072) content/fetchers/data.c:65 fetch_data_initialise: fetch_data_initialise called for data
(0.197479) content/fetchers/resource.c:298 fetch_resource_initialise: redirect url for adblock.css
(0.244720) content/fetchers/resource.c:298 fetch_resource_initialise: redirect url for default.css
(0.291458) content/fetchers/resource.c:298 fetch_resource_initialise: redirect url for internal.css
(0.337338) content/fetchers/resource.c:298 fetch_resource_initialise: redirect url for quirks.css
(0.353052) content/fetchers/resource.c:298 fetch_resource_initialise: redirect url for credits.html
(0.353379) content/fetchers/resource.c:298 fetch_resource_initialise: redirect url for licence.html
(0.353632) content/fetchers/resource.c:298 fetch_resource_initialise: redirect url for welcome.html
(0.353880) content/fetchers/resource.c:298 fetch_resource_initialise: redirect url for maps.html
(0.355115) content/fetchers/resource.c:298 fetch_resource_initialise: redirect url for netsurf.png
(0.357365) content/llcache.c:3336 llcache_initialise: llcache initialising with a limit of 9437184 bytes
(0.357763) framebuffer/gui.c:450 process_cmdline: argc 1, argv 0xcf7d23e4
(0.358157) framebuffer/framebuffer.c:400 framebuffer_initialise: The sdl surface is not available from libnsfb

Unable to initialise framebuffer

[shep]

Just updated to a new snapshot (i386, Sep 5). pkg_add went fine and smooth, no errors

.

Sometimes in current, packages lag the core libraries.

The i386 builds from Sep 6 included allowing W^X violations in webkitgtk3 - xombrero is working again. There is a good chance that the Sep 6 builds will correct your netsurf-fb problem.

[fvgit]

The snapshot build dates on the mirror I installed from are Sep 5 for the i386 base system and Sep 6 for the packages. Is this normal or should they be identical?

[shep]

They are rarely identical. The core teams and package teams are separate, although they do keep an eye on each other. If you had done your upgrade Sep 5 the packages would have been from Sep 2.

[fvgit]

Logged in with firefox-esr-38.6.1, application start took about 75 secs. Very slow take-off, although once a page has loaded it's more or less sufferable. For instance navigating a page like undeadly was almost possible at 'normal' speed, but getting there will challenge your self-control. Opening a second tab is definitely NOT recommended.
I'll have to compare this again to the other firefox and the 6.0-foxes. No keyboard problems, btw.
Mozilla devs have a sense of humour: Turtle icon at the bottom with the words "Mozilla Firefox seems slow... to... start."

Also tested arora (package log attached): very scary animal, firefox is tame in comparison. Memory consumption like sth. out of a horror movie. I happened to have top running and you could literally watch it grow by the second. With each of top's 5-sec updates there was another big jump and the system soon began to crawl. I had to kill it in self defense. Otherwise it would have eaten up my computer, then myself, the house, the street...

[fvgit]

My latest results: Raiders of the lost error message, a couple of knock outs and I met Dr. Jekyll & Mr. Hyde.

First came vimb. It was not entirely stable dumping core on some pages. But when it works it's not bad. Probably in the same category as Surf. I'll need to take a closer look in round two.

Next up was luakit. Instead of starting I received a red error message in my xterm:

[    1.340254] E: luakit: luaH_panic:264: unprotected error in call to Lua API (CPU not supported)

Fair enough. I liked the coloured message, is that a python thing? The explanation: The lua API requires a CPU instruction called CMOV (conditional move) introduced by Intel in the Pentium Pro architecture and not present in my AMD K6III. It seems this error is so rare that even google has only about two hits. It felt a bit like Dr. Jones recovering a rare artifact in an ancient temple, hehe. So until I have my macbook up and running luakit will have to wait. That being said, I wonder if it'd be possible to trick the lua api into thinking it's running on a different cpu?

After that I tried Iridium which coredumped right away. This wasn't entirely unexpected after my experience with chromium the other day. AFAIK they share the same codebase.

On to Surf2 which immediately coredumped. It also took the cake pulling in a record-breaking 130 dependencies, incl. samba among other things. I know this is the way how things are in the ports department, but I still think it's madness.
As a medium-term project I will absolutely have to dig deeper into the whole ports & package infrastructure thing to understand the how & why. The situation annoys me immensely and I at least need to make sense of it.

Epiphany, despite its name just coredumped. That's three coredumps in a row. Perhaps I should try my luck with the slot machines in Vegas.

And last but not least, I met Dr. Jekyll and Mr. Hyde in the form of qutebrowser (6.0-current)
Let's start with the ugly Mr Hyde: an incredible 116 dependencies (not far behind Surf2) and, fasten your seat belts, a record-breaking startup-up time of 2:30 minutes. Yes, that's two minutes and thirty seconds.
Mr. Hyde's other face is that of Dr. Jekyll and he's one dapper gent: A slick interface with vi-like keyboard navigation (no gtk-like widget nonsense or anything like that). The browser config window pops up
just like the quake console, only from below not from above. And despite its unprecedentedly slow initialization, it is in fact still usable on my outdated hardware. I can't wait to try this on a more modern machine. The port is fairly new, it was added to the ports tree only a few weeks ago. I wish this thing had a smaller foot print, but the interface is really nice. I encourage anyone to try it out. http://openports.se/www/qutebrowser

Unless I oversaw a candidate that concludes round one.

[Carpetsmoker]

qutebrowser is pretty nice. I used it for a while and actually made some pull requests for it.

I stopped using it because it uses an old version of WebKit and after many years of using "alternative" browsers I was just tired of fighting with web page compatibility, idiotic messages warning me that my browser is unknown, etc. so I just started using Firefox. More recently however I've been forced to switch to Chromium since some websites have serious performance issues with Firefox. Unfortunately Chromium has some other serious issues that would be rather off-topic here ;-)

That being said, work on switching qutebrowser to QtWebEngine (the newer version of WebKit) seems to be on its way, but there are still bugs and features missing (see this).

[fvgit]

Originally Posted by Carpetsmoker

qutebrowser is pretty nice. I used it for a while and actually made some pull requests for it.

I saw its name pop up on openports.se a while ago and then did a forum search here. The only hit was one of your posts. I really like it despite not having tested it thoroughly. But first impressions were favourable. It somehow feels 'different', if that makes any sense.
Btw, I could live with using different browsers for different goals. I'd rather prefer it to one size fits all, I think.

Anyway, as soon as I have upgraded to a new current snapshot I plan to give it and the rest of the gang a more closer look (and also a more organised one!). Despite the naysayers, I'd say things aren't looking too bleak for my old hardware. At least not yet.