https://buildd.debian.org/status/package.php?p=luajit
All green, including ppc64el and s390x
(arch-specific transitional dummy package)
Seems we are ready to start the rebuild?
On Tue, 2022-06-07 at 20:37 -0700, M. Zhou wrote:
> On Tue, 2022-06-07 at 20:03 -0700, M. Zhou wr
/12818940efdf76cf48b8e2cfea2dfaa5dc11664a
luajit2 (2.1-20220411-5) unstable
Now it should be fine after several hours when we retry the autopkgtest.
On Tue, 2022-06-07 at 22:28 -0700, M. Zhou wrote:
> https://buildd.debian.org/status/package.php?p=luajit
> All green, including ppc64el and s390x
> (arch-specific tra
On Thu, 2022-06-09 at 10:47 +0200, Paul Gevers wrote:
>
> I think there one more *test* issue, the first test in src:luajit
> doens't explicitly declare dependencies, which means it implicitly has
> has '@'. Quoting [1]:
>
>
> Which means that autopkgtest asks apt to make sure all packages fro
On Thu, 2022-06-09 at 13:58 +0200, Paul Gevers wrote:
> Hi Mo,
>
> You may want to look at the FTBFS on mipsel for python-lupa.
>
> https://buildd.debian.org/status/fetch.php?pkg=python-lupa&arch=mipsel&ver=1.13%2Bdfsg-1%2Bb2&stamp=1654771416&raw=0
Yunqiang Su (@syq) volunteers to look into luaj
On Thu, 2022-06-09 at 21:51 -0700, M. Zhou wrote:
>
> > lua-moses autopkgtest failure [2] looks bad (still a segmentation fault):
> > autopkgtest [07:20:14]: test command9: luajit debian/tests/simple.lua
> > autopkgtest [07:20:14]: test command9: [---
&g
On Sun, 2022-06-12 at 21:19 +0200, Paul Gevers wrote:
> Hi Mo,
>
> On 10-06-2022 08:00, M. Zhou wrote:
> > > There are some compilation flags tweakable. I'll try with
> > > qemu to see whether I can make it work.
> >
> > I tried to tweak some comp
Hi Andrius,
Thank you so much for the help! I was still looking for time slot
to login into a build server to deal with this hard-to-build package.
Nowadays I sort of started to dislike packages that my laptop cannot
easily build within a few minutes :-)
On Mon, 2022-06-13 at 11:57 +0300, Andriu
On Mon, 2022-06-13 at 08:30 +0200, Gürkan Myczko wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Gürkan Myczko
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: ffcv
>Version : 0.0.3
>Upstream Authors: ffcv team
>URL : https://ffcv.io/
> *
Source: flexbar
Version: 3.5.0-4
Severity: important
Dear maintainer,
There is a major API change from tbb to onetbb, please refer
https://oneapi-src.github.io/oneTBB/main/tbb_userguide/Migration_Guide.html
for more details.
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
[ 50%] Building
On Thu, 2022-03-24 at 13:12 +0100, Paul Gevers wrote:
> >
> > "I heard from archlinux" is not good enough. I sent you email about
> > this without getting a reply, then filed #1006920, without getting a
> > reply, now this incomplete proposal. you may want to look at all the
> > build rdeps fo
Hi Jose,
Could you please provide more details on "the split of the libraries
is breaking some common use cases"?
I cannot figure out what could happen if we split the library packages
from the links provided.
On Mon, 2022-03-21 at 17:58 +0100, Jose Luis Rivero wrote:
> On Tue, 8 Mar 2022 10:30:
On Thu, 2022-03-24 at 17:55 +0100, Sebastian Ramacher wrote:
> >
> > libtbb2 and libtbb12 contains some common files hence the conflict.
> > I'd rather wait for all the reverse deps to be ready for this
> > transition, compared to going through NEW again due to binary
> > package change.
>
> This
Thanks for the updates. Currently the packaging of onnx is going
through a overhaul due to significant changes in upstream build
system.
IIRC the current status of the git master branch is till FTBFS,
or flawed.
I also have to test the 1.11.0's compatibility with
src:pytorch before the upload.
S
Hi Stefano,
The patch looks good to me and should be eligible to upload
without delay.
On Sat, 2022-03-26 at 17:36 -0400, Stefano Rivera wrote:
> Dear maintainer,
>
> I've prepared an NMU for onnx (versioned as 1.7.0+dfsg-3.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> sh
Hi Pierre,
The original C++/Python implementation xgboost is maintained
by deep learning team:
https://salsa.debian.org/deeplearning-team/xgboost
I have assigned the whole debian science team with
maintainer access (max role) to deep learning team.
You may choose to maintain the package there
if
On Tue, 2022-03-29 at 21:09 +0200, Pierre Gruet wrote:
>
> >
> > This team is dedicated to hardware acceleration,
> > machine learning, and deep learning. See
> > debian...@lists.debian.org
> >
>
> Now subscribed!
>
> By the way, does the team have some policy? Or does it inherit its
> policy
Sure, I think we can ship a snapshot version as long as it works
fine with llvm-14. Could you please verify the snapshot hash
again?
https://github.com/numba/llvmlite/commit/c65b3e662b7b08920172b710419d7a06b660be59
The commit seems missing. If it was close to the master branch,
I can directly pul
: build: plugin distutils failed with: exit code=1:
/usr/bin/python3 setup.py build
dh_auto_build: error: pybuild --build -i python{version} -p "3.11 3.10"
returned exit code 13
make: *** [debian/rules:11: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned
Control: tag -1 +moreinfo
I have tried exactly the same patch half a year ago,
which resulted a massive number of segmentation faults.
Build log can be found in our buildd.
See https://github.com/oneapi-src/oneTBB/issues/777
I'm not sure whether the latest assembly code in
https://github.com/one
Control: fixed -1 2022.07+dfsg-1
Control: close -1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: simdj...@packages.debian.org
Control: affects -1 + src:simdjson
Hi release team,
The simdjson upstream has bumped the ABI version along with their
new release. Thus the tra
The issue still exists with armel:
https://buildd.debian.org/status/package.php?p=onetbb
On Wed, 2023-08-02 at 22:46 +0200, Petter Reinholdtsen wrote:
> [M. Zhou]
> > I'm aware of this issue. I'm slightly faster than buildd for
> > toolchain
> > upgrades. The iss
Control: fixed -1 2021.9.0-2
I agree.
On Thu, 2023-08-03 at 00:32 +0200, Petter Reinholdtsen wrote:
> [M. Zhou]
> > The issue still exists with armel:
> > https://buildd.debian.org/status/package.php?p=onetbb
>
> If so, this is a duplicate of
> https://bugs.debian.org/1
-1 confirmed
>
> On 2023-08-01 22:07:33 -0700, M. Zhou wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: simdj...@packages.debian.org
> > Control: affec
Package: nvidia-smi
Version: 535.216.03-1
Severity: important
Control: forwarded -1
https://forums.developer.nvidia.com/t/nvidia-smi-uses-all-of-ram-and-swap/295639/16
Dear maintainer,
On a newly installed Debian sid system, I noted that nvidia-smi
always gets stuck in the middle and consume all
LGTM and sponsored. Thank you for your contribution!
On Mon, 2024-12-30 at 19:27 +0100, Christian Göttsche wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "ncdu":
>
> * Package name : ncdu
> Version : 1.2
Control: close -1
Forgot to mark this RFS as done.
On Mon, 2024-12-30 at 15:11 -0500, M. Zhou wrote:
> LGTM and sponsored. Thank you for your contribution!
>
> On Mon, 2024-12-30 at 19:27 +0100, Christian Göttsche wrote:
> > Package: sponsorship-requests
> > Severity:
Original src:cpuinfo maintainer here. The patch looks good to me.
This package indeed encounters test failure for new CPUs
expecially the Intel CPUs with P+E cores. Ignoring test failure
is the simplest solution in the current situation.
On Mon, 2024-12-30 at 18:48 +0100, Santiago Vila wrote:
> Ok
Control: close -1
I revived this package. No longer orphaning.
Source: ros-vision-opencv
Version: 1.16.2+ds-3
Severity: important
Dear maintainer,
We will start opencv 4.10 transition soon. And since opencv 4.10 has
merged libopencv_barcode into libopencv_objdetect, the autopkgtest
fails since it cannot find the shared object.
This is similar to the problem
On Fri, 2025-01-31 at 12:53 +0100, Emilio Pozuelo Monfort wrote:
> On 27/01/2025 00:45, M. Zhou wrote:
> > On Tue, 2025-01-14 at 13:19 +0100, Emilio Pozuelo Monfort wrote:
> > >
> > > This sounds good, but let's wait a bit for the Python transition to
> > &
On Fri, 2025-01-31 at 12:31 +0100, Simon Josefsson wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Simon Josefsson
> X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
>
> * Package name : ollama
> Version : 0.5.7-1
> Upstream Author : Ollama
> * URL
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: vllm
Version : 0.7.1
Upstream Contact:
* URL :
* License : Apache-2.0
Programming Lang: Python
Description : A high
On Thu, 2025-02-06 at 01:33 +0100, Petter Reinholdtsen wrote:
>
> I was sad to discover the server example is missing, as it is the
> llama.cpp progam I use the most. Without it, I will have to continue
> using my own build.
I second this. llama-server is also the service endpoint for DebGPT.
I
On Fri, 2025-02-07 at 02:10 +0500, Andrey Rakhmatullin wrote:
> On Mon, Jan 27, 2025 at 09:15:06AM +0100, Sebastian Ramacher wrote:
> > Source: pytorch-cuda
> > Version: 2.5.1+dfsg-4
> > Severity: serious
> > X-Debbugs-Cc: sramac...@debian.org
> >
> > pytorch-cuda is involved in the currently ongo
On Thu, 2025-02-06 at 09:13 +0100, Christian Kastner wrote:
>
> I meant to ask anyway: performance-wise, is it comparable to your local
> build? I mean, I wouldn't know what in the code would alter this, but I
> built and tested this on platti.d.o and performance was poor, so another
> data point
Package: g++-14
Version: 14.2.0-14
Severity: important
Dear maintainer,
We noted that pytorch 2.6.0 FTBFS on arm64 due to an internal compiler
error from g++. The relevant part of error log reads:
```
/usr/bin/c++ -DAT_BUILD_ARM_VEC256_WITH_SLEEF -DAT_PER_OPERATOR_HEADERS
-DBUILD_ONEDNN_GRAPH -
Source: mrpt
Version: 1:2.14.7+ds-1
Severity: important
opencv 4.10 has merged libopencv_barcode into libopencv_objdetect.
So mrpt fails to build against it because -lopencv_barcode cannot
be found.
Control: reassign -1 nvidia-persistenced 535.216.01-1
On Wed, 2025-01-08 at 09:16 +0100, Andreas Beckmann wrote:
> On 1/8/25 00:42, M. Zhou wrote:
> > Package: nvidia-smi
> > Version: 535.216.03-1
>
> > In the above thread, a magic fix is provided:
> >
Source: ros-opencv-apps
Version: 2.0.2-10
Severity: important
opencv 4.10 has merged libopencv_barcode into libopencv_objdetect.
So ros-opencv-apps FTBFS against it since -lopencv_barcode cannot be found.
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: ope...@packages.debian.org
Control: affects -1 + src:opencv
User: release.debian@packages.debian.org
Usertags: transition
Our current opencv version in sid is quite ancient. I intend to make
the transition towards the latest 4.10 versi
I second this request.
On Sat, 30 Nov 2024 19:34:42 +0100 Carsten Schoenert
wrote:
> Source: rust-pyo3
> Version: 0.22.6-1
> Severity: wishlist
>
> Dear Maintainer,
>
> it would be nice if rust-pyo3 could get a recent upstream version, while
> writing 0.23.2 is available.
>
> While trying to
[OK]
On Wed, 2025-01-08 at 13:37 -0500, M. Zhou wrote:
> Package: release.debian.org
> Severity: normal
> X-Debbugs-Cc: ope...@packages.debian.org
> Control: affects -1 + src:opencv
> User: release.debian@packages.debian.org
> Usertags: transition
On Mon, 2025-01-27 at 11:13 +0100, Christian Kastner wrote:
> Hi Cory,
>
> On 2025-01-27 09:44, Cordell Bloor wrote:
> > Could we just sidestep this whole question of native instructions by
> > building llama.cpp with the BLAS backend?
>
> I was going to ship BLAS as one of the backends, but you
On Tue, 2025-01-14 at 13:19 +0100, Emilio Pozuelo Monfort wrote:
>
> This sounds good, but let's wait a bit for the Python transition to settle.
Ping? The python3.13-default transition seems to be at 100% now.
Hi Sudip,
Thank you for fixing this while I'm dealing with other packages.
Please feel free to upload without delay. If you have access to
the git repo, please git push and that will be appreciated :-)
On Sat, 2025-01-25 at 12:42 +, Sudip Mukherjee wrote:
> Control: tags 1092802 + patch
> Co
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: snapr...@packages.debian.org
Control: affects -1 + src:snapraid
User: ftp.debian@packages.debian.org
Usertags: remove
Hi ftp-master,
It seems that the mips64el support for this package is broken
for a while due to test failure. I don't th
Package: python3-onnxruntime
Version: 1.19.2+dfsg-3
Severity: normal
Forwarded: https://github.com/conan-io/conan-center-index/issues/17380
I just added the autopkgtest test case for inferencing a dummy network
exported from pytorch. The test case runs, but with lots of error reports
for "Schema e
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: python-onnxscript
Version : git head, since there is no versioned release
Upstream Contact: Microsoft
* URL : https://github.com/micr
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: openvino
Version : 2024.6.0
Upstream Contact: Intel
* URL : https://github.com/openvinotoolkit/openvino
* License : Apache-2.
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: xnnp...@packages.debian.org
Control: affects -1 + src:xnnpack
User: ftp.debian@packages.debian.org
Usertags: remove
The upstream of src:xnnpack does not support ppc64el. So keeping
a ppc64el binary in experimental forever is pointless. The
On Fri, 2025-02-14 at 11:48 +0100, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
>
> The numpy 2 transition shouldn't be a blocker, as numpy rdeps can migrate to
> testing freely. As it's taking a while to get it sorted out, let's go ahead
> with
> this one.
Thanks, and uploaded t
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: simdj...@packages.debian.org
Control: affects -1 + src:simdjson
User: release.debian@packages.debian.org
Usertags: transition
Hi release team,
The new upstream release of simdjson bumped the SOVERSION, so we
need to handle the transit
Control: fixed -1 2.6.0+dfsg-6
Control: close -1
Manually rebuilt. Marking this as done.
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: huggingface-hub
Version : 0.29.3
Upstream Contact: Huggingface
* URL : https://github.com/huggingface/huggingface_hub
* License
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org,
c...@debian.org
* Package name: llama.vim
* URL : https://github.com/ggml-org/llama.vim
* License : MIT/Expat
Programming Lang: Vim
Description
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: llm.nvim
* URL : https://github.com/huggingface/llm.nvim
* License : Apache-2.0
Programming Lang: Lua
Description : LLM powered d
On Wed, 2025-02-12 at 09:12 +0100, Emilio Pozuelo Monfort wrote:
>
> Go ahead.
>
Uploaded. And the transition seems finished:
https://release.debian.org/transitions/html/auto-simdjson.html
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: simdutf
Version : 6.2.0
* URL : https://github.com/simdutf/simdutf
* License : Apache-2.0 OR MIT
Programming Lang: C++
Description : Unicode valida
Control: severity -1 important
Lowering the importance since I'm not able to reproduce this issue.
It might be a flaky test.
Control: fixed -1 4.10.0+dfsg-2
Control: close -1
I can not reproduce the said problem. Closing.
Feel free to reopen if there is reproducible code snippet.
Package: python3-torch-cuda
Version: 2.6.0+dfsg-3
Severity: serious
In [1]: import torch
---
ImportError Traceback (most recent call last)
Cell In[1], line 1
> 1 import torch
File /usr/lib/py
Package: wnpp
Severity: normal
It is in good shape, but I'm no longer using this package.
(CPU-only) can be left intact.
And can we remove the ppc64el architecture for src:pytorch-cuda from testing?
The libcuda1 dependency is no longer available on ppc64el, so pytorch-cuda
is not installable anyway.
On Sat, 2025-06-14 at 08:59 +0200, Sebastian Ramacher wrote:
> On 2025-06-13 16:28:38
Control: retitle -1 unblock: pytorch-cuda/2.6.0+dfsg-7+b1
The ROM for ppc64el binary has been filed at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1107961
On Tue, 2025-06-17 at 23:29 -0400, M. Zhou wrote:
> retitle -1 unblock: pytorch-cuda/2.6.0+dfsg-7+b1
>
> I have manually
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pytorch-c...@packages.debian.org, debian-powe...@lists.debian.org
Control: affects -1 + src:pytorch-cuda
User: ftp.debian@packages.debian.org
Usertags: remove
User: debian-powe...@lists.debian.org
Usertags: ppc64el
The libcuda1 is no longe
On Thu, 2025-06-12 at 22:14 -0400, M. Zhou wrote:
>
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: lu...@debian.org
>
> [ Tests ]
> It should work. If there is regression, it'
On Fri, 2025-06-13 at 19:20 +0200, Santiago Vila wrote:
> >
> > We need CUDA >= 12.4 to fix the src:pytorch-cuda FTBFS #1105066,
>
> Hi. Not a release manager, but am I right to think that if we
> do nothing and just wait for CUDA 12.4 to enter testing, the bug
> would be solved as well?
You are
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: lu...@debian.org
Please unblock package pytorch{,-cuda}
We need CUDA >= 12.4 to fix the src:pytorch-cuda FTBFS #1105066, which
is due to CUDA's gcc support being too old. Bu
The bug is largely triggered by g++-12 being too old. However, the
latest version of g++ supported by CUDA 12.3 is g++-12.2. We need to
wait for the nvidia team to upload CUDA 12.4 (they have planned so) to
unstable, and bump the g++ symlink in nvidia-cuda-toolkit-gcc to g++-13.
At that time th
Control: retitle -1 unblock: lapack/3.12.3-4 (pre-approval)
We need to bump the revision since -3 was uploaded to experimental.
My previously proposed solution "Breaks+Replaces" won't work.
The working solution is to introduce a transitional dummy package
so apt can correctly deal with the packag
t; You can try editing the Packages files in /var/lib/apt directly if you
> want to test other solutions.
>
> Feel free to take it from here.
>
> Cheers Jochen
>
> Am 19. Juli 2025 18:47:17 MESZ schrieb "M. Zhou" :
> > I disagree. You may have incorrectly unders
or trixie I uploaded it to NEW/experimental. The
> release team agreed to take it afterwards. I will take care of the rest
> unless someone disagrees with the approach.
>
> Cheers Jochen
>
>
> * Jochen Sprickerhof [2025-07-18 10:26]:
> > Hi,
> >
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: lap...@packages.debian.org
Control: affects -1 + src:lapack
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package lapack
[ Reason ]
This is a one-liner targted fix of
https://bugs.debian.org/cgi-bin/bugrepo
It seems that gguf-py is not an independent code repository,
but a part of llama.cpp.
In that sense you should try to incorporate the python binary
package to src:llama.cpp and collaborate with Christian (@ckk).
https://salsa.debian.org/deeplearning-team/llama.cpp/-/tree/master/gguf-py?ref_type=h
Hi,
I'm still a little bit confused about the report.
Based on the podman image debian:bookwork, I can upgrade psfex without apt
reporting issue like reported. So the problem seems to be highly specific
to the -14 revision of atlas.
Do that mean making lapack break the -14 version is enough to f
ckage is ready to migrate.
Feel free to delay for a couple of days as you see appropriate.
unblock lapack/3.12.1-4
On Sat, 2025-07-19 at 22:06 +, Ivo De Decker wrote:
> Control: tags -1 confirmed moreinfo
>
> Hi,
>
>
> On Sat, Jul 19, 2025 at 03:05:13PM -0400, M. Zhou wrot
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: lap...@packages.debian.org
Control: affects -1 + src:lapack
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package lapack
[ Reason ]
This is a targeted bug fix for smoothing the upgrade path
to trixie:
https
201 - 278 of 278 matches
Mail list logo
