On Mittwoch 13 Mai 2009 12:24:48 James Westby wrote: Hi
>Check that the bug is fixed in the current development release, and that its bug report task is "Fix released". It is, in general, not appropriate to release bug fixes for stable systems without first testing them in the current development branch. Done. https://bugs.launchpad.net/ubuntu/+source/gnumed- client/+bug/375874 >Update the bug report description and make sure it contains the following information: >A statement explaining the impact of the bug on users and justification for backporting the fix to the stable release Done in bug report > An explanation of how the bug has been addressed in the development branch, including the relevant version numbers of packages modified in order to implement the fix. Done in bug report > A minimal patch applicable to the stable version of the package. If preparing a patch is likely to be time-consuming, it may be preferable to get a general approval from the SRU team first. Patch does not make sense. If only the single issue is fixed than we skip the other (not neccessarly reported) bugs. Debdiff is here: https://launchpad.net/~gnumed/+archive/ppa/+files/gnumed- client_0.3.12-ubuntu1~ppa3_0.4.4-1.diff.gz > Detailed instructions how to reproduce the bug. These should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. Please mark this with a line "TEST CASE:". Test case: #1 Set your timezone to CLT and run GNUmed. This bug will appear: > 2009-04-20 00:26:49 WARNING gm.database (/var/lib/python- support/python2.6/Gnumed/pycommon/gmPG2.py::__validate_timezone() #186): time zone [CLT] seems invalid > 2009-04-20 00:27:04 ERROR gm.person (/var/lib/python- support/python2.6/Gnumed/business/gmPerson.py::__init__() #762): cannot instantiate staff instance ... > DataError: unable to parse time Set your timezone to GMT and try again to see it works. > A discussion of the regression potential of the patch and how users could get inadvertently effected. The upgrade could have introduced ne bugs. We know our userbase that has this running in production very well. They have confirmed that it works. Most user's affected are the drive-by tryout user which are not affected as they do not run production systems. >Use Nominate for release to mark the bug as an SRU candidate for the appropriate Ubuntu releases (e. g. the current LTS and latest stable release), then subscribe ubuntu-sru for packages in main/restricted, or motu-sru for packages in universe/multiverse. Done. > Upload the fixed package to release-proposed with the patch in the bug report, a detailed and user-readable changelog, and no other unrelated changes. This requires upload previledges, doesn't it. I have the fixed version in the PPA https://launchpad.net/~gnumed/+archive/ppa Changelog: gnumed-client (0.4.4-1) unstable; urgency=low * New upstream version -- Andreas Tille <[email protected]> Sat, 02 May 2009 00:12:23 +0200 gnumed-client (0.4.3-1) unstable; urgency=low * New upstream version * Do not ship /etc/gnumed/gnumed-client_public.conf any more -- Andreas Tille <[email protected]> Mon, 20 Apr 2009 14:54:58 +0200 gnumed-client (0.4.2-1) unstable; urgency=low * New upstream version * debian/control: gnumed-doc only suggests dwww to not force people installing Apache. * Depends: ${misc:Depends} (as suggested by lintian) * Do not Recommmend libchipcard3-tools any more because it is outdated * Standards-Version: 3.8.1 (no changes needed) * Provides: ${python:Provides} for gnumed-client and gnumed-common * Removed outdated {Provides,Replaces,Conflics} for old packaging stuff. * debian/pyversions: s/2\.3/2.4/ * debian/tools/gnumed: Add GNUmed dir to PYTHONPATH * Depends: python-egenix-mxdatetime -- Andreas Tille <[email protected]> Wed, 18 Mar 2009 12:00:27 +0100 gnumed-client (0.3.12-1) unstable; urgency=low * New upstream version * Watch file now parses developer release page to work around unsifficient uscan - watch file magic which is not sufficient to ignore RC releases of upcoming new version (Thanks to Paul Wise) * New /usr/bin/gnumed according to a suggestion of Josselin Mouette and Karsten Hilbert to work better with new python-support Closes: #516037 (Remark: The GNUmed Python modules do remain for the moment in usr/share/python-support/gnumed-client do keep compatibility with Lenny for some time.) -- Andreas Tille <[email protected]> Mon, 02 Mar 2009 15:46:15 +0100 gnumed-client (0.3.10-1) unstable; urgency=low * New upstream version. -- Andreas Tille <[email protected]> Wed, 11 Feb 2009 22:08:07 +0100 > Make sure that the version number does not conflict with any later and future version in other Ubuntu releases (the security policy document has a well-working scheme which can be used for SRUs.) Also be sure to reference the SRU bug number in the changelog using the 'LP: #NNNNNN' convention. No conflicts evident. >Once the archive admins approve and publish your upload, test the actual binaries in the Ubuntu archive yourself and follow up in the bug report. Who needs to upload this ? Thanks for your time, GNUmed team -- gnumed - SRU - "new upstream available" - 0.4.4 https://bugs.launchpad.net/bugs/375874 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
