Bug#1069876: libsbml: autopkgtest regression
Hi, Am Fri, Apr 26, 2024 at 09:27:55AM +0200 schrieb Sebastian Ramacher: > 95s autopkgtest [21:29:51]: test autodep8-python3: [--- > 95s Testing with python3.12: Short note: If I understood upstream correctly they currently support Python3.11 only. In any case they support only *one* Python3 version at the same time. It might be sensible to reach out to upstream for an update but that's currently out of my scope. Kind regards Andreas. -- https://fam-tille.de
Bug#1024889: Pending
Control: tags -1 pending Control: block -1 by 1064596 thanks Pplacer needs to be build against the old version of MCL which is featuring some OCAML patch. This old version was just uploaded to new. Kind regards Andreas. -- https://fam-tille.de
Bug#1069509: r-cran-metamix: FTBFS on armhf: tests fail
Hi Lucas, thanks a lot for all your work on rebuilding the archive on different architectures. That's really appreciated. In this specific case I wonder whether your build host has simply trouble initialising MPI given I find strings like MPI_ERRORS_ARE_FATAL Kind regards Andreas. Am Sat, Apr 20, 2024 at 03:14:31PM +0200 schrieb Lucas Nussbaum: > Source: r-cran-metamix > Version: 0.3-2 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armhf > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on armhf. > > > Relevant part (hopefully): > > make[1]: Entering directory '/<>/src' > > make[1]: Leaving directory '/<>/src' > > installing to > > /<>/debian/r-cran-metamix/usr/lib/R/site-library/00LOCK-r-cran-metamix-0.3/00new/metaMix/libs > > ** R > > ** data > > *** moving datasets to lazyload DB > > ** inst > > ** byte-compile and prepare package for lazy loading > > -- > > Sorry! You were supposed to get help about: > > pmix_init:startup:internal-failure > > But I couldn't open the help file: > > /usr/share/pmix/help-pmix-runtime.txt: No such file or directory. > > Sorry! > > -- > > [ip-10-84-234-19:2164897] PMIX ERROR: NOT-FOUND in file > > ../../../../../../../../opal/mca/pmix/pmix3x/pmix/src/server/pmix_server.c > > at line 237 > > [ip-10-84-234-19:2164891] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to > > start a daemon on the local node in file > > ../../../../../../orte/mca/ess/singleton/ess_singleton_module.c at line 716 > > [ip-10-84-234-19:2164891] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to > > start a daemon on the local node in file > > ../../../../../../orte/mca/ess/singleton/ess_singleton_module.c at line 172 > > -- > > It looks like orte_init failed for some reason; your parallel process is > > likely to abort. There are many reasons that a parallel process can > > fail during orte_init; some of which are due to configuration or > > environment problems. This failure appears to be an internal failure; > > here's some additional information (which may only be relevant to an > > Open MPI developer): > > > > orte_ess_init failed > > --> Returned value Unable to start a daemon on the local node (-127) > > instead of ORTE_SUCCESS > > -- > > -- > > It looks like MPI_INIT failed for some reason; your parallel process is > > likely to abort. There are many reasons that a parallel process can > > fail during MPI_INIT; some of which are due to configuration or environment > > problems. This failure appears to be an internal failure; here's some > > additional information (which may only be relevant to an Open MPI > > developer): > > > > ompi_mpi_init: ompi_rte_init failed > > --> Returned "Unable to start a daemon on the local node" (-127) instead > > of "Success" (0) > > -- > > *** An error occurred in MPI_Init > > *** on a NULL communicator > > *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, > > ***and potentially your MPI job) > > [ip-10-84-234-19:2164891] Local abort before MPI_INIT completed completed > > successfully, but am not able to aggregate error messages, and not able to > > guarantee that all other processes were killed! > > ERROR: lazy loading failed for package ‘metaMix’ > > * removing > > ‘/<>/debian/r-cran-metamix/usr/lib/R/site-library/metaMix’ > > dh_auto_install: error: R CMD INSTALL -l > > /<>/debian/r-cran-metamix/usr/lib/R/site-library --clean . > > "--built-timestamp='Sat, 21 Mar 2020 14:53:15 +0100'" returned exit code 1 > > make: *** [debian/rules:4: binary] Error 25 > > > The full build log is available from: > http://qa-logs.debian.net/2024/04/20/r-cran-metamix_0.3-2_unstable-armhf.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240420;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20240420=lu...@debian.org=1=1=1=1#results > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please mark it as 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. > >
Bug#1055847: Please check python-sparse issue at Github
Hi Diane and Ghislain, you are listed as Uploaders of python-sparse. Since I now have other tasks than maintaining team maintained packages I would be really happy if you could subscribe upstream issue https://github.com/pydata/sparse/issues/628 and continue what I have started. Thanks a lot Andreas. -- https://fam-tille.de
Bug#1012893: Status of the t64 transition
Hi Sebastian, thank you for your work on t64 transition. Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher: I've spotted these Debian Med packages. > gentle > jellyfish > quorum > sbmltoolbox No idea how we can help here. Please let us know if we can do something. > anfo We like to fix gcc-12 issues (#1012893) in anfo but so far nobody managed to do so since it seems to be quite complex. If we are blocking progress with this package its probably a sign that it should be removed from Debian. > blasr We try to work on #1067374. > freebayes Upstream is working on bug #1067271. > vg This package is in a bad state in any case and we are aware of this. However, could you explain in how far is this affecting t64 transition since 32bit architectures are excluded? > If you maintain any of the packages above, please check their status and > help get them fixed. Any help in filing bugs, fixing packages, > requesting removals, etc. is appreciated so that we can look into > unblocking the whole stack and migrate it to testing. I fixed two packages of Debian Python Team and pinged about some packages in Debian Science Team. Kind regards Andreas. -- https://fam-tille.de
Bug#1066334: Redefinition of _Int (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])
H again,
Am Sun, Apr 14, 2024 at 07:17:41AM +0200 schrieb Andreas Tille:
> Am Sat, Apr 13, 2024 at 10:46:17PM +0100 schrieb Jeremy Sowden:
> >
> > The one after this looks like a GTK problem, and that's the point at
> > which I bow out.
I was able to fix some more missing declaration issues (which luckily did
not were connected to GTK) but I'm now stumbling upon:
...
In file included from disknew.c:85:
../whooks/systags.h:57:15: error: expected identifier before numeric constant
57 | #define _Int 24
| ^~
../wh/acetypes.h:36:16: note: in expansion of macro '_Int'
36 | typedef enum { _Int, _Text, _Float, _DateType, _Key, _Tag } AceType;
|^~~~
...
which is caused by whooks/systags.h[2]
...
#define _Int 24
#define _Unsigned 25
#define _Long 26 /* not supported */
#define _Long_Unsigned 27 /* not supported */
#define _Float 28
...
Is there any trick I could use here instead of replacing these
definitions by something else like _Int_acedb or so globally to get this
build by modern compilers?
Kind regards
Andreas.
[1] https://salsa.debian.org/med-team/acedb/-/jobs/5586407#L1893
[2]
https://salsa.debian.org/med-team/acedb/-/blob/master/whooks/systags.h?ref_type=heads#L57-61
--
https://fam-tille.de
Bug#1066334: cython/bison issue (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])
Hi Jeremy, Am Sat, Apr 13, 2024 at 10:46:17PM +0100 schrieb Jeremy Sowden: > > The one after this looks like a GTK problem, and that's the point at > which I bow out. Thanks a lot for your help so far. Your patches are pushed to Git. Kind regards Andreas. -- https://fam-tille.de
Bug#1066334: cython/bison issue (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])
Control: tags -1 help thanks Hi, while I was able to fix the origininal cause of the failure I'm now blocked by some issue that cython seems to miss adding some #include but I have no idea how to accomplish this. The Salsa CI build log[1] says: ... y.tab.c: In function 'yyparse': y.tab.c:1409:16: error: implicit declaration of function 'yylex' [-Werror=implicit-function-declaration] y.tab.c:2185:7: error: implicit declaration of function 'yyerror'; did you mean 'YYerror'? [-Werror=implicit-function-declaration] In file included from aqlparse.y:335: aqlparse.l: In function 'yylex': ... Any help would be welcome Andreas. [1] https://salsa.debian.org/med-team/acedb/-/jobs/5580840 -- https://fam-tille.de
Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Hi, Am Wed, Apr 10, 2024 at 03:33:53PM -0700 schrieb Steven Eker: > I like that solution since I believe there are 64-bit platforms where long > is 32-bits. I've updated my development version thus: > > // > // timeValue.tv_sec is 64-bit since Linux kernel 5.6 but GMP doesn't > yet have support > // for long long which is a problem on platforms where long is less > than 8 bytes. > // > #if SIZEOF_LONG < 8 > double seconds = timeValue.tv_sec; > #else > long seconds = timeValue.tv_sec; > #endif > mpz_class nanoSeconds(seconds); Sounds like some working solution. It would help if you could tag a new released to enable us fetching a fresh tarball incorporatinig this change. > Of course I expect to drop support for 32-bit before 2038 - certainly when > one our dependencies drops support. But I've gotten a bug report for > building Maude on a Raspberry Pi. Raspian is based on Debian and if the 32bit ARM architectures fail here Raspian people have a problem. Kind regards Andreas. -- https://fam-tille.de
Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Hi, I'd suggest to set Build-Depends: architecture-is-64-bit, architecture-is-little-endian and remove 32bit architectures of maude. Kind regards Andreas. -- https://fam-tille.de
Bug#1068401: Pending uplad (Was: Bug#1068401: ltrsift dependencies unsatisfiable on 32-bit non-i386 architectures.)
Hi Sascha, Am Thu, Apr 04, 2024 at 10:33:16PM +0200 schrieb Sascha Steinbiss: > Interesting to see that there is no ltrsift-examples package indeed. But > I must have had my reasons back then... > > Anyway, to be honest I don't see much long-term future for LTRsift. I am > actually surprised to see it still in Debian and not dropped out of > testing as it depends on GTK2, which I assumed was gone from Debian > already [0, 1]. I guess GTK2 will not be supported after the next release any more (at best). As long as no RC bugs are filed against packages depending from it, it seems fine to keep these in a clean shape. > I'd be happy with introducing an examples package but I don't think > there is going to be a usable autopkgtest to gain, sorry. Thanks for the clarification. I'll leave this absolutely to you. Given your explanation I do not think it is worth a detour via new queue. Thus I reverted my change to introduce the examples package. I'll leave you the final decision and upload (where you can drop the "Team upload" in changelog to silence lintian). > I have pushed some changes and can upload soon. Thanks a lot Andreas. > [0] Apparently not, but it's dead upstream: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947713 > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967603 -- https://fam-tille.de
Bug#1065339: src:r-cran-rstanarm: FTBFS on mips64el and risc64
Control: retitle -1 src:r-cran-rstanarm: FTBFS on mips64el and risc64
Control: reopen -1
Control: tags -1 upstream
Control: forwarded -1 https://github.com/stan-dev/rstanarm/issues/619
thanks
As per autobuilders log[1] the package fails to build on mips64el and risc64
with
...
g++ -std=gnu++17 -I"/usr/share/R/include" -DNDEBUG -I"../inst/include"
-I"/usr/lib/R/site-library/StanHeaders/include/src" -DBOOST_DISABLE_ASSERTS
-DEIGEN_NO_DEBUG -DBOOST_MATH_OVERFLOW_ERROR_POLICY=errno_on_error -DUSE_STANC3
-D_HAS_AUTO_PTR_ETC=0 -I'/usr/lib/R/site-library/StanHeaders/include'
-I'/usr/lib/R/site-library/rstan/include'
-I'/usr/lib/R/site-library/BH/include' -I'/usr/lib/R/site-library/Rcpp/include'
-I'/usr/lib/R/site-library/RcppEigen/include'
-I'/usr/lib/R/site-library/RcppParallel/include'-I/usr/include
-DTBB_INTERFACE_NEW -I'/usr/lib/R/site-library/RcppParallel/include'
-D_REENTRANT -DSTAN_THREADS -DTBB_INTERFACE_NEW-fpic -g -O2
-ffile-prefix-map=/<>/r-base-4.3.2=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c
stan_files/count.cc -o stan_files/count.o
In file included from
/usr/include/boost/math/special_functions/detail/bessel_jy.hpp:14,
from /usr/include/boost/math/special_functions/bessel.hpp:20,
from
/usr/lib/R/site-library/StanHeaders/include/stan/math/prim/fun/bessel_first_kind.hpp:6,
from
/usr/lib/R/site-library/StanHeaders/include/stan/math/prim/fun.hpp:31,
from
/usr/lib/R/site-library/StanHeaders/include/stan/math/prim.hpp:14,
from
/usr/lib/R/site-library/StanHeaders/include/src/stan/io/dump.hpp:7,
from
/usr/lib/R/site-library/rstan/include/rstan/stan_fit.hpp:43,
from
/usr/lib/R/site-library/rstan/include/rstan/rstaninc.hpp:4,
from stan_files/count.hpp:18,
from stan_files/count.cc:3:
/usr/include/boost/math/special_functions/gamma.hpp: In instantiation of
‘boost::math::detail::upper_incomplete_gamma_fract::result_type
boost::math::detail::upper_incomplete_gamma_fract::operator()() [with T =
double; result_type = std::pair]’:
/usr/include/boost/math/tools/fraction.hpp:217:20: required from ‘typename
boost::math::tools::detail::fraction_traits::result_type
boost::math::tools::continued_fraction_a(Gen&, const U&, uintmax_t&) [with Gen
= boost::math::detail::upper_incomplete_gamma_fract; U = double;
typename detail::fraction_traits::result_type = double; uintmax_t = long
unsigned int]’
/usr/include/boost/math/tools/fraction.hpp:252:31: required from ‘typename
boost::math::tools::detail::fraction_traits::result_type
boost::math::tools::continued_fraction_a(Gen&, const U&) [with Gen =
boost::math::detail::upper_incomplete_gamma_fract; U = double; typename
detail::fraction_traits::result_type = double]’
/usr/include/boost/math/special_functions/gamma.hpp:314:68: required from ‘T
boost::math::detail::upper_gamma_fraction(T, T, T) [with T = double]’
/usr/include/boost/math/special_functions/gamma.hpp:1176:44: required from ‘T
boost::math::detail::gamma_incomplete_imp(T, T, bool, bool, const Policy&, T*)
[with T = double; Policy =
boost::math::policies::policy,
boost::math::policies::promote_float,
boost::math::policies::promote_double,
boost::math::policies::default_policy, boost::math::policies::default_policy,
boost::math::policies::default_policy, boost::math::policies::default_policy,
boost::math::policies::default_policy, boost::math::policies::default_policy,
boost::math::policies::default_policy, boost::math::policies::default_policy,
boost::math::policies::default_policy, boost::math::policies::default_policy>]’
/usr/include/boost/math/special_functions/gamma.hpp:2130:35: required from
‘boost::math::tools::promote_args_t boost::math::gamma_p(RT1, RT2,
const Policy&) [with RT1 = double; RT2 = double; Policy =
policies::policy,
policies::pole_error,
policies::promote_double, policies::digits2<0>,
policies::default_policy, policies::default_policy, policies::default_policy,
policies::default_policy, policies::default_policy, policies::default_policy,
policies::default_policy, policies::default_policy, policies::default_policy>;
tools::promote_args_t = double]’
/usr/lib/R/site-library/StanHeaders/include/stan/math/prim/fun/gamma_p.hpp:76:30:
required from here
/usr/include/boost/math/special_functions/gamma.hpp:299:16: note: the ABI for
returning a value with C++17 empty bases but otherwise an aggregate with only
one or two floating-point fields was changed in GCC 12.1
299 |result_type operator()()
|^~~~
"/usr/lib/R/bin/Rscript" -e "source(file.path('..', 'tools', 'make_cc.R'));
make_cc(commandArgs(TRUE))" stan_files/jm.stan
code for methods in class "Rcpp_model_base" was not checked for suspicious
field assignments (recommended package 'codetools' not available?)
code for methods in class
Bug#1068401: Pending uplad (Was: Bug#1068401: ltrsift dependencies unsatisfiable on 32-bit non-i386 architectures.)
Control: tags -1 pending thanks Hi Sascha, after routine-update dh_missing failed due to compat level 13 which defaults to fail if some files are not installed. This made me aware that upstream in principle installs a test suite we could use for an autopkgtest. I also realised that you once added debian/ltrsift-examples.examples - so you probably had such a package in mind. Since I have no idea what reasons you had not to use this file I'll leave the final decision to you. (Please note: Somehow a copy of ltrsift_code ends up in the examples dir - I did not yet investigated why this is happening. Before I have no clear picture about your intentions I'll left this for later investigation.) Kind regards Andreas. -- https://fam-tille.de
Bug#1067959: sambamba: FTBFS on armhf (supported compiler issue)
Hi, Am Fri, Mar 29, 2024 at 10:32:25PM +0900 schrieb Kentaro HAYASHI: > sambamba fails to build on armhf. Thanks a lot for this bug report. I'd recommend to drop 32bit architectures for this package. Kind regards Andreas. > FYI: > > https://buildd.debian.org/status/fetch.php?pkg=sambamba=armhf=1.0.1%2Bdfsg-1=1699230688=0 > > Regards, -- https://fam-tille.de
Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Hi Emanuele. Am Tue, Mar 19, 2024 at 12:16:16PM +0100 schrieb Emanuele Rocca: > I've uploaded a NMU to DELAYED/2: https://bugs.debian.org/1067147 Thanks a lot for your attempt to help. In principle we have a team wide low threshold NMU - so undelayed NMUs are fine. The kind of race condition in uploads might imply that some ping in advance might be helpful to avoid duplicated work. > With those changes dcmtk builds fine on both armel and armhf. I've > dropped the graphviz build-depend on those arches too, it can of course > be reintroduced once graphviz become installable again. Meanwhile your patch is imported and was uploaded by Michael - thanks to all who helped solving this. Kind regards Andreas. -- http://fam-tille.de
Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Hi again, sorry, I did not checked the situation. Am Tue, Mar 19, 2024 at 10:34:13AM +0100 schrieb Andreas Tille: > Testing removals are happening automatically if some RC bug exists > for a certain time without pinging. Just writing some additional > information to the bug in question would have prevented this but > nobody of us had sufficient capacity. That's a shame but will be > healed over time (which is hopefully not that long). Since you all pinged that bug we now have another 4 weeks of time before anything gets removed from testing. So we just need to bear the noise from testing removal warnings of quite some packages (which I'd love to get rid of thus uploading a fix would be great). Kind regards Andreas. -- http://fam-tille.de
Bug#1063980: Mark affected test xfail and reduce bug severity + report upstream
Control: tags -1 important Control: tags -1 upstream Control: forwarded -1 https://github.com/jnothman/UpSetPlot/issues/273 thanks Hi, I've checked the new upstream version of python-upsetplot which shows the same problem. Thus I marked the one affected test xfail and reported the problem upstream. Since the package builds again now and is passing its autopkgtest I reduced the severity of the bug from serious to important. Kind regards Andreas. -- http://fam-tille.de
Bug#1066409: Reassign nodejs and merge bug (Was: Linker fails to find libraries in unstable but succeeds in testing)
Control: reassign -1 nodejs Control: forcemerge 1066399 -1 thanks Hi Jochen, Am Fri, Mar 15, 2024 at 08:46:11AM +0100 schrieb Jochen Sprickerhof: > > I guess that's the same as #1066399. > > libnode-dev: > libv8.so -> libnode.so > libnode.so -> libnode.so.108t64 > > But libnode.so.108t64 does not exist Thanks a lot for the hint. Reassigning and merging accordingly. Kind regards Andreas. -- http://fam-tille.de
Bug#1066409: Linker fails to find libraries in unstable but succeeds in testing
Hi, thanks to the next round of Lucas' FTBFS QA rebuilds (at least) one package of the R pkg team is affected by some strange linker issue #1066409 r-cran-v8: FTBFS: ld: cannot find -lv8: No such file or directory which boils down to[1] g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o V8.so RcppExports.o bindings.o -lv8 -lv8_libplatform -L/usr/lib/R/lib -lR /usr/bin/ld: cannot find -lv8: No such file or directory /usr/bin/ld: cannot find -lv8_libplatform: No such file or directory The Build-Depends libnode-dev provides both libraries and when I try to build the package under testing all is fine. Is there any linker issue involved that might be introduced in unstable? Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/r-cran-v8/-/jobs/5446089 -- http://fam-tille.de
Bug#1066409: [Help] Re: Bug#1066409: r-cran-v8: FTBFS: ld: cannot find -lv8: No such file or directory
Control: tags -1 help Control: tags -1 confirmed Hi, Am Wed, Mar 13, 2024 at 01:05:16PM +0100 schrieb Lucas Nussbaum: > > Using PKG_LIBS=-lv8 -lv8_libplatform > > Running feature test for pointer compression... > > /usr/bin/ld: cannot find -lv8: No such file or directory > > /usr/bin/ld: cannot find -lv8_libplatform: No such file or directory I can confirm this problem also for the latest upstream version (which is not astonishing since nothing in this line has changed) as you can see on Salsa CI https://salsa.debian.org/r-pkg-team/r-cran-v8/-/jobs/5446089 I have to admit I have no idea why suddenly the perfectly available libraries are not found by the linker any more. The linker call g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o V8.so RcppExports.o bindings.o -lv8 -lv8_libplatform -L/usr/lib/R/lib -lR looks perfectly fine, was not changed and the libraries /usr/lib/x86_64-linux-gnu/libv8_libplatform.so /usr/lib/x86_64-linux-gnu/libv8.so are provided by libnode-dev inside the chroot as I verified. Interestingly the package builds fine on my local system which is running testing. Remark to Leopold: As I wrote in my "Action needed for R-pkg Uploaders"-mail I would be happy if you would pronounce whether you are up for maintaining this package actively or not. You are mentioned as only Uploader but the changelog says: $ grep '^ --' debian/changelog -- Andreas Tille Fri, 22 Dec 2023 10:19:13 +0100 -- Andreas Tille Fri, 22 Dec 2023 10:12:23 +0100 -- Andreas Tille Mon, 16 Oct 2023 16:47:36 +0200 -- Andreas Tille Fri, 21 Jul 2023 17:26:16 +0200 -- Andreas Tille Tue, 04 Jul 2023 09:07:03 +0200 -- Andreas Tille Thu, 29 Jun 2023 14:58:21 +0200 -- Andreas Tille Tue, 15 Nov 2022 19:39:16 +0100 -- Andreas Tille Thu, 11 Aug 2022 16:19:43 +0200 -- Jérémy Lal Sun, 17 Jul 2022 17:49:15 +0200 -- Andreas Tille Tue, 24 May 2022 11:25:24 +0200 -- Andreas Tille Wed, 16 Feb 2022 10:45:42 +0100 -- Andreas Tille Sun, 15 Aug 2021 13:51:20 +0200 -- Andreas Tille Mon, 09 Nov 2020 12:50:36 +0100 -- Dylan Aïssi Tue, 30 Jun 2020 10:18:56 +0200 -- Jérémy Lal Sun, 14 Jun 2020 21:31:12 +0200 -- Dylan Aïssi Wed, 03 Jun 2020 08:57:25 +0200 -- Dylan Aïssi Fri, 20 Mar 2020 12:03:25 +0100 -- Andreas Tille Thu, 23 Jan 2020 21:23:32 +0100 -- Dylan Aïssi Sat, 11 Jan 2020 08:30:40 +0100 -- Dylan Aïssi Thu, 18 Jul 2019 21:14:49 +0200 -- Dylan Aïssi Thu, 07 Feb 2019 07:43:35 +0100 -- Dylan Aïssi Sun, 03 Feb 2019 13:46:40 +0100 -- Andreas Tille Thu, 21 Jun 2018 17:34:03 +0200 -- Andreas Tille Wed, 25 Oct 2017 09:28:11 +0200 -- Leopold Palomo-Avellaneda Tue, 21 Mar 2017 12:17:40 +0100 It was great you introduced the package into Debian. Thanks fro doing so. However, please be verbose whether you have the capacity to keep on maintaining it or not. Kind regards Andreas. [1] https://lists.debian.org/debian-r/2024/03/msg0.html -- http://fam-tille.de
Bug#1065759: Retitle libbio-samtools-perl: FTBFS on arm{el,hf}: lib/Bio/DB/Sam.xs:324:4: error: implicit declaration of function ‘bam_sort_core’; did you mean ‘bam_format1_core’? [-Werror=implicit-fun
Control: retitle -1 libbio-samtools-perl: FTBFS: lib/Bio/DB/Sam.xs:324:4: error: implicit declaration of function ‘bam_sort_core’; did you mean ‘bam_format1_core’? [-Werror=implicit-function-declaration] Control: tags -1 help thanks I can confirm that this bug also occures on amd64 thus removing the arm-restriction from the title. Unfortunately I have no idea how to fix this (except by possibly suppressing the -Werror=implicit-function-declaration option). Thus tagging 'help' Kind regards Andreas. -- http://fam-tille.de
Bug#1064921: src:r-cran-estimatr: fails to migrate to testing for too long: autopkgtest regression on i386
Control: tags -1 upstream Control: forwarded -1 https://github.com/DeclareDesign/estimatr/issues/407 Control: reopen -1 thanks I have forwarded this problem upstream. I've also reopened this bug to make sure it will show up on our sentinel Kind regards Andreas. -- http://fam-tille.de
Bug#1064922: src:r-cran-gbm: fails to migrate to testing for too long: autopkgtest regression
Control: tags -1 upstream Control: forwarded -1 https://github.com/gbm-developers/gbm/issues/78 Control: reopen -1 thanks I have forwarded this bug upstream. I've also re-opened the bug to make sure it appears on our list of bugs. -- http://fam-tille.de
Bug#1064135: src:r-cran-bigmemory: fails to migrate to testing for too long: autopkgtest fails on arm*, ppc64el and s390x
Control: tags -1 upstream Control: forwarded -1 https://github.com/kaneplusplus/bigmemory/issues/115 Control: reopen -1 Thanks Bug was forwarded upstream with no response so far. Re-opening to stay aware that this bug exists. -- http://fam-tille.de
Bug#1026587: cerealizer: TypeError: __dict__ must be set to a dictionary, not a 'NoneType'
Control: tags -1 upstream Control: forwarded -1 j...@lesfleursdunormal.fr Hi Jean-Baptiste, the Debian packaged version of cerealizer recieved a bug report about a build failure TypeError: __dict__ must be set to a dictionary, not a 'NoneType' You can read the relevant part of the build log inside the bug report[1]. While this report is not about your latest upstream version (it is against version 0.8.1 which was the packaged version at the time of the bug report) I updated to version 0.8.3 in our packaging git. When running our CI test with the latest tools I get the same error unfortunately. You can find the full build log here: https://salsa.debian.org/python-team/packages/cerealizer/-/jobs/5375270 It would be great if you could find a fix for this issue. Kind regards Andreas. [1] https://bugs.debian.org/1026587 -- http://fam-tille.de
Bug#1054736: Do we need versiontools in Debian any more?
Hi Benjamin, as far as I can see no other package is using versiontools and it seems orphaned upstream. Do you think we need this package in Debian or should we rather ask ftpmaster for removal? I personally have no specific interest in this package and was just hunting some Python3.12 related bugs. Kind regards Andreas. -- http://fam-tille.de
Bug#1064160: pngcrush FTBFS with libpng 1.6.42
Control: tags -1 patch Control: tags -1 pending Hi Marga, I've pushed the patch used in ArchLinux to Git[1]. I could do another NMU but I would prefer to move the package to Debian Phototools team and I'd volunteer to do that move. Kind regards Andreas. [1] https://salsa.debian.org/debian/pngcrush/-/blob/master/debian/patches/ignore_PNG_IGNORE_ADLER32.patch?ref_type=heads -- http://fam-tille.de
Bug#1061765: Help needed to fix python-coverage-test-runner
HI Andrius, Am Fri, Feb 23, 2024 at 09:29:27AM +0200 schrieb Andrius Merkys: > > ModuleNotFoundError: No module named 'imp' > > I had a similar problem. I worked it around by depending on > python3-zombie-imp, the original code did not require any modifications. Nice hint - implemented. Thanks a lot Andreas. -- http://fam-tille.de
Bug#1061765: Help needed to fix python-coverage-test-runner
Control: tags -1 help Hi, I've attempted to fix python-coverage-test-runner in Git since this package is finally responsible for the failure of vmdb2: File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 22, in import imp ModuleNotFoundError: No module named 'imp' In the patch in Git[1] I replaced imp by importlib (and distutils by setuptools but this is not causing actual problems). Unfortunately when trying to run vmdb2 test against this patched package I get: ./check Running unit tests Traceback (most recent call last): File "", line 198, in _run_module_as_main File "", line 88, in _run_code File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 313, in run() File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 304, in run result = runner.run() File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 211, in run importlib.reload(module) File "/usr/lib/python3.11/importlib/__init__.py", line 148, in reload raise ImportError(msg.format(name), name=name) ImportError: module plugin not in sys.modules The fact that importlib.reload(module) makes me wonder whether my patch for _load_module_from_pathname() is correct (despite when I added some debug lines it looked sensible). Any help is welcome. Kind regards Andreas. [1] https://salsa.debian.org/python-team/packages/python-coverage-test-runner/-/blob/master/debian/patches/Python3.12.patch?ref_type=heads -- http://fam-tille.de
Bug#1058895: Status of sqlalchemy
Hi, we have quite some Python3.12 related bugs caused by sqlalchemy which seem to be fixed in experimental (which is lagging behind upstream 2.0.27 as well as version 1.4 in unstable where upstream just released 1.4.51). It seems the issue that leads to bug #1058265 > File "/usr/lib/python3/dist-packages/sqlalchemy/sql/sqltypes.py", line 2061, in Interval > epoch = dt.datetime.utcfromtimestamp(0) is not fixed in 1.4.51 so sticking to 1.4 maintenance releases will not simply solve our Python3.12 issues if we do not fix these ourselves with patches. So the question remains for Thomas wo wrote in bug #1058895: > It'd be nice if we could have the patch in Unstable with this series 1.4.x > before uploading 2.x, so that I have a chance to fix all Python 3.12 bugs and > not mix SQLA 2.x and Py 3.12 problems. Do yuo really want to fix 1.4.x (maybe x=51) first or do we want to switch to 2.0.27 and fix remaining problems with this latest version? I have no resources to run all the tests but I stumbled upon this question when trying to do some general Python3.12 bug hunting. Kind regards Andreas. -- http://fam-tille.de
Bug#1056503: Bug#1052619: ITP: pydantic-core -- Rust implementation of pydantic core functionality
Hi Timo, thanks for the quick update. Am Thu, Feb 22, 2024 at 09:08:19AM +0100 schrieb Timo Röhling: > * Andreas Tille [2024-02-22 08:49]: > > any progress with pydantic-core? I've checked Salsa for the string > > "pydantic" but did not found pydantic-core there. It would be really > > great to have pydantic 2.x (I stumbled upon python-semantic-release > > which also needs it to easily fix #1056503 by upgrading to latest > > upstream which seems to work with Python3.12) > The pydantic-core packaging itself is pretty much done, but I still need the > Rust crate "speedate" as dependency. For the latest upstream version of > pydantic-core, "jitter" is needed as well. Sounds promising. ;-) > > I need to admit I have no experience in Rust packaging so I can't > > really help here but pushing some start to Salsa could be the first > > step. > The Rust team has a very unusual workflow, which is not difficult to follow > but somewhat more involved than "file ITP, upload package", which caused me > to procrastinate. :/ :-) Well, I hope this workflow does not prevent you from pushing to Salsa. I personally have the habit to add some TODO items to d/changelog where other developers hopefully look first. Thanks a lot for working on this Andreas. -- http://fam-tille.de
Bug#1056503: ITP: pydantic-core -- Rust implementation of pydantic core functionality
Hi Timo, any progress with pydantic-core? I've checked Salsa for the string "pydantic" but did not found pydantic-core there. It would be really great to have pydantic 2.x (I stumbled upon python-semantic-release which also needs it to easily fix #1056503 by upgrading to latest upstream which seems to work with Python3.12) I need to admit I have no experience in Rust packaging so I can't really help here but pushing some start to Salsa could be the first step. Kind regards Andreas. -- http://fam-tille.de
Bug#1055728: Segyio is lagging behind upstream (Was: segyio ftbfs with Python 3.12)
Hi Tino, thanks for the hint which reduced the number of test suite failures to one as you can see in Salsa CI[1]. In case someone might find a solution for this one we might upload - if not I wonder whether this package is a candidate for removal. Please note: I have no interest into this package at all - just hunting for Python3.12 issues. Kind regards Andreas. [1]https://salsa.debian.org/science-team/segyio/-/jobs/5338110 Am Wed, Feb 21, 2024 at 11:42:58AM +0100 schrieb Tino Didriksen: > std::uint16_t is in #include > > stdint.h is the C header, which doesn't import the symbols to the std:: > namespace. In general, the headers Standard C++ imports from Standard C > snips the .h and prefixes c, so stdint.h -> cstdint, stdio.h -> cstdio, etc. > > -- Tino Didriksen > > > On Wed, 21 Feb 2024 at 11:16, Andreas Tille wrote: > > > Hi, > > > > I've found in the set of patches for segyio other cherry-picked patches > > to adapt to certain Python3.x versions[1]. The patch kindly suggested > > by s3v to fix this bug[2] would simply be another cherry-pick from upstream > > who has meanwhile released a couple of new versions incorporating all > > patches we seem to need for Python3.12 - thus by upgrading to latest > > upstream the current bug would be fixed. > > > > Usually I would do this in case of team maintained packages but I faced > > some problems with latest upstream and thus I simply created a branch > > version_1.9.12 with all proposed changes including current packaging > > standards and fixing a further bug. Unfortunately the build system is > > all but smooth compared to other packages and I finally stumbled upon > > a C++ conversion issue[4] which is not solved by simply adding > >#include > > and my further attempt leads to a test suite issue which seems to > > indicate that my poor C++ understanding is wrong. > > > > So I'm giving up here by leaving two questions: > > > >1. Anybody up for fixing this package and bringing it to latest > > upstream? > >2. Alternatively do we want to drop this package from Debian? > > > > Kind regards > > Andreas. > > > > > > [1] > > https://salsa.debian.org/science-team/segyio/-/tree/master/debian/patches?ref_type=heads > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055728#14 > > [3] > > https://salsa.debian.org/science-team/segyio/-/tree/version_1.9.12?ref_type=heads > > [4] > > https://salsa.debian.org/science-team/segyio/-/blob/version_1.9.12/debian/patches/gcc-13.patch?ref_type=heads#L6-9 > > > > -- > > http://fam-tille.de > > > > -- http://fam-tille.de
Bug#1055728: Segyio is lagging behind upstream (Was: segyio ftbfs with Python 3.12)
Hi, I've found in the set of patches for segyio other cherry-picked patches to adapt to certain Python3.x versions[1]. The patch kindly suggested by s3v to fix this bug[2] would simply be another cherry-pick from upstream who has meanwhile released a couple of new versions incorporating all patches we seem to need for Python3.12 - thus by upgrading to latest upstream the current bug would be fixed. Usually I would do this in case of team maintained packages but I faced some problems with latest upstream and thus I simply created a branch version_1.9.12 with all proposed changes including current packaging standards and fixing a further bug. Unfortunately the build system is all but smooth compared to other packages and I finally stumbled upon a C++ conversion issue[4] which is not solved by simply adding #include and my further attempt leads to a test suite issue which seems to indicate that my poor C++ understanding is wrong. So I'm giving up here by leaving two questions: 1. Anybody up for fixing this package and bringing it to latest upstream? 2. Alternatively do we want to drop this package from Debian? Kind regards Andreas. [1] https://salsa.debian.org/science-team/segyio/-/tree/master/debian/patches?ref_type=heads [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055728#14 [3] https://salsa.debian.org/science-team/segyio/-/tree/version_1.9.12?ref_type=heads [4] https://salsa.debian.org/science-team/segyio/-/blob/version_1.9.12/debian/patches/gcc-13.patch?ref_type=heads#L6-9 -- http://fam-tille.de
Bug#1064223: imbalanced-learn: fails tests with sklearn 1.4: needs new versions
Control: tags -1 upstream Control: forwarded -1 https://github.com/scikit-learn-contrib/imbalanced-learn/issues/1062 Hi, thanks a lot for the hint about the new version of imbalanced-learn. Unfortunately it is not sufficient to simply upgrade to latest upstream as you can see in Salsa CI[1]. Thus I've reported the issue upstream. Kind regards Andreas. [1] https://salsa.debian.org/med-team/imbalanced-learn/-/jobs/5331921 -- http://fam-tille.de
Bug#1044054: dyda: test failure with pandas 2.0
Control: tags -1 help Hi, I've pushed the packaging to Debian Science team on Salsa which created a persistent autopkgtest log in Salsa CI[1] where the said bug can be reproduced. Any help to fix TypeError: Could not convert string 'classification' to numeric The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/tmp/autopkgtest-lxc.zjkxt8yu/downtmp/build.5t5/src/tests/test_DeterminatorByAggregatedDataSingle.py", line 24, in test_main_process d.run() File "/usr/lib/python3/dist-packages/dyda/core/dyda_base.py", line 674, in run self.main_process() would be welcome. Kind regards Andreas. [1] https://salsa.debian.org/science-team/dyda/-/jobs/5321620 -- http://fam-tille.de
Bug#1044060: More qiime related issues affecting q2-quality-control (Was: Help needed to port qiime to Python3.12)
Hi again, Am Sun, Feb 18, 2024 at 12:25:49PM +0100 schrieb Andreas Tille: > I just realised that a new qiime version is out. I will upgrade > to latest upstream and see how this might affect this issue The new qiime upstream version does not change anything. After I switched q2-* packages to run autopkgtest for `py3versions -s` I realised the problem below exist in several of the q2-* packages so its rather no Pandas issue but a Python3.12 problem which in parallel to the Pandas migration showed up. If you might have any hint how to deal with these (no matter for the old or the new qiime package since I assume the patch will apply to both, it would be really appreciated. Kind regards Andreas. > Am Sun, Feb 18, 2024 at 12:11:04PM +0100 schrieb Andreas Tille: > > Control: tags -1 help > > > > Hi again, > > > > I hope to approach the last remaining Pandas issue for the qiime > > ecosystem. As it has become obvious in the q2-types package I'm now > > facing pretty similar errors when running the q2-quality-control > > package which can be seen in full length in Salsa-CI[3] and contains > > errors like: > > > > E AttributeError: 'ProvenancePath' object has no attribute '_drv' > > E AttributeError: 'ProvenancePath' object has no attribute > > '_raw_paths' > > E AttributeError: 'ProvenancePath' object has no attribute '_str' > > E AttributeError: 'OutPath' object has no attribute '_str' > > > > This all goes back to the qiime package but I admit I have no idea > > how to fix this. > > > > Kind regards > > Andreas. > > > > > > [3] https://salsa.debian.org/med-team/q2-quality-control/-/jobs/5320775#L700 > > > > Am Sat, Feb 17, 2024 at 11:36:41AM +0100 schrieb Andreas Tille: > > > Hi, > > > > > > as reported in a qiime2 issue[1] there is some problem with Python3.12 > > > in the tests of the q2-* packages which are all using the qiime package. > > > This problem is currently hidden from the tests made by Python3.12 > > > porters but it became obvious now on Salsa CI[2]. I tried to fiddle > > > around a bit with the qiime code but with no success at all. Any help > > > would be welcome. > > > > > > Kind regards > > > Andreas. > > > > > > [1] https://github.com/qiime2/qiime2/issues/751 > > > [2] https://salsa.debian.org/med-team/q2-types/-/jobs/5313640#L900 > > > > > > -- > > > http://fam-tille.de > > > > -- > > http://fam-tille.de > > -- > http://fam-tille.de -- http://fam-tille.de
Bug#1044060: More qiime related issues affecting q2-quality-control (Was: Help needed to port qiime to Python3.12)
Hi, I just realised that a new qiime version is out. I will upgrade to latest upstream and see how this might affect this issue Kind regards Andreas. Am Sun, Feb 18, 2024 at 12:11:04PM +0100 schrieb Andreas Tille: > Control: tags -1 help > > Hi again, > > I hope to approach the last remaining Pandas issue for the qiime > ecosystem. As it has become obvious in the q2-types package I'm now > facing pretty similar errors when running the q2-quality-control > package which can be seen in full length in Salsa-CI[3] and contains > errors like: > > E AttributeError: 'ProvenancePath' object has no attribute '_drv' > E AttributeError: 'ProvenancePath' object has no attribute '_raw_paths' > E AttributeError: 'ProvenancePath' object has no attribute '_str' > E AttributeError: 'OutPath' object has no attribute '_str' > > This all goes back to the qiime package but I admit I have no idea > how to fix this. > > Kind regards > Andreas. > > > [3] https://salsa.debian.org/med-team/q2-quality-control/-/jobs/5320775#L700 > > Am Sat, Feb 17, 2024 at 11:36:41AM +0100 schrieb Andreas Tille: > > Hi, > > > > as reported in a qiime2 issue[1] there is some problem with Python3.12 > > in the tests of the q2-* packages which are all using the qiime package. > > This problem is currently hidden from the tests made by Python3.12 > > porters but it became obvious now on Salsa CI[2]. I tried to fiddle > > around a bit with the qiime code but with no success at all. Any help > > would be welcome. > > > > Kind regards > > Andreas. > > > > [1] https://github.com/qiime2/qiime2/issues/751 > > [2] https://salsa.debian.org/med-team/q2-types/-/jobs/5313640#L900 > > > > -- > > http://fam-tille.de > > -- > http://fam-tille.de -- http://fam-tille.de
Bug#1044060: More qiime related issues affecting q2-quality-control (Was: Help needed to port qiime to Python3.12)
Control: tags -1 help Hi again, I hope to approach the last remaining Pandas issue for the qiime ecosystem. As it has become obvious in the q2-types package I'm now facing pretty similar errors when running the q2-quality-control package which can be seen in full length in Salsa-CI[3] and contains errors like: E AttributeError: 'ProvenancePath' object has no attribute '_drv' E AttributeError: 'ProvenancePath' object has no attribute '_raw_paths' E AttributeError: 'ProvenancePath' object has no attribute '_str' E AttributeError: 'OutPath' object has no attribute '_str' This all goes back to the qiime package but I admit I have no idea how to fix this. Kind regards Andreas. [3] https://salsa.debian.org/med-team/q2-quality-control/-/jobs/5320775#L700 Am Sat, Feb 17, 2024 at 11:36:41AM +0100 schrieb Andreas Tille: > Hi, > > as reported in a qiime2 issue[1] there is some problem with Python3.12 > in the tests of the q2-* packages which are all using the qiime package. > This problem is currently hidden from the tests made by Python3.12 > porters but it became obvious now on Salsa CI[2]. I tried to fiddle > around a bit with the qiime code but with no success at all. Any help > would be welcome. > > Kind regards > Andreas. > > [1] https://github.com/qiime2/qiime2/issues/751 > [2] https://salsa.debian.org/med-team/q2-types/-/jobs/5313640#L900 > > -- > http://fam-tille.de -- http://fam-tille.de
Bug#1044064: Help needed fpr last Pandas issue in pyrange (Was: q2-taxa: test failure with pandas 2.1)
Control: tags -1 help
Hi again,
Am Sat, Feb 17, 2024 at 07:31:48PM +0100 schrieb s3v:
> More immediate fix is attached but I guess there is a more elegant
> way by changing the code in _ids_to_keep_from_taxonomy() function.
thanks a lot for all your fixes you provided for Debian Med packages.
There are a few remaining issues, which I would love to ask you step by
step. I found a patch for pyranges[1] which solves all issues but one:
>pd.testing.assert_frame_equal(df1, df2)
EAssertionError: Attributes of DataFrame.iloc[:, 7] (column name="Cluster")
are different
E
EAttribute "dtype" are different
E[left]: int32
E[right]: int64
My attempt to fix this by
+--- a/tests/helpers.py
b/tests/helpers.py
+@@ -57,6 +57,7 @@ def assert_df_equal(df1, df2):
+ print(df2.index)
+ print("index equal", df1.index == df2.index)
+
++df1["Cluster"] = df1["Cluster"].astype(np.int64)
+ pd.testing.assert_frame_equal(df1, df2)
+
+ pd.options.mode.chained_assignment = "warn"
totally failed and introduced a new series of failures basically saying
> ???
E KeyError: 'Cluster'
pandas/_libs/hashtable_class_helper.pxi:7088: KeyError
Any suggestion how to fix that issue?
Kind regards
Andreas.
[1]
https://salsa.debian.org/med-team/pyranges/-/blob/master/debian/patches/pandas2.0.patch?ref_type=heads
--
http://fam-tille.de
Bug#1053943: [Help] q2-taxa: test failure with pandas 2.1 (Was: q2-types: test failure with pandas 2.1)
Control: tags -1 help Am Sat, Feb 17, 2024 at 06:35:41AM +0100 schrieb s3v: > Attached patch makes autopkg tests pass in unstable on a basis of > your work/references and [1] (iteritems() was deprecated since version > 1.5.0 in favor of items()). Cool. This is uploaded (but not yet in incoming due to some routing issue in Debian infrastructure.) > Please note that autopkg test fail with python 3.12 as default because > qiime2, I guess. (log attached). Thanks for the additional hint - I've forwarded the issue upstream. > Thanks for all your work! ... which is possible thanks to the help of kind people like you. The next problem is with q2-taxa, which throws some errors "Passing a set as an indexer is not supported. Use a list instead." E TypeError: Passing a set as an indexer is not supported. Use a list instead. Again I had some vague feeling what to do but failed finding an actual patch after poking around a bit. Any further help would be really great Andreas. -- http://fam-tille.de
Bug#1053944: q2-types: test failure with pandas 2.1 (Was: Bug#1044068: q2templates: FTBFS with pandas 2.0)
Control: tags -1 help
Hi again,
thanks again for your great help. I admit I need some help for q2-types as
well. While log in the bug report vanished you will easily find things like
TypeError: read_csv() got an unexpected keyword argument 'squeeze'
when trying to build the package.
I've found an issue at pandas upstream[1] which inspired me to the patch
--- a/q2_types/sample_data/tests/test_transformer.py
+++ b/q2_types/sample_data/tests/test_transformer.py
@@ -28,8 +28,8 @@ class TestTransformers(TestPluginBase):
obs = transformer(exp)
# Squeeze equals true to return series instead of dataframe
-obs = pd.read_csv(str(obs), sep='\t', header=0, index_col=0,
- squeeze=True)
+obs = pd.read_csv(str(obs), sep='\t', header=0, index_col=0)
+obs.squeeze("columns")
assert_series_equal(exp, obs)
which is obviously wrong since it leads to
# Squeeze equals true to return series instead of dataframe
obs = pd.read_csv(str(obs), sep='\t', header=0, index_col=0)
obs.squeeze("columns")
> assert_series_equal(exp, obs)
Probably a better solution can be found at stackoverflow[2] to use
DataFrame.squeeze('columns') but I'm simply lacking an example how to use
this.
Finally this is not the only error and I would appreciate any helping hint
(patch?) to get the package ported to recent pandas.
Kind regards
Andreas.
[1] https://github.com/pandas-dev/pandas/issues/43242
[2]
https://stackoverflow.com/questions/76684141/why-am-i-getting-an-error-when-using-squeeze-keyword-in-read-csv
Am Fri, Feb 16, 2024 at 10:48:59AM +0100 schrieb s3v:
> ...
> Kind Regards
--
http://fam-tille.de
Bug#1044068: q2templates: FTBFS with pandas 2.0
Hi, thanks a lot for all your help! I've just uploaded q2templates. If you have more hints to pandas2 related bugs these are very welcome. Kind regards Andreas. Am Fri, Feb 16, 2024 at 02:29:15PM +0100 schrieb s3v: > Hi, > > sorry for writing again but, after removing override for auto_test in > d/rules and s/python3/python3-all in d/control for Build-Depends, > tests fail with Python 3.12: > > dh_auto_clean > I: pybuild base:305: python3.12 setup.py clean > /build/q2templates-2023.9.0+ds/versioneer.py:422: SyntaxWarning: invalid > escape sequence '\s' > LONG_VERSION_PY['git'] = ''' > Traceback (most recent call last): > File "/build/q2templates-2023.9.0+ds/setup.py", line 14, in > version=versioneer.get_version(), > > File "/build/q2templates-2023.9.0+ds/versioneer.py", line 1481, in > get_version > return get_versions()["version"] > ^^ > File "/build/q2templates-2023.9.0+ds/versioneer.py", line 1413, in > get_versions > cfg = get_config_from_root(root) > ^^ > File "/build/q2templates-2023.9.0+ds/versioneer.py", line 343, in > get_config_from_root > parser = configparser.SafeConfigParser() > ^ > AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. > Did you mean: 'RawConfigParser'? > E: pybuild pybuild:391: clean: plugin distutils failed with: exit code=1: > python3.12 setup.py clean > > Kind Regards > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de
Bug#1044079: augur: FTBFS with pandas 2.0
Control: tags -1 pending Hi, thanks a lot for this hint. Am Wed, Feb 14, 2024 at 10:36:05AM +0100 schrieb s3v: > I don't know if renaming is a drop-in replacement Me neither but I simply trust that its passing its test suite. Kind regards Andreas. -- http://fam-tille.de
Bug#1056419: Spinx help needed
Control: tags -1 pending Hi, I pushed fixes for #1056419 and #1058311 to Git and I think should be fixed as well. The only remaining build problem is new and caused by sphinx[1]: dh_sphinxdoc -i -O--buildsystem=pybuild dh_sphinxdoc: error: debian/python-lmfit-doc/usr/share/doc/python3-lmfit/html/search.html top-level node does not have data-content_root attribute Unfortunately I have no idea how to fix this. Any ideas? Kind regards Andreas. [1] https://buildd.debian.org/status/package.php?p=lmfit-py=experimental -- http://fam-tille.de
Bug#1063599: More info (Was: mathgl: FTBFS on amd64: tests seg fault)
Control: tags -1 moreinfo Control: severity -1 important Hi Sebastian, the package builds nicely in my local pbuilder, in Salsa CI as well as in the autobuilders. Thus I'm tagging the bug moreinfo and set severity to important. Kind regards Andreas. -- http://fam-tille.de
Bug#1056419: Can we also move uncertainties to DPT (Was: python-hug: autopkgtest failure with Python 3.12)
Hi, thanks for Federico confirming, thus I will move the package to not need to ask again in a possible future attempt. Am Wed, Feb 14, 2024 at 12:24:03PM +0100 schrieb Alexandre Detiste: > Hi Andreas, > > I think usage of "past" has been neutered since: > > if sys.version_info < (3,): > from past.builtins import basestring > else: > # Avoid importing from past in Python 3 since it utilizes the builtin > # 'imp' module, which is deprecated as of Python 3.4, see > # https://docs.python.org/3/library/imp.html. The 2to3 tool replaces > # basestring with str, so that's what we effectively do here as well: > basestring = str > > My attempt to rebuild lmfit-py in experimental failed for another reason: > > https://buildd.debian.org/status/package.php?p=lmfit-py=experimental Thanks for the hint. I try to seek about a solution for this sphinx issue. > Le mer. 14 févr. 2024 à 12:19, Federico Ceratto a écrit > : > > > I'm a fan of team-maintained packages - I just set the maintainer field to > > DPMT in the git repo. > > Thank you too Thanks to both of you. Its always fun to work together with you Andreas. -- http://fam-tille.de
Bug#1056419: Can we also move uncertainties to DPT (Was: python-hug: autopkgtest failure with Python 3.12)
Hi again Federico, > Am Thu, Feb 08, 2024 at 07:02:09PM +0100 schrieb Federico Ceratto: > > Sure, go ahead, and thank you for taking care of the bug! After you accepted python-hug I wonder whether we can also move python-uncertainties to DPT. I think the usage of past in uncertainties is responsible for bug #1056419 of lmfit-py ... 352s /usr/lib/python3/dist-packages/uncertainties/core.py:22: in 352s from past.builtins import basestring 352s /usr/lib/python3/dist-packages/past/builtins/__init__.py:54: in 352s from past.builtins.misc import (apply, chr, cmp, execfile, intern, oct, 352s /usr/lib/python3/dist-packages/past/builtins/misc.py:45: in 352s from imp import reload I would love if uncertainties would be in DPT and we could do team uploads. Kind regards Andreas. -- http://fam-tille.de
Bug#1063800: Should we restrict libtread-pool to 64bit only
Am Mon, Feb 12, 2024 at 10:09:43PM -0500 schrieb Aaron M. Ucko: > Andreas Tille writes: > > >Build-Depends libthread-pool 4.0.0 which does not build > >for 32bit architectures[1] > > I see a fix in experimental: > > https://buildd.debian.org/status/package.php?p=libthread-pool=experimental > > Why not just reupload it to unstable? Done. Thanks a lot for the reminder Andreas. -- http://fam-tille.de
Bug#1063800: Should we restrict libtread-pool to 64bit only (Was: Bug#1063800: src:pinfish: fails to migrate to testing for too long: not installable on armel, armhf and i386)
Hi, the chain of dependencies for pinfish which creates the problem is pinfish depends racon which in turn can't install its Build-Depends libthread-pool 4.0.0 which does not build for 32bit architectures[1] My suggestion to solve the issue is to explicitly set Architecture: any-amd64 arm64 mips64el ppc64el riscv64 s390x alpha ia64 loong64 ppc64 sparc64 x32 and ask ftpmaster for removing 32bit architectures for libthread-pool, racon and pinfish. Does anybody think we should ask libthread-pool upstream to support 32bit or do we just want to go on to remove 32bit (which also solves time_t bug easily). Kind regards Andreas. [1] https://buildd.debian.org/status/package.php?p=libthread-pool Am Mon, Feb 12, 2024 at 09:35:34PM +0100 schrieb Paul Gevers: > Source: pinfish > Version: 0.1.0+ds-3 > Severity: serious > Control: close -1 0.1.0+ds-4 > Tags: sid trixie > User: release.debian@packages.debian.org > Usertags: out-of-sync > > Dear maintainer(s), > > The Release Team considers packages that are out-of-sync between testing and > unstable for more than 30 days as having a Release Critical bug in testing > [1]. Your package src:pinfish has been trying to migrate for 31 days [2]. > Hence, I am filing this bug. It seem the version in unstable isn't > installable on our 32 bit architectures. It seems like the version in > testing doesn't have binaries on these architectures, while the buildd > history shows they were built for the previous version, so you probably had > them removed. You probably need to do this again, but I suggest to add a > Build-Depends on racon to prevent accidental builds on architectures where > racon isn't available (and thus the package becomes not installable). > > If a package is out of sync between unstable and testing for a longer > period, this usually means that bugs in the package in testing cannot be > fixed via unstable. Additionally, blocked packages can have impact on other > packages, which makes preparing for the release more difficult. Finally, it > often exposes issues with the package and/or > its (reverse-)dependencies. We expect maintainers to fix issues that hamper > the migration of their package in a timely manner. > > This bug will trigger auto-removal when appropriate. As with all new bugs, > there will be at least 30 days before the package is auto-removed. > > I have immediately closed this bug with the version in unstable, so if that > version or a later version migrates, this bug will no longer affect testing. > I have also tagged this bug to only affect sid and trixie, so it doesn't > affect (old-)stable. > > If you believe your package is unable to migrate to testing due to issues > beyond your control, don't hesitate to contact the Release Team. > > Paul > > [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html > [2] https://qa.debian.org/excuses.php?package=pinfish > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de
Bug#1059385: r-cran-ggally: autopkgtest regression
Control: block -1 by 1063785 Control: tags -1 pending Hi, as per upstream the test fails due to the missing Test-Depends r-cran-intergraph. This is uploaded to new (WNPP #1063785) and will be uploaded as soon as it has cleared new. Kind regards Andreas. -- http://fam-tille.de
Bug#1058997: Patch is not sufficient (Was: flask-autoindex is incompatible with Py3.12)
Control: tags -1 - patch Hi Alexandre, I've applied your patch in Git but as you can see in Salsa CI[1] it is not sufficient to fix the build issue. Kind regards and thanks for your help anyway Andreas. [1] https://salsa.debian.org/python-team/packages/flask-autoindex/-/jobs/5272253 -- http://fam-tille.de
Bug#1059666: python-hug: autopkgtest failure with Python 3.12
Hi Federico, Am Thu, Feb 08, 2024 at 07:02:09PM +0100 schrieb Federico Ceratto: > Sure, go ahead, and thank you for taking care of the bug! Done.[1] Please note: I activated build-time testing and non-trivial autopkgtest. This involved some fixes for Python3.11, Python3.12 as well as numpy. I also marked tests accessing network skip. There were two remaining types of test failures I would like you to pay attention or point upstream to. This is documented in debian/README.source[2]. I have the feeling that also python-marshmallow would reside nicely in DPT but since there is no bug in this package I do not see any reason to act right now. Kind regards Andreas. [1] https://tracker.debian.org/news/1502390/accepted-python-hug-260-3-source-into-unstable/ [2] https://salsa.debian.org/python-team/packages/python-hug/-/blob/master/debian/README.source?ref_type=heads -- http://fam-tille.de
Bug#1056227: Fixed Python3.12 issue but astropy issue is pending (Was: aplpy's autopkg tests fail with Python 3.12)
Control: tags -1 pending Hi Ole, I've fixed the distutils issue of Python3.12 in Git but there is an issue pending which you probably can solve way more easier than I: from astropy.config.configuration import ( E ImportError: cannot import name 'update_default_config' from 'astropy.config.configuration' (/usr/lib/python3/dist-packages/astropy/config/configuration.py) (See Salsa CI https://salsa.debian.org/debian-astro-team/aplpy/-/jobs/5270405) Kind regards Andreas. -- http://fam-tille.de
Bug#1059666: python-hug: autopkgtest failure with Python 3.12
Hi Federico, I'd volunteer to fix this bug but my personal policy is to work on team maintained packages only. Would you mind if I move the package to Debian Python Team? Kind regards Andreas. -- http://fam-tille.de
Bug#1059642: [AmanoTeam/duckpy] Example stopped working (Issue #15)
Hi Alisson, Am Thu, Feb 08, 2024 at 07:12:35AM -0800 schrieb Alisson L.: > Hello, and thanks for reaching out. An empty results list usually means that > DuckDuckGo has blocked your IP. I have just tried here with my home IP, and > it worked fine: Argh, what might be the reason for blocking on one hand Debian infrastructure from where the first test was run as well as my own private IP? > Either way, an error should be raised if your IP is blocked, rather than just > blindly returning an empty list (which is also the behaviour for not found > queries). This project was made in a very rudimentary way, so there's a lot > of room for improvements. Does it mean a lot of work for you to implement the distinction between a block and not found queries. We could probably sensibly close the Debian bug report by drafting a more senible CI test using this feature. Kind regards, Andreas.
Bug#1059642: python-duckpy: autopkgtest failure with Python 3.12
Control: retitle -1 python-duckpy: autopkgtest failure Control: tags -1 upstream Control: forwarded -1 https://github.com/AmanoTeam/duckpy/issues/15 Hi, the problem does not only exists for Python3.12. Thus I changed the bug title and reported the issue upstream. Kind regards Andreas. -- http://fam-tille.de
Bug#1058336: Team-maintenance of visidata in Debian Science team (Was: visidata: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13)
Hi Anja, when analysing Python3.12 bugs like this I stumbled upon visidata. While I have no idea for a fix my first attempt would be to update to the latest upstream version and see whether the bug might be fixed. I would love to help out (with such an upgrade or sponsoring the package.) However, my personal policy is to touch team maintained packages only. In the case of visidata I'd suggest Debian Science team (list in CC). Just let us know what you think. If you agree I would volunteer to move the Git archive to science-team and sponsor an upload. Kind regards Andreas. -- http://fam-tille.de
Bug#1063431: src:r-cran-future.apply: fails to migrate to testing for too long: autopkgtest failure
Control: tags -1 upstream Control: forwarded -1 https://github.com/HenrikBengtsson/future.apply/issues/120 Hi Paul, thanks a lot for all your work. I have forwarded the problem upstream. Kind regards Andreas. -- http://fam-tille.de
Bug#1058364: python-etcd: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Control: tags -1 pending
Hi,
I've fixed the issue reported in the bug in Git. However, Salsa CI
shows another issue[1]:
if _is_instance_mock(spec):
> raise InvalidSpecError(f'Cannot spec a Mock object.
> [object={spec!r}]')
E mock.mock.InvalidSpecError: Cannot spec a Mock object.
[object=]
/usr/lib/python3/dist-packages/mock/mock.py:537: InvalidSpecError
Any idea how to fix this?
Kind regards
Andreas.
[1] https://salsa.debian.org/python-team/packages/python-etcd/-/jobs/5265383
--
http://fam-tille.de
Bug#1056442: What about upgrading to latest upstream (Was: pyrlp's autopkg tests fail with Python 3.12)
Hi Ben, I'd volunteer to upgrade pyrlp to its latest upstream version (4.0.0) if the package can be moved to DPT. Please note: I have not yet checked the latest upstream version - I'm just hunting for "any" Python3.12 related bug and see what I can do if packages are team maintained. Kind regards Andreas. PS: sorry about the confusion I've caused in my previous mails with wrong package name. -- http://fam-tille.de
Bug#1044079: [Help] augur: FTBFS with pandas 2.0
Control: tags -1 help Hi Rebecca, Étienne has forwarded the issue long ago but it seems upstream does not want to move to Pandas 2.x[1] and simply closed the issue. Since I do not see any good reason that we maintain two versions of Pandas I need to ask for some help in this issue. Kind regards Andreas. [1] https://github.com/nextstrain/augur/issues/1303 -- http://fam-tille.de
Bug#1062427: ghmm: NMU diff for 64-bit time_t transition
Hi Lukas, Am Thu, Feb 01, 2024 at 11:27:43AM +0100 schrieb Lukas Märdian: > please note that ghmm seems to FTBFS for a reason unrelated to this NMU: > > dh_install > dh_install: warning: Cannot find (any matches for) > "usr/lib/python3*/site-packages/*" (tried in ., debian/tmp) > > dh_install: warning: ghmm missing files: usr/lib/python3*/site-packages/* > dh_install: error: missing files, aborting > make[1]: *** [debian/rules:15: override_dh_install] Error 255 > make[1]: Leaving directory '/home/slyon/time_t/ghmm-0.9~rc3' > make: *** [debian/rules:9: binary] Error 2 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 > > > The python files seem to be generated in wrong directory (see tree below). The uploaded package was lagging quite behind packaging in Git. Since I was able to upload a fixed package to unstable today I applied all your changes in another upload to experimental which I "sponsored" for you as ghmm_0.9~rc3-5.1~exp. Hope this contributes a bit to all your huge work for the time_t transition. Kind regards and thanks a lot for your work Andreas. PS: In case you notice in tracker.debian.org that "version in VCS is newer than in repository, is it time to upload?" is set it might be useful to contact the maintainers of the package. -- http://fam-tille.de
Bug#1044055: Reopen
Control: reopen -1 The issue is not closed by latest upload -- http://fam-tille.de
Bug#1044068: q2templates: FTBFS with pandas 2.0
Hi Rebecca, I've checked several Debian Med packages for your assumption that replacing pandas.util.testing might help but non of the candidates I've checked was caused by this. I'm rather seeing quite strange errors like in the case of q2templates here in Salsa CI https://salsa.debian.org/med-team/q2templates/-/jobs/5247852 Do you have any hint how to fix this? Kind regards Andreas. -- http://fam-tille.de
Bug#1044073: Sorry Re: python-altair and pandas 2.0
Am Sat, Feb 03, 2024 at 10:51:05PM + schrieb Rebecca N. Palmer: > > I think we should strive for latest upstream in > > general > > Agreed, assuming that doing so doesn't break things. I picked an upstream version which is compatible with pandas 2.x but does not need any not yet packaged module. Kind regards Andreas. -- http://fam-tille.de
Bug#1044071: Bug#1043240: transition: pandas 1.5 -> 2.1 - please upload fixes
Hi again, Am Fri, Feb 02, 2024 at 09:56:14PM +0100 schrieb Andreas Tille: > Hi Rebecca, > > Am Tue, Jan 30, 2024 at 08:05:35AM + schrieb Rebecca N. Palmer: > > 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 > > Was uploaded, all bugs closed. > > > python-altair > > I tried hard to get the latest version which implements what you suggested > independently in the bug report. Unfortunately it needs a new dependency > as I wrote in my comment in the bug report[2] and I was not able to easily > exclude the test that fails due to the missing module. Maybe I'd rather revert to the version currently in Debian. I might check later if nobody will beat me. > > python-feather-format I've followed the hint given by Rebecca. Unfortunately there are new Cython issues as you can see in Salsa CI[1]. Any hint would be welcome. > > seaborn Discussed in other mails > > tqdm > > I try to check later. Kind regards Andreas. [1] https://salsa.debian.org/python-team/packages/python-feather-format/-/jobs/5246082 -- http://fam-tille.de
Bug#1044073: python-altair and pandas 2.0
Hi Rebecca, Am Sat, Feb 03, 2024 at 09:32:32PM + schrieb Rebecca N. Palmer: > Please don't skip/xfail tests - my suggestion above is an actual fix: > > https://salsa.debian.org/rnpalmer-guest/python-altair/-/tree/fix1044073?ref_type=heads > > (In a fork because, despite its description, this is not actually a > debian-science package. The Salsa CI "fail" is because the *old* version is > uninstallable due to Breaks: in pandas and the piuparts upgrade test counts > this as a fail.) The point I was making in my mail was that I had trouble running the tests in **latest** upstream version (5.2.0). I did not test your suggested patch since I think we should strive for latest upstream in general and this is a good chance to do so ... except if we might be in a hurry to catch up with Pandas 2.x and there is no quick chance to sort out the remaining python-altair issue.[1] Kind regards Andreas. [1] https://salsa.debian.org/python-team/packages/python-altair/-/jobs/5240584 -- http://fam-tille.de
Bug#1044076: influxdb-python and pandas 2.1
Hi Rebecca, Am Sat, Feb 03, 2024 at 12:32:07PM + schrieb Rebecca N. Palmer: > My fixes are pushed to Salsa, but they're in a fork because this isn't a > debian-science package: > https://salsa.debian.org/rnpalmer-guest/influxdb-python Argh, I missed that link inside the bug report and duplicated parts of your work. To be sure this is not happening it would be helpful if you would create a MR from your repository. Alternatively you become a member of the Python team. Thanks a lot for all your work on Pandas - I've uploaded it as a DPT team upload. Kind regards, Andreas. -- http://fam-tille.de
Bug#1044073: python-altair: FTBFS with pandas 2.0
Short notice while traveling. I tried @pytest.skip which failed since it seems even from altair.jupyter.jupyter_chart import ( IntervalSelection, IndexSelection, PointSelection, ) is a problem. WHen uncommenting this even more errors arrise. Sorry for my brevity Andreas. Am Fri, Feb 02, 2024 at 04:05:43PM -0500 schrieb Sandro Tosi: > > which is not packaged yet. I had no luck to skip the according test which > > fails in build time test[2]. > > what did you try that failed to skip that test? this seems a > straightforward case where --ignore and/or -k "not " should be > enough. > > please be more explicit when you ask for error and report what > attempts you made tht didnt work, so others will try other ways > without repeating previous unsuccessful ones > > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi > -- http://fam-tille.de
Bug#1044073: python-altair: FTBFS with pandas 2.0
Hi, I tried to upgrade python-altair in Git to the latest upstream version which should work with Pandas 2.0. Unfortunately it has a new dependency[1] which is not packaged yet. I had no luck to skip the according test which fails in build time test[2]. Kind regards Andreas. [1] https://pypi.org/project/anywidget/ [2] https://salsa.debian.org/python-team/packages/python-altair/-/jobs/5240584 -- http://fam-tille.de
Bug#1044076: influxdb-python: FTBFS with pandas 2.0
Hi Rebecca, I followed your hint "replacing all 3 instances of pandas.util.testing with pandas.testing" [1] but as you can see in Salsa CI there are remaining issues[2]. The Python3.12 issues should be fixed meanwhile in version 5.3.1-5. Any further hints / patches (preferably pushed to Salsa) would be nice. Kind regards Andreas. [1] https://salsa.debian.org/python-team/packages/influxdb-python/-/blob/master/debian/patches/pandas2.0.patch?ref_type=heads [2] https://salsa.debian.org/python-team/packages/influxdb-python/-/jobs/5239463 -- http://fam-tille.de
Bug#1061344: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)
Hi again, I've filed bug #1062371 RM: emboss [armel armhf i386 hppa m68k powerpc sh4] -- ROM; No support of 32 bit architectures any more Kind regards Andreas. Am Wed, Jan 31, 2024 at 07:53:26AM +0100 schrieb Andreas Tille: > Hi again, > > besides my suggested solution to split up emboss-lib again (and when > doing so make the package emboss-lib a metapackage depending from single > packages to match all its rdepends) I wonder whether we should provide > EMBOSS for 64 bit architectures only. While we probably need to file a > lot of removal requests to 32 bit packages of its rdepends it somehow > fits the reality that these days nobody seriously runs emboss on 32bit > architectures. As explained in the according wiki page[1] other binary > distros are dropping 32-bit at all and Debian rather cares for > automotive, IOT, TVs, routers, plant control, building > monitoring/control, cheap Android phones - nothing that is using EMBOSS. > > I would really like to get some input from *our users* here on the > Debian Med list since I need your response to draw a sensible decision. > > Kind regards > Andreas. > > [1] https://wiki.debian.org/ReleaseGoals/64bit-time > > Am Fri, Jan 26, 2024 at 10:44:09AM +0100 schrieb Andreas Tille: > > Hi Charles, > > > > I wonder how we can properly solve this bug. In the early stage of > > Emboss packaging obviously the packages > > > >libajax6, > >libajax6-dev, > >libnucleus6, > >libnucleus6-dev > > > > existed (thus the remaining Conflicts/Replaces on emboss-lib which can > > probably be removed right now). I wonder whether we should restore those > > single library package per shared library + devel package, merge > > static+shared library in one package or even merge > > > >libacd 6 emboss-lib (>= 6.6.0+dfsg) > >libajax 6 emboss-lib (>= 6.6.0+dfsg) > >libajaxdb 6 emboss-lib (>= 6.6.0+dfsg) > >libajaxg 6 emboss-lib (>= 6.6.0+dfsg) > >libensembl 6 emboss-lib (>= 6.6.0+dfsg) > >libnucleus 6 emboss-lib (>= 6.6.0+dfsg) > > > > in libemboss6 > > > >libepcre 7 emboss-lib (>= 6.6.0+dfsg) > > > > in libemboss-pcre7 (ugly since its a code copy of pcre3 but well, > > that's another battle field) and > > > >libeplplot 3 emboss-lib (>= 6.6.0+dfsg) > > > > in libemboss-plplot3 to express the proper sonames inside the library > > package names. Any more sensible suggestion is pretty welcome. > > > > Kind regards > > Andreas. > > > > -- > > http://fam-tille.de > > -- > http://fam-tille.de > > -- http://fam-tille.de
Bug#1058454: Do we really need to support 32bit in abinit and prody (maybe others)
Hi, in connection with the time_t transition in Debian Med we are discussing[1] whether we really need 32 bit support for some of our tools or whether we should realistically drop this support to concentrate on problems which are more relevant for our users. I wonder whether we could also consider abinit and prody candidates for droping 32 bit support and by doing so closing these two RC bugs. Kind regards Andreas. [1] https://lists.debian.org/debian-med/2024/01/msg00021.html -- http://fam-tille.de
Bug#1061344: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)
Hi again, besides my suggested solution to split up emboss-lib again (and when doing so make the package emboss-lib a metapackage depending from single packages to match all its rdepends) I wonder whether we should provide EMBOSS for 64 bit architectures only. While we probably need to file a lot of removal requests to 32 bit packages of its rdepends it somehow fits the reality that these days nobody seriously runs emboss on 32bit architectures. As explained in the according wiki page[1] other binary distros are dropping 32-bit at all and Debian rather cares for automotive, IOT, TVs, routers, plant control, building monitoring/control, cheap Android phones - nothing that is using EMBOSS. I would really like to get some input from *our users* here on the Debian Med list since I need your response to draw a sensible decision. Kind regards Andreas. [1] https://wiki.debian.org/ReleaseGoals/64bit-time Am Fri, Jan 26, 2024 at 10:44:09AM +0100 schrieb Andreas Tille: > Hi Charles, > > I wonder how we can properly solve this bug. In the early stage of > Emboss packaging obviously the packages > >libajax6, >libajax6-dev, >libnucleus6, >libnucleus6-dev > > existed (thus the remaining Conflicts/Replaces on emboss-lib which can > probably be removed right now). I wonder whether we should restore those > single library package per shared library + devel package, merge > static+shared library in one package or even merge > >libacd 6 emboss-lib (>= 6.6.0+dfsg) >libajax 6 emboss-lib (>= 6.6.0+dfsg) >libajaxdb 6 emboss-lib (>= 6.6.0+dfsg) >libajaxg 6 emboss-lib (>= 6.6.0+dfsg) >libensembl 6 emboss-lib (>= 6.6.0+dfsg) >libnucleus 6 emboss-lib (>= 6.6.0+dfsg) > > in libemboss6 > >libepcre 7 emboss-lib (>= 6.6.0+dfsg) > > in libemboss-pcre7 (ugly since its a code copy of pcre3 but well, > that's another battle field) and > >libeplplot 3 emboss-lib (>= 6.6.0+dfsg) > > in libemboss-plplot3 to express the proper sonames inside the library > package names. Any more sensible suggestion is pretty welcome. > > Kind regards > Andreas. > > -- > http://fam-tille.de -- http://fam-tille.de
Bug#1060965: q2cli: AttributeError: module 'bibtexparser' has no attribute 'bparser'
Control: tags -1 - upstream Control: tags -1 pending The issue was resolved by downgrading bibtexparser to the latest stable upstream release (the formerly uploaded beta caused the problem). Unfortunately there is a new issue in the new version of q2cli which fails to build due to test suite errors, which can be seen in Salsa CI https://salsa.debian.org/med-team/q2cli/-/jobs/5223461 Kind regards Andreas. -- http://fam-tille.de
Bug#1061931: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#1061931: fixed in biosquid 1.9g+cvs20050121-14)
Control: tags -1 pending Hi Steve, I reverted the change in unstable and pushed the change for experimental to Git. Do you want me to upload this change to experimental or should I keep on waiting? Sorry for the noise again Andreas. Am Tue, Jan 30, 2024 at 11:34:07AM +0100 schrieb Andreas Tille: > Hi Steve, > > I just realised that I've set the wrong distribution. I'll revert > and will upload the requested change to experimental. Sorry for the > noise > > Andreas. > > Am Tue, Jan 30, 2024 at 12:52:18AM -0800 schrieb Steve Langasek: > > Um, please revert this change. This was to be an NMU targeted at > > *experimental*. The dpkg in unstable does not yet set the compiler defaults > > to provide 64-bit time_t; so packages built as part of this upload will now > > have the wrong ABI, in the opposite direction. -- http://fam-tille.de
Bug#1061931: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#1061931: fixed in biosquid 1.9g+cvs20050121-14)
Hi Steve, I just realised that I've set the wrong distribution. I'll revert and will upload the requested change to experimental. Sorry for the noise Andreas. Am Tue, Jan 30, 2024 at 12:52:18AM -0800 schrieb Steve Langasek: > Um, please revert this change. This was to be an NMU targeted at > *experimental*. The dpkg in unstable does not yet set the compiler defaults > to provide 64-bit time_t; so packages built as part of this upload will now > have the wrong ABI, in the opposite direction. > > On Tue, Jan 30, 2024 at 08:36:05AM +, Debian Bug Tracking System wrote: > > This is an automatic notification regarding your Bug report > > which was filed against the src:biosquid package: > > > > #1061931: biosquid: NMU diff for 64-bit time_t transition > > > > It has been closed by Debian FTP Masters > > (reply to Andreas Tille ). > > > > Their explanation is attached below along with your original report. > > If this explanation is unsatisfactory and you have not received a > > better one in a separate message then please contact Debian FTP Masters > > (reply to Andreas Tille > > ) by > > replying to this email. > > > > > > -- > > 1061931: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061931 > > Debian Bug Tracking System > > Contact ow...@bugs.debian.org with problems > > > Date: Tue, 30 Jan 2024 08:34:14 + > > From: Debian FTP Masters > > To: 1061931-cl...@bugs.debian.org > > Subject: Bug#1061931: fixed in biosquid 1.9g+cvs20050121-14 > > > > Source: biosquid > > Source-Version: 1.9g+cvs20050121-14 > > Done: Andreas Tille > > > > We believe that the bug you reported is fixed in the latest version of > > biosquid, which is due to be installed in the Debian FTP archive. > > > > A summary of the changes between this version and the previous one is > > attached. > > > > Thank you for reporting the bug, which will now be closed. If you > > have further comments please address them to 1061...@bugs.debian.org, > > and the maintainer will reopen the bug report if appropriate. > > > > Debian distribution maintenance software > > pp. > > Andreas Tille (supplier of updated biosquid package) > > > > (This message was generated automatically at their request; if you > > believe that there is a problem with it please contact the archive > > administrators by mailing ftpmas...@ftp-master.debian.org) > > > > > > -----BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Format: 1.8 > > Date: Tue, 30 Jan 2024 08:30:22 +0100 > > Source: biosquid > > Architecture: source > > Version: 1.9g+cvs20050121-14 > > Distribution: unstable > > Urgency: medium > > Maintainer: Debian-Med Packaging Team > > > > Changed-By: Andreas Tille > > Closes: 1061931 > > Changes: > > biosquid (1.9g+cvs20050121-14) unstable; urgency=medium > > . > >[ Steve Langasek ] > >* Rename libraries for 64-bit time_t transition. > > Closes: #1061931 > > . > >[ Andreas Tille ] > >* Versioned Build-Depends: d-shlibs (>= 0.106) to support --t64 option > >* Add --t64 option to d-shlibmove > >* d-slibs checks for Conflicts: libsquid1 (rather than Breaks) > > Checksums-Sha1: > > 3a2569dfe87eeedba8862eb718ae5ce5fc8e3bb3 2212 > > biosquid_1.9g+cvs20050121-14.dsc > > f5cb92edd34b55931bbc80b400f9a8c859a412c4 14616 > > biosquid_1.9g+cvs20050121-14.debian.tar.xz > > feb8b397a79e7b8a5946c0408e602ba0a1345d85 8202 > > biosquid_1.9g+cvs20050121-14_amd64.buildinfo > > Checksums-Sha256: > > ff9a7bd190b048f461172d47c07c911343a9c7c6e5da2a958c000dd11bda236a 2212 > > biosquid_1.9g+cvs20050121-14.dsc > > db46e17e4e3479b3f63b78dc0daffb93cb662e1260d5e279c5cd25970bda0a54 14616 > > biosquid_1.9g+cvs20050121-14.debian.tar.xz > > bca9051273e9750a94e410e72853edc45365706a746fdf3c3dd15679b17dd017 8202 > > biosquid_1.9g+cvs20050121-14_amd64.buildinfo > > Files: > > 882295af2c26fa062142a8a7a6876f44 2212 science optional > > biosquid_1.9g+cvs20050121-14.dsc > > bf472ff3a7362ef78b15ed6e4933eaf1 14616 science optional > > biosquid_1.9g+cvs20050121-14.debian.tar.xz > > 90be71357f77dd0d1159f10cbf0e2ff7 8202 science optional > > biosquid_1.9g+cvs20050121-14_amd64.buildinfo > > > > -BEGIN PGP SIGNATURE- > > > > iQJFBAEBCgAvFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmW4qekRHHRpbGxlQGRl > > Ymlhbi5vcmcACgkQV4oElNHGRtFEgA/+O4GrUvw8IEnl7b1nxPvmI+VnQhSX+u0k > > kFdUZKVU/bgcRR
Bug#1044055: Reopen
Control: reopen -1 I wrongly assumed that this issue has vanished. Thus reopening the bug. -- http://fam-tille.de
Bug#1052826: Broken entrypoints package: actually a pybuild issue?
Am Sun, Jan 28, 2024 at 08:13:01PM +0100 schrieb julien.pu...@gmail.com: > > > > upstream page[1] says: > > > > This package is in maintenance-only mode. New code should use the > > importlib.metadata module in the Python standard library to find > > and load entry points. > > > > So it seems we do not need adapt you patch very frequently since > > no changes will be to be expected (but the dependencies of entrypoint > > should be adapted. > > Doesn't that mean that we should strive to RM entrypoints? I'm fine with this but we need to fix the rdepends first. Kind regards Andreas. -- http://fam-tille.de
Bug#1052866: python-plaster: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Hi, I upgraded python-plaster to latest upstream - but this did not changed the test suite error. Kind regards Andreas. -- http://fam-tille.de
Bug#1052826: Broken entrypoints package: actually a pybuild issue?
Hi Jullien, upstream page[1] says: This package is in maintenance-only mode. New code should use the importlib.metadata module in the Python standard library to find and load entry points. So it seems we do not need adapt you patch very frequently since no changes will be to be expected (but the dependencies of entrypoint should be adapted. Kind regards Andreas. [1] https://github.com/takluyver/entrypoints -- http://fam-tille.de
Bug#1042325: python-miio: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Control: tags -1 help Hi, I upgraded python-miio in Git. Unfortunately there are some test suite errors[1] Any help would be welcome Andreas. [1] https://salsa.debian.org/python-team/packages/miio/-/jobs/5212674 -- http://fam-tille.de
Bug#1042620: New upstream version of flufl.i18n fails its test
Hi, I checked some random DPT packages and had a look into flufl.i18n. Unfortunately the new upstream version fails its test as you can see in Salsa CI[1]. Any help is welcome Andreas. [1] https://salsa.debian.org/python-team/packages/flufl.i18n/-/jobs/5148646 -- http://fam-tille.de
Bug#1056852: python-cassandra-driver: ftbfs with cython 3.0.x
Control: tags -1 help Control: tags -1 moreinfo Hi, I tried building the current status in Git and realised that the suggested patch is not sufficient. I decided to relax the versioned dependency from cython[1] which at least let the configure and build step pass. Unfortunately the cython3-legacy build dependency led to 5 errors and thus I tried cython3 instead which only leads to 2 errrors which you can hopefully reproduce in a couple of minutes in Salsa CI[2] (I'm going AFK instantly so can not check any more). May be it is appropriate to skip those two tests? I'll leave this decision to you since I do not know this package sufficiently enough. Hope this helps Andreas. [1] https://salsa.debian.org/python-team/packages/python-cassandra-driver/-/blob/debian/master/debian/patches/0006-relax_vesioned_cython_dependency.patch?ref_type=heads [2] https://salsa.debian.org/python-team/packages/python-cassandra-driver/-/pipelines/631074 -- http://fam-tille.de
Bug#1061344: emboss-lib: identified for time_t transition but no ABI in shlibs
Hi Charles, I wonder how we can properly solve this bug. In the early stage of Emboss packaging obviously the packages libajax6, libajax6-dev, libnucleus6, libnucleus6-dev existed (thus the remaining Conflicts/Replaces on emboss-lib which can probably be removed right now). I wonder whether we should restore those single library package per shared library + devel package, merge static+shared library in one package or even merge libacd 6 emboss-lib (>= 6.6.0+dfsg) libajax 6 emboss-lib (>= 6.6.0+dfsg) libajaxdb 6 emboss-lib (>= 6.6.0+dfsg) libajaxg 6 emboss-lib (>= 6.6.0+dfsg) libensembl 6 emboss-lib (>= 6.6.0+dfsg) libnucleus 6 emboss-lib (>= 6.6.0+dfsg) in libemboss6 libepcre 7 emboss-lib (>= 6.6.0+dfsg) in libemboss-pcre7 (ugly since its a code copy of pcre3 but well, that's another battle field) and libeplplot 3 emboss-lib (>= 6.6.0+dfsg) in libemboss-plplot3 to express the proper sonames inside the library package names. Any more sensible suggestion is pretty welcome. Kind regards Andreas. -- http://fam-tille.de
Bug#1056813: Just adding a blocker for a new upload as upstream tag
Control: tags -1 upstream Control: forwarded -1 https://github.com/macs3-project/MACS/issues/615 This is no issue about the topic of this bug report (cython) but rather an issue opened upstream to solve the problem which prevents us uploading latest macs3. Kind regards Andreas. -- http://fam-tille.de
Bug#1060965: Problem is caused by upgrade of python3-bibtexparser to 2.0.0b5 - issue filed upstream
Control: tags -1 upstream Control: forwarded -1 https://github.com/sciunto-org/python-bibtexparser/issues/451 It turns out that bibtexparser has changed its API. I asked for some documentation about this change to find a proper patch. -- http://fam-tille.de
Bug#1060973: Reduce severity since it is not reproducible
Control: severity -1 important
Bug#1027203: RFH: qiskit-terra
Hi, since qiskit-terra has two RC bugs (#1027203 and #1056878 in CC) and nobody who has expressed any help with this package I wonder whether we can keep this package in Debian. I had a look in later upstream versions but even in 0.13.0 there is a not yet packaged dependency retworkx[1] which seems to become not used in lates upstream any more but this becomes quite rust-dependant. So tags later than 0.19.2 need Rust crates.io-index[2] and I personally do not have any experience with packaging rust. Given that we have no real capacity to catch up with upstream sensibly I wonder whether it makes sense to keep this package inside Debian. I have not analysed the upstream status of qiskit-aer. If it will require similar new dependencies I wonder whether we should remove both packages. While it seems to be not very hard to fix the RC bugs in both packages it does not make much sense to fix very outdated software. What do you think? Kind regards Andreas. [1] https://pypi.org/project/retworkx/ [2] https://github.com/rust-lang/crates.io-index -- http://fam-tille.de
Bug#1061233: src:nitime: fails to migrate to testing for too long: autopkgtest regression on 32 bits systems
Control: tags -1 upstream Control: forwarded -1 https://github.com/nipy/nitime/issues/214
Bug#1054748: [Help] Re: mlpy ftbfs with Python 3.12
Control: tags 1056819 pending Control: tags -1 help Hi, after applying the patch for the cython3 issue the build issues of this package are remaining. This is strange since the missing modules are provided inside the package. I wonder what trick I might need to do to convince the Python3 interpreter to seek for the modules recursively which was obviously working until some point of time when the package was building formerly. Any help would be welcome Andreas. -- http://fam-tille.de
Bug#1056841: pymatgen: ftbfs with cython 3.0.x
Am Fri, Jan 19, 2024 at 08:22:21PM +0100 schrieb Drew Parsons: > On 2024-01-19 18:52, Drew Parsons wrote: > > > > Hi Andreas, could you push your upstream and pristine-tar branches? > > Otherwise we can't use your 2023.12.18 branch. > > I see what you mean. The tag is there, the orig tarball can be regenerated > with > gbp export-orig. Good to know that you can work what is on Salsa - I have removed my local clone. Good luck Andreas. -- http://fam-tille.de
Bug#1056841: pymatgen: ftbfs with cython 3.0.x
Control: tags -1 pending Hi, I've applied the patch in Git and also tried to upgrade to latest upstream since there is a chance that other Python3.12 issues might be fixed. Unfortunately the upgrade is all but straightforward and I gave up finally over the changes in the sphinx documention where finally some files are missing. I've created a branch 2023.12.18 which fails with Sphinx error: root file /build/pymatgen-2023.12.18+dfsg1/docs/apidoc/index.rst not found I hope that my preliminary work might be helpful for the package but I have to give up now due to time constraints. Hope this helps Andreas. -- http://fam-tille.de
Bug#1056484: python-molotov's autopkg tests fail with Python 3.12
Control: tags -1 upstream Control: forwarded -1 https://github.com/tarekziade/molotov/issues/164 -- http://fam-tille.de
Bug#1057393: FTBFS: object has no attribute 'assertNotEquals'. Did you mean: 'assertNotEqual'
Control: tags -1 upstream Control: forwarded -1 https://github.com/Azure/azure-cli/issues/28194 Control: retitle -1 FTBFS: object has no attribute 'assertDictContainsSubset' Hi, while I was able to fix the object has no attribute 'assertNotEquals'. Did you mean: 'assertNotEqual' issue in Git I consider it is better if upstream has a look at the object has no attribute 'assertDictContainsSubset' which is described as Undocumented and broken TestCase method assertDictContainsSubset (deprecated in Python 3.2). in the Python3.12 doc[1]. It might make sense to skip those tests to enable the Python3.12 migration but I'll leave this to the main Uploader. Kind regards Andreas. [1] https://docs.python.org/3/whatsnew/3.12.html#unittest -- http://fam-tille.de
Bug#1055847: python-sparse's autopkg tests fail with Python 3.12
Hi Nilesh, Am Sat, Jan 13, 2024 at 04:15:07PM +0530 schrieb Nilesh Patra: > Fixed in Git, please check. Thanks a lot. I'll wait for debci whether bug #1055847 persists. I wonder whether we could close simply #1058485 since the test is passing with current numba. Kind regards Andreas. -- http://fam-tille.de
Bug#1056504: python-sparse's autopkg tests fail with Python 3.12
Hi, thanks to Rebecca's hint I've updated python-sparse in Git to the latest upstream version. I decided to deactivate all patches. When trying to build I'm running into several errors: ModuleNotFoundError: No module named 'sparse._version' [1] This is surely due to the removal of versioneer in upstream commit 6fca42bc1cd0acea2153b074658b834231a4d00f - but I can't imaginge upstream simply left the according responsible line sparse/__init__.py:from ._version import __version__, __version_tuple__ # noqa: F401 and did not noticed that tests are failing. Am I missing something? Kind regards Andreass. [1] ModuleNotFoundError: No module named 'sparse._version' -- http://fam-tille.de
Bug#1042590: [Pending] django-session-security: FTBFS with Sphinx 7.1, docutils 0.20: error: invalid command 'build_sphinx'
Control: tags -1 pending Hi, I've fixed this problem in Git[1] but did not uploaded since autopkgtest is failing in Salsa CI[2]. Kind regards Andreas. [1] https://salsa.debian.org/python-team/packages/django-session-security/-/commit/af1ebc734a33cf1b629a2626bad508b833eb2706 [2] https://salsa.debian.org/python-team/packages/django-session-security/-/jobs/5150104 -- http://fam-tille.de
Bug#1056423: [Help] Started to replace future but failed
Am Fri, Jan 12, 2024 at 11:45:02AM +0100 schrieb Alexandre Detiste: > > -class ExtensionNode(with_metaclass(ExtensionNodeMetaclass, object)): > +class ExtensionNode(metaclass=ExtensionNodeMetaclass, object_=True): > > Just simply > +class ExtensionNode(metaclass=ExtensionNodeMetaclass): > , but I can't test here: This helped a bit further. Unfortunately we have *lots* of instances of from past.utils import old_div with several instances of old_div inside the code. Do you know some automated tool to fix this? Replacing all these seems pretty error prone. Kind regards Andreas. -- http://fam-tille.de
