Re: QSpeakers : worth packaging ?

[Benoît Rouits]

Le 25/10/2016 à 16:31, Filippo Rusconi a écrit :

Greetings, Benoît,

On Mon, Oct 24, 2016 at 11:16:40PM +0200, Benoît Rouits wrote:

Hello debian-science list !
[...]
I wrote a program to simulate frequency response of well-known
loudspeaker enclosures given the loudspeaker Thiele/Small [TS]
parameters and the cabinet parameters (volume, ...). As i use it
extensively as a DIY-er, i wondered if it could be useful for other
people, including teachers in acoustics (i studied, lots of years ago
in this realm). [...]


I do not think that anybody would discourage you from writing good
software and
then package it for Debian !


cool, i filled an ITP against wnpp: #842087
I just uploaded a source package on:
https://mentors.debian.net/package/qspeakers

reviews and sponsorship welcomed !



I saw on the image that the GUI is in French. Of course, you'll need to
have
that GUI by default in English.


Yes, indeed, the screenshot shows QSpeakers in my locale, but QSpeakers 
defaults to English.




If your program is on par with other software with similar features, of
course I think Debian might benefit from a properly packaged software
piece.
Even moreso if you package the software yourself!


see above :-)



Cheers,
Filippo


Thank you for your kind reply,
Benoît

Re: QSpeakers : worth packaging ?

[Filippo Rusconi]

Greetings, Benoît,

On Mon, Oct 24, 2016 at 11:16:40PM +0200, Benoît Rouits wrote:

Hello debian-science list !

This is my first post to this list, my name is Benoît and I felt it 
was a topic for debian-science -- sorry if not.


I wrote a program to simulate frequency response of well-known 
loudspeaker enclosures given the loudspeaker Thiele/Small [TS] 
parameters and the cabinet parameters (volume, ...). As i use it 
extensively as a DIY-er, i wondered if it could be useful for other 
people, including teachers in acoustics (i studied, lots of years ago 
in this realm). So, would it be worth to include it in Debian as a 
"misc" package? There are a lot of programs like it on Windows® but no 
free software, appart gspeakers (defunct, gtk+2.0, never packaged) for 
unices, AFAIK. I would like to have your comments or suggestions on 
it.


I do not think that anybody would discourage you from writing good software and
then package it for Debian !

I saw on the image that the GUI is in French. Of course, you'll need to have
that GUI by default in English.

If your program is on par with other software with similar features, of
course I think Debian might benefit from a properly packaged software piece.
Even moreso if you package the software yourself!

Cheers,
Filippo

--
Filippo Rusconi, PhD - 
public crypto key B053 304E 17D6 D419 DD9B 4651 41AB 484D 7694 CF42 @ pgp.mit.edu

Re: [ftpmas...@ftp-master.debian.org: dh-r_20160916_amd64.changes ACCEPTED into unstable, unstable]

[Andreas Tille]

On Tue, Oct 25, 2016 at 03:31:47PM +0200, Gordon Ball wrote:
> > know and I'll work down the list of packages on my todo list.  I just
> > want to avoid duplicated work.
> > 
> 
> Quite a few are probably now out of date (bioconductor release in the
> meanwhile), but yes, I can push some updates once I'm able to verify the
> builds without needing to inject a local copy of dh-r.

I actually want to update the packages outdated upstream thus I'd just
take over your packaging changes and merge it with the new upstream
version.  I do not intend to simply change the packaging of any R
package.
 
Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: [ftpmas...@ftp-master.debian.org: dh-r_20160916_amd64.changes ACCEPTED into unstable, unstable]

[Gordon Ball]

On 25/10/16 15:26, Andreas Tille wrote:
> Hi Gordon,
> 
> good news that dh-r was accepted.  You previously wrote that you had
> some packages converted and tested.  Would you mind commiting at least
> the Debian Med packages to VCS.  I'll notice the commits and will check
> and upload.  If you have reasons not to push your changes just let me
> know and I'll work down the list of packages on my todo list.  I just
> want to avoid duplicated work.
> 

Quite a few are probably now out of date (bioconductor release in the
meanwhile), but yes, I can push some updates once I'm able to verify the
builds without needing to inject a local copy of dh-r.

Gordon

[ftpmas...@ftp-master.debian.org: dh-r_20160916_amd64.changes ACCEPTED into unstable, unstable]

[Andreas Tille]

Hi Gordon,

good news that dh-r was accepted.  You previously wrote that you had
some packages converted and tested.  Would you mind commiting at least
the Debian Med packages to VCS.  I'll notice the commits and will check
and upload.  If you have reasons not to push your changes just let me
know and I'll work down the list of packages on my todo list.  I just
want to avoid duplicated work.

Thanks for all your work

Andreas.

- Forwarded message from Debian FTP Masters 
 -

Date: Tue, 25 Oct 2016 12:00:11 +
From: Debian FTP Masters 
To: Gordon Ball , Debian Science Maintainers 
, ti...@debian.org
Subject: dh-r_20160916_amd64.changes ACCEPTED into unstable, unstable



Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 16 Sep 2016 11:25:42 +0200
Source: dh-r
Binary: dh-r
Architecture: source all
Version: 20160916
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 

Changed-By: Gordon Ball 
Description:
 dh-r   - Debian helper tools for packaging R libraries
Closes: 837953
Changes:
 dh-r (20160916) unstable; urgency=medium
 .
   * Initial release (closes: #837953)
Checksums-Sha1:
 98e34f852754a3131092d96b50920358e0cac1d9 1608 dh-r_20160916.dsc
 7b7abdbc964305ee26a0be6eb15bbdba086260c1 7236 dh-r_20160916.tar.xz
 1cba602cfff68f9818d6a276f7d46475e387423d 7378 dh-r_20160916_all.deb
Checksums-Sha256:
 047a40ac40df9c3b67bd524ef28fcce6bc50d76193179b54798b71e7556e3f13 1608 
dh-r_20160916.dsc
 9ee38f93466b4b21105e1460a3f3bb5c49a8d99749f04c64b2220877cbf2f1ae 7236 
dh-r_20160916.tar.xz
 8285ad3d1e077260f4aad40c35a9f7a4b94df4dc6612f0916d72dd18fcfe35b5 7378 
dh-r_20160916_all.deb
Files:
 a267d7f9e01d1047929b7185fb590fe3 1608 science optional dh-r_20160916.dsc
 e57e8213807267caa9c9f9be64199907 7236 science optional dh-r_20160916.tar.xz
 17246b479606569a3768be016783f0aa 7378 science optional dh-r_20160916_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJX28B0AAoJEFeKBJTRxkbRfM8P/j37GwXaSsiv8rsF1hDJRWMo
nzVtKLskY6HTOTLIKFSU5wY+cnUPg6SU18muDv2EQ2C6mSI9q1mMZu8F2xy23Toz
0gbv5J/BXwuAcTq7aFwHLnlYoeJtL0nswbRWcQpFxNP3gjsYsZ2amID9PP4uZike
uGBKaAR/03OR0pBbuJLEzFZvZPvfJRlmUQvpjnFOvHTd78E8za7MVttVVTn/O31t
GghEp5Zy9lIMc9y1twsDe0qHoqyCN7W81AUNnN3vjREj6e7JYDAcUAYpwjQazOeW
GzSB20ctWJxCadWfZ/cAQ5vfIRM7EKOxPjyfnznX9u599zSEPlkvg66oOSpUQ6oS
nz9mLAduw3FW3sE5MrZfgrFUtXKMjlbcPyvJSedFgo/M4HkicC+S605T+bGZH7pu
1cP8f8WhFodTPXwMs08G5E5wtBHHzq8WqtpwfdBYY9UwYx9ULA6S7n6U2AisL1d1
EcOUWUVHdB62QOfs2zY6JGRTIYmRredzaU/b4WFc8GOMLZyjgrPdEvpis69YYcKu
tJlVK9qlJo8OSWGJmXp/5WNtqUyiD6V53hPXuAMNy318hVNZapm1tdJQzLYxOkvx
sZY6mybbiGHFAHckyHzpA700aSUDzga3Oy1Y0mRVpUS8ittCyGUXvckhOgtOVAHk
XSZmB4iUqCy2AykODGiK
=djMB
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

-- 
debian-science-maintainers mailing list
debian-science-maintain...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


- End forwarded message -

-- 
http://fam-tille.de

Re: Debhelper for R packages (accepted)

[Gordon Ball]

On 08/10/16 20:57, Dirk Eddelbuettel wrote:
> 
> On 8 October 2016 at 20:01, Joost van Baal-Ilić wrote:
> | I couldn't agree more.  I'm a cdbs fan, and some of my packages I maintain 
> with
> | neither cdbs nor dh.  So I was _very_ happy to find out cdbs was the tool 
> used
> | by many r-cran packages, when I started packaging r-cran stuff.  Don't get 
> me
> | wrong: I am happy we now can use dh to build r-cran packages: more choice is
> | always welcome.  So: thanks a lot Gordon and Dylan for your work.  I however
> | won't immediately start converting my r-cran packages from cdbs to dh-r.
> 
> Spot on, and agreed. Andreas et al did well with the updates to r-cran.mk,
> and the cdbs approach is serving us well -- but needs an update. dh-r may fit
> that bill.
> 

dh-r was accepted to unstable today. You are of course free to use it,
or not, as you see fit.

Gordon

Re: HDF5 1.10 transition?

[Jerome Kieffer]

On Tue, 25 Oct 2016 08:13:43 +0100
Ghislain Vaillant  wrote:

> 
> What about h5py ? Have you tried it with hdf5 v1.10 ?
> 

There are many things going around pytables, h5py and hdf5:

* h5py (2.6) supports the new features of hdf5 1.10 (SWMR mainly)

* pytable is useful but no more heavily developed. It has been agreed
  with the dev of h5py to make pytable depend on h5py to have only 1
  wrapper for hdf5 in python and pytables will just offer a different API.

This said, I don't know how advanced this migation.

Cheers

-- 
Jérôme Kieffer
tel +33 476 882 445

Fwd: Re: HDF5 1.10 transition?

[Gilles Filippini]

[forgot to CC the list]

 Original Message 
Subject: Re: HDF5 1.10 transition?
Date: 2016-10-25 09:33
From: Gilles Filippini 
To: Ghislain Vaillant 

On 2016-10-25 09:13, Ghislain Vaillant wrote:

Le 25 oct. 2016 8:37 AM, "Sebastiaan Couwenberg" 
a écrit :


On 10/24/2016 11:54 PM, Gilles Filippini wrote:
> I'm about to request a transition slot for HDF5 1.10 in a couple

of

> days, but I'm concerned about pytables which doesn't support HDF5

1.10

> at all [1].
>
> [1] https://github.com/PyTables/PyTables/issues/545 [1]
>
> This package seems rather widely used, with a popcon > 3000. What

do you

> think should be done?
> * leave Stretch with HDF5 1.8.16 (don not transition)
> * transition and break pytables
> * transition and temporarily ship pytables with an embedded hdf5

1.8.16

> source tree
> * ...
>
> Thanks in advance for any feedback,

Ideally #545 leads to upstream adding support for HDF5 1.10,
alternatively perhaps the Debian community can contribute that

support.


In case support for HDF5 1.10 isn't available before the transition,
embedding HDF5 1.8.16 seems like a reasonable alternative, although
highly undesirable.

Breaking pytables may help motivate affected parties to work on HDF5
1.10 support, but risks removal of a substantial reverse dependency
chain from stretch. Also highly undesirable.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


What about h5py ? Have you tried it with hdf5 v1.10 ?


It builds fine. But I haven't tested the resulting package.

Thanks,

_g.

Re: HDF5 1.10 transition?

[Ghislain Vaillant]

Le 25 oct. 2016 8:37 AM, "Sebastiaan Couwenberg"  a
écrit :
>
> On 10/24/2016 11:54 PM, Gilles Filippini wrote:
> > I'm about to request a transition slot for HDF5 1.10 in a couple of
> > days, but I'm concerned about pytables which doesn't support HDF5 1.10
> > at all [1].
> >
> > [1] https://github.com/PyTables/PyTables/issues/545
> >
> > This package seems rather widely used, with a popcon > 3000. What do you
> > think should be done?
> > * leave Stretch with HDF5 1.8.16 (don not transition)
> > * transition and break pytables
> > * transition and temporarily ship pytables with an embedded hdf5 1.8.16
> > source tree
> > * ...
> >
> > Thanks in advance for any feedback,
>
> Ideally #545 leads to upstream adding support for HDF5 1.10,
> alternatively perhaps the Debian community can contribute that support.
>
> In case support for HDF5 1.10 isn't available before the transition,
> embedding HDF5 1.8.16 seems like a reasonable alternative, although
> highly undesirable.
>
> Breaking pytables may help motivate affected parties to work on HDF5
> 1.10 support, but risks removal of a substantial reverse dependency
> chain from stretch. Also highly undesirable.
>
> Kind Regards,
>
> Bas
>
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

What about h5py ? Have you tried it with hdf5 v1.10 ?

Ghis

Re: new libgtkdatabox release

[Petter Reinholdtsen]

Thank you for the heads up.

[Andreas Tille]
>> Petter Reinholdsten, who maintains the Debian xoscope package, has
>> indicated that a freeze is coming up.  I'd like to get the new
>> version of libgtkdatabox in under the wire, if possible.

Note, I do not maintain it, I just decided to help the maintainer and do
some non-maintainer uploads to get it into shape before the next Debian
release while the maintatainer was busy.

> New package version uploaded, but needs to pass new queue due to name
> change of binary packages.

I suspect a binary NMU might be enough to fix xoscope once the new
libgtkdatabox is in the archive.

Cc to Bhavani, the xoscope maintainer.

-- 
Happy hacking
Petter Reinholdtsen

Re: HDF5 1.10 transition?

[Sebastiaan Couwenberg]

On 10/24/2016 11:54 PM, Gilles Filippini wrote:
> I'm about to request a transition slot for HDF5 1.10 in a couple of
> days, but I'm concerned about pytables which doesn't support HDF5 1.10
> at all [1].
> 
> [1] https://github.com/PyTables/PyTables/issues/545
> 
> This package seems rather widely used, with a popcon > 3000. What do you
> think should be done?
> * leave Stretch with HDF5 1.8.16 (don not transition)
> * transition and break pytables
> * transition and temporarily ship pytables with an embedded hdf5 1.8.16
> source tree
> * ...
> 
> Thanks in advance for any feedback,

Ideally #545 leads to upstream adding support for HDF5 1.10,
alternatively perhaps the Debian community can contribute that support.

In case support for HDF5 1.10 isn't available before the transition,
embedding HDF5 1.8.16 seems like a reasonable alternative, although
highly undesirable.

Breaking pytables may help motivate affected parties to work on HDF5
1.10 support, but risks removal of a substantial reverse dependency
chain from stretch. Also highly undesirable.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature