On 03/12/10 20:41, Selbak, Rolla N wrote:
So to answer your q, you're right, the SR# bug comment is not necessary
right now, but a nice-to-have for ease of tracking.
The one thing you are required to do is make sure the bug or feature you are
requesting is set to 'resolved', which indicates that the code is submitted.
Then once it hits MeeGo Trunk, Release Engineers will set the bug to
'released', or if the submisison is rejected, they will set the bug to
'reopened'.
I am still concerned that MeeGo cannot easily (historically) determine which rpm
or release a bug is fixed in. This is especially problematic on a week-to-week
basis and it matters more to our customers (device vendors) than to MeeGo core
engineering - which is why
a) it is important
b) we don't really see it - so we don't care
The main problem is as simple as "the changelog doesn't mention the rpm release
number". Only the upstream source version; and that can stay static for a long time.
[1] is a bug where this caused real problems. Sadly it's a closed vendor bug so
I've posted snippets at the end:
(If you have access then please take a look at the bug)
As mentioned in that bug the changelog (snippet) is the canonical source of
information about a package:
# * Wed Oct 13 2010 Markus Lehtonen <[email protected]> - 0.61.25
# - Fix BMC#8330 by modifying dbus.conf
#
# * Fri Oct 01 2010 Markus Lehtonen <[email protected]> - 0.61.25
# - Version bump to 0.61.25
# - Bugfixes plus some of the previous MeeGo-patches now merged upstream
When I check, what rpm contains the fix?
Answer: 0.61.25-2.1 in release W43 and not 0.61.25-1.1 in W42
So I'd like to repeat a proposal I made before the conference [2] that addresses
this problem (although it does have scope-creep into a larger versioning issue).
Either stop using the OBS "generated -Release" mechanism and replace it with a
process/policy based solution designed to meet MeeGo's versioning needs or add
an incrementing/resetting 'pXX' to the version number to specify the MeeGo
patchlevel; ie a manual supplement to -release.
X.Y.ZpRR
This then MUST then be recorded in the .changes file to allow specific changelog
entries which address specific bug/features to be differentiated and related to
specific rpms and hence weekly (and maybe even major) releases.
This needs further development to support packages which are developed on the
new production branch and the old stable branch (eg 1.1 and 1.2). See [2] for
more details.
I've logged a bug [3]
David
[1] Bug showing the issue biting a MeeGo vendor
https://projects.maemo.org/bugzilla/show_bug.cgi?id=200067
[2] Raising the versioning issue (our archives are broken BMC#10909)
http://www.mail-archive.com/[email protected]/msg00415.html
[3] MeeGo Package Changelogs are broken bug:
http://bugs.meego.com/show_bug.cgi?id=10910
##############################################################
The problem was:
Failed to open the connection to "system" message bus: Failed to connect to
socket /var/run/dbus/system_bus_socket: No such file or folder
<snip>
Which dsme version are you using in the images? The problem has been fixed in
MeeGo Trunk week or two ago
<snip>
It looks to me as if the BMC bug #8330
(http://bugs.meego.com/show_bug.cgi?id=8330) were related. It was fixed to
version 0.61.25 of dsme "by modifying dbus.conf" on Oct 13th.
<snip>
Yeah, but comment #3 tells that the fix is not helping our images. The same dbus
message occurs even though we have version 0.61.25 of dsme.
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging
