Proposal: XSBC-Bugtracker in debian package

[X-Fade]

While implementing the maemo.org packages interface (http://maemo.org/packages/), I wanted to add a link to the bugtracker for a package or project. Eventually integrating bug reporting/searching, but more on that later. As all information is gathered from the debian packages themselves, it would make sense to have the bugtracker URL available in the control file.

There doesn't seem to be a default field in debian control files for and URL of the bugtracker which the project is using. Therefor I want to propose introducing the Xsbc-Bugtracker field.

Xsbc-Bugtracker:
The URL of the bugtracker for this package, preferably (when applicable) the URL where you can directly file a bug. The content of this field is a simple URL without any surrounding characters such as <>.

Example:

Xsbc-Bugtracker: https://bugs.maemo.org/enter_bug.cgi?product=Wormux

By putting the bugtracker URL inside the package, people always have a way to find out where to file bugs. This could even be used for filing bugs through an application interface or crash reporter in the future.

When this feature is accepted, it should be added to the Packaging Policy too.

Please let me know what you think.

[zerojay]

While implementing the maemo.org packages interface (http://maemo.org/packages/), I wanted to add a link to the bugtracker for a package or project. Eventually integrating bug reporting/searching, but more on that later. As all information is gathered from the debian packages themselves, it would make sense to have the bugtracker URL available in the control file.

There doesn't seem to be a default field in debian control files for and URL of the bugtracker which the project is using. Therefor I want to propose introducing the XSBC-Bugtracker field.

XSBC-Bugtracker:
The URL of the bugtracker for this package, preferably (when applicable) the URL where you can directly file a bug. The content of this field is a simple URL without any surrounding characters such as <>.

Example:

XSBC-Bugtracker: https://bugs.maemo.org/enter_bug.cgi?product=Wormux

By putting the bugtracker URL inside the package, people always have a way to find out where to file bugs. This could even be used for filing bugs through an application interface or crash reporter in the future.

When this feature is accepted, it should be added to the Packaging Policy too.

Please let me know what you think.

I love it. Anything that can help us track bugs down easier would be great.

[timsamoff]

Brilliant!

Tim

[X-Fade]

I love it. Anything that can help us track bugs down easier would be great.

I will implement a test in the importer for the packages interface. One beer at the Summit for the first person to upload a package with the field included ;)

[pelago]

What does XSBC mean?

[mikkov]

What does XSBC mean?

X tells that it's user defiend field
S tells that field will be copied to source package control file
B tells that field will be copied to binary package control file
C tells that field will be copied upload control file

[mikkov]

I included the line in one package, but won't tell which one :)

[Graham Cobb]

Niels,

Please post the proposal on maemo-developers. That is where the developers, who are the ones who would have to implement this, live!

Persoanlly I have no objection but I know that the several times this has been discussed before there has been disagreement about how to achieve this goal.

Graham

[X-Fade]

Niels,

Please post the proposal on maemo-developers. That is where the developers, who are the ones who would have to implement this, live!

Persoanlly I have no objection but I know that the several times this has been discussed before there has been disagreement about how to achieve this goal.

Graham

Hi Graham, sorry about that. I was going to do that yesterday evening, but got distracted by the login issue we had.

[Graham Cobb]

Hmm. I tried adding an Xsbc-Bugtracker: line to a package (in the Source: section of the control file).

dh_builddep issued a warning (which was repeated for each binary package):

warning, `debian/libxsettings-client-dev/DEBIAN/control' contains user-defined field `Bugtracker'

And the field appeared as Bugtracker: in the .deb.

Is this as expected? I would have thought it should have been copied unchanged to the packages or, at least, that it would have retained the X- prefix.

I'm not keen on having every build produce several warnings from dh_buildep. Is there any other way to do this?

Graham

[mikkov]

yes, that's how it should work. See http://www.debian.org/doc/debian-policy/ch-controlfields.html#s5.7

User defined fields are allowed in Debian policy, so warning can be ignored.

[aboaboit]

Example:

Xsbc-Bugtracker: https://bugs.maemo.org/enter_bug.cgi?product=Wormux


Source: openvpn
Section: user/network
Priority: optional
Maintainer: Andrea Borgia <andrea@borgia.bo.it>
Build-Depends: debhelper (>= 5), libssl-dev (>= 0.9.8e-1), liblzo2-dev, quilt
Standards-Version: 3.8.2
Xsbc-Bugtracker: https://bugs.maemo.org/enter_bug.cgi?product=openvpn

Is there a specific section of the control file where this tag should be placed? As written above, the link in the deb appears truncated at ...product=o
(Fremantle SDK, final)

[mikkov]

Is there a specific section of the control file where this tag should be placed? As written above, the link in the deb appears truncated at ...product=o
(Fremantle SDK, final)

I tested with openvpn from fremantle extras-devel with your new line in debian/control and Bugtracker field appears intact in .deb file. How did you test it?

Apparently you're making a new version, so could add maemo-optify there too :)

[aboaboit]

I tested with openvpn from fremantle extras-devel with your new line in debian/control and Bugtracker field appears intact in .deb file. How did you test it?


I created the package in my sdk and browsed the deb through mc. The package from extras-devel has been uploaded by somebody else and is not installable, because of a missing dependency (liblzo2-2) that is supposed to be already in the device itself but in fact isn't.



Apparently you're making a new version, so could add maemo-optify there too :)

Hopefully I won't get too many flames but... maemo-optify looks kludgy to me. From the discussion at the summit, I understood that it is ok to alter debian/rules & configure to install directly under /opt/package and that what I have in mind for rc20.

[Jaffa]

Hopefully I won't get too many flames but... maemo-optify looks kludgy to me. From the discussion at the summit, I understood that it is ok to alter debian/rules & configure to install directly under /opt/package and that what I have in mind for rc20.

That's fine. The main thing is that you use /opt.