Re: Upload of praat 5.3.46-1
* Joost van Baal-Ilić [2013-05-22 00:07]: On Tue, Apr 23, 2013 at 09:29:55AM +0200, Andreas Tille wrote: On Tue, Apr 23, 2013 at 08:39:11AM +0200, Rafael Laboissiere wrote: I forgot to say two things: 1) I reverted my previous changes in Git regarding the linking against the native GSL library. The version in HEAD uses now the GSL sources shipped in the pristine tarball, since this is the desire of the upstream author. Uhmmm, so your negotiations about using packaged libraries did not helped? That's sad. Was it a pure "desire" or did he gave reasons for this. I mean: I could perfectly follow good reasons based on a diff or a test case that might fail when using option B instead of option A. However, following pure desire in contrast to my technical understanding is not really convincing to me. Or maybe there was no new statement from upstream about this? Rafael? I based my decision on what the upstream author wrote some time ago, in a discussion forwarded to debian-med: * Paul Boersma [2013-04-13 22:53]: Op 13 apr. 2013, om 22:24 heeft Rafael Laboissiere het volgende geschreven: It fails, unfortunately: Error: Script assertion fails in line 32 (undefined): abs (fisherQ (invFisherQ (i/1000, df1, df2), 1, 10) - 3/1000) < 1e-11 ; 3 1 10 OK, this may be due to only a minor precision problem in GSL or to another set of NaN values in GSL, so determining whether a dynamic GSL library would work for Praat at all will require more testing on our part. For the time being, and perhaps indefinitely, we'll stay with statically linking our libraries, at least for all the editions we produce from here. best wishes, Paul Cheers, Rafael -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130522053607.gc11...@laboissiere.net
Re: Upload of praat 5.3.46-1
Hi,
On Tue, Apr 23, 2013 at 09:29:55AM +0200, Andreas Tille wrote:
> On Tue, Apr 23, 2013 at 08:39:11AM +0200, Rafael Laboissiere wrote:
> > I forgot to say two things:
> >
> > 1) I reverted my previous changes in Git regarding the linking
> > against the native GSL library. The version in HEAD uses now the
> > GSL sources shipped in the pristine tarball, since this is the
> > desire of the upstream author.
>
> Uhmmm, so your negotiations about using packaged libraries did not
> helped? That's sad. Was it a pure "desire" or did he gave reasons for
> this. I mean: I could perfectly follow good reasons based on a diff or
> a test case that might fail when using option B instead of option A.
> However, following pure desire in contrast to my technical understanding
> is not really convincing to me.
Or maybe there was no new statement from upstream about this? Rafael?
Bye,
Joost
--
irc:joostvb@{OFTC,freenode} ∙ http://mdcc.cx/ ∙ http://ad1810.com/
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130521220730.gf30...@beskar.mdcc.cx
Re: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]
Hi Mathias, thanks for the ping and for working on the tryton modules. On Tue, May 21, 2013 at 05:12:42PM +0200, Mathias Behrle wrote: > * Mathias Behrle: " Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 > [ITP]" (Mon, 6 May 2013 14:35:04 +0200): > > CCing specific audience debian-med@lists.debian.org and > debian-pyt...@lists.debian.org > > Dear mentors, > > could you please reconsider the RFS for this (and other) Tryton module(s)? Two > weeks have passed without a response. > > ... > > I would appreciate a lot, if a sponsor could step up soon, because I would > have > preferred to upload the whole Tryton suite (which is still waiting from the > freeze in experimental) together with the new modules at once to unstable. In general I'm working in teams were the VCS is hosted on alioth.org and where I have commit permissions. It is not that I usually would tend to commit a lot. But sometimes it is just simpler to commit a small fix than explaining the sponsee what I want to be changed. Because I prefer working with VCS rather than mentors I gave your Git repository a try: $ git stash Saved working directory and index state WIP on debian: d30bd8f Moving doc/index.rst to appropriate subdirectory doc. HEAD is now at d30bd8f Moving doc/index.rst to appropriate subdirectory doc. $ git-buildpackage dh clean --with python2 dh_testdir debian/rules override_dh_auto_clean make[1]: Entering directory `/home/tillea/debian-maintain/alioth/tryton/tryton-modules-stock-lot' dh_auto_clean running clean 'build/lib.linux-x86_64-2.6' does not exist -- can't clean it 'build/bdist.linux-x86_64' does not exist -- can't clean it 'build/scripts-2.6' does not exist -- can't clean it running clean 'build/lib.linux-x86_64-2.7' does not exist -- can't clean it 'build/bdist.linux-x86_64' does not exist -- can't clean it 'build/scripts-2.7' does not exist -- can't clean it rm -rf *.egg-info make[1]: Leaving directory `/home/tillea/debian-maintain/alioth/tryton/tryton-modules-stock-lot' dh_clean gbp:error: You have uncommitted changes in your source tree: gbp:error: # On branch debian # Changes not staged for commit: # (use "git add/rm ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # deleted:trytond_stock_lot.egg-info/PKG-INFO # deleted:trytond_stock_lot.egg-info/SOURCES.txt # deleted:trytond_stock_lot.egg-info/dependency_links.txt # deleted:trytond_stock_lot.egg-info/entry_points.txt # deleted:trytond_stock_lot.egg-info/not-zip-safe # deleted:trytond_stock_lot.egg-info/requires.txt # deleted:trytond_stock_lot.egg-info/top_level.txt # no changes added to commit (use "git add" and/or "git commit -a") gbp:error: Use --git-ignore-new to ignore. The reason is that you intentionally are deleting trytond_stock_lot.egg-info which is part of upstream tarball. People (like me) who are keen on creating packages that are building twice in a row would prefer to rather move the package out of the way, lets say to trytond_stock_lot.hen-info and restore it afterwards. However, I was running git-buildpackage --git-ignore-new which worked. So I would not have used the issue above as a showstopper specifically when targeting at experimental. But there is finally one issue which let me refrain from a final upload because the file debian/docs is different in Git and on mentors. So I do not have an idea what you really want to be uploaded. Please bring both into sync and I'll sponsor what I will find in Git once you have confirmed that this is OK. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130521160238.gp20...@an3as.eu
[Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]
* Mathias Behrle: " Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]" (Mon, 6 May 2013 14:35:04 +0200): CCing specific audience debian-med@lists.debian.org and debian-pyt...@lists.debian.org Dear mentors, could you please reconsider the RFS for this (and other) Tryton module(s)? Two weeks have passed without a response. The list of new packaged Tryton modules can be seen at [1] (ITPs) resp. [2] (RFSs). VCS for packaging can be found at [7]. They all add important new functionality to the Tryton framework. Especially this one (tryton-modules-stock-lot) is needed as dependency for the package gnuhealth [3] currently waiting in experimental. gnuhealth contains another set of Tryton modules providing the functionality of GNU Health, a free Health and Hospital Information System. All packages are packaged in the same way and they are free of lintian pedantic warnings (the one indicated being outdated [5]). So checking one is checking almost all of them, thus reducing the work load which could seem apparently high for 19 packages. Basically the complete suite of Tryton packages [6] is currently bug free, and I am doing my best to keep this state. I was already signalled to get DM Upload permissions for those new modules as I have already for the other packages. So sponsoring would be a one-shot and not a permanent task. I would appreciate a lot, if a sponsor could step up soon, because I would have preferred to upload the whole Tryton suite (which is still waiting from the freeze in experimental) together with the new modules at once to unstable. Thanks a lot for considering, Mathias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Atryton;dist=unstable;package=wnpp [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Atryton;dist=unstable;package=sponsorship-requests [3] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/gnuhealth/trunk/ [4] http://health.gnu.org/index.html [5] http://lists.debian.org/debian-lint-maint/2012/07/msg7.html [6] http://packages.debian.org/search?keywords=tryton [7] http://debian.tryton.org/gitweb/ > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package > tryton-modules-stock-lot > > * Package name: tryton-modules-stock-lot >Version : 2.8.0-1 >Upstream Author : Tryton project (www.tryton.org) > * URL : http://downloads.tryton.org/2.8/ > * License : GPL-3+ >Section : python > > It builds those binary packages: > > tryton-modules-stock-lot - Tryton Application Platform (Stock Lot Module) > > To access further information about this package, please visit the following > URL: > > http://mentors.debian.net/package/tryton-modules-stock-lot > > > Alternatively, one can download the package with dget using this command: > > dget -x > > http://mentors.debian.net/debian/pool/main/t/tryton-modules-stock-lot/tryton-modules-stock-lot_2.8.0-1.dsc > > > More information about Tryton can be obtained from http://www.tryton.org > Debian packaging for Tryton is hosted at http://debian.tryton.org > > Regards, >Mathias Behrle -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
