On 18 Sep, tlsa@netsurf-browser.org typed:
> 1. Hotlist viewer (bookmarks)
> 2. Global history viewer
> 3. Cookie manager window
By the way, 'Global history' doesn't appear to include the list given
by the main window's drop-down 'URL suggestion icon'. That list is
stored in file Choices.WWW.NetSurf.URL. I'm unclear which URLs are
placed there, but I do see that it is unaffected by deleting the
items from Global history.
Yet it is a history of sorts which has to be manually deleted should
one wish to clear all actual history.
Any thoughts?
RISC OS 5.23 Netsurf 3.7 (Dev CI #4213)
--
Bernard
Tuesday, 3 October 2017
Re: [gccsdk] Unable to autpbuild libpng12-0
Hi,
Thanks for that, guys.On Mon, 2 Oct 2017 at 16:38 Theo Markettos <theo@markettos.org.uk> wrote:
On Mon, Oct 02, 2017 at 04:15:12PM +0100, Lee Noar wrote:
> No, something has changed; I can't build it either. It was okay in June
> when I last built it. As a work around for this package, you can add:
>
> AB_URL=http://http.debian.net/debian/pool/main/libp/libpng/libpng_1.2.50.orig.tar.xz
>
> to the top of its setvars file until we figure out what's going on.
>
> If it turns out to be more widespread, ie, others packages are the
> same, then perhaps they've changed the server's name or structure
> and we need to catch up.
I think this is the result of Debian releasing version 9 'stretch' in July.
Since we mostly pick up sources from the 'stable' and/or 'testing' Debian
repos, a new Debian release means they advance their sources according to
their release schedule (so now stable='stretch' and testing='buster',
eventually to be v10). That may break RISC OS packaging scripts that look
for or depend on specific package names from a previous release. Libraries
with the version number in the package name are particularly vulnerable.
In stretch the package is libpng-dev (for the header files) and libpng16-16
(for the library binaries) so it would be worth renaming to libpng16-16 and
see if it's possible to build that. If so, it's probably worth changing the
'depends' files of packages that depend on libpng12 to libpng16-16. It may
be we need to retain the libpng12 package because some programs won't work
with libpng 1.6, in which case pinning it to the source tarball as Lee
indicates above is probably going to be necessary. But we should move as
much as possible to 1.6.
A rename is simply renaming the folder inside the autobuilder/ tree, and
possibly changing the setvars script inside it as well. The autobuilder
scripts should pick that up and find the right sources.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Monday, 2 October 2017
Re: [gccsdk] Unable to autpbuild libpng12-0
On Mon, Oct 02, 2017 at 04:15:12PM +0100, Lee Noar wrote:
> No, something has changed; I can't build it either. It was okay in June
> when I last built it. As a work around for this package, you can add:
>
> AB_URL=http://http.debian.net/debian/pool/main/libp/libpng/libpng_1.2.50.orig.tar.xz
>
> to the top of its setvars file until we figure out what's going on.
>
> If it turns out to be more widespread, ie, others packages are the
> same, then perhaps they've changed the server's name or structure
> and we need to catch up.
I think this is the result of Debian releasing version 9 'stretch' in July.
Since we mostly pick up sources from the 'stable' and/or 'testing' Debian
repos, a new Debian release means they advance their sources according to
their release schedule (so now stable='stretch' and testing='buster',
eventually to be v10). That may break RISC OS packaging scripts that look
for or depend on specific package names from a previous release. Libraries
with the version number in the package name are particularly vulnerable.
In stretch the package is libpng-dev (for the header files) and libpng16-16
(for the library binaries) so it would be worth renaming to libpng16-16 and
see if it's possible to build that. If so, it's probably worth changing the
'depends' files of packages that depend on libpng12 to libpng16-16. It may
be we need to retain the libpng12 package because some programs won't work
with libpng 1.6, in which case pinning it to the source tarball as Lee
indicates above is probably going to be necessary. But we should move as
much as possible to 1.6.
A rename is simply renaming the folder inside the autobuilder/ tree, and
possibly changing the setvars script inside it as well. The autobuilder
scripts should pick that up and find the right sources.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> No, something has changed; I can't build it either. It was okay in June
> when I last built it. As a work around for this package, you can add:
>
> AB_URL=http://http.debian.net/debian/pool/main/libp/libpng/libpng_1.2.50.orig.tar.xz
>
> to the top of its setvars file until we figure out what's going on.
>
> If it turns out to be more widespread, ie, others packages are the
> same, then perhaps they've changed the server's name or structure
> and we need to catch up.
I think this is the result of Debian releasing version 9 'stretch' in July.
Since we mostly pick up sources from the 'stable' and/or 'testing' Debian
repos, a new Debian release means they advance their sources according to
their release schedule (so now stable='stretch' and testing='buster',
eventually to be v10). That may break RISC OS packaging scripts that look
for or depend on specific package names from a previous release. Libraries
with the version number in the package name are particularly vulnerable.
In stretch the package is libpng-dev (for the header files) and libpng16-16
(for the library binaries) so it would be worth renaming to libpng16-16 and
see if it's possible to build that. If so, it's probably worth changing the
'depends' files of packages that depend on libpng12 to libpng16-16. It may
be we need to retain the libpng12 package because some programs won't work
with libpng 1.6, in which case pinning it to the source tarball as Lee
indicates above is probably going to be necessary. But we should move as
much as possible to 1.6.
A rename is simply renaming the folder inside the autobuilder/ tree, and
possibly changing the setvars script inside it as well. The autobuilder
scripts should pick that up and find the right sources.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Unable to autpbuild libpng12-0
On 02/10/17 14:04, Jason Tribbeck wrote:
> Hi,
>
> I'm just trying to autobuild libpng12-0, and it appears as though it's
> unable to find it in the downloaded sources:
[snip]
> Unfortunately, I'm not that familiar with the autobuild system, so I've
> no idea if libpng-dev can be easily swapped in. It's entirely possible
> I've done something weird :)
No, something has changed; I can't build it either. It was okay in June
when I last built it. As a work around for this package, you can add:
AB_URL=http://http.debian.net/debian/pool/main/libp/libpng/libpng_1.2.50.orig.tar.xz
to the top of its setvars file until we figure out what's going on.
If it turns out to be more widespread, ie, others packages are the
same, then perhaps they've changed the server's name or structure
and we need to catch up.
Lee.
.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Hi,
>
> I'm just trying to autobuild libpng12-0, and it appears as though it's
> unable to find it in the downloaded sources:
[snip]
> Unfortunately, I'm not that familiar with the autobuild system, so I've
> no idea if libpng-dev can be easily swapped in. It's entirely possible
> I've done something weird :)
No, something has changed; I can't build it either. It was okay in June
when I last built it. As a work around for this package, you can add:
AB_URL=http://http.debian.net/debian/pool/main/libp/libpng/libpng_1.2.50.orig.tar.xz
to the top of its setvars file until we figure out what's going on.
If it turns out to be more widespread, ie, others packages are the
same, then perhaps they've changed the server's name or structure
and we need to catch up.
Lee.
.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] Unable to autpbuild libpng12-0
Hi,
I'm just trying to autobuild libpng12-0, and it appears as though it's unable to find it in the downloaded sources:jason@sourceror:~/gccsdk/trunk/build$ ../autobuilder/build -v libpng12-0
Autobuilder warning: polkit-policy-file-validate not found; continuing anyway
Autobuilder: using GCCSDK set values
Autobuilder: no local build-setvars found, using default build parameters
Autobuilder: Package "libpng12-0" will be built using rules at "/home/jason/gccsdk/trunk/autobuilder/libraries/graphics/libpng12-0"
Autobuilder: Dependency zlib1g satisfied by previous successful build
Autobuilder: Building package: libpng12-0
Autobuilder: Detected 4 CPUs: set AB_CPUS to use more or fewer (eg in case build breaks)
Autobuilder: Fetching source for libpng12-0
Autobuilder: Using existing Sources.gz (testing/main)
Autobuilder: Using existing Sources.gz (testing/contrib)
Autobuilder: Using existing Sources.gz (stable/main)
Autobuilder: Using existing Sources.gz (stable/contrib)
Autobuilder: Searching for libpng12-0 in ../Sources-testing-main.gz...
Autobuilder: Searching for libpng12-0 in ../Sources-testing-contrib.gz...
Autobuilder: Searching for libpng12-0 in ../Sources-stable-main.gz...
Autobuilder: Searching for libpng12-0 in ../Sources-stable-contrib.gz...
AutoBuilder: Package not found
Package libpng12-0: ***Failure***
Build for package "libpng12-0" failed
Looking at the four .gz files, the only references I can find are for libpng-dev.
Note that SVN for gccsdk itself appears up to date, and I've deleted the existing Sources-*.gz files to force an update.
Unfortunately, I'm not that familiar with the autobuild system, so I've no idea if libpng-dev can be easily swapped in. It's entirely possible I've done something weird :)
Sunday, 1 October 2017
Re: LibCSS: Flexbox property support review
In article <03eccc20-da08-a0f8-54e8-47abe82415be@codethink.co.uk>,
Michael Drake <michael.drake@codethink.co.uk> wrote:
> On 30/09/17 21:05, Tim Hill wrote:
> > In article <0a012258-3662-78c0-93ca-5dac0982be36@codethink.co.uk>,
> > Michael Drake <tlsa@netsurf-browser.org> wrote:
> > This is great news even though I suspect you didn't mean to post it
> > to 'users' :).
> Yes, I meant to send it to the dev list, sorry.
> This work adds handling of flexbox properties to LibCSS, but there has
> currently been no work to implement the Flexbox layout algorithms in
> NetSurf.
> We only change version numbers when we do a release.
> Cheers,
Thanks for the clarifications.
--
Tim Hill
timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk
Michael Drake <michael.drake@codethink.co.uk> wrote:
> On 30/09/17 21:05, Tim Hill wrote:
> > In article <0a012258-3662-78c0-93ca-5dac0982be36@codethink.co.uk>,
> > Michael Drake <tlsa@netsurf-browser.org> wrote:
> > This is great news even though I suspect you didn't mean to post it
> > to 'users' :).
> Yes, I meant to send it to the dev list, sorry.
> This work adds handling of flexbox properties to LibCSS, but there has
> currently been no work to implement the Flexbox layout algorithms in
> NetSurf.
> We only change version numbers when we do a release.
> Cheers,
Thanks for the clarifications.
--
Tim Hill
timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk
Re: LibCSS: Flexbox property support review
On 30/09/17 21:05, Tim Hill wrote:
> In article <0a012258-3662-78c0-93ca-5dac0982be36@codethink.co.uk>,
> Michael Drake <tlsa@netsurf-browser.org> wrote:
> This is great news even though I suspect you didn't mean to post it to
> 'users' :).
Yes, I meant to send it to the dev list, sorry.
This work adds handling of flexbox properties to LibCSS, but there
has currently been no work to implement the Flexbox layout algorithms
in NetSurf.
We only change version numbers when we do a release.
Cheers,
--
Michael Drake http://www.codethink.co.uk/
> In article <0a012258-3662-78c0-93ca-5dac0982be36@codethink.co.uk>,
> Michael Drake <tlsa@netsurf-browser.org> wrote:
> This is great news even though I suspect you didn't mean to post it to
> 'users' :).
Yes, I meant to send it to the dev list, sorry.
This work adds handling of flexbox properties to LibCSS, but there
has currently been no work to implement the Flexbox layout algorithms
in NetSurf.
We only change version numbers when we do a release.
Cheers,
--
Michael Drake http://www.codethink.co.uk/
Subscribe to:
Posts (Atom)