|
OpenBSD Packages and Ports Installation and upgrading of packages and ports on OpenBSD. |
|
Thread Tools | Display Modes |
|
|||
It works fine here out of the box.
__________________
Many thanks to the forum regulars who put time and effort into helping others solve their problems. |
|
|||
The FAQ has sections on remapping keyboards and localization.
FAQ Quote:
|
|
||||
Quote:
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)? |
|
|||
Quote:
Quote:
__________________
Many thanks to the forum regulars who put time and effort into helping others solve their problems. |
|
||||
Quote:
"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 Code:
(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 |
|
|||
Quote:
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. |
|
|||
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.
|
|
||||
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... |
|
||||
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: Code:
[ 1.340254] E: luakit: luaH_panic:264: unprotected error in call to Lua API (CPU not supported) 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. |
|
||||
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).
__________________
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. |
|
||||
Quote:
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. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Security Zero day Java exploit being used in the wild | jggimi | News | 7 | 20th January 2013 07:18 AM |
Security New Adobe Reader zero-day in the wild | J65nko | News | 1 | 8th December 2011 08:22 PM |
daemonforums in Midori | Mr-Biscuit | Off-Topic | 3 | 8th January 2011 10:35 PM |
Midori port | roddierod | OpenBSD Packages and Ports | 18 | 6th January 2011 04:01 PM |
Dev goes 'Wild' with H.264 Firefox | J65nko | News | 0 | 19th May 2010 09:43 PM |