I just fixed this in version control, but there's more to do, and I'm
not releasing anything into the archive.
https://salsa.debian.org/science-team/sundials/-/commit/dc8951dabd913d2cc4c259b5c5e59f90f4c60f26
--
debian-science-maintainers mailing list
Package: python3-opencv
Version: 4.2.0+dfsg-6+b6
Severity: normal
X-Debbugs-Cc: none, Dima Kogan
Hi. I just upgraded my python opencv bindings on Debian/sid:
apt install python3-opencv
This worked. But then this happened:
dima@fatty:~$ python3
Python 3.9.1 (default, Dec 8 2020, 07:51
Hi. Yeah, wayland is almost certainly the cuplrit. If you can talk to
the gnuplot upstream to get it resolved, that'd be awesome.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Hi. Notes inline.
Detlev Zundel writes:
> I cannot get dynamic plots to work on my system.
OK. I suspect this is something on your end, but let's run some
experiments.
> while true; do sleep 1; cat /proc/net/dev; done |
> gawk '/enp6s0/ {if(b) {print $2-b; fflush()} b=$2}' |
> feedgnuplot
Hi.
Graham Inggs writes:
> numpy 1:1.21.4-2 in testing is already built for python3.9 and 3.10
> [1]. Search for 'cpython-3' and you should find files like:
>
> /usr/lib/python3/dist-packages/numpy/core/_multiarray_tests.cpython-310-x86_64-linux-gnu.so
>
Hi. Thanks for the bug report. I'm not clear on how to reproduce this so
that I can fix it.
I installed python3.10, and asked the build system to use it. Instead of
the error you're reporting, I get a build error: it can't find the numpy
headers because python3-numpy is built for python3.9. This
Thorsten Alteholz writes:
> please also mention mrcal-2.1/minimath in your debian/copyright.
Hi Thorsten. Thanks for flagging this down. I just pushed an updated
version to NEW: mrcal 2.1-2. There're a few more packaging fixes, mostly
dealing with cross-building.
--
debian-science-maintainers
Andrius Merkys writes:
> Do you know any software already in Debian which would benefit from
> having SAIL in Debian?
There aren't many C image-reading libraries. libfreeimage is mostly-dead
upstream, and is kinda weird. If SAIL was in Debian and is all the
things that its website claims, I
Thorsten Alteholz writes:
> please also mention opengv/matlab/helpers/rodrigues.m in your
> debian/copyright.
Hi. Thanks for pointing that out. I added this to the debian/copyright,
and I re-uploaded. The upload includes two other minor tweaks:
- Improved package description in debian/control
Thanks for checking, Helmut. After talking to you on the mailing list I
had already solved the problem, but haven't made an upload yet. Doing
that right now. Thanks.
https://lists.debian.org/debian-cross/2023/01/msg1.html
--
debian-science-maintainers mailing list
Package: libfreeimage-dev
Version: 3.18.0+ds2-8
Severity: normal
X-Debbugs-Cc: none, Dima Kogan
Hi. This package can be marked Multi-arch:same since all the files
either are straight copies from the upstream repo (FreeImage.h) or live
in arch-specific directories:
$ dpkg -L libfreeimage-dev
Package: rosbash
Version: 1.15.8-5
Severity: normal
X-Debbugs-Cc: none, Dima Kogan
Hello. I'm using the package from bookworm. rosbash
The "rosbash" package should provide several commandline tools,
documented here:
http://wiki.ros.org/rosbash
But only "rosrun" is pro
Thank you very much for the report. I completely forgot about these.
Fixed just now.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Hello. Thank you for the report. This is already fixed in the libdogleg
upstream repo. I will push a new package when a new libdogleg is
released or when the new suitesparse moves to unstable, whichever comes first.
--
debian-science-maintainers mailing list
Package: libeigen3-dev
Version: 3.4.0-4
Severity: normal
X-Debbugs-Cc: none, Dima Kogan
Hello. I'm making this report to track the report in this mailing list
thread:
https://www.mail-archive.com/debian-science@lists.debian.org/msg13666.html
In short: there's a known issue in Eigen that can
Hi.
libmrcal-dev does not use time_t. I'm seeing the abi-compliance-checker
failure here:
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libmrcal-dev/base/log.txt
The cause is that the tool takes all the headers in /usr/include/mrcal
in an arbitrary order, and tries to
Package: libsuitesparse-dev
Version: 1:7.3.1+dfsg-2
Severity: serious
X-Debbugs-Cc: none, Dima Kogan
Hi. I'm chasing down
http://bugs.debian.org/1060986
The problem is that mrcal uses libdogleg, which contains
typedef struct
{
cholmod_common common
Thanks.
In case you're unaware, there're tools that can report ABI and API
breaks. I usually use abi-compliance-checker (works great). And there's
also abigail (have't tried it myself, but supposedly works well). Both
are in Debian.
Cheers.
--
debian-science-maintainers mailing list
This is this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067398
You need both of
python3-numpy 1:1.26.4+ds-6
mrbuild 1.9
This failing build you have has the former but not the latter (you have mrbuild
1.8). What is being built? Is this Ubuntu's version of experimental? I
Hi. It looks like the current 3.18.0 release is at r1806. Are there
features in r1909 that you want that aren't in our 3.18.0?
If there are useful things there, I think it would be best to talk to
upstream about releasing a 3.19. Is upstream completely gone, or just
slow?
--
Thanks for the report, but I cannot reproduce. I upgraded my python3
install to what's currently in experimental: "python3" starts up 3.12.3,
and mrcal builds just fine.
Can I get the version of these packages please:
- mrbuild
- python3-numpy
Any other specific suggestions would be good too.
Hi.
I might be misunderstanding what you're asking specifically, but two
notes:
- Today leptonlib Build-Depends on gnuplot-nox only if !nocheck. So if
you build leptonlib with testing disabled, there's no dependency on
gnuplot
- Today the gnuplot source package has a hard Build-Depends on
Thre's a bug in my patches: gnuplot-data is supposed to get some qt
stuff, which isn't built in the nox-only profile. Should be an easy fix,
but I gotta go do something else right now.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
I added the requested profile, and fixed a few build bugs I encountered
in the process. The patch series is here:
https://salsa.debian.org/science-team/gnuplot/-/commits/bug-1067582
Anton: can you please review and upload, if it looks good? Or let me
know, and I'll make a Team upload.
--
OK. I see what you're saying. I can do this today or tomorrow. Anton:
are you good with that? I'd make a profile "nox-only" that elides the
gnuplot-x11 and gnuplot-qt packages.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
OK. I just pushed your suggestion to the git repo.
You can now build gnuplot-nox without the qt or wxt dependencies.
Does it help you, though? Without gnuplot-data you won't be able to
install gnuplot-nox to satisfy the downstream Build-Depends. Is that
still OK for you? If so, reply here, and
Hi. I'd like to get more clarity.
- You see the issue when you try to plot anything at all?
- You say "plot x" and you get a plot window, but it's all white, or
something?
- Only with the "qt" terminal?
You can try to change your window manager, qt versions, etc, etc. If no
trigger is found,
Hi. vnlog does not depend on time_t. Is it too late to stop this
update?
The abi-compliance-checker failure is here:
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libvnlog-dev/base/log.txt
That error message says what the problem is: you are not supposed to
#include
Can you see if other wxt applications work on a system that's exhibiting
this problem?
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Steve Langasek writes:
> What I'm unclear on is why you don't run vnl-gen-header at build time
> and output the "generated" header in the -dev package with a
> comprehensive description of all the ABI entry points?
Each user of libvnlog-dev would give different arguments to
vnl-gen-header, and
Thanks for replying. I'll revert the changes.
> ... however, I will say it's very strange to ship a shared library,
> that has a public shlibs file, and has a -dev package that depends on
> it, but the headers shipped in that -dev package are NOT the
> authoritative api for that library?
That's
31 matches
Mail list logo
