On 03/02/16 04:47, Rahul Amaram wrote: > On Wednesday 03 February 2016 12:05 AM, Ximin Luo wrote: >>> iv. Upload new packages twextpy and pg8000 >>> >> I've just uploaded these. I fixed a few minor things before uploading, >> please check git and review them. In general, I run "lintian -i -I >> --pedantic --color auto xxx.changes" to catch things like that, and it's a >> good habit to get into. > I had created two entries in debian/changelog because I had already tagged > the first release version and did not want to delete the tags. I have now, > however, deleted the tags and recreated them. Like you said, I think it is > best to create tags, once the packages are uploaded. > Also, I always run lintian, but don't use the --pedantic option. Will start > using it hereafter.
Ah yes, not deleting/recreating tags is good practice in general. However, for Debian at this time, FTP is the primary source for "what is a particular version" and the git repos are secondary, so it's OK to go back and fix up history. In the future maybe/hopefully Debian will integrate the FTP and git systems better, then if that happens there ought to be automatic enforcement of "can't push tag xxx because it's not in FTP yet". >> >> As part of the fix to (k) earlier, I pushed another patch to a side branch >> of calendarserver: [1]. You haven't applied it to debian/sid yet, but I >> think it may be necessary. To test, you should try to add/remove events with >> non-ascii unicode characters in them such as "ßßß". If it fails, then try >> the patch and if it works please add it to git as well. >> >> X >> >> [1] >> https://anonscm.debian.org/cgit/calendarserver/calendarserver.git/diff/debian/patches/unicode-fixes.patch?h=debian/_wip_sid&id=4476a73ff4df39baa297606e00e66241f371178c >> > I will see how I could test unicode characters. Also, I do not know the > impact of the change. Should I get it reviewed by upstream? > For me, I could reproduce the bug by adding an event in a client (e.g. icedove+iceowl) called "ßßß" or some other thing, then the event wouldn't actually be created, and I could see some decode errors in the caldavd error logs. The change should have minimal impact - it merely allows that function to accept more values for self.scheduleTag than it was doing previously (raising exception when it was of type 'unicode' containing non-ascii chars). But yes it would be good to ask upstream to review it. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
