RE:hdfview 2.11 locks SWMR files

[PICCA Frederic-Emmanuel]

Hello Jan,

just as a work around, you can use the silx package which is available as a 
stretch-backports in order to explore your hdf5 file.

cheers

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

Bug#888092: python-fabio: please run the ci with -v

[Picca Frederic-Emmanuel]

Package: python-fabio
Version: 0.5.0+dfsg-2~bpo9+1
Severity: wishlist

Dear Maintainer,

It should be better to add -v after tuen run_tests in order to simplify 
debugging.

thanks

-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-0.bpo.2-amd64 (SMP w/40 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-fabio depends on:
ii  libc6 2.24-11+deb9u1
ii  python2.7.13-2
ii  python-h5py   2.7.0-1
ii  python-lxml   3.7.1-1
ii  python-matplotlib 2.0.0+dfsg1-2
ii  python-numpy [python-numpy-abi9]  1:1.12.1-3
ii  python-pil4.0.0-4
ii  python-qt44.11.4+dfsg-2+b1
ii  python-six1.10.0-3

python-fabio recommends no packages.

Versions of packages python-fabio suggests:
ii  python-fabio-doc  0.5.0+dfsg-2~bpo9+1

-- no debconf information

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

RE:pytables 3.4.2-2 (closes RC bug #881741)

[PICCA Frederic-Emmanuel]

Hello Valentino,

I will have a look at this maybe this week-end.

thanks a lot for your contributions.

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

Bug#853750: hdfview not usable

[PICCA Frederic-Emmanuel]

Just for info and as a work around, in stretch-backports there is the silx 
package which can be used in order to explore the hdf5 files.

the command line is 

silx view.

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

Bug#876739: pyfai FTBFS: help2man: can't get `--help' info from /tmp/check_calib_0hk8odnh

[PICCA Frederic-Emmanuel]

This problem was due to this  

python-fabio (0.5.0+dfsg-2) unstable; urgency=medium

  * d/control
- python-qt4 -> python3-pyqt4-dbg (Closes: #876288)

Now that python-fabio was solved, it is ok to close this bug

thanks

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

Bug#875618: openblas: please enable build on s390x

[PICCA Frederic-Emmanuel]

Hello 

> Unfortunately it does not look that simple. OpenBLAS is optimized for z13, but
> our s390x port is supposed to support all the z systems (see [1]).

what about asking for a a z13-support package to the isa-support (source 
package) maintainer.
This way it could be possible to upload an optimise vesion of openblas which 
can install on recent enought s390x machines.

the question will be then : does the buildd support these instructions ?

Cheers

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

RE:RFS: numexpr 2.6.2 and pytables 3.4.2

[PICCA Frederic-Emmanuel]

> ah... right after I hit send it stroke me that you probably meant
> "uploaded to Debian" so nothing for me todo.  Thanks Frederic-Emmanuel! ;)

Yes,enjoy your week-end :))

And numexpr was almost uploaded into unstable :))
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

RE:RFS: numexpr 2.6.2 and pytables 3.4.2

[PICCA Frederic-Emmanuel]

Hello,

I uploaded numexpr.

Cheers

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

Bug#870664: hkl: build-depends on obsolete emacs24

[PICCA Frederic-Emmanuel]

Hello,

I need to work on the hkl library next week for my work.
I must backport this for jessie-backport. I think that I will use emacs instead 
of emacs25/emacs24

Cheers

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

Bug#861736:

[PICCA Frederic-Emmanuel]

here the error message

~/Debian/nexus/bugs$ ./bug.py
Traceback (most recent call last):
  File "./bug.py", line 15, in 
f.flush()
  File "/usr/lib/python2.7/dist-packages/nxs/napi.py", line 397, in flush
raise NeXusError, "Could not flush NeXus file %s"%(self.filename)
nxs.napi.NeXusError: Could not flush NeXus file /tmp/foo.h5

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

Bug#861736:

[PICCA Frederic-Emmanuel]

It seems that the fix is not enought

this test failed at the flush

import nxs
f = nxs.open("/tmp/foo.h5", "w5")
f.makegroup('entry', 'NXentry')
f.opengroup('entry')
f.makegroup('g', 'NXcollection')
f.opengroup('g', 'NXcollection')
f.makedata('d', 'float64', shape=(1,))
f.opendata('d')
f.putdata(1.23)
f.closedata()
f.closegroup()
f.flush()
f.close()
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848137: [Dbconfig-common-devel] Bug#848137: problem with the upgrade of tango-db

[PICCA Frederic-Emmanuel]

> Ehm, yes. :)

so I just tested an upgrade from jessie to sid of tango-db and it works :)))

Now I have only one concern about the dump.
Since we had a failure with the dump when it ran as user, we discovered that 
our procedures where wrong and necessitate the dbadmin grants in order to works.

Would it be possible to display the error if the dump failed with the user 
grants. So during the upgrade we should see that something was wrong.

This way we should have this interesting information. (from my point of view, 
but you can dis-agreed :)

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

Bug#848137: [Dbconfig-common-devel] Bug#848137: problem with the upgrade of tango-db

[PICCA Frederic-Emmanuel]

Hello Paul

> Officially, no, because the documentation says: "If files exist in both
> data and scripts, they will both be executed in an unspecified order."
> However, the current behavior of dbconfig-common is to first run the
> script and then run the admin code and then run the user code. So you
> should be fine (but please test) and I'll make sure this behavior
> doesn't change in stretch.

Reading this. I think that I do not need the scripts part in order to fix 
tango-db

I juste need to get rid of the procedures in the dbadmin part and then the user 
scripts will be called :).

Agreed ?

thanks

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

Bug#848137: [Dbconfig-common-devel] Bug#848137: problem with the upgrade of tango-db

[PICCA Frederic-Emmanuel]

Hello Paul

> I really hope I can upload this weekend. I have code that I believe does
> what I want. I am in the process of testing it.

thanks a lot.


> [...]

>  What I meant,
> instead of the mysql code that runs as user, run a script for the
> upgrade (they are run with database administrator credentials) and in
> that script do two things: call the DROP PROCEDURES... and then use the
> user credentials to run the normal script.

> Apart from this repair, do you see more use cases? The problem is that
> you would need nearly all the logic that is now in dbc_go for this to
> work. What I am considering is if I could guarantee the order of
> script/user mysql/admin mysql (or the last two reversed). I guess that
> if I would guarantee the script to always come first, it would be easier
> to solve the tango-db issue at hand (which was originally created by
> dbconfig-common).


ok, so If I understand correctl.

In my tango-db postinst, I will add a script 

/usr/share/dbconfig-common/scripts/PACKAGE/upgrade/DBTYPE/VERSION

which does the fix (drop all the procedures)

then 

dbconfig-common will run my normal

 /usr/share/dbconfig-common/data/PACKAGE/upgrade/DBTYPE/VERSION

script.

right ?

I have more than one version of 'normal' upgrade scripts,

7.2.6
8.0.5
8.2.0
9.2.5

so I need to add the same amount of fix scripts in order to be sure that the 
database is fixed from the first upgrade.
7.2.6 -> 8.0.5 etc...

I just need to be sure that the database dump is done after the fix except if 
you run the dump at dbadmin, but In that case I would  have a dump with the non 
fixed database.


Cheers


Frederic



Paul

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

RE:sardana_2.2.2-2_i386.changes is NEW

[PICCA Frederic-Emmanuel]

same here after a binary upload my packages when thru the NEw process ?

BUt sardana is already into testing ??? and there is no new package at all


De : debian-science-maintainers 
[debian-science-maintainers-bounces+picca=synchrotron-soleil...@lists.alioth.debian.org]
 de la part de Debian FTP Masters [ftpmas...@ftp-master.debian.org]
Envoyé : vendredi 13 janvier 2017 16:52
À : Debian Science Maintainers; Picca Frédéric-Emmanuel
Objet : sardana_2.2.2-2_i386.changes is NEW

binary:python-sardana is NEW.
binary:python-sardana-doc is NEW.
binary:python-sardana is NEW.
binary:python-sardana-doc is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.



Cheers

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

RE:sardana_2.2.2-2_source.changes REJECTED

[PICCA Frederic-Emmanuel]

Hello

Is it normal ?

Source-only uploads to NEW are not allowed.

binary:python-sardana is NEW.
binary:python-sardana-doc is NEW.

The package is not NEW, but the previous source upload did not build.
So it seems thaht we can not do a new source upload if the previous one FTBFS.

Cheers

Frederic

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

Bug#848137: [Dbconfig-common-devel] Bug#848137: problem with the upgrade of tango-db

[PICCA Frederic-Emmanuel]

Hello Paul,

> Once I fixed 850190, 

Do you think that you will fix this bug before next week in order to let me 
enought time to fix tango and upload it.

> I believe that ought to work, although that is
> still a hack. I was thinking of doing the "DROP PROCEDURE IF EXISTS *"
> calls with the administrator credentials and the rest of the upgrade
> script with the proper tango credentials. But probably your solution is
> easier to implement.

I am thinking about this, and I agreed thaht it would be nice to put the fic in 
the postinst, just before the 
dbc_go whcih does the upgrade.

Can you give me an example of how to execute this DROP PROCEDURES IF EXISTS *
with the dbadmin right in this postinst

I am wondering if dbconfig-common could provide something in order to execute 
an sql script everywhen at the request of the maintainer,

dbc_dbuser = dbadmin
dbc_custom_stript=
dbc_go tango "runscript"

which run the script with the right database configuration extracted from the 
configuration phase.

Cheers

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

Bug#848137: [Dbconfig-common-devel] Bug#848137: problem with the upgrade of tango-db

[PICCA Frederic-Emmanuel]

Hello,

I discuss with the tango-db upstream and he found that

this one line fixed the problem, befrore doing the tango-db upgrade

UPDATE mysql.proc SET Definer='tango@localhost' where Db='tango';

Ideally it should be something like

UPDATE mysql.proc SET Definer='xxx' where Db='yyy';

where xxx is the dbuser and yyy the database name.à
It is true that for now my package works only if the database name is tango.


this is a limitation but I do not want to mix this into this bug report.

so can you help me write the right snipser at the right place in the debian 
scripts.

Or maybe I should just put the upgrade script og tango-db 9.2.5 intot eh 
dbadmin part with this fix at the end in order to have something consistant 
forthe next upgrade (tango 10)


Thanks for your help

Cheers

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

Bug#848137: [Dbconfig-common-devel] Bug#848137: RE:Bug#848137: Info received (problem with the upgrade of tango-db)

[PICCA Frederic-Emmanuel]

Hello,

> I am suspecting that this commit may be related to the current behavior:
> https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git/commit/?id=acdb99d61abfff54630c4cfba6e4452357a83fb9

> I believe I implemented there that the drop of the database is performed
> with the user privileges instead of the dbadmin privileges because I
> believed one should always have the rights to drop the db. Apparently I
> was wrong. We may need to clone or reassign this bug to dbconfig, but
> I'm not sure yet if there aren't more things, or if tango-db should work
> around the issue (which may be created by buggy dbconfig-common behavior
> of the past).

I can not give an educated guess if the current logic of dbconfig-common is 
good or not.
I do not have enough knowledge of SQL/MySQL/Postsgresq etc...

This problem could affect other package using dbconfig-common.

I agreed also that I must fix the wrongly created procedure/tables due to the 
previous dbconfig-common behaviour.

Can you help me in this proces in order to produce the right snopset to put in 
my package (preinst ?) script.

I need to change the owner of the procedure from

root @ localhost -> tango @ locahost

Which kind of script should I add in my debian scripts ?

thansk for your help


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

Bug#848137: Info received (problem with the upgrade of tango-db)

[PICCA Frederic-Emmanuel]

Thanks to reynald

1) On Jessie 

with the tango account

mysql> use tango;
mysql> show create procedure class_att_prop\G

I got  "Create Procedure": NULL

But If I use the root account (mysqladmin)

CREATE DEFINER=`root`@`localhost` PROCEDURE `class_att_prop` (IN class_name 
VARCHAR(255), INOUT res_str BLOB)

which shows clearly that on jessie the procédure where created with the admin 
account

2) On stretch

with the tango account

> CREATE DEFINER=`tango`@`localhost` PROCEDURE `class_att_prop` (IN class_name 
> VARCHAR(255), INOUT res_str MEDIUMBLOB)

Which shows that the procedures were created with the right tango account.

Now the question is how can we fix this ?
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848137: problem with the upgrade of tango-db

[PICCA Frederic-Emmanuel]

Hello, I would like to discuss about this bug [1]

I tryed to reproduce the scenary of piuparts in a virtual machine (gnome-box)

installed in 3 steps:
   jessie base system
   mysql-server (I need a working database)
   tango-db (daemon)


It works ok, I have a running tango-db daemon (ps aux | grep tango)

then

replace jessie by stretch in the sources.list

apt-get update
apt-get install mysql-server (5.5 -> 5.6)

the tango-db is still working.


Now I installed the new default-mysql-server


apt-get install default-mysql-server (5.6 -> mariadb 10.1)

the tango-db daemon is still working.

Now I upgrade tango-db

apt-get install tango-db (tango8 -> tango9)

and during this upgrade I have a problem of right that you can see in the bug 
report.

I would like to know how to debug this problem, I tryed to export dbc_debug=1, 
But I got no real information about the failing mysqldump.

I would say that I know almost nothing about sql, but I can learn.

What is strange from mmy point of view, is that I created the table and 
populate it only with dbconfig-common.
So I find strange that the dump can not work.

Maybe this is a problem of compatibility between mysql/mariadb, because the 
dabatase was first created with mysql 5.5 and the upgrade is done via mariadb.

Are you aware of problem of right due to mariadb ?


thanks for your help


Fred

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


please CC me I am not on the mailing list

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

Bug#811973: closed by Picca Frédéric-Emmanuel <pi...@debian.org> (Bug#811973: fixed in ssm 1.4.0-1~exp1)

[PICCA Frederic-Emmanuel]

No i  do not have access to my computer until 3 january 
If you want to nmu go ahead 

Cheers 

De : Adrian Bunk [b...@stusta.de]
Envoyé : mercredi 21 décembre 2016 16:57
À : 811...@bugs.debian.org; Picca Frédéric-Emmanuel
Objet : Re: Bug#811973 closed by Picca Frédéric-Emmanuel  
(Bug#811973: fixed in ssm 1.4.0-1~exp1)

Picca, can you also upload a fix/workaround for #811973 to unstable?

Thanks
Adrian

--

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Bug#848137: tango-db: fails to upgrade from 'jessie': mysqldump: tango has insufficent privileges to SHOW CREATE PROCEDURE `class_att_prop`!

[PICCA Frederic-Emmanuel]

Hello Andreas,

> In jessie, tango-db used mysql-server-5.5 (via mysql-server).
> The upgrade of tango-db was performed after mysql-server had been upgraded
> to mariadb-server-10.0 (via default-mysql-server) and was started again.

do you know if the mariadb-server was running during the upgrade of tango-db.
Because tango-db need a running server in order to work.

My problem is that tango-db provide a daemon which require a running 
mysql/mariadb running server in order to be installed.

BUT.

I do not know how to express via Dependencies, how to have a running 
mysql/mariadb server.
Especially if this running server is running on another computer than the one 
where I install the tango-db package.

I need to support both scenarios

tango-db + mysql on the same server (Maybe a Pre-Depends)
tango-db and mysql/mariad server on different computers.
 
cheers

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

Bug#844601: python-spyder: "from spyder.plugins.editor import Editor" hangs the machine

[PICCA Frederic-Emmanuel]

> In other words: if you want to use Qt you *need* a QApplication instance. 
> That's Qt basics. Not using it is a bug.

I understand,

Nervertheless I think that the python binding should fail gracefully with an 
exception instead of segfaulting...

Cheers

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

Bug#844601: python-spyder: "from spyder.plugins.editor import Editor" hangs the machine

[PICCA Frederic-Emmanuel]

Hello Dmitry

> The QFontDatabase method will definitely not work properly without a
> Q(Gui)Application instance.

thanks for this analyze.

so if I understand correctly, the problem is in the QFontDatabse method which 
should raise an exception instead of segfaulting.

right ?

so I should clone this bug and assign it to python{3}-pyqt5

sice it is a segfault maybe the culprite is  around sip...

Cheers

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

RE:python-spyder: "from spyder.plugins.editor import Editor" hangs the machine

[PICCA Frederic-Emmanuel]

> From the original bug report (the only thing I had up to know):

I attached my backtrace in the bug report. this is why we are speaking about 
different things;)

> Then if the gdb backtrace in the original bug report is to be trusted then 
> you are indeed mixing Qt4 and Qt5. And you can expect dragons for doing that 
> ;-)

the original bactrace was done by the initial bug reporter

then I tryed to reproduce the failure and I also got a segfault, but for a 
different reason.

so I think that there is a problem in the python pyqt5 binding...

let's investigate

Cheers

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

RE:python-spyder: "from spyder.plugins.editor import Editor" hangs the machine

[PICCA Frederic-Emmanuel]

> Hi Picca! Please next time you reassign a bug also CC the maintainer/team that
> receives the bug, else we don't get this very text you wrote above :-)

sorry about that.

> No, this not seems to be a Qt bug, and even less a Qt5 bug, as the lib
> mentioned in the backtrace is from Qt4. By looking at the bug log I am
> wondering if you are not happen to be mixing Qt4 and Qt5 in the same package.

I am not at all a Qt specialiste, so I red the first lines of the backtrace

#0  registerFont (fnt=0xbfffdd24) at text/qfontdatabase.cpp:1025
#1  QFontDatabasePrivate::addAppFont (this=, fontData=..., 
fileName=...) at text/qfontdatabase.cpp:2436
#2  0xb47ea5dd in QFontDatabase::addApplicationFont (fileName=...) at 
text/qfontdatabase.cpp:2482
#3  0xb4c5bc0a in ?? () from 
/usr/lib/python2.7/dist-packages/PyQt5/QtGui.i386-linux-gnu.so
#4  0x800d6ba1 in call_function (oparg=, pp_stack=0xbfffde88) at 
../Python/ceval.c:4352

then I seems to me that we where talking about PyQT5 (the binding) and then I 
deducted that the #0 where commin from qt5.

How do I know from which library this is comming from.

I obtained these backtrace by installing the qt5 debug symbols and not the qt4 
ones.

> Please double check all your dependencies that you are not mixing Qt4 and Qt5.
> And before reassigning to Qt please check that the issue is not in the
> bindings. Hint: try coding a minimal example.

> Due to the above I'm reassigning you the bug.

> It can be caused by a missued of your
> library but nevertheless it should not segfault :).

> Pass a null pointer to be dereferenced and you will get a segfault. And that's
> purely missuse.


Yes this si why I like haskell ;)


Regards, Fred

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

RE:spyder3 error

[PICCA Frederic-Emmanuel]

Thanks, I forwarded the bug to the upstream

Do not hesitate to fill a bug report via reportbug

reportbug spyder

this way we will have all the necessary informations, version of all your 
softwares etc...

https://github.com/spyder-ide/spyder/issues/3691

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

Bug#841600: pyfai: FTBFS: Tests failures

[PICCA Frederic-Emmanuel]

The problem was in scipy, 

#840264 

Now it is fixed.
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#842777: python3-spyder: broken dependency on python3-qtconsole (virtual package)

[PICCA Frederic-Emmanuel]

We are in the middle of the ipython  transition and we are awaiting for the 
ipykernel to b e uploaded.

I needed to uploade spyder in order to fix sardana for the ipython transition.

Cheers

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

Bug#840524: sardana: ipython transition: Please help assess the situation

[PICCA Frederic-Emmanuel]

sardana 2.1.1-1~exp1 available into experimental is supporting python-qtconsole 
and ipython5
so this is not a problem for the transition.

Cheers

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

Bug#840521: lmfit-py: ipython transition: Please help assess the situation

[PICCA Frederic-Emmanuel]

> we are planning to transition ipython from version 2.4 to 5 [1]. This
> amounts to larger changes: ipython-notebook and ipython-qtconsole were
> moved to a separate project, Jupyter. Packages for ipython 5 and several
> Jupyter components are available in experimental (see [1]), however
> jupyter-notebook and jupyter-qtconsole are not packaged yet.

Juste for info, I amrezady pacakged python-qtconsole

There is no jupyter-qtconsole package, but the python modules are available 
under

python(3)-qtconsole.


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

Bug#836850: pymca-doc: fails to upgrade from 'jessie' - trying to overwrite /usr/share/doc-base/pymca

[PICCA Frederic-Emmanuel]

Hello Andreas, what is strange is this

https://piuparts.debian.org/sid/state-successfully-tested.html#pymca-doc

Is there a problem with piuparts ?
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#826042:

[PICCA Frederic-Emmanuel]

Hello during the packaging I get this error message for the tests

==
ERROR: spyderlib.widgets.tests.test_array_builder 
(unittest.loader.ModuleImportFailure)
--
ImportError: Failed to import test module: 
spyderlib.widgets.tests.test_array_builder
Traceback (most recent call last):
  File "/usr/lib/python2.7/unittest/loader.py", line 254, in _find_tests
module = self._get_module_from_name(name)
  File "/usr/lib/python2.7/unittest/loader.py", line 232, in 
_get_module_from_name
__import__(name)
  File "spyderlib/widgets/tests/test_array_builder.py", line 13, in 
from pytestqt import qtbot
ImportError: No module named pytestqt


so it seems that we need to package also pytest-qt
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

RE:python-vispy_0.4.0-1_i386.changes REJECTED

[PICCA Frederic-Emmanuel]

uploaded


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

Bug#811339: spyder: major feature broken: ipython console doesn't work

[PICCA Frederic-Emmanuel]

Hello, I know that the current state of the spyder stack is quite unstable :((

Can you test this with the version available into unstable 2.3.8. And gives me 
your feedback.

The problem is that spyder > 2.3.5 changed by default the PyQt API#1 -> #2 and 
it broke a bunch of dependencies.
This is why I blocked the upgrade into testing.

- Another problem is that spyder will require ipython >3 which is not available 
in Debian for now.

- another problem is the removal of qtwebkit in the qt4 stack.

This require  a migration to the 3.X series or the switch to PyQt5 of spyder.

I can not garanti when this will be available into Debian testing AND unstable 
for now.

>The IDE is stuck in an infinite loop.
>* What outcome did you expect instead?
>When Spyder IDE is working, you open the IDE and the ipython console 
> displays the ipython console... and allows you to run commands (it doesn't 
> have a dialog box).

So can you test the latest version and if it does not solve your problem, you 
should considere reverting to the stable version of Debian.

Cheers

Frederic

PS: Staying with Debian stable is always better in production except if you are 
preparing the next stable :)
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#804358: Install issue with x86_64?

[PICCA Frederic-Emmanuel]

Hello I do not know why this break, but nevertheless, I will reassign to 
libstdc++in order to understand what is going on

 * libstdc++6:i386 breaks python-guiqwt (<=2.3.1-1)

Please gcc guyes, can you tell me if a binNMU would be enought to solve this 
problem.

Cheers

Frederic

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

Bug#803631: spyder FTBFS due to missing build dependencies

[PICCA Frederic-Emmanuel]

thanks for the pacth :)

BUT python3-qt4 -> python3-pyqt4

I will upload spyder 2.3.7 today.

Thanks

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

RE:python3 package for python-fabio on Wheezy

[PICCA Frederic-Emmanuel]

Hello Eugen,

Tes' when wheezy was released, Fabio was not available for python3.
I backported it to Jessie but I think that nothing prevent the backport to 
wheezy.
Can test the backport on wheezy, then de will upload it into wheezy backported.

Cheers

Fred

De : debian-science-maintainers 
[debian-science-maintainers-bounces+picca=synchrotron-soleil...@lists.alioth.debian.org]
 de la part de Eugen Wintersberger [eugen.wintersber...@gmail.com]
Envoyé : vendredi 23 octobre 2015 08:49
À : debian-science-maintainers@lists.alioth.debian.org
Objet : python3 package for python-fabio on Wheezy

Hi folks,
  is there a good reason why python-fabio is only available for Python
2.X on Wheezy? A Python3 package exists on Jessie so is there some
showstopper to create a backport for Wheezy and Python3?

best regards
  Eugen Wintersberger


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

Bug#797284: Info received (Bug#797284: Info received (Bug#797284: pytango ftbfs in unstable))

[PICCA Frederic-Emmanuel]

Here also a discussion about the problem on the gcc mailing list

https://gcc.gnu.org/ml/gcc-help/2015-09/msg00057.html

It seems that a abi_tag attribut should be added in tango to the problematic 
symbols in order to help gcc5 decide which ABI is expected.

ifdef _GLIBCXX_USE_CXX11_ABI
define TANGO_CXX11_ABI __attribute((abi_tag("cxx11")))
else
define TANGO_CXX11_ABI
endif
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#797284: Info received (Bug#797284: pytango ftbfs in unstable)

[PICCA Frederic-Emmanuel]

I started a thread about this on debian-python mailing list.

https://lists.debian.org/debian-python/2015/09/msg00028.html

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

Bug#797284: Info received (Bug#797284: pytango ftbfs in unstable)

[PICCA Frederic-Emmanuel]

:/usr/lib/i386-linux-gnu$ nm -D libtango.so.8.1.2  | grep ranges_type | c++filt 
0045f258 D Tango::ranges_type2const::enu
00460dfc B Tango::ranges_type2const::str[abi:cxx11]
0045f280 D Tango::ranges_type2const::enu
00460fdc B Tango::ranges_type2const::str[abi:cxx11]
0045f27c D Tango::ranges_type2const::enu
00460fac B Tango::ranges_type2const::str[abi:cxx11]
0045f26c D Tango::ranges_type2const::enu
00460eec B Tango::ranges_type2const::str[abi:cxx11]
0045f278 D Tango::ranges_type2const::enu
00460f7c B Tango::ranges_type2const::str[abi:cxx11]
0045f268 D Tango::ranges_type2const::enu
00460ebc B Tango::ranges_type2const::str[abi:cxx11]
0045f25c D Tango::ranges_type2const::enu
00460e2c B Tango::ranges_type2const::str[abi:cxx11]
0045f250 D Tango::ranges_type2const::enu
00460d9c B Tango::ranges_type2const::str[abi:cxx11]
0045f254 D Tango::ranges_type2const::enu
00460dcc B Tango::ranges_type2const::str[abi:cxx11]
0045f270 D Tango::ranges_type2const::enu
00460f1c B Tango::ranges_type2const::str[abi:cxx11]
0045f260 D Tango::ranges_type2const::enu
00460e5c B Tango::ranges_type2const::str[abi:cxx11]
0045f274 D Tango::ranges_type2const::enu
00460f4c B Tango::ranges_type2const::str[abi:cxx11]
0045f264 D Tango::ranges_type2const::enu
00460e8c B Tango::ranges_type2const::str[abi:cxx11]

so it seems that tango does not contain the symbol.

Tango::ranges_type2const::str

ok this symbol is not from the abi:cxx11.

We need to understand why pytango was built with the old abi.
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#797284: pytango ftbfs in unstable

[PICCA Frederic-Emmanuel]

Ok, with the new tango,I get another symbols problem

ImportError: /«PKGBUILDDIR»/build/lib.linux-i686-2.7/PyTango/_PyTango.so: 
undefined symbol: _ZN5Tango17ranges_type2constIsE3strE

Tango::ranges_type2const::str

so once again a problem with a string ???

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

Bug#797284: pytango ftbfs in unstable

[PICCA Frederic-Emmanuel]

ok, I just uploaded a tango package which fix the FTBFS with gcc5.
I also made a libstdc++6 transition for tango.

so now I think that after tango acceptation into unstable a simple binNMU 
should fix this issue.

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

Bug#797284: pytango ftbfs in unstable

[PICCA Frederic-Emmanuel]

ok, when I unmangle the symbol, I get this

c++filt _ZN5Tango11DeviceProxy14get_corba_nameB5cxx11Eb

Tango::DeviceProxy::get_corba_name[abi:cxx11](bool)

so it seems that this FTBFS is about a cxx11 ABi change.

during this build the c++ code compile in pytango (boost python)is noo more 
compatible with the 
libtango8 (whcih is not yest recompile with gcc5 due to the FTBF).

Even if a compilation of tango and then pytango should be possible.

I am wondering if the right solution is not to create a libtango8v5 and then to 
recompile pytango with this version ?

can I have yur opinion doko ?

thanks


Frederic

De : debian-science-maintainers 
[debian-science-maintainers-bounces+picca=synchrotron-soleil...@lists.alioth.debian.org]
 de la part de Matthias Klose [d...@debian.org]
Envoyé : samedi 29 août 2015 11:11
À : Debian Bug Tracking System
Objet : Bug#797284: pytango ftbfs in unstable

Package: src:pytango
Version: 8.1.5-1
Severity: serious
Tags: sid stretch

pytango ftbfs in unstable:

creating /scratch/packages/tmp/pytango-8.1.5/build/sphinx/html
Running Sphinx v1.3.1
Traceback (most recent call last):
  File setup.py, line 528, in module
main()
  File setup.py, line 525, in main
return setup(**setup_args())
  File /usr/lib/python2.7/distutils/core.py, line 151, in setup
dist.run_commands()
  File /usr/lib/python2.7/distutils/dist.py, line 953, in run_commands
self.run_command(cmd)
  File /usr/lib/python2.7/distutils/dist.py, line 972, in run_command
cmd_obj.run()
  File setup.py, line 210, in run
dftbuild.run(self)
  File /usr/lib/python2.7/distutils/command/build.py, line 128, in run
self.run_command(cmd_name)
  File /usr/lib/python2.7/distutils/cmd.py, line 326, in run_command
self.distribution.run_command(command)
  File /usr/lib/python2.7/distutils/dist.py, line 972, in run_command
cmd_obj.run()
  File setup.py, line 282, in run
sphinx.setup_command.BuildDoc.run(self)
  File /usr/lib/python2.7/dist-packages/sphinx/setup_command.py, line 161, in 
run
freshenv=self.fresh_env)
  File /usr/lib/python2.7/dist-packages/sphinx/application.py, line 126, in
__init__
confoverrides or {}, self.tags)
  File /usr/lib/python2.7/dist-packages/sphinx/config.py, line 277, in 
__init__
execfile_(filename, config)
  File /usr/lib/python2.7/dist-packages/sphinx/util/pycompat.py, line 128, in
execfile_
exec_(code, _globals)
  File /usr/lib/python2.7/dist-packages/six.py, line 672, in exec_
exec(exec _code_ in _globs_, _locs_)
  File string, line 1, in module
  File conf.py, line 15, in module
  File
/scratch/packages/tmp/pytango-8.1.5/build/lib.linux-x86_64-2.7/PyTango/__init__.py,
line 120, in module
from . import _PyTango
ImportError:
/scratch/packages/tmp/pytango-8.1.5/build/lib.linux-x86_64-2.7/PyTango/_PyTango.so:
undefined symbol: _ZN5Tango11DeviceProxy14get_corba_nameB5cxx11Eb
dh_auto_build: python setup.py build --force returned exit code 1
debian/rules:13: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 1
make[1]: Leaving directory '/scratch/packages/tmp/pytango-8.1.5'

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

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

Bug#797285: tango ftbfs in unstable

[PICCA Frederic-Emmanuel]

Hello Doko,


libtool: link: g++ -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -std=c++11 -D_REENTRANT -DOMNI_UNLOADABLE_STUBS -Wl,-z
-Wl,relro -o .libs/notifd2db notifd2db.o  -L../../lib/cpp/server
/scratch/packages/tmp/tango-8.1.2c+dfsg/build/lib/cpp/server/.libs/libtango.so
-L../../lib/cpp/log4tango/src
/scratch/packages/tmp/tango-8.1.2c+dfsg/build/lib/cpp/log4tango/src/.libs/liblog4tango.so
-lzmq -ldl -L/usr/lib -lomniORB4 -lomniDynamic4 -lCOS4 -lnsl -lomnithread 
-lpthread
/scratch/packages/tmp/tango-8.1.2c+dfsg/build/lib/cpp/server/.libs/libtango.so:
undefined reference to `Tango::ranges_type2constunsigned long::str'
/scratch/packages/tmp/tango-8.1.2c+dfsg/build/lib/cpp/server/.libs/libtango.so:
undefined reference to `Tango::ranges_type2constlong::str'
/scratch/packages/tmp/tango-8.1.2c+dfsg/build/lib/cpp/server/.libs/libtango.so:
undefined reference to `Tango::ranges_type2constint::str'
/scratch/packages/tmp/tango-8.1.2c+dfsg/build/lib/cpp/server/.libs/libtango.so:
undefined reference to `Tango::ranges_type2constunsigned char::str'
/scratch/packages/tmp/tango-8.1.2c+dfsg/build/lib/cpp/server/.libs/libtango.so:
undefined reference to `Tango::ranges_type2constdouble::str'
/scratch/packages/tmp/tango-8.1.2c+dfsg/build/lib/cpp/server/.libs/libtango.so:
undefined reference to `Tango::ranges_type2constunsigned int::str'
/scratch/packages/tmp/tango-8.1.2c+dfsg/build/lib/cpp/server/.libs/libtango.so:
undefined reference to `Tango::ranges_type2constshort::str'
/scratch/packages/tmp/tango-8.1.2c+dfsg/build/lib/cpp/server/.libs/libtango.so:
undefined reference to `Tango::ranges_type2constunsigned short::str'
/scratch/packages/tmp/tango-8.1.2c+dfsg/build/lib/cpp/server/.libs/libtango.so:
undefined reference to `Tango::ranges_type2constfloat::str'


If I look at this it seems that during the link of notifd2db, ld doesn not find 
a bunch of symbols 
these symboles are defined in lib/cpp/server/attribute.cpp via a macro defined 
in lib/cpp/server/tango_const.h

I never had a problem befaore, so I do not understand what the problem is.

do you have any idea of what's going on ?
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#797284: pytango ftbfs in unstable

[PICCA Frederic-Emmanuel]

I am working on it with the upstream.

once fixed,I will upload a tango with the v5 extension. then I will ask for a 
transition
right ?

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

Bug#797284: pytango ftbfs in unstable

[PICCA Frederic-Emmanuel]

 any libstdc++6 follow-up transition is waived. you can just upload to 
 unstable.

ok, I will try to fix this issue  next week.

thanks

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

Bug#791002: clipper: library transition may be needed when GCC 5 is the default

[PICCA Frederic-Emmanuel]

Here I attach the unmangled symbols

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

RE:mmdb_2.0.1-1~exp1_i386.changes REJECTED

[PICCA Frederic-Emmanuel]

Hello when I look here [1]

it seems that the Distribution is sid

Distribution:   sid

but I expected to target the experimental  distribution.

Changes:mmdb (2.0.1-1~exp1) experimental; urgency=medium

This is the first time, I used sbuild to generate the package instead of 
pbuilder.

Should I re-upload with the right Distribution ?


Thanks

Frederic

[1] https://ftp-master.debian.org/new/mmdb_2.0.1-1~exp1.html

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

RE:mmdb_2.0.1-1~exp1_i386.changes REJECTED

[PICCA Frederic-Emmanuel]

Ok,

I fixed the package, remove the GPL section, now the code is only LGPL.

use cme to add the default lpgl snipset.

I also made the -dbg pacakge multi-arch same.

thanks for considering accepting mmdb.

Cheers

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

RE:libQGLViewer and Qt5

[PICCA Frederic-Emmanuel]

 Yes, it will be renamed. In those build only Qt5 was tested
 without renaming.

one of the revers dependencies of qglviwer force us to keep the qt4 version ?

$ apt-cache rdepends libqglviewer2
libqglviewer2
Reverse Depends:
  python-yade
  libyade
  utopia-documents
  octovis
  liboctovis1.6
  libqglviewer-dev
  science-viewing

Cheers

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

RE:ssm_1.4-1~exp1_i386.changes REJECTED

[PICCA Frederic-Emmanuel]

Is it ok if I do the copyright modification ?

Cheers

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

Bug#766970: python-scoop: Provide the Python 3 package

[PICCA Frederic-Emmanuel]

Hello, 

since we are close to the freeze and because your package add a new binary 
package it will requiered to pass the new queue.
So it will no be possible to have python3 package for scoop into jessie.

nevertheless I propose to upload it targetting the experimental distribution 
and reseve unstable for last minut fix if requiered by the release-team.

Is it ok for you ?

Cheers

Frederic.

so : just change in the changelog unstable for experimenta and I will upload 
the package.

thanks

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

Bug#765963: spyder3: new upstream release (2.3.1)

[PICCA Frederic-Emmanuel]

 I also took the liberty to bump the standards version and fix some of the
 lintian pedentic errors. I am happy to share my changes with you guys if
 you're interested


Hello, are you part of the debian-sceince team ?
if yes you can push your changes to the repository.

If not, just give me the URL were I can find your modifications, or attach a 
pacth to the bug report :)


cheers

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

Bug#765963: spyder3: new upstream release (2.3.1)

[PICCA Frederic-Emmanuel]

 Yes, I am part of the DST. I did not know it was so straightforward.

This is the principle of team maintenance :)

 What should i do regarding the changelog though ?

put your name in the changelog

 Do i make it as spyder (2.3.1+dfsg-1) with distribution set to
 UNRELEASED and file an RFS ?


yes then I will finalise the pacakge.


Cheers

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

RE:Packaging coot for Debian

[PICCA Frederic-Emmanuel]

Hello,

I have uploaded into unstable

mmdb, ssm, libccp4 and clipper.

so it is possible to work on the coot packaging for jessie.

cheers

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

RE:Packaging coot for Debian

[PICCA Frederic-Emmanuel]

Hello andreas,

 in beginning of February you injected an empty repository coot.git into
 Debian Med team Git.  I might have forgotten whether you did some
 announcement about this but for the moment I see no point in keeping
 any empty repository in our space.  Moreover there is some existing
 packaging at

git://git.debian.org/git/debian-science/packages/coot.git

Yes I started this packaging effort taking the work already done by Morten 
Kjeldgaard in its ppa.
I sent him a few private emails, but I never received an answer.

For the packaging of coot, I have not enought time to spend on this package for 
now (lake of ressources)
So if someone want to take over this packaging effor tunder the debian-science 
umbrella, this is not a problem for me.

the first step of the packaging was to add all its dependencies into Debian.

so this is what I did with:

ccp4
ssm
mmdb
clipper

which are now in experimental for a long time now.
I think that I should upload them into unstable before the freeze.
At this time I was looking for the official release of ccp4 6.4.0
Now it seems that this is ok.

now the refmac-dictionnary must be package to enhance coot.

 While this packaging is obviously unmaintained / unfinished (I just
 updated homepage and watch file) I wonder whether we should join forces
 to finalise the packaging (I have not tested the build!).

It would be great, it seems to me that this package is not that far from 
releaseable in a short time.

Cheers

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

Bug#737956: conflict between system user and normal user

[PICCA Frederic-Emmanuel]

 I don't think there is much that can reall be done to fix the
 fundamental problem which is that system users and regular users have to
 live in the same namespace causing a risk of conflicts.

 There are two things I can see you could do to impreove the situation
 with your package.
 1: Fail early, it's better to have preinst fail than it is to start
 creating stuff with wrong permissions/ownership.

Yes I nedd to faisl with a human comprehensible error explaining that the 
requested users
is already there but that is not a system user.

 2: Choose a less generic name that is less likely to cause conflicts. Do
 you plan to use this user only for the db? if so tango-db might make
 sense, if not maybe something like tango-control-system.


no this user will be used by all tango controls system daemon.
tango-db
tango-starter
tango-accesscontrol
...

no my question is should I provide a amigration plan from the current tango 
user ?

this package is already usedin production.
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers