Bug#1039087: removing embeded version of yajl
Here the upstream point of view about the CVE. https://github.com/epics-base/epics-base/issues/405 check with the security team, if their analyse is ok ? Fred -- 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: [c-bloas2] Transition for c-blosc2 v2.14.4
> Thanks a lot Frederic your welcome, I would say in fact, thanks to your for your contributions to Debian :)) -- 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#1039087: Info received (removing embeded version of yajl)
Here the diff between the epics version (debian patch unapplyed) and the
current 2.1.0 version of yajl (debian patch unapplyed).
not that simple...diff --git a/src/yajl.c b/src/yajl.c
index d477893..fdad3f6 100644
--- a/src/yajl.c
+++ b/src/yajl.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2007-2014, Lloyd Hilaiel
+ * Copyright (c) 2007-2011, Lloyd Hilaiel
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
@@ -14,16 +14,16 @@
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
-#include "api/yajl_parse.h"
-#include "yajl_lex.h"
-#include "yajl_parser.h"
-#include "yajl_alloc.h"
-
#include
#include
#include
#include
+#include "yajl_parse.h"
+#include "yajl_lex.h"
+#include "yajl_parser.h"
+#include "yajl_alloc.h"
+
const char *
yajl_status_to_string(yajl_status stat)
{
@@ -62,16 +62,19 @@ yajl_alloc(const yajl_callbacks * callbacks,
}
hand = (yajl_handle) YA_MALLOC(afs, sizeof(struct yajl_handle_t));
+if (hand == NULL) {
+return NULL;
+}
/* copy in pointers to allocation routines */
memcpy((void *) &(hand->alloc), (void *) afs, sizeof(yajl_alloc_funcs));
hand->callbacks = callbacks;
hand->ctx = ctx;
-hand->lexer = NULL;
+hand->lexer = NULL;
hand->bytesConsumed = 0;
hand->decodeBuf = yajl_buf_alloc(&(hand->alloc));
-hand->flags = 0;
+hand->flags = yajl_allow_json5 | yajl_allow_comments;
yajl_bs_init(hand->stateStack, &(hand->alloc));
yajl_bs_push(hand->stateStack, yajl_state_start);
@@ -79,13 +82,16 @@ yajl_alloc(const yajl_callbacks * callbacks,
}
int
-yajl_config(yajl_handle h, yajl_option opt, ...)
+yajl_config(yajl_handle h, int option, ...)
{
+yajl_option opt = option; /* UB to use an enum in va_start */
int rv = 1;
va_list ap;
-va_start(ap, opt);
+va_start(ap, option);
switch(opt) {
+case yajl_allow_json5:
+opt |= yajl_allow_comments; /* JSON5 allows comments */
case yajl_allow_comments:
case yajl_dont_validate_strings:
case yajl_allow_trailing_garbage:
@@ -124,7 +130,11 @@ yajl_parse(yajl_handle hand, const unsigned char * jsonText,
if (hand->lexer == NULL) {
hand->lexer = yajl_lex_alloc(&(hand->alloc),
hand->flags & yajl_allow_comments,
- !(hand->flags & yajl_dont_validate_strings));
+ !(hand->flags & yajl_dont_validate_strings),
+ hand->flags & yajl_allow_json5);
+}
+if (hand->lexer == NULL) {
+return yajl_status_error;
}
status = yajl_do_parse(hand, jsonText, jsonTextLen);
@@ -144,7 +154,8 @@ yajl_complete_parse(yajl_handle hand)
if (hand->lexer == NULL) {
hand->lexer = yajl_lex_alloc(&(hand->alloc),
hand->flags & yajl_allow_comments,
- !(hand->flags & yajl_dont_validate_strings));
+ !(hand->flags & yajl_dont_validate_strings),
+ hand->flags & yajl_allow_json5);
}
return yajl_do_finish(hand);
diff --git a/src/yajl_alloc.c b/src/yajl_alloc.c
index 96ad1d3..2388814 100644
--- a/src/yajl_alloc.c
+++ b/src/yajl_alloc.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2007-2014, Lloyd Hilaiel
+ * Copyright (c) 2007-2011, Lloyd Hilaiel
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
@@ -20,25 +20,23 @@
* free
*/
-#include "yajl_alloc.h"
#include
+#include "yajl_alloc.h"
+
static void * yajl_internal_malloc(void *ctx, size_t sz)
{
-(void)ctx;
return malloc(sz);
}
static void * yajl_internal_realloc(void *ctx, void * previous,
size_t sz)
{
-(void)ctx;
return realloc(previous, sz);
}
static void yajl_internal_free(void *ctx, void * ptr)
{
-(void)ctx;
free(ptr);
}
diff --git a/src/yajl_alloc.h b/src/yajl_alloc.h
index 203c2f9..406310a 100644
--- a/src/yajl_alloc.h
+++ b/src/yajl_alloc.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2007-2014, Lloyd Hilaiel
+ * Copyright (c) 2007-2011, Lloyd Hilaiel
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
@@ -16,19 +16,31 @@
/**
* \file yajl_alloc.h
- * default memory allocation routines for yajl which use malloc/realloc and
- * free
+ * \brief Memory allocation macros for yajl
+ * \author Lloyd Hilaiel
+ *
+ * These macros are used inside YAJL instead of directly calling
+ * malloc(), realloc() or free(). They call the equivalent method
+ * in their \ref yajl_alloc_funcs parameter \a afs.
*/
#ifndef
Bug#1039087: removing embeded version of yajl
following a different path..., I added this in the rules file -export POSIX_CFLAGS+=$(CFLAGS) +export POSIX_CFLAGS+=$(CFLAGS) $(shell pkgconf --cflags yajl) export POSIX_CFLAGS+=$(CPPFLAGS) export POSIX_CPPFLAGS+=$(CPPFLAGS) -export POSIX_LDFLAGS+=$(LDFLAGS) +export POSIX_LDFLAGS+=$(LDFLAGS) $(shell pkgconf --libs yajl) but it ends up like this /usr/bin/gcc -D_GNU_SOURCE -D_DEFAULT_SOURCE -D_X86_64_ -DUNIX -Dlinux -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -I/usr/include/yajl -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -I/usr/include/yajl -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -g -Wall -Werror-implicit-function-declaration -mtune=generic -m64 -I. -I../O.Common -I. -I. -I.. -I../../../../include/compiler/gcc -I../../../../include/os/Linux -I../../../../include -c ../yajl_test.c ../yajl_test.c: In function ‘main’: ../yajl_test.c:209:23: error: ‘yajl_allow_json5’ undeclared (first use in this function) 209 | yajl_config(hand, yajl_allow_json5, 0); | ^~~~ ../yajl_test.c:209:23: note: each undeclared identifier is reported only once for each function it appears in the embeded version seems to provide at least this extra symbols. what about integrating this symbol in the yajl library ? -- 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: [c-bloas2] Transition for c-blosc2 v2.14.4
i am on it. Cheers - Le 25 Mai 24, à 22:26, Antonio Valentino antonio.valent...@tiscali.it a écrit : > Dear Frederic, dear all, > the upgrade from c-blosc2 v2.13.1 to v2.14.4 requires a change in the > SONAME and hence a transition. > > I'm preparing the transition and it should be quite simple, but I would > need the support from a DD to sponsor the upload to experimental that > will go in the new-queue. > > The package is ready in salsa [1]. > I kindly ask to review and upload at your best convenience. > > > The following source package need to be rebuilt: > > pytables > > I'm an uploader of that package so I can upload an updated version of > the package should the binNUM performed by the release team not be > sufficient. > From my test I do not expect no issue. > > In terms of 'ben' lingo, the transition has the following parameters: > > Affected: .build-depends ~ /libblosc2-dev/ > Good: .depends ~ /libblosc2-2t64/ > Bad: .depends ~ /libblosc2-2t64/ > > > I will make a request to schedule a binNMU for the above mentioned > packages on all architectures. > > > [1] https://salsa.debian.org/science-team/c-blosc2 > > kind regards > -- > Antonio Valentino -- 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#1069144: ADvice about htis pocl issue on armel
Hello Andreas,
I have another autopkgtest failure on armel with silx and pocl
The content of check_atomic32 is
def check_atomic32(device):
try:
ctx = pyopencl.Context(devices=[device])
except:
return False, f"Unable to create context on {device}"
else:
queue = pyopencl.CommandQueue(ctx)
src = """
kernel void check_atomic32(global int* ary){
int res = atom_inc(ary);
}
"""
try:
prg = pyopencl.Program(ctx, src).build()
except Exception as err:
return False, f"{type(err)}: {err}"
a = numpy.zeros(1, numpy.int32)
d = cla.to_device(queue, a)
prg.check_atomic32(queue, (1024,), (32,), d.data).wait()
value = d.get()[0]
return value == 1024, f"Got the proper value 1024=={value}"
1019s Testing with python3.12:
1024s pocl warning: encountered incomplete implementation in
./lib/CL/clGetDeviceInfo.c:98
1026s
dlopen("/tmp/autopkgtest-lxc.1tg98r_u/downtmp/autopkgtest_tmp/.cache/pocl/kcache/GI/PODCELNLNPFCGBFNGLEIHDEIECBKNFCDBNAPP/check_atomic32/0-0-0/check_atomic32.so")
failed with
'/tmp/autopkgtest-lxc.1tg98r_u/downtmp/autopkgtest_tmp/.cache/pocl/kcache/GI/PODCELNLNPFCGBFNGLEIHDEIECBKNFCDBNAPP/check_atomic32/0-0-0/check_atomic32.so:
undefined symbol: __atomic_fetch_add_4'.
1026s note: missing symbols in the kernel binary might be reported as 'file not
found' errors.
I found something similar about scipy here
https://github.com/scipy/scipy/issues/19982
I am wondering if this is an issue with pocl or llvm on armel.
Fred
--
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#1060318: Could be related to LLVM rather than PoCL: works with LLVM-15
bravo !!! This is team works. :)) Cheers Frederic -- 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#1065724: epics-base: FTBFS on amd64: Tests failed
Here an analyse of the FTBFS On the amd64, I have two failures dureing the test Test Summary Report --- testPVAServer.t(Wstat: 0 Tests: 0 Failed: 0) Parse errors: No plan found in TAP output Files=6, Tests=129, 1 wallclock secs ( 0.05 usr 0.01 sys + 0.09 cusr 0.06 csys = 0.21 CPU) Result: FAIL --- and Test Summary Report --- testInetAddressUtils.t (Wstat: 0 Tests: 65 Failed: 0) TODO passed: 64 testChannelAccess.t (Wstat: 0 Tests: 152 Failed: 0) TODO passed: 45 testServerContext.t (Wstat: 0 Tests: 0 Failed: 0) Parse errors: No plan found in TAP output Files=12, Tests=6381, 27 wallclock secs ( 0.38 usr 0.03 sys + 0.42 cusr 0.18 csys = 1.01 CPU) Result: FAIL --- on arm64, the first test seems to work... testPVAServer.t .. 1..1 pvAccess Server v7.1.7 Active configuration (w/ defaults) EPICS_PVAS_INTF_ADDR_LIST = 0.0.0.0:5075 EPICS_PVAS_BEACON_ADDR_LIST = EPICS_PVAS_AUTO_BEACON_ADDR_LIST = YES EPICS_PVAS_BEACON_PERIOD = 15 EPICS_PVAS_BROADCAST_PORT = 5076 EPICS_PVAS_SERVER_PORT = 5075 EPICS_PVAS_PROVIDER_NAMES = local ok 1 - ctx.get()!=0 ok I am wondering if this is not something related to the network configuration. i386 Test Summary Report --- printfTest.t (Wstat: 256 (exited 1) Tests: 97 Failed: 1) Failed test: 70 Non-zero exit status: 1 Files=22, Tests=5033, 29 wallclock secs ( 0.42 usr 0.04 sys + 1.74 cusr 0.34 csys = 2.54 CPU) Result: FAIL --- Test Summary Report --- testInetAddressUtils.t (Wstat: 0 Tests: 65 Failed: 0) TODO passed: 64 testChannelAccess.t (Wstat: 0 Tests: 152 Failed: 0) TODO passed: 45 testServerContext.t (Wstat: 0 Tests: 0 Failed: 0) Parse errors: No plan found in TAP output Files=12, Tests=6381, 26 wallclock secs ( 0.42 usr 0.02 sys + 0.46 cusr 0.20 csys = 1.10 CPU) Result: FAIL --- Test Summary Report --- testPVAServer.t(Wstat: 0 Tests: 0 Failed: 0) Parse errors: No plan found in TAP output Files=6, Tests=129, 0 wallclock secs ( 0.08 usr 0.02 sys + 0.10 cusr 0.04 csys = 0.24 CPU) Result: FAIL --- And there is a bunch of unsupported architectures. /<>/src/tools/EpicsHostArch.pl: Architecture 'mips64el-linux-gnuabi64-thread-multi' not recognized /<>/src/tools/EpicsHostArch.pl: Architecture 'powerpc64le-linux-gnu-thread-multi' not recognized /<>/src/tools/EpicsHostArch.pl: Architecture 'riscv64-linux-gnu-thread-multi' not recognized /<>/src/tools/EpicsHostArch.pl: Architecture 's390x-linux-gnu-thread-multi' not recognized -- 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#1060318: Info received (Bug#1060318: Info received (Bug#1060318: Info received (Bug#1060318: Info received (silx: autopkgtest failure with Python 3.12))))
A workaround for now is to use this POCL_WORK_GROUP_METHOD=cbs Jerome is helping also here trying to understand the problem... https://github.com/silx-kit/silx/issues/4073 -- 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#1060318: Info received (Bug#1060318: Info received (Bug#1060318: Info received (Bug#1060318: Info received (silx: autopkgtest failure with Python 3.12))))
POCL_WORK_GROUP_METHOD=cbs python3 test.py make it works $ POCL_WORK_GROUP_METHOD=cbs python3 test.py [SubCFG] Form SubCFGs in bsort_all [SubCFG] Form SubCFGs in bsort_horizontal [SubCFG] Form SubCFGs in bsort_vertical [SubCFG] Form SubCFGs in bsort_book [SubCFG] Form SubCFGs in bsort_file [SubCFG] Form SubCFGs in medfilt2d [SubCFG] Form SubCFGs in medfilt2d -- 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#1060318: Info received (Bug#1060318: Info received (Bug#1060318: Info received (silx: autopkgtest failure with Python 3.12)))
With latest version (PAS OK) $ dpkg -l | grep pocl ii libpocl2-common5.0-2.1 all common files for the pocl library ii libpocl2t64:amd64 5.0-2.1 amd64Portable Computing Language library ii pocl-opencl-icd:amd64 5.0-2.1 amd64pocl ICD -- 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#1060318: Info received (Bug#1060318: Info received (silx: autopkgtest failure with Python 3.12))
Debian12 (OK) $ dpkg -l | grep pocl ii libpocl2:amd64 3.1-3+deb12u1 amd64Portable Computing Language library ii libpocl2-common 3.1-3+deb12u1 all common files for the pocl library ii pocl-opencl-icd:amd643.1-3+deb12u1 amd64pocl ICD unstable (NOT OK) $ dpkg -l | grep pocl ii libpocl2:amd64 5.0-2 amd64Portable Computing Language library ii libpocl2-common5.0-2 all common files for the pocl library ii pocl-opencl-icd:amd64 5.0-2 amd64pocl ICD -- 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#1060318: Info received (Bug#1060318: Info received (silx: autopkgtest failure with Python 3.12))
On Debian12 it works out of the box $ POCL_DEBUG=1 python3 test.py [2024-03-11 10:05:31.837738936]POCL: in fn pocl_install_sigfpe_handler at line 229: | GENERAL | Installing SIGFPE handler... [2024-03-11 10:05:31.868890390]POCL: in fn POclCreateCommandQueue at line 98: | GENERAL | Created Command Queue 3 (0x1ee13c0) on device 0 [2024-03-11 10:05:31.868917030]POCL: in fn POclCreateContext at line 227: | GENERAL | Created Context 2 (0x1ee0e40) [2024-03-11 10:05:31.868966549]POCL: in fn POclCreateCommandQueue at line 98: | GENERAL | Created Command Queue 4 (0x1f31f10) on device 0 [2024-03-11 10:05:31.874596495]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel s8_to_float (0x1fc5540) [2024-03-11 10:05:31.874606285]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel u8_to_float (0x1fc5610) [2024-03-11 10:05:31.874617005]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel s16_to_float (0x1fc5730) [2024-03-11 10:05:31.874622275]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel u16_to_float (0x1f81e70) [2024-03-11 10:05:31.874632075]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel u32_to_float (0x1f81fb0) [2024-03-11 10:05:31.874638955]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel s32_to_float (0x1f820f0) [2024-03-11 10:05:31.874646635]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel corrections (0x1f82230) [2024-03-11 10:05:31.874654714]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel corrections2 (0x1f82590) [2024-03-11 10:05:31.874663744]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel corrections3Poisson (0x1f82990) [2024-03-11 10:05:31.874669284]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel corrections3 (0x1f82d90) [2024-03-11 10:05:31.874673814]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel bsort_all (0x201ded0) [2024-03-11 10:05:31.874681154]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel bsort_horizontal (0x201e010) [2024-03-11 10:05:31.874685604]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel bsort_vertical (0x201e150) [2024-03-11 10:05:31.874691454]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel bsort_book (0x201e290) [2024-03-11 10:05:31.874699564]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel bsort_file (0x201e3d0) [2024-03-11 10:05:31.874709654]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel medfilt2d (0x201e510) [2024-03-11 10:05:31.877001426]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel s8_to_float (0x1fdf150) [2024-03-11 10:05:31.877011365]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel u8_to_float (0x20103f0) [2024-03-11 10:05:31.877019735]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel s16_to_float (0x1f60f90) [2024-03-11 10:05:31.877025545]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel u16_to_float (0x1f61060) [2024-03-11 10:05:31.877030655]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel u32_to_float (0x1f5f1f0) [2024-03-11 10:05:31.877038395]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel s32_to_float (0x1f5f310) [2024-03-11 10:05:31.877043475]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel corrections (0x1f60500) [2024-03-11 10:05:31.877055965]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel corrections2 (0x200efa0) [2024-03-11 10:05:31.877061275]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel corrections3Poisson (0x200f3a0) [2024-03-11 10:05:31.877064514]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel corrections3 (0x200f7a0) [2024-03-11 10:05:31.877071304]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel bsort_all (0x200fc20) [2024-03-11 10:05:31.877079984]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel bsort_horizontal (0x200fd60) [2024-03-11 10:05:31.877087744]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel bsort_vertical (0x1f613b0) [2024-03-11 10:05:31.877094244]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel bsort_book (0x1f614f0) [2024-03-11 10:05:31.877098614]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel bsort_file (0x1f61630) [2024-03-11 10:05:31.877102884]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel medfilt2d (0x1f61770) [2024-03-11 10:05:31.877723934]POCL: in fn POclCreateKernel at line 138: | GENERAL | Created Kernel medfilt2d (0x1f61e00) [2024-03-11 10:05:31.878064028]POCL: in fn POclSetKernelArg at line 107: | GENERAL | Kernel
Bug#1060318: Info received (silx: autopkgtest failure with Python 3.12)
We already had the warning message [2024-03-10 14:26:18.189651850]POCL: in fn void appendToProgramBuildLog(cl_program, unsigned int, std::string&) at line 111: | ERROR | warning: /home/picca/.cache/pocl/kcache/tempfile_msXjLw.cl:861:14: AVX vector argument of type '__private float8' (vector of 8 'float' values) without 'avx' enabled changes the ABI warning: /home/picca/.cache/pocl/kcache/tempfile_msXjLw.cl:893:14: AVX vector argument of type '__private float8' (vector of 8 'float' values) without 'avx' enabled changes the ABI warning: /home/picca/.cache/pocl/kcache/tempfile_msXjLw.cl:933:16: AVX vector argument of type '__private float8' (vector of 8 'float' values) without 'avx' enabled changes the ABI warning: /home/picca/.cache/pocl/kcache/tempfile_msXjLw.cl:1266:26: AVX vector argument of type '__private float8' (vector of 8 'float' values) without 'avx' enabled changes the ABI [2024-03-10 14:26:18.195708864]POCL: in fn llvm::Module* getKernelLibrary(cl_device_id, PoclLLVMContextData*) at line 992: | LLVM | Using /lib/x86_64-linux-gnu/../../share/pocl/kernel-x86_64-pc-linux-gnu-sse41.bc as the built-in lib. [2024-03-10 14:26:20.314065808]POCL: in fn int pocl_llvm_build_program(cl_program, unsigned int, cl_uint, _cl_program* const*, const char**, int) at line 756: | LLVM | Writing program.bc to /home/picca/.cache/pocl/kcache/LK/MONFDAKCFIMDEBOPEIHEOILBLCLBMGGNLPDID/program.bc. /usr/lib/python3/dist-packages/pyopencl/cache.py:417: CompilerWarning: From-source build succeeded, but resulted in non-empty logs: Build on succeeded, but said: warning: /home/picca/.cache/pocl/kcache/tempfile_msXjLw.cl:861:14: AVX vector argument of type '__private float8' (vector of 8 'float' values) without 'avx' enabled changes the ABI warning: /home/picca/.cache/pocl/kcache/tempfile_msXjLw.cl:893:14: AVX vector argument of type '__private float8' (vector of 8 'float' values) without 'avx' enabled changes the ABI warning: /home/picca/.cache/pocl/kcache/tempfile_msXjLw.cl:933:16: AVX vector argument of type '__private float8' (vector of 8 'float' values) without 'avx' enabled changes the ABI warning: /home/picca/.cache/pocl/kcache/tempfile_msXjLw.cl:1266:26: AVX vector argument of type '__private float8' (vector of 8 'float' values) without 'avx' enabled changes the ABI prg.build(options_bytes, [devices[i] for i in to_be_built_indices]) -- 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#1060318: Info received (silx: autopkgtest failure with Python 3.12)
It seems that here is an error here [2024-03-10 14:22:19.550588408]POCL: in fn int pocl_llvm_build_program(cl_program, unsigned int, cl_uint, _cl_program* const*, const char**, int) at line 420: | LLVM | all build options: -Dcl_khr_int64 -DPOCL_DEVICE_ADDRESS_BITS=64 -D__USE_CLANG_OPENCL_C_H -xcl -Dinline= -I. -cl-kernel-arg-info -opaque-pointers -D NIMAGE=1 -I /usr/lib/python3/dist-packages/pyopencl/cl -D__ENDIAN_LITTLE__=1 -D__IMAGE_SUPPORT__=1 -DCL_DEVICE_MAX_GLOBAL_VARIABLE_SIZE=64000 -D__OPENCL_VERSION__=300 -cl-std=CL3.0 -D__OPENCL_C_VERSION__=300 -Dcl_khr_byte_addressable_store=1 -Dcl_khr_global_int32_base_atomics=1 -Dcl_khr_global_int32_extended_atomics=1 -Dcl_khr_local_int32_base_atomics=1 -Dcl_khr_local_int32_extended_atomics=1 -Dcl_khr_3d_image_writes=1 -Dcl_khr_command_buffer=1 -Dcl_pocl_pinned_buffers=1 -Dcl_khr_subgroups=1 -Dcl_intel_unified_shared_memory=1 -Dcl_khr_subgroup_ballot=1 -Dcl_khr_subgroup_shuffle=1 -Dcl_intel_subgroups=1 -Dcl_intel_required_subgroup_size=1 -Dcl_ext_float_atomics=1 -Dcl_khr_spir=1 -Dcl_khr_fp64=1 -Dcl_khr_int64_base_atomics=1 -Dcl_khr_int64_extended_atomics=1 -D__opencl_c_3d_image_writes=1 -D__opencl_c_images=1 -D__openc l_c_atomic_order_acq_rel=1 -D__opencl_c_atomic_order_seq_cst=1 -D__opencl_c_atomic_scope_device=1 -D__opencl_c_program_scope_global_variables=1 -D__opencl_c_generic_address_space=1 -D__opencl_c_subgroups=1 -D__opencl_c_atomic_scope_all_devices=1 -D__opencl_c_read_write_images=1 -D__opencl_c_fp64=1 -D__opencl_c_ext_fp32_global_atomic_add=1 -D__opencl_c_ext_fp32_local_atomic_add=1 -D__opencl_c_ext_fp32_global_atomic_min_max=1 -D__opencl_c_ext_fp32_local_atomic_min_max=1 -D__opencl_c_ext_fp64_global_atomic_add=1 -D__opencl_c_ext_fp64_local_atomic_add=1 -D__opencl_c_ext_fp64_global_atomic_min_max=1 -D__opencl_c_ext_fp64_local_atomic_min_max=1 -D__opencl_c_int64=1 -cl-ext=-all,+cl_khr_byte_addressable_store,+cl_khr_global_int32_base_atomics,+cl_khr_global_int32_extended_atomics,+cl_khr_local_int32_base_atomics,+cl_khr_local_int32_extended_atomics,+cl_khr_3d_image_writes,+cl_khr_command_buffer,+cl_pocl_pinned_buffers,+cl_khr_subgroups,+cl_intel_unified_shared_memory,+cl_khr_subgroup_ballo t,+cl_khr_subgroup_shuffle,+cl_intel_subgroups,+cl_intel_required_subgroup_size,+cl_ext_float_atomics,+cl_khr_spir,+cl_khr_fp64,+cl_khr_int64_base_atomics,+cl_khr_int64_extended_atomics,+__opencl_c_3d_image_writes,+__opencl_c_images,+__opencl_c_atomic_order_acq_rel,+__opencl_c_atomic_order_seq_cst,+__opencl_c_atomic_scope_device,+__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space,+__opencl_c_subgroups,+__opencl_c_atomic_scope_all_devices,+__opencl_c_read_write_images,+__opencl_c_fp64,+__opencl_c_ext_fp32_global_atomic_add,+__opencl_c_ext_fp32_local_atomic_add,+__opencl_c_ext_fp32_global_atomic_min_max,+__opencl_c_ext_fp32_local_atomic_min_max,+__opencl_c_ext_fp64_global_atomic_add,+__opencl_c_ext_fp64_local_atomic_add,+__opencl_c_ext_fp64_global_atomic_min_max,+__opencl_c_ext_fp64_local_atomic_min_max,+__opencl_c_int64 -fno-builtin -triple=x86_64-pc-linux-gnu -target-cpu penryn 4 warnings generated. [2024-03-10 14:22:20.986369997]POCL: in fn void appendToProgramBuildLog(cl_program, unsigned int, std::string&) at line 111: | ERROR | warning: /home/picca/.cache/pocl/kcache/tempfile_NcEztR.cl:861:14: AVX vector argument of type '__private float8' (vector of 8 'float' values) without 'avx' enabled changes the ABI warning: /home/picca/.cache/pocl/kcache/tempfile_NcEztR.cl:893:14: AVX vector argument of type '__private float8' (vector of 8 'float' values) without 'avx' enabled changes the ABI warning: /home/picca/.cache/pocl/kcache/tempfile_NcEztR.cl:933:16: AVX vector argument of type '__private float8' (vector of 8 'float' values) without 'avx' enabled changes the ABI warning: /home/picca/.cache/pocl/kcache/tempfile_NcEztR.cl:1266:26: AVX vector argument of type '__private float8' (vector of 8 'float' values) without 'avx' enabled changes the ABI [2024-03-10 14:22:20.992890946]POCL: in fn llvm::Module* getKernelLibrary(cl_device_id, PoclLLVMContextData*) at line 992: | LLVM | Using /lib/x86_64-linux-gnu/../../share/pocl/kernel-x86_64-pc-linux-gnu-sse41.bc as the built-in lib. [2024-03-10 14:22:23.151001890]POCL: in fn int pocl_llvm_build_program(cl_program, unsigned int, cl_uint, _cl_program* const*, const char**, int) at line 756: | LLVM | Writing program.bc to /home/picca/.cache/pocl/kcache/OO/KDMNEJOLAKKIBKBOIDNJJPAEHMJELJCBLMGBG/program.bc. /usr/lib/python3/dist-packages/pyopencl/cache.py:417: CompilerWarning: Non-empty compiler output encountered. Set the environment variable PYOPENCL_COMPILER_OUTPUT=1 to see more. prg.build(options_bytes, [devices[i] for i in to_be_built_indices]) let export the PYOPENCL_COMPILER_OUTPUT -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net
Bug#1060318: Info received (silx: autopkgtest failure with Python 3.12)
Here a log with POCL_DEBUG=all picca@cush:/tmp$ python3 test.py [2024-03-10 14:22:19.462191847]POCL: in fn pocl_install_sigfpe_handler at line 265: | GENERAL | Installing SIGFPE handler... [2024-03-10 14:22:19.475550217]POCL: in fn POclCreateCommandQueue at line 103: | GENERAL | Created Command Queue 3 (0x27d55b0) on device 0 [2024-03-10 14:22:19.475690904]POCL: in fn void pocl_llvm_create_context(cl_context) at line 592: | LLVM | Created context 2 (0x27d4960) [2024-03-10 14:22:19.475732695]POCL: in fn POclCreateContext at line 232: | GENERAL | Created Context 2 (0x27d4960) [2024-03-10 14:22:19.475822461]POCL: in fn POclRetainContext at line 32: | REFCOUNTS | Retain Context 2 (0x27d4960), Refcount: 2 [2024-03-10 14:22:19.475856682]POCL: in fn POclCreateCommandQueue at line 103: | GENERAL | Created Command Queue 4 (0x27d77b0) on device 0 [2024-03-10 14:22:19.492655607]POCL: in fn POclRetainContext at line 32: | REFCOUNTS | Retain Context 2 (0x27d4960), Refcount: 3 [2024-03-10 14:22:19.492795776]POCL: in fn compile_and_link_program at line 718: | LLVM | building program with options -I /usr/lib/python3/dist-packages/pyopencl/cl [2024-03-10 14:22:19.492824004]POCL: in fn compile_and_link_program at line 755: | LLVM | building program for 1 devs with options -I /usr/lib/python3/dist-packages/pyopencl/cl [2024-03-10 14:22:19.492847621]POCL: in fn compile_and_link_program at line 759: | LLVM | BUILDING for device: cpu [2024-03-10 14:22:19.497354940]POCL: in fn POclRetainContext at line 32: | REFCOUNTS | Retain Context 2 (0x27d4960), Refcount: 4 [2024-03-10 14:22:19.497919687]POCL: in fn POclRetainContext at line 32: | REFCOUNTS | Retain Context 2 (0x27d4960), Refcount: 5 [2024-03-10 14:22:19.497963205]POCL: in fn POclCreateBuffer at line 292: |MEMORY | Created Buffer 6 (0x2801b90), MEM_HOST_PTR: (nil), device_ptrs[0]: (nil), SIZE 4, FLAGS 1 [2024-03-10 14:22:19.498110078]POCL: in fn pocl_driver_alloc_mem_obj at line 428: |MEMORY | Basic device ALLOC 0x27f7380 / size 4 [2024-03-10 14:22:19.498162446]POCL: in fn POclRetainCommandQueue at line 35: | REFCOUNTS | Retain Command Queue 4 (0x27d77b0), Refcount: 2 [2024-03-10 14:22:19.498187844]POCL: in fn pocl_create_event at line 527: |EVENTS | Created event 1 (0x27e4e60) Command write_buffer [2024-03-10 14:22:19.498211789]POCL: in fn pocl_create_command_struct at line 648: |EVENTS | event pointer provided [2024-03-10 14:22:19.498232543]POCL: in fn pocl_create_command_struct at line 668: |EVENTS | Created immediate command struct: CMD 0x27e4d50 (event 1 / 0x27e4e60, type: write_buffer) [2024-03-10 14:22:19.498259772]POCL: in fn pocl_command_enqueue at line 1290: |EVENTS | In-order Q; adding event syncs [2024-03-10 14:22:19.498280767]POCL: in fn pocl_command_enqueue at line 1335: |EVENTS | Pushed Event 1 to CQ 4. [2024-03-10 14:22:19.498303076]POCL: in fn pocl_update_event_queued at line 2177: |EVENTS | Event queued: 1 [2024-03-10 14:22:19.498326609]POCL: in fn pocl_update_event_submitted at line 2197: |EVENTS | Event submitted: 1 [2024-03-10 14:22:19.498451579]POCL: in fn pocl_update_event_running_unlocked at line 2216: |EVENTS | Event running: 1 [2024-03-10 14:22:19.498484119]POCL: in fn pocl_update_event_finished at line 2368: |EVENTS | cpu: Command complete, event 1 [2024-03-10 14:22:19.498509038]POCL: in fn pocl_exec_command at line 343: |TIMING | >>>32.497 usEvent Write Buffer [2024-03-10 14:22:19.498531904]POCL: in fn POclReleaseMemObject at line 53: | REFCOUNTS | Release Memory Object 6 (0x2801b90), Refcount: 1 [2024-03-10 14:22:19.498562333]POCL: in fn POclReleaseEvent at line 39: | REFCOUNTS | Release Event 1 (0x27e4e60), Refcount: 2 [2024-03-10 14:22:19.498656679]POCL: in fn POclCreateKernel at line 133: | GENERAL | Created Kernel check_atomic32 (0x27f74c0) [2024-03-10 14:22:19.501056049]POCL: in fn POclRetainContext at line 32: | REFCOUNTS | Retain Context 2 (0x27d4960), Refcount: 6 [2024-03-10 14:22:19.501139297]POCL: in fn POclReleaseContext at line 53: | REFCOUNTS | Release Context 2 (0x27d4960), Refcount: 5 [2024-03-10 14:22:19.503196833]POCL: in fn POclSetKernelArg at line 107: | GENERAL | Kernel check_atomic32 || SetArg idx 0 || int* || Local 0 || Size 8 || Value 0x7fff7b47ae20 || Pointer 0x2801b90 || *(uint32*)Value:0 || *(uint64*)Value:0 || Hex Value: 901B8002 [2024-03-10 14:22:19.503275428]POCL: in fn pocl_kernel_calc_wg_size at line 182: | GENERAL | Preparing kernel check_atomic32 with local size 32 x 1 x 1 group sizes 32 x 1 x 1... [2024-03-10 14:22:19.503311773]POCL: in fn POclRetainCommandQueue at line 35: | REFCOUNTS | Retain Command Queue 4 (0x27d77b0), Refcount: 3 [2024-03-10 14:22:19.503350256]POCL: in fn pocl_create_event at line 527: |EVENTS | Created event 2
Bug#1060318: Info received (silx: autopkgtest failure with Python 3.12)
Here a small script which trigger the errorfrom silx.image import medianfilter import numpy IMG = numpy.arange(1.0).reshape(100, 100) KERNEL = (1, 1) res = medianfilter.medfilt2d( image=IMG, kernel_size=KERNEL, engine="opencl", ) -- 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#1060318: silx: autopkgtest failure with Python 3.12
In order to reproduce the bug, install python3-silx 2.0.0+dfsg-1 python3-pytest-xvfb pocl-opencl-icd then $ pytest --pyargs silx.image.test.test_medianfilter -v === test session starts === platform linux -- Python 3.11.8, pytest-8.0.2, pluggy-1.4.0 -- /usr/bin/python3 cachedir: .pytest_cache rootdir: /home/picca/debian/science-team/pyvkfft plugins: anyio-4.2.0, dials-data-2.4.0, xvfb-3.0.0 collected 2 items ::TestMedianFilterEngines::testCppMedFilt2d PASSED [ 50%] ::TestMedianFilterEngines::testOpenCLMedFilt2d Abandon the OpenCL test fails -- 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#1060318: silx: autopkgtest failure with Python 3.12
With the silx 2.0.0 version the failire is located in the OpenCL part the backtrace is this one when running the median filter # build the packag eintht echroot and enter into it once build dgit --gbp sbuild --finished-build-commands '%SBUILD_SHELL' run this command to obtain the backtrace... DEBUGINFOD_URLS="https://debuginfod.debian.net; PYTHONPATH=. gdb --args python3.11 -m pytest --pyarg silx silx/image/test/test_medianfilter.py here the backtrace. Thread 1 "python3.11" received signal SIGABRT, Aborted. 0x77d3516c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x77d3516c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x77ce7472 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x77cd14b2 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x77cd13d5 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x77ce03a2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x7344770d in pocl::Kernel::createParallelRegionBefore (this=, B=0x8980180) at ../llvmopencl/./lib/llvmopencl/Kernel.cc:129 #6 pocl::Kernel::getParallelRegions (this=, LI=..., ParallelRegions=0x7fff4860) at ../llvmopencl/./lib/llvmopencl/Kernel.cc:193 #7 0x7346ab82 in pocl::WorkitemLoopsImpl::processFunction (this=this@entry=0x7fff47c0, F=...) at ../llvmopencl/./lib/llvmopencl/WorkitemLoops.cc:445 #8 0x7346cb8d in pocl::WorkitemLoopsImpl::runOnFunction (this=0x7fff47c0, F=...) at ../llvmopencl/./lib/llvmopencl/WorkitemLoops.cc:183 #9 0x7346ecac in pocl::WorkitemLoops::run (this=, F=..., AM=...) at ../llvmopencl/./lib/llvmopencl/WorkitemLoops.cc:1490 #10 0x7346ede5 in llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) (this=, IR=..., AM=...) at /usr/lib/llvm-16/include/llvm/IR/PassManagerInternal.h:89 #11 0x7fffe91d7579 in run () at llvm/include/llvm/IR/PassManager.h:517 #12 0x7fffeaeedb01 in llvm::detail::PassModel>, llvm::PreservedAnalyses, llvm::AnalysisManager>::run(llvm::Function&, llvm::AnalysisManager&) () at llvm/include/llvm/IR/PassManagerInternal.h:89 #13 0x7fffe91dade6 in run () at build-llvm/tools/clang/stage2-bins/llvm/lib/IR/PassManager.cpp:124 #14 0x7fffeaeed921 in llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) () at llvm/include/llvm/IR/PassManagerInternal.h:89 #15 0x7348cd85 in llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (AM=..., IR=..., this=0x7fff50b8) at /usr/include/c++/13/bits/unique_ptr.h:199 #16 PoCLModulePassManager::run (this=0x7fff4f98, Bitcode=...) at ./lib/CL/pocl_llvm_wg.cc:322 #17 0x73494b14 in TwoStagePoCLModulePassManager::run (Bitcode=..., this=0x7fff4e10) at ./lib/CL/pocl_llvm_wg.cc:386 #18 runKernelCompilerPasses (Device=Device@entry=0x151f050, Mod=...) at ./lib/CL/pocl_llvm_wg.cc:727 #19 0x73496302 in pocl_llvm_run_pocl_passes(llvm::Module*, _cl_command_run*, llvm::LLVMContext*, PoclLLVMContextData*, _cl_kernel*, _cl_device_id*, int) [clone .isra.0] ( Bitcode=Bitcode@entry=0x16d6ef0, RunCommand=RunCommand@entry=0x7fffbd40, PoclCtx=PoclCtx@entry=0x157e340, Kernel=Kernel@entry=0x7fffbcb0, Device=Device@entry=0x151f050, Specialize=Specialize@entry=0, LLVMContext=) at ./lib/CL/pocl_llvm_wg.cc:1101 #20 0x7348ff32 in pocl_llvm_generate_workgroup_function_nowrite (DeviceI=DeviceI@entry=0, Device=Device@entry=0x151f050, Kernel=Kernel@entry=0x7fffbcb0, Command=Command@entry=0x7fffbd40, Output=Output@entry=0x7fff6548, Specialize=Specialize@entry=0) at ./lib/CL/pocl_llvm_wg.cc:1147 #21 0x73424b2f in llvm_codegen (output=output@entry=0x30d19f0 "/sbuild-nonexistent/.cache/pocl/kcache/BC/KCELIMKPIAEADDLPJHGMOMPOPMNFLCMCBIOCK/medfilt2d/0-0-0/medfilt2d.so", device_i=device_i@entry=0, kernel=kernel@entry=0x7fffbcb0, device=0x151f050, command=command@entry=0x7fffbd40, specialize=specialize@entry=0) at ./lib/CL/devices/common.c:137 #22 0x7342778e in pocl_check_kernel_disk_cache (command=command@entry=0x7fffbd40, specialized=specialized@entry=0) at ./lib/CL/devices/common.c:983 #23 0x73427e7a in pocl_check_kernel_dlhandle_cache (command=command@entry=0x7fffbd40, retain=retain@entry=0, specialize=specialize@entry=0) at ./lib/CL/devices/common.c:1108 #24 0x7fffe477fc3d in pocl_basic_compile_kernel (cmd=0x7fffbd40, kernel=0x7fffbcb0, device=, specialize=0) at ./lib/CL/devices/basic/basic.c:682 #25 0x7342c71f in pocl_driver_build_poclbinary (program=0x15a6170, device_i=) at ./lib/CL/devices/common_driver.c:969 #26 0x733f291e in get_binary_sizes (sizes=, program=) at ./lib/CL/clGetProgramInfo.c:54 #27 POclGetProgramInfo (program=0x15a6170, param_name=, param_value_size=, param_value=0x15116f0, param_value_size_ret=0x7fffbf70) at ./lib/CL/clGetProgramInfo.c:143 #28 0x736a46ae in pyopencl::program::get_info
Bug#1043240: transition: pandas 1.5 -> 2.1 - please upload fixes
for dials it seems that the CI works with pandas 2.1 from experimental. https://ci.debian.net/packages/d/dials/unstable/amd64/41962612/#S4 - Le 30 Jan 24, à 9:05, Rebecca N. Palmer rebecca_pal...@zoho.com a écrit : > I intend to upload pandas 2.x to unstable soon. These packages have a > patch in their bug - please upload them (I'm a DM, I can't do that), or > if you think this patch won't work or isn't a good idea, tell me why: > dials influxdb-python python-altair python-feather-format seaborn tqdm > > In particular, I'd like the seaborn fix uploaded before pandas, so I can > set Breaks for it. (The pandas documentation build-depends on seaborn.) -- 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#1038443: ITP: c-blosc2 -- Fast, compressed, persistent binary data store library for C
I am on it. Cheers - Le 12 Nov 23, à 8:06, Antonio Valentino antonio.valent...@tiscali.it a écrit : > Dear Frederic, > I kindly ask your sponsor the initial upload of the c-blosc2 library. > It is a compression library that in now (since PyTables v3.8) a > dependency of the PyTables package (currently maintained in Debian Science). > An update of debian package for PyTables (currently v3.7) is needed to > support Python 3.12. > > Moreover I think that c-blosc2 will soon become a dependency also for zarr. > > I have created a repository on salsa > > https://salsa.debian.org/science-team/c-blosc2 > > and the package is now ready to be reviewed and upload. > > The ITP bug is #1038443 > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038443) and the > upstream repository is on GitHub: https://github.com/Blosc/c-blosc2. > > With respect to the initial ITP the package has been now updated to v2.11.2. > > After the initial upload I will take care of maintaining the package and > uploading new versions. > > > kind regards > Antonio > > Il 18/06/23 17:43, Antonio Valentino ha scritto: >> Dear all, >> c-blosc2 is "Fast, compressed, persistent binary data store library" >> (see details below). >> >> Since v3.8 PyTables (maintained in Debian Science) requires also c-blosc2. >> >> I would like to maintain the package in Debian Science and I'm looking >> for a sponsor for the initial upload. >> >> The git repository for the Debian package of c-blosc2 is currently in my >> personal area on salsa: >> https://salsa.debian.org/antonio.valentino/c-blosc2 >> >> I will quickly move it to https://salsa.debian.org/science-team/c-blosc2 >> as soon as someone accepts to sponsor it. >> >> >> kind regards >> antonio >> >> Messaggio Inoltrato >> Oggetto: Bug#1038443: ITP: c-blosc2 -- Fast, compressed, persistent >> binary data store library for C >> Rispedito-Data: Sun, 18 Jun 2023 11:15:01 + >> Rispedito-Da: Antonio Valentino >> Rispedito-A: debian-bugs-d...@lists.debian.org >> Rispedito-CC: debian-de...@lists.debian.org, w...@debian.org >> Data: Sun, 18 Jun 2023 13:12:24 +0200 >> Mittente: Antonio Valentino >> Rispondi-a: Antonio Valentino , >> 1038...@bugs.debian.org >> A: Debian Bug Tracking System >> >> Package: wnpp >> Severity: wishlist >> X-Debbugs-Cc: debian-de...@lists.debian.org >> Owner: Antonio Valentino >> >> * Package name : c-blosc2 >> Version : 2.9.2 >> Upstream Author : Antonio Valentino >> * URL : >> * License : BSD-3-clause >> Programming Lang: C >> Description : Fast, compressed, persistent binary data store >> library for C >> >> Binary package names: libblosc2-2, libblosc2-dev >> >> Blosc is a high performance compressor optimized for binary data. >> It has been designed to transmit data to the processor cache faster >> than the traditional, non-compressed, direct memory fetch approach >> via a memcpy() OS call. Blosc main goal is not just to reduce the >> size of large datasets on-disk or in-memory, but also to accelerate >> memory-bound computations. >> . >> C-Blosc2 is the new major version of C-Blosc, and tries hard to be >> backward compatible with both the C-Blosc1 API and its in-memory >> format. However, the reverse thing is generally not true for the >> format; buffers generated with >> C-Blosc2 are not format-compatible with C-Blosc1 (i.e. forward >> compatibility is not supported). In case you want to ensure full >> API compatibility with C-Blosc1 API, define the BLOSC1_COMPAT symbol. > > -- > Antonio Valentino -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
command line to extract the list of source package of a maintainer
Hello, Do we have a cmd line tool which allows to extract the list of the source package and the vcs-x info for a given maintainer or uploaders. via udd (for an uptodate info)... The idea is to generate a mrconfig file for a dedicated team instead of doing it manually. thanks Frederic -- 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#1040159: epics-base: embedded yajl is vulnerable to CVE-2017-16516 and CVE-2022-24795
Hello, I dicovered that upstream modifier yajl in order to support json5. I am wondering if their modification could not be integrated in our yajl. I fill a burg report about this idea here https://github.com/epics-base/epics-base/issues/405 Tell me what is your opinion about this. Cheers Fred -- 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#1024859: change in the extention importation with 3.11
There is a fix from the upstream around enum. https://github.com/boostorg/python/commit/a218babc8daee904a83f550fb66e5cb3f1cb3013 Fix enum_type_object type on Python 3.11 The enum_type_object type inherits from PyLong_Type which is not tracked by the GC. Instances doesn't have to be tracked by the GC: remove the Py_TPFLAGS_HAVE_GC flag. The Python C API documentation says: "To create a container type, the tp_flags field of the type object must include the Py_TPFLAGS_HAVE_GC and provide an implementation of the tp_traverse handler." https://docs.python.org/dev/c-api/gcsupport.html The new exception was introduced in Python 3.11 by: python/cpython#88429 an opinion ? -- 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#1024859: change in the extention importation with 3.11
in order to debug this, I started gdb set a breakpoint in init_module_scitbx_linalg_ext then a catch throw and I end up with this backtrace Catchpoint 2 (exception thrown), 0x770a90a1 in __cxxabiv1::__cxa_throw (obj=0xb542e0, tinfo=0x772d8200 , dest=0x772c1290 ) at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:81 81 ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc: Le dossier n'est pas vide. (gdb) bt #0 0x770a90a1 in __cxxabiv1::__cxa_throw (obj=0xb542e0, tinfo=0x772d8200 , dest=0x772c1290 ) at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:81 #1 0x772ad089 in boost::python::throw_error_already_set () at libs/python/src/errors.cpp:61 #2 0x772b6f05 in boost::python::objects::(anonymous namespace)::new_enum_type (doc=0x0, name=0x7743ddf9 "bidiagonal_matrix_kind") at libs/python/src/object/enum.cpp:169 #3 boost::python::objects::enum_base::enum_base (this=this@entry=0x7fffcee0, name=name@entry=0x7743ddf9 "bidiagonal_matrix_kind", to_python=to_python@entry=0x7741f720 ::to_python(void const*)>, convertible=convertible@entry=0x77422e50 ::convertible_from_python(_object*)>, construct=construct@entry=0x7741fb60 ::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*)>, id=..., doc=0x0) at libs/python/src/object/enum.cpp:204 #4 0x774203cb in boost::python::enum_::enum_ (this=0x7fffcee0, name=0x7743ddf9 "bidiagonal_matrix_kind", doc=0x0) at /usr/include/boost/python/enum.hpp:45 #5 0x77428330 in scitbx::matrix::boost_python::bidiagonal_matrix_svd_decomposition_wrapper::wrap (name=name@entry=0x7743dbd0 "svd_decomposition_of_bidiagonal_matrix") at ./scitbx/linalg/boost_python/svd.cpp:19 #6 0x7741f6b0 in scitbx::matrix::boost_python::wrap_svd () at ./scitbx/linalg/boost_python/svd.cpp:66 #7 0x773f8aa3 in scitbx::matrix::boost_python::(anonymous namespace)::init_module () at ./scitbx/linalg/boost_python/linalg_ext.cpp:19 #8 0x772c13e3 in boost::function0::operator() (this=0x7fffd2b0) at ./boost/function/function_template.hpp:763 #9 boost::python::handle_exception_impl (f=...) at libs/python/src/errors.cpp:25 #10 0x772c1b69 in boost::python::handle_exception (f=) at ./boost/function/function_template.hpp:635 #11 boost::python::detail::(anonymous namespace)::init_module_in_scope (init_function=0x773f8ac0 , m=) at libs/python/src/module.cpp:24 #12 boost::python::detail::init_module (moduledef=..., init_function=0x773f8ac0 ) at libs/python/src/module.cpp:43 not crystal clear to me :) -- 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#1013158: facet-analyser: vtk[6,7] removal
Hello Anton, I have just pushed a few dependencies in the -dev package in the salsa repo I did not updated the changelog. Cheers Fred -- 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#1013158: facet-analyser: vtk[6,7] removal
Hello Anton, I try to checkout paraview in order to add the -dev dependencies but I have this message $ git clone https://salsa.debian.org/science-team/paraview Clonage dans 'paraview'... remote: Enumerating objects: 175624, done. remote: Counting objects: 100% (78929/78929), done. remote: Compressing objects: 100% (38687/38687), done. remote: Total 175624 (delta 47039), reused 65625 (delta 39190), pack-reused 96695 Réception d'objets: 100% (175624/175624), 246.21 Mio | 12.11 Mio/s, fait. Résolution des deltas: 100% (109096/109096), fait. [attr]our-c-style whitespace=tab-in-indent,-blank-at-eol format.clang-format non permis : ThirdParty/QtTesting/vtkqttesting/.gitattributes : 8 [attr]our-c-style whitespace=tab-in-indent,-blank-at-eol format.clang-format=9 non permis : ThirdParty/catalyst/vtkcatalyst/catalyst/.gitattributes : 4 [attr]our-c-style whitespace=tab-in-indent,-blank-at-eol format.clang-format=8 non permis : VTK/.gitattributes : 10 [attr]our-c-style whitespace=tab-in-indent format.clang-format=9 non permis : VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/.gitattributes : 2 Mise à jour des fichiers: 100% (30828/30828), fait. [attr]our-c-style whitespace=tab-in-indent,-blank-at-eol format.clang-format=8 non permis : VTK/.gitattributes : 10 [attr]our-c-style whitespace=tab-in-indent format.clang-format=9 non permis : VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/.gitattributes : 2 Downloading VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/README.md (643 B) Error downloading object: VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/README.md (b30a14a): Smudge error: Error downloading VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/README.md (b30a14a308f64c6fc2969e2b959d79dacdc5affda1d1c0e24f8e176304147146): [b30a14a308f64c6fc2969e2b959d79dacdc5affda1d1c0e24f8e176304147146] Object does not exist on the server or you don't have permissions to access it: [404] Object does not exist on the server or you don't have permissions to access it Errors logged to /home/experiences/instrumentation/picca/debian/science-team/paraview/.git/lfs/logs/20221101T101535.441130442.log Use `git lfs logs last` to view the log. error: le filtre externe 'git-lfs filter-process' a échoué fatal: VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/README.md : le filtre smudge 'lfs' a échoué warning: Le clone a réussi, mais l'extraction a échoué. Vous pouvez inspecter ce qui a été extrait avec 'git status' et réessayer avec 'git restore --source=HEAD :/' -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
ann library and cctbx
Hello, I am preparing the cctbx[1] package and I am facing this issue. cctbx embed the ann libbrary via this repository [2], but worst than that it also apply a transformation to its source code https://github.com/cctbx/annlib_adaptbx/blob/master/source_generators/generate_all.py this produce a new library with the ann old symbols + the new symbols. In order to provide a full featured cctbx library, I would like to add this logic to the current ann library package [3] So, I need to instrument the ann package to generate the extra sources files using the cctbx logic. My question is should I build a libann-cctbx.so dedicated library in the ann package or should I add the the new symbols directly into the actual ann library ? then I should patch the cctbx buildsystem in order to use this version of the ann library. thanks for your help. Frederic [1] https://tracker.debian.org/pkg/cctbx [2] https://github.com/cctbx/annlib_adaptbx/ [3] https://tracker.debian.org/pkg/ann -- 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#1013158: facet-analyser: vtk[6,7] removal
Hello, I removed the vtk7 dependency but I needed a bunch of -dev packages. + libavcodec-dev, + libavformat-dev, libdouble-conversion-dev, libfftw3-dev, + libfreetype-dev, + libgdal-dev, libgdcm-tools, + libgl2ps-dev, + libglew-dev, libinsighttoolkit4-dev, liblz4-dev, + libogg-dev, libopengl-dev, + libopenmpi-dev, libqt5opengl5-dev, libqt5svg5-dev, + libswscale-dev, + libtheora-dev, libutfcpp-dev, - libvtk7-dev, libvtkgdcm-cil, libvtkgdcm-dev, libvtkgdcm-java, @@ -26,10 +37,9 @@ Build-Depends: qtbase5-dev, qttools5-dev, qtxmlpatterns5-dev-tools, - vtk7, paraview seems to use an internal version of vtk. So when I build an extension with paraview-dev, I expect to have all the -dev pulled via this package. Package: paraview-dev Version: 5.10.1-1 Priority: optional Section: libdevel Source: paraview Maintainer: Debian Science Team Installed-Size: 117 MB Depends: qttools5-dev-tools, libc6 (>= 2.14), paraview (= 5.10.1-1), python3:any | python3-minimal:any, libeigen3-dev I am wondering if the right solution is not to add all these vtk dependency in the paraview -dev package ? cheers Fred -- 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#1013158: facet-analyser: vtk[6,7] removal
Hello anton, If I try to switch to vtk9 it end up with The following packages have unmet dependencies: python3-paraview : Conflicts: python3-vtk9 but 9.1.0+really9.1.0+dfsg2-3+b3 is to be installed 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: [ITA] triangle
Done, it is now public Cheers Fred - Antonio Valentino a écrit : > Hi Andreas, > the git repository for the triangle package on salsa > (https://salsa.debian.org/science-team/triangle) seems to be private. > Could you please make it public? > The debian tracker complains about it and it seems that I'm not allowed > to change permissions myself. > > kind regards > antonio > > Il 18/12/21 20:52, Andreas Tille ha scritto: > > Hi Antonio > > > > Am Sat, Dec 18, 2021 at 07:15:23PM +0100 schrieb Antonio Valentino: > >> I would like to adopt triangle (non-free) [1] and maintain it under the > >> Debian Science umbrella. > >> I have found already a git repository for the package in salsa [2] with > >> some > >> preliminary job done by Andreas (in cc). > > > > I do not even remember. ;-) In general it is fine if anyone wants to > > add her/his ID to Uploaders and do whatever needs to be done with a > > package I touched before. > > > >> Please let me know if anyone has something against it. > >> If not I will go on and adopt the package in few days. > > > > Thanks a lot for adopting it > > > > Andreas. > > > >> [1] https://tracker.debian.org/pkg/triangle > >> [2] https://salsa.debian.org/science-team/triangle > > > > -- > Antonio Valentino > > -- > debian-science-maintainers mailing list > debian-science-maintainers@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers -- 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#1003037:
It seems that this is an issue in gcc has observed when compiling tensorflow https://zenn.dev/nbo/scraps/8f1505e365d961 -- 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#1001168: hkl: FTBFS on mipsel: FAIL: trajectory.py
bugs report are already filled on matplotlib #1000774 and #1000435 I will try to see if this is identical... -- 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#1001168: hkl: FTBFS on mipsel: FAIL: trajectory.py
Here the backtrace on mips64el #0 agg::pixfmt_alpha_blend_rgba, agg::order_rgba>, agg::row_accessor >::blend_solid_hspan(int, int, unsigned int, agg::rgba8T const&, unsigned char const*) (covers=0x100 , c=..., len=, y=166, x=, this=) at extern/agg24-svn/include/agg_color_rgba.h:395 #1 agg::renderer_base, agg::order_rgba>, agg::row_accessor > >::blend_solid_hspan(int, int, int, agg::rgba8T const&, unsigned char const*) (covers=, c=..., len=, y=166, x=, this=0x12123abf8) at extern/agg24-svn/include/agg_renderer_base.h:294 #2 agg::render_scanline_aa_solid::embedded_scanline, agg::renderer_base, agg::order_rgba>, agg::row_accessor > >, agg::rgba8T >(agg::serialized_scanlines_adaptor_aa::embedded_scanline const&, agg::renderer_base, agg::order_rgba>, agg::row_accessor > >&, agg::rgba8T const&) (color=..., ren=..., sl=...) at extern/agg24-svn/include/agg_renderer_scanline.h:40 #3 agg::renderer_scanline_aa_solid, agg::order_rgba>, agg::row_accessor > > >::render::embedded_scanline>(agg::serialized_scanlines_adaptor_aa::embedded_scanline const&) (sl=..., this=0x12123ac10) at extern/agg24-svn/include/agg_renderer_scanline.h:130 #4 agg::render_scanlines, agg::serialized_scanlines_adaptor_aa::embedded_scanline, agg::renderer_scanline_aa_solid, agg::order_rgba>, agg::row_accessor > > > >(agg::serialized_scanlines_adaptor_aa&, agg::serialized_scanlines_adaptor_aa::embedded_scanline&, agg::renderer_scanline_aa_solid, agg::order_rgba>, agg::row_accessor > > >&) [clone .part.0] [clone .lto_priv.0] (ras=..., sl=..., ren=...) at extern/agg24-svn/include/agg_renderer_scanline.h:446 #5 0x00fff49a367c in agg::render_scanlines, agg::serialized_scanlines_adaptor_aa::embedded_scanline, agg::renderer_scanline_aa_solid, agg::order_rgba>, agg::row_accessor > > > >(agg::serialized_scanlines_adaptor_aa&, agg::serialized_scanlines_adaptor_aa::embedded_scanline&, agg::renderer_scanline_aa_solid, agg::order_rgba>, agg::row_accessor > > >&) (ren=..., sl=..., ras=...) at extern/agg24-svn/include/agg_renderer_scanline.h:440 #6 RendererAgg::draw_markers(GCAgg&, py::PathIterator&, agg::trans_affine&, py::PathIterator&, agg::trans_affine&, agg::rgba) (color=..., trans=..., path=..., marker_trans=..., marker_path=..., gc=..., this=0x12123aaa0) at src/_backend_agg.h:658 #7 PyRendererAgg_draw_markers(PyRendererAgg*, _object*) (self=, args=) at src/_backend_agg_wrapper.cpp:285 #8 0x0001202e36a0 in cfunction_call (func=0xfff11f08b0, args=, kwargs=) at ../Objects/methodobject.c:552 #9 0x00012003891c in _PyObject_MakeTpCall (tstate=0x1205a97c0, callable=0xfff11f08b0, args=, nargs=, keywords=0x0) at ../Objects/call.c:191 #10 0x00012002841c in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775814, args=0x121281590, callable=0xfff11f08b0, tstate=) at ../Include/cpython/abstract.h:116 #11 _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775814, args=0x121281590, callable=0xfff11f08b0, tstate=) at ../Include/cpython/abstract.h:103 #12 PyObject_Vectorcall (kwnames=0x0, nargsf=9223372036854775814, args=0x121281590, callable=0xfff11f08b0) at ../Include/cpython/abstract.h:127 #13 call_function (kwnames=0x0, oparg=, pp_stack=, tstate=) at ../Python/ceval.c:5075 #14 _PyEval_EvalFrameDefault (tstate=, f=, throwflag=) at ../Python/ceval.c:3487 #15 0x00012001d898 in _PyEval_EvalFrame (throwflag=0, f=0x121281330, tstate=0x1205a97c0) at ../Include/internal/pycore_ceval.h:40 #16 function_code_fastcall (tstate=0x1205a97c0, co=, args=0xfff120cd78, nargs=2, globals=) at ../Objects/call.c:330 #17 0x00012002535c in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=, args=0xfff120cd68, callable=0xfff520a310, tstate=0x1205a97c0) at ../Include/cpython/abstract.h:118 #18 PyObject_Vectorcall (kwnames=0x0, nargsf=, args=0xfff120cd68, callable=0xfff520a310) at ../Include/cpython/abstract.h:127 #19 call_function (kwnames=0x0, oparg=, pp_stack=, tstate=) at ../Python/ceval.c:5075 #20 _PyEval_EvalFrameDefault (tstate=, f=, throwflag=) at ../Python/ceval.c:3518 #21 0x000120107de0 in _PyEval_EvalFrame (throwflag=0, f=0xfff120cbe0, tstate=0x1205a97c0) at ../Include/internal/pycore_ceval.h:40 #22 _PyEval_EvalCode (tstate=0x1205a97c0, _co=0xfff5231500, globals=, locals=, args=, argcount=2, kwnames=0x0, kwargs=0xfff1069720, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0xfff51fafa0, name=0xfff7953bb0, qualname=0xfff5264730) at ../Python/ceval.c:4327 #23 0x000120039e20 in _PyFunction_Vectorcall (func=, stack=, nargsf=, kwnames=) at ../Objects/call.c:396 #24 0x0001200262dc in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=, args=0xfff1069710, callable=0xfff520a3a0, tstate=0x1205a97c0) at ../Include/cpython/abstract.h:118 #25 PyObject_Vectorcall (kwnames=0x0, nargsf=, args=0xfff1069710, callable=0xfff520a3a0) at ../Include/cpython/abstract.h:127 #26 call_function (kwnames=0x0, oparg=,
Bug#994226:
Hello reading this I do not understand what need to be changed in the init script https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Whenever systemd encounters a $network dependency in LSB headers of init scripts it will translate this to a Wants= and After= dependency on network-online.target hence staying relatively close to traditional LSB behaviour. So it seems to me that systemd already translate the network target into network-online cheers Fred -- 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#994882: ITS: vitables
ack ;) sorry for the delay. You can commit directly to the repository. Cheers Fred De : Benda Xu [o...@debian.org] Envoyé : vendredi 24 septembre 2021 10:24 À : Anton Gladky Cc : 994...@bugs.debian.org; PICCA Frederic-Emmanuel Objet : Re: Bug#994882: ITS: vitables Anton Gladky writes: > Thanks for your contribution. I have approved and merged your MR. Also > I have added you to the Debian Science group on salsa. > > @PICCA Frederic-Emmanuel, would you want also to check those changes? Thanks Anton! I will wait for Picca's ack for a month before I go ahead to add myself to uploaders list. Yours, Benda -- 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#961183: metis: providing a 64-bit build
Hello, why there is no pkgconfig files provided with metis and metis64. this simplify the configuration of packages depending on these libraries. Cheers Fred -- 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:TR : Bug#988001: python-fabio: autopkgtest needs update
Hello, Jerome, Due to the freeze, I think that the best solution is to do the backport. I will add a patch to fabio and upload it. thanks Fred -- 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#986785: binoculars gui does not work
Hello Andrius. I am on it, I am also the upstream of this software :)). Thanks for your help, nevertheless I am a bit like you, I did not wrote this part of the code :)) and the matplotlib changelog is sort of useless :)) Cheers Fred -- 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:Close pysph RC bug #948736 (Was: Re: zarr and numcodecs sponsorship)
Sorry I would have said antonio, it seems that the build failed on salsa ??? -- 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:Close pysph RC bug #948736 (Was: Re: zarr and numcodecs sponsorship)
Hello anton, is it normal ? https://salsa.debian.org/science-team/pysph/-/jobs/1420077 -- 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#976735: spyder needs source upload for Python 3.9 transition
> Strangely enough, I've already done that ;-) my bad. Cheers Fred -- 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#976735: spyder needs source upload for Python 3.9 transition
> I have a package of Spyder 4 waiting to upload, but it requires five > packages to be accepted into unstable from NEW first (pyls-server, > pyls-black, pyls-spyder, abydos, textdistance); once that happens, the > rest of the packages are almost ready to go. Maybe you can contact the ftpmaster team and request a review of these packages. In order to avoid the spyder removal. 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
Bug#972017: pyfai ftbfs with python3.9 as supported python3 version
Looking at the build log of pyfai, I can find this https://launchpadlibrarian.net/501584970/buildlog_ubuntu-groovy-armhf.pyfai_0.19.0+dfsg1-3build1_BUILDING.txt.gz Selecting previously unselected package python3-silx. Preparing to unpack .../238-python3-silx_0.13.1+dfsg-1_armhf.deb ... Unpacking python3-silx (0.13.1+dfsg-1) ... Selecting previously unselected package python3-silx-dbg. Preparing to unpack .../239-python3-silx-dbg_0.13.1+dfsg-1_armhf.deb ... Unpacking python3-silx-dbg (0.13.1+dfsg-1) ... so it seems that this was rebuild with the wrong version on silx. not the one rebuilt with python3.9 support. I guess this by looking at other packages which containes Selecting previously unselected package python3-scipy-dbg:armhf. Preparing to unpack .../237-python3-scipy-dbg_1.5.2-2build1_armhf.deb ... Unpacking python3-scipy-dbg:armhf (1.5.2-2build1) ... the build1 version :) -- 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#972017: pyfai ftbfs with python3.9 as supported python3 version
Hello, the error comes from here. > ModuleNotFoundError: No module named 'silx.image.marchingsquares._mergeimpl' did you rebuilt it with a silx packages already rebuilt with python3.9 ? -- 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#946035: Request fo sponsor to uplad python-jsonrpc-server
Hello, It compile fine :), but I have a concern about the license. It is considère a good practice to use the same license for the debian directory and the source code. In your case, you chooses GPL-3+, but the code is MIT. Fred -- 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#949549: Not fixed
Hello Thomas, I am wondering if this is not a false positive. all the code is compiled with -D_FORTIFY_SOURCE=2 https://salsa.debian.org/science-team/tango/-/jobs/954394/raw Can you confirm that it is a false positive ? I am not that confident when it comes to hardening flags. for the record I checked also the Database and it is also affected by this. 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
Bug#945467: Fix available (fwd)
you can look also at the CI, now that it works :) https://salsa.debian.org/science-team/veusz/pipelines/137494 Cheers Frederic -- 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:hdfview in buster
Yes it is not in buster but if you want to look at hdf5 files you can try silx silx view foo.h5 -- 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#956462: pkg-config for Qhull
Done :)) sorry for the delay De : Timo Röhling [t...@gaussglocke.de] Envoyé : samedi 25 avril 2020 14:06 À : PICCA Frederic-Emmanuel Cc : 956...@bugs.debian.org Objet : Re: pkg-config for Qhull Hi Frédéric! On 12.04.20 14:22, PICCA Frederic-Emmanuel wrote: > I will add both path in order to make the package backportable :) > Just pinging: Can you prepare an upload soon(ish), so I can continue with the Qhull transition? The "new" include path will work with the current 2015.2 release, too, so you won't break anything. Or you can use both paths as you suggested, which won't hurt either. Cheers Timo -- 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#956462: pymca: FTBFS with Qhull 2019.1
Do you provide a pkgconfig file with qhull ? De : debian-science-maintainers [debian-science-maintainers-bounces+picca=synchrotron-soleil...@alioth-lists.debian.net] de la part de Timo Röhling [t...@gaussglocke.de] Envoyé : samedi 11 avril 2020 19:08 À : sub...@bugs.debian.org Objet : Bug#956462: pymca: FTBFS with Qhull 2019.1 Source: pymca Version: 5.5.4+dfsg-1 Severity: important Tags: ftbfs, patch Dear maintainer, your package uses a deprecated include path for Qhull, which will no longer build with the latest release. Attached is a patch that will fix the build with the qhull package in experimental. -- 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#954352: pymca: Missing dependency "python3-scipy", probably in "python3-silx"
A work around for now is to install by hand apt install python3-scipy reassign -1 silx 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#936924: libsvm: Python2 removal in sid/bullseye - reopen 936924
Hello, if it is like for my ufo-core package, this could be due to a script file with a shebang using python instead of python3 Cheers Fred -- 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#938743: ufo-core: Python2 removal in sid/bullseye - reopen 938743
Maybe this is due to this picca@cush:~/Debian/ufo-core/ufo-core/bin$ rgrep python * ufo-mkfilter.in:#!/usr/bin/python ufo-prof:#!/usr/bin/env python I will replace python -> python3 and see what is going on -- 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#938743: ufo-core: Python2 removal in sid/bullseye - reopen 938743
Hello Sandro this is strange because, I have this in the control file
Package: libufo-bin
Architecture: any
Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
Suggests: ufo-core-doc
Description: Library for high-performance, GPU-based computing - tools
The UFO data processing framework is a C library suited to build
general purpose streams data processing on heterogeneous
architectures such as CPUs, GPUs or clusters. It is extensively used
at the Karlsruhe Institute of Technology for Ultra-fast X-ray Imaging
(radiography, tomography and laminography).
.
A gobject-instrospection binding is also provided to write scripts or
user interfaces.
.
This package contains binaries to run JSON descriptions of task graphs.
Package: libufo-data
So it seems that this python dependency comes from
python3:Depends.
is it normal ?
Cheers
Fred
--
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#943786: lmfit-py: failing tests with python3.8
Hello andreas, I will try to find some time during these holydays in order to upload the 1.0.0 version :) cheers Fred and happy new year. De : debian-science-maintainers [debian-science-maintainers-bounces+picca=synchrotron-soleil...@alioth-lists.debian.net] de la part de Andreas Tille [andr...@an3as.eu] Envoyé : dimanche 22 décembre 2019 10:48 À : PICCA Frederic-Emmanuel Cc : 943...@bugs.debian.org; MARIE Alexandre Objet : Bug#943786: lmfit-py: failing tests with python3.8 On Sun, Dec 22, 2019 at 07:54:23AM +, PICCA Frederic-Emmanuel wrote: > Hello andreas, In fact we were wayting for the pacakging of ipywidget 7.x > the jupyter-sphinx extension expected by lmfit-py require a newer version of > ipywidget. > > So maybe the best solution for now is to not produce the documentation until > this dependency is ok. Everything is fine for me. Just push a change that builds and upload (or ping me for sponsoring). I was just wondering about fixes in Git that were not uploaded. Kind regards Andreas. -- http://fam-tille.de -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers -- 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#943786: lmfit-py: failing tests with python3.8
Hello andreas, In fact we were wayting for the pacakging of ipywidget 7.x the jupyter-sphinx extension expected by lmfit-py require a newer version of ipywidget. So maybe the best solution for now is to not produce the documentation until this dependency is ok. cheers Frederic -- 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#946422: silx: autopkgtest regression: pocl error
looking in picca@sixs7:~/Debian/silx/silx/silx/opencl/test/test_addition.py
def setUp(self):
if ocl is None:
return
self.shape = 4096
self.data = numpy.random.random(self.shape).astype(numpy.float32)
self.d_array_img = pyopencl.array.to_device(self.queue, self.data)
self.d_array_5 = pyopencl.array.zeros_like(self.d_array_img) - 5
self.program = pyopencl.Program(self.ctx,
get_opencl_code("addition")).build()
I found that commenting this line
# self.d_array_5 = pyopencl.array.zeros_like(self.d_array_img) - 5
remove the pocl issue.
I remove everythings from the unit test.
@unittest.skipUnless(ocl, "pyopencl is missing")
def test_add(self):
self.assetTrue(True)
that means, only ther setUp and the tearDown are done.
with the line uncomment
(sid_amd64-dchroot)picca@barriere:~$ PYOPENCL_COMPILER_OUTPUT=1
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py -v
pocl error: lt_dlopen("(null)") or lt_dlsym() failed with 'can't close resident
module'.
note: missing symbols in the kernel binary might be reported as 'file not
found' errors.
Aborted
with the line commented
(sid_amd64-dchroot)picca@barriere:~$ PYOPENCL_COMPILER_OUTPUT=1
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py -v
.Maximum valid workgroup size 0 on device
--
Ran 1 test in 0.013s
OK
Test suite succeeded
If now I do not import silx.io before there is no issue with or without the
commented line
(sid_amd64-dchroot)picca@barriere:~$ PYOPENCL_COMPILER_OUTPUT=1
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py -v
.Maximum valid workgroup size 0 on device
--
Ran 1 test in 0.021s
OK
Test suite succeeded
So what is going on when executing this line ???
self.d_array_5 = pyopencl.array.zeros_like(self.d_array_img) - 5
--
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#946422: silx: autopkgtest regression: pocl error
I decided to concentrate myself on one opencl test (addition)
So I deactivated all other test by commenting the test in
silx/opencl/__init__.py
If I do not import silxs.io, this test works
(sid_amd64-dchroot)picca@barriere:~$ PYOPENCL_COMPILER_OUTPUT=1
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py -v
.Maximum valid workgroup size 2048 on device
--
Ran 1 test in 0.030s
OK
If I add silxs.io, it fails
(sid_amd64-dchroot)picca@barriere:~$ PYOPENCL_COMPILER_OUTPUT=1
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py -v
pocl error: lt_dlopen("(null)") or lt_dlsym() failed with 'can't close resident
module'.
note: missing symbols in the kernel binary might be reported as 'file not
found' errors.
Aborted
so this test is ok in order to investigate this issue.
--
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#946422: silx: autopkgtest regression: pocl error
With the silx.io import I have this
(sid_amd64-dchroot)picca@barriere:~$
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py
pocl error: lt_dlopen("(null)") or lt_dlsym() failed with 'can't close resident
module'.
note: missing symbols in the kernel binary might be reported as 'file not
found' errors.
without, I have this
(sid_amd64-dchroot)picca@barriere:~$
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py -v
.Maximum valid workgroup size 2048 on device
FThe gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
.The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
.The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
../home/picca/silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build/silx/opencl/test/test_linalg.py:69:
FutureWarning: Using a non-tuple sequence for multidimensional indexing is
deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this
will be interpreted as an array index, `arr[np.array(seq)]`, which will result
either in an error or a different result.
gradient[slice_all] = np.diff(img, axis=d)
4096
...7 warnings generated.
/usr/lib/python3/dist-packages/pyopencl/__init__.py:235: CompilerWarning:
Non-empty compiler output encountered. Set the environment variable
PYOPENCL_COMPILER_OUTPUT=1 to see more.
"to see more.", CompilerWarning)
..7 warnings generated.
..
==
FAIL: test_medfilt (silx.opencl.test.test_medfilt.TestMedianFilter)
--
Traceback (most recent call last):
File
"/home/picca/silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build/silx/opencl/test/test_medfilt.py",
line 115, in test_medfilt
self.assertEqual(r.error, 0, 'Results are correct')
AssertionError: 3.4028235e+38 != 0 : Results are correct
--
Ran 217 tests in 175.525s
FAILED (failures=1, skipped=48)
I will run it with the PYOPENCL_COMPILEr_OUTPUT=1 to check that compiler warning
(sid_amd64-dchroot)picca@barriere:~$ PYOPENCL_COMPILER_OUTPUT=1
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py -v
.Maximum valid workgroup size 2048 on device
FThe gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
.The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
.The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
The gpyfft module was not found. The Fourier transforms will be done on CPU.
For more performances, it is advised to install gpyfft.
../home/picca/silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build/silx/opencl/test/test_linalg.py:69:
FutureWarning: Using a non-tuple sequence for multidimensional indexing is
deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this
will be
Bug#946422: silx: autopkgtest regression: pocl error
not better
test cpp engine for medfilt2d ... ok
testOpenCLMedFilt2d (silx.image.test.test_medianfilter.TestMedianFilterEngines)
test cpp engine for medfilt2d ... pocl error: lt_dlopen("(null)") or lt_dlsym()
failed with 'can't close resident module'.
note: missing symbols in the kernel binary might be reported as 'file not
found' errors.
The next step will be to ding in the code and find the culprite.
--
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#946422: silx: autopkgtest regression: pocl error
It seems that this test does not PASS
@unittest.skipUnless(ocl, "PyOpenCl is missing")
def testOpenCLMedFilt2d(self):
"""test cpp engine for medfilt2d"""
res = medianfilter.medfilt2d(
image=TestMedianFilterEngines.IMG,
kernel_size=TestMedianFilterEngines.KERNEL,
engine='opencl')
self.assertTrue(numpy.array_equal(res, TestMedianFilterEngines.IMG))
testOpenCLMedFilt2d (silx.image.test.test_medianfilter.TestMedianFilterEngines)
test cpp engine for medfilt2d ... pocl error: lt_dlopen("(null)") or lt_dlsym()
failed with 'can't close resident module'.
note: missing symbols in the kernel binary might be reported as 'file not
found' errors.
Aborted
E: pybuild pybuild:341: test: plugin custom failed with: exit code=134: env
PYTHONPATH=/home/picca/silx-0.11.0+dfsg/.pybuild/cpython3_3.8_silx/build
WITH_QT_TEST=False xvfb-run -a --server-args="-screen 0 1024x768x24" python3.8
run_tests.py -vv --installed
dh_auto_test: pybuild --test -i python{version} -p "3.8 3.7" -s custom
"--test-args=env PYTHONPATH={build_dir} WITH_QT_TEST=False xvfb-run -a
--server-args=\"-screen 0 1024x768x24\" {interpreter} run_tests.py -vv
--installed" returned exit code 13
make[1]: *** [debian/rules:70: override_dh_auto_test] Error 255
make[1]: Leaving directory '/home/picca/silx-0.11.0+dfsg'
make: *** [debian/rules:27: build] Error 2
the code of medfilt2d is there
def medfilt2d(image, kernel_size=3, engine='cpp'):
"""Apply a median filter on an image.
This median filter is using a 'nearest' padding for values
past the array edges. If you want more padding options or
functionalities for the median filter (conditional filter
for example) please have a look at
:mod:`silx.math.medianfilter`.
:param numpy.ndarray image: the 2D array for which we want to apply
the median filter.
:param kernel_size: the dimension of the kernel.
Kernel size must be odd.
If a scalar is given, then it is used as the size in both dimension.
Default: (3, 3)
:type kernel_size: A int or a list of 2 int (kernel_height, kernel_width)
:param engine: the type of implementation to use.
Valid values are: 'cpp' (default) and 'opencl'
:returns: the array with the median value for each pixel.
.. note:: if the opencl implementation is requested but
is not present or fails, the cpp implementation is called.
"""
if engine not in MEDFILT_ENGINES:
err = 'silx doesn\'t have an implementation for the requested engine: '
err += '%s' % engine
raise ValueError(err)
if len(image.shape) is not 2:
raise ValueError('medfilt2d deals with arrays of dimension 2 only')
if engine == 'cpp':
return medianfilter_cpp.medfilt(data=image,
kernel_size=kernel_size,
conditional=False)
elif engine == 'opencl':
if medfilt_opencl is None:
wrn = 'opencl median filter not available. '
wrn += 'Launching cpp implementation.'
_logger.warning(wrn)
# instead call the cpp implementation
return medianfilter_cpp.medfilt(data=image,
kernel_size=kernel_size,
conditional=False)
else:
try:
medianfilter = medfilt_opencl.MedianFilter2D(image.shape,
devicetype="gpu")
res = medianfilter.medfilt2d(image, kernel_size)
except(RuntimeError, MemoryError, ImportError):
wrn = 'Exception occured in opencl median filter. '
wrn += 'To get more information see debug log.'
wrn += 'Launching cpp implementation.'
_logger.warning(wrn)
_logger.debug("median filter - openCL implementation issue.",
exc_info=True)
# instead call the cpp implementation
res = medianfilter_cpp.medfilt(data=image,
kernel_size=kernel_size,
conditional=False)
return res
in our case we have engine = 'opencl' and no warning message, so medfil_opencl
should not be None.
it comes from here
from silx.opencl import medfilt as medfilt_opencl
In this code we have
:param devicetype: type of device, can be "CPU", "GPU", "ACC" or "ALL"
So let's do a first test by replacing gpu by cpu to see if it change something
during the test.
--
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#942533: sardana: needs a source-only upload.
Hello >Package: sardana >Version: 3.0.0a+3.f4f89e+dfsg-1 >Severity: serious >The release team have decreed that non-buildd binaries cannot migrate to >testing. Please make a source-only upload so your package can migrate. ok, but this packages comes from NEW. So it would be nice if the process NEW -> unstable could be a source upload. Ir is not possible to upload without the binary in New. This processus necessitate two uploads if I understand correctly. -- 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#938550: spyder: Python2 removal in sid/bullseye
> I didn't notice it, so wasn't planning to add it. spyder_kernels > imports without complaining, and spyder seems to start fine anyway. > Where does it come to notice? I do not know, but on wndows it is optional. So maybe this is not a big issue. Fred -- 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#938550: spyder: Python2 removal in sid/bullseye
It seems that wurlitzer which is a dependency of spyder-kernel is missing. did you plan to add it ? 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
Bug#938550: spyder: Python2 removal in sid/bullseye
Hello > Hi Frédéric, I prepared spyder (and spyder-kernels) for python2 removal. > The removal of cloudpickle forces us to do it earlier than we otherwise > might have. no problem for me :), the faster we get rid of Python2, the better. > With spyder, it made sense to me to keep spyder as the main binary > package, relegating spyder3 to a transitional dependency package. I set > /usr/bin/spyder as a symlink to spyder3 (manpage likewise). Let me know > if you're happy with that and we can go ahead with the upload. > Otherwise I can swap it to keep spyder3 as the binary package. I think that you should set the section, oldlibs for spyder3 if this is a transitional package. then you can upload. Cheers Fred -- 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#940822: silx view crashes on invocation
Ok this simple script trigger the bug. from PyQt5.QtWidgets import QApplication, QLabel app = QApplication([]) on KDE, but not on Gnome. BUT this app = QApplication(['a']) works. on KDE and Gnome. -- 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#940822: silx view crashes on invocation
If I remove the config file, I have this error picca@cush:~$ rm .config/silx/silx-view.ini picca@cush:~$ silx view QSettings::value: Empty key passed QSettings::value: Empty key passed KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = python3.7 path = /usr/bin pid = 1893 KCrash: Arguments: KCrash: Attempting to start .usr/lib/x86_64-linux-gnu/libexec/drkonqi from kdeinit sock_file=/run/user/1001/kdeinit5__0 KCrash: Attempting to start .usr/lib/x86_64-linux-gnu/libexec/drkonqi directly KCrash failed to exec(), errno = 2 -- 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#940822: silx view crashes on invocation
Ok, I can reproduce this bug. I switched to plasma and now I have picca@cush:~$ silx view malloc_consolidate(): invalid chunk size KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = python3.7 path = /usr/bin pid = 1876 KCrash: Arguments: Minuterie d'alerte So this is something related to kde... -- 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#940822: silx view crashes on invocation
Did you trye also to remove the .config files picca@cush:~/.config/silx$ ls silx-view.ini If I remember correctly, I had a problem which was solved by removing this file. -- 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#940822: silx view crashes on invocation
Here you have the information about the core dump. https://wiki.debian.org/HowToGetABacktrace -- 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#940822: silx view crashes on invocation
> Please find attached the output It seems that KCrash is in our way. Is it possible for you to run silx view from a gnome environment ? are you using kde ? -- 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#940822: silx view crashes on invocation
gdb -ex r --args python3 -m silx.app.view.main -- 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#940822: silx view crashes on invocation
Hello carlos, I am using this on all our computers and I have no problem. com-diffabs@diffabs6:~$ dpkg -l | grep silx ii python-silx 0.11.0+dfsg-1~bpo10+1 amd64Toolbox for X-Ray data analysis - Python2 library ii python-silx-dbg 0.11.0+dfsg-1~bpo10+1 amd64Toolbox for X-Ray data analysis - Python2 debug ii python-silx-doc 0.11.0+dfsg-1~bpo10+1 all Toolbox for X-Ray data analysis - Documentation ii python3-silx 0.11.0+dfsg-1~bpo10+1 amd64Toolbox for X-Ray data analysis - Python3 ii python3-silx-dbg 0.11.0+dfsg-1~bpo10+1 amd64Toolbox for X-Ray data analysis - Python3 debug ii silx 0.11.0+dfsg-1~bpo10+1 all Toolbox for X-Ray data analysis - Executables Could it be a problem with the OpenGL drivers on your computer ? Do you have a backtrace from gdb available ? -- 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#940130: pymca: testsuite failure (segfault)
Hello, this is a probleme due to a bug in python-numpy which is already solved in python-numpy 1.6.5 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933056 Cheers De : debian-science-maintainers [debian-science-maintainers-bounces+picca=synchrotron-soleil...@alioth-lists.debian.net] de la part de Gianfranco Costamagna [locutusofb...@debian.org] Envoyé : jeudi 12 septembre 2019 21:37 À : sub...@bugs.debian.org Objet : Bug#940130: pymca: testsuite failure (segfault) Source: pymca Version: 5.5.1+dfsg-1 Severity: serious Hello, looks like the package autopkgtest is failing... testFastFitEdfMap (PyMcaBatchTest.testPyMcaBatch) ... Segmentation fault https://ci.debian.net/packages/p/pymca/testing/amd64 can you please have a look? -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers -- 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:pyfai: Python2 removal in sid/bullseye
> Hi, > The latest pyFAI uses python3 for the application instead of python2, > at least on the master. I did not check if it was the case for the release. > In the worse case, one would just have to wait for the next release > which is planed later this year. Anyhow, I recently fixed a bug related > to the documentation which was generated using the python2 build > systsem. Hello, I have just one concern about this change, is that I need to produce backports for buster with the Python2 packages. So Sandro do you know if this is possible to upload into backports packages with python2 binaries even if they where removed in buster+1. Cheers Frederic -- 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:python-pyqtgraph_0.10.0-3_source.changes ACCEPTED into unstable
Is it a leaf package ? De : debian-science-maintainers [debian-science-maintainers-bounces+picca=synchrotron-soleil...@alioth-lists.debian.net] de la part de Debian FTP Masters [ftpmas...@ftp-master.debian.org] Envoyé : mercredi 28 août 2019 12:43 À : Debian Science Team; Gianfranco Costamagna Objet : python-pyqtgraph_0.10.0-3_source.changes ACCEPTED into unstable Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 21 Aug 2019 18:27:17 +0200 Source: python-pyqtgraph Binary: python3-pyqtgraph python-pyqtgraph-doc Architecture: source Version: 0.10.0-3 Distribution: unstable Urgency: medium Maintainer: Debian Science Team Changed-By: Gianfranco Costamagna Description: python-pyqtgraph-doc - Scientific Graphics and GUI Library for Python (common documentat python3-pyqtgraph - Scientific Graphics and GUI Library for Python 3 Changes: python-pyqtgraph (0.10.0-3) unstable; urgency=medium . * Drop python2 package Checksums-Sha1: 1a5c9c18276445fae0295f4d410179b5697be34a 2171 python-pyqtgraph_0.10.0-3.dsc 8bc8240a3ac07a5a493ae6022cdc50c6e3004d2f 3720 python-pyqtgraph_0.10.0-3.debian.tar.xz 522a4a9ad9731615ddc21a0b6d2ceeb0545e24b4 8648 python-pyqtgraph_0.10.0-3_source.buildinfo Checksums-Sha256: 0d9c2cd4e1715871b17b39db8fcbbed1f56404ec9ca86d7cb32acf4374d2bc09 2171 python-pyqtgraph_0.10.0-3.dsc 294b1981916d1be17edd03b8c038c87373f36a9ff6a3c9ef1d4410a7b53c69e9 3720 python-pyqtgraph_0.10.0-3.debian.tar.xz c9ff2ae4d0365b5b9a755916184f40488a026dc8b89b00f0872ae51090bc7340 8648 python-pyqtgraph_0.10.0-3_source.buildinfo Files: 3491830519b486a317f7549edfe2c9b2 2171 python optional python-pyqtgraph_0.10.0-3.dsc adf7ad5f43d641f07453c6541b2b7e61 3720 python optional python-pyqtgraph_0.10.0-3.debian.tar.xz 1f7d5b319eef0d5c2386a2b61ca83e0e 8648 python optional python-pyqtgraph_0.10.0-3_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkpeKbhleSSGCX3/w808JdE6fXdkFAl1dcggACgkQ808JdE6f XdkyTxAAl0DBYQwI32PEuKJVuM7ZweiUVKF4n1PlMKC7Oa/O7eNSNLSVAl1gnm8b acnXRM42tcPyHk5Bbl06X01OFerzRah7I8civhKm0QmilCiGm6aPzkE7MIkhS8gn NaQbdixsnlbdDEmhJ3dOi4EFBKfV7NA+v8kvsPW5SkAW9f9yrWO6pLTGg0LNj7/6 0fpxrByeRY81nJTBZKsU2WwGxrRKIHaDD0LnjZcQQAJyAqQmDSkt5wG0gN5UXymT 7CgAzJZh2Mym9lLcavcgNGONF/k14Z7F8CJMlb9/11vusCX1ifarybfjlskl2vbK elL7RZfieuu+aI/uClLTcKGvvhI/SwN2TVo+rPpG9Sa7de7Oco1alCSL/GYdzeOz E+nwZE+YfKVs/hua6y4fraf6RURlvYhAHYQYvsrdOogLenGTIcbRyB5QYglSDGkM rR6vXKb4YqUC5XnbPyyHaJrbEenBjheLL3mUT21wxyTKgcqHnzsVqAU5FM6qlJC+ +IiSO4esUUSrAI/8yjcjx6FPDX3NcByM/hsbwN6u+VzAmcxut3KNIeKCfuv90okm hIHFlOA/8Okpkcsd1LFFudvI9gMYz373t3YrrZLpHpSrWwm3oJwQ+LBoPRjWYrrr TRW00mOGiiih4mKCvfmOwEchTGJpOszx9i5v3FPROH9Oii88iR4= =/sZC -END PGP SIGNATURE- Thank you for your contribution to Debian. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers -- 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:python-xarray_0.12.1-2~bpo10+1_amd64.changes ACCEPTED into stretch-backports-sloppy->backports-policy, stretch-backports-sloppy
is the version number correct. I thought that stretch-backports-sloppy would be bpo9 and not bpo10. I missed something ? Fred -- 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#929720: hkl: FTBFS: ../../hkl/ccan/generator/generator.h:23:2: error: #error Generators require coroutines
Hello, I am wondering if the problem is not a gcc bug. I tryed to deal with this issue, with the ccan upstream. https://github.com/rustyrussell/ccan/issues/65 but I do not have the skills in order to fix it otherwise than applying the simple one line fix Here the patch I am applying i order to fix the build issue. But it seems that it is not sufficient... https://salsa.debian.org/science-team/hkl/blob/master/debian/patches/0001-889878-make-test-for-pointer-safe-makecontext-succee.patch Cheers Fred -- 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#935454: pymca: autopkgtest regression: Segmentation fault
This regression is due to a bug in python-numpy #933056, that I already reported, whcih was solved upstream and will be available in the 0.17 version. Cheers Fred -- 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#918807: taurus: diff for NMU version 4.0.3+dfsg-1.1
The upstream, Just packages the latest taurus. So I think that you can defer your upload now. thanks a lot for your help. Frederic -- 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#920257: TR : Fw: TR : Bug#920257: python3-fabio: program fails with Nexus data from Diamond Light Source
Hello, here an answer from the ESRF. De : V. Armando Sole [s...@esrf.fr] Envoyé : mercredi 23 janvier 2019 20:29 À : PICCA Frederic-Emmanuel Cc : s...@edna-site.org Objet : Re: Fw: TR : Bug#920257: python3-fabio: program fails with Nexus data from Diamond Light Source Two possibulities: - Diamond light source uses SWMR. Is the HDF5 version used on the reading machine 1.10.x? - The fact there is a master file and the dataset name points to Eiger data. Is the hdf5plugin module installed? Armando -- 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#916195: changed sources in salsa
Hello Carlos, > I am fine with removing it, but just let me point that if it does not cause > harm to leave it there, it may facilitate the creation of backports to > stretch. I think that it needs to be removed for Buster. I understand for the backports. do you know if a release is expected before the Debian freeze ? Fred -- 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#916195: changed sources in salsa
Hello, since Debian wants to remove python-qt4 for buster, maybe it would be nice to remove this from the dependecies ? Do not hesitate to commit this change if this is ok for you. Fred -- 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#916195: Additional information: docker stretch
Hello Marc, do you have an account on salsa.debian.org. This way you could fix directly the problem on the Debin package :)). Tell me if you need help. Fred -- 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#914140: pytango FTBFS with boost 1.67
Hello Adrian If I look at the current boost1.67, I find this in the boost python package https://packages.debian.org/sid/amd64/libboost-python1.67.0/filelist and https://packages.debian.org/sid/amd64/libboost-python1.67-dev/filelist We can find these /usr/lib/x86_64-linux-gnu/libboost_python3-py36.a /usr/lib/x86_64-linux-gnu/libboost_python3-py36.so but only for the python3.6 version and not for 2.7 and 3.7 previously we had for boost 1.62 https://packages.debian.org/sid/amd64/libboost-python1.62-dev/filelist all python version add these -pyXY.so files. Is it an intended change in the new boost_python package, or a mistake ? This logic -pyXY was coded in the pytango setup.py, in order to deal with boost_python. cheers Fred -- 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#906921: tango-starter does not start after a reboot
> Ok, I did it. It is right? It would be nice to hqve q one line explqinqtion of the fix. sort of d/tango-starter.init.d -Added network to Should-[Start|Stop]. (Closes: #...) It is important to have something understandable in the debian changelog. thansk Fred Ps: What about the patch ;) -- 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#906921: tango-starter does not start after a reboot
Hello carlog > I think so, It may affect to others users. So is it possible to add this as a patch for the packaging ? > I did a MR (https://salsa.debian.org/science-team/tango/merge_requests/1) Can you modify your MR and update the Debian/changelog in order to close the bug during the next upload ? - create a new entry (increase the debian version). - add a message to close the bug :)) thanks Fred -- 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#906921: tango-starter does not start after a reboot
Hello Carlos, > Dear Maintainer, > We saw that in some machines the tango-starter did not start after > rebooting the PC. > Note: We are using a custom version of the tango package ( > 9.2.5a+dfsg1-2+patch1~bpo9+0~alba+1) is this patch interesting for others ? > # Should-Start: tango-db network > # Should-Stop: tango-db network > Could you add this fix in the init script of the official package? If > you prefer I can do a PR in salsa.d.o Yes it would be great :)), and then prepare a new debian revision for upload :) cheers Sorry for the delay, I was on holydays. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
@salsa-pipeline-guest Developer access for Debian science.
Hello guyes, I would like to know if you are ok, if I grant a Developer acces to salsa-pipeline-guest for the science-team. I would like to use this [1], for my packages. what is your opinion ? thanks Frederic [1] https://salsa.debian.org/salsa-ci-team/pipeline -- 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#904262: python-fabio builds for the default python3 version, but tests with all supported versions.
> your autopkg tests loops over all *supported* python versions, but you only > build the extension for the *default* python3 version. Try build-depending on > python3-all-dev instead and see that you have extensions built for both 3.6 > and > 3.7. Building in unstable, of course. But , I already depends on python3-all-dev ??? https://sources.debian.org/src/python-fabio/0.6.0+dfsg-1/debian/control/ I think that this is due to the python3.7 transtion which is ot over for python-fabio. 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
Bug#904262: python-fabio builds for the default python3 version, but tests with all supported versions.
Hello, Matthias, I do not understand this bug report. I use pybuild so fabio should be build for all python3 versions. It is now FTBFS due to a problem with the cython package already reported. #903909 Cheers Frederic -- 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:New version of numexpr breaks autopkgtests of pytables in testing
It seems to me that the real culprite is python-numpy. De : debian-science-maintainers [debian-science-maintainers-bounces+picca=synchrotron-soleil...@alioth-lists.debian.net] de la part de Paul Gevers [elb...@debian.org] Envoyé : samedi 12 mai 2018 10:10 À : nume...@packages.debian.org; pytab...@packages.debian.org Cc : Paul Gevers Objet : New version of numexpr breaks autopkgtests of pytables in testing Dear maintainers, [This e-mail is automatically sent. V2 (20180508)] As recently announced [1] Debian is now running autopkgtests in testing to check if the migration of a new source package causes regressions. It does this with the binary packages of the new version of the source package from unstable. With a recent upload of numexpr the autopkgtest of pytables started to fail in testing [2]. This is currently delaying the migration of numexpr version 2.6.5-1 [3]. This e-mail is meant to trigger prompt direct communication between the maintainers of the involved packages as one party has insight in what changed and the other party insight in what is being tested. Please therefore get in touch with each other with your ideas about what the causes of the problem might be, proposed patches, etc. A regression in a reverse dependency can be due to one of the following reasons (of course not complete): * new bug in the candidate package (fix the package) * bug in the test case that only gets triggered due to the update (fix the reverse dependency, but see below) * out-of-date reference date in the test case that captures a former bug in the candidate package (fix the reverse dependency, but see below) * deprecation of functionality that is used in the reverse dependency and/or its test case (discussion needed) Triaging tips are being collected on the Debian Wiki [4]. Unfortunately sometimes a regression is only intermittent. Ideally this should be fixed, but it may be OK to just have the autopkgtest retried (a link is available in the excuses [3]). There are cases where it is required to have multiple packages migrate together to have the test cases pass, e.g. when there was a bug in a regressing test case of a reverse dependency and that got fixed. In that case the test cases need to be triggered with both packages from unstable (reply to this e-mail and/or contact the ci-team [5]) or just wait until the aging time is over (if the fixed reverse dependency migrates before that time, the failed test can be retriggered [3]). Of course no system is perfect. In case a framework issue is suspected, don't hesitate to raise the issue via BTS or to the ci-team [5] (reply to me is also fine for initial cross-check). To avoid stepping on peoples toes, this e-mail does not automatically generate a bug in the BTS, but it is highly recommended to forward this e-mail there (psuedo-header boilerplate below [6,7]) in case it is clear which package should solve this regression. It can be appropriate to file an RC bug against the depended-on package, if the regression amounts to an RC bug in the depending package, and to keep it open while the matter is investigated. That will prevent migration of an RC regression. If the maintainers of the depending package don't have available effort to fix a problem, it is appropriate for the maintainers of the depended-on package to consider an NMU of the depending package. Any such an NMU should take place in accordance with the normal NMU rules. Neither of the above steps should be seen as hostile; they are part of trying to work together to keep Debian in tip-top shape. If you find that you are not able to agree between you about the right next steps, bug severities, etc., please try to find a neutral third party to help you mediate and/or provide a third opinion. Failing that your best bet is probably to post to debian-devel. [1] https://lists.debian.org/debian-devel-announce/2018/05/msg1.html [2] https://ci.debian.net/packages/p/pytables/testing/amd64/ [3] https://qa.debian.org/excuses.php?package=numexpr [4] https://wiki.debian.org/ContinuousIntegration/TriagingTips [5] #debci on oftc or debian...@lists.debian.org [6] numexpr has an issue Source: numexpr Version: 2.6.5-1 Severity: normal or higher Control: affects -1 src:pytables User: debian...@lists.debian.org Usertags: breaks [7] pytables has an issue Source: pytables Version: 3.4.3-1 Severity: normal or higher Control: affects -1 src:numexpr User: debian...@lists.debian.org Usertags: needs-update -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers -- 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:matplotlib: missing depends on python(3)-kiwisolver
there is two problemes. kiwisolver MUST provide -dbg packages AND matplotlib should depends on these packages once available. Cheers Frederic -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
