headers
tracker | 2 Jan 2010 00:00
Favicon

Open patches in Rockbox

Flyspray contains 455 open patches:

0 days old: Hebrew glyphs for 08-Rockfont.bdf
0 comments, 2 files: http://www.rockbox.org/tracker/10886

5 days old: RTL aware WPS
12 comments, 8 files: http://www.rockbox.org/tracker/10882

9 days old: Improve the usability of the virtual keyboard
2 comments, 1 files: http://www.rockbox.org/tracker/10872

13 days old: Always display backdrop in the plugin's menu
9 comments, 2 files: http://www.rockbox.org/tracker/10868

15 days old: Mandelbrot: Yield buttons during painting of the fractal
1 comments, 2 files: http://www.rockbox.org/tracker/10865

15 days old: Wormlet: Remove obsolete text
0 comments, 1 files: http://www.rockbox.org/tracker/10864

15 days old: Add second backlight timeout
5 comments, 1 files: http://www.rockbox.org/tracker/10862

17 days old: Skip to previous track inconsistent when using cuesheet
3 comments, 2 files: http://www.rockbox.org/tracker/10856

18 days old: SVG Image for Onda VX777
2 comments, 2 files: http://www.rockbox.org/tracker/10854

18 days old: radio screen skin support
(Continue reading)

Permalink | Reply | 0 comments |
headers
tracker | 2 Jan 2010 00:00
Favicon

Open bugs in Rockbox

Flyspray contains 238 open bugs:

1 days old: bmark files contains only zeros
1 comments, 1 files: http://www.rockbox.org/tracker/10884

3 days old: clickwheel stops working when its used during the bookmark setting process
3 comments, 1 files: http://www.rockbox.org/tracker/10883

6 days old: Website has dead links after target rename
0 comments, 0 files: http://www.rockbox.org/tracker/10878

6 days old: Low battery makes it forget everything.
0 comments, 0 files: http://www.rockbox.org/tracker/10876

7 days old: Build Server mixes up builds
0 comments, 0 files: http://www.rockbox.org/tracker/10875

8 days old: no track will play after playing a deleted, semi-buffered track
1 comments, 0 files: http://www.rockbox.org/tracker/10874

9 days old: Unable to mount as mass storage device under Ubuntu
6 comments, 0 files: http://www.rockbox.org/tracker/10873

13 days old: Directory listing slow
2 comments, 0 files: http://www.rockbox.org/tracker/10869

14 days old: Backlight won't turn on after going off
1 comments, 0 files: http://www.rockbox.org/tracker/10867

16 days old: Can't browse directories with an ipod nano 2G
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dominik Riebeling | 4 Jan 2010 20:19
Picon

Re: tomers: r24174 - in trunk/rbutil/rbutilqt: . base

On Sun, Jan 3, 2010 at 9:17 PM,  <mailer <at> svn.rockbox.org> wrote:
> Date: 2010-01-03 21:17:36 +0100 (Sun, 03 Jan 2010)
> New Revision: 24174
>
> Log Message:
> rbutil: Fix some messages

What on earth is this a "fix"? It doesn't fix anything. The strings
touched where completely correct, and the only thing changed is
punctuation and capitalization. Furthermore, from my point of view the
punctuation changed was absolutely correct, thus there wasn't even a
need to change it -- the change made it worse.

> -        emit logItem(tr("Download finished."), LOGOK);
> +        emit logItem(tr("Download finished"), LOGOK);

Why is the trailing dot removed here? This is a (rather short)
statement, so it should end with a punctuation character, i.e. a dot.

However, if such kind of messages should not end with a dot, then
please make it actually consistent. For example, there is
    emit logItem(tr("Download error: received HTTP error %1.")
which should, following the change, also not end with a dot. There are
also other log messages that (still) end with a dot. However, this
wasn't changed by this commit. Nevertheless, if we want log messages
to not end with a dot we need to agree upon it. Which hasn't happened
up to now.

> -        emit logItem(tr("done."), LOGOK);
> +        emit logItem(tr("Done"), LOGOK);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Martitz | 4 Jan 2010 21:07
Picon

Re: I suggest we postpone release 14 days

We're on the best way to be a month late. I'd say if we exceed this 
month we should just skip 3.5 (name the next release 3.5), since 3.6 
wants to be released too and I guess we want to meet the "deadline" for 
that one, otherwise there would only be 2 month between 3.5 and 3.6.

Although if we keep the current cycle we're gonna have the same problems 
at this year's christmas. Maybe delaying the schedule by a month or so 
for all subsequent releases or changing the number if releases per year 
would be a good idea. (/me'd still prefers 3 per year).

Am 09.12.2009 19:53, schrieb Daniel Stenberg:
> 2 - because several pretty largish changes have recently been 
> committed that I think will appreciate getting slightly longer time to 
> settle before we can consider them release-worthy.
>

It seems quite a few people are not away (or have forgotten) which 
changes you're refering too. One of them is probably the viewportmanager 
api change, but I'm not sure if any of the remaining bugs is a real 
release blocker.

If we decide on starting the release cycle soon, I'd like to propose 
that (since we have no real testing system yet) we have 2 RC builds, 1 
for the freeze phase and one for the branch phase. Getting testers in 
the official test builds forum is probably the best we can get at this 
point.

Best regards.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rafaël Carré | 5 Jan 2010 00:09
Picon

Re: I suggest we postpone release 14 days

On Mon, 04 Jan 2010 21:07:10 +0100
Thomas Martitz <thomas.martitz <at> student.HTW-Berlin.de> wrote:

> Although if we keep the current cycle we're gonna have the same
> problems at this year's christmas. Maybe delaying the schedule by a
> month or so for all subsequent releases or changing the number if
> releases per year would be a good idea. (/me'd still prefers 3 per
> year).

We could shift release to the end of the month to avoid that and start
freeze in 10 days.

The question of release cycle could still be discussed until end of
april.

Looking at http://www.rockbox.org/wiki/MajorChanges I think we can go
for 3 releases a year and spend less time on releasing process and more
time on rockboxing.

--

-- 
Rafaël Carré
Permalink | Reply | 0 comments |
headers
Torne Wuff | 6 Jan 2010 01:20
Picon

Help getting frotz plugin to work on lowmem targets

I've just about completed my port of the frotz Z-Machine interpreter to
Rockbox (FS#10370) but currently it does not build for the lower memory
targets as it is too big. (70KB or so on ipodvideo). It could be made
into an overlay like goban/chessbox/etc however I don't really
understand the makefile magic that makes this work and I don't have any
of these targets to test on. Would anyone be willing to lend a hand with
this.. make the appropriate changes and test them on a lowmem target? It
should be able to run on anything with a bitmap LCD once this is done.

Thanks in advance,

--

-- 
Torne Wuff
torne <at> wolfpuppy.org.uk
Permalink | Reply | 3 comments |
headers
Nils | 6 Jan 2010 08:16
Picon

Re: Help getting frotz plugin to work on lowmem targets

Have you tried building with -Os?
Permalink | Reply | 1 comment |
headers
Maurus Cuelenaere | 6 Jan 2010 11:36
Picon

Re: Help getting frotz plugin to work on lowmem targets

Op 06-01-10 01:20, Torne Wuff schreef:
> I've just about completed my port of the frotz Z-Machine interpreter to
> Rockbox (FS#10370) but currently it does not build for the lower memory
> targets as it is too big. (70KB or so on ipodvideo). It could be made
> into an overlay like goban/chessbox/etc however I don't really
> understand the makefile magic that makes this work and I don't have any
> of these targets to test on. Would anyone be willing to lend a hand with
> this.. make the appropriate changes and test them on a lowmem target? It
> should be able to run on anything with a bitmap LCD once this is done.
>
> Thanks in advance

Whenever you get this working, could you document/describe what you've done?

I'm interested in this as it needs to be done for the Lua plugin too.

Thanks,
Maurus Cuelenaere
Permalink | Reply | 0 comments |
headers
Torne Wuff | 6 Jan 2010 14:40
Picon

Re: Help getting frotz plugin to work on lowmem targets

On Wed, Jan 06, 2010 at 08:16:56AM +0100, Nils wrote:
> Have you tried building with -Os?

Alas -Os saves only 2.5KB on ARM and probably comparable on other
platforms. The Frotz implementation is just *really big*. It's quite a
complex virtual machine. :)

--

-- 
Torne Wuff
torne <at> wolfpuppy.org.uk
Permalink | Reply | 0 comments |
headers
tracker | 9 Jan 2010 00:00
Favicon

Open bugs in Rockbox

Flyspray contains 238 open bugs:

0 days old: Can't load Rockbox on Cowon D2 from SD
0 comments, 0 files: http://www.rockbox.org/tracker/10900

2 days old: Changed default codepage is applied only afterl reboot
2 comments, 0 files: http://www.rockbox.org/tracker/10896

3 days old: iPod Nano 2G USB Issues
2 comments, 0 files: http://www.rockbox.org/tracker/10894

4 days old: Pictureflow plugin has drawing issue on left side with scrolling text
0 comments, 0 files: http://www.rockbox.org/tracker/10893

13 days old: Website has dead links after target rename
0 comments, 0 files: http://www.rockbox.org/tracker/10878

13 days old: Low battery makes it forget everything.
1 comments, 0 files: http://www.rockbox.org/tracker/10876

14 days old: Build Server mixes up builds
1 comments, 0 files: http://www.rockbox.org/tracker/10875

15 days old: no track will play after playing a deleted, semi-buffered track
1 comments, 0 files: http://www.rockbox.org/tracker/10874

16 days old: Unable to mount as mass storage device under Ubuntu
12 comments, 4 files: http://www.rockbox.org/tracker/10873

20 days old: Directory listing slow
(Continue reading)

Permalink | Reply | 0 comments |

Gmane