1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
LaunchpadIntegration
====================
There are three operations we want to support are:
1. Display the Soyuz information page for the given package
2. Display the Rosetta translations page for the given package
3. Display a Malone bug entry form for the given package.
We want to display these pages in the user's preferred web browser so
that we don't need to worry about authentication, etc.
Soyuz Information Page
======================
http://launchpad.net/$distro/$release/+source/$sourcepackagename
Rosetta Translations Page
=========================
http://translations.launchpad.net/$distro/$release/+source/$sourcepackagename
Do we send them to a page specific to the user's configured locale?
Malone Bug Entry Form
=====================
This one is a bit different. We want to prefill the form with some
information about the system, similar to how the debian reportbug
script does. The information we can provide includes:
* source package name
* binary package name
* version
* architecture
* distro
* distro release
* architecture
* kernel/locale info
* versions of dependencies
In Malone, this could be used to automatically add package
infestations to bugs when they get created. The information would
likely be dumped into the comments box as part of a template for the
user to fill in.
Given that we can only spawn a web browser with a URL, this quantity
of information could easily exceed the URL length limit.
The suggestion on IRC was to have a system where we post some
information to the server before hand, getting back a token in return.
This token is then used to construct the URL to send the user to (the
token could actually be the URL). The creation of such tokens would
need to be possible without authentication, and they should expire
after some interval.
This process might go something like this:
POST /special-bug-submission-url HTTP/1.1
Content-Type: application/xml
Content-Length: ...
<bugdata>
<distro>Ubuntu</distro>
<distrorelease>hoary</distrorelease>
<distroarch>amd64</distroarch>
<binarypackagename>mozilla-firefox</binarypackagename>
<sourcepackagename>mozilla-firefox</sourcepackagename>
<version>1.0.2-0ubuntu5.3</version>
<dependencies>
...
</dependencies>
</bugdata>
HTTP/1.1 303 See Other
Location: https://launchpad.net/malone/bugs/+package?token=XXXXXXXX
...
We then open the resulting URL in the user's preferred browser.
Gathering Information
=====================
The identify.py script demonstrates grabbing of the package specific
information, using one of the following (in increasing order of
reliability):
* an X window ID (or letting the user pick the window)
* a process ID
* a file owned by the package
* the package name
Distro Name and Release can be found with lsb_release program:
$ lsb_release --id --codename --short
Ubuntu hoary
Dpkg can tell us the distro arch:
$ dpkg --print-architecture
amd64
Kernel version can be found with os.uname(). Locale info can be found
from environment and locale.setlocale('').
|