[Bug 375874] Re: gnumed - SRU - "new upstream available" - 0.4.4

Wed May 13 11:07:17 UTC 2009

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 <tille at debian.org>  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 <tille at debian.org>  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 <tille at debian.org>  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 <tille at debian.org>  Mon, 02 Mar 2009 15:46:15 +0100
gnumed-client (0.3.10-1) unstable; urgency=low

   * New upstream version.

 -- Andreas Tille <tille at debian.org>  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
ubuntu-bugs at lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs