Re: migrate from im-switch to im-config

2012-10-28 Thread Ma Xiaojun

On 10/25/12 6:49 PM, Gunnar Hjalmarsson wrote:

im-switch (unlike im-config) provides per display language
configuration, which you are able to set from language-selector.
Considering that there is a plan to replace language-selector with the
g-c-c region capplet, so far we have sticked with im-switch even if it's
deprecated.


I personally feel that per language IM configuration is useless.
Mac OS X doesn't have this feature.
Even we stick with current language-selector dialog, we can decouple 
language selection and IM configuration easily I guess.



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: migrate from im-switch to im-config

2012-10-28 Thread Gunnar Hjalmarsson
On 2012-10-28 06:08, Ma Xiaojun wrote:
 Even we stick with current language-selector dialog, we can decouple
 language selection and IM configuration easily I guess.

I think you are right. But it would be changed behavior and a change to
the GUI, so it would not be appropriate for SRUs. (Saying that because
of the latest comments at https://bugs.launchpad.net/bugs/875435.)

-- 
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


UDS-R Architecture Preview

2012-10-28 Thread Allison Randal
Upcoming highlights for this week in Copenhagen:

http://allisonrandal.com/2012/10/28/uds-r-architecture-preview/

Allison

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


UDS-R: Let's talk about GSoC

2012-10-28 Thread Dylan McCall
Ubuntu participated in Google Summer of Code two years ago, with some
excellent results, but we have not participated since then. Let's talk
about GSoC and think about laying the foundations for a really rocking
application in 2013.

I will be participating remotely at UDS-R (from a particularly troublesome
time zone), so I won't be able to run a session - but I would definitely
like to help with one. So, this is my attempt to gauge interest and to find
a hero who can lead us to victory!

Last year, it looked like Ubuntu's application was kind of hurt because
there weren't a whole lot of clear goals, and many of the suggested
projects would be better handled at their respective upstreams. I think we
should talk about we would like to achieve with a program like GSoC. This
is different from something like the paper cuts initiative. Good project
ideas tend to be significant, yet scoped well enough that someone new to
Ubuntu development can happily complete them under a deadline.

GSoC is a long way off, but UDS is a great opportunity to get it in
peoples' heads so we can hit the ground running this time, with lots of
potential mentors and interesting ideas. Even if GSoC doesn't happen, I
think this discussion could lead to some useful resources for new
developers who want to make unique contributions to Ubuntu.

Any thoughts are appreciated :)

Dylan
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: UDS-R: Let's talk about GSoC

2012-10-28 Thread Benjamin Kerensa
On Sun, Oct 28, 2012 at 1:29 PM, Dylan McCall dylanmcc...@gmail.com wrote:

 Ubuntu participated in Google Summer of Code two years ago, with some
 excellent results, but we have not participated since then. Let's talk
 about GSoC and think about laying the foundations for a really rocking
 application in 2013.

 I will be participating remotely at UDS-R (from a particularly troublesome
 time zone), so I won't be able to run a session - but I would definitely
 like to help with one. So, this is my attempt to gauge interest and to find
 a hero who can lead us to victory!

 Last year, it looked like Ubuntu's application was kind of hurt because
 there weren't a whole lot of clear goals, and many of the suggested
 projects would be better handled at their respective upstreams. I think we
 should talk about we would like to achieve with a program like GSoC. This
 is different from something like the paper cuts initiative. Good project
 ideas tend to be significant, yet scoped well enough that someone new to
 Ubuntu development can happily complete them under a deadline.

Last year we did not apply because there were legal issues surrounding
finding someone at Canonical to grant Luke Faraone permission to act as Org
Admin and enter into a agreement ( http://j.mp/SRAhEO ) on behalf of the
Ubuntu Community. Also the issue of who would receive the money that Google
gives as a stipend to mentors was not addressed since Ubuntu is not a
organization or company and typically Open Source Projects have foundations
that handle the money for them.

We're hoping with luck that these things will be addressed in advance of
the deadlines this year if so Luke has volunteered again to take on the
role as Org Admin and I will be helping and then Daniel Holbach is going to
look into the Legal and Money issue.


 GSoC is a long way off, but UDS is a great opportunity to get it in
 peoples' heads so we can hit the ground running this time, with lots of
 potential mentors and interesting ideas. Even if GSoC doesn't happen, I
 think this discussion could lead to some useful resources for new
 developers who want to make unique contributions to Ubuntu.

True it might have been helpful to have a session but I imagine no slots
are available at this point but still yet many should see this e-mail.


 Any thoughts are appreciated :)

 Dylan

 --
 ubuntu-devel mailing list
 ubuntu-devel@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel




-- 
 Benjamin Kerensa
Tech Writer  Social Media Guru http://benjaminkerensa.com
Phone: (503) 564-8608
 http://facebook.com/bkerensa  http://twitter.com
https://plus.google.com/u/0/115750270177636397262
  http://www.stumbleupon.com/stumbler/bkerensa/
http://www.reddit.com/user/bkerensa
  http://flickr.com/bkerensa  http://benjaminkerensa.com
http://wiki.ubuntu.com/bkerensa
  http://www.last.fm/user/bkerensa

*This message may contain information which is privileged or confidential.
If you are not the named addressee of this message please destroy it
without reading, using, copying or disclosing its contents to any other
person.*
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Raring now open for development

2012-10-28 Thread Matthias Klose

Raring is now open for development, with syncs from unstable currently running.
The development version starts with updated versions of eglibc and python3, and 
some upload rearrangements.


 - GCC 4.7 did see some updates from the upstream branches, and supports
   x32 multilibs on amd64 and i386.

 - eglibc is updated to 2.16.1 [1]. Known issues are
   + a new macro TIME_UTC which conflicts with a macro of the same name
 in boost.
   + exposing a warning for building without any optimization, but defining
 _FORTIFY_SOURCE (currently disabled in the Ubuntu package). A check
 for _FORTIFY_SOURCE using the preprocessor without optimization now
 doesn't show the fortify support anymore.

 - Python 3.3 [2] is now the default python3 version. Packages are now
   rebuilt to use the new python version. It's the plan to drop python3.2
   support before the first raring beta release.

 - Toolchain source packages are now setup to support an aarch64 cross
   toolchain.

 - For Raring, all uploads will go to raring-proposed, and a modified
   instance of britney (the software that handles migration from Debian
   unstable to testing) will copy them to raring when they've been built
   everywhere and do not reduce the count of installable packages in the
   archive [3].

Please check your uploads in a raring chroot, don't just test in a quantal
environment. See [4] how to setup such a development chroot.

[1] http://sourceware.org/ml/libc-alpha/2012-06/msg00807.html
[2] http://docs.python.org/3.3/whatsnew/3.3.html
[3] https://lists.ubuntu.com/archives/ubuntu-devel/2012-October/036043.html
[4] https://wiki.ubuntu.com/DebootstrapChroot


--
ubuntu-devel-announce mailing list
ubuntu-devel-announce@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce


Thinking about SRU

2012-10-28 Thread Ma Xiaojun

SRU stands for Stable Release Updates:
https://wiki.ubuntu.com/StableReleaseUpdates

I think the When list may need some additions.

Probably everyone wants latest version if she happens to notice the 
difference between upstream and Ubuntu.


I'm in no way suggest that Ubuntu should become rolling released. But I 
believe we shouldn't let user stick with old version in these two cases.


1. Misbehaved Software
I mean software that doesn't even fulfill its supposed functionality.
Two examples:

rar package:
RAR format is proprietary, ... (fill suitable bad words here)
But it indeed support Unicode file name / path well.
However, current Ubuntu repository stuck with a broken version:
http://pad.lv/587980

im-switch package:
Due to some obscure reasons, this package make IBus indicator works in a 
probabilistic (like flip a coin) way; the indicator icon may disappear 
in many situations.

This bug spans from 11.10 to 12.10.
http://pad.lv/875435

2. Alpha-quality Software.
Current many desktop stuff on Linux is indeed Alpha-quality.
Examples include GNOME, IBus, Unity, ...
Frequent upgrades are definitely needed. How can we leave users with 
software that stably crash?


Point 0 components from GNOME already caused some problem in 12.10. 
Fortunately they got SRU.


I guess same principle applies to IBus, though 1.5 bumping should 
definitely leave to at least R. We should have 1.3.9 for 10.04 and 1.4.2 
for 11.10/12.04/12.10.

http://pad.lv/1072172
http://pad.lv/1072174

Well, I know there is regression risk in any upgrades. But there is no 
meaning to keep software in stably broken state.



--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss