Re: Backport an non-exist package to lucid main
Hello YunQiang, YunQiang Su [2010-09-14 1:37 +0800]: > opencc now is in 10.10's main, but it is not in lucid. > > Can I backport it? Yes, the backport process covers that. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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
Re: extending apport/problem_report format?
Hello Edwin, Edwin Grubbs [2010-09-16 17:47 -0500]: > Launchpad.net is looking into whether to use the problem_report python > module to store website errors or even to use the apport python module > to help collect system data for the problem report. Currently, each > exception is stored in a separate "oops" file with a bunch of extra > data, such as the cgi request variables, and it is formatted like an > rfc822 email message to take advantage of modules for formatting and > parsing. That indeed is what Apport .crash reports have as well. > The oops-tools project, which analyzes and displays the oops files in > a web page, is planned to be open sourced soon. Therefore, I have two > main questions. > 1. Is there interest in having the problem_report format be extended > to handle more complex data structures that will be parsed and > analyzed by a tool such as oops-tools? Not from my side. So far we got along well with just having a single-layer dictionary. The convention for lists as values is to have one element per line, e. g.: Dependencies: libfoo1 libbar2 Can you point out an example what else you need? > 2. Would apport be interested in receiving other features of > oops-tools, such as the django based web interface for viewing oopses? Is this read-only, or can you also update the data there? We have used Launchpad Bugs as a "crash database" backend so far, because a bug tracker provides us all the functionaly that we need, except that it's sometimes hard to tell apart crashes and regular bugs, for getting a clean view for triagers. It sounds like an interesting option, though, if it can represent the structure of Ubuntu, like distros/packages/package versions, etc. > The second question is probably hard to answer right now, so I'll > focus on the limitations of the problem_report format that we would > either extend in a wrapper class or in problem_report itself. > > * problem_report doesn't provide a standard format for complex data. Right, it currently uses standard RFC822, which doesn't define any more complex data types. > Even adding another level of name/value pairs inside a field is not > well supported, since you have to use a StringIO object to get the > data from ProblemReport object to put it in a field of another > ProblemReport. Lists of dictionaries would also require their own > format. Here is an example of recursive ProblemReports. This works fine if you hardcode assumptions about the syntax of particular field names, which we generally have to for such post-processing scripts anyway. But if we need complex data structures, then I'd rather use a standard format like JSON for this, as you suggested. The problem_report module is not conceptually limited to RFC822 only. For example, it also has the ability to output its data Multipart/MIME format (for uploading data to Launchpad). So it wouldn't be a problem at all to add reading/writing JSON. However, the module currently _is_ conceptually limited to a single level dictionary structure, since API users can (and do) pretty much treat it as a dictionary with extra features, and can currently rely on the data types of the values (strings). We could allow more, and then just fix the existing write() and write_mime() to throw an exception if they encounter an unrepresentable data type; this would mean you could never upload such a report to Launchpad bugs. > * problem_report only allows field names to contain letters, numbers, > ".", "_", and "-". That could cause problems when dumping a bunch of > name/value pairs from an application in order to analyze it later. That's not a problem in Apport and package hooks, since (as pointed out before) the set of key names is pretty much static. In the cases where it isn't, hookutils provides a helper for cleaning up key names. I'd like to avoid arbitrary strings here, since it can easily lead to problems, break the RFC822 format, or cause unexpected errors in scripts which process those reports. > * problem_report really supports text or compressed text files. There > is no ability to specify a content-type even when using > problem_report's write_mime() method. In general we know what content type a field has. If not, then you could always specify it in another field, like: Data: blob0xDEADBEEF DataType: image/jpeg ? > * The write_mime() method even encodes the single-line name/value > pairs as base64, so it is not at all human readable. Only if it's longer than 5 lines or has non-ASCII characters, otherwise it lands in the "short values" text section (where it is readable). But why do you care? This format is supposed to be nothing more than a transport vehicle from client computers to Launchpad. It's not really supposed to be looked at by humans. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- Ubuntu-devel-discus
Re: ubuntu-release delegations for unseeded packages in universe/multiverse
On 21/09/10 20:20, Stefan Potyra wrote: > For universe/multiverse packages, that are NOT found on any installation > media, Feature Freeze Exceptions [1] can be obtained from one of the > delegates in addition to ubuntu-release until the date of Final Freeze for > universe [2]: > > * mythbuntu: Mario Limonciello (~superm1) [superm1] > * mozilla team: Chris Coulson (~chrisccoulson) [chrisccoulson], Micah Gersten > (~micahg) [micahg] > * xubuntu: Lionel Le Folgoc (~mrpouit) [mr_pouit] > * netbook: Didier Roche (~didrocks) [didrocks] > * edubuntu: Jonathan Carter (~jonathan) [highvoltage], > Stéphane Graber (~stgraber) [stgraber] > * Ubuntustudio: Scott Lavender (~slavender) [ScottL] Very nice, organised communication, thanks Stefan! How are the delegations working out, now that we have a couple of substantial teams carrying their respective responsibilities? Any observations / suggestions / concerns on your end? Mark -- 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
Re: ubuntu-release delegations for unseeded packages in universe/multiverse
On 22/09/10 15:45, Mark Shuttleworth wrote: > Very nice, organised communication, thanks Stefan! > How are the delegations working out, now that we have a couple of > substantial teams carrying their respective responsibilities? Any > observations / suggestions / concerns on your end? *cough*. Reply-to strikes again, sorry for the broadcast, this was intended for Stefan directly! But I'm interested in thoughts from everyone on the list. The delegation process *should* be giving us a smoother scalability in our diverse community, I'm interested in hear if that's happening, and what friction is being caused if any. Mark -- 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
Re: Ubuntu Branch reviewers
On Mon, 05 Jul 2010 18:47:46 +0300, Bilal Akhtar wrote: > Hi all, > I think it would be a *lot* better to set the reviewer of all ubuntu > branches to ubuntu-sponsors. This would prevent confusion among people > who wish to fix bugs in Ubuntu or merge packages. Such people propose a > merge and the value of reviewer is set to ubuntu-branches, while, > according to https://wiki.ubuntu.com/Bugs/HowToFix and others, the > reviewer should be ubuntu-sponsors. A merge proposal that has this > mistake is > https://code.edge.launchpad.net/~joel-auterson/ubuntu/maverick/shotwell/menu_rename/+merge/28598 > where I had to comment in order to get this change done. > > What are your opinions? The default reviewer for all branches is now set to ~ubuntu-dev as discussed in this thread: https://lists.ubuntu.com/archives/ubuntu-devel/2009-December/029694.html Thanks, James -- 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
Re: About ibus 1.3.7 ibus languages
Hi Shawn and all, On Mon, Sep 20, 2010 at 07:57:12PM -, Computerguy wrote: > I was wondering if you wanted to use ibus-m17 for all of the other > languages in ibus 1.3.7. I have contacted martin pitt and told him for > japanese at least using anthy is better than ibus-m17. Anthy for > japanese has a lot more features than ibus-m17. > > Thank you, Shawn > -- > This message was sent from Launchpad by > Computerguy (https://launchpad.net/~blah-679) > using the "Contact this user" link on your profile page > (https://launchpad.net/~happyaron). > For more information see > https://help.launchpad.net/YourAccount/ContactingPeople I think there are some misunderstanding for the ibus packages and what we are doing. Please let me try to make it clear. Here are some facts: Firstly, ibus is almost used only by CJK users AFAIK, that is to say Chinese (simplified and traditional), Japanese and Korean. I believe the number of users in each of the four are descending sorted in this order as well. Secondly, ibus-m17n was in CD before this time we see it is being removed. This package provides some input method that are not good through m17n libraries. Thirdly, the better choices for users: * Chinese: ibus-pinyin (ibus-chewing is better for some traditional Chinese users, but ibus-pinyin is still good enough comparing with ibus-m17n) * Japanese: ibus-anthy * Korean: ibus-hangul Question: What we are doing? Now we are removing ibus-m17n (and dependencies) from the CD to save some space, because it is not good. Maybe people will complain that with ibus-m17n there is at least a working one but without it there is none. Yes, but removing it should be still considered a step forward rather than regression, because we can find better way for aid of input method in near future's development. Question: Shall we also consider it a regression since some user cannot input characters when they just finished a fresh installation? Definitely not. People who don't use an input method may think there is a one that can use is better than none. But things seems to be contrary in this specific field, because the low quality of those input methods will do harm to user experience and when there is none users will know they need to install it (install language support or simply a package). In fact, we may consider it a big step forward, as explained below. Question: Why removing ibus-m17n a step forward? We make Ubuntu for best user experience, so we are urging to provide top class applications we can. As I've said before, ibus-m17n provides not good input methods for users. According to our user's feedback (Chinese users, via forum, mailing list, irc, etc), newcomers are often be confused by those pre-installed input methods and thinking they are the recommended ones (because Ubuntu will make a best choice for their product if the vendor of Ubuntu is sane). Unfortunately, the input method there are really hard to use: for example, two "pinyin" in ibus-m17n. Input methods on Windows (R) platform are evolving quickly, the user will soon be frustrated by such 1990s style of input method in ibus-m17n, then drop Ubuntu because they feel the experience is UNBELIEVABLE BAD. Removing ibus-m17n from default installation is a best way of solving the misleading. Question: What for users who need ibus-m17n? I've wrote at the very beginning of this letter, that most people who are using ibus are CJK users, and these users have better choices that we can install for them when they are installing language support. For those who really wants input method provided by ibus-m17n, they can simply install it handily. -- Regards, Aron Xu signature.asc Description: Digital signature -- 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
python app import guidelines
I am packaging up a python app to upload it to my PPA eventually. Before this everything I have written is in one directory so all my imports were simple. Now that I am breaking up the app and the top level script is in a "bin" directory and the helper scripts are in a "helpers" directory on the same level. How should my imports be with this directory structure. Would I modify the PYTHONPATH to add any directories I need or is there a better way to do this? I have read python docs about imports but I'm wondering if there are any more guidelines in terms of imports for python apps that are packaged for Ubuntu. Any help would be appreciated. Steve -- 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
Re: python app import guidelines
Stephen, Maybe using a PYTHONPATH (or sys.path.append()) to specify the top-level of your package and then touch'ing __init__py's in all the directories leading to importable packages? Maybe I've misunderstood the question though... -tim On Wed, Sep 22, 2010 at 12:43 PM, Stephen Burke wrote: > I am packaging up a python app to upload it to my PPA eventually. > Before this everything I have written is in one directory so all my > imports were simple. Now that I am breaking up the app and the top > level script is in a "bin" directory and the helper scripts are in a > "helpers" directory on the same level. How should my imports be with > this directory structure. Would I modify the PYTHONPATH to add any > directories I need or is there a better way to do this? I have read > python docs about imports but I'm wondering if there are any more > guidelines in terms of imports for python apps that are packaged for > Ubuntu. > > Any help would be appreciated. > > Steve > > -- > 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 > -- -tim -- 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
Re: python app import guidelines
On Wed, Sep 22, 2010 at 12:43:32PM -0500, Stephen Burke wrote:
> I am packaging up a python app to upload it to my PPA eventually.
> Before this everything I have written is in one directory so all my
> imports were simple. Now that I am breaking up the app and the top
> level script is in a "bin" directory and the helper scripts are in a
> "helpers" directory on the same level. How should my imports be with
> this directory structure. Would I modify the PYTHONPATH to add any
> directories I need or is there a better way to do this? I have read
> python docs about imports but I'm wondering if there are any more
> guidelines in terms of imports for python apps that are packaged for
> Ubuntu.
>
If I understood the question correctly..
I don't think this problem is Ubuntu-specific at all. It's more about
Python's import mechanisms and distutils, but let me tell how I would do
in your situation.
I assume you are using Python version 2.6.
It's a quite good practice to place all your modules inside a package
module. Let's assume that your project is called myproject. Then I would
call the project directory myproject. I would also create a top-level
package called myproject (but the directory name here is lib). It's a
directory with __init__.py file in it.
Directory structure of the project would be something like this:
myproject/setup.py
myproject/src/bin/script
myproject/src/lib/__init__.py
myproject/src/lib/helper.py
And setup() in setup.py would resemble the one below:
distutils.core.setup(
.
.
.
package_dir={'myproject': 'src/lib'},
packages=['myproject'],
scripts=['src/bin/script'],
.
.
)
So the scripts reside in bin-directory and lib-directory would represent
your top-level package, myproject.
python setup.py install will install files by default under /usr/local
prefix:
/usr/local/bin/script
/usr/local/lib/python2.6/dist-packages/myproject
/usr/local/lib/python2.6/dist-packages/myproject/__init__.py
/usr/local/lib/python2.6/dist-packages/myproject/helper.py
/usr/local/bin is by default in PATH and
/usr/local/lib/python2.6./dist-packages in Python's search path.
Once installed, helper.py can be imported with:
import myproject.helper
There should be no need to play with PYTHONPATH or sys.path.append()
whatsoever.
The package structure works as a namespace. It gives a logical structure
for your project and reduces the risk of mixing identically named
modules.
For further information, please refer to:
http://docs.python.org/distutils/
When you are building a deb-package for your project, see
https://wiki.ubuntu.com/PackagingGuide/Complete#Packaging%20Python%20modules%20with%20CDBS
I hope this helped. Perhaps more experienced ones can correct my
mistakes and give alternative solutions.
--
Tuomas
signature.asc
Description: Digital signature
--
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
Re: About ibus 1.3.7 ibus languages
On 22 September 2010 19:27, Aron Xu wrote: > Thirdly, the better choices for users: > * Chinese: ibus-pinyin (ibus-chewing is better for some traditional > Chinese users, but ibus-pinyin is still good enough comparing > with ibus-m17n) Pinyin won't work for Taiwanese users - like you're saying, ibus-chewing is needed since those users don't use pinyin at all (i.e. ibus-pinyin isn't "good enough"). Unless you mean by your selection that Cantonese users have to use something different than ibus (which method would that be?), ibus-pinyin and ibus-chewing don't cover all Chinese users. They'd have to learn a whole new language (Mandarin) before even being able to consider those methods. > Question: What we are doing? > > Now we are removing ibus-m17n (and dependencies) from the CD to save > some space, because it is not good. Maybe people will complain that with > ibus-m17n there is at least a working one but without it there is none. > Yes, but removing it should be still considered a step forward rather > than regression, because we can find better way for aid of input method > in near future's development. > > Question: Shall we also consider it a regression since some user cannot > input characters when they just finished a fresh installation? > > Definitely not. People who don't use an input method may think there is > a one that can use is better than none. But things seems to be contrary > in this specific field, because the low quality of those input methods > will do harm to user experience and when there is none users will know > they need to install it (install language support or simply a package). > In fact, we may consider it a big step forward, as explained below. I completely agree that no method at all would, in this case, be better than one that doesn't work. The Ubuntu Community should be aware, though, that most CJK users would just download specially localized version of the LiveCD, resulting in more fragmentation and less bug reports. However, that was already the case when CJK support was not working in older versions of Ubuntu, and while it meant at the time the main Ubuntu didn't get the fixes (and wasn't working), CJK support has now improved to the point the international version just works, so not getting those smaller improvements might not be a big deal. And thanks a lot Aron for your dedication. (Also, sorry if the formatting isn't right - I only have access to webmail these days). -- 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
