Terrific. Thank you very much. The Wiki page has been updated to reflect this image.Hexxeh wrote:Threw together a new SD card image for Raspbian at mpthompson's request over the weekend, it's available here: distribution.hexxeh.net/raspbian/raspbian-r3.zip
Excellent news! Thanks for expediting this.mpthompson wrote:There have been requests for web browsers on Raspbian to fill out the GUI experience. I've looked into it and at a minimum we won't have one for at least another 4 days or so. The reason is that Midori and Chromium both rely on webkit which according to the Debian armhf build logs is an 81 hour build on similar type of hardware we are using to build Raspbian. Gulp!!! 81 hours!!! That's a 3+ day build...
Even worse, it looks like they both rely on different versions of webkit. Firefox/IceWeasel even a separate huge build. No matter what, these are going to be very painful builds to get through and we'll have to exercise patience. I don't have knowledge of how to cross-compile such complex Debian packages so there isn't much of option to use more powerful Intel hardware for these builds (which isn't the Debian way anyway).
To get through this as quickly as possible, I've stopped autobuilding on one server and devoted it to building webkit for the next 3+ days. I had to use a handful of Debian armhf packages to satisfy build dependencies so there is a risk that at the end of these builds we can't use the packages as they may have ARMv7 contamination and won't run on the Raspberry Pi. However, this risk is generally pretty low so it's probably worth taking to these critical pieces of a GUI experience built.
Since the build system I do manual builds on will be devoted to webkit for the next few days this will give me time to turn my attention to fixing up the Raspbian.org website and some infrastructure issues I've been meaning to get to for the last week or so. Plugwash has been busy with his own set of manual builds on another build server so we'll have three to four other autobuilders pounding on the scheduled set of packages. Binary packages will be coming out slower for a little while, but they progress will continue to be made.
PS. If you want to go old school, you can use the lynx browser on Raspbian which is a text-mode browser. Doing so, at least you'll really appreciate Midori or Chromium when they do show up on Raspbian.
I just went to download the Hexxah image. The link in the Wiki isn't correct. It points to http://www.raspbian.org/distribution.hexxeh.net/... (instead of just distribution.hexxeh.net/...). I created an account on the Wiki to fix it, but the pages are locked.mpthompson wrote:Terrific. Thank you very much. The Wiki page has been updated to reflect this image.
http://www.raspbian.org/HexxehImages
Thank you for pointing out the error. It should now be fixed. I went ahead an enabled your account to be able to edit content on the Wiki. Let me know if you have any problems.chrisost wrote:I just went to download the Hexxah image. The link in the Wiki isn't correct. It points to http://www.raspbian.org/distribution.hexxeh.net/... (instead of just distribution.hexxeh.net/...). I created an account on the Wiki to fix it, but the pages are locked.
I look forward to trying it out. I'm downloading now.
Next time might want to see if you can get it to build with the gold linker. It is supposed to use less memory and be a lot faster for big c++ things. Hexxeh might know if that works or not.mpthompson wrote: With webkit, I'm now about 35 hours into what looks to be at least an 81 hour build. I was examining the build system earlier today and even though it has 1GB of RAM, a very large link of a shared library consumed just over 2GB of swap. Having that much memory in swap is painful.
Thanks for the information. I added it to the wiki page so others will see it when downloading.veryevil wrote:Thats it so far. Thanks for the huge effort Cannot wait for a decent web browser on this!
I'm fairly certain we'll be going after the 'non-free' packages as well. It just won't happen in a serious way until we are finished with the 'main' packages. I haven't looked into what's required to support the non-free packages in the reprepro based repository we are using. Probably not much, but I'll look into it so perhaps we can put at least a few of the firmware packages in there to help Raspberry Pi users such as yourself.Toad King wrote:Also, I know you're mainly focusing on the main section of Debian packages, but the non-free firmware packages might be worth including, at least for people like me who have Wifi dongles that need them:
Got this answered in the IRC channel:SquallStrife wrote:Using the v3 image, I'm getting a lot of "mmc0: Controller never released inhibit bit(s)." messages.
But there don't seem to be any other symptoms. What's causing that?
Thanks Hexxeh. We now have two mirrors in Europe and one in North America.Hexxeh wrote:Both Raspbian mirrors are ready:
So for example if someone wanted to contribute XBMC (hint hint) how would they go about this?mpthompson wrote: How can you help Raspbian?
Code: Select all
Program received signal SIGSEGV, Segmentation fault.
0x4a947828 in ?? ()
(gdb) bt
#0 0x4a947828 in ?? ()
#1 0x41cf76e4 in JSC::JSValue::get(JSC::ExecState*, JSC::Identifier const&, JSC::PropertySlot&) const () from /usr/lib/libjavascriptcoregtk-1.0.so.0
#2 0x41d2e294 in JITStubThunked_op_get_by_id_self_fail ()
from /usr/lib/libjavascriptcoregtk-1.0.so.0
#3 0x41d2b834 in cti_op_get_by_id_self_fail ()
from /usr/lib/libjavascriptcoregtk-1.0.so.0
#4 0x41d2b834 in cti_op_get_by_id_self_fail ()
from /usr/lib/libjavascriptcoregtk-1.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Before we start packaging such programs there is a need to decide what we are gonig to do with regards packaging the broadcom libaries. Do we just leave them in /opt? if so how do we make binaries use them instead of the mesa versions. Do we use rpaths (which would mean making special broadcom specific versions of all software we want GPU accelleration for)? Do we symlink them from the usual library dirs? and how do we do that in a way that doesn't screw with the existing debian packages.So for example if someone wanted to contribute XBMC (hint hint) how would they go about this?
Hmmm, I knew things were going too smoothly. From the stack trace it looks like the problem is in the Javascript webkit shared library. The webkit of course being at least a two day build. The best I can do at this point is to try to reproduce the problem under QEMU and see if I can find where things are going off track.veryevil wrote:Hi, installed midori but its not at all stable. it Segfaults a lot.
Hope we can work towards a fix
Steven
