116

I've been running Alpha releases of Ubuntu for some time now. I keep running into issues - how can I get these resolved? What should I do when I encounter these problems? And where can I find other Ubuntu+1 users to ask questions?

0

9 Answers 9

78

General Alpha Information

If you've been redirected here you've probably asked a question about an Alpha or Beta release of Ubuntu.

Generally speaking we don't take questions about running or using unreleased versions of Ubuntu releases here since development releases change almost by the hour and usually it's broken and alpha testers are expected to give direct feedback to the developers via the bug tracker so that these issues can be fixed for everyone.

It's not that we don't care, we just wouldn't be good at it and one of the main purposes of the site is to create a reusable resource for users, which would be hard if we had a bunch of questions about something that quickly became out of date!

The answers in this question will help you get started, good luck, and thanks for testing!

File bugs

You should file bugs for the relevant package that you are having problems with. Bugs are one of the main advantages of having developer releases - they provide valuable information to the developers and help them to improve the software.

How do I report a bug?

If you are unsure which package to file the bug against, please use the other resources (forums, mailing lists etc.) to ask which package you should file it against.

Debugging Information will help you file bugs.

33

Forums

  • If your question on Ask Ubuntu was linked to this answer then this is where you should probably go to repost your problem.

The Ubuntu Forums' Development & Programming section is a good place to start. The precise subforum depends on the release, but at the moment you want the Ubuntu Development Version.

Take a look through the recent threads and see if anything looks like the problem you are experiencing. If it doesn't you should create a new thread detailing your experiences.

26

Before an upgrade, always test

sudo apt-get --simulate dist-upgrade

If you get an error about broken packages, don't upgrade.

24

IRC (Internet Relay Chat)

20

ubuntu-devel-announce mailing list

When large changes are being made usually a developer will post on the ubuntu-devel-announce list. This list doesn't get many posts (compared to some of the other Ubuntu lists!) so for pre-release testers there is no excuse not be subscribed to it.

17

Keep an eye on package uploads

Uploads to the archive are sent to a mailing list, named after the animal nickname, for example lucid-changes, utopic-changes, etc. Following this list can be useful to see when risky uploads are being uploaded so you can hopefully avoid problems before it's too late.

Also the Archive Status tool is useful for showing the status of the archive before you upgrade.

1
  • 1
    Alternative: changelogs. Update manager will show only the relevant part (changes between the new and the current version) while Synaptic/apt(itude) will show the full changelog.
    – papukaija
    Apr 17, 2011 at 19:50
8

Launchpad Answers

Launchpad Answers is another official question-and-answer site for Ubuntu (and some other software that is developed on Launchpad), but whereas AskUbuntu is focused on producing reusable answers that help lots of people and evolve over time, Launchpad Answers is a support tracker focused on replying with answers to each question, whatever that question is and whether or not the question is in a form useful to other users.

For some reason, Launchpad Answers often doesn't appear on lists of official Ubuntu support resources, even though it is one (listed prominently here and here), it's been up and running for a long time, and a vibrant chunk of the Ubuntu community puts in lots of time and energy providing and receiving assistance there.

Questions about the development release of Ubuntu (or Ubuntu+1, as we call it here on AU) are welcome in Launchpad Answers, though, like here, if you post a bug as a question, the response will be "file a bug report." Questions about how to properly file or investigate a bug in the development release of Ubuntu are quite welcome on Launchpad Answers, though you should make clear that this is what you're asking or people may assume you're trying to report the bug.

Even if your question is about something that wouldn't produce a good article as an answer, it's still appropriate for Launchpad Answers. Nothing is too localized for Launchpad Answers. The flip side is that answers on Launchpad Answers cannot be edited or voted on, and tend only to be answered by one person at a time (that is, until you indicate whether or not their answer worked for you).

Launchpad Answers is connected to Launchpad Bugs, and questions and bugs on Launchpad can be link to each other (which affects how subscribers are notified), and even converted into each other. Bug reports that should be questions are often converted to questions. Questions that should be bug reports are sometimes converted to bug reports. (While this is possible, often it's better to start from scratch when reporting a bug rather than start with a question, so if someone on Launchpad asks you to report a bug, that's what you should do.)

Questions in any language are supported in Launchpad Answers (you select what language you're asking the question in), even though bug reports should only be filed in English. This is particularly relevant to Ubuntu+1 because it means:

  1. You can use Launchpad Answers to work on bugs that are specific to your language or region, without knowing or feeling comfortable writing and reading English.

  2. You can use Launchpad Answers to ask for help translating text from your language into English, so you can report a bug in English. (Or ask for help making changes to a bug report you've previously made in English.)

Just as it's a good idea to look at the FAQ before using AskUbuntu, it's suggested to read the guide (it's very short!), or at least the part on asking questions, before posting a question on Launchpad Answers.

5

Have fun learning!

The examples here use one branch in quantal. Feel free to change as necessary.

When you see a bug and report it, you can get valuable feedback, especially from developers. You can also try to get a start in programming by submitting a patch. First, you must figure out the source package the bug is related to(related package). It will show up as a name such as linux-meta-ti-omap4, or another package name. You can then visit https://code.launchpad.net/ubuntu/+source/linux-meta-ti-omap4, replacing the package name as needed.

Once there, you should pick the correct branch, usually something like lp:ubuntu/[version-in-development]-proposed/linux-meta-ti-omap4(Note the [version-in-development] part should be the version currently in alpha, or beta.

Now, it's time to get the branch:

First, you'll want bzr:

sudo apt-get install bzr

and you'll want an SSH key(you can skip this if your SSH keys are already on Launchpad):

  1. Open up 'Passwords and Keys' by searching from the dash.

  2. Create a new SSH key, with possibly a password. Make sure it is SSHv2 if there is an option for that, and use RSA.

  3. Right-click it in the list once created, and export it to a file of your choice.

  4. Open the file with Gedit, and copy the text, including the short line on top with info about the key.

  5. Paste this into the box at the bottom of the page here, and submit the form.

  6. You can now connect with BZR. Open a command-line, and create a new directory and change to it:

     mkdir directory-name-of-your-choice&&cd directory-name-of-your-choice
    
  7. Perform the following:

     bzr launchpad-login [launchpad userid]
    
  8. You can now get the branch with:

      bzr branch lp:ubuntu/quantal-proposed/linux-meta-ti-omap4 
    

    changing the branch name as necessary. This is for quantal, but the branch name will change as stated previously.

  9. If you think the branch has been changed by the devs, you can always use bzr pull when in the folder you branched to.

  10. Make your changes using any program of your choice(excluding .po files as those are dynamically generated), and if the problem involves UI text, be sure to change the correct .pot files.

  11. Every time you want to make a checkpoint, use:

    bzr commit -m "a descriptive message about your changes"
    
  12. After finishing work, push the branch with:

    bzr push lp:~[your userid]/project-name/branch-name
    

    in this example case, it will be

     bzr push lp:~[your userid]/ubuntu/quantal-proposed/linux-meta-ti-omap4
    

    Once you are done, visit the bug, and click the "Link to a related branch" at the right. Paste the branch you created, without the lp: part:

    ~[your userid]/ubuntu/quantal-proposed/linux-meta-ti-omap4
    

    in this example. The branch will be merged if the devs like it, or it will be improved upon. It can also be rejected if the problem can be solved more cleanly, your changes do not solve the problem, or if the problem has been solved already, in another branch.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .