Control: tags -1 +patch
https://salsa.debian.org/apt-team/python-apt/-/merge_requests/90
On Sun, 2023-09-17 at 14:12 +0200, Ari wrote:
> Have you, maintainers of zfs, considered configuring the packages so
> that it skips trying to build of affected kernels?
> This would at least reduce the time of installing any packages
> drastically - currently my system tries to build it for two
On Tue, 5 Sep 2023 18:11:55 +0200 "Miguel A. Vallejo"
wrote:
> M. Zhou wrote:
>
> > But after that I noticed that the most important
> > package grub-efi-amd64-signed:amd64 (1+2.06+13,
> > 1+2.12~rc1+7) was not upgraded along with the other
> > grub pac
Same here. But I have some different conclusions after fixing my
machine.
Before my machine becoming unable to boot, the last apt log involves
Start-Date: 2023-09-05 00:09:00
Commandline: apt upgrade
Requested-By: lumin (1000)
Upgrade: libimath-3-1-29:amd64 (3.1.9-2, 3.1.9-3),
Sorry for the inconvenience. This is a temporary break due to the
undergoing pytorch 2.0.1 upgrade work.
On Mon, 2023-08-21 at 14:52 +0200, Mattias Ellert wrote:
> Package: python3-torch
> Version: 1.13.1+dfsg-4
> Severity: serious
>
> Importing torch results in failure due to missing symbols:
>
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
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 issue will au
Source: onetbb
Version: 2021.9.0-1
Severity: serious
I'm aware of this issue. I'm slightly faster than buildd for toolchain
upgrades. The issue will automatically disappear once our amd64 buildd
migrates to gcc-13. The gcc-12 will lead to the FTBFS you see now.
Local sbuild with gcc-13 has no
Control: severity -1 important
Control: fixed -1 1.13.1+dfsg-5
I believe these symlinks were deprecated already. These symlinks are removed in
1.13.1+dfsg-5 (experimental).
I'm not able to prepare a 1.13.1+dfsg-4.1 release to only remove these symlinks
within a short time... too busy lately.
So
Control: fixed -1 2.1.11-1
2.1.11-1 has migrated to testing.
On Mon, 2023-01-30 at 06:46 +0100, Andreas Tille wrote:
> Am Sun, Jan 29, 2023 at 10:22:24AM -0500 schrieb M. Zhou:
>
>
> Since we do not have this module[2] (yet) we should probably exclude all
> tests that need this module, right? If you think its a nice thing to
> have
On Sun, 2023-01-29 at 09:03 +0100, Andreas Tille wrote:
>
>
> I have no idea about fmtlib but I noticed:
>
> [2022-09-04] fmtlib 9.1.0+ds1-2 MIGRATED to testing (Debian testing
> watch)
> [2022-09-04] Accepted fmtlib 9.1.0+ds1-2 (source) into unstable
> (Shengjing Zhu)
> [2022-08-27] Accepted
For reference, a 8 core + 16GB RAM configuration should be able to finish the
pytorch compilation timely. The build takes roughly an hour. My observation
is based on power9 -- on amd64 it should be something similar.
On Sun, 2023-01-29 at 11:09 +0800, Aron Xu wrote:
> On Fri, Jan 27, 2023 at
Feel free to break the pytorch reverse dependencies without a
transition slot -- we do not need the slot in the current status.
The rdeps are already not in testing due to RC bugs and needs
some new patchworks. Manual upload is needed for its rebuild.
On Fri, 2023-01-27 at 20:19 +0800, Aron Xu
Control: severity -1 important
I think this FTBFS mostly stems from the toolchain.
1. before the bug is filed, it builds successfully on amd64
2. On the day I recieved this bug report, I reproduced it
3. after some toolchain updates, I cannot reproduce it anymore
Currently, I'd say PyTorch and TensorFlow are the two most
popular libraries. And I even worry google is trying to
write something new like Jax to replace TensorFlow in some aspects.
On Sat, 2023-01-14 at 11:12 +, Rebecca N. Palmer wrote:
> theano has been mostly abandoned upstream since
--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 exit status 2
On Thu, 2022-12-22 at 18:20 -0500, M. Zhou wrote:
> Sure, I think we can ship a snapshot version
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
Control: severity -1 important
Control: tags -1 +moreinfo
I'm still not sure about why the upgrade failed, and I could not
reproduce the problem in a clean chroot using the following script:
Control: merge 1025214 1025171
The "MAKEFLAGS="--environment-overrides" also caused zfs-dkms FTBFS.
The two bugs above are the same issue, hence the merge.
Control: reassign -1 dkms 3.0.8-2
Control: retitle -1 regression: dkms/3.0.8-2 renders zfs-dkms FTBFS
Control: severity -1 serious
Hi,
Thank you for the information! I can confirm that this is the same issue
that you have encountered. By commenting out the --environment-overrides,
the current
Package: zfs-dkms
Version: 2.1.6-3
Severity: serious
It was built againt 6.0.0-3-amd64 on my sid machine, but suddenly
stopped working with the recent 6.0.0-5-amd64 kernel.
Control: fixed -1 2.6.1-1
Source: tbb
Version: 2020.3-2.1
Severity: serious
src:tbb: do not migrate. this source is deprecated in favor of
src:onetbb. The RM bug of src:tbb is filed at
https://bugs.debian.org/1014990
On Sat, 2022-08-27 at 08:55 +0200, Emanuele Rocca wrote:
> On 08/04 09:36, Paul Gevers wrote:
> > We are in the transition of making python3.10 the default Python
> > versions
> > [0]. With a recent upload of python3-defaults the autopkgtest of
> > pytorch
> > fails in testing when that
The bug should have been fixed in the -13 upload of src:onetbb
The FTBFS occurred because of GCC-11 -> GCC-12 bump.
According to upstream suggestion, we can simply turn off some warnings.
Please let me know if this bug persists.
On Wed, 2022-08-24 at 13:21 -0700, Diane Trout wrote:
> On Fri,
address this issue in timely manner.
On Thu, 2022-07-28 at 10:15 +0200, Andreas Tille wrote:
> Hi Graham,
>
> Am Thu, Jul 28, 2022 at 09:15:06AM +0200 schrieb Graham Inggs:
> > Hi
> >
> > On Wed, 27 Jul 2022 at 17:57, M. Zhou wrote:
> > > The previous
Source: scikit-learn
Version: 1.1.1-1
Severity: serious
Justification: Policy section 4.9 violation
There are loads of similar traceback message saying the documentation build
has failed to retrieve some URL, like this:
```
generating gallery for auto_examples/decomposition... [ 30%]
Control: reopen -1
Control: found -1 0.38.1-3
Simply upgrading llvm deps from 11 to 13 leads to regression for
numba. I'm reverting this change back until the upstream source
code can really support a newer version.
Control: severity -1 important
I've uploaded 1.12 to unstable. Let's see whether the situation has been
changed a little bit for armhf.
Floating point precision is sometimes flaky indeed, but I think this would not
be that fatal.
So changing the severity down to important. If the flaky test no
Hi,
Thanks for the bug report. I'm aware of the break, and other users have reported
this issue some time before:
https://lists.debian.org/debian-ai/2022/06/msg00060.html
The break is due to onnx 1.12 upgrade.
The pytorch version in the new queue works fine with onnx 1.12,
as mentioned in the
Source: trilinos
Version: 13.2.0-1
Severity: serious
This is a side-product of a rebuild test against libtbb-dev/experimental
==> CMakeFiles/CMakeError.log <==
Performing C++ SOURCE FILE Test
Source: gazebo
Version: 11.10.2+dfsg-1
Severity: serious
I was testing rdeps for onetbb transition but found this issue.
Source: blender
Version: 2.83.5+dfsg-5
Severity: serious
I found it ftbfs during onetbb reverse dependency test,
although the reason irrelevant to onetbb.
Version 3.X is still not built for amd64.
Source: openblas
Version: 0.3.20+ds-1
Severity: serious
Justification: FTBFS
According to lapack 3.10.1 release note and upstream pull request 570,
xCOMBSSQ has been deprecated. Openblas upstream source has not yet
adapted to this change. And thus FTBFS due to missing the following
two symbols
since some of the core APIs have been changed.
Please expect a relatively negative rebuild result.
Help is welcome.
On Mon, 2022-03-14 at 01:30 +0530, Nilesh Patra wrote:
> Hi Mo,
>
> On 2/23/22 11:01 AM, M. Zhou wrote:
> > Hello guys. Finally it's all green on our releas
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 FTBFS bugs if any.
On Tue, 2022-02-08 at 17:59 -0500, M. Zhou
Source: tensorflow
Version: 2.3.1-1
Severity: serious
Justification: FTBFS; Bazel tries to download during build.
Building tensorflow locally with sbuild results in errors like the follows
ERROR:
/<>/tensorflow/compiler/mlir/tensorflow/BUILD:1249:11:
Hi Diane,
Thank you. I have added that patch in the git repository.
On Tue, 2022-02-08 at 13:49 -0800, Diane Trout wrote:
> Hi,
>
> After Andreas pointed it out I looked through some of the build
> failures for onetbb and talked to upstream about the i386 failure.
>
To anyone who is concerned with the package status in debian,
since there is a significant change in packaging, we have to
go through new queue again.
https://ftp-master.debian.org/new/onetbb_2021.4.0-1~exp1.html
This depends on our ftp team.
The latest package git repository is here:
API changes. So I guess the
transition won't be easy.
On Wed, 2021-12-29 at 23:27 -0800, Diane Trout wrote:
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 r
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 said in previous posts that we prefer a faster
NEW queue process.
Control: severity -1 important
Lowering the severity to unblock the migration, as migration is
currently the first priority for us due to the huge diff between
0.8.6 and 2.0.1, given the stable freeze schedule.
I will fix it and upload 2.0.1-3 immediately after migration.
It is easy to apply
Hi Dominique,
Will do it later. BTW, the *.moarvm not found error is related to this:
https://github.com/rakudo/rakudo/issues/3093
We can temporarily symlink several directories to wordaround this.
On Fri, 13 Sep 2019 at 12:24, Dominique Dumont wrote:
>
> On Thursday, 12 September 2019
On Tue, 27 Aug 2019 at 15:21, Dominique Dumont wrote:
>
> On Tuesday, 27 August 2019 10:04:23 CEST Dominique Dumont wrote:
> > Right.. This is the same error than the one showing in the FTBS issue.
> >
> > I guess we need to talk to upstream. They may not have seen this issue yet
> > if they use
Hi dod,
On Mon, 26 Aug 2019 at 16:45, Dominique Dumont wrote:
>
> On mercredi 21 août 2019 13:08:42 CEST Ivo De Decker wrote:
> > A binnmu of rakudo in unstable fails on amd64:
> >
> > https://buildd.debian.org/status/package.php?p=rakudo
>
> Rakudo fails to build with latest version of libuv1
control: severity -1 important
This is not baseline violation. julia -C
"armv7-a;armv7-a,neon;armv7-a,neon,vfp4"
compiles 3 branches of code, and the optimal branch will be selected
during runtime. The SIGILL raised during build on the buildd stems from
LLVM's incorrect CPU detection.
Here is
Hi,
On Mon, Jan 07, 2019 at 12:24:29AM +0100, Petter Reinholdtsen wrote:
> Is TensorFlow different from libtensorflow, already in unstable:
experimental
>
48 matches
Mail list logo
