Monday, 8 December 2025

[netsurf-dev] Re: toolchains: branch jmb/sdk-update updated. a5187886ae92325c9859ac5efaefae0d851137b4

Hey John-Mark

In relation to the below, I was trying to update this to a newer GCC - you can see my attempt in chris/m68k-gcc15. Ultimately I gave up as it kept complaining about not being able to create binaries. In theory this compiler does work outside the NetSurf toolchain, but I'm not familiar enough with the workings of GCC to figure out what's wrong here.

There might be some of my NDK 3.2 updates on that branch which will need reverting. I'm holding off moving to that until after the next NetSurf release, as it's going to break 3.5/3.9 compatibility.

Chris


8 Dec 2025 01:19:41 NetSurf Browser Project <dmarc-noreply@freelists.org>:

Gitweb links:

...log http://git.netsurf-browser.org/toolchains.git/shortlog/a5187886ae92325c9859ac5efaefae0d851137b4
...commit http://git.netsurf-browser.org/toolchains.git/commit/a5187886ae92325c9859ac5efaefae0d851137b4
...tree http://git.netsurf-browser.org/toolchains.git/tree/a5187886ae92325c9859ac5efaefae0d851137b4

The branch, jmb/sdk-update has been updated
       via  a5187886ae92325c9859ac5efaefae0d851137b4 (commit)
       via  0ed58efcbe99982c34cd31623fbd3c49499b998d (commit)
       via  6cfb90abc9798bf4c6b29a30b0f58291cfaaf1b9 (commit)
       via  7e09c0d16f371bd95d982243a75612a855e83fb3 (commit)
       via  841d3230a29004935514443aa831f24e594ca57c (commit)
       via  2bffa4dc4e5bcc57e1fd996567dee292b40a1889 (commit)
      from  78390cc946b54c1e4b79fb0d6ff12638f1b3de40 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commitdiff http://git.netsurf-browser.org/toolchains.git/commit/?id=a5187886ae92325c9859ac5efaefae0d851137b4
commit a5187886ae92325c9859ac5efaefae0d851137b4
Author: John-Mark Bell <jmb@netsurf-browser.org>
Commit: John-Mark Bell <jmb@netsurf-browser.org>

    m68k-unknown-amigaos: disable fatal warnings in GCC14
   
    The sources being built here are ancient and give GCC14 a large
    amount of (reasonable) indigestion. It is intractable to patch
    these, so simply stop the fatal ones being fatal. Trying to build
    GCC 3.4.6 (or binutils 2.14) from source with any modern compiler
    is increasingly unlikely to work without copious warnings, at
    minimum.
   
    Thus, this entire toolchain is in need of updating to something
    more modern (if, indeed, such a thing exists).

diff --git a/m68k-unknown-amigaos/Makefile b/m68k-unknown-amigaos/Makefile
index c232f2b..437c309 100644
--- a/m68k-unknown-amigaos/Makefile
+++ b/m68k-unknown-amigaos/Makefile
@@ -154,7 +154,7 @@ $(BUILDSTEPS)/ndk.d: $(SOURCESDIR)/$(UPSTREAM_NDK_TARBALL) $(SOURCESDIR)/$(UPSTR
###

$(BUILDSTEPS)/bootstrap-compiler.d: $(BUILDSTEPS)/bison.d $(BUILDSTEPS)/srcdir-step3.d $(BUILDSTEPS)/binutils.d
-   cd $(BUILDDIR) && $(GCC_ENV_PARAMS) $(GCC_SRCDIR)/configure \
+   cd $(BUILDDIR) && $(GCC_ENV_PARAMS) CFLAGS="-Wno-implicit-int -Wno-implicit-function-declaration -Wno-incompatible-pointer-types" $(GCC_SRCDIR)/configure \
                --prefix=$(PREFIX) \
                --target=$(TARGET_NAME) \
                --disable-threads \
@@ -223,7 +223,7 @@ $(BUILDSTEPS)/$(UPSTREAM_BISON_TARBALL).d: $(BUILDSTEPS)/buildsteps.d $(SOURCESD
# Build a 32bit binary until this gets fixed
$(BUILDSTEPS)/binutils.d: $(BUILDSTEPS)/binutils-srcdir.d
    mkdir -p $(BUILDDIR)/binutils
-   cd $(BUILDDIR)/binutils && CFLAGS="-m32" LDFLAGS="-m32" $(BINUTILS_SRCDIR)/configure --prefix=$(PREFIX) --target=$(TARGET_NAME) --disable-nls --disable-werror
+   cd $(BUILDDIR)/binutils && CFLAGS="-m32 -Wno-implicit-int -Wno-implicit-function-declaration" LDFLAGS="-m32" $(BINUTILS_SRCDIR)/configure --prefix=$(PREFIX) --target=$(TARGET_NAME) --disable-nls --disable-werror
    cd $(BUILDDIR)/binutils && make
    cd $(BUILDDIR)/binutils && make install
    touch $@


commitdiff http://git.netsurf-browser.org/toolchains.git/commit/?id=0ed58efcbe99982c34cd31623fbd3c49499b998d
commit 0ed58efcbe99982c34cd31623fbd3c49499b998d
Author: John-Mark Bell <jmb@netsurf-browser.org>
Commit: John-Mark Bell <jmb@netsurf-browser.org>

    m68k-unknown-amigaos: pin a known-working binutils
   
    It turns out that the Makefile would just fetch whatever was at
    the top of the SVN branch, which is unfortunate. It also turns
    out that nothing happens if there's already a stamp file
    indicating that the sources have been obtained. Pin the revision
    last fetched by the CI worker (which dates from 2017, so is
    hardly modern) as that is known to work (and our patches apply
    to it).

diff --git a/m68k-unknown-amigaos/Makefile b/m68k-unknown-amigaos/Makefile
index a9c17d2..c232f2b 100644
--- a/m68k-unknown-amigaos/Makefile
+++ b/m68k-unknown-amigaos/Makefile
@@ -7,10 +7,11 @@ UPSTREAM_GCC_VERSION := 3.4.6
UPSTREAM_GCC_TARBALL := gcc-$(UPSTREAM_GCC_VERSION).tar.bz2
UPSTREAM_GCC_URI := http://ftp.gnu.org/gnu/gcc/gcc-$(UPSTREAM_GCC_VERSION)/$(UPSTREAM_GCC_TARBALL)

+UPSTREAM_BINUTILS_REVISION := 630
UPSTREAM_BINUTILS_VERSION := 2.14
# Not a tarball; so sue me
UPSTREAM_BINUTILS_TARBALL := binutils-$(UPSTREAM_BINUTILS_VERSION)
-UPSTREAM_BINUTILS_URI := http://svn.code.sf.net/p/adtools/code/branches/binutils/$(UPSTREAM_BINUTILS_VERSION)/
+UPSTREAM_BINUTILS_URI := http://svn.code.sf.net/p/adtools/code/branches/binutils/$(UPSTREAM_BINUTILS_VERSION)/@$(UPSTREAM_BINUTILS_REVISION)

UPSTREAM_GMP_VERSION := 4.3.2
UPSTREAM_GMP_TARBALL := gmp-$(UPSTREAM_GMP_VERSION).tar.bz2


commitdiff http://git.netsurf-browser.org/toolchains.git/commit/?id=6cfb90abc9798bf4c6b29a30b0f58291cfaaf1b9
commit 6cfb90abc9798bf4c6b29a30b0f58291cfaaf1b9
Author: John-Mark Bell <jmb@netsurf-browser.org>
Commit: John-Mark Bell <jmb@netsurf-browser.org>

    SDK/libcurl: refresh patches for m68k-unknown-amigaos

diff --git a/sdk/recipes/patches/libcurl/m68k-unknown-amigaos/lib.curl_setup.h.p b/sdk/recipes/patches/libcurl/m68k-unknown-amigaos/lib.curl_setup.h.p
index ba595ca..0e3a6d3 100644
--- a/sdk/recipes/patches/libcurl/m68k-unknown-amigaos/lib.curl_setup.h.p
+++ b/sdk/recipes/patches/libcurl/m68k-unknown-amigaos/lib.curl_setup.h.p
@@ -1,10 +1,10 @@
--- lib/curl_setup.h.orig  2017-10-10 15:19:45.611896396 +0100
+++ lib/curl_setup.h   2017-10-17 15:42:25.304921197 +0100
-@@ -314,7 +314,6 @@
+@@ -454,7 +454,6 @@
   * In clib2 arpa/inet.h warns that some prototypes may clash
   * with bsdsocket.library. This avoids the definition of those.
   */
-#  define __NO_NET_API
 

Saturday, 29 November 2025

[netsurf-users] Re: Fonts

On 29 Nov, Drag N Drop wrote in message
<3D59E7C8-8322-4B22-818A-828B88073AF0@dragdrop.co.uk>:

> Ah, so it's really only for if it comes across a particular character not
> available the default font (Homerton.Medium on RISC OS?) it will see if it
> can get it from A.N.Other font, you think?

Isn't it RUfl that's doing the scanning (or on whose behalf NetSurf is doing
the scanning)?

https://www.netsurf-browser.org/projects/rufl/

It's to enable the rendering of Unicode glyphs which aren't represented in
the current system character set.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

[netsurf-users] Re: Fonts

Ah, so it's really only for if it comes across a particular character not available the default font (Homerton.Medium on RISC OS?) it will see if it can get it from A.N.Other font, you think?

Kinda hoping you could write some CSS styling like

@font-face { font-family: 'customfont'; src: url('<Font$Path>.SomeRISCfont') }

body { font-family: customfont; }

so if the page is rendered on RISC OS it would use the specified SomeRISCfont and if it was on non-RISC OS it would fall back on standard fonts on that system.

Chris.
Drag N Drop | Publications for RISC OS computers | www.dragdrop.co.uk

On 29 November 2025 16:55:36 GMT, Paul Sprangers <dmarc-noreply@freelists.org> wrote:
>In article <9152F4A5-E371-4F53-819C-46AAEB402C99@dragdrop.co.uk>,
> Drag N Drop <dmarc-noreply@freelists.org> wrote:
>
>> I've always wondered what the point is of Netsurf scanning and keeping a
>> file of information about fonts.
>
>As far as I've understood, NetSurf scans all active fonts in order to be
>able to display as many different pages as possible, particularly pages
>that contain other characters than the Latin1 ones.
>
>Paul
>

[netsurf-users] Re: Fonts

In article <9152F4A5-E371-4F53-819C-46AAEB402C99@dragdrop.co.uk>,
Drag N Drop <dmarc-noreply@freelists.org> wrote:

> I've always wondered what the point is of Netsurf scanning and keeping a
> file of information about fonts.

As far as I've understood, NetSurf scans all active fonts in order to be
able to display as many different pages as possible, particularly pages
that contain other characters than the Latin1 ones.

Paul

--
https://riscos.sprie.nl

[netsurf-users] Fonts

Hi all,

Can anyone point me to any documentation about fonts in Netsurf, this is on RISC OS although not sure if it applies to all/other platforms.

Asking because I've always wondered what the point is of Netsurf scanning and keeping a file of information about fonts.

For example, is there a way of utilising local (RISC OS) fonts on web pages eg in CSS code?

Thanks

Chris.

Drag N Drop | Publications for RISC OS computers | www.dragdrop.co.uk

Sunday, 16 November 2025

[netsurf-dev] NetSurf domain down

All of the *.netsurf-browser.org services appear to be down.

Just in case you weren't already aware.

Chris

Friday, 14 November 2025

[netsurf-dev] Fwd: [FOSDEM] Call for participation: Retrocomputing Devroom - FOSDEM 2026

_______________________________________________
FOSDEM mailing list
FOSDEM@lists.fosdem.org
https://lists.fosdem.org/listinfo/fosdem-------- Message transféré --------
Sujet : [FOSDEM] Call for participation: Retrocomputing Devroom -
FOSDEM 2026
Date : Wed, 5 Nov 2025 00:04:19 +0100 (CET)
De : Sebas Devroom manager FOSDEM 2024 Retrocomputing <seg@seglabs.eu>
Pour : devrooms@fosdem.org <devrooms@fosdem.org>,
fosdem@lists.fosdem.org <fosdem@lists.fosdem.org>,
devroom-managers@lists.fosdem.org <devroom-managers@lists.fosdem.org>,
retrocomputing-devroom-manager@fosdem.org
<retrocomputing-devroom-manager@fosdem.org>



*******************************************************************************

*                                                                       
                                             *
* # FOSDEM 2026 - Retrocomputing Devroom - Call for participation: #    *
*                                                                       
                                             *
*                                                                       
                                             *
*******************************************************************************


* Retrocomputing Devroom - WHAT
FOSDEM offers open source and free software developers a place to meet,
share ideas and collaborate. Renowned for being highly
developer-oriented, the event brings together some 8500+ participants
from all over the world.
The twenty-sixth edition will take place Saturday 31st January and
Sunday 01st February 2026 in Brussels, Belgium.
The *Retrocomputing DevRoom* will welcome your talks about usage of
older computing hardware and software in modern times.
* Presentation topics may include, but are not limited to:
    - Emulation of old systems (i.e. to run videogames, legacy
software, etc.);
    - New software, hardware or related to be used with classic systems;
    - Open source software emulation/simulation;
    - Open hardware;
    - Operating systems for retrocomputers & retrosystems;
    - Uses of retrocomputing today;
    - Other retrocomputing topics;
FOSDEM is an open source conference, therefore commercial and/or
marketing presentations are not allowed.
* Timeline - WHEN
- Deadline submission of your talk proposal:  December 01st 2025;
- Accepted talks to be notified by December 15th, 2025;
- FOSDEM dates 31st January & 01st February 2026;
- *Retrocomputing devroom: 01st February 2026 (afternoon).*
* Submission of proposal - practicalities - HOW
We are accepting talks of 20-30 minutes, with time for Q&A's afterwards.
Should you need less or more time, please let us know in your submission.
The conference language is English.
Talks will be delivered live, no pre-recorded talks!!
All submissions have to be made in the pretalx event planning tool:
https://fosdem.org/submit (https://pretalx.fosdem.org/fosdem-2026/cfp)
While creating your proposal, please provide the title of your talk, a
short abstract (one or two paragraphs), and some information about
yourself (name, bio, and photo).
If you used Pentabarf for a previous FOSDEM edition, we are sorry to
inform you the data wasn't migrated.
Make sure you select "Retrocomoputing" Devroom!!

* Recording Permission - CONSENT
All FOSDEM talks will be recorded; this requires speakers to consent to
being recorded and streamed.
Therefore, should you wish to be a speaker, please note you implicitly
give consent for your talk to be recorded and streamed. The recordings
will be published under the same license as all FOSDEM content (CC-BY).


* Volunteering - SUPPORT
A couple of volunteers would be welcome to support during the afternoon
session, ie.: pass the mic. around the room; control room attendance
capacity; technical setup; etc.
Please reach out if you want to contribute in that sense.

* Contact
retrocomputing-devroom-manager at fosdem.org

* See you at FOSDEM!
FOSDEM is a free event for software developers to meet, share ideas and
collaborate. Every year, thousands of developers of free and open source
software from all over the world gather at the event in Brussels.
https://fosdem.org
By participating to the FOSDEM, you are required to adhere to the Code
of Conduct:
https://fosdem.org/2026/practical/conduct/