Le lundi 13 juillet 2020 à 01:31 +, Torrance, Douglas a écrit :
> Would anyone be able to review and sponsor an upload? It's available
> in
> Salsa:
> https://salsa.debian.org/science-team/macaulay2
At first I had a failure :
jpuydt@phaeris:~/Debian/exper/macaulay2$ LANG=C gbp buildpackage
Hi,
Le lundi 13 juillet 2020 à 01:31 +, Torrance, Douglas a écrit :
>
> Would anyone be able to review and sponsor an upload? It's available
> in
> Salsa:
> https://salsa.debian.org/science-team/macaulay2
I only had a very quick look this morning, just looking at the debian/
directory :
Le lundi 13 juillet 2020 à 01:31 +, Torrance, Douglas a écrit :
> Would anyone be able to review and sponsor an upload? It's available
> in
> Salsa:
> https://salsa.debian.org/science-team/macaulay2
After I got through the first issues, it ends with :
/bin/echo 'echo -- loaded
Doug Torrance writes:
>
>> - couldn't the emacs component be another source-package ?
>
> I considered this, but it's too tied to Macaulay2 itself. It doesn't
> build by itself; several of the files in the M2-emacs submodule are
> generated during the main Macaulay2 build. And Macaulay2
On 7/13/20 8:20 AM, David Bremner wrote:
Doug Torrance writes:
- couldn't the emacs component be another source-package ?
I considered this, but it's too tied to Macaulay2 itself. It doesn't
build by itself; several of the files in the M2-emacs submodule are
generated during the main
Doug Torrance writes:
>
> Thanks for the note! I considered using dh_elpa when I decided to split
> off the Emacs files into their own binary package. But dh_install
> already installs them to the correct place, and there are not any test
> suites to run. Is there another reason to use
On 7/13/20 2:39 AM, Julien Puydt wrote:
I only had a very quick look this morning, just looking at the debian/
directory :
- the maintainer should be :
Maintainer: Debian Science Maintainers <
debian-science-maintain...@alioth-lists.debian.net>
Fixed. (Debian Science policy still shows the
On 7/13/20 3:11 AM, Julien Puydt wrote:
After I got through the first issues, it ends with :
/bin/echo 'echo -- loaded .gdb-directories\n' >>.gdb-directories
touch .gdbinit.unknown-user
cp .gdbinit.unknown-user .gdbinit
echo '# -*- sh -*-' >.gdb-files
/bin/echo 'echo -- loading .gdb-files\n'
On 7/13/20 10:03 AM, David Bremner wrote:
Doug Torrance writes:
Thanks for the note! I considered using dh_elpa when I decided to split
off the Emacs files into their own binary package. But dh_install
already installs them to the correct place, and there are not any test
suites to run.
Hi,
Le lundi 13 juillet 2020 à 09:04 -0400, Doug Torrance a écrit :
> Yikes -- sorry for the troubles! I hadn't been setting export-dir
> when
> I experimented with gbp (I usually just use pbuilder), so I hadn't
> noticed this. I've fixed up gbp.conf so that it copies the emacs
> files
>
On 7/13/20 4:08 PM, Julien Puydt wrote:
It builds better, but lintian is quite unhappy :
E: macaulay2: arch-dependent-file-not-in-arch-specific-directory
usr/bin/M2-binary
which according to "lintian-info --tags arch-dependent-file-not-in-
arch-specific-directory" means some M-A tag is wrong.
Dear Science team,
I just submitted two python module packages and wonder if anyone is
willing to take a look and sponsor these packages
The python-jdata and python-bjdata packages aim to enable sharing python
data with other programming environments (like MATLAB, C/C++) via
JSON/binary
On 7/13/20 4:21 PM, Doug Torrance wrote:
On 7/13/20 4:08 PM, Julien Puydt wrote:
It builds better, but lintian is quite unhappy :
E: macaulay2: arch-dependent-file-not-in-arch-specific-directory
usr/bin/M2-binary
which according to "lintian-info --tags arch-dependent-file-not-in-
13 matches
Mail list logo
