Hi,
On 05-08-2024 04:25, Jeremy Bícha wrote:
Some Rust autopkgtests take a very long time to complete which is
especially noticeable on riscv64 which I think may be the slowest
autopkgtest infrastructure.
That's why the test timeout on riscv64 is double that of other
architectures:
https://s
That is not the actual contents of the .deb. Download the .deb and
open it in file-roller or something to check for yourself. Or look at
the build log.
https://buildd.debian.org/status/package.php?p=rust-async-broadcast
Some Rust autopkgtests take a very long time to complete which is
especially
Processing control commands:
> affects -1 + src:rust-async-broadcast
Bug #1077958 [release.debian.org] nmu: rust-async-broadcast_0.7.1-1
Added indication that 1077958 affects src:rust-async-broadcast
--
1077958: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077958
Debian Bug Tracking System
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: rust-async-broadc...@packages.debian.org,
debian-r...@lists.debian.org
Control: affects -1 + src:rust-async-broadcast
User: release.debian@packages.debian.org
Usertags: binnmu
nmu rust-async-broadcast_0.7.1-1 . riscv64 . unstable . -m
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@debian.org
Control: affects -1 + src:rapiddisk
[ Reason ]
An upstream change from Linux 6.9 got backported by upstream to
Linux 6.1.83 and causes module build fa
Processing control commands:
> affects -1 + src:rapiddisk
Bug #1077916 [release.debian.org] bookworm-pu: package rapiddisk/9.0.0-1+deb12u1
Added indication that 1077916 affects src:rapiddisk
--
1077916: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077916
Debian Bug Tracking System
Contact
On Sun, Aug 04, 2024 at 01:32:24PM +0200, Paul Gevers wrote:
> Hi,
>
> On 04-08-2024 13:22, Adrian Bunk wrote:
> > The question would be whether you want to enforce it in Britney,
> > which basically implies that Autobuild: should default to yes in
> > non-free-firmware.
>
> I see this as a rephr
Hi,
On 04-08-2024 13:22, Adrian Bunk wrote:
The question would be whether you want to enforce it in Britney,
which basically implies that Autobuild: should default to yes in
non-free-firmware.
I see this as a rephrasing of the discussion, so I can only agree that
that's the question.
You c
On Sun, Aug 04, 2024 at 10:31:30AM +0200, Paul Gevers wrote:
>...
> On 04-08-2024 09:31, Niels Thykier wrote:
> > That leaves us with 3/15 and the question whether we want to commit for
> > future firmware.
>
> I don't think we need to commit, just express a very strong desire to build
> on buildd
> On 2024-07-31 21:50:33 +, Mathias Gibbens wrote:
> > Hi,
> >
> > For the past ~4 days the testing excuses for golang-google-genproto
> > has said that it would attempt migration to testing, but that hasn't
> > happened yet. Is something else stuck, or somewhere I could look to see
> > why
Hi,
On 04-08-2024 09:31, Niels Thykier wrote:
That leaves us with 3/15 and the question whether we want to commit for
future firmware.
I don't think we need to commit, just express a very strong desire to
build on buildds when possible, and be practical if we can't.
Paul
OpenPGP_signature
Roland Clobus:
On 03/08/2024 18:30, Niels Thykier wrote:
Had a quick look at the testing `Sources` file for non-free-firmware.
We are 10/15 on `Autobuild: yes` with remaining 5 not having the header.
...
The 5 that are not `Autobuild: yes` would be:
atmel-firmware
bluez-firmware
I was infor
12 matches
Mail list logo
