Hello everyone.
Our current developer guidelines for python development state that we
should support both python2.5 and python2.6.
I'd like to ask if python2.5 can be dropped from the list. I just took
the steps required to test python2.5 (and removed 2.6-only features in
the process). I had to use Hardy VM to do so because python 2.5 is no
longer available in the Lucid archive. Doing additional testing in a VM
is cumbersome and error-prone as we can accidentally slip in a 2.6-only
code or trigger 2.5 bug we didn't know about and it might go untested.
Can we rationalise the requirements for supporting python2.5 and if so,
devise a sensible testing plan for our python development?
BTW: It's worth publishing our python development practices on the
Linaro wiki.
Best regards
Zygmunt
Hi All,
Matthias and I have been throught the Ubuntu GCC 4.4 patch set and
decided what to do with each of them in Linaro GCC 4.4 and 4.5. Some
patches will be integrated into Linaro, and some will remain
Debian/Ubuntu local.
The patches can be found here:
http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/?p…
Here are the patches in alphabetical order, and whether to apply to
linaro gcc (yes/no) or already in 4.5 (upstream):
PATCH Linaro 4.4 4.5
----------------------------------------------------------------
ada-acats.diff yes yes
ada-arm-eabi.diff yes upstream
ada-bug564232.diff no no
ada-default-project-path.diff no no
ada-driver-check.diff no no
ada-gcc-name.diff [1] no no
ada-gnatvsn.diff [7] maybe maybe
ada-libgnatprj.diff no no
ada-libgnatvsn.diff no no
ada-library-project-files-soname.diff no no
ada-link-lib.diff no no
ada-mips.diff no no
ada-nobiarch-check.diff no no
ada-polyorb-dsa.diff maybe upstream
ada-sjlj.diff no no
ada-symbolic-tracebacks.diff [2] maybe maybe
alpha-ieee.diff no no
alpha-ieee-doc.diff no no
alpha-no-ev4-directive.diff no no
arm-boehm-gc-locks.diff yes upstream
armel-hilo-union-class.diff [8] maybe maybe
arm-gcc-gcse-cs.diff yes upstream
arm-unbreak-eabi-armv4t.diff no no
boehm-gc-getnprocs.diff [1] maybe maybe
boehm-gc-nocheck.diff no no
cell-branch.diff [9] no upstream
cell-branch-doc.diff [9] no upstream
config-ml.diff no no
cross-fixes.diff no no
cross-include.diff no no
deb-protoize.diff no no
fix-warnings.diff no no
gcc-arm-implicit-it.diff [5] maybe maybe
gcc-arm-thumb2-sched.diff [10] yes upstream
gcc-atom.diff in CS upstream
gcc-atom-doc.diff in CS upstream
gcc-build-id.diff yes upstream
gcc-cloog-dl-cs.diff no no
gcc-default-format-security.diff [1] no no
gcc-default-fortify-source.diff [1] no no
gcc-default-relro.diff [1] no no
gcc-default-ssp.diff [1] no no
gcc-d-lang.diff no no
gcc-driver-extra-langs.diff no no
gcc-hash-style-both.diff [1] no no
gcc-hash-style-gnu.diff [1] no no
gcc-ice-apport.diff no no
gcc-ice-hack.diff [3] no no
gcc-ix86-asm-generic32.diff no no
gcc-multiarch-cs.diff no no
gcc-multiarch-i686-cs.diff no no
gcc-multilib64dir.diff no no
gcc-pascal-lang.diff no no
gcc-stack_chk_fail-check.diff yes upstream
gcc-textdomain.diff [1] no no
gcc-unwind-debug-hook.diff yes upstream
gcj-use-atomic-builtins.diff yes upstream
gcj-use-atomic-builtins-doc.diff yes upstream
gold-and-ld.diff no no
gold-and-ld-doc.diff no no
hurd-changes.diff no no
hurd-pthread.diff no no
ignore-comp-fail.diff no no
kbsd-gnu-ada.diff no no
kbsd-gnu.diff no no
libgomp-omp_h-multilib.diff [3] no no
libjava-armel-unwind.diff no no
libjava-atomic-builtins-eabi.diff yes upstream
libjava-disable-plugin.diff no upstream
libjava-disable-static.diff no upstream
libjava-fixed-symlinks.diff no upstream
libjava-jnipath.diff no no
libjava-josm-fixes.diff yes upstream
libjava-nobiarch-check.diff no no
libjava-rpath.diff no no
libjava-sjlj.diff no no
libjava-stacktrace.diff [1,2] no no
libjava-subdir.diff no no
libstdc++-arm-no-check.diff no no
libstdc++-arm-wno-abi.diff no no
libstdc++-doclink.diff no no
libstdc++-ldbl-compat.diff [4] yes yes
libstdc++-man-3cxx.diff no no
libstdc++-pic.diff no no
libstdc++-test-installed.diff [5] maybe maybe
libsupc++-vmi_class_type_info.diff yes upstream
link-libs.diff no no
m68k-allow-gnu99.diff no no
mips-fix-loongson2f-nop-cs.diff no no
mips-triarch.diff no no
mudflap-nocheck.diff no no
note-gnu-stack.diff [3] no no
powerpc-biarch.diff no no
pr25509.diff no upstream
pr25509-doc.diff no upstream
pr38333.diff no upstream
pr39429.diff yes upstream
pr39491.diff no no
pr40133.diff yes upstream
pr40134.diff [2,6] yes yes
pr40521-revert-workaround.diff yes upstream
pr41848.diff [4] yes yes
pr42321.diff yes upstream
pr42748.diff yes upstream
pr43323.diff yes upstream
pr44261.diff no no
rename-info-files.diff no no
rev146451.diff yes upstream
s390-biarch.diff no no
sh4_atomic_update.diff no no
sh4-mode-switching.diff no no
sh4-multilib.diff no no
sh4-scheduling.diff no no
sparc-force-cpu.diff no no
testsuite-hardening-format.diff no no
testsuite-hardening-fortify.diff no no
testsuite-hardening-printf-types.diff no no
[1] not upstreamable, but maybe another patch would be.
[2] Matthias to investigate.
[3] Fedora origin.
[4] Already submitted upstream, not in 4.5.
[5] Requires review.
[6] ARM part only.
[7] issue closed upstream, no patch.
[8] Julian to investigate.
[9] Not interesting to Linaro, but Canonical would like CS to unbreak it
for Ubuntu.
[10] Part of this patch is already in 4.4
Andrew Stubbs
Hi
Wanted to share that Matthias Klose launched a rebuild of Ubuntu main
packages on i386 and amd64 with gcc-4.4 + first Linaro diff which we
had sent him.
All build failures:
https://launchpad.net/ubuntu/+archive/test-rebuild-20100628/+builds?build_t…
What needs to happen is reviewing the failures to see whether they are
regressions caused by the Linaro diff. One way to do that is to
compare with:
http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
which has failures from a recent rebuilds of Ubuntu (compare the
version number as well!).
Steve Langasek told me the Foundations team might be able to help sort
these into toolchain and non-toolchain bugs.
For each build failure:
Check whether it's a regression with the same source + version
If it's a regression:
If it's a toolchain bug:
file a bug against gcc-linaro
Else:
file a bug against the Ubuntu package, tag it gcc-linaro
Else:
decide whether it's worth filing a bug against the Ubuntu package
Thanks!
--
Loïc Minier
Hi all,
This is a reminder that Linaro 1.0 alpha2 will be release on Thursday 1st
July and an archive freeze will be in place from Tuesday 29th June. For
more information on the 1.0 release and the upcoming milestones, please
take a look at this [1] wiki page.
Regards,
Jamie.
--
Linaro Release Manager
[1] https://wiki.linaro.org/Releases/1011#Linaro10.11Schedule
Dnia poniedziałek, 28 czerwca 2010 o 10:58:32 Yuri Bushmelev napisał(a):
> > Is there a X11 server which can run (perhaps windowed) under QWS? This
> > would be great for compatibility with X apps. Something like
> > Xephyr/Xnest perhaps?
>
> There was Xqt and Xqt2 but they are based on Opie (QT/E 1.5-2.0 iirc).
OPIE was based on Qt/E 2.3 version. 1.5-2.2 were Qtopia versions from which
OPIE took lot of code.
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
Hi all!
As part of the User Platform team's exploration of non X11-based graphical
environments I have started experimenting with the QWS variant of the Qt
library (also known as Qt/Embedded).
Qt/QWS offers the ability to render graphics directly on a Linux framebuffer
without the need for X11 or any other windowing system. It provides its own
simple windowing system, which is (unsurprisingly) called the Qt Windowing
System (QWS).
The Qt/QWS variant is mostly API compatible with Qt/X11, except for some X11
specific functions and some missing libraries (eg QtOpenGL). Most Qt programs
should build without problems with Qt/QWS. Note, however, that Qt/QWS is *not*
ABI compatible with Qt/X11.
Qt/QWS has been tested successfully on the x86 architecture under both X11
(using the QVFB virtual framebuffer) and the Linux framebuffer. Tests for the
ARM architecture are under way. If you test the libraries on ARM please let
us know how it went!
You can find installation and usage instructions at:
https://wiki.ubuntu.com/Specs/M/ARMQtonEmbedded/Guide
You can also find some screenshots at:
http://people.canonical.com/~afrantzis/qt4-qws-screenshots/
If you have any issues or questions don't hesitate to contact me!
As a side note, the next generation of Embedded Qt, called (for now)
project Lighthouse, is planned for Q1 2011 and is going to improve on
QWS by offering support for hardware acceleration and a plugin
architecture for windowing systems (instead of just a built-in one). We
are keeping an eye on that and are planning to eventually provide
experimental packages for Lighthouse.
Thanks,
Alexandros
All,
I joined few days back with intention to contribute in development. I
have experience in device drivers and base port for Arm based SOCs. But
i am not sure where to start here in lenaro! I have access to A9 dual
core based boards at work, and if necessary i'll arrange beagle
board.
Are we going to have some formal start of project emails on the list?
how would i know which areas require contribution from volunteers?
Thanks and regards,
pankaj
Hi all,
From some discussions at the previous Ubuntu Developer Summit, I've put up a
page on the devicetree.org wiki with the ultimate goal of describing device
tree bindings for ALSA System on Chip devices.
At this stage, we're just looking at how to structure device in the device
tree. The bindings for specific devices will come as required (ie, as we add
device tree support for them).
So - if you're interested in the ALSA and/or device tree areas, please take a
look at the notes from UDS:
http://devicetree.org/SoC_Audio
- if you have any comments or suggestions, please let me know, or add to the
page (or the discussion for the page). I intend for this document to become a
more formal specification, but we still have a way to go before that happens.
If you'd like an introduction to device trees, Grant has a good walkthrough-
style document at:
http://devicetree.org/Device_Tree_Usage
Cheers,
Jeremy