Ubuntu people want users to use apport to report bugs. There's a command-line
tool called 'ubuntu-bug' that you can use if you know the name of the package
or at least the name of executable. There's a "Report a problem" menu item
in many, but not all GUI apps.
Here's what you can do if the GUI app in question doesn't have that menu
item, and you don't remember what it's called, and you're the same sort of a
crazy command-line person that I am:
$xprop|grep PID
Click on the app's window. Watch that shell command return a line that
looks like
_NET_WM_PID(CARDINAL) = 807
Now run
$ps 807 # substitute the real number
You'll see the command name, e.g.
PID TTY STAT TIME COMMAND
807 ? S 0:02 /usr/lib/indicator-applet/indicator-applet --oaf-acti
You can use that with apport-cli or on the Launchpad online bug reporting
form.
For some (many?) programs you can short-circuit this trail by looking at
the WM_CLASS property instead of the _NET_WM_PID property:
$xprop|grep CLASS
WM_CLASS(STRING) = "indicator-applet", "Indicator-applet"
While there is no requirement for the window class name to match the name of
the Ubuntu package or the name of the executable, it may give you a reasonable
guess.
Ubuntu 9.04 is going to be released in around three weeks. As usual I
couldn't wait (and saw that some bugs that were irritating me every day
were fixed in Jaunty), so I upgraded to the current beta.
After a
little hiccough at the beginning, the upgrade was the smoothest Ubuntu
upgrade I've ever had: I spent those two and a half hours browsing the web,
watching screencasts and chatting on IRC, while update-manager worked in the
background. Firefox was mostly very responsive, only stuttering when
update-manager got around to unpacking openoffice.org-common. There were few
debconf or conffile questions (one from sysstat 2 minutes into the upgrade,
then a conffile question after 1 hour and 20 minutes, then two more after 15
minutes, and one more 5 minutes later. And the last one 10 minutes later).
There were no ugly theme changes or failing GNOME applet error messages during
the upgrade. Near the end X-Chat automatically started showing new-style
notifications (beautiful!) and Firefoxes nicely asked to be restarted with a
fold-down notification bar.
Nice. Now, after a reboot things were not so nice: I couldn't login.
After typing in my password and a couple of mode changes I was kicked back
to the GDM prompt. I panicked and started logging into the text consoles
and trying to run startx, quite in vain, since when I just tried gdm again
it worked fine.
The intel video driver feels slower, as promised by the release notes,
but it's acceptable as long as you don't try to rotate the external screen.
Then it's horrible and unusable—a regression since Intrepid. I'll have
to retry with UXA.
Compiz failed to enable a plugin (GNOME Compatibility), so a couple of
key bindings didn't work (Alt+F1 to get the menu, Alt+F2 to get the run dialog,
my custom keybinding to open a terminal) until someone on FreeNode told me
what to enable.
The Flash plugin is now swfdec, and it is unable to cope with Youtube music
videos—the sound is all choppy. I'm wondering if this is swfdec's fault,
pulseaudio's fault (it's common knowledge that all audio problems stem from
pulseaudio, right? ;) or X.org's fault (top shows it's X that's eating 90% CPU
when swfdec is trying to play a video).
A lot of very irritating bugs are gone. I don't need to restart Compiz
after playing with xrandr. X doesn't crash after I play with xrandr.
Two-finger scrolling with the Synaptics touchpad doesn't produce phantom
scroll-down-17-pages events when I take my fingers off the touchpad. The
GNOME panels don't migrate to the external screen when I play with xrandr
(but one of them jumps
from the bottom to the top when I play some more). The new splash
screen has a pretty gradient for its progress bar (but is displayed off-center,
maybe because I added vga=872 to my GRUB kernel options list to avoid ugly
stretching of text consoles). X.org no longer distorts the aspect ratio of
1024x768 when stretching it to fit the 1280x800 screen—now I get sensible
black bars on the sides. The new notification bubbles are
beautiful!. I could stare at them all day. (But the new indicator
applet is
ugly.)
Overall I'm happy. A bunch of very irritating bugs were replaced with
a smaller bunch of somewhat less irritating bugs. The intel video slowdown
scares me a bit, though, but the prettiness of the notification bubbles
outweigh everything else. What can I say, I like pretty things—Ooh,
shiny!
Today I happened to read about lazr.enum in a mailing list.
I went to the PyPI page and
saw raw ReStructuredText
markup instead of a nicely formatted page. Now I know from prior experience
that this happens when the package's description has an error in the markup.
I thought I'd report a bug and provide a patch.
Leap of knowledge: since I know lazr.enum was created by the Launchpad.net
team I could safely assume they were keeping the sources in Launchpad. Therefore
I was pretty sure I could get them with
$bzr branch lp:lazr.enum
so I ran that command and it worked.
Next I looked at setup.py to see how it produces the long_description field.
It was reading the contents of a couple of text files, one of them being
src/lazr/enum/README.txt. I looked at that and saw a
.. toc-tree: directive that does not exists in plain docutils
(it's a Sphinx extension).
I added up a couple of lines to setup.py to strip that out, tested it
(with setup.py --long-description > test.rst; restview test.rst)
committed to my local branch, and created a bug report in Launchpad. Then I
was a bit lost, since I didn't know how to make my fix available. Attach a
patch? Maybe, but I wanted to see if this distributed version control thing is
good for anything else.
I thought that first I'd make that branch public, and then see if there
was a way to link it to the bug report. I ran
$bzr push lp:~mgedmin/lazr.enum/pypi-fix
which took a few seconds to create a new public branch on Launchpad with my
fix in it (it would be nice if I didn't have to explicitly specify my Launchpad
username and the project name—both of which bzr already knows—and
just specify the name of the branch). Then I went back to my bug report and
saw an option to link it to a branch. There was a search field in the popup
that found my "~mgedmin/lazr.enum/pypi-fix" easily enough when I pasted it
into the search box.
After clicking on the branch, I saw a "propose a merge" option. I did that
and Launchpad sent an email to the developers asking them to merge my fix.
I made one mistake, I think: I should've created the bug report
first, and then mentioned the bug number in my commit message (with
bzr commit --fixes=NNN, although here I'm suddenly not sure if the bug
number should be left bare, or prefixed with something like "lp" to indicate it
was a Launchpad bug number?).
Other than that it was a pretty smooth experience. When will I be able to
do that for Ubuntu packages?
Wanted: PyBlosxom plugin to bake CSS styles into the RSS feed, i.e.
replace things like <span style="keyword"> in the main blog pages with
things like <span style="color: #ff7700"> in the RSS.
Also wanted: a spam-resistant comments plugin. (Maybe some/all of them are?
I was always afraid to try.) And a tags plugin (categories are too limiting).
And useful page titles. And a pony.
Update: Laurence Rowe and Alexander Artemenko suggested I
check out cssutils. Alexander
also pointed out that a
similar question was asked on stackoverflow. Peter Bengtsson recently posted a similar tool built with
lxml and regexps. Meanwhile, I took the plunge and installed a comments
plugin, and even somehow managed not to get drowned in spam.
I think I'm going to blog about Ubuntu bugs I encounter during my day.
Don't get me wrong—I love Ubuntu and haven't seen a better OS yet. But
it has bugs.
Why blog and not report them to Launchpad? Many reasons:
producing good bug reports is hard work; bugs rarely show up alone, and if I
start filing one, I'll forget details about the others; sometimes it's unclear
whether something is or is not a bug until you've written it down and looked
at it; Launchpad is slow while previewing a blog post on the local machine is
fast.
This is one of those long and rambling posts that you can skip without
feeling guilty. ;-)
Things I did today:
I enabled my dual-head screen and had to restart compiz to avoid
bug 317431.
After work I tried to switch to single-screen mode again and X promptly
crashed—bug 298226.
When X restarted it picked a fugly stretched 1024x768 mode that looks
very bad on my 1280x800 widescreen panel—because this was the
only common mode between the internal panel and the external 1280x1024
LCD.
I used Ctrl+Alt+Backspace after pulling the VGA cable as a quick way
to restart GDM with a saner resolution. I wonder what I'll do in Jaunty
where Ctrl+Alt+Backspace is disabled by default. (BTW I agree with
that decision, having accidentally pressed Ctrl+Alt+Backspace on
several painful occasions.)
I suspended my laptop and put it in my backpack, then went home.
At home I tried to resume. The laptop suspended again immediately after
waking up.
When I woke it up again, it did not accept my fingerprint (this often
happens, I don't particularly mind—it's difficult to swipe the
finger precisely).
I then typed my password, pressed Enter—and then
gnome-screensaver spent an unreasonably long time verifying my password
(this I do mind).
While it was verifying the password suddenly the GNOME panel showed up
on top of the gnome-screensaver, with two new notification bubbles: one
was the usual post-upgrade reboot required, and the other was a typical
post-upgrade informational notice (one about refreshing ALSA
configuration presets—I haven't seen it before). The interesting
thing is that I don't remember running apt-get upgrade today, and
/var/log/dpkg.log confirms I last upgraded things yesterday at
noon.
I could not take a screenshot of the bizarreness described in step 3,
but that's reasonable—the desktop was still locked. So I took a
(crappy) picture with my cell phone (and now I'm too lazy to upload
it—but I have proof! proof!).
After 30 seconds or so gnome-screensaver finally timed out, the GNOME
panel disappeared, and I got a new fresh screensaver unlock dialog.
This time it worked.
Just after unlocking the screen I saw a GNOME keyring prompting
for my keyring password to enable Network Manager to get the WPA
passphrase needed to log in.
It's the same as my login password. Shouldn't some PAM magic I
recently read about in Ubuntu mailing lists unlock that keyring for me
automatically on login? Oh, right, I log in using
my fingerprint, not my password. Darn.
Now I feel like I should report item #3 (and #13) as a wishlist, item #6 as
a bug (there's probably one open, with a bunch of duplicates, already), #8 as a
bug (but that would be useless—I've no recipe for replicating that), #9
as a bug (again, how can I replicate?)—or, rather two bugs (why did the
informational notices got delayed by a day?). Maybe three bugs: the untitled
(four bugs!) window with the update information says
Refresh Advanced Linux Sound Architecture (ALSA) configuration
presets
New Advanced Linux Sound Architecture (ALSA) configuration presets have
been added. Please execute the asoundconf(1) set-default-card macro in a
Terminal now to refresh your user's configuration presets. You may
accomplish this task by executing the following command in a Terminal:
asoundconf set-default-card
which reads like gibberish to any nontechnical person (and many technical
persons too, I think).
Let's talk more about this notification: the first thought that comes into
the mind of a technical person is: if you know what command I should run in
a terminal, why don't you run it yourself, you stupid machine? The
answer is “because that's not the complete command that you need
to run”:
$asoundconf set-default-card
You have omitted a necessary parameter. Please see the
output from `asoundconf list`, and use one of those sound
card(s) as the parameter.
Okay, I'll bite
$asoundconf list
Names of available sound cards:
Intel
There's only one card. Why isn't it selected as default
automatically, without forcing me to jump through hoops in a terminal? Think
of the children (or, better, your mother)!
But now I remember that Pulseaudio is supposed to be the default ALSA card.
What will happen if I select Intel here? Will it break Pulseaudio? Oh dear,
I've no idea. I'm afraid to do anything now.
I think I will put on my regular-user-glasses and look at that dialog again:
Technobabble technobabble
gibberish gibberish gibberish
Okay, I hit the only button available—close. I'm done here.
Sound appears to continue to work fine without me doing anything.
Why was that dialog necessary? Just get rid of it.
I'm sorry. I did not intend this to become a rant. I wanted to make
a list of reportable bugs that I could review later and file properly (or
have helpful people look up and send me via email—this has happened
before, and I was surprised and grateful).
