Bug#1055847: Please check python-sparse issue at Github

On Wed, 2024-04-24 at 15:53 +0200, Andreas Tille wrote: > 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 > >   

Bug#1067504: python3-numba: Can not be installed.

On Fri, 2024-03-22 at 15:58 +, Elizabeth Loss-Cutler-Hull wrote: > Package: python3-numba > Version: 0.59.0+dfsg-1 > Severity: serious > > In Debian sid, python3-numba currently depends on python3-numpy (< > 1:1.25) and python3-numpy (>= 1:1.22.0). > > However the currently available version

Bug#1059630: fix build with Python 3.12

On Mon, 2024-01-01 at 11:22 +0100, Matthias Klose wrote: > Control: tags -1 + patch > > patch at > http://launchpadlibrarian.net/706939750/python-sparse_0.14.0-1_0.14.0-1ubuntu1.diff.gz > I think a better solution to the versioneer fail to build is to remove the embedded versioneer and use the

Bug#1058178: marked as pending in partd

Control: tag -1 pending Hello, Bug #1058178 in partd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at:

Bug#1058391: marked as pending in heapdict

Control: tag -1 pending Hello, Bug #1058391 in heapdict reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at:

Bug#1050526: marked as pending in dask

Control: tag -1 pending Hello, Bug #1050526 in dask reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at:

Bug#1050526: dask: autopkgtest regression on s390x

Hi, I'm kind of shocked I think I found a fix. I looked a little bit, and it seems like the random number generator behaves differently between s390x and x86 Eventually the test calls dask.util.random_state_data(1, 42) on x86 it starts with this on two different machines: In [9]:

Bug#1033907: numba crashes on non-x86

On Sat, 2023-08-19 at 18:21 +0100, Rebecca N. Palmer wrote: > numba also crashes on mips64el, mipsel and armhf (and s390x but that > was > already known; not amd64, i386 or ppc64el).  However, I agree that > arm64 > is a good place to start trying to fix this, given how common it is. > Also

Bug#1033907: numba: autopkgtest regression: segmentation fault on arm64

:29 -0700 Diane Trout wrote: > > Unfortunately it also wants llvmlite 0.40.0. > > Could you please be more verbose about this "unfortunately"? > > > It'd probably be easier to get upstream to help with debugging 0.57 > > I fully agree that we should target a

Bug#1040411: cloudpickle: implicitly depends on python3-py

Thanks for the heads up. It should be fixed now On Wed, 2023-07-05 at 18:33 +0200, Timo Röhling wrote: > Source: cloudpickle > Version: 2.2.0-1 > Severity: serious > > Dear maintainer, > > your package implicitly depends on python3-py for its autopkgtest, > which used > to be provided by

Bug#1040411: marked as pending in cloudpickle

Control: tag -1 pending Hello, Bug #1040411 in cloudpickle reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at:

Bug#1033907: numba: autopkgtest regression: segmentation fault on arm64

I'm not really sure what to do about it. I looked some and there are a variety of different types of segfaults triggered by numba on arm64. I wasn't able to find any particular patterns. I have most of the patches they initially recommended but upstream has moved on to released 0.57.0 which

Bug#1009261: bug 1009261 is forwarded to https://bugs.webkit.org/show_bug.cgi?id=202363

On Sat, 2023-02-11 at 22:03 +0200, Adrian Bunk wrote: > On Sat, Feb 11, 2023 at 11:46:56AM -0800, Diane Trout wrote: > > forwarded 1009261 https://bugs.webkit.org/show_bug.cgi?id=202363 > > thanks > > If this was the problem, then this bug is a duplicate of #986218 that >

Bug#1009261: closing 1009261

close 1009261 3.46.3-1 thanks I forgot to specify which evolution version I tested works. It may have been fixed a bit earlier than 3.46.3, but it looks like the full fix was somewhere around 3.4x. Diane

Bug#1009261: Evolution bwrap problem - may fail to print or hang in startup

On Sun, 01 May 2022 14:41:26 +0200 Domenico Cufalo wrote: > Dear developers, > > I have the same issue in my machine (Debian Bullseye Stable with Gnome > 3.38): Evolution doesn't start at all. > I also had this problem, but it went away on systems running testing or bookworm.

Bug#1030096: dask.distributed intermittent autopkgtest fail

> > That presumably means 5 days, which we don't have, i.e. *don't* > unless > release team tell you otherwise. For what it's worth this is our answer from #debian-release elbrus detrout: I'll handle dask.distributed detrout elbrus, Thank you. sorry about needing to ask for an exception

Bug#1030096: dask.distributed intermittent autopkgtest fail

> > That might be true on amd64, but I don't think it's true of > arm*/s390x: > the tests that are failing there do *not* appear to be isinstalled > tests. > > I suspect the tests wouldn't have worked on those architectures in > 2022.02 either, and we didn't notice because the previously

Bug#1030096: dask.distributed intermittent autopkgtest fail

On Fri, 2023-02-10 at 08:44 +0530, Nilesh Patra wrote: > Control: fixed -1 2022.12.1+ds.1-2 > > Some tests passed after I put it for (multiple) retries. The > current state looks fine > > https://qa.debian.org/excuses.php?package=dask.distributed > > But I am not sure if this counter

Bug#1030096: dask.distributed intermittent autopkgtest fail

On Thu, 2023-02-09 at 21:21 +, Rebecca N. Palmer wrote: > > > On 09/02/2023 17:07, Diane Trout wrote: > > Would it make sense to drop those errors back to warnings, and do > > you > > know enough about the setup.cfg language to do it quickly? > > > >

Bug#1030096: dask.distributed intermittent autopkgtest fail

On Thu, 2023-02-09 at 07:44 +, Rebecca N. Palmer wrote: > On 09/02/2023 06:36, Diane Trout wrote: > > Also there's still some flaky tests as the rebuild triggered by my > > just > > committing the changelog release had a failure in > > "test_release_ret

Bug#1030096: dask.distributed intermittent autopkgtest fail

On Wed, 2023-02-08 at 23:11 +, Rebecca N. Palmer wrote: > > Mostly, please upload *something* today, because we won't know for > sure > whether it passes on a real buildd/debci until we try that, and if it > doesn't then the sooner we find out the better. > It's uploaded it earlier today

Bug#1030096: dask.distributed intermittent autopkgtest fail

Hello, So I discovered I'd forgotten to do git cherry-pick --continue so missed the last patch from Rebecca. (b82894aa) Thank you so much for working out a better strategy for the flaky tests. I also found a computer I could log into that has has no working ipv6 support, and so could more

Bug#1030096: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ?

On Tue, 2023-02-07 at 07:31 +, Rebecca N. Palmer wrote: > On 07/02/2023 03:20, Diane Trout wrote: > > What's your test environment like? > > Salsa CI. > > > I don't think head is hugely different from what was released in - > > 1. > > > > The

Bug#1030096: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ?

On Mon, 2023-02-06 at 21:39 +, Rebecca N. Palmer wrote: > I agree that xfailing the tests *may* be a reasonable solution.  I'm > only saying that it should be done by someone with more idea than me > of > whether these particular tests are important, because blindly > xfailing > everything

Bug#1030096: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ?

On Mon, 2023-02-06 at 11:13 +0100, Andreas Tille wrote: > Hi Rebecca, > > Am Mon, Feb 06, 2023 at 07:59:17AM + schrieb Rebecca N. Palmer: > > (Background: the pandas + dask transition broke dask.distributed > > and it was > > hence removed from testing; I didn't notice at the time that if we

Bug#1029232: dask.distributed: broken by version mismatch with dask

On Fri, 2023-01-20 at 13:20 -0800, Diane Trout wrote: > On Fri, 2023-01-20 at 21:02 +, Rebecca N. Palmer wrote: > > Would you like some help?  If so, please push what you currently > > have > > to > > Salsa so we can see it. > > > > (No promises - #10

Bug#1029232: dask.distributed: broken by version mismatch with dask

On Fri, 2023-01-20 at 21:02 +, Rebecca N. Palmer wrote: > Would you like some help?  If so, please push what you currently have > to > Salsa so we can see it. > > (No promises - #1029251 doesn't look like a big job but I might be > wrong > about that.) In shocking news, the build I did

Bug#1029232: dask.distributed: broken by version mismatch with dask

On Fri, 2023-01-20 at 07:57 +, Rebecca N. Palmer wrote: > Package: python3-distributed > Version: 2022.02.0+ds1-3 > Severity: serious > > dask.distributed has been failing its autopkgtests since dask was > upgraded to 2022.12.1. Yep. Andreas did the upload of dask 2022.12.1 with out asking

Bug#1028691: dask.distributed: FTBFS: unsatisfiable build-dependencies: python3-dask (>= 2022.02.0), python-numpy-doc

On Wed, 2023-01-18 at 10:49 +0100, Sebastiaan Couwenberg wrote: > On 1/18/23 08:38, Sebastiaan Couwenberg wrote: > > python-numpy-doc has been dropped from the build dependencies in > > git, > > but the package FTBFS due to test failures. Those might be fixed in > > a > > new upstream release,

Bug#1028667: dask BD-Uninstallable

On Sun, 2023-01-15 at 14:42 -0800, Diane Trout wrote: > On Sun, 2023-01-15 at 18:16 +, Rebecca N. Palmer wrote: > > Probably fixed - see my merge request on Salsa. > > > > > I'd tried to build versions of dask from 2022.03 - 2022.06 and they > all > failed wit

Bug#1028667: dask BD-Uninstallable

On Sun, 2023-01-15 at 18:16 +, Rebecca N. Palmer wrote: > Probably fixed - see my merge request on Salsa. > I'd tried to build versions of dask from 2022.03 - 2022.06 and they all failed with what appeared to be a strong dependency on pyarrow, which debian doesn't have. Did you get around

Bug#1026286: Unsatisfiable versioned dependency on python3-numpy

On Wed, 2023-01-11 at 13:15 +0100, Enrico Zini wrote: > > Thanks! I've opened > https://github.com/numba/numba/issues/8703 upstream > to track the possibility of numba making it in time for testing: > let's > see what happens. > Thnaks I commented with the what I did to get numba to build.

Bug#1026286: Unsatisfiable versioned dependency on python3-numpy

On Sat, 2022-12-17 at 20:19 +0100, Enrico Zini wrote: > Package: python3-numba > Version: 0.56.2+dfsg-2 > Severity: serious > > Hello, > > thank you for maintaining python3-numba! > > Unfortunately the package is currently uninstallable in sid. > > It depends on `python3-numpy (<< 1:1.22),

Bug#1027254: dask and pandas 1.5

On Mon, 2023-01-09 at 08:00 +, Rebecca N. Palmer wrote: > To get the new upstream version to work, dask_sphinx-theme, dask and > dask.distributed all need to be updated, in that order.  Tests here: > https://launchpad.net/~rebecca-palmer/+archive/ubuntu/dask2022p12v2/+packages Ok thanks for

Bug#1028175: snakemake rulename failes with asyncio has no attribute coroutine with python3.11

Package: snakemake Version: 7.12.1-1 Severity: serious Dear Maintainer, I noticed that snakemake-modes tests were failing while I was trying to build the package. Eventually I found that running the snakemake executable was failing with python 3.11, but worked with 3.10. Using the test

Bug#1024795: python-llvmlite

On Fri, 2022-12-23 at 10:56 -0500, M. Zhou wrote: > Control: tags -1 +moreinfo > > I'm confused. How did you manage to build the package from source > using c65b3e662b7b08920172b710419d7a06b660be59 on salsa? > > I did not upload it because I can never successfully build it > from source. > It

Bug#1024795: python-llvmlite

commit c65b3e662b7b08920172b710419d7a06b660be59 against llvm-14 and llvmlite's test cases pass. (And most of numba's passed too. And I think the remaining test failures aren't related to llvmlite) Is there a chance we could get an updated version released soon? Thanks Diane Trout signature.asc

Bug#1024648: elpa-snakemake: fails to install with emacs 27: misses 'transient'

On Tue, 2022-11-22 at 18:24 +0100, Andreas Beckmann wrote: > > There needs to be either a >   Depends: emacs-el (>= 1:28) > or an equivaent >   Breaks: (emacs-el (<< 1:28) > or the installation must be skipped if emacs is too old. So it looks like elpa-snakemake depends on the transient package

Bug#1000922: upgrading llvmlite to llvm-13

Hi, I found a pull request that starts the process of upgrading llvmlite to llvm-12 or -13. https://github.com/numba/llvmlite/pull/802 I modified it to work with our llvmlite 0.39.1 package and was able to build llvmlite and have it's tests pass on x86 64. The llvmlite upstream developers are

Bug#1016283: onetbb: FTBFS: _segment_table.h:63:63: error: member ‘tbb::detail::d1::segment_table, 128>, tbb::detail::d1::cache_aligned_alloc

On Fri, 2022-08-12 at 13:57 +0200, Lucas Nussbaum wrote: > On 08/08/22 at 22:45 +0200, Richard B. Kreckel wrote: > > I am unable to reproduce the above compile-time error. > > Hi, > > I can still reproduce it. > > Lucas > I saw this bug floating around and thought I'd try building tbb as

Bug#1017075: #1017075 dask - autopkgtest regression on i386 and armhf

On Mon, 2022-08-22 at 08:37 +0200, Graham Inggs wrote: > Hi Drew > > On Sun, 21 Aug 2022 at 19:08, Drew Parsons > wrote: > > In regards to bug severity, the dask debci failures are now marked > > as > > "Not a regression" so they won't hold up migration of dask. > > Dask's autopkgtests are

Bug#1014690: llvmlite breaks numba autopkgtest: segmentation fault

On Thu, 2022-07-14 at 10:10 +0200, Paul Gevers wrote: > Control: reassign 1014690 src:llvmlite 0.38.1-2 > Control: affects 1014690 src:numba > Control: fixed 1014690 0.38.1-3 > > Hi Diane, > > On 14-07-2022 05:26, Diane Trout wrote: > > I know there's some pr

Bug#1014690: llvmlite breaks numba autopkgtest: segmentation fault

Hi, I know there's some problems with some of numba's autopkgtests but I couldn't reproduce the segmentation fault. llvmlite's tracker suggests that the tests are passing now? Did you find a solution or is this likely to be a random problem? Diane On Sun, 2022-07-10 at 13:10 +0200, Paul

Bug#1013080: dask: incompatibility with scipy 1.8

On Sat, 2022-06-25 at 10:17 +0200, Graham Inggs wrote: > Control: severity -1 serious > Control: tags -1 + patch > > Please see attached patch from Ubuntu for this issue. Thank you for the patch it worked well. I wanted to give a status update since it's been a while. I haven't made as much

Bug#1006333: biboumi: fail to start after libexpat1 update

FWIW I saw a more complex patch for this issue posted here https://lab.louiz.org/louiz/biboumi/-/commit/0061298dd0945f7f67e7fa340c6649b179c804d5 from the Biboumi XMPP muc. I added the patch to 9.0-4 and compiled it for bullseye, and it seems to work. I tried connecting to oftc.net and tried

Bug#1006537: dask: autopkgtest failure on 32 bit, mismatch in size of data structure.

Hi, I had some time to work on this and worked around the test case that was failing, since it was failing because it was assuming it was running in a 64-bit environment. I submitted my comments to upstream here https://github.com/dask/dask/issues/8169#issuecomment-1059839906 I tested in a

Bug#1006537: dask: autopkgtest failure on 32 bit, mismatch in size of data structure.

On Sun, 2022-02-27 at 08:34 +, Peter Michael Green wrote: > Package: dask >  Version: 2022.01.0+dfsg-1 >  Severity: serious >   >  The autopkgtest for dask is once-again failing on 32-bit > architectures, >  this is blocking the fix for >

Bug#1000336: Upgrading tbb

On Wed, 2022-02-23 at 00:31 -0500, M. Zhou wrote: > Hello guys. Finally it's all green on our release architectures > https://buildd.debian.org/status/package.php?p=onetbb=experimental > > I shall request the slot for transition once finished the rebuild > of its reverse dependencies and filed

Bug#1000336: numba: FTBFS with Python 3.10

On Sat, 2022-02-19 at 11:02 +0100, Drew Parsons wrote: > Source: numba > Followup-For: Bug #1000336 > > onetbb is now building (in experimental) for all arches except > armel and armhf. > > Is it worth at this point to make an upload of numba 0.55 to > experimental to check that it's building

Bug#1002402: python-sparse: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

On Mon, 2022-02-21 at 02:24 +, Peter Michael Green wrote: > > During a rebuild of all packages in sid, your package failed to > > build > > on amd64. >   >  I'm no expert on this particular package, but this looks to me like > it is not actually caused by a problem in python-sparse, but is >

Bug#1000336: Upgrading tbb

Hi, After Andreas pointed it out I looked through some of the build failures for onetbb and talked to upstream about the i386 failure. https://github.com/oneapi-src/oneTBB/issues/370#issuecomment-1030387116 They have a patch.

Bug#1000336: Upgrading tbb

On Thu, 2021-12-23 at 11:03 -0500, M. Zhou wrote: > Hi all, > > I'm back. > > I've just finished my final exams so I could do something during > the holiday. That TBB repository is still work-in-progress and > FTBFS from the master branch is something expected. I will finalize > it soon. Andreas

Bug#1000336: numba: FTBFS with Python 3.10

On Wed, 2021-12-22 at 22:24 +0530, Nilesh Patra wrote: > > Upstream has mentioned that it has been fixed upstream. Diane, could > you > please do the needful and upload? > > Actually because of the current state of numba, several reverse > depends are FTBFS so it's > bit urgent to push.

Bug#1001348: dask: autopkgtest failures on 32 bit with pandas 1.3: Buffer type mismatch

I had been trying to update dask to newer version (2021.11.1), but it looks like the issue you referenced is still open. I tried the change they suggested in an i386 sbuild chroot and most of the errors went away. Though there was one test failure. "c.astype(np.int64, copy=False), k from

Bug#1001488: toolz: (autopkgtest) needs update for python3.10: Missing introspection for the following callables

On Sat, 2021-12-11 at 10:48 -0800, Steve Langasek wrote: > Package: toolz > Version: 0.11.1-1 > Followup-For: Bug #1001488 > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu jammy ubuntu-patch > Control: tags -1 patch > > Please find attached a trivial patch for this issue. >

Bug#987816: marked as pending in dask.distributed

Control: tag -1 pending Hello, Bug #987816 in dask.distributed reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at:

Bug#1000336: numba: FTBFS with Python 3.10

Thanks for the bug report and the forward, I'd managed to spot the build failures last night but only read the log files about why today. I subscribed to the upstream bug report. Diane On Sun, 2021-11-21 at 15:55 -0400, Stefano Rivera wrote: > Source: numba > Version: 0.52.0-5 > Severity:

Bug#997085: numba: FTBFS: AttributeError: 'Sphinx' object has no attribute 'add_stylesheet'

On Sun, 2021-10-24 at 15:18 -0400, Boyuan Yang wrote: > X-Debbugs-CC: di...@debian.org di...@ghic.org > Control: tags -1 +patch > > I believe the fix should be present at > https://github.com/numba/numba/pull/7122 . I haven't verified the > patch, > though. > > P.S. It might be a better solution

Bug#997085: numba: FTBFS: AttributeError: 'Sphinx' object has no attribute 'add_stylesheet'

On Sun, 2021-10-24 at 15:18 -0400, Boyuan Yang wrote: > X-Debbugs-CC: di...@debian.org di...@ghic.org > Control: tags -1 +patch > > I believe the fix should be present at > https://github.com/numba/numba/pull/7122 . I haven't verified the > patch, > though. Thanks for the link to the second part

Bug#995735: dask.distributed: autopkgtest sometimes times out on ci.d.n worker since dask migrated

Hi, I missed this bug report. I don't have any idea why the tests were failing on a large machine. I've been building and running the autopkgtests for dask.distributed my laptop with 2 cores & 16GB of RAM, and it' hasn't hung for me. I also glanced at the current CI build results and all the

Bug#995782: dask autopkgtest fails with SQLAlchemy 1.4.23+ds1-2

On Tue, 2021-10-05 at 17:40 +0200, Thomas Goirand wrote: > Source: dask > Version: 2021.08.1+dfsg-3 > Severity: serious > > Hi, > > As per this log: > https://ci.debian.net/data/autopkgtest/testing/amd64/d/dask/15777502/log.gz > > Please fix this ASAP. Looks like upstream fixed it and the

Bug#980692: dask: FTBFS: dh_sphinxdoc: error: debian/python-dask-doc/usr/share/doc/python-dask-doc/html/_static/js/html5shiv.min.js is missing

On Thu, 2021-09-30 at 17:43 +0200, Drew Parsons wrote: > Can anyone say why this Bug#980692 is still holding up the dask > migration? > > The bug is fully marked fixed and closed now, it shouldn't be in the > way > any more. I tried closing the bug again with the currently available version.

Bug#992672: closing 992672

# ci.debian.org tests appear to pass now close 992672 2021.08.1+dfsg-2 thanks Looks like everything passes now autopkgtest for dask/2021.08.1+dfsg-2: amd64: Pass, arm64: Pass, armhf: Pass, i386: Pass, ppc64el: Pass

Bug#993694: missing Depends: python3-jinja2

Hmm... So dask doesn't think jinja is required for base functionality. It's a dependency for an extended extras. >From dask's setup.py extras_require = { "array": ["numpy >= 1.18"], "bag": [], # keeping for backwards compatibility "dataframe": ["numpy >= 1.18", "pandas >= 1.0"],

Bug#980692: closing 980692

close 980692 2021.01.0+dfsg-1 thanks I forgot to close this bug. the doc package does build now.

Bug#992672: Uploaded dask_2021.08.1+dfsg-1

package: dask tags: pending version: 2021.08.1+dfsg-1 I uploaded the new version of dask, and on my computer dask's autopkgtests pass with python3-scipy 1.7.1. Diane signature.asc Description: This is a digitally signed message part

Bug#992672: scipy breaks dask autopkgtest: 5 times FAILED array/tests/test_stats.py::test_two

On Mon, 2021-08-23 at 12:53 +0200, Drew Parsons wrote: > Source: dask > Followup-For: Bug #992672 > Control: reassign 992672 src:dash 2021.01.0+dfsg-1 > > This bug is addressed in https://github.com/dask/dask/pull/7841 > > A version upgrade should fix it. > Ok thanks for checking. I have a

Bug#985467: "Clarification of Guix vulnerability."

Hi, I received an update from Leo Famulari: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47229#25 When using a guix-daemon that does not include the fix [0] for the bug reported here, it is still possible for rogue build scripts to escape the build environment, even when protected

Bug#982098: python-anndata: autopkgtest failure on 32bit

On Wed, 2021-02-10 at 01:43 +0200, Adrian Bunk wrote: > On Sat, Feb 06, 2021 at 04:20:47PM +0100, Michael R. Crusoe wrote: > > Control: forwarded -1 > > https://github.com/theislab/anndata/issues/443 > > > > I've let upstream know about this, thanks. > > Unless they have a solution immediately,

Bug#982424: python3-louvain: The package name should match the import module name "community"

Package: python3-louvain Version: 0.0+20181013git3fc1f575-1 Severity: serious Justification: Python packaging 3.3 Module Package Names Dear Maintainer, According to Section 3.3 of the Python Policy package binary names should match their import names:

Bug#930733: evolution: Can't open evolution

to trouble. Experimental isn't complete on its own and assumes dependencies in unstable will be available. Thank you, Diane Trout On Wed, 19 Jun 2019 14:41:16 +0200 Alexandre wrote: > Package: evolution > Version: 3.32.2-1 > Severity: grave > Justification: renders package unusab

Bug#972519: black and #972519

Hi, I saw you'd done some work on black recently but it was dropped out of testing because of the autopkgtest regression #972519. I looked and the d/tests/control file doesn't install the package but some of the tests assume the black command line program should exist If I do the following

Bug#959136: close this bug?

On Tue, 2020-10-13 at 22:10 +0100, Rebecca N. Palmer wrote: > The linked upstream report says this went away in numpy 1.18.4, and > the > tests in question now pass on debci. > Thank you for checking. That does sound like it's been resolved. It's at least passing on amd and arm 64

Bug#969621: propellor: Propellor fails to find location of built propellor binary

Version: 5.12-1 Version 5.12-1 compiled correctly on my testing system just now. Diane On Sun, 2020-09-13 at 20:47 -0700, Sean Whitton wrote: > Hello, > > On Sat 05 Sep 2020 at 09:22PM -07, Diane Trout wrote: > > > I tried to just build 5.11, but export CABAL=./Setup br

Bug#969621: propellor: Propellor fails to find location of built propellor binary

Package: propellor Version: 5.10.2-2 Severity: grave Tags: upstream Justification: renders package unusable Dear Maintainer, While trying to test propellor on a Debian Testing system, I discovered my changes were not taking effect. Eventually I discovered that the haskell build system was

Bug#951977: marked as pending in flake8-polyfill

Control: tag -1 pending Hello, Bug #951977 in flake8-polyfill reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at:

Bug#935455: Updated version of dask

Hi, I updated the version of dask to 2.11.0 does that help with this bug? Diane

Bug#952641: scipy: What is the license of scipy/stats/stats.py?

Source: scipy Severity: serious Tags: upstream Justification: Debian policy 2.1 "Debian Freee Software Guidelines" Dear Maintainer, While reviewing the dask source (which is also affected by this bug) I noticed this header in scipy/stats/stats.py # Copyright 2002 Gary Strangman. All rights

Bug#942235: [Python-modules-team] Bug#942235: Bug#942235: dask: autopkgtest needs update for new version of pytest

On Mon, 2019-11-04 at 19:42 -0300, Emmanuel Arias wrote: > I can work on fsspec :-) if there aren't opposition Go for it. I should find time and figure out where I was at for bokeh javascript dependencies. I wonder if the js team would review my first couple of packages while I try to

Bug#942235: dask: autopkgtest needs update for new version of pytest

On Tue, 2019-10-29 at 09:15 +0800, Drew Parsons wrote: > On 2019-10-29 03:01, Rebecca N. Palmer wrote: > > Assuming we're talking about > > > > https://salsa.debian.org/python-team/modules/dask/blob/experimental/debian/patches/use-local-intersphinx.patch > > > > I think the actual problem is on

Bug#930762: marked as pending in pybigwig

Control: tag -1 pending Hello, Bug #930762 in pybigwig reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at:

Bug#936076: python3-numba: numba segfaults when run with python 3.7.4 at numba/_dynfunc.c:52

Package: python3-numba Version: 0.42.0-1 Severity: grave Tags: upstream Justification: renders package unusable Dear Maintainer, Attempting to run any numba code immediately segfaults when running with python 3.7.4. I found this upstream bug report. https://github.com/numba/numba/pull/4328

Bug#924787: Motivation for blocking 842194

Hi, I discovered the need for the new udev rules via trying to use the yubikey-personalization-gui. Someone had reported 842194 and as far as I can tell its caused by the same permission denied problem this bug is covering. I suppose one could argue the gui should have reported the permission

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

version: 0.17+repack-3 tag: pending I have a new version (hopefully uploaded successfully) where I fixed dnssec-trigger-control-setup to not generate new keys or certificates if called repeatedly. So now the code to delete small keys should get called. I also included upstream's fix for the

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

On Wed, 2019-01-16 at 08:55 +0100, Axel Beckert wrote: > > > # summary of how this script can be called: > #* `configure' > [...] > case "$1" in > configure) > # configure the control channel if run for the first time > if [ -z "$2" ]; then >

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

Ok I found the place that was causing the segfault on installation, made a patch, it worked for me, and I pushed a new release. (Fixes also sent upstream) dnssec-trigger should also now only look for configuration files in /etc/dnssec-trigger, and it shouldn't try to create ones in /etc any

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

On Tue, 2019-01-15 at 00:08 +0100, Florian Schlichting wrote: > > Before thinking about cleanup, I'd start by making sure that fresh > installs don't re-create problems. At the moment, purging dnssec- > trigger > leaves two keypairs in /etc; and when I rm them manually, and again > install

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

On Mon, 2019-01-14 at 21:25 +0100, Florian Schlichting wrote: > Hi, > > in the course of looking into the upgrade failure, I ended up purging > dnssec-trigger and then installed it again. I notice this creates > keys > and config files in both /etc/ and /etc/dnssec-trigger?! Different to > Alex,

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

On Mon, 2019-01-14 at 14:35 +0100, Axel Beckert wrote: > Hi, > > Axel Beckert wrote: > > The syslog shows again this: > > > > Jan 14 07:18:59 c-cactus2 dnssec-triggerd[22039]: Jan 14 07:18:59 > > dnssec-triggerd[22039] error: Error in SSL_CTX use_certificate_file > > crypto error:140AB18F:SSL

Bug#911951: Bug #911951 in partd marked as pending

Control: tag -1 pending Hello, Bug #911951 in partd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at:

Bug#911951: partd autopkg tests need to depend on python3-all

On Friday, October 26, 2018 7:51:00 AM PDT you wrote: > Package: src:partd > Version: 0.3.8-1 > Severity: serious > Tags: sid buster > > the partd autopkg tests need to depend on python3-all, same as in the build > dependencies. This will block at least python3-defaults once failing autopkg >

Bug#898969: dnssec-trigger: fails with OpenSSL 1.1.1 due to too-small key

On Mon, 2018-09-17 at 09:55 +0800, Paul Wise wrote: > Package: dnssec-trigger > Version: 0.15+repack-1 > Followup-For: Bug #898969 > Control: retitle -1 dnssec-trigger: fails with OpenSSL 1.1.1 due to > too-small key and unknown ca > Control: severity -1 serious > > If I delete the existing keys

Bug#898969: dnssec-trigger: fails with OpenSSL in experimental due to too-small key

On Mon, 2018-10-01 at 20:23 +0200, Lee Garrett wrote: > Hi, > > Any update on this bug? dnssec-trigger will be autoremoved due to > this bug > tomorrow. I'd like to see it in buster, though. Ooops I forgot, Also does this bug impact unbound? I tried checking the unbound maintainer scripts and

Bug#909986: cloudpickle: FTBFS (TypeError: can't pickle _abc_data objects)

On Sun, 2018-09-30 at 23:03 +, Santiago Vila wrote: > Package: src:cloudpickle > Version: 0.5.2-2 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > I tried to build this package in buster but it failed: Looks like a python 3.7 incompatibility I updated to cloudpickle 0.5.6 and it

Bug#900535: Binary Independent build seems to have FTBFS

Package: src:python3-stdlib-extensions Version: 3.6.4-4 Severity: serious X-Debbugs-CC: debian-pyt...@lists.debian.org Hello, python3-distutils is currently unavailable in unstable, it appears that python3-stdlib-extensions was intended to provided it, but the all architecture package is

Bug#862757: dnssec-trigger 0.15 release

Hello, It took longer than I expected to produce a clean history, with the right maintainer field, in the right repository on salsa. Also I thought I'd pushed it last night, but apparently I'd forgotten to push again after testing with dry-run. I just received the email from ftpmaster saying it

Bug#862757: Finished patched

Just for thoroughness. Here's the final patch that seems to be working. DianeAuthor: Michael Biebl Description: libnm-glib/libnm-util has been deprecated upstream in favour of libnm. --- a/dnssec-trigger-script.in +++ b/dnssec-trigger-script.in @@ -18,9 +18,9 @@ import signal

Bug#862757: dnssec-trigger 0.15 release

On Wed, 2018-05-02 at 14:09 +0200, Michael Biebl wrote: > Hi Diane > > Am 02.05.2018 um 07:17 schrieb Diane Trout: > > Should I release this version or wait for what Michael did? > > You don't have to wait for me. I provided a patch for the issue for > the > maintain

Bug#862757: dnssec-trigger 0.15 release

Hi, I put together a potential 0.15 release for dnssec-trigger. I'm not sure how far Michael Biebl got, and I had a little bit of time to clean fix a few issues. I don't have access to the dns team salsa page, so I put the repository in my personal space for the moment.

Bug#896219: Added python3-distutils dependency

version 0.1.7-2 tags: pending thanks I added python3-distutils as a dependency and that should fix your problem. The new package should show up in unstable in a couple of hours. Diane signature.asc Description: This is a digitally signed message part

  1   2   >