“Failed to fetch” errors for PPAs …
Published by Martin Pool February 18, 2011 in PPA
You may start getting “Failed to fetch” error messages when updating your software sources (e.g. through “apt-get update” or “Reload package information” in Synaptic), which may be due to a bug we’ve just cleaned up in Launchpad’s PPAs.
The error looks like this:
W: Failed to fetch http://ppa.launchpad.net/chromium-daily/ppa/ubuntu/dists/maverick/Release Unable to find expected entry restricted/binary-i386/Packages in Meta-index file (malformed Release file?) E: Some index files failed to download, they have been ignored, or old ones used instead.
Launchpad’s UI is evolving
Published by Curtis Hovey February 17, 2011 in General
We are updating the UI over several iterations over the next few weeks for several reasons:
- Launchpad should apply the Canonical guidelines for websites to take advantage of the research done for other sites. Being consistent with other Ubuntu and Canonical sites means there is less for users to learn about what the presentation means.
- Launchpad has 730 style rules. Most are dedicated to defining exceptions, not standards. 730 rules is too much, too much for developers to maintain, too much for users to understand.
Many users have remarked about Launchpad’s recent the loss of colour. We did this because:
- It is hard to learn the meaning of so many colours.
- It is confusing to see headings of different colour that have the same meaning.
- Answers and Blueprints used blue, the same colour as links.
- There were inappropriate uses of green that confused users who know that green means “perform an action without leaving the page”.
- The were uses of orange and purple that users might mistake for Canonical’s aubergine and Ubuntu’s orange.
We appreciate your feedback, and we would like to hear more. There are also legitimate concerns being raised and we are not surprised because they are the same concerns we discussed.
1. Headers are harder to identify
Indeed they are. The old colours were hiding the font-size and whitespace issues that are still present in Launchpad. I am working on this issue right now. Launchpad uses many font sizes, and the percentage mechanism used does not render the size developers intend (font size smaller than default creates accessibility and usability difficulties). I think headers will be easier to understand when there are fewer, but distinct, font-sizes being used.
2. Buttons, callout actions, are hard to find
The links to report a bug for example look like normal links. They are hard to see. These important actions are no longer callouts. The only action that users can still find is the green download button…but that green does not mean “perform an action without leaving the page”. This is bad. We do know what to do about this yet. Maybe you can help. I think they need colour, they may need iconography. Look at http://www.ubuntu.com/ to see an example button and callout links. Launchpad does not have a colour at this moment. Launchpad does not have an obvious position along the axis described in the website guidelines (Canonical, corporate, aubergine)..(Ubuntu, community, orange). Launchpad definitely has both aspects; Canonical created Launchpad to build Ubuntu. I think there is a second axis for upstream projects (corporate and community, hosted and mirrored, Ubuntu and other OSes) that might need a colour. Most of the links that I think of are about participation in community, so I favour orange. But is this right? Does the orange also mean Ubuntu to non-Ubuntu users? Will the use of orange stop users from reporting a bug in the OpenStack project?
Bug search no longer does substring matching of source package names
Published by Robert Collins February 16, 2011 in General
As part of improving performance we have disabled the substring matching of source package names. This fixes bug 268508 and bug 607960. However its a slightly contentious issue – opinions vary about whether bug 268508 is a valid bug or not.
So we have only disabled it – the code is still present and when we have more leeway on the performance of bug searching we’ll revisit this and look into some design and UI analysis to decide whether substring matching of this sort should be done or not.
For now though, there should be less timeouts in bug searches.
Silencing bug notifications for stuff you did
Published by Brad Crittenden February 11, 2011 in Bug Tracking, Cool new stuff, General
Launchpad’s bug mail can be a bit chatty sometimes as I’m sure you’ve noticed. This cycle the Yellow Squad is working to give you more control about the bug mail Launchpad sends to you.
One problem that we’ve known about for a really long time was reported as bug 548 and has recently been closed thanks to the effort of Данило Шеган and Gary Poster. Their fix allows you to globally specify whether you want to receive email about actions you did.
Most people probably do not need to be reminded of something they did a few minutes ago and will want to turn off those emails. But, since this is new functionality we’ve preserved the old behavior unless a user changes the setting. If you do nothing you’ll continue to get email about actions you instigate on bugs.
Opting out of those messages is easy. Simply go to https://launchpad.net/people/+me/+edit and uncheck the box as shown below by the big red arrow.
As mentioned, this is just the first of many features and refinements that we’re working on to help you customize the stream of bug mail coming from Launchpad to suit your needs.
Launchpad read-only 09.00 UTC 11th February 2011
Published by Francis J. Lacoste February 10, 2011 in General
In twelve hours from this posting, Launchpad’s web interface will be read-only, with other aspects offline, for around 90 minutes. This is to allow us to make an update to the structure of the Launchpad database. This replaces the previous read-only period announced for Feb 10th 2011 23.00 UTC.
Starts: 09.00 UTC 11th of February 2011
Expected back by: 10.30 UTC 11th of February 2011
There is a slim possibility that the Launchpad’s web interface will be completely unavailable. Because of circumstances beyond our control, the recovery procedure from the aborted roll-out wasn’t able to be completed within the time frame necessary for the previously scheduled window. In the case where it wouldn’t be complete for that next window, we will still complete the roll-out by taking the web interface offline.
I’m sorry that we’ve had to delay this period of service disruption on such short notice.
Launchpad read-only 23.00 UTC 10th February 2011
Published by Matthew Revell in Notifications
In thirteen hours from this posting, Launchpad’s web interface will be read-only, with other aspects offline, for around 90 minutes. This is to allow us to make an update to the structure of the Launchpad database.
Starts: 23.00 UTC 10th of February 2011
Expected back by: 00.30 UTC 11th of February 2011
We tried to make this release yesterday. Unfortunately, we came across a problem during the roll-out and had to stop what we were doing in order to find a fix.
I’m sorry that we’ve had to arrange a second period of service disruption in two days.
Launchpad offline 23:00UTC 9 February
Published by Martin Pool February 9, 2011 in General
Launchpad will be offline for about 90 minutes while we roll out some changes to the database and to code hosting.
Should launchpadlib default to staging?
Published by Martin Pool in API, Coming changes
Launchpad API client developers: have your say in bug 714043 on whether launchpadlib should connect by default to Launchpad’s staging server (so data is discarded), or to real Launchpad.
Bug expiry reactivated
Published by Martin Pool in Coming changes
As we foreshadowed last October, bug expiry is now active again.
Bugs that are marked Incomplete and that haven’t been touched for 60 days will now start moving to the Expired state. If it turns out the bug’s still useful or valid, anyone can move it back.
We recommend people use the Incomplete state to mean: if this bug report doesn’t get more information, there’s nothing we can do with it.
This only affects projects expire incomplete bug reports setting turned on in the Configure bug tracker page.
New ‘web_link’ property on API objects
Published by Martin Pool February 7, 2011 in API, Cool new stuff
Launchpad has a REST API that exposes almost every object within Launchpad. Most of them have API URLs that closely match the human-readable URL: for instance, https://bugs.launchpad.net/bugs/316694 can also be obtained in machine-oriented JSON or XML form from http://api.launchpad.net/1.0/bugs/316694. (The “1.0” in that URL means this is in the 1.0 API namespace.)
Previously, many Launchpadlib clients used string transformation to get from the API URL to something they could show a human in a web browser.
We’ve just added a web_link property on all Launchpad objects, so client applications can (and should) now just use that instead. Because this is just sent in the object representation you don’t need to upgrade launchpadlib to see it.
