Bug#995829: ITP: itk5 -- extensive suite of software tools for image analysis

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Vaillant 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org

* Package name: itk5
  Version : 5.2.1
  Upstream Author : NumFOCUS
* URL : https://itk.org
* License : Apache-2.0
  Programming Lang: C++, Python
  Description : extensive suite of software tools for image analysis

This package is a core dependency for a large array of medical packages.

This package will be maintained by the Debian Med Packaging Team.

Bug#892758: ITP: python-bsdf -- Python implementation of the Binary Structured Data Format

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Vaillant 

* Package name: python-bsdf
  Version : 2.1.1
  Upstream Author : Almar Klein
* URL : http://bsdf.io/
* License : BSD
  Programming Lang: Python
  Description : Python implementation of the Binary Structured Data Format

Long-Description:
 The Binary Structured Data Format (BSDF) is an open specification for
 serializing (scientific) data, for the purpose of storage and (inter
 process) communication.
 .
 It's designed to be a simple format, making it easy to implement in
 many programming languages. However, the format allows implementations
 to support powerful mechanics such as lazy loading of binary data, and
 streamed reading/writing.
 .
 BSDF is a binary format; by giving up on human readability, BSDF can be
 simple, compact and fast. See the full specification, or how it
 compares to other formats.

This library is a new dependency for src:python-imageio. It will be
maintained by the Debian Science Team.

Re: Bug#892495: ITP: python3-aiohttp-swagger -- Swagger API Documentation builder for aiohttp server

[Ghislain Vaillant]

Le samedi 10 mars 2018 à 16:24 +, Joel Cross a écrit :
> > s/python3-aiohttp-swagger/python-aiohttp-swagger
> > 
> > for the name of the *source* package.
> > 
> > The python3- prefix is for the name of the *binary* package
> > targetting
> > the Python 3 interpreter.
> 
> Oops, my apologies. I think 'aiohttp-swagger' would be the more
> appropriate name, do you agree? I will then use 'python3-aiohttp-
> swagger' as the binary package name (since the package will only be
> targeting Python 3).

It's up to you.

Tradiotionally, `python-foo` was used for Python libs and simply `foo`
for Python apps. Nowadays, people tend to stick to the upstream name,
unless it is too generic (for instance python-schema).

> > > I am interested in packaging a project that depends on this
> > > library,
> > > hence why
> > > I am packaging this library.
> > 
> > What's this project? Have you filed an ITP for it yet?
> 
> The other project is one that has not yet been released under an
> open-source license, although I have it on good authority that it
> will be over the coming months. Sorry I can't tell you much more or
> file at ITP at present, but I will do as soon as I can.

Okay, then good luck with the packaging. I'd advise you to join and
maintain the package under the Debian Python Modules Team.

Ghis

Re: Bug#892495: ITP: python3-aiohttp-swagger -- Swagger API Documentation builder for aiohttp server

[Ghislain Vaillant]

Le vendredi 09 mars 2018 à 17:27 +, Joel Cross a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Joel Cross 
> 
> * Package name: python3-aiohttp-swagger

s/python3-aiohttp-swagger/aiohttp-swagger

or

s/python3-aiohttp-swagger/python-aiohttp-swagger

for the name of the *source* package.

The python3- prefix is for the name of the *binary* package targetting
the Python 3 interpreter.

>   Version : 1.0.5
>   Upstream Author : Daniel Garcia 
> * URL : https://github.com/cr0hn/aiohttp-swagger
> * License : BSD
>   Programming Lang: Python
>   Description : Swagger API Documentation builder for aiohttp
> server
> 
> aiohttp-swagger is a plugin for aiohttp.web server that allows an API
> developer
> to document APIs using Swagger and the Swagger-ui console.
> 
> I am interested in packaging a project that depends on this library,
> hence why
> I am packaging this library.

What's this project? Have you filed an ITP for it yet?

Cheers,
Ghis

Re: Bug#892386: ITP: python3-pgzero -- pygame zero, environment for zero-boilerplate programming of 2D games.

[Ghislain Vaillant]

Le jeudi 08 mars 2018 à 17:26 +, plugwash a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: plugwash 
> 
> * Package name: python3-pgzero

Please consider using the name "pgzero" or "python-pgzero" for the
source package.

The binary packages may get a different prefix based on the targeted
interpreter (python3- for CPython, pypy- for PyPy...).

>   Version : 1.2.post1
>   Upstream Author : Daniel Pope 
> * URL : https://bitbucket.org/lordmauve/pgzero
> * License : LGPLv3
>   Programming Lang: python3

Programming Lang: python

>   Description : pygame zero, environment for zero-boilerplate
> programming of 2D games.

Description: environment for zero-boilerplate programming of 2D games

> Pygame zero provides an environment in which 2D games can be
> developed in
> python without the need for boilerplate code or complex APIs.
> 
> It is intended for use in education, so that teachers can teach basic
> programming without needing to explain the Pygame API or write an
> event loop.

Sounds very interesting. Thanks for working on this package.

Do you intend to get the package team-maintained under the Debian Games
umbrella? Sounds like a good fit.

Ghis

Re: What can Debian do to provide complex applications to its users?

[Ghislain Vaillant]

Le vendredi 16 février 2018 à 16:11 +0100, Raphael Hertzog a écrit :
> Hello everybody,
> 
> the fact that I had to request the removal of dolibarr from Debian
> makes
> me sad (see below for the reasons) and I believe that we should be
> able
> to do better to provide complex applications to our end users.

I feel your pain too and agree with your assessment.

> Dolibarr is not alone:
> 
> - while gitlab is packaged in Debian, its packaging took years and
> the
>   result is brittle because it can break in many ways whenever one
> the 
>   dozens of dependencies gets updated to some new upstream version
>   (BTW salsa.debian.org does not use the official package)
> 
> - I have the Debian packaging of distro-tracker (the code behind
>   tracker.debian.org) available in the git repository for years
>   but I never released it into Debian because it embeds a few
> javascript
>   libraries (bootstrap, jquery) and I don't want to validate that
>   it does work with the versions currently in Debian
> 
> I'm sure we are missing lots of good applications due to our
> requirements.
> What can we do to avoid this?

The problem also comes from the disconnect between current software
development practices: relying on libraries pinned to a specific
version, or with unstable APIs, or vendored to the code base, and the
ideal proned by Debian: a centralized repository of dependencies which
all applications should be built with.

The situation is particularly visible with the Javascript ecosystem,
but similar problems are appearing in the Python and Ruby world. 

> I don't have any definite answers although there are ideas to
> explore:
> 
> - we could relax our requirements and have a way to document the
>   limitations of those packages (wrt our usual policies)

In particular for non-compiled libraries kept private to the
application. These should represent a lower threat vector than say,
multiple vendored copies of openssl or zlib.

> - we could ship those applications not as .deb but as container
>   and let them have their own lifecycle

Not sure what you mean, but I trust you on that.

> What do you think? Do you have other ideas? Are there other persons
> who are annoyed by the current situation?

Or do our best to support alternative means of installing software such
as docker, snap or flatpak.   

> Cheers,
> 
> On Fri, 16 Feb 2018, Raphaël Hertzog wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > 
> > I'm the usual sponsor of dolibarr in Debian. The maintainer (and
> > upstream author) Eldy Destailleur announced me a few weeks ago that
> > he
> > will no longer be maintaining Dolibarr within Debian because it was
> > too much of a pain to respect all the Debian requirements.
> > 
> > He explained to me that Dolibarr relies on 15 javascripts libraries
> > (some of them
> > are dependencies of the libraries that Dolibarr are using in the
> > first
> > place) and 5 PHP libraries.
> > 
> > Debian's requirement to provide a non-minified copy of the
> > javascript is
> > really hard to meet for him because often the projects are only
> > providing
> > the sources under the form a github link (and not under the form of
> > a non-minified javascript that we could put next to the minified
> > file to
> > please lintian). He would have to spend a lot of times with the
> > different
> > upstreams to get them to provide the non-minified file in a form
> > that is
> > suitable for Debian. It's even likely that his requests would be
> > dismissed
> > by multiple upstream authors leaving him in the inconvenient
> > position of
> > having to remove features to be able to ship a policy-compliant
> > Debian
> > package.
> > 
> > The requirement to use packaged versions of all the libraries is
> > also
> > problematic. More often that not the version used by Dolibarr will
> > not
> > match the version currently available in Debian and it's always a
> > risk
> > to use a different version. Sometimes it will work just fine,
> > sometimes it
> > will break.
> > 
> > Given all those constraints, he decided to stop trying to maintain
> > Dolibarr in Debian and the Dolibarr project will only provide an
> > unofficial .deb embedding all the libraries that they need.
> > 
> > I doubt anyone else is willing to maintain Dolibarr in Debian and
> > I'm
> > thus requesting the package to be removed. Users are better served
> > by the upstream unofficial package rather than by Debian's outdated
> > package (it's outdated due to the difficulty of updating it in a
> > policy-compliant way).
> > 
> > I would hope that we could find a way to get the best of both
> > worlds
> > but right now it seems that we don't have a good solution for that
> > kind
> > of web application.
> > 
> > Thank you.
> > 
> 
> 

Re: Bug#890523: ITP: python3-anosql -- A Python library for using SQL

[Ghislain Vaillant]

Le jeudi 15 février 2018 à 10:05 -0500, Florian Grignon a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Florian Grignon 
> 
> * Package name: python3-anosql

s/python3-anosql/python-anosql

The name for the source package should use the python- prefix as in
Python the language. The python3- prefix is intended for the binary
package providing the modules for the Python 3 interpreter.

>   Version : 0.2.0
>   Upstream Author : Honza Pokorny 
> * URL : https://github.com/honza/anosql
> * License : BSD
>   Programming Lang: Python
>   Description : A Python library for using SQL
> 
> A Python library for using SQL.
> Inspired by the excellent Yesql library by Kris Jenkins. In my mother
> tongue, ano means yes.
> 
> This Python library is becoming popular amoung the Python community
> working with PostgreSQL and SQLite. This library has currently
> (15/02/2018) 66 stars github, and is referenced in some books (like
> MasteringPostgreSQL from Dimitry Fontaine). The library is simple and
> small. It is tested on Travis CI, and has a github repository
> https://github.com/honza/anosql.
> 
> I am an experienced Python web developper, and I use this library in
> small personnal project, alongside Flask and psycopg2. This is, from
> these three libraries the only one I'm packaging myself with the
> pybuild
> buildsystem. I took example on the Flask packaging system and it
> works
> like a charm out of the box.
> 
> This library is a very small library that helps Python project to use
> raw SQL queries. This can be seen as a competitor of ORM. And as
> performance becomes more and more important with the size of a Python
> project, the need to use raw SQL instead of ORM becomes inevitable.
> Raw SQL queries also gives much more flexibility and features to the
> developper compared to the ORM.
> 
> This library doesn't have any dependencies. It can be used alongside
> psycopg2 for PostgreSQL or sqlite for SQLite databases engine.
> 
> As a full-time computer scientist, I have time to create and maintain
> it
> on my professionnal and personnal time. I will search for a sponsor
> to
> guide me through the steps of creating and maintaining a debian
> packaging.
> 
> I'd like to include the package, in a second time, to the Debian
> Python
> Module Team, and include myself to the team.

Thank you for the comprehensive description and personal motivation.

You did not mention why this package needs to be packaged though (as
opposed to being installed via pip). Is it required by another package
(or upcoming update of) currently in the archive?

Cheers,
Ghis

Re: Re: Bug#882803: ITP: python3-precis-i18n -- internationalized usernames and passwords

[Ghislain Vaillant]

Quoting Ghislain Vaillant :

s/python3-precis-i18n/python-precis-i18n

Unless this source package is Python 3 specific, please consider
renaming the source package to python-precis-i18n, or just

precis-i18n. The "python3-" prefix is for binary packages built
for the Python 3 interpreter. Unless the DPMT policy has changed
since. 


OK, will do. The minimal supported Python version is 3.3 btw. No 2.7.
The current policy discourages providing Python 2 binary packages for 
new source packages anyway.


There are other interpreters than Python 3 however, such as pypy and 
perhaps pypy3 in the future [1].


The "python-" prefix for source packages refers to Python the language.

The "python-", "python3-", "pypy-" prefixes for binary packages 
correspond to the respective target interpreters.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825970

Cheers,
Ghis

Re: Bug#882803: ITP: python3-precis-i18n -- internationalized usernames and passwords

[Ghislain Vaillant]

s/python3-precis-i18n/python-precis-i18n

Unless this source package is Python 3 specific, please consider 
renaming the source package to python-precis-i18n, or just precis-i18n. 
The "python3-" prefix is for binary packages built for the Python 3 
interpreter. Unless the DPMT policy has changed since.


Thanks,

Ghis

Re: s/python3-sphinx-intl/sphinx-intl

[Ghislain Vaillant]

On 13/09/17 12:21, Ondrej Novy wrote:
if sphinx-intl is primary application (cli tool, etc.), than binary pkg 
sphinx-intl is better. If it's library/module, than python3-sphinx-intl 
is better.


Based on the description of the project [1], it looks like it is the former.

[1] https://pypi.python.org/pypi/sphinx-intl

Ghis

Re: s/python3-sphinx-intl/sphinx-intl

[Ghislain Vaillant]

On 12/09/17 14:07, Hideki Yamane wrote:

On Mon, 11 Sep 2017 16:48:17 +0100
Ghislain Vaillant  wrote:

Please consider changing the source package name to sphinx-intl. Based
on the description of the source package, it will produce a stand-alone
utility not a Python library.


  Thanks for your comment, I've chosen it since sphinx as python3-sphinx
  package. Is sphinx-intl better?


The python3- prefix is for binary packages only (alongside python- and 
pypy-).


Should you decide to use a prefix for the source package name, it should 
be python-, not python3-. Since sphinx-intl is intended to be used as a 
utility, not a library, I suggested you to just name the source package 
sphinx-intl and the corresponding binary packages sphinx-intl / 
sphinx-intl-doc.


Ghis

s/python3-sphinx-intl/sphinx-intl

[Ghislain Vaillant]

Please consider changing the source package name to sphinx-intl. Based 
on the description of the source package, it will produce a stand-alone 
utility not a Python library.


Cheers,
Ghis

Re: Too many Recommends (in particular on mail-transport-agent)

[Ghislain Vaillant]

On Tue, 2017-06-06 at 00:14 -0400, Afif Elghraoui wrote:
> I see now that python-networkx has some integration with those
> visualization libraries [1], which is not what I expected to be the
> case, though the page also says:
> 
> ~~~
> NetworkX provides basic functionality for visualizing graphs, but its
> main goal is to enable graph analysis rather than perform graph
> visualization. In the future, graph visualization functionality may be
> removed from NetworkX or only available as an add-on package.
> ~~~
> 
> so I guess until that integration is removed, it makes sense to keep it
> as Recommends. My main problem remains, however, and it is that networkx
> brings in a graphics stack when you try to install pbhoney on a headless
> machine, like cluster compute nodes.

Given this is a Python package, we should not even have to argue about
package relationships. Setuptools metadata provides install_requires
and extras_require, the former mapping to Depends, the latter to
Suggests. Period.

Your typical Python project README would instruct users to install the
Python package via `pip install`. If one runs `pip install networkx`,
the graphics dependencies do not get pulled. That alone is enough to
justify that these dependencies should not go to Recommends.

FYI, I have a similar problem with sympy (#861741), which pulls an
insane amount of packages via chained Recommends.

Ghis

Re: Too many Recommends (in particular on mail-transport-agent)

[Ghislain Vaillant]

On Wed, 2017-05-31 at 14:41 -0400, Nicholas D Steeves wrote:
> On 31 May 2017 at 13:53, Adam Borowski  wrote:
> > On Wed, May 31, 2017 at 11:31:43AM +0100, Simon McVittie wrote:
> > > On Wed, 31 May 2017 at 11:32:29 +1200, Ben Caradoc-Davies wrote:
> > > > Trust is not transitive. Perhaps Recommends should not be either?
> > > 
> > > Recommends are for the relationship "wanting foo but not bar is unusual".
> > > If A Recommends B and B Recommends C, and if we assume for example
> > > that "unusual" means 10% of users of A do not need B and 10% of users
> > > of B do not need C, then installing Recommends means somewhere
> > > between 0% and 20% of users of A get C unnecessarily. (The real figure
> > > depends on whether not wanting B and not wanting C are positively or
> > > negatively correlated, or independent.)
> > 
> > That's true.
> > 
> > I'd say the biggest problem is maintainers having an emotional attachment to
> > their packages and thus overestimating their importance.
> > 
> > A random example (not meant to single out its maintainer):
> > libuuid1 (transitively essential) Recommends: uuid-runtime.
> > The latter is, as far as I understand, needed only if you generate a massive
> > number of uuids per seconds.  Packages that actually need so (like ceph)
> > actually Depend: uuid-runtime already.  The rest -- those which need a
> > single uuid per mkfs or so, are perfectly fine without that daemon.
> > 
> > Thus, axing this dependency or degrading it to Suggests would be probably a
> > good idea.  And there's hundreds if not thousands of Recommends of this kind
> > that need to be looked at -- this example is just more prominent as it
> > affects every Debian system.
> > 
> > (I'm not filing bugs yet as it's better to have a consensus first before
> > mass-filing.)
> > 
> 
> With the exception of maintaining Recommends for mail-transport-agent
> for packages where emailed warnings are highly desirable (there might
> be others besides smartd and mdadm), I agree that there are many cases
> were Recommends can be downgraded to Suggests.  My pet peeve is
> unnecessary Recommends on texlive packages, but it's easy enough to
> type "NO" and then install with --no-install-recommends...but if you
> mass-file "please degrade Recommends to Suggests" I hope it will be
> for a few of those :-)

+1 on the texlive packages.

Considering their definitions in d-policy:

```
Recommends:

This declares a strong, but not absolute, dependency. The Recommends
field should list packages that would be found together with this one
in all but unusual installations.

Suggests:

This is used to declare that one package may be more useful with one or
more others. Using this field tells the packaging system and the user
that the listed packages are related to this one and can perhaps
enhance its usefulness, but that installing this one without them is
perfectly reasonable.
```

I fail to understand how -doc packages can qualify for anything else
but Suggests.

Ghis

Re: Bug#863605: ITP: python-pyserial -- serial port access library in Python

[Ghislain Vaillant]

On Mon, 2017-05-29 at 10:32 +0200, Julien Cristau wrote:
> On 05/29/2017 10:22 AM, Ghislain Antony Vaillant wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Ghislain Antony Vaillant 
> > 
> > * Package name: python-pyserial
> >   Version : 3.3
> >   Upstream Author : Chris Liechti 
> > * URL : https://github.com/pyserial/pyserial
> > * License : BSD
> >   Programming Lang: Python
> >   Description : serial port access library in Python
> > 
> > Long-Description:
> >  This module encapsulates the access for the serial port. It provides
> >  backends for Python running on Windows, OSX, Linux, BSD (possibly any
> >  POSIX compliant system) and IronPython. The module named "serial"
> >  automatically selects the appropriate backend.
> > 
> > This package is a dependency to src:python-pymeasure. It will be
> > co-maintained by the Debian Science Team.
> > 
> 
> Sounds like this duplicates the existing python-serial package.
> 
> Cheers,
> Julien

Correct, thanks for spotting it.

Ghis

Re: Help requested: Packages which FTBFS randomly

[Ghislain Vaillant]

On Mon, 2017-02-20 at 11:45 +0100, Vincent Bernat wrote:
>  ❦ 20 février 2017 10:05 GMT, Jonathan Dowland  :
> 
> > None of the FTBFS problems I've seen in this thread have been because the
> > tests *required* multiple cores, by the way; more so that they were racy
> > or buggy in some other fashion. If uniprocessor buildds are finding these
> > bugs then that's a virtue, IMHO.
> 
> Time is a limited resource and we need to set our priorities. Having
> test suites that work 100% of the time with constrained resources is not
> a goal I find worthy of the time I can spend on Debian. Unfortunately,
> those bugs are popping up as RC and I have the choice between
> downgrading them and appear as a bad player or fix them.

I share the same feelings towards a similar intermittent FTBFS with
src:python-qtpy (#8544936). I admit I have no clue what is going on,
neither does upstream, nor does the reporter (Santiago).

Ghis

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Ghislain Vaillant]

On Fri, 2017-01-13 at 15:57 +0100, Ole Streicher wrote:
> Paul Gevers  writes:
> > I am not sure if you are addressing me or Pirate, but indeed I am
> > working on an implementation similar to what Ubuntu does (see the link
> > above about the details) which will be used as unstable to testing
> > migration blocker. debci is the worker, but all the policy logic will be
> > with britney where it belongs. And of course I try to have a full
> > release cycle to tune it.
> 
> Will there be a way to override this for the maintainer? Otherwise I
> would see the danger that a buggy reverse dependency CI test can prevent
> an important update, for example if the reverse dependency uses a long
> deprecated function that is now removed.
> 
> Best regards
> 
> Ole

I second Ole's concerns here. Strict autorejection would be assuming
that all autopkgtest testsuites are solid, which has not always been
the case in my experience.

Ghis

Re: Converting to dgit

[Ghislain Vaillant]

On Thu, 2017-01-12 at 21:46 +0100, Raphael Hertzog wrote:
> Hi,
> 
> On Fri, 06 Jan 2017, Ghislain Vaillant wrote:
> > > I don't use it often enough to remember all the details either.  I don't 
> > > recall the last time I had to do more than copy/paste a command from the 
> > > man 
> > > page (OK, git-dpm tag I can remember).
> > 
> > Besides, git-dpm usually tells you what command to run next, like:
> > 
> > git-dpm import-new-upstream -> git-dpm rebase-patched -> git-dpm 
> > update-patches
> > 
> > It did not take me much time to adapt to the git-dpm workflow as a
> > result. I should say that I have been a happy git-dpm user so far.
> 
> And I have been a very unhappy user with python-django. If by mistake, you
> use "gbp import-orig" instead of "git-dpm import-new-upstream" then you're
> completely screwed because git-dpm relies on metadata it manually stores
> in debian/.git-dpm, it does not rely on git's history to figure out the
> appropriate data. Same if you change any patch outside with a third party
> tool...

Well, remember that `git-dpm import-new-upstream` only records the new
upstream commit in the .git-dpm metadata and delays the actual import
of the new upstream data until you have a properly rebased patch queue.

This is to be contrasted with `gbp` where you may import the new
upstream and leave the packaging repository in an inconsistent state
(as far as the patch queue is concerned) until someone runs `gbp pq` or
`quilt` to refresh.

Then, no wonder that mixing `gbp import-orig` with git-dpm does not
work. I admire your courage for trying to fixup the git-dpm metadata
manually nonetheless. Same problem if you try to mix `git-dpm cherry-
pick` with `gbp pq import` -> `git cherry-pick` -> `gbp pq export`.

> So I have opened the manual page many times to read about the format of
> that file and tried to fix up the inconsistent meta-data.
> 
> Also it's really painful to use with multiple branches as you can't really
> merge branches together:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801667

This is indeed a limitation. Based on the design of the tool, git-dpm
works on a rather flat git history. Considering the workflow you
described for django, git-dpm is unlikely to ever become suitable.

> It produces a very verbose git history as soon as you have a significant
> number of patches, even if most of them do not change at all across a
> minor upstream release.

Is that such a bad thing though, I wonder? Given that the price for it
is a guaranteed consistent patch queue.

> Also it's effectively orphaned, nobody is taking care of bugs.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801666
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801548
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795694

So was pristine-tar for a long time and people kept using it
nonetheless.

I also commented in #801666, so I am aware of your issues with git-dpm. 
I agree that integration with existing gbp configuration would be a
plus and help support arbitrary repository layouts, such as those
recommended in DEP-14.

I don't necessarily disagree with you, as I keep using both gbp and
git-dpm in a complementary way. I just wanted to contrast the perceived
hate towards git-dpm in this thread with some positive feedback.

Cheers,
Ghis

Re: Converting to dgit

[Ghislain Vaillant]

On Fri, 2017-01-06 at 00:41 -0500, Scott Kitterman wrote:
> On Friday, January 06, 2017 12:29:54 AM IOhannes m zmölnig wrote:
> > On 01/04/2017 05:42 AM, Colin Watson wrote:
> > > git-dpm does too, and I agree it's nice.
> > 
> > here's an opposite data point:
> > 
> > being forced to use git-dpm by the python-modules-team policy - i
> > haven't had a single joyful experience with git-dpm.
> > so far, every import of a new upstream release turned into a nightmare
> > with an extra working clone of the repository, and skimming through the
> > same man- and webpages full of outdated documentation even though i'm
> > pretty sure that the required information was there the last time i looked.
> > 
> > git-dpm might be useful if you use it daily.
> > as it stands, i'm a very happy gbp user (without fancy addons) for
> > almost all of my packages, and the few python modules i maintain don't
> > do releases that often (which explains why i don't get a routine for
> > doing new upstream imports with git-dpm).
> 
> I don't use it often enough to remember all the details either.  I don't 
> recall the last time I had to do more than copy/paste a command from the man 
> page (OK, git-dpm tag I can remember).

Besides, git-dpm usually tells you what command to run next, like:

git-dpm import-new-upstream -> git-dpm rebase-patched -> git-dpm update-patches

It did not take me much time to adapt to the git-dpm workflow as a
result. I should say that I have been a happy git-dpm user so far.

Ghis

Re: Bug#849050: ITP: python-graphviz -- Simple Python 3 interface for Graphviz

[Ghislain Vaillant]

>> Package: wnpp
>> Severity: wishlist
>> Owner: Diane Trout 
>> 
>> * Package name: python-graphviz
>>   Version : 0.5.2
>>   Upstream Author : Sebastian Bank
>> * URL : https://github.com/xflr6/graphviz
>> * License : Expat
>>   Programming Lang: Python
>>   Description : Simple Python 3 interface for Graphviz
>
> This naming would be unacceptable. Python 3 package should be named
> as "python3-foobar", not "python-foobar".

I completely disagree, "python-graphviz" is the appropriate name for
the source package.

It would produce a python3-graphviz binary package for the Python 3
build and a python-graphivz-doc for the documentation package.  

> There are already packages called "python{,3}-pygraphviz" and you may
> want to take a look.

There are different Python packages for graphviz [1]. Diane already had
a look at it I believe.

[1] https://pypi.python.org/pypi?%3Aaction=search&term=graphviz&submit=
search

Ghis

Help with watch file

[Ghislain Vaillant]

Dear all,

I am trying to write a watch file suitable for fetching tarballs from a
*link* published on a GitHub release page [1]. It seems this link
points to a different location on Amazon S3 [2].

[1] https://github.com/arrayfire/arrayfire/releases
[2] http://arrayfire.s3.amazonaws.com/index.html#!/arrayfire_source%2F

Could you guys assist me with this? My watchcraft is not particularly
good I must admit.

Cheers,
Ghis

Bug#821008: ITP: pyfr -- flux reconstruction in Python

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: pyfr
  Version : 1.3.0
  Upstream Author : Imperial College London
* URL : http://www.pyfr.org/
* License : BSD
  Programming Lang: Python
  Description : flux reconstruction in Python

Long-Description
 PyFR is an open-source Python based framework for solving 
advection-diffusion

 type problems on streaming architectures using the Flux Reconstruction
 approach of Huynh. The framework is designed to solve a range of governing
 systems on mixed unstructured grids containing various element types. 
It is
 also designed to target a range of hardware platforms via use of an 
in-built

 domain specific language derived from the Mako templating engine.

This package will be co-maintained by the Debian Science Team.

Bug#818983: ITP: ciftilib -- library for reading and writing CIFTI files

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org
Owner: Ghislain Antony Vaillant 

* Package name: ciftilib
  Version : 1.3
  Upstream Author : Washington University School of Medicine
* URL : https://github.com/Washington-University/CiftiLib
* License : BSD
  Programming Lang: C++
  Description : library for reading and writing CIFTI files

Long-Description:
 CIFTI (Connectivity Informatics Technology Initiative) standardizes
 file formats for the storage of connectivity data. These formats are
 developed by the Human Connectome Project and other interested parties.
 .
 CiftiLib is a C++ library for reading and writing CIFTI-2 files. It
 additionally supports CIFTI-1 files, for both on-disk and in-memory
 access. It also provides C++ code for reading and writing generic
 NIfTI-1 and NIfTI-2 files.

This package will be maintained by the Debian Med Team.

RFP: elusive-icons -- the iconic font and CSS framework

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist

* Package name: elusive-icons
  Version : 2.0.0
  Upstream Author : The Redux Team
* URL : http://elusiveicons.com/
* License : SIL OFL 1.1, Expat
  Programming Lang: Text + CSS
  Description : the iconic font and CSS framework

Long-Description:
 Elusive Icons is a full suite of 304 pictographic icons for easy scalable
 vector graphics on websites, created and maintained by Team Redux.

Rationales:
 The fonts provided by this source package are required for the
 python-qtawesome source package, which currently uses an embedded copy.

ITP: python-hdf5storage -- high-level utilities to read from and write to HDF5

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: python-hdf5storage
  Version : 0.1.12
  Upstream Author : Freja Nordsiek
* URL : https://github.com/frejanordsiek/hdf5storage
* License : BSD
  Programming Lang: Python
  Description : high-level utilities to read from and write to HDF5

This package uses h5py as a driver to provide a higher-level API to
interact with files saved in HDF5 format, including MATLAB v7.3. The
package will be co-maintained by the Debian Science Team, where h5py
currently resides.

ITP: python-qtpy -- abtraction layer for PySide/PyQt4/PyQt5

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: python-qtpy
  Version : 1.0b1
  Upstream Author : Gonzalo Peña-Castellanos
* URL : https://github.com/spyder-ide/qtpy
* License : Expat
  Programming Lang: Python
  Description : abtraction layer for PySide/PyQt4/PyQt5

This package will become a build dependency for future releases of the 
Spyder IDE.

ITP: python-qtawesome -- iconic fonts in PyQt and PySide applications

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: python-qtawesome
  Version : 0.2.0
  Upstream Author : The Spyder development team
* URL : https://github.com/spyder-ide/qtawesome
* License : Expat
  Programming Lang: Python
  Description : iconic fonts in PyQt and PySide applications

This package is a build dependency for future releases of the Spyder
IDE.

ITP: opengm -- C++ template library for discrete factor graph models

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: opengm
  Version : 2.0.2
  Upstream Author : The OpenGM Developers 


* URL : http://hci.iwr.uni-heidelberg.de/opengm2/
* License : MIT
  Programming Lang: C++, Python
  Description : C++ template library for discrete factor graph models

OpenGM is a C++ template library for discrete factor graph models and
distributive operations on these models. It includes state-of-the-art
optimization and inference algorithms beyond message passing. OpenGM 
handles large models efficiently, is modular and extendible. The 
graphical model data structure, inference algorithms and different 
encodings of functions inter-operate through well-defined interfaces. 
The binary OpenGM file format is based on the HDF5 standard and 
incorporates user extensions automatically.


This package will be maintained by the Debian Science Team.

Best regards,
Ghis

debian queue demon keeps spawning emails for clblas/2.6-2 upload

[Ghislain Vaillant]

Dear all,

Just to report that d-sicience-maintainers [1] keeps receiving email 
about an upload (clblas/2.6-2) which has been accepted already.


Can anyone who has access have a look and kill whatever process is 
responsible for this.


[1] 
http://lists.alioth.debian.org/pipermail/debian-science-maintainers/2015-August/thread.html


Many thanks,
Ghislain

Re: Packaging ASL

[Ghislain Vaillant]

On 21/07/15 18:17, Zeev Pekar wrote:

[...]


May I ask somebody to volunteer to finish the initial creation of the
package, so it can be uploaded?
It has been developed/tested on Debian since 2010 so the process should
be smooth.
Packaging efforts for other distros are underway and probably can be
helpful for Debian [1].

Thank you,
Zeev
--
In short about the library:
It is an OpenCL-based multiphysics simulation software that can be
deployed (besides CPU) on different massively parallel architectures
like GPUs, FPGAs, DSPs etc. and covers a variety of physical and
chemical phenomena. It can be utilized in a number of fields:

- CFD: http://asl.org.il/benchmarks/multicomponent_flow/
- image-guided surgery: http://avtechscientific.com/cryovision
- crystal growth:
https://github.com/AvtechScientific/ASL/blob/master/examples/levelSet/levelSetFacetedGrowth.cc
- virtual sensing (i.a. medical): http://avtechscientific.com/brainshift
- R&D of biomed devices (i.a. microfluidics):
http://avtechscientific.com/focus
- etc., etc..
--

[1]:
https://aur.archlinux.org/packages/libasl/
https://copr.fedoraproject.org/coprs/lupinix/ASL/
https://build.opensuse.org/package/show/home:ealin:physics/ASL



[...]






I am fairly experienced with packaging CMake-based projects and could
give you a hand on that.

Since the project follows a Git workflow (master branch + tagged
release), it would make sense to adopt a Git approach for the packaging
repository rather than the more conventional import-from-source-tarball
approach that the d-science policy only advocates.

I can see from your original work that you are not quite there yet with
the packaging content, which is what Andreas mentioned in his reply. I
am afraid that the "New maintainers guide" is a mandatory stop, should
you intend to maintain this package long term in Debian. I can only give
you a lift for the initial effort.

Best regards,
Ghislain



Hi Ghislain,

initial effort, i.e. initial package creation is exactly what is needed
- Anton will take over the upload and the maintenance (at least in the
short term).

It was not my intention to maintain ASL in Debian - I take care of it
upstream (I'm one of the developers). I wanted to do my best to initiate
the process. I hope that there will be more people interested in
maintaining the package once it actually enters Debian and Ubuntu (btw.
is there a chance it will get into the Ubuntu 15.10?) and the community
starts to grow.

Thank you very much!
Zeev



From the first look I have had of it, it should not be too complicated 
to put some packaging up to shape. FYI, I filed a bug with regards to a 
missing copyright header caught by licensecheck.


I can't commit to a particular timeline. It will probably take me a few 
commutes to work before getting something decent. As to whether it will 
land in 15.10 or not, that will depend on how quickly the package is 
mentored (via Andreas or Anton maybe?) and eventually processed by the 
release team.


If the package does not land in time for 15.10, you guys can still make 
a PPA available on Launchpad and use backportpackage from the Debian 
source package to generate Ubuntu packages for all versions you guys 
want to support (maybe all the way down to 14.04 LTS, assuming all 
build-deps are in there).


Hope that makes sense.

Cheers,
Ghis


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b0bd46.4070...@gmail.com

Re: Packaging ASL

[Ghislain Vaillant]

On 21/07/15 12:25, Zeev Pekar wrote:

Dear Debian Developers,

I wanted to see ASL - Advanced Simulation Library  as
part of Debian. I contacted an experienced DD who kindly agreed to
upload and maintain it however he didn't have the time to create the
initial package (see his email bellow). I was advised to create it
myself according to this guide:

http://debian-science.alioth.debian.org/debian-science-policy.html

After looking on the doc I decided to give it a try (despite having no
packaging knowledge/experience) and after overcoming some technical
difficulties I managed to make some progress:

ssh://git.debian.org/git/debian-science/packages/asl.git

Later it turned out (see second email) that the doc describes only the
steps specific to Debian Science while there is much more to do/read (->
"New maintainers guide", etc) :-(((
May I ask somebody to volunteer to finish the initial creation of the
package, so it can be uploaded?
It has been developed/tested on Debian since 2010 so the process should
be smooth.
Packaging efforts for other distros are underway and probably can be
helpful for Debian [1].

Thank you,
Zeev
--
In short about the library:
It is an OpenCL-based multiphysics simulation software that can be
deployed (besides CPU) on different massively parallel architectures
like GPUs, FPGAs, DSPs etc. and covers a variety of physical and
chemical phenomena. It can be utilized in a number of fields:

- CFD: http://asl.org.il/benchmarks/multicomponent_flow/
- image-guided surgery: http://avtechscientific.com/cryovision
- crystal growth:
https://github.com/AvtechScientific/ASL/blob/master/examples/levelSet/levelSetFacetedGrowth.cc
- virtual sensing (i.a. medical): http://avtechscientific.com/brainshift
- R&D of biomed devices (i.a. microfluidics):
http://avtechscientific.com/focus
- etc., etc..
--

[1]:
https://aur.archlinux.org/packages/libasl/
https://copr.fedoraproject.org/coprs/lupinix/ASL/
https://build.opensuse.org/package/show/home:ealin:physics/ASL




Hi all,

I talked to Zeev regarding this package and I would upload
it, if its packaging state would fit to our requirements. But
sorry, I do not have time for the moment to package it from
the zero point.

Surely, it would be a nice package for the scientists and
engineers in Debian archive.





On Mon, Jul 13, 2015 at 04:06:53PM +0300, Zeev Pekar wrote:

I uploaded ASL  to:

ssh://git.debian.org/git/debian-science/packages/asl.git


Please, let me know, whether it lacks anything...


It lacks

 debian/changelog
 debian/rules
 debian/compat
 debian/source/format

at minimum.  Also debian/control has some fields differently
as per policy.  Please dive into the several existing examples
of Debian Science packages and the "New maintainers guide".

Kind regards

   Andreas.


--
http://fam-tille.de







I am fairly experienced with packaging CMake-based projects and could 
give you a hand on that.


Since the project follows a Git workflow (master branch + tagged 
release), it would make sense to adopt a Git approach for the packaging 
repository rather than the more conventional import-from-source-tarball 
approach that the d-science policy only advocates.


I can see from your original work that you are not quite there yet with 
the packaging content, which is what Andreas mentioned in his reply. I 
am afraid that the "New maintainers guide" is a mandatory stop, should 
you intend to maintain this package long term in Debian. I can only give 
you a lift for the initial effort.


Best regards,
Ghislain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55ae34f9.4040...@gmail.com

Re: RFS: h5py/2.4.0+dfsg1-1~exp1 -- general-purpose Python interface to hdf5

[Ghislain Vaillant]

I have just added a new entry in the SoB [1].

Cheers,

Ghis

[1] https://wiki.debian.org/DebianPureBlends/SoB

2015-04-01 20:40 GMT+01:00 Ghislain Vaillant :

> Package: sponsorship-requests
> Severity: normal
>
>
> I am looking for a sponsor for the source package "h5py".
>
> It builds the following binary packages:
>
>  python-h5py  -- Python 2 version
>  python3-h5py -- Python 3 version
>
>
> This upload brings the package up to date with the most recent
> stable upstream release.
>
>
> This package can be checked out at:
>  https://anonscm.debian.org/cgit/debian-science/packages/h5py.git
>
> This package can be built with:
>
>  gbp buildpackage --git-debian-branch=debian/experimental \
>  --git-upstream-branch=upstream/latest
>
>
> Changes since the last upload:
>
>   * New upstream release
>   * d/control: lintian fix
>   * d/copyright:
> - lintian fix
> - made dep5 compatible
> - strip residual .DS_Store files in tarball
>   * d/watch:
> - add repack due to file strip
>   * d/patches/*:
> - add 0001-prevent-rpath.patch
> - disable drop-mpiposix.patch
>
> Best regards,
>
> Ghislain
>
>

RFS: h5py/2.4.0+dfsg1-1~exp1 -- general-purpose Python interface to hdf5

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal


I am looking for a sponsor for the source package "h5py".

It builds the following binary packages:

 python-h5py  -- Python 2 version
 python3-h5py -- Python 3 version


This upload brings the package up to date with the most recent
stable upstream release.


This package can be checked out at:
 https://anonscm.debian.org/cgit/debian-science/packages/h5py.git

This package can be built with:

 gbp buildpackage --git-debian-branch=debian/experimental \
 --git-upstream-branch=upstream/latest


Changes since the last upload:

  * New upstream release
  * d/control: lintian fix
  * d/copyright:
- lintian fix
- made dep5 compatible
- strip residual .DS_Store files in tarball
  * d/watch:
- add repack due to file strip
  * d/patches/*:
- add 0001-prevent-rpath.patch
- disable drop-mpiposix.patch

Best regards,

Ghislain

Re: ITP: bitstring -- Python module for manipulation of binary data

[Ghislain Vaillant]

2015-03-30 20:50 GMT+01:00 Adrien Clerc :

>  Le 30/03/2015 20:50, Ghislain Vaillant a écrit :
>
> Package: wnpp
> Severity: wishlist
> Owner: Ghislain Antony Vaillant 
>
> * Package name: bitstring
>   Version : 3.1.3
>   Upstream Author : Scott Griffiths 
> * URL : https://code.google.com/p/python-bitstring/
>
>  If it's a new package, it shouldn't be hosted on Google Code right now.
> Or I'm missing something.
>
> Adrien
>
>

Hi Adrien,

The upstream project is on code.google. Upstream confirmed they will be
moving to Github in the future.
My packaging work is local for now, as I am currently waiting to hear from
the Alioth admins on joining
either Python-Modules or Collab-Maint to have access and host it.

Ghis

ITP: bitstring -- Python module for manipulation of binary data

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: bitstring
  Version : 3.1.3
  Upstream Author : Scott Griffiths 
* URL : https://code.google.com/p/python-bitstring/
* License : MIT
  Programming Lang: Python
  Description : Python module for manipulation of binary data


Long Description


Bitstring is a pure Python module designed to help make the creation and
analysis of binary data as simple and natural as possible.

Bitstrings can be constructed from integers (big and little endian), hex,
octal, binary, strings or files. They can be sliced, joined, reversed,
inserted into, overwritten, etc. with simple functions or slice notation.
They can also be read from, searched and replaced, and navigated in,
similar
to a file or stream.


Reasons for packaging
-

This package brings simple support for arrays of bits, is well documented,
and works very well. It provides similar functionalities to bitarray
(already packaged) but does not require any compiled c-extension.


Due to the nature of this package, it should probably be team-maintained by
the Debian Python Modules Team (DPMT).


Best regards,
Ghislain

ITP: pyzolib -- Utilities for the Pyzo environment

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: pyzolib
  Version : 0.3.3
  Upstream Author : Almar Klein 
* URL : https://bitbucket.org/pyzo/pyzolib
* License : BSD
  Programming Lang: Python
  Description : Utilities for the Pyzo environment

Description
 The pyzolib package provides basic functionality for the Pyzo environment.
 It contains a collection of modules and small packages that should be
 imported as "from pyzolib import xxx"
 .
 The packages currently are:
   * path - object oriented path processing (no more os.path.x)
   * paths - Get paths to useful directories in a cross platform manner.
   * qt - Proxy for importing QtCore et al. from PySide or PyQt4
   * ssdf - the Simple Structured Data Format (for config files and
 scientific databases)
   * insertdocs - a sphynx pre-processor to include docstrings in the text,
 allowing readthedocs.org to host the docs without requiring importing
code.
   * pyximport - for easy on the fly compilation of Cython, using the Pyzo
 environment to establish the location of a gcc compiler.
   * gccutils - used by the above to manage the gcc compiler.
   * interprerers - list the Python interpreters available on this system.
   * dllutils - utilities to set the RPATH in dynamic libararies and
 remove depndencies on the MSVCR from the embedded manifest.

Further information:
 - Pyzolib is a dependency to iep [1],
 - Pyzolib has already been reviewed and packaged in Fedora [2].

I'd suggest to maintain this package as part of the Debian Science
family, together with IEP.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23772820
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1064661

Cheers,
Ghislain

ITP: iep -- Interactive Editor for Python

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: iep
  Version : 3.5
  Upstream Author : Almar Klein 
* URL : http://www.iep-project.org/
* License : BSD
  Programming Lang: Python
  Description : Interactive Editor for Python

Description:
 IEP is a cross-platform Python IDE aimed at interactivity
 and introspection. Its practical design is aimed at
 simplicity and efficiency. IEP consists of an editor, a
 shell, and a set of tools to help the programmer in various
 ways.

Further information:
 - IEP is similar to Spyder but comparatively much lighter,
 - Supports additional features useful for development, like a
   source tree, builtin loggin, cell support...
 - One of the package dependency is not (yet) in Debian: pyzolib,
 - Pyzolib is also licensed under the BSD license.

I believe this package is a good candidate for inclusion to the
Debian science family, via the Sponsorship of Blends initiative [1].

[1] https://wiki.debian.org/DebianPureBlends/SoB

Cheers,
Ghislain

ITP: pyrecord -- Pythonic record types

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant

* Package name  : pyrecord
  Version : 1.0.0~rc1
  Upstream Author   : Gustavo Narea
* URL : https://pythonhosted.org/pyrecord/
* License: Apache-2.0
  Programming Lang: Python
  Description   : Pythonic record types

Long description taken from PyPI:
 A record (aka "struct" in C) is a pre-defined collection
 of values where each is accessed by a unique name. Depending
 on the nature of the data, records may be a superior
 alternative to dictionaries and instances of custom classes.
 .
 PyRecord allows you to use records in Python v2.7 to v3.x and
 PyPy v2, and can be thought of as an improved namedtuple.

Considering the nature of this package, it should probably be
maintained under the Debian Python Team umbrella.

Cheers,
- Ghis

Re: Debian default desktop environment

[Ghislain Vaillant]

On Wed, 2014-04-09 at 12:56 +0100, Ian Jackson wrote:
> Ghislain Vaillant writes ("Re: Debian default desktop environment"):
> > Users do care about visual identity (or call it brand
> > recognition if you like), and currently XFCE in Debian does not have
> > any, I am afraid.
> 
> My experiences with less-sophisticated users are the opposite.  They
> don't give a flying fuck about "brand recognistion" or "visual
> identity".  They don't even seem to care very much about whether it's
> pretty.

Possibly. So many different users, so many opinions. My personal
experience (work colleagues + close relatives, most of them being first
time switchers) is that they do.

> What they care about is being able to easily do whatever they wanted
> to use a computer for.  Mostly, that means that the UI should be
> similar to other systems they're likely to have used (so they don't
> have to learn anything), and it should be easy to find how to do
> things.

Which GNOME 3 classic mode does for me, being used to GNOME 2 before.
That's probably why Red Hat chose it as default to ease the transition
from RHEL 6 to RHEL 7.

I have also tried my best to dig in the GNOME 3 way, and eventually
succeeded with a bit of efforts, but respect and understand people who
cannot get used to it.

My vote would be on GNOME 3 classic for now, but XFCE with sensible and
visually appealing defaults would do it for me too.

Ghislain



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1397127970.22857.18.camel@lat644-lap

Re: Debian default desktop environment

[Ghislain Vaillant]

Just tossing my experience and personal opinion as a Linux user.

On Thu, 2014-08-28 at 14:40 +0100, Kevin Chadwick wrote:
> previously on this list Bálint Réczey contributed:
> 
> > Xfce is friendly enough, but it feels old compared to Gnome 3 and I
> > would like to attract new users before convincing them. It is much
> > easier than in the opposite order. :-)

That was my experience too. At my lab, most of my colleagues who have
looked at XFCE in its default configuration found it unattractive. Sure,
you can customize it (which is what I replied), but they just don't have
the time for that.

> 
> I think you are reflecting a subset of users priorities. I've switched
> users from desktop to desktop and they don't care a jot about
> flashiness 

See my point above. Flashiness no, but visual appeal definitely yes.

> in fact many like simple but pretty which is perfectly
> do-able with almost any window manager, what they hate is 
> 
> a) things moving too much that they can't find
> 
> b) not being able to do what they want or things disappearing
> 
> 
> Looking Flashy is always enticing but not at any functional expense
> and limited performance expense.
> 
> 
> Gnome 3 is getting both a and b wrong.
> 

IMHO, GNOME 3 in *classic mode* get it right. I use it daily and only
got positive comments from other Linux and non-Linux users. FYI, the DE
popularity in my lab is split between Unity (ahead by far), GNOME and
KDE. None of them is running XFCE to my knowledge.

However, I believe XFCE *could* be a good default DE for Debian, but
some efforts need to be made with regards to the default theme and
layout. Users do care about visual identity (or call it brand
recognition if you like), and currently XFCE in Debian does not have
any, I am afraid.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1397037011.3500.16.camel@lat644-lap

packaging of MATLAB files

[Ghislain Vaillant]

Hi everyone,

I am currently working on packaging a scientific project for which MATLAB
wrappers are available. I was wondering where these should be installed in
the file system tree and whether there were particular things to be careful
with. I am talking about pure MATLAB files for now, i.e. only files with .m
extension, no mex files.

Thanks for your help,

Ghis

Bug#732361: ITP: gadgetron -- an open source framework for medical image reconstruction

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Vaillant 

* Package name: gadgetron
  Version : 2.01
  Upstream Author : Michael S. Hansen 
* URL : http://gadgetron.sourceforge.net/
* License : MIT
  Programming Lang: C++
  Description : an open source framework for medical image reconstruction

The Gadgetron is an open source framework for medical image reconstruction. It
has been developed at the National Heart, Lung, and Blood Institute, NIH,
Bethesda, MD, USA and at the Department of Computer Science and Department of
Clinical Medicine, Aarhus University, Denmark. It is made freely available to
the medical image reconstruction community.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131217084719.12948.54718.reportbug@LAT643

Bug#732360: ITP: ismrmrd -- ISMRM Raw Data Format

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Vaillant 

* Package name: ismrmrd
  Version : 2013.20130706
  Upstream Author : Michael S. Hansen 
* URL : http://ismrmrd.sourceforge.net/
* License : MIT
  Programming Lang: C++
  Description : ISMRM Raw Data Format

A prerequisite for sharing magnetic resonance (imaging) reconstruction
algorithms and code is a common raw data format. This standard was developed by
a subcommittee of the ISMRM Sedona 2013 workshop.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131217084107.12676.20058.reportbug@LAT643

Bug#728282: ITP: pynfft -- a Pythonic wrapper around the NFFT library

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Vaillant 

* Package name: pynfft
  Version : 1.1.0
  Upstream Author : Ghislain Vaillant 
* URL : http://pythonhosted.org/pyNFFT/
* License : GPL
  Programming Lang: Python
  Description : a Pythonic wrapper around the NFFT library

pyNFFT is a set of Pythonic wrapper classes around the NFFT library. The aim is
to provide access to the core functionalities of the library using a more
straightforward instantiation through Python classes, while keeping similar
naming conventions to the C-library structures and routines.

The package will be maintained in Debian-Science team.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131030085800.21583.38882.reportbug@LAT643

Bug#728085: ITP: pyfftw -- A pythonic wrapper around FFTW, the FFT library, presenting a unified interface for all the supported transforms.

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Vaillant 

* Package name: pyfftw
  Version : 0.9.2
  Upstream Author : Henry Gomersall 
* URL : http://hgomersall.github.io/pyFFTW/
* License : GPL-3, some windows-specific headers in BSD clause-2 and 3
  Programming Lang: python 
  Description : A pythonic wrapper around FFTW, the FFT library, presenting 
a unified interface for all the supported transforms.

pyFFTW is a pythonic wrapper around FFTW 3, the speedy FFT library. The
ultimate aim is to present a unified interface for all the possible transforms
that FFTW can perform.

Both the complex DFT and the real DFT are supported, as well as on arbitrary
axes of abitrary shaped and strided arrays, which makes it almost feature
equivalent to standard and real FFT functions of numpy.fft (indeed, it supports
the clongdouble dtype which numpy.fft does not).

Wisdom import and export now works fairly reliably.

Operating FFTW in multithreaded mode is supported.

pyFFTW implements the numpy and scipy fft interfaces in order for users to take
advantage of the speed of FFTW with minimal code modifications.

A comprehensive unittest suite can be found with the source on the github
repository or with the source distribution on PyPI.

The documentation can be found on github pages, the source is on github and the
python package index page is here.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131028092412.23785.34977.reportbug@LAT643

Bug#725705: ITP: nfft -- Library for computing the Non-uniform Fast Fourier Transform

[Ghislain Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Vaillant 

* Package name: nfft
  Version : 3.2.3
  Upstream Author : Prof. Dr. Daniel Potts 
* URL : http://www-user.tu-chemnitz.de/~potts/nfft/
* License : GPL
  Programming Lang: C
  Description : Library for computing the Non-uniform Fast Fourier Transform

The NFFT is a C subroutine library for computing the nonequispaced
discrete Fourier transform (NDFT) in one or more dimensions, of
arbitrary input size, and of complex data.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131007150429.14002.13227.reportbug@LAT643