Re: [b2g] ZTE Open C: any word on installing?
Le 09/06/2014 04:23, Robey Pointer a écrit : I managed to unbrick my ZTE Open C today, thanks to updated instructions here (thanks!): https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/ZTE_OPEN_C The root problem was exactly what's described in the attached bug: There's a bug in the firmware that will crash if you send it an image file bigger than about 256MB, so you need to build a stripped-down system.img with just enough stuff to let the recovery installer validate the update.zip file from the sdcard, but small enough to be uploaded through fastboot. (If anyone wants the hacked-up system.img I used, email me privately.) However, the developer page claims you still need Windows to run the "upgrade tool" that would allow me to install FFOS 1.4. I don't have Windows and probably never will. Is there any hope for people like me? Is some kind of upgrade tool "coming soon"? How soon? Or will this OS always be Windows-only, and I should give up? I can be trusted with low-level command-line tools -- try me! (Without meaning to sound *too* bitter, I definitely would not have purchased a Firefox phone if I knew it required Windows. That, to me, is the *opposite* of "open". Linux users are not *all* bad!) Believe me, very few of Firefox OS developers use windows, so it pisses everyone off. No promise here, I think this will be resolved soon, like what they did for the Open. -- Julien ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] ZTE Open C: any word on installing?
I managed to unbrick my ZTE Open C today, thanks to updated instructions here (thanks!): https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/ZTE_OPEN_C The root problem was exactly what's described in the attached bug: There's a bug in the firmware that will crash if you send it an image file bigger than about 256MB, so you need to build a stripped-down system.img with just enough stuff to let the recovery installer validate the update.zip file from the sdcard, but small enough to be uploaded through fastboot. (If anyone wants the hacked-up system.img I used, email me privately.) However, the developer page claims you still need Windows to run the "upgrade tool" that would allow me to install FFOS 1.4. I don't have Windows and probably never will. Is there any hope for people like me? Is some kind of upgrade tool "coming soon"? How soon? Or will this OS always be Windows-only, and I should give up? I can be trusted with low-level command-line tools -- try me! (Without meaning to sound *too* bitter, I definitely would not have purchased a Firefox phone if I knew it required Windows. That, to me, is the *opposite* of "open". Linux users are not *all* bad!) ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] User report: 6 months of Firefox phone
On 08/06/2014 23.54, Johannes Bauer wrote: Hm yes the Alcatel is quite a tortoise speed-wise and unresponsive at times. I also blame the hardware for that. The hardware is not stellar but we could also do better in certain respects. Is the difference between the Alcatel One Touch Fire and the ZTE Open C really so huge? Because if it really is I might even buy the Open C. For 75 EUR it's affordable enough to play around. The Open C is quite a bit better than the Alcatel One Touch Fire in every possibly metric (*) but I'm not sure if it will offer a better developer experience at this stage (see the other thread about it). If I were you I'd wait that we get at least a proper configuration for it in our main repo. Gabriele *) If you're interested in details the Open C sports a Snapdragon 200 8210 SoC vs the Snapdragon S1 MSM7227A of the Alcatel One Touch Fire. This gets you two cores vs one, roughly 40% higher performance per core, a faster (50%+) and more featured GPU and twice the RAM (512MiB vs 256MiB). Internal storage is 4GB vs 512MB and it's probably going to be faster too. ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] v1.2 to v1.4 update -> black screen on Alcatel One Touch Fire (hamachi)
On 08/06/2014 23.34, Johannes Bauer wrote: When the phone is in blackscreen mode, it seems to have booted, but just isn't displaying anything. When I do "adb shell" I do get a command shell. When I start the phone with a running "adb logcat", here's what I get: http://pastebin.com/ZnqFZAY8 This is an issue I've run into a few times when upgrading the hamachi and I've never really figured out what causes it. Anyway reflashing the userdata partition almost invariably solves the issue for me but it involves wiping all your data. If losing data doesn't bother you then try rebooting your phone in fastboot mode and then flash the userdata partition with the userdata.img file that resulted from the build. Hope this helps, Gabriele ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] User report: 6 months of Firefox phone
On 05.06.2014 21:33, Chris Mills wrote: >> Thinking about it, maybe I'll write a wrapper script that does exactly >> what I propose. That will clone the different repos, have some >> rudimentary i18n support (will create these json files for instance) and >> will be able to extract and re-feed that proprietary.tar.gz tarball. >> Maybe I think I could play around with it some more and give it a shot. > > that does sounds really cool! So I've done that. Unfortunetely while testing the script it could build a firmware but one that bricked my phone :-/ Opened up another thread for that issue. In any case, I'm currently building stock-i18n versions only. When I add i18n support and can properly test it, I'll release it. One thing that I've implemented that I think build.sh should implement itself: Check for presence of adb, autoconf2.13 and ccache BEFORE starting to build anything. It's super frustrating when you start a build, go grab some coffee and return half an hour later to see the build script has failed because some dependency was missing. The script I wrote checks for presence of each of those and gives sane error messages (i.e. advises what the user should do and names Mint/Ubuntu package names). If I get my phone working again, I'll report back here. Cheers, Johannes ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] User report: 6 months of Firefox phone
Hey Natalia, On 04.06.2014 18:46, Natalia Martinez-Winter wrote: > After using 1.4 for a while (and was really satisfied with it, although > I could report some minor bugs...), I'm currently on 2.0 on my Alcatel > One Touch Fire and I wouldn't recommend it right now. There are still > many bugs which prevents from using it as a phone (you would probably > miss calls, be annoyed when typing SMS...). That said, I might try it > again but with the Open C which is much faster and fluid ! a > life-changer :-) Hm yes the Alcatel is quite a tortoise speed-wise and unresponsive at times. I also blame the hardware for that. Is the difference between the Alcatel One Touch Fire and the ZTE Open C really so huge? Because if it really is I might even buy the Open C. For 75 EUR it's affordable enough to play around. I'll see if I get 1.4 running on my phone (which unfortunately I just bricked trying to update...) and if I like it and you can confirm that the ZTE is worth its money, I think I'll upgrade. > I've also discovered that flashing with our own builds is difficult > because there are a lot of dependencies to hardware (my proximity sensor > doesn't work anymore (no drivers), so I have to use headsets to avoid > dropping /muting calls...). Are these issues that are present on the Open C? Do you use it with 1.4 right now? > I realize this project is super challenging and is still a "baby", the > teams are doing incredible things with scarce resources. Hopefully with > the Flame, more contributors will be able to help testing, debugging, > documenting :-) Yup, I do realize that pulling such a project up is a ton of work and it's really the idealism that keeps me going on it. Competition is good for all sides (and I trust the Mozilla Foundation more than any other smartphone provider as of now). This is, in my opinion, where the FxOS can really make a strong point: By showing that it's actually respecting the users privacy (in strong contrast to Google and Apple). Cheers, Johannes ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] User report: 6 months of Firefox phone
Hey Julien, yes you paraphrased my points nicely and the proposed solutions (i.e. having different "channels" to upgrade to) would be absolutely wonderful. About the browser crashes, I didn't know that the Alcatel was so poorly equipped with hardware. But that would certainly explain things. Thanks for the clarification on that. Cheers, Johannes On 06.06.2014 11:31, Julien Wajsberg wrote: > Hey Johannes, > > If I can summarize your thoughts, in my decreasing order of importance : > > 1. when I report bug, they basically get ignored > -> this is the #1 issue to have a sane community. > > The owners or peers of components should definitely triage their coming > bugs at least once a week. Maybe different people in the team every > week, pick your own process, but letting a user bug without an answer is > really bad. > And this must be done for every component; any component that has no > specific owner needs to have one. > > 2. I want to upgrade my phone, what should I do, which repository can I > take, what is safe ? > -> we need IMO 3 channels: "release", "beta", > "nightly-might-break-your-phone" > I think this is what we're preparing for Flame. Sadly it's more > difficult to do for other phones because binary drivers suck. I mean, > it's not even advisable to make you do this by building yourself... > > FWIW v2.0 is too much a moving target right now; some of our people are > dogfooding it but this is dangerous if you're not in the team. v1.4 is > definitely ok and quite pleasant though. > > 3. Browser is crashing > -> IMO what's really happening is that the webpage uses too much memory, > and the page "crashes" because of out of memory condition. The Alcatel > has only 256MB memory... Even on Peak (512MB) I have this issue > sometimes too. We did huge improvements lately (that you don't have on > 1.2) but still this issue happens sometimes. > > We desperately need something to distinguish a real crash from OOM > conditions; we need something that says "this page uses too much memory > and we had to close it". > We also desperately need to have a tracker blocker: preventing tracking > scripts/images from even loading would definitely save memory. > > Hope this answers some of your questions... I guess I have more > questions than you :) > > Le 03/06/2014 11:48, Johannes Bauer a écrit : >> Hey list, >> >> so I've been using Firefox OS on my Alcatel One Touch Fire since Nov >> 2013 as my only phone on a day-to-day basis. I'd like to share my >> feedback to give you an impression about what I like and dislike about >> it. I've been on branch 1.2 for pretty much the whole trip. >> >> Gernerally when I bought the phone I knew I was getting into a haphazard >> kind of development situation. I knew there was going to be fiddling >> involved and that's okay. The main reason I bought it was beacuse I was >> happy to see an alternative to Android on the market and was curious if >> it were possible to actually actively participate in the project. >> >> About the usage: One of the very very first things I noticed was that >> the phone had a irritating, annoyning and most of all completely useless >> vibration effect when pressing the home button. It's one of the first >> tickets I commented on and it was annoying enough for me to actually >> patch the relevant code (described solution in #885716). Six months >> later: I tried to pull a 1.4 branch only to realize this is still >> exactly the same code. A dev had the ticket assigned to himself only to >> disassign it a few days back saying this isn't going anywhere. >> >> I don't get it. You guys even have a "user experience" team. Those >> people should know how freakishly annoying vibration can be. Why can't >> you just comment out the two lines until it's implemented "properly"? >> Actually I don't think anyone would miss the vibration when pressing the >> home button at all. In any case, it's utterly frustrating to see that >> this is not something that is important enough to warrant attention. >> >> Other quirks: The phone has sometimes really weird behavior when >> dialing. Sometimes it dials the wrong number (i.e. I have three numers >> stored and I absolutely positively press the first one, but it dials up >> the third one). Data import and export is horrible (it was a real pain >> upgrading the phone because there was no option to delete all contacts). >> Also when the number that is dialed is busy it just goes back to the >> address book with no indication what went wrong whatsoever. This is >> pretty annoying (i.e. you have the phone on your ear for a few seconds >> and hear nothing, then you look at it again and it's stopped dialing as >> if you never dialed to begin with). Some random flickering/crashing >> issues too but not reproducible and seldomly enough to be considered >> okay. >> >> Ironically the worst thing about the phone is the browser. Wow, that >> browser sucks so much it's hard to put in words. It feels like Netscape >> Navigato
Re: [b2g] User report: 6 months of Firefox phone
On 03.06.2014 16:52, Kartikaya Gupta wrote:
> In general the proprietary files are stored in a backup-* folder inside
> the B2G source folder. (For the Alcatel it's probably called
> backup-hamachi or backup-buri). You should be able to back this folder
> up as you describe and then put it back into place into a new source
> tree at some later date. For devices that we are still in the process of
> adding support the contents of the folder may change as we add support
> for difference pieces of hardware, but for the Alcatel phone that
> shouldn't be a problem.
Cool, I did this as you described and included it in my buildscript.
Is the general recipe that the directory name is backup-${target}? I'd
like to write it so people can build on different targets and the
backup/restore functionality still works.
Cheers,
Johannes
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
[b2g] v1.2 to v1.4 update -> black screen on Alcatel One Touch Fire (hamachi)
Hey there, since the readers on this mailing list are so helpful and encouraged me to try out a more recent version of FxOS and I found the time to do so tonight, I did... but unfortunately with no success. The phone now shows a permanent black screen :-( Here's what I did: The phone ran a v1.2 I built about half a year back. Today I built a BRANCH=v1.4 completely without any localizations or further configurations with a completely freshly checked out B2G git repo (testing a wrapper build script that I wrote). Then I restarted my phone and booted into a "root" image. B2G started up fine in v1.2. Then I started flash.sh and initiated adb flashing. The copying of files went on its way, as the last steps it reset the time and rebooted the phone. Then all I got was a black screen. I left it for a couple of minutes, but nothing changed. Took out the battery and reinserted: It shows the Alcatel logo for a few seconds, then goes to blackscreen mode. No GUI ever shows up. So I then decided that maybe it was an upgrade problem with adb only updating certain files and did a fastboot flash. The problem however persists as described. When the phone is in blackscreen mode, it seems to have booted, but just isn't displaying anything. When I do "adb shell" I do get a command shell. When I start the phone with a running "adb logcat", here's what I get: http://pastebin.com/ZnqFZAY8 Any idea what's going on there? Cheers, Johannes ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Build instructions and tutorials out of date / manifest files broken
Hello again, On 6/7/14, 9:47 PM, LazerUnicorns Developers wrote: Hey guys, I wanted to give you an update, I managed to root the device and inspect / reverse engineer the stuff that is going on there. good news! I'm currently trying to port autosign for Linux, so that you can ship ROMs with your own update.zip on SD card, which eases up installation pretty much. Very cool. 2. I have never built anything but gaia, as I can't get through the config.sh call. If you read that shell script and trace it out, it's essentially making a trivial config file (.config) and then doing massively heavy 'repo sync' which is downloading all the git repositories for all the projects (gigabytes). This second will fail a few times before the hundred or so repositories all get downloaded correct; you can run 'repo sync' again anytime to try again or to update the projects later. Btw, the 'repo' tool splits the source code repositories (.git directories) which it puts, by default, in $b2g_work_dir/.repo/projects/, from the working copies (i.e. the files) which you see in your B2G working directory. The 'manifest file' is also in the .repo/ directory. (So yes, the repo developers decided to store GIGABYTES in hidden directories; some people don't really understand. However, you *can* make .repo a symlink to a REPO/ directory to clarify for yourself what is happening.) Gaia itself was built successfully and flashed after the rooting process. As the master variant depends on the new Gecko API, I guess I have to built everything from scratch (navigator.mozInputMethod.removeFocus() seems to be not existing in the OEM Gecko variant, so all select fields are broken :P). 3. I couldn't fix the xml file myself. How can I fix the repo url? The URL is set in $b2g_work_dir/.repo/manifest.xml (note the dot in .repo) which is a symlink to $b2g_work_dir/.repo/manifests/$mydevice.xml. So backup and hack away to your heart's content. You set a block at the top of the file with the URL. You then, in the individual block add two attributes: remote='$name_used_above' and revision=.. Take a look at hamachi.xml for an example. The problem is - as I never built anything yet - I have no idea where the repository has to be cloned to. repo takes care of that so you don't need to change anything. It uses git commands to put the git 'repository' in .repo/projects/ and the working copy (the files) in the $b2g_work_dir. Should it land in external/tinyxml2 or platform/external/tinyxml2? Again, leave in place what is there; you just add to xml attributes to the file. It's superconfusing, I have really no idea how to overwrite it correctly as the platform/external/tinyxml2 is listed nowhere as a remote inside the base-caf-jb.xml. If the remote= and revision= are not set, repo uses the defaults which are set globally for the manifest file. Please help. hope that helps, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
