chromium comes to town

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

chromium comes to town

f.holop
hi there,

is anybody looking at this?
http://dev.chromium.org/developers/how-tos/build-instructions-linux

perhaps it's not too linux oriented
if they chose the bsd license :]

-f
--
if practice makes perfect, and nobody's perfect, why practice?

Reply | Threaded
Open this post in threaded view
|

Re: chromium comes to town

Marco Peereboom
It might be interested when they are not a windows only thing...

On Wed, Sep 03, 2008 at 01:11:28AM +0200, frantisek holop wrote:

> hi there,
>
> is anybody looking at this?
> http://dev.chromium.org/developers/how-tos/build-instructions-linux
>
> perhaps it's not too linux oriented
> if they chose the bsd license :]
>
> -f
> --
> if practice makes perfect, and nobody's perfect, why practice?
>

Reply | Threaded
Open this post in threaded view
|

Re: chromium comes to town

Peter Hessler
they only released pre-built binaries for windows.  the link below shows
how to fetch and build from source.


On 2008 Sep 02 (Tue) at 18:32:16 -0500 (-0500), Marco Peereboom wrote:
:It might be interested when they are not a windows only thing...
:
:On Wed, Sep 03, 2008 at 01:11:28AM +0200, frantisek holop wrote:
:> hi there,
:>
:> is anybody looking at this?
:> http://dev.chromium.org/developers/how-tos/build-instructions-linux
:>
:> perhaps it's not too linux oriented
:> if they chose the bsd license :]
:>
:> -f
:> --
:> if practice makes perfect, and nobody's perfect, why practice?
:>
:

--
Bore, n.:
        A guy who wraps up a two-minute idea in a two-hour vocabulary.
                -- Walter Winchell

Reply | Threaded
Open this post in threaded view
|

Re: chromium comes to town

Christian Weisgerber
In reply to this post by f.holop
frantisek holop <[hidden email]> wrote:

> is anybody looking at this?
> http://dev.chromium.org/developers/how-tos/build-instructions-linux

I at least would wait for the Google guys to finish a port to some
Unix/X11 platform (Linux/i386, in other words).

If you have read the comic, you might remember that their JavaScript
engine compiles to native machine code.  Guess how many of our CPU
architectures will be supported?

"V8 [...] runs on Windows XP and Vista, Mac OS X 10.5 (Leopard),
 and Linux systems that use IA-32 or ARM processors."

Chromium is going to be more difficult to port than Mozilla.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: chromium comes to town

Brandon Mercer-3
Yes, but most of us on going to be using the web on those archs.  I think
this is a step in the right direction.  And now that they've fixed their
license it's time to take a closer look.  Brandon

On Wed, Sep 3, 2008 at 8:09 PM, Christian Weisgerber <[hidden email]>wrote:

> frantisek holop <[hidden email]> wrote:
>
> > is anybody looking at this?
> > http://dev.chromium.org/developers/how-tos/build-instructions-linux
>
> I at least would wait for the Google guys to finish a port to some
> Unix/X11 platform (Linux/i386, in other words).
>
> If you have read the comic, you might remember that their JavaScript
> engine compiles to native machine code.  Guess how many of our CPU
> architectures will be supported?
>
> "V8 [...] runs on Windows XP and Vista, Mac OS X 10.5 (Leopard),
>  and Linux systems that use IA-32 or ARM processors."
>
> Chromium is going to be more difficult to port than Mozilla.
>
> --
> Christian "naddy" Weisgerber                          [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: chromium comes to town

Masao Uebayashi-2
In reply to this post by Christian Weisgerber
> If you have read the comic, you might remember that their JavaScript
> engine compiles to native machine code.  Guess how many of our CPU
> architectures will be supported?

I think the CPU specific part is independent of OS.  So, once it's
ported to the CPU you want (by someone(tm)), it's OK. :)

Masao

Reply | Threaded
Open this post in threaded view
|

Re: chromium comes to town

patrick keshishian
In reply to this post by Christian Weisgerber
On Wed, Sep 3, 2008 at 5:09 PM, Christian Weisgerber <[hidden email]> wrote:

> frantisek holop <[hidden email]> wrote:
>
>> is anybody looking at this?
>> http://dev.chromium.org/developers/how-tos/build-instructions-linux
>
> I at least would wait for the Google guys to finish a port to some
> Unix/X11 platform (Linux/i386, in other words).
>
> If you have read the comic, you might remember that their JavaScript
> engine compiles to native machine code.  Guess how many of our CPU
> architectures will be supported?

http://www.google.com/googlebooks/chrome/

:-)


>
> "V8 [...] runs on Windows XP and Vista, Mac OS X 10.5 (Leopard),
>  and Linux systems that use IA-32 or ARM processors."
>
> Chromium is going to be more difficult to port than Mozilla.
>
> --
> Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: chromium comes to town

Brad Smith-14
On Wed, 3 Sep 2008 20:50:27 -0700
"patrick keshishian" <[hidden email]> wrote:

> On Wed, Sep 3, 2008 at 5:09 PM, Christian Weisgerber <[hidden email]> wrote:
> > If you have read the comic, you might remember that their JavaScript
> > engine compiles to native machine code.  Guess how many of our CPU
> > architectures will be supported?
>
> http://www.google.com/googlebooks/chrome/
>
> :-)

And your point is?

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Reply | Threaded
Open this post in threaded view
|

Re: chromium comes to town

patrick keshishian
On Wed, Sep 3, 2008 at 8:59 PM, Brad <[hidden email]> wrote:

> On Wed, 3 Sep 2008 20:50:27 -0700
> "patrick keshishian" <[hidden email]> wrote:
>
>> On Wed, Sep 3, 2008 at 5:09 PM, Christian Weisgerber <[hidden email]> wrote:
>> > If you have read the comic, you might remember that their JavaScript
>> > engine compiles to native machine code.  Guess how many of our CPU
>> > architectures will be supported?
>>
>> http://www.google.com/googlebooks/chrome/
>>
>> :-)
>
> And your point is?

Simply providing a link to the "comic" Christian Weisgerber
was referring to.

--patrick

Reply | Threaded
Open this post in threaded view
|

[NEW] rbutil - Rockbox Utility

Brian-79
This is my first port, and it's a work in progress.  For more information about Rockbox:

http://www.rockbox.org/

This port builds the Rockbox Utility, which will install on your mp3 player an open source firmware.  I have only tested this app on my iPod nano 1st gen on an amd64.  I cannot guarantee it will work with anything else.  Please test.  

For a list of mp3 players this app will work with, please refer to the site above.

This first stab at the port has some current issues:

1) I need help understanding the license, so I can properly set the license
   flags

2) the port is made off a moving tree, so I need to know what to do to
   create a stable distfile; I wasn't sure how big of a file I could
   e-mail to this list.

3) please check my Makefile for errors or better ways of doing things;
   this is my first attempt at this

4) not sure what version to put on this thing

Things that are broken in the app:

1) no progress bar shows up for uninstall even though the firmware
   uninstalled correctly

2) theme site comes up and down; hoping the app maintainers will fix this

3) app's Makefile will break on a gmake install, so their docs suggest
   a gmake install_target, which works; I just coded up a do-install with
   an install to /usr/local/bin because I wasn't sure how to have make
   fake and make install change install to install_target.  

I'm not asking at this time for port submission or approvals.  I know more work is needed on this port, but I'm reaching the point, where I just need others to look at it.

Tell me what you think.

Thanks,

Brian







     

rbutil.tar.gz (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: chromium comes to town

Brandon Mercer-3
In reply to this post by patrick keshishian
On Thu, Sep 4, 2008 at 12:21 AM, patrick keshishian <[hidden email]>wrote:

> On Wed, Sep 3, 2008 at 8:59 PM, Brad <[hidden email]> wrote:
> > On Wed, 3 Sep 2008 20:50:27 -0700
> > "patrick keshishian" <[hidden email]> wrote:
> >
> >> On Wed, Sep 3, 2008 at 5:09 PM, Christian Weisgerber <
> [hidden email]> wrote:
> >> > If you have read the comic, you might remember that their JavaScript
> >> > engine compiles to native machine code.  Guess how many of our CPU
> >> > architectures will be supported?
> >>
> >> http://www.google.com/googlebooks/chrome/
> >>
> >> :-)
> >
> > And your point is?
>
> Simply providing a link to the "comic" Christian Weisgerber
> was referring to.


I guess I failed to see some of the nasty dependencies that are required for
this browser.  While the project itself is licensed BSD, all the stuff it
depends on isn't.  It also seems they've done some crazy things like keeping
all the sources for all the deps in their source tree... could make for
quite the mess.... But the comic looks cool!
==fanboi out==
Reply | Threaded
Open this post in threaded view
|

Re: chromium comes to town

Stuart Henderson
In reply to this post by Masao Uebayashi-2
On 2008/09/04 09:25, Masao Uebayashi wrote:
> > If you have read the comic, you might remember that their JavaScript
> > engine compiles to native machine code.  Guess how many of our CPU
> > architectures will be supported?
>
> I think the CPU specific part is independent of OS.  So, once it's
> ported to the CPU you want (by someone(tm)), it's OK. :)

that's probably ok for i386 and arm then. maybe amd64. but what's
the chance of seeing hppa, sparc (!64-bit), superh, even powerpc...

Reply | Threaded
Open this post in threaded view
|

Re: chromium comes to town

Brad Smith-14
On Thu, 4 Sep 2008 16:55:39 +0100
Stuart Henderson <[hidden email]> wrote:

> On 2008/09/04 09:25, Masao Uebayashi wrote:
> > > If you have read the comic, you might remember that their JavaScript
> > > engine compiles to native machine code.  Guess how many of our CPU
> > > architectures will be supported?
> >
> > I think the CPU specific part is independent of OS.  So, once it's
> > ported to the CPU you want (by someone(tm)), it's OK. :)
>
> that's probably ok for i386 and arm then. maybe amd64. but what's
> the chance of seeing hppa, sparc (!64-bit), superh, even powerpc...

Their codebase does not even work on 64-bit systems yet! IMO this is
beyond ridiculous.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Reply | Threaded
Open this post in threaded view
|

Need Some More Help

Brian-79
I made a mistake in the package I put out here this morning.  While the port will do a make fake, it will not resolve a package install.  And I'm not sure what I am doing wrong.

Here's the output:

# make port-lib-depends-check

rbutil:
Asking ports for dependency tiff-3.8.2p1(graphics/tiff)
Asking ports for dependency jpeg-6bp3(graphics/jpeg)
Asking ports for dependency glib2-2.16.4p1(devel/glib2)
Asking ports for dependency dbus-1.0.2p5(x11/dbus)
Asking ports for dependency lcms-1.17p0(graphics/lcms)
Asking ports for dependency qt4-4.3.5(x11/qt4)
Asking ports for dependency libiconv-1.12(converters/libiconv)
Asking ports for dependency libusb-0.1.12(devel/libusb)
Asking ports for dependency libmng-1.0.10(graphics/libmng)
Asking ports for dependency gettext-0.17(devel/gettext)
Asking ports for dependency png-1.2.28(graphics/png)
Asking ports for dependency pcre-7.7p0(devel/pcre)
# make lib-depends-check

/usr/ports/packages/amd64/all/rbutil.tgz:
Asking ports for dependency tiff-3.8.2p1(graphics/tiff)
Asking ports for dependency jpeg-6bp3(graphics/jpeg)
Asking ports for dependency glib2-2.16.4p1(devel/glib2)
Asking ports for dependency dbus-1.0.2p5(x11/dbus)
Asking ports for dependency lcms-1.17p0(graphics/lcms)
Asking ports for dependency qt4-4.3.5(x11/qt4)
Asking ports for dependency libiconv-1.12(converters/libiconv)
Asking ports for dependency libusb-0.1.12(devel/libusb)
Asking ports for dependency libmng-1.0.10(graphics/libmng)
Asking ports for dependency gettext-0.17(devel/gettext)
Asking ports for dependency png-1.2.28(graphics/png)
Asking ports for dependency pcre-7.7p0(devel/pcre)
# make install
===>  Installing rbutil from /usr/ports/packages/amd64/all/
Can't resolve rbutil.tgz
*** Error code 1

Stop in /usr/ports/audio/rbutil (line 1453 of /usr/ports/infrastructure/mk/bsd.port.mk).

I have added all the WANTLIB and LIB_DEPENDS that came up, so I'm not sure how to debug this problem.  

#Dependencies
WANTLIB += ICE SM X11 Xcursor Xext Xfixes Xi Xinerama Xrandr Xrender
WANTLIB += c crypto fontconfig freetype glib-2.0 gthread-2.0 iconv
WANTLIB += intl m png pthread ssl stdc++ z

 
LIB_DEPENDS =            QtGui.>=8,QtNetwork.>=7::x11/qt4 \
                         ::devel/libusb \
                         ::graphics/png \
                         ::x11/dbus \
                         ::graphics/libmng \
                         ::graphics/lcms \
                         ::graphics/jpeg \
                         ::graphics/tiff \
                         ::devel/glib2 \
                         ::devel/pcre \
                         ::devel/gettext \
                         ::converters/libiconv \



Where do I look to debug this?  The checklist mentioned logs.  What logs do I look at?

Thanks,

Brian                                        


     

Reply | Threaded
Open this post in threaded view
|

Re: Need Some More Help

Steven Mestdagh-3
Brian [2008-09-04, 20:39:17]:
> I made a mistake in the package I put out here this morning.  While the port will do a make fake, it will not resolve a package install.  And I'm not sure what I am doing wrong.
>
> Here's the output:
>
> # make install
> ===>  Installing rbutil from /usr/ports/packages/amd64/all/
> Can't resolve rbutil.tgz
> *** Error code 1

Looks like your PKGNAME does not comply with packages-specs(7), i.e. it does
not have a version.

Reply | Threaded
Open this post in threaded view
|

Re: Need Some More Help

Brian-79



--- On Thu, 9/4/08, Steven Mestdagh <[hidden email]> wrote:

> From: Steven Mestdagh <[hidden email]>
> Subject: Re: Need Some More Help
> To: [hidden email]
> Date: Thursday, September 4, 2008, 10:33 PM
> Brian [2008-09-04, 20:39:17]:
> > I made a mistake in the package I put out here this
> morning.  While the port will do a make fake, it will not
> resolve a package install.  And I'm not sure what I am
> doing wrong.
> >
> > Here's the output:
> >
> > # make install
> > ===>  Installing rbutil from
> /usr/ports/packages/amd64/all/
> > Can't resolve rbutil.tgz
> > *** Error code 1
>
> Looks like your PKGNAME does not comply with
> packages-specs(7), i.e. it does
> not have a version.

Thanks.  That worked.  I'll re-post the package with corrections since
now it will actually install packages.  This first time through was
tough, but the next time will be a lot easier.

Thanks again.

Brian


     

Reply | Threaded
Open this post in threaded view
|

[NEW]: rbutil - Rockbox Utility *fixed*

Brian-79
I fixed the package installation process and dependencies.  This port will now install properly.  Please test.

If you are installing on an iPod other than a nano, please send me a disklabel readout of the iPod.  

Again, check out: http://www.rockbox.org for a list of mp3 players this firmware will install on.  Additional install instructions can also be found at that site.

Thanks for all the help.

Brian

Note: this is my first port, so please look out for errors I might have made.




     

rbutil.tar.gz (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [NEW]: rbutil - Rockbox Utility *fixed*

Stuart Henderson
On 2008/09/04 23:23, Brian wrote:

> I fixed the package installation process and dependencies.  This port will now install properly.  Please test.
>
> If you are installing on an iPod other than a nano, please send me a disklabel readout of the iPod.  
>
> Again, check out: http://www.rockbox.org for a list of mp3 players this firmware will install on.  Additional install instructions can also be found at that site.
>
> Thanks for all the help.
>
> Brian
>
> Note: this is my first port, so please look out for errors I might have made.
well done :-)

I have quite a few comments but don't be disheartened,
this is not the simplest choice of software for a first port,
it looks like a good learning experience!

> COMMENT =               Rockbox Utility

this could be a bit more descriptive, maybe something like
"tool to install Rockbox firmware on portable music players"

> PKGNAME =               rbutil-${VERSION}
> VERSION =               1.0.6

no need to use a separate variable for VERSION if you only use
it in one place. though I'm wondering if it might be better to use
the SVN id as part of this, and it can be used to set WRKDIST
explicitly rather than wildcard as you have:

> WRKBUILD =              ${WRKDIR}/rockbox-*/rbutil/rbutilqt
> WRKDIST =               ${WRKDIR}/rockbox-*/rbutil

> # Would be better to have a snapshot dist file, so that the source isn't a moving target

not just better, essential.

> NO_CHECKSUM =           YES

we can't put something in the tree which basically downloads what
could be some totally random software and runs it on build machines
without checking what it is. NO_CHECKSUM is for special cases e.g.
where the source is not fetched from a MASTER_SITE, rather it's
included right in the tree. (very uncommon).

> # Need to know what to do to make this happen.

fetch a copy and optionally repack (maybe without the whole
rockbox firmware source tree), then either host it yourself,
or ask here if someone can help with that.

> CHECK_LIB_DEPENDS = YES

oh, I didn't know you could do that, well spotted :) it's not
something that would be normally set in a port's own Makefile though,
rather something you could set in mk.conf, or on the make command
line. (probably more useful on bulk build machines to identify
problems; while you're working on a port, it's quicker to "make
port-lib-depends-check" now we have that option).

> WRKINST =               ${WRKDIR}/fake

this should just be left at the default

> # bad install target: install_target
> # work around until I learn a better way

>         cd ${WRKBUILD}  && cp rbutilqt ${DESTDIR}/usr/local/bin  

${INSTALL_PROGRAM}

>         mkdir -p ${DESTDIR}/usr/local/share/doc/rbutil/docs

${INSTALL_DATA_DIR}

>         cp -R  ${WRKDIR}/rockbox-*/docs/* ${DESTDIR}/usr/local/share/doc/rbutil/docs

${INSTALL_DATA}

..

there are also quite a few places with spaces rather than tabs,
you need to take care of this with Makefiles, there are places
where you _must_ use tabs, but even where it's not strictly
required it should be done anyway. (Also trailing spaces on
the do-configure line).

here's an update with some of the above taken into account,
and with patches regenerated (we use "make update-patches" for
this, which generates patches against .orig files in ${WRKSRC}).
I haven't touched MASTER_SITES yet. Also adjusted WRKSRC/WRKDIST,
tweaked the installed docs a little and and re-run "make plist"

No supported hardware so I can't test it actually works here,
though it starts up and looks alright :-)


rbutil.tgz (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: chromium comes to town

Marc Espie-2
In reply to this post by Brad Smith-14
On Thu, Sep 04, 2008 at 08:03:19PM -0400, Brad wrote:
> Their codebase does not even work on 64-bit systems yet! IMO this is
> beyond ridiculous.

On the other hand, they have a lot of manpower, so wait and see...
I predict that, in 3 months time, it will be much better.

Reply | Threaded
Open this post in threaded view
|

Re: [NEW]: rbutil - Rockbox Utility *fixed*

Marc Espie-2
In reply to this post by Stuart Henderson
On Fri, Sep 05, 2008 at 12:38:15PM +0100, Stuart Henderson wrote:
> > COMMENT =               Rockbox Utility
>
> this could be a bit more descriptive, maybe something like
> "tool to install Rockbox firmware on portable music players"
>
Too long
install rockbox firmware on ipod

(does it apply to other mp3 players ?)
> > WRKBUILD =              ${WRKDIR}/rockbox-*/rbutil/rbutilqt
> > WRKDIST =               ${WRKDIR}/rockbox-*/rbutil

NO WILDCARD in WRKBUILD and WRKDIST, this does *not* work, as soon as
you update the port, if anyone has got a wrkdir checked out, this will
*fail* in a momentous way.

Don't define WRKBUILD like that,
WRKBUILD = ${WRKDIST}/rbutilqt
is much better. Remember make variables are lazy, so the order does NOT matter.

> > NO_CHECKSUM =           YES
>
> we can't put something in the tree which basically downloads what
> could be some totally random software and runs it on build machines
> without checking what it is. NO_CHECKSUM is for special cases e.g.
> where the source is not fetched from a MASTER_SITE, rather it's
> included right in the tree. (very uncommon).

Indeed. Forbidden!

> > # Need to know what to do to make this happen.
>
> fetch a copy and optionally repack (maybe without the whole
> rockbox firmware source tree), then either host it yourself,
> or ask here if someone can help with that.
>
> > CHECK_LIB_DEPENDS = YES
>
> oh, I didn't know you could do that, well spotted :) it's not
> something that would be normally set in a port's own Makefile though,
> rather something you could set in mk.conf, or on the make command
> line. (probably more useful on bulk build machines to identify
> problems; while you're working on a port, it's quicker to "make
> port-lib-depends-check" now we have that option).

This is documented in bsd.port.mk as User settings, minus the typo.
*Anything* documented as user settings only belongs in mk.conf.

If there was a simple automated way to check it does come from a Makefile,
this would error out.

12