Bug#1023696: libfreeimage-dev: libfreeimage-dev should be Multi-arch:same
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 /. /usr /usr/include /usr/include/FreeImage.h /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libfreeimage.a /usr/lib/x86_64-linux-gnu/libfreeimageplus.a /usr/share /usr/share/doc /usr/share/doc/libfreeimage-dev /usr/share/doc/libfreeimage-dev/changelog.Debian.gz /usr/share/doc/libfreeimage-dev/changelog.gz /usr/share/doc/libfreeimage-dev/copyright /usr/lib/x86_64-linux-gnu/libfreeimage.so Adding Multi-arch:same to that package will make it more convenient to use. Thanks! -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1029083: mrcal FTBFS with nocheck profile: ModuleNotFoundError: No module named 'numpy'
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 debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1062952: This package is not affected by time_t
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 #include them. That does not work here. "mrcal-internal.h" should not be #included explicitly since it is already #included by mrcal.h. Removing that header from the command in the error log above makes the errors disappear. Let me know what needs to happen to ingest that logic, to exclude mrcal from this transition. This will make my life easier. Thanks. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1064320: libeigen3-dev: linking objects compiled with different flags may cause crashes
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 create crashing binaries when using a very reasonable workflow. A description of the issue and minimized reproducer are here: https://www.mail-archive.com/debian-science@lists.debian.org/msg13710.html I propose to patch this in Debian and/or talk to Eigen upstream to eliminate the cause of the crash. A proposed patch appears here: https://www.mail-archive.com/debian-science@lists.debian.org/msg13857.html In my view, a questionable design choice in C++ allows the user to create crashing code, and Eigen expoloits this design choice to make this crashing possible. We cannot fix C++, but we can fix Eigen. The issue is that a templated function defined in a header generates a (weak symbol) copy of this function in EACH compile unit, and the linker then picks an arbitrary copy from the many compile units it is given. It is thus imperative that each copy is compatible with every other copy. Eigen breaks this requirement by using the preprocessor to select incompatible behaviors that might crash when linked together. The proposed patch eliminates this preprocessor-based variability. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1064982: gnuplot-qt: gnuplot displays a window with nothing in it
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, it would be good to bisect the gnuplot sources to find the cause. Are you able to do that? I cannot reproduce at the moment, so I cannot do it myself. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1064982: gnuplot-qt: gnuplot displays a window with nothing in it
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
Bug#1063051: vnlog: NMU diff for 64-bit time_t transition
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 vnlog.h directly. Instead you're supposed to use the "vnl-gen-header" tool (also in the "libvnlog-dev" package) to produce usable headers that themselves #include vnlog.h. For instance: vnl-gen-header 'int w' 'uint8_t x' 'char* y' 'double z' > vnlog_fields_generated.h If you then run vnlog_fields_generated.h (which, again, #includes vnlog.h) through abi-compliance-checker, you'll see that it passes. vnl-gen-header doesn't support any time-related types, so this is y2k38 safe. Thanks. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1063051: vnlog: NMU diff for 64-bit time_t transition
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 how I did it, and while it sounds odd, I believe this is right. The public interface is vnl-gen-header ... > generated.h and #include "generated.h" The generated header contains some user-facing macros that call the functions in vnlog.h with specific arguments. That's the API. From the compiler's perspective, the functions declared in vnlog.h are the interface, and the ABI in those symbols must be stable, and putting them into the .symbols file is appropriate. Let me know if I'm doing something wrong. Thanks -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1063051: vnlog: NMU diff for 64-bit time_t transition
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 would get a different generated header file. So there isn't a single generated header I can produce when building the vnlog packages. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Bug#1067582: gnuplot: please provide a profile to break B-D cycle
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 wxt and qt. Removing either of those (even in a specific profile) would make it impossible to build gnuplot-qt and gnuplot-x11 packages with the same set of functionality they normally have. If a profile was added to loosen either of these dependencies, but that dramatically changed the end product, would that be useful? Thanks -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1067582: gnuplot: please provide a profile to break B-D cycle
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 https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Bug#1067582: gnuplot: please provide a profile to break B-D cycle
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. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Bug#1067582: gnuplot: please provide a profile to break B-D cycle
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 https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Bug#1067582: gnuplot: please provide a profile to break B-D cycle
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 I'll do a Team Upload. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1068718: freeimage: consider packaging r1909?
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? -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Bug#1069220: mrcal ftbfs with Python 3.12
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. Thanks. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1069220: mrcal ftbfs with Python 3.12
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 believe both of these packages are in Debian/unstable right now, hence it builds fine there (yes, unstable has python 3.11, but the error you're seeing is exactly what mrbuild 1.9 fixes). mrcal 2.4.1 made it to Ubuntu/noble, right? -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: RFP: SAIL image decoding library
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 would consider moving my upstream software to use it instead of libfreeimage. So I'd like to see this in Debian, but have too much of a backlog to do the packaging myself, sadly. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1061049: libsuitesparse-dev: libsuitesparse-dev 7.4.0 has an ABI break in libcholmod5 without bumping to "libcholmod6"
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;
} dogleg_solverContext_t;
The existing "libdogleg2" package was built against libsuitesparse-dev
7.3, so it must be linked with packages that use that ABI. But in
suitesparse 7.4 the cholmod_common structure has a new member at the
end:
FILE *blas_dump ; // only used if CHOLMOD is compiled with -DBLAS_DUMP
This is in CHOLMOD/Include/cholmod.h
This extra member changes sizeof(cholmod_common), which changes the ABI,
causing the crash. One way to fix this is to bump the SONAME of
libcholmod.
Thanks.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1061049: libsuitesparse-dev: libsuitesparse-dev 7.4.0 has an ABI break in libcholmod5 without bumping to "libcholmod6"
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 debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: opengv_1.0+1git91f4b1-1_amd64.changes REJECTED
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 - Added a forgotten Build-Depends to successfully build more of the documentation Thanks! -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1001764: More info
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 makes sense. What do I need to install to reproduce this bug? Thanks. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1001764: More info
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 > /usr/lib/python3/dist-packages/numpy/core/_multiarray_tests.cpython-39-x86_64-linux-gnu.so Strange. I had a new version installed (1:1.21.4-3), and it only had python 3.9 files in there. An even newer python3-numpy ws just uploaded, and it has both 3.9 and 3.10. So I'm good there. >> What do I need to install to reproduce this bug? > > You should be able to reproduce this with all packages from unstable, > or all packages from testing and only packages built from > src:python3-defaults from unstable, e.g. python3, python3-all ,etc. > Follow the links in the unstable and testing columns [2], and note the > 'Trigger/Pinned packages' column on the testing page. OK. mrgingham currently will build for only ONE python version: the one that runs when you invoke "python3". You're saying that I should build for ALL the versions that "py3versions" reports, yes? And all the resulting binaries should go into the python3-mrgingham package, yes? Thanks. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: mrcal_2.1-1_amd64.changes REJECTED
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 mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1040942: rosbash: Most binary tools (roscd, rosd, rosls, ....) are unavailable in this package
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 provided in the package. This is because most of the tools are not binaries, but are shell functions. These are supposed to be defined in /usr/share/rosbash/rosbash, but our rosbash package does not ship this file. This file exists in the package sources in tools/rosbash/rosbash, but it is not installed anywhere. This is the bug. Our package does reference the tools (we include all the tab completions). And the package scripts ask for it: dima@fatty:$ source /usr/share/rosbash/catkin_env_hook/15.rosbash.bash bash: /usr/share/rosbash/rosbash: No such file or directory So if we install that file, that would probably fix this bug. Thanks -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1041059: FTBFS against suitesparse 7
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 debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1041410: libdogleg-dev: missing Breaks+Replaces: libdogleg-doc (<< 0.16-2)
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
Bug#957847: Fixed in git
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 debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#977578: python3-opencv: Incomplete dependency on libcharls2
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:42) [GCC 10.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import cv2 Traceback (most recent call last): File "", line 1, in ImportError: libcharls.so.2: cannot open shared object file: No such file or directory I had libcharls2=2.0.0+dfsg-1 (the current stable release). It called that library libCharLS.so.2 instead of libcharls.so.2. Upgrading libcharls2 to the current Debian/sid version fixed the problem. Opencv should update its dependency. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#984917: feedgnuplot: dynamic plots (--stream) do not work
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 --lines --stream --xlen 10 --ylabel 'Bytes/sec' --xlabel seconds
>
> This opens up a gnuplot window but it is not updating every second as
> it should. The lower left corner seems to be showing a coordinate and
> this indeed updates every second, but the plot itself does not. From
> time to time the plot gets redrawn but then again stays fixed.
I can think of several potential causes. First off, let's eliminate X
issues. Can you please add '--terminal "dumb 80 40"' to the feedgnuplot
command? If that works properly, you'll see an ascii plot printed onto
your console every second. Do you see that?
> Doing more diagnosing, I used the --dump switch to see what is being fed into
> gnuplot and when I manually run gnuplot and paste the fragments into it, it
> works just fine. It seems to be related with the fact that gnuplot reads the
> input from the pipe.
Right. The second theory is that it's something related to buffering.
That command should handle it, but let's see. Try this:
1. apt install mawk
2. while true; do sleep 1; cat /proc/net/dev; done |
mawk -Winteractive '/enp6s0/ {if(b) {print $2-b} b=$2}' |
feedgnuplot --lines --stream --xlen 10 --ylabel 'Bytes/sec' --xlabel seconds
--terminal 'dumb 80 40'
So use "mawk -Winteractive" instead of "gawk", and remove the fflush().
Does that make any difference?
> Maybe this is related to the gnuplot version in Bullseye?
Maybe, but I doubt it. Please run the two experiments above, and we can
go from there.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#984917: feedgnuplot: dynamic plots (--stream) do not work
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 https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
