= Where is armel port today = Buildd's are running fine, and more and more packages get built properly. However, there is not much development going on or pushing to get it included officially. - Armel port keeps between 90-91% upto date. This is about the same level as m68k port. The largest missing bit is lack of g77, which I intend to workaround by pushing Debian to the more modern gfortran compiler. Unfortunately I haven't had as much time to dedicate to this as I wished.. - The biggest changes since summer: Thanks to the efforts of Andrew Haley, gcj Java compiler and runtime has been ported for Arm EABI, and has been included in Debian armel. - Most breakage is related to sid being more or less broken all the time. Which means we need to make a sid snapshot release users can use for debootstrapping any day. = Help Needed = As mentioned earlier, I m mildly busy, so I can't work on everything. Thus I call for help. http://wiki.debian.org/ArmEabiTodo and #debian-arm on irc.debian.org are used as communication channel. Instead of updating the wiki again, I'll try listing the most urgent issues in this mail now. == Developer machine == I believe Wookey was working on this - any news? Meanwhile using qemu system emulator is the best way for developers to try out armel port: http://wiki.debian.org/ArmEabiHowto == Fixing bugs == - Toolchain The only bug in toolchain sticks out at the moment is #443234. testcase: http://nchipin.kos.to/test-llabs.cpp - Bugs filed: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-arm@lists.debian.org&tag=eabi Normal bug triaging: add patch where missing, where bug has patch, poke maintainer. - Packages failing to build: Some of these already have bugs. Many of them FTBFS on official architectures as well. For the failures that don't have a bug, research is needed to find out why they fail. http://unstable.buildd.net/buildd/armel_Failed.html In cases a bug exists (but isn't marked on wanna-build page), usertagging the bug as eabi (see the end of ArmEabiTodo wiki page) would be helpfull. == NMU's == If you have DD access, NMU'ing arm eabi bugs ignored by their MIA maintainers, should be fine. Use 7-day Delayed. For packages with RC bugs, we are supposedly on 0-day NMU period. Still, as long as we are talking about a unofficial port, being polite with maintainers is a good idea. == Porting == Much bigger tasks than just fixing bugs, but on the other hand has potentially much more satisfaction when completed :) Objective C / gnustep - Any takers? Gnu Haskell (ghc6) - Ditto. Gnu D compiler (gdc-4.1) - Another new language, may work partially? ocaml - missing native compiler ...And many many lesser languages.. == Triaging wanna-build states == Dep-wait states that a source package will not be tried to build until the package being depended on appears. Unfortunately this state sticks, even if the dependencies have changed since. Alternatively I may have set a wrong dep-wait accidentally.. http://unstable.buildd.net/buildd/armel_Dep-Wait.html Also, Not-For-Us state sticks, even if the package gets ported over to armel in meanwhile: http://unstable.buildd.net/buildd/armel_Not-For-Us.html If you can spot either of the above states, send a mail to me or tell me on #debian-arm. == Emptying unreleased repository == Unreleased contains packages that could not wait for maintainer fixing issues. Since Joey Hess reviewed the list of packages a few months ago, the list has got a lot shorter. As the only regression, I have uploaded a hacked libidn while waiting for #444580 in glibc to get resolved. http://ftp.gnuab.org/debian/dists/unreleased/main/binary-armel/Packages == Support for more hardware == Yes, we do want to support many other systems than just iop32x and ixp400 systems! Personally I think the most interesting ones would be: 1) Orion Based NAS systems, and people have asked for supporting them several times. Cheap, well available and appear to be reasonably fast. 2) Nokia internet tablets (TI OMAP based) (stay tuned, I'm working on it..) == Poking ftp masters for archive inclusion == This one is something *I* need to do... I just hope to eliminate as many as possible lame excuses not to include to the port before starting nag the powers to be. Thanks for reading all the way to the end :) Cheers, Riku -- "rm -rf" only sounds scary if you don't have backups
Attachment:
signature.asc
Description: Digital signature