Re: AGM minutes
by Chris Young
On Sat, 4 Jan 2014 19:23:23 +0000, John-Mark Bell wrote:
> > > AI: Chris to sort out Spidermonkey for the Amiga cross-toolchain
> >
> > I've lost the previous discussion, but having just built a new 64-bit
> > Debian VM I'm still getting the exact same errors building the
> > toolchains:
> >
>
> [...]
>
> Should be fixed on master.
Working, thanks.
Chris
9 years, 5 months
Re: netsurf: branch master updated. release/3.0-900-g581d877
by Chris Young
Hi Daniel
On Sat, 04 Jan 2014 19:34:18 +0000, Commit Mailer wibbled on for an age:
> - Log -----------------------------------------------------------------
> commitdiff http://git.netsurf-browser.org/netsurf.git/commit/?id=581d87757601286fbb8...
> commit 581d87757601286fbb8250abc8d2bd185dddecb7
> Author: Daniel Silverstone <dsilvers(a)digital-scurf.org>
> Commit: Daniel Silverstone <dsilvers(a)digital-scurf.org>
>
> In theory, store raw filenames and pass them through for file
> upload. Untested due to no file-upload in GTK frontend just yet
That fixed the error message, but now NetSurf is crashing on submit
(unless this is an unrelated problem).
Stack trace:
native kernel module newlib.library.kmod+0x00003838
native kernel module newlib.library.kmod+0x0002e3c4
curl_formadd()+0x810 (section 1 @ 0x1C137C)
[content/fetchers/curl.c:1302] fetch_curl_setup()+0x5c0 (section 1 @ 0x3F508)
[content/fetch.c:327] fetch_start()+0x1ac (section 1 @ 0x3B738)
[content/llcache.c:715] llcache_object_refetch()+0x134 (section 1 @ 0x4484C)
[content/llcache.c:1142] llcache_object_retrieve()+0xd4 (section 1 @ 0x44B78)
[content/llcache.c:2406] llcache_handle_retrieve()+0xc0 (section 1 @ 0x4643C)
[content/hlcache.c:271] hlcache_handle_retrieve()+0xec (section 1 @ 0x43224)
[desktop/browser.c:1841] browser_window_navigate()+0x2fc (section 1 @ 0x5D080)
[render/form.c:1557] form_submit()+0x134 (section 1 @ 0x9035C)
[render/html_interaction.c:936] html_mouse_action()+0x8ec (section 1 @ 0x98494)
[content/content.c:478] content_mouse_action()+0x68 (section 1 @ 0x382E0)
[desktop/browser.c:2877] browser_window_mouse_click()+0x250 (section 1 @ 0x5EE70)
[amiga/gui.c:1723] ami_handle_msg()+0x5f4 (section 1 @ 0x1AFE4)
ami_get_msg()+0x1ec (section 1 @ 0x1C09C)
[desktop/netsurf.c:228] netsurf_main_loop()+0x38 (section 1 @ 0x68F08)
[amiga/gui.c:1052] main()+0x444 (section 1 @ 0x1CD24)
native kernel module newlib.library.kmod+0x000020ac
native kernel module newlib.library.kmod+0x00002d5c
native kernel module newlib.library.kmod+0x00002ef0
_start()+0x170 (section 1 @ 0x16C)
native kernel module dos.library.kmod+0x00024f18
native kernel module kernel+0x0003b4b0
native kernel module kernel+0x0003b530
CI build #1578
Chris
9 years, 5 months
Bugs, their care and stomping
by Vincent Sanders
The NetSurf team are pleased to announce the availability of a new bug tracker [1]
The new tracker uses mantis [2] software which is usable from NetSurf
This move has been necessitated because of several issues, principally:
- The SourceForge issue tracking system has been upgraded and is now
unusable from NetSurf
- The advertisements on the site have become aggressively invasive
- The reliability of the site has come into question.
We have imported the bugs from SourceForge although this has resulted
in a renumbering of identifiers (bug numbers).
We have been able to put a link back to the old sourceforge bug
numbers in the "Additional Information" of every imported bug.
Please do not use the SourceForge tracker for any new bugs or update
any old ones there as they will be ignored.
Accounts
--------
We have created users within the new system for everyone who has
reported a bug. For most imported users the email address used was
their sourceforge contact address [3]
The new system does not allow for anonymous issue reporting, if this
is a problem for you we thank you for your opinion but this decision
is not negotiable.
To login please use the lost password interface [4] to update your
details if you wish.
If a user needs the address associated with their account altering and
cannot access it through sourceforge please contact us [5] giving as
much information as possible (including the user id and some
reasonable argument that the account is yours - we will set the
address to where you send the mail from)
Accounts have been created manually for the many users who usefully
put their contact details within their reports, additionally their
email details have been removed from the publicly visible reports
which should reduce spam harvesting.
We assure all users we will never use the email addresses given to the
system other than to reply to their bug reports.
New and existing bugs
---------------------
Updates to bugs will (by default! this is configurable for each user
[6]) result in the reporter receiving an email. If you wish to update
a bug please use the web interface, replying to the emails means a
developer has to manually copy the reply to the bug. We may reconsider
changing the reply address to refuse mail if this becomes a burden.
New reports should contain as much information as the reporter can
provide we give some guidence [7] but ultimately the more information
you provide the more likely we can reproduce the issue and the more
likely it is to get resolved.
Debugging is hard [8] please do not have unreasonably high
expectations, we did *not* intend to have the bug that you found,
please do not take it personally.
I have currently triaged just over 10% of the open bugs and will make
my way through those that remain over the forthcoming weeks. Please
understand that there are very few active developers and many open
bugs so this work goes slow.
I have to be pretty harsh in my triage and will close incomplete bugs
(especially anonymous ones) without a detailed examination. These may
be reopened by the reporter but I request that as much information is
provided as you can.
What things mean
----------------
I know some reporters are already misunderstanding what the various
fields in a report are for, especially the severity and status
fields.
Severity refers to how severe the impact is on the project overall
i.e. if the bug causes a crash in normal operation (crash severity)
and is *not* a reflection on how important the bug is (we specifically
do not have a priority field for that). To be clear the *default* of
minor means, in this context, that the bug does not make the browser
unusable for *everyone*
Status is related to the bug work flow within the netsurf team. It
starts at new when the bug is reported, gets set to feedback when we
need more information from the user or a user reopens an unresolved
issue.
The acknowledged status means a developer has at least looked at
the report but not reproduced the issue whereas confirmed shows they
have reproduced it (not the reporter, we know they managed it!).
The assigned status means that one of the developers has decided they
are the best person to fix the issue and are actively examining the
problem. We are also using the assignment to the import user as a flag
that basic triage has not yet been performed on the bug.
Finally the resolved status implies that the resolution field should
be looked at to see how the issue was resolved and the closed status
implies the developer has finished with the report and no additional
activity will be made on the issue.
[1] http://http://bugs.netsurf-browser.org
[2] http://www.mantisbt.org/
[3] if the userid on sourceforge was kyllikki the email used was kyllikki(a)users.sourceforge.net
[4] http://bugs.netsurf-browser.org/mantis/lost_pwd_page.php
[5] help(a)netsurf-browser.org
[6] http://bugs.netsurf-browser.org/mantis/account_prefs_page.php
[7] http://bugs.netsurf-browser.org/
[8] Everyone knows that debugging is twice as hard as writing a program in the first place. - Brian Kernighan "The Elements of Programming Style", 2nd edition, chapter 2
--
Regards Vincent
9 years, 5 months
File uploads with non-ASCII filenames
by Chris Young
I was recently alerted to a problem with file uploading when the
filename contained non-ASCII characters. What appears to happen is
NetSurf converts the filename given by the frontend to UTF-8, and then
when the POST is done by Curl it tries to open the file using the
UTF-8 name.
When the OS uses a filesystem which stores filenames in UTF-8 this is
not a problem. However, when it stores them in a local character set
the conversion means Curl can't open the file and an error occurs
rather than the file being uploaded. This happens on OS4 and I
suspect some of our other targets too.
The branch chris/non-ascii-file-upload is my attempt at fixing this.
I've added a new item to the form structure to hold the original
filename given to NetSurf by the OS, and this is then passed to Curl
instead of the UTF-8 version (the UTF-8 version is still there for the
display).
I'm not sure if this is the best way of handling it, and my build
environment is screwed up so I can't actually test it at the moment,
so any comments welcomed.
Chris
9 years, 5 months
RISC OS Hotlist Fixes
by Steve Fryatt
I've updated the RISC OS front-end to properly support the new hotlist
tool in the URL bar (ie. handle mouse clicks, confirm before deleting
things and provide interactive help). Because I've added some items to
FatMessages and therefore can't push them, the changes are in a branch
here:
http://git.netsurf-browser.org/netsurf.git/log/?h=stevef/hotlist
It builds and tests OK for me, so should be OK to merge in to master.
The following tokens are new in FatMessages, and so could do with
translations if anyone can help.
all.RemoveHotlist
all.Remove
all.DontRemove
ro.HelpToolbarFav
ro.HelpToolbarHot
The three confirmation texts are currently set to 'all' to match all the
other similar entries in the file; they could be made 'ro' specific if
that's considered better, although in theory they would apply to other
front-ends implementing this functionality in the future.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
9 years, 5 months
RISC OS Hotlist Fixes
by Steve Fryatt
[Apologies if this appears twice: I've been having issues with email for the
past few days, and although they now seem to be fixed I can't see any sign
of the original having made it to the outside world.]
I've updated the RISC OS front-end to properly support the new hotlist
tool in the URL bar (ie. handle mouse clicks, confirm before deleting
things and provide interactive help). Because I've added some items to
FatMessages and therefore can't push them, the changes are in a branch
here:
http://git.netsurf-browser.org/netsurf.git/log/?h=stevef/hotlist
It builds and tests OK for me, so should be OK to merge in to master.
The following tokens are new in FatMessages, and so could do with
translations if anyone can help.
.all.RemoveHotlist
.all.Remove
.all.DontRemove
.ro.HelpToolbarFav
.ro.HelpToolbarHot
The three confirmation texts are currently set to 'all' to match all the
other similar entries in the file; they could be made 'ro' specific if
that's considered better, although in theory they would apply to other
front-ends implementing this functionality in the future.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
9 years, 5 months
