Re: Adding Python 3.8 as a supported Python3 version
Le 07/11/2019 à 15:08, Matthias Klose a écrit : > [1] https://wiki.debian.org/Python/Python3.8. Thanks Matthias. I've added the following point to "common upstream issues": * Embedding Python: modules are not linked with libpython3.8 anymore, but programs that embed Python still need to link with it. When configuring such programs, --embed must be passed to python3-configure. Earlier versions of python3-configure do not support this option. Failing that, errors will occur at link-time (usually part of compile-time, but sometimes part of run-time). I've stumbled upon that in my project Gyoto and fixed python.m4 (borrowed from [1]pyconfigure) to support it. I've also submitted my patch [2]there. Regards, Thibaut. [1] https://savannah.gnu.org/projects/pyconfigure/ [2] https://savannah.gnu.org/bugs/?57115 PS: setting Mail-Followup-To 942...@bugs.debian.org signature.asc Description: OpenPGP digital signature
Re: Help needed with dbgsym package: yorick_2.2.04+dfsg1-7_amd64.changes REJECTED
Le 12/02/2018 à 13:35, Sébastien Villemot a écrit : Hi Thibaut, On Mon, Feb 12, 2018 at 01:27:00PM +0100, Thibaut Paumard wrote: I recently tried to convert a package from the old, manual -dbg package scheme to the new, automatic -dbgsym package scheme. I get this reject, below. Do you have any clue what I'm doing wrong? Le 07/02/2018 à 11:22, Debian FTP Masters a écrit : yorick-dbgsym_2.2.04+dfsg1-7_amd64.deb: trying to install to unstable-debug, but could not find source Looking at the REJECT message, you forgot to include the .dsc file in your upload (i.e. you built with "dpkg-buildpackage -b" or something similar). Best, Thanks Sébastien, That's it. Nothing to do with the dbgsym package after all. I'll check my sbuild configuration. Kind regards, Thibaut.
Help needed with dbgsym package: yorick_2.2.04+dfsg1-7_amd64.changes REJECTED
Dear fellow developpers, I recently tried to convert a package from the old, manual -dbg package scheme to the new, automatic -dbgsym package scheme. I get this reject, below. Do you have any clue what I'm doing wrong? Le 07/02/2018 à 11:22, Debian FTP Masters a écrit : yorick-dbgsym_2.2.04+dfsg1-7_amd64.deb: trying to install to unstable-debug, but could not find source Regards, Thibaut.
Re: Changing maintainer for mpich to debian-hpc
Le 24/01/2018 à 16:14, Sébastien Villemot a écrit : Fair enough, but I would still prefer to keep a single Maintainer address for the many science packages. What should this address be? It could be: team+debian-science-maintain...@tracker.debian.org Packages with this email will be automatically added to the tracker page for the Debian Science Team: https://tracker.debian.org/teams/debian-science-maintainers/ Then one can subscribe to the whole team through tracker.d.o in order to get all DAK/BTS messages (i.e. the same as the current debian-science-maintainers@ list). Or it is also possible to subscribe to indivdual packages. So this scheme offers a lot of flexibility. The only problem is that, currently, messages sent to that email go to /dev/null, which could be a problem if someone try to contact the package maintainer through that mean. But this situation is only temporary, since buxy (the maintainer of distro-tracker, the software behind tracker.d.o) intends to fix this. I guess that's the way to go, but not until this is fixed.
Re: Changing maintainer for mpich to debian-hpc
Le 24/01/2018 à 15:54, Drew Parsons a écrit : On Wed, 2018-01-24 at 16:15 +0300, Boris Pek wrote: I propose to change the Maintainer: for mpich from "Debian Science Maintainers" which is an Alioth list, to debian-hpc@lists.debian .org. Any comments or objections? I would prefer to have all Debian Science package-related e-mails on a single list. Given the sort of traffic that we have on debian- science (mostly packaging-related already), I would vote for using debian-science as the maintainer address. There are too huge amount of packages related to Debian Science team. And as far as I know the most of maintainers are interested only in limited amount of them. Thus all extra emails will be perceived as a flood. People who do not have enough free time to sort such flood manually just will stop usage of this mailing list. I vote for not mixing of ML for communication with team members with ML for automatic emails related to packaging activity. I agree with Boris, the maintenance emails would make the discussion threads almost unreadable. Could use mail filters, but the same problem applies to the web interface where you can't use a filter. A separate list is cleaner. Anyone who wants to subscribe to both still can of course. Fair enough, but I would still prefer to keep a single Maintainer address for the many science packages. What should this address be? T.
Re: Changing maintainer for mpich to debian-hpc
Le 24/01/2018 à 10:54, Alastair McKinstry a écrit : Hi, I propose to change the Maintainer: for mpich from "Debian Science Maintainers" which is an Alioth list, to debian-...@lists.debian.org. Any comments or objections? Dear Alastair, I would prefer to have all Debian Science package-related e-mails on a single list. Given the sort of traffic that we have on debian-science (mostly packaging-related already), I would vote for using debian-science as the maintainer address. Kind regards, Thibaut.
Re: Please categorise your packages for the Debian Science metapackages
Dear Andreas, Le 05/01/2017 à 14:39, Andreas Tille a écrit : > Since this script has the logic to check whether a package that is > maintained by the Debian Science team is mentioned in Debian Science > tasks the best way to do the exclusion would be rather if you move your > packages into Debian Astro team. > > I have also *not* included yorick-mira into any Debian Astro which you > definitely should if you think it should be part of some metapackage. Yes, that's actually what I meant. I'll do that with the next upload in the next few days. Regards, Thibaut.
Re: Please categorise your packages for the Debian Science metapackages
Dear Andreas, All my packages should really go to astronomy. Two sets of packages I would hide in any case, the last one would need to fit in the right task in the astronomy blend. (python|python3|yorick)-pyorick hide yorick-mira should go to astronomy (python|python3|yorick)-svipc hide Kind regards, Thibaut. Le 04/01/2017 à 15:50, Andreas Tille a écrit : > Hi, > > as in every release cycle I'm trying to verify that every package > maintained in Debian Science team is properly categorised in our Blends > tasks. If a package is just a predependency for some other scientific > software I can add it to a blacklist of packages that should not show > up in the Debian Science metapackages explicitly. I have uploaded the > list of not yet categorised (not yet blacklisted) source packages to > >http://blends.debian.net/tmp/debian-science.txt > > The list also contains the latest uploader - so simply seek for your > name - everybody in CC is mentioned at least once in the list and should > definitely have a look. If other readers here feel competent to > classify a package for one or more (!) tasks in our task list > >https://blends.debian.org/science/tasks/ > > evary suggestion is welcome. > > To add a binary (!) package to a task you can simply > > debcheckout -u your_alioth_login debian-science > cd debian-science/tasks > > and edit the task in question. Members of the Debian Pure Blends team > as well as any DD (ACLs are set but I have heard this does not work > reliably) have commit permissions. I'm also fine if you debcheckout > anonymously and send me `git format-patch` formated changes or just > answer here to this mail. > > If you are not sure whether a package belongs to a task or not feel > free to discuss this here. > > Kind regards and thanks for your cooperation > > Andreas. >
Re: Autopkgtest, MPI and network access (Was: Autopkgtest and MPI code)
Le 04/10/2016 à 20:28, Alastair McKinstry a écrit : > Deat Thibault > > Were these tests done under fakeroot ? See the thread from earlier > (yesterday and today) on debian-devel. Basically, openmpi breaks under > fakeroot as it gets unexpected credentials back from getsockopt() > Dear Alastair, I have seen this thread. The tests done manually for sure were not run under fakeroot. I don't know for sure whether autopkgtest invokes fakeroot, but I doubt it. Kind regards, Thibaut. > regards > > Alastair > > > > On 04/10/2016 17:09, Thibaut Paumard wrote: >> Dear all, >> >> Last year I had trouble writing autopkgtest tests that would run >> smoothly in a container. It seems that recent changes in openmpi have >> broken it again. >> >> This is what worked last year: >> >> Le 26/05/2015 à 10:07, Johannes Ring a écrit : >>> On Sat, May 23, 2015 at 7:10 PM, Thibaut Paumard wrote: >>>> What does work on my box is: >>>> orterun --mca btl_tcp_if_include lo >>>> >>>> This never crashes the machine, but it does not work in a chroot (for >>>> lack of a loopback interface, I guess). I get this error message: >>> It works for me in pbuilder if I set OMPI_MCA_orte_rsh_agent=/bin/false: >>> >>> (pbuild22309)root@debian-t420s:/# orterun --mca btl_tcp_if_include lo ls >> This has been working fine until mid-September this year: >> >> https://ci.debian.net/packages/g/gyoto/unstable/amd64/ >> >> I checked that I can still run gyoto with MPI parallelisation with >> openmpi 2, which is reassuring, but: >> >> 1- gyoto with MPI parallelisation fails again if I turn off network >> access (processes are unable to reach one-another). To turn off network >> access, I issue "ifdown eth0". >> >> 2- even with networking turned on, using "--mca btl_tcp_if_include lo" >> makes my gyoto job fail, whatever the value of OMPI_MCA_orte_rsh_agent >> (processes are unable to reach one-another); >> >> 3- I removed the two variables from the test script, it runs fine when >> started manually as long as network is available, but if I let >> autopkgtest run it with `null' as virtualization server, the job remain >> stuck, apparently at the step when gyoto tries to spawn workers using >> MPI_Comm_spawn. >> >> Those tests were done in VirtualBox. >> >> Looking at the last successful run of autopkgtest on ci.debian.net and >> the first failed one, the version of openmpi seems to be the same >> (libopenmpi1.10). >> >> Does anyone have a clue what might be going on here? I have the >> impression I am facing two issues, one of which is related to ompenmpi, >> the other one possibly to autopkgtest. >> >> Regards, Thibaut. >> > -- * Dr Thibaut Paumard | LESIA/CNRS - Table équatoriale (bât. 5) * * Tel: +33 1 45 07 78 60 | Observatoire de Paris - Section de Meudon * * Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen* * thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) * smime.p7s Description: Signature cryptographique S/MIME
Autopkgtest, MPI and network access (Was: Autopkgtest and MPI code)
Dear all, Last year I had trouble writing autopkgtest tests that would run smoothly in a container. It seems that recent changes in openmpi have broken it again. This is what worked last year: Le 26/05/2015 à 10:07, Johannes Ring a écrit : > On Sat, May 23, 2015 at 7:10 PM, Thibaut Paumard wrote: >> What does work on my box is: >> orterun --mca btl_tcp_if_include lo >> >> This never crashes the machine, but it does not work in a chroot (for >> lack of a loopback interface, I guess). I get this error message: > > It works for me in pbuilder if I set OMPI_MCA_orte_rsh_agent=/bin/false: > > (pbuild22309)root@debian-t420s:/# orterun --mca btl_tcp_if_include lo ls This has been working fine until mid-September this year: https://ci.debian.net/packages/g/gyoto/unstable/amd64/ I checked that I can still run gyoto with MPI parallelisation with openmpi 2, which is reassuring, but: 1- gyoto with MPI parallelisation fails again if I turn off network access (processes are unable to reach one-another). To turn off network access, I issue "ifdown eth0". 2- even with networking turned on, using "--mca btl_tcp_if_include lo" makes my gyoto job fail, whatever the value of OMPI_MCA_orte_rsh_agent (processes are unable to reach one-another); 3- I removed the two variables from the test script, it runs fine when started manually as long as network is available, but if I let autopkgtest run it with `null' as virtualization server, the job remain stuck, apparently at the step when gyoto tries to spawn workers using MPI_Comm_spawn. Those tests were done in VirtualBox. Looking at the last successful run of autopkgtest on ci.debian.net and the first failed one, the version of openmpi seems to be the same (libopenmpi1.10). Does anyone have a clue what might be going on here? I have the impression I am facing two issues, one of which is related to ompenmpi, the other one possibly to autopkgtest. Regards, Thibaut.
Re: Autopkgtest and MPI code
Le 23/05/2015 14:10, Anton Gladky a écrit : > Hi Thibaut, > > for testing MPI I add the following line into the script: > > export OMPI_MCA_orte_rsh_agent=/bin/false > > Usually it works [1--3]. Dear Anton, Thanks for the tip. Unfortunately it does not work (tested only on jessie and on gyoto). Setting this variable does not change anything. Gyoto is a bit peculiar compared to most MPI codes in that it uses MPI_Comm_spawn to spawn workers instead of relying on mpirun to launch several identical processes. This scenario may have issues different from the more classical strategy. Oddly, it seems that the shared memory transport does not work at all: if I use "orterun --mca btl sm,self ", the code always crashes the machine. What does work on my box is: orterun --mca btl_tcp_if_include lo This never crashes the machine, but it does not work in a chroot (for lack of a loopback interface, I guess). I get this error message: adt-run [19:01:17]: test python-gyoto-mpi: [--- [tantive-iv:26356] [[INVALID],INVALID] ORTE_ERROR_LOG: Not found in file ess_hnp_module.c at line 170 -- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): orte_plm_base_select failed --> Returned value Not found (-13) instead of ORTE_SUCCESS -- [tantive-iv:26356] [[INVALID],INVALID] ORTE_ERROR_LOG: Not found in file runtime/orte_init.c at line 128 -- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): orte_ess_set_name failed --> Returned value Not found (-13) instead of ORTE_SUCCESS -- [tantive-iv:26356] [[INVALID],INVALID] ORTE_ERROR_LOG: Not found in file orterun.c at line 694 adt-run [19:01:18]: test python-gyoto-mpi: ---] adt-run [19:01:18]: test python-gyoto-mpi: - - - - - - - - - - results - - - - - - - - - - python-gyoto-mpi FAIL non-zero exit status 243 thibaut@tantive-iv:~/git/gyoto$ Kind regards, Thibaut. > > > [1] > http://anonscm.debian.org/cgit/debian-science/packages/esys-particle.git/tree/debian/tests/build1#n7 > [2] > https://anonscm.debian.org/cgit/debian-science/packages/liggghts.git/tree/debian/tests/heat > [3] > https://anonscm.debian.org/cgit/debian-science/packages/liggghts.git/tree/debian/tests/packing > > Best regards > > Anton > > Anton > > > 2015-05-23 10:41 GMT+02:00 Thibaut Paumard : >> Hi, >> >> I'm working on autopkgtest support in one of my packages, gyoto. >> >> The upcoming upstream release (preview available on our alioth git repo) >> features MPI parallelisation, and I want to test this feature. >> >> In my experience, running MPI code requires network access. Failing >> that, openmpi hangs the machine. For instance, when debugging in the >> subway, I have to connect to my cell-phone by wifi else the computer >> will freeze during the test suite! >> >> I'm wondering whether putting "Restrictions: isolation-container" in the >> test stanza is sufficient to ensure openmpi will behave properly? >> >> Also akin, is there a way to test the code during build, since it is >> forbidden to access the network at that time? >> >> Kind regards, Thibaut. >> >> >> -- >> To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org >> Archive: https://lists.debian.org/55603d25.1080...@debian.org >> > > -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5560b48c.2070...@debian.org
Autopkgtest and MPI code
Hi, I'm working on autopkgtest support in one of my packages, gyoto. The upcoming upstream release (preview available on our alioth git repo) features MPI parallelisation, and I want to test this feature. In my experience, running MPI code requires network access. Failing that, openmpi hangs the machine. For instance, when debugging in the subway, I have to connect to my cell-phone by wifi else the computer will freeze during the test suite! I'm wondering whether putting "Restrictions: isolation-container" in the test stanza is sufficient to ensure openmpi will behave properly? Also akin, is there a way to test the code during build, since it is forbidden to access the network at that time? Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55603d25.1080...@debian.org
Max size of debian-astro-commits messages
Dear all, As I am moderating the debian-astro-commits mailing lists, which receives all or git commits, I often see large or very large commit messages. The limit is currently set to 40KB. I think I should increase the limit to at least 200KB, and still allow manually larger messages which are not spam. Also, I'm wondering what are the consumers of these messages. Is it important to someone to receive all this traffic? Whenever someone commits a new upstream release, that can mean hundreds of large messages. What do you think? Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55601f82.4040...@debian.org
Bug#785604: ITP: python-pyorick -- Python module to execute Yorick code
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-science@lists.debian.org, debian-pyt...@lists.debian.org * Package name : python-pyorick Version : 1.4 Upstream Author : Dave Munro * URL : https://github.com/dhmunro/pyorick * License : BSD 2-Clause Description : The pyorick package starts yorick as a subprocess and provides an interface between python and yorick interpreted code. Features: + exec or eval arbitrary yorick code strings + get or set yorick variables + call yorick functions or subroutines with python arguments + get or set slices of large yorick arrays + terminal mode to interact with yorick by keyboard through python Most of the data is exchanged via binary pipes between the two interpreters. Yorick runs in a request-reply mode. Python prints anything yorick sends to stdout or stderr except prompts. The package yorick-yutils contains an interface (pyk.i) which allows the reverse: controlling Python from Yorick. The pyk.i approach however suffers from severe limitations (most notably, all data are sent via textual representations). The yorick-svipc and python(3)-svipc packages allow exchanging data between the two interpreters using shared memory. While not as straightforward to use as this package, the shared memory approach may avoid data duplication and can be used together with this package. The package will be hosted under the Debian Science umbrella, like the rest of the Yorick stack. Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5559ace6.5090...@debian.org
Re: Fwd: plplot_5.10.0-0.1_amd64.changes is NEW
Le 24/09/2014 11:25, Thibaut Paumard a écrit : > (CC: debian-science) > > Le 23/09/2014 22:26, Andrew Ross a écrit : >> >> Thibat, >> >> I have now uploaded a new version 5.10.0+dfsg-1 to mentors.debian.net. > > I'm building it right now. Uploaded. signature.asc Description: OpenPGP digital signature
Re: Fwd: plplot_5.10.0-0.1_amd64.changes is NEW
(CC: debian-science) Le 23/09/2014 22:26, Andrew Ross a écrit : > > Thibat, > > I have now uploaded a new version 5.10.0+dfsg-1 to mentors.debian.net. > This the serious outstanding bugs, other than the Ada problem, which > I believe is a transient issue related to gnat rather than a plplot > problem. I've fixed up some lintian issues as well. If you (or Axel > / Olly) are able to review / upload this I would be most grateful! I'm building it right now. > I've applied to join debian-science with the intention of putting the > debian packaging on alioth. Currently it lives on the upstream git > repository on sourceforge. I hope that will aid maintenance for all. Thanks, I do believe it will help! And welcome in the team! Whenever you can, check that your package follows de Debian Science policy as much as possible (at least change the Maintainer field, put yourself as Uploader instead, make the VCS fields point to alioth) and push it to Alioth. Then ping me and I will upload it (I may wait until the previous upload migrates to testing though). https://wiki.debian.org/DebianScience http://debian-science.alioth.debian.org/debian-science-policy.html Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: OT: namespace pollution & prefixes
Le 23/05/2014 22:01, Felix Salfelder a écrit : > On Fri, May 23, 2014 at 11:41:33AM +0200, Tobias Hansen wrote: >> I would recommend to be careful not to pollute the /usr/bin namespace. >> If a package really has to install many commands to /usr/bin in bulk, >> consider prefixing them with the name of the project, e.g. seacas-fastq. >> Especially if there are generic names such as decomp, algebra, numbers >> involved. > > good idea. thanks Tobias. > > Nico: i have added & pushed the suggested prefixes, i didn't check > whether some of them call each other yet. > Another possibility is to put the actual commands in a lib directory (e.g. /usr/lib/seacas-fastq/bin) and provide a wrapper in /usr/bin which could look a bit like that: #!/bin/sh set -e export PATH=/usr/lib/seacas-fastq/bin:$PATH $@ exit 0 One advantage is that this should work even if the tools call one another. Another is that users can also set their own path and drop the prefix. Kind regards, Thibaut. -- * Dr Thibaut Paumard | LESIA/CNRS - Table équatoriale (bât. 5) * * Tel: +33 1 45 07 78 60 | Observatoire de Paris - Section de Meudon * * Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen* * thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) * smime.p7s Description: Signature cryptographique S/MIME
Re: Debian science policy: Priorities field
Le 21/05/2014 11:54, Оlе Ѕtrеісhеr a écrit : > Hi, Hi, > I just came around the science policy and found the following sentence: > > | The Priority field should be set to "extra" if this is permitted by > | the Debian Policy, or set to "optional" otherwise. > > However, the Debian Policy states: > > | optional - (In a sense everything that isn't required is optional, but > | that's not what is meant here.) This is all the software that you > | might reasonably want to install if you didn't know what it was and > | don't have specialized requirements. This is a much larger system and > | includes the X Window System, a full TeX distribution, and many > | applications. Note that optional packages should not conflict with > | each other. > | > | extra - This contains all packages that conflict with others with > | required, important, standard or optional priorities, or are only > | likely to be useful if you already know what they are or have > | specialized requirements (such as packages containing only detached > | debugging symbols). > > I would guess, the two priorities are mixed up in the Science policy, > right? I think the rationale is that Science packages "are only likely to be useful if you already know what they are". However they are not at all like the stated example (detached debugging symbols, so I do believe that the meaning of the Policy is that most of our packages should be of Priority "optional" and our Science Policy is sort of wrong. That's what I have thought for a couple of years now, and I'm glad you bring the matter. Kind regards, Thibaut. -- * Dr Thibaut Paumard | LESIA/CNRS - Table équatoriale (bât. 5) * * Tel: +33 1 45 07 78 60 | Observatoire de Paris - Section de Meudon * * Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen* * thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) * smime.p7s Description: Signature cryptographique S/MIME
Re: Bug#743379: ITP: gravit -- visually stunning gravity simulator
Le 02/04/2014 17:22, Tomasz Buchert a écrit : > On 02/04/14 15:21, Andreas Tille wrote: >> Hi Tomasz, >> >> I guess you might like to maintain this package in Debian Astro team. > Hi Andreas, > I totally agree, it is a great idea. Do I have to do something > special about it? > What about stellarium? I'm doing completely fine alone, but, > well, what do you think? > Yes please :-) We don't have a policy yet, I think you can just apply the debian-science policy with s/debian-science/debian-astro/. The essential steps are to put debian-astro-maintainers@lists.alioth.d.o in the Maintainer field, yourself as Uploader, and putting the package in a git repository on alioth under /git/debian-astro. Of course you also need to subscribe to debian-astro-maintainers@lists.alioth.d.o, debian-astro@lists.d.o and request to be added to the alioth project. https://alioth.debian.org/projects/debian-astro https://lists.alioth.debian.org/mailman/listinfo/debian-astro-maintainers http://debian-science.alioth.debian.org/debian-science-policy.html Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Bug#725957: gnudatalanguage and plplot not migrating
Le 26/03/2014 00:52, Axel Beckert a écrit : > forwarded 725957 http://sourceforge.net/p/gnudatalanguage/bugs/594/ > kthxbye > > Hi, Hi, > Thibaut Paumard wrote: >> Do you need help fixing plplot and gnudatalanguage so they can reach >> testing? > > As documented in the BTS I've forwarded the FTBFS to Sylwester Arabas > (the one of the GDL upstream devs I had most contact with) by e-mail > after I noticed them, but got no reply so far. He though opened an > issue at their tracker just an hour ago: > http://sourceforge.net/p/gnudatalanguage/bugs/594/ That's because I had been talking with a colleague who is also involved upstream. I decided to offer my help here while he pinged Sylwester. >> I think it would make sense to maintain them in a team, either >> debian-science (CC:) or debian-astro. > > I'm happy if someone else would help keeping GDL in Debian in shape or > even wants to take over maintainership completely. We both, Gürkan and > me, only maintain GDL in Debian because we need it at work. We don't > use it ourselves. I don't mean to hijack your package. However, it would make sense for me to get involved since I can meet upstream face to face anytime. > With regards to plplot: I reviewed it for sponsoring and there's a > package at https://mentors.debian.net/package/plplot -- it's mostly > fine with one exception, it should have version 5.9.10-1, not version > 5.9.10-2. The older 5.9.10-1 package at the same location has more > issues and fixing them resulted in the 5.9.10-2 upload to mentors. I'll see if I can help for plplot and gdl on the short term, and we'll see later about adoption and team maintenance. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
gnudatalanguage and plplot not migrating
Hi guys, Do you need help fixing plplot and gnudatalanguage so they can reach testing? I think it would make sense to maintain them in a team, either debian-science (CC:) or debian-astro. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Fwd: Re: Bug#741538: Request for a debian-astro mailing list
Hi, I hereby support creation of the debian-astro mailing list. Kind regards, Thibaut. Le 17/03/2014 21:51, Ole Streicher a écrit : > Dear astronomy enthusiasts, > > please post to the bug <741...@bugs.debian.org> and express your > interest in having the mailing list. > > Best regards > > Ole > > Original-Nachricht > Betreff: Re: Bug#741538: Request for a debian-astro mailing list > Datum: Mon, 17 Mar 2014 20:14:24 +0100 > Von: David Moreno > An: Ole Streicher , 741...@bugs.debian.org > > On Thu, Mar 13, 2014 at 04:38:22PM +0100, Ole Streicher wrote: >> Dear list maintainers, >> >> Please create the mailing list debian-as...@lists.debian.org: > > Hello, > > Thanks for filling this request. As stated here: > https://www.debian.org/MailingLists/HOWTO_start_list > > ...please have other people interested on this mailing list post to the bug > to record public interest. > -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53280592.2070...@free.fr
Re: Request for Ideas - Astronomy working group
Le 13/03/2014 16:14, Thibaut Paumard a écrit : > Le 13/03/2014 15:34, Оlе Ѕtrеісhеr a écrit : >> Thibaut Paumard writes: >>> I was thinking a developer-oriented address would be better for >>> semi-private discussions, but Alioth list archives are public anyway. At >>> least, that would avoid too much noise when discussing with upstream. >>> >>> We need the developer list for the packages though, if we start moving >>> them from debian-science to debian-astro. >> >> I would do it like for debian-science: >> >> * debian-as...@lists.debian.org common discussion, developer and user >> * debian-astro-maintainer@lists.alioth - Maintainer: of the packages >> * debian-astro-commits@list.alioth - commit messages > > Good for me. > Done, I have created the debian-astro project and taken the liberty of adding you two as admins. I have chosen "Debian Astronomy & Astrophysics" for the full project name, which is not that important and can be changed later. I have created the two public lists debian-astro-maintainers (note the extra "s") and debian-astro-commits. Within a few hours, the projects will appear on Alioth and the lists be created, so dear fellow astronomers, don't hesitate to register to this Alioth project and the corresponding mailing lists. Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5321d642.10...@free.fr
Re: Request for Ideas - Astronomy working group
Le 13/03/2014 15:34, Оlе Ѕtrеісhеr a écrit : > Thibaut Paumard writes: >> I was thinking a developer-oriented address would be better for >> semi-private discussions, but Alioth list archives are public anyway. At >> least, that would avoid too much noise when discussing with upstream. >> >> We need the developer list for the packages though, if we start moving >> them from debian-science to debian-astro. > > I would do it like for debian-science: > > * debian-as...@lists.debian.org common discussion, developer and user > * debian-astro-maintainer@lists.alioth - Maintainer: of the packages > * debian-astro-commits@list.alioth - commit messages Good for me. > The maintainer list is a bit hidden and may be used for semi-private > discussions. However, I don't see their need. > > If there are no objections, I would send a bug report create the first > of these lists. OK. > > For the alioth project, I seem to have no access to "My Page" and > therefore cannot create anything there. Maybe because I am not a DD > (yet). Could I ask you to take this? You were prepared to do so anyway > :-) I'm doing it. Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5321cb48.2010...@free.fr
Re: Request for Ideas - Astronomy working group
Le 13/03/2014 11:32, Оlе Ѕtrеісhеr a écrit : > In the moment, I would not differ between users and developers, just > like debian-science (which also has no -devel). Just for the record, there is the debian-science-maintainers alioth list. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Request for Ideas - Astronomy working group
Hi, Le 13/03/2014 13:24, Andreas Tille a écrit : > But h, just let me try some provocation (after I have confirmed that > I have most probably the very same negative attitude about this way to > fool stupid people): Debian is about Free Software and technical > perfectness. We have some packages dealing with bible and quran and > bible and we even have some astrological software maitreya. *If* there > is some high quality software packaged by a gifted Debian Maintainer I > wonder what might be the best way to get a strong Debian Astro team and > whether we should follow an exclusive or an inclusive strategy. (End of > provocation) I actually would welcome high quality astrology packages, because of the cultural interest of astrology in History. However, what I don't want is trolls on the veracity of astrology, conspiracy theories regarding man on the Moon etc. But perhaps they are unavoidable. I'm fine with debian-astro. >> 2- the software that we personally use for certain tasks, make perhaps >> some publicity on the packages in Debian and what they can be used for; > > I'm not sure whether I agree here. I'd like to insist on the tasks > concept and this could open another door for unmaintained package lists. What I have in mind is rather extensive package reviews. Each software is documented on its own webpages, but say I want to produce a nice-looking chi² plot, how would I do this using Python, Yorick, MIDAS, GDL or whatever else? It a wild idea I know, I have not thought it through, and the Debian wiki may not be the best place for this, but I think we lack some trans-package documentation like this. >> A developer mailing-list such as debian-astro-devel@alioth would be very >> nice so we can all be in copy when each of us discuss something with >> upstream, for instance. > > We are using the alioth list more for internal discussion. For upstream > contact I'd recommend debian-astro.*@lists.debian.org - this is a > similar usage like you know from Debian Science. I was thinking a developer-oriented address would be better for semi-private discussions, but Alioth list archives are public anyway. At least, that would avoid too much noise when discussing with upstream. We need the developer list for the packages though, if we start moving them from debian-science to debian-astro. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5321bef3.4020...@free.fr
Re: Request for Ideas - Astronomy working group
Hi, Le 13/03/2014 10:08, Оlе Ѕtrеісhеr a écrit : > The idea of a sprint is also on my mind; however I am afraid that there > are still only very few people going to take part, and I feel still > unsure on how to organize it. A videocon would be in order. > You are however right: it is the right time to setup some Debian > infrastructure for it. I'll do that in the next days. I agree, I was about to set it up after this e-mail, but Ole is the right person (probably the most active project contributor in the field). For the bike-shedding: I propose to use one of debian-astro debian-astronomy pkg-astro This is my order of preference, although many people will associate the short name "astro" with astrology rather than astronomy. Yet "astro" is shorter than astronomy and is also a short-hand for astrophysics. > One point here is the Wiki. As you point out, there is no use for > listing packages there. What else could be its content? I have collected > some ideas for the debian-astronomy blend which I could put there; > however the Wiki is designed for users and not developers, so I doubt > that this is the right place. However, were should I put this? Mailing > list is not optimal, since I'd like to have an evolving document. IMHO, a wiki is a good place to document: 1- who we are, the domains of expertise, the contacts that we have with upstream, the software project in which we are involved upstream; 2- the software that we personally use for certain tasks, make perhaps some publicity on the packages in Debian and what they can be used for; 3- our TODO list and timeline, things that I don't think can be efficiently represented in the blend file (Andrea, please correct me if I'm wrong here. IIRC, the blend can be used to document prospective packages, but not in generic terms). A developer mailing-list such as debian-astro-devel@alioth would be very nice so we can all be in copy when each of us discuss something with upstream, for instance. Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53218611.6060...@free.fr
Re: Bug#740728: ITP: yorick-ynfft -- nonequispaced fast Fourier transform for Yorick
Le 06/03/2014 14:39, Andreas Tille a écrit : > Hi Thibaut, > > since I guess you will maintain this package in Debian Science team it > would be great to CC this list (which I'm doing now). > Right, thanks for the reminder. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53187b01.8050...@free.fr
Re: Request for Ideas - Astronomy working group
Le 15/01/2014 12:10, Olе Streicher a écrit : > Andreas Tille writes: >> But as I said, some IRC meeting might do as well for a very first thing. > > For me, a Sprint in Potsdam in March (as Steffen proposed) would be fine. Hi, I don't think I'll be able to travel to Potsdam in March. I can join by video, though. Also, I'll be in Heidelberg for a couple of days mid-February, I can certainly meet Florian there. The annual meeting of the French astronomical will be in Paris, June 3-6. http://2014.sf2a.eu/ Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Request for Ideas - Astronomy working group
Le 10/01/2014 11:27, Andreas Tille a écrit : > Hi Ole, > > at first thanks for all your great work on astronomy packages. > > On Thu, Jan 09, 2014 at 10:41:42PM +0100, Ole Streicher wrote: >> Dear all (astrophysicists, amateurs, scientists, other), >> >> there are now quite some people around that are interested in using >> Debian for astronomy related tasks. It may be a good idea if we could >> somehow bring us together and see where we can coordinate our efforts. > > +1 Hi, I would very much support the creation of an Astronomy working group, but I am not quite sure how we would actually use an Alioth project and mailing list, especially if the packaging remains under debian-science umbrella which seems the right thing to me. Well, perhaps we should just give it a try :-) Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: [Repost] RFS: cpl-plugin-* [ITP] -- ESO data reduction pipeline recipes
Le 14/10/2013 11:12, Olе Streicher a écrit :
> Dear mentors,
>
> Since I didn't get response since three weeks, I am reposting my
> Requests For Sponsorship so that it does not get lost:
>
Hi Ole,
Sorry I thought your usual sponsor would help you here.
I should be able to start having a look next week if nobody volunteers
by then. Please ping me privately.
Do you have off-the-shelf sample data for each plug-in, so that I don't
need to look for them myself on the ESO archive? Don't bother for
SINFONI, I have some lying around.
Regards, Thibaut.
> I have prepared five packages that have a similar structure and are to
> be used as plugins for the "cpl" library and the "esorex" and
> "python-cpl" packages. Each plugin contains the software to process
> ("reduce" in the astronomer's slang) the data of one instrument mounted
> at the Very Large Telescope (VLT) of the European Southern Telescope
> (ESO) in Paranal:
>
> * cpl-plugin-hawki/1.8.12-1
> * cpl-plugin-sinfo/2.3.3-1
> * cpl-plugin-fors/4.9.23-1
> * cpl-plugin-giraf/2.11.1-1
> * cpl-plugin-amber/4.2.2-1
>
> RFS:
> * HAWK-I http://bugs.debian.org/723962
> * SINFONI http://bugs.debian.org/723968
> * FORShttp://bugs.debian.org/723970
> * GIRAFFE http://bugs.debian.org/723971
> * AMBER http://bugs.debian.org/723972
>
> Source package URL:
> * HAWK-I http://mentors.debian.net/package/cpl-plugin-hawki
> * SINFONI http://mentors.debian.net/package/cpl-plugin-sinfo
> * FORShttp://mentors.debian.net/package/cpl-plugin-fors
> * GIRAFFE http://mentors.debian.net/package/cpl-plugin-giraf
> * AMBER http://mentors.debian.net/package/cpl-plugin-amber
>
> All packages are GPL and upstream developer is ESO. A common overview
> for the pipelines is on http://www.eso.org/sci/software/pipelines/
>
> The packages are all built using a common template, so reviewing all
> five should be not much more work than for one.
>
> Relevant differences between the packages:
>
> * The copyright files are special since usually the upstream source code
> is collected from several sources. I always checked where their use can
> be replaced by Debian packages (like sextractor in cpl-plugin-fors).
>
> * Dependencies differ a bit (libfftw, libwcs).
>
> * The packages are usually accompanied with a number of files used for
> calibration purposes. Due to their size, I did not always include them.
> I have chosen a limit of ~10MB package size, so that calibration
> packages exceeding this size will not include the files but download
> them during the package installation. (cpl-plugin-amber-calib).
>
> Best regards
>
> Ole
>
>
signature.asc
Description: OpenPGP digital signature
Re: Bug#710248: RFS: fitsverify/4.16 [ITP] -- FITS File Format-Verification Tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Uploaded. Le 31/05/2013 12:19, Ole Streicher a écrit : > Hi Thibaut, > > Am 29.05.2013 14:38, schrieb Thibaut Paumard: >> I don't think the FTP master will let the package in with just >> this short notice (so short that I missed it despite looking for >> it). Maybe they would be OK if you reproduced said e-mail in >> full. > > I have included the E-mail confirmation into the copyright file > and re-uploaded it to mentor.debian.net. > >> But the best would of course be to get upstream to just add a >> copyright notice at the beginning of each source file plus a >> copy of the applicable license and release a new tarball. It >> should be about 15 minutes of their time, well spent. > > I have asked upstream, but he refused to do this on a short term. > Instead he recommended that I could inserting the License.txt > myself (what I basically did by creating the debian/copyright > file). So I would guess it is completely OK to insert the package > into Debian. > > Best regards > > Ole > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJRrKbpAAoJEJOUU0jg3ChAPKUQAIYkdzimlsMTc9Zc2a26AJ9y HAQbr7MoeJ3MvdmAtFkCzVEMOgp/v0rauanCoNQePIFyf83NudQUEAm/uy3u3APM qOk3e2zuB8zUFzSXgsRkdz9kwL2sk41SXJnSMjMgKBxERv/6By2h/6ZY9+jdEIZN K9i7TwOXZLcqEfdPjWNrCh5jeBTrjhluHQu+W8Fb1XHLlKAcreCMp7vBDwCGb2Wi Lr2RCApck6nJKjylZrGAI7m0DD0mX3cAtOUQ+uqYR3nf2z2ULG8KZSVOr30Pi6bz zmRHHWnS171xBBN/bnPb2KEfZsU/zuBCUOksivdNAjmy5IVHUbyOfXZ5QRJahp4d W/w5+O0O3Vo2IpUzE320+yY/4rYqCCtAXzVnTpRU64GgAEGQTmJiplKngtYucXQa rfv2NzYLsOKddtoVWsR2C8I1wyCaO3ida8rTs9yndGFwJoCpIHZZlMmF/hb+zTVF KBP2GE57zaNnWVfy48hlDtqPL43Ckws2HLvxXfXBjbcX9329CsgiGs6Mq2kThAnt uOSpG3x8iPemPorrnCJKdNuJofMxcm2eSD3vVoflATwPB65ePtlUFKHn6VtqHKdQ 1RxBcGEwFVHwPtfzPPeWmWNGtSDXD/d71NodpV3NvtMnJTa9/Th2eTWR64otzGep bxiu9HGEizd5s89ItTzT =O6aT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51aca6fb.9000...@debian.org
Re: Bug#710248: RFS: fitsverify/4.16 [ITP] -- FITS File Format-Verification Tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 29/05/2013 14:02, Ole Streicher a écrit : > Hi Thibaut, > > Am 29.05.2013 13:44, schrieb Thibaut Paumard: >> Le 29/05/2013 12:44, Ole Streicher a écrit : >>> I am looking for a sponsor for my package "fitsverify" >> package looks good. I couldn't find upstream's license and >> copyright statement though, where is it? > > Not there. I asked and got a confirmation from William Pence that > the license is the same as for CFITSIO. I've put a note for that > in debian/copyright. > > Best > > Ole Hi Ole, I don't think the FTP master will let the package in with just this short notice (so short that I missed it despite looking for it). Maybe they would be OK if you reproduced said e-mail in full. But the best would of course be to get upstream to just add a copyright notice at the beginning of each source file plus a copy of the applicable license and release a new tarball. It should be about 15 minutes of their time, well spent. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJRpfawAAoJEJOUU0jg3ChA/lQQAJNegk1RkQ47pb6Yoase3NES FWLoCshkfn8SnHiHF1SWLZcG001hi/y94Xo/QoR14rMSJzRjitpV52FmloLdrlUn j/QjBG5XAJpKhWm33rKmaojyQB52jzD0uuvSfbptg87ZampsmbOK+8oGhxbQp5/a noS3jN5WjV+llo6C2Wp1j6t47YZzC/Mxcxe1WZEfa+KTcAdsSKFkJdLh8Hs/eoxd 2C66t/koDj/gdB1EKTZq7pXIe+kV3VFQeYpPOZmcNdkkyzqWN0oaNRHcdEZEddRO N8IhF3PVKSvMVzOs6qBcsmxWqinDZ9csu7Q4wDSX7OuH3SB2JfpxxT6RUhsRj9k4 GpT6vMnoB0mdAraLyZg3yy8iUCze0W47LQjQAx92SYofl7HbqNzL/tGrNo2lRM2z hJQvCrEV5X57G8hRykzywgMLsunf9F6krgT/X+ufXDU7EPOTM5N3OoKQrEJc/TqO Vq+P8FDixgUcfs4qrAOp7q77UFkp9LFaY/19j8dcrij0+kycVXrsN4UMMkPIRAe0 KjsVLgpp214KFbJ8G3W1ovg0Ot5MhJEesBc0S2D/1xdOTNTorrfIxZo83N/sIt4O aVWJz4AeTEHAOl7CGzLjh4mMjzpd5xxTAxE6Ms7eQfz3Qj6dP50AFbacOMrokpEW IpQBxFhS0a7ix/YJtdGB =HGAk -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a5f6b0.8010...@debian.org
Re: Bug#710248: RFS: fitsverify/4.16 [ITP] -- FITS File Format-Verification Tool
Le 29/05/2013 12:44, Ole Streicher a écrit : > Package: sponsorship-requests > Severity: normal > X-Debbugs-Cc: debian-science@lists.debian.org > > Dear mentors, > > I am looking for a sponsor for my package "fitsverify" Hi Ole, package looks good. I couldn't find upstream's license and copyright statement though, where is it? Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a5ea0c.4080...@free.fr
Re: Bug#681968: RFS: scscp-imcce/0.6.4+ds-1 [ITP] -- IMCCE SCSCP C Library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 21/07/12 13:38, Jerome BENOIT a écrit : > Hello: > > On 19/07/12 16:13, Jerome BENOIT wrote: >> On 18/07/12 11:22, Thibaut Paumard wrote: >>> Le 18/07/12 10:40, Jerome Benoit a écrit : >>>> I am looking for a sponsor for my package "scscp-imcce" >>> [...] >>>> >>>> SCSCP stands for Symbolic Computation Software Composibility >>>> Protocol. This protocol is developed by the European project >>>> SCIEnce - Symbolic Computation Infrastructure for Europe: >>>> http://www.symbolic-computing.org/ >>> >>> Dear Jérôme, >>> >>> What about putting your package under collaborative maintenance >>> in by the Debian Science Team? >> >> I am on my way to do so. >> >> See: >>> >>> http://debian-science.alioth.debian.org/debian-science-policy.html >>> >>> >>> It may then be easier for you to find a sponsor within the team. >>> >>> I can help you with that (setting up a git repository on alioth >>> and all) >> >> I will have an attentive look before asking. > > I have an account at Debian-Science. But I am confused now because > it is not clear what is the next step. (The document seems very > terse.) > > Any hint to step further is welcome. (Moving the discussion to debian-science, where it belongs). You mean to set-up the git repository? Once you have an Alioth account and you are in the debian-science group, you can ssh @vasks.debian.org cd /git/debian-science/packages mkdir .git cd .git git init --bare On your local machine, you should then be able to use: git checkout git+ssh://@git.debian.org/git/debian-science/packages/.git or git remote add alioth git+ssh://@git.debian.org/git/debian-science/packages/.git Make sure the package itself follows the debian-science policy. Good luck. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQCwtKAAoJEJOUU0jg3ChACiUP/AmjAnAGU3wvVV5XmdY1EV8w s7avXkqaBo6YK46xIU83PXb3O7QRQLretMyDD77cx4NIGVZ62AFs5DTqFRQqU88s J/kmz5mwlf/BU7ZVIhjRyb9niZf22NBRUxQnkVgzy5U80PPqEV9Z4z05Ms4HqwFz uHCqKsLvVS/5nVTIJgoG9VzFZlw8yzfDGkN3t64fBTIEusjKNGZrTzHg4v8Qohtp 4V8b9wm4kF4XwoP4pC62AZjmDuCDWPTLRxUS9OOqyQNY0htH9Gc4sGORQqr7zKL7 oA54VmzrxF55MJ9JqTuXsomGyTzwj96avgB9zaF6pb5KbHTjxwUoH7zRXKM3Ouzr YVGnQuQhU3yQ1qCKYZu7/QoT/lqanQgpJx/XpTaw+0iUGr4T2DiAtl/JYDMqBNVG d+uON9V5dNNc2oSJLfJJCVdKKyHtTfD9RMn6erveE8bBQVXJX3ZkqlVzX3AAl3wT 77jeZN+EtUkc5s4bHf65CT+TiexnDqar55KDsgD84C3sTwUTBy2pikgAAZdW4XDB 8gPnCSR4LlvgY2OI5ztNnPGzhpuuyBl4JLyO9OCVSdBsOSlFAZovnFFC6kEY1c5g uUVU0N5uan6V/1Nqg3JRRHMAshV8znr8QT/LQGUORrhdcCeeNee4rZMcV8r7ulQa deCPKWaNUmz0C+Ak3ZHT =Rgh8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/500b0b4b.3030...@users.sourceforge.net
Re: Bug#682205: ITP: heasoft-fv -- General FITS file browser/editor/plotter with a gui
Le 20/07/12 13:46, Andreas Tille a écrit : > Hi Ole, > > in which Debian Science task(s) would this fit according to your > opinion? I'd volunteer to put this into the proper task file if you do > not want to dive into this yourself, but some hint would help > Hi, I have replaced the "fv" stanza for the old package with a simple "Depends: heasoft-fv" in the astronomy task. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50094b28.7090...@free.fr
Bug#681314: unblock: yp-svipc/0.14-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock source package yp-svipc.
It builds the following binary packages:
- python-svipc
- python3-svipc
- yorick-svipc
I attach a debdiff and explain the changes below.
1- Hardening flags release goal:
http://bugs.debian.org/680216
Fixed for python*-svipc by putting CPPFLAGS in CFLAGS, for yorick-svipc by
passing Y_LDFLAGS etc. to make.
2- 0.14-1 failed to build on kfreebsd-any:
http://bugs.debian.org/679919
Portability code for *BSD and Darwin is erroneously activated on GNU/kFreeBSD,
which doesn't need it.
Fixed for python*-svipc by patching setup.py; for yorick-svipc by passing
PKG_CFLAGS explicitly to make.
3- the yorick-full meta-package (src:yorick), already unblocked, is waiting for
yorick-svipc to build on kfreebsd-* before it can migrate.
http://release.debian.org/migration/testing.pl?package=yorick
Fixing the above-mentioned FTBFS takes us halfway through to letting yorick
migrate (Yorick is also waiting for yorick-gyoto, I'm working on it).
Kind regards, Thibaut.
unblock yp-svipc/0.14-2
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores)
diff -Nru yp-svipc-0.14/debian/changelog yp-svipc-0.14/debian/changelog
--- yp-svipc-0.14/debian/changelog 2012-06-22 11:25:24.0 +0200
+++ yp-svipc-0.14/debian/changelog 2012-07-11 13:41:39.0 +0200
@@ -1,3 +1,14 @@
+yp-svipc (0.14-2) unstable; urgency=low
+
+ * Bug fix: "don't rely on yorick to pass the fortified build flags"
+(Closes: #680216).
+ * Bug fix: "FTBFS on kfreebsd-i386 and kfreebsd-amd64: "conflicting
+types for semtimedop"" (Closes: #679919). Involves a patch for the
+Python modules (fix_679919_kFreeBSD_FTBFS) and passing PKG_CFLAGS when
+building the Yorick plug-in.
+
+ -- Thibaut Paumard Wed, 11 Jul 2012 13:41:39 +0200
+
yp-svipc (0.14-1) unstable; urgency=low
* Initial release (Closes: #668841)
diff -Nru yp-svipc-0.14/debian/patches/fix_679919_kFreeBSD_FTBFS yp-svipc-0.14/debian/patches/fix_679919_kFreeBSD_FTBFS
--- yp-svipc-0.14/debian/patches/fix_679919_kFreeBSD_FTBFS 1970-01-01 01:00:00.0 +0100
+++ yp-svipc-0.14/debian/patches/fix_679919_kFreeBSD_FTBFS 2012-07-11 13:58:53.0 +0200
@@ -0,0 +1,24 @@
+Description: fix 679919 FTBFS on kfreebsd-*
+ upstream provides an implementation of semtimedop which they use on FreeBSD
+ and MacOS. It is eroneously used also under GNU/kFreeBSD and GNU/Hurd.
+ This patch disables it altogether for the python modules.
+Author: Thibaut Paumard
+Origin: vendor
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679919
+Forwarded: no
+Last-Update: 2012-07-11
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/setup.py
b/setup.py
+@@ -32,10 +32,8 @@
+('SVIPC_NOSEGFUNC', None),
+]
+
+ platform=uname()[0]
+-if platform != 'Linux':
+- define_macros.append(('SVIPC_HACKS', None))
+
+ extra_compile_args=[
+#'-g3',
+#'-ggdb3'
diff -Nru yp-svipc-0.14/debian/patches/series yp-svipc-0.14/debian/patches/series
--- yp-svipc-0.14/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ yp-svipc-0.14/debian/patches/series 2012-07-11 14:08:11.0 +0200
@@ -0,0 +1 @@
+fix_679919_kFreeBSD_FTBFS
diff -Nru yp-svipc-0.14/debian/rules yp-svipc-0.14/debian/rules
--- yp-svipc-0.14/debian/rules 2012-06-22 11:25:06.0 +0200
+++ yp-svipc-0.14/debian/rules 2012-07-11 14:17:49.0 +0200
@@ -6,6 +6,7 @@
# This has to be exported to make some magic below work.
export DH_OPTIONS
+CFLAGS += $(CPPFLAGS)
%:
dh $@ --with python2 \
@@ -23,7 +24,10 @@
set -ex; for python in $(shell py3versions -r); do \
$$python setup.py build; \
done;
- cd yorick; make
+ cd yorick; make COPT_DEFAULT="" \
+ Y_CFLAGS="$(CFLAGS)" \
+ Y_LDFLAGS="$(LDFLAGS)" \
+ PKG_CFLAGS="-I ../common"
override_dh_auto_install:
dh_auto_install
Bug#679512: RFS: yorick-mpeg/0.1-2 [Release goal: hardening]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "yorick-mpeg". This upload fixes issues with the hardening flags, a Wheezy release goal (in addition to complying with the debian-science policy). * Package name: yorick-mpeg Version : 0.1-2 Upstream Author : Dave Munro * URL : https://github.com/dhmunro/yorick-mpeg * License : BSD Section : science It builds those binary packages: yorick-mpeg - MPEG output support for the Yorick language To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yorick-mpeg Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/y/yorick-mpeg/yorick- mpeg_0.1-2.dsc The package is also available on Alioth: Vcs-Git: git://git.debian.org/git/debian-science/packages/yorick-mpeg.git Vcs-Browser: http://git.debian.org/?p=debian-science/packages/yorick-mpeg.git To test the installed package: $ yorick Copyright (c) 2005. The Regents of the University of California. All rights reserved. Yorick 2.2.02 ready. For help type 'help' > #include "mpgtest.i" > mpgtest 200.00 frames of filled surface drumhead completed in 10.763189 sec Rate for filled mesh is 64.096504 frames/(CPU sec), 18.581681 frames(wall sec) > quit $ mplayer test.mpg Changes since the last upload: * Move to maintenance to the debian-science team. Update debian/control to comply with their policy: + change Maintainer, put self in Uploaders; + DM-Upload-Allowed: yes; + fill-in Vcs-* fields; + Priority is extra. * Configure in a patch rather than running yorick -batch make.i at build time which may cause unpatch to fail because it's not a good idea to modify the same file (Makefile) both at patch-time and build-time. * Fix machine readable copyright format * Remove dh-make template header from rules * Suggest yorick-av * Simplfiy debian/rules with short dh notation * Fortify (don't rely on yorick to provide right flags) Regards, Thibaut Paumard -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629095341.5127.56756.reportbug@localhost.localdomain
Re: Moving yorick-* to debian-science (just) in time for wheezy
Le 29/06/12 11:37, Andreas Tille a écrit : > Hi Thibaut, > > I once started helping you with this and I could do the upload of these > two packages as well. However, I can and will not promise that I will > reach the freeze deadline. So if you might find some other volunteer who > might spare some time cycles this would be more safe. > Dear Andreas, Thanks for your message. You may have noticed one minute ago that I am sending RFSes for the two packages. I have updated them this morning. The goal, if possible, is to: * move maintainance to debian-science, ensure the packages build fine with git-buildpackage etc. * fix one issue with the hardening flags. I have spent about two days doing the same for the rest of the yorick packages :-) The move to debian-science is nice to have, but the hardening flags is a release goal (which I thought I had fixed already, but I was wrong). Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fed7990.1080...@free.fr
Bug#679509: RFS: yorick-av/0.0.1-2 [Release goal: hardening]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "yorick-av". This upload fixes issues with the hardening flags, a Wheezy release goal: http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags In addition, this upload puts yorick-av in compliance with the debian-science team like the rest of the Yorick packages. * Package name: yorick-av Version : 0.0.1-2 Upstream Author : Thibaut Paumard * URL : http://paumard.github.com/yorick-av/ * License : permissive Section : science It builds those binary packages: yorick-av - write movies from Yorick in various formats To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yorick-av Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/y/yorick-av/yorick- av_0.0.1-2.dsc yorick-av is also available from Alioth: Vcs-Git: git://git.debian.org/git/debian-science/packages/yorick-av.git Vcs-Browser: http://git.debian.org/?p=debian-science/packages/yorick-av.git Changes since the last upload: * Move to maintenance to the debian-science team. Update debian/control to comply with their policy: + change Maintainer, put self in Uploaders; + DM-Upload-Allowed: yes; + fill-in Vcs-* fields; + Priority is extra. * Fix machine-readable copyright format. * Add lintian override about no fortified functions. * Fortify (don't rely on yorick to pass the right build flags) Note the lintian warning remains. Yet you will see the correct flags during build. Regards, Thibaut Paumard -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629093655.4117.41016.reportbug@localhost.localdomain
Moving yorick-* to debian-science (just) in time for wheezy
Dear fellow Debian Scientists, After some discussion on this list, I'm trying to move all of the Yorick packages to team maintenance within the science team. This involves one upload per package with little changes to comply with the debian science policy. Most of this I can do on my own, but two young packages still lack the DMUA field. Would someone be kind enough to upload them within the next few days? The purpose of both packages is to provide yorick users with the ability of saving animations as movie files. yorick-mpeg has been around for some time but has only been uploaded recently in the Debian archive. It concentrates on MPEG1 and builds fine on every arch (although I have not been able to check yet whether it provides meaningful output on all arches). yorick-av attempts to be a compatible replacement which uses LibAV to write movies in more recent formats (Ogg/Voris, MP4...). It's therefore better than yorick-mpeg when it works, but it is bound to have issues during LibAV transitions, and doesn't run properly on some arches (yet). Help welcome, by the way. yorick-av: http://mentors.debian.net/package/yorick-av git://git.debian.org/git/debian-science/packages/yorick-av.git This package runs a test suite at run time. You can also run yorick -batch check.i from the built source tree for a more ex(t|p)ensive test. It will create movies in various formats which you can then visually check with mplayer. yorick-mpeg: http://mentors.debian.net/package/yorick-mpeg git://git.debian.org/git/debian-science/packages/yorick-mpeg.git To test this package, first install it, then launch yorick, then within yorick: > #include "mpgtest.i" > mpgtest > quit and finally check the file called test.mpg. Best regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Two astronomy-related RFSes up for sponsoring (since 2 months)
Le 25/06/12 19:06, Thibaut Paumard a écrit : > Dear Andreas, > > Le 25/06/12 17:58, Andreas Tille a écrit : >>> gyoto: General relativistic geodesic integration and ray-tracing > >> Moreover I do see some room for enhancement for this package. I wonder >> whether you have some reason to stick to debhelper 7 for this package >> (may be some backporting plan might rectify this). However, even dh 7 >> knows short debhelper notation which makes team maintenance way more >> easy. Would you consider changing this? I would not insist on this as >> a condition for sponsering but I'd really recommend it. Actually the rules file is based on the short dh notation, only I had to add several custom rules to get the behaviour I wanted. I may be able to simplify it by using a more recent version but that will take some time to check that all the files are compiled and installed correctly. >> What I really like you to do is to remove the dh-make template (except >> if Joey Hess and Craig Small did really worked on this very package >> ;-).) > > Ok, I'll do that tomorrow :-) Done :-) Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe8c4d0.3040...@free.fr
Re: Two astronomy-related RFSes up for sponsoring (since 2 months)
Dear Andreas, Le 25/06/12 17:58, Andreas Tille a écrit : > Hi Thibaut, > > On Mon, Jun 25, 2012 at 11:58:26AM +0200, Thibaut Paumard wrote: >> I have sent these two RFS a little bit more than two months ago. > > I'm afraid that these packages will not make it any more into Wheezy > because the new queue will not be processed until the Freeze date - at > least this is the information I have. I realize it may be too late for Wheezy already. I just _had_ to try one last time :-) > But finally you did not really > wasted your time - Debian development is not really a discrete step from > release to release but a continuous flow. Certainly, having those packages around even if not in the official repository or in the next release is already valuable :-) >> yp-svipc: System V InterProcess Communication > I uploaded this package to the new queue because I think it is OK. > > The only issue I have that as always I wonder why the package is not yet > mentioned in the astronomy(-dev ??) task of Debian Science. Could you > please suggest reasonable task(s) for the binary packages of this source > package? Ideally yorick-svipc should be listed as a dependency of yorick-full, in the astronomy task. But doing that before yp-svipc enters unstable would render yorick-full uninstallable... I don't understand how tasks work, is it harmless to include a package which is not yet in testing (or even not in the archive at all)? >> gyoto: General relativistic geodesic integration and ray-tracing > I added to the package a debian/upstream file featuring citation > information when I have seen flashing a hint about a publication when > watching at the build log. As a general note: Please do upstream and > your users a favour and add citation information if there are scientific > publications about packages available. It really helps strengthening > Debian inside the scientific community. Thanks, good point. > Moreover I do see some room for enhancement for this package. I wonder > whether you have some reason to stick to debhelper 7 for this package > (may be some backporting plan might rectify this). However, even dh 7 > knows short debhelper notation which makes team maintenance way more > easy. Would you consider changing this? I would not insist on this as > a condition for sponsering but I'd really recommend it. I'm guessing this is mostly because I started packaging gyoto a long time ago, before I understood enough of the dh shorthand to feel confident using it. Not sure I'll have time for this conversion this week (but as you said, this package is unlikely to reach wheezy anyway, I'll push it into backports soon enough). > What I really like you to do is to remove the dh-make template (except > if Joey Hess and Craig Small did really worked on this very package > ;-).) Ok, I'll do that tomorrow :-) > I decided to add gyoto to the astronomy task - please confirm that this is > all what should be added or whether possibly libgyoto0-dev would be a > good thing for astronomy-dev (or whatever) Yes, I would put libgyoto0-dev in astronomy-dev, gyoto in astronomy, and at some point add yorick-gyoto to yorick-full. > >> I'd be really, really grateful if someone from the community would have >> a look. > > Hope this helps you a bit while I'm on Debian Science meeting in Grenoble. :-) Yes, that helps a lot :-) > Kind regards > > Andreas. > Regards, Thibaut -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe89aa4.6060...@free.fr
Two astronomy-related RFSes up for sponsoring (since 2 months)
Hi, I have sent these two RFS a little bit more than two months ago. I have put a lot of effort into them (for instance I've worked with upstream to fix bugs in yp-svipc and port it to Python 3) and I'd be sorry if they missed Wheezy for lack of a sponsor. yp-svipc: System V InterProcess Communication ITP: http://bugs.debian.org/668841 RFS: http://bugs.debian.org/669209 http://mentors.debian.net/package/yp-svipc This package builds plug-ins for the Python and Yorick interpreter to expose the SysV IPC to interpreted code. This permits building parallel codes and sharing memory segments between processes. The Yorick plug-in can be used by [YAO], an adaptive optics simulator, to make faster computations thanks to parallelisation. The combination of the two plug-ins allows building mixed Python/Yorick applications. [YAO] http://packages.debian.org/wheezy/yorick-yao gyoto: General relativistic geodesic integration and ray-tracing ITP: http://bugs.debian.org/640809 RFS: http://bugs.debian.org/669016 http://mentors.debian.net/package/gyoto Gyoto allows computing trajectories (e.g. of stars) and ray-tracing images in the vicinity of compact objects such as black holes. It is usable as a C++ library, a stand-alone utility executable, and a Yorick plug-in. I'd be really, really grateful if someone from the community would have a look. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Maintaining yorick in Vcs at debian.org (Was: RFS: yorick/2.2.02+dfsg-2)
Le 21/06/12 11:33, Andreas Tille a écrit : > On Wed, Jun 20, 2012 at 06:38:06PM +0200, Thibaut Paumard wrote: >> I have now pushed Yorick to Alioth. >> >> I happen to have uncovered a severity=important bug: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678276 >> This bug breaks PNG output from Yorick on ia64 and may have other >> unknown effects. >> >> I have prepared a new upload but I can't upload it myself as yorick is >> still in NEW. > > This has changed now (as I also realised to late ;-)) Thanks, I'll re-upload when I get a reasonable connection. > >> Would someone be so kind as to upload it for me well? > > While I could use the orig.tar.gz from `apt-get source yorick` I would > like to mention that the Git archive is lacking an upstream branch. So > > $ git-buildpackage I don't use git-buildpackage myself, but the git repository definitely has the 4 branches described in debian/README.source, which follows the gbp convention: thibaut-guest@vasks:/git/debian-science/packages/yorick.git$ git branch * master pristine-tar upstream upstream-non-dfsg By the way, I use xz compression. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe32ca5.2040...@free.fr
Re: Maintaining yorick in Vcs at debian.org (Was: RFS: yorick/2.2.02+dfsg-2)
Dear Andreas et al., Le 14/06/12 10:01, Andreas Tille a écrit : > On Wed, Jun 13, 2012 at 10:50:54PM +0200, Thibaut Paumard wrote: >>>> Alternatively, one can download the package with dget using this command: >>>> >>>> dget -x >>>> http://mentors.debian.net/debian/pool/main/y/yorick/yorick_2.2.02+dfsg-2.dsc >>> >>> I wonder why you do not maintain the package at git.debian.org. This >>> would make for sponsors and other team members way easier. I tried >>> >>>debcheckout --user tille yorick >>> >>> >> >> Hi Andreas, >> >> The reason is I never invested enough time to understand how to do that >> (or even how to properly package under git). I haven't pushed my changes >> to github yet. > > So I just uploaded the package as is to get the metapackage in. I have now pushed Yorick to Alioth. I happen to have uncovered a severity=important bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678276 This bug breaks PNG output from Yorick on ia64 and may have other unknown effects. I have prepared a new upload but I can't upload it myself as yorick is still in NEW. Would someone be so kind as to upload it for me well? The package can be found: - on Alioth: git.debian.org/git/debian-science/yorick.git - on mentors: http://mentors.debian.net/package/yorick http://mentors.debian.net/debian/pool/main/y/yorick/yorick_2.2.02+dfsg-3.dsc (The revision is not tagged in git as I'm not sure it will actually reach master in its current form). Changes: - fixing 678276: + introduce new patch fix-weird-alignment + add -DMM_LIN_ALIGNMENT to CPPFLAGS on ia64 in debian/rules - fixing 584136: remove HPPA from the list of arches the tests should not be ran on in debian/rules - debian-science policy: edits in debian/control - rewrite README.source. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Non DFSG-free files and git.debian.org (Was: Maintaining yorick in Vcs at debian.org)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 18/06/12 11:06, Thibaut Paumard a écrit : > Hi, > > Le 17/06/12 00:07, Andreas Tille a écrit : >> On Thu, Jun 14, 2012 at 04:14:07PM +0200, Thibaut Paumard wrote: >>> >>> - Yorick is only distributed from github (no distinct tarballs, >>> just git tags). It has to be repackaged to meet the DFSG. What >>> I was experimenting with on github is: - one branch mirroring >>> upstream (contains non-DFSG-free material); - one branch for >>> the DFSG free source; - one branch for the Debian packaging. Is >>> that a reasonable approach for Alioth or should the >>> non-DFSG-free files never enter the debian.org domain? >> For the record, I have committed yorick with this set-up on Alioth. Cheers, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/giiIACgkQ+37NkUuUiPGMYgCcDrRKrRkVb85pq4VAWCdN0b5l qK0An1TOdM2QcRQ/1XA/XgExyzcTfT4p =JED5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe08a22.80...@users.sourceforge.net
Non DFSG-free files and git.debian.org (Was: Maintaining yorick in Vcs at debian.org)
Hi, Le 17/06/12 00:07, Andreas Tille a écrit : > On Thu, Jun 14, 2012 at 04:14:07PM +0200, Thibaut Paumard wrote: >> >> - Yorick is only distributed from github (no distinct tarballs, just >>git tags). It has to be repackaged to meet the DFSG. What I was >>experimenting with on github is: >> - one branch mirroring upstream (contains non-DFSG-free material); >> - one branch for the DFSG free source; >> - one branch for the Debian packaging. >>Is that a reasonable approach for Alioth or should the non-DFSG-free >>files never enter the debian.org domain? > > I have no experience with github at all. If there is no release tarball > I usually create a script debian/get-orig-source and add this to > debian/watch (I guess it is somehow possible to parse the web interface > from github for new tags) and also call it in debian/rules target > get-orig-source. The question at hand is rather: should I make every effort to avoid importing those non-DFSG-free files from the debian.org domain, or is it OK to have them on git as basically a working area? It's certainly safest to just import de repacked tarball, but its technically superior to clone the upstream "non-free" repository. I don't see any intermediate solution whihc would retain most of upstream's history without introducing the incriminated files in the repository. I wonder whether I could get something sensible by rebasing my DFSG branch on the initial clean-up and pushing only that branch to git.debian.org. (By sensible I mean I would like to be able to merge upstream commits without re-introducing the non-DFSG files). Does anybody from science have any suggestion/experience on that matter? Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Maintaining yorick in Vcs at debian.org (Was: RFS: yorick/2.2.02+dfsg-2)
Le 14/06/12 10:01, Andreas Tille a écrit : > On Wed, Jun 13, 2012 at 10:50:54PM +0200, Thibaut Paumard wrote: >>>> Alternatively, one can download the package with dget using this command: >>>> >>>> dget -x >>>> http://mentors.debian.net/debian/pool/main/y/yorick/yorick_2.2.02+dfsg-2.dsc >>> >>> I wonder why you do not maintain the package at git.debian.org. This >>> would make for sponsors and other team members way easier. I tried >>> >>>debcheckout --user tille yorick >>> >>> but failed becuase Vcs-Git points to github.com where I do not have any >>> login nor could I commit some changes. For the sake of getting the >>> metapackage which I do consider very interesting I would make some >>> exception and would consider sponsering it anyway but otherwise I would >>> probably insist in sticking to Debian Science policy and ask for using a >>> debian.org hosted Vcs. Would you consider a move or do you want to >>> stick to the current location for the moment? >>> >> >> Hi Andreas, >> >> The reason is I never invested enough time to understand how to do that >> (or even how to properly package under git). I haven't pushed my changes >> to github yet. > > So I just uploaded the package as is to get the metapackage in. Thanks, Andreas. > >> Note that at the moment the package is not under the debian science >> packaging team umbrella. And this is also mostly because I was unsure >> how to proceed. >> >> I would be willing to go in that direction in the future, of course. > > I would definitely ask for this. Please try to follow Debian Science > policy[1] closely and use the debian.org infrastructure to enable > effective team maintenance. I have two questions that I need to decide before I commit anything to alioth: - since Yorick and its add-ons make 17 source packages (and growing), wouldn't it make sense to put their respective repositories in a subdirectory: /git/debian-science/packages/yorick/yorick.git /git/debian-science/packages/yorick/yorick-foo.git /git/debian-science/packages/yorick/yorick-bar.git - Yorick is only distributed from github (no distinct tarballs, just git tags). It has to be repackaged to meet the DFSG. What I was experimenting with on github is: - one branch mirroring upstream (contains non-DFSG-free material); - one branch for the DFSG free source; - one branch for the Debian packaging. Is that a reasonable approach for Alioth or should the non-DFSG-free files never enter the debian.org domain? > Further things to consider: I'm not a user of yorick but from my > feeling it would be rather typical to name the metapackage "yorick" and > the former yorick package "yorick-base" (or something like this). I > left it as is for the moment because I assume you will have your reasons > to do it that way but you might consider this for future releases. I add thought about that too and I'm glad you answer that for me. I think we are too close from freezing to undertake such a transition (all the yorick-* packages would need to depend on yorick-base instead of yorick etc...). Isn't that also your opinion ? Depending or "yorick-base | yorick" would certainly ease transition and upgrades. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd9f1af.7070...@free.fr
Re: Maintaining yorick in Vcs at debian.org (Was: RFS: yorick/2.2.02+dfsg-2)
Le 13/06/12 21:43, Andreas Tille a écrit : > Hi Thibaut, > >> To access further information about this package, please visit the >> following URL: >> >> http://mentors.debian.net/package/yorick >> >> >> Alternatively, one can download the package with dget using this command: >> >> dget -x >> http://mentors.debian.net/debian/pool/main/y/yorick/yorick_2.2.02+dfsg-2.dsc > > I wonder why you do not maintain the package at git.debian.org. This > would make for sponsors and other team members way easier. I tried > >debcheckout --user tille yorick > > but failed becuase Vcs-Git points to github.com where I do not have any > login nor could I commit some changes. For the sake of getting the > metapackage which I do consider very interesting I would make some > exception and would consider sponsering it anyway but otherwise I would > probably insist in sticking to Debian Science policy and ask for using a > debian.org hosted Vcs. Would you consider a move or do you want to > stick to the current location for the moment? > Hi Andreas, The reason is I never invested enough time to understand how to do that (or even how to properly package under git). I haven't pushed my changes to github yet. Note that at the moment the package is not under the debian science packaging team umbrella. And this is also mostly because I was unsure how to proceed. I would be willing to go in that direction in the future, of course. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd8fd2e.3000...@free.fr
RFS: yorick/2.2.02+dfsg-2 (Was:Please check whether your package is mentioned in tasks files)
Dear Andreas (and other prospective mentors), Andreas Tille wrote: > On Tue, Jun 12, 2012 at 01:56:14PM +0200, Thibaut Paumard wrote: > > I have thought about it before and I think it is a good idea. The main > > problem is I would need to find a sponsor for that upload since it adds > > a binary package, and I'm afraid I might miss the release. > If you are concerned about a sponsor I might volunteer to do this for > this specific upload. Thanks Andreas for this proposal. I've put an updated package on mentors: I am looking for a sponsor for my package "yorick" * Package name: yorick Version : 2.2.02+dfsg-2 Upstream Author : Dave Munro * URL : http://yorick.sourceforge.net/ * License : BSD Section : science It builds those binary packages: yorick - interpreted language and scientific graphics yorick-data - interpreted library for the Yorick language yorick-dbg - debugging symbols for Yorick yorick-dev - development files for the Yorick interpreted language yorick-doc - documentation for the Yorick interpreted language yorick-full - full installation of the Yorick interpreter and add-ons yorick-mpy-common - Message Passing Yorick (common files) yorick-mpy-mpich2 - Message Passing Yorick (MPICH2 build) yorick-mpy-openmpi - Message Passing Yorick (OpenMPI build) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yorick Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/y/yorick/yorick_2.2.02+dfsg-2.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * add yorick-full metapackage to ease installing Yorick + its plug-ins (in particular to be included in the astronomy task) * pass hardenned LDFLAGS when building codger Regards, Thibaut Paumard signature.asc Description: OpenPGP digital signature
Re: Bug#669016: RFS: gyoto/0.0.1-1 [ITP] -- general relativistic ray-tracing and orbit computation
Hi,
Could someone have a look at this 2-month-old RFS?
Kind regards, Thibaut.
Le 19/04/12 11:35, Thibaut Paumard a écrit :
> Hi,
>
> I've updated the package which now installs the headers in a
> subdirectory of /usr/include:
>
> http://mentors.debian.net/package/gyoto
> http://mentors.debian.net/debian/pool/main/g/gyoto/gyoto_0.0.2-1.dsc
>
> Regards, Thibaut.
>
>
>
> Le 16/04/12 17:10, Thibaut Paumard a écrit :
>> Package: sponsorship-requests
>> Severity: wishlist
>>
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "gyoto"
>>
>> * Package name: gyoto
>>Version : 0.0.1-1
>>Upstream Author : Frédéric Vincent & myself
>> * URL : http://gyoto.obspm.fr
>> * License : GPL-3+
>>Section : science
>>
>> Gyoto aims at providing a framework for computing orbits and ray-traced
>> images
>> in General relativity. It consists in a shared library (libgyoto0), utility
>> programs (in the gyoto package), and a plug-in for the Yorick programing
>> language (in yorick-gyoto). Gyoto can be extended with plug-ins (see
>> libgyoto0-dev).
>>
>> The source package builds those binary packages:
>> gyoto - General relativistic ray-tracing
>> gyoto-dbg - debugging symbols for gyoto, libgyoto0 and yorick-gyoto
>> gyoto-doc - documentation for the Gyoto library
>> libgyoto0 - General relativistic geodesic integration and ray-tracing
>> libgyoto0-dev - development files for libgyoto
>> yorick-gyoto - General relativistic geodesic integration for the Yorick
>> language
>>
>> To access further information about this package, please visit the following
>> URL:
>> http://mentors.debian.net/package/gyoto
>>
>> Alternatively, one can download the package with dget using this command:
>> dget -x http://mentors.debian.net/debian/pool/main/g/gyoto/gyoto_0.0.1-1.dsc
>>
>> Once installed, the packages can be tested as follows (a test suite is
>> already
>> ran during build):
>> - gyoto package:
>> Compute the example sceneries with
>> for file in /usr/share/doc/gyoto/examples/example-*.xml; do gyoto ${file}
>> `basename ${file%xml}fits`; done
>> The two *rotstar* example file won't run, they depend on the option al plug-
>> in lorene which is not compiled. The other files should produce FITS image
>> files which you can visualize using e.g. spydr from the yorick-spydr package
>> or
>> simply with the gimp :
>> spydr *.fits
>>
>> - yorick-gyoto package:
>> You can first run gyotoy:
>> gyotoy
>> You should see a plot representing the orbit of a star around a black hole.
>> You
>> can play with the
>> projection, the initial parameters etc.
>>
>> Then you can run the test suite:
>> ln -s /usr/share/doc/gyoto/ doc
>> cp -R /usr/share/doc/yorick-gyoto/examples ./
>> cd examples
>> gunzip *.gz
>> yorick -batch check.i
>>
>> Best regards, Thibaut.
>>
>>
>>
>> -- System Information:
>> Debian Release: wheezy/sid
>> APT prefers unstable
>> APT policy: (500, 'unstable')
>> Architecture: i386 (i686)
>>
>> Kernel: Linux 3.2.0-2-686-pae (SMP w/1 CPU core)
>>
>>
>>
>
>
>
>
signature.asc
Description: OpenPGP digital signature
[PING] Re: Bug#669209: RFS: yp-svipc/0.13-1 [ITP] -- System V InterProcess Communication for Python/Yorick
Hi guys, it's been two months since I initially posted this RFS, and the release is getting nearer... Regards, Thibaut. Le 26/05/12 11:05, Thibaut Paumard a écrit : > Le 08/05/12 09:43, Thibaut Paumard a écrit : >> Hi guys, > >> I'd love it if someone could have a look at this package: >> http://mentors.debian.net/package/yp-svipc >> dget -x http://mentors.debian.net/debian/pool/main/y/yp-svipc/yp-svipc_0.14-1.dsc > >> It gives access to the system V interprocess communication >> mechanisms to the [1]yorick and python (2-3) interpreters. With >> this mechanisms, it becomes possible to do multi-process parallel >> scripting and to develop mixed yorick/python applications. [1] >> http://packages.debian.org/sid/yorick > >> The Yorick plug-in can optionally be used for faster computations >> by YAO, a scientific software already in Debian: >> http://packages.debian.org/sid/yorick-yao > >> Since the initial ITP, I've worked with upstream to port the >> software to python 3 and to fix a couple of bugs. > >> Best regards, Thibaut. > > >> Le 18/04/12 09:32, Thibaut Paumard a écrit : >>> Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: >>> debian-pyt...@lists.debian.org > >>> Dear mentors, > >>> I am looking for a sponsor for my package "yp-svipc" > >>> * Package name: yp-svipc Version : 0.13-1 Upstream >>> Author : Matthieu Bec * URL : >>> https://github.com/frigaut/yorick-svipc/ * License : >>> GPL-3 Section : Python, Science Programming Lang: C, >>> Yorick, Python Description : System V InterProcess >>> Communication for Python/Yorick ITP : >>> http://bugs.debian.org/668841 > >>> It builds those binary packages: > >>> python-svipc - interprocess communication (shared memory...) for >>> Python yorick-svipc - interprocess communication (shared >>> memory...) for Yorick > >>> To access further information about this package, please visit >>> the following URL: http://mentors.debian.net/package/yp-svipc > >>> Alternatively, one can download the package with dget using this >>> command: dget -x >>> http://mentors.debian.net/debian/pool/main/y/yp-svipc/yp-svipc_0.13-1.dsc > >>> When the two packages are installed, they can be tested with: - >>> yorick-only multiprocess computing: yorick -i >>> /usr/share/doc/yorick-svipc/examples/timing-demo.i - >>> yorick/python communication: yorick -i >>> /usr/share/doc/yorick-svipc/examples/ping.i > >>> I have not been able to make it work under python3 so far (on >>> Linux: it works on a Mac). > >>> Regards, Thibaut Paumard. > > > > > > > > > signature.asc Description: OpenPGP digital signature
Re: Please check whether your package is mentioned in tasks files (Was:RFS: FreeFOAM)
Le 12/06/12 13:32, Andreas Tille a écrit : > Without having the slightest idea about yorick this somehow smells like > it might make sense to create a metapackage which installs all yorick > plug-ins in one rush. We could in turn make the science-astronomy > metapackage suggesting this. I have thought about it before and I think it is a good idea. The main problem is I would need to find a sponsor for that upload since it adds a binary package, and I'm afraid I might miss the release. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd72e5e.8000...@free.fr
Re: Please check whether your package is mentioned in tasks files (Was:RFS: FreeFOAM)
Le 12/06/12 11:36, Andreas Tille a écrit : > Hi, > > On Tue, Jun 12, 2012 at 10:48:19AM +0200, Thibaut Paumard wrote: >> Can you please add the following packages to the astronomy task? >> >> yorick-mira >> yorick-spydr >> yorick-yao > > This makes the following packages in the task matching "yorick" > (including the packages which were just there): > > Depends: yorick-cubeview, yorick-mira, yorick-spydr, yorick-yao > > Suggests: yorick > [...] > Does anybody think we should mention more yorick related packages? Hi, I'm the maintainer for all these packages. The packages I suggested for the astronomy task are the most astronomy specific and are (mostly) usable by people who don't know yorick yet. On the other hand, most users who actually run the yorick interpreter will want to install all the other plug-ins as well. Yorick itself (and some other plug-ins) is a dependency of each of the yorick-* package, so it doesn't need to be suggested by the task, other than for information to the users. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd715e5.6090...@free.fr
Re: Please check whether your package is mentioned in tasks files (Was:RFS: FreeFOAM)
> BTW, it would be really cool if *any* developer of a > scientific application would check *now* whether its > package is mentioned in the Debian Science tasks. Hi, Can you please add the following packages to the astronomy task? yorick-mira yorick-spydr yorick-yao (I'm a DM) Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: buildd failure due to lack of disk space, how to rebuild ?
Le 16/04/12 13:29, Thibaut Paumard a écrit : > Le 16/04/12 13:17, Christophe Prud'homme a écrit : >> All, >> >> buildd failed on ia64 for feel++ (-4) due to lack of disk space. >> Is there another way than uploading -5 ? >> >> Best regards >> C. > > > Yes there is. You must send an e-mail to debian-release asking to > "give-back" your package. > > Please read > http://release.debian.org/wanna-build.txt > Sorry, reading that more carefully myself, the right recipient is debian-wb-t...@lists.debian.org. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f8c0396.4000...@free.fr
Re: buildd failure due to lack of disk space, how to rebuild ?
Le 16/04/12 13:17, Christophe Prud'homme a écrit : > All, > > buildd failed on ia64 for feel++ (-4) due to lack of disk space. > Is there another way than uploading -5 ? > > Best regards > C. Yes there is. You must send an e-mail to debian-release asking to "give-back" your package. Please read http://release.debian.org/wanna-build.txt Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f8c02a2.2050...@free.fr
Re: adding a new file using (d)quilt
Le 12/04/12 12:50, Gerber van der Graaf a écrit : > Hi, for packaging freefoam-user-doc I intend to include the static file > UsersGuide.pdf.gz as asymptote is currently broken. > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668286) > Also, generating the manual pages for the freefoam package does not work > for the moment as a2x from asccidoc does currently not work properly. > The idea is to include these files statically (for the moment until > mentioned packages have been repaired) using (d)quilt. Hi, It's not OK to include a binary file which can't be built automatically. That's called "fails to build from source in a sane way". That said, you can't use a diff file to include a binary file. That's why we now use debian.tar.gz rather than .diff.gz. The right solution is to list your file in debian/source/include-binaries, see man dpkg-source. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f86b728.4020...@free.fr
Re: How do I get started?
Le 13/03/12 15:18, Yves S. Garret a écrit : > Hi, > >I'm reading a book called nanotechnology for dummies. I'd like to > know more about this field, Hi, Note that this list is about software, not science per se... Although you might meet people here who are knowledgeable or even experts in various fields, this is not really the best place to start a discussion about it. You could try looking for a "nanotechnology forum" on the web. That said, you start with "debien science" software just as with any other Debian software: you launch your package manager (be it synaptic, aptitude or other), you look for a package you want either by searching in your package manager or on the internet, and install it. For instance, look here: http://packages.debian.org/sid/science/science-nanoscale-physics This is in itself a package you can install. It "Recommends" and "Suggests" a variety of packages : you can install this package and all of the packages it recommends with: aptitude install -r science-nanoscale-physics To know the content of a package (in particular the binaries in /usr/bin), you can click on "list of files" on this package's page. For instance, for the "avogadro" package: http://packages.debian.org/en/sid/i386/avogadro/filelist Each executable in /usr/bin has a corresponding manual page that you read with "man ", for instance: man avogadro man avopkg In addition, each package provides documentation (sometimes only little, sometimes a lot) under /usr/share/doc/. For instance avogadro provides plenty of sample input files under /usr/share/doc/avogadro/examples/ Best regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f5f69a4.6000...@users.sourceforge.net
Re: RFS: yorick (new version, add dbg package)
Hi Sylvestre, Le 30/09/11 01:06, Sylvestre Ledru a écrit : > Le jeudi 29 septembre 2011 à 22:24 +0200, Thibaut Paumard a écrit : >> Dear mentors, >> >> I am looking for a sponsor for my package "yorick". >> >> I have maintained the Yorick packages for over 5 years. The package >> has the DM-Upload-Allowed field set. I need a sponsor to upload this >> revision because it introduces a new binary package: yorick-dbg. It is >> very useful to have debugging symbols in the yorick executable when >> debugging a Yorick plug-in, which up to know required recompiling >> Yorick from source. The upload also make a couple of minor changes. > Could you push the changes in the git repository ? > Done. > By the way, don't hesitate to join Debian Science. ;) Actually, I don't know exactly how to proceed :-) Would that simply mean changing the "Maintainer" field to debian-science-maintainers, putting myself as Uploader, and pushing the package to the Debian Science git repository? Best regards, Thibaut. > > Sylvestre > > > -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e8554c7.4070...@free.fr
RFS: yorick (new version, add dbg package)
Dear mentors, I am looking for a sponsor for my package "yorick". I have maintained the Yorick packages for over 5 years. The package has the DM-Upload-Allowed field set. I need a sponsor to upload this revision because it introduces a new binary package: yorick-dbg. It is very useful to have debugging symbols in the yorick executable when debugging a Yorick plug-in, which up to know required recompiling Yorick from source. The upload also make a couple of minor changes. * Package name: yorick Version : 2.2.01+dfsg-2 Upstream Author : David Munro * URL : http://yorick.sourceforge.net * License : BSD Section : science It builds those binary packages: yorick - interpreted language and scientific graphics yorick-data - interpreted library for the Yorick language yorick-dbg - debugging symbols for Yorick yorick-dev - development files for the Yorick interpreted language yorick-doc - documentation for the Yorick interpreted language yorick-mpy-common - Message Passing Yorick (common files) yorick-mpy-mpich2 - Message Passing Yorick (MPICH2 build) yorick-mpy-openmpi - Message Passing Yorick (OpenMPI build) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yorick Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/y/yorick/yorick_2.2.01+dfsg-2.dsc I would be glad if someone uploaded this package for me. Kind regards, Thibaut Paumard signature.asc Description: OpenPGP digital signature
Re: How is mpi-default-dev supposed to work?
Le 24 mars 10 à 13:58, Thibaut Paumard a écrit : - solution 1: make mpi-default-dev conflict against the non-default MPI implementations. [...] - solution 2: implement mpicc-default et al. links, install them as alternatives for mpicc et al. with high priority. [...] - solution 3: raise the priority of openmpi [...] - solution 4: set the right alternative in mpi-default-dev's postinst [...] In the end, solution 1 is the most robust, but yields some pain. [...] Bug submitted with a patch attached, implementing the "Conflicts:" approach: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575259 Best regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cc5b5ac1-fa75-4729-8a3a-6133467ab...@free.fr
Re: How is mpi-default-dev supposed to work?
Hi again, Le 24 mars 10 à 10:30, Lucas Nussbaum a écrit : Is it what will happen in practice? I'm afraid that the opposite will happen: dpkg may well refuse to install the new package because a conflicting package is already installed. I believe what we want to do requires a combination of Conflicts, Provides and Replaces that will be hard if not impossible to put in place. dpkg might refuse to do that, but it's apt-get which matters here Yes, I know that. Sorry for the inaccuracy. I've made a quick-and-dirty test, it seems apt-get does the right thing, removing the installed package in favour of the new package, in both directions. My concerns were therefore not grounded. Below, I summarize and discuss the various solutions discussed so far. I draw my conclusions right after this discussion. Discussion: ___ To summarize the discussion so far: ___ - solution 1: make mpi-default-dev conflict against the non-default MPI implementations. pros: ensures the right implementation is always used. cons: mpi-default-dev cannot be installed concurrently with the other lib*mpi*-dev. Means alternatively (un)installing mpi-default-dev and the non-default implementations when working on various MPI packages, so some pain for developers. End-users may be annoyed as well. - solution 2: implement mpicc-default et al. links, install them as alternatives for mpicc et al. with high priority. pros: the right implementation is _always_ used in clean build environment; mpi-default-dev can be installed together with the non- default implmentations. cons: in dirty environments, packages may end-up linked against the wrong implementation. Specifically, there can be trouble when the admin has set the alternative manually and the package to build uses mpicc instead of mpicc.default (i.e., currently, all packages). - solution 3: raise the priority of openmpi pros: the right implementation is _always_ used in clean build environment _for the time being_; mpi-default-dev can be installed together with the non- default implmentations. cons: does not allow for chosing mpich2 as default on some arch where openmpi exists, bad when a new arch is supported by openmpi (a transition to change the default for this arch has to be done immediately). can link against the wrong implementation on dirty environments. - solution 4: set the right alternative in mpi-default-dev's postinst pros: works, on clean environments; cons: a package should not set an alternative, it's admin's territory; does not prevent the admin to reset the alternative. Conclusion: ___ In the end, solution 1 is the most robust, but yields some pain. Solution 2 is still very robust and is also more flexible. Solution 3 is less robust and paves the way for trouble. Solution 4 is not very robust and not politically correct. Do you agree with me? Is there a consensus that solution 1 is the best? Best regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ae8ee663-cef8-417f-826a-243b71045...@free.fr
Re: How is mpi-default-dev supposed to work?
Hi again, Le 23 mars 10 à 11:22, Lucas Nussbaum a écrit : other solution: - ensure (in mpi-defaults' postinst) that mpicc points to the correct binary. Having thought about it, I also think this is wrong: the idea behind update-alternatives is that only the admin may set the alternative manually. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/01f41af3-ff4d-448b-ad86-55f2e8e47...@free.fr
Re: How is mpi-default-dev supposed to work?
Hi, Le 23 mars 10 à 19:40, Lucas Nussbaum a écrit : I think that the best way to solve this problem is to explicitely conflict with the other implementations in mpi-defaults. I don't see any other solution that really fixes the problem we are having and doesn't require an upload of all packages using mpi-defaults. I thought about that a little bit more carefully and I think it is a dangerous solution that may lead to many FTBFSes. At least it needs to be tested. The problem is that is that the way dpkg chooses between two conflicting packages may not be what we expect. What we want is that dpkg always installs the last package selected for installation, uninstalling the one installed: - if mpich2 is installed and installation of mpi-default-dev is requested, uninstall mpich2; - if mpi-default-dev is installed and installation of mpich2 is requested, uninstall mpi-default-dev. Is it what will happen in practice? I'm afraid that the opposite will happen: dpkg may well refuse to install the new package because a conflicting package is already installed. I believe what we want to do requires a combination of Conflicts, Provides and Replaces that will be hard if not impossible to put in place. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e246cca3-1e87-4dee-8258-2093ab575...@free.fr
Re: How is mpi-default-dev supposed to work?
Hi, Le 23 mars 10 à 19:01, Manuel Prinz a écrit : To comment on the discussions you had: The problem Thibaut mentions only exists on the platforms where both implementations exist and mpich2 is installed later into a buildd chroot. Actually, I was wrong about that: from toying around with the two packages, it seems update-alternatives falls back to lexicological order when the priorities are the same, so mpich2 always has precedence over openmpi. Mpich2 also has a priority higher than LAM, which is buggy as long as the default is LAM when OpenMPI is not available, but the plan is to make MPICH2 the default in that case anyway. The easiest (and cleanest) solution seems to be to add mpicc.default and friends (or whatever we call it) to mpi-defaults-dev, being symlinks to the default mpicc on that platform. Those can be used by the packages using only mpi-defaults-dev. The only downside I see right now it the fact that we should fix all packages not using it also which has a negative effect on the whole transition. On the other hand, we do not need to; it won't break anything if the assumptions made are valid. (But as said, we can't really rely to it.) And as I stated earlier, you can install mpicc.default as an alternative for mpicc with a high priority. So mpicc wil really point to the right implementation unless the admin has chosen otherwise, which buildd admins should not do. I could also increase the update-alternatives priority of Open MPI to something higher than MPICH2. This should have no negative side effects but does of course not fix the current problem. What do you think about that? (Planning to upload some minor fixes to Open MPI anyway.) I think it is an easy solution that indeed mostly solves the problem for the time being, with no foreseeable nasty side effects. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1106126e-d69b-4419-b1e6-be1855114...@free.fr
Re: How is mpi-default-dev supposed to work?
Hi, Le 23 mars 10 à 12:03, Lucas Nussbaum a écrit : Most buildds have been migrated to using schroot with LVM snapshots, so it is no longer an issue on those buildds. I didn't realize that. - my preferred solution: mpi-defaut-dev could provide links like mpicc.mpi-defaults that would be the commands actually used when building. They could also be installed as alternatives with a very high priority, but I think it is safer to directly use the fully qualified name "mpicc.mpi-default". [...] Sure, but we don't want a solution that only fixes the problem for packages that are modified. This effectively requires transitioning all packages to fix the problem everywhere. The option in which mpicc.mpi-default is an alternative for mpicc with a high priority does fix the problem for existing packages in clean- enough environments (i.e. as long as the alternative has not been set manually). [...] Yes, it's probably better to just conflict in mpi-defaults with the other providers of mpicc. Which unfortunately forbids to both build with the default implementation and with each available implementation. Agreed, this is not recommended anyway. Just wondering if any package does this already. Note that help is usually welcomed. It might be better to invest time to solve that problem with a distribution-wide solution, rather than just for your own package. Which is why I am here discussing with you :-) I would be happy to prepare a patch once the best solution is agreed. Best regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/93acc7b6-3486-44e6-9df4-041b6ef66...@free.fr
Re: How is mpi-default-dev supposed to work?
Hi, Thanks for your answer. Le 23 mars 10 à 11:22, Lucas Nussbaum a écrit : I think that this currently does not work reliably since mpich2 has the same priority (40) as openmpi for the alternatives system. If package A build-depends on mpi-default-dev and is built on a machine where mpich2-dev has been installed after openmpi-dev, package A will be built against mpich2, not against openmpi. That's why we are supposed to build in clean chroots ;) Depends on what you call "clean": only official packages without custom configuration, or minimalistic system. Buildds are the former version of "clean", not the latter. Packages required by previous builds may be present if you don't build-conflict on them. I know there is a recurring debate about that, but this is the current situation... - my preferred solution: mpi-defaut-dev could provide links like mpicc.mpi-defaults that would be the commands actually used when building. They could also be installed as alternatives with a very high priority, but I think it is safer to directly use the fully qualified name "mpicc.mpi-default". That requires transitioning all packages: no. I don't agree : this solution doesn't break existing packages. If you install mpicc.mpi-default (et al.) as an alternative for mpicc, mpicc is still a link, and in the end it points to the expected implementation. Existing packages use it and build properly. It's just that by providing the explicit mpicc.mpi-default, the system is a little more reliable on "dirty" build environments, where the mpicc alternative may have been set manually. If you don't install mpicc.mpi-default as an alternative, this solution doesn't fix the problem for existing packages, but it doesn't hurt them either: they use the same mpicc as they do currently. other solution: - ensure (in mpi-defaults' postinst) that mpicc points to the correct binary. By using update-alternatives --set? Hmmm... yes, I guess that should work. But still not on dirty build environments, so it will be a bit more painful for developers to debug on their machine before they pdebuild. For the time being, I will try to make my debian/rules use mpicc.openmpi if it is available and fall back to mpicc, since the default is openmpi wherever it can be installed. mpicc may be a link to mpicc.mpich2 instead of mpicc.lam in some circumstances. Please don't. Follow what the other packages are doing. Finally I don't use mpi-default-dev at all but I build the two versions (openmpi and mpich2). This way I don't have to do something I know is flawed and I can look at myself in the mirror again :-) Best regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/42ead073-8243-4a27-8cf1-b82c3945e...@free.fr
How is mpi-default-dev supposed to work?
Hi, I am building a new package against mpi-default-dev. If I understand correctly, mpi-default-dev just pulls either openmpi- dev or lam-dev (to be replaced soon by mpich2-dev...) and trusts the alternatives system to install the right links as mpicc etc. I think that this currently does not work reliably since mpich2 has the same priority (40) as openmpi for the alternatives system. If package A build-depends on mpi-default-dev and is built on a machine where mpich2-dev has been installed after openmpi-dev, package A will be built against mpich2, not against openmpi. This can be resolved in several manners: - mpi-default-dev could conflict against all the non-default MPI implementations; - openmpi could (should) have a higher priority than mpich2; - my preferred solution: mpi-defaut-dev could provide links like mpicc.mpi-defaults that would be the commands actually used when building. They could also be installed as alternatives with a very high priority, but I think it is safer to directly use the fully qualified name "mpicc.mpi-default". I do not (yet) file a bug report because the bug may well lie in my understanding, so I prefer to discuss the matter here first. For the time being, I will try to make my debian/rules use mpicc.openmpi if it is available and fall back to mpicc, since the default is openmpi wherever it can be installed. mpicc may be a link to mpicc.mpich2 instead of mpicc.lam in some circumstances. Best regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e9f4e8c-5d63-4fb4-b832-81fa2c3d4...@free.fr
Re: MPI implementations in squeeze
Hi, I am about to upload a new package which build-depends on mpi-default- dev (it will need to be checked by a sponsor and then go through NEW). It it ok to do so in the next couple of days or should I wait for the new mpi-default-dev? Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/98447058-9033-4e2b-8da5-d630e363e...@free.fr
Changing section from math to science?
Hi, I maintain a bunch of related packages. Yorick is an interpreter specialized in number crunching and data analysis. I also maintain extension packages which either extend the capabilities of Yorick (plug-ins, interpreted libraries) or use Yorick to do something specific (graphical data viewers, simulators, specific data reduction...) All of this is currently in the "math" section and has been there for about 10 years. I wonder whether all of this should move to the "science" or "interpreters" section. It is better if all these packages stay together, whatever the section. I also wonder how to proceed: is the best way to simply send an e-mail to FTP masters? Best regards, Thibaut. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian-science and science-* packages
Le 28 août 07 à 16:02, Christian Holm Christensen a écrit : On Tue, 2007-08-28 at 14:34 +0200, Thibaut Paumard wrote: Le 27 août 07 à 08:04, Andreas Tille a écrit : * The `-astronomy' package should also depend on what-ever ... while the later contains developent libraries etc. In this case most probably IDL would go into the science-astronomy-dev dependency list. I think not, it's an interpreted language. Just goes to show how much I know :-) But, isn't there a (proprietary) compiler for IDL? I don't think you can turn IDL code into a stand-alone executable, but I could be wrong. I would compare with Yorick (which I know better ;-) : the yorick-dev package contains what you need to develop yorick plugins, Is that compiled "Yorick" or compiled C/C++/... ? Mostly compiled C. Yorick can be seen as a shell specialised in number crunching. (same for IDL). Anyway, I would put yorick-dev and perhaps python-dev and other in a science-something-dev, and yorick and python themselves in a science-something. On the other hand, IDL/GDL, yorick and a few others are really general tools, so a "science-general" or "-common" could be a better idea. Erhm, doesn't that really depend on use-cases. For example, I've never heard of people using Yorick or IDL in High Energy Physics (HEP), but I know the astronomers swear by IDL, and more or less vice versa for C ++. Python seems to be popular in some areas of HEP, and Ruby has some users too. The HEP theorists use what-ever symbolic manipulation they can get their hands on, since they are mostly doing Mathematics anyways (in some M-dimensional space un-fathomable and un-measurable to anyone but the theorists themselves :-) Sure. I guess we are back to the new menu architecture discussion. I'm an astrophysicist and I use yorick on a daily basis. However I know it can be used and is used in other domains as well. So its place is not in Applications/Science/Astronomy, and it ends up in Applications/Science/Mathematics, although Mathematics is probably one of the few things you cannot do in yorick... Menu entries and dependencies are different in that a given item should probably exist only once in the entire menu, whereas its absolutely OK for several packages to depend/recommend a common package. Perhaps an idea would be to use a meta-package, something like "science-number-crunching-shell" that would be Provided by yorick & co. and Recommended by science-astro and others? Then of course we need to get the default right... [...] On the other hand we could also use the DebTAGS mechanism more aggressively. In fact, we could use the DebTAGS as a "voting machine" for what goes were, with the added benefit that the tags will be there to be used. Sure, that's a topic I need to learn more about... Regards, T.
Re: debian-science and science-* packages
Le 27 août 07 à 08:04, Andreas Tille a écrit : * The `-astronomy' package should also depend on what-ever implementation that exists in Debian of `IDL' (Interactive Data Language). For some odd reason, that language seems popular among astrologists - sorry astronomers :-) I wonder whether it might be reasonable to implement a scheme like science-and science--dev while the later contains developent libraries etc. In this case most probably IDL would go into the science-astronomy-dev dependency list. I think not, it's an interpreted language. I would compare with Yorick (which I know better ;-) : the yorick-dev package contains what you need to develop yorick plugins, while the yorick package contains all you need to run yorick. Both Yorick and IDL/GDL are useful in themselves: just launch them and you're able to compute "2*2", or load an array into memory and do some visualisation or number crunching. On the other hand, IDL/GDL, yorick and a few others are really general tools, so a "science-general" or "-common" could be a better idea. I would probably "Recommend" or "Suggest" it in most other science-* packages. Regards, T.
Re: gnudatalanguage
Le 18 janv. 07 à 22:31, Christian T. Steigies a écrit :
On Wed, Jan 17, 2007 at 12:33:09PM +0100, aetherlux wrote:
Hi everybody,
I opened the ITP for gnudatalanguage about two years ago. [...]
afaik, the versions built by Sergio and Heimy has a lack, they
don't have save/re
store support. This feature is available in the last
gnudatalanguage version, but
it is done through CMSVLIB (by Craig Marqwardt, available from
http://cow.physic
s.wisc.edu/~craigm/idl/down/cmsvlib.tar.gz). afaik, this library
is not packaged
for Debian.
I am not a lawyer, but I have my doubts that cmsvlib can be
included in
Debian, I would not agree to the IDL EULA without ever having seen
it or
without even using IDL:
http://cow.physics.wisc.edu/~craigm/idl/down/LICENSE.RSI
It is probably not even redistributable by Debian ("please obtain
permission
before redistributing"), but since cmsvlib just contains a bunch
of .pro
files, can't every user, who agrees to the IDL EULA, just install that
package locally if he needs to use save files?
I propose again to handle gnudatalanguage via the pkg-scicomp svn
repository. Sergo agreed that we could use his packaging as a starting
point, and I must say it looks pretty neat, everything is handled
by cbds. I
could do the initial commit to the svn, but it would be nice if
there was a
co-maintainer. Especially since I don't really use IDL...
I agree. I've also removed files based on these from the Yorick
package, pointing users to where they can download them if needed (in
README.Debian).
Regards, Thibaut.
Re: Scienfific (was Re: Simulation software package maintainer is xmds, version 1.5-3)
On Fri, 24 Nov 2006 18:52:14 +0100 Vanuxem Gregory <[EMAIL PROTECTED]> wrote: > Le vendredi 24 novembre 2006 à 14:33 +0100, Christophe Prud'homme a > écrit : > > [ jeudi 23 novembre 2006 21:11 Vanuxem Gregory ] > > | > Debian Developer - http://people.debian.org/~prudhomm/ > > | > Scienfific computing packages maintainer > > | > > | Is it an error ? If not what is its definition ? > > | Not exactly the topic of this mailing list... > > you mean that scientific computing is not a topic for debian-science ? > > Not at all, I wondered what was the notion of scienfificity. For > example, does it express a certain philosophical viewpoint about > sciences. You're a poet... I don't now what a scienfific is, but I'm almost certain I'm one :-) T.
[new version] RFC/RFS: yorick -- interpreted language and scientific graphics
[Note to the debian-science readers: this is a followup to this thread:
http://lists.debian.org/debian-mentors/2006/05/msg00252.html .
All relevant information is included as cited text below.]
Dear all,
I am still looking for a [1] sponsor for [2] Yorick, that I am [3]
adopting.
[1] http://sponsors.debian.net/viewpkg.php?id=282
[2] http://yorick.sourceforge.net/
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357679
Yorick has been in Debian for 9 years now, but the former maintainer
(and upstream author) can't take care of the Debian package anymore.
It's a quite viable DFSG-free alternative to [4] IDL. Indeed, I find the
syntax (especially for indexing arrays) quite attractive and I always
use Yorick rather than IDL whenever possible.
[4] http://rsinc.com/idl/
Since my last request, I have split the yorick package into yorick,
yorick-data and yorick-dev . The two add-on packages that I suggest to
review together with Yorick have been updated accordingly
(build-dependency). Please use the following options to
dpkg-buildpackage to ensure the relevant bugs are closed and the
orig.tar.gz is uploaded as well:
yorick(version:2.1.01cvs20060524-2):-v1.5.14-1.1 -sa
yorick-yutils (version: 1.1.1-2): -v0 -sa
yorick-z (version: 1.2.0.0.cvs20060511-2): -v0 -sa
(Note: I did _not_ use -sa when uploading to mentors.debian.net)
The packages are available at
deb-src http://mentors.debian.net/debian unstable main contrib non-free
as well as
deb http://www.mpe.mpg.de/~paumard/debian sid main
deb-src http://www.mpe.mpg.de/~paumard/debian sid main
(sid/i386 binaries only).
The three packages build in pbuilder and are piuparts, lintian and
linda-clean, except for three warnings:
- two lintian Ws have to do with icons that are not found in yorick:
they are in yorick-data;
- the third (found by both lintian and linda) has to do with a command
in the .menu entry that does not belong to yorick. This is on purpose
and works.
Note that most of the debian/ directory is in the orig source. I'm
currently thinking of whether to separate it and how to do that in a
headache-minimising way. (The package was built as "native" up to now).
Thanks for your time and attention,
Best regards, Thibaut.
Le jeudi 25 mai 2006 à 12:43 +0200, Thibaut Paumard a écrit :
> Some more information:
>
> ITA:: #357679
> Package name: yorick
> Version : 2.1.01cvs20060524 (upstream 2.1.02 in development)
> Upstream Author : David H. Munro
> URL : http://yorick.sourceforge.net
> License : BSD
> Description : interpreted language and scientific graphics
> Yorick is an interpreted programming language for:
> * scientific simulations or calculations
> * postprocessing or steering large simulation codes
> * interactive scientific graphics
> * reading, writing, and translating large files of numbers
> .
> The language features a compact syntax for many common array
> operations, so it processes large arrays of numbers very quickly and
> efficiently. Superficially, yorick code resembles C code, but yorick
> variables are never explicitly declared and have a dynamic scoping
> similar to many Lisp dialects. The yorick language is designed to be
> typed interactively at a keyboard, as well as stored in files for
> later use.
> .
> This package includes an emacs-based development environment, which
> you can launch by typing M-x yorick in emacs.
>
>
> The version in the archive (1.5.14) is obsolete (see #333074, 227 day
> old). The former maintainer (who is also the upstream author) has lost
> his upload privileges (lapsed key), so I need a sponsor.
>
> The new version has very interesting new features, in particular the
> ability to load plug-ins. I have completely revamped the package, and
> work with upstream to make Yorick's internal package management system
> integrate well in Debian.
>
> This upload will close 5 bugs (+ the ITA). The two remaining bugs are
> very old, I will close one as "fixed since long" and the other as "won't
> fix" as soon as I become the official maintainer with this upload.
>
> Regards, Thibaut.
In addition, since the new version supports compiled add-ons
("plug-ins"), I have packaged a bunch of these. I recommend reviewing
two add-on packages together with Yorick: one that is a plug-in
(yorick-z), the other one that is a library of interpreted functions
(yorick-yutils). ITPs:
Bug#366710: ITP: yorick-z -- zlib, jpeg, png and mpeg support for the
Yorick language (BSD license)
Bug#366711: ITP: yorick-yutils -- various utilities for the Yorick
language (GPL license)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366710
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=
Re: Bug#361418: Debian menu and the Apps/Science section
Le mardi 16 mai 2006 à 12:14 -0700, JD Rogers a écrit : > That said, I think we should not overly subdivide. If the menu depth > gets too large, we will be spending more time clicking menu levels > than scanning a menu list for the app name. For example in my > experience, I may have a couple of astronomy apps, but rarely 50 > installed on any one system. I doubt many users will want to click > Apps -> Science -> Astronomy -> Cosmology to get a list containing 1 > cosmology program that is installed. Same for other fields of science. I would very much agree with this. Actually, I thought it was possible to give "hints" in the .menu files, so that update-menu automatically creates relevant submenus only when the number of installed packages gets large. If my understanding is correct, one could put for program A "Astronomy, Sky Charts" and for prog. B "Astronomy, Data Visualisation" so that if I have a lot of astronomy programs installed, I'll get the submenus "Sky charts" and "Data Visualisations", but if I've got programs from all fields, I'll get "Astronomy" and, say, "Genetics" (and if I've got only a couple of softs, I won't end up with any 1 item submenus, which is good). In that case, why not rather prepare a list of standardised hints rather than a fixed subdivision? Quite honestly, in how many circumstances will someone have programs relevant for more than one field installed? The "Games" case is different: I'd bet most people who install games install a lot of them. Regards, Thibaut. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
